|
Ref Number
|
Document Name
|
Revision
|
Availability Date
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DPF
|
Digital Processor Framework
|
|
GM
|
“Golden Model”. Also called
Reference Model
|
|
DSP
|
Digital Signal Processing
|
|
SPV
|
SimPlus Verification library
|
|
API
|
Application Programming Interface
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
DPF, standing for Digital Processing
Framework, is a C++ software framework, built upon SPV, for testing simulated
HDL designs against a bit accurate (or clock accurate) software model. These kinds of models are often used in DSP
applications, (hence the name), usually using Matlab. DPF provides a structure for creating test
benches with a high degree of automation, and the necessary interface
infrastructure to communicate with Matlab based reference models during runtime.
DPF is built on SimPlus Verification’s SPV
verification library, adding higher level concepts and project
methodology. In other words, DPF comes
with more user-ready classes and extensible base classes, and defines the
structure and relationships between the various classes of an object oriented
verification application.
DPF can be largely separated into two major
sections – active and passive. The
active sections involve stimulation of the design based on random and/or
non-random parameters. The passive
sections involve the DUT versus GM check and gathering coverage statistics.
2.1 Matlab Interface Classes
Both the active and passive sections make
use of the Matlab interface classes that make up a central component of
DPF. These classes wrap Matlab entities
such as structures, cells, and numeric arrays and matrixes, and provide a
simple, intuitive way to read and write the data contained therein.
The Matlab wrapper classes allow the user
(and the rest of the DPF infrastructure) to create Matlab entities at runtime
and use them for Matlab input or preserved in a file. Similarly, Matlab output or saved file data
can be examined at runtime.
2.2 Active
The active part of DPF includes the
generation of parameters and data and the insertion of that data into the
simulation. DPF defines several entities
for those tasks.
·
Traffic Generator
·
Registers/Memories Database
·
Drivers
2.2.1
Generation Parameters
Generation parameters can be defined in
user-level text files and recalled via the DPF API at runtime. These parameters can even be set on several
levels, allowing defaults to be defined, say, per project, per block, and per
test. Each level of the hierarchy will
override the previous levels giving great flexibility in test configuration,
without unnecessary duplication.
In addition, DPF supports a generation
scheme that involves defining a Matlab structure who’s format (fields)
represent the parameters required for stimulus.
Text file generators can then be associated with the structure’s fields
by simply naming the generator with the full path name of the field. That field’s contents can then be generated
without further intervention.
2.2.2
Registers/Memories Database
The modules in the design will often contain
registers and memories that can be read and/or written via an addressable
bus. DPF includes the means to define
these registers and memories, their on-reset defaults, and “software”
initialization values. DPF can then use
these definitions, together with a driver, to perform system initialization, as
a basis for testing the on-reset defaults (where relevant), and for random
value write-then-read testing.
2.2.3
Traffic/Data Generation
The traffic generator’s purpose is to create
an atomic unit of data, perhaps using generators defined in end-user text
files, that a driver will then insert into the design. When the driver completes its task, the
traffic generator will be notified and can decide what course of action to
take. Typically, it will generate
another batch of data, and the entire process will start over.
2.2.4 Drivers
Drivers are the abstraction from the higher
level generation to the signal domain.
Two main types of drivers are defined in DPF, (addressable) bus driver
and data drivers. The former is
responsible for driving the signals for both system initialization and the
address space testing. The latter drives
the system’s basic unit of data, e.g. a packet.
2.2.4.1
Lab to Simulation Driver
One interesting variation on the standard
driver is a driver that drives the data contained in a saved Matlab structure
(.mat file). If we choose a naming
convention for the fields and substructures that mirrors the DUT structure, it
becomes possible to drive the DUT signals based on the field data where each
element in the fields corresponds to a signal’s data for one clock cycle.
This scheme is useful for injecting predefined
input vectors into the design. It
becomes especially useful when lab equipment is available to record logic
analyzer data into such a file. Here the
recorded data can be used to recreate lab scenarios in a simulated environment,
often even with the passive section of the verification environment running –
or in other words, the GM can still be used for comparison.
2.3 Passive
2.3.1
GM Input
GM input is recorded from the DUT input
signals over time. At some user-defined
trigger, the recording will stop and the recorded values will be forwarded to
the GM for calculation of expected DUT behavior. This output forms the basis for the
comparison in the test points.
The GM functions itself will usually either
be a C++ model or a Matlab based model compiled to C with the Matlab Compiler,
mcc, or with the Matlab engine interface (which launches a Matlab instance). The GM input signals are defined at the user
level via text file configuration.
2.3.2
Test Points
The heart of DPF is the Test Point. From the user’s perspective, a test point is
a collection of parameters that define which signals to check, when to do so,
and how to map these signals to GM fields.
During the recording of GM input, each test point also records signal
values from the DUT. Following GM
calculation, the recorded signal values are compared against the expected
output. Mismatched, missing, or
superfluous values are detected as errors and both detected and expected values
are recorded to the SPV log file.
To aid in debugging, the test point GM values
can be saved to an instrumentation trace.
These instrumentation “signals” are graphical representation of the
reference model’s output – the same output used for comparison. The instrumentation trace is saved in vcd
format and synchronized with the simulation.
This file can be displayed the simulator’s wave viewer together with the
simulation trace, providing a very intuitive and easy-to-read graphical
comparison over time.
2.4
Coverage
DPF extends SPV’s coverage classes with
added capabilities and specializations for state machine coverage. Coverage objects can be defined for any
signal or group of HDL signals, on the fields of a Matlab structure, and
through derivation, for other C++ objects as well.
Specialized classes exist for covering state
machine variables; in particular, statistics for both the various states and state
transitions can be collected.
2.4.1
Coverage-Generation Feedback
A special function of the coverage objects
is generating values based on those areas least covered. When the coverage is defined on the driven
signals or on a Matlab structure’s fields, the coverage database can be used to
generate the next set of values. The
values are generated randomly, but only from those combinations least covered,
thus directing the generation towards full coverage with the least possible
number of attempts. In other words, our
generation can be 100% efficient, saving much simulation time.