Stratix III FPGA: Problem using Asynchronous FIFOs

[Altera_Forum]

Hi, 

   I’m using a Stratix III FPGA and I have made a design using two interconnected Asynchronous FIFOs and when I launch the Post-Place and route simulation (using Modelsim) it doesn’t work for high frequencies. However, when I compile it with Quartus, the calculated frequency is three times higher. Why can it happen?    The configuration of the FIFOS is:   

• Two clocks 
• Asynchronous clear 
• Width: 128 bits 
• Depth: 4 words 
• Show ahead synchronous FIFO mode 

  In attached files you can find the vhdl files.    Thank you in advance.

[Altera_Forum]

I have tried to disable the register using tcheck_set in Modelsim but it doesn't recognise the command. I have found an option that lets disable all timing checks, not an specific one.

[Altera_Forum]

The tcheck_set command is only available within the vsim environment, so you need to run it after you've started the simulation. 

You also need to run the command every time you restart the simulation.

[Altera_Forum]

Hello, 

I've also got interesting problem with DCFIFO, which is mixed width.  The FIFO has 9bit input (start signal plus 8bit data) and 36bit output. Input clock: 135MHz, but wrreq is asserted only every 5 clock edges, so basically I have a 27MHz data flow. The read side use 125MHz clock and starts reading the data when the FIFO is half full (I use rdusedw bus for that). Pipeline level set to 3. The problem is that on signaltap, I see incoming data: 0x47 0x1F 0xFF 0x10 0x00 0x00 0x00 0x00 But the output is a mess: 0x47000000 0x0010FF1F  Strange is that I can rarely get the design working correctly, but mostly this part fails. I suppose, I have some timing problems, so let's check what do I have. In order to see timing errors between clock crossings, I've made async clock groups:  set_clock_groups -asynchronous -group { PLL0|altpll_component|auto_generated|pll1|clk PLL0|altpll_component|auto_generated|pll1|clk } -group { PLL1|altpll_component|auto_generated|pll1|clk PLL1|altpll_component|auto_generated|pll1|clk PLL1|altpll_component|auto_generated|pll1|clk }# Here:# PLL0 c0 -> 125MHz system clock (runs QSys and all the stuff)# PLL0 c1 -> 125MHz -65deg clock, which goes directly to SDRAM chip clk pin# PLL1 c0 -> 337.5MHz ASI soft receiver oversample clock# PLL1 c1 -> 337.5MHz +90deg same as above# PLL1 c2 -> 135MHz ASI receiver data clock   The timequest shows me some setup violations, but that are only for Qsys internal signals, which has nothing to do with the FIFO I'm writing here, so I am not sure what's happening. Is it possible to see Fmax for FIFO interfaces? Or maybe my read clock is too fast?  Thanks.

[Altera_Forum]

The pipeline level should be set to 5. from the 'SCFIFO and DCFIFO Megafunctions User Guide' : 

--- Quote Start ---   Specify the number of synchronization stages in the cross clock domain. The value of the RDSYNC_DELAYPIPE parameter relates the synchronization stages from the write control logic to the read control logic, while the WRSNYC_DELAYPIPE parameter relates the synchronization stages from the read control logic to the write control logic. Use these parameters to set the number of synchronization stage if the clocks are not synchronized, and set the CLOCKS_ARE_SYNCHRONIZED parameter to FALSE. The actual synchronization stage implemented relates variously to the parameter value assigned, depends on the target device. For Cyclone II and Stratix II devices and onwards, the values of these parameters are internally reduced by 2. Thus, the default values of 3 for these parameters correspond to a single synchronization stage, a value of 4 results in 2 synchronization stages, and so on. For these devices, choose the value at least of 4 (2 synchronization stages) for metastability protection. See “Metastability Protection and Related Options” on page 15.  --- Quote End ---  

[Altera_Forum]

Hm, that didn't help. 

Btw, Design Assistant shows me critical warning: Warning (308071): (Medium) Rule D102: Multiple data bits that are transferred across asynchronous clock domains are synchronized, but not all bits may be aligned in the receiving clock domain. (Value defined:2). Found 7 asynchronous clock domain interface structure(s) related to this rule.  And inside this warning, I see my core, which has that DCFIFO inside.

[Altera_Forum]

What's the fifo depth? it must be at least 8 for a dcfifo to work correctly. For a dcfifo_mixed_widths it may well be the depth on the 'wide' side. 

The Design Assistant warning should have been suppressed by the dcfifo-code.

[Altera_Forum]

It's 9bit on write side and 36bit on read side: 

component ts_fifo1 PORT ( aclr : IN STD_LOGIC := '0'; data : IN STD_LOGIC_VECTOR(8 DOWNTO 0); rdclk : IN STD_LOGIC; rdreq : IN STD_LOGIC; wrclk : IN STD_LOGIC; wrreq : IN STD_LOGIC; q : OUT STD_LOGIC_VECTOR(35 DOWNTO 0); rdempty : OUT STD_LOGIC; rdusedw : OUT STD_LOGIC_VECTOR(10 DOWNTO 0)); end component;   wrclk = 135MHz wrreq goes high every 5 clock edges rdclk = 125MHz rdreq goes high, when rdusedw'high = '1';  FIFO parameters:  PARAMETERS ( ACF_DISABLE_MLAB_RAM_USE = "FALSE", ADD_RAM_OUTPUT_REGISTER = "OFF", ADD_USEDW_MSB_BIT = "OFF", CLOCKS_ARE_SYNCHRONIZED = "FALSE", DELAY_RDUSEDW = 1, DELAY_WRUSEDW = 1, LPM_NUMWORDS, LPM_SHOWAHEAD = "OFF", LPM_WIDTH, LPM_WIDTH_R = 0, LPM_WIDTHU = 1, LPM_WIDTHU_R = 1, MAXIMIZE_SPEED = 5, OVERFLOW_CHECKING = "ON", RAM_BLOCK_TYPE = "AUTO", RDSYNC_DELAYPIPE = 5, READ_ACLR_SYNCH = "OFF", UNDERFLOW_CHECKING = "ON", USE_EAB = "ON", WRITE_ACLR_SYNCH = "OFF", WRSYNC_DELAYPIPE = 5, CBXI_PARAMETER = "NOTHING" );

[Altera_Forum]

The parameter block you show is inside a .tdf file, I presume, the 'real' parameters are found in the invocation of that .tdf, one level higher.  

For a dcfifo LPM_NUMWORDS must be at least 8 (and preferably a power of 2). I guess that in the case of a dcfifo_mixed_widths as used in your case it must be 32 to guarantee those 8 words at the output side.

[Altera_Forum]

Unfortunately, the higher level of file, I've posted contents before, is megawizard file. Clicking on it opens a megawizard.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

Maybe you should trigger on the endofpacket and see whether there are no superfluous writes there? Which would upset the fifo on the next packet

[Altera_Forum]

Can you reproduce the problem it with a gate-level simulation?