Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

BUG in simulation library for dcfifo_mixed_widths with Modelsim

EGrub
Beginner
3,174 Views

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.

different_clk.png

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

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

0 Kudos
30 Replies
AndyN
New Contributor I
1,731 Views

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

0 Kudos
EGrub
Beginner
1,731 Views

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

 

 

 

0 Kudos
EGrub
Beginner
1,731 Views

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

0 Kudos
KhaiChein_Y_Intel
1,731 Views

Hi EGrub,

 

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

 

Thanks

0 Kudos
EGrub
Beginner
1,731 Views

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

 

0 Kudos
KhaiChein_Y_Intel
1,731 Views

Hi,

 

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

 

Thanks.

0 Kudos
EGrub
Beginner
1,731 Views

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

0 Kudos
KhaiChein_Y_Intel
1,731 Views

Hi,

We shall communicate using private message.

Thanks

 

 

0 Kudos
Kay
Beginner
1,731 Views

Are you running gate level simulation or RTL simulation?

0 Kudos
EGrub
Beginner
1,731 Views

Hi Kay!

 

I do RTL simulation.

 

Regards,

Erich

0 Kudos
EGrub
Beginner
1,731 Views

@KhaiY_Intel​ 

Have you received my private message?

Regards,

Erich

0 Kudos
KhaiChein_Y_Intel
1,731 Views

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.

0 Kudos
EGrub
Beginner
1,731 Views

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:DCLK_FIFO_same_clk.png

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

0 Kudos
EGrub
Beginner
1,731 Views

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

Here is the wrong behavior:

DCLK_FIFO_same_clk_issue.png

 

Best regards,

Erich

0 Kudos
KhaiChein_Y_Intel
1,731 Views

Hi,

 

Please allow me some time to create the test case.

 

Thanks

0 Kudos
EGrub
Beginner
1,731 Views

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.

event_display_fine1.png

 

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.

event_display_wrong1.png

 

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

0 Kudos
KhaiChein_Y_Intel
1,730 Views

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. 

 

Same clk.PNGDiff clk.PNG

Thanks.

0 Kudos
EGrub
Beginner
1,730 Views

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

0 Kudos
KhaiChein_Y_Intel
1,730 Views

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

0 Kudos
EGrub
Beginner
1,716 Views

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

0 Kudos
Reply