Re usable continuous-time analog sva assertions

CDNLive! EMEA 2012 1 Re-usable continuous-time analog SVA
assertions
Re-usable continuous-time analog SVA assertions
Regis Santonja, Mixed-Signal Verification Engineer, Freescale
Semiconductor
As the advanced digital verification techniques get adopted by the analog and mixed-
signal world, systemverilog assertions (SVA) and PSL have increasingly been adopted
to 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 analog
assertions vertically? In other words, how can we develop a Verification IP (VIP) that is
able to access the design signals both at block-level and at SoC level without editing
their hierarchical paths. This might sound natural for digital guys, but we’ll see that in
analog, probing currents with no hierarchical path is not obvious. Secondly, how do we
re-use our analog assertions between wreal models and AMS models, or even with the
actual design at transistor level (in the digital world, this would be re-using the same
assertions between RTL and gate-level)
At first glance, PSL appears to be well-suited to overcome these challenges: it directly
accesses the signals of the DUT, as the vunits stand in the same scope as the bound
design. 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 signal
names. As such, PSL assertions need to be edited when applied to a new design in
which signal names have changed. Additionally, PSL does not provide a straight
forward way (without a TCL interaction with the simulator [13]) to execute action
blocks to interact with the testbench i.e. to accumulate the number of failures. It can
neither provide any information to a testbench monitor. Additionally, it is yet another
language to manage in a verification environment which is likely to use systemverilog
extensively (such as in a UVM-MS environment). For these reasons, we decided to use
SystemVerilog instead.
In this paper, we present a methodology based on SVA. A DPI gives access to the
signals of the bound design as if the assertions were at the same level of hierarchy. As
such, no hierarchical path appears in the assertion’s code which can then be re-used at

assertions
block or SoC levels. This methodology is also able to assert properties related to both
voltage and current signals as the Cadence $cgav() system task permits. However, the
latter can only access signals from the analog domain and fails short when the DUT is
modeled in wreal. Another DPI is used to enable both analog and wreal values to be
fetched. Additionally, we are able to assert analog properties in the continuous-time
domain thanks to a global adaptive assertion clock that ensures no analog hazard (i.e.
glitches, overshoots, etc…) gets overlooked.
1. Introduction
Today’s Mixed-Signal SoCs have hundreds, if not thousands, of mechanisms to be
verified before tape-out. As a consequence, it is vain to start chip-level simulations
when 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 the
design gradually becomes available.
Figure 1 - V-curve of Verification Cycle
This is a continuous process during the project’s development cycle: blocks evolve, and
the simulation suite needs to be re-run on each “release candidate” version of the design
to ensure no regression was introduced by the design changes. As the tape-out date
approaches, the design, hopefully, gets mature and stabilizes. However, it is not seldom
to require a late design change right before tape-out. This is what verification is all

assertions
about: identify what should be fixed before we go to silicon. Of course, there is no way
we can visually inspect all simulation waveforms in such a short period of time. Even if
we could (with an army of verification engineers), it is a human brain weakness to pay
less and less attention to things repeatedly seen equal before. Fortunately, simulators do
not get influenced by any remembrance of previous simulations. This is why we need to
have the simulator do the checks for us. We call “assertions” a piece of code that
continuously checks a property of the design. Systemverilog provides a powerful syntax
for assertions that can be applied, not only to the digital side of the Soc, but also to its
analog part. There have been many different papers on analog assertions already. But, to
our knowledge, none was able to present a unified methodology for re-usable,
continuous-time analog assertions.
2. Assertion re-use
2.1. Systemverilog bind statement
There are two kinds of assertions: the ones developed by the block designers, and the
ones developed by the integration and/or verification team. We could split those into
more sub-categories, but let’s consider these for now. The first assertions are embedded
inside the design blocks. The second ones might either reside in the bench itself, or just
be 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 their
code to be re-usable. Let’s say you have several instances of a FIFO in your chip. You
want to be able to re-use the exact same code for each FIFO instance. The systemverilog
bind statement is exactly made for that purpose. It allows you to gather your block-level
assertions in a module and “project” it into your block under verification. Then you can
access its signals by creating as many inputs to your assertion module as needed, and
connect 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 the
target module. Hence the signals to monitor do not need to appear with the same name
into the assertion code. If the signal names change, you can always re-connect them
without having to edit the assertions code.

assertions
Figure 2 - SV Bind mechanism
2.2. A few other re-usability considerations
There are several other considerations to ensure your
assertions can be re-used, like using some existing assertions
library, such as the ones available in the Open Verification
Library (OVL). You can build your own libraries too.
Your assertions could also use named properties with formal
arguments, such as in the example below:
property prop_delay(signal, cond, delay, min, max);
@(clk) cond |-> ($time-t0)[*0:$] ##1 (signal >= min) && (signal <+ max) ;
endproperty
assert_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 analog
engineers. All is fine as long as you only want to monitor potentials: in the same way as
Figure 3 - Courtesy of
Accelera
Figure 4 - Named property example with formal arguments to help re-use

assertions
for digital signals, you can create input ports to your monitor. You can then rely on the
elaboration phase to insert E2R connect modules. The latter allow your assertions to
work 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 your
monitor to be placed in series on the branch you want to measure the current from. You
would need to open the branch, insert your module, and reconnect the branch on both
sides. You simply can’t do that without editing your design, which is something you
don’t want to do.
2.4. Using value fetch mechanism
So is it lost? Fortunately not. Cadence provides another means to access signals than
through the monitor’s ports. The mechanism is called value fetch. This is what
$cds_get_analog_value (aka $cgav()) is good for:
always @(clk) begin
voltage = $cgav(“top.dut.blockA.net123”, “potential”);
current = $cgav(“top.dut.blockB.port123”, “flow”);
end
Unfortunately, the latter needs, as a first argument, either a name in the local scope, or a
a complete hierarchical path in a string. As the signals we want to monitor are one level
of 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 module
or 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, if
we could give a relative path, starting at the level of the cell we are monitoring (it is one
level above the bound monitor), all would be fine: the assertion code would be re-usable
again. Unfortunately, if this runs flawlessly with Incisiv 12.10 with digital signals, this
does 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 to
fetch 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 a
relative hierarchical path
Figure 5 - Example of $cgav usage to probe analog potential or flows

assertions
2.5. Using a DPI to get rid of hierarchical paths
In order to work around this difficulty, we use an ad hoc DPI which returns a string of
the complete path of a net or a port in the block directly above. It is the place where the
signals to monitor are when we call this DPI from the bound module. This DPI is used
to generate the appropriate string that will be
passed as the first argument to $cgav():
module monitor (input logic clk);
import “DPI-C” context function string
genPath(string netName);
real voltage;
real current;
string PATH= genPath(“net”);
always @(clk) begin
voltage = $cgav(PATH, “potential”);
current = $cgav(PATH, “flow”);
end
endmodule
The way the DPI works is that it retrieves the scope of its call. This is a string that
contains the full hierarchical path to the monitor instance. Then it removes the monitor
instance name and replaces it with the net name given as an argument to the DPI. The
result 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 function
scope = svGetNameFromScope(svGetScope() );
// Prepare full path prefix, including the last dot
strcpy(fullPath,scope);
if (strrchr(fullPath,'.')!=NULL)
*(strrchr(fullPath,'.')+1)=0; // +1 to include the dot
else printf("t DPI: ERROR : no dot found in path");
// Append the net name to the hierarchical prefix
strcat(fullPath,netName);
printf("t DPI: %s", fullPath);
return fullPath;
}
net
(electrical)
real voltage
real current
block under test
monitor
Figure 9 - DPI to compute the full hierarchical string name of the net/port given as an argument
Figure 7 - Example of SV monitor using DPI to
compute hierarchical name of probed signal
Figure 8 - Fetching values on the block
under test (principle)

assertions
In order to have a unified way of accessing both potentials and currents, we like to also
use this value fetch mechanism for potentials. As a consequence, our monitors will
likely have no ports at all (in fact the last section will introduce a clock port). So are we
done? Not yet…
2.6. Assertions re-use when switching between behavioral models
and 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 are
declared as “modules” and the bind mechanism works just fine: this allows us to switch
our 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 a
consequence, if we want to switch to a wreal model, there is no chance to make it work
as 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 an
argument to the VPI’s function vpi_get_value(). The latter’s output is formatted as a
vpiRealVal and returned.
Now that we have this DPI, we use Cadence’s $cds_analog_is_valid() system task to
check if the net to measure is within the analog domain, and if the arguments that we
intend 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

assertions
to 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: for
example, $cds_analog_is_valid(getPath(“name”)) fails. We use wrapping functions to
work-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 monitor
Similarly, a macro called `get_logic is used to fetch signals that we intend to assert as
logic signals (as opposition to using real values). This is typically for digital signals that
might 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 to
getReal but returns a scalar (0, 1, x, z) instead of a real. This makes the assertions easier
to write. Finally, some similar macros are used to fetch values from digital or analog
busses. 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);
endfunction
function 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 the
appropriate fetch task call
Figure 12 - Macro used to assert logic signals that might be turned into analog duting full-
transistor simulations

assertions
In this example, a clock port was introduced to trig the assertion. In this case, we’re
using local property variables to record successive values of the regulator’s output in
order to check its monotonicity. Note that it is slightly simplified here. In a real
situation, a tolerance needs to be considered, especially for the case where the regulator
is turned into transistor-level.
3. Continuous-time SVA analog assertions
Now, when talking about analog assertions, we’re talking about being able to monitor
continuous values and continuous time signals. Recent improvements of systemverilog
allow 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 had
a hard time with a SoC showing a short but big current spike during boot (due to an
ESD diode being triggered) that was not captured by our simulation bench. Since this
time we decided not to take the risk to overlook analog glitches anymore. There are
three 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);
endproperty
assert_vrega_monotonicity: assert property (vrega_monotonicity)
PRINT_PASS("VREGA is monotonic"); else begin $warning("%m failed");
PRINT_ERROR("VREGA is not monotonic"); end
endmodule
Figure 13 - SV monitor example using macro and DPI to prevent hierarchical names during value
fetch

assertions
3.1. Increase assertions clock frequency
Prior art often makes the assumption that the properties to check are static (i.e. output
level of a voltage regulator), or « semi-static »: the signal properties can only reach a
known number of static states based on a digital controller (i.e. a regulator can have
several programmable output voltages, an oscillator can be programmed for several
frequencies, etc…). In this case, it is often considered that the digital controller’s clock
can be used to sample the analog signal. However, any unexpected instability of the
signal between edges of the controller’s clock could be overlooked. If some instability
during a bounded settling time after the controller’s clock edges is expected, some
instability could be due to internal analog mechanisms that should be captured for
analysis.
In case of continuous signals that do not depend on a digital controller, it is up to the
engineer’s discretion to choose an appropriate frequency. Usually, the Nyquist criterion
is applied: the sampling clock’s frequency is chosen to be twice the frequency of the
largest frequency component of the signal. Unfortunately, when a signal does not
behave as expected (this is what verification wants to capture), its theoretical maximum
frequency might not be known in advance. Finally, we can just arbitrarily increase the
assertions clock frequency and potentially kill our simulation time.
3.2. Use verilog-A/MS continuous-time monitors
Continuous-time monitors can easily be generated in verilog-A or verilog-AMS. The
analog process allows them to monitor the signals at each analog time-step preventing
any analog hazards to be overlooked. However, the @cross or @above statements that
these monitors are likely to use introduce additional time-steps, that were not originally
required 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 into
the design for each signal to monitor. Additionally, these monitors have no direct access
to the coverage database and need to be associated with a systemverilog counterpart. As
a consequence, asserted properties need to be split across different languages and
modules, making the code harder to understand and maintain.

assertions
3.3. Generate an adaptive assertion clock
None 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 the
assertions 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 does
that:
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 second
time-step, clk_a is back to its initial value zero, and so on. The always @ statement then
digitizes this analog clock. No @cross or @above are used to prevent the solver to
generate any additional time steps. The absdelta statement is used to generate events on
clk_a value changes.
The adaptive clock can then be connected to each bound monitor. Monitors would
typically also use a traditional digital clock. However, as we already saw, the monitored
signals 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 = 1'b0;
always @(absdelta(clk_a, 10m, 10p, 1m))
if ((clk_a == 1.0) || (clk_a == 0.0)) clk = ~clk;
analog begin
clk_a = 1.0 - clk_a;
end
endmodule
Figure 14 - verilog-AMS adaptive clock generator
Figure 15 - Example of bound monitors connected to the adaptive continuous-time clock. Typically a
usual digital clock is also used

assertions
The assertions on the voltage regulator presented on the snapshot below were prepared
on a regulator wreal model. Then the regulator was turned into a more accurate AMS
model. 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 output
As the adaptive clock does not have a regular period, the assertions sequences cannot be
expressed in terms of number of cycles anymore. However, for usual timing checks, one
can still use a regular clock. Indeed, the adaptive clock is not intended to be used for all
analog assertions, but for the ones that monitor signals whose stability over time is
critical. For example, checking that the regulator settle time is below 10us, one can still
use an ad hoc 1us period clock and count 10 periods.

assertions
In this example, the clock is started on the pre-condition of the assertion, and stopped by
a task attached to the assertion, at the successful match of the subsequent
(postcondition) sequence.
4. Adaptive-clock assertion example
Usual SystemVerilog assertions use Linear Temporal Logic sequence operators such as
cycle delay ##, consecutive repetition [* ], non-consecutive repetition [= ] or goto
repetition [-> ]. These operators are not well-suited for handling continuous-time. A lot
of research is going on, involving both Accelera and IEEE standardization Comittees to
come up with an enhanced set of operators dedicated to handling continuous signals.
However, some continuous-time assertions can already be developed using the $time
system task.
4.1.Delayed assertions
Systemverilog IEEE 1800-2012 introduced deferred assertions to “suppress false reports
due to glitching activity”. However, the latter are a subset of immediate assertions. As
such, they cannot describe behaviors that span over time, as concurrent assertions do.
reg clk_1us = 1'b0;
reg run_clk_1us = 1'b1;
always #500 clk_1us = ~clk_1us & bg_ok & run_clk_1us;
task stop_clk_1us; run_clk_1us = 1'b0; endtask
property vrega_startup_within_10us;
@(posedge clk_1us) bg_ok |-> ##[0:10] (vrega >= 0.9*vthi,
stop_clk_1us);
endproperty
assert_vrega_startup_within_10us: assert property
(vrega_startup_within_10us ) PRINT_PASS("VREGA startup time is
within 10us"); else begin $warning("%m failed"); PRINT_ERROR("");
end
Figure 18 - Example of usual regulator settling time assertion
Figure 17 - Asserting settling time of a regulator with a usual digital clock

assertions
Here below is a property which takes as an argument a delay during which the condition
to 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 the
rising edge of cond by a separate always process. This time t0 cannot be recorded
within the assertion because a $rose(cond) would be required, but we want the property
to 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 the
signal is within the tolerance". The consecutive repetition [*0:$] allows the delay not to
be expired during as many cycles as required, but then the signal condition must be true
on the next cycle. If the delay is already expired, ($time-t0 < delay)[*0:$] remains
true thanks to the min limit being zero.
This delayed property would typically be used to ensure a signal, such as a voltage or
current reference stays within a desired template after a settling time period.
Conclusion
This paper has shown how 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 highlighted how a DPI can fix analog
assertions specificities, such as getting rid of hierarchical paths, especially when
probing currents. This paper also demonstrated how to flawlessly switch models
between digital (wreal) and analog models without breaking the assertions. Finally, it
demonstrated how we can generate an adaptive clock to continuously assert analog
properties whose stability over time is critical, such as current or voltage references or
supplies.
property prop_delayed(signal, cond, delay, value, tol);
@(clk) cond |-> ($time-t0 < delay)[*0:$] ##1 (signal >= (1-
tol)*value) && (signal <= (1+tol)*value);
endproperty
Figure 19 - Example of delayed property

assertions
References
[1] IEEE Std 1800™-2012 (Revision of IEEE Std 1800-2009 - )IEEE Standard for
SystemVerilog – Unified Hardware Design, Specification, and Verification Language,
IEEE Computer Society and the IEEE Standards Association Corporate Advisory
Group
[2] SystemVerilog Assertions Design Tricks and SVA Bind Files, Sunburst Design,
SNUG 2009
[2] Instrumenting AMS assertion Verification on Commercial Platforms, Radjeep
Mukhopadhyay, S. K. Panda, Pallab Dasgipta, IIT Kharagpur, India and John
Gough,National Semiconductor Corp., Greenock, UK
[4] Analog Assertion Based Verification Methodology – reality or a Dream ? Srikanth V
Raghavan (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 Mukherjee
and Pallab Dasgupta – Indian Institute of Technology Kharagpur
[8] Asynchronous Behaviors Meet Their Match with SystemVerilog Assertions, Doug
Smith, Doulos
[9]Verification of mixed-signal designs using System-Verilog assertions in co-
simulation, Somasunder Kattepura Sreenath, Texas Instruments, SNUG 2010 Best
Paper.
[10] PSL and SVA: Two Standard Assertion Languages Addressing Complementary
Engineering 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 Don
O’Riordan, EEtimes

assertions
[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

Re usable continuous-time analog sva assertions

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Re usable continuous-time analog sva assertions

Similaire à Re usable continuous-time analog sva assertions (20)

Dernier

Dernier (20)

Re usable continuous-time analog sva assertions