This customer was busy with the design of a new sofwtare/hardware embedded system composed of an embedded processor and a bunch of peripherals implemented with standard components 'off-the-shelf' and some other specific peripherals implemented in a FPGA.

All the peripherals were controlled with a central microcontroller.

The development of the embedded software occurred with a prototype board and a software emulator connected to the board, allowing execution on the target board and processor directly. The companion FPGA which contained some specific peripherals had been designed in VHDL and carefully debugged with a testbench in simulation.

During the development of the embedded software, some code execution caused the FPGA peripheral to stopped functioning from time to time. The origin of the crash were rather undefined, as the customer quickly found which part of the software generated the faulty condition BUT, the crash did not happen at EVERY code execution.

The customer suspected that a specific control sequence and/or a specific control and data signal timing between the microcontroller and the FPGA peripheral caused the crash. While the executed software code remained identical all the time, our customer knew there was no guarantee to always reproduce the same signal sequence and timing. Hence, the erratic behaviour.

Customer's requirements

The physical configuration of the embedded system made it possible to 'intercept' the data traffic between the microcontroller and the FPGA. The customer had a need to:

- record enough data traffic between the microcontroller and the FPGA, especially during the execution of the problematic code.
- being able to replay the recorded traffic in order to systematically reproduce the faulty condition. Being able to replay the problematic set of stimulus also allowed several engineers analyse the problem on a separate.
- being able to easily reuse the recorded data in the simulation environment in order to debug the peripheral implemented in FPGA.

Byte Paradigm's solution

- Byte Paradigm proposed a GP-24100 device to record the data traffic between the microcontroller and the FPGA. The bus frequency was set to 20 MHz, and the data was recorded at 40 MHz and 100 MHz. The GP-24100 device started sampling data upon occurrence of a software-generated specific data.
- GP-24xxx device was preferred over a GP-22050 because of its 8MByte memory. GP-2411 or GP-24132 (not available at the time of the tests) with 16 MB and 32 MB memory would have been even better.
- Once several potential problematic stimuli had been recorded, replaying them systematically at the input of the FPGA showed which one caused a systematic crash of it. Several variants of the stimulus caused the crash, which had helped having a preliminary idea of the bug in the FPGA.

- Finally, the recorded stimulus was reused in the simulation environment, allowing a fast correction of a nasty bug in the design!

Recommended products

GP-24xxx devices, which offer both a logic analyzer mode of operation to record up to 16 bits in parallel.
GP-24xxx are available with a memory buffer of 8 MB, 16MB or 32 MB, enabling rather long record times at a sampling frequency up to 100 MHz.

GP-24xxx also feature a digital pattern generator mode of operation that uses the same data format as the logic analyzer; this allows easily replay the recorded samples.