ECE 587 Hardware/Software Co-Design Lecture 12 Verification II, System Modeling

Transcription

1 ECE 587 Hardware/Software Co-Design Spring /20 ECE 587 Hardware/Software Co-Design Lecture 12 Verification II, System Modeling Professor Jia Wang Department of Electrical and Computer Engineering Illinois Institute of Technology February 15, 2018

2 ECE 587 Hardware/Software Co-Design Spring /20 Reading Assignment This lecture: 7.3, 3.3 Next lecture: 3.4

3 ECE 587 Hardware/Software Co-Design Spring /20 Outline Model Checking System Modeling

4 ECE 587 Hardware/Software Co-Design Spring /20 Model Model refers to desired system properties (in mathematics) Safety: bad things never happen Liveness: good things eventually happen Examples for safety Two circuits always produce the same outputs with the same inputs (i.e. equivalence checking) The microwave oven will not start when the door is open. Examples for liveness A processor eventually executes an instruction. The brake is eventually applied after you hit the pedal (within a deadline)

5 ECE 587 Hardware/Software Co-Design Spring /20 Model Model refers to desired system properties (in mathematics) Safety: bad things never happen Liveness: good things eventually happen Examples for safety Two circuits always produce the same outputs with the same inputs (i.e. equivalence checking) The microwave oven will not start when the door is open. Examples for liveness A processor eventually executes an instruction. The brake is eventually applied after you hit the pedal (within a deadline)

6 ECE 587 Hardware/Software Co-Design Spring /20 Model Model refers to desired system properties (in mathematics) Safety: bad things never happen Liveness: good things eventually happen Examples for safety Two circuits always produce the same outputs with the same inputs (i.e. equivalence checking) The microwave oven will not start when the door is open. Examples for liveness A processor eventually executes an instruction. The brake is eventually applied after you hit the pedal (within a deadline)

7 Model Checking (Gajski et al.) Model checking requires to represent the system and the model to be checked in a mathematically unambiguous way. The system: FSM The model: temporal logic, a function that maps all traces of state transitions to 0 and 1 The system FSM could be the RTL implementation of the system but is usually its abstraction. Enable one to check a RTL system with more than states Model checker will generate a counter example when the property doesn t hold, helping to identify corner cases for simulation-based verification. ECE 587 Hardware/Software Co-Design Spring /20

8 Model Checking (Gajski et al.) Model checking requires to represent the system and the model to be checked in a mathematically unambiguous way. The system: FSM The model: temporal logic, a function that maps all traces of state transitions to 0 and 1 The system FSM could be the RTL implementation of the system but is usually its abstraction. Enable one to check a RTL system with more than states Model checker will generate a counter example when the property doesn t hold, helping to identify corner cases for simulation-based verification. ECE 587 Hardware/Software Co-Design Spring /20

9 Model Checking (Gajski et al.) Model checking requires to represent the system and the model to be checked in a mathematically unambiguous way. The system: FSM The model: temporal logic, a function that maps all traces of state transitions to 0 and 1 The system FSM could be the RTL implementation of the system but is usually its abstraction. Enable one to check a RTL system with more than states Model checker will generate a counter example when the property doesn t hold, helping to identify corner cases for simulation-based verification. ECE 587 Hardware/Software Co-Design Spring /20

10 ECE 587 Hardware/Software Co-Design Spring /20 Computation as a Tree (Gajski et al.) We can expand the FSM into a tree that captures all possible traces of state transitions to 0 and 1. Temporal logics are limited to certain traces on the tree.

11 ECE 587 Hardware/Software Co-Design Spring /20 Computation as a Tree (Gajski et al.) We can expand the FSM into a tree that captures all possible traces of state transitions to 0 and 1. Temporal logics are limited to certain traces on the tree.

12 ECE 587 Hardware/Software Co-Design Spring /20 Temporal Logics I (a) p always (G) holds in one future (E): liveness (b) p always (G) holds in all futures (A): safety (Gajski et al.)

13 ECE 587 Hardware/Software Co-Design Spring /20 Temporal Logics I (a) p always (G) holds in one future (E): liveness (b) p always (G) holds in all futures (A): safety (Gajski et al.)

14 ECE 587 Hardware/Software Co-Design Spring /20 Temporal Logics II (c) p holds eventually (F) in one future (E): safety (d) p holds eventually (F) in all futures (A): liveness (Gajski et al.)

15 ECE 587 Hardware/Software Co-Design Spring /20 Temporal Logics II (c) p holds eventually (F) in one future (E): safety (d) p holds eventually (F) in all futures (A): liveness (Gajski et al.)

16 ECE 587 Hardware/Software Co-Design Spring /20 Example Consider a game that the player wins if he/sha could obtain exactly 4 gallons of water using a 5 gallon jug, a 3 gallon jug, and a water faucet. All jugs start empty. Each step the player could either Empty a jug to ground. Pour water from a jug to another, until one of them is empty or full. Fill a jug full with the faucet. How to model the game and how to reason with the model?

17 ECE 587 Hardware/Software Co-Design Spring /20 Example Consider a game that the player wins if he/sha could obtain exactly 4 gallons of water using a 5 gallon jug, a 3 gallon jug, and a water faucet. All jugs start empty. Each step the player could either Empty a jug to ground. Pour water from a jug to another, until one of them is empty or full. Fill a jug full with the faucet. How to model the game and how to reason with the model?

18 ECE 587 Hardware/Software Co-Design Spring /20 Example Consider a game that the player wins if he/sha could obtain exactly 4 gallons of water using a 5 gallon jug, a 3 gallon jug, and a water faucet. All jugs start empty. Each step the player could either Empty a jug to ground. Pour water from a jug to another, until one of them is empty or full. Fill a jug full with the faucet. How to model the game and how to reason with the model?

19 ECE 587 Hardware/Software Co-Design Spring /20 Example Consider a game that the player wins if he/sha could obtain exactly 4 gallons of water using a 5 gallon jug, a 3 gallon jug, and a water faucet. All jugs start empty. Each step the player could either Empty a jug to ground. Pour water from a jug to another, until one of them is empty or full. Fill a jug full with the faucet. How to model the game and how to reason with the model?

20 ECE 587 Hardware/Software Co-Design Spring /20 Other Formal Verification Techniques Theorem proving via deductive reasoning Proofs are usually obtained interactively, i.e. designers need provide additional deduction rules for the prover if it cannot proceed further automatically. Bounded model checking Simplify model checking by bounding the lengths of traces Symbolic simulation Use symbols to increase coverage in simulation-based verification while utilizing equivalence checking for monitor

21 ECE 587 Hardware/Software Co-Design Spring /20 Other Formal Verification Techniques Theorem proving via deductive reasoning Proofs are usually obtained interactively, i.e. designers need provide additional deduction rules for the prover if it cannot proceed further automatically. Bounded model checking Simplify model checking by bounding the lengths of traces Symbolic simulation Use symbols to increase coverage in simulation-based verification while utilizing equivalence checking for monitor

22 ECE 587 Hardware/Software Co-Design Spring /20 Other Formal Verification Techniques Theorem proving via deductive reasoning Proofs are usually obtained interactively, i.e. designers need provide additional deduction rules for the prover if it cannot proceed further automatically. Bounded model checking Simplify model checking by bounding the lengths of traces Symbolic simulation Use symbols to increase coverage in simulation-based verification while utilizing equivalence checking for monitor

23 ECE 587 Hardware/Software Co-Design Spring /20 Summary of Verification Techniques (Gajski et al.)

24 ECE 587 Hardware/Software Co-Design Spring /20 Outline Model Checking System Modeling

25 ECE 587 Hardware/Software Co-Design Spring /20 System Design Challenges Input: a high-level system specification Could be functionalities only described in MoCs Output: a low-level system implementation Software: programs for the targeted instruction sets Hardware: what level? Methodologies and tools are mature for abstraction levels at and below RTL for hardware. For system design, hardware implementations stop at RTL. No single step solution for system design Semantic gap: there are multiple ways to implement a single MoC Huge semantic gap exists between specification and implementation.

26 ECE 587 Hardware/Software Co-Design Spring /20 System Design Challenges Input: a high-level system specification Could be functionalities only described in MoCs Output: a low-level system implementation Software: programs for the targeted instruction sets Hardware: what level? Methodologies and tools are mature for abstraction levels at and below RTL for hardware. For system design, hardware implementations stop at RTL. No single step solution for system design Semantic gap: there are multiple ways to implement a single MoC Huge semantic gap exists between specification and implementation.

27 ECE 587 Hardware/Software Co-Design Spring /20 System Design Challenges Input: a high-level system specification Could be functionalities only described in MoCs Output: a low-level system implementation Software: programs for the targeted instruction sets Hardware: what level? Methodologies and tools are mature for abstraction levels at and below RTL for hardware. For system design, hardware implementations stop at RTL. No single step solution for system design Semantic gap: there are multiple ways to implement a single MoC Huge semantic gap exists between specification and implementation.

28 ECE 587 Hardware/Software Co-Design Spring /20 System Design Challenges Input: a high-level system specification Could be functionalities only described in MoCs Output: a low-level system implementation Software: programs for the targeted instruction sets Hardware: what level? Methodologies and tools are mature for abstraction levels at and below RTL for hardware. For system design, hardware implementations stop at RTL. No single step solution for system design Semantic gap: there are multiple ways to implement a single MoC Huge semantic gap exists between specification and implementation.

29 ECE 587 Hardware/Software Co-Design Spring /20 System Design Process Decompose the whole system design process into a series of smaller steps. Ensure the semantic gap is small enough for a single step Each step is defined by a pair of system models. The one at higher abstraction level serves as specification. The one at lower abstraction level serves as implementation. Refinement: generate the implementation from the specification for each step Introduce additional details limited to certain scope of the specification Incorporate design decisions to choose one implementation from multiple possible ones While more tools are available for refinement, it is critical for designers to provide proper design decisions. Especially when an initial system implementation fails to meet design constraints and multiple design iterations are necessary.

30 ECE 587 Hardware/Software Co-Design Spring /20 System Design Process Decompose the whole system design process into a series of smaller steps. Ensure the semantic gap is small enough for a single step Each step is defined by a pair of system models. The one at higher abstraction level serves as specification. The one at lower abstraction level serves as implementation. Refinement: generate the implementation from the specification for each step Introduce additional details limited to certain scope of the specification Incorporate design decisions to choose one implementation from multiple possible ones While more tools are available for refinement, it is critical for designers to provide proper design decisions. Especially when an initial system implementation fails to meet design constraints and multiple design iterations are necessary.

31 ECE 587 Hardware/Software Co-Design Spring /20 System Design Process Decompose the whole system design process into a series of smaller steps. Ensure the semantic gap is small enough for a single step Each step is defined by a pair of system models. The one at higher abstraction level serves as specification. The one at lower abstraction level serves as implementation. Refinement: generate the implementation from the specification for each step Introduce additional details limited to certain scope of the specification Incorporate design decisions to choose one implementation from multiple possible ones While more tools are available for refinement, it is critical for designers to provide proper design decisions. Especially when an initial system implementation fails to meet design constraints and multiple design iterations are necessary.

32 ECE 587 Hardware/Software Co-Design Spring /20 System Design Process Decompose the whole system design process into a series of smaller steps. Ensure the semantic gap is small enough for a single step Each step is defined by a pair of system models. The one at higher abstraction level serves as specification. The one at lower abstraction level serves as implementation. Refinement: generate the implementation from the specification for each step Introduce additional details limited to certain scope of the specification Incorporate design decisions to choose one implementation from multiple possible ones While more tools are available for refinement, it is critical for designers to provide proper design decisions. Especially when an initial system implementation fails to meet design constraints and multiple design iterations are necessary.

33 ECE 587 Hardware/Software Co-Design Spring /20 Typical System Design Tool and Design Process (Gajski et al.)

34 ECE 587 Hardware/Software Co-Design Spring /20 Roles of Models The implementation of the previous design step will serve as the specification of the next one. For implementation, models allow designers to reason about design decisions by simulating and analyzing certain aspects of the system. For specification, models document system features that need to be implemented and decided. As design progresses, More details are included into the models so simulation and analysis takes more time to finish. Simulation and analysis will become more accurate due to the available details. Designers will be able to afford the increased simulation and analysis time by focusing on the most important parts of the system.

35 ECE 587 Hardware/Software Co-Design Spring /20 Roles of Models The implementation of the previous design step will serve as the specification of the next one. For implementation, models allow designers to reason about design decisions by simulating and analyzing certain aspects of the system. For specification, models document system features that need to be implemented and decided. As design progresses, More details are included into the models so simulation and analysis takes more time to finish. Simulation and analysis will become more accurate due to the available details. Designers will be able to afford the increased simulation and analysis time by focusing on the most important parts of the system.

36 ECE 587 Hardware/Software Co-Design Spring /20 Roles of Models The implementation of the previous design step will serve as the specification of the next one. For implementation, models allow designers to reason about design decisions by simulating and analyzing certain aspects of the system. For specification, models document system features that need to be implemented and decided. As design progresses, More details are included into the models so simulation and analysis takes more time to finish. Simulation and analysis will become more accurate due to the available details. Designers will be able to afford the increased simulation and analysis time by focusing on the most important parts of the system.

37 ECE 587 Hardware/Software Co-Design Spring /20 Roles of Models The implementation of the previous design step will serve as the specification of the next one. For implementation, models allow designers to reason about design decisions by simulating and analyzing certain aspects of the system. For specification, models document system features that need to be implemented and decided. As design progresses, More details are included into the models so simulation and analysis takes more time to finish. Simulation and analysis will become more accurate due to the available details. Designers will be able to afford the increased simulation and analysis time by focusing on the most important parts of the system.

38 ECE 587 Hardware/Software Co-Design Spring /20 Abstraction Levels for System Design At the highest abstraction level, we would assume the system is specified using process-based models while each process is specified using state-based models. What intermediate abstraction levels should we introduce for HW/SW implementations? Separate communication from computation Compilers will help to implement a single process as HW or SW. Communications become limiting factors for system performance. Accurate system analysis demands accurate communication modeling. The ratio of communication latency to computation latency generally increases as more transistors are packed into a chip. Complex system requires more data to be transfered among subsystems, resulting in latency with limited bandwidth and excessive power consumption.

39 ECE 587 Hardware/Software Co-Design Spring /20 Abstraction Levels for System Design At the highest abstraction level, we would assume the system is specified using process-based models while each process is specified using state-based models. What intermediate abstraction levels should we introduce for HW/SW implementations? Separate communication from computation Compilers will help to implement a single process as HW or SW. Communications become limiting factors for system performance. Accurate system analysis demands accurate communication modeling. The ratio of communication latency to computation latency generally increases as more transistors are packed into a chip. Complex system requires more data to be transfered among subsystems, resulting in latency with limited bandwidth and excessive power consumption.

40 ECE 587 Hardware/Software Co-Design Spring /20 Abstraction Levels for System Design At the highest abstraction level, we would assume the system is specified using process-based models while each process is specified using state-based models. What intermediate abstraction levels should we introduce for HW/SW implementations? Separate communication from computation Compilers will help to implement a single process as HW or SW. Communications become limiting factors for system performance. Accurate system analysis demands accurate communication modeling. The ratio of communication latency to computation latency generally increases as more transistors are packed into a chip. Complex system requires more data to be transfered among subsystems, resulting in latency with limited bandwidth and excessive power consumption.

41 ECE 587 Hardware/Software Co-Design Spring /20 Abstraction Levels for System Design At the highest abstraction level, we would assume the system is specified using process-based models while each process is specified using state-based models. What intermediate abstraction levels should we introduce for HW/SW implementations? Separate communication from computation Compilers will help to implement a single process as HW or SW. Communications become limiting factors for system performance. Accurate system analysis demands accurate communication modeling. The ratio of communication latency to computation latency generally increases as more transistors are packed into a chip. Complex system requires more data to be transfered among subsystems, resulting in latency with limited bandwidth and excessive power consumption.

42 ECE 587 Hardware/Software Co-Design Spring /20 System Design Models Cycle-Accurate Model (CAM) Both computation and communication are specified cycle-by-cycle. Model functionality in implementation Specification Model (SM) Both computation and communication are not timed. Timed Functional Model Transaction-Level Model (TLM) Both computation and communication are approximated timed Bus Cycle-Accurate Model (BCAM) Computation Cycle-Accurate Model (CCAM)

43 ECE 587 Hardware/Software Co-Design Spring /20 System Design Models Cycle-Accurate Model (CAM) Both computation and communication are specified cycle-by-cycle. Model functionality in implementation Specification Model (SM) Both computation and communication are not timed. Timed Functional Model Transaction-Level Model (TLM) Both computation and communication are approximated timed Bus Cycle-Accurate Model (BCAM) Computation Cycle-Accurate Model (CCAM)

44 ECE 587 Hardware/Software Co-Design Spring /20 System Design Models Cycle-Accurate Model (CAM) Both computation and communication are specified cycle-by-cycle. Model functionality in implementation Specification Model (SM) Both computation and communication are not timed. Timed Functional Model Transaction-Level Model (TLM) Both computation and communication are approximated timed Bus Cycle-Accurate Model (BCAM) Computation Cycle-Accurate Model (CCAM)

45 ECE 587 Hardware/Software Co-Design Spring /20 System Design Models Cycle-Accurate Model (CAM) Both computation and communication are specified cycle-by-cycle. Model functionality in implementation Specification Model (SM) Both computation and communication are not timed. Timed Functional Model Transaction-Level Model (TLM) Both computation and communication are approximated timed Bus Cycle-Accurate Model (BCAM) Computation Cycle-Accurate Model (CCAM)

46 ECE 587 Hardware/Software Co-Design Spring /20 System Design Models Cycle-Accurate Model (CAM) Both computation and communication are specified cycle-by-cycle. Model functionality in implementation Specification Model (SM) Both computation and communication are not timed. Timed Functional Model Transaction-Level Model (TLM) Both computation and communication are approximated timed Bus Cycle-Accurate Model (BCAM) Computation Cycle-Accurate Model (CCAM)

47 ECE 587 Hardware/Software Co-Design Spring /20 System Design Models Cycle-Accurate Model (CAM) Both computation and communication are specified cycle-by-cycle. Model functionality in implementation Specification Model (SM) Both computation and communication are not timed. Timed Functional Model Transaction-Level Model (TLM) Both computation and communication are approximated timed Bus Cycle-Accurate Model (BCAM) Computation Cycle-Accurate Model (CCAM)

48 ECE 587 Hardware/Software Co-Design Spring /20 System Design Methodology as Model Transformations (Gajski et al.) A design methodology is illustrated as a path from A to F. We will be interested in the one passing C.

49 ECE 587 Hardware/Software Co-Design Spring /20 System Design Methodology as Model Transformations (Gajski et al.) A design methodology is illustrated as a path from A to F. We will be interested in the one passing C.

50 ECE 587 Hardware/Software Co-Design Spring /20 Summary of System Modeling System design is decomposed into steps. A model for implementation at one step will serve for specification at the next step. System design models can be classified by how they model computation and communication. System design methodology is represented by the transformations of the system at various models.