Transformation - Functional Verification - Lecture Slides, Slides of Computer Science

Download Transformation - Functional Verification - Lecture Slides and more Slides Computer Science in PDF only on Docsity!

Calculator 3:

Transformation to an ALU!

Design specs

Overview of calc

Calc3 is is the third in a series. The following describes the first calc. The first design is a simple 4 port calculator, where each port can send in 1 command at a time. Th commands consist of add, subtract, shift left, and shift right. The operand data accompanies the commands. Since there are 4 ports, there could be up to four oustanding commands at once. The input/output timing on a single port is as follows:

req1_data_in<0:31>

req1_cmd_in<0:3>

out_data1<0:31>

out_resp1<0:1>

The lightening bolt represents "some number of cycles passing". The data accompanies a successful response signal.

A second request from the same port is prohibited until the response from the first command is received.

Internally, there are two ALUs, one that processes all add commands, and the second for all shiftDocsity.com

Overview of calc2 (continued)

A timing diagram of back-to-back commands might look like this:

The lightening bolt represents "some number of cycles passing". The data accompanies a success response signal. Responses may or may not be in order, but the tags will identify which command the response is for.

There may be up to 16 commands outstanding at once (4 ports, 4 commands each). As in the first calc design, the commands consist of add, subtract, shift left, and shift right.

req1_cmd_in

req1_data_in

req1_tag_in

req_resp1req_data

req_tag

Calc3 Overview

Design now has 16 internal data registers

 Arithmetic operands no longer sent by requestor

 Operand data is read internally from registers

Two new commands added to access registers

 Fetch from register x; Store to register x

Two new branch commands

 Successful branch causes next command from port to be

skipped

Each requester can still send in up to 4 commands

 2 bit tag on request

 Using same tag simulaneously is not supported

I/O protocols

For each requestor X: Inputs: reqX_cmd(0:3)  add: 0001 adds contents of d1 to d2 and stores in r  subtract: 0010 subtracts contents of d2 from d1 and stores in r  shift left: 0101 shifts contents of d1 to the left d2(27:31) places and stores in r  shift right:0110 shifts contents of d1 to the right d2(27:31) places and stores in r  store: 1001 stores reqX_data(0:31) into r  fetch:1010 fetches contents of d1 and outputs it on out_dataX(0:31)  branch if zero: 1100 skip next valid command if contents of d1 are 0  branch if equal: 1101 skip next valid command if contents of d1 and d2 are equal reqX_d1(0:3) reqX_d2(0:3) reqX_r1(0:3) reqX_tag(0:1) reqX_data(0:31) Outputs: outX_resp(0:1)  Successful completion: 01  overflow/underflow error:  Command skipped due to branch: 11 outX_tag(0:1) outX_data(0:31)

I/O timing

reqX_cmd(0:3) reqX_d1(0:3) reqX_d2(0:3) reqX_r1(0:3) reqX_tag(0:1) outX_resp(0:1) outX_tag(0:1)

Basic timing of a single arithmetic command:

I/O timing

reqX_cmd(0:3) reqX_d1(0:3) reqX_d2(0:3) reqX_r1(0:3) reqX_tag(0:1) outX_resp(0:1) outX_tag(0:1) outX_data(0:31)

Basic timing of a fetch command:

I/O timing

reqX_cmd(0:3) reqX_d1(0:3) reqX_d2(0:3) reqX_r1(0:3) reqX_tag(0:1) outX_resp(0:1) outX_tag(0:1) outX_data(0:31)

Basic timing of a branch command:

valid d2 value when command is 1101

value is 1 if next command will be skipped (branch occurs) Docsity.com

Command that follows a branch

 Any valid command can follow a branch

 If the branch evaluates true, the following command will b

"skipped": Add/Sub/SL/SR will not write to array Store will not write to array Fetch will not return data Branch will evaluate to false (case of branch followed by branch)

 Response code of '11'b for follower indicating above actio

has occurred

 Invalid OP codes are ignored and are NOT considered to

be "command that follows a branch."

Command and ordering rules

Within each requestor's (port's) instruction stream, operations

can complete out of order with the following restrictions:

Operands (d1,d2) cannot be used if prior instruction in

stream writes (result r1) to the operand and prior instruction

has not completed.

Results (r1) cannot be written if either of the prior command'

operands (d1,d2) use the same register as R1.

Same R1(result) values from different instructions must

complete in order.

There are no restrictions of this type across different

requestors.

Some thoughts

 As in real-life, verification requires teamwork an

communication

 Make a testplan

Aim to get something "up and running" early, and build upon it....but plan for growth.

 Split the work

Drivers, Monitors, Checkers, Coverage, referenc model How will you predict the outcome? When?

 Use instructor as "designer"

 Final presentations on Friday

Teams

 David Smith, Peter Szewczyk, Karina Hernande

 Gernot (Gary) Gunther, Vasantha Vuyyuru

 Shaun Uldrikis, Lynn Marie Kiefer

 Gary Moore, Michael Halas

 Corey Westrick, Fadi Zaraket

 Vic Fernandes, Visda Vokhshoori

 Suma Aluka, Bing Hu, Steve Goldman

 Sheryll Veneracion, Ka-shan Choy