Interfacing a DE0 Nano (EP4CE22F17) with at FT232H as a usb to fifo. - Page 1
Forum section: electronics / general

author: rainbain
author_rank: Contributor
timestamp: July 17, 2021, 04:27:23 am
content: I been sending and receiving data threw a FT232H as a fifo but with some errors in the data being received by the FT232h. Its a DE0 Nano and the clock signal coming in from the FT232h is at 60MHz. I am new to FPGAs and wondering if its bad timing in the verlog code or if the fpga can not drive the wires fast enough. I added a 100k resistor between some of the data pins and the number of errors did not change. It seems to be an error every so 1000 bytes but has no visible pattern. When I send all 0s the errors disappear and stranger it does not just seem to be the amount of data sent that gets corrupted but also the number of bytes received being 0-10 bytes off from what was expected. One of my main thoughts was that possibly my timing with the RXF was broken as it seems to turns on every 1000 or so bytes as well so the FT232H can send its buffer threw its USB but in all my changes with the timing it has not changed and I don't know why what data I send would change that unless it did compression but I don't think it does. Ill post my verlog code and my wiring setup down bellow. Its all quire messy and I really just goal on getting it to work before I improve it but any recommendations on how to improve it elsewhere is also quite helpful. Knowing what I can do to determine what is the cause or better yet fix it would be awesome. I thank you so much. Its been a week of slightly tweeking verlog code with no results.Code:module FIFO(inout wire[7:0] DATA, output wire RXS, output wire TXS, output wire OE, input wire RXF, input wire TXF, input wire clk, output reg[7:0] recive_data, input wire[7:0] transmitt_data, input wire transmitt_enable, output wire next, output reg skip);wire readMode;//Only driving the inout when transmittingassign DATA = transmitt_enable ? transmitt_data : 8'bZ;//Read when not transmitting and there is data to be read.assign readMode = (transmitt_enable == 0) && (RXF == 0);//OE is if we are reading (inverted)assign OE = ~readMode;//Recive Strobe when reading (inverted)assign RXS = ~canRead;//Transmit Strobe when transmit is enabled and the fifo has room. (inverted)assign TXS = ~(transmitt_enable & (TXF == 0));//If we are able to read. (Used to skip 1 clock cylce so OE can take effect)reg canRead;//Is used for telling the system that the byte has been sent and to move to the next one.reg writeNext;always @ (posedge clk) beginif(readMode == 0) begin//Clear canRead if we reached the end of the transmition and cler the next bitcanRead <= 0;writeNext <= 0;end else begin//If can read is set trigger to read the next bit and write it to the data buss. otherwise set it this clock cycleif(canRead) beginrecive_data <= DATA;writeNext <= 1;end else begincanRead <= 1;endendend//Go to the next byte if done writing or done transmitting on clock negative edgeassign next = (writeNext & (~clk)) | (transmitt_enable & (~clk));//Wait a clock cycle to clear the skip bit.always @ (*) beginif(TXF) beginskip = 1;end else if(~clk) beginskip = 0;endendendmodule

author: vstrakh
author_rank: Contributor
timestamp: July 17, 2021, 08:01:12 am
content: I see the oscilloscope there. Probe the signals on the receiving ends, because 60 MHz is a bit of a stretch for the dupont jumper wires. Signal integrity issues might become quite significant here.An example with SPI slave done in fpga and connected to RPi at similar frequency.The first case uses short (<10 cm) jumper wires, soldered directly to fpga board and plugged to RPi.The signal was already accepted by RPi, but didn't look great.The second case is using even shorter coaxials and series termination at the driver side. The signal looks much better.

author: oPossum
author_rank: Super Contributor
timestamp: July 17, 2021, 08:04:57 am
content: I suggest shortening the wiring for better signal integrity. There are limits to what can be done with 200mm jumpers and breadboards. Once you have good SI, then it is time to look for bugs in the HDL.

author: rainbain
author_rank: Contributor
timestamp: July 17, 2021, 05:46:30 pm
content: Ok I got the best capture of the date lines I have gotten so far and its 100 times more messy than I expected. I was planning to make another pcb that plugs directly into the fpga with the ft232h breakout board soldered directly to it. Is that a good solution to it and if so should I have a ground plane bellow the data lines or will that induce unwanted capacitance. Also should I goal on making sure all the wires are around the same length for a 60 MHz signal?

author: BrianHG
author_rank: Super Contributor
timestamp: July 17, 2021, 07:03:39 pm
content: You would be thinking about trace length matching at 600MHz. 60MHz is a breeze.Are you sure your oscilloscope probes are set to 10x mode. Remember, a 100MHz oscilloscope probe in 1x mode really only passes around ~10MHz to the scope. This lousy 10MHz figure is even true for a 250MHz or 500MHz probe. The probe needs to in 10x mode to pass the full bandwidth.Is the sample rate on the scope at it's full 1GSPS? You probably need to be zoomed in on an ACTIVE signal to capture it at full bandwidth. Otherwise is you captured a signal zoomed out, froze that signal, then zoomed in, it was potentially captured at a lower frequency by the scope.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 17, 2021, 07:27:49 pm
content: I haven't taken a look at your code, but just noticed you use the synchronous FIFO mode. Are you using any other clock in your design, or is everything clocked from the 60 MHz clock provided by the FT232H? In the former case, you may have clock domain crossing issues. In the latter case, make sure you handle the FIFO flags appropriately.

author: rainbain
author_rank: Contributor
timestamp: July 17, 2021, 08:18:49 pm
content: Yep all the verlog is clocked at 60 MHz from the FT232H. there is another clock controlling some of the data in a internal fifo but its only active when not transmitting.

author: vstrakh
author_rank: Contributor
timestamp: July 17, 2021, 09:14:06 pm
content: Quote from: rainbain on July 17, 2021, 05:46:30 pmThe ground plane under the traces will reduce the inductance, its effects are dominating over the capacitance.It's always better to have the ground plane, but it also could happen that you won't really require that. Simply making the links shorter might do the trick.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 17, 2021, 09:24:46 pm
content: Ah I didn't look at the pic with the wiring.Ouch. That's definitely too messy here. That would be OK for like SPI @ a few MHz, but not for this. I remember having crosstalk issues with a flat cable between a MCU board and an LCD panel (parallel bus). Everything was fine when the cable was straight between the two, but communication started being corrupted when the cable was folded over itself, unless I drastically decreased the data rate...What I did for prototyping with a FT232H breakout board and a FPGA dev board was soldering the breakout board on a small piece of prototyping board and solder a header connector on it that would plug directly on the FPGA board. Connections made with solder blobs and some small pieces of wire on it. So there was no overlapping wires and connection length something like 20 mm max from one board to the other. You can probably be ok with just wires, but shorten them drastically, and arrange them so none of them overlaps other wires. You very likely have crosstalk. Preferrably use a small piece of flat cable for this, if you don't want to go the prototyping board way as I did.

author: rainbain
author_rank: Contributor
timestamp: September 05, 2021, 05:08:36 pm
content: Ok it took a bit cause i also had to work on other pcbs for the project but i made the wires as short as possible on a protoboard and the popping is definitely less but corruption of the amount of data sent is still apparent. When no audio device is plugged in and its just sending 0s or something close to 0 but when audio is going threw it skips around generally missing 1-100 bytes causing a short audio blip around every half second. You can still here popping occasionally but most seems to be the adc's noise now. Im starting to think its the breakout board i got for the FT232h as its not designed for a fifo and i had to use FT_Prog to make it into one but I don't want to make a all new hookups (and probably another custom pcb to fix it as much as possible) if there is a good solution. I don't think its the verlog as the audio recording is separate from the fifo and command/control system unless the FT232h does some sort of compression on the data sent. What do you suggest I do and is there any other ways to get a high data rate on usb without data loss (possibly differential). I have a bad habit of not being able to find an ic to do a task until its too late. Also note I did make a few modifications to the verlog as the clock source was entirely off phase as compared to the shorter wires. Now it matches what the datasheet says. Ima count the amount of the the FT232H tells it to wait so I can see if its most likely a verlog issue or the wiring,Ok slight revelation. The general size of the wait time is the same but still skips around a little bit. So it could definitely be a mixture of both verlog timing issues and cross talk.Another revaluation. Taking a closer look at the datasheet the FT232h has "runt" pulses on the TXF line that should be ignored. this seems like it could be the cause.