Simulation Management - Functional Verification - Lecture Slides, Slides of Computer Science

Download Simulation Management - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Simulation Management

Simulation Management

 Pass or Fail?

 Managing Simulations

 Regression

 Behavioral Models

Managing Simulations

 Are you simulating the right model?

 Configuration Management

 Verilog Configuration Management

 VHDL Configuration Management

Configuration Management

 A configuration is the set of models used in a

simulation.

 Different from source management (revision control). Revision control deals with source files, while configuration deals with what models you are using. (behavioral vs. RTL)  For system level tests, could have a mix of both  Want an easy way to specify a particular configuration.  Could use a script to submit runs.

Verilog Configuration

Management (Cont)

 Only one that can be source controlled and

reliably reproduced – Manifest

 Not constrained to just files, can include all command line options required  These can be hierarchical  Use relative path names, not absolute.  Assumption that everyone on project is setup similar.  Some simulators have a –F option  It prepends path information of the manifest files.  Other alternative is a preprocessing script that does the same.

VHDL Configuration

Management

 VHDL is compiled (Verilog can be

compiled or interpreted)

 How do you know what you are

simulating?

 Makefiles  Reporting metrics  Configuration units

VHDL Configuration

Management (Cont)

 Reporting Metrics

 Environment should report name (and version) of files  Use within testcase run by using asserts  Use with a makefile

 Configuration Units

 Use Configuration declarations  Binds architectures to entities  Testcase uses which configuration it needs  Use configuration of configurations at top level

Output File Management

 Simulations create output files  Log file  Wave file  When running massively parallel jobs, problem with collisions.  Especially if hard coded names are used.  Want to have the ability to create unique names  <tc_name>..<log | wav>  Can use scripts to create the names (utilizing the simulators command line options.  Use Verilog/VHDL conventions to create this  Verilog: Use the manifest file and parameters with a script  VHDL: Use generics and pass in values from a script.

Running Regressions

 Must be run at regular intervals  Typically nightly

 Added to a master list called the regression suite

 Suite is to large to run overnight, can split it up into different ways:  Two lists:  One list to run nightly  One to be run over the weekend (includes nightly run)  Include a “fast mode”  Could pre-configure things  Could enable only certain functions in the stimulus models

Regression Management

 Ensure your using a version that is

regression certified!

 Simulation Run Time

 Automatic classification of regression.

Simulation Run Time

(continued)

 Don’t want to run any longer than necessary

 Randomization causes run times to vary

 Create a BFM for clock generation

 It would run a specified time from testcase, then stop clocks (thus shutting down the simulation) – this is the time bomb.  Coordinate this with generators/monitors.  If generator is done sending in transactions and checkers are done validating output, stop simulation!  If run time is reached and generator not done sending in transactions or monitors still have checking to be performed – failure.

Automatic classification of

regressions

 Using an output log scan script, determine the success or failure of a test.  For any given regression suite, a summary could be e-mailed to everyone on the team.  Could be used for status and discussions in team meetings  Should include:  T ime/Date  Design environment (unit name)  Testcase name  Random Number seed  Simulation time  Real time (wall clock)  System run on  Operating System Version  Memory in system  Paging Space on system

Benefits of Behavioral Models

 Audit of the specification  Missing functional details of the specification are uncovered earlier, not during the debug of the RTL.  Development and debug of testbenches in parallel with the RTL  Don’t have to wait for unstable RTL. Since it is behavioral, debug turn around is faster.  When RTL is available, already have a debugged regression suite.  System verification can start earlier, same benefits as above, in addition:  If behavioral is validated as equivalence to RTL, system tests will run faster.  Used as an evaluation tool for customers Docsity.com

Behavioral vs. Synthesizeable

Models

 Behaviorals may not be synthesizeable

 Behaviorals are not just for test benches

 Behaviorals describe functionality, not

implementation specifics.

 Require different mindset

 Focus on functionality  When implementation affects the behavioral, you

start writing RTL++