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

2. © 2001 Synopsys, Inc. (2) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (3) CONFIDENTIAL Direct C interface Requirements Use model Additions to System Verilog Value exchange API  Direct access  Abstract access DirectC function DirectC module

4. © 2001 Synopsys, Inc. (4) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (5) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (6) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (7) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (8) CONFIDENTIAL External cmodule declaration External module declaration  Declarations made in the top-level context  cmodule module-id ( port-list ) port-direction-list { }  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. © 2001 Synopsys, Inc. (9) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (10) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (11) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (12) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (13) CONFIDENTIAL Questions & Answers 5 minutes time limit

14. © 2001 Synopsys, Inc. (14) CONFIDENTIAL Assertion API Requirements Static assertion information  Assertion iterators  Type information  Source information Dynamic assertion information  Callbacks  Assertion controls

15. © 2001 Synopsys, Inc. (15) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (16) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (17) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (18) CONFIDENTIAL Questions & Answers 5 minutes time limit

19. © 2001 Synopsys, Inc. (19) CONFIDENTIAL Coverage Metrics API Requirements User level coverage API  System tasks  C API Tool level  C API

20. © 2001 Synopsys, Inc. (20) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (21) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (22) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (23) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (24) CONFIDENTIAL 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. © 2001 Synopsys, Inc. (25) CONFIDENTIAL Questions & Answers 5 minutes time limit