1 / 42

Methods to Differentiate Mil/Aero Solutions Using FPGAs

Methods to Differentiate Mil/Aero Solutions Using FPGAs. Dan Gardner. Final MAPLD Presentation. Agenda. Why FPGA technology is important Technology to consider for FPGA EDA software Why you need these for Mil/Aero FPGA. FPGAs overtake ASICs in Mil/Aero Segment. Source: Gartner Dataquest.

genera
Download Presentation

Methods to Differentiate Mil/Aero Solutions Using FPGAs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Methods to Differentiate Mil/Aero Solutions Using FPGAs Dan Gardner Final MAPLD Presentation

  2. Agenda • Why FPGA technology is important • Technology to consider for FPGA EDA software • Why you need these for Mil/Aero FPGA Gardner MAPLD 2005/P145

  3. FPGAs overtake ASICs in Mil/Aero Segment Source: Gartner Dataquest Gardner MAPLD 2005/P145

  4. FPGAs overtake ASICs in Mil/Aero Segment Source: Gartner Dataquest Gardner MAPLD 2005/P145

  5. Requirements for FPGA software in Mil/Aero • Cost effective delivery of mission performance • Initial Creation • Cost and speed of design • Predictable time to market at fixed cost • Fast iterations • Timing and system closure • Complete Verification • Commercial FPGA often skips many verification steps • Some Mil/Aero applications have additional considerations • Maintenance of Project • Cost of life cycle maintainability of design • Support of standard platforms • Support Mil-preferred devices, documentation and flows Gardner MAPLD 2005/P145

  6. FPGA Technologies are Very Competitive • Many FPGA selections available • High-performance choices • Altera Stratix II/GX • Xilinx Virtex-4 • High-volume choices • Actel ProASIC3/3E • Altera Cyclone II • Lattice LatticeEC/ECP • Xilinx Spartan-3/3E • Radiation Tolerant choices • Actel RTAX-S • Xilinx QPro Gardner MAPLD 2005/P145

  7. Widespread Use in Mil/Aero • Complex applications require latest FPGA technologies • Software defined radio • Platform-based computing • Reconfigurable computing • DSP algorithms in hardware co-processors • On the other end of the spectrum are the radiation tolerant devices • Low volumes fit FPGAs better than ASICs in many cases Gardner MAPLD 2005/P145

  8. Technologies to Consider • All technologies listed below are required to build a complete methodology and will be covered • This presentation will essentially focus on the unique requirements of Mil/Aero FPGA applications: • Rule checker with platform-independent coding styles • Design management • RTL + physical synthesis • I/O design with integration path to PCB • System-level design • Verification • Electronic System-Level (ESL) Overview • Assertion based (CDC to validate SEU protection) • Coverage Driven • Clock domain crossing (CDC) • Embedded systems Gardner MAPLD 2005/P145

  9. Rule Checkers Static Design Checking for VHDL/Verilog RTL • Encapsulate knowledge: • Expect built-in checks from standard sources • Reuse Methodology Manual • FPGA vendor recommendations • Must allow quick customization for your own checks • Use Early and Often: • Perform checking interactively or in batch • Understand the causes of violations • Easily interact, organize, & track violations • Interactively trace & fix violations • Share knowledge: • Share checks with the team/company • Allow any designer to apply accumulated knowledge • Export results for reporting Gardner MAPLD 2005/P145

  10. Put a Senior Designer on Everyone’s Shoulder • Do not re-learn from the same mistakes over and over again • Code Browser indicates errors & warnings • Code lines highlighted • Hover help for each violation • Step through errors • Trace to graphics • Show rule/rule help • Rerun analysis Gardner MAPLD 2005/P145

  11. Design Simulate Process Automation Version Management FPGA Vendor P&R Synthesize Designing in Teams • Progressive development, validation, implementation • Designers work in parallel, from RTL  placed gates • Top-down & bottom-up methodology freedom • Supports team standards • Code, graphical appearance, tool preferences, design flows • Manages multiple versions of the design • Long design existence requires reproducible flows • Multiple contracts on single, long-term projects require comprehensive, customized design management tools Gardner MAPLD 2005/P145

  12. Visualization for Design Reviews & Reuse • Strict documentation and traceability rules dominate Mil/Aero design • Effective implementation of IP reuse • Minimize additional design for reuse time • Automate processes and policies to design IP • Minimize design time to include IP • Automate analysis of IP for fast implementation Gardner MAPLD 2005/P145

  13. Design and IP Reuse Flows • FIRM macro blocks enhance design productivity at physical implementation level • Achieve predictable results for FPGA fabric family • Seamless porting between like-family FPGA devices • Helps in easy verification Gardner MAPLD 2005/P145

  14. Platform FPGA Technology vs. Pushbutton FPGA Design Flow • Major technology changes in platform FPGA • More gates per part • Specialized embedded technology • Specialized interconnect • High-speed device effects • Emerging design challenges • Design debug process is unreliable for complex designs • Harder to bring quality product to market quickly • Harder to manage flows: • Design reuse & IP integration • Harder to predict development costs Gardner MAPLD 2005/P145

  15. Before Physical Synthesis After Physical Synthesis Control for Complex Requirements • Fully integrated RTL synthesis and physical synthesis capabilities • Enhances RTL Synthesis • Takes physical considerations into account • Linking physical data with logic synthesis • RTL to placed gates • Improves productivity by enhancing design analysis • Cross selection between RTL code, schematic, physical and timing views • Physically aware IP and design reuse • Improves time to design completion • Improves performance by interactively optimizing the placed design Gardner MAPLD 2005/P145

  16. Advanced FPGA Methodologies Physical Awareness Fulfills Key Technology Needs • Placement reuse/ECO • Add new functionality safely • Add/change RTL code w/ minimum placement impact • Divide and conquer approach • Meet challenging design requirements quickly • Isolate & optimize tricky portions of circuitry Gardner MAPLD 2005/P145

  17. System Design Trends Average FPGAs on a single PCB Average pins of largest FPGA Almost half of all PCBs with FPGAs have multiple FPGAs per PCB Many FPGAs now over 500 pins 2004 EDA Study Gardner MAPLD 2005/P145

  18. Isolated Flows with Manual Integration • FPGA & PCB teams typically don’t communicate well • All information entered and synchronized manually • Package, speed-grade, pin assignments • Information must stay consistent in three locations • FPGA, PCB schematic, PCB layout Gardner MAPLD 2005/P145

  19. HDL FPGA  PCB Designer Issues Best location to meet Board constraints • The FPGA must work on the board and the overall system must work • Each design engineer has his own constraints to achieve • May be in conflict/unsupportive of partner designer • Need to converge on a trade-off acceptable to both parties Best location to meet FPGA constraints Gardner MAPLD 2005/P145

  20. Design Languages & Tasks Task Language Text / UML Requirements Architectural Analysis tools aren’t … C/C++ Untimed SystemC Algorithm Exploration Transaction Level SystemC Architecture Analysis …adopted by RTL Designers Verification VHDL Verilog RTL Design Gardner MAPLD 2005/P145

  21. Design Languages & Tasks Task Language Text / UML Requirements HVL’s Extend & Accelerate the RTL Design Process C/C++ Untimed SystemC Algorithm Exploration Transaction Level SystemC Architecture Analysis System Verilog Verification Assertions PSL/SVA VHDL Verilog RTL Design Gardner MAPLD 2005/P145

  22. Design Languages & Tasks Task Language Text / UML Requirements …and enable RTL Designers to cross the chasm to system level design C/C++ Untimed SystemC Algorithm Exploration Transaction Level SystemC Architecture Analysis System Verilog Verification Assertions PSL/SVA VHDL Verilog RTL Design Gardner MAPLD 2005/P145

  23. C Synthesis • Typical end user: hardware designer • Developing compute intensive designs • Have existing C functional models • Typical Applications • Wireless, satellite communications; video/image processing • Automatic frequency control (AFC), clock tracking • Viterbi, turbo decoder, Reed-Solomon • FFT, DCT, FIR filters Gardner MAPLD 2005/P145

  24. What C Synthesis Delivers • Untimed C++ synthesis • Technology independent source focused on true functional intent • Connects system to hardware design domain • Micro-architecture “what if” analysis • Interface “what if” analysis • SystemC compatible • No proprietary extensions • Automated RTL creation • Algorithm and data path analysis • Faster verification Gardner MAPLD 2005/P145

  25. Why SystemVerilog for Design? • Encapsulation allows designers to model at more abstract levels • Scalability makes incremental design changes simpler • Code re-usability increases design efficiency • Easier to model accurate, synthesizable modelsof any size designs • Not only system-level designers need SystemVerilog • Both Synthesis and Simulation benefit from SystemVerilog Gardner MAPLD 2005/P145

  26. Summary of SystemVerilog Design • SystemVerilog increases productivity for both synthesis and simulation • Can use existing VHDL and Verilog modules mixed with SystemVerilog • Interface features: • Ability to encapsulate functionality as well as connectivity • Ability to replace a group of names by a single name • New concise and powerful implicit port connection features speed design entry and provide early type checking • Allows designers to take advantage of new abstract architectural models • Allows designers to insert assertions directly into RTL code Gardner MAPLD 2005/P145

  27. 20x (2 days!!) 10,000x (1 min) Functional 1,000x Structural 100x Transaction 10x 2x (2 weeks) Cycle 1x (7 days) 1x (5 weeks) RTL Abstraction Drives Design Productivity Implementation Simulation Source Algorithmic C++ Untimed TLM SystemC Timed TLM SystemC Cycle Accurate SystemC RTL Gardner MAPLD 2005/P145

  28. Automatic Generation of Verification Infrastructure • Facilitates the Verification of the synthesized design • The original C++ testbench can be reused to verify the design • RTL or Cycle Accurate • SystemC, VHDL or Verilog • Transactors convert function calls to pin-level signal activity • Pushbutton verification solution includes Makefiles and Simulation scripts Original C++ Testbench Transactor RTL Original C++ Algorithm Transactor Comparator Golden results DUT results Gardner MAPLD 2005/P145

  29. Quickly produce RTL code from algorithmic specifications Regardless of the quality of the architecture Run RTL synthesis and P&R with integrated tool flows Validate the functional correctness of the algorithm on FPGA prototyping boards Architecture optimization can be pursued in parallel Exhaustive Algorithm VerificationWith Automated Real Time Prototypes ? Algorithms C Code Constraints Catapult C Synthesis Precision RTL Synthesis RTL Code Constraints FPGA Vendor P&R Netlist Constraints  Prototyping Gardner MAPLD 2005/P145

  30. Functional Flaws Driving Need for Re-Spin …the Problem is Getting Worse Source: 2004/2002 IC/ASIC Functional Verification Study, Collett International Research, Used with Permission Source: 2004/2002 IC/ASIC Functional Verification Study, Collett International Research, Used with Permission Gardner MAPLD 2005/P145

  31. Methodology Explosion Targeting Verification • Assertion-based verification • Functional coverage • Constrained-random testing • Coverage-driven verification • Dynamic-formal verification • Transaction-level verification • Model checking • And more . . . Gardner MAPLD 2005/P145

  32. SystemVerilog for Verification • SystemVerilog is a complete Verification Language • Can be used with VHDL • Stimulus generation capabilities • Dynamically configurable constrained-random value generation • Ability to generate constrained-random stimulus sequences • Ability to randomly select control paths (test scenario selection, etc.) • Functional coverage modeling • Measure the verification quality and test effectiveness • Dynamic reactivity with constrained-random stimulus generation • Assertion-Based Verification • Property specification • Assertion & coverage monitoring • High-level modeling (programming) capabilities • Efficiently and effectively model the operational environment • Develop reusable verification environments Gardner MAPLD 2005/P145

  33. Assertion-Based VerificationAssertions Enable Higher Quality Designs Reference Model • Assertions provide observability for higher complexity designs • ABV makes assertions a key element, ensuring that design properties are not violated • Assertions describe (un)desired behavior • Assertions dramatically shorten debug and repair time • Assertions stay on during block, chip and system-level tests • Finds bugs you weren’t looking for Bus Monitor Bus Monitor Assertion Checkers Assertion Checkers Gardner MAPLD 2005/P145

  34. Coverage-Driven Verification • Verification is effectively metric-less • Few designers know if their strategy is adequate or efficient • Sign-off criteria are ad hoc and vary by company • Code coverage is not a functional verification metric Gardner MAPLD 2005/P145

  35. Expect Widespread Use of Coverage-Driven Verification • PSLand SystemVerilog provide coverage constructs • Simulators integrating functional coverage to improve performance and debug • New test strategies require functional coverage • Random and constrained random tests need coverage to determine what they tested Gardner MAPLD 2005/P145

  36. Clock-Domain Crossings • Incorrect handling of Clock-Domain Crossing (CDC) signals is the 2nd major cause of re-spins • Traditional verification techniques do not work for CDC signals • CDC problems are subtle, will occur in hardware, and are complex to debug Assertion Synthesis automates CDC verification, significantly reducing the risk of CDC-related silicon re-spins Gardner MAPLD 2005/P145

  37. Common CDC Myths • Adding correct synchronizers on all paths is all that is needed • Even if implemented perfectly, protocol errors and reconvergence error will still exist • I can detect protocol violations by sweeping clocks in my simulation • Is very reliant on luck, and will only detect a small subset of errors • I use special synchronizers that add a random delay, so I am covered for reconvergence • This only works for paths that contain synchronizers, and lacks the automation and coverage necessary to significantly reduce risk. A complete CDC solution MUST verify the structural correctness, transfer protocols, and deep sequential reconvergence, otherwise bugs WILL be missed Gardner MAPLD 2005/P145

  38. Platform FPGAs Need a Complete Flow Hardware Software Platform Studio IDE Platform Exp ASAP Precision Synthesis Inventra Stacks Code|Lab ISS Seamless Modelsim BSP ISE Tools Microtec Nucleus XRAY SW-HW OnChip Debug Chipscope PCB, Signal Integrity Tools Gardner MAPLD 2005/P145

  39. Supports: Edit/Compile/Verify Eliminates: Edit/Synthesize/ Implement/Download/Verify Promotes: Superior Visibility and Control Evaluation Board Seamless FPGA Co-Verification HW/SW Co-verification: Faster Iteration Loop Without Co-verification With Co-verification HDL Entry HDL Entry HDL Compile Synthesis Implementation Download Bitstream Into FPGA Gardner MAPLD 2005/P145

  40. Executable and Translatable UML solution generates embedded code Eclipse-powered complete, integrated development tool suite Prototype wholesoftware application Source code, royalty-free RTOS & middleware Processors Require SW Tools Embedded software to cover it all UML Suite Dev Tools Prototyping Middleware RTOS Gardner MAPLD 2005/P145

  41. Support for Processor-based FPGAs • RTOS support for both Xilinx MicroBlaze and PowerPC architectures and Altera NIOS, NIOS II and ARM architectures • Target software debugger and build environment • Support for Xilinx Spartan3, Virtex II Pro, and Virtex-4 and Altera Cyclone II and Stratix II • Embedded software suite for FPGA system design must include complete tool offerings and target software platform, including high-level modeling with xtUML and advanced target software debugging environment. Gardner MAPLD 2005/P145

  42. Summary • With engineers from software, hardware and system disciplines all converging on FPGAs, it is important to focus on the methods that can help differentiate your solution from others. • It is necessary to use all the basic verification and design tools, but there are new technologies emerging that can better address the unique requirements of Mil/Aero applications. Gardner MAPLD 2005/P145

More Related