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-lis
  t ltcmodule codegt
• 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 simulators 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
• _at_(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