DCFIFO simultaneous read and write problem

[Altera_Forum]

I'm having problems with the dcfifo IP block when simulating in modelSim. 

 I'm using the same clock on both the read and writes ports, I'm only using the dual clock FIFO as I want to feed data in with 32bit width and read out 16bit width.  The error occurs when there is a write and read on the same clock cycle.  The fifo is configured as:  intended_device_familt => "Cyclone IV GX", lpm_numwords => 1024, lpm_showahead => "ON", lpm_type => "dcfifo_mixed_widths", lpm_width => 32, lpm_widthu => 10, lpm_widthu_r => 12, lpm_width_r => 16, overflow_checking => "ON", rdsync_delaypipe => 3, read_aclr_synch => "OFF", underflow_checking => "ON", use_eab => "ON", write_aclr_synch => "ON", wrsync_delaypipe => 3  My testbench runs OK until there happens to be a clock cycle where wrreq and edreq are both '1'. The value written here is lost along with many subsequent writes. Data is still read out OK until we get to reading the value where the simultaneous access occurred, and then we just get "000...." out.  The level of the FIFO is 1931 as reported on the rdusedw port. At the time the simultaneous access occurs my test bench is reading data faster than it's writing. So although the FIFO is quite full it isn't overflowing.  I have tried putting in a line of code to delay the write clock by 1 simulation delta cycle (writeClock <= clock) and even delaying the write clock (writeClock <= clock after 1nS), but this has had no effect.  I haven't tried running this design on hardware yet, so can't say if this is just a simulation error or not, but I can't believe that this FIFO would fail in this way.  Any ideas?  Mark

[Altera_Forum]

This does sound a bit odd, and I hope it's just a simulation issue. 

 One bug I have noticed, is that your lpm_widthu_r is wrong. It should be 11, not 12, as the read port only has 2048 locations (unless you're trying to see the depth when it's full, but Im not sure if the internal logic will work like that).  Does the FIFO report the data is valid? was the wrfull flag high when you wrote the failing value in? Try stopping the write at the point of the failing data, is the "0000..." value marked as not empty?  I did find a bug a long long time ago (about 7 years ago) with the DC fifo. I had a similar config to you (but ip and op widths were the same) and the read and write clocks were the same clock frequency but from different sources (so there were some PPM differences). Every now and again the read side pointer would reset back to 0 for no apparent reason, and as the data was video data, you would see the left side of the specific line repeated on the rhs of the screen. This was on a Cyclone 1. Never a problem with a sim, just an implementation glitch (and took a long while to find the source.)

[Altera_Forum]

Thanks Tricky, 

 I have the lpm_widthu_r set to 12 so that it doesn't roll round to 0 when full. There is an option in the Mega Wizard that allows you to add an extra MSB to the level.  My system has an external bus that reads the FIFO along with a number of status and control registers. So that the level reports correctly I need the extra bit. In the past when I've used the single clock fifo I've just appended the full flag. Because of the pipeline in the dual clock FIFO the I couldn't do this here, so I manually added one bit to the lpm_widthu_r.  My design doesn't use the wrusedw port, so I didn't think to change the lpm_widthu generic.  Setting lmp_width_u to 11 has fixed my design! :)  Seems that if you add the extra MSBit to the "used words" ports you need to do it on both.:confused:  Mark

[Altera_Forum]

Also I was missing the generic add_usedw_msb_bit <= "ON". 

 Looks like Altera should really be putting some assertions within the IP code that check the configuration.