RTL Analysis and CDC Analysis for Maximum Design

RTL Analysis and CDC Analysis for Maximum Design Efficiency and Quality By Scott Calkins – scott. calkins@bluepearlsoftware. com SEFUW: Space. E FPGA Users Workshop

RTL Analysis and CDC Analysis for Maximum Design Efficiency and Quality • Efficiency and QUALITY - - - great words • Static analysis is where it’s at for Software these days • They’ve been doing it for more than 25 years with empirical proof of increased project efficiency and productivity with a side benefit of reusability • I’ve seen absolutely no evidence of this industry getting that memo • This industry appears to be behind the curve • Let me explain… © 2018 Blue Pearl Software Page 2

Our Problem Statement • FPGA and OTP developers follow a couple of traditional flows which are far from optimal • There are better methodologies out there, which can be borrowed from SW & ASIC designers, and which still fit within your project budgets • Satellite/Hi. Rel design and IP Development share common problems with ASIC development - Cost and Time • Everything in your most trusted devices are built with a much better philosophy, a philosophy that started back in the mid – 90’s … So how far behind the curve are you? Page 3 VERY . . .

Traditional Flows • FPGA • Spec Code Testbench Simulate Synthesize Lab Debug • Testbench covers enough to get into the lab and use Logic Analyzers • ASIC • Spec Code Static Analysis Source Code Control Testbench / UVM Simulate FPGA Prototype ASIC Synthesize Equivalency / Formal Analysis Place and Route STA Massive Back End Work from Layout to DFT • Formal verification is an ENORMOUS undertaking • Most everything after simulation has no place in FPGA designs other than Synthesis, Place and Route with the supplier provided tools • And there is no back end work per se Page 4

Lessons Learned • High Reliability and Satellite designs require a little bit of the ASIC methodology • … but not too much • Static Analysis and Source Code Control are mandatory • Static Analysis finds many problems that Simulation May Not find • There is plenty of empirical evidence to point to testbenching NOT handling problems or showing these mistakes • The effort, energy and time it takes to set up UVM verification means that EVERY ASIC must perform static analysis to protect their simulations from non-functional coding issues Page 5

Verify As You Code . • The problems that commercial ASICs face are that once a device is built, it’s now a minimum of $15 Million for NRE, plus a loss of up to a half a year to restart the process • What is worse, the time or the money? Ask Samsung about their Note problems • Therefore, they have evermore rigorous testing. Simulations that last up to a week or more, and scores of them that run in parallel • This simulation effort is the rationale for Static Analysis. 65% of all simulation bugs found are because of careless human problems Page 6

More Than Stupid Human Problems • We in the EDA industry understand that oversimplification is needed to explain things in a standard “Elevator Pitch” • But it’s far more than that • Static Analysis finds Structural problems, problems that can by found by careful inspection of the code, as it is being read into a tool • Then Symbolic Analysis can be run on a database of pure gates • ATPG Algorithms are a key aspect of this analysis • Think of it as database analysis Page 7

Simple Examples of FPGA Structural Issues • Timing Closure issues • • • Combinational loops Reset conditions Long if-then-else Large Conditional operators Infinite and zero-count loops • Other issues • • Page 8 Previously assigned registers and signals Missing Asynchronous Reset Deassertion Missing resets in general Non-synthesizable constructs © 2018 Blue Pearl Software

Serious Code Violations • Combinatorial loops are just deadly • Simulation of these are very difficult to identify – How would you find them? • FSM mistakes • • Unreachable States Terminal States Missing Case Items Undefined States with no assignments Lack of ‘catch all’ statement SEU mitigation with two-variable FSM Types How much development time does it take to create a testbench that identifies these? How much Analysis time does this take What if I told you that this can be done instantly? ! Page 9 …

More Serious Code Violations • Code with missing connections • Driven nets and pins with no loads • Undriven nets and pins that are loaded • Floating buses • Delay statements • Just a 20 year old practice that is out of date and FLAT OUT WRONG • Initialization statements • Do you know that these go into the Bitstream!!!! • This means that initialization is TOTALLY different than global reset conditions Page 10

Clock Domain Crossing Analysis • How can this best be done? • How do you find these with simulation? • What role does STA play? • Do the FGPA Vendors really help? Page 11 © 2018 Blue Pearl Software ….

Clock Domain Crossing Resulting in Metastability • Random or intermittent issues, nearly impossible to recreate • Debugging with simulators and lab benches is virtually impossible • Synthesis and STA cannot identify exact issues • Unexplained field failures • Defies careful and accurate measurements Wilson research reports Clocking/CDC Errors are the #2 cause of respins Blue Pearl Software presented this at the 2017 Design Automation Conference Come and see the demos this week Page 12 © 2018 Blue Pearl Software . .

Analysis Run On Space. Wire • Recently, in 2017, separate projects at separate companies, the Space. Wire core was inspected with a Static Analysis Tool using a mix of Structural Analysis, Symbolic Simulation and Deterministic Formal Verification rules • Both designs displayed a number of problems in their own State Machine designs, and a litany of others found via Structural Analysis. • Then more than 3 dozen Clock Domain Crossing errors were found. • These designs are still under analysis © 2018 Blue Pearl Software Page 13

Space. Wire Core Program Analysis - Post Sim • • • Finite State Machines Problems Undriven signals connected downstream Undriven signals in general Wait statements Uninitializable DFFs Missing If-Block Assignments Lack of Deassertion for Asynchronous reset Dozens of CDC mistakes Reconvergence of synchronized CDCs These were considered “Flight Ready” How “Flight Ready” is your design? © 2018 Blue Pearl Software Page 14

BPS Please come and find me this week END Page 15