VHDL Core troubleshooting

[jack.gassett]

While trying to synthesize a new version of the VHDL core that drives the ARM and Trigger LED's correctly I have run into some snags. It seems that every time I remove the serial rx line from the LED things start to go wrong. The design synthesizes as normal but then the Java client can no longer communicate with the VHDL core.

I suspect that connecting the LED introduces a delay that puts the serial communications within the right timing parameters and then removing the LED removes that delay. But that is just a guess. So I think my next step is to synthesize a version that has all the serial related signals routed to the pins of the Wing header. We can then use another board running a good Logic Analyzer core to see if there are any issues with the timing.

Stay tuned for links.
Jack.

[robots]

Have you tried to run it through simulator ?

I know, it's just simulator, and it's much different from real world HW. But it would save time to rebuild and reupload the new core.

[jack.gassett]

I sort of made the assumption that it would work as expected in the simulator. But it might be worthwhile to do so to at least get a better understanding of how it is supposed to look. There is a testbench already created so it should be easy to do.

[colin.i]

You think and LED causes a delay?  Why don't you just remove the LED and replace it with a very small capacitor to see if that does the trick.  Check the datasheet for the LED you are using and replace it with a similar capacitance.  If that doesn't work, try a diode... but that shouldn't really affect anything, I'd bet on the capacitor.

[jack.gassett]

Well, a bit of a false alarm I guess. I was able to change the TRXSCALE constant which seems to change the oversampling rate and have been able to get a number that has been completely stable. All of my changes are working properly now.

I managed to synthesize a design that uses the maximum amount of BRAM (6Kx32bit) and it is working as expected. The Java client does need to be updated to provide a 6k drop down box though.

So I will continue to make more changes and hopefully I won't run into any more snags.

[jack.gassett]

Sorry about causing confusion with the LED, I didn't word that very well. I don't think the LED actually causes a delay. I was thinking that having an LED attached to the internal rx signal causes the rx signal to be routed through an additional logic slice. Every logic slice adds its own delay to a design. I was thinking that the logic slice to connect the LED was adding enough of a delay to put the design within parameters that made it work.

Jack.

[ian]

Glad you figured it out. These kind of problem are a pain.

[robberknight]

Hi,

I managed to synthesize a design that uses the maximum amount of BRAM (6Kx32bit) and it is working as expected.

Do the client and the VHDL core allow to reduce the channels (e.g. to 8 bit) to increase the number of samples possible with the available BRAM? How about the RLE encoding existing in newer versions of the client?

I'm asking because I already tried the BusPirate as simple LA with the java client. The biggest problem when analyzing some i2c-like protocol and a bit of uart was not the limited speed of the BusPirate LA but the max sample size. Just having 6K samples would make the Sump Pump nearly useless for me, 24K with 8 channels or even more with RLE would make the difference.

[jack.gassett]

Yes, the client and the "Sump" VHDL core do allow you to select 8, 16, 24, or 32 channels. With custom bitstreams it is possible to extend the sample depth for fewer channels. I had made bitstreams for:
 -24k samples x 8 channels
 -12k samples x 16 channels
 -6k samples x 32 channels

But what I found once I started testing with waveforms is that the design, as it is, requires that the size of memory be a power of 2. So the non power of two memory sizes above had holes in the data.

So for now I'm going to generate bitstreams with the following memory sizes:
 -16k samples x 8 channels
 -8k samples x 16 channels
 -4k samples x 32 channels

I'm going to put modifying the VHDL code to support the full memory sizes on a backburner for now. For now I think its more important to work with Ian on finishing up all the things we need to do in order to get these boards up for sale at Seeed Studio by the end of the month.

The RLE encoding is included in both the "Sump" VHDL core and the Java client that I am working with. It does indeed make a difference in testing.

I've had the same problems that you had debugging i2c and uart protocols with limited memory. RLE and more memory helps but I think the best solution will come once we integrate a SPI slave core into the design. Once the communication between the FPGA and the microcontroller is on the higher speed SPI channel then we will be limited by the USB speed and will be able to start bypassing the BRAM memory. I'm not sure what speeds will be practical to sample in realtime but I'm sure that i2c and uart speeds will be very easy to send directly out over the USB port for unlimited sampling sizes.

[robberknight]

Hi Jack,

thanks for your reply. I hope you'll manage to make the full 24K available when the design is done and the boards are shipping.

but I think the best solution will come once we integrate a SPI slave core into the design. Once the communication between the FPGA and the microcontroller is on the higher speed SPI channel then we will be limited by the USB speed and will be able to start bypassing the BRAM memory.

I wish you used the FT2232H instead of the PIC for USB. Then you could increase the speed for live sampling up to (nearly) 60 MByte (using the Synchronous FIFO mode with 60 MHz-Clock driven by the FTDI).