In-System Debugging for Design Verification

1. In-System Debugging for Design Verification Mark Beardslee, Synplicity Inc.

2. The Goal: Improve PLD Design Reliability • A Unique Design Verification Methodology: • Enable visibility into the operation of the design under these conditions: • Verify the design in the target system – “In-System” • Verify the design at the target speed – “At-Speed” • Verify the actual design source code – “HDL-level”

3. Design Verification for Reliability “In-system” – Use real world stimuli • No errors in modeling the function or timing of the environment “At-Speed” – Live, full speed testing • No errors environment modeling due to slowing the system • High throughput for extensive testing “HDL-level” – Test at the level you design • No errors in translating to/from HDL and gate level for testing and debugging

4. Modes of Operation Testing: • Repeatable tests on live hardware – use internal visibility to capture the system state under specific conditions. • Compare with “golden” results. Note: the tests run at design speed, so they can test long sequences of states which would be too time consuming using a simulator. Debugging: Use internal visibility to develop an understanding of the design behavior

5. Practical Requirements • Goal: No special hardware required No hardware external to the PLD No high-speed links No Special cables This requires the verification system to: Use an existing PLD channel to communicate • A user accessible JTAG link exists on most PLDs • Standard JTAG configuration cables are readily available. • Goal: No impact on the logical behavior or timing of the design being verified • Verification hardware must only sink signals from user design • Critical timing path must NOT go through verification HW

6. Implications of Using JTAG Channel JTAG is Slow (1 to 10Mhz) Therefore: no continuous data streaming from the PLD Implication: Must capture sample data in on-board RAMs and then upload to the host machine But… On-board RAM size is limited Consequently, the sample depth is limited Therefore: we must precisely control when the data is captured This is accomplished by triggering the sample capture from • The state of the data signals • The state of the design control flow Defining the triggering from the HDL description is key Because it gives the necessary precision of control

7. Design to be verified Verification Logic Host Computer System Hardware Schematic PLD Verification hardware consists of: • JTAG Communication block • Verification logic • Data Sampler • Sample Controller JTAG Comm. block

8. Schematic of Verification Logic HDL data Signals Trigger Logic cone: • Enforces conditions on all trigger-able data and control signals • Is run-time configurable Sampler Controller Combines trigger events across time for complex trigger behavior Continuous Sample Buffer in RAM Sampler Controller Trigger Logic HDL Control Signals Overview

9. PLD Requirements The PLD Must: • Contain large amounts of on-board RAM • Contain an interface to JTAG communication • Contain clocking resources for the verification HW The PLD ideally should: Be reprogrammable – may want to test/debug many times Candidates: Volatile - Actel ProASIC family (Currently supported) As well as other vendors volatile devices Non-Volatile – Actel Accelerator (future)

10. Synplicity Identify™ - Verification System Components • The Instrumentor Compiles and inserts logic into design • The Debugger The runtime controller • Communicates to FPGA • Configures triggering • Displays data • The On-Chip Hardware Called the IICE (Intelligent In Circuit Emulator) • Communications Controller • Triggering Logic • Data Storage Buffer

11. The Design Flow • Read RTL into the Instrumentor Create modified RTL based on user selections • Synthesize, Place & Route • Use the Debugger to view the In-System operation of the design Identify™Instrumentor RTL Source Synthesis P&R Identify™Debugger Overview

12. The Identify™ Instrumentor Takes a complete HDL design • Parses the design to determine all potential data signals and control-flow triggers • Presents the annotated design to the user • Gives estimates of area usage as the designer specifies the Instrumentation • Creates a modified version of the HDL design which incorporates the desired instrumentation hardware

13. Instrumentor - Select Signals Click on signal ID to: • Sample signal data • Use signal as trigger Estimate of area added to design Identify Instrumentor

14. 1 2 3 Instrumentor – Control-flow triggers • Control-Flow Triggers are based on HDL activation regions Interpretation of Trigger: HDL Code PROCESS (a, b) BEGIN CASE a IS WHEN read_state => IF b = “100110” THEN o <= “110”; END IF; WHEN OTHERS => o <= “000”; END CASE; END PROCESS; Trigger when: a == read_state a == read_state && b == “100110” a != read_state Identify Instrumentor

15. Instrument a Control-Flow Trigger Click on radio button to make Control-Flow trigger available for debugging Estimate of area added to design Identify Instrumentor

16. The Identify™ Debugger The Debugger interacts with the In-System, At-Speed instrumented design at runtime • Displays the HDL design with the annotated instrumentation • Allows triggers to be graphically or texturally specified • Runs to collect data: • Download trigger configuration • Wait for trigger event to occur • Upload the captured data and translate to HDL format • Display data imbedded in the HDL code or in a waveform

17. The Debugger – Set a Data Trigger • Select Signal • Enter one or two value expressions to trigger • One value to trigger when that value is reached • Two values to trigger on a transition Identify Debugger

18. Summary The Synplicity Identify™ system has been described which: Allows debugging/testing an HDL design implemented in a PLD while the PLD is in its target system, running at its target speed. For ease of use and reduction of errors, all interaction with the design is done through an interface based on the original HDL design. This capability can increase reliability by ensuring that the design is thoroughly tested with real-world stimulus and while running at the target speed in the target system. Potentially error prone data translations are handled automatically.