250 likes | 431 Views
Synopsys System Verilog API Donations to Accellera. João Geada. Outline. Introduction Donations DirectC (Direct Foreign Language API) Assertion API Coverage Metrics API For each donation, will be presenting Requirements/needs addressed by API Changes/additions to SV (if any)
E N D
Synopsys System Verilog API Donations to Accellera João Geada
Outline • Introduction • Donations • DirectC (Direct Foreign Language API) • Assertion API • Coverage Metrics API • For each donation, will be presenting • Requirements/needs addressed by API • Changes/additions to SV (if any) • Overview of the API • Questions & Answers
Direct C interface • Requirements • Use model • Additions to System Verilog • Value exchange API • Direct access • Abstract access • DirectC function • DirectC module
Requirements • Users need a simple to use, high-performance interface to incorporate programming language (C/C++) models into their designs • Interface should have minimal impact on existing designs • Foreign language functions/modules usage must be identical to Verilog functions/modules • To permit arbitrary replacement of functions/modules from C to Verilog or vice-versa by merely changing the declaration
Use model • User declares external functions and/or modules in System Verilog • External functions/modules used exactly the same as normal functions & modules • Compiler generates a C/C++ header file from the external declarations • Used to validate prototypes of all external functions and modules and any complex structures passed through ports • User is not required to include this header file in their C/C++ code, though it is recommended • User supplies the C/C++ source code or object code/library to the simulator/compiler
Additions to System Verilog • One new type over System Verilog • Pointer type • Pointers are opaque in the System Verilog side and cannot be manipulated, only passed to other functions, modules • Size of pointer is not defined, permitting operation on both 32 and 64 bit simulators • Keywords • extern • Already a System Verilog keyword • cmodule • Only a keyword at the top declarative level
External C function declarations • Declarations made in the top-level context • extern [mode] [attribute] return-type function-id ( args ); • Mode is the access mode: direct or abstract • Attribute indicates if function is “pure”, ie has no side-effects • Pure functions permit more advance optimizations • All args have direction: • Input, output, inout
External cmodule declaration • External module declaration • Declarations made in the top-level context • cmodule module-id ( port-list )port-direction-list{ <cmodule code>} • All ports have direction: • Input, output, inout • Cmodule ports are always registers, never nets • No resolution function • Cmodule ports cannot be coerced • Assignments to input ports not permitted
Value exchange API • Two value exchange APIs provided • Abstract access • Direct Access • Abstract access • Safe operation • All values passed via opaque handles • Values obtained from handle via a number of provided functions (47 vc_*() functions) • Functions will validate arguments and prevent access errors • Compatible across all simulators
Value exchange API (cont.) • Direct access • Highest performance, little error checking • Uses simulator’s native format: may be simulator dependent • Errors in usage of value may result in core-dumps or unexpected behavior • Input values values with C/C++ compatible types passed by value • For all other types, and for output and inout ports, values passed by reference • Values manipulated directly in normal C/C++ operations without any error or bounds checking
DirectC Functions • Have no simulation time duration • Can be used anywhere a Verilog function could be used • Only declaration changes, not usage • May contain state and or have side-effects • These functions may not be declared “pure”
DirectC Modules • Permit simulation time to pass within C/C++ code • Used as any normal Verilog module • Only declaration changes, not usage • May contain multiple • Initial blocks • Always blocks • “global” variables, useable by all blocks, but not accessible from Verilog • C code can contain • Delay control statements • vc_delay(time); • Event control statements • @(signal);
Questions & Answers • 5 minutes time limit
Assertion API • Requirements • Static assertion information • Assertion iterators • Type information • Source information • Dynamic assertion information • Callbacks • Assertion controls
Requirements • Tools and test benches require access to assertion information • Reactive test benches • Use of temporal assertions for coverage • Debug/analysis tools • Assertions may be built-in to the simulator or provided as a add-on capability • Separate API required, to permit the API to be independent of simulator implementation
Static assertion information • Provides means to obtain • Assertion by name • Assertion iterator • Assertion clock • Assertion source info • Start line and column • End line and column • Assertion type
Dynamic assertion information • Callbacks • Callbacks on assertion events • Attempt, success, failure events, control events • Callbacks provide full information on • Attempt start and end times • Type of event • Callbacks on engine events • Initialization, finish events, control events • Assertion control • Reset, stop or terminate assertion engine • Reset, disable, enable a specific assertion • Terminate current assertion attempt(s) leaving assertion active
Questions & Answers • 5 minutes time limit
Coverage Metrics API • Requirements • User level coverage API • System tasks • C API • Tool level • C API
Requirements • Realtime coverage information needed • By reactive testbenches • To control random stimulus generators • Users require a common means to access coverage information regardless of tool or coverage metric • Coverage metrics are available both as a built-in simulator capability and as a feature provided by stand-alone tools • Separate API required, so that API independent of simulator implementation
Real time coverage system tasks • Enums • Coverage types • Line, condition, toggle, fsm state, fsm transition • Coverage types easily extended without modifying API • Scope control • Return value categories • Error, partial success, success • Control task • Enable/disable coverage • Query availability of coverage • Task to obtain current coverage value • Task to obtain coverage limiting value • Coverage % = (current / limit) * 100
Task scope control • All tasks permit operation to be carried out selectively on • Named module • Named instance • Named hierarchy • All the hierarchies below the instances of a given module • Each of the above can be arbitrarily combined, as separate individual arguments to a coverage task
Real time coverage user API • C equivalent to the system tasks • Addresses coverage reactivity requirements of HLVs and C testbenches • Enums • Equivalent to the coverage enums in SV • cm_coverage() • cm_get_coverage() • cm_get_limit()
Real time coverage tool API • Provides more detailed access to FSM coverage • Iterate over all FSMs in module/instance • cm_count_fsms(), cm_fsm_id() • State by state coverage • cm_fsm_get_state() • Transition by transition coverage • cm_fsm_get_transition() • Get FSM state vector • cm_fsm_get_statevar() • May be null for implied state FSMs
Questions & Answers • 5 minutes time limit