mastering fpga design through debug, adrian hernandez, xilinx

Mastering FPGA Design through DebugDesign through Debug

Adrian HernandezAdrian Hernandez

Xilinx Confidential – Internal21 May, 2010

Agenda

Introduction – Why is Debug important? Incremental Design & Debug System Integration

M f t i d i th fi ld t t Manufacturing and in the field test Conclusion

© Copyright 2010 Xilinx

Introduction – Why is debug important?

FPGA DebuggingFPGA Debugging ChallengesDebug ToolsDebug ToolsMain source of

bugs: Designbugs: Design


FPGA Debugging Challenges

Larger Devices enables more system integration – Drives up on-chip complexity– More clock domains on single FPGA– More 3rd party IPMore 3rd party IP

High speed serial links now standard with FPGAs– Simplifies Chip-Chip signaling– Signal integrity issues complicated by multi-gigabit links– Serial protocol necessary for communication

Cost and Power Challenges– User applications demanding lower power– Cost sensitive solutions needed– Customers demanding more individualized features


Customers demanding more individualized features

Debug Tools

Simulation– HDL Simulators– SPICE– Cycle accurate simulation models

On-Chip Instrumentation– Logic Analyzers– Input / Output drivers/monitors– Assertion monitors– Synthesized transaction generators and checkers

Off-Chip Instruments– Voltage Meters– Oscilloscopes– Logic Analyzers


– Protocol Analyzers

Design bugs originate from designs

Tools do not solve the debugging challenges Root source of bugs is in the design Use debug tools concurrently while designing

Design using controlled incremental changes– Design using controlled incremental changes– Verify, measure and analyze these changes– Build efficient and tight design and test iterations– Verify FPGA design in-circuit early and often


Agenda




Incremental Design & Debug

IDD Fundamentals Unit test and debug Code refactoring


IDD Fundamentals

Test driven design– Equal importance to test and design development– Design planning through test development– Perform upfront in-circuit FPGA verificationPerform upfront in circuit FPGA verification

Add design changes incrementally– Learn from your mistakes– Take measured risks with smart code refactoring– Design exploration throughout development cycle


Unit test and debugFunctional behavior assertions

Document the core function of the module/entity– Plainly describe the unit’s function

Identify proper operation assertionsCreate guide of correct transaction operation– Create guide of correct transaction operation

Create test case definitions that drive assertions– Focus on triggering and validating assertions

Design in assertion verification– Use your language constructs to build in assertion checking– System Verilog assertion creation is not essential, but helpfuly g , p


Unit test and debugUnit testing on an FPGAg

Perform early testing on FPGA platforms Unified simulation + hardware verification

– Goal: Simulation matches hardware tests

Invest and reuse test infrastructure Invest and reuse test infrastructure– Create reusable test components– Target test components for simulation AND hardware– Reuse test library to speed unit development– Build reusable test configurations


Unit test and debugExperiment Analysisp y

Create custom GUI views to debug circuits Save views and create basic unit screenshot documentation Experiment with debug tools

Interactively confirm your design assertions– Interactively confirm your design assertions– Use manual experiments to develop efficient regression tests


Unit test and debugRegressions as debug aidsg g

Use regression failures to analyze results– These failures should give clues where to find a bug

Incorporate regression analysisBuild analysis tools for test result processing– Build analysis tools for test result processing

Incorporate regressions into your check-in process– Use unit regressions often– Exercising regressions is part of check-in process


Unit test and debugFPGAs based regressionsg

Unit design must target an FPGA– Identify an FPGA to target– Use a development boards for pre-proto testing

Have at least one test execute in hardware Have at least one test execute in hardware– Unit design will run in-circuit independent of the system

Strive to emulate simulation verification in-circuit– Simulation should not exclude developing a hardware testing

FPGA regressions run at check-in– Unit design should always synthesizeg y y– Unit design should always implement on target FPGA


Refactor

Clean up code and variables for maintainability Optimize for power/performance goals Take measured risks

Try new solutions verify with unit tests– Try new solutions, verify with unit tests– Experiment “breakthrough” ideas throughout the design cycle

Refactor the unit design often– Strive to always have the new code better than the original


Incremental Design & Debug

IDD Fundamentals– Plan for success with tested incremental changes

Unit test and debugDesigning for high quality and low maintenance– Designing for high quality and low maintenance

Code refactoring– Plan for design breakthroughs!


Agenda




System Integration

Build on known good IP Focus on the IP interface Use unit test harness

Si l ti + FPGA Simulation + FPGA Learn from mistakes


System IntegrationBuilding on IPg

Always build on known good IP– Unit testing ensures good IP– Use only trusted 3rd party IP

Assume IP has been tested Assume IP has been tested– Assume that checked-in IP was fully tested– Assume 3rd party was fully verified

System design is all about IP block connections– Wiring is all that should be at the system level– Complex functions exist in sub-units– Avoid adding “quick-fixes” at the system level


System IntegrationFocus on IP interface

Debug and verification of interfaces– Focus is not on the verification of the IP blocks

Concentrate on transaction level operations Only verify basic IP functional correctness Only verify basic IP functional correctness

– Treat IP as a black box function processor

Cover extreme system cases for system level metrics– Power measurement– Clock jitter– Signal integrityg g y


System IntegrationUse unit test harness

Fix unit tests– Interface verification may occasionally find unit bugs– Unit tests should be updated to catch bugs found

3rd party IP may require separate unit test 3 party IP may require separate unit test– 3rd party IP bugs should have separate unit tests– Unit tests are used for fixes or workarounds from vendor

Reuse unit level infrastructure for deeper IP block debugging– Debug unit bugs by using the unit tests– Don’t debug unit issues at the infrastructure


System IntegrationSystem + FPGAy

Create an efficient system simulation environment Use FPGAs to get accurate system results Build in-circuit system level regression tests


System Integration : Simulation + FPGASimulation Environment

Use transaction verification methods / tools (ex OVM) Simulate basic and random scenarios Use simulation to experiment special conditions

Ex: Cross clock domain crossing– Ex: Cross clock domain crossing– Ex: Min/Max conditions

Have "experimentation-ready" setups– Create configurations for running in-circuit scenarios in simulation


System Integration : Simulation + FPGAIn-circuit Verification

Verify on prototype board– Reproduce bus transactions similar to simulation– Create system DFT blocks– Use test tools scripting to build system regression testsUse test tools scripting to build system regression tests

Measure and analyze design margins– Manually measure the design margins– Create test harness that allows you to run in-circuit regressions


System Integration : Simulation + FPGARegression testingg g

Build regression on FPGA reconfiguration– Create multiple designs to validate sections the system– Accelerate long simulation tests by running in-circuit

Turn your experiments to regression tests Turn your experiments to regression tests– Seek to turn system measurement and analysis into regressions

Run your system level test regularly– Use board farms to help run parallel in-circuit tests– Build test frameworks for easy addition of in-circuit tests


System IntegrationLearn from mistakes

Extend testing to cover bugs found Update specifications to reflect actual implementation Share your IP, share your wisdom!

Encourage reuse across projects and teams– Encourage reuse across projects and teams– Have open discussions on lessons learned


System Integration

Build on known good IP– IP blocks design strives to be ready for system integration

Focus on the IP interfaceSystem integration main goal is to join IP blocks– System integration main goal is to join IP blocks

Use unit test harness– Enables faster debug and more “what if” exploration

Simulation + FPGA– Transaction methods simplifies and accelerates verification– In-circuit verification improves quality and speed regression testingp q y p g g

Learn from mistakes– Always improve the design and your knowledge


Agenda




Manufacturing and in-the-field testManufacturing successg

Create multiple designs for fast board verification– Non-scan based verification running at speed– Covers more than connectivity faults

Validate high speed serial links independently Validate high speed serial links independently– Ex: serial exercisers like Xilinx IBERT– Use protocol based reference designs re-targeted for your board

Verify system connectivity– Test memory interfaces with specialized IP/SW exercisers– Test bus connectivity through basic bus exercisers

Perform quick measurements for accurate margin analysis– Ensures high quality for customers

Catch performance issues from multi source part vendors


– Catch performance issues from multi-source part vendors

Manufacturing and in-the-field testLower support costspp

Convert manufacturing tests to in-the-field tests Use special test modes to load verification FPGA bits Incorporate return codes into customer support guide

D i f db k i t i th fi ld t Design feedback into in-the-field support– Use test results to improve verification– Regularly meet with product support– Seek to reduce support cost


Manufacturing and in-the-field test

Manufacturing– Improve product quality from the design

In-the-field testReduce product lifetime costs through better design– Reduce product lifetime costs through better design


Agenda




Conclusion

Build on FPGA reconfiguration– Keep the customer happy– No regressions! Always improve the product!– Add features in incremental steps use IDD to the fullestAdd features in incremental steps, use IDD to the fullest


Conclusion

Build on FPGA reconfiguration Take advantage of in-circuit test

– Use on chip debug tools for in-circuit testExtend create and reuse your in circuit tools– Extend, create and reuse your in-circuit tools

– Incorporate regressions into product


Conclusion

Build on FPGA reconfiguration Take advantage of in-circuit test Seek design perfection, seek design simplicity

Any intelligent fool can make things bigger more complex and moreAny intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction. —Albert Einstein


Conclusion


A b tif l i d A beautiful mind– Reuse and share your debug and testing IP– Share your knowledge and experiences


Conclusion


A b tif l i d A beautiful mind– Reuse and share your debug and testing IP– Share your knowledge and experiences

Buddhist Saying:“To kno and not to se is not et to kno ”“To know and not to use is not yet to know”


Mastering FPGA Design through Debug

Th k !Thank you!


References:

Xilinx market solutions development IP and boards– http://www.xilinx.com/esp

Xilinx ChipScope Analyzerhttp://www xilinx com/chipscope– http://www.xilinx.com/chipscope

OVM– http://www.ovmworld.org

Agilent– http://www.agilent.com/find/9000


mastering fpga design through debug, adrian hernandez, xilinx

Technology