Xilinx FIFO usage

It is my first time here, so hello everybody! :)

I have problems with Xilinx FIFO on Spartan 3. As far as I understand it,
standard FIFO sends data out in the next clock cycle after I set 'rd_en'
signal to '1'. In my case I get output not in the next, but in the second
clock cycle. Do you know what may cause that problem? 

Here is what I do (first I put in FIFO two byte words):
STATE1 => if FIFO is not empty then 'rd_en' to '1', go to STATE2,
STATE2 => I keep 'rd_en' equal '1', and go to STATE3, (the output here is
zero),
STATE3 => I know there were two byte words so  'rd_en' to '0', here I can
get first byte, and I go to STATE4,
STATE4 => 'rd_en' still '0', I can get second byte, then I go and stay into
IDLE state.

Every state last one clock cycle, instead of STATE1 where I wait for not
empty FIFO and IDLE obviously after all.

Regards,
Valdez

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Valdez wrote:
> It is my first time here, so hello everybody! :)
>
> I have problems with Xilinx FIFO on Spartan 3. As far as I understand it,
> standard FIFO sends data out in the next clock cycle after I set 'rd_en'
> signal to '1'. In my case I get output not in the next, but in the second
> clock cycle. Do you know what may cause that problem?

I suppose you are using a FIFO generated with Core Generator? There is 
an option there to "use embedded registers". If you enable that, a 
register stage will be added at the FIFO output, adding one clock cycle 
of delay. But I believe that is not your problem, see below.

> Here is what I do (first I put in FIFO two byte words):
> STATE1 => if FIFO is not empty then 'rd_en' to '1', go to STATE2,
> STATE2 => I keep 'rd_en' equal '1', and go to STATE3, (the output here is
> zero),
> STATE3 => I know there were two byte words so  'rd_en' to '0', here I can
> get first byte, and I go to STATE4,
> STATE4 => 'rd_en' still '0', I can get second byte, then I go and stay into
> IDLE state.

So you expect to get the first data word in STATE2? I suppose you have 
your state machine in a clocked process. If you look at the simulation, 
you should be able to see that the rd_en-signal you set to '1' in STATE1 
doesn't go high until you reach STATE2. That's because rd_en is the 
output of a flip flop and will not be updated until the next rising edge 
of the clock (or falling edge, if that's how you wrote it).

One clock cycle later (by then you've reached STATE3) the first data 
word appears at the FIFO output, so everything's "logical" and behaves 
the way that it should (data is available one clock cycle after rd_en is 
set to '1').

Hope that helps,
Sean

>Valdez wrote:
>> It is my first time here, so hello everybody! :)
>>
>> I have problems with Xilinx FIFO on Spartan 3. As far as I understand
it,
>> standard FIFO sends data out in the next clock cycle after I set
'rd_en'
>> signal to '1'. In my case I get output not in the next, but in the
second
>> clock cycle. Do you know what may cause that problem?
>
>I suppose you are using a FIFO generated with Core Generator? There is 
>an option there to "use embedded registers". If you enable that, a 
>register stage will be added at the FIFO output, adding one clock cycle 
>of delay. But I believe that is not your problem, see below.
>
>> Here is what I do (first I put in FIFO two byte words):
>> STATE1 => if FIFO is not empty then 'rd_en' to '1', go to STATE2,
>> STATE2 => I keep 'rd_en' equal '1', and go to STATE3, (the output here
is
>> zero),
>> STATE3 => I know there were two byte words so  'rd_en' to '0', here I
can
>> get first byte, and I go to STATE4,
>> STATE4 => 'rd_en' still '0', I can get second byte, then I go and stay
into
>> IDLE state.
>
>So you expect to get the first data word in STATE2? I suppose you have 
>your state machine in a clocked process. If you look at the simulation, 
>you should be able to see that the rd_en-signal you set to '1' in STATE1 
>doesn't go high until you reach STATE2. That's because rd_en is the 
>output of a flip flop and will not be updated until the next rising edge 
>of the clock (or falling edge, if that's how you wrote it).
>
>One clock cycle later (by then you've reached STATE3) the first data 
>word appears at the FIFO output, so everything's "logical" and behaves 
>the way that it should (data is available one clock cycle after rd_en is 
>set to '1').
>
>Hope that helps,
>Sean
>

Sure that helps :)
I am new at this and always forgot that signals value is changed after
clock cycle. Thanks for reminder.
I will have to check this in ISim on Windows, because I can't run it on
Ubuntu.

But I don't see now how to get data in situation, when I switch between two
states in a clocked process. In first state I'd like to get data byte, in
the second I don't want next byte. Then I go back to the first... it will
be repeated 512 times. Could you please give me idea for such an
algorithm?

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Fri, 21 Dec 2012 02:57:47 -0600, Valdez wrote:

>>Valdez wrote:

> I will have to check this in ISim on Windows, because I can't run it on
> Ubuntu.

Why not? I've been running ISim on both OpenSuse 11.x and Debian, so it 
ought to run on Ubuntu. 

(There may be some dependency you have to install, or some path to fix, 
but that's about it...)

- Brian

>On Fri, 21 Dec 2012 02:57:47 -0600, Valdez wrote:
>
>>>Valdez wrote:
>
>> I will have to check this in ISim on Windows, because I can't run it on
>> Ubuntu.
>
>Why not? I've been running ISim on both OpenSuse 11.x and Debian, so it 
>ought to run on Ubuntu. 
>
>(There may be some dependency you have to install, or some path to fix, 
>but that's about it...)
>
>- Brian
>
Yes, missing libraries. I tried to follow some instructions, but I can't
run ISim when the project includes Core Generator modules. I will try
during Xmas, when will be more time and no access to hardware :)	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com