DCFIFO not simulating as expected - no data output on q

[thunderdan]

Folks,

Platform - Q24.1_lite;
Target - Cyclone V;
Language - VHDL;
Sim - Questa_Starter and GHDL.

A little lost as to what's going on here, I've tried to instantiate a DCFIFO (https://www.intel.com/content/www/us/en/docs/programmable/683522/24-2/user-guide.html) and am not seeing the expected simulation results. I have written a simple tb file (attached) that writes a few bytes then attempts to read them back while toggling the wrreq and rdreq as required. The DCFIFO is synchronous with a common clock connected to both wrclk and rdclk.

Sim waveform and code attached.

It appears something is working as the rdused, wrdemty and rdfull signals seem to be working as expected during the read portion of the simulation.. but no data output on q.

I'm seeing the exact simulation results on both Questa and GHDL simulators. Running the everything up on an old install of Q18.1 also results in the same behavior.

I have been looking at this way too long and am hoping someone can see what I'm missing!

[thunderdan · Accepted solution]

Folks,

I believe I have gotten to the bottom of this..  I did notice a few assertion errors being flagged during elaboration,  

altera_mf.vhd:47082:17:@0ms:(assertion error): Error! USE_EAB must be ON or OFF.

altera_mf.vhd:47070:17:@0ms:(assertion error): Error! UNDERFLOW_CHECKING must be ON or OFF.

altera_mf.vhd:47076:17:@0ms:(assertion error): Error! OVERFLOW_CHECKING must be ON or OFF.

As seen in my original code, the above generics look to have been set so I discounted the error thinking it was somehow related to synthesis or implementation as these parameters relate to device specifics and I was only running a behavioral simulation. 

In my effort to figure this out I proceeded to implement a quick hardware design to prove my above assumption. Much to my disgust, the assertion errors were still coming up. After going through the altera_mf.vhd file (wow.. almost 53000 lines!!) i can see the assert is raised if the uppercase string "ON" or "OFF" is not found. My lower case "on" and "off" doesn't cut the mustard, very simple oversight that cost me a day! 

[RichardTanSY_Altera]

Just saw your post—glad to hear you were able to resolve the issue!

It’s easy to overlook something like case sensitivity, especially when the simulation appears to be partially working and the assertion messages seem unrelated at first glance.

I can imagine how frustrating it must have been to track this down.

Thanks for sharing the root cause—this will definitely help others avoid the same pitfall.

Regards,

Richard Tan

[thunderdan]

Interestingly, other generic fields within the dcfifo e.g. clocks_are_synchronized and intended_device_family that have functions that check for both upper or lower case!

[RichardTanSY_Altera]

Now, I will transitioning this thread to community support. If you have any further questions or concerns, please don't hesitate to reach out. Please login to https://supporttickets.intel.com/s/?language=en_US , view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

The community users will be able to help you on your follow-up questions.

Thank you and have a great day!

Best Regards,

Richard Tan

[KennyTan_Altera]

reopening the case

[RichardTanSY_Altera]

I’ll check with the tool specialist to see if we can enhance the feature to remove case sensitivity for capital letters.

However, please be aware that this is in Quartus Lite/Standard, which is currently in maintenance mode. The likelihood of implementing any enhancements is very low, especially since a workaround is already available.

Regards,

Richard Tan

[RichardTanSY_Altera]

deleted post