Getting data out of an FPGA for testing - Page 1
Forum section: electronics / general

author: Harvs
author_rank: Super Contributor
timestamp: February 09, 2014, 12:08:50 am
content: I was just thinking about using an FPGA board I had sitting around yesterday to rig up a quick test jig to calibrate an RTC (basically a couple of long counters.)I'm wondering what's usually the best way to then get the result out? For those that use FPGAs regularly, do you have a serializer block (e.g. UART tx'er) you'd drop in when you need the value out of something? Or is there an easier way?I'm not talking about production code here, more so what you'd use for debugging.

author: joelby
author_rank: Frequent Contributor
timestamp: February 09, 2014, 05:42:20 am
content: The absolute easiest way is to use Xilinx ChipScope Pro (or the equivalent from another manufacturer). Just do something with the signals so that they don't get trimmed (e.g. 'or' all of the signals together and output them to an LED) and you can capture and download data with CSP, then inspect it in Matlab or whatever. This works great even for high speed data where you only need to capture a few hundred or thousand samples, and it's easy to set up start and capture conditions.For low speed stuff, find or write a good UART core and dump values to it. For general purpose low speed debugging, it can be worth using a soft processor to implement a simple serial console that can read and set registers. Xilinx PicoBlaze is good fun for this sort of thing, though there's now a free MicroBlaze variant which would make firmware development a bit quicker.

author: nctnico
author_rank: Super Contributor
timestamp: February 09, 2014, 11:59:51 am
content: What I usually do is have 8 or 16 debug pins. Internally I have multiplexer which receives 8 to 16 debug signals from various modules and sends those to the debug pins. Having a permanent debugging feature is handy if it turns out you need to debug a design later on.

author: codeboy2k
author_rank: Super Contributor
timestamp: February 09, 2014, 02:38:04 pm
content: I usually do the what nctnico said, basically use some I/O pins as debug for indicating internal state.I've also dropped in a UART on occasion, but usually alot can be done with just a few I/O pins.If the dev board has and LCD or LED I'll sometimes try to use that for more complex needs.

author: Harvs
author_rank: Super Contributor
timestamp: February 09, 2014, 10:09:13 pm
content: I guess UART it is in this case at a least (probably 64bit result.)I've used chipscope in the distant past, and yes it was very good. I'm using small lattice parts at the moment that don't have the large internal blockrams that the xilinx parts have.

author: marshallh
author_rank: Unknown
timestamp: February 10, 2014, 02:35:15 am
content: Signaltapor write a small SPI block... or write a simple SD controller. there are many ways to accomplish this

author: Bassman59
author_rank: Super Contributor
timestamp: February 10, 2014, 04:55:45 am
content: Quote from: Harvs on February 09, 2014, 12:08:50 amA UART which talks to a host PC's serial port via your favorite terminal emulator is pretty straightforward, although you'll find you need to rig up a bit of logic to have it send human-readable strings. Dropping in a PicoBlaze makes that pretty easy.

author: JoeyP
author_rank: Frequent Contributor
timestamp: February 10, 2014, 08:16:24 pm
content: Having a dozen or more debug pins is very nice, and I try to always include them, but it's not always possible. A UART doesn't sound very practical to me. Would need a lot of logic, and has some limitations. I usually crate an SPI interface. Takes only 3 pins (can get away with 2 if really needed), has almost unlimited data length, and takes minimal logic. I use a logic analyzer to decode the resulting SPI signal, which can be demuxed to show numerous values of mixed lengths. So the logic analyzer will show say an 8 bit value from one area of logic, a 14 bit value from somewhere else, and maybe a few 32 bit or even 64 bit values when needed.

author: Harvs
author_rank: Super Contributor
timestamp: February 10, 2014, 11:04:28 pm
content: Demuxing is a great idea.When looking at it just from a transmitting perspective, I'm not sure I agree that a UART is particularly complicated. The only real differences to the spi is the requirement to generate start and stop bits and the fixed data length. But I can see where you're coming from, SPI of any data width through a mux and into a logic analyser is a partially neat solution!

author: codeboy2k
author_rank: Super Contributor
timestamp: February 11, 2014, 09:30:40 am
content: @ JoeyP, I agree, demuxing like this with an SPI connection is a great idea, and actually has me thinking...what if you had a drop in soft LA module that has say 32 or 64 bits of input and you hook that up to test points in your own HDL code when you build your bitstream.That LA module sends any changes on it's inputs out over a single LVTTL or LVCMOS pair, and you use another FPGA to receive that, demux it and present those internal input ports as outputs on the second development board's I/O headers. Now you can hook up leads to the external LA and see it in real time (provided the LVDS link is fast enough).I might do something like this for my next FPGA project, as I have plenty of FPGA dev boards lying around.

author: JoeyP
author_rank: Frequent Contributor
timestamp: February 11, 2014, 05:52:41 pm
content: @codeboy2k, I think this could work, but doesn't seem necessary. I think the term "real-time" would also have to be qualified. The SPI interface would have to be clocked at an extremely high rate to get anything that approaches "real-time" output to the logic analyzer. You might also need a lot of channels for the analyzer.I've attached an example image of what I was talking about. In this case I've concated 7 values from different areas of logic into 193 bits of SPI data, which the analyzer demuxed back into the original 7 values. Notice a couple of the values are 64 bits wide (they happen to the be input and output of a FIFO in this case). One of the advantages of this technique is that you can easily "get at" the existing logic in your design to create extremely elaborate trigger conditions when needed. In this example the different values were captured at different times, and the group of values was sent only when the last value was captured. It would be very difficult for an external analyzer to get at enough of your logic through physical IO pins to setup this trigger situation (even assuming the analyzer itself were actually capable of it).

author: nctnico
author_rank: Super Contributor
timestamp: February 11, 2014, 06:18:03 pm
content: You could use an LVDS to parallel chip for this. Saves an extra FPGA. Then again if you need this much debugging you might want to simulate your design first.

author: JoeyP
author_rank: Frequent Contributor
timestamp: February 11, 2014, 06:30:04 pm
content: @nctnico: codeboy2k was talking about using an FPGA already on an existing development board. Seems we all have one or more of these laying around, so no additional FPGA/cost. As far as simulation, I do usually simulate small/medium sized blocks of the logic in my designs if I have any doubts, but in the example I gave the overall design was extremely complex and it was only practical to debug it under actual conditions. I could have spent months coming up with simulation vectors to test for all possible conditions of that logic - and would have eventually come across the bug. Instead I chose to debug it in real hardware in just a couple of hours.

author: codeboy2k
author_rank: Super Contributor
timestamp: February 11, 2014, 07:52:22 pm
content: @Joey, yeah, I like that SPI trickAs for what I was talking about, only do something like this if needed. In the general sense, if I did it and I liked it, I would automate it with a script to take the input source, and a list of connections, and auto-generate the connections needed.It would not be SPI , but perhaps a 3.125 Gbps short-run Serial RapidIO link using an available serdes I/O channel on each FPGA. That's why I said a "real-time" view, because if the internal clock is much lower, i.e. 50Mhz, even up to 500Mhz, then the link is fast enough to send the changes along with a timestamp to the other FPGA. With the timestamp, you could theoretically pull the data stream out and display it directly on a PC, no need for an external LA. ... The internal LA could have triggers too.. (oh, oh, now it sounds like I am re-writing Chipscope )But that SPI trick is really great! I'm going to start using that sooner, rather than later!I think you are even using the same LA I have, the Intronix Logicport.. At least, your screen capture looks like it..

author: marshallh
author_rank: Unknown
timestamp: February 12, 2014, 04:47:13 am
content: You folks are overthinking it.Signaltap... I wrote an MPEG audio decoder in a week using only signaltap and JTAG. No simulation

author: JoeyP
author_rank: Frequent Contributor
timestamp: February 12, 2014, 04:43:41 pm
content: Quote from: marshallh on February 12, 2014, 04:47:13 amNot at all. Signaltap is fine if you have hoards of excess logic and memory available, and are willing to learn its interface and live with its limitations. The solution I described uses very little logic (and NO memory) in the FPGA. For the design I was debugging with that screen shot, Signaltap was a total non-starter because all memory was already needed for the design, and the logic was already around 90% utilized.

author: marshallh
author_rank: Unknown
timestamp: February 12, 2014, 09:18:54 pm
content: Quote from: JoeyP on February 12, 2014, 04:43:41 pmYup, you're right, in those cases where you're using a tiny fpga and have no room. But in other cases, it's not worth reinventing the wheel. In one case I dropped a larger device onto the pcb for dev to keep compile times down (fitter is quicker with less congestion) and for the shipping boards put on the smaller fpga.

author: JoeyP
author_rank: Frequent Contributor
timestamp: February 12, 2014, 10:17:20 pm
content: Quote from: marshallh on February 12, 2014, 09:18:54 pmIn the case I referenced, it wasn't a tiny FPGA at all. It was one of the largest of the family, and actually did have the highest IO count of any part in the family. The IO was very nearly 100% used. I couldn't use a larger part for development because the IO count goes down as the size increases (presumably due to the need for more power/ground pins with higher logic content). This was no small project. For smaller projects, I normally just reserve a bunch of pins for debug, connect the logic analyzer and be done with it.I've tried Signaltap. I agree that it could be useful for small/simple projects where you have plenty of resources to squander and don't need to worry too much about timing issues. Especially if you don't have a real logic analyzer to use. But for large complex projects where you need max performance from the part, Signaltap is in my experience simply not practical. Adding it to the design can dramatically change routing and performance.

author: codeboy2k
author_rank: Super Contributor
timestamp: February 13, 2014, 12:01:02 pm
content: I'll have to start using Altera more... SignalTap is free

author: lgbeno
author_rank: Frequent Contributor
timestamp: February 13, 2014, 01:04:36 pm
content: Signal tap is your friend, I agree if resources are available, no sense in rolling your own debug.I've also use the Altera System console. Just make a very simple Qsys project with a jtag to Avalon bridge and some pios and you can read any pin status via TCL commands. You can even make a Test GUI which I've used many times for board bring up before software guys got their stuff together.

author: lgbeno
author_rank: Frequent Contributor
timestamp: February 13, 2014, 01:06:17 pm
content: http://www.altera.com/literature/hb/qts/qts_qii53028.pdf

author: codeboy2k
author_rank: Super Contributor
timestamp: February 13, 2014, 02:18:33 pm
content: thanks for the link .. I'll read up on it.