Time Abstraction in Simulation-Based Hardware Verification

Time Abstraction in Simulation-Based Hardware Verification

Alexander [email protected]

Institute for System Programming of the Russian Academy of Sciences (ISPRAS)http://hardware.ispras.ru

Summer School on Software Engineering and Verification (SSSEV)July 17-27, Moscow, Russia

Summer School on Software Engineering and Verification (SSSEV) - July 17-27, 2011 - Moscow, Russia 2 of 50

Time Abstraction in Simulation-Based Hardware VerificationAlexander Kamkin

Agenda Introduction

Digital hardware design Simulation-based verification Time abstraction in hardware modeling

Main part Time abstraction levels Model-based reaction checking Error diagnostics

Conclusion C++TESK testing toolkit Future work Questions & answers



Time

Time is a part of measuring system used to sequence events, to compare the durations of events and the intervals between them…

Wikipedia

The only reason for time is so that everything doesn’t happen at once

Albert Einstein



Abstraction

Abstraction is the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances

Webster’s Dictionary

Abstraction captures only those details about an object that are relevant to the current perspective

Wikipedia

Time abstraction is (1) generalization of events ordering relationship and (2) factorization of time intervals between them

This Presentation



Hardware design in a nutshell

Hardware is designed using hardware description languages (HDL), like Verilog and VHDL

The result is a software model that can be executed in an HDL simulator

The main approach to verify a design is to test the HDL model (simulation-based verification)

To automate simulation-based verification, reference models are used (C/C++)



Inputs, outputs, and system clock

Inputs Outputs

ClockClock



Hardware description language (HDL)input S;output R1, R2;void design() { while(true) { wait(S); delay(6); R1 = 1; delay(1); R1 = 0; delay(1); R2 = 1; delay(1); R2 = 0; V1 = 1;}}

CLKS

R1

6 cycles

R2

Concurrent assignments



Simulation-based verification

S2

R1 R2

Stimuli

Reactions

S3S1

R3Generation

Checking



Stimuli generation

Reaction checking

Coverage tracking

Simulation-based verification tasks

Coverage Tracker

Reaction Checker

Stimulus Generator

StimulusGenerator

TargetDesign

ReactionChecker

TestCoverage



Reaction checking

Number of reactions is correct

Each reaction is correct

Order of reactions is correct

Time intervals between reactions are correct

Timing

Functionality



Design modifications

Timing

Interface

Function

Requirements are not time-accurate;design’s timing constantly changes



Model abstraction

Abstract models are easier to develop and to maintain

Abstract models are more stable (reusable)

Abstract models are less error-prone

Abstract models provide lower verification quality

Abstract models are less deterministic and predictable

+++



Time abstraction

S

R1

R2

Stimulus

ReactionsEvents

Concrete event sequence S #6 R1 #2 R2

Abstract specificationS #+ R1 #* R2

More abstract specificationsS ((#+ R1 #* R2) | (#+ R2 #* R1))S ((#+ R1) || (#+ R2))

S

R1

R2

#

R2S

R1

R2

#

S

R1

R2

#

S

R1

R2

#

S

R1

R2

#

S

#

R1 R2

#

SR1

R2

#

#



Time abstraction in practice

Hardware design modeling

Development of reference models at different abstraction levels (specification of time properties)

Change of abstraction level (refinement of time properties)

Reference model adaptation

Adaptation of abstract (untimed) reference models for co-simulation in a time environment

Tuning time properties being checked without changing a reference model (reaction arbitration, etc.)



To be continued…Questions?



Agenda Introduction






Time abstraction levels

Time-accurate (cycle-accurate) models

…

Time-inaccurate (time-approximate) models

…

Untimed (functional) models



input bool val_in_data;input uint8_t in_data;output bool val_out_data;output uint8_t out_data;

void store_word() { uint32_t data = 0; uint32_t temp = 0; while(true) { wait(val_in_data); for(int i = 0; i < 4; i++) { data |= in_data << (i << 3); delay(1); } temp = memory; delay(1); memory = data; delay(1); val_out_data = 1; for(int i = 0; i < 4; i++) { out_data = (temp >> (i << 3)) & 0xff; delay(1); } val_out_data = 0;}}

input bool val_in_data;input uint8_t in_data;output bool val_out_data;output uint8_t out_data;

void store_word() { uint32_t data = 0; uint32_t temp = 0; for(int i = 0; i < 4; i++) { data |= in_data << (i << 3); delay(1); }

temp = memory; delay(1); memory = data; delay(1);

val_out_data = 1; for(int i = 0; i < 4; i++) { out_data = (temp >> (i << 3)) & 0xff; delay(1); } val_out_data = 0;}

Cycle-accurate models



Modeling concurrency

Tim

e

delay(1)

Operation

delay(1)

delay(1)

return

Operation

delay(1)

return

delay(1)

Operation

delay(1)

delay(1)

return

delay(1)

delay(1)

return

delay(1)

Operation



uint32_t store_word(uint32_t data) { uint32_t temp = memory; memory = data; return temp}

Functional (untimed) models:time interval abstraction

input in_iface<uint32_t>;output out_iface<uint32_t>;

void store_word() { uint32_t temp = memory; memory = recv(in_iface); // delay([0,)) = #* send(out_iface, temp);}



input bool val_in_data[ ];input uint8_t in_data[4];output bool val_out_data[ ];output uint8_t out_data[4];

void store_word() { uint32_t data = 0; uint32_t temp = 0; for(int i = 0; i < 4; i++) { data |= in_data[t1] << (i << 3); delay(1); }

temp = memory; delay(1); memory = data; delay(1);

val_out_data = 1; for(int i = 0; i < 4; i++) { out_data[t2] = (temp >> (i << 3)) & 0xff; delay(1); } val_out_data = 0;}

Functional (untimed) models (cont.)

t1++

t2++

input in_iface<uint32_t>;

output out_iface<uint32_t>;

void store_word() { uint32_t data = 0; uint32_t temp = 0;

data = recv(in_iface);

temp = memory;

memory = data;

send(out_iface, temp);

}



Functional (untimed) models:events ordering abstractioninput in_iface <uint32_t>;output out_iface1<uint32_t>;output out_iface2<uint32_t>;

void store_word() { uint32_t temp = memory; memory = recv(in_iface); // Order of events is undefined send(out_iface1, temp); send(out_iface2, memory);}



Time-approximate models

input in_iface<uint32_t>;output out_iface<uint32_t, FIFO>; // Reactions ordering

void store_word() { uint32_t data = 0; uint32_t temp = 0;

data = recv(in_iface, in_data);

temp = memory; delay([0, 3]); // Delays are approximate memory = data; delay([1, 4]); // Delay=(0+1)=1, Timeout=(3-0)+(4-1)=6 send(out_iface, temp); }



Transaction-level modeling (TLM)

TLM is a hardware modeling approach that separates communication among design units from the functional description of those units

Discrete signals distributed in time

Data Data

Wires/pins

Package

Data Data

Channels/interfaces

Untimed data package (message)

TLM is data transmission encapsulation



25

Model interface adapters

Target Design(HDL Model)

Input interface #1

Input interface #N

Data

Data Data

Data Data

Data Data

Output interface #1

Output interface #M

Reaction CheckerInput Interface Adapters

(Serializers)Output Interface Adapters

(Deserializers)Reference Model (TLM)

input in_iface<uint32_t>;output out_iface<uint32_t>;

void store_word() { uint32_t temp = memory; memory = recv(in_iface); ... send(out_iface, temp);}



Problems caused by time abstraction

Design state uncontrollability

Design|Model is not deterministic

Problems in stimulus generation & coverage tracking

Reaction order ambiguity

Order of reactions is unpredictable

Problems in reaction checking



Design state uncontrollability

SR1 R2

Design’s Inputs/Outputs

Model’s State

S’S’

Nondeterministic behavior

Design’s State Uncontrollable actions

PreImpl(S’)=false

PreImpl(S’)=true



Reaction order ambiguity

SR2 R1

Design’s Inputs/Outputs

recv(in_iface, S);

Model Execution Trace

send(out_iface, R1);

send(out_iface, R2);

...

...Failed: R2 R1

Different order

Output Interface’s Queue

R1R2Passed: R2 Queue



Agenda Introduction






To be continued…Questions?



Reaction arbitration

Reaction arbiter finds a model reaction corresponding to a reaction received from the target design

Reaction checking accuracy depends not only on the model abstractness, but on reaction arbitration as well

Each output interface has its own reaction arbiter

Reaction arbiters encapsulates all reaction ordering aspects of the reaction checker



Model-based reaction checker

TargetDesign

Reaction Checker

ReactionComparators

ReferenceModel

ReactionArbiters

Inp

ut

Inte

rfa

ce A

da

pte

rs

Ou

tpu

t Inte

rface

Ad

ap

ters

Stimuli

Design’sReactions

Model’sReactions

Verdict



Reaction arbiter types Deterministic model-based arbiters

arbiter: 2Reaction Reaction {fail}

Adaptive arbiters

arbiter: 2Reaction Feedback Reaction {fail}

Two-level arbiters

arbiter(reactions) arbiter2(arbiter1(reactions), feedback)

Nondeterministic model-based arbiter

arbiter1: 2Reaction 2Reaction : arbiter1(reactions) reactions

Adaptive arbiter

arbiter2: 2Reaction Feedback Reaction {fail}



Deterministic model-based arbiter

R1

Design’s Reactions

Model’s Reactions

send(R1);

send(R2);

... R1R2

ReactionArbiter

R1

R2

FIFO

✕ Comparison

S R

Order is defined



Adaptive arbiter

R1


Model’s Reactions

send(R1);

send(R2);

...

R1

R2 ReactionArbiter

R1

R2

✕

Get(R1)

Comparison

S R

Order is undefined

Feedback



Two-level arbiter

R1


Model’s Reactions

send(R1);

send(R2);

...

R1

R2Arbiter

#1

R1

R2

✕

Get(R1)

Comparison

S R

Order is partially defined

Arbiter#2

Feedback

Candidates



Reaction checking algorithmOn model reaction R on interface out:

Reactionsout := Reactionsout {R} wind(TimerR)

On model reaction’s time-out:

return “Missing reaction”

On design’s reaction R’ on interface out:

Candidateout := Reactionsout

if(|Candidateout| 2) { Candidateout := Arbiter1

out(Reactionsout) if(|Cadidatesout| 2) Candidatesout := Arbiter2

out(Reactionsout, R’); } assert(|Cadidatesout| < 2) if(Cadidatesout = ) return “Unexpected reaction” if(R’ get(Candidatesout))) return “Incorrect reaction”



Simple error classification

“Missing reaction”

The reference model generates a reaction, but the design’s reaction is not appeared in time

“Unexpected reaction”

The target design produces a reaction, but it is not expected by the reference model

“Incorrect reaction”Both the reference model and the target design generate reactions, but those reactions are different



Classification of abstraction levels

Cycle-accurate modelsG (out |Reactionsout| < 2)

Cycle-accurate models (Time(R) = 0) Quasi cycle-accurate models (otherwise)

Order-accurate models

G (out |Reactionsout| < 2 |Arbiter1out(Reactionsout)| < 2)

Order-accurate models (Arbiter1out = FIFO)

Quasi order-accurate models (otherwise)

Order-inaccurate models

otherwise



Error diagnosis problem

0x19c3827ab2920e58 0xf953e8d83a9b9209

0xf953e8d83a9b9209 0x19c3827ab2920e58



Error diagnosis approach

●,○

○,

○,○

○,●

○,●,● ,□

●,○

,○

□,○

○,○

●,●

●,●

●,■

○,■

■,■

□,□

□,□

■,■

○,●●,○



Control errors model

, = ○,○ , ○,● + ●,○ ○,○ + ●,● ○,■ + ●,○ ○,○ + ●,■ ○, + ,○ ○,○ + , ○,● + ●, ○, + ●,● ○,● + ,○ ,● + ○,○



Functional errors model

○,□ ○,○ ○,■ + ●,□ ○,□ + ●,■ ○, + ,□ ○,□ + , ○,■ + ●, ○, + ●,■ ○,● + ,□ ,● + ○,□



Agenda Introduction






C++TESK testing toolkit

Development of hardware models at different abstraction levels and model adapters

Description of test coverage and test scenarios

Report generation (coverage and errors)

Automated test sequence generation based on state graph exploration

Test execution parallelization based on distributed state graph exploration



C++TESK testing toolkit (cont.)Web: http://forge.ispras.ru/projects/cpptesk-toolkitE-mail: [email protected]



Conclusion

Time abstraction hides control logic (timing) of a design (pipelining, arbitration, queuing, etc.)

Time-abstract models are easier to develop and sufficiently easier to maintain (timing is changeable)

Time-abstract models reduce verification efforts and allow creating reusable tests (quality is reduced also)

Verification quality can be increased by refining time properties of a model (events ordering, durations, etc.)



Conclusion (cont.) Interface transformation

serialization(S): S inputs deserialization(R’): outputs R’

Reaction queuing send(R) is asynchronous: enqueue(R)

Reaction arbitration arbiter1(queue) candidates

arbiter2(candidates, R’) R R, R’

Reaction comparison compare(R, R’) status

Error diagnosis diagnose({Ri, Ri’}i=1,n) diagnosis



Contacts Institute for System Programming of RAS (ISPRAS)

http://www.ispras.ru

Hardware Verification R&D @ ISPRAShttp://hardware.ispras.ru

Alexander [email protected]



The EndThank you! Questions?

Documents

Time Abstraction in Simulation-Based Hardware Verification