Stop Writing Assertions! Efficient Verification Methodology Dave Whipp – DVClub SV, August 2008.

Slides:



Advertisements
Similar presentations
Putting It All Together: Using Formal Verification In Real Life Erik Seligman CS 510, Lecture 19, March 2009.
Advertisements

Programmable FIR Filter Design
ECOE 560 Design Methodologies and Tools for Software/Hardware Systems Spring 2004 Serdar Taşıran.
Using emulation for RTL performance verification
Xiushan Feng* ASIC Verification Nvidia Corporation Automatic Verification of Dependency 1 TM Jayanta Bhadra
by Adiel Khan Staff CAE Synopsys
February 28 – March 3, 2011 Stepwise Refinement and Reuse: The Key to ESL Ashok B. Mehta Senior Manager (DTP/SJDMP) TSMC Technology, Inc. Mark Glasser.
Lecture # 2 : Process Models
Effective RTL coding rules to avoid Simulation Shoot-thru Udit Kumar 1, Bhanu Prakash 1, Olivier Florent 1, Paras Mal Jain 2, Anshu Malani 2, Shaker Sarwary.
1 Speed, Drunkenness, and the Wall Does High Level Design/ESL Make Sense? Kris Konigsfeld Sr. Principal Engineer Oregon CPU Architecture Intel Corporation.
Leveraging Assertion Based Verification by using Magellan Michal Cayzer.
Design For Verification Synopsys Inc, April 2003.
Behavioral Design Outline –Design Specification –Behavioral Design –Behavioral Specification –Hardware Description Languages –Behavioral Simulation –Behavioral.
ECE Synthesis & Verification1 ECE 667 Spring 2011 Synthesis and Verification of Digital Systems Verification Introduction.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Process Models.
Fundamentals of Simulation-Based Verification 1.Structure of a Testbench - stimulus, checkers, etc. 2.Observation and Assertions - automatic checking of.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Creating Test Environments HDL Model HDL Testbench Simulation Engine API stimulus check Testbench Program stimulus check Non-HDL languages may be used.
EE694v-Verification-Lect5-1- Lecture 5 - Verification Tools Automation improves the efficiency and reliability of the verification process Some tools,
Principle of Functional Verification Chapter 1~3 Presenter : Fu-Ching Yang.
Methods for checking simulation correctness How do you know if your testcase passed or failed?
VerificationTechniques for Macro Blocks (IP) Overview Inspection as Verification Adversarial Testing Testbench Design Timing Verification.
Chapter 7: The Object-Oriented Approach to Requirements
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
TM Freescale™ and the Freescale logo are trademarks of Freescale Semiconductor, Inc. All other product or service names are the property of their respective.
Introduction to High-Level Language Programming
1 Chapter 2. The System-on-a-Chip Design Process Canonical SoC Design System design flow The Specification Problem System design.
TM Efficient IP Design flow for Low-Power High-Level Synthesis Quick & Accurate Power Analysis and Optimization Flow JAN Asher Berkovitz Yaniv.
Chapter 2 The process Process, Methods, and Tools
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Managing the development and purchase of information systems (Part 1)
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Transaction Assertions in an Interface Definition Language Dave Whipp – DesignCon 2008.
MAPLDDesign Integrity Concepts You Mean We’re Still Working On It? Sustaining a Design.
Magnetic Field Measurement System as Part of a Software Family Jerzy M. Nogiec Joe DiMarco Fermilab.
Some Course Info Jean-Michel Chabloz. Main idea This is a course on writing efficient testbenches Very lab-centric course: –You are supposed to learn.
A Multi-Paradigm Verification Flow Dave Whipp. Copyright © NVIDIA Corporation 2005 Multiple Paradigms Analog Mixed Signal Digital Formal Semi-formal Simulation.
Copyright © 2002 Qualis Design Corporation Industry and Textbook Overview Qualis Design Corporation PO Box 4444 Beaverton, Oregon USA Phone:
Using Formal Verification to Exhaustively Verify SoC Assemblies by Mark Handover Kenny Ranerup Applications Engineer ASIC Consultant Mentor Graphics Corp.
Intent Specification Intent Specification is used in SpecTRM
System Verilog Testbench Language David W. Smith Synopsys Scientist
1 H ardware D escription L anguages Modeling Digital Systems.
High Performance Embedded Computing © 2007 Elsevier Lecture 3: Design Methodologies Embedded Computing Systems Mikko Lipasti, adapted from M. Schulte Based.
High Performance Embedded Computing © 2007 Elsevier Chapter 1, part 2: Embedded Computing High Performance Embedded Computing Wayne Wolf.
© 2012 xtUML.org Bill Chown – Mentor Graphics Model Driven Engineering.
Functional Verification Figure 1.1 p 6 Detection of errors in the design Before fab for design errors, after fab for physical errors.
© 2003 Fast-Chip. All rights reserved. 11/23/2015 3:37:34 AM RTL-Synchronized Transaction Reference Models Dave Whipp Fast-Chip Inc.
UML MARTE Time Model for Spirit IP-XACT Aoste Project INRIA Sophia-Antipolis.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Assertions Jean-Michel Chabloz. Assertions basic Idea We assert that a certain “thing” should be true. –If it is true, fine –If it is false, then we get.
Traceability: From Transactions to RTL Dave Whipp.
CSC480 Software Engineering Lecture 10 September 25, 2002.
ECE-C662 Lecture 2 Prawat Nagvajara
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Callista Enterprise Test Driven ESB Development Sofia Jonsson
Part A Final Dor Obstbaum Kami Elbaz Advisor: Moshe Porian August 2012 FPGA S ETTING U SING F LASH.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 4 Slide 1 Software Processes.
Exploiting Architecture For Verification Dave Whipp.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Writing, Verifying and Exploiting Formal Specifications for Hardware Designs Chapter 3: Verifying a Specification Presenter: Scott Crosby.
Problem: design complexity advances in a pace that far exceeds the pace in which verification technology advances. More accurately: (verification complexity)
ASIC Design Methodology
Designing Well-Structured and Scalable Models
Chapter 18 Maintaining Information Systems
Software Life Cycle “What happens in the ‘life’ of software”
Digital System Verification
Part 3 Design What does design mean in different fields?
February 25-28, 2013 DoubleTree, San Jose
ECE-C662 Introduction to Behavioral Synthesis Knapp Text Ch
Verilog-AMS Integration with P1800 SV Standard
Presentation transcript:

Stop Writing Assertions! Efficient Verification Methodology Dave Whipp – DVClub SV, August 2008

NVIDIA Confidential Todays Talk An Overview of Methodology Creation Methodology as User Interface Making ESL work as a Hardware Design Flow Evolution of a Interface Definition Language Transaction Level Assertions Transaction Level Debug

NVIDIA Confidential A HW Development Flow Big Paper Spec Design Verification RTL Testbench Checkers Tests Scoreboard Assertions C Model Synthesis Directed Random BFMs, TLMs Clocks, Resets Assertions ISS Model Coverage Debug Formal

NVIDIA Confidential User Model for Running Tests Build Testbench Generate Test Run Predictor Run DUT Compare Behaviors *

Part 1 Methodology Design

NVIDIA Confidential Purpose of a Flow Conceptual Framework Where do things live? How do things work? Keep out of the way Don’t make life difficult for people Define Metaphors Subtly influence future directions Anchor for Variation Give people something to complain about

NVIDIA Confidential Two Philosophies Conformity Emphasize Standardization Diversity Emphasize Innovation Synergy or Conflict?

NVIDIA Confidential Understanding Variation To understand what to standardize: you need to understand what not to standardize Personal Preferences Technical Aspects of the Designs Supporting Legacy Seeking the Next Big Thing

NVIDIA Confidential Personal Preferences Emacs! vi

NVIDIA Confidential Personal Preferences Choice of editor doesn’t affect others At least, not much Choice of scripting language has greater impact But is encapsulated A script’s users don’t see the implementation language Choice of HVL affects whole team Can’t write “E” tests for a “Vera” testbench! But a unit testbench isn’t seen by other units A good flow will allow encapsulation of preferences I can go to any unit and build & run its tests Enables rapid localization of infrastructure issues

NVIDIA Confidential Technological Differences

NVIDIA Confidential Technical Characteristics PCIEPCIE Video Frame Buffer Off-chip Memory Graphics Pipe

NVIDIA Confidential Reuse Vs Stagnation Reuse considered Good Avoid reinventing the wheel Build on the shoulders of giants Reuse invites Inertia Reuse can propagate dependencies Dependencies make things harder to change Resistance to change is known as inertia Inertia can lead to Stagnation Improper reuse accumulates dependencies Reused code that is not understood will bit-rot To avoid stagnation, inject agitation

NVIDIA Confidential Are Single Paradigm Projects Possible? Project 1 Unit A Unit B Unit C Project 2Project 3 Unit D Unit B Unit C Unit B Paradigm 1 Paradigm 2 Paradigm 3 time

NVIDIA Confidential Watch some Real Users Image courtesy of DAZ Productions

NVIDIA Confidential How to “Watch” Users Meetings and Discussions Coffee-Break Grousing Bug Reports Keep Track of Support Requests create FAQs VNC (Remote Desktop) Instrumentation

NVIDIA Confidential Build Time Distribution: 10,000 per sample

NVIDIA Confidential Build Time Distribution: 1000 per sample

Part 2 ESL for Transaction Design

NVIDIA Confidential A HW Development Flow Big Paper Spec Design Verification RTL Testbench Checkers Tests Scoreboard Assertions C Model Synthesis Directed Randoms BFMs, TLMs Clocks, Resets Assertions ISS Model Coverage Debug (BAD)

NVIDIA Confidential A HW Development Flow Big Paper Spec Design Verification RTL Testbench Checkers Tests Scoreboard Assertions C Model Synthesis Directed Randoms BFMs, TLMs Clocks, Resets Assertions ISS Model Coverage Debug (BAD)

NVIDIA Confidential A HW Development Flow (Better) RTL Scoreboards Synthesis Randoms Clocks, Resets Design Verification Testbench Small Paper Spec ISS ModelESL C Model Interfaces Assertions Directed Tests BFMs TLMs Validation Assertions Triage Debug Coverage

NVIDIA Confidential Who Writes Assertions? Designers Bottom Up Assumptions Verification Engineers Top-down Intent

NVIDIA Confidential Who Writes Assertions? Designers Bottom Up Assumptions Verification Engineers Top-down Intent Architects The Specification Top Down Assumptions Bottom Up Intent

NVIDIA Confidential Where to Write Assertions The RTL Inline Bound The Testbench Scoreboard Environment E.g. Post Process Log file

NVIDIA Confidential Where to Write Assertions The RTL Inline Bound The Testbench Scoreboard Environment Post Process Log files The Specification C Models (?)

NVIDIA Confidential Where To Write Specification Assertions Functionality Model Performance Model RTL Design

NVIDIA Confidential Where To Write Specification Assertions Transaction Model Performance Model RTL Design Correlation Model ISS Model Debug/Triage Model

NVIDIA Confidential Where To Write Specification Assertions Performance Model RTL Design Structural Model Transaction Model

NVIDIA Confidential Interfaces Vs State Two approaches to comparing models: Compare “Architectural State” Registers/flops within the design whose existence is required by the specification Compare externally visible behavior Compare interface traffic B. F. Skinner?

NVIDIA Confidential Birth of an IDL Interface Description Language Initially, a language just to define signals Interface a2b clock clk down U valid 1 up U busy 1 down U cmd 24 down U data 32

NVIDIA Confidential Evolution of an IDL Quickly added flow-control protocol abstraction Interface a2b clock clk flow valid_busy down U cmd 24 down U data 32 From this we can generate: Testbench components (BFMs: producers, consumers) Protocol Assertions …

NVIDIA Confidential Continued Evolution of an IDL Separation of packet structure from interface group SOP down U cmd 24 group MOP down U data 32 group EOP down U checksum 32 Interface a2b clock clk flow valid_busy packet SOP, MOP, EOP

NVIDIA Confidential Transaction Assertions in YACC valid_interface_traffic: | valid_interface_traffic transaction; transaction: begin middle end; begin: SOP; middle: | middle MOP; end: EOP

NVIDIA Confidential Cycle Level Assertions in SVA sequence valid_trans; (cmd==SOP) (##1 cmd != SOP && cmd != EOP) [*0:$] ##1 cmd == EOP endsequence a_well_formed_transaction: clk) cmd == SOP |-> sequence (valid_trans) clk cmd SOPEOP MOP

NVIDIA Confidential Transaction Level Assertions in SVA sequence valid_transaction; (cmd==SOP) (##1 cmd != SOP && cmd != EOP) [*0:$] ##1 cmd == EOP endsequence clk valid cmd SOPEOP MOP

NVIDIA Confidential Transaction Level Assertions in SVA event sample; clk) if (valid && ! busy) -> sample cmd == SOP |-> sequence (valid_transaction) clk valid busy cmd SOPEOP MOP

NVIDIA Confidential Transaction Level Assertions in SVA event sample; clk) if (valid && ! busy) -> sample cmd == BEGIN |-> sequence (valid_transaction) clk valid busy cmd SOPEOP MOP

NVIDIA Confidential Grammer using IDL assert “temporal representation” data SOP => past( EOP ) data MOP => past( SOP | MOP ) data EOP => past( SOP | MOP ) assert “bnf representation” bnf SOP -> MOP ** past( SOP.length-1 :sample( SOP ) ) -> EOP

NVIDIA Confidential Multi-Unit Assemblies AEBCDFG a2bb2cc2dd2ee2ff2g A simple pipeline

NVIDIA Confidential Multi-Unit Assemblies A E BC D F G a2bb2cc2d d2e e2f f2g Simple rearrangement

NVIDIA Confidential Multi-Unit Assemblies A E BC D F G a2bb2cc2d d2e e2f f2g Identify units with similar behaviors

NVIDIA Confidential Multi-Unit Assemblies BEBE CFCF D a2be be2cf cf2d d2be cf2g G A Extract common behavior into unified components be2cf === b2c + e2f

NVIDIA Confidential Reusing Interface Definitions AEBCDFG D G A BEBE CFCF How to maximize reuse between these two architectures?

NVIDIA Confidential Packets as Traffic Streams group b2c down U data 32 group e2f down U data 32 Interface be2cf clock clk flow valid_credit packet b2c, e2f

NVIDIA Confidential Time Units of Temporal Expressions Group b2c down U value 4 assert value != past( value ) Group e2f down U value 4 assert ( value == 0 ) => ( past( value ) != 0 ) Interface be2cf packet b2c, e2f assert b2c => ( b2c.value != past( b2c.value :sample(b2c) ) ) assert past( e2f && e2f.value == 0 ) => (b2c && b2c.value != 0)

NVIDIA Confidential Example RendererMemory

NVIDIA Confidential The Traffic group mem_write down U address 16 down U data 1 group sync down U shape 2 enum SQUARE, CIRCLE, TRIANGE, BLANK down U radius 3

NVIDIA Confidential Accumulate Memory State group mem_write down U address 16 down U data 1 assign mem[ x = ][ y = ] = past( data :sample( address == {x,y} ))

NVIDIA Confidential Add Predicates group_more mem_write assign is_circle[ r = 0..7 ] = “&&”( [ x = ] [ y = ] mem[ x+8 ][ y+8 ] == ( x**2 + y**2 <= r**2 ) )

NVIDIA Confidential Define the interface interface render2memory clock mem_clk flow valid_busy packet sync, mem_write assert “correct sync shape” sync && sync.shape == CIRCLE => past( mem_write.is_circle[ sync.radius ] )

NVIDIA Confidential Example RendererMemory assert “correct sync shape” sync && sync.shape == CIRCLE => past( mem_write.is_circle[ sync.radius ] )

NVIDIA Confidential Summary Efficient Verification Understand Variation Encourage Diversity avoid anarchy Encourage Standardization avoid stagnation Frontload The Schedule Provide Verification with Executable Spec (ESL) C Model, Correlation Model (pre validated) Interfaces, Transactions (definitions for code generators) Assertions, Testpoints (neutral language, pre validated)

Questions

NVIDIA Confidential Summary Architects should write assertions Validated assertions are input to Verification Assertions must be directly reusable across models Manual recoding invites errors Explicitly model the structure that is common to architectural models and to design Tie assertions to these common points

NVIDIA Confidential Threading Models Thread Follows Resource Traditional SystemC approach Thread Follows Transaction Think “Multithreaded ISS” Cycle-based Model The “Old” way of doing things A non-threaded version of “thread follows resource” Different models are convenient at various times But SystemC forces you to commit early to one approach Therefore need extra code for transaction level debug

NVIDIA Confidential 70% 70% of schedule is Verification What is correct figure 0% synthesize architectural models, constraints Correct by construction! 100% synthesize verification models, constraints no design needed!

NVIDIA Confidential Transactions Vs Cycles Data min_val (Addr a1, Addr a2) { Data d1 = mem_read(a1); Data d2 = mem_read(a2); if (d1 < d2) return d1; else return d2; } Address Data a1 d1 Pipelined Bus a2 d2 t1 t2 t3 t4 t5 t6

NVIDIA Confidential Unit Level System Testing Stage N-1 Stage N+1 Stage N Graphics Pipeline (Transaction Model) RTL Unit DIFF

NVIDIA Confidential New Challenges New Tools New Platforms New People New Ideas Refactoring Testability D.R.Y. Avoiding Stagnation