What is the current status now about
inferring FIFOs in Virtex 4 or 5
with VHDL ?

Brad Smallridge
Ai Vision

Brad,

No issue whatsoever.

In V4, the solftware places the extra circuits to bypass the flags that 
didn't work under some conditions, and in V5 all that hardware works 
perfectly.

You do need to use the appropriate version for V4 with the fixes (which 
I believe is any 9.X or later).

Austin

> You do need to use the appropriate version
for V4 with the fixes (which I 
> believe is any 9.X or later).

I have version 9.2 and can't find any documentation on inferring FIFOs,
synchronous or asynchronous, unless you consider instantiating a primitive
such as FIFO18 and the like as inference.

Brad Smallridge
Ai Vision

Brad,

Yes,  sorry about that.  Not all synthesis is equal when it comes to 
recognizing the IP blocks.  And, a lot of it is too new to be supported 
today.

I am aware of a lot of work by the XST folks, as well as by our 
partners, to recognize things like FIFO's, DSP48's, etc. automatically 
without having to specifically instantiate the blocks.

I was concentrating on the known silicon V4 FIFO bug with the empty/full 
flags that was resolved by adding a small amount of external logic to 
get around the issue.

The full hardware fix was implemented in V5, so that structure needed no 
special treatment.

The V5 verification and characterization also learned many lessons from 
V4, and the overall release quality was improved a great deal. The FXT 
release just last week, is the finest ever (IMHO) by Xilinx, with now 
the complete solution platform released all at the same time.  The three 
videos of the sophisticated pcbs that were built to showcase these apps 
are testament to the "whole enchilada" being ready to go on day one.

At the ITRS TWG group meeting near Bonn last week (where I was), it was 
interesting to educate people that "it ain't your daddy's FPGA anymore..."

The 65nm V5 family is only second to Intel's 65nm product offering in 
complexity and process sophistication (and perhaps we are, in fact 
first, since Hi-K is only in their 45nm line).  They have dual core, we 
have dual core.  They have neat IP, we have neat IP.  They have some 
large die (with > 1 billion devices), and so do we.

Austin

austin wrote:

> The 65nm V5 family is only second to Intel's 65nm product offering in 
> complexity and process sophistication (and perhaps we are, in fact 
> first, since Hi-K is only in their 45nm line).  They have dual core, we 
> have dual core.  They have neat IP, we have neat IP.  They have some 
> large die (with > 1 billion devices), and so do we.

The difference between Xilinx and Intel chips is that the decimal point for
the price of the Xilinx parts is at the wrong position :-)

I would like to use more FPGAs, but most of the time a fast CPU or
microcontroller and maybe a small external FPGA, is cheaper and solves the
problem, too.

The PSoC concept from Cypress looks interesting: Lots of high-level analog
and digital blocks, which can be connected at runtime and a fast CPU, all
in a cheap and low power package:

http://tinyurl.com/43qz49

Of course, you can't compare this to a Virtex, with which you can do high
speed and parallel calculations, but for many products a small FPGA with a
small CPU, some integrated analog components and standard interfaces, like
I2C, USB, ethernet etc., would be nice.

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss wrote:
> austin wrote:
> 
> 
>>The 65nm V5 family is only second to Intel's 65nm product offering in 
>>complexity and process sophistication (and perhaps we are, in fact 
>>first, since Hi-K is only in their 45nm line).  They have dual core, we 
>>have dual core.  They have neat IP, we have neat IP.  They have some 
>>large die (with > 1 billion devices), and so do we.
> 
> 
> The difference between Xilinx and Intel chips is that the decimal point for
> the price of the Xilinx parts is at the wrong position :-)

Intel's new Atom series looks interesting - good horsepower and
very important : FANLESS - so they are back on the radar for embedded
applications.


> I would like to use more FPGAs, but most of the time a fast CPU or
> microcontroller and maybe a small external FPGA, is cheaper and solves the
> problem, too.
> 
> The PSoC concept from Cypress looks interesting: Lots of high-level analog
> and digital blocks, which can be connected at runtime and a fast CPU, all
> in a cheap and low power package:
> 
> http://tinyurl.com/43qz49
> 
> Of course, you can't compare this to a Virtex, with which you can do high
> speed and parallel calculations, but for many products a small FPGA with a
> small CPU, some integrated analog components and standard interfaces, like
> I2C, USB, ethernet etc., would be nice.

Atmel & Triscend tried that, and flopped. The real problem is not 
technical, it is commercial : You cannot nail-down three resource sets, 
and still have a large enough market footprint.

FpSLIC for example, you HAVE to hope the small AVR is going to
be enough (Code,Mips) for the life of the product, and hope that
the FPGA is large enough for the added stuff.
Miss on any one of those 3, and you are a dead-duck.

Small uC do not tend to _need_ FPGA support, so that's another 
miss-match. Then the process is generations behind the point 
solutions...  Too many compromises = market flop.

The Atmel AT91CAP series is much smarter :
It has a larger core (ARM7, ARM9), and is lower power than FPGA,
and targets highish volume downstream-feeder off FPGA designs.


So, it's smarter to choose the best commercial microcontroller, and then
mop-up what else you need, in a FPGA.
If your market is large enough, someone will craft a chip, with your
extras included, and the fpga can be discarded.

-jg

On Apr 6, 2:53=A0pm, Jim Granville
<no.s...@designtools.maps.co.nz>
wrote:
> Frank Buss wrote:
> > austin wrote:
>
> >>The 65nm V5 family is only second to Intel's 65nm product offering in
> >>complexity and process sophistication (and perhaps we are, in fact
> >>first, since Hi-K is only in their 45nm line). =A0They have dual core, w=
e
> >>have dual core. =A0They have neat IP, we have neat IP. =A0They have some=

> >>large die (with > 1 billion devices), and so do we.
>
> > The difference between Xilinx and Intel chips is that the decimal point =
for
> > the price of the Xilinx parts is at the wrong position :-)
>
> Intel's new Atom series looks interesting - good horsepower and
> very important : FANLESS - so they are back on the radar for embedded
> applications.
>
> > I would like to use more FPGAs, but most of the time a fast CPU or
> > microcontroller and maybe a small external FPGA, is cheaper and solves t=
he
> > problem, too.
>
> > The PSoC concept from Cypress looks interesting: Lots of high-level anal=
og
> > and digital blocks, which can be connected at runtime and a fast CPU, al=
l
> > in a cheap and low power package:
>
> >http://tinyurl.com/43qz49
>
> > Of course, you can't compare this to a Virtex, with which you can do hig=
h
> > speed and parallel calculations, but for many products a small FPGA with=
 a
> > small CPU, some integrated analog components and standard interfaces, li=
ke
> > I2C, USB, ethernet etc., would be nice.
>
> Atmel & Triscend tried that, and flopped. The real problem is not
> technical, it is commercial : You cannot nail-down three resource sets,
> and still have a large enough market footprint.
>
> FpSLIC for example, you HAVE to hope the small AVR is going to
> be enough (Code,Mips) for the life of the product, and hope that
> the FPGA is large enough for the added stuff.
> Miss on any one of those 3, and you are a dead-duck.
>
> Small uC do not tend to _need_ FPGA support, so that's another
> miss-match. Then the process is generations behind the point
> solutions... =A0Too many compromises =3D market flop.
>
> The Atmel AT91CAP series is much smarter :
> It has a larger core (ARM7, ARM9), and is lower power than FPGA,
> and targets highish volume downstream-feeder off FPGA designs.
>
> So, it's smarter to choose the best commercial microcontroller, and then
> mop-up what else you need, in a FPGA.
> If your market is large enough, someone will craft a chip, with your
> extras included, and the fpga can be discarded.
>
> -jg

Jim, you hit the nail on the head. That's the dilemma in our product
planning. There are thousands of interesting ideas, but we need to
always hit a market of a few hundred million dollars, otherwise we are
just diluting our efforts and miss the better opportunities. But that
leaves openings for the "little guys", the Actel and Atmel, who can
(and must) go after smaller fry.
It is often very frustrating when neat ideas get shot down by "where
is the multi-million dollar market ?".
But on the other hand, the standard FPGA has grown into many new
markets, just by its fundamental versatility.
Peter Alfke

Jim Granville wrote:

> The Atmel AT91CAP series is much smarter :
> It has a larger core (ARM7, ARM9), and is lower power than FPGA,
> and targets highish volume downstream-feeder off FPGA designs.

The downside is the high setup cost and you can't update the programmable
logic part with a firmware update. The FPSLIC looks interesting, but the
CPU and peripherals are a bit limited.

> So, it's smarter to choose the best commercial microcontroller, and then
> mop-up what else you need, in a FPGA.

Yes, maybe this is the best idea.

-- 
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

austin wrote:
> I am aware of a lot of work by the XST folks, as well as by our 
> partners, to recognize things like FIFO's, DSP48's, etc. automatically 
> without having to specifically instantiate the blocks.

I wasn't aware of any such initiative.  I'd be interested in how this 
would work.  A FIFO seems complex enough that it would be pretty hard to 
infer.  It can't really be described simply without coding the pointers 
and flag logic.  The only really abstract way I could think of 
describing a FIFO is through a function call like push() and pop(), 
which would be a nice abstraction but would preclude the code from 
working on other synthesizers.
-Kevin

Frank Buss <f...@frank-buss.de> writes:
> The difference between Xilinx and Intel chips is that the decimal point for
> the price of the Xilinx parts is at the wrong position :-)

I dunno about that.  It seems to me that Xilinx makes a lot of Spartan 3
parts that are at quite attractive price points.  I certainly wouldn't
want to see Xilinx raise those prices to match Intel.