Re usable continuous-time analog sva assertions - slides

TM
Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, t
he Energy EfficientSolutionslogo, mobileGT, PowerQUICC, QorIQ, StarCore and Symphony
are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack,
ColdFire+,CoreNet, Flexis, Kinetis, MXC, Platform in a Package, Processor Expert, QorIQ
Qonverge, Qorivva, QUICC Engine, SMARTMOS, TurboLink, VortiQa and Xtrinsic are trademarks
of Freescale Semiconductor, Inc. All other product or service names are the property
of their respective owners. © 2011 Freescale Semiconductor, Inc.

TM
Freescale, the Freescale logo, AltiVec, C-5, CodeTEST, CodeWarrior, ColdFire, C-Ware, the Energy EfficientSolutionslogo, mobileGT, PowerQUICC, QorIQ, StarCore
and Symphonyare trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. BeeKit, BeeStack, ColdFire+, CoreNet, Flexis, Kinetis, MXC, Platformin a
Package, Processor Expert, QorIQ Qonverge, Qorivva, QUICC Engine, SMARTMOS, TurboLink, VortiQa and Xtrinsic are trademarks of Freescale Semiconductor, Inc.
All other product or service names are the property of their respective owners. © 2011 Freescale Semiconductor, Inc.
2
1. Introduction
2. PSL versus SystemVerilog assertions
3. SystemVerilog bind statement used to monitor analog blocks
4. Using value fetch mechanism
5. Resolving hierarchical paths
6. Switching between wreal models and transistor-level
7. Continuous-time analog assertions
8. Linear Temporal Logic versus continuous time properties
using $time
9. Conclusion

TM
3
• SystemVerilog and PSL are increasingly adopted to verify
the correct integration of analog IPs into Mixed-Signal
SoCs.
• However, several difficulties:
− Vertical re-use: from block-level to SoC-level
− Cross-model re-use: same assertion code for wreal, AMS and
transistor-level
 In digital this would be re-using the same assertions for both RTL and
gate-level
− Monitor continuous-time analog signals

TM
4
• At first glance, PSL appears to be well suited for our
needs:
− Vunits stand in the same scope as the design
− Similar to a `include statement
− Direct access to the DUT’s signals
− PSL borrows the Boolean layer of the language it is running on
→ It can access analog operators such as V() and I()
− Vunits can contain assertions, but also auxiliary AMS code

TM
5
• However, PSL has some drawbacks:
− Assertions need to be updated as design signal names change
− No straight forward way to execute action blocks to interact with the
testbench
 i.e. TCL interaction required to accumulate the number of failures
− It is yet another language to handle in a verification environment which
is likely to use systemverilog extensively
 i.e. UVM-MS bench
• SystemVerilog assertions:
− Are embedded in their own scope (module, interface, program)
− Do not need to match design signal names
− Can trig action blocks (with no need of TCL interaction)

TM
6
• Use systemverilog bind statement
− Instantiates external modules into target module
without editing the latter
− SV monitors can be « projected » into AMS modules !
− Analog schematics are netlisted as verilog-AMS
modules
 Analog blocks can be switched between behavioral or transistor-
level without breaking the assertion code
 Potentials can be asserted via monitor ports, just like logic nets
− Automatic insertion of connect modules (E2R)
 However, currents cannot be connected to the bound SV monitor
− Branch would need to be opened and monitor inserted in series

TM
7
Block A
Assertions
A assertions
bind
Block B
Block C
DUT
Assertions
B bind
Assertions
C
Assertions
B
Assertions
Cbind
bind BlockA AssertionsA I_assertionsA (<list of pins>)

TM
8
• One cannot simply put a probe on a net, as for the voltages
• Connecting a wire “somewhere” in the design to an input of the
monitor will just create another branch (with –hopefully- no
current)
• “Fetch” the current from a block’s port using $cds_get_analog_value()
• Same mechanism applied to voltage measurements (unified approach)
Syntax:
$cds_get_analog_value(hierarchical_name, [optional index, [optional quantity
qualifier]])
Example:
current: $cds_get_analog_value(“top.dut.BlockA.vdda”, “flow”);
voltage: $cds_get_analog_value(“top.dut.BlockA.vdda”, “potential”);

TM
9
• Unfortunately, the $cgav() system task requires a complete
hierarchical path as a first argument
− Unless the signal is in the same scope…
− … but our signals are one-level above in the hierarchy…
• We use a DPI genPath(string netName);
− The argument is a net or port name in the module to monitor
− The DPI builds the string of the full hierarchical path to the specified net or
port
• Our monitor would look like that:
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

TM
10
#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;
}
Retrieve scope of the DPI call
Remove instance name of
the monitor from the
hierarchical path string
Append the net/port name
and return string

TM
11
• Unfortunately $cgav() cannot fetch values from the digital solver…
− We’re using yet another DPI to access logic or wreal net values
− The DPI is calling some VPI functions:
#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;
}
Uses getPath() as an argument
to vpi_handle_by_name()
Calling vpi_get_value() on the
target net

TM
12
• We define a verilog macro to determine if $cgav() or get_v() should be called
on a net
• Macro based on Cadence $cds_analog_is_valid()
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);

TM
13
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
• Note: not using the current (ivssa) in the assertion here
Importing our DPIs
Use our macros for both
potentials and currents
(unified approach)
Use local variables

TM
14
• PSL or SV assertions executed by the digital solver
− Continuous-time signals mapped into the digital discrete time
domain
− Potential analog hazards (glitches) can be overlooked
• How to ensure analog properties continuously match ?
− Voltage/Current level, Phase, Frequency, Amplitude, etc…
• A stable clock frequency to sample the signal can only be
arbitrary.
− A 1Mhz clock (1us period) would likely not detect a 10ns glitch.
− Shall we take a 1Ghz clock instead (1ns period) and consider any
smaller glitch irrelevant, we would slow down the simulation so
much that this solution is impracticable

TM
15
• Verilog-AMS does the analog measurements
• Checks against expected are either:
1. Done in AMS and passed over to systemverilog for coverage
recording
2. Analog measurements are passed over to systemverilog (real
numbers) who is doing the actual check.
• Advantages
− Continuous-time signals can “naturally” be monitored continuously
• Drawbacks
− Two modules have to be maintained together (AMS+SV)
 Error-prone
 Not easy to read, understand and maintain
− One AMS module instantiated for each signal to monitor
 adding to the analog simulator load
 impacting the simulation time (@cross/above() create additional time-steps)

TM
16
• Systemverilog does the analog measures and checks
• Adaptive clock used to trigger the assertions:
− Based on the analog time-steps
− Time-steps are determined by the analog solver based on
 Kirchoff’s Law
 Newton-Raphson to determine next DC point
 If no DC within a limited number of iterations, choose smaller time-step,
etc…
• Advantages
− All quantities (I, V, Freq,…) to monitor and check are real numbers
− Single language, single monitor, easier maintenance and readability
− No extra load for the analog solver
− No impact on convergence
− No connect module !

TM
17
• Use a verilog-AMS module
− The analog process executes at each time step
− An analog clock is generated
− And then digitized to generate the digital clock to be used by the
assertions
 No @cross or @above to prevent addtional time steps
`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

TM
18
• Typically monitors would also use a traditional digital clock
• Signals to monitor are not connected through the monitor ports
(but 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));

TM
19
• Assertions on the voltage regulator prepared on wreal model
• Then turned into transistor-level with its non-idealities:
− A glitch was captured when transitioning from low-power to low-noise
bandgap

TM
20
• Example: regulator’s settle time
// Check settle time of VREGA is within 10us
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(t);
@(posedge clk_1us) bg_ok |-> ##[0:t] (vrega >= 0.9*vthi, stop_clk_1us);
endproperty
assert_vrega_startup_within_10us: assert property (vrega_startup(10) )
PRINT_PASS("VREGA startup time is within 10us"); else begin
$warning("%m failed");
PRINT_ERROR("");
end
Action block
called by the
assertion
Named property with formal arguments
Ad hoc clock generation

TM
21
• SV assertions use sequence operators:
− Cycle delay ##
− Consecutive repetition [* ]
− Non-consecutive repetition [= ]
− 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
written using the $time system task

TM
22
• Continuously monitor signal range while cond is true, starting after delay:
property prop_delayed (signal, cond, delay, value, tol);
@(clk) cond |-> ($time-t0 < delay)[*0:$] ##1 (signal >= (1-
tol)*value) && (signal <= (1+tol)*value);
endproperty
• 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.
− 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
• 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, and the signals condition keeps
being asserted (continuously).

TM
23
• SystemVerilog bind statement can be used to « project » an SV monitor into
any module, including a transistor-level AMS netlist
• Potentials could be accessed via ports, just like logic (E2R connect modules
inserted)
• But currents can not, hence we use value fetch ($cgav()) instead.
• A DPI is used to generate the hierarchical path string so that the monitor’s
code is re-usable (hierarchy independent)
• Another DPI, symmetrical to $cgav() for wreal nets is used together with a
verilog macro to seamlessly switch between wreal models and AMS or
transistor-level
• Finally, an adaptive clock, based on the analog time-steps is used for
asserting continuous-time properties
• Academic research is active on defining new continuous-time semantics
based on temporal logic operators with time domain ranges, error margins,
tolerances, etc…
• A future systemverilog-AMS standard has long been awaited
− Verilog-AMS + assertions
− SystemVerilog + AMS

TM
24
[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
[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 - slides

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a Re usable continuous-time analog sva assertions - slides

Similar a Re usable continuous-time analog sva assertions - slides (20)

Último

Último (20)

Re usable continuous-time analog sva assertions - slides