• Save
Re usable continuous-time analog sva assertions
Upcoming SlideShare
Loading in...5
×
 

Re usable continuous-time analog sva assertions

on

  • 626 views

This paper shows how SystemVerilog Assertions (SVA) modules can be bound to analog IP blocks, shall they be at behavioral or transistor-level, enabling the assertions to become a true IP deliverable ...

This paper shows how SystemVerilog Assertions (SVA) modules can be bound to analog IP blocks, shall they be at behavioral or transistor-level, enabling the assertions to become a true IP deliverable that can be reused at SoC level. It also highlights how DPIs can fix analog assertions specificities, such as getting rid of hierarchical paths, especially when probing currents. This paper also demonstrates how to flawlessly switch models between digital (wreal) and analog models without breaking the assertions. Finally, it demonstrates how one can generate an adaptive clock to continuously assert analog properties whose stability over time is critical, such as current or voltage references or supplies.

Statistics

Views

Total Views
626
Views on SlideShare
626
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Re usable continuous-time analog sva assertions Re usable continuous-time analog sva assertions Document Transcript

  • CDNLive! EMEA 2012 1 Re-usable continuous-time analog SVAassertionsRe-usable continuous-time analog SVA assertionsRegis Santonja, Mixed-Signal Verification Engineer, FreescaleSemiconductorAs the advanced digital verification techniques get adopted by the analog and mixed-signal world, systemverilog assertions (SVA) and PSL have increasingly been adoptedto verify the correct integration of analog IPs within mixed-signal SoCs. However,several difficulties get along the way. Primarily, how do we re-use our set of analogassertions vertically? In other words, how can we develop a Verification IP (VIP) that isable to access the design signals both at block-level and at SoC level without editingtheir hierarchical paths. This might sound natural for digital guys, but we’ll see that inanalog, probing currents with no hierarchical path is not obvious. Secondly, how do were-use our analog assertions between wreal models and AMS models, or even with theactual design at transistor level (in the digital world, this would be re-using the sameassertions between RTL and gate-level)At first glance, PSL appears to be well-suited to overcome these challenges: it directlyaccesses the signals of the DUT, as the vunits stand in the same scope as the bounddesign. It can even access the V() and I() analog operators. And it is language-agnostic:PSL assertions can co-exist in a verilog-AMS code. However, this makes it less re-usable than SVA, as the PSL code makes an explicit reference to the design signalnames. As such, PSL assertions need to be edited when applied to a new design inwhich signal names have changed. Additionally, PSL does not provide a straightforward way (without a TCL interaction with the simulator [13]) to execute actionblocks to interact with the testbench i.e. to accumulate the number of failures. It canneither provide any information to a testbench monitor. Additionally, it is yet anotherlanguage to manage in a verification environment which is likely to use systemverilogextensively (such as in a UVM-MS environment). For these reasons, we decided to useSystemVerilog instead.In this paper, we present a methodology based on SVA. A DPI gives access to thesignals of the bound design as if the assertions were at the same level of hierarchy. Assuch, no hierarchical path appears in the assertion’s code which can then be re-used at
  • CDNLive! EMEA 2012 2 Re-usable continuous-time analog SVAassertionsblock or SoC levels. This methodology is also able to assert properties related to bothvoltage and current signals as the Cadence $cgav() system task permits. However, thelatter can only access signals from the analog domain and fails short when the DUT ismodeled in wreal. Another DPI is used to enable both analog and wreal values to befetched. Additionally, we are able to assert analog properties in the continuous-timedomain thanks to a global adaptive assertion clock that ensures no analog hazard (i.e.glitches, overshoots, etc…) gets overlooked.1. IntroductionToday’s Mixed-Signal SoCs have hundreds, if not thousands, of mechanisms to beverified before tape-out. As a consequence, it is vain to start chip-level simulationswhen the design is finished. The verification process actually starts at system-level,before any transistor is available. Then, the SoC’s implementation is verified as thedesign gradually becomes available.Figure 1 - V-curve of Verification CycleThis is a continuous process during the project’s development cycle: blocks evolve, andthe simulation suite needs to be re-run on each “release candidate” version of the designto ensure no regression was introduced by the design changes. As the tape-out dateapproaches, the design, hopefully, gets mature and stabilizes. However, it is not seldomto require a late design change right before tape-out. This is what verification is all
  • CDNLive! EMEA 2012 3 Re-usable continuous-time analog SVAassertionsabout: identify what should be fixed before we go to silicon. Of course, there is no waywe can visually inspect all simulation waveforms in such a short period of time. Even ifwe could (with an army of verification engineers), it is a human brain weakness to payless and less attention to things repeatedly seen equal before. Fortunately, simulators donot get influenced by any remembrance of previous simulations. This is why we need tohave the simulator do the checks for us. We call “assertions” a piece of code thatcontinuously checks a property of the design. Systemverilog provides a powerful syntaxfor assertions that can be applied, not only to the digital side of the Soc, but also to itsanalog part. There have been many different papers on analog assertions already. But, toour knowledge, none was able to present a unified methodology for re-usable,continuous-time analog assertions.2. Assertion re-use2.1. Systemverilog bind statementThere are two kinds of assertions: the ones developed by the block designers, and theones developed by the integration and/or verification team. We could split those intomore sub-categories, but let’s consider these for now. The first assertions are embeddedinside the design blocks. The second ones might either reside in the bench itself, or justbe another set of assertions embedded into the chip-level module. But in any case,assertions must access the signals of the DUT without any hierarchical path in theircode to be re-usable. Let’s say you have several instances of a FIFO in your chip. Youwant to be able to re-use the exact same code for each FIFO instance. The systemverilogbind statement is exactly made for that purpose. It allows you to gather your block-levelassertions in a module and “project” it into your block under verification. Then you canaccess its signals by creating as many inputs to your assertion module as needed, andconnect them to the signals to monitor, just as you would do for a usual instantiation.This has the advantage over PSL vunit that the bind statement creates a new scope in thetarget module. Hence the signals to monitor do not need to appear with the same nameinto the assertion code. If the signal names change, you can always re-connect themwithout having to edit the assertions code.
  • CDNLive! EMEA 2012 4 Re-usable continuous-time analog SVAassertionsFigure 2 - SV Bind mechanism2.2. A few other re-usability considerationsThere are several other considerations to ensure yourassertions can be re-used, like using some existing assertionslibrary, such as the ones available in the Open VerificationLibrary (OVL). You can build your own libraries too.Your assertions could also use named properties with formalarguments, such as in the example below:property prop_delay(signal, cond, delay, min, max);@(clk) cond |-> ($time-t0)[*0:$] ##1 (signal >= min) && (signal <+ max) ;endpropertyassert_vref_0v6: assert property (prop_delay(vref_0v6, enable, 5e4, 0.59,0.61) else $warning (“%m failed”);2.3. What about currents?So, is that really so simple? For digital guys, yes… But not for mixed-signal and analogengineers. All is fine as long as you only want to monitor potentials: in the same way asFigure 3 - Courtesy ofAcceleraFigure 4 - Named property example with formal arguments to help re-use
  • CDNLive! EMEA 2012 5 Re-usable continuous-time analog SVAassertionsfor digital signals, you can create input ports to your monitor. You can then rely on theelaboration phase to insert E2R connect modules. The latter allow your assertions towork with real-number expressions.But as you want to verify you analog blocks, you will also need to monitor its currents.Either current references or current consumption. And for that, you would need yourmonitor to be placed in series on the branch you want to measure the current from. Youwould need to open the branch, insert your module, and reconnect the branch on bothsides. You simply can’t do that without editing your design, which is something youdon’t want to do.2.4. Using value fetch mechanismSo is it lost? Fortunately not. Cadence provides another means to access signals thanthrough the monitor’s ports. The mechanism is called value fetch. This is what$cds_get_analog_value (aka $cgav()) is good for:always @(clk) beginvoltage = $cgav(“top.dut.blockA.net123”, “potential”);current = $cgav(“top.dut.blockB.port123”, “flow”);endUnfortunately, the latter needs, as a first argument, either a name in the local scope, or aa complete hierarchical path in a string. As the signals we want to monitor are one levelof hierarchy above the monitor, a full hierarchical path is required, making the code un-re-usable again!.. Systemverilog IEEE 1800-2012 specifies that “the name of a moduleor module instance is sufficient to identify the module and its location in the hierarchy.A lower level module can reference items in a module above in the hierarchy”. Hence, ifwe could give a relative path, starting at the level of the cell we are monitoring (it is onelevel above the bound monitor), all would be fine: the assertion code would be re-usableagain. Unfortunately, if this runs flawlessly with Incisiv 12.10 with digital signals, thisdoes not work when referencing analog ones. And this does not work with $cgav()system function either:ERROR (VALUEFETCH-004) $cds_get_analog_value() failed: Failed tofetch the value of [path…]”To solve this issue, we developed a small DPI.Figure 6 - $cgav error when trying to access a net or a port in a higher-level of hierarchy with arelative hierarchical pathFigure 5 - Example of $cgav usage to probe analog potential or flows
  • CDNLive! EMEA 2012 6 Re-usable continuous-time analog SVAassertions2.5. Using a DPI to get rid of hierarchical pathsIn order to work around this difficulty, we use an ad hoc DPI which returns a string ofthe complete path of a net or a port in the block directly above. It is the place where thesignals to monitor are when we call this DPI from the bound module. This DPI is usedto generate the appropriate string that will bepassed as the first argument to $cgav():module monitor (input logic clk);import “DPI-C” context function stringgenPath(string netName);real voltage;real current;string PATH= genPath(“net”);always @(clk) beginvoltage = $cgav(PATH, “potential”);current = $cgav(PATH, “flow”);endendmoduleThe way the DPI works is that it retrieves the scope of its call. This is a string thatcontains the full hierarchical path to the monitor instance. Then it removes the monitorinstance name and replaces it with the net name given as an argument to the DPI. Theresult is the hierarchical path of the net or port from which we want to fetch a value.#include <stdio.h>#include <string.h>#include "svdpi.h"char* getPath (char *netName) {char *scope;static char fullPath[100];// Get scope of calling functionscope = svGetNameFromScope(svGetScope() );// Prepare full path prefix, including the last dotstrcpy(fullPath,scope);if (strrchr(fullPath,.)!=NULL)*(strrchr(fullPath,.)+1)=0; // +1 to include the dotelse printf("t DPI: ERROR : no dot found in path");// Append the net name to the hierarchical prefixstrcat(fullPath,netName);printf("t DPI: %s", fullPath);return fullPath;}net(electrical)real voltagereal currentblock under testmonitorFigure 9 - DPI to compute the full hierarchical string name of the net/port given as an argumentFigure 7 - Example of SV monitor using DPI tocompute hierarchical name of probed signalFigure 8 - Fetching values on the blockunder test (principle)
  • CDNLive! EMEA 2012 7 Re-usable continuous-time analog SVAassertionsIn order to have a unified way of accessing both potentials and currents, we like to alsouse this value fetch mechanism for potentials. As a consequence, our monitors willlikely have no ports at all (in fact the last section will introduce a clock port). So are wedone? Not yet…2.6. Assertions re-use when switching between behavioral modelsand schematics (transistor-level)In AMS-designer, the schematics from Cadence Framework are netlisted in verilog-AMS format (in opposition to a spice or spectre netlist for example). As such they aredeclared as “modules” and the bind mechanism works just fine: this allows us to switchour module’s view from AMS (or wreal) to schematic and vice-versa flawlessly…Unfortunately, $cgav() is not able to fetch any value from the digital domain. As aconsequence, if we want to switch to a wreal model, there is no chance to make it workas is…The work-around is yet another DPI used to access digital domain values:The DPI retrieves the net’s hierarchical name using getPath(), and uses it as anargument to the VPI’s function vpi_get_value(). The latter’s output is formatted as avpiRealVal and returned.Now that we have this DPI, we use Cadence’s $cds_analog_is_valid() system task tocheck if the net to measure is within the analog domain, and if the arguments that weintend to use with $cgav() are correct ($cds_analog_exists() can also optionally be used#include <stdio.h>#include <vpi_user.h>#include <string.h>#include "svdpi.h"double getReal (char *netName){vpiHandle net;s_vpi_value vpi_val;net = vpi_handle_by_name(getPath(netName), NULL);vpi_val.format = vpiRealVal;vpi_get_value(net, &vpi_val);return vpi_val.value.real;}Figure 10 - DPI used to value fetch logic or wreal nets
  • CDNLive! EMEA 2012 8 Re-usable continuous-time analog SVAassertionsto determine if the net is analog). If analog, we use $cgav(), otherwise we use getReal().We actually have a verilog macro for that. For some reasons, $cds_analog_is_valid and$cgav() are not able to evaluate the value returned by a function as an argument: forexample, $cds_analog_is_valid(getPath(“name”)) fails. We use wrapping functions towork-around this limitation: VAL is the name of the real variable which is going to receive the net’s expected value. QUAL is the quantity_qualifier (“potential”, “flow”, “pwr”, or “param”) SIG is a string (between quotes) matching the name of the signal to monitorSimilarly, a macro called `get_logic is used to fetch signals that we intend to assert aslogic signals (as opposition to using real values). This is typically for digital signals thatmight be turned into analog during full-transistor simulations.As long as the signal is digital, we use a DPI called getLogic. It is very similar togetReal but returns a scalar (0, 1, x, z) instead of a real. This makes the assertions easierto write. Finally, some similar macros are used to fetch values from digital or analogbusses. Finally, our monitor would look like this:function automatic logic caiv(string name, string qualifier="potential");string path=getPath(name);caiv = $cds_analog_is_valid(path, qualifier);endfunctionfunction automatic real cgav(string name, string qualifier="potential");string path=getPath(name);cgav = $cgav(path, qualifier);endfunction`define get_value(VAL, QUAL, SIG) real VAL; always @(clk) if (caiv(SIG,QUAL)) VAL=cgav(SIG, QUAL); else VAL=getReal(SIG);`define get_logic(VAL, SIG, THS) real VAL; always @(clk) if (caiv(SIG,QUAL)) VAL=(cgav(SIG, “potential”) > THS); else VAL=getLogic(SIG);Figure 11 – Macro used to sort fetched signal from analog or digital domain and use theappropriate fetch task callFigure 12 - Macro used to assert logic signals that might be turned into analog duting full-transistor simulations
  • CDNLive! EMEA 2012 9 Re-usable continuous-time analog SVAassertionsIn this example, a clock port was introduced to trig the assertion. In this case, we’reusing local property variables to record successive values of the regulator’s output inorder to check its monotonicity. Note that it is slightly simplified here. In a realsituation, a tolerance needs to be considered, especially for the case where the regulatoris turned into transistor-level.3. Continuous-time SVA analog assertionsNow, when talking about analog assertions, we’re talking about being able to monitorcontinuous values and continuous time signals. Recent improvements of systemverilogallow real-valued signals to be asserted, but still in the digital discrete-time domain.Indeed, assertions need a digital “clock” signal to be triggered. A few years ago, we hada hard time with a SoC showing a short but big current spike during boot (due to anESD diode being triggered) that was not captured by our simulation bench. Since thistime we decided not to take the risk to overlook analog glitches anymore. There arethree solutions for that.module monitor (input logic clk);import "DPI-C" context function string getPath (string netName);import "DPI-C" context function real getReal (input string path);`get_value(vrega, "potential", "vrega")`get_value(ivssa, "flow", "vssa")// Check monotonicity of VREGA// ---------------------------property vrega_monotonicity;real x1, x2;@(clk) (bg_ok, x1 = vrega) |-> ##1 (`TRUE, x2 = vrega) ##0 (x2>=x1);endpropertyassert_vrega_monotonicity: assert property (vrega_monotonicity)PRINT_PASS("VREGA is monotonic"); else begin $warning("%m failed");PRINT_ERROR("VREGA is not monotonic"); endendmoduleFigure 13 - SV monitor example using macro and DPI to prevent hierarchical names during valuefetch
  • CDNLive! EMEA 2012 10 Re-usable continuous-time analog SVAassertions3.1. Increase assertions clock frequencyPrior art often makes the assumption that the properties to check are static (i.e. outputlevel of a voltage regulator), or « semi-static »: the signal properties can only reach aknown number of static states based on a digital controller (i.e. a regulator can haveseveral programmable output voltages, an oscillator can be programmed for severalfrequencies, etc…). In this case, it is often considered that the digital controller’s clockcan be used to sample the analog signal. However, any unexpected instability of thesignal between edges of the controller’s clock could be overlooked. If some instabilityduring a bounded settling time after the controller’s clock edges is expected, someinstability could be due to internal analog mechanisms that should be captured foranalysis.In case of continuous signals that do not depend on a digital controller, it is up to theengineer’s discretion to choose an appropriate frequency. Usually, the Nyquist criterionis applied: the sampling clock’s frequency is chosen to be twice the frequency of thelargest frequency component of the signal. Unfortunately, when a signal does notbehave as expected (this is what verification wants to capture), its theoretical maximumfrequency might not be known in advance. Finally, we can just arbitrarily increase theassertions clock frequency and potentially kill our simulation time.3.2. Use verilog-A/MS continuous-time monitorsContinuous-time monitors can easily be generated in verilog-A or verilog-AMS. Theanalog process allows them to monitor the signals at each analog time-step preventingany analog hazards to be overlooked. However, the @cross or @above statements thatthese monitors are likely to use introduce additional time-steps, that were not originallyrequired by the SoC itself, slowing down the simulation. Furthermore, these verilog-A/MS monitors add to the load of the analog solver, as they need to be instantiated intothe design for each signal to monitor. Additionally, these monitors have no direct accessto the coverage database and need to be associated with a systemverilog counterpart. Asa consequence, asserted properties need to be split across different languages andmodules, making the code harder to understand and maintain.
  • CDNLive! EMEA 2012 11 Re-usable continuous-time analog SVAassertions3.3. Generate an adaptive assertion clockNone of the two previous solutions are satisfactory (using a regular clock, or a verilog-A/MS monitor). The best would be if one could use an adaptive clock to trigger theassertions on the time-step that the analog solver determined appropriate for the SoC.This is exactly the solution we adopted. The piece of verilog-AMS code below just doesthat:The analog process is executed at each time step of the analog solver. At time zero,clk_a is set to zero. At the first time step, it becomes 1.0 – 0.0 =1.0. On the secondtime-step, clk_a is back to its initial value zero, and so on. The always @ statement thendigitizes this analog clock. No @cross or @above are used to prevent the solver togenerate any additional time steps. The absdelta statement is used to generate events onclk_a value changes.The adaptive clock can then be connected to each bound monitor. Monitors wouldtypically also use a traditional digital clock. However, as we already saw, the monitoredsignals are not connected to the monitors ports (they are fetched instead).bind DigCore dig_monitor digmon (.clkd(clkd));bind PowerMgt PM_monitor PMmon (.clka(analog.clk), .clkd(clkd));bind SigChain sc_monitor scmon (.clka(analog.clk), .clkd(clkd));bind ADC adc_monitor adcmon (.clka(analog.clk), .clkd(clkd));bind OSC osc_monitor oscmon (.clka(analog.clk), .clkd(clkd));bind PadRing padring_monitor padmon(.clka(analog.clk), .clkd(clkd));`include "disciplines.vams"module analog_timestep();real clk_a;reg clk = 1b0;always @(absdelta(clk_a, 10m, 10p, 1m))if ((clk_a == 1.0) || (clk_a == 0.0)) clk = ~clk;analog beginclk_a = 1.0 - clk_a;endendmoduleFigure 14 - verilog-AMS adaptive clock generatorFigure 15 - Example of bound monitors connected to the adaptive continuous-time clock. Typically ausual digital clock is also used
  • CDNLive! EMEA 2012 12 Re-usable continuous-time analog SVAassertionsThe assertions on the voltage regulator presented on the snapshot below were preparedon a regulator wreal model. Then the regulator was turned into a more accurate AMSmodel. Finally, the regulator was turned into a schematic with its non-idealities. Indeed,a glitch was found as the bandgap was switched from low-power to low-noise mode.Figure 16 - Snapshot presenting a glitch captured on a regulator outputAs the adaptive clock does not have a regular period, the assertions sequences cannot beexpressed in terms of number of cycles anymore. However, for usual timing checks, onecan still use a regular clock. Indeed, the adaptive clock is not intended to be used for allanalog assertions, but for the ones that monitor signals whose stability over time iscritical. For example, checking that the regulator settle time is below 10us, one can stilluse an ad hoc 1us period clock and count 10 periods.
  • CDNLive! EMEA 2012 13 Re-usable continuous-time analog SVAassertionsIn this example, the clock is started on the pre-condition of the assertion, and stopped bya task attached to the assertion, at the successful match of the subsequent(postcondition) sequence.4. Adaptive-clock assertion exampleUsual SystemVerilog assertions use Linear Temporal Logic sequence operators such ascycle delay ##, consecutive repetition [* ], non-consecutive repetition [= ] or gotorepetition [-> ]. These operators are not well-suited for handling continuous-time. A lotof research is going on, involving both Accelera and IEEE standardization Comittees tocome up with an enhanced set of operators dedicated to handling continuous signals.However, some continuous-time assertions can already be developed using the $timesystem task.4.1.Delayed assertionsSystemverilog IEEE 1800-2012 introduced deferred assertions to “suppress false reportsdue to glitching activity”. However, the latter are a subset of immediate assertions. Assuch, they cannot describe behaviors that span over time, as concurrent assertions do.reg clk_1us = 1b0;reg run_clk_1us = 1b1;always #500 clk_1us = ~clk_1us & bg_ok & run_clk_1us;task stop_clk_1us; run_clk_1us = 1b0; endtaskproperty vrega_startup_within_10us;@(posedge clk_1us) bg_ok |-> ##[0:10] (vrega >= 0.9*vthi,stop_clk_1us);endpropertyassert_vrega_startup_within_10us: assert property(vrega_startup_within_10us ) PRINT_PASS("VREGA startup time iswithin 10us"); else begin $warning("%m failed"); PRINT_ERROR("");endFigure 18 - Example of usual regulator settling time assertionFigure 17 - Asserting settling time of a regulator with a usual digital clock
  • CDNLive! EMEA 2012 14 Re-usable continuous-time analog SVAassertionsHere below is a property which takes as an argument a delay during which the conditionto meet can be false, but after this delay, the condition must be true:The delay is measured with the system task $time, compared to a time t0 taken on therising edge of cond by a separate always process. This time t0 cannot be recordedwithin the assertion because a $rose(cond) would be required, but we want the propertyto be verified at each time-step when cond is true, not only on the rising edge of cond.The consequent (post-condition) says "wait for the delay to expire, then check that thesignal is within the tolerance". The consecutive repetition [*0:$] allows the delay not tobe expired during as many cycles as required, but then the signal condition must be trueon the next cycle. If the delay is already expired, ($time-t0 < delay)[*0:$] remainstrue thanks to the min limit being zero.This delayed property would typically be used to ensure a signal, such as a voltage orcurrent reference stays within a desired template after a settling time period.ConclusionThis paper has shown how SVA modules can be bound to analog IP blocks, shall theybe at behavioral or transistor-level, enabling the assertions to become a true IPdeliverable that can be reused at SoC level. It also highlighted how a DPI can fix analogassertions specificities, such as getting rid of hierarchical paths, especially whenprobing currents. This paper also demonstrated how to flawlessly switch modelsbetween digital (wreal) and analog models without breaking the assertions. Finally, itdemonstrated how we can generate an adaptive clock to continuously assert analogproperties whose stability over time is critical, such as current or voltage references orsupplies.property prop_delayed(signal, cond, delay, value, tol);@(clk) cond |-> ($time-t0 < delay)[*0:$] ##1 (signal >= (1-tol)*value) && (signal <= (1+tol)*value);endpropertyFigure 19 - Example of delayed property
  • CDNLive! EMEA 2012 15 Re-usable continuous-time analog SVAassertionsReferences[1] IEEE Std 1800™-2012 (Revision of IEEE Std 1800-2009 - )IEEE Standard forSystemVerilog – Unified Hardware Design, Specification, and Verification Language,IEEE Computer Society and the IEEE Standards Association Corporate AdvisoryGroup[2] SystemVerilog Assertions Design Tricks and SVA Bind Files, Sunburst Design,SNUG 2009[2] Instrumenting AMS assertion Verification on Commercial Platforms, RadjeepMukhopadhyay, S. K. Panda, Pallab Dasgipta, IIT Kharagpur, India and JohnGough,National Semiconductor Corp., Greenock, UK[4] Analog Assertion Based Verification Methodology – reality or a Dream ? Srikanth VRaghavan (http://www.cadence.com/Community/blogs/cic/archive/2011/02/09/analog-assertion-based-verification-methodology-reality-or-a-dream-part-2.aspx)[5] Assertion Writing Guide, Cadence Design Systems, USA 2012.[6] Virtuoso® AMS Designer User Guide, Cadence Design Systems, USA 2011[7] Incorporating Local Variables in Mixed-Signal Assertions, Subhankar Mukherjeeand Pallab Dasgupta – Indian Institute of Technology Kharagpur[8] Asynchronous Behaviors Meet Their Match with SystemVerilog Assertions, DougSmith, Doulos[9]Verification of mixed-signal designs using System-Verilog assertions in co-simulation, Somasunder Kattepura Sreenath, Texas Instruments, SNUG 2010 BestPaper.[10] PSL and SVA: Two Standard Assertion Languages Addressing ComplementaryEngineering Needs, John Havlicek, Freescale Semiconductor, Inc. and Yaron Wolfsthal,IBM Haifa Research Lab, Israel[11] Assertion-based verification in mixed-signal design, Prabal Bhattacharya ad DonO’Riordan, EEtimes
  • CDNLive! EMEA 2012 16 Re-usable continuous-time analog SVAassertions[12] Assertion for AMS design, Himyanshu Anand, john Havlicek, Scott Little,Freescale Semiconductor[13] Real-Valued Mixed-Signal Verification: An Abstraction Adjustable Methodology,Arthur Freitas, Freescale Semiconductor, 2013