BUG in simulation library for dcfifo_mixed_widths with Modelsim

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.

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

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

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

Hi,

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

Thanks.

Hi Khai Chein!

Your question is a joke isn't it?

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

Thanks!

Hi Erich,

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

Thanks.