Using a Hardware Description Language - Digital Design of Signal Processing Systems: A Practical Approach - page 61

communications as transactions and the behavior of each component at the functional level.
Transaction-level modeling is easy to develop and fast to simulate, so enabling the designer to
verify the functionality of the design at transaction level early in the development life cycle. RTL
models, though, are developed in parallel but are very slow to simulate for verification and analysis
of the design. For a complex SoC design the architects need to develop these three models: the
functional model in the early stages, while the transaction-level and RTL are developed in parallel.
Building three models of a system requires them to be consistent at different stages of the design
cycle.

2.8 Example of a Verification Setup
A complete setup for testing a signal-processing based design in hardware is shown in Figure 2.19. A
C þþ environment generates constrained random test vectors to be input to the algorithm running in
C and also to the translated design that is implemented in TLM. A transactor block converts the

test vector into transactions, and these are input to the transaction-level model. The output of the
model is also in terms of transactions. A transactor converts the transactions into results that can be
compared with the output of the simulation result. A checker compares the two results to find
functional equivalence. The input to the simulator is also fed to a coverage block. This block checks
the level of coverage and can direct the dynamic constrained random generator to generate the input
sample to maximize the coverage.
When the transaction model of Figure 2.19(a) is verified, the same setup can be used to test the
RTL design as in Figure 2.19(b). A driver block is added that converts a transaction into an RTL
detailed signal to be input to the device under test (DUT). The output of the RTL implementation of
the DUT is also converted back to transactions. Amonitor checks the cycle-by-cycle behavior of the
DUT using assertions.

þþ

2.9 SystemVerilog
As designs becomemore complex in functionality, test-vector generation for appropriate coverage is
also becoming critical. Verification engineers have been using tools specific to verification, such as
Vera and e . Nevertheless there has been a need to have a unified language that supports both design
and verification of complex designs. SystemVerilog (SV) is such an initiative that offers a unified
language that is very powerful to model complex systems and provides advanced level constructs.
These constructs facilitate concise writing of test-benches and the analysis of coverage. Most of the
EDA tool vendors are continuously adding support for SV. The added features make SV a very
powerful language for hardware modeling and verification.

2.9.1 Data Types
SystemVerilog supports additional data types logic , int , bit , byte , longint and short-
int . The data type reg of Verilog is ambiguous because reg also means a physical register but
once inferred may result in a physical wire or a register. A logic type is similar to a reg where
all the bits in the variable of this type can take any one of four values: 0 , 1 , x and z . In the other
data types each bit can be 0 or 1 . The variables of these types are automatically initialized to 0 at
time zero. Table 2.13 shows all the additional data types in SystemVerilog and their related
information.