Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
13 years ago

DCFIFO sample duplication problem

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

13 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

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

    Good luck with your testing!

    Cheers,

    Dave