Thesis Functional verification with SystemC Verification with SystemC Funktionell verifiering med...

2009-10-16

Functional Verification with SystemC

Funktionell verifiering med SystemC

Author: George Kalo Employer: Integrated Systems Scandinavia AB, Stockholm Supervisor: Magnus Ljung, Integrated Systems Scandinavia AB

Christer Albinsson, KTH Syd Acceptance date: 2006-05-05 Thesis work, 10 points within Computer science and Electronic production. KTH Syd, Campus Telge

ii

This page is intentionally left blank.

iii

Abstract To manufacture ASIC designs today is a long, complex and time consuming process. First, you need to describe the behaviour of the design in a high level language such as C++. Then you need to rewrite the high level code in another language so that you can make simulations on the design, usually in VHDL or Verilog. As the complexity and the demands on the functionality of the designs become more critical, the existing methodology is not satisfying because it is time consuming and costly, as well as prone to errors due to the manual labour and human interaction. Why writing design-code several times in different languages for different abstraction levels? We have studied the use of single language, SystemC, which covers the whole ESL (Electronic System Level)- design flow. It’s adapted for designing and verifying in a high level of abstraction. SystemC is a strong candidate to become one, if not the, native language for designing and verifying designs within the next 10 year time period. Until that, the design- and verification engineers may have seen the benefits of this powerful language in conjunction with its programming-environments, Vista and AccurateC. These tools will cut the costs and above all, create a faster design- and verifying process in the overall ESL-flow. In this paper we will describe how to write a testbench in SystemC to verify an existing VHDL-design and to show how Vista and AccurateC helped us to achieve efficiency in writing SystemC code.

iv


v

Sammanfattning Att tillverka elektronikkretsar i dag är en väldig lång och komplex process, speciellt när det gäller kundspecifika applikationer. Kretsarnas beteenden beskrivs nämligen initiellt i ett högnivåspråk som exempelvis C eller C++ och därefter skrivs beteende- koden om till ett språk som man kan simulera konstruktionen i, vanligtvis VHDL eller Verilog. Allt eftersom kretsarna hela tiden blir mer komplexa och kravet på funktionalitet ökar så är denna konstruktionsprocess icke längre tillfredställande, dels för att processen tar alldeles för lång tid, och dels för att kostnaderna blir för höga. Det existerande flödet är också på tok för manuellt och därmed finns det uppenbart en källa till fel- den mänskliga faktorn. Varför skriva om samma kod i två olika språk för olika abstraktionsnivåer? Vi har istället valt att studera användandet av SystemC, ett konstruktions- och verifieringsspråk som täcker hela ESL-(Electronic Design Level) flödet och som vi tror har kapacitet att ersätta även dagens VHDL och Verilog inom 10 år. Under denna tid har förhoppningsvis konstruktions och verifieringsingenjörerna insett fördelarna med SystemC tillsammans med programmeringsmiljöerna Vista och AccurateC, vilket kan leda till en förbättrad och mer kostnadseffektiv konstruktions- och framförallt verifierings-process. I detta dokument beskriver vi hur man skriver en SystemC testbänk för att testa och verifiera en redan befintlig VHDL konstruktion. Slutligen visar vi hur Vista och AccurateC har hjälpt oss med att skriva SystemC testbänken.

vi


vii

Prefatory note First of all I would thank my supervisor Magnus Ljung, who helped me during the whole process of this thesis work. I would also thank Ronny Strömberg and Emil Hillung at the ISS Group in Stockholm for helping me with SystemC, and for sharing their experiences. Many thanks to Vincent Viteau at Summit Design in France who was helping and providing me with materials and licenses for Vista. Finally thanks to my supervisor at the Royal Institute of Technology (KTH), Christer Albinsson and Johan Renberg at the ISS Group for their support in doing this thesis work.

viii


ix

Table of content 1 INTRODUCTION ............................................................................................................................................... 1

1.1 BACKGROUND .............................................................................................................................................. 1

1.2 DESCRIPTION OF AIMS ................................................................................................................................. 1

1.3 DEMARCATION AND PROPORTIONS ............................................................................................................. 1

1.4 METHODS OF SOLUTION .............................................................................................................................. 1

2 COMPANY PRESENTATIONS ...................................................................................................................... 2

3 VHDL DESIGN DESCRIPTION ...................................................................................................................... 3

3.1 THE SBT ROUTER ....................................................................................................................................... 3

3.1.1 Input signals ....................................................................................................................................... 3

3.1.2 Output signals .................................................................................................................................... 3

3.2 DATA PACKET STRUCTURE .......................................................................................................................... 4

3.3 DESIGN SPECIFICATION ............................................................................................................................... 4

3.4 VHDL DESIGN STRUCTURE......................................................................................................................... 5

4 SYSTEMC .......................................................................................................................................................... 6

4.1 BACKGROUND AND HISTORY ....................................................................................................................... 6

4.2 SYSTEMC CHARACTERISTICS ...................................................................................................................... 6

4.3 SYSTEMC PHILOSOPHY ............................................................................................................................... 6

4.4 SYSTEMC LIBRARY OVERVIEW .................................................................................................................... 6

4.4.1 SC_MODULE .................................................................................................................................... 7

4.4.2 SC_CTOR .......................................................................................................................................... 8

4.4.3 SC_THREAD ..................................................................................................................................... 8

4.4.4 sc_fifo ................................................................................................................................................. 9

4.4.5 sc_signal ............................................................................................................................................ 9

4.4.6 sc_main ............................................................................................................................................ 10

4.4.6 sc_clock ............................................................................................................................................ 11

4.4.7 sc_port .............................................................................................................................................. 12

5 TESTBENCH ................................................................................................................................................... 13

5.1 MODELLING THE DATA PACKET .................................................................................................................. 14

5.2 DRIVER ....................................................................................................................................................... 15

5.2.1 Driver module .................................................................................................................................. 15

5.2.2 drive_data thread ............................................................................................................................ 16

5.3 RECEIVER .................................................................................................................................................. 17

5.3.1 Receiver module ............................................................................................................................. 17

5.3.2 receive_data thread ........................................................................................................................ 18

5.4 SCOREBOARD ............................................................................................................................................ 19

5.5 SC_MAIN ..................................................................................................................................................... 21

5.6 TOP MODULE .............................................................................................................................................. 22

5.6.1 Signals .............................................................................................................................................. 23

5.6.2 Module Instantiation ....................................................................................................................... 23

5.6.3 port Connections ............................................................................................................................. 23

5.7 TESTBENCH SUMMARY .............................................................................................................................. 24

5.7.1 Foreign module ............................................................................................................................... 24

6 USING VISTA .................................................................................................................................................. 26

6.1 CREATING THE PROJECT ........................................................................................................................... 27

6.2 COMPILING THE PROJECT .......................................................................................................................... 28

6.3 RUNNING THE SIMULATION ........................................................................................................................ 29

6.4 EXAMINE THE SIMULATION ......................................................................................................................... 30

x

7 USING ACCURATEC .................................................................................................................................... 31

7.1 INVOKING ACCURATEC RULE CHECKER ................................................................................................... 32

7.2 CODE CONSULTANT WINDOW .................................................................................................................... 33

8 SUMMARY ....................................................................................................................................................... 34

8.1 VISTA.......................................................................................................................................................... 34

8.1.1 Easy project configuration and management ............................................................................. 34

8.1.2 Makefiles .......................................................................................................................................... 34

8.1.3 Comprehensive design viewer ...................................................................................................... 34

8.1.4 Data acquisition ............................................................................................................................... 34

8.1.5 Waveform viewer ............................................................................................................................ 35

8.1.7 SystemC specific debug support .................................................................................................. 35

8.2 ACCURATEC .............................................................................................................................................. 35

8.2.1 Rule checker .................................................................................................................................... 35

8.2.1 Code consultant .............................................................................................................................. 35

8.3 FUTURE WORK ........................................................................................................................................... 36

9 CONCLUSIONS .............................................................................................................................................. 37

REFERENCES ..................................................................................................................................................... 1

APPENDIX A ........................................................................................................................................................ 2

APPENDIX B ........................................................................................................................................................ 4

APPENDIX C ........................................................................................................................................................ 6

APPENDIX D ........................................................................................................................................................ 8

APPENDIX E ...................................................................................................................................................... 10

APPENDIX F ....................................................................................................................................................... 13

APPENDIX G ...................................................................................................................................................... 14

APPENDIX H ...................................................................................................................................................... 16

APPENDIX I ........................................................................................................................................................ 20

APPENDIX J ....................................................................................................................................................... 27

APPENDIX K ...................................................................................................................................................... 30

xi

List of figures Figure 3.1 – SBT Router (Device Under Test) ............................................................ 3

Figure 3.2 – Packet structure ...................................................................................... 4

Figure 3.3 – VHDL-design input protocol .................................................................... 4

Figure 3.4 – The VHDL DUT (Device Under Test) ..................................................... 5

Figure 4.1 – sc_clock ................................................................................................ 11

Figure 4.2 – Port to port connection ......................................................................... 12

Figure 5.1 – Testbench structure .............................................................................. 14

Figure 5.2 – Driver module ....................................................................................... 15

Figure 5.3 – Receiver module ................................................................................... 17

Figure 5.4 – Scoreboard module .............................................................................. 19

Figure 5.5 – Testbench overview .............................................................................. 24

Figure 5.6 – Foreign stub module ............................................................................. 25

Figure 6.1 – Vista IDE architecture ........................................................................... 26

Figure 6.2 – Creating project in Vista ....................................................................... 27

Figure 6.3 – Vista project folders .............................................................................. 27

Figure 7.1 – AccurateC design flow .......................................................................... 31

Figure 7.2 – AccurateC Rulechecker GUI................................................................. 32

Figure 7.3 – Rule Checker Code Consultant ............................................................ 33

Functional verification with SystemC

1

1 Introduction

1.1 Background Functional design verification is today a larger part of the design work then the creation of the design itself. This is a trend that seems to be here to stay considering that the systems consists in a larger degree of reused blocks and parts, sometimes commercially available as Intellectual Property (IP). The development in the Electronic Design Automation (EDA) tools for design support has literally exploded, while tools for verification have seriously lagged behind. Some new interesting tools within the design and verification area are Vista and AccurateC.

1.2 Description of aims The objective of this thesis work is to write a SystemC testbench to verify an existing VHDL-design, and to evaluate and show how we can achieve efficiency using the Vista and AccurateC environments when writing SystemC code.

1.3 Demarcation and proportions The SystemC testbench must be constructed so it will test the entire VHDL-design, not only a particular block. This kind of testbench is commercially called System testbench. Since we do not have any VHDL-simulator available, we will create an “empty” DUT (Device Under Test) in SystemC instead of using the real VHDL-design. The “empty” DUT will only accepts data packets and send them further. The testbench must be built up out from the specifications provided with the VHDL-design.

1.4 Methods of solution To write the SystemC testbench, we will go trough the Language Reference Manual (LRM), examples and various tutorials for SystemC. We will also look at the documentation and go through the tutorials provided with the Vista and AccurateC installation packages.


2

2 Company presentations

The ISS Group is involved in distributing, consulting, product development and support in the electronic design and manufacturing industry. It was founded in 1986 and has 13 employees. The mission of the company is to provide on the edge tools, services and technology to the industry of primarily Scandinavia. Examples of tools that ISS provides are Vista and AccurateC. Summit Design's industry-leading ESL and HDL solutions enable SOC (System On Chip) companies to deliver products that meet system-level performance. Summit's products address engineering challenges met during the specification and implementation design phases of complex hardware/software systems. Example of tool that Summit provides is Vista IDE. Vista extends traditional IDE capabilities with hardware and system-level design and verification tools to truly support ESL design. Vista leverages several reliable tools familiar to designers such as XEmacs, GDB, gcc, and the OSCI reference simulator to simplify learning and speed adoption. Vista’s Data Introspection provides both hardware (module hierarchy) and software (class) views of the design, enabling designers to better understand and debug their SystemC designs. Vista’s advanced coding facilities, browsers, and verification capabilities natively support system level and transaction-level modelling. Actis Design provides software tools and methods to enhance SystemC- and hardware description language (HDL)-based hardware designs. The primary tool that Actis provide is AccurateC. AccurateC provides the source code analysis and debug capabilities necessary to fully utilize the power of C/C++ for hardware design. It’s easy to integrate into your SystemC-based design flow, and adds immediate value by identifying syntax, semantic and style errors in your C/C++ code prior to compilation, simulation and synthesis. Use of AccurateC promotes consistent coding standards across design teams, resulting in readable and maintainable code, for easy reuse and modification in future projects.


3

3 VHDL Design description

3.1 The SBT Router The VHDL design which will be verified is called SBT Router. It is a simple router which accepts data packets on a single input port, and routes the packet to one of the three output channels, channel0, channel1 or channel2. The router signals are shown below:

Figure 3.1 – SBT Router (Device Under Test)

3.1.1 Input signals

All input signals are active high and are synchronized to the falling edge of the clock. The packet_valid signal has to be asserted on the same clock when the first byte of a packet (the header byte), is driven onto the data bus. Since the header byte contains the address, this tells the router to witch output channel the packet should be routed. Each subsequent byte of data should be driven on the data bus with each new falling clock edge. After the last payload byte has been driven, on the next falling clock edge, the packet parity byte should be driven on the next falling clock edge. The input data cannot change while suspend_data_in signal is active (indicating FIFO overflow). The err signal asserts when a packet with bad parity is detected.

3.1.2 Output signals

All output signals are active high and synchronized to the rising edge of the clock. Each output port is internally buffered by a FIFO of dept 16 and a width of 1 byte. The router asserts the vld_chan_x signal when valid data appears on the channelx output bus. The read_enb_x inout signal must then be asserted to the falling clock edge in which data is read from channelx bus. As long the read_enb_x signal remains active, the channelx bus drives a valid packet byte on each rising clock edge.


4

3.2 Data packet structure The data packet which will be passed through the router is structured as follows:

Figure 3.2 – Packet structure

2-bit addr field and 6-bit len field, byte 0. This byte is also called the header. N data bytes with N equalling the value of len field. 1 byte of even parity calculated over the header and data bytes. Packet can have a minimum of 2 bytes and maximum 32 bytes of data. In other words, N and len are both in the range of 2…32.

3.3 Design specification

Figure 3.3 – VHDL-design input protocol

Above is shown the design input protocol diagram. This means that we must follow this scheme in order to send data packets into the DUT. As we can see in the figure above, the packet_valid signal must go high on the falling clock edge simultaneously as the 8 first bytes (header) is being sent, then the data is sent in group of 8 bits on each clock-period, depending on the data length. Finally the packet_valid signal goes low and the parity byte is sent.


5

3.4 VHDL Design structure The router design is composed of the tree following VHDL-files.

� port_fsm.vhd � router_top.vhd � fifo.vhd

Those files together constitute the VHDL design, the router itself.

Figure 3.4 – The VHDL DUT (Device Under Test)

The table below shows all VHDL ports connected to the design:

Port name VHDL type In/out

clock in std_logic in

packet_valid in std_logic in

Data in std_logic_vector (7 downto 0) in

channel0 out std_logic_vector (7 downto 0) out



vld_chan_0 out std_logic out



read_enb_0 in std_logic in



suspend_data_in out std_logic out

err out std_logic) out


6

4 SystemC

4.1 Background and History SystemC has its roots in the idea of using C++ for modelling hardware and software components of a system. Version 2.0, introduced in July 2001, which changed SystemC from a cycle-based to event-based simulator and added user-defined interfaces, channels and ports as well as restructured the core language. SystemC 2.1 provided better support for transaction level design- and verification.

4.2 SystemC characteristics While C++ is certainly adequate for modelling the software components of a system, there are three major reasons why C++ is inadequate for modelling the hardware components. SystemC consists of a C++ class library and simulation kernel that addresses these inadequacies.

C++ SystemC

Notion of time No support A notion of time is introduced and implemented

Concurrency No support Processes are define which are executed in parallel within the simulator

Hardware data types No suitable support Hardware data types are introduced. These classes describe arbitrary precision, integers, fixed point and 4 valued logic.

SystemC "extends" the C++ language without changing the syntax by using classes. Modules are introduced as a means of encapsulating behaviour and describing hierarchy.

4.3 SystemC philosophy The language is very rich. While features can be intermixed, SystemC extensions to C++ are mostly aimed at different design domains; RTL designers can write VHDL-like code. And System designers (HW/SW designers) can write C++ code while taking advantage of some “bonus” feature like concurrency, powerful synchronization mechanisms and abstraction of actual hardware. Design refinement can be done while staying within the SystemC framework, without learning new languages.

4.4 SystemC library overview Below follows a short description of some classes and macros that were used to build up the testbench.


7

4.4.1 SC_MODULE

A module is a C++ class; it encapsulates a hardware or software description. SystemC defines that any module has to be derived from the existing sc_module. Modules are analogous to VHDL entity/architecture pairs, as they represent the basic building block of a hierarchical system. By definition, modules communicate with other modules through channels and via ports. Typically a module will contain numerous concurrent processes used to implement their required behaviour. An example of a module is as follows:

Objects of class SC_MODULE can only be constructed during elaboration. Every class derived (directly or indirectly) from class SC_MODULE shall have at least one constructor. Every such constructor shall have one and only one parameter of class SC_MODULE_name but may have further parameters of classes other than SC_MODULE_name. That parameter is not required to be the first parameter of the constructor. A string-valued argument shall be passed to the constructor of every module instance. It is good practice to make this string name the same as the C++ variable name through which the module is referenced, if such variable exists. Inter-module communication should typically be accomplished via interface method calls; that is, a module should communicate with its environment via its ports. Other communication mechanisms are allowed, for example for debugging or diagnostic purposes.

SC_MODULE(my_module)

{

sc_in<bool> A, B, F;

sc_in<bool> clk;

void my_function()

{

while(true)

{

cout << sc_time_stamp();

cout << A.read();

wait();

}

}

SC_CTOR(my_module)

{

SC_THREAD(my_function);

sensitive << clk.pos();

}

}

};


8

All modules need: Communication: Modules can interface to each other via ports, interfaces and

channels. Functionality: achieved by means of processes.

4.4.2 SC_CTOR

SC_CTOR is a macro declaring the class constructor. The constructor is the place for all the initializations:

� All the default values � Including connections � List of key functions: methods or threads.

Each class declared in C++ needs a constructor. SC_CTOR is a macro which provides a convenient way of declaring the constructor for SystemC modules. This macro is provided for convenience when declaring or defining a constructor of a module. The macro SC_CTOR shall only be used at a place where the rules of C++ permit a constructor to be declared, and can be used as the declarator of a constructor declaration or a constructor definition. The name of the module class being constructed shall be passed as the argument to the macro. The use of macro SC_CTOR is not obligatory. Using SC_CTOR, it is not possible to add user-defined arguments to the constructor. If an application needs to pass additional arguments, the constructor shall be provided explicitly. This is a useful coding idiom.

4.4.3 SC_THREAD

This sub clause shall apply to both static and dynamic process instances. A function associated with a thread process instance is called once and only once by the SystemC kernel. A thread may call the function wait. Such a call causes the calling process to suspend the execution. Function wait is a member function of class sc_module, a member function of class sc_prim_channel, and a non-member function. A thread process instance is said to be resumed when the kernel causes the process to continue execution starting with the statement immediately following the most recent call to function wait. When a thread process is resumed, the process executes until it reaches the next call to function wait. Then, the process is suspended once again. A thread process instance may have static sensitivity, or may call function wait to create dynamic sensitivity. A clocked thread process instance is statically sensitive only to a single clock.


9

4.4.4 sc_fifo

FIFO is a shortening for First In First Out. This expression describes the principle of a queue or first-come, first-served behaviour. What comes in first is handled first, what comes in next waits until the first is finished and so on. The expression FIFO can be used in different contexts. In this case we are using FIFO instead of signals because the data packets which are sent among the modules must stay longer than one clock cycle. When using FIFO, the packets are still in the FIFO queue until the module port has accepted the packet. This process can take several clock cycles, therefore are signals not suitable here. Class sc_fifo is a predefined primitive channel intended to model the behaviour of a FIFO, that is, a first-in first-out buffer. A FIFO is an object of class sc_fifo. Each FIFO has a number of slots for storing values. The number of slots is fixed when the object is constructed, 16 default. The class sc_fifo_in and sc_fifo_out are specialized port class for use when reading and writing from/to a FIFO. It provides functions to conveniently access certain member functions of the FIFO to which the port is bound. Class sc_fifo_in_if and sc_fifo_out_if is an interface proper, used by the predefined channel sc_fifo. Interface sc_fifo_in_if/sc_fifo_out_if gives read and write access to a FIFO channel, and is derived from two further interfaces proper, sc_fifo_nonblocking_in_if and sc_fifo_blocking_in_if.

4.4.5 sc_signal

A signal connects the port of one module to the port of another module. The signal transfers data from one port to another as if the ports were directly connected. When a port is read the value of the signal connected to the port is returned. When a port is written the new value will be written to the signal when the process performing the write operation has finished execution, or has been suspended. This is done so that all operations within the process will work with the same value of the signal. This is to prevent some processes seeing the old value while other processes see the new value during execution. All processes executing during a time step will see the old value of the signal. These signal semantics are the same as VHDL signal operation and Verilog deferred assignment behaviour. The sc_signal class is a predefined primitive channel intended to model the behaviour of a single piece of wire carrying a digital electronic signal.


10

The argument passed to template sc_signal shall be either a C++ type for which the predefined semantics for assignment and equality are adequate (for example, a fundamental type or a pointer), or a type T that obeys each of the following rules: a) The following equality operator shall be defined for the type T, and should return the value true if and only if the two values being compared are to be regarded as indistinguishable for the purposes of signal propagation (that is, an event occurs only if the values are different). The implementation shall use this operator within the implementation of the signal to determine whether an event has occurred.

b) The following stream operator shall be defined, and should copy the state of the object given as the second argument to the stream given as the first argument. The way in which the state information is formatted is undefined by this standard. The implementation shall use this operator in implementing the behaviour of the member functions print and dump.

c) If the default assignment semantics are inadequate (in the sense given in this sub clause), the following assignment operator should be defined for the type T. In either case (default assignment or explicit operator), the semantics of assignment should be sufficient to assign the state of an object of type T such that the value of the left operand is indistinguishable from the value of the right operand using the equality operator mentioned in this sub clause. The implementation shall use this assignment operator within the implementation of the signal when assigning or copying values of type T.

d) If any constructor for type T exists, a default constructor for type T shall be defined. e) If the class template is used to define a signal to which a port of type sc_in, sc_inout, or sc_out is bound, the following function shall be defined: void sc_trace( sc_trace_file*, const T&, const std::string& );

4.4.6 sc_main

In sc_main(), the top level of the design is created. The user then starts the simulation kernel. When sc_main() returns, the simulation is over. sc_main() has all the arguments of “main” passed to it. The argc variable contains the number of arguments, and argv[] contains the arguments themselves. The first argument, argv[0], is always the name of the program. sc_main is not a class, it is a function call. An application shall provide a function sc_main with the following prototype. The order and types of the arguments and the return type shall be as shown here:

int sc_main( int argc, char* argv[] );

bool T::operator== ( const T& );

std::ostream& operator<< ( std::ostream&, const T& );

const T& operator= ( const T& );


11

This function shall be called once from the kernel, and is the only entry point into the application. The arguments argc and argv[] are command-line arguments. An implementation shall pass the values of the C++ command-line arguments (as passed to function main) unaltered through to function sc_main. Elaboration consists of the execution of the sc_main function from the start of sc_main to the point immediately before the first call to the function sc_start. A return value of 0 from function sc_main shall indicate successful completion. An application may use other return values to indicate other termination conditions.

4.4.6 sc_clock

Class sc_clock is a predefined primitive channel derived from the class sc_signal and intended to model the behaviour of a digital clock signal. A clock is an object of the class sc_clock. The value and events associated with the clock are accessed via the interface sc_signal_in_if<bool>. A clock is characterized by the following properties: a) Period -The time interval between two consecutive transitions from value false to value true, which shall be equal to the time interval between two consecutive transitions from value true to value false. The period shall be greater than zero. The default period is 1 nanosecond. b) Duty cycle -The proportion of the period during which the clock has the value true. The duty cycle shall lay between the limits 0.0 and 1.0, exclusive. The default duty cycle is 0.5. c) Start time - The absolute time of the first transition of the value of the clock (false to true or true to false). The default start time is zero. d) First edge - If true, the clock is initialized to the value false, and changes from false to true at the start time. If false, the clock is initialized to the value true, and changes from true to false at the start time. The default value of posedge_first is true.

Figure 4.1 – sc_clock

A clock does not have a stop time, but will stop in any case when function sc_stop is called.


12

4.4.7 sc_port Ports of a module are the external interface that pass information to and from a module, and trigger actions within the module. A port can have three different modes of operation:

� Input � Output � InOut

An input port transfers data into a module. An output port transfers data out from a module, and an inout port transfers data both into and out of a module depending on module operation. Ports are always bound to a signal except for one special case, when a port is bound directly to another port. Ports are always bound to only one signal. That signal may be a complex signal such as a structure, but it is still treated as one signal. Signal binding occurs during module instantiation. When building a hierarchical design structure, modules are instantiated within other modules to form the hierarchy of the design. The special case binding mentioned earlier occurs when a top level module port is directly bound to a lower level module port during instantiation. See figure 4.2.

Figure 4.2 – Port to port connection


13

5 Testbench All verification is "proving" that the models you write reflect the specification of the item you wish to model. In SystemC, functional verification is done through simulation, applying stimulus to the Device Under Test (DUT) and verifying the response against an expected result. The DUT may be models at varying levels, from System Architectural Models (SAM) to Register Transfer Level models (RTL) to gate level models written in other languages such as Verilog or VHDL. The first step in the creation of a testbench is developing the testbench strategy. There are several considerations. The first is to determine if the approach will be for testing at system level or unit level. Unit level testing means that each unit, typically a module, has its own testbench. There are both advantages and disadvantages to this approach. The advantages are that this approach is familiar to the designer and that it is usually easier to get a testbench together quickly. These testbenches are usually not as sophisticated or as complex as system level testbenches. You can quickly make changes to focus on a particular problem. The disadvantages are that there are more testbenches written, one per design partition, resulting in duplication of effort as each testbench needs to represent the rest of the system in some manner. Often the coverage between units is uneven. Each unit may be tested well, but the system as a whole is not tested well. Since this is a fairly small and simple design, we decided to create a System Testbench to verify all the blocks together. In this chapter we will now describe how the SystemC Testbench was gradually built up. As shown in figure 5.1 the testbench contains of three main modules. The purpose of the first module, driver, is to generate randomized data, assign it to the packet fields and send the packet into the DUT. Receiver module will capture data packets from DUT and send them future to the scoreboard module. Scoreboard module will check that the packets sent into the DUT are correctly received in the receiver.


14

Figure 5.1 – Testbench structure

5.1 Modelling the data packet The packets witch will be sent through the modules were modelled as a C++ class as follows: As shown in the code above, there are four fields, addr, parity, length and data. (This is described in chapter 3.2). Beyond those fields we have several method calls. The methods is not shown here, See appendix A for complete code description of packet_type.h. These methods are necessary and are used to implement the following operators as described in chapter 4.4.5:

� = � == � << � sc_trace()

class packet_type {

public:

packet_type () {}

virtual ~packet_type() {}

sc_uint<2> addr;

sc_uint<8> parity;

sc_uint<6> length;

sc_uint<8> data[32];

/* rest of class not shown */

};


15

Because we have defined our own data type packet_type, we must now implement the operators above in order to use the structure in the SystemC testbench. If not, we will not be able to use the user defined packet_type.

5.2 Driver The driver module has one input port and three output ports as shown in figure 5.2.

Figure 5.2 – Driver module

All SystemC modules have a clock input port. This port is bound with the common clock signal, my_clock which allows synchronization between modules within the testbench.

5.2.1 Driver module

Below is how we made the driver module was made using FIFO instead of signals for communication between the modules:

SC_MODULE(driver) {

public:

//module ports

sc_in_clk driver_clock;

sc_port<sc_fifo_out_if<packet_type> > data_out;

sc_port<sc_fifo_out_if<packet_type> >data_out_2;

sc_port<sc_fifo_out_if<sc_logic> >packet_valid_port;

//variables

packet_type s;

//constructor

SC_CTOR(driver){

SC_THREAD(drive_data);

sensitive << driver_clock.pos();

dont_initialize();

}

private:

//module methods

void drive_data();

};


16

In the first line, SC_MODULE(driver), declare a SystemC module and call it “driver”. sc_port<sc_fifo_out_if<packet_type> > data_out, declare a FIFO out port of type packet_type and call it data_out. Since the packet_type.h is included in the driver.h, we have access to the packet fields. Packet_type s is only a local variable of type packet_type. The generated packet is stored in variable s. The sc_in_clk port is a clock in port especially made for clock signals. This clock port was not available in earlier versions of SystemC. It is available within SystemC 2.0. In the constructor we are declaring a SC_THREAD “drive_data” and set its sensitivity to the driver_clock port. dont_initialize() means that the thread is made not runnable during the initialization phase. Finally we declare the drive_data thread process in the driver module. The purpose of this module is to generate random data, assign the generated data to the packet fields and assign the packet to the data_out and data_out_2 ports. The packet which is assigned to data_out will go through channel (FIFO) a into the VHDL design. See figure 5.1.

5.2.2 drive_data thread

Driver module contains a method, drive_data, it is here the data generation and assignments occur. This process triggers on positive clock edge (set in module constructor). Below is the implementation of the drive_data process:

Void driver::drive_data() means that the thread drive_data is member of driver module. scv_bag<packet_type> is used for random access, to create distributions of values and to collect objects of similar types. scv_smart_ptr<packet_type> p is a pointer of type packet_type and gives access to the SCV APIs (SystemC Verification Application Programming Interfaces). The SCV (SystemC Verification Library) is a set of C++ templates, functions and classes that gives us possibility to randomize and generate data packets very easy.

void driver::drive_data()

{

while(true)

{

//generate random data

scv_bag<packet_type> bag("myBagOfPackets");

scv_smart_ptr<packet_type> p;

p->next();

s = *p;

packet_valid_port->write(sc_logic_0);

wait();


data_out->write(s);


wait();

data_out_2->write(s);

wait();

}

};


17

Complete SystemC description of the driver module is shown in appendix B.

5.3 Receiver

Figure 5.3 – Receiver module

This module accepts packets from the DUT. When the receiver receives a packet, it sends a copy of the received packet to the scoreboard.

5.3.1 Receiver module

This module is very similar to driver module. In all SystemC modules usually you have in and out ports, some variables, constructor and one or several processes of various type. The implementation of the receiver module is shown below:

SC_MODULE(receiver) {

public:

//module ports

sc_in_clk receiver_clock;

sc_port<sc_fifo_in_if<packet_type> >packet_in;

sc_port<sc_fifo_out_if<packet_type> >packet_to_scoreboard;

//local variables

packet_type received_packet;

// constructor

SC_CTOR(receiver) {

SC_THREAD(receive_data);

sensitive << receiver_clock.pos();

dont_initialize();

}

private:

//module methods

void receive_data();

};


18

5.3.2 receive_data thread

This thread takes packets on the packet_in port and put it into a local variable called received_packet. received_packet is then sent to the scoreboard via the packet_to_scoreboard port. We choose to use SC_THREAD in our processes because of several reasons: SC_THREAD adds the ability to suspended to SC_METHOD processes by means of wait() calls. SC_THREAD still has a sensitivity list. Wait() returns when a change is detected on a port in the sensitivity list. SC_THREAD remembers its internal state among invocations. The execution resumes from where it was left. SC_THREAD is very useful for clocked systems and for multi-cycle behaviour. One disadvantage is that SC_THREAD imposes a heavier load onto the SystemC scheduler due to context switches and state tracking. This may results in slower simulations. Since this testbench is quite small, we do not have to care about this. See appendix C for complete code on receiver module.

void receiver::receive_data()

{

while(true)

{

received_packet = packet_in->read();

cout << "Received packet from DUT !" << endl;

packet_to_scoreboard->write(received_packet);

cout << "The packet is now sent from RECEIVER to SCOREBOARD" << endl;

wait();

}

};


19

5.4 Scoreboard The purpose of this module is to control the packet flow between modules during simulation. The scoreboard is often called for reference model or golden model. One of the basic concerns when checking data is to verify that the output data item collected from the DUT matches the corresponding data item injected into the DUT. This is what the scoreboard actually does. With scoreboard checking each injected data item is stored into a local variable. When receiving a data item from the DUT it looks for a match in the scoreboard for the received data item. If a match is not found, then the scoreboard will report an error.

Figure 5.4 – Scoreboard module

Code view of the scoreboard module. Also this module is very similar to the modules described above. One different here is that we have 2 threads, one for checking the packets and one for comparing the data.

SC_MODULE(scoreboard) {

public:

//module ports

sc_in_clk score_board_clock;

sc_port<sc_fifo_in_if<packet_type> >packet_from_driver;

sc_port<sc_fifo_in_if<packet_type> >packet_from_receiver;

//variables

packet_type packet_sent;

packet_type packet_received;

//constructor

SC_CTOR(scoreboard){

SC_THREAD(check_data);

sensitive << score_board_clock.pos();

SC_THREAD(compare_packets);

sensitive << score_board_clock.pos();

dont_initialize();

}

private:

//module methods

void check_data();

void compare_packets();

};


20

Above is shown the implementations file containing the check_data and compare_data threads. See appendix D for detailed code description on the scoreboard module.

void scoreboard::check_data()

{

while(true)

{

packet_sent = packet_from_driver->read();

cout << "Packet from driver_module received... " << endl;

packet_received = packet_from_receiver->read();

cout << "Packet from receiver_module received..." << endl;

wait();

}

};

void scoreboard::compare_packets()

{

while(true)

{

if (packet_sent == packet_received)

{

cout << "Packet received match - OK " << endl;

}

else

{

cout << "******** ERROR ********" << endl;

cout << "ERROR - Packet received does NOT match packet sent! " << endl;

}

wait();

}

};


21

5.5 sc_main The sc_main routine is the top-level routine that ties all the modules together and provides the clock generation and tracing capabilities. The sc_main routine is shown below:

To follow the “good coding style” idiom, we chose to split the top module into 2 files, test_router.cpp and test_router.h. The test_router.cpp contains the sc_main in which we create the Top instance and set simulation time to 100 ns. test_router.h contains the Top instance and all the channel/port connections. See appendix E for complete code description of the test_router.cpp.

int sc_main(int, char **)

{

Top top("top");

sc_start(100);

return 0;

};


22

5.6 Top module This module is the “top” module where all the modules described earlier in this chapter are instantiated and where we map all the ports to channels.

SC_MODULE(Top)

{

//top module channels/signals

sc_clock my_clock;

sc_fifo<packet_type> a;

sc_fifo<sc_logic> b;

sc_fifo<packet_type> c;

sc_fifo<packet_type> d;

sc_fifo<packet_type> e;

//module instances

driver *driver_INST;

receiver *receiver_INST;

fake_dut * fake_dut_INST;

scoreboard *scoreboard_INST;

//constructor

SC_CTOR(Top)

: my_clock("my_clock"),

a("a"), b("b"), c("c"), d("d"), e("e")

{

//create instances

driver_INST = new driver("driver");

receiver_INST = new receiver("receiver");

fake_dut_INST = new fake_dut("fake_dut");

scoreboard_INST = new scoreboard("scoreboard");

//instance connections

driver_INST->driver_clock(my_clock);

driver_INST->data_out(a);

driver_INST->packet_valid_port(b);

driver_INST->data_out_2(d);

receiver_INST->receiver_clock(my_clock);

receiver_INST->packet_in(c);

receiver_INST->packet_to_scoreboard(e);

fake_dut_INST->fake_dut_clock(my_clock);

fake_dut_INST->data(a);

fake_dut_INST->packet_valid(b);

fake_dut_INST->data_out(c);

scoreboard_INST->score_board_clock(my_clock);

scoreboard_INST->packet_from_driver(d);

scoreboard_INST->packet_from_receiver(e);

}

};


23

Notice that the sc_main file, test_router.h includes all of the other modules in the design. We instantiate each of the lower level modules and connect their ports with signals to create the design in sc_main. To instantiate a lower level module, the interface of the module must be visible. Including the .h file from the instantiated module provides the necessary visibility. See appendix E for complete code description.

5.6.1 Signals

First, the local channels are declared to connect the module ports together. Four channels of type FIFO are needed to cross connect the driver, receiver, and the scoreboard module. There is one clock declaration, my_clock. my_clock is the common clock signal used to synchronize all the modules together. First, we declare four FIFOs of packet_type and one of sc_logic type. The, a, c, d and e FIFOs are used to transport data packets between the modules. FIFO b is used to set the packet_valid bit.

5.6.2 Module Instantiation

After the declaration statements, the modules in the design are instantiated. The driver, fake_dut, receiver and scoreboard are instantiated and connected together with the locally declared signals. This completes the implementation of the design.

5.6.3 port Connections

In our testbench we used name connection. A named connection connects a port name to a signal name. For instance:

driver_INST->data_out(a);

This means that we connect the data_out port from the driver instance and connect it to channel a. See appendix E for complete code description of the test_router.h.


24

5.7 Testbench summary

Figure 5.5 – Testbench overview

Now, we have created the driver, receiver and the scoreboard modules, instantiated them into the Top module and connected the module ports to respective channel as shown in figure 5.5 above. Our clock signal is also connected to all modules inclusive the “empty” DUT itself in order to achieve synchronization between the modules. In chapter 5.7.1 we have described how to do if using the VHDL-design instead of “empty” DUT. 5.7.1 Foreign module In order for the SystemC testbenches to interface properly with any VHDL designs, first we need a VHDL simulator (in this case we are going to explain how to do this using Modelsim 6.1). Then we must create a stub module, a foreign module declaration so that the SystemC testbench can interface with the VHDL design. To do that, we will use the scgenmod command in Modelsim to create the foreign module declaration. Finally, we will link the created C object files by using sccom –link in Modelsim command prompt.


25

Figure 5.6 – Foreign stub module

When we type the scgenmod command at Modelsim command prompt, a header file router.h is automatically generated. This file’s purpose is to let us drive and receive data into and from the DUT. See appendix F for complete content of router.h. Thanks to this auto generated file we can now interface properly with the DUT. All signal and port names in router.h is the same as in the VHDL design, also the file has same name as the top level entity, “router”, therefore router.h. As we can see in the figure 5.6 above, the VHDL design is wrapped by the SystemC foreign stub module and the stub module is wrapped by the SystemC Testbench. This is the methodology when running this kind of verification, Co-simulation i.e. when running SystemC testbenches together with VHDL-designs.


26

6 Using Vista Vista is a software environment for develop, compilation, simulation, debug and analysis of SystemC programs. It relies on GNU products for the editing and compilation parts, on OSCI (Open SystemC Initiative) products for the simulation kernel and extension libraries parts. Vista is designed for an easy and intuitive use that does not require any ramp up time. Vista’s data Introspection provides both hardware (module hierarchy) and software (class) views of the design, enabling designers to better understand and debug their SystemC designs. Vista’s advanced coding facilities, browsers, and verification capabilities natively support system-level and transaction-level modelling. As a stand-alone tool, Vista targets text-based design in SystemC.

Figure 6.1 – Vista IDE architecture

SystemC Source Code Xemacs

Project Browser

Compile gcc

Simulation OCSI, gdb

Design Browser

Code Browser

Waveform

TLM Viewer


27

6.1 Creating the project

Figure 6.2 – Creating project in Vista

It was very easy to create the project in Vista. Above is shown the project settings window. From this window all necessary project settings are made. We do not have to do any changes to the Makefile. All compiler settings and Makefiles are automatically created and edited by Vista. Vista project folders are not real but rather virtual folders. This means that all project files will retain their original location in the file system, while Vista project folders will simply reference them. See figure 6.3. For this reason, an operation like cutting and pasting files between folders is in fact simply changing the reference to the file.

Figure 6.3 – Vista project folders


28

6.2 Compiling the project

Figure 6.4 – Compiling implementations files

Once the SystemC files are written, we can simply right-click on the implementations-file, (.cpp) and choose “compile”. All header-files (.h) witch are included in the implementation-file will also be compiled. It is also possible to build the entire design, thereby generating an executable. The file test_router.cpp is our Top module in where we instantiate all the other modules. However, when we compile this “top” file, Vista automatically sense that this file contains the sc_main function call and therefore create automatically the design hierarchy. See figure 6.5 below.

Figure 6.5 – Compiling the top module


29

When the ”Designs” folder is created, we can simply browse into the hierarchy and view all modules which where instantiated in the top module.

6.3 Running the simulation

Figure 6.6 – Starting the simulations

To start simulating the design, click once on the test_router.cpp to mark it. Otherwise Vista doesn’t know where the sc_main function is. When the mark is set, go to the main menu and click on simulation and simulate. The simulation windows will then pop up as shown is figure 6.6. In this window we can set which top module we want to simulate (it is also possible to have several top modules in same project). We can also choose to stop the simulation before or after the elaboration. Once the project is built, elaborating it will allow us to:

� Simulate and debug � View the hierarchical structure

The OSCI kernel used in Vista is modified so that, following elaboration, the structure of the design is observable.


30

6.4 Examine the simulation

Figure 6.7 – Exploring the data packet content

One nice feature in Vista is the waveform viewer that can acquire any design object of any kind. As shown in figure 6.7 above, we are looking at variable “s” which is a packet variable of type packet_type. We can also look at all packet fields and their value which was randomized in the driver module before sending it in to the DUT. All C++ variables that are visible in the Comprehensive Design Viewer can be acquired. They can become "watched" variables and/or become traced in the waveform viewer. Without user's instrumentation, automatic introspection recognizes: Structures and classes, recognizing inheritance and displaying parent’s fields. Enum, displaying the names of the list and not the integer values mapped by the compiler.

� Integers (SystemC with sc_int, sc_uint, etc. or C with short, int, long int, unsigned short, etc).

� Floating-point (double, float), displayed as "12.345" for instance. � Fixed-point (sc_fix, sc_fixed). � Bit and bit vectors (sc_bit, sc_bv, sc_logic, sc_lv), displayed as logic signals � Strings (char *), displayed with the chain of characters between double quotes.


31

7 Using AccurateC AccurateC is a static C++ code analysis for SystemC, consisting of a Rule Checker and a Rule Generator. AccurateC Rule Checker takes C++ source files as input and analyzes them using sets of rules specifically created to aid in the analysis of SystemC code. AccurateC Rule Generator gives us access to AccurateC API (Application Programming Interface functions to create User-Defined Rules. In addition to full C++/SystemC syntax and coding style checking, AccurateC understands the special requirements when coding for the latest synthesis tools, both at the RTL and Behavioural levels. All of this knowledge is contained in the Rulesets which the AccurateC Rule Checker can apply to user code.

3Figure 7.1 – AccurateC design flow

When working after the “old-fashion” C++ methodology, usually we need to go through many loops and iterations before we can create an executable file of the design as shown in figure 7.1 (design flow to the left). With AccurateC, we can be spared of the hard work. AccurateC will check out the C++/SystemC code in one time. This saves a lot of time when checking for syntax, semantics and netlist errors. See figure 7.1 (design flow to the right).


32

7.1 Invoking AccurateC Rule Checker To load the design into AccurateC, we must invoke the accheck executable from within the directory where all our project files are: % accheck *.cpp will run the AC-check on all .cpp files in the current directory. This causes AccurateC to analyze the design for syntax and netlist errors. Once analysis is complete the AC Design Analysis window opens. The header .h files are loaded automatically, since they are #included in the implementation .cpp files.

Figure 7.2 – AccurateC Rule checker GUI

The GUI (Graphical User Interface) consists of two main windows used for configuring, controlling and interactively analyzing a rule check. The windows are the Design Analysis window and the Code Consultant window. A language sensitive editor is also provided. Invoking AccurateC will display the Design Analysis window which consists of a menu bar, a button bar and the Design View region. As we can see in figure 7.2, the design contains both C++ syntax errors and netlist errors in several files. Note that these errors have not been recognized by the Vista SystemC compiler (Systemc-21v1-gcc-343). It is here we see these errors occur for the firs time.


33

So, on start-up, AccurateC highlights these files in the File List with a red icon. Problems are highlighted in both the Source Code and AC Report panes. The first problem line number is also highlighted in yellow in AC Report, to indicate a warning.

7.2 Code Consultant window If we want more information about a specific error, we can simply click on the red, yellow or green highlighted line numbers in the AC Report to get more information on this type of violation. Notice how the Code Consultant window opens and explains how to interpret the message. Typically it would be a good idea to go ahead and correct these problems before running any further checks. This window is used primarily for displaying additional information about a given message in the AC Report. By default this window is not displayed, but will pop up whenever we click on a message link.

Figure 7.3 – Rule Checker Code Consultant


34

8 Summary In this thesis we have taken the first step to create a SystemC testbench for an existing VHDL-design. We have also described how to do if running Co-simulation i.e. how to run the VHDL-design together with the SystemC testbench. Below follows a short description on what advantages Vista and AccurateC gave us compared to writing SystemC testbenches without these tools.

8.1 Vista

8.1.1 Easy project configuration and management

Thanks to a graphical wizard, specific variables can be defined, include directories, compiler and linker options can be specified. This can also be manually done by direct modifications of the project file in a text format. Vista also checks for simultaneous accesses on opened projects.

8.1.2 Makefiles

Makefiles are automatically generated and updated by Vista, taking care of dependencies between header and source files. It is possible to edit the makefiles manually, if needed.

8.1.3 Comprehensive design viewer

The structure of the SystemC design is displayed in a graphical tree. It represents all the SystemC objects and their members, following the SystemC hierarchical names. This comprehensive tree displays C++ variable names in case SystemC explicit constructors have not been used. It allows to quickly switching the editing area between the "definition" and the "instantiation" of a SystemC object. The C++ code structure is also visible in a joint graphical tree.

8.1.4 Data acquisition

All the C++ variables that are visible in the Comprehensive Design Viewer can be acquired. They can become "watched" variables and/or become traced in the waveform viewer, without user's instrumentation.


35

8.1.5 Waveform viewer

Values of C++ variables or SystemC channels are displayed on a horizontal time line:

� Zoom to level of delta cycles. � Supports all the C/C++/SystemC types listed in data acquisition.

8.1.7 SystemC specific debug support

� Instance specific breakpoints � Step to next delta-cycle � Step to next change of time � Step through code bypasses SystemC kernel � Run until... time � Breakpoints in constructors and template structures.

8.2 AccurateC

8.2.1 Rule checker

The AccurateC Rule checker found the “hidden” errors in a very short manner of time and divided the errors in three groups, errors, warnings and notes depending on the severity.

8.2.1 Code consultant

The Code consultant helped us to understand the errors, thanks to easy error description and the example provided with each error ID.


36

8.3 Future work This study is an initial attempt to look at how verification engineers can write design testbenches in SystemC. Due to the time limit of the project, several assumptions and simplifications in the testbench have been made. Next step in pursuing this work is suitably to: �� Run both SystemC and VHDL-simulators simultaneously to verify the VHDL-

design together with the SystemC testbench. What impact will this have on simulation performance?

�� Rewrite the testbench in a higher level of abstraction, taking advantages of the

SystemC TLM (Transaction Level Modelling) library. How can this improve the verification process? In what manner will the TLM-testbench be reusable?

�� Include a VHDL-simulator into Vista so that Co-simulations can be run directly in

Vista without using an external VHDL-simulator.


37

9 Conclusions In the beginning of this work we asked ourselves the following question: Why writing design-code several times in different languages? The problem is of course that of the manual, complex and time consuming process that exists today. As the complexity and the demands of the designs keeps increasing, the existing methodology is really not satisfying and prone to errors due to human interaction. Not to mention a very time consuming and hence costly process. So, during this thesis work we have found the following key points: 1) Automation As less code needs to be written manually by hand, also the risk of human mistakes decreases. By that, the engineers can spend more time in doing more effective verification tests and implement more complex functions into their design. One disadvantage when automating the process is that code is updated automatically without user’s attention. This can sometimes cause unexpected modification on the design. 2) Graphical view Since it is now easier to understand the entire design, engineers can spend their time more effectively. More and more blocks can be connected together, as a camera into a cell phone or a MP3-player into a portable USB-memory, making the IP (Intellectual Property) industry grow rapidly. On the basis of this the verification process becomes even simpler. 3) Higher abstraction level There is no need to take care of low level-signals anymore; instead, you can now focus on event based cases without taking care of the details. Design Re-Use, will become standard in that a testbench which earlier was used to verify one design, can now be used to verify any number of related (family) designs. However, depending on which testbench methodology is being used, the higher the demands on the equipment (computer power). Due to demands on accuracy and sometimes technical limitations, you need to write some partitions in a lower abstraction level too. Hence, this leads to a substantial change in both the methodology and the practicality of work for digital ASIC and system designers. Less experience is needed due to the more intuitive work flow, perhaps more suitable for younger designers learning new tools than for older engineers. 4) Computer based simulation and emulation It’s now possible to both simulate and emulate a specific design in software without having an expensive pre-silicon prototype. You can use computer based simulators and emulators to run driver and firmware tests on the design long before having the


38

actual hardware. This cuts the cost dramatically and gives the software engineers the possibility to start writing firmware and driver-code much earlier than before. It is plausible that future development work will be using an “all-cover” language, such as SystemC, and various tools through the design and verification process. Hardware emulation is eliminated making the entire process much shorter than with current methodologies. To simply answer the question put above: No, it’s not necessary to write design-code several times over in different languages. A language such as SystemC can be used through the entire design and verification flow and provides key benefits to the user. Automation reduces time; time increases the value and the quality of the design.

1

References 1. OSCI SystemC 2.1 Language Reference Manual Stuart Swan, Open SystemC Initiative, Copyright © 2005. 2. Modelling in SystemC Training Class Vincent Viteau, Summit Design, April 2004. 3. AccurateC Users Guide 2.4.3 Actis Design, LLC, 2005. 4. Vista Online Documentation Provided with the Vista installation 1.1.3, 2006. 5. SystemC Verification Randomization Stuart Swan, Cadence Design Systems, Inc, 2003. 6. SystemC Tutorial Federico Angolini, University of Bologna, Italy, 2005. 7. SystemC Verification Standard Specification SCV Working Group, 2003. 8. SystemC Users Guide 2.0.1 SystemC working group, by all contributors, 2002. 9. SystemC Golden Reference Guide Doulos Ltd, 2005. 10. System Design with SystemC Thorsten Grötker, Synopsys Inc, Grant Martin, Cadence Design Systems Inc, 2004. 11. SystemC Community www.systemc.org (2006-04-19). 12. Esperan www.esperan.com (2006-04-19). 13. Cadence Testbuilder www.testbuilder.net (2006-04-19). 14. Actis Design www.actisdesign.com (2006-04-19). 15. Summit Design www.sd.com (2006-04-19).

2

Appendix A //packet_type.h #include <scv.h> #include <systemc.h> #include <iostream> #include <iomanip> using std::setw; #ifndef packet_type_H #define packet_type_H // Define a packet with a variable size data // nbcode "fields" start class packet_type { public: packet_type () {} virtual ~packet_type() {} // Packet's data sc_uint<2> addr; sc_uint<8> parity; sc_uint<6> length; // Number of items in the data sc_uint<8> data[32]; // nbcode "assign" start // Define an equal operator packet_type& operator=(const packet_type& rhs) { addr=rhs.addr; parity=rhs.parity; length=rhs.length; for(unsigned int i=0; (i<length) && (i<32); i++) data[i]=rhs.data[i]; return *this; } // nbcode "compare" start // Define a comparison operator friend bool operator==(const packet_type& a, const packet_type& b) { if (a.addr != b.addr) {return false;} if (a.parity != b.parity) {return false;} if (a.length != b.length) {return false;} for(unsigned int i=0; (i<a.length) && (i<32); i++) if (a.data[i] != b.data[i]) {return false;} return true; } // Define a not-equal operator (some compilers do not // automatically create this from operator=)

3

friend bool operator!=(const packet_type& a, const packet_type& b) { if (a.addr != b.addr) {return true;} if (a.parity != b.parity) {return true;} if (a.length != b.length) {return true;} for(unsigned int i=0; (i<a.length) && (i<32); i++) if (a.data[i] != b.data[i]) {return true;} return false; } // nbcode "out" start // Define ostream method to print data friend ostream& operator<< (ostream& os, const packet_type& p) { os << " addr: " << setw(5) << p.addr << " parity: " << setw(5) << p.parity << " length: " << setw(4) << p.length << " data: " << setw(5) << p.data[0] << " .. " << setw(5) << p.data[p.length-1]; return os; } }; //nbcode "ext" start //Extensions to packet_type template<> class scv_extensions<packet_type> : public scv_extensions_base<packet_type> { public: scv_extensions< sc_uint<2> > addr; scv_extensions< sc_uint<8> > parity; scv_extensions< sc_uint<6> > length; scv_extensions< sc_uint<8>[32] > data; SCV_EXTENSIONS_CTOR(packet_type) { //must be in order SCV_FIELD(addr); SCV_FIELD(parity); SCV_FIELD(length); SCV_FIELD(data); } }; #endif

4

Appendix B //driver.h #ifndef DRIVERN #define DRIVERN #include "packet_type.h" #include <systemc.h> #include <scv.h> SC_MODULE(driver) { public: //module ports sc_in_clk driver_clock; sc_port<sc_fifo_out_if<packet_type> > data_out; sc_port<sc_fifo_out_if<packet_type> >data_out_2; sc_port<sc_fifo_out_if<sc_logic> >packet_valid_port; //variables packet_type s; // 'local' is a local variable of packet_type. // Allows access to the packet fields that cannot // be accessed directly from the port. //constructor SC_CTOR(driver){ SC_THREAD(drive_data); sensitive << driver_clock.pos(); dont_initialize(); } private: //module methods void drive_data(); }; #endif

5

//driver.cpp #include "driver.h" //drive_data method void driver::drive_data() { while(true) { //generate random data scv_bag<packet_type> bag("myBagOfPackets"); scv_smart_ptr<packet_type> p; p->next(); s = *p; cout << "1. Packet generated" << endl; //write the generated packet to module ports packet_valid_port->write(sc_logic_0); cout << "2. packet_valid is set to '0'" << endl; wait(); packet_valid_port->write(sc_logic_1); cout << "3. packet_valid is set to '1'" << endl; data_out->write(s); cout << "4. 's' where writed to data_out port" << endl; packet_valid_port->write(sc_logic_0); cout << "5. packet_valis is set to '0'" << endl; //data_out->write(s.parity); wait(); data_out_2->write(s); //packet to the scoreboard cout << "6. 's' where writed to data_out_2 port" << endl; wait(); } };

6

Appendix C //receiver.h #ifndef RECEIVERN #define RECEIVERN #include "packet_type.h" #include <systemc.h> SC_MODULE(receiver) { public: //module ports sc_in_clk receiver_clock; sc_port<sc_fifo_in_if<packet_type> >packet_in; sc_port<sc_fifo_out_if<packet_type> >packet_to_scoreboard; //local variables packet_type received_packet; // constructor SC_CTOR(receiver) { SC_THREAD(receive_data); sensitive << receiver_clock.pos(); dont_initialize(); } private: //module methods void receive_data(); }; #endif

7

// receiver.cpp #include "receiver.h" //receive_data method void receiver::receive_data() { while(true) { received_packet = packet_in->read(); cout << "Received packet from DUT !" << endl; packet_to_scoreboard->write(received_packet); cout << "The packet is now sent from RECEIVER to SCOREBOARD" << endl; wait(); } };

8

Appendix D //scoreboard.h #ifndef SCOREBOARDEN #define SCOREBOARDEN #include "packet_type.h" #include <systemc.h> SC_MODULE(scoreboard) { public: //module ports sc_in_clk score_board_clock; sc_port<sc_fifo_in_if<packet_type> >packet_from_driver; sc_port<sc_fifo_in_if<packet_type> >packet_from_receiver; //variables packet_type packet_sent; packet_type packet_received; //constructor SC_CTOR(scoreboard){ SC_THREAD(check_data); sensitive << score_board_clock.pos(); SC_THREAD(compare_packets); sensitive << score_board_clock.pos(); dont_initialize(); } private: //module methods void check_data(); void compare_packets(); }; #endif

9

// scoreboard.cpp #include "scoreboard.h" //check_data method void scoreboard::check_data() { while(true) { //packet_sent = packet_from_driver->read(); cout << "Packet from driver_module received... " << endl; //packet_received = packet_from_receiver->read(); cout << "Packet from receiver_module received..." << endl; wait(); } }; //compare_data method void scoreboard::compare_packets() { while(true) { // if (packet_sent == packet_received) // { // cout << "Packet received match - OK " << endl; // } // else // { // cout << "********************* ERROR ***********************" << endl; // cout << "ERROR - Packet received does NOT match packet sent! " << endl; // } wait(); } };

10

Appendix E //test_router.h #ifndef test_router_h #define test_router_h #include <systemc.h> #include "driver.h" #include "receiver.h" #include "fake_dut.h" #include "scoreboard.h" #include "packet_type.h" #include <time.h> #include <stdio.h> SC_MODULE(Top) { //top module channels/signals sc_clock my_clock; sc_fifo<packet_type> a; sc_fifo<sc_logic> b; sc_fifo<packet_type> c; sc_fifo<packet_type> d; sc_fifo<packet_type> e; //module instances driver *driver_INST; receiver *receiver_INST; fake_dut * fake_dut_INST; scoreboard *scoreboard_INST; //constructor SC_CTOR(Top) : my_clock("my_clock"), a("a"), b("b"), c("c"), d("d"), e("e") { //create instances driver_INST = new driver("driver"); receiver_INST = new receiver("receiver"); fake_dut_INST = new fake_dut("fake_dut"); scoreboard_INST = new scoreboard("scoreboard");

11

//instance connections driver_INST->driver_clock(my_clock); driver_INST->data_out(a); driver_INST->packet_valid_port(b); driver_INST->data_out_2(d); receiver_INST->receiver_clock(my_clock); receiver_INST->packet_in(c); receiver_INST->packet_to_scoreboard(e); fake_dut_INST->fake_dut_clock(my_clock); fake_dut_INST->data(a); fake_dut_INST->packet_valid(b); fake_dut_INST->data_out(c); scoreboard_INST->score_board_clock(my_clock); scoreboard_INST->packet_from_driver(d); scoreboard_INST->packet_from_receiver(e); } //destructor // ~Top() // { // if (driver_INST) {delete driver_INST; driver_INST = 0;} // if (receiver_INST) {delete receiver_INST; receiver_INST = 0;} // if (fake_dut_INST) {delete fake_dut_INST; fake_dut_INST = 0;} // if (scoreboard_INST) {delete scoreboard_INST; scoreboard_INST = 0;} // } }; #endif

12

// test_router.cpp #include "test_router.h" int sc_main(int, char **) { Top top("top"); sc_start(100); return 0; };

13

Appendix F //router.h #ifndef ROUTERN #define ROUTERN #include <systemc.h> class router : public sc_foreign_module { public: sc_in<sc_logic> clock; sc_in<sc_logic> packet_valid; sc_in<sc_lv<8> > data; sc_out<sc_lv<8> > channel0; sc_out<sc_lv<8> > channel1; sc_out<sc_lv<8> > channel2; sc_out<sc_logic> vld_chan_0; sc_out<sc_logic> vld_chan_1; sc_out<sc_logic> vld_chan_2; sc_in<sc_logic> read_enb_0; sc_in<sc_logic> read_enb_1; sc_in<sc_logic> read_enb_2; sc_out<sc_logic> suspend_data_in; sc_out<sc_logic> err; router(sc_module_name nm, const char* hdl_name) : sc_foreign_module(nm, hdl_name), clock("clock"), packet_valid("packet_valid"), data("data"), channel0("channel0"), channel1("channel1"), channel2("channel2"), vld_chan_0("vld_chan_0"), vld_chan_1("vld_chan_1"), vld_chan_2("vld_chan_2"), read_enb_0("read_enb_0"), read_enb_1("read_enb_1"), read_enb_2("read_enb_2"), suspend_data_in("suspend_data_in"), err("err") {} ~router() {} }; #endif

14

Appendix G -- fifo.vhd library ieee; use std.standard.all; use ieee.std_logic_1164.all; entity fifo is port (clock: in std_logic; write_enb: in std_logic; read_enb: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0) := "00000000"; empty: inout std_logic := '1'; full: inout std_logic := '0'); end fifo; architecture behave of fifo is type mem_type is array(0 to 15) of std_logic_vector (7 downto 0); signal write_ptr, read_ptr: integer := 0; begin fifo_core: process( clock ) variable ram: mem_type; variable w_ptr, r_ptr: integer := 0; begin if (clock'event and clock = '1') then if ((write_enb = '1') and (full = '0')) then ram(w_ptr) := data_in; empty <= '0'; w_ptr:= (w_ptr + 1) mod (16); if ( r_ptr = w_ptr ) then full <= '1'; end if; end if; if ((read_enb = '1') and (empty = '0')) then data_out <= ram(r_ptr); full <= '0'; r_ptr := (r_ptr + 1) mod (16); if ( r_ptr = w_ptr ) then empty <= '1'; end if; end if; end if; write_ptr <= w_ptr; read_ptr <= r_ptr;

15

end process fifo_core; -- need initialization end behave;

16

Appendix H -- port_fsm.vhd library ieee; use std.standard.all; use ieee.std_logic_1164.all; entity port_fsm is port (clock: in std_logic; suspend_data_in: out std_logic:='0'; err: out std_logic:='0'; write_enb: out std_logic_vector (2 downto 0):= "000"; fifo_empty: in std_logic; hold: in std_logic; packet_valid: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0) := "00000000"; addr: out std_logic_vector (1 downto 0) := "00"); end port_fsm; architecture behave of port_fsm is type state_type is (ADDR_WAIT,DATA_LOAD,PARITY_LOAD,HOLD_STATE); signal write_enb_r: std_logic_vector (2 downto 0):= "000"; signal fsm_write_enb: std_logic:='0'; signal state_r, state: state_type; signal parity: std_logic_vector (7 downto 0):= "00000000"; signal parity_delayed: std_logic_vector (7 downto 0):= "00000000"; signal sus_data_in: std_logic:='0'; begin suspend_data_in <= sus_data_in; addr_mux: process (packet_valid) begin if (packet_valid = '1') then case data_in(1 downto 0) is when "00" => -- Packet addressed to port 0 write_enb_r(0) <= '1'; write_enb_r(1) <= '0'; write_enb_r(2) <= '0'; when "01" => -- Packet addressed to port 1 write_enb_r(0) <= '0'; write_enb_r(1) <= '1'; write_enb_r(2) <= '0'; when "10" => -- Packet addressed to port 2

17

write_enb_r(0) <= '0'; write_enb_r(1) <= '0'; write_enb_r(2) <= '1'; when others => write_enb_r <= ("000"); end case; end if; end process addr_mux; fsm_state: process (clock) begin if (clock'event and clock = '1') then state_r <= state; end if; end process fsm_state; fsm_core: process (state_r, packet_valid, fifo_empty, hold, data_in) begin state <= state_r; --Default state assignment case state_r is when ADDR_WAIT => --transition-- if ((packet_valid = '1') and ("00" <= data_in(1 downto 0)) and (data_in(1 downto 0) <= "10")) then if (fifo_empty = '1') then state <= DATA_LOAD; end if; end if; --combinational-- sus_data_in <= not fifo_empty; if ((packet_valid = '1') and ("00" <= data_in(1 downto 0)) and (data_in(1 downto 0) <= "10") and (fifo_empty='1')) then addr <= data_in(1 downto 0); data_out <= data_in; fsm_write_enb <= '1'; else fsm_write_enb <= '0'; end if; when DATA_LOAD => --transition-- if ((packet_valid = '1') and (hold = '0')) then state <= DATA_LOAD;

18

elsif ((packet_valid = '0') and (hold = '0')) then state <= PARITY_LOAD; else state <= HOLD_STATE; end if; --combinational-- sus_data_in <= '0'; if ((packet_valid = '1') and (hold = '0')) then data_out <= data_in; fsm_write_enb <= '1'; elsif ((packet_valid = '0') and (hold = '0')) then data_out <= data_in; fsm_write_enb <= '1'; else fsm_write_enb <= '0'; end if; when PARITY_LOAD => --transition-- state <= ADDR_WAIT; --combinational-- data_out <= data_in; fsm_write_enb <= '0'; when HOLD_STATE => --transition-- if (hold = '1') then state <= HOLD_STATE; elsif (hold = '0' and packet_valid = '0') then state <= PARITY_LOAD; else state <= DATA_LOAD; end if; --combinational-- if (hold = '1') then sus_data_in <= '1'; fsm_write_enb <= '0'; else fsm_write_enb <= '1'; data_out <= data_in; end if; end case; end process fsm_core;

19

write_enb(0) <= write_enb_r(0) and fsm_write_enb; write_enb(1) <= write_enb_r(1) and fsm_write_enb; write_enb(2) <= write_enb_r(2) and fsm_write_enb; parity_calc: process(clock) begin if ((clock'event) and (clock='1')) then parity_delayed <= parity; err <= '0'; if ((packet_valid = '1') and (sus_data_in='0')) then parity <= parity xor data_in; elsif (packet_valid = '0') then if ((state_r = PARITY_LOAD) and (parity_delayed /= data_in)) then err <= '1'; else err <= '0'; end if; parity <= "00000000"; end if; end if; end process parity_calc; end behave;

20

Appendix I -- router.vhd library ieee; use std.standard.all; use ieee.std_logic_1164.all; entity fifo is port (clock: in std_logic; write_enb: in std_logic; read_enb: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0) := "00000000"; empty: inout std_logic := '1'; full: inout std_logic := '0'); end fifo; architecture behave of fifo is type mem_type is array(0 to 15) of std_logic_vector (7 downto 0); signal write_ptr, read_ptr: integer := 0; begin fifo_core: process( clock ) variable ram: mem_type; variable w_ptr, r_ptr: integer := 0; begin if (clock'event and clock = '1') then if ((write_enb = '1') and (full = '0')) then ram(w_ptr) := data_in; empty <= '0'; w_ptr:= (w_ptr + 1) mod (16); if ( r_ptr = w_ptr ) then full <= '1'; end if; end if; if ((read_enb = '1') and (empty = '0')) then data_out <= ram(r_ptr); full <= '0'; r_ptr := (r_ptr + 1) mod (16); if ( r_ptr = w_ptr ) then empty <= '1'; end if; end if; end if; write_ptr <= w_ptr; read_ptr <= r_ptr;

21

end process fifo_core; -- need initialization end behave; --*****************************************************************/ library ieee; use std.standard.all; use ieee.std_logic_1164.all; entity port_fsm is port (clock: in std_logic; suspend_data_in: out std_logic:='0'; err: out std_logic:='0'; write_enb: out std_logic_vector (2 downto 0):= "000"; fifo_empty: in std_logic; hold: in std_logic; packet_valid: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0) := "00000000"; addr: out std_logic_vector (1 downto 0) := "00"); end port_fsm; architecture behave of port_fsm is type state_type is (ADDR_WAIT,DATA_LOAD,PARITY_LOAD,HOLD_STATE); signal write_enb_r: std_logic_vector (2 downto 0):= "000"; signal fsm_write_enb: std_logic:='0'; signal state_r, state: state_type; signal parity: std_logic_vector (7 downto 0):= "00000000"; signal parity_delayed: std_logic_vector (7 downto 0):= "00000000"; signal sus_data_in: std_logic:='0'; begin suspend_data_in <= sus_data_in; addr_mux: process (packet_valid) begin if (packet_valid = '1') then case data_in(1 downto 0) is when "00" => -- Packet addressed to port 0 write_enb_r(0) <= '1'; write_enb_r(1) <= '0'; write_enb_r(2) <= '0'; when "01" => -- Packet addressed to port 1 write_enb_r(0) <= '0'; write_enb_r(1) <= '1';

22

write_enb_r(2) <= '0'; when "10" => -- Packet addressed to port 2 write_enb_r(0) <= '0'; write_enb_r(1) <= '0'; write_enb_r(2) <= '1'; when others => --BUG: A packet with address 3 shall be discarded. -- : (Not as in this case routed to port 1.) write_enb_r(0) <= '0'; write_enb_r(1) <= '1'; write_enb_r(2) <= '0'; end case; end if; end process addr_mux; fsm_state: process (clock) begin if (clock'event and clock = '1') then state_r <= state; end if; end process fsm_state; fsm_core: process (state_r, packet_valid, fifo_empty, hold, data_in) begin state <= state_r; --Default state assignment case state_r is when ADDR_WAIT => --transition-- if ((packet_valid = '1') and ("00" <= data_in(1 downto 0)) and (data_in(1 downto 0) <= "10")) then if (fifo_empty = '1') then state <= DATA_LOAD; end if; end if; --combinational-- sus_data_in <= not fifo_empty; if ((packet_valid = '1') and ("00" <= data_in(1 downto 0)) and (data_in(1 downto 0) <= "10") and (fifo_empty='1')) then addr <= data_in(1 downto 0); data_out <= data_in; fsm_write_enb <= '1'; else fsm_write_enb <= '0'; end if;

23

when DATA_LOAD => --transition-- if ((packet_valid = '1') and (hold = '0')) then state <= DATA_LOAD; elsif ((packet_valid = '0') and (hold = '0')) then state <= PARITY_LOAD; else state <= HOLD_STATE; end if; --combinational-- sus_data_in <= '0'; if ((packet_valid = '1') and (hold = '0')) then data_out <= data_in; fsm_write_enb <= '1'; elsif ((packet_valid = '0') and (hold = '0')) then data_out <= data_in; fsm_write_enb <= '1'; else fsm_write_enb <= '0'; end if; when PARITY_LOAD => --transition-- state <= ADDR_WAIT; --combinational-- data_out <= data_in; fsm_write_enb <= '0'; when HOLD_STATE => --transition-- if (hold = '1') then state <= HOLD_STATE; elsif (hold = '0' and packet_valid = '0') then state <= PARITY_LOAD; else state <= DATA_LOAD; end if; --combinational-- if (hold = '1') then sus_data_in <= '1'; fsm_write_enb <= '0'; else fsm_write_enb <= '1'; data_out <= data_in;

24

end if; end case; end process fsm_core; write_enb(0) <= write_enb_r(0) and fsm_write_enb; write_enb(1) <= write_enb_r(1) and fsm_write_enb; write_enb(2) <= write_enb_r(2) and fsm_write_enb; parity_calc: process(clock) begin if ((clock'event) and (clock='1')) then parity_delayed <= parity; err <= '0'; if ((packet_valid = '1') and (sus_data_in='0')) then parity <= parity xor data_in; elsif (packet_valid = '0') then if ((state_r = PARITY_LOAD) and (parity_delayed /= data_in)) then --BUG: err should be asserted when incorrect parity. err <= '0'; else err <= '0'; end if; parity <= "00000000"; end if; end if; end process parity_calc; end behave; --*****************************************************************/ library ieee; use std.standard.all; use ieee.std_logic_1164.all; entity router is port (clock: in std_logic; packet_valid: in std_logic; data: in std_logic_vector (7 downto 0); channel0, channel1, channel2: out std_logic_vector (7 downto 0); vld_chan_0, vld_chan_1, vld_chan_2: out std_logic; read_enb_0, read_enb_1, read_enb_2: in std_logic; suspend_data_in: out std_logic; err: out std_logic); end router;

25

architecture behave of router is component fifo port (clock: in std_logic; write_enb: in std_logic; read_enb: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0); empty, full: inout std_logic); end component; for all: fifo use entity work.fifo (behave); component port_fsm port (clock: in std_logic; suspend_data_in: out std_logic; err: out std_logic; write_enb: out std_logic_vector (2 downto 0); fifo_empty: in std_logic; hold: in std_logic; packet_valid: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0); addr: out std_logic_vector (1 downto 0) := "00"); end component; for all: port_fsm use entity work.port_fsm(behave); signal data_out_0, data_out_1, data_out_2: std_logic_vector (7 downto 0); signal write_enb_fsm: std_logic := '0' ; signal full_0, full_1, full_2: std_logic; signal empty_0, empty_1, empty_2: std_logic; signal fifo_empty: std_logic; signal fifo_empty0: std_logic; signal fifo_empty1: std_logic; signal fifo_empty2: std_logic; signal hold_0: std_logic; signal hold_1: std_logic; signal hold_2: std_logic; signal hold: std_logic; signal write_enb: std_logic_vector (2 downto 0) := "000"; signal write_enb_r: std_logic_vector (2 downto 0) := "000"; signal data_out_fsm: std_logic_vector (7 downto 0) := "00000000";

26

signal addr: std_logic_vector (1 downto 0) := "00"; begin --addr <= data (1 downto 0); channel0 <= data_out_0; --mak note assignment only for consistency with vlog env channel1 <= data_out_1; channel2 <= data_out_2; vld_chan_0 <= not empty_0; vld_chan_1 <= not empty_1; vld_chan_2 <= not empty_2; fifo_empty0 <= (empty_0 or ( addr(1) or addr(0))); --addr!=00 fifo_empty1 <= (empty_1 or ( addr(1) or not addr(0))); --addr!=01 fifo_empty2 <= (empty_2 or (not addr(1) or addr(0))); --addr!=10 fifo_empty <= fifo_empty0 and fifo_empty1 and fifo_empty2; hold_0 <= (full_0 and ( not addr(1) and not addr(0))); --addr=00 hold_1 <= (full_1 and ( not addr(1) and addr(0))); --addr=01 hold_2 <= (full_2 and ( addr(1) and not addr(0))); --addr=10 hold <= hold_0 or hold_1 or hold_2; queue_0: fifo port map (clock,write_enb(0),read_enb_0,data_out_fsm,data_out_0,empty_0,full_0); queue_1: fifo port map (clock,write_enb(1),read_enb_1,data_out_fsm,data_out_1,empty_1,full_1); queue_2: fifo port map (clock,write_enb(2),read_enb_2,data_out_fsm,data_out_2,empty_2,full_2); in_port: port_fsm port map (clock, suspend_data_in, err, write_enb, fifo_empty, hold, packet_valid, data, data_out_fsm, addr); end behave;

27

Appendix J -- router_top.vhd library ieee; use std.standard.all; use ieee.std_logic_1164.all; entity router is port (clock: in std_logic; packet_valid: in std_logic; data: in std_logic_vector (7 downto 0); channel0, channel1, channel2: out std_logic_vector (7 downto 0); vld_chan_0, vld_chan_1, vld_chan_2: out std_logic; read_enb_0, read_enb_1, read_enb_2: in std_logic; suspend_data_in: out std_logic; err: out std_logic); end router; architecture behave of router is component fifo port (clock: in std_logic; write_enb: in std_logic; read_enb: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0); empty, full: inout std_logic); end component; for all: fifo use entity work.fifo (behave); component port_fsm port (clock: in std_logic; suspend_data_in: out std_logic; err: out std_logic; write_enb: out std_logic_vector (2 downto 0); fifo_empty: in std_logic; hold: in std_logic; packet_valid: in std_logic; data_in: in std_logic_vector (7 downto 0); data_out: out std_logic_vector (7 downto 0); addr: out std_logic_vector (1 downto 0) := "00");

28

end component; for all: port_fsm use entity work.port_fsm(behave); signal data_out_0, data_out_1, data_out_2: std_logic_vector (7 downto 0); signal write_enb_fsm: std_logic := '0' ; signal full_0, full_1, full_2: std_logic; signal empty_0, empty_1, empty_2: std_logic; signal fifo_empty: std_logic; signal fifo_empty0: std_logic; signal fifo_empty1: std_logic; signal fifo_empty2: std_logic; signal hold_0: std_logic; signal hold_1: std_logic; signal hold_2: std_logic; signal hold: std_logic; signal write_enb: std_logic_vector (2 downto 0) := "000"; signal write_enb_r: std_logic_vector (2 downto 0) := "000"; signal data_out_fsm: std_logic_vector (7 downto 0) := "00000000"; signal addr: std_logic_vector (1 downto 0) := "00"; begin --addr <= data (1 downto 0); channel0 <= data_out_0; --mak note assignment only for consistency with vlog env channel1 <= data_out_1; channel2 <= data_out_2; vld_chan_0 <= not empty_0; vld_chan_1 <= not empty_1; vld_chan_2 <= not empty_2; fifo_empty0 <= (empty_0 or ( addr(1) or addr(0))); --addr!=00 fifo_empty1 <= (empty_1 or ( addr(1) or not addr(0))); --addr!=01 fifo_empty2 <= (empty_2 or (not addr(1) or addr(0))); --addr!=10 fifo_empty <= fifo_empty0 and fifo_empty1 and fifo_empty2; hold_0 <= (full_0 and ( not addr(1) and not addr(0))); --addr=00 hold_1 <= (full_1 and ( not addr(1) and addr(0))); --addr=01 hold_2 <= (full_2 and ( addr(1) and not addr(0))); --addr=10 hold <= hold_0 or hold_1 or hold_2; queue_0: fifo port map (clock,write_enb(0),read_enb_0,data_out_fsm,data_out_0,empty_0,full_0); queue_1: fifo port map

29

(clock,write_enb(1),read_enb_1,data_out_fsm,data_out_1,empty_1,full_1); queue_2: fifo port map (clock,write_enb(2),read_enb_2,data_out_fsm,data_out_2,empty_2,full_2); in_port: port_fsm port map (clock, suspend_data_in, err, write_enb, fifo_empty, hold, packet_valid, data, data_out_fsm, addr); end behave;

30

Appendix K -- fixture.vhd -- SIGNALS signal clock: std_logic := '0'; signal packet_valid: std_logic := '0'; signal data: std_logic_vector (7 downto 0) := "00000000"; signal channel0, channel1, channel2: std_logic_vector (7 downto 0); signal vld_chan_0, vld_chan_1, vld_chan_2: std_logic; signal read_enb_0, read_enb_1, read_enb_2: std_logic := '0'; signal suspend_data_in: std_logic; signal err: std_logic; -- COMPONENTS component router port (clock: in std_logic; packet_valid: in std_logic; data: in std_logic_vector (7 downto 0); channel0, channel1, channel2: out std_logic_vector (7 downto 0); vld_chan_0, vld_chan_1, vld_chan_2: out std_logic; read_enb_0, read_enb_1, read_enb_2: in std_logic; suspend_data_in: out std_logic; err: out std_logic); end component; -- Configuration Specifications for all: router use entity avm_dut.router (behave); -- INSTANCES clock <= not clock after 50 ns; router1: router port map (clock, packet_valid, data, channel0,channel1,channel2, vld_chan_0,vld_chan_1,vld_chan_2, read_enb_0,read_enb_1,read_enb_2, suspend_data_in,err);

Thesis Functional verification with SystemC Verification with SystemC Funktionell verifiering med...

Documents

Transcript of Thesis Functional verification with SystemC Verification with SystemC Funktionell verifiering med...