© 2003 Fast-Chip. All rights reserved. 11/23/2015 3:37:34 AM RTL-Synchronized Transaction Reference Models Dave Whipp Fast-Chip Inc.

© 2003 Fast-Chip. All rights reserved. 04/20/23 07:17 PM

RTL-SynchronizedTransaction Reference Models

Dave Whipp

Fast-Chip Inc.

© 2003 Fast-Chip Confidential. All rights reserved. 04/20/23 07:17 PM

Motivation

›Needed Cycle Verification•Now, not 6 months later

›Why build two models, when one will do•We had a working “functional” model

›Don’t Chase RTL•Avoid modeling artifacts of the implementation


Overview

1. What is Transaction Synchronization

2. Patterns in Transaction Synchronization

3. Methodology, Futures, Summary


Part 1

What is Transaction Synchronization?


A Functional Model

int classify_packet ( Packet packet_data, Uint32 rule_address ){

int result = ITERATE while (result == ITERATE) {

RuleStruct rule; read_rule(&rule, rule_address); int field = extract(rule, packet_data); interpret(rule, field, &result, &rule_address);

} return result;

}


“Bringup” Flow

test.script C-sim

RTL-sim

Compare

csim.log

rtl.log


Transaction Interactions

Read-Rule

Rules DB

Write-Rule

Thread A Thread B


Trace Files

›A trace of the sequence of transaction steps›Each synch point has a name, and thread-ID

•Comments provide context (values from RTL)

›Often hand-edited during debug

Example:[1536] read_rule thread_A # addr=h8a34 data=h1578[1544] write_rule thread_B # addr=h8a34 data=h5343[1632] read_rule thread_A # addr=h8a34 data=h5343[1694] write_rule thread_B # addr=h8a34 data=hf519[1694] read_rule thread_A # addr=h8a34 data=hf519


“Synchronized” Flow

C-sim

RTL-sim

Compare

csim.log

rtl.logtest.script


Simulation Kernel

Read Synch

Read Stimulus

[pending]

[not pending]

Call Synchfunction

Pending SynchPoints (task list)


Memory Access with Arbiter

A

B

Arb Mem

Monitor

Delay Delay


Dual Port Memory Access

Monitor A Monitor B

A BMemoryDelay Delay


int field = extract(rule, packet_data); interpret(rule, field, &result, &rule_address);

}return result;

}

A Functional Model

}

int continue_read_rule (){

int classify_packet ( Packet packet_data, Uint32 rule_address ){

int result = ITERATEwhile (result == ITERATE){

RuleStruct rule; read_rule(&rule, rule_address);


Refactoring

1. Move local variables into a “context” structure. Create an instance (on the heap, not the stack) at start of transaction – and delete at end.

2. Replace iterative loops with recursive functions.

3. For each function that requires synchronization (directly or indirectly), replace the call with a request/callback pair.


“Context” Structure

struct context{

Packet packet_data;Uint32 rule_address;RuleStruct rule;int field;int result;

void (*callback) (int);};


Introduce Context Structure

void classify_packet_request (Packet packet_data, Uint32 rule_address, void (*callback)(int))

{ struct context *cxt = calloc(1, sizeof(struct context)); cxt->packet_data = packet_data; cxt->rule_address = rule_address; cxt->callback = callback;

cxt->result = ITERATE;

classify_packet_iterate(cxt);}

void packet_classify_reply(struct context *cxt){

int result = cxt->result;void (*callback)(int) = cxt->callback;free(cxt);callback(result);

}


Non-Recursive Implementation

void classify_packet_iterate ( struct context *cxt )

{

while (cxt->result == ITERATE)

{

read_rule(&cxt->rule, cxt->rule_address);

cxt->field = extract(cxt->rule, cxt->packet_data);

interpret(cxt->rule, cxt->field, &cxt->result, &cxt->rule_address);

}

classify_packet_reply(cxt);

}


Recursive Implementation

void classify_packet_iterate ( struct context *cxt )

{

if (cxt->result == ITERATE)

{

read_rule(&cxt->rule, cxt->rule_address);

cxt->field = extract(cxt->rule, cxt->packet_data);

interpret(cxt->rule, cxt->field, &cxt->result, &cxt->rule_address);

classify_packet_iterate(cxt);

}

else

{

classify_packet_reply(cxt);

}

}


Synchronized Implementation

void classify_packet_iterate ( struct context *cxt ){

if (cxt->result == ITERATE) {

read_rule_request(&cxt->rule, cxt->rule_address, &classify_packet_continue); } else {

classify_packet_reply(cxt); }

}

void continue_read_rule ( struct context *cxt ){ cxt->field = extract(cxt->rule, cxt->packet_data); interpret(cxt->rule, cxt->field, &cxt->result, &cxt->rule_address); classify_packet_iterate(cxt);}


Transaction Diagrams

Extract

Interpret

Read Rule

[done] [iterate]

Rules DB

Packet Buffer

Classify Packet


Part 2

Patterns in Transaction Synchronization


Adding a Cache

›Cache needn’t effect transactions•Data-RAM not modeled

•cache is coherent

•Can rerun all tests, with no changes to C model

›Tag RAM is an Addition, not Modification•Independent Transactions

•Independent Synchronization


Single Port, Cached

A

B

Arb Mem

Read/Write

Delay DelayCache

Tag RAMMiss Rd/Wr

Hit Rd/Wr

Correct Errors

Check ECC


Cache Transaction (Read)

Read Data

[hit]

Write Tag

Read Tag

Read Tag

[miss]

Write TagCheck ECC


FIFOs and Counters

›Delay elements need no synchronization•But synchronization can increase locality

›Some FIFOs can drop transactions•Synchronize overflow: don’t model actual size

›Counters seem to need cycle-based model•We want to avoid this

›Correct Synch propagates “forces” to Model


Force

Synchronizing a FIFO

Flow Control

Producer ConsumerFIFO

Push Pop

Drop


FIFO Transaction Diagram

[drop]

[push]

Pop


FIFO Synchronization Checker

Producer ConsumerFIFO

Push PopDrop

Checker: Queue Size Assertions


Force

value

Counters

Register+1

load

Client

UpdateSample

value

select clk sample_en


Scaffolding

›Permit verification incomplete RTL•Encourage end-to-end skeletons

•Implement “incorrect, but simple” algorithms•Don’t wait for complete RTL

•Postpone modeling the algorithm

•Use synch to avoid chasing a moving target

•Remove scaffolding once RTL is complete


An Algorithm Cache

Read Node

TreeSearch

NodeMemory

Result Cache

Hit Miss

Tag Ram

Hit Rd/Wr

Miss Rd/Wr


Algorithm Cache: Transactions

Read Node

[match]

[No match]

[iterate]

[hit]

[miss]

Backdoorsearch

Read Tag


Speculation

›When hardware speculates:•Effect precedes cause

•Transaction model appears incorrect

›Creative accounting can sometimes help•Insert a “virtual” delay

•Filter based on future events


Speculation

Read Ctrl

Read Data

Read Data


Speculation

Read Ctrl

Read Data


Speculative Reads

Stage 1 Stage 2 Stage 4Stage 3

Ctrl RAMUpdate

Lookup(Pipe)

write

read

Delay (2 clocks)?

write

read

Data RAMUpdate

advance (2 clocks)?


Part 3

Methodology, Futures, Summary


Verification Flow

›RTL Simulation is expensive•Licenses

•CPU time

›Post-Processing is cheap

›Stop simulations when broken•But not if bug is in test/model


Methodology

›Cycle-Precise Reference Comparison•Without a cycle-accurate model

›Verify the System First•Bringup Flow (Function Model)

•Synchronized Flow (Transaction-Testbench)

›Postpone module level testing•Use scoreboarding to identify unit testbenches

•Only build unit-testbenches for stable modules


Comparison with Platform-Based

›System-on-Chip Methodology•Verify components first

•Verify system as composition of verified units

›Complex-ASIC Methodology•Verify transactions first

•Verify units in context of verified transactions

•An “Agile” Methodology


Future Work

›Performance in non-synchronized mode•Use threading to avoid fragmentation

›Synchronization as basis of SW architecture•Cycle-model plug-in could provide synch

•Can postpone this plug-in until tapeout

›But what if we want a cycle-model earlier?•Example: up-front performance validation


Summay

›Cycle timing is a “Don’t Care”

› Initial verification uses “Functional” model•Refactor into “Transaction” model

›RTL provides cycle timing•Caches, like FIFOs, are just delay elements

•“Forces” in testbench propagate to model

›“Coarse-grain first” methodology


Questions

mailto:[email protected]

http://Dave.Whipp.name/dv

© 2003 Fast-Chip. All rights reserved. 11/23/2015 3:37:34 AM RTL-Synchronized Transaction Reference Models Dave Whipp Fast-Chip Inc.

Documents