ECE 587 Hardware/Software Co-Design Lecture 11 Verification I
|
|
- Candice James
- 6 years ago
- Views:
Transcription
1 ECE 587 Hardware/Software Co-Design Spring /23 ECE 587 Hardware/Software Co-Design Lecture 11 Verification I Professor Jia Wang Department of Electrical and Computer Engineering Illinois Institute of Technology February 13, 2018
2 ECE 587 Hardware/Software Co-Design Spring /23 Reading Assignment This lecture: Next lecture: 7.3
3 ECE 587 Hardware/Software Co-Design Spring /23 Outline Verification Simulation Based Methods Equivalence Checking
4 ECE 587 Hardware/Software Co-Design Spring /23 Functional Verification Analysis and reasoning on a computer model of the system Before manufacturing Establish confidence in functional correctness before the product is shipped Critical for systems where safety is the first concern Prevent costly recall for non-critical systems as well Designers need to make sure the model at each step of design does reflect the original intent. Catch bugs as early as they are introduced so one can locate them effectively
5 ECE 587 Hardware/Software Co-Design Spring /23 Functional Verification Analysis and reasoning on a computer model of the system Before manufacturing Establish confidence in functional correctness before the product is shipped Critical for systems where safety is the first concern Prevent costly recall for non-critical systems as well Designers need to make sure the model at each step of design does reflect the original intent. Catch bugs as early as they are introduced so one can locate them effectively
6 ECE 587 Hardware/Software Co-Design Spring /23 Functional Verification Analysis and reasoning on a computer model of the system Before manufacturing Establish confidence in functional correctness before the product is shipped Critical for systems where safety is the first concern Prevent costly recall for non-critical systems as well Designers need to make sure the model at each step of design does reflect the original intent. Catch bugs as early as they are introduced so one can locate them effectively
7 ECE 587 Hardware/Software Co-Design Spring /23 Simulation Based Verification vs. Formal Verification Both verification methods need a golden reference as part of the specification. Simulation based methods: stimuli (inputs) and monitors (expected outputs) Formal methods: mathematical model of desired properties Simulation-based methods are effective to catch bugs at early design stages, though only as good as the stimuli. Formal methods can provide a proof of correctness, but require more effort at design time. Simulation is still predominant while formal methods are catching up. More formal verification tools become available. More designers are trained to use these tools. e.g. most gate-level verifications are based on formal methods nowadays
8 ECE 587 Hardware/Software Co-Design Spring /23 Simulation Based Verification vs. Formal Verification Both verification methods need a golden reference as part of the specification. Simulation based methods: stimuli (inputs) and monitors (expected outputs) Formal methods: mathematical model of desired properties Simulation-based methods are effective to catch bugs at early design stages, though only as good as the stimuli. Formal methods can provide a proof of correctness, but require more effort at design time. Simulation is still predominant while formal methods are catching up. More formal verification tools become available. More designers are trained to use these tools. e.g. most gate-level verifications are based on formal methods nowadays
9 ECE 587 Hardware/Software Co-Design Spring /23 Simulation Based Verification vs. Formal Verification Both verification methods need a golden reference as part of the specification. Simulation based methods: stimuli (inputs) and monitors (expected outputs) Formal methods: mathematical model of desired properties Simulation-based methods are effective to catch bugs at early design stages, though only as good as the stimuli. Formal methods can provide a proof of correctness, but require more effort at design time. Simulation is still predominant while formal methods are catching up. More formal verification tools become available. More designers are trained to use these tools. e.g. most gate-level verifications are based on formal methods nowadays
10 ECE 587 Hardware/Software Co-Design Spring /23 Simulation Based Verification vs. Formal Verification Both verification methods need a golden reference as part of the specification. Simulation based methods: stimuli (inputs) and monitors (expected outputs) Formal methods: mathematical model of desired properties Simulation-based methods are effective to catch bugs at early design stages, though only as good as the stimuli. Formal methods can provide a proof of correctness, but require more effort at design time. Simulation is still predominant while formal methods are catching up. More formal verification tools become available. More designers are trained to use these tools. e.g. most gate-level verifications are based on formal methods nowadays
11 ECE 587 Hardware/Software Co-Design Spring /23 Outline Verification Simulation Based Methods Equivalence Checking
12 ECE 587 Hardware/Software Co-Design Spring /23 Simulation Based Methods (Gajski et al.)
13 ECE 587 Hardware/Software Co-Design Spring /23 Test-Bench A test-case consists of a stimulus and the corresponding monitor. Monitors are usually generated from stimuli using a higher level model (golden) that is more likely to be correct. A collection of test-cases forms the test-bench. To achieve maximum productivity, each test-case should uncover some bug that has not been uncovered by a previous one waste of time to test part of DUT that have already been tested. How to measure the part being tested under a test-case?
14 ECE 587 Hardware/Software Co-Design Spring /23 Test-Bench A test-case consists of a stimulus and the corresponding monitor. Monitors are usually generated from stimuli using a higher level model (golden) that is more likely to be correct. A collection of test-cases forms the test-bench. To achieve maximum productivity, each test-case should uncover some bug that has not been uncovered by a previous one waste of time to test part of DUT that have already been tested. How to measure the part being tested under a test-case?
15 ECE 587 Hardware/Software Co-Design Spring /23 Test-Bench A test-case consists of a stimulus and the corresponding monitor. Monitors are usually generated from stimuli using a higher level model (golden) that is more likely to be correct. A collection of test-cases forms the test-bench. To achieve maximum productivity, each test-case should uncover some bug that has not been uncovered by a previous one waste of time to test part of DUT that have already been tested. How to measure the part being tested under a test-case?
16 ECE 587 Hardware/Software Co-Design Spring /23 Coverage Could be based on the percentage of DUT that has been checked e.g. in terms of # lines of source code or # states in a state diagram modeling the system However, that s different from the entire behavior of the design. A single statement may involve many variables and a test-case covers it may miss some important corners. All corner cases may be modeled explicitly in the state diagram for coverage. But then the size of the diagram will become a big concern.
17 ECE 587 Hardware/Software Co-Design Spring /23 Coverage Could be based on the percentage of DUT that has been checked e.g. in terms of # lines of source code or # states in a state diagram modeling the system However, that s different from the entire behavior of the design. A single statement may involve many variables and a test-case covers it may miss some important corners. All corner cases may be modeled explicitly in the state diagram for coverage. But then the size of the diagram will become a big concern.
18 ECE 587 Hardware/Software Co-Design Spring /23 Coverage Could be based on the percentage of DUT that has been checked e.g. in terms of # lines of source code or # states in a state diagram modeling the system However, that s different from the entire behavior of the design. A single statement may involve many variables and a test-case covers it may miss some important corners. All corner cases may be modeled explicitly in the state diagram for coverage. But then the size of the diagram will become a big concern.
19 ECE 587 Hardware/Software Co-Design Spring /23 Performance Considerations Coverage may increase as you simulate with more test-cases. However, simulation takes time. Need to trade-off verification performance with quality Stimulus optimization: simulate less cases Use coverage feedback mechanism to improve test-cases that are otherwise generated randomly Not all test-cases are valid only simulate with valid ones Monitor optimization: discover bugs faster White box testing also monitor internal variables Use assertions instead of golden for internal variables Communicate more effectively with designers via visualization Speed-up techniques: faster simulation Faster algorithms Hardware assistance, e.g. on FPGA Simulate at higher abstraction levels, e.g. TLM, if certain details can be omitted.
20 ECE 587 Hardware/Software Co-Design Spring /23 Performance Considerations Coverage may increase as you simulate with more test-cases. However, simulation takes time. Need to trade-off verification performance with quality Stimulus optimization: simulate less cases Use coverage feedback mechanism to improve test-cases that are otherwise generated randomly Not all test-cases are valid only simulate with valid ones Monitor optimization: discover bugs faster White box testing also monitor internal variables Use assertions instead of golden for internal variables Communicate more effectively with designers via visualization Speed-up techniques: faster simulation Faster algorithms Hardware assistance, e.g. on FPGA Simulate at higher abstraction levels, e.g. TLM, if certain details can be omitted.
21 ECE 587 Hardware/Software Co-Design Spring /23 Performance Considerations Coverage may increase as you simulate with more test-cases. However, simulation takes time. Need to trade-off verification performance with quality Stimulus optimization: simulate less cases Use coverage feedback mechanism to improve test-cases that are otherwise generated randomly Not all test-cases are valid only simulate with valid ones Monitor optimization: discover bugs faster White box testing also monitor internal variables Use assertions instead of golden for internal variables Communicate more effectively with designers via visualization Speed-up techniques: faster simulation Faster algorithms Hardware assistance, e.g. on FPGA Simulate at higher abstraction levels, e.g. TLM, if certain details can be omitted.
22 ECE 587 Hardware/Software Co-Design Spring /23 Performance Considerations Coverage may increase as you simulate with more test-cases. However, simulation takes time. Need to trade-off verification performance with quality Stimulus optimization: simulate less cases Use coverage feedback mechanism to improve test-cases that are otherwise generated randomly Not all test-cases are valid only simulate with valid ones Monitor optimization: discover bugs faster White box testing also monitor internal variables Use assertions instead of golden for internal variables Communicate more effectively with designers via visualization Speed-up techniques: faster simulation Faster algorithms Hardware assistance, e.g. on FPGA Simulate at higher abstraction levels, e.g. TLM, if certain details can be omitted.
23 ECE 587 Hardware/Software Co-Design Spring /23 Performance Considerations Coverage may increase as you simulate with more test-cases. However, simulation takes time. Need to trade-off verification performance with quality Stimulus optimization: simulate less cases Use coverage feedback mechanism to improve test-cases that are otherwise generated randomly Not all test-cases are valid only simulate with valid ones Monitor optimization: discover bugs faster White box testing also monitor internal variables Use assertions instead of golden for internal variables Communicate more effectively with designers via visualization Speed-up techniques: faster simulation Faster algorithms Hardware assistance, e.g. on FPGA Simulate at higher abstraction levels, e.g. TLM, if certain details can be omitted.
24 ECE 587 Hardware/Software Co-Design Spring /23 Coverage Feedback I (Gajski et al.) The logic gates could be a simplification of branch conditions. It could be impossible to generate a single test-case to cover all branches.
25 ECE 587 Hardware/Software Co-Design Spring /23 Coverage Feedback I (Gajski et al.) The logic gates could be a simplification of branch conditions. It could be impossible to generate a single test-case to cover all branches.
26 ECE 587 Hardware/Software Co-Design Spring /23 Coverage Feedback II The additional test-cases can be found manually or automatically (by formal methods). (Gajski et al.)
27 ECE 587 Hardware/Software Co-Design Spring /23 Visualizing Bugs Look for most intuitive ways to visualize the bugs (Gajski et al.)
28 Hardware Emulation (Gajski et al.) Speed-up simulations that cannot be speeded-up otherwise. Usually when cycle-accurate behavior has to be simulated ECE 587 Hardware/Software Co-Design Spring /23
29 ECE 587 Hardware/Software Co-Design Spring /23 Outline Verification Simulation Based Methods Equivalence Checking
30 ECE 587 Hardware/Software Co-Design Spring /23 Equivalence Checking Make sure two designs are the same in term of functionality Ensure the correctness of implementations and optimizations Designers could make mistakes when implement a system manually. Automated software tools for synthesis and optimization may have bugs. What does it mean by the same functionality? Same output given same input?
31 ECE 587 Hardware/Software Co-Design Spring /23 Equivalence Checking Make sure two designs are the same in term of functionality Ensure the correctness of implementations and optimizations Designers could make mistakes when implement a system manually. Automated software tools for synthesis and optimization may have bugs. What does it mean by the same functionality? Same output given same input?
32 ECE 587 Hardware/Software Co-Design Spring /23 Equivalence Checking Make sure two designs are the same in term of functionality Ensure the correctness of implementations and optimizations Designers could make mistakes when implement a system manually. Automated software tools for synthesis and optimization may have bugs. What does it mean by the same functionality? Same output given same input?
33 ECE 587 Hardware/Software Co-Design Spring /23 Combinational Equivalence Checking What does it mean by the same functionality? Combinational circuits C1 and C2 At least they should have the same inputs and outputs For any input x, the output C1(x) should be the same as C2(x) One can build a larger combinational circuit E(x) = (C1(x) C2(x)). XOR each pair of corresponding bits of C1(x) and C2(x) Then OR the results together To prove C1 and C2 are equivalent is the same as to prove there is no x such that E(x) = 1. If such x exists, you can use it to debug your circuits.
34 ECE 587 Hardware/Software Co-Design Spring /23 Combinational Equivalence Checking What does it mean by the same functionality? Combinational circuits C1 and C2 At least they should have the same inputs and outputs For any input x, the output C1(x) should be the same as C2(x) One can build a larger combinational circuit E(x) = (C1(x) C2(x)). XOR each pair of corresponding bits of C1(x) and C2(x) Then OR the results together To prove C1 and C2 are equivalent is the same as to prove there is no x such that E(x) = 1. If such x exists, you can use it to debug your circuits.
35 ECE 587 Hardware/Software Co-Design Spring /23 Combinational Equivalence Checking What does it mean by the same functionality? Combinational circuits C1 and C2 At least they should have the same inputs and outputs For any input x, the output C1(x) should be the same as C2(x) One can build a larger combinational circuit E(x) = (C1(x) C2(x)). XOR each pair of corresponding bits of C1(x) and C2(x) Then OR the results together To prove C1 and C2 are equivalent is the same as to prove there is no x such that E(x) = 1. If such x exists, you can use it to debug your circuits.
36 ECE 587 Hardware/Software Co-Design Spring /23 Combinational Equivalence Checking What does it mean by the same functionality? Combinational circuits C1 and C2 At least they should have the same inputs and outputs For any input x, the output C1(x) should be the same as C2(x) One can build a larger combinational circuit E(x) = (C1(x) C2(x)). XOR each pair of corresponding bits of C1(x) and C2(x) Then OR the results together To prove C1 and C2 are equivalent is the same as to prove there is no x such that E(x) = 1. If such x exists, you can use it to debug your circuits.
37 ECE 587 Hardware/Software Co-Design Spring /23 Satisfiability (SAT) Find x such that E(x) = 1 for a given combinational circuit E or prove no such x exists. This is a well-studied problem: satisfiability (SAT) In theory, we don t know if there is a better way to solve it than to inspect the truth table of E. i.e. to try all possible inputs, 2 N for N inputs In practice, efficient solutions have been developed during the last two decades. That s the reason formal verification becomes more and more popular now.
38 ECE 587 Hardware/Software Co-Design Spring /23 Satisfiability (SAT) Find x such that E(x) = 1 for a given combinational circuit E or prove no such x exists. This is a well-studied problem: satisfiability (SAT) In theory, we don t know if there is a better way to solve it than to inspect the truth table of E. i.e. to try all possible inputs, 2 N for N inputs In practice, efficient solutions have been developed during the last two decades. That s the reason formal verification becomes more and more popular now.
39 ECE 587 Hardware/Software Co-Design Spring /23 Satisfiability (SAT) Find x such that E(x) = 1 for a given combinational circuit E or prove no such x exists. This is a well-studied problem: satisfiability (SAT) In theory, we don t know if there is a better way to solve it than to inspect the truth table of E. i.e. to try all possible inputs, 2 N for N inputs In practice, efficient solutions have been developed during the last two decades. That s the reason formal verification becomes more and more popular now.
40 ECE 587 Hardware/Software Co-Design Spring /23 FSM Equivalence Checking Concerning synchronous sequential circuits i.e. RTL designs For any input trace, the two FSM should produce the same output trace. From certain initial states What about states and state encodings? State encodings could be different. States could also be different. In general a very difficult problem that requires further research. In practice, if you could provide hints to relate the states of the two circuits, tools may be able to provide a proof.
41 ECE 587 Hardware/Software Co-Design Spring /23 FSM Equivalence Checking Concerning synchronous sequential circuits i.e. RTL designs For any input trace, the two FSM should produce the same output trace. From certain initial states What about states and state encodings? State encodings could be different. States could also be different. In general a very difficult problem that requires further research. In practice, if you could provide hints to relate the states of the two circuits, tools may be able to provide a proof.
42 ECE 587 Hardware/Software Co-Design Spring /23 FSM Equivalence Checking Concerning synchronous sequential circuits i.e. RTL designs For any input trace, the two FSM should produce the same output trace. From certain initial states What about states and state encodings? State encodings could be different. States could also be different. In general a very difficult problem that requires further research. In practice, if you could provide hints to relate the states of the two circuits, tools may be able to provide a proof.
43 ECE 587 Hardware/Software Co-Design Spring /23 FSM Equivalence Checking Concerning synchronous sequential circuits i.e. RTL designs For any input trace, the two FSM should produce the same output trace. From certain initial states What about states and state encodings? State encodings could be different. States could also be different. In general a very difficult problem that requires further research. In practice, if you could provide hints to relate the states of the two circuits, tools may be able to provide a proof.
44 ECE 587 Hardware/Software Co-Design Spring /23 FSM Equivalence Checking Examples Consider reachable states in product FSM (Gajski et al.)
45 ECE 587 Hardware/Software Co-Design Spring /23 A Special Case of FSM Equivalence Checking (Gajski et al.) With the same states, state encodings, and initial states, one just need to prove the next state and the output functions are equivalent. That s combinational equivalence checking. Solved!
46 ECE 587 Hardware/Software Co-Design Spring /23 A Special Case of FSM Equivalence Checking (Gajski et al.) With the same states, state encodings, and initial states, one just need to prove the next state and the output functions are equivalent. That s combinational equivalence checking. Solved!
47 ECE 587 Hardware/Software Co-Design Spring /23 Limitations of Combinational and FSM Equivalence Checking What if the functional equivalence goes beyond inputs/outputs per cycle? e.g. two kinds of processors with the same ISA but requiring different number of cycles to complete the same instructions? Although we perceive them as equivalent, it is difficult to define equivalence in mathematical sense. Equivalence checkings cannot be applied as of now. We have to apply a more expensive method called model checking.
48 ECE 587 Hardware/Software Co-Design Spring /23 Limitations of Combinational and FSM Equivalence Checking What if the functional equivalence goes beyond inputs/outputs per cycle? e.g. two kinds of processors with the same ISA but requiring different number of cycles to complete the same instructions? Although we perceive them as equivalent, it is difficult to define equivalence in mathematical sense. Equivalence checkings cannot be applied as of now. We have to apply a more expensive method called model checking.
49 ECE 587 Hardware/Software Co-Design Spring /23 Limitations of Combinational and FSM Equivalence Checking What if the functional equivalence goes beyond inputs/outputs per cycle? e.g. two kinds of processors with the same ISA but requiring different number of cycles to complete the same instructions? Although we perceive them as equivalent, it is difficult to define equivalence in mathematical sense. Equivalence checkings cannot be applied as of now. We have to apply a more expensive method called model checking.
50 ECE 587 Hardware/Software Co-Design Spring /23 Summary (Gajski et al.)
ECE 587 Hardware/Software Co-Design Lecture 12 Verification II, System Modeling
ECE 587 Hardware/Software Co-Design Spring 2018 1/20 ECE 587 Hardware/Software Co-Design Lecture 12 Verification II, System Modeling Professor Jia Wang Department of Electrical and Computer Engineering
More informationCS/ECE 5780/6780: Embedded System Design
CS/ECE 5780/6780: Embedded System Design John Regehr Lecture 18: Introduction to Verification What is verification? Verification: A process that determines if the design conforms to the specification.
More informationAdministrivia. ECE/CS 5780/6780: Embedded System Design. Acknowledgements. What is verification?
Administrivia ECE/CS 5780/6780: Embedded System Design Scott R. Little Lab 8 status report. Set SCIBD = 52; (The Mclk rate is 16 MHz.) Lecture 18: Introduction to Hardware Verification Scott R. Little
More informationECE 587 Hardware/Software Co-Design Lecture 23 Hardware Synthesis III
ECE 587 Hardware/Software Co-Design Spring 2018 1/28 ECE 587 Hardware/Software Co-Design Lecture 23 Hardware Synthesis III Professor Jia Wang Department of Electrical and Computer Engineering Illinois
More informationQualification of Verification Environments Using Formal Techniques
Qualification of Verification Environments Using Formal Techniques Raik Brinkmann DVClub on Verification Qualification April 28 2014 www.onespin-solutions.com Copyright OneSpin Solutions 2014 Copyright
More informationDesign Verification Lecture 01
M. Hsiao 1 Design Verification Lecture 01 Course Title: Verification of Digital Systems Professor: Michael Hsiao (355 Durham) Prerequisites: Digital Logic Design, C/C++ Programming, Data Structures, Computer
More informationBulletproofing FSM Verification Automated Approach to Detect Corner Case Issues in an FSM Design
Bulletproofing FSM Verification Automated Approach to Detect Corner Case Issues in an FSM Design Lisa Piper Technical Marketing Real Intent Inc., Sunnyvale, CA Comprehensive verification of Finite State
More informationADVANCED DIGITAL IC DESIGN. Digital Verification Basic Concepts
1 ADVANCED DIGITAL IC DESIGN (SESSION 6) Digital Verification Basic Concepts Need for Verification 2 Exponential increase in the complexity of ASIC implies need for sophisticated verification methods to
More informationCertitude Functional Qualification with Formal Verification. Jean-Marc Forey November 2012
Certitude Functional Qualification with Formal Verification Jean-Marc Forey November 2012 Springsoft Proprietary Topics Case study presentation Why Verification Verification efficiency Formal verification
More informationEECS150 - Digital Design Lecture 20 - Finite State Machines Revisited
EECS150 - Digital Design Lecture 20 - Finite State Machines Revisited April 2, 2009 John Wawrzynek Spring 2009 EECS150 - Lec20-fsm Page 1 Finite State Machines (FSMs) FSM circuits are a type of sequential
More informationECE 449 OOP and Computer Simulation Lecture 09 Logic Simulation
ECE 449 Object-Oriented Programming and Computer Simulation, Fall 2017, Dept. of ECE, IIT 1/31 ECE 449 OOP and Computer Simulation Lecture 09 Logic Simulation Professor Jia Wang Department of Electrical
More informationSoC Verification Methodology. Prof. Chien-Nan Liu TEL: ext:
SoC Verification Methodology Prof. Chien-Nan Liu TEL: 03-4227151 ext:4534 Email: jimmy@ee.ncu.edu.tw 1 Outline l Verification Overview l Verification Strategies l Tools for Verification l SoC Verification
More informationVerification of Power Management Protocols through Abstract Functional Modeling
Verification of Power Management Protocols through Abstract Functional Modeling G. Kamhi, T. Levy, Niranjan M, M. Mhameed, H. Rawlani, R. B. Rajput, E. Singerman, V. Vedula, Y. Zbar Motivation Microprocessor
More informationLeveraging Formal Verification Throughout the Entire Design Cycle
Leveraging Formal Verification Throughout the Entire Design Cycle Verification Futures Page 1 2012, Jasper Design Automation Objectives for This Presentation Highlight several areas where formal verification
More informationEECS150 - Digital Design Lecture 7 - Computer Aided Design (CAD) - Part II (Logic Simulation) Finite State Machine Review
EECS150 - Digital Design Lecture 7 - Computer Aided Design (CAD) - Part II (Logic Simulation) Feb 9, 2010 John Wawrzynek Spring 2010 EECS150 - Lec7-CAD2 Page 1 Finite State Machine Review State Transition
More informationFormal Technology in the Post Silicon lab
Formal Technology in the Post Silicon lab Real-Life Application Examples Haifa Verification Conference Jamil R. Mazzawi Lawrence Loh Jasper Design Automation Focus of This Presentation Finding bugs in
More informationECEU530. Schedule. ECE U530 Digital Hardware Synthesis. Datapath for the Calculator (HW 5) HW 5 Datapath Entity
ECE U530 Digital Hardware Synthesis Prof. Miriam Leeser mel@coe.neu.edu November 6, 2006 Classes November 6 and 8 are in 429 Dana! Lecture 15: Homework 5: Datapath How to write a testbench for synchronous
More informationCS 250 VLSI Design Lecture 11 Design Verification
CS 250 VLSI Design Lecture 11 Design Verification 2012-9-27 John Wawrzynek Jonathan Bachrach Krste Asanović John Lazzaro TA: Rimas Avizienis www-inst.eecs.berkeley.edu/~cs250/ IBM Power 4 174 Million Transistors
More informationCSE 374 Programming Concepts & Tools. Hal Perkins Fall 2015 Lecture 15 Testing
CSE 374 Programming Concepts & Tools Hal Perkins Fall 2015 Lecture 15 Testing Where we are Some very basic software engineering topics in the midst of tools Today: testing (how, why, some terms) Later:
More informationEfficient Failure Triage with Automated Debug: a Case Study by Sean Safarpour, Evean Qin, and Mustafa Abbas, Vennsa Technologies Inc.
Efficient Failure Triage with Automated Debug: a Case Study by Sean Safarpour, Evean Qin, and Mustafa Abbas, Vennsa Technologies Inc. Functional debug is a dreadful yet necessary part of today s verification
More informationAn Evaluation of the Advantages of Moving from a VHDL to a UVM Testbench by Shaela Rahman, Baker Hughes
An Evaluation of the Advantages of Moving from a VHDL to a UVM Testbench by Shaela Rahman, Baker Hughes FPGA designs are becoming too large to verify by visually checking waveforms, as the functionality
More informationSystem Debugging and Verification : A New Challenge. Center for Embedded Computer Systems University of California, Irvine
System Debugging and Verification : A New Challenge Daniel Gajski Samar Abdi Center for Embedded Computer Systems http://www.cecs.uci.edu University of California, Irvine Overview Simulation and debugging
More informationTesting! Prof. Leon Osterweil! CS 520/620! Spring 2013!
Testing Prof. Leon Osterweil CS 520/620 Spring 2013 Relations and Analysis A software product consists of A collection of (types of) artifacts Related to each other by myriad Relations The relations are
More informationMixed Signal Verification Transistor to SoC
Mixed Signal Verification Transistor to SoC Martin Vlach Chief Technologist AMS July 2014 Agenda AMS Verification Landscape Verification vs. Design Issues in AMS Verification Modeling Summary 2 AMS VERIFICATION
More informationIn this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs.
In this Lecture you will Learn: Testing in Software Development Process Examine the verification and validation activities in software development process stage by stage Introduce some basic concepts of
More informationRevolutioni W zi h Wn e hgn e n F a Mi i s liu lsir u e ro e Cri I ti s Ic N al o t V A e n ri n O fi p c ti a o ti n oo
Formal Verification Revolutionizing Mission Critical Verification When Failure Is Not An Option Formal-based Security Verification www.onespin.com March 2016 HW Security Issues More Common Than Thought
More informationEECS150 - Digital Design Lecture 5 - Verilog Logic Synthesis
EECS150 - Digital Design Lecture 5 - Verilog Logic Synthesis Jan 31, 2012 John Wawrzynek Spring 2012 EECS150 - Lec05-verilog_synth Page 1 Outline Quick review of essentials of state elements Finite State
More informationHardware Design and Simulation for Verification
Hardware Design and Simulation for Verification by N. Bombieri, F. Fummi, and G. Pravadelli Universit`a di Verona, Italy (in M. Bernardo and A. Cimatti Eds., Formal Methods for Hardware Verification, Lecture
More informationVERIFICATION OF RISC-V PROCESSOR USING UVM TESTBENCH
VERIFICATION OF RISC-V PROCESSOR USING UVM TESTBENCH Chevella Anilkumar 1, K Venkateswarlu 2 1.2 ECE Department, JNTU HYDERABAD(INDIA) ABSTRACT RISC-V (pronounced "risk-five") is a new, open, and completely
More informationFormal Verification Adoption. Mike Bartley TVS, Founder and CEO
Formal Verification Adoption Mike Bartley TVS, Founder and CEO Agenda Some background on your speaker Formal Verification An introduction Basic examples A FIFO example Adoption Copyright TVS Limited Private
More informationLogic Verification 13-1
Logic Verification 13-1 Verification The goal of verification To ensure 100% correct in functionality and timing Spend 50 ~ 70% of time to verify a design Functional verification Simulation Formal proof
More informationEECS150 - Digital Design Lecture 6 - Logic Simulation
EECS150 - Digital Design Lecture 6 - Logic Simulation Sep. 17, 013 Prof. Ronald Fearing Electrical Engineering and Computer Sciences University of California, Berkeley (slides courtesy of Prof. John Wawrzynek)
More informationPractical Approaches to Formal Verification. Mike Bartley, TVS
Practical Approaches to Formal Verification Mike Bartley, TVS 1 Acknowledgements This paper is based on work performed by TVS with ARM Specific thanks should go to Laurent Arditi Bryan Dickman Daryl Stuart
More informationHardware Design Verification: Simulation and Formal Method-Based Approaches William K Lam Prentice Hall Modern Semiconductor Design Series
Design Verification An Introduction Main References Hardware Design Verification: Simulation and Formal Method-Based Approaches William K Lam Prentice Hall Modern Semiconductor Design Series A Roadmap
More informationPortable Stimulus vs Formal vs UVM A Comparative Analysis of Verification Methodologies Throughout the Life of an IP Block
Portable Stimulus vs Formal vs UVM A Comparative Analysis of Verification Methodologies Throughout the Life of an IP Block Gaurav Bhatnagar Staff Engineer, Analog Devices, Inc David Brownell Manager, Analog
More informationTwo Case Studies in Formal Deployment on ARM CPUs : Instruction-Fetch and Floating-Point datapath
Two Case Studies in Formal Deployment on ARM CPUs : Instruction-Fetch and Floating-Point datapath DVClub May 15, 2018 Vaibhav Agrawal CPU Validation, Austin Instruction-Fetch unit Why formal on Instruction-Fetch
More informationFPGA Verification How to improve verification without throwing everything away
Test and Verification Solutions Experts in Verification FPGA Verification How to improve verification without throwing everything away Mike Bartley, TVS 1 Agenda Have you concerns with your current verification
More informationAdvanced VLSI Design Prof. Virendra K. Singh Department of Electrical Engineering Indian Institute of Technology Bombay
Advanced VLSI Design Prof. Virendra K. Singh Department of Electrical Engineering Indian Institute of Technology Bombay Lecture 40 VLSI Design Verification: An Introduction Hello. Welcome to the advance
More informationTesting. ECE/CS 5780/6780: Embedded System Design. Why is testing so hard? Why do testing?
Testing ECE/CS 5780/6780: Embedded System Design Scott R. Little Lecture 24: Introduction to Software Testing and Verification What is software testing? Running a program in order to find bugs (faults,
More informationEECS 4340: Computer Hardware Design Unit 4: Validation
EECS 4340: Unit 4: Validation Prof. Simha Sethumadhavan Reference Book: System Verilog for Verification Agenda Last Unit Design abstractions Basic primitives This Unit Validation Forthcoming Design Tips
More informationCombinational Equivalence Checking
Combinational Equivalence Checking Virendra Singh Associate Professor Computer Architecture and Dependable Systems Lab. Dept. of Electrical Engineering Indian Institute of Technology Bombay viren@ee.iitb.ac.in
More informationASIC world. Start Specification Design Verification Layout Validation Finish
AMS Verification Agenda ASIC world ASIC Industrial Facts Why Verification? Verification Overview Functional Verification Formal Verification Analog Verification Mixed-Signal Verification DFT Verification
More informationHECTOR: Formal System-Level to RTL Equivalence Checking
ATG SoC HECTOR: Formal System-Level to RTL Equivalence Checking Alfred Koelbl, Sergey Berezin, Reily Jacoby, Jerry Burch, William Nicholls, Carl Pixley Advanced Technology Group Synopsys, Inc. June 2008
More informationWhy testing and analysis. Software Testing. A framework for software testing. Outline. Software Qualities. Dependability Properties
Why testing and analysis Software Testing Adapted from FSE 98 Tutorial by Michal Young and Mauro Pezze Software is never correct no matter what developing testing technique is used All software must be
More informationShortest path to the lab. Real-world verification. Probes provide observability
OVM/UVM for FPGAs: The End of Burn and Churn FPGA Verification by In-Circuit Test Burn and churn based on at-speed test with real input 2 Shortest path to the lab Nominal simulation of RTL blocks Relatively
More informationEE 4755 Digital Design Using Hardware Description Languages
EE 4755 Digital Design Using Hardware Description Languages Basic Information URL: http://www.ece.lsu.edu/v Offered by: David M. Koppelman, Room 345 ERAD Building 578-5482. koppel@ece.lsu.edu, http://www.ece.lsu.edu/koppel/koppel.html
More informationVerification of Clock Domain Crossing Jitter and Metastability Tolerance using Emulation
Verification of Clock Domain Crossing Jitter and Metastability Tolerance using Emulation Ashish Hari ashish_hari@mentor.com Suresh Krishnamurthy k_suresh@mentor.com Amit Jain amit_jain@mentor.com Yogesh
More informationEECS150 - Digital Design Lecture 6 - Logic Simulation. Encoder Example
EECS150 - Digital Design Lecture 6 - Logic Simulation Feb 7, 2013 John Wawrzynek Spring 2013 EECS150 - Lec06-sim Page 1 Encoder Example What is y if x == 4 b1111? always @(x) : encode if (x == 4'b0001)
More informationHigh Speed Fault Injection Tool (FITO) Implemented With VHDL on FPGA For Testing Fault Tolerant Designs
Vol. 3, Issue. 5, Sep - Oct. 2013 pp-2894-2900 ISSN: 2249-6645 High Speed Fault Injection Tool (FITO) Implemented With VHDL on FPGA For Testing Fault Tolerant Designs M. Reddy Sekhar Reddy, R.Sudheer Babu
More informationChapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering
Chapter 11, Testing Using UML, Patterns, and Java Object-Oriented Software Engineering Outline Terminology Types of errors Dealing with errors Quality assurance vs Testing Component Testing! Unit testing!
More informationReset and Initialization, the Good, the Bad and the Ugly
Reset and Initialization, the, the and the Ugly Ping Yeung Design & Verification Technology Mentor Graphics, Fremont, U.S.A. Kaowen Liu Design Technology Division MediaTek Inc, San Jose, U.S.A. Abstract-
More informationVLSI Test Technology and Reliability (ET4076)
VLSI Test Technology and Reliability (ET4076) Lecture 4(part 2) Testability Measurements (Chapter 6) Said Hamdioui Computer Engineering Lab Delft University of Technology 2009-2010 1 Previous lecture What
More informationVerification and Validation
Steven Zeil February 13, 2013 Contents 1 The Process 3 1 2 Non-Testing V&V 7 2.1 Code Review....... 8 2.2 Mathematically-based verification......................... 19 2.3 Static analysis tools... 23 2.4
More informationVerification and Validation
Steven Zeil February 13, 2013 Contents 1 The Process 2 2 Non-Testing V&V 3 2.1 Code Review........... 4 2.2 Mathematically-based verification.................................. 8 2.3 Static analysis tools.......
More informationThree General Principles of QA. COMP 4004 Fall Notes Adapted from Dr. A. Williams
Three General Principles of QA COMP 4004 Fall 2008 Notes Adapted from Dr. A. Williams Software Quality Assurance Lec2 1 Three General Principles of QA Know what you are doing. Know what you should be doing.
More informationEE382V: System-on-a-Chip (SoC) Design
EE382V: System-on-a-Chip (SoC) Design Lecture 20 SoC Verification Sources: Jacob A. Abraham Andreas Gerstlauer Electrical and Computer Engineering University of Texas at Austin gerstl@ece.utexas.edu Lecture
More information3. Formal Equivalence Checking
3. Formal Equivalence Checking 1 3. Formal Equivalence Checking Jacob Abraham Department of Electrical and Computer Engineering The University of Texas at Austin Verification of Digital Systems Spring
More informationIntegrated Workflow to Implement Embedded Software and FPGA Designs on the Xilinx Zynq Platform Puneet Kumar Senior Team Lead - SPC
Integrated Workflow to Implement Embedded Software and FPGA Designs on the Xilinx Zynq Platform Puneet Kumar Senior Team Lead - SPC 2012 The MathWorks, Inc. 1 Agenda Integrated Hardware / Software Top
More informationRecommended Design Techniques for ECE241 Project Franjo Plavec Department of Electrical and Computer Engineering University of Toronto
Recommed Design Techniques for ECE241 Project Franjo Plavec Department of Electrical and Computer Engineering University of Toronto DISCLAIMER: The information contained in this document does NOT contain
More informationBibliography. Measuring Software Reuse, Jeffrey S. Poulin, Addison-Wesley, Practical Software Reuse, Donald J. Reifer, Wiley, 1997.
Bibliography Books on software reuse: 1. 2. Measuring Software Reuse, Jeffrey S. Poulin, Addison-Wesley, 1997. Practical Software Reuse, Donald J. Reifer, Wiley, 1997. Formal specification and verification:
More informationContents 1 Introduction 2 Functional Verification: Challenges and Solutions 3 SystemVerilog Paradigm 4 UVM (Universal Verification Methodology)
1 Introduction............................................... 1 1.1 Functional Design Verification: Current State of Affair......... 2 1.2 Where Are the Bugs?.................................... 3 2 Functional
More informationCoverage Metrics for Functional Validation of Hardware Designs
Coverage Metrics for Functional Validation of Hardware Designs Serdar Tasiran, Kurt Keutzer IEEE, Design & Test of Computers,2001 Presenter Guang-Pau Lin What s the problem? What can ensure optimal use
More informationECE 587 Hardware/Software Co-Design Lecture 07 Concurrency in Practice Shared Memory I
ECE 587 Hardware/Software Co-Design Spring 2018 1/15 ECE 587 Hardware/Software Co-Design Lecture 07 Concurrency in Practice Shared Memory I Professor Jia Wang Department of Electrical and Computer Engineering
More informationVLSI Testing. Fault Simulation. Virendra Singh. Indian Institute of Science Bangalore
VLSI Testing Fault Simulation Virendra Singh Indian Institute of Science Bangalore virendra@computer.org E0 286: Test & Verification of SoC Design Lecture - 4 Jan 25, 2008 E0-286@SERC 1 Fault Model - Summary
More informationProperty-based design with HORUS / SYNTHORUS
Property-based design with HORUS / SYNTHORUS Dominique Borrione, Negin Javaheri, Katell Morin-Allory, Yann Oddos, Alexandre Porcher Radboud University, Nijmegen 1 March 27, 2013 Functional specifications
More informationEvolution of CAD Tools & Verilog HDL Definition
Evolution of CAD Tools & Verilog HDL Definition K.Sivasankaran Assistant Professor (Senior) VLSI Division School of Electronics Engineering VIT University Outline Evolution of CAD Different CAD Tools for
More informationDIGITAL VS. ANALOG SIGNAL PROCESSING Digital signal processing (DSP) characterized by: OUTLINE APPLICATIONS OF DIGITAL SIGNAL PROCESSING
1 DSP applications DSP platforms The synthesis problem Models of computation OUTLINE 2 DIGITAL VS. ANALOG SIGNAL PROCESSING Digital signal processing (DSP) characterized by: Time-discrete representation
More informationBeyond Soft IP Quality to Predictable Soft IP Reuse TSMC 2013 Open Innovation Platform Presented at Ecosystem Forum, 2013
Beyond Soft IP Quality to Predictable Soft IP Reuse TSMC 2013 Open Innovation Platform Presented at Ecosystem Forum, 2013 Agenda Soft IP Quality Establishing a Baseline With TSMC Soft IP Quality What We
More informationResearch Collection. Formal background and algorithms. Other Conference Item. ETH Library. Author(s): Biere, Armin. Publication Date: 2001
Research Collection Other Conference Item Formal background and algorithms Author(s): Biere, Armin Publication Date: 2001 Permanent Link: https://doi.org/10.3929/ethz-a-004239730 Rights / License: In Copyright
More informationReducing the cost of FPGA/ASIC Verification with MATLAB and Simulink
Reducing the cost of FPGA/ASIC Verification with MATLAB and Simulink Graham Reith Industry Manager Communications, Electronics and Semiconductors MathWorks Graham.Reith@mathworks.co.uk 2015 The MathWorks,
More informationVLSI Testing. Virendra Singh. Bangalore E0 286: Test & Verification of SoC Design Lecture - 7. Jan 27,
VLSI Testing Fault Simulation Virendra Singh Indian Institute t of Science Bangalore virendra@computer.org E 286: Test & Verification of SoC Design Lecture - 7 Jan 27, 2 E-286@SERC Fault Simulation Jan
More informationVLSI System Testing. Fault Simulation
ECE 538 VLSI System Testing Krish Chakrabarty Fault Simulation ECE 538 Krish Chakrabarty Fault Simulation Problem and motivation Fault simulation algorithms Serial Parallel Deductive Concurrent Random
More informationDigital VLSI Testing Prof. Santanu Chattopadhyay Department of Electronics and EC Engineering India Institute of Technology, Kharagpur.
Digital VLSI Testing Prof. Santanu Chattopadhyay Department of Electronics and EC Engineering India Institute of Technology, Kharagpur Lecture 05 DFT Next we will look into the topic design for testability,
More information1. Choose a module that you wish to implement. The modules are described in Section 2.4.
Chapter 2 Lab 2 - Datapath 2.1 Overview During lab 2 you will complete the RTL code of the ALU and MAC datapaths of the DSP core and write a set of small test programs to verify your implementation. Most
More informationChapter 10. Testing and Quality Assurance
Chapter 10 Testing and Quality Assurance Different styles of doing code review Human Reviewer Code Inspection with continuous integration infrastructure Pinger s testing set up Testing Related topics 1.
More informationTKT-1212 Digitaalijärjestelmien toteutus. Lecture 7: VHDL Testbenches Ari Kulmala, Erno Salminen 2008
TKT-1212 Digitaalijärjestelmien toteutus Lecture 7: VHDL Testbenches Ari Kulmala, Erno Salminen 2008 Contents Purpose of test benches Structure of simple test bench Side note about delay modeling in VHDL
More informationLab #1: Introduction to Design Methodology with FPGAs part 1 (80 pts)
Nate Pihlstrom, npihlstr@uccs.edu Lab #1: Introduction to Design Methodology with FPGAs part 1 (80 pts) Objective The objective of this lab assignment is to introduce and use a methodology for designing
More informationStaffan Berg. European Applications Engineer Digital Functional Verification. September 2017
Portable Stimulus Specification The Next Big Wave in Functional Verification Staffan Berg European Applications Engineer Digital Functional Verification September 2017 AGENDA Why Portable Stimulus? What
More informationBy Matthew Noonan, Project Manager, Resource Group s Embedded Systems & Solutions
Building Testability into FPGA and ASIC Designs By Matthew Noonan, Project Manager, Resource Group s Embedded Systems & Solutions Introduction This paper discusses how the architecture for FPGAs and ASICs
More informationHardware Modelling. Design Flow Overview. ECS Group, TU Wien
Hardware Modelling Design Flow Overview ECS Group, TU Wien 1 Outline Difference: Hardware vs. Software Design Flow Steps Specification Realisation Verification FPGA Design Flow 2 Hardware vs. Software:
More informationOverview of Digital Design with Verilog HDL 1
Overview of Digital Design with Verilog HDL 1 1.1 Evolution of Computer-Aided Digital Design Digital circuit design has evolved rapidly over the last 25 years. The earliest digital circuits were designed
More informationFormal for Everyone Challenges in Achievable Multicore Design and Verification. FMCAD 25 Oct 2012 Daryl Stewart
Formal for Everyone Challenges in Achievable Multicore Design and Verification FMCAD 25 Oct 2012 Daryl Stewart 1 ARM is an IP company ARM licenses technology to a network of more than 1000 partner companies
More informationECE Digital Design Laboratory. Lecture 3 Finite State Machines!
ECE 4401 - Digital Design Laboratory Lecture 3 Finite State Machines! 1!!!! Synchronous Sequential Circuits!!! Synchronous sequential logic circuits are realized using combinational logic and storage elements
More informationVerilog. What is Verilog? VHDL vs. Verilog. Hardware description language: Two major languages. Many EDA tools support HDL-based design
Verilog What is Verilog? Hardware description language: Are used to describe digital system in text form Used for modeling, simulation, design Two major languages Verilog (IEEE 1364), latest version is
More informationEE434 ASIC & Digital Systems Testing
EE434 ASIC & Digital Systems Testing Spring 2015 Dae Hyun Kim daehyun@eecs.wsu.edu 1 Introduction VLSI realization process Verification and test Ideal and real tests Costs of testing Roles of testing A
More informationEE 4755 Digital Design Using Hardware Description Languages
EE 4755 Digital Design Using Hardware Description Languages Basic Information URL: http://www.ece.lsu.edu/v Offered by: David M. Koppelman, Room 3316R P. F. Taylor Hall 578-5482. koppel@ece.lsu.edu, http://www.ece.lsu.edu/koppel/koppel.html
More informationHardware-Software Codesign
Hardware-Software Codesign 8. Performance Estimation Lothar Thiele 8-1 System Design specification system synthesis estimation -compilation intellectual prop. code instruction set HW-synthesis intellectual
More informationVerification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should
More informationHardware Design Environments. Dr. Mahdi Abbasi Computer Engineering Department Bu-Ali Sina University
Hardware Design Environments Dr. Mahdi Abbasi Computer Engineering Department Bu-Ali Sina University Outline Welcome to COE 405 Digital System Design Design Domains and Levels of Abstractions Synthesis
More informationESE Back End 2.0. D. Gajski, S. Abdi. (with contributions from H. Cho, D. Shin, A. Gerstlauer)
ESE Back End 2.0 D. Gajski, S. Abdi (with contributions from H. Cho, D. Shin, A. Gerstlauer) Center for Embedded Computer Systems University of California, Irvine http://www.cecs.uci.edu 1 Technology advantages
More informationDESIGN STRATEGIES & TOOLS UTILIZED
CHAPTER 7 DESIGN STRATEGIES & TOOLS UTILIZED 7-1. Field Programmable Gate Array The internal architecture of an FPGA consist of several uncommitted logic blocks in which the design is to be encoded. The
More informationOutline. EECS Components and Design Techniques for Digital Systems. Lec 11 Putting it all together Where are we now?
Outline EECS 5 - Components and Design Techniques for Digital Systems Lec Putting it all together -5-4 David Culler Electrical Engineering and Computer Sciences University of California Berkeley Top-to-bottom
More informationSymbolic Model Checking
Bug Catching 5-398 Symbolic Model Checking Hao Zheng Dept. of Computer Science & Eng. Univ. of South Florida Overview CTL model checking operates on sets. Calculates the fix points over finite state sets.
More informationstructure syntax different levels of abstraction
This and the next lectures are about Verilog HDL, which, together with another language VHDL, are the most popular hardware languages used in industry. Verilog is only a tool; this course is about digital
More informationHere is a list of lecture objectives. They are provided for you to reflect on what you are supposed to learn, rather than an introduction to this
This and the next lectures are about Verilog HDL, which, together with another language VHDL, are the most popular hardware languages used in industry. Verilog is only a tool; this course is about digital
More informationTest and Verification Solutions. ARM Based SOC Design and Verification
Test and Verification Solutions ARM Based SOC Design and Verification 7 July 2008 1 7 July 2008 14 March 2 Agenda System Verification Challenges ARM SoC DV Methodology ARM SoC Test bench Construction Conclusion
More informationEsterel Studio Update
Esterel Studio Update Kim Sunesen Esterel EDA Technologies www.esterel-eda.com Synchron, November 2007, Bamberg Germany Agenda Update on Esterel Studio Architecture Diagrams Formal Verification IEEE standardization
More informationDesign Process. Design : specify and enter the design intent. Verify: Implement: verify the correctness of design and implementation
Design Verification 1 Design Process Design : specify and enter the design intent Verify: verify the correctness of design and implementation Implement: refine the design through all phases Kurt Keutzer
More informationLogic Synthesis. EECS150 - Digital Design Lecture 6 - Synthesis
Logic Synthesis Verilog and VHDL started out as simulation languages, but quickly people wrote programs to automatically convert Verilog code into low-level circuit descriptions (netlists). EECS150 - Digital
More informationTransaction-Based Acceleration Strong Ammunition In Any Verification Arsenal
Transaction-Based Acceleration Strong Ammunition In Any Verification Arsenal Chandrasekhar Poorna Principal Engineer Broadcom Corp San Jose, CA USA Varun Gupta Sr. Field Applications Engineer Cadence Design
More information