Time Abstraction in Simulation-Based Hardware Verification

1
Time Abstraction in Simulation-Based Hardware
Verification
Summer School on Software Engineering and
Verification (SSSEV) July 17-27, Moscow, Russia

• Alexander Kamkin
• kamkin_at_ispras.ru

Institute for System Programming of the Russian
Academy of Sciences (ISPRAS) http//hardware.ispra
s.ru
2
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
• CTESK testing toolkit
• Future work
• Questions answers

3
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
  doesnt happen at once
• Albert Einstein

4
Abstraction

• Abstraction is the act of considering something
  as a general quality or characteristic, apart
  from concrete realities, specific objects, or
  actual instances
• Websters 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

5
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)

6
Inputs, outputs, and system clock
Clock
Outputs
Inputs
7
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

CLK
S
R1
R2
6 cycles
Concurrent assignments
8
Simulation-based verification
S2
Stimuli
S3
S1
Reactions
R3
Generation
R1
R2
Checking
9
Simulation-based verification tasks

• Stimuli generation
• Reaction checking
• Coverage tracking

Stimulus Generator
Reaction Checker
Coverage Tracker
10
Reaction checking
Functionality

• Number of reactions is correct
• Each reaction is correct
• Order of reactions is correct
• Time intervals between reactions are correct

Timing
11
Design modifications
Requirements are not time-accurate designs
timing constantly changes
Timing
??
Interface
Function
12
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

13
Time abstraction
S
Stimulus
Concrete event sequence S 6 R1 2 R2 Abstract
specification S R1 R2 More abstract
specifications S (( R1 R2) ( R2
R1)) S (( R1) ( R2))
R2
Reactions
Events
R1
14
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.)

15
To be continuedQuestions?
16
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
• CTESK testing toolkit
• Future work
• Questions answers

17
Time abstraction levels

• Time-accurate (cycle-accurate) models
• Time-inaccurate (time-approximate) models
• Untimed (functional) models

18
Cycle-accurate 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 lt 4 i)
• data in_data ltlt (i ltlt 3)
• delay(1)
• temp memory
• delay(1)
• memory data
• delay(1)
• val_out_data 1

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 lt
4 i) data in_data ltlt (i ltlt 3)
delay(1) temp memory
delay(1) memory data delay(1)
val_out_data 1 for(int i 0 i lt 4 i)
out_data (temp gtgt (i ltlt 3)) 0xff
delay(1) val_out_data 0
19
Modeling concurrency
Operation
Operation
Operation
delay(1)
delay(1)
delay(1)
delay(1)
Operation
delay(1)
delay(1)
delay(1)
delay(1)
delay(1)
return
delay(1)
return
Time
return
return
20
Functional (untimed) modelstime interval
abstraction
input in_ifaceltuint32_tgt output
out_ifaceltuint32_tgt void store_word()
uint32_t temp memory memory
recv(in_iface) // delay(0,??))
send(out_iface, temp)
uint32_t store_word(uint32_t data) uint32_t
temp memory memory data return temp
21
Functional (untimed) models (cont.)
input bool val_in_data input uint8_t
in_data4 output bool val_out_data output
uint8_t out_data4 void store_word()
uint32_t data 0 uint32_t temp 0
for(int i 0 i lt 4 i) data
in_datat1 ltlt (i ltlt 3) delay(1)
temp memory delay(1) memory data
delay(1) val_out_data 1 for(int i 0
i lt 4 i) out_datat2 (temp gtgt (i
ltlt 3)) 0xff delay(1)
val_out_data 0
input in_ifaceltuint32_tgt output
out_ifaceltuint32_tgt void store_word()
uint32_t data 0 uint32_t temp 0 data
recv(in_iface) temp memory memory
data send(out_iface, temp)
t1
t2
22
Functional (untimed) modelsevents ordering
abstraction

• input in_iface ltuint32_tgt
• output out_iface1ltuint32_tgt
• output out_iface2ltuint32_tgt
• void store_word()
• uint32_t temp memory
• memory recv(in_iface)
• // Order of events is undefined
• send(out_iface1, temp)
• send(out_iface2, memory)

23
Time-approximate models
input in_ifaceltuint32_tgt output
out_ifaceltuint32_t, FIFOgt // 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(01)1,
Timeout(3-0)(4-1)6 send(out_iface, temp)
24
Transaction-level modeling (TLM)

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

TLM is data transmission encapsulation
Wires/pins
Channels/interfaces
Discrete signals distributed in time
Untimed data package (message)
25
25
Model interface adapters
Input interface 1
Output interface 1
Target Design (HDL Model)
input in_ifaceltuint32_tgt output
out_ifaceltuint32_tgt void store_word()
uint32_t temp memory memory
recv(in_iface) ... send(out_iface,
temp)
Input interface N
Output interface M
Reaction Checker
Input Interface Adapters (Serializers)
Output Interface Adapters (Deserializers)
Reference Model (TLM)
26
Problems caused by time abstraction

• Design state uncontrollability
• DesignModel is not deterministic
• ? Problems in stimulus generation coverage
  tracking
• Reaction order ambiguity
• Order of reactions is unpredictable
• ? Problems in reaction checking

27
Design state uncontrollability
Designs Inputs/Outputs
S
R1
R2
Designs State
Uncontrollable actions
Models State
PreImpl(S)false
S
PreImpl(S)true
S
Nondeterministic behavior
28
Reaction order ambiguity
Model Execution Trace
recv(in_iface, S)
...
Output Interfaces Queue
send(out_iface, R1)
Failed R2 ? R1
...
R1
R2
Passed R2 ? Queue
send(out_iface, R2)
Designs Inputs/Outputs
S
R2
R1
Different order
29
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
• CTESK testing toolkit
• Future work
• Questions answers

30
To be continuedQuestions?
31
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

32
Model-based reaction checker
Target Design
Reaction Checker
Reference Model
Models Reactions
Reaction Arbiters
Input Interface Adapters
Output Interface Adapters
Stimuli
Reaction Comparators
Designs Reactions
Verdict
33
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

34
Deterministic model-based arbiter
S
R
Models Reactions
send(R1)
Order is defined
...
R1
R2
Reaction Arbiter
send(R2)
FIFO
Designs Reactions
R1
R2
R1
Comparison
35
Adaptive arbiter
S
R
Models Reactions
send(R1)
R1
Order is undefined
...
Reaction Arbiter
send(R2)
R2
Get(R1)
Designs Reactions
R1
R2
R1
Comparison
Feedback
36
Two-level arbiter
S
R
Models Reactions
send(R1)
R1
Order is partially defined
Candidates
...
Arbiter 1
send(R2)
R2
Arbiter 2
Get(R1)
Designs Reactions
R1
R2
R1
Comparison
Feedback
37
Reaction checking algorithm

• On model reaction R on interface out
• Reactionsout Reactionsout ? R
• wind(TimerR)
• On model reactions time-out
• return Missing reaction
• On designs reaction R on interface out
• Candidateout Reactionsout
• if(Candidateout ?? 2)
• Candidateout
  Arbiter1out(Reactionsout)
• if(Cadidatesout ? 2)
• Candidatesout
  Arbiter2out(Reactionsout, R)
• assert(Cadidatesout lt 2)
• if(Cadidatesout ??)

38
Simple error classification

• Missing reaction
• The reference model generates a reaction, but
  the designs 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

39
Classification of abstraction levels

• ? Cycle-accurate models
• G (?out?? Reactionsout lt 2)
• Cycle-accurate models (Time(R) 0)
• Quasi cycle-accurate models (otherwise)
• ? Order-accurate models
• G (?out?? Reactionsout lt 2 ?
  Arbiter1out(Reactionsout) lt 2)
• Order-accurate models (Arbiter1out FIFO)
• Quasi order-accurate models (otherwise)
• Order-inaccurate models
• otherwise

40
Error diagnosis problem
0xf953e8d83a9b9209 ? 0x19c3827ab2920e58
0x19c3827ab2920e58 ? 0xf953e8d83a9b9209
41
Error diagnosis approach
??,??
??,??
??,?
??,??
??,??
??,??
??,??
??,??
??,??
??,??
??,??
??,??
??,?
?,?
??,??
??,??
??,??
??,??
??,??
??,??
?,?
42
Control errors model

• ??,?? ?
• ??,?? ? ??,??
• ??,?? ??,?? ? ??,?? ??,??
• ??,? ??,?? ? ??,?? ??,?
• ??,?? ??,?? ? ??,?? ??,??
• ??,?? ??,?? ? ??,?? ??,??
• ??,?? ??,?? ? ??,?? ??,??

43
Functional errors model

• ??,?? ? ??,??
• ??,? ??,?? ? ??,?? ??,?
• ??,?? ??,?? ? ??,?? ??,??
• ??,? ??,?? ? ??,?? ??,?
• ??,?? ??,?? ? ??,?? ??,??

44
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
• CTESK testing toolkit
• Future work
• Questions answers

45
CTESK 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

46
CTESK testing toolkit (cont.)
Web http//forge.ispras.ru/projects/cpptesk-to
olkit E-mail cpptesk-support_at_ispras.ru
47
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.)

48
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?i1,n) ? diagnosis

49
Contacts

• Institute for System Programming of RAS
  (ISPRAS)http//www.ispras.ru
• Hardware Verification RD _at_ ISPRAShttp//hardware
  .ispras.ru
• Alexander Kamkinkamkin_at_ispras.ru

50
The EndThank you! Questions?