FPGA debugging challenges

1. Challenging to debug immediately after unexpected failure

• Requires several trials and errors to find the appropriate trigger condition

• Takes time with the re-synthesis and P&R to identify the timing of the failure

2. Takes time to debug while reviewing the system level operation because of limited time window for waveform depending on BRAM availability, which makes the trigger condition complicated

VSTAR solution with automatic failure analysis

1. Immediate debugging after a failure happened to be encountered in a consecutive operation even after several days

  • Automatically creates the rules from the sequence of signal states transition
  • Automatically generates the internal trigger as an error by monitoring FPGA with the rules
  • No user trigger conditions required

2. Debugging with system level chart and narrowing down to detailed signal waveforms by simultaneously acquiring system level operation and detailed signal waveforms

3. Observes system level behavior up to 100,000 x longer than other solutions by only recording the information of signal change points, which greatly improves the usage efficiency of BRAM

4. Consists of on-chip verification IP and proprietary GUI

  • Automatic configuration and implementation of the IP to user design using GUI
  • Supports the selection of probed signals, change of settings for buffer size, etc.
  • GUI communicates with the IP via JTAG which can be shared with Xilinx Vivado.

Application example for state machine / timeout error

VSTAR detects unusual state transitions with the auto-generated rule from signal states transitions and the timing intervals.

1. State machine monitoring for unusual transition detection

2. Time-out error detection in a certain period of time

3. Stall detection in a certain period of time

Application example for system-level debugging

This is an example of displaying long-term system-level operation and detailed signal waveforms at the same time for debugging a system where software is executed by a CPU to control the entire system. By probing the value of the CPU address bus and the signal indicating the operating status of the IPs connected to the bus, the operating sequence of the entire system including the software can be verified.

1. Block diagram

  • Master 0: CPU that controls the entire system
  • Master 1, 2 and 3: DMA, USB IP and MIPI IP with data transfers controlled by CPU

2. System operation timing and VSTAR probes

  • Cyclic operation for about 27,000 clocks
  • Data transfers of Master 1, 2 and 3 controlled by CPU (Master 0)
  • VSTAR probes added to detect CPU operation
    • Value matches with CPU address bus
    • Rising edge of enable signal to control each data transfer of Master 1, 2 and 3
  • VSTAR supports AXI and other standard protocols.

3. Actual operation timing and events detected by the VSTAR probes

4. VSTAR Event Transition Chart

  • Displays system level operation for 100,000 clocks or more
  • Acquires for the period of time that cannot be handled by other tools

5. Displays the detailed signal waveform to GTKWave near the error detected by VSTAR

Application example for debugging pixel excess / deficiency

This is an example of applying VSTAR’s rule generation from signal states transitions to the detection of data change regularity. Due to defect in the image processing pipeline circuit, pixel data omission and duplication may occur. VSTAR analyzes even if the number of pixel data in one line (in one frame) is correct and there is an error only in the pixel data.

1. Adds VSTAR probes to monitor the input / output data of each module

2. Generates VSTAR rules with periodic image data for easier debugging

3. VSTAR detects the shift of timing intervals for the events indicating data change in the vertical line parts as an error.