fpga debug

Marco schrieb:

You can do the same thing in the simulator. In the real system, such things are often not usefull, since the FPGA interacts in realtime with external components (RAM, busses, whatever). So you need some kind of real time debugging. Simples method is using some pins to access internal nodes and wathcing them using a scope or logic analyzer. More complex debugging can be done using an integrated logic analyzer, integrated into the FPGA fabric, accessible via JTAG or special interfaces. On think I do is to use a Picoblaze as a terminal server to access internal registers and nodes. Works nice. (But only for Xilinx)

Regards Falk

Falk, really interesting your idea of using a Picoblaze as a terminal server, I have to deal with a Spartan3, could you please give more details on the way you do that? Thanks, Marco

Marco schrieb:

Its straight forward. Use a Picoblaze from xapp213. There is a version for Spartan-II (4K BRAMs) and Spartan3 (18k BRAMs). Just connect some registers to the IO bus. Also connect the UART from xapp?? (233?). Connect the UART with your PC (level converters necessary, of cource). Use hyperterminal or whatever you like to send char down to the FPGA. Now all you need is a small program inside the picoblaze that waits for the reception of a special char from the UART, lets say 'd' like debug. Then a routine can do whatever you like, do a register dump, set some registers, the possibilities are endless.

Regards Falk

Falk, I think I'll try that and, if I'll fail somewhere, I'll ask you for more help. Thanks again, Marco

Marco, If you have access to a tool such as ChipScope (embedded Logic analyzer from Xilinx

) this will provide a more convenient debug solution. However the picoblaze approach is definitely more fun.

Vivian

-- Sandbyte

Most functional debug is done with a simulator.

The techniques Falk has outlined are useful for debugging real world interface problems but for debugging the majoroty of typos, logical errors etc then you need a simulator.

Simulation can range from a quick and dirty simple module level testbench to a full system tests modelling the behaviour of external RAMS, PCI interfaces etc.

Nial.

You forgot to mention the price: $695 to $844 (depending on options). Prices are shown at:

Ron

But you can evaluate the full version for 60 days before having to pay anything. I ended up purchasing the program after those 60 days though... I can't stress the usefulness of that sort of on-chip debugging hard enough.

Marco, if you are talking about debugging of software running on the embedded processors on the FPGA the gcc is available in EDK. It is not very stable, but it works sometimes. Or if you have the time to wait for debug prints to the terminal you can always add some xil_printf("debug..."); to your c-code.

Take care!

Johan

--
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Un bel giorno Falk Brunner digitò:

Since FPGA are static devices, it shouldn't be so hard to support breakpoints by temporarily "disconnecting" the clocks, and watch/change the "variables" through JTAG; if you can do partial reconfiguration, I suppose you can also read/change the BRAM, registers and so on. Of course there are asynchronous signals too, but even with normal software debug there are asynchronous events you can't control.

--
asd

dalai lamah schrieb:

The problem is not the FPGA but the external components. Those are often not static, so this is no option.

The key word is real-time monitoring.

Regards Falk