SystemVerilog For Design phần 9 pps

• Records or structures• The ability to package data with function/task calls • The ability to parallelize and serialize data • Semaphores to control shared resources A fundamental capab

// iterate through bytes of packet, deasserting

// Start Of Cell indicater

@(negedge Utopia.clk_out);

Utopia.clav <= 1;

for (int i=0; i<=52; i++) begin

// If not enabled, loop

while (Utopia.en === 1'b1) @(negedge Utopia.clk_out);

// Assert Start Of Cell indicater, assert enable,

// send byte 0 (i==0)

for (int i=0; i<=52; i++) begin

// If not enabled, loop

while (Utopia.en!==1'b0) @(negedge Utopia.clk_out);

Pkt.Mem[i] = Utopia.data;

@(negedge Utopia.clk_out);

end

task automatic HostWrite (int a, CellCfgType d); // configure

#10 CPU.Addr <= a; CPU.DataIn <= d; CPU.Sel <= 0;

The main testbench module uses the encapsulated methods listedabove.

Example 11-8: Utopia ATM testbench

`include "definitions.sv"

module test;

parameter int NumRx = `RxPorts;

parameter int NumTx = `TxPorts;

// NumRx x Level 1 Utopia Rx Interfaces

for (int i=0; i<=47; i++) begin

Pkt.uni.Payload[i] = 47-i; //$random(seed);

// Function to compute the HEC value

function automatic logic [7:0] hec (logic [31:0] hdr);

CellCfgType lookup [255:0]; // copy of look-up table

function logic [0:NumTx-1] find (logic [11:0] VPI);

for (int i=0; i<=255; i++) begin

if (lookup[i].VPI == VPI) begin

if (lookup[i] != CellFwd) begin

$display("Error, Mem Location 0x%h contains 0x%h, expected 0x%h",

generate // replicate access to ports

for (RxIter=0; RxIter<NumRx; RxIter++) begin: RxGen

initial begin: Sender

// Increment counter if output packet expected

for (int i=0; i<NumTx; i++) begin

//$display("Port %d sent packet", RxIter);

repeat ($random(seed)%200) @(negedge clk);

for (TxIter=0; TxIter<NumTx; TxIter++) begin: TxGen

initial begin: Receiver

// Check for all detected packets

logic [0:NumTx-1] TxDetectEnd;

generate

for (TxIter=0; TxIter<NumTx; TxIter++) begin: TxDetect initial begin

The testbench instance of the design is contained in a separate file,

so that pre-and post-synthesis versions can be used

squat #(NumRx, NumTx) squat(Rx, Tx, mif, rst, clk);

These NNI and UNI structures are grouped together as a union,which allows a single piece of storage to represent either type ofpacket Because the union is packed, a value can be stored as onepacket type, and retrieved as the other packet type This furthersimplifies the code required to transfer a packet from one format toanother

The communication between the major blocks of the design isencapsulated into interfaces This moves the declarations of theseveral ports of each module in the design to a central location Theport declarations within each module are minimized to a singleinterface port The redundancy of declaring the same ports in sev-eral modules is eliminated.

SystemVerilog constructs are also used to simplify the coderequired to verify the design The same union used to store the NNIandUNI packets is used to store test values as an array of bytes Thetestbench can load the union variable using bytes, and the value can

be read by the design as an NNI or UNI packet It is not necessary tocopy test values into each variable that makes up a packet

SystemVerilog includes a large number of additional enhancementsfor verification that are not illustrated in this example These

enhancements are covered in the companion book, SystemVerilog for Verification1

1 Spear, Chris “SystemVerilog for Verification”, Norwell, MA: Springer 2006, 0-387-27036-1.

Behavioral and Transaction

Level Modeling

RE 12-0

his chapter defines Transaction Level Modeling (TLM) as anadjunct to behavioral modeling The chapter explains howTLM can be used, and shows how SystemVerilog is suited to TLM.Behavioral modeling can be used to provide a high level executablespecification for development of both RTL code and the testbench.Transaction level modeling allows the system executable specifica-tion to be partitioned into executable specifications of the sub-systems

The executable specifications shown in this chapter are generallynot considered synthesizable However, there are some tools called

“high level” or “behavioral” synthesis tools which are able to dle particular categories of behavioral or transaction level model-ing

han-The topics covered in this chapter include:

begin state = 2; a = 0; end else state = 0;

Note that there is an even more abstract style of behavioral ing that is not cycle-accurate, and therefore can be used before thedetailed scheduling of the design as an executable specification Anexample is an image processing algorithm that is to be implemented

model-in hardware

12.2 What is a transaction?

In everyday life, a transaction is an interaction between two people

or organizations to transfer information, money, etc In a digitalsystem, a transaction is a transfer of data and control between twosubsystems This normally means a request and a response A trans-action has attributes such as type, data, start time, duration, and sta-tus It may also contain sub-transactions

A key concept of TLMs is the suppressing of uninteresting parts ofthe communication For example, if a customer has to pay $20 for abook in a shop, he can perform the transaction at many levels

Lowest level—20 transactions of $1 each

“Here is $5”, hands over the $5 bill

“OK that’s $20, here is the book”

“OK that’s $20, here is the book”

“Thanks”

This illustrates a key benefit of TLMs, that of efficiency Engineersonly need to model the level that they are interested in One of thekey motivators in the use of TLMs is the hiding of the detail suchthat the caller does not know the details of the transactions Thisprovides a much higher level representation of the interfacebetween blocks

Note that it is not just the abstracting of the data (e.g using the $20total), but also the removal of the control (less low level communi-cation), that increases the TLM abstraction and potential simulationperformance At the highest level, the book buyer is only interested

in paying the $20, and does not really care whether it is in $1s or

$5s or a $20 Hiding detail allows different implementations of aprotocol to exist without the caller knowing, or needing to know,which level is being used, and then being able to switch in and outdifferent TLMs as needed Switching in and out different TLMsmay be done for efficiency reasons, to use a less detailed more effi-cient TLM, or maybe during the life of a project, where in thebeginning only high level details are defined, and then more detailsare added over the life of the project

12.3 Transaction level modeling in SystemVerilog

Whereas behavior level modeling raises the abstraction of the blockfunctionality, transaction level modeling raises the abstraction level

of communication between blocks and subsystems, by hiding thedetails of both control and data flow across interfaces

In SystemVerilog, a key use of the interface construct is to beable to separate the descriptions of the functionality of modules andthe communication between them

Transaction level modeling is a concept, and not a feature of a cific language, though there are certain language constructs that areuseful for writing transaction level models (TLMs) These include:

spe-• Structural hierarchy

• Function and task calls across hierarchy boundaries

• Records or structures

• The ability to package data with function/task calls

• The ability to parallelize and serialize data

• Semaphores to control shared resources

A fundamental capability that is needed for TLMs is to be able toencapsulate the lower level details of information exchange intofunction and task calls across an interface The caller only needs toknow what data is sent and returned, with the details of the trans-mission being hidden in the function/task call

The transaction request is made by calling the task or functionacross the interface/module boundary Using SystemVerilog’s

interface and function/task calling mechanisms makes creating

TLMs in SystemVerilog extremely simple The term method is used

to describe such function/task calls, since they are similar to ods in object-oriented languages

meth-12.3.1 Memory subsystem example

Example 12-1 illustrates a simple memory subsystem Initially this

is coded as read and write tasks called by a single testbench Thetestbench tries a range of addresses, and tests the error flag.Example 12-1: Simple memory subsystem with read and write tasks

task ReadMem(input logic [19:0] Address,

output logic [15:0] Data,

if (Address >= LOWER && Address <= UPPER) begin

task WriteMem(input logic [19:0] Address,

input logic [15:0] Data,

if (Address >= LOWER && Address <= UPPER) begin

5000 bus error on write 080000

6000 bus error on read 080000

7000 bus error on write 0c0000

8000 bus error on read 0c0000

12.4 Transaction level models via interfaces

The next example partitions the memory subsystem into three ules, two memory units and a testbench The modules are con-nected by an interface In this design, the address regions are wiredinto the memory units One, and only one, memory should respond

mod-to each read or write If no unit responds, there is a bus error.This broadcast request with single response can be convenientlymodeled with the extern forkjoin task construct in SystemVer-ilog interfaces This behaves like a fork join containing multi-ple task calls The difference is that the number of calls is notdefined, which allows the same interface code to be used for anynumber of memory units The output values are written to the actualarguments for each task call, and the valid task call delays itsresponse so that it overwrites the invalid ones

Example 12-2: Two memory subsystems connected by an interface

module TopTLM;

Membus Mbus();

Tester T(Mbus);

Memory #(.Lo(20'h00000), Hi(20'h3ffff))

M1(Mbus); // lower addrs

Memory #(.Lo(20'h40000), Hi(20'h7ffff))

M2(Mbus); // higher addrs

endmodule : TopTLM

// Interface header

interface Membus;

extern forkjoin task ReadMem (input logic [19:0] Address,

output logic [15:0] Data,

extern forkjoin task WriteMem (input logic [19:0] Address,

input logic [15:0] Data, output bit Error); extern task Request();

extern task Relinquish();

endinterface

module Tester (interface Bus);

// forkjoin task model delays if OK (last wins)

module Memory(interface Bus);

parameter Lo = 20'h00000;

parameter Hi = 20'h3ffff;

logic [15:0] Mem[Lo:Hi];

task Bus.ReadMem(input logic [19:0] Address,

output logic [15:0] Data,

if (Address >= Lo && Address <= Hi) begin

task Bus.WriteMem(input logic [19:0] Address,

input logic [15:0] Data,

if (Address >= Lo && Address <= Hi) begin

5000 bus error on write 080000

6000 bus error on read 080000

7000 bus error on write 0c0000

8000 bus error on read 0c0000

12.5 Bus arbitration

If there are two bus masters, it is necessary to prevent both mastersfrom accessing the bus at the same time The abstract mechanism

for modeling such a resource sharing is the semaphore

SystemVer-ilog includes a built-in semaphore class object In this chapter, ever, an interface model is used This illustrates how the classbehavior can be described, using interfaces and interface methods.TheSemaphore interface in the following example has a number

how-of keys, corresponding to resources The default is one The gettask waits for the key(s) to be available, and then removes them.Theput task replaces the key(s)

The model below has an arbiter module containing the phore An alternative would be to put the semaphore in the inter-face, but this would differ from the RTL implementation hierarchy

sema-Example 12-3: TLM model with bus arbitration using semaphores

Memory #(.Lo(20'h00000), Hi(20'h3ffff)) M1(Mbus);

Memory #(.Lo(20'h40000), Hi(20'h7ffff)) M2(Mbus);

endmodule : TopArbTLM

interface Membus; // repeated from previous example

extern forkjoin task ReadMem (input logic [19:0] Address,

output logic [15:0] Data,

extern forkjoin task WriteMem (input logic [19:0] Address,

input logic [15:0] Data, output bit Error); extern task Request();

extern task Relinquish();

module Arbiter (interface Bus);

Semaphore s (); // built-in type would use semaphore s = new;

// Memory Modules

// forkjoin task model delays if OK (last wins)

module Memory (interface Bus); // repeated from previous example parameter Lo = 20'h00000;

parameter Hi = 20'h3ffff;

logic [15:0] Mem[Lo:Hi];

task Bus.ReadMem(input logic [19:0] Address,

output logic [15:0] Data,

if (Address >= Lo && Address <= Hi) begin

task Bus.WriteMem(input logic [19:0] Address,

input logic [15:0] Data,

if (Address >= Lo && Address <= Hi) begin

4000 bus error on write 00080000

4000 bus error on write 00080000

5000 bus error on read 00080000

5000 bus error on read 00080000

6000 bus error on write 000c0000

6000 bus error on write 000c0000

7000 bus error on read 000c0000

7000 bus error on read 000c0000

12.6 Transactors, adapters, and bus functional models

For TLMs to be useful for hardware design, it is necessary to nect them to the RTL models via code which is variously called

con-transactors, adapters, and bus functional models (BFMs) These

can be either master or slave adapters, depending on the direction ofcontrol

The master adapter contains tasks, called by the master subsystemTLM, which encapsulate the protocol and manipulate the signals tocommunicate with an RTL model of the slave subsystem

The slave adapter contains processes, which monitor signals from

an RTL model of the master subsystem and call the tasks or tions in the TLM of the slave subsystem

func-12.6.1 Master adapter as module

One way to code adapters is to make them modules which translate

a transaction level interface to a pin level interface, or vice-versa.The adapter has two interface ports, the transaction level and thepin level

Example 12-4: Adapter modeled as a module

MemoryPIN #(.Lo(20'h00000), Hi(20'h3ffff))

M1 (PLMbus.ADR, PLMbus.DAT, PLMbus.MRDC, PLMbus.MWTC,

PLMbus.XACK, PLMbus.BCLK);

MemoryPIN #(.Lo(20'h40000), Hi(20'h7ffff))

M2 (PLMbus.ADR, PLMbus.DAT, PLMbus.MRDC, PLMbus.MWTC,

PLMbus.XACK, PLMbus.BCLK);

endmodule : TopTLMPLM

The example below is a simplified version of the Intel Multibus(now IEEE 796) This allows multiple masters and multiple slaves.Each master has a request wire BREQ to the arbiter module and apriority input wire BPRN from the arbiter, i.e the parallel prioritytechnique specified in the standard

Example 12-5: Simplified Intel Multibus with multiple masters and slaves

// Interface header

interface Multibus;

parameter int MASTERS = 1; // number of bus masters

// structural communication

wand /*active0*/ MRDC, MWTC; // mem read/write commands

wand /*active0*/ [1:MASTERS] BREQ; // bus request

wire /*active0*/ [1:MASTERS] BPRN; // bus priority to master

// by only one master

// Tasks - Behavioral communication

extern task Request (input int n);

extern task Relinquish (input int n);

extern forkjoin task ReadMem (input logic [19:0] Address,

output logic [15:0] Data,

extern forkjoin task WriteMem (input logic [19:0] Address,

input logic [15:0] Data, output bit Error); endinterface

module Clock (Multibus Bus);

always begin // clock

If the master does not already have control of the bus, the masterhas to request it from the arbiter, wait for the priority to be granted,and then wait for the previous master to relinquish the bus Theseactions are encapsulated in the task GetBus

If no slave responds to the address, then a time out occurs and theread or write task returns with the error flag set

Example 12-6: Simple Multibus TLM example with master adapter as a module

module MultibusMaster (interface Tasks, interface Wires);

parameter int Number = 1; // number of master for

// request/grant

enum {IDLE, READY, READ, WRITE} Master_State;

logic [19:0] adr = 'z; assign Wires.ADR = adr;

logic [15:0] dat = 'z; assign Wires.DAT = dat;