09-18-2014 02:10 AM
I have problem with my built-in independent clock FIFO. I use it this way.
As can you see i perform reset and i also wait to assertion of LOCKED signal from MMCM. img_stab_clk and sd_card_clk both are 100Mhz and came form CLKOUT0 and CLKOUT1 in MMCM.
The problems is that when I assert WR_EN it doesnt affect EMPTY - its still '1'. Isim didnt report any error related to FIFO. Ive also tried the clock-dependent built-in FIFO but it didint help.
09-18-2014 03:02 AM
Standard FIFO Read Operation
"Once the user writes at least one word into the FIFO, EMPTY is deasserted — indicating data is available to be read"
In my case it didnt happen. After reset, the EMPTY is set to one by default. Then I start to write fisrt word to FIFO sa EMPTY should be driven low but its still '1'.
I didint mention it but the problem is the FIFO do not de-assert EMPTY after FIRST written word, just after reset. Its shown at the screenshot above.
09-18-2014 03:15 AM - edited 09-18-2014 03:16 AM
Yes, Empty should reflect the writes but I think it might have some latencies.
What is your core configuration, can you atatch your .xci/.xco?
Did you provide read clock, I do not see it in snapshot...
09-18-2014 03:31 AM
1. Ive checked if EMPTY changed to '1' in next 10 us, but it didint. Signals visible on screenshot are taken directly form fifo instantiation
2. Core configuration is built-in clock independent FIFO - As simple as possible. xco file in attachments.
3. read and write clock are the same. Ive also tried to generate IP core with common clock but it didint work neither.
09-18-2014 06:32 AM - edited 09-18-2014 06:33 AM
There are some known deficiencies in the behavioral FIFO models. When you generated the core, was your project set to generate Behavrioal or Structural simulation models?
[Edit] Never mind. I can see it in the .xco file that it should have built the Structural model.
09-19-2014 05:22 AM
Ive tesed FIFO in example_design by lunching simulate_isim.sh and its working correctly. The only difference beetwen example design and my design is clock source. Ive changed the clock source in my design from MMCM to extarnal port(generated in test bench) and FIFO is working correctly.
When I used MMCM to generate clock I kept RST high as long as LOCKED is low. After assertion of LOCKED I set RST low. What is wrog with this approach?
Never mind... After Ive changed clock to MMCM again , FIFO works correctly. Very strange behaviour
09-19-2014 06:11 AM
Look in the TCL Console: the FIFO will print many messages if the resets, clocks and enables do not operate properly: number of clock cycles before reset, length of reset, time between reset and enable, some others I am forgetting.
09-19-2014 06:15 AM
Very strange behavior indeed. In you last screen shot, you showed the signals from within the FIFO module, so the source of the clocks should not have mattered. It really sounds like there is a bug in the simulation model, perhaps only the VHDL version? I have not run into this issue with Verilog. I remember that older VHDL block RAM models had issues due to clock buffering within the model that caused the BRAM to appear to read out asynchronously if the address input did not have some hold time after the clock edge. If you could come up with a minimal project that shows the issue, Xilinx should look at it.
09-19-2014 06:48 AM
Yes you are right but as I wrote before ISIM console didint report any reset issue, however FIFO EMPTY didnt respond. Now I counducted successful reset cycle. It shoudl looks like that:
ISIM report DRC error after first RST falling edge but dont complain after second one, so I suppose its correct.
09-19-2014 07:06 AM
Im afraid this bug will be hard to replicate. Honestly I really hope it wont come back. I think that the problem could be DRC. Because ISIM didnt report any DRC errors - no matter how the reset cycle was pefromed. Now as I wrote above its reporting about unsuccessfull reset.
09-30-2014 12:15 AM
Im posting in the same thread because I have another problem with fifo simulation. My design hierarchy looks like that:
When aurora_top module is removed form project FIFO works correctly:
But when Im adding aurora_top file to project(even without aurore.xco ip core) iSIM prints this errors:
at 4974600 ps(9): Error: A RESET cycle must be observerd before the first use of the FIFO instance.
and FIFO empty signal is not responding.
09-30-2014 12:18 AM
Check below link
09-30-2014 12:29 AM
I know how to perform reset cycle and I showed it at screenshot above. As you can see Its working properly and iSIM doesnt print any errors. But it only works when aurora_top.vhd file is not included in project. When I add it again the reset is not working, though I perform reset cycle exactly the same way...
It looks like some bug.
09-30-2014 06:24 AM
In previous post I was asked to prepare minimal project to let you look at this problem. Its attached. Its enough just to run Virtex1_tb and take a look at FIFO1 component. Please pay attention that iSIM conosole doesnt report any errors related to reset cycle. I remeber that at the first falling edge of RSTR signal there was always information about DRC issues...