Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] How to do debug a design post implementation in fpga

Status
Not open for further replies.

UltraGreen

Junior Member level 3
Joined
Aug 26, 2016
Messages
30
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
269
Hello all,

If I dump a bit file into an FPGA with no violation and no error and critical warning.
Now if the design is not working, then what are the steps should I follow.
Also if for some reason I cannot use ILA, then what options do I have? How to find the issue where to start from? Is there any link which can help me do that ?

As a professional what are the ideal step by step procedure to debug in such situation.
 

Go back to simulation - have you covered all cases for all of your individual blocks, or do they have sufficient coverage? do you have a top level test bench (with the same questions).

If it doesnt work, then you'll have to put debug in the design to find out why. CPU registers is about the only visibility you have. That requires more RTL and another compile.

If you only have the final design, no chance of extra RTL, and no debug, then you're stuck.
 

To be on the safe side check post-impl simulation too!

If you can't use ILA/VIO/Chipscope for debugging the you really think hard, monitor your design closely and do what Tricky has mentioned in #2.

Another not so effective approach is, you might selectively bring out some internal signals or a combination of internal signals to the top-level output port and then connect them to GPIO LEDs and follow their statuses (for large designs this approach might be very difficult). Assuming these brought out signals convey meaningful info as visual indication required for your debug.
 

Another not so effective approach is, you might selectively bring out some internal signals or a combination of internal signals to the top-level output port and then connect them to GPIO LEDs and follow their statuses (for large designs this approach might be very difficult). Assuming these brought out signals convey meaningful info as visual indication required for your debug.

If they already knew they couldn't use Chipscope (no license, too cheap to buy the license) then hopefully the board designer had the foresight to add a mictor connector to the FPGA. With that you could route out signals to a external logic analyzer (if you have one or can buy one of those really cheap 16-32 channel USB PC ones) and look at internal signals that way.

Your best option is to do as a previous post suggested, run simulations on the design (perhaps this was not done?). The only time I break out Chipscope or send out signals from internal nodes of a design is if there is some system integration problem that has never shown up in simulation. The error usually ends up being caused by something that was never foreseen and that corner case is what results in producing the problem. I primarily use the ILA to detect the inputs/protocol that causes the problem, so I can replicate the scenario in my testbench simulation, I don't use the ILA as my "simulator" to find and fix the problem like some people.
 
Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top