Asserts Spectre17.1

Device Checks/Asserts
Product Version: SPECTRE 17.1.0
December, 2017
Copyright Statement
© 2017 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders.
Learn more at Cadence Support Portal - https://support.cadence.com

© 2017 Cadence Design Systems, Inc. All rights reserved worldwide. Page 2
Device Checks/Asserts (RAK)
Contents
Purpose ..................................................................................................................... 4
Prerequisites .............................................................................................................. 4
Overview .................................................................................................................... 4
Introduction ................................................................................................................ 5
Use Model ................................................................................................................. 7
Commonly used asserts ............................................................................................ 8

Voltage assert ........................................................................................................ 8
Current assert ...................................................................................................... 14
Physical dimensions assert ................................................................................. 16
Current density assert.......................................................................................... 17
Boolean assert..................................................................................................... 20
Inline subckt assert .............................................................................................. 22
Workshop exercise .................................................................................................. 24

1. assert – mod, dev, param, modelparam, and primitive ................................. 24
2. assert – level ................................................................................................. 26
3. assert – anal_types ....................................................................................... 27
4. assert – maxvio_perinst, maxvio_all ............................................................. 29
5. checklimit – check_windows ......................................................................... 30
6. checklimit – enable/disable ........................................................................... 32
7. checklimit – param=level, param=duration ................................................... 33
8. options – checklimit_skip_subs ..................................................................... 34
9. options – checklimit_full_duration ................................................................. 35
10. options – asserts_silent_init....................................................................... 37
Support .................................................................................................................... 39
Feedback ................................................................................................................. 39

Purpose
This rapid adoption kit (RAK)/workshop database describes the usage of the commonly
used asserts available in Spectre and Spectre APS. Assert statement enables you to
perform checks on operating point parameters, model parameters, node voltages, device
currents. Sub circuit scoping is supported and asserts using boolean and non-boolean
expressions are also supported. These device checks are different from Safe Operating
Check (SOA) checks, through which the user can setup checks for circuit conditions,
operating regions and, device checking.
Prerequisites
Basic working knowledge of running simulations with Spectre.
Overview
This Rapid Adoption Kit (RAK) will demonstrate how to use the Spectre Asserts using
command line. At the end of this workshop, you will be able to write Spectre assert
statements.
This RAK is intended for design and verification engineers who are interested in using
asserts using Spectre/APS simulators to identify and debug violations in required circuit
behavior.
Separate workshops and RAK’s are available covering related topics:
1. Static and Dynamic Checks RAK

2. ADE XL RAK
3. Introduction to Device Safe Operating Area (SOA) Circuit Conditions & Asserts
RAK
Introduction
The Spectre assert statement enables you to perform checks on design parameters,
node voltages, element currents, model parameters, operating point parameters, and
expressions. Typical applications are parameter out-of-range checks, and save operation
element voltage and current checks. Use of wildcards and subcircuit scoping are
supported. When multiple assert checks are used, the check and checklimit statements
enable you to manage which check is active during which analysis.
Note: The Spectre assert, check, and checklimit statements are supported only
in Spectre and Spectre APS. Spectre XPS does not support this functionality.
The assert Statement

With the assert statement, you can set custom characterization checks to specify the safe
operating conditions for your circuit. The Spectre circuit simulator then issues messages
telling you when parameters move outside the safe operating area and, conversely, when
the parameters return to the safe area, peak value and duration of violations. When a
variable changes from an above-max value directly to a below-min value in one simulation
step (that is, no stay within bounds), the Spectre simulator uses a middle-bound solution
(min+max)/2 to report the peak value and the duration of violations. By default, Spectre
reports the margin value as value - boundValue. However, if the ASSERT_PEAKMARGIN
environment variable is set to 1, Spectre reports the margin value as peakValue -
boundValue.
The output destination of all asserts is specified by the keyword checklimitdest.

There are 3 options available: file, psf, and both.
file --> all violations are written to the logfile or file specified by checklimitfile
psf --> all violations are written just to the psf simulation directory
All asserts can be applied either globally to the entire design, or locally to specific blocks
of a design. The scoping options are available to define the scope of each design check.
The design checks can be applied to a specific subcircuit instance (dev=…), or to all
instances of a subckt definition (sub=”…”), or to an array of subcircuit
masters(subs=[…]), or to subcircuit master patterns (subs=[inv* *buf*]). For
further details on the scoping, please check the Spectre User Manual or use command
“% spectre -h”.

The command-line for running SPECTRE is shown below.
1. Spectre®
% spectre netlist.scs
2. Spectre® APS
% spectre +aps netlist.scs
If the netlist is in spice format that please add +spice in command line.

Use Model
The syntax used by the assert checks can be characterized by the following Spectre
syntax. The spice syntax is not supported.
Syntax
<Assert Name> assert <param=value> <expr=” MDL expression”>
Examples:
diode_vtg_assert assert mod=diode1 param=v min=-1 max=0.5
current_density_check assert dev=R1 expr="abs(I(1))>1u"
boolean_check assert mod=pch expr="(V(g,s)<-1 || V(g,s)>1)"
message="PMOS gate voltage exceeded" duration=0.1n
The key parameters are:

1. mod … device model to which an assert is applied to.
2. param …defines a parameter to which assert is to be performed on.
3. expr …defines a MDL expression to be checked. If expr returns true, violation is
reported.
4. duration …defines a time limit over which a violation is reported
The next section demonstrates the commonly used asserts. Notice that for each assert,
its corresponding netlist <netlistName> is in the sub-directory that is named by
<netlistName>.

Commonly used asserts

In this section, commonly used asserts are introduced and explained along with example
of each category with the help of simple circuits. Output waveforms are also shown along
with time points to better visualize the violations.
Voltage assert
The purpose of this section is to get familiar with the voltage assert. Here you will
learn how to create an assert for quickly figuring out forward biased diodes in the
entire circuit.
Action 1: Open the netlist voltage.scs, review the circuit and the assert
statement.
vgs_invalid assert subs=[inv] mod=nch param=vgs min=-11

max=1.0 message="Maximum voltage exceeded !!" duration=0.1n
Checks the operating point vgs of model nch over device instances present in the
inv subckt and prints a warning Maximum voltage exceeded !! if the value
of vgs is less than -11 and higher than 1.0.
Similarly, an assert may be used to perform terminal voltage check as below –

parameter
cap_vtg assert dev=C1 expr="V(1)" min=-1 max=1 message="cap

terminal voltage exceeded beyond +/-1V !!" duration=0.1n
Checks the terminal voltage V(1) in the instance C1 and prints a warning cap
terminal voltage exceeded beyond +/-1V !! if the value of V(1) is less
than -1 and higher than 1.0. Here V(1)refers to the positive terminal of the
capacitor.

message="Maximum diode voltage exceeded - Improper bias -
diode forward biased !!" duration=1n
Checks the parameter v over all instances of the model diode1 and prints a
warning Maximum diode voltage exceeded - Improper bias - diode
forward biased !! if the value of v is less than -1 and higher than 0.5.
Figure 1
The top-level circuit is shown above.
Action 2: Run the netlist with Spectre.
LINUX:>> spectre voltage.scs
Action 3: Open and review the log file voltage.log. Check for any warning
messages.
Here’s the waveform for this circuit. The associated assert name is written besides
the signal being used in that assert.

cap_vtg
vgs_invalid
diode_vtg_assert
Figure 2.
Marker is placed at 1.0V for vgs and out in above waveform plot.
The first assert statement will check value of vgs parameter for nch model. If it
goes above 1V, a warning message is written to the log file as below -
Warning from spectre at time = 360 ps during transient analysis `tran'.
WARNING (SPECTRE-4017): vgs_invalid: Maximum voltage exceeded !!.

Instance I2.X21.MN1, Parameter `vgs' having value 3.74649 V has exceeded its
upper bound `1'.
To generate the waveform plot below, right click on the name of signal, choose
Type-> points.

Figure 3. Zoomed-in portion of I22.X21.MN1:vgs at the start of simulation.
The first assert statement also outputs a message when value of vgs returns to
below 1V as shown below -
Warning from spectre at time = 3.56554 ns during transient analysis `tran'.
WARNING (SPECTRE-4020): vgs_invalid: Instance I2.X21.MN1, Parameter

`vgs' having value 953.818 mV has returned to within bounds [-11, 1].
Similar warnings are displayed for other transistors. Please review the log file
carefully and understand the violations.
The second assert statement will be true @ V(1)>1 V for duration >=100 psec as
shown below -
WARNING (SPECTRE-4018): cap_vtg: cap terminal voltage exceeded beyond

+/-1V !!. Instance C1, Parameter `V(1)' having value 1.38652 V has exceeded its
upper bound `1'.

Figure 4. Zoomed-in portion of the signal V(mid) at the start of violation ‘cap_vtg’.
As soon as V(out) has returned to within bounds, below message is displayed –

WARNING (SPECTRE-4021): cap_vtg: Instance C1, Parameter `V(1)' having
value 795.947e-03 V has returned to within bounds [-1, 1].
Figure 5. Zoomed-in portion of the signal V(mid) near the end of violation ‘cap_vtg.

The third assert statement will check value of diode voltage for diode1 model. If it
goes below -1V for 1nsec, a warning message is written to the log file as below -
WARNING (SPECTRE-4011): diode_vtg_assert: Maximum diode voltage

exceeded - Improper bias - diode forward biased !!. Instance D2, Parameter `v'
having value -4.86476 V has exceeded its lower bound `-1'.
Figure 6. Zoomed-in portion of the diode voltage near the start of violation
‘diode_vtg_assert’.
From here on, voltage for D2 diode remains below -1V.
Here, as you may have seen, the voltage you want to check can be at a node in
the circuit or a sub circuit or a diode terminal or a voltage parameter of a transistor.

Current assert
Action 1: Open the netlist current.scs, review the circuit and the design check
statement.
diode_current_assert assert mod=diode1 param=i min=-1m

max=20m message="Danger: diode working outside of safe zone:
current exceeded !!" duration=1n
Checks the current parameter i over all instances of the model diode1 and prints
a warning Danger: diode working outside of safe zone: current
exceeded !! if the value of i is less than -1mA and higher than 20mA for
duration>=1nsec.
LINUX:>> spectre current.scs
Action 3: Open and review the log file current.log. Check for any warning
messages.
Here’s the current waveform for diode D1.
Figure 7 waveform plot of diode D1 current.

The assert will become true when i goes above 20mA for duration>=1nsec as
shown below –
WARNING (SPECTRE-4017): diode_current_assert: Danger: diode working

outside of safe zone: current exceeded !!. Instance D1, Parameter ì' having value
42.4793 mA has exceeded its upper bound `20e-03'.
Figure 8. Zoomed-in portion of the D1 diode current at the start of violation

‘diode_current_assert’.
As soon as i has returned to within bounds, below message is displayed –
WARNING (SPECTRE-4020): diode_current_assert: Instance D1, Parameter ì'

having value 14.1654 mA has returned to within bounds [-1e-03, 20e-03].

Figure 9. Zoomed-in portion of the D1 diode current at the end of violation

‘diode_current_assert’
Physical dimensions assert
Action 1: Open the netlist physical_dimensions.scs, review the circuit and the
design check statement.
check_width_invalid assert dev=MP1 expr="w/l" min=3e-6

max=50e-6 message="PMOS: Gate width over length ratio went
beyond range!!" level=warning
Checks the expression w/l in the device instance MP1 and prints a warning
PMOS: Gate width over length ratio went beyond range!! if the
value of w/l is less than 3u and higher than 50u.
LINUX:>> spectre physical_dimensions.scs

Action 3: Open and review the log file physical_dimensions.log. Check for any
warning messages.
Here for MP1: w=4u l=45n; w/l = 88.8889
The warning message is displayed just once and not at every time step since the
assert is always true in this case –
Warning from spectre at time = 67.5303 fs during transient analysis `tran'.
WARNING (SPECTRE-4104): check_width_invalid: Instance MP1, PMOS:

Gate width over length ratio went beyond range!!. Expression `w/l' having value
88.8889 has exceeded its upper bound `50e-06'.
Current density assert

Action 1: Open the netlist current_density.scs, review the circuit and the design
check statements.
Figure 10. Circuit.

current_density_check assert dev=R1 expr="curr=abs(I(1));
I_max=J_max*area; abs(I(1))>(J_max*area)" message="Current
density level of resistor has exceeded beyond the safety
limit!!" duration=0.1p

Checks the boolean expression abs(I(1))>(J_max*area) in the device

instance R1 and prints a warning Current density level of resistor
has exceeded beyond the safety limit!! when the boolean expression
is true and returns the value of curr and I_max.
LINUX:>> spectre current_density.scs
Action 3: Open and review the log file current_density.log. Check for any
warning messages.
Here’s the current waveform for resistor R1.
Figure 11. Waveform of current through resistor R1.
WARNING (SPECTRE-4056): current_density_check, Instance R1: Current

density level of resistor has exceeded beyond the safety limit!!. Expression
`curr=abs(I(1)); I_max=J_max*area; abs(I(1))>(J_max*area)' is getting true where
curr=1.21231e-03, I_max=1e-03.

Figure 12. Zoomed-in portion of current waveform at the start of simulation.
As soon as I(1) returns to within bounds (< 1mA), below message is displayed
–
Warning from spectre at time = 21.1225 ps during transient analysis `tran'.

`curr=abs(I(1)); I_max=J_max*area; abs(I(1))>(J_max*area)' is getting false where
curr=911.326e-06, I_max=1e-03. Total duration of overshoot was 20.7163e-12.

Boolean assert
Action 1: Open the netlist boolean.scs, review the circuit and the assert statement.
boolean_check_nmos assert mod=nch expr="(V(g,s)<-1 ||

V(g,s)>1) && I(d)>0.5m" message="NMOS gate voltage exceeded
beyond +/-1V & current exceeded 500uA!!" duration=0.1n
Checks the boolean expression (V(g,s)<-1 || V(g,s)>1) && I(d)>0.5m

over all device instances of the model nch and prints a warning NMOS gate
voltage exceeded beyond +/-1V & current exceeded 500uA!! when
the boolean expression is true for duration>=0.1n.
% spectre boolean.scs
Action 3: Open and review the log file boolean.log. Check for any warning
messages. Please review the waveform below –
Figure 13. Waveform of vgs and Id for MN1.

The marker is placed at 1V for vgs and 500 mA for Id.
The assert will become true when the expr becomes true for duration>=100psec
as shown below–

WARNING (SPECTRE-4056): boolean_check_nmos, Instance MN1: NMOS

gate voltage exceeded beyond +/-1V & current exceeded 500uA!!. Expression
`(V(g,s)<-1 || V(g,s)>1) && I(d)>0.5m' is getting true.
Figure 14. Zoomed-in portion of waveform at the start of violation.
As soon as vgs returns to within bounds (< 1V), below message is displayed –
WARNING (SPECTRE-4060): boolean_check_nmos, Instance MN1: NMOS

gate voltage exceeded beyond +/-1V & current exceeded 500uA!!. Expression
`(V(g,s)<-1 || V(g,s)>1) && I(d)>0.5m' is getting false. Total duration of overshoot
was 4.74475e-09.

Figure 15. Zoomed-in portion of waveform at the end of violation.
The simulator doesn’t wait for I(d)to go within bounds [-infinity < I(d) <
0.5mA] to display the above warning.
Similarly, please review the assert statement for PMOS –
boolean_check_pmos assert mod=pch expr="(V(g,s)<-1 ||

V(g,s)>1) && I(d)<-0.5m" message="PMOS gate voltage exceeded
beyond +/-1V & current exceeded 500uA!!" duration=0.1n
As an exercise, please review and understand the warning messages related to

this assert.
Inline subckt assert

Action 1: Open the netlist inline_subckt.scs, review the circuit and the assert
statement.
InvalidModel assert dev=C2 param=A1 max=0.1f message="model

poly_cap not allowed"

Checks the inline sub circuit parameter A1 in the device instance C2 and prints a
warning model poly_cap not allowed if the value of A1 is above 0.1fF and
returns the value of A1.
Action 2: Run the netlist with Spectre
LINUX:>> spectre inline_subckt.scs
Action 3: Open and review the log file inline_subckt.log. Check for any warning
messages.
WARNING (SPECTRE-4016): InvalidModel: model poly_cap not allowed.

Subcircuit Instance C2, Parameter À1' having value 1e-15 has exceeded its upper
bound `100e-18'.
As you might have observed, you can exclude certain instances from the asserts.
Here for example, in the netlist, C3 is excluded from the assert check.
The next section contains detailed examples demonstrating new features in this
Spectre version along with already availabe features. As in last section, for each
assert, its corresponding netlist <netlistName> is in the sub-directory that is named
by <netlistName>. At the end, you will be able to write asserts with the knowledge
of how to skip asserts for certain subckts, enable and disable certain asserts using
a single statement, etc.

Workshop exercise
In this section, different dynamic checks are introduced and applied to simple circuits with
their output shown.
1. assert – mod, dev, param, modelparam, and primitive

Action 1: Open the netlist example1.scs, review the circuit and the design check
statement.
 mod=model: model type whose model or instance parameter is to be checked.
diode_area_assert assert mod=diode1 modelparam=area max=0.5n

message="Danger: diode area is too HIGH !!" duration=.01n
Checks the model parameter area over all device instances with the model
diode1 and prints a warning Danger: diode area is too HIGH !! if the
value of area is above 0.5n and returns the value of area.
You should use mod when you want to apply an assert to devices which use a
specific model. This check is useful in cases where the designer is aware of the
model of the violating devices.
 dev=device or subckt instance: only the specified device or instance will

be checked.
dev_assert assert subs=[in?] dev=MN1 param=l max=40n

message="Danger: length is > 40n !!" duration=.01n
Checks the length l of device instance MN1 in all instances of the subcircuits;
whose names match in? (in our case, it matches with inv) and prints a warning
Danger: length is > 40n !! if the value of l is above 40n and returns the
value of l.
You should use dev when you want to apply an assert to specific instances in the
whole circuit. This option is useful in cases where the designer is aware of the
violating devices or instances.
 param= paramname: paramname can be an Instance parameter, Operating

point parameter, Netlist parameter, Node voltage or device, terminal current.
param_invalid assert dev=MN1 param=w min=1u max=1.5u

message="width > 1.5 u or width < 1u !!" duration=0.1n

Checks the width w of device instance MN1 in all instances of the subcircuits and
prints a warning width > 1.5 u or width < 1u !! if the value of w is above
1.5u or below 1u and returns the value of w.
param is often used to quickly point out violating devices in the circuit. For
example, it can enable the designer in locating the dangerously big as well as
extremely devices which can break the circuit.
For subcircuit instances, paramname can be a subcircuit parameter.
sub_assert assert subs=[buffe?] param=area max=40n

message="Danger: length is > 40n !!" duration=.01n
Checks the subcircuit parameter area in all instances of the subcircuits; whose
names match buffe? (in our case, it matches with buffer) and prints a warning
Danger: length is > 40n !! if the value of l is above 40n and returns the
value of l.
 modelparam= paramname: paramname must be a model parameter.
dtox_assert assert mod=nch modelparam=dtox min=-1 max=-0.0002

message="dtox is too HIGH !!" duration=0.1n level=notice
Checks the model parameter dtox over all device instances with the model nch
and prints a warning dtox is too HIGH !! if the value of dtox is above -
0.0002 or below -1 and returns the value of dtox.
modelparam is used to locate violating devices based on values of model

parameters.
 primitive= primitive: All models of the specified primitive type are

checked.
tnom_assert assert primitive=bsim4 modelparam=tnom min=0

max=24 message="Primitive: temperature exceeded beyond limit
!!" duration=0.1n
Checks the nominal temperature tnom over all instances of the primitive type
bsim4 and prints a warning Primitive: temperature exceeded beyond
limit !! if the value of tnom is above 24 or below 0 and returns the value of
tnom.

LINUX:>> spectre example1.scs
Action 3: Open and review the log file example1.log. Check for any warning
messages.
2. assert – level
The purpose of this section is get familiar with the level option available in
Spectre assert. level allows you to control the severity level of the message if
the check fails. Its default value is warning. Possible values are none, notice,
warning, error, and fatal.
Action 1: Open the netlist example2.scs, review the circuit and the assert
statement.
vtg_range_invalid assert subs=[inv] mod=nch param=vgs min=-

11 max=1.0 message="Maximum voltage exceeded !!"
duration=0.1n level=none
cap_vtg assert dev=C1 param=V(1) min=-1 max=1 message="cap

terminal voltage exceeded beyond +/-1V !!" duration=0.1n
level=error

diode forward biased !!" duration=1n level=notice
These are like the voltage asserts described earlier (in first section) except the
value of level is specified here.
If the severity level is error, the Spectre circuit simulator aborts the
analysis when the first error-level violation occurs.
If the severity level is notice or warning, simulations continues after

the message is displayed.
If the severity level is none, the Spectre circuit simulator will ignore to
report such violations and continues the analysis.

% spectre example2.scs
Action 3: Open and review the log file example2.log. Check for any
notice/error/warning messages.
Notice from spectre at time = 1.12584 ns during transient analysis `tran'.

diode_vtg_assert: Maximum diode voltage exceeded - Improper bias - diode
forward biased !!. Instance D2, Parameter `v' having value -4.86472 V has
exceeded its lower bound `-1'.
As you can see above, since the level associated with diode_vtg_assert is
notice, it will report a notice and continue the simulation.
Error found by spectre at time = 1.83899 ns during transient analysis `tran'.

ERROR (SPECTRE-4018): cap_vtg: cap terminal voltage exceeded beyond +/-
1V !!. Instance C1, Parameter `V(1)' having value 1.38692 V has exceeded its
upper bound `1'.
Analysis `tran' was terminated prematurely due to an error.
As the cap_vtg assert becomes true, it will error out and exit from the simulation
as seen above.
Note: You may also choose to specify severity through the checklimit
statement (described in example6 below). This overrides the severity levels
specified for individual assert checks.
3. assert – anal_types
User can specify a list of analysis types over which the assert is to be applied. By
default, the check is applied for all the analyses specified in the netlist. Possible values
are ac, dc, tran and noise.
Example: anal_types= [dc tran]
Note: The anal_types parameter will be ignored if an invalid analysis type is specified.

Action 1: Open the netlist example3.scs, review the analyses and the assert
statement.

diode forward biased !!" duration=1n anal_types=[dc]
Checks the parameter v over all instances of the model diode1 over dc and dc
sweep analyses and prints a warning Maximum diode voltage exceeded -
Improper bias - diode forward biased !! if the value of v is less than
-1 and higher than 0.5.
Here we have a DC sweep analysis -
dc dc param=vdc start=0 stop=6 step=0.5 annotate=steps
=> vdc is swept from 0 to 6 in steps of 0.5
messages. Below warning messages are displayed during dc sweep analysis –
Warning from spectre at vdc = 1.5 during DC analysis `dc'.

WARNING (SPECTRE-4011): diode_vtg_assert: Maximum diode voltage
exceeded - Improper bias - diode forward biased !!. Instance D2, Parameter `v'
having value -1.5 V has exceeded its lower bound `-1'.
WARNING (SPECTRE-4017): vtg_range_invalid: Maximum voltage exceeded !!.
Instance I2.X21.MN1, Parameter `vgs' having value 1.5 V has exceeded its upper
bound `1'.
The violations are reported just once when they occur and they are not printed
continuously at each time step afterwards even if they are true because they don’t
serve any purpose.
As an added exercise, please open the waveform with VIVA to

visualize/understand these warning messages.

4. assert – maxvio_perinst, maxvio_all

Here we have an example to illustrate how to limit the number of warnings per assert
or for all asserts.
Action 1: Open the netlist example4.scs, review the circuit and the assert
statement.
maxvio_perinst_assert_4 assert subs=[inv] mod=nch param=id

min=1u message="Maximum current exceeded !!" duration=0.1n
maxvio_perinst=4
Checks the parameter id of the model nch in all instances of the subcircuit inv
and prints a warning Maximum current exceeded !! if the value of id is less
than 1u and limits the number of violations to 4 for each checked instance.
maxvio_all_assert assert subs=[inv] mod=nch param=id min=1u

message="Maximum current exceeded !!" duration=0.1n
maxvio_all=3
Checks the parameter id of the model nch in all instances of the subcircuit inv
and prints a warning Maximum current exceeded !! if the value of id is less
than 1u and limits the number of violations to 3 for all checked instances during
the analysis.
messages.
Note: The warnings are displayed when the violation becomes true and when it
becomes false i.e., the value of the parameter being checked has returned to within
bounds.
As an exercise, perform –
% grep maxvio_all_assert example4.log
And verify that maxvio_all option is working as expected. Similarly verify this
for maxvio_perinst_assert_4.

5. checklimit – check_windows
User can specify a time window over which the assert is to be checked in the
checklimit statement.
Action 1: Open the netlist example5.scs, review the circuit, assert and the
checklimit statement.
Figure 16. Circuit for the netlist in this example

check_0to1p3n assert mod=nch param=V(g) check_windows=[0
1.3n] min=0 max=0.9
Checks the gate voltage V(g) over all instances of model nch from 0 to 1.3n
and prints a warning message if V(g) is higher than 0.9V or less than 0V and
returns the value of V(g).
messages.

Please compare the violations against the regular assert statement which outputs
violations over the complete simulation time window.
Warning from spectre at time = 1.22 ns during transient analysis `transient1',

during task `MDLControl'.
WARNING (SPECTRE-4015): check_alltimes: Instance MM0, Parameter `V(g)'

having value 1.2 V has exceeded its upper bound `900e-03'.
WARNING (SPECTRE-4015): check_0to1p3n: Instance MM0, Parameter `V(g)'

having value 1.2 V has exceeded its upper bound `900e-03'.
Warning from spectre at time = 1.8269 ns during transient analysis `transient1',

during task `MDLControl'.
WARNING (SPECTRE-4021): check_alltimes: Instance MM0, Parameter `V(g)'

having value 786.199e-03 V has returned to within bounds [0, 900e-03].

6. checklimit – enable/disable
You can enable or disable an assert or a group of asserts with the checklimit
statement. You can define one or more checklimit statements in the netlist, each
enabling or disabling individual asserts. The statement is applied to subsequent
transient, DC, and DC sweep analyses until the next checklimit statement appears.
By default, all asserts are enabled.
Action 1: Open the netlist example6.scs, review the assert and the checklimit
statements.
myChecklimit checklimit enable=[diode_*]

disable=[vtg_range_invalid cap_vtg] severity=error
check_windows=[0 3n]
Checks will be enabled for diode_current_assert and diode_vtg_assert

and vtg_range_invalid and cap_vtg checks will be disabled. severity
level of the messages will be error. check_windows option indicates the time
or sweep windows within which the assert is to be enabled. Here, checks will be
active from 0 to 3n.
Action 3: Open and review the log file example6.log. Check for any error
messages.
Error found by spectre at time = 1.12584 ns during transient analysis `tran'.

ERROR (SPECTRE-4011): diode_vtg_assert: Maximum diode voltage exceeded
- Improper bias - diode forward biased !!. Instance D2, Parameter `v' having value
-4.86472 V has exceeded its lower bound `-1'.
Since, we have specified error as the severity level for all the enabled alerts,
the simulation is killed once the first error-level assert occurs.
Analysis `tran' was terminated prematurely due to an error.

7. checklimit – param=level, param=duration

At instances, the designer may want to modify level and duration parameters for
specific asserts which are already defined inside the design or subckt. It will be
cumbersome to modify each assert. Alternatively, checklimit can provide this
functionality. Please see the example below for usage.
Action 1: Open the netlist example7.scs, review the circuit, assert, checklimit
statements and options.
checkLimit_level_note checklimit asserts=[*] param=level

value=notice
Sets the level for all asserts to notice. Please note the default value of level
is warning.
checkLimit_duration_1u checklimit
asserts=[vtg_range_invalid] param=duration value=1n
Sets the duration for the assert vtg_range_invalid to 1ns. Original value
was 0.1ns.
Action 3: Open and review the log file example7.log. Check for any warning/notice
messages.
Please note the value when violation is reported and the level of messages.
Notice from spectre at time = 1.27896 ns during transient analysis `tran'.
vtg_range_invalid: Maximum voltage exceeded !!. Instance I2.MN1, Parameter

`vgs' having value 3.7418 V has exceeded its upper bound `1'.

8. options – checklimit_skip_subs
At instances (for e.g., when iterations of circuit/device checks are performed), the
designer might already know which subcircuits do not contain violating instances. And
if the designer wants to skip such subcircuits from being checked, it can be
implemented by using checklimit_skip_subs=[...]which is a global option.
User can alternatively choose to add such subcircuits in a file and use
checklimit_skip_file parameter. This file contains the subcircuit masters or
subcircuit master patterns to be skipped in device checking. Patterns can have any
wildcard symbols.
Action 1: Open the netlist example8.scs, review the circuit, assert statements and
options.
simulatorOptions options dochecklimit=yes

checklimitdest=file checklimit_skip_subs=[buffer]
Checks will be enabled for current_assert while checks will be disabled for
vtg_range_invalid and area_assert because the later asserts contain
subs=[buffer].
Action 3: Open and review the log file example8.log. Check for the asserts which
are enabled or ON.

9. options – checklimit_full_duration
The option checklimit_full_duration enables the designer to change the
reported duration of the violation.
If set to yes, assert violation includes the duration for which the violation takes
place, and uses interpolation when the value exceeds the max/min bound value.
checklimit_full_duration=yes => outputs full duration of violation.
Possible values are no and yes. Default value is ‘no’.
options.
assertOpts options checklimitdest=both dochecklimit=yes

checklimit_full_duration=yes
Action 3: Open and review the log file example9.log. Please carefully review the
warning messages and the waveform below –
Figure 17. Waveform of current for R1. (Marker @ 1mA)

Figure 18. Zoomed-in portion of waveform at the start of violation.
The violation start time is same for checklimit_full_duration= yes or no

as below –

`curr=abs(I(1));
I_max=J_max*area; abs(I(1))>(J_max*area)' is getting true where

curr=1.21231e-03, I_max=1e-03.
With checklimit_full_duration=no

`curr=abs(I(1));

I_max=J_max*area; abs(I(1))>(J_max*area)' is getting false where

(total reported duration of violation = 21.1225 ps – 0.40615 ps = 20.71635 ps;

please refer to Figure 18.)
With checklimit_full_duration=yes

`curr=abs(I(1));
I_max=J_max*area; abs(I(1))>(J_max*area)' is getting false where

(total reported duration of violation 21.1225 ps – 0.20595 ps = 20.91655 ps; please

refer to Figure 18.)
10. options – asserts_silent_init

Asserts may output multiple warning messages if a subckt is not present in the
design. In early phase of design, designer may need to have an ability to suppress
initialization warning messages related to asserts present in the PDK subckts.
To enable this, user can assign a group name to an assert, then use the global
option:
asserts_silent_init=[ xxx "group=yyy" ]
to suppress initialization warning message of the listed assert xxx and assert
group yyy.
o Default value of group is default.
o Wildcard is not supported in asserts_silent_init;
o Double quotes are required to specify the group name for e.g.,
"group=yyy".

options.
assertOpts options checklimitdest=file dochecklimit=yes

asserts_silent_init=[ "group=default" "group=group1" chk2
chk02 ]
Action 3: Open and review the log file example10.log. Please carefully review the
warning messages.
Without using this global option, the log file contains 15 warning messages
related to asserts being ignored as below –
Warning from spectre during initial setup.
WARNING (SPECTRE-16685): res_I:Specified device instance `xxx' was not found.

Assert is ignored.
WARNING (SPECTRE-16460): chk03:Specified subcircuit master `xxx' was not found.
WARNING (SPECTRE-16462): chk03:Error in specification of subcircuit master. Assert

is ignored.

is ignored.

is ignored.

is ignored.

is ignored.


is ignored.

is ignored.
With this global option properly set, the log file now contains just 3 warning
messages related to asserts being ignored as below –
Warning from spectre during initial setup.
WARNING (SPECTRE-16685): res_I:Specified device instance `xxx' was not
found. Assert is ignored.
WARNING (SPECTRE-16460): chk03:Specified subcircuit master `xxx' was not
found.
WARNING (SPECTRE-16462): chk03:Error in specification of subcircuit master.
Assert is ignored.
Support
Cadence Support Portal provides access to support resources, including an extensive
knowledge base, access to software updates for Cadence products, and the ability to
interact with Cadence Customer Support. Visit https://support.cadence.com.
Feedback
Email comments, questions, and suggestions to
content_feedback@cadence.com.


Asserts Spectre17.1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Asserts Spectre17.1

Încărcat de

Drepturi de autor:

Formate disponibile

Device Checks/Asserts

Product Version: SPECTRE 17.1.0

Learn more at Cadence Support Portal - https://support.cadence.com

Use Model ................................................................................................................. 7

Commonly used asserts ............................................................................................ 8

Workshop exercise .................................................................................................. 24

Learn more at Cadence Support Portal - https://support.cadence.com

Basic working knowledge of running simulations with Spectre.

Separate workshops and RAK’s are available covering related topics:

1. Static and Dynamic Checks RAK

The assert Statement

The output destination of all asserts is specified by the keyword checklimitdest.

Learn more at Cadence Support Portal - https://support.cadence.com

The command-line for running SPECTRE is shown below.

% spectre +aps netlist.scs

Learn more at Cadence Support Portal - https://support.cadence.com

The key parameters are:

Learn more at Cadence Support Portal - https://support.cadence.com

Commonly used asserts

vgs_invalid assert subs=[inv] mod=nch param=vgs min=-11

Similarly, an assert may be used to perform terminal voltage check as below –

cap_vtg assert dev=C1 expr="V(1)" min=-1 max=1 message="cap

diode_vtg_assert assert mod=diode1 param=v min=-1 max=0.5

Action 2: Run the netlist with Spectre.

LINUX:>> spectre voltage.scs

Learn more at Cadence Support Portal - https://support.cadence.com

Warning from spectre at time = 360 ps during transient analysis `tran'.

WARNING (SPECTRE-4017): vgs_invalid: Maximum voltage exceeded !!.

Learn more at Cadence Support Portal - https://support.cadence.com

Figure 3. Zoomed-in portion of I22.X21.MN1:vgs at the start of simulation.

Warning from spectre at time = 3.56554 ns during transient analysis `tran'.

WARNING (SPECTRE-4020): vgs_invalid: Instance I2.X21.MN1, Parameter

Warning from spectre at time = 1.83877 ns during transient analysis `tran'.

WARNING (SPECTRE-4018): cap_vtg: cap terminal voltage exceeded beyond

Learn more at Cadence Support Portal - https://support.cadence.com

As soon as V(out) has returned to within bounds, below message is displayed –

Warning from spectre at time = 51.0212 ns during transient analysis `tran'.

Learn more at Cadence Support Portal - https://support.cadence.com

Warning from spectre at time = 1.12584 ns during transient analysis `tran'.

WARNING (SPECTRE-4011): diode_vtg_assert: Maximum diode voltage

Learn more at Cadence Support Portal - https://support.cadence.com

diode_current_assert assert mod=diode1 param=i min=-1m

Action 2: Run the netlist with Spectre.

LINUX:>> spectre current.scs

Here’s the current waveform for diode D1.

Figure 7 waveform plot of diode D1 current.

Learn more at Cadence Support Portal - https://support.cadence.com

Warning from spectre at time = 53.1011 ns during transient analysis `tran'.

WARNING (SPECTRE-4017): diode_current_assert: Danger: diode working

Figure 8. Zoomed-in portion of the D1 diode current at the start of violation

As soon as i has returned to within bounds, below message is displayed –

Warning from spectre at time = 100.1 ns during transient analysis `tran'.

WARNING (SPECTRE-4020): diode_current_assert: Instance D1, Parameter `i'

Learn more at Cadence Support Portal - https://support.cadence.com

Figure 9. Zoomed-in portion of the D1 diode current at the end of violation

Physical dimensions assert

check_width_invalid assert dev=MP1 expr="w/l" min=3e-6

Action 2: Run the netlist with Spectre.

LINUX:>> spectre physical_dimensions.scs

Learn more at Cadence Support Portal - https://support.cadence.com

Here for MP1: w=4u l=45n; w/l = 88.8889

Warning from spectre at time = 67.5303 fs during transient analysis `tran'.

WARNING (SPECTRE-4104): check_width_invalid: Instance MP1, PMOS:

Current density assert