BUG in simulation library for dcfifo_mixed_widths with Modelsim

[EGrub]

If a dcfifo_mixed_widths is used (because I need the mixed width) but write and read side getting the same clock signal then simulation fails.

With the read request signal the output changes immediately (without one clock of output delay).

See images with same clock and with different clock!

I wired everything into a struct but the signals are wires!

Different clock is fine, output is one clock later.

Using the same clock, you can see that the output changes immediately!

I have recognized the issue in Quartus 13.1, 15.1 and 17.1.

@ Intel:

Please answer as soon as possible with your suggestions!

BR

Erich

[RRomano001]

Hi Erich, from your forum post, not only forum got worst, also support people seems don't read messages before reply.

Are you Altera centric or use other competitor?

I collected some critics to new Altera behavior, I am just searching for information about bug on simulation release, hardware and correlated.

Most of time simulator crash or report error on VHDL syntax, valid syntax. I simulate on thirdy party or competitor to check just IP core.

When I come back to Quartus design sometimes work and no idea of how to close timing and synthesis to get things work.

I feel this forum is not the best, are you on a neutral one like http://www.fpgadeveloper.com/? Can we join there to get a free of fear opinion about not least share opinion about what to do in the future?

I never used Altera from MM Pal age, Philips PLA (nicr fuse) and Xilinx XACT to mention few.

I migrated to Altera near 2005, designed on near all firm. Luckily speaking I never made large number on this firm.

Previous week I told my custom I fear I am not able to complete design and upset with me due I choosed Altera, made prototypes and fail at production test stage. :(

Best regards

Roberto

[KhaiChein_Y_Intel]

Hi Erich,

Thank you for attaching the third and fourth screenshot of the waveform because I could not find the rdclk in the first and second screenshot. It seems like there is an information mismatch between the waveform and the description. Initially, I thought it was a single clk design because I see only one clock in the first and second waveform. From the third and fourth screenshot, I can see both rdclk and wrclk in the waveform.

Secondly, the behavior for the normal mode and show-ahead mode are different. This is the reason why the question about the FIFO mode was raised. In the parameters provided later, I can know that the FIFO mode is show-ahead.

Thus, I created a test case with reference to the parameters provided. Below is the parameter of the test case:

dcfifo_mixed_widths dcfifo_mixed_widths_component (

.aclr (aclr),

.data (data),

.rdclk (rdclk),

.rdreq (rdreq),

.wrclk (wrclk),

.wrreq (wrreq),

.q (sub_wire0),

.rdempty (sub_wire1),

.rdfull (sub_wire2),

.rdusedw (sub_wire3),

.wrempty (sub_wire4),

.wrfull (sub_wire5),

.wrusedw (sub_wire6));

defparam

dcfifo_mixed_widths_component.add_usedw_msb_bit = "ON",

dcfifo_mixed_widths_component.intended_device_family = "Cyclone V",

dcfifo_mixed_widths_component.lpm_numwords = 256,

dcfifo_mixed_widths_component.lpm_showahead = "ON",

dcfifo_mixed_widths_component.lpm_type = "dcfifo_mixed_widths",

dcfifo_mixed_widths_component.lpm_width = 8,

dcfifo_mixed_widths_component.lpm_widthu = 9,

dcfifo_mixed_widths_component.lpm_widthu_r = 9,

dcfifo_mixed_widths_component.lpm_width_r = 8,

dcfifo_mixed_widths_component.overflow_checking = "ON",

dcfifo_mixed_widths_component.rdsync_delaypipe = 4,

dcfifo_mixed_widths_component.read_aclr_synch = "ON",

dcfifo_mixed_widths_component.underflow_checking = "ON",

dcfifo_mixed_widths_component.use_eab = "ON",

dcfifo_mixed_widths_component.write_aclr_synch = "ON",

dcfifo_mixed_widths_component.wrsync_delaypipe = 4;

In the third and fourth screenshot provided, the third waveform is correct after including your workaround and the fourth waveform is the wrong waveform originally generated as mentioned. Please correct me if I understand wrongly.

Below is the screenshot of the waveform for my test case with the same and different signals for wrclk and rdclk. 

For the same rdclk and wrclk signal, the rdclk and rdreq are high at 85.028ns and the output changes at 95.12ns.

For different wrclk and rdclk signal, the rdclk and rdreq are high at 90.038ns and the output changes at 110ns. 

The behavior for both testcase are similar. I could not replicate the bug reported. Please let me know if I miss out anything so that I can replicate the issue you see in your design. 

Thanks. 

[EGrub]

Hi Khai Chein!

Your simulation seems to work, I had issues when I delayed all signals by 23ps.

I know that is not the usual case and it was not my intention to do so.

Best regards,

Erich

[KhaiChein_Y_Intel]

Hi, May I know how do you write the testbench for the two scenarios described above? - No signal or just the request signals are delayed with 23ps - All the signals (including clock) are delayed by the same amount of time (23ps) Thanks.

[EGrub]

Hi Khai Chein!

Yes it was:

• scenario 1: No delay at all
• sencario 2: all signals including clock were delayed with 23ps

Best regards,

Erich

[KhaiChein_Y_Intel]

Hi Erich, Can you share the testbench file? Are you adding delay for rdreq using # or with reference to posedge of the rdclk? Thanks.

[EGrub]

Hi Khai Chein!

No I can not share my testbench, because I did not build a testbench around the FIFO. I integrated the FIFO in my own module and tested that module. Additionally you would not be able to start it as it is a co simulation of system verilog and C++

I used # to delay signals.

Best regards,

Erich

[KhaiChein_Y_Intel]

Hi,

Can you add the delay for rdreq with respect to the posedge of the rdclk and see if the problem persists?

Thanks.

[EGrub]

Hi Khai Chein!

Your question is a joke isn't it?

Please read post: https://forums.intel.com/s/question/0D70P000006GX54SAG

Thanks!

[KhaiChein_Y_Intel]

Hi Erich,

I have sent the sample test case to you. I look forward to hearing from you.

Thanks.