1 / 25

Synopsys System Verilog API Donations to Accellera

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)

hedia
Download Presentation

Synopsys System Verilog API Donations to Accellera

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related