cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hghbaobin
Observer
Observer
15,577 Views
Registered: ‎11-27-2008

About FIFO RST PORT and Empty PORT

Jump to solution

I use fifo generate 4.3  togenerate a FIFO

1. I give a rst port high for 10us , when FIFO RST is Assert I still give FIFO Write And Read Signal ,The FIFO'DOUT PORT act just like FIFO is  RST signal is not assert

 

2.In post route Simulation I give a rst port high for 1 us and at 2us I give a Write Signal ,But Empty Signal Need about 4 read clk cycle to be low 

0 Kudos
1 Solution

Accepted Solutions
gszakacs
Professor
Professor
22,376 Views
Registered: ‎08-14-2007

You didn't mention what parameters you used when generating your FIFO.  i.e.  is this

using BRAM, distributed RAM, or built-in FIFO?  From your mention of "read clock" I

assume it is "asynchronous" (dual clocked).

 

Your first point seems to be a problem with the behavioral simulation model.  I have

noticed that in ModelSim I see some message about the behavioral model being

"not cycle accurate".  This is probably an understatement.

 

As to the second point, depending on the design parameters it seems reasonable

that the empty flag could take four clock cycles to de-assert after a write.  The

flag code is "conservative" in that it makes sure that something is in the FIFO

before de-asserting empty and similarly makes dure there is room left in the

FIFO before de-asserting full.  I expect the built-in FIFO's of Virtex 5 to do a

little better than 4 cycles, but again this may depend on the relative clock

frequencies as well.  If your write clock is much slower than the read clock

for instance the flag may need another cycle of the write clock after the

cycle you assert write enable.  This could account for several read clock

cycles if the write clock is much slower.

-- Gabor

View solution in original post

3 Replies
gszakacs
Professor
Professor
22,377 Views
Registered: ‎08-14-2007

You didn't mention what parameters you used when generating your FIFO.  i.e.  is this

using BRAM, distributed RAM, or built-in FIFO?  From your mention of "read clock" I

assume it is "asynchronous" (dual clocked).

 

Your first point seems to be a problem with the behavioral simulation model.  I have

noticed that in ModelSim I see some message about the behavioral model being

"not cycle accurate".  This is probably an understatement.

 

As to the second point, depending on the design parameters it seems reasonable

that the empty flag could take four clock cycles to de-assert after a write.  The

flag code is "conservative" in that it makes sure that something is in the FIFO

before de-asserting empty and similarly makes dure there is room left in the

FIFO before de-asserting full.  I expect the built-in FIFO's of Virtex 5 to do a

little better than 4 cycles, but again this may depend on the relative clock

frequencies as well.  If your write clock is much slower than the read clock

for instance the flag may need another cycle of the write clock after the

cycle you assert write enable.  This could account for several read clock

cycles if the write clock is much slower.

-- Gabor

View solution in original post

hghbaobin
Observer
Observer
15,548 Views
Registered: ‎11-27-2008

I tried Block RAM And Distributed RAM, 

Empty Port just as U Said ,It take four  Read clock cycles to de-assert after a write. It take no time to de-assert after a write In  behavioral simulation.MayBe This is behavioral model being

"not cycle accurate".

Rst Port I did Post Route Simulation, FIFO Still not Clear write and read point!!!!!!!!

 

0 Kudos
kylocke18
Xilinx Employee
Xilinx Employee
15,516 Views
Registered: ‎08-01-2007

Hello,

 

For your first point, note that the FIFO v4.x cores use an edge sensitive reset, not level-sensitive.  So the core will exit the reset state after a set amount of clock cycles regardless of whether you have RST asserted still.  This has been clarified in the FIFO v4.4 User Guide (UG175) on page 72:

 

"Note: The reset is edge sensitive and not level sensitive. The synchronization logic looks for the
rising edge of RST and creates an internal reset for the core. Note that the assertion of asynchronous
reset immediately causes the core to go into a predetermine reset state - this is not dependent on any
clock toggling. The reset synchronization logic is used to ensure that the logic in the different clock
domains comes OUT of the reset mode at the same time - this is by synchronizing the deassertion of
asynchronous reset to the appropriate clock domain. By doing this glitches and metastability can be
avoided. This synchronization takes 4 clock cycles (write or read) after the asynchronous reset is
detected on the rising edge read and write clock respectively. "

 

 

For your second point, I think the first reply from gzsakacs summarized it well.

 

-Kyle

 

Message Edited by kylocke18 on 12-01-2008 10:50 AM