Module-level Verification For DRRA and DiMarch

(1)

Royal Institute of Technology

School Of Information and Communication Technology

Stockholm, Sweden

Module-level Verification For DRRA and DiMarch

G¨okmen Tuna Becerik February 26, 2013 TRITA-ICT-EX-2013:40

(2)

Acknowledgements

I’m extremely grateful to my family and all of my friends for their great support in my studies in Sweden, including preparation of my thesis. Thanks to Professor Ahmed Hemani for providing me with the opportunity to work in this project, in particular Ph.D. candidate Mohammad Badawi for his expert guidance and invaluable input. Thanks to Ph.D. candidate Nasim Farahni and Muhammad Adeel Tajammul for their help and contribution to my thesis.

(3)

ABSTRACT

This thesis presents a verification process for the electronic hardware design implemented using Very-high-speed integrated circuits Hardware Descrip- tion Languages (VHDL). In this study, Register Transfer Level(RTL) modules are verified. They belong to Dynamic Reconfigurable Resource Array (DRRA) project and Distributed Memory Architecture (DiMArch) project.

Firstly, detailed description and specification of each module provided from designer during implementation of the test. According to the specification, simulation based tests are used as white-box verifications of the modules.

Methodology and implementation details for verification of the system are briefly explained. The basic objective of this thesis is finding location of bugs inside the design which improves the implementation of DRRA and DiMArch projects. Results show that all bugs determined during verification have been reported and fixed, leading to a bug-free implementation.

(4)

List of Figures

3.1 DRRA Architecture with DiMarch . . . 13

3.2 DRRA Architecture Chart with Verified modules . . . 14

3.3 DiMarch Architecture Chart with Verified modules . . . 14

3.4 Block diagram of the RegFile.v . . . 15

3.5 Block diagram of the FIFO.v . . . 18

3.6 Processes of the FIFO.vhdl . . . 20

3.7 Processes of the FIFO.vhdl . . . 21

3.8 ConTile[1] . . . 22

3.9 iSwitch[1] . . . 25

3.10 iSwitch bus priority . . . 27

3.11 Source FSM[1] . . . 38

(7)

List of Tables

3.1 Port list of the RegFile.v . . . 16

3.2 Generic Port list of the RegFile.v . . . 17

3.3 Port list of the FIFO.v . . . 18

3.4 Generic Port list of the FIFO.v . . . 18

3.5 Internal signal list of the FIFO.v . . . 19

3.6 dSwitch I/0 Ports . . . 23

3.7 Constants and Records . . . 23

3.8 Input Output . . . 24

3.9 iSwitch I/O Ports . . . 26

3.10 iSwitch Generics . . . 27

3.11 Instruction Decoder I/O Ports . . . 28

3.12 Source Destination Cases Part 1 . . . 29

3.15 Partition Cases Part 1 . . . 32

3.16 Partition Cases Part 2 . . . 33

3.17 Instruction Cases Partition(S) Part 1 . . . 34

3.18 Instruction Cases Partition(S) Part 2 . . . 35

3.19 Instruction Cases Partition(D) Part 1 . . . 36

3.20 Instruction Cases Partition(D) Part 2 . . . 37

3.21 Source FSM Ports . . . 39

4.1 Random variable list of the RegFile.v . . . 40

4.2 Random variable list of the tb FIFO.v . . . 41

4.3 Random variable list of the tb crossbar.v . . . 42

4.4 Random variable list of the tb crossbar source decoder.v . . . 44

4.5 Random variable list of the tb contile sd.v . . . 46

4.6 Random variable list of the tb iswitch.v . . . 49

5.1 list of the Coverage bins . . . 50

5.2 Summary of Coverage Result . . . 50

(8)

LIST OF TABLES LIST OF TABLES

(9)

Chapter 1

Introduction

Since digital circuit is introduced into our daily life, our expectations from new technology have become higher. Consequently, the commercial value of new technologies, product capacities and complexities have been increased rapidly. Continuously increasing complexity of the electronic system, has led to the requirement for more advanced testing.

Today all hardware designs are produced with the help of strong computer tools. Most of these designs are implemented with hardware description languages at register transfer level. The design tools give necessary computation power for the transformation of RTL. Computer based tools have also enabled simulation before production. Therefore, it becomes possible to conduct through test and verify the functionality of the design before fabricated. Test functionalities of the hardware description languages have same importance as the design tools. Basic level testing languages are not enough for verifying the complex design of hightechs digital circuits.

Therefore, test opportunities have been developed in parallel with the design technologies; followed by development of verification concept. Most common method for verifying the hardware is simulation based verification.

Simulation-based techniques are not efficient when it comes to run-times since number of simulation cycles loosely correlate to quality of effort and hard-to-reach corner case bugs validate bug fix[2]. Assertion is organized coding statements same as if and else structure. Difference from if-else, assertions have special properties which gives informations like hitting count of assertions, timing of the error and etc.. In Classical simulation designer shows more effort for finding the actual location of the bugs and Its cause simulations re-run a lot which is not efficient for large scale designs. There- fore, simulation based verification is aided with assertions. Assertion Based Verification increases the control opportunities and provides the test with more formal, easy readable statement and organized structure. Therefore,

(10)

CHAPTER 1. INTRODUCTION

AVB increases the chance of inspection of the bugs.

Designer should take into consideration some design rules to able to im- prove the quality of the test applied to design. Clean design partitioning with simplified inter-block interface,well-documented specifications, use of static property-based checks during development as well as use of high-level design description aided by high-level synthesis are some of the techniques that are useful towards this mission[3].

There are various applications for testing the hdl based designs, Develop- ment of the testing methods adequacy is another critical issue. The ultimate question pertaining to verification is “When do we know we are done?” as opposed to “How do we know are done?”. As such, verification is a never ending process and by any measure it only proves presence of bugs can not prove absence of bugs in the design description[3].

In this thesis, specific modules within the DRRA[4] and DiMarch[1]

projects are verified. Both projects are research studies and implemented in KTH. DRRA project has several versions were implemented by different designers. Development of both projects is still continuing. Some of old modules used in previous designs are still used in the new version of the design. Therefore, the modules which are selected for test have been chosen according to possibility of bug suspicion or critical element of the system.

Please refer to Chapter 3 for detailed description of the projects and tested modules. Testing time and test quality are very important issues that are directly related to complexity of the modules tested. To be able to over- come this problem, verification of a complex module has been handled by verifying different hierarchical elements of the module. Bottom-up method is used for verification. It integrates blocks on the bottom and their parents in the first step, and then parent and so on, until the top block is involved[5].

AVB is very efficient testing methodology for these project, because most

(11)

Chapter 2

Background

In this thesis, specific modules in Dynamic Reconfigurable Resource Ar- ray (DRRA) and DiMarch are verified. DRRA and DiMarch have been implemented by ICT School of Royal Institute of Technology in Sweden.

Therefore, I had the chance for close contact with the designer while prepar- ing my thesis. Methodology and tools used in the verification are explained in this chapter.

To be able to understand the verification concept, some Formal defini- tions are listed:

• Validation: The process to determine that a specification meets its functional and market requirements[6].

• Verification: The process to determine that an implementation meets its specification[6].

• Formal verification: A mathematical comparison of an implementation against a specification or requirement to determine if the implementation can violate its specification or requirement[6].

2.1 Assertion based Verification

Assertion-based verification (ABV) is a methodology in which designers use assertions to capture specific design intent and, either through simulation, formal verification, or emulation of these assertions, verify that the design correctly implements that intent[7]. Therefore, Assertion based verification decreases the complexity of the simulation. and increases the control power of the test engineer.

ABV is a form of whitebox testing. That is, properties–asserted behaviours–

(12)

2.2. SYSTEMVERILOG CHAPTER 2. BACKGROUND

This feature lets you identify errors sooner and closer to the source, and also lets you specify functional coverage points deep within the design[8].The following are the primary technologies that has been used for preparation of the assertion based verification:

• Simulation–Dynamic checking of monitors in simulation[8].

• Formal Analysis–Static property checking tools try to prove that a property that is asserted will hold true for all input conditions that do not violate an assumed behaviour[8].

• Acceleration-based assertions (ABA)–Another form of dynamic ABV that uses a simulation accelerator[8].

• Some verification goals are well-suited for ABV technologies, and other goals might be handled better by other tools. The key is to use ABV where you get the best return on investment[8].

2.2 SystemVerilog

In the semiconductor and electronic design industry, SystemVerilog is a combined Hardware Description Language and Hardware Verification Lan- guage based on extensions to Verilog[9].One of its significant extensions is the support for assertions.

SystemVerilog is the tool combination of RTL based hardware description language Verilog and object oriented programming techniques used for verification purpose. Therefore, SystemVerilog has advantage against the VHDL and Verilog language in terms of verification.

In this thesis all the test-benches are implemented in SystemVerilog language. However, all the tested modules in DRRA and DiMarch projects are implemented in VHDL language. Therefore, to be able to make appropriate

(13)

2.3. TOOLS CHAPTER 2. BACKGROUND

2.3.2 Nclaunch

NCLaunch provides a graphical user interface to configure and launch the following tools to simulate and debug your Verilog or VHDL design[10].

The tools contain inside nclaunch;

• NC-Verilog compiler: Used for compiling SystemVerilog test-benches.

• Nc-VHDL compiler: Used for compiling VHDL modules and adapter files.

• Nc-Elaborator: Used for elaboration of test module for the simulation.

• Nc-SimVision: Tool used for simulation of the test-benches.

2.3.3 ICC and Coverage

Coverage is a measure of progress of the verification process. Includes several coverage metrics, such as code coverage, functional coverage and FSM coverage[6].

Cadence’s Incisive Comprehensive Coverage (ICC) solution has well- defined coverage metrics to perform a thorough analysis of verification com- pleteness. Coverage metrics can be classified as code coverage and functional coverage[11].

Code coverage is a method of assessing how well the simulation has tested the intended behaviour and to what extent they execute the design.

Includes several metrics, such as line coverage, path coverage, toggle coverage, expression coverage and assertion coverage[6].

Functional coverage focuses on functional aspects of a design and provides a very good insight on how the verification goals set by a test plan are being met[11].

Cross coverage is a combination of two or more coverage metrics to measure their relative occurrences. Cannot be used to combine heterogeneous coverage measurements, such as code coverage and functional coverage[6].

Random constraint is a modification of a verification environment, through additional constraints, to increase the likelihood that specific stimulus will be generated[6].

ICC tool of Cadence is program which organize and present coverage data produced by simulator. Coverage types and explanations:

(14)

2.3. TOOLS CHAPTER 2. BACKGROUND

• Assertion coverage — A measure of how thoroughly an asserted property has been exercised. Does not imply any measure of functional intent. Part of code coverage[6].

• FSM coverage — A measure of the visited states and transitions observed on a finite-state machine during specific simulations. Can be automatically extracted from the FSM implementation or indepen- dently specified[6].

• Block Coverage - Identifies the lines of code that get executed during a simulation run. It helps you determine if the various testbenches exercise the statements in a block[11].

• Expression Coverage - Provides information on why a conditional piece of code was executed. It provides statistics for all expressions in the HDL code[11].

• Toggle Coverage - Provides information about the change of signals and ports, during a simulation run. It measures activity in the design, such as unused signals, signals that remain constant, or signals that have too few value changes[11].

(15)

Chapter 3

Description

3.1 DRRA

DRRA is a Coarse Grain Reconfigurable Architecture (CGRA). DRRA technology is a SoC architecture design methodology based on network on chip concept. Internal computation blocks and switchbox system is reconfigurable therefore flexibility of the system is very high. According to limit of the number of computation unit, some of media communication application can be implemented inside the chip.

DRRA consists of 7 x 2 DRRA Cell and each cell is connected to vertical and horizontal bus witch switch boxes. Each cell contains RegFile, mDPU and sequencer.

In this application of DRRA, re-configurability is achieved by the module called sequencer. Sequencer which contains the information about work- ing modes of mDPU, RegFile and switch box, is the main controller of the DRRA architecture. At the same time, a sequencer is able to communicate with other sequencers and share or exchange data by controlling the switch boxes. These sequencers can be programmed externally,for the media processing application to be implemented.

(16)

3.1. DRRA CHAPTER 3. DESCRIPTION

Figure 3.1: DRRA Architecture with DiMarch [1]

(17)

3.1. DRRA CHAPTER 3. DESCRIPTION

DRRA

RF

FIFO

Regfile

MDPU Interconnect Sequencer

Figure 3.2: DRRA Architecture Chart with Verified modules

DiMarch

STILE CONTILE

SEQUENCER CROSSBAR ISWITCH

SOURCE DECODER

SOURCE FSM

SRAM

AGU

Figure 3.3: DiMarch Architecture Chart with Verified modules

In this thesis, specific modules according to necessity are selected for the verification. These modules are marked in red in the figure 3.3 and 3.2. The tested modules are defined in the following subsections.

(18)

3.2. REGFILE CHAPTER 3. DESCRIPTION

3.2 RegFile

Reg File module consists of simple addressable register block. Main functionalities of the module are writing and reading functions according to given address. In addition, writing function has priority to the three different input ports for avoiding address conflict. Priority of the writing function is wr3 > wr1 > wr2. Block diagram and port list of the module presented in figure 3.4 and table 3.1.

rst_n clk wr1 wr2 wr3 wrAdr1 wrAdr2 wrAdr3 rdAdr1 rdAdr2 rdAdr3 dataIn1 dataIn2 dataIn3

dataOut1 dataOut2 dataOut3 1

1 1 1 1 6 6 2 6 6 2 16 16 256

16 16 256

RegFile

Figure 3.4: Block diagram of the RegFile.v

(19)

3.2. REGFILE CHAPTER 3. DESCRIPTION

3.2.1 I/O Ports

RegFile Port List

Portname Direction Width Type Description

rst n in 1 logic

clk in 1 logic

wr1 in 1 logic

wr2 in 1 logic

wr3 in 1 logic

wrAdr1 in REGFILEADRWITH vector

wrAdr2 in REGFILEADRWITH vector

wrAdr3 in REGFILEMEMADRWITH vector

rdAdr1 in REGFILEADRWITH vector

rdAdr2 in REGFILEADRWITH vector

rdAdr3 in REGFILEMEMADRWITH vector

dataIn1 in REGFILEDATAWITH signed

dataIn2 in REGFILEDATAWITH signed

dataIn3 in REGFILEMEMDATAWITH signed

dataOut1 out REGFILEDATAWITH signed

dataOut2 out REGFILEDATAWITH signed

dataOut3 out REGFILEMEMDATAWITH signed Table 3.1: Port list of the RegFile.v

(20)

3.3. FIFO CHAPTER 3. DESCRIPTION

RegFile Generic Port List

rst n in 1 logic

clk in 1 logic

wr1 in 1 logic

wr2 in 1 logic

wr3 in 1 logic

wrAdr1 in 6 vector

wrAdr2 in 6 vector

wrAdr3 in 2 vector

rdAdr1 in 6 vector

rdAdr2 in 6 vector

rdAdr3 in 2 vector

dataIn1 in 16 signed

dataOut1 out 16 signed

Table 3.2: Generic Port list of the RegFile.v

3.3 Fifo

FIFO is a standard FIFO used in most of the circuit design. It is used as buffer input for the instruction coming from SEQUENCER to AGU.

Specifications;

1) 2 x 64 bit word capacity

2) First written instIn block has to be read from instOut first.

3) When rd or instEnd signal comes and if FIFO is not empty instOut equal

(21)

ure 3.5 and table 3.3.

FIFO

rst_n 1

clk 1

rd 1

instEnd 1

instIn 32

full 1

instOut 64 instValid 1

Figure 3.5: Block diagram of the FIFO.v

3.3.1 I/O Ports

FIFO Port List

rst n in 1 logic

clk in 1 logic

rd in 1 logic

instEnd in 1 logic

instIn in INSTR WIDTH REG logic

full out 1 logic

instOut out 2 x INSTR WIDTH REG logic Table 3.3: Port list of the FIFO.v

FIFO Generic Port List

rst n in 1 logic

clk in 1 logic

rd in 1 logic connected to AGU

instEnd in 1 logic connected to AGU

instIn in 32 logic connected to SEQ.

full out 1 logic connected to SEQ.

instOut out 64 logic connected to AGU Table 3.4: Generic Port list of the FIFO.v

(22)

FIFO internal signal used in Process diagram List

Portname Width Description

FIFOType 2 x 64 internal registers fulltmp 1 connected full output port

empty 1

eq 1 check wrPntr and RdPntr same eqfirst 1 check wrPntr and RdPntr same

rdPtr 1 internal registers pointer wrPtr 1 internal register pointer

lastOP 1

wrEn 1

rdEn 1

rdEn2 1

lastOPTrigger 1 secondPart 1

wrEnDelay 1

rdT 1

rdTT 1

firstTime 1

rdPtrT 1

rdPtrTT 1

first 1

firstDelay 1

rdDelay 1

rdDelay2 1

rdDelay3 1

makeZero 1

makeZero2 1

makeZero3 1

rdPtrTemp 2

wrPtrTemp 2

(23)

Process Pointer

IDLE rdPtr = !rdPtr

LastOP = 0 (rd and (wrPtr=!rdPtr or LastOp)) or lastOpTrigger or Makezero3

else

IDLE wrPtr = !wrPtr

LastOP = 1

!full and InstIn[29] and InstIn[1] or secondpart

else

Process Write

IDLE myFIFO[wrPtr][63:32]=instIn

myFIFO[wrPtr][63:32]=instIn secondPart=1

myFIFO[wrPtr[31:0]=instIn secondPart=0

wrEn and !instIn(1)

wrEn and instIn(1) else

else

(rd and (wrPtr=!rdPtr or LastOp)) or lastOpTrigger or Makezero3

!full and InstIn[29] and InstIn[1] or secondpart

wrEn and instIn(1)

wrEn and !instIn(1) wrEn and !instIn(1)

else

wrEn and instIn(1)

IDLE myFIFO[rdptr**]=0

else else

makeZero makeZero

Figure 3.6: Processes of the FIFO.vhdl

(24)

3.4. CONTILE CHAPTER 3. DESCRIPTION

Process read

instOut=myFifo[rdPtr]

rd or (!rd* and instEnd)

rd or (!rd and instEnd) else

else

(instout same)

makeZero3=1

instOut[53:48]==0 and instOut[61]=1 and instOut[33]=1 and InstEnd

makeZero2=1 makeZero3=1 instOut=0 InstEnd

!InstEnd

IDLE

makeZero2=0 makeZero3=0

else

full<= (rdPtr==wrPtr and LastOP) wrEn<= !full and insIn[29]=1

makezero<=(rdEn** and rd*** and !(WrEn* and rdptr**==wrPtr)) or (wrEn and rdptr**==wrPtr) ( * ) means 1 clock cyle past

Figure 3.7: Processes of the FIFO.vhdl

3.4 Contile

Contile is the configuration tile of the Distributed Memory System (Di- MArch). It encompasses

1. Instruction Switch(iSwitch), 2. Crossbar,

(25)

3.5. CROSSBAR CHAPTER 3. DESCRIPTION

Figure 3.8: ConTile[1]

bursts transfers. These AGUs help SRAMs behave as a contiguous memory while communicating with RFile. AGUs associated with each SRAM or RFile ports are programmed to work either individually or separately. They work in a coordinated way such that it appears as if it is reading from/writing to one large contiguous memory. These sets of instruction constitute the configware which programs AGUs of SRAM and RFile. The configware resides inside the Sequencer.

This works fine for the targeted signal processing application with de- terministic cyclo-stationary behaviour. Based on the instruction issued by Sequencer, the ConTile decides to either route, partition or both.

3.5 Crossbar

ConTile Crossbar is a set of multiplexers connected with registered select lines. Each Crossbar has two independent selected inputs, which can simul-

(26)

taneously program two independent outputs. Crossbar can be programmed to multi-casting or broadcast by iteratively programming each port.

ConTile Crossbar has six input and output ports for Data. Each port is SRAM WIDTH wide. Two select ports VER SELECT and HOR SELECT provide directions. Based on the value of direction, output ports select an input port. Each output is registered.

3.5.1 I/O ports

The crossbar has seperate input and output ports. The data width is set by a constants called SRAM WIDTH. This constant discribes the width of a block size in bits which is transfered in one cycle through an interface.

Currently the width is set to 256.

Name Direction Type Range

rst n IN std logic -

clk IN std logic -

DATA MEM IN IN std logic vector SRAM WIDTH

DATA NORTH IN IN std logic vector SRAM WIDTH

DATA RF1 IN IN std logic vector SRAM WIDTH

DATA EAST IN IN std logic vector SRAM WIDTH

DATA WEST IN IN std logic vector SRAM WIDTH

CONTILE CORSSBAR

VER SELECT IN INSTRUCTION Record

RECORD TYPE CONTILE CORSSBAR

HOR SELECT IN INSTRUCTION Record

RECORD TYPE

DATA MEM OUT OUT std logic vector SRAM WIDTH

DATA NORTH OUT OUT std logic vector SRAM WIDTH

DATA RF1 OUT OUT std logic vector SRAM WIDTH

DATA RF2 OUT OUT std logic vector SRAM WIDTH

DATA EAST OUT OUT std logic vector SRAM WIDTH DATA WEST OUT OUT std logic vector SRAM WIDTH

(27)

Following table describes all possible inputs which can be used to program all the directions options for the crossbar. These values can be found as constants in NOC Package. The table is a set of constants which are records of type CONTILE CROSSBAR INSTRUCTION RECORD TYPE.

The enable discribes weather the instruction is valied or not. The To field selects the multiplexer on the output while the from field selects which input to be selected at the multiplexer. One input and one output are setup in one cycle. Multiple instruction are required for multicasting.

Name Enable To From

IGNORE CONTILE 0 0 0

TO MEMORY FROM NORTH 1 0 0

TO MEMORY FROM EAST 1 0 1

TO MEMORY FROM WEST 1 0 2

TO MEMORY FROM RF0 1 0 3

TO MEMORY FROM RF1 1 0 4

TO NORTH FROM MEMORY 1 1 0

TO NORTH FROM EAST 1 1 1

TO NORTH FROM WEST 1 1 2

TO NORTH FROM RF0 1 1 3

TO NORTH FROM RF1 1 1 4

TO EAST FROM MEMORY 1 2 0

TO EAST FROM NORTH 1 2 1

TO EAST FROM WEST 1 2 2

TO EAST FROM RF0 1 2 3

TO EAST FROM RF1 1 2 4

TO WEST FROM MEMORY 1 3 0

TO WEST FROM NORTH 1 3 1

TO WEST FROM EAST 1 3 2

TO WEST FROM RF0 1 3 3

TO WEST FROM RF1 1 3 4

TO RF0 FROM MEMORY 1 4 0

TO RF0 FROM NORTH 1 4 1

TO RF0 FROM EAST 1 4 2

TO RF0 FROM WEST 1 4 3

TO RF0 FROM RF1 1 4 4

TO RF1 FROM MEMORY 1 5 0

TO RF1 FROM NORTH 1 5 1

TO RF1 FROM EAST 1 5 2

TO RF1 FROM WEST 1 5 3

TO RF1 FROM RF0 1 5 4

Table 3.8: Input Output

(28)

3.6. ISWITCH CHAPTER 3. DESCRIPTION

3.6 iSwitch

iSwitch partitions, represent the segmented buses and routes the instructions from source to the destination using the segmented buses. Figure 3.9 illustrates the communication between two manjor components of iSwitch.

1. Instruction Decoder

2. Source Finite State Machine (FSM)

Figure 3.9: iSwitch[1]

According to Contile algorithm system should be able to set up connection between chosen Source and Destination. All the set up command come from down to up in this algorithm. Therefore all possible corner point are from north tile to (east tile or west tile) and from (east tile or west tile) to north. Therefore inside the Iswitch for able to handle critical turn point there is different priority for vertical bus out, horizontal bus out, SRam AGU instruction write, SRam AGU instruction read, top, left and right instruction.These priorities explained below;

(29)

3.6. ISWITCH CHAPTER 3. DESCRIPTION

Name I/O Type Discription

rst n in std logic -

clk in std logic -

east priority in std logic partition

east splitter direction in std logic vector partition range =2

west priority in std logic partition

west splitter direction in std logic vector partition range =2

north priority in std logic partition

north splitter direction in std logic vector partition range =2

hor bus in in NOC BUS TYPE segmented bus I/0

ver bus in in NOC BUS TYPE segmented bus I/0

hor bus out out NOC BUS TYPE segmented bus I/0

ver bus out out NOC BUS TYPE segmented bus I/0

PARTITION

top instruction out INSTRUCTION partition setup

RECORD TYPE PARTITION

left instruction out INSTRUCTION partition setup

RECORD TYPE PARTITION

right instruction out INSTRUCTION partition setup

RECORD TYPE

SRAM AGU out unsigned To AGU with range

instruction r SRAM AGU INSTR WIDTH

SRAM AGU out unsigned To AGU with range

instruction w SRAM AGU INSTR WIDTH

agu en r out std logic To AGU

agu en w out std logic To AGU

CONTILE CORSSBAR Retransmission

direction ver out INSTRUCTION insutruction for

RECORD TYPE vertical segment

CONTILE CORSSBAR Retransmission

direction hor out INSTRUCTION insutruction for

RECORD TYPE vertical segment

Table 3.9: iSwitch I/O Ports

(30)

3.7. INSTRUCTION DECODER CHAPTER 3. DESCRIPTION

VERTICAL SD

HORIZONTAL SD

VER_BUS_OUT

HOR_BUS_OUT VER_bus_ver_sel

VER_

bus_ho r_sel

HOR_bus_hor_sel HOR_bus_

ver_sel

Note: Cross sections have higher privilege than straight selections

Figure 3.10: iSwitch bus priority

Name Type Range value

This ROW UNSIGNED ROW WIDTH 1

This COL UNSIGNED COL WIDTH 1

Table 3.10: iSwitch Generics

3.7 Instruction Decoder

The instruction Decoder, decodes the instructions that it receives from iNoC’s horizontal and vertical Bus Segments using a Source Decoder. It analyses the source, destination and intermediate address along with other routing flags (Rt-flags) sent within an instruction.

Keeping in mind that source and destination signify starting and ending points of data transfers. The node which issues instruction packet is called origin node. An origin node can either be in source or destination column ConTile. Source Decoder first checks if an instruction is a direct instruction or an indirect instruction using intermediate flag (Rt-flag0). In current version we will only test direct instruction but both direct and indirect are

(31)

source, destination or intermediate node for this instruction.

3.7.1 I/O Ports

Name Direction Type

rst n in std logic

clk in std logic

NOC BUS IN in NOC BUS TYPE

DIRECTION OUT out CONTILE CORSSBAR INSTRUCTION RECORD TYPE

RETRANSMIT out std logic

SEGMENT SRC out std logic

SEGMENT DST out std logic

flip transmit out std logic

rw out std logic

NORTH instruction out PARTITION INSTRUCTION RECORD TYPE

EAST instruction out PARTITION INSTRUCTION RECORD TYPE

WEST instruction out PARTITION INSTRUCTION RECORD TYPE

Table 3.11: Instruction Decoder I/O Ports

3.7.2 Generics

The generics remain the same as section 3.6.2.

(32)

Cases Source Destination 1 (>x,>y) (>x,>y) 2 (>x,>y) (>x, =y) 3 (>x,>y) (>x,<y) 4 (>x,>y) ( =x,>y) s5 (>x,>y) ( =x, =y) 6 (>x,>y) ( =x,<y) 7 (>x,>y) (<x,>y) 8 (>x,>y) (<x, =y) 9 (>x,>y) (<x,<y) 10 (>x, =y) (>x,>y) 11 (>x, =y) (>x, =y) 12 (>x, =y) (>x,<y) c13 (>x, =y) ( =x,>y) d14 (>x, =y) ( =x, =y) c15 (>x, =y) ( =x,<y) 16 (>x, =y) (<x,>y) 17 (>x, =y) (<x, =y) 18 (>x, =y) (<x,<y) 19 (>x,<y) (>x,>y) 20 (>x,<y) (>x, =y) 21 (>x,<y) (>x,<y) 22 (>x,<y) ( =x,>y) d23 (>x,<y) ( =x, =y) 24 (>x,<y) ( =x,<y) 25 (>x,<y) (<x,>y) 26 (>x,<y) (<x, =y) 27 (>x,<y) (<x,<y) 28 ( =x,>y) (>x,>y) c29 ( =x,>y) (>x, =y) 30 ( =x,>y) (>x,<y)

(33)

Cases Source Destination d32 ( =x,>y) ( =x, =y) 33 ( =x,>y) ( =x,<y) 34 ( =x,>y) (<x,>y) c35 ( =x,>y) (<x, =y) 36 ( =x,>y) (<x,<y) s37 ( =x, =y) (>x,>y) s38 ( =x, =y) (>x, =y) s39 ( =x, =y) (>x,<y) s40 ( =x, =y) ( =x,>y) 41 ( =x, =y) ( =x, =y) s42 ( =x, =y) ( =x,<y) s43 ( =x, =y) (<x,>y) s44 ( =x, =y) (<x, =y) s45 ( =x, =y) (<x,<y) 46 ( =x,<y) (>x,>y) c47 ( =x,<y) (>x, =y) 48 ( =x,<y) (>x,<y) 49 ( =x,<y) ( =x,>y) d50 ( =x,<y) ( =x, =y) 51 ( =x,<y) ( =x,<y) 52 ( =x,<y) (<x,>y) c53 ( =x,<y) (<x, =y) 54 ( =x,<y) (<x,<y) 55 (<x,>y) (>x,>y) 56 (<x,>y) (>x, =y) Table 3.13: Source Destination Cases Part 2

(34)

Cases Source Destination 57 (<x,>y) (>x,<y) 58 (<x,>y) ( =x,>y) d59 (<x,>y) ( =x, =y) 60 (<x,>y) ( =x,<y) 61 (<x,>y) (<x,>y) 62 (<x,>y) (<x, =y) 63 (<x,>y) (<x,<y) 64 (<x, =y) (>x,>y) 65 (<x, =y) (>x, =y) 66 (<x, =y) (>x,<y) c67 (<x, =y) ( =x,>y) d68 (<x, =y) ( =x, =y) c69 (<x, =y) ( =x,<y) 70 (<x, =y) (<x,>y) 71 (<x, =y) (<x, =y) 72 (<x, =y) (<x,<y) 73 (<x,<y) (>x,>y) 74 (<x,<y) (>x, =y) 75 (<x,<y) (>x,<y) 76 (<x,<y) ( =x,>y) d77 (<x,<y) ( =x, =y) 78 (<x,<y) ( =x,<y) 79 (<x,<y) (<x,>y) 80 (<x,<y) (<x, =y) 81 (<x,<y) (<x,<y) Table 3.14: Source Destination Cases Part 3

(35)

Cases Partition(S) Partition(D)

2 v(UP)

5 h(RIGHT) v(UP)

6 h(LEFT)

8 v(UP)

10 v(UP)

11 v(UP)h(UP) v(UP)h(UP)

12 v(UP)

13 v(RIGHT,UP)

14 v(UP) v(UP)

15 v(LEFT,UP)

16 v(UP)

17 v(UP) v(UP)

18 v(UP)

20 v(UP)

22 h(RIGHT)

23 v(UP)

26 v(UP)

29 v(RIGHT,UP)

30 h(RIGHT)

32 v(RIGHT)

33 h(LEFT) h(RIGHT)

35 v(RIGHT)

36 h(RIGHT)

37 v(UP)

38 v(UP) v(UP)

39 v(UP)

40 v(RIGHT)

42 v(LEFT)

46 h(LEFT)

47 v(RIGHT,UP)

49 h(RIGHT) h(LEFT)

50 v(LEFT)

Table 3.15: Partition Cases Part 1

(36)

Cases Partition(S) Partition(D)

52 h(LEFT)

53 v(LEFT)

56 v(UP)

60 h(LEFT)

64 v(UP)

65 v(UP) v(UP)

66 v(UP)

67 v(RIGHT)

69 v(LEFT)

74 v(UP)

76 h(RIGHT)

Table 3.16: Partition Cases Part 2

(37)

Cases Partition(S)

5 h(TO MEMORY FROM EAST)

6 h(TO WEST FROM EAST)

8 v(TO RF1 FROM NORTH)

13 v(TO EAST FROM NORTH)

14 v(TO MEMORY FROM NORTH)

15 v(TO WEST FROM NORTH)

22 h(TO EAST FROM WEST)

23 h(TO MEMORY FROM WEST)

29 v(TO NORTH FROM EAST)

32 h(TO MEMORY FROM EAST)v(TO MEMORY FROM EAST)

37 h(TO EAST FROM MEMORY)v(TO NORTH FROM MEMORY)

38 v(TO NORTH FROM MEMORY)

39 h(TO WEST FROM MEMORY)v(TO NORTH FROM MEMORY) 40 h(TO EAST FROM MEMORY)v(TO EAST FROM MEMORY) 42 h(TO WEST FROM MEMORY)v(TO WEST FROM MEMORY) 43 h(TO EAST FROM MEMORY)v(TO RF1 FROM MEMORY)

44 v(TO RF1 FROM MEMORY)

45 h(TO WEST FROM MEMORY)v(TO RF1 FROM MEMORY)

47 v(TO NORTH FROM WEST)

56 v(TO NORTH FROM RF1)

59 h(TO MEMORY FROM EAST)v(TO MEMORY FROM RF1)

Table 3.17: Instruction Cases Partition(S) Part 1

(38)

Cases Partition(S)

67 v(TO EAST FROM RF1)

68 v(TO MEMORY FROM RF1)

69 v(TO WEST FROM RF1)

Table 3.18: Instruction Cases Partition(S) Part 2

(39)

Cases Partition(D)

13 v(TO EAST FROM NORTH)

29 v(TO NORTH FROM EAST)

32 h(TO MEMORY FROM EAST)v(TO MEMORY FROM EAST)

35 v(TO RF1 FROM EAST)

37 h(TO EAST FROM MEMORY)v(TO NORTH FROM MEMORY)

38 v(TO NORTH FROM MEMORY)

39 h(TO WEST FROM MEMORY)v(TO NORTH FROM MEMORY) 40 h(TO EAST FROM MEMORY)v(TO EAST FROM MEMORY) 42 h(TO WEST FROM MEMORY)v(TO WEST FROM MEMORY) 43 h(TO EAST FROM MEMORY)v(TO RF1 FROM MEMORY)

44 v(TO RF1 FROM MEMORY)

45 h(TO WEST FROM MEMORY)v(TO RF1 FROM MEMORY)

47 v(TO NORTH FROM WEST)

50 v(TO MEMORY FROM WEST)

53 v(TO RF1 FROM WEST)

59 h(TO MEMORY FROM EAST)v(TO MEMORY FROM RF1)

Table 3.19: Instruction Cases Partition(D) Part 1

(40)

Cases Partition(D)

Table 3.20: Instruction Cases Partition(D) Part 2

In this table :

Partition(S): Partition instruction originates from source column sequencer Partition(D): Partition instruction originates from destination column se-

quencer

v(): Instruction received from Vertical segment h(): Instruction received from Horizontal segment N: North

E: East W: West

S: South (South is replaced for contile RF0 and RF1 using by using i RF flag )

M: Memory

(41)

3.8. SOURCE FSM CHAPTER 3. DESCRIPTION

3.8 Source FSM

Figure 3.11: Source FSM[1]

Source FSM analyses instruction as well as the output of source decoder.

It decides to either route, partition or perform both functionalities simulta- neously. This is illustrated in Figure 3.11. In partitioning state partitioning direction from the source decoder is compared to the current state. If the flags are different then retransmission flag is made true regardless of the po- sition of the node. When the retransmission flag is set to true, then previous instruction is retransmitted either to the horizontal or the vertical bus segment based on the value of inverted-flag. If the instruction is received from vertical bus segment and inverted flag is true then instruction is transmitted to horizontal bus segment, otherwise it is retransmitted to the vertical bus segment. The vice versa is true for instructions from horizontal segment.

In the routing state it checks if it is a corner, source, destination or intermediate node by checking the flags from source decoder. For corner or intermediate node it waits for AGU instructions and retransmits them to the appropriate bus segments. For source and destination nodes it waits for AGU instructions which are sent to the appropriate AGUs of the STile.

In both state, routing and partitioning operations are performed simul- taneously. Retransmissions are performed after partitions are setup.

(42)

3.8. SOURCE FSM CHAPTER 3. DESCRIPTION

3.8.1 I/O Ports

Name I/O Type Discription

rst n in std logic -

clk in std logic -

BUS IN in NOC BUS TYPE -

RETRANSMIT in STD LOGIC data turning

SEGMENT SRC in STD LOGIC the source node (for routing) SEGMENT DST in STD LOGIC the destination node (for routing)

flip transmit in STD LOGIC an intermediate node

and we need to flip the segment bit (for routing)

rw in STD LOGIC is this a e or a desitination node

PARTITION

NORTH instruction in INSTRUCTION partition setup RECORD TYPE

PARTITION

SOUTH instruction in INSTRUCTION partition setup RECORD TYPE

PARTITION

EAST instruction in INSTRUCTION partition setup RECORD TYPE

PARTITION

WEST instruction in INSTRUCTION partition setup RECORD TYPE

east priority in std logic partition status

east splitter direction in std logic vector(2) partition status

west priority in std logic partition status

west splitter direction in std logic vector(2) partition status

north priority in std logic partition status

north splitter direction in std logic vector(2) partition status

BUS OUT out NOC BUS TYPE segmented bus output

bus ver sel out STD LOGIC select segmented bus output bus hor sel out STD LOGIC select segmented bus output

agu en r out std logic AGU enable

(43)

Chapter 4

Verification

4.1 RegFile

tb RegFile is implemented for creating the test environment. Some random address and data are created and sent to the port of the module. The address value which created for write operation, has given to the read address port for comparing the data sent to the registers one clock cycle before.

Assertion is used to compare these values. Data output of the Regfile module is compared to virtually created variable multidimensional array “ram”

inside the test-bench. This array has been recorded all the write operation with the priority of write operation. Data3 port read 16 x 16 bit part from memory and dimensions scale is not unsupported from compiler. Therefore, the assertion for data3 has handled by parsing the 16 bit world.

Assertion list

assertion 1: read dataOut1 and compare with the data ,which had written previous clock cycle.

assertion 2: read dataOut2 and compare with the data ,which had written previous clock cycle.

assertion 3 to 19: read dataOut3 and compare with the data ,which had written previous clock cycle.

Random variable

Random variable Port Name Range addr1 wrAdr1,rdAdr1 0 to 63 addr2 wrAdr2,rdAdr2 0 to 63 addr3 wrAdr3,rdAdr3 0 to 3

data1 dataIn1 0 to 2¹⁶

data2 dataIn2 0 to 2¹⁶

data3 dataIn3 0 to 2²⁵⁶

Table 4.1: Random variable list of the RegFile.v

(44)

4.2. FIFO CHAPTER 4. VERIFICATION

4.2 Fifo

Random variables in the table are applied to FIFO module in System Verilog testbench environment for 10000 clock cycle without any constraint.

With 4 assertion, behaviour of the FIFO is tested according to the specification.

Description of assertions;

1)Single write operation is tested according to specification 5. When the single write operation is executed previous clock cycle and rd or instEnd are triggered, then the written instruction have to come out and second part(31 to 0) of 64 bit word must be 0.

2)Double write operation is tested according to specification 5. same as single write. Only difference is instruction captured in two clock cycle.

Second part is captured next clock cycle after the first instruction and is written to FIFO. Then the captured instruction is compared with instOut when the read operation was executed.

3)FIFO behaviour is tested. The first instruction is written to FIFO have to come out first.

4) Special InstEnd case is tested whenever the written instructions (21:36) bit is zero and on the read operation instEnd is 1 for 2 cycles 0 value sent to inst out of the FIFO.

List of fixed bugs;

-On single write operation not all the time second part has got zero value.

-Some case InstEnd delete the data inside FIFO. But the actual mechanism is not understandable by the code.

(45)

4.3. CROSSBAR CHAPTER 4. VERIFICATION

written in VHDL format; file name is “contile crossbar adapter.vhdl”

According to instructions table setting up the connection controller instruction is handled with complex algorithm. Because 5 input is connected to 6 output, the selected port is not able to connect back itself. While input port is indexing, index of the output port is not included in available input ports index. Therefore, indexing of the input ports is changed according to output port. This issue is handled in test-bench by using the formgen class.

Random signals are applied to the control and the data input of the device. To be able to observe switching activity, 30 different combinations are randomly sent to both vertical and horizontal control signal. Assertions listed below are used for verification.

Assertion list

assertion 1: When vertical control is enable, next clock cycle defined input output connection has checked.

assertion 2: When horizontal control is enable, next clock cycle defined input output connection has checked. Vertical control have high priority.

Therefore, neglect the effect of horizontal control in case both control signal tried to connect different input to same output. Therefore, assertion-2 only works when vertical connection not enable,to be able to handling the priority.

Random variable

Random variable Port Name Range

rH ENABLE V ENABLE 0 to 1

rV SELECT TO V SELECT TO 0 to 5 rV SELECT FROM V SELECT FROM 0 to 4

rH ENABLE H ENABLE 0 to 1

rH SELECT TO H SELECT TO 0 to 5 rH SELECT FROM H SELECT FROM 0 to 4

DATA MEM IN MEM IN 0 to 2²⁵⁶

DATA NORTH IN NORTH IN 0 to 2²⁵⁶

DATA RF1 IN RF1 IN 0 to 2²⁵⁶

DATA RF2 IN RF2 IN 0 to 2²⁵⁶

DATA EAST IN EAST IN 0 to 2²⁵⁶

DATA WEST IN WEST IN 0 to 2²⁵⁶

Table 4.3: Random variable list of the tb crossbar.v

(46)

4.4. INSTRUCTION DECODER CHAPTER 4. VERIFICATION

4.4 Instruction Decoder

Tested device control signals are implemented as special VHDL type. To be able to handle port binding in System Verilog, test-bench adapter file is written in VHDL format; file name is “contile sourcedecoder adapter.vhdl”

According to table 4.4, random signal column and row are given to source, destination , i RF and i ON signals given to the decoder. the Out- put signals are compared with expected result. All the 81 cases tested for vertical node and some of the fixed bugs are listed above.

1: Unsigned to signed casting causes loss of data on the row or column numbers bigger then most significant bit used.line 800

2: Partition instruction is not reset to idle flag beginning of the status check;

therefore, wrong old partition flag values are send.line 125

3: Due to typing mistake in the code, some cases do not matched the table.

Assertion list

assertion 1 CHECK Inst: When NOC BUS IN BUS ENABLE, next clock cycle according to given row and column value status case is calculated and instruction flags are checked according to the table.

assertion 2 CHECK W: When NOC BUS IN BUS ENABLE, next clock cycle according to given row and column value status case is calculated and west partitioning flags are checked according to the table.

assertion 3 CHECK E: When NOC BUS IN BUS ENABLE, next clock cycle according to given row and column value status case is calculated and east partitioning flags are checked according to the table.

assertion 4 CHECK N: When NOC BUS IN BUS ENABLE, next clock cycle according to given row and column value status case is calculated and

(47)

4.5. SOURCE FSM CHAPTER 4. VERIFICATION

Random variable

sr I SR 0 to 4

sc I SC 0 to 7

dr I DR 0 to 4

dc I DC 0 t0 7

on I ON 0 to 1

rf I RF o to 1

Table 4.4: Random variable list of the tb crossbar source decoder.v

4.5 Source FSM

Tested device control signals are implemented as special VHDL type. To be able to handle port binding in System Verilog, test-bench adapter file is written in VHDL format; file name is “contile sd adapter.vhdl”

To be able to simplify assertions Fsm state value is connected to tem- porary output port of the tested module. According to the state machine table and given specification of the modules state transitions and expected outputs tested by several assertion listed below. To be able to test each case all the input ports are randomized for sufficient number of clock cycle.

Assertion list

assertion 1 Check retransmit: When Route or Both Steps case if retransmit flag is enable, next clock cycle BUS OUT has to be equal to previous BUS IN.

assertion 2 Check Nort: When Partition or Both Steps case if North direction is not North splitter direction, next clock cycle BUS OUT has to be equal to previous BUS IN.

assertion 3 Check East: When Partition or Both Steps case if East direction is not East splitter direction, next clock cycle BUS OUT has to be equal to previous BUS IN.

assertion 4 Check West: When Partition or Both Steps case if West direction is not West splitter direction, next clock cycle BUS OUT has to be equal to previous BUS IN.

assertion 5 CHECK dts:When Route or Both Steps case if the Destina- tion flag is active, AGU write instructions must be sent to the AGU or next

(48)

4.5. SOURCE FSM CHAPTER 4. VERIFICATION

state must be WAIT4AGU case.

assertion 6 CHECK src:When Route or Both Steps case if the Source flag is active, AGU read instructions must be sent to the AGU or next state must be WAIT4AGU case.

assertion 7 CHECK DTS:Transition after Route or Both Steps case to WAIT4AGU case AGU write instructions must not be active.

assertion 8 CHECK SRC:Transition after Route or Both Steps case to WAIT4AGU case AGU read instructions must not be active.

assertion 9 Check waitAgu: If case changed FROM WAIT4AGU to other case at least AGU read or AGU write instruction has to be activated.

assertion 10. Check ver1: When Route or Both Steps case evaluated if Retransmit flag or North direction is not North splitter direction then bus ver sel has to be enabled.

assertion 11. Check ver2: When Partition or Both Steps case evaluated if East direction is not East splitter direction or West direction is not West splitter direction then bus hor sel has to be enabled.

According to these assertions some bugs are detected and fixed.

(49)

4.6. ISWITCH CHAPTER 4. VERIFICATION

Random variable

BUS IN ENABLE rBUS IN ENABLE 0 to 1

BUS IN INSTR CODE rBUS IN INSTR CODE 0 to 4

BUS IN INSTRUCTION CODE rBUS IN INSTRUCTION 0 to 4

RETRANSMIT rRETRANSMIT 0 to 1

SEGMENT SRC rSEGMENT SRC 0 to 1

rSEGMENT DST rSEGMENT DST 0 to 1

NORTH INSTRUCTION ENABLE rNORTH INSTRUCTION ENABLE 0 to 1 NORTH INSTRUCTION PARTITION rNORTH INSTRUCTION PARTITION 0 to 4 NORTH INSTRUCTION PRIORITY rNORTH INSTRUCTION PRIORITY 0 to 1 EAST INSTRUCTION ENABLE rEAST INSTRUCTION ENABLE 0 to 1 EAST INSTRUCTION PARTITION rEAST INSTRUCTION PARTITION 0 to 4 EAST INSTRUCTION PRIORITY rEAST INSTRUCTION PRIORITY 0 to 1 WEST INSTRUCTION ENABLE rWEST INSTRUCTION ENABLE 0 to 1 WEST INSTRUCTION PARTITION rWEST INSTRUCTION PARTITION 0 to 4 WEST INSTRUCTION PRIORITY rWEST INSTRUCTION PRIORITY 0 to 1 east splitter direction reast splitter direction 0 to 4 west splitter direction rwest splitter direction 0 to 4 north splitter direction rnorth splitter direction 0 to 4

Table 4.5: Random variable list of the tb contile sd.v

4.6 iSwitch

Tested device control signals are implemented as special VHDL type. To be able to handle port binding in System Verilog, test-bench adapter file is written in VHDL format; file name is “iswitch adapter.vhdl”

Inside the testbench both sourceDecoder and sourceFsm modules assertions are used for vertical and horizontal modules. After the codeshave been de- bugged and the specification has been clarified, all functions of the system work properly.

Assertion list

assertion 1 HOR CHECK DTS: Transition from Route or Both Steps state to WAIT4AGU state AGU write instructions haven’t to be active for horizontal module.

assertion 2 HOR CHECK SRC: Transition from Route or Both Steps state to WAIT4AGU state AGU read instructions haven’t to be active for horizontal module.

(50)

assertion 3 HOR Check waitAgu: If state is changed from WAIT4AGU to other state at least AGU read or AGU write instruction has to be activate for horizontal module.

assertion 4 VER CHECK DTS: Transition from Route or Both Steps state to WAIT4AGU state AGU write instructions haven’t to be active for vertical module.

assertion 5 VER CHECK SRC: Transition from Route or Both Steps state to WAIT4AGU state AGU read instructions haven’t to be active for vertical module.

assertion 6 VER Check waitAgu: If state changed from WAIT4AGU to other state at least AGU read or AGU write instruction have to be activate for vertical module.

assertion 7 Check retransmitV: Retransmit from horizontal fsm to vertical bus out has to be done due to corner state or north splitter mismatch with priority to Check retransmitV2.

assertion 8 Check retransmitV2: Retransmit from vertical fsm to vertical bus out has to be done due to north splitter mismatch.

assertion 9 Check retransmitH: Retransmit from vertical fsm to horizontal bus out has to be done due to corner state or west or east splitter mismatch with priority to Check retransmitH2.

assertion 10 Check retransmitH2: From horizontal fsm to horizontal bus out has to be done due to west or east splitter mismatch.

assertion 11 CHECK H dts: After Agu write instruction come to horizontal fsm it has to be sent to SRAM AGU instruction w with priority then

(51)

assertion 15 VER CHECK Inst: When vertical bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and Instruction flag is checked according to the table.

assertion 16 HOR CHECK Inst: When horizontal bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status is case calculated and Instruction flag is checked according to the table.

assertion 17 VER CHECK W: When vertical bus in enable is and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and west partition flag is checked according to the table high priority to assertion HOR CHECK W .

assertion 18 VER CHECK E: When vertical bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and east partition flag is checked according to the table high priority to assertion HOR CHECK E .

assertion 19 VER CHECK N:When vertical bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and north partition flag is checked according to the table high priority to assertion HOR CHECK N .

assertion 20 HOR CHECK W: When horizontal bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and west partition flag is checked.

assertion 21 HOR CHECK E: When horizontal bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and east partition flag is checked.

assertion 22 HOR CHECK N: When horizontal bus in is enable and AGU instruction isn’t, next clock cycle according to given row and column value status case is calculated and north partition flag is checked.

(52)

Random variable

HOR BUS IN ENABLE rHOR BUS IN ENABLE 0 to 1

HOR BUS IN INSTR CODE rHOR BUS IN INSTR CODE 0 to 4

HOR BUS IN INSTRUCTION[10:9] rVsr 0 to 4

HOR BUS IN INSTRUCTION[14:12]sc rVsc 0 to 7

HOR BUS IN INSTRUCTION[17:16]dr rVdr 0 to 4

HOR BUS IN INSTRUCTION[21:19]dc rVdc 0 t0 7

HOR BUS IN INSTRUCTION[31]on rVon 0 to 1

HOR BUS IN INSTRUCTION[32]rf rVof o to 1

VER BUS IN ENABLE rVER BUS IN ENABLE 0 to 1

VER BUS IN INSTR CODE rVER BUS IN INSTR CODE 0 to 4

VER BUS IN INSTRUCTION[10:9] rVsr 0 to 4

VER BUS IN INSTRUCTION[14:12]sc rVsc 0 to 7

VER BUS IN INSTRUCTION[17:16]dr rVdr 0 to 4

VER BUS IN INSTRUCTION[21:19]dc rVdc 0 t0 7

VER BUS IN INSTRUCTION[31]on rVon 0 to 1

VER BUS IN INSTRUCTION[32]rf rVof o to 1

east splitter direction reast splitter direction 0 to 4 west splitter direction rwest splitter direction 0 to 4 north splitter direction rnorth splitter direction 0 to 4

Table 4.6: Random variable list of the tb iswitch.v

(53)

Chapter 5

Result

5.1 RegFile

5.1.1 Coverage

Coverage Bins wr1 wr2 wr3 wrAdr1 wrAdr2 wrAdr3 rdAdr1 rdAdr2 rdAdr3

Table 5.1: list of the Coverage bins

All the input and output ports of the DUT are included in coverage bins.

Hundred percent of functional coverage has been achieved and the summary of the results are given below.

Block Expression Toggle Assertion Cov Bins

100 100 99 100 100

Table 5.2: Summary of Coverage Result

5.1.2 Coverage Result Discussion

All write and read control signals are tested and according to assertion,

(54)

5.2. FIFO CHAPTER 5. RESULT

are presented in appendix.

5.2 Fifo

5.2.1 Coverage

Coverage Bins rd

instEnd instIn

rd x instEnd x instIn Table 5.3: list of the Coverage bins

All input and output ports of the DUT are included in coverage beans.

The summary of the result is given below.

94 98 81 100 100

All possible input signals are included in cross coverage bins.100 percent coverage is achieved. Known bugs according to assertions are listed under Test environment section. Detailed coverage results are presented in the appendix.

5.3 Crossbar

(55)

5.4. INSTRUCTION DECODER CHAPTER 5. RESULT

All of the control ports of the DUT are included in coverage beans.

Functionality of the device is switch-box. To be able to test functionality of switch-box large scale data in signal has to be connected to data out signal.

Ineffective data buses are not included in coverage bins. These signals are used for monitoring the accuracy of switching activity.

100 100 99 100 72

All inputs for the control signals coverage are achieved at 100 percent cross coverage. Result of Cover Group bins is 72 percent because 3 bit array is used as control input but smaller input range has used for the functionality.

Detailed Coverage results are presented in the appendix.

5.4 Instruction Decoder

5.4.1 Coverage

Coverage Bins SR SC DR DC On RF

SR x SC x DR x DC x On x RF Table 5.7: list of the Coverage bins

All the control signal ports of the DUT are included in coverage bins.

Unused dummy signals are not included in coverage bins. Detailed coverage results are listed below.

100 100 29 100 99

(56)

5.5. SOURCE FSM CHAPTER 5. RESULT

All of the control signals cross coverages have achieved with 99 percent.

Toggle coverage is very low because some of the bits inside input ports of the module is not related to functionality of the module. Known bugs according to assertions are listed under verification section Detailed Coverage results are presented in the appendix.

5.5 Source FSM

5.5.1 Coverage

Coverage Bins RETRANSMIT SEGMENT SRC SEGMENT DST

NORTH Par NORTH sp

EAST Par EAST sp WEST Par

WEST sp InstCode

Status

All the control signal ports of the DUT are included in coverage bins.

Unused dummy signals are not included in coverage bins. Detailed coverage results are listed below.

(57)

5.6. ISWITCH CHAPTER 5. RESULT

5.6 iSwitch

5.6.1 Coverage

Coverage Bins VSR VSC VDR VDC VOn VRF HSR HSC HDR HDC HOn HRF NORTH sp

EAST sp WEST sp HorInstCode VerInstCode

VSR x VSC x VDR x VDC x VOn x VRF x HSR x HSC x HDR x HDC x HOn x HRF x NORTH sp x EAST sp x WEST sp x HorInstCode x VerInstCode

All control signal ports of the DUT are included in coverage bins . Un- used functionless signals are not included in coverage bins. Detailed coverage results are listed below.

99 100 23 100 100

All of the control signals coverages are achieved at 100 percent. Toggle coverage is very low because some of the bits inside input ports of the module are not related to functionality of the module, Therefore, they are not have to randomized. Detailed Coverage results are presented in the appendix.

Module-level Verification For DRRA and DiMarch

Royal Institute of Technology

School Of Information and Communication Technology

Module-level Verification For DRRA and DiMarch

Contents

List of Figures

List of Tables

Chapter 1

Introduction

Chapter 2

Background

2.1 Assertion based Verification

2.2 SystemVerilog

Chapter 3

Description

3.1 DRRA

DRRA

RF

FIFO

Regfile

MDPU Interconnect Sequencer

DiMarch

STILE CONTILE

SEQUENCER CROSSBAR ISWITCH

SOURCE DECODER

SOURCE FSM

SRAM

SRAM

AGU

3.2 RegFile

RegFile

3.3 Fifo

FIFO

3.4 Contile

3.5 Crossbar

3.6 iSwitch

VERTICAL SD

HORIZONTAL SD

3.7 Instruction Decoder

3.8 Source FSM

Chapter 4

Verification

4.1 RegFile

4.2 Fifo

4.4 Instruction Decoder

4.5 Source FSM

4.6 iSwitch

Chapter 5

Result

5.1 RegFile

5.2 Fifo

5.3 Crossbar

5.4 Instruction Decoder

5.5 Source FSM

5.6 iSwitch