FPGA Central

Hi all
We've set up a simple FIFO on a Spartan3 FPGA using the free code from
Xilinx XApp258 (FifoCTLR_IC_V2.vhd)
Initially this mechanism was tied to a DMA and we were having a hard
time figuring out what was going on.
By process of elimination, we tied the FIFO to an address and used the
read/write strobed to read and write to the fifo.

We can scribble data and read it back.
The weird thing we're seeing is that the "empty" does not become true
until data is read for the first time. It also becomes untrue with data
left in the FIFO (usually 2 longs remaining).

Has anyone seen this before? Or do we need to pay for the libary to get
it fixed

TIA
Remco

"Remco" <whybcuz@yahoo.com> wrote in message
news:1126643665.621179.25160@g44g2000cwa.googlegro ups.com...
> Hi all
> We've set up a simple FIFO on a Spartan3 FPGA using the free code from
> Xilinx XApp258 (FifoCTLR_IC_V2.vhd)
> Initially this mechanism was tied to a DMA and we were having a hard
> time figuring out what was going on.
> By process of elimination, we tied the FIFO to an address and used the
> read/write strobed to read and write to the fifo.
>
> We can scribble data and read it back.
> The weird thing we're seeing is that the "empty" does not become true
> until data is read for the first time. It also becomes untrue with data
> left in the FIFO (usually 2 longs remaining).
>
> Has anyone seen this before? Or do we need to pay for the libary to get
> it fixed
>
> TIA
> Remco

Or you could use the Xilinx FIFO Generator v2.2 Logicore for a more fully
specified interface. The user guide has timing diagrams and signal
descriptions that are probably much better than the XAPP258.

Why not designing a FIFO on your own?

V


"Remco" <whybcuz@yahoo.com> wrote in message
news:1126643665.621179.25160@g44g2000cwa.googlegro ups.com...
> Hi all
> We've set up a simple FIFO on a Spartan3 FPGA using the free code from
> Xilinx XApp258 (FifoCTLR_IC_V2.vhd)
> Initially this mechanism was tied to a DMA and we were having a hard
> time figuring out what was going on.
> By process of elimination, we tied the FIFO to an address and used the
> read/write strobed to read and write to the fifo.
>
> We can scribble data and read it back.
> The weird thing we're seeing is that the "empty" does not become true
> until data is read for the first time. It also becomes untrue with data
> left in the FIFO (usually 2 longs remaining).
>
> Has anyone seen this before? Or do we need to pay for the libary to get
> it fixed
>
> TIA
> Remco
>

Vladislav Muravin wrote:
> Why not designing a FIFO on your own?
>
> V
>

Yeah, that's what we're doing now.

It is just that when they give you the freebie library of components
why re-invent the wheel, right?

Of course, their %#$%$%$^@# component doesn't work for crap, so they
basically steer you down a dark alley for a day or so.
We had it integrated in a DMA mechanism and when stuff doesn't work,
you don't immediately assume it is the commercially availbable
component -- one would hope they test their junk before it is thrown
over the wall (I guess they didn't).
So the first thing you assume is bad is your own code..

I guess you get what you pay for.

Remco


>

> "Remco" <whybcuz@yahoo.com> wrote in message
> news:1126643665.621179.25160@g44g2000cwa.googlegro ups.com...
> > Hi all
> > We've set up a simple FIFO on a Spartan3 FPGA using the free code from
> > Xilinx XApp258 (FifoCTLR_IC_V2.vhd)
> > Initially this mechanism was tied to a DMA and we were having a hard
> > time figuring out what was going on.
> > By process of elimination, we tied the FIFO to an address and used the
> > read/write strobed to read and write to the fifo.
> >
> > We can scribble data and read it back.
> > The weird thing we're seeing is that the "empty" does not become true
> > until data is read for the first time. It also becomes untrue with data
> > left in the FIFO (usually 2 longs remaining).
> >
> > Has anyone seen this before? Or do we need to pay for the libary to get
> > it fixed
> >
> > TIA
> > Remco
> >

Remco wrote:

> It is just that when they give you the freebie library of components
> why re-invent the wheel, right?

Yes, the components are presented like
jelly beans in a candy store.
I didn't notice the handcuffs, the black box,
and the lawyer until the sugar wore off.

> Of course, their %#$%$%$^@# component doesn't work for crap, so they
> basically steer you down a dark alley for a day or so.

Even if they worked perfectly,
I don't need the complications of their
sim models and libraries. Running
synthesis and simulation using the
same code that I wrote and
understand is a huge advantage.

Many of the components are one-liners anyway.
Even a fifo is just two counters
and a block ram template.

> We had it integrated in a DMA mechanism and when stuff doesn't work,
> you don't immediately assume it is the commercially availbable
> component -- one would hope they test their junk before it is thrown
> over the wall (I guess they didn't).

I don't doubt that some vendor testing is
done, but I don't have the source and I have
to redo it anyway in my own testbench.

> So the first thing you assume is bad is your own code..

If I write my own code, I don't have to assume.
The problem is always in my own code,
but I am free to sim/edit/trace it as
much as I like.

> I guess you get what you pay for.

The only payment required is time and thought.

-- Mike Treseler

Mike Treseler wrote:
> Remco wrote:
>
> > It is just that when they give you the freebie library of components
> > why re-invent the wheel, right?
>
> Yes, the components are presented like
> jelly beans in a candy store.
> I didn't notice the handcuffs, the black box,
> and the lawyer until the sugar wore off.
>
> > Of course, their %#$%$%$^@# component doesn't work for crap, so they
> > basically steer you down a dark alley for a day or so.
>
> Even if they worked perfectly,
> I don't need the complications of their
> sim models and libraries. Running
> synthesis and simulation using the
> same code that I wrote and
> understand is a huge advantage.
>
> Many of the components are one-liners anyway.
> Even a fifo is just two counters
> and a block ram template.
>
> > We had it integrated in a DMA mechanism and when stuff doesn't work,
> > you don't immediately assume it is the commercially availbable
> > component -- one would hope they test their junk before it is thrown
> > over the wall (I guess they didn't).
>
> I don't doubt that some vendor testing is
> done, but I don't have the source and I have
> to redo it anyway in my own testbench.
>
> > So the first thing you assume is bad is your own code..
>
> If I write my own code, I don't have to assume.
> The problem is always in my own code,
> but I am free to sim/edit/trace it as
> much as I like.
>
> > I guess you get what you pay for.
>
> The only payment required is time and thought.
>
> -- Mike Treseler

All good points - thanks for the reality check.
Remco

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:3or2mhF752qmU1@individual.net...
> Remco wrote:
>
>> It is just that when they give you the freebie library of components
>> why re-invent the wheel, right?
>
> Yes, the components are presented like
> jelly beans in a candy store.
> I didn't notice the handcuffs, the black box,
> and the lawyer until the sugar wore off.
>
>> Of course, their %#$%$%$^@# component doesn't work for crap, so they
>> basically steer you down a dark alley for a day or so.
>
> Even if they worked perfectly,
> I don't need the complications of their
> sim models and libraries. Running
> synthesis and simulation using the
> same code that I wrote and
> understand is a huge advantage.
>
> Many of the components are one-liners anyway.
> Even a fifo is just two counters
> and a block ram template.
>
>> We had it integrated in a DMA mechanism and when stuff doesn't work,
>> you don't immediately assume it is the commercially availbable
>> component -- one would hope they test their junk before it is thrown
>> over the wall (I guess they didn't).
>
> I don't doubt that some vendor testing is
> done, but I don't have the source and I have
> to redo it anyway in my own testbench.
>
>> So the first thing you assume is bad is your own code..
>
> If I write my own code, I don't have to assume.
> The problem is always in my own code,
> but I am free to sim/edit/trace it as
> much as I like.
>
>> I guess you get what you pay for.
>
> The only payment required is time and thought.
>
> -- Mike Treseler

I haven't looked at their FIFO app note, but in general, the app notes are
just that: notes to help you get an understanding of how to work with the
device. Their IP (Coregen or $) will be expected to be more reliable and,
presumably, application appropriate.

For an asynchronous FIFO I need, I just ran Coregen and trust that it is
doing it right. (Yes, I simulated it, and yes, I'll test it in the lab.)
For another kind, where I need lots of FIFOs of varying sizes (perhaps
dynamic), I need to create my own: and I've done it. Seems every
application, though quite similar to a previous design, has some new quirks.

JTW (Wright, not Weddick)