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

[AndyN]

Do you have the intended_device_family parameter set to something other than default? For some reason, the simulation models for the fifos seem to do strange things otherwise...

Hope that helps,

Andy

[EGrub]

Hi Andy!

Thank you for your reply. I've set it to:

dcfifo_mixed_widths_component.intended_device_family = "Cyclone V",

I don't think that is the problem for the simulation, I think the issue is in the simulation lib altera_mf.v and dcfifo_sync

There they set the flag i_showahead_flag2 with the wr and the rd clock

and the output does not depend on clock but on posedge i_showahead_flag2:

always @(posedge i_showahead_flag)

  begin

    i_q_tmp <= mem_data[i_rdptr[lpm_widthu-1:0]];

    i_showahead_flag2 <= 1'b0;

  end // @(posedge i_showahead_flag)

and at the end:

assign q = i_q_tmp;

So I think that is the issue

Regards,

Erich

[EGrub]

My workaround was to delay Wr and Rd signal by a few ps but the behavior of the lib is wrong!

Please Intel test it and fix the bug!

Regards,

Erich

[KhaiChein_Y_Intel]

Hi EGrub,

Could you provide the design for investigation? Which version of the software you are using?

Thanks

[EGrub]

Hi YY!

As I have written in my first post: I have recognized the issue in Quartus 13.1, 15.1 and 17.1.

To provide you with something, how is the procedure now with NDAs? Is the old NDA with Altera still valid? How to send you the files? I will for sure not upload it to the forum.

But it should be easy to test for you by instantiating a dual clock fifo with different bitwidths and lookahead. Additional information on timings you can extract from my screenshots.

Regards,

Erich

[KhaiChein_Y_Intel]

Hi,

It would be helpful if you can provide design that is non-confidential for investigation.

Thanks.

[EGrub]

Hi YY!

In advance sorry for the following reply, it is nothing against you personally and I know it would maybe fit better into the flames, but:

Intel decided to replace a good working support tool (the old service requests) by a non working forum at all with the following drawbacks:

• No direct support
• The forum has a lot of bugs it self!!!
• No subcategories
• no possibility to provide confidential data
• the old forum worked better
• and some more

So no I will not provide you with my simulation because you will not be able to run it anyway.

No I will not provide you with a non-confidential design because I will not get time from my boss to generate it.

Please report to your boss that I'm unhappy with the overall support (not your support) but the type of support and the forum it self.

Regards,

Erich

[KhaiChein_Y_Intel]

Hi,

We shall communicate using private message.

Thanks

[Kay]

Are you running gate level simulation or RTL simulation?

[EGrub]

Hi Kay!

I do RTL simulation.

Regards,

Erich

[EGrub]

@KhaiY_Intel​ 

Have you received my private message?

Regards,

Erich

[KhaiChein_Y_Intel]

Hi Erich,

In both the screenshot attached, I can see only one clock, which is wClk. Are you using a SCFIFO or DCFIFO? Which mode ( Legacy mode / Show-ahead mode) you are using for both the FIFO?

Thanks.

[EGrub]

Hi YY!

Please read my first post carefully.

Here are the parameters:

dcfifo_mixed_widths dcfifo_mixed_widths_component (

      .rdclk (rdclk),

      .wrclk (wrclk),

      .wrreq (wrreq),

      .aclr (aclr),

      .data (data),

      .rdreq (rdreq),

      .wrempty (sub_wire0),

      .wrfull (sub_wire1),

      .q (sub_wire2),

      .rdempty (sub_wire3),

      .rdfull (sub_wire4),

      .wrusedw (sub_wire5),

      .rdusedw (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 = P_BUFFER_SIZE,

   dcfifo_mixed_widths_component.lpm_showahead = "ON",

   dcfifo_mixed_widths_component.lpm_type = "dcfifo_mixed_widths",

   dcfifo_mixed_widths_component.lpm_width = P_INPUT_WIDTH,

   dcfifo_mixed_widths_component.lpm_widthu = P_INPUT_FILL_WIDTH,

   dcfifo_mixed_widths_component.lpm_widthu_r = P_OUT_FILL_WIDTH,

   dcfifo_mixed_widths_component.lpm_width_r = P_OUTPUT_WIDTH,

   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;

and a screenshot from Modelsim showing all signals from that dcfifo:

You can see there the output changes immediately with the same clock the read request is captured, I marked it with the cursor.

Best regards,

Erich

[EGrub]

The image in my previous post is fine, it includes my work around.

Here is the wrong behavior:

Best regards,

Erich

[KhaiChein_Y_Intel]

Hi,

Please allow me some time to create the test case.

Thanks

[EGrub]

I did some further tests and I can bring some light into that issue. I analyzed it further and used the "Events mode" display in Modelsim.

I have now two examples where the same input is send to the FIFO. One time it behaves properly one time it fails.

The following situation is fine:

No signal or just the request signals are delayed with 23ps -> simulation works as you would expect.

In "Event Display mode" one can see that the clock is the first event and the read request signal comes later in the events.

The following situation it fails:

All the signals (including clock) are delayed by the same amount of time (23ps). So all the signals arrive the FIFO at the same time (as in the working situation described above)

In "Event Display mode" one can see that for any reason the read request signal is computed first. -> So with the next clock cycle (which actually had the rising edge at the same time as the request signal) the output is changed -> reason for the to early output.

So the behavior of that FIFO simulation model is weird. In my opinion if I look at it as a black box it should behave the same way if I input the same signals at any time!

Of course it is not the usual case to delay the clock signal and it is an edge case.

Best regards,

Erich

[KhaiChein_Y_Intel]

Hi,

I created two test cases. The behavior for both test cases are the same. The output signal is high at positive edge of the rdclk when rdreq is high. Attached are the waveforms for same rdclk & wrclk and different rdclk & wrclk. 

Thanks.

[EGrub]

Hi YY!

Thank you for your reply!

Have you read my previous reply? It seems that in my case Modelsim changed the priority of the input signals and the read request signal was computed before the clock signal! As I wrote above one can see it with event mode enabled.

I have no idea why that happened, I will not further investigate on it.

How to continue?

Best regards,

Erich

[KhaiChein_Y_Intel]

Hi,

The last screenshot captures only the beginning of the waveform and there is no change of the clock signal and output data. Could you provide a full waveform with a few clock signals and changes of the output data?

Thanks

[EGrub]

Hi YY!

Those images are just a zoom image, to the rising edge of rdreq. Zoomed out it looks like here: https://forums.intel.com/s/question/0D70P000006GWhbSAG

Best regards,

Erich