Expected Use Models

• Owner: Scott Little

For the categories described above, describe the ways in which we believe the analog assertions will be used. The kinds of problems and tasks we believe we are attempting to satisfy. Design/Verification. Analog/Mixed mode. Simulation/Formal. Documentation/Checking

Expected Use Models

It is expected that the assertion language will be primarily used in simulation-based mixed-signal verification. The focus of the language should be to provide assertions that can be used by verification engineers to perform functional verification of mixed-signal designs. Currently, the state of the art in formal verification engines for mixed-signal circuits is relatively immature and will not strongly influence language design and features.

The expected use models below can be largely understood in the context of the verification methodology described by Chang and Kundert in their paper entitled "Verification of Complex Analog and RF IC Designs." Briefly, the methodology involves developing behavioral models of the analog blocks. These models are checked against the implementation. The models are also used in block-level as well as system-level verification using self-checking testbenches. Currently the self-checking in these testbenches is done using Verilog-AMS monitors. The expectation is that these monitors can be replaced with assertions.

Definitions -Device-level: a transistors, resistors, etc. fabricated on the IC
-Block-level: a basic unit of the design that is created by a single designer (maybe 2 designers) such as an LNA, ADC, PLL, voltage regulator, I/O pad, op amp, etc.
-System-level: a composition of blocks and potentially "glue logic" that operate together to perform a specific function such as an RF transceiver, power management unit, SerDes, etc.
-Chip-level: the entire IC or SoC
-Performance verification: verifying performance specifications such as SNR, BER, INL, phase noise, jitter, power consumption, etc.
-Functional verification: verifying the function of a given circuit. For example, ensuring that a high value on the enable signal enables the circuit, verifying correct interconnection of blocks, verifying that a given analog value results in the expected digital output in the expected time of an ADC.

Required

The assertions language will focus on providing a solution that largely (if not completely) provides the tools necessary to verify designs in the following scenarios.

User: Behavioral model developer (Analog designer or AMS VE)
Purpose: Model vs. implementation checking
Level: Block
Circuit type: SPICE netlist/Verilog-AMS model
Description: Create a testbench to verify consistency between implementation and model. The model is ideally derived from the specification, but may also contain model design functions that are specified at the system level but not at the block level.

User: AMS VE
Purpose: Model functional verification
Level: Block
Circuit type: Verilog-AMS model
Description: Verify the functional correctness of an AMS block using the Verilog-AMS model. Depending on the size of the block, it may not be possible to verify all desired functionality of a block-level Verilog-AMS model against the implementation. It is still worthwhile to verify the full behavior of the model. This verification IP can be used in an assume/guarantee methodology at higher levels of the hierarchy.

User: VE
Purpose: System-level functional verification
Level: System/Chip
Circuit type: SystemVerilog/Verilog-AMS/SPICE netlist
Description: Verify the functional correctness of the entire system/chip. Verification requirements should focus on issues relating to proper integration of the system/chip. Using an assume/guarantee methodology at this level can be very beneficial and should include running constraints/assertions used at the block level during system/chip-level simulations.

Non-primary Focus Areas Receiving Strong Consideration

These areas do not directly fall within the primary focus area of the assertions language. However, they are closely related and their requirements should be strongly considered during language development. Complications may result in some needed features not being included in the language. In the case of exclusion, the language should be designed with serious thought for near future inclusion of these use cases.

User: Compact model developer
Purpose: Safety/reliability checks
Level: Device
Circuit type: Compact model
Description: Provide a set of assertions that govern safe/reliable use of the device that can be delivered with the device and checked at higher levels of design and verification.

User: Analog designer
Purpose: Functional verification (time domain analysis)
Level: Block
Circuit type: SPICE netlist
Description: This case relates to verifying time domain properties using a time domain simulation. At this level it is common to use waveforms to verify the design. This is useful, but there is still value that can be derived by providing assertions to provide automation and accuracy to block-level analog verification.

User: Analog designer
Purpose: Functional verification (frequency domain analysis)
Level: Block
Circuit type: SPICE netlist
Description: This case relates to verifying frequency domain properties using a frequency domain simulation. Analog designers often run some form of frequency domain simulation. Providing assertion language constructs to automatically verify properties of these waveforms adds useful functionality for analog designers. The properties should require the same constructs as a time domain simulation. There does need to be support for accessing the frequency as the independent variable instead of time.

Non-primary Focus Areas Receiving Weak Consideration

These areas may benefit from the assertions language and should be considered for future treatment. Currently, they are not a priority due to the adequacy of current solutions or to the added complexity they promise to bring to the assertions language. These use cases involve performance verification which tends to be less closely related to traditional digital verification use models than functional verification concerns.

User: Analog designer
Purpose: Functional verification (frequency domain analysis)
Level: Block
Circuit type: SPICE netlist
Description: This case relates to verifying frequency domain properties using a time domain simulation. The Verilog-AMS language does not provide thorough support for these types of analysis. Because the assertion language is based on Verilog-AMS, it is difficult for the assertion language to provide quality support for these types of properties.

User: Analog designer
Purpose: Performance verification
Level: Block
Circuit type: SPICE netlist
Description: This is one of the most time and simulation intensive tasks of the analog designer. The designer must ensure satisfaction of key performance specifications over a wide range of fabrication and operating conditions.

User: VE
Purpose: System-level performance verification
Level: System/Chip
Circuit type: SystemVerilog/Verilog-AMS/SPICE netlist
Description: There are several performance specifications that must be measured at the system/chip-level. Measuring the performance for a subset of operating conditions is often very time consuming for even a single operating condition.

-- ScottLittle - 09 Feb 2009

-- AnandHimyanshu - 04 Feb 2009