Path: EDN Asia >> Design Centre >> IC/Board/Systems Design >> Accelerating pre-silicon validation
IC/Board/Systems Design Share print

Accelerating pre-silicon validation

20 Feb 2013  | Rajesh Udenia, Rohit Goyal, Neha Singh

Share this page with your friends


 • In situations where the simulation environment for validation testbench is unavailable, this method can be opt for debugging, as to build a simulation environment for the validation testbench from scratch can be tedious and time consuming.
 • This method can speed up the debug process, as it provides the required observability to the validation engineer to observe the behaviour of internal signals of design.
 • This method provides a window into the device in operation without the requirement of any extra software effort.
 • As all the validation scenarios are executed on the FPGA board itself, so this method can be adopted for designs which generally have frustratingly long simulation times otherwise.

 • The designer needs to instrument the design manually and iterate the debug by manual editing each time. The internals nodes required for the debug that are not at the top-level of the design must be routed to get them to the top.
 • The number of probes gets limited by the number of free pins available on the board.
 • It becomes tedious to enter signal names into the logic analyser viewer in order to track which signal in the design is displayed where.
 • Routing probes in the design may cause issues with device operation or timing.
Debugging with a logic analyser thus becomes time consuming and enervating and can't be used for debugging of complex designs.

Insertion of on board debug logic
Designs that have complex logic implementation usually demand real time debug capabilities. These are necessary for better insight into the design without going into building of complex testbench infrastructure or implementation of external hardware.

a) Inserting debug logic along with the design itself on an FPGA can reduce the debug time and effort required to a great extent by just putting in some initial one-time effort. This would involve writing synthesisable logic for driver and monitor IPs that can be then integrated with the design itself and can be ported on to the FPGA. Such a debug model using onboard debug logic is shown in figure 3.

Figure 3: Debug model using onboard logic.

Also, this on board logic can be made memory mapped so as to extract the results or drive inputs on the fly through a debugger.

b) Another way could be to read out the debug signals by making them memory mapped. These values can then be read out using a debugger or compared by the CPU with the expected values of these signals. If the output data from design comes out at a faster rate than it is read out, a FIFO can be implemented. The incoming data can be stored at a faster rate and read out at the reduced frequency of the debugger clock. The depth of the FIFO can be determined taking into consideration the frequencies of the two clocks.


 • There is no need to drive stimulus externally through the pads or GPIO's which eliminates the issues that can be caused by the external connections.
 • The frequency is not limited by the external driver frequency.
 • The stimulus driven and results monitored are in real time making the debug faster.
 • The monitors dismiss any requirement of getting the nodes on externals pins as they can be checked internally and errors flagged using registers that are memory mapped.
 • No extra iterations of bit-file generation required in order to add debug bus signals.

 • The drivers and monitors need to be synthesisable hence might not be possible to re-use the ones on the verification testbench.
 • The logic used by the drivers and monitors can lead to over utilisation of FPGA resources.
 • It can happen that if either of them has a memory requirement and it exceeds the available FPGA resources, it will not be possible to implement the drivers and monitors.
 • Adding extra logic (as drivers or monitors) can lead to difficulties in meeting the desired timing requirements for the design.

Real-time debug tools
These debugging tools eliminate the need of extracting the internal design signals on top of the board and also provide signal probing capabilities along with real time debugging.

There are multiple tools available in this category that can be used for real-time debug of the device. The best way to select a suitable tool would be depending on the complexity and functionality of the design along with the technology of the FPGA being used. These tools are used to insert probes in the design in order to dump data and provide the controllability of specific triggers to start data storage.

 First Page Previous Page 1 • 2 • 3 Next Page Last Page

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact