Stratix III FPGA: Problem using Asynchronous FIFOs

--- Quote Start ---

If you hover of the entity in the 'Project Navigator' pane the actual parameter settings will pop-up. How mayn wrods of 8 bits did you specify in the MegaWizard?

You can also open the generated file by using the 'Open' on the menu bar and select the megawizard generated .vhd file. Ther tou can read all about the parameters.

--- Quote End ---

Oh, my bad, the contents of generated .vhd file are here:

    dcfifo_mixed_widths_component : dcfifo_mixed_widths
    GENERIC MAP (
        intended_device_family => "Cyclone III",
        lpm_numwords => 8192,
        lpm_showahead => "OFF",
        lpm_type => "dcfifo_mixed_widths",
        lpm_width => 9,
        lpm_widthu => 13,
        lpm_widthu_r => 11,
        lpm_width_r => 36,
        overflow_checking => "ON",
        rdsync_delaypipe => 7,
        underflow_checking => "ON",
        use_eab => "ON",
        write_aclr_synch => "ON",
        wrsync_delaypipe => 7
    )

I've set metastability protection stages to 5, so I believe that's why I see 7 here.

I usually instantiate RAMs and FIFOs directly, without using the MegaWizard. (hence my setting of 5 ...)

Now 8192 words of 9 bits is definitely larger than 8 (or 36).

Is 'aclr' connected and in which clock domain is it generated?

The output stream looks like 3 writes with '0x00' have preceded the '0x47' one. After that the stream is correct.

--- Quote Start ---

I usually instantiate RAMs and FIFOs directly, without using the MegaWizard. (hence my setting of 5 ...)

Now 8192 words of 9 bits is definitely larger than 8 (or 36).

--- Quote End ---

Yes, sorry for misunderstanding before.

--- Quote Start ---

Is 'aclr' connected and in which clock domain is it generated?

--- Quote End ---

Yes it is, I've enabled sync to wrclk, which is actually coming from that clock. 135MHz clock is used by ASI megacore, so the data and status signals should be already synchronous to that clock. I am using cable-sync signal (when core detects connected cable, status signal goes high) as reset source to the FIFO. This means, that when the cable is not connected, fifo is in reset condition. I am not sure if core generates sync chains inside for this cable-sync-loss signal, so I've enabled synchronizer there. On the other hand, I've tried to disable it with no success. Maybe I should remove clear signal at all for some tests?

--- Quote Start ---

The output stream looks like 3 writes with '0x00' have preceded the '0x47' one. After that the stream is correct.

--- Quote End ---

I am triggering on the start signal and my signaltap memory is quite short. According to the results I observe, I believe I get such data corruptions every received packet (packet length = 188 bytes).

Altera says that I should wait a few cycles after reset before asserting wrreq. Maybe this could be an issue?

--- Quote Start ---

Yes, sorry for misunderstanding before.

--- Quote End ---

No it was me jumping quick to decisions :)

--- Quote Start ---

Altera says that I should wait a few cycles after reset before asserting wrreq. Maybe this could be an issue?

--- Quote End ---

There are few warnings about wrreq being active while aclr is. So I may be a good idea to either only reset the fifo at powerup (and real error conditions) and further rely on the FIFO to do what it should do or either to keep reset and wrreq well apart.

--- Quote Start ---

I am triggering on the start signal and my signaltap memory is quite short. According to the results I observe, I believe I get such data corruptions every received packet (packet length = 188 bytes).

--- Quote End ---

May you can set up Signaltap to focus on what happens at the start of packet?

--- Quote Start ---

May you can set up Signaltap to focus on what happens at the start of packet?

--- Quote End ---

There is a start of a packet I've mentioned before. I trigger on start signal, but also 0x47 is a start byte. All start signals comes up with 0x47.

I could also suffer from data writes to the middle of the packet when fpga powers up, this means, that 0x47 could anywhere, but not at the start place. I will try to do some safety logic here.