DCFIFO sample duplication problem

Something does not look right with your timing diagram.

Look at the signals in the read clock domain. They appear to be half a clock different than the CLKOUT signal, i.e., some logic is using the rising edge, while other logic is using the falling edge.

Try and create a testbench with just the FIFO in it. Reproduce the error and post the testbench code.

Cheers,

Dave

Thank's for Your reply.

The timing diagram is as it should be. As I wrote in the opening post, the logic which controls the FIFOs read inputs works on the rising edge of CLKOUT, and the FIFO itself works on the falling edge.

Luckily I found the problem myself, and it's quite unrelated to the timing diagram. There was a last logic operation with the FIFO_read_req signal right in the instantiation of the FIFO which altered the signal - but this didn't show up in the simulation (because it did not affect the FIFO_write_req register - it did show up in the FIFO itself in the simulation though, which finally helped me to find the error).

Your's sincerely,

Felix Lembcke

--- Quote Start ---

the logic which controls the FIFOs read inputs works on the rising edge of CLKOUT, and the FIFO itself works on the falling edge.

--- Quote End ---

Is there a reason for this? So long as you've setup a TimeQuest .SDC file for the timing analysis and it passes, I guess its ok. However, its not something I've ever needed to do (except perhaps in an I/O element to meet timing).

--- Quote Start ---

Luckily I found the problem myself, and it's quite unrelated to the timing diagram.

--- Quote End ---

That is why I recommended trying to isolate the problem and posting a testbench. That exercise is usually enough to determine the problem :)

Cheers,

Dave

The reason is the device (FTDI USB chip) I'm interfacing with. It signals me wether it can accept any more data on the rising edge - so it takes at least one cycle to see wether my write access was successful or not. Then, if the FIFO would also run on the positive edge, it would take another cycle untill the FIFO get's notified that it shouldn't provide more data.

In that case, I would need to keep track / store up to 3 "old" data samples. I guess this could be done with pipelining, but since I'm working with a Stratix Device and the clock is "only" 60MHz, there are no timing issues with the alternating clock edge logic.

Since the access to the FTDI is bidirectional, this is quite complicated the way it is already.

Thanks for Your advice nonetheless.

Your's sincerely,

Felix Lembcke

--- Quote Start ---

The reason is the device (FTDI USB chip) I'm interfacing with. It signals me wether it can accept any more data on the rising edge - so it takes at least one cycle to see wether my write access was successful or not. Then, if the FIFO would also run on the positive edge, it would take another cycle untill the FIFO get's notified that it shouldn't provide more data.

--- Quote End ---

Which FTDI device and which mode? The FT245 and FT2232 devices have an asynchronous FIFO mode, while the FT2232H device has a synchronous FIFO mode. If you're interfacing to the FTDI device in asynchronous FIFO mode, then you need to run the FTDI signals through synchronizers before using them, so the FPGA clock is basically independent of the FTDI device. I haven't used synchronous mode, though I do have an FT2232H module I've been planning on testing one of these days ...

Cheers,

Dave

I'm using a FT2232H in synchronous mode, since this is the fastest transfer option for data (high data throughput is needed for the purpose of the whole design - in both directions).

The CLKOUT signal is the clock given to me from the FTDI (60MHz).

Your's sincerely,

Felix Lembcke

--- Quote Start ---

I'm using a FT2232H in synchronous mode, since this is the fastest transfer option for data (high data throughput is needed for the purpose of the whole design - in both directions).

The CLKOUT signal is the clock given to me from the FTDI (60MHz).

--- Quote End ---

Ok, thanks.

How are you going to generate USB traffic? FTDI's libftd2xx works fine under Windows and Linux. The open-source libraries libusb, libusb-1.0, libftdi, and libftdi-1.0 are a bit more fragmented, and were not so windows friendly.

The other useful thing to do while testing, is to use Wireshark under Linux to trace the USB bus traffic (Wireshark under Windows does not have a USB tracing option). If you're running Windows XP, then you can also install VirtualBox, Linux inside VirtualBox, give the FTDI device to the virtual machine, and trace the USB traffic from Wireshark in there. Using Windows 7 as a host does not work as well, as it does not like to give the USB-Blaster to the VM (but it'll give the FTDI device to the VM).

One other problem I have run into, and have yet to solve, is that I get conflicts with the FTDI driver and USB-Blaster. Eg., if I have SystemConsole with a JTAG connection open, I cannot access the FTDI device via the COM port, until the JTAG connection is closed. This makes it a pain to trigger SignalTap II for tracing USB traffic once it reaches the FPGA.

I'd be interested in hearing what data rates you end up getting over the synchronous FTDI interface.

Cheers,

Dave

We are using the basic FTDI dll plus an own dll which implements our interface: the FPGA accepts commands with data appended to them as a byte-stream, and also generates a byte-stream, which then goes back to the PC for interpretation (it's a combined pattern generator and scope).

However, I didn't write that dll or any software using it. I just programmed most of the FPGA's code (in verilog).

On the PC, I have a small debug application which will send and receive data to / from the FPGA (via our dll and the FTDI dll) and notifies me if an error occurs.

This worked very well, but there was a bug occuring very rarely, sometimes after a few minutes, sometimes after several hours. The cause of the bug was what I described above.

Your's sincerely,

Felix Lembcke

--- Quote Start ---

We are using the basic FTDI dll plus an own dll which implements our interface...

--- Quote End ---

Thanks for the description.

--- Quote Start ---

This worked very well, but there was a bug occuring very rarely, sometimes after a few minutes, sometimes after several hours. The cause of the bug was what I described above.

--- Quote End ---

The lesson to take away from that experience is that you need to write a testbench that includes a bus functional model (BFM) of the FTDI FT2232H synchronous interface. Your testbench should then generate activity over the synchronous interface that matches the data streams you send from the PC. This is where using Wireshark and SignalTap II to trace the activity is important, as you can see from those traces whether the USB data is sent in a single USB packet, or whether it is spread over several USB packets. Reimplement those hardware measurement sequences in your BFM and then randomize the order in which you generate command sequences them to your design. That will improve your confidence that the design will operate under all conditions.

If you have Modelsim-SE, then you can use advanced features like code coverage. However, the above sequence works well in Modelsim-ASE.

Cheers,

Dave

This is what I did. I created a file which simulates the FTDI's behaviour (as described in the datasheet) as part of my testbench.

However, it's hard to create all possible combinations of problems which may cause an error if You don't know what possible combinations may cause an error...

By the way, it doesn't really matter how the data is transfered over USB. The FTDI has it's own protocoll and will provide any data that comes from it's USB interpreter, so on the FPGA's side, all You need to do is read bytes or write bytes on the application layer.

Maybe I didn't fully get what You wanted to tell me.

For debugging, I'm currently transferring an increasing counter (instead of the actual data). If it increases by a value which is not 1 (or doesn't increase at all), I know that something went wrong.

I can trigger on such events with signaltap - I implemented a small interpretation module within the FPGA wich will generate an error signal if the previous value + 1 doesn't match the current value.

Your's sincerely,

Felix Lembcke