rdusedw not count in my dcfifo

[Altera_Forum]

rdusedw not count in my dcfifo 

 EP3C16F256C8N Quartus II 9.1 sp2 a dcfifo generated by megawizard plugin manager. rdclk: 75MHz wrclk: 40MHz this is a snipping image of a running signaltap(rdclk as the sample clock): http://www.alteraforum.com/forum/attachment.php?attachmentid=3531&stc=1&d=1295551799  the rdusedw is always 0. this is the code from the generated .v file  dcfifo_component.intended_device_family = "Cyclone III", dcfifo_component.lpm_numwords = 256, dcfifo_component.lpm_showahead = "OFF", dcfifo_component.lpm_type = "dcfifo", dcfifo_component.lpm_width = 32, dcfifo_component.lpm_widthu = 8, dcfifo_component.overflow_checking = "ON", dcfifo_component.rdsync_delaypipe = 5, dcfifo_component.underflow_checking = "ON", dcfifo_component.use_eab = "ON", dcfifo_component.write_aclr_synch = "ON", dcfifo_component.wrsync_delaypipe = 5;  why rdusedw not count after wrreq assert?

[Altera_Forum]

possibility 1: is rdclk connected to fifo? 

possibility 2: you have plenty of delay. Have you looked further down in signaltap? possibility 3: you have written till fifo was full and stayed full with rdcounter rolled over to zero and stayed at zero.

[Altera_Forum]

--- Quote Start ---  possibility 1: is rdclk connected to fifo? possibility 2: you have plenty of delay. Have you looked further down in signaltap? possibility 3: you have written till fifo was full and stayed full with rdcounter rolled over to zero and stayed at zero.  --- Quote End ---    possibility 1: I use "...|fifo0:fifo0_inst|rdclk" as the sampling clock of signaltap, if no rdclk, no data in signaltap. possibility 2: I get 256 samples each trigger, the rdusedw never changes. possibility 3: There is a "assign avl_irq = (rdusedw >= 8'd128);" in my design, when I use avl_irq = 1 as the trigger condition, no data captured. And it never stops writting data to fifo.

[Altera_Forum]

Don't lose hope, it must something out there. Fifo usually work. 

 presence of sampling clock does not mean fifo read clock is wired to fifo, simple to rule out.  Your trigger may not work if it misses the startup stage when fpga is configured and write clock starts outright then it will fill up your fifo and the count will settle at zero unless you read fast enough.   Just thoughts...

[Altera_Forum]

I also note that your write clock is less than half speed of read clock as meausred visually in signaltap waveforms. This may give some clue about accurcy of your clocking

[Altera_Forum]

Hard to tell why with the signals that are sampled. I would sample the clear signal to make sure you are not accidentally holding the FIFO in reset as well as sample the empty and full bits for good measure. Like kaz said, your FIFO might be full and as a result the empty bits rolled over to be 0.

[Altera_Forum]

Thanks kaz! 

  --- Quote Start ---  the count will settle at zero unless you read fast enough  --- Quote End ---   Will the rdusedw settle at 0 after fifo is full? you mean it will not count cycling when rolles over, from 255 to 0, then to 1, 2, ... I really don't know about this.  The read end of the fifo is connected to a nios cpu via avalon memmap slave, and read in a ISR, may be I should apply a clear signal just after the ISR being registered.  But... settle at 0... if it will settle at some value, or in another word, saturate at some value, why it's not 255 but 0? settle at 0, result in dead locking of the fifo, but settle at 255, only losing of data. Anyway, I will try appling a clear at read end...    --- Quote Start ---  I also note that your write clock is less than half speed of read clock as meausred visually in signaltap waveforms.  --- Quote End ---   I don't think so, 2 low level samples are gona happen: http://www.alteraforum.com/forum/attachment.php?attachmentid=3533&stc=1&d=1295583980  frequency -> edges count duty -> possibility of high level sample a 50% duty cycled clock by another clock, always get equal numbers of high levels and low levels, unless their freqs share large common divisor.

[Altera_Forum]

Your FIFO is 256 deep. The used signal is 8 bits wide, so when the FIFO is full the used amount is 256 (1,0000,0000 in binary). Since you only have 8 bits for the used signal the 100000000 turns into 00000000 due to truncation. To get the "true" used amount you should concatenate the full and used signals together. i.e. something like this: assign true_used = {fifo_full, fifo_used}; // fifo_used width + 1

[Altera_Forum]

Thank Kaz and BadOmen! 

I wrote a test bench and simulated in modelsim. It really settle at 0! It fixed after I checked the "Add an extra MSB to usedw port" option.