UseModels < VerilogAMS

VerilogAMS Web>AmsAssertions>RequirementsGatheringGroup>RequirementsWorkingDraft>UseModels (2009-03-02, ScottLittle) (raw view)EditAttach
---++ 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%BR%
-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.%BR%
-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.%BR%
-Chip-level: the entire IC or SoC%BR%
-Performance verification: verifying performance specifications such
as SNR, BER, INL, phase noise, jitter, power consumption, etc.%BR%
-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)%BR%
Purpose: Model vs. implementation checking%BR%
Level: Block%BR%
Circuit type: SPICE netlist/Verilog-AMS model%BR%
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%BR%
Purpose: Model functional verification%BR%
Level: Block%BR%
Circuit type: Verilog-AMS model%BR%
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%BR%
Purpose: System-level functional verification%BR%
Level: System/Chip%BR%
Circuit type: SystemVerilog/Verilog-AMS/SPICE netlist%BR%
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%BR%
Purpose: Safety/reliability checks%BR%
Level: Device%BR%
Circuit type: Compact model%BR%
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%BR%
Purpose: Functional verification (time domain analysis)%BR%
Level: Block%BR%
Circuit type: SPICE netlist%BR%
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%BR%
Purpose: Functional verification (frequency domain analysis)%BR%
Level: Block%BR%
Circuit type: SPICE netlist%BR%
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%BR%
Purpose: Functional verification (frequency domain analysis)%BR%
Level: Block%BR%
Circuit type: SPICE netlist%BR%
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%BR%
Purpose: Performance verification%BR%
Level: Block%BR%
Circuit type: SPICE netlist%BR%
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%BR%
Purpose: System-level performance verification%BR%
Level: System/Chip%BR%
Circuit type: SystemVerilog/Verilog-AMS/SPICE netlist%BR%
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.

-- Main.ScottLittle - 09 Feb 2009

-- Main.AnandHimyanshu - 04 Feb 2009
Topic revision: r3 - 2009-03-02 - 14:12:03 - ScottLittle
VerilogAMS