fifo occupancy bigger than fifo size?

Note: using EDk 8.2.02 with peripheral generated with the wizard with FIFO
enabled and one user interrupt that is set to the fifo_almostfull line.

I'm set up to generate interrupts on the fifo almost full signal but I get a
couple interrupts and then it stops. If I go read the occupancy register I
get a number(0x737) greater than the size of the fifo (0x400). If I then go
and manually read from the fifo data register(from gdb) I can get the
occupancy to go back to 0x400 and the next interrupt occurs when I run but
they stop shortly after.

So,
How could the occupancy be greater than the size of the fifo?
Have you seen anything like this before?

Thanks,
Clark

FYI, I found that by gating the fifo write request with the fifo full signal
I could prevent this problem. Apparently the fifo does not like to be
written to once it is already full.

-Clark

"cpope" <cepope@nc.rr.com> wrote in message
news:4613bd5c$0$18872$4c368faf@roadrunner.com...
> Note: using EDk 8.2.02 with peripheral generated with the wizard with FIFO
> enabled and one user interrupt that is set to the fifo_almostfull line.
>
> I'm set up to generate interrupts on the fifo almost full signal but I get
a
> couple interrupts and then it stops. If I go read the occupancy register I
> get a number(0x737) greater than the size of the fifo (0x400). If I then
go
> and manually read from the fifo data register(from gdb) I can get the
> occupancy to go back to 0x400 and the next interrupt occurs when I run but
> they stop shortly after.
>
> So,
> How could the occupancy be greater than the size of the fifo?
> Have you seen anything like this before?
>
> Thanks,
> Clark
>
>

That's the way controllers are designed. When a FULL signal is
generated, it is up to the data source to stop writing (and when
EMPTY,it's up to the destination to stop reading.) That's what these
status or handshake signals are for.
One could design these controllers to be idiot-proof, but that usually
sacrificesperformance or versatility. In a FIFO controller, you want
to be "lean andmean", to maintain max performance.
Nothing stops you as user to add "child-proof" circuitry, as long as
the loss of performance is acceptable.
Peter Alfke, Xilinx

On Apr 4, 4:09 pm, "cpope" <cep...@nc.rr.com> wrote:
> FYI, I found that by gating the fifo write request with the fifo full signal
> I could prevent this problem. Apparently the fifo does not like to be
> written to once it is already full.
>
> -Clark
>
> "cpope" <cep...@nc.rr.com> wrote in message
>
> news:4613bd5c$0$18872$4c368faf@roadrunner.com...
>
> > Note: using EDk 8.2.02 with peripheral generated with the wizard with FIFO
> > enabled and one user interrupt that is set to the fifo_almostfull line.
>
> > I'm set up to generate interrupts on the fifo almost full signal but I get
> a
> > couple interrupts and then it stops. If I go read the occupancy register I
> > get a number(0x737) greater than the size of the fifo (0x400). If I then
> go
> > and manually read from the fifo data register(from gdb) I can get the
> > occupancy to go back to 0x400 and the next interrupt occurs when I run but
> > they stop shortly after.
>
> > So,
> > How could the occupancy be greater than the size of the fifo?
> > Have you seen anything like this before?
>
> > Thanks,
> > Clark

In my defense, this is the only module (in my design) that isn't idiot proof
thus my surprise at having to gate the write myself. One could argue that if
xilinx is the one telling me (the user) the fifo is full shouldn't they
already know not to allow any more writes? But I get your point.

-Clark


"Peter Alfke" <alfke@sbcglobal.net> wrote in message
news:1175739444.142886.279410@n76g2000hsh.googlegroups.com...
> That's the way controllers are designed. When a FULL signal is
> generated, it is up to the data source to stop writing (and when
> EMPTY,it's up to the destination to stop reading.) That's what these
> status or handshake signals are for.
> One could design these controllers to be idiot-proof, but that usually
> sacrificesperformance or versatility. In a FIFO controller, you want
> to be "lean andmean", to maintain max performance.
> Nothing stops you as user to add "child-proof" circuitry, as long as
> the loss of performance is acceptable.
> Peter Alfke, Xilinx
>
> On Apr 4, 4:09 pm, "cpope" <cep...@nc.rr.com> wrote:
> > FYI, I found that by gating the fifo write request with the fifo full
signal
> > I could prevent this problem. Apparently the fifo does not like to be
> > written to once it is already full.
> >
> > -Clark
> >
> > "cpope" <cep...@nc.rr.com> wrote in message
> >
> > news:4613bd5c$0$18872$4c368faf@roadrunner.com...
> >
> > > Note: using EDk 8.2.02 with peripheral generated with the wizard with
FIFO
> > > enabled and one user interrupt that is set to the fifo_almostfull
line.
> >
> > > I'm set up to generate interrupts on the fifo almost full signal but I
get
> > a
> > > couple interrupts and then it stops. If I go read the occupancy
register I
> > > get a number(0x737) greater than the size of the fifo (0x400). If I
then
> > go
> > > and manually read from the fifo data register(from gdb) I can get the
> > > occupancy to go back to 0x400 and the next interrupt occurs when I run
but
> > > they stop shortly after.
> >
> > > So,
> > > How could the occupancy be greater than the size of the fifo?
> > > Have you seen anything like this before?
> >
> > > Thanks,
> > > Clark
>
>

You have a loss-of-data condition which should NEVER be handled politely 
and automatically by the FIFO.  You should either have the system 
designed to never be in that situation or use the (almost) full flag to 
make things happen so you don't overfill; usually this means shutting 
off the flow of data, not simply ignoring it.


cpope wrote:
> In my defense, this is the only module (in my design) that isn't idiot proof
> thus my surprise at having to gate the write myself. One could argue that if
> xilinx is the one telling me (the user) the fifo is full shouldn't they
> already know not to allow any more writes? But I get your point.
> 
> -Clark
> 
> 
> "Peter Alfke" <alfke@sbcglobal.net> wrote in message
> news:1175739444.142886.279410@n76g2000hsh.googlegroups.com...
>> That's the way controllers are designed. When a FULL signal is
>> generated, it is up to the data source to stop writing (and when
>> EMPTY,it's up to the destination to stop reading.) That's what these
>> status or handshake signals are for.
>> One could design these controllers to be idiot-proof, but that usually
>> sacrificesperformance or versatility. In a FIFO controller, you want
>> to be "lean andmean", to maintain max performance.
>> Nothing stops you as user to add "child-proof" circuitry, as long as
>> the loss of performance is acceptable.
>> Peter Alfke, Xilinx
>>
>> On Apr 4, 4:09 pm, "cpope" <cep...@nc.rr.com> wrote:
>>> FYI, I found that by gating the fifo write request with the fifo full
> signal
>>> I could prevent this problem. Apparently the fifo does not like to be
>>> written to once it is already full.
>>>
>>> -Clark
>>>
>>> "cpope" <cep...@nc.rr.com> wrote in message
>>>
>>> news:4613bd5c$0$18872$4c368faf@roadrunner.com...
>>>
>>>> Note: using EDk 8.2.02 with peripheral generated with the wizard with
> FIFO
>>>> enabled and one user interrupt that is set to the fifo_almostfull
> line.
>>>> I'm set up to generate interrupts on the fifo almost full signal but I
> get
>>> a
>>>> couple interrupts and then it stops. If I go read the occupancy
> register I
>>>> get a number(0x737) greater than the size of the fifo (0x400). If I
> then
>>> go
>>>> and manually read from the fifo data register(from gdb) I can get the
>>>> occupancy to go back to 0x400 and the next interrupt occurs when I run
> but
>>>> they stop shortly after.
>>>> So,
>>>> How could the occupancy be greater than the size of the fifo?
>>>> Have you seen anything like this before?
>>>> Thanks,
>>>> Clark