- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi EGrub,
Could you provide the design for investigation? Which version of the software you are using?
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
It would be helpful if you can provide design that is non-confidential for investigation.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
We shall communicate using private message.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you running gate level simulation or RTL simulation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Kay!
I do RTL simulation.
Regards,
Erich
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The image in my previous post is fine, it includes my work around.
Here is the wrong behavior:
Best regards,
Erich
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Please allow me some time to create the test case.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page