Transcript Formal Performance Evaluation of AMBA-based System-on-Chip Designs Gabor Madl1, Sudeep Pasricha1, Qiang Zhu2, Luis Angel D.

Formal Performance Evaluation of
AMBA-based System-on-Chip
Designs
Gabor Madl1, Sudeep Pasricha1, Qiang Zhu2,
Luis Angel D. Bathen1, Nikil Dutt1*
1
1{gabe,
Center for Embedded Computer Systems, UC Irvine
2 Fujitsu Laboratories Limited
sudeep, lbathen, dutt}@ics.uci.edu, [email protected]
*This research was partially supported by a CPCC Fellowship
Emsoft 2006
http://www.cecs.uci.edu
November 6, 2015
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Outline
» Motivation
» Model-based evaluation of SoCs
» Formal modeling of SoCs using the AMBA AHB bus
» Functional verification of AMBA-based SoC designs
» Case study: Digital camera SoC
» Performance evaluation of AMBA-based SoC designs
» Simulation-based performance evaluation
» Model checking-based performance evaluation
» Conclusion
http://www.cecs.uci.edu
November 6, 2015
2
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Challenges in Bus Protocol Specs
» Bus protocols have to implement complex methods for
component interactions
» Increasing number of (often contradictory) constraints
» There is a trend to propagate the management of bus
constraints to the SoC designer
» Bus protocols have a critical role in providing a reliable
SoC platform
» Specifications are written as a combination of natural
languages and timing diagrams
» Effective way to explain the use of the protocol to SoC designers
» Cannot cover every possible use case
» Introduces ambiguity in the specification
http://www.cecs.uci.edu
November 6, 2015
3
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
The Need for Functional Verification
» SoC designers have to use the specification as a guide to
satisfy constraints in their design
» Which constraints are missing or implied from the specification?
» Different vendors may implement ambiguous specifications
differently
» The interoperability of such IP blocks may be at risk
» Simulations and test vectors are widely used to evaluate
SoC designs
» It can only show the presence of errors, not their absence
» Time consuming, limiting the analysis to a few test cases
» There is a need to verify the functionality of SoC designs
even when well-known protocols have been used
http://www.cecs.uci.edu
November 6, 2015
4
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Formal Methods for SoC Evaluation
» Simulations can accurately model some execution traces
of a design
» Did I consider all the interesting execution traces?
» Formal methods can capture all execution traces of a
design with some accuracy
» More abstract representation than for simulations
» How accurate are my results? How do I obtain parameters for the
design?
» Combine simulations & formal methods to achieve best
coverage and performance
» Provides for the best coverage possible with the highest accuracy
for a given time frame
http://www.cecs.uci.edu
November 6, 2015
5
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Model-based Verification
Design
feedback
Design
feedback
Domain Specific Model
Semantic
Analysis
Domain
mapping
Formal
Model
Input
Functional
Verification
Simulation
Model
Parameters
Perf.
Evaluation
Simulations
Property Verification
http://www.cecs.uci.edu
November 6, 2015
6
Outline
Motivation
Formal modeling
Functionality
Case study
Formal Modeling of AMBA AHB
» Finite state machines – NuSMV tool
» Cycle-accurate bus model
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» Arbitration delays
» Pipelining
» Busy slaves
» SPLIT and RETRY transfers – for functional verification only
» 2-cycle response times for RETRY and SPLIT responses
» We model AMBA masters using 6 states (idle, busreq,
haddr, read, write, error)
» We model slaves using 4 states (idle, write, read, error)
» Round-robin arbiter (specific to AMBA)
http://www.cecs.uci.edu
November 6, 2015
7
Outline
Motivation
Formal modeling
Functionality
Case study
Model of an AMBA Slave
MODULE slave (HADDR, HTRANS, HWDATA, HRDATA, HREADY, HRESP,
HMASTER, HSPLIT, MASK_MASTER1, MASK_MASTER2, MASK_MASTER3,
SLAVE_STATE)
VAR
state : {idle, write, read, error};
prev state : {idle, write, read, error};
extended : boolean;
ASSIGN
init (state) := idle;
init (prev_state) := state;
init (extended) := 0;
next (prev_state) := state;
next (state) :=
case
SLAVE_STATE != x : SLAVE_STATE;
HRESP = SPLIT : idle;
!HREADY : state;
HTRANS = BUSY : state;
HRESP = RETRY : prev state;
state = idle & HTRANS = NONSEQ & HADDR : write;
state = idle : state;
state = write & HTRANS = NONSEQ : read;
state = read & HTRANS = NONSEQ & HWDATA : idle;
1 : error;
esac;
...
http://www.cecs.uci.edu
November 6, 2015
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
8
Outline
Motivation
Formal modeling
Functionality
Case study
Model of an AMBA Slave
MODULE slave (HADDR, HTRANS, HWDATA, HRDATA, HREADY, HRESP,
HMASTER, HSPLIT, MASK_MASTER1, MASK_MASTER2, MASK_MASTER3,
SLAVE_STATE)
VAR
state : {idle, write, read, error};
prev state : {idle, write, read, error};
extended : boolean;
ASSIGN
init (state) := idle;
init (prev_state) := state;
init (extended) := 0;
next (prev_state) := state;
next (state) :=
case
SLAVE_STATE != x : SLAVE_STATE;
HRESP = SPLIT : idle;
!HREADY : state;
HTRANS = BUSY : state;
HRESP = RETRY : prev state;
state = idle & HTRANS = NONSEQ & HADDR : write;
state = idle : state;
state = write & HTRANS = NONSEQ : read;
state = read & HTRANS = NONSEQ & HWDATA : idle;
1 : error;
esac;
...
http://www.cecs.uci.edu
November 6, 2015
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
9
Outline
Motivation
Formal modeling
Functionality
Case study
Model of an AMBA Slave
MODULE slave (HADDR, HTRANS, HWDATA, HRDATA, HREADY, HRESP,
HMASTER, HSPLIT, MASK_MASTER1, MASK_MASTER2, MASK_MASTER3,
SLAVE_STATE)
VAR
state : {idle, write, read, error};
prev state : {idle, write, read, error};
extended : boolean;
ASSIGN
init (state) := idle;
init (prev_state) := state;
init (extended) := 0;
next (prev_state) := state;
next (state) :=
case
SLAVE_STATE != x : SLAVE_STATE;
HRESP = SPLIT : idle;
!HREADY : state;
HTRANS = BUSY : state;
HRESP = RETRY : prev state;
state = idle & HTRANS = NONSEQ & HADDR : write;
state = idle : state;
state = write & HTRANS = NONSEQ : read;
state = read & HTRANS = NONSEQ & HWDATA : idle;
1 : error;
esac;
...
http://www.cecs.uci.edu
November 6, 2015
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
10
Outline
Motivation
Formal modeling
Functionality
Case study
Model of an AMBA Slave
MODULE slave (HADDR, HTRANS, HWDATA, HRDATA, HREADY, HRESP,
HMASTER, HSPLIT, MASK_MASTER1, MASK_MASTER2, MASK_MASTER3,
SLAVE_STATE)
VAR
state : {idle, write, read, error};
prev state : {idle, write, read, error};
extended : boolean;
ASSIGN
init (state) := idle;
init (prev_state) := state;
init (extended) := 0;
next (prev_state) := state;
next (state) :=
case
SLAVE
STATE != x : SLAVE
STATE;
SLAVE_STATE
SLAVE_STATE;
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
HRESP = SPLIT : idle;
!HREADY : state;
HTRANS = BUSY : state;
HRESP = RETRY : prev state;
state = idle & HTRANS = NONSEQ & HADDR : write;
state = idle : state;
state = write & HTRANS = NONSEQ : read;
state = read & HTRANS = NONSEQ & HWDATA : idle;
1 : error;
esac;
...
http://www.cecs.uci.edu
November 6, 2015
11
Outline
Motivation
Formal modeling
Functionality
Case study
Model of an AMBA Slave
MODULE slave (HADDR, HTRANS, HWDATA, HRDATA, HREADY, HRESP,
HMASTER, HSPLIT, MASK_MASTER1, MASK_MASTER2, MASK_MASTER3,
SLAVE_STATE)
VAR
state : {idle, write, read, error};
prev state : {idle, write, read, error};
extended : boolean;
ASSIGN
init (state) := idle;
init (prev_state) := state;
init (extended) := 0;
next (prev_state) := state;
next (state) :=
case
SLAVE_STATE != x : SLAVE_STATE;
HRESP = SPLIT : idle;
!HREADY : state;
HTRANS = BUSY : state;
HRESP = RETRY : prev state;
state = idle & HTRANS = NONSEQ & HADDR : write;
state = idle : state;
state = write & HTRANS = NONSEQ : read;
state = read & HTRANS = NONSEQ & HWDATA : idle;
1 : error;
esac;
...
http://www.cecs.uci.edu
November 6, 2015
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
12
Outline
Motivation
Formal modeling
Functionality
Case study
Functional Verification
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
» The formal verification of the AMBA AHB
protocol
has been addressed by many
researchers
previously
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» The formal models used for the analysis were manually extracted
from the specification – the correctness of these models have been
shown, not the protocol itself
» No inconsistencies found in the final version of the protocol
» Unspecified parts of the specification may have been manually
resolved by the researchers
» Can unspecified/ambiguous parts of the specification cause
problems?
» We have found an ambiguity in the specification that may
lead to flawed implementations (deadlocks)
http://www.cecs.uci.edu
November 6, 2015
13
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Ambiguity in AMBA Specification
Conclusion
Design
feedback
» Slave can unmask master by issuing HSPLITx
» What happens if slave also asserts RETRY?
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» The specification is ambiguous: “A slave which issues
RETRY responses must only be accessed by one master at
a time”
» Is splitting an access? Can a slave issue RETRY if it can split?
» HSPLITx may be lost in some implementations
» No acknowledgement
Masked
» Slave thinks master is unmasked
» Arbiter is waiting for unmask req.
RETRY
Communication
HSPLIT3
(unmask Master3)
http://www.cecs.uci.edu
November 6, 2015
14
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
How to be Careful?
Conclusion
Design
feedback
» The specification warns that “both the SPLIT
and RETRY transfer responses must be used
with care to prevent bus deadlock”
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» AMBA AHB does allow bus deadlocks in some cases
» It is up to the designer to ensure functional correctness
» How to be a “careful designer”?
» Most often evaluated using simulations – imperfect
» Experience – expensive
» Formal methods – time consuming, difficult
» Functionality of SoC designs needs to be verified
» Tools and modeling languages are needed that help in the
application of functional verification to SoC designs
http://www.cecs.uci.edu
November 6, 2015
15
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Can we resolve the ambiguity?
» We have assumed that HRESP = RETRY and
HSPLITx does not occur simultaneously
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» We introduced formulas that evaluate to true infinitely often
» HREADY, HRESP = OK, HSPLIT = masterx
» Using these assumptions we could prove
» There are no deadlocks in the system – no states with no
transitions enabled
» There are no livelocks in the system – no states from which only a
subset of states is reachable that cannot provide the necessary
functionality of the system
http://www.cecs.uci.edu
November 6, 2015
16
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Case Study – JPEG 2000 Encoder
» Distributed compression method – works on tiles
» Convert tile pixels from unsigned integers to two’s complements
» RGB  YUV or RGB  YCbCr transformation
» DWT generates four sub-bands (computation int. – HW)
» Quantization when lossy compression is used
» EBCOT: Tier–1 (computation int. – HW), Tier–2 (control int. – CPU)
http://www.cecs.uci.edu
November 6, 2015
17
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Case Study – SoC Architecture
http://www.cecs.uci.edu
November 6, 2015
18
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Case Study – Simulation Framework
» Implemented the model in SystemC
» Cycle-accurate at the transaction level, functional blocks
are cycle-approximate
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» Each component is declared as SC_MODULE
» Each SC_MODULE may have several threads (SC_THREAD)
» There are 42 threads altogether in our implementation – verification
using the SystemC model is practically not feasible
http://www.cecs.uci.edu
November 6, 2015
19
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Simulation Results 1/2
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
» Simulation results for JPEG encoding using
64x64 pixel tiles. Scale: cycles
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
DWT
Tier-1
Image
DWT
ET
Tier-1
BCET
Tier-1
WCET
Tier-2 ET
Input
Output
End-to-end
WC
baboon
194 188
517 005
741 519
9 122 240
12 288
11 099
10 335 043
boat
194 188
165 141
737 046
8 750 875
12 288
10 046
10 044 857
goddesses
194 188
513 846
772 461
8 663 630
12 288
11 456
9 996 487
goldhill
194 188
242 055
747 954
8 672 436
12 288
10 376
9 978 464
lena
194 188
461 601
769 239
8 689 815
12 288
11 979
10 024 198
Simulation
Model
Simulations
Tier-2
http://www.cecs.uci.edu
November 6, 2015
20
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Simulation Results 2/2
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
» Simulation results for JPEG encoding using
128x128 pixel tiles. Scale: cycles
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
DWT
Tier-1
Image
DWT
ET
Tier-1
BCET
Tier-1
WCET
Tier-2 ET
Input
Output
End-to-end
WC
baboon
751 393
2 315 254
3 151 948
9 010 373
49 152
36 537
14 290 609
boat
751 393
1 764 568
3 086 892
8 758 372
49 152
41 719
13 990 027
goddesses
751 393
1 843 190
3 219 664
9 451 990
49 152
42 391
14 823 509
goldhill
751 393
2 325 098
3 173 076
8 768 459
49 152
41 645
14 090 307
lena
751 393
2 364 360
3 241 400
8 793 070
49 152
37 578
14 172 351
Simulation
Model
Simulations
Tier-2
http://www.cecs.uci.edu
November 6, 2015
21
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Model-based Performance Evaluation
Design
feedback
Design
feedback
Domain Specific Model
Semantic
Analysis
Domain
mapping
Formal
Model
Input
Functional
Verification
Property Verification
http://www.cecs.uci.edu
Simulation
Model
Parameters
Perf.
Evaluation
Exhaustive state
space search on the
formal models using
the annotations
November 6, 2015
Simulations
Abstract out best case
and worst case timing
information for each
component
22
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Information from Simulations
[bcet, wcet]
[bcet, wcet]
Size of
messages sent
through the bus
[bcet, wcet]
Accurate formal bus & communication model
[bcet, wcet]
http://www.cecs.uci.edu
November 6, 2015
23
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Formal Performance Evaluation
» The model checker performs an exhaustive
state space search using the parameters
obtained by simulations
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» Computations are abstracted out, but the timing
information used as parameters is as accurate as the
simulations
» All the valid execution traces of the model are considered
for the analysis, if a property is violated a counter-example
can be obtained
» The analysis may be fully automated & driven by the
domain-specific model
http://www.cecs.uci.edu
November 6, 2015
24
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Formal Performance Evaluation
» We use the formal models developed for the
functional verification to evaluate the worst
case end-to-end performance of the SoC
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
Simulation
Model
Simulations
» We make several assumptions for performance analysis
» No communication errors, no unexpected delays
» Forced execution order using signals/interrupts
» Several restrictions are forced by the model checkers
» Yes/no questions, truncating parameters – decreased accuracy
» More flexible model checkers are needed for practical application
» Several manual changes in the FSM models
» Manually removed several (unused) transitions from the models
» Goal is to increase the model checking scalability
http://www.cecs.uci.edu
November 6, 2015
25
Outline
Motivation
Formal modeling
Functionality
Case study
Formal Performance Evaluation
» Worst case bounds on the end-to-end
computation time of the digital camera
SoC obtained using model checking.
Scale: cycles
Tile size
Performance
Conclusion
Design
feedback
Design
feedback
Domain-specific Model
Semantic
Analysis
Domain
mapping
Formal Model
Functional
Verification
Perf.
Evaluation
WCET
WCET
(by simulation)
(by model checking)
64 × 64 pixel tiles
10 335 043
11 000 000
128 × 128 pixel tiles
14 823 509
17 000 000
http://www.cecs.uci.edu
November 6, 2015
Simulation
Model
Simulations
26
Outline
Motivation
Formal modeling
Functionality
Case study
Performance
Conclusion
Conclusion
» We have presented a systematic formal method to
evaluate AMBA-based SoC designs
» Formal model of AMBA AHB bus using SMV
» Functional verification method to find ambiguities from
AHB specification which may cause flawed SoC designs,
and propose a way to resolve these issues
» Apply formal methods for performance evaluation
» The proposed method can guarantee worst case end-toend execution times of AMBA-based SoCs
» The described method may be fully automated
» Improvements are needed in model checkers to allow easier use
and simulations as well
http://www.cecs.uci.edu
November 6, 2015
27
Questions?
» The NuSMV AMBA models are available for download at
http://alderis.ics.uci.edu/amba2
http://www.cecs.uci.edu
November 6, 2015
28