cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wyrwikufel
Contributor
Contributor
12,200 Views
Registered: ‎11-18-2013

FIFO EMPTY flag

Hi,

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.

 

Virtex6

0 Kudos
14 Replies
wyrwikufel
Contributor
Contributor
12,191 Views
Registered: ‎11-18-2013

Screenshot of the simulation:

Screenshot from 2014-09-18 11:13:37.png

0 Kudos
wyrwikufel
Contributor
Contributor
12,168 Views
Registered: ‎11-18-2013

fifo_generator_ug175.pdf

Standard FIFO Read Operation

page 106:

"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. 

0 Kudos
vsrunga
Xilinx Employee
Xilinx Employee
12,158 Views
Registered: ‎07-11-2011

Hi,

 

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...

---------------------------------------------------------------------------------------------
Please do google search before posting, you may find relavant information.
Mark the post - "Accept as solution" and give kudos if information provided is helpful and reply oriented
0 Kudos
wyrwikufel
Contributor
Contributor
12,154 Views
Registered: ‎11-18-2013

Screenshot from 2014-09-18 12:20:46.png

 

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.

0 Kudos
gszakacs
Instructor
Instructor
12,121 Views
Registered: ‎08-14-2007

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.

-- Gabor
0 Kudos
wyrwikufel
Contributor
Contributor
12,097 Views
Registered: ‎11-18-2013

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

 

 

0 Kudos
dwisehart
Scholar
Scholar
12,090 Views
Registered: ‎06-23-2013

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.

 

Daniel

 

0 Kudos
gszakacs
Instructor
Instructor
12,088 Views
Registered: ‎08-14-2007

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.

-- Gabor
0 Kudos
wyrwikufel
Contributor
Contributor
12,081 Views
Registered: ‎11-18-2013

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: Screenshot from 2014-09-19 15:43:22.png

ISIM report DRC error after first RST falling edge but dont complain after second one, so I suppose its correct.

0 Kudos
wyrwikufel
Contributor
Contributor
9,202 Views
Registered: ‎11-18-2013

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.

0 Kudos
wyrwikufel
Contributor
Contributor
9,132 Views
Registered: ‎11-18-2013

Im posting in the same thread because I have  another problem with  fifo simulation.  My design hierarchy looks like that:

Screenshot from 2014-09-30 09:06:16.png

 

When aurora_top module is removed form project FIFO works correctly:

Screenshot from 2014-09-30 09:07:02.png

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.

 

?

0 Kudos
yenigal
Xilinx Employee
Xilinx Employee
9,130 Views
Registered: ‎02-06-2013

Hi

 

Check below link

http://forums.xilinx.com/t5/Simulation-and-Verification/FIFO18E1-and-FIFO36E1-reset-issue/td-p/477928

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
wyrwikufel
Contributor
Contributor
9,125 Views
Registered: ‎11-18-2013

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...

 

Screenshot from 2014-09-30 09:14:21.png

 

It looks like some bug.

0 Kudos
wyrwikufel
Contributor
Contributor
9,069 Views
Registered: ‎11-18-2013

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...

0 Kudos