Synopsys System Verilog API Donations to Accellera

1. Synopsys System Verilog API Donations to Accellera João Geada

2. 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

3. Direct C interface • Requirements • Use model • Additions to System Verilog • Value exchange API • Direct access • Abstract access • DirectC function • DirectC module

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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”

12. 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);

13. Questions & Answers • 5 minutes time limit

14. Assertion API • Requirements • Static assertion information • Assertion iterators • Type information • Source information • Dynamic assertion information • Callbacks • Assertion controls

15. 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

16. 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

17. 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

18. Questions & Answers • 5 minutes time limit

19. Coverage Metrics API • Requirements • User level coverage API • System tasks • C API • Tool level • C API

20. 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

21. 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

22. 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

23. 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()

24. 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

25. Questions & Answers • 5 minutes time limit