36
344 Advanced Verification Features Session delivered by: Padmanaban K . Session-09

Session 9 advance_verification_features

Embed Size (px)

Citation preview

Page 1: Session 9 advance_verification_features

344

Advanced Verification Features

Session delivered by:

Padmanaban K .

Session-09

Page 2: Session 9 advance_verification_features

345

Session Objectives• To learn the concept of Direct Programming interface

• To understand the concept of System Verilog regions

• To learn the concept of Program and Clocking blocks

NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 3: Session 9 advance_verification_features

346

Session Topics• Direct Programming interface

• Programming Language Interface

• System Verilog regions

• Program and Clocking Blocks

Page 4: Session 9 advance_verification_features

347

Verilog PLI• The Verilog Programming Language Interface (PLI) provides

a mechanism for Verilog code to call functions written in the C programming language.

• The venerable Verilog PLI is one of the reasons the Verilog language has been so successful for hardware design.

• Using the PLI companies and end-users can extend the capabilities of commercial Verilog simulators.

• Recently a new ―SystemVerilog‖, an extension to the IEEE Verilog standard, which includes a new way for Verilog code to call C and C++ functions.

• This interface eliminates the complexity of the earlier PLI (programming language interface) that required users to access HDL objects through a set of API and setup-explicit callback methods.

• With earlier methods such as PLI, the user must setup an explicit table to link HDL with C.

NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 5: Session 9 advance_verification_features

348

System Verilog DPI

• SystemVerilog DPI eliminates all this by allowing HDL

compiler to create the C interface and data access.

• DPI is an interface between System Verilog and a foreign

programming language.

• These Foreign languages can be a System C, C, C++ as well

as others.

• It consists of two separate layers: the System Verilog layer

and a foreign language layer.

• Both the layers are isolated from each other.

• Different programming languages can be used and supported

with the same intact System Verilog layer.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 6: Session 9 advance_verification_features

349

System Verilog DPI

• However, System Verilog defines a foreign language layer only for the C programming language.

• The methodological requirement is that the interface should allow a diversified system to be built (a design or a testbench) in which some components can be written in a language (or more

• languages) other than System Verilog, hereinafter called the foreign language.

• On a practical aspect for an easy and efficient way to connect existing code is to write in C or C++, without the knowledge and the overhead of PLI or VPI.

Page 7: Session 9 advance_verification_features

350

Two layers of the DPI

• DPI consists of two separate layers: the SystemVerilog layer

and a foreign language layer.

• The SystemVerilog layer does not depend on which

programming language is actually used as the foreign

language.

• SystemVerilog code shall look identical and its semantics

shall be unchanged for any foreign language layer.

• Different SystemVerilog requires only that its

implementation shall support C protocols and linkage.

NIV
Highlight
Page 8: Session 9 advance_verification_features

351

SystemVerilog layer

• The SystemVerilog side of DPI does not depend on the

foreign programming language.

• In the function call protocol and argument passing

mechanisms used in the foreign language are transparent and

irrelevant to SystemVerilog.

• SystemVerilog code shall look identical to the foreignside of

the interface.

• This clause does not constitute a complete interface

specification.

• It only describes the functionality, semantics, and syntax of

the SystemVerilog layer of the interface.

Page 9: Session 9 advance_verification_features

352

Foreign language layer

• The foreign language layer of the interface specifies howactual arguments are passed and how they can be accessedfrom the foreign code and are represented.

• It reveals how they are translated to and from somepredefined C-like types.

• The data types allowed for formal arguments and results ofimported functions or exported functions are generallySystemVerilog types.

• Software tools, like a SystemVerilog compiler, can facilitatethe mapping of SystemVerilog types onto foreign nativetypes by generating the appropriate function headers.

• The same SystemVerilog code (compiled accordingly) shallbe usable with different foreign language layers, regardless ofthe data access method assumed in a specific layer.

Page 10: Session 9 advance_verification_features

353

Example DPI

Example:- import "DPI" function void myInit();

// from standard math library

import "DPI" pure function real sin(real);

// from standard C library: memory

management

import "DPI" function chandle malloc(int size);

// standard C function

import "DPI" function void free(chandle ptr); //

standard C function

Page 11: Session 9 advance_verification_features

354

Disabling DPI tasks and functions

• It is possible for a disable statement to disable a block that is

currently executing a mixed language call chain.

• When a DPI import task or function is disabled, the C code is

required to follow a simple disable protocol.

• The protocol gives the C code the opportunity to perform any

necessary resource cleanup, such as closing open file handles,

closing open VPI handles, or freeing heap memory.

Page 12: Session 9 advance_verification_features

355

Advantages and Limitations of DPI

• The ability to import a C function and then directly call thefunction using the DPI is much simpler than the Verilog PLI.

• Using the DPI, the Verilog code can directly call the sinfunction from the C math library, directly pass inputs to thefunction, and directly receive value from the C function.

• Using the PLI, several steps are required to create a userdefined system task that indirectly calls and passes values tothe sin function.

Eg:- import "DPI" function real sin(real in);

always @(posedge clock)

begin slope <= sin(angle);

end

Page 13: Session 9 advance_verification_features

356

Advantages and Limitations of DPI

• DPI applications cannot schedule writing values into

simulation at a later stages simulation time.

• Verilog PLI applications can schedule value changes to

transpire at any future time.

• DPI task or function can have is limited types of formal

arguments data type that can have logic value.

• Where in verilog PLI can have function/task arguments with

both verilog and system verilog variables, net data types,

module instance and null arguments.

Page 14: Session 9 advance_verification_features

357

Advantages and Limitations of DPI

• DPI receives values directly from C functions as a functionsreturns value.

• Other programming languages indirectly.

• C function can call verilog functions and task. No otherprogrammer has this facility.

• Concurrent calls to task use the C stack.

• The DPI import declaration contains a prototype of theimported function arguments.

• The PLI does not define prototypes of system tasks andfunctions.

Page 15: Session 9 advance_verification_features

358

Features• The SystemVerilog Direct Programming Interface provides

an ideal solution for integratingVerilog models with SystemC models.

• The DPI import declarations allow Verilog code to directlycall C code without the complexity and overhead of theVerilog PLI.

• As DPI is a standard integrating model, Interfacing ofVerilog and SystemC becomes a simple and straightforwardprocess.

• To overcome the disadvantages of the Verilog PLI, DPI hasbeen introduced has got many advantages as listed.

• On the new era of system verilog DPI will replace PLI as ithas got many advanced features over PLI.

Page 16: Session 9 advance_verification_features

359

System Verilog Regions

Page 17: Session 9 advance_verification_features

360

IEEE Std 1800-2005 regions

Page 18: Session 9 advance_verification_features

361

IEEE Std 1800-2005 regions

Page 19: Session 9 advance_verification_features

362

SystemVerilog Event Regions and Advantages

• Active and NBA regions are designed for correct RTL

functionality.

• Preponed, Reactive, Re-Inactive and Postponed regions for

correct verification execution.

• Preponed, Observed, and Reactive regions for concurrent

assertion checking.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 20: Session 9 advance_verification_features

363

Preponed Events Region

• This region is to sample values that are used by concurrentassertions.

• The Preponed region is executed only once in each timestep,immediately after advancing simulation time.

• Concurrent assertions means the values of variables that areused in assertions are sampled in the Preponed region of atime slot, and the assertions are evaluated during theObserved region.

• For a simulator its not necessary to know about any futureevents, it only needs to ensure that the values present in the

• Preponed region are available to the sampling constructs,when the clocking expression is actually triggered and whileprocessing the later regions.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 21: Session 9 advance_verification_features

364

Active Events Region

• Execute all module blocking assignments

• Evaluate the Right-Hand-Side (RHS) of all nonblocking

assignments and schedule updates into the NBA region.

• Execute all module continuous assignments

• Evaluate inputs and update outputs of Verilog primitives.

• Execute the $display and $finish commands.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 22: Session 9 advance_verification_features

365

Inactive Events Region

• Inactive region is where #0 blocking assignments arescheduled.

• We should not make #0 RTL procedural assignments as perthe guideline.

• If we continue to use #0 assignments then we are trying todefeat a race condition that might exist in the code due toassignments made to the same variable from more than onealways block, which cause violation of Race AvoidanceGuideline #6.

• For good coding practices there are no need for #0 RTLassignments and hence, the Inactive region will be deletedfrom the rest of the events.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 23: Session 9 advance_verification_features

366

Nonblocking Assignment Region (BA).

• The main principal function of NBA region is to execute the

updates to the Left-Hand-Side (LHS) variables that were

scheduled in the Active region for all currently executing

nonblocking assignments.

• As Race Avoidance Guideline #1(for sequential logic use

non blocking assignment) dictates that all RTL clocked logic

modeled using an always block should be coded using

nonblocking assignments to ensure that the sequential logic

will execute in the NBA region and correctly model the

pipelined nature of sequential elements.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 24: Session 9 advance_verification_features

367

Observed Region

• This region evaluates the concurrent assertions using thevalues sampled in the Preponed region.

• Assertions that execute a pass or fail action block, actuallyschedule a process associated with the pass and fail code intothe Reactive region, not in the Observed region.

• This is because concurrent assertions are designed to behavestrictly as monitors and are not allowed to modify the state ofthe design

NIV
Highlight
NIV
Highlight
Page 25: Session 9 advance_verification_features

368

Reactive Region

• Reactive region is to execute the verification processes call

forth by program blocks.

• The Reactive region is located towards the end of the time

step; at the same time will have an access to three key pieces

of information:

• The current set of steady-state values – at the start of the

current time step.

• The next set of steady-state values, after clock and signal

propagation.

• The disposition of all concurrent assertions triggered in this

timestep.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 26: Session 9 advance_verification_features

369

Re-Inactive Region

• Re-Inactive region run with the Reactive region until allReactive/Re-Inactive events have completed.

• RTL regions (Active-Inactive-NBA) will re-trigger if theprogram execution scheduled any events in those regions inthe same timestep.

• Events are scheduled into the Re-Inactive region byexecuting #0 in a program process.

• Re-Inactive region is the dual of the Inactive RTL regionwhich is not recommended.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 27: Session 9 advance_verification_features

370

Postponed Region

• Postponed Region execute the $strobe and $monitor

commands that will show the final updated values for the

current timestep.

• This region is also used to collect functional coverage for

items that use strobe sampling.

• There is no feedback path from the Postponed region back

into the RTL or Reactive-loop regions, so the values

displayed and the coverage collected will be the final values

for that timestep.

NIV
Highlight
NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 28: Session 9 advance_verification_features

371

Clocking Blocks

• In Verilog, the communication between blocks is specified

using module ports.

• SystemVerilog adds the interface, a key construct that

encapsulates the communication between blocks, thereby

enabling users to easily change the level of abstraction at

which the inter-module communication is to be modeled.

• An interface can specify the signals or nets through which a

test bench communicates with a device under test.

• However, an interface does not explicitly specify any timing

disciplines, synchronization requirements, or clocking

paradigms.

NIV
Highlight
Page 29: Session 9 advance_verification_features

372

Clocking Blocks

• SystemVerilog adds the clocking block that identifies clock

signals, and captures the timing and synchronization

requirements of the blocks being modeled.

• A clocking block assembles signals that are synchronous to a

particular clock, and makes their timing explicit.

• The clocking block is a key element in a cycle-based

methodology, which enables users to write test benches at a

higher level of abstraction.

• Rather than focusing on signals and transitions in time, the

test can be defined in terms of cycles and transactions.

• Depending on the environment, a test bench can contain one

or more clocking blocks, each containing its own clock plus

an arbitrary number of signals.

NIV
Highlight
NIV
Highlight
NIV
Highlight
Page 30: Session 9 advance_verification_features

373

Example for Clocking Block

clocking ck1 @(posedge clk);

default input #1step output negedge; // legal

// outputs driven on the negedge clk

input ... ;

output ... ;

endclocking

clocking ck2 @(clk); // no edge specified!

default input #1step output negedge; // legal

input ... ;

output ... ;

endclocking

Page 31: Session 9 advance_verification_features

374

Example for Clocking Block

clocking bus @(posedge clock1);

default input #10ns output #2ns;

input data, ready, enable = top.mem1.enable;

output negedge ack;

input #1step addr;

endclocking

Page 32: Session 9 advance_verification_features

375

Program Block

• The module is the basic building block in Verilog. Modulescan contain hierarchies of other modules, wires, task andfunction declarations, and procedural statements withinalways and initial blocks.

• This construct works extremely well for the description ofhardware.

• However, for the test bench, the emphasis is not in thehardware-level details such as wires, structural hierarchy, andinterconnects, but in modeling the complete environment inwhich a design is verified.

• A lot of effort is spent getting the environment properlyinitialized and synchronized, avoiding races between thedesign and the test bench, automating the generation of inputstimuli, and reusing existing models and other infrastructure.

Page 33: Session 9 advance_verification_features

376

Program Block

• The program block serves three basic purposes:

1) It provides an entry point to the execution of testbenches.

2) It creates a scope that encapsulates program-wide data.

3) It provides a syntactic context that specifies scheduling in the

Reactive region.

Page 34: Session 9 advance_verification_features

377

Program Block

• The program construct serves as a clear separator between

design and testbench, and, more importantly, it specifies

specialized execution semantics in the Reactive region for all

elements declared within the program.

• Together with clocking blocks, the program construct

provides for race-free interaction between the design and the

testbench, and enables cycle and transaction level

abstractions.

Page 35: Session 9 advance_verification_features

378

Example

program test (input clk, input [16:1] addr, inout

[7:0] data);

initial ...

endprogram

or

program test ( interface device_ifc );

initial ...

endprogram

Page 36: Session 9 advance_verification_features

379

Summary• SystemVerilog DPI eliminates all this by allowing HDL

compiler to create the C interface and data access

• The main principal function of NBA region is to execute the

updates to the Left-Hand-Side (LHS) variables that were

scheduled in the Active region for all currently executing

nonblocking assignments

• The SystemVerilog Direct Programming Interface provides

an ideal solution for integratingVerilog models with System

C models.