DCFIFO sample duplication problem

[Altera_Forum]

Dear fellow forum members, 

 yesterday I encountered a strange problem when simulating a DCFIFO (Altera Megafunction). I attached a picture of the functiuonal simulation, created with Quartus 10.1 (SP1) and Modelsim 6.6c.   The FIFO I'm using has a sample depths of 8 samples (in order to test wether my design handles FIFO full / empty signals correctly). It has write on full / read on empty protection enabled.   Everything seems to work well except for a special situation in which either the writing or reading of a sample does not work (sample is either written twice, or read twice - I don't know).   In the attached picture You can see the FIFO input domain (clkSystem is 100MHz, both the logic and the FIFO work on the raising clock edge) in green colour, and the FIFO output domain (CLKOUT is 60MHz, control logic works on the rising edge, FIFO on the falling edge) in light blue.   Also, the write request signal runs through an AND gate, combined with the inverted FIFO full signal (this isn't usually the case in my design - I added this to make sure the sample isn't written twice). However, this didn't change the FIFOs behaviour.   The sample 0x4e should be written to the FIFO only once, but when I request it, the output of the FIFO does not change from 0x4e to 0x4f, as I would expect.   Am I doing something wrong? Is there some special case with contolling the FIFO I've missed to take into account in my design?   Thank's in advance for any help You can give me,   Your's sincerely, Felix Lembcke

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

--- 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

[Altera_Forum]

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

[Altera_Forum]

--- Quote Start ---  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.   --- Quote End ---    I'm confused by "I created a file". You mean you created a procedure? If I was going to create a bus functional model (BFM) of the FTDI device, I'd create a procedure to generate a byte-stream and receive a byte-stream, then I'd layer read and write byte-sequences on top of those streams. Then my testcase generator would issue read and write commands.    --- Quote Start ---   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...    --- Quote End ---    Right, that's where tracing the hardware comes in; it gives you sequences that are representative of reality.    --- Quote Start ---   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.    --- Quote End ---    That's true. But your hardware should handle the case of a partial packet, eg., what happens if you unplug the USB cable and plug it back in again. Lets say the FTDI device was self-powered, so your FPGA remained powered the whole time. Would a partial packet cause your FPGA to get stuck in an FSM state waiting for bytes that'll never show up?    --- Quote Start ---   Maybe I didn't fully get what You wanted to tell me.    --- Quote End ---   Basically I was commenting that your testbench should try to cover a reasonable number of use-cases and byte-streams, so that you can be confident that the design works.    --- Quote Start ---   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.    --- Quote End ---    Sounds like a good plan. Make sure to send invalid data to check that the FPGA recovers and can then read good data.  Cheers, Dave

[Altera_Forum]

I was referring to my testbench. I included a simulation of the FTDI in verilog (it's basically a simulation of the FTDI and the USB bus, since it generates data for the FTDI to send to the FPGA at set times / frames of data) in one of my testbench files. 

 In case a transfer is corrupted, a reset sequence can be sent which will resync the FPGA (basically just 0xFF, and enough bytes to be longer than any other command, including attached data). However, unpugging the device while a measurement takes place souldn't be done anyways.   Reading data in general does work. The bug(s) reside(s) only in the FPGA to FTDI interface (upstream), as it seems.   Your's sincerely, Felix Lembcke

[Altera_Forum]

It sounds like you have a pretty good testbench and test procedure.  

 Good luck with your testing!  Cheers, Dave