Electronics > FPGA

Interfacing a DE0 Nano (EP4CE22F17) with at FT232H as a usb to fifo.

(1/2) > >>

rainbain:
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 transmitting 
  assign 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) begin
    if(readMode == 0) begin
           //Clear canRead if we reached the end of the transmition and cler the next bit
   canRead <= 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 cycle
     if(canRead) begin
         recive_data <= DATA;
         writeNext <= 1;
     end else begin
         canRead <= 1;
     end
end
  end
 
  //Go to the next byte if done writing or done transmitting on clock negative edge
  assign next = (writeNext & (~clk)) | (transmitt_enable & (~clk));
 
  //Wait a clock cycle to clear the skip bit.
  always @ (*) begin
    if(TXF) begin
   skip = 1;
end else if(~clk) begin
   skip = 0;
end
  end
endmodule
--- End code ---

vstrakh:
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.

oPossum:
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.

rainbain:
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?

BrianHG:
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.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version