EDK : FSL macros defined by Xilinx are wrong

[Newman]

Stefan,
The huffman coding sounds interesting. From what I remember, most real
image data is spatially correlated. That would lead me to guess that
the most likely difference between two adjacent pixel values is zero,
then one, etc. This would seem to be suitable to use huffman coding
on, by just coding the difference It would be interesting to run
sample scenes through the filter. It is not obvious that a lossless
2:1 reduction can be guaranteed because one could synthesize a scene
that would not compress. Also, the transformed image may not be robust
in the presence of noise. Just my two cents.

-Newman

 

[Jim Granville]

Peter Alfke wrote:

Didi wrote:

Does anyone know anything about the Z80'000 that I've got a prelim
datasheet/usermanual for? It seemed like a chip ahead of its time...


The Z80,000 was after my time. So I have nothing to say about it.

The Z8000 appeared right after the 8086, and almost simultaneously with
the 68000 by Motorola, all 3 were 16-bit microprocessors. And the race
was on!

The 8086 won because IBM picked its baby-brother, the 8088, for the PC,
and because of Intel's massive marketing campaign ("operation Crush"),
against the cleaner and technically superior 68000. Never underestimate
Intel's marketing muscle. It was a brutal campaign. There is a book
about it, by Mr Davidov, the Intel marketing guy.

...Or Intel's manufacturing muscle - once the IBM PC selected the x88, it
really was Game Over, and helped a lot more by Microsoft's marketing
Muscle, than Intel's.

The Z8000 became condemned to a back-water existence. It was smaller
and simpler and thus potentially cheaper than the 68000, but (like the
8086) it partitioned the memory space into 64K segments, and there was
no way to detect when the address counter rolled over. Ziliog used
arrogant and semi-religious arguments for memory partitioning (the chip
architect really believed that it was a great feature, not a handicap),
but the upcoming graphics applications preferred a linear address
space, and they all went to the 68000.
The Z8000 was left with military and some arcade-game designs.
My only encounter with Steve Jobs was when I tried (unsuccessfully) to
convince him to use the Z8000 instead of the 68000 for what soon became
the Macintosh. The 68000 came in a gigantic package, and just its gold
plating cost almost as much as the Z8000 die. But the linear addressing
won...

Of the three contenders, the obviously worst one became the winner. The
68000 did so-so, and the cleanest and leanest became the loser. Who
says life is fair?.
Peter Alfke, reminiscing.

~68000 is still alive, in Coldfire microcontrollers, but if the Z8000
had 64Kpages, it was too similar to the x86, and also too late to use
the code base the x86 then had.

The Key in all this, is Intel was able to make, and ship x88 silicon,
while the others were sampling, and/or unable to meet price targets.

There was also a time, back then, when better code size mattered
due to the price of memory.

These days, the 64K issue appears again in the microcontroller sector-
most 16 bit cores naturally have 64K opcode reach issues - and we
see a swing into 32 bit microcontrollers : memory is far cheaper today.

An interesting 'inversion' is the sight of a mere 8K code variant
ARM from Philips - LPC2101.

-jg

 

[Piotr Wyderski]

Bryan Hackney wrote:

http://www.cbsnews.com/stories/2005/03/22/world/main682341.shtml

35 then. Excuse me.

Well, please do not extrapolate this on all the European countries.
That website is about France and thus it is, um... self-explanatory. ;-)))
Despite the fact that we call ourselves "European Union", there is
no essential unification between our countries in this field. Each
country has its own regulations, so no French labour time limit is
applicable in, for example, Poland and vice versa. Here we have
40 hours/week + overtime, if necessary.

Best regards
Piotr Wyderski

--
"If you were plowing a field, which would you rather use?
Two strong oxen or 1024 chickens?" -- Seymour Cray

 

[Everett M. Greene]

"Rich Grise, but drunk" <yahright@example.net> writes:

Rich Grise, pronounced Greiss if you're German or Gryce if you're some
kind of emigré. And if you learned anything _at all_ in elementary
school about English pronunciation, you'd have heard, "Long I, Silent
E". Interestingly, the only people I've met who have pronounced my name
right on the first try have been Asians. Probably because they pay
attention in school.

What does paying attention in school or pronunciation rules
have to do with pronouncing family names?

 

Ray Andraka wrote:

Why is it so hard to justify. One could argue that you can't use 100%
of a microprocessor either. Any given instruction leaves part of the
microprocessor idle: it is impossible to use all of the features all of
the time.

First, apples and oranges and cow pucky comparison. It's not about
leaving unused resources idle, it's about not idling used resources,
which is exactly the problem here. Good compilers get well inside of
99.x% efficiency for code to hardware fit in terms of the application
for most architectures. Even poor compilers tend to get better than a
90% fit. When it's only possible to get a 50%, or less fit, by your
standards in an fpga for the primary execution path netlist, that is a
HUGE derate. Most good compilers pack pipelines with very, very, very
few wasted cycles for nearly 100% hardware effieciency for the
application. The goal, is to reach similar efficient pipeline packing
on FPGA's, and waste few if any resources in the process. I agree with
your argument, that the existing Xilinx fpga's and tools will not yeild
close to 100%, and we need to derate that expectation that we carry
forward from traditional instruction set pipeline packing experience.
You are the Xilinx expert here, and if you claim less than 50% packing
efficiency with Xilinx product ... I'm not going to stand here and
argue with you about that.

I will argue, that given better integration to a different place and
route tool, such as that contained in JHDLbits, that FpgaC can do
significantly better than "less than 50% efficiency/utililization" of
LUT/FF based resources for a large number of unrolled loop
applications, such a finite difference modeling, RC5 code cracking, and
other dense unrolled loop pipelines which are common in the industry as
threaded/MPI/PVM multiprocessor applications.

 

[Ray Andraka]

fpga_toys@yahoo.com wrote:

Ray Andraka wrote:

Why is it so hard to justify. One could argue that you can't use 100%
of a microprocessor either. Any given instruction leaves part of the
microprocessor idle: it is impossible to use all of the features all of
the time.


First, apples and oranges and cow pucky comparison. It's not about
leaving unused resources idle, it's about not idling used resources,
which is exactly the problem here. Good compilers get well inside of
99.x% efficiency for code to hardware fit in terms of the application
for most architectures. Even poor compilers tend to get better than a
90% fit. When it's only possible to get a 50%, or less fit, by your
standards in an fpga for the primary execution path netlist, that is a
HUGE derate. Most good compilers pack pipelines with very, very, very
few wasted cycles for nearly 100% hardware effieciency for the
application. The goal, is to reach similar efficient pipeline packing
on FPGA's, and waste few if any resources in the process. I agree with
your argument, that the existing Xilinx fpga's and tools will not yeild
close to 100%, and we need to derate that expectation that we carry
forward from traditional instruction set pipeline packing experience.
You are the Xilinx expert here, and if you claim less than 50% packing
efficiency with Xilinx product ... I'm not going to stand here and
argue with you about that.

I will argue, that given better integration to a different place and
route tool, such as that contained in JHDLbits, that FpgaC can do
significantly better than "less than 50% efficiency/utililization" of
LUT/FF based resources for a large number of unrolled loop
applications, such a finite difference modeling, RC5 code cracking, and
other dense unrolled loop pipelines which are common in the industry as
threaded/MPI/PVM multiprocessor applications.

I think you missed my point.

The FPGA is not a processor, and its design is circuit design, not a one
dimensional sequencing of instructions. As I mentioned an FPGA offers
many more degrees of freedom. That translates directly into more
design 'corners'. It is not possible to simultaneously hit all of them.
That's the price of freedom.

Have you used JHDL? The higher densities you suggest do take more work
to achieve, and come about through using placed macros. The same can be
done using the xilinx tools by building a hierarchical library of placed
macros. There is nothing inherent in the tools preventing this, but as
I have said, it takes more design effort to get there. There is no
magic bullet regardless of who developed the tools.

BTW, the efficiency I was referring to on a uP is the utilization of the
gates. Each instruction only uses a fraction of the logic in the uP;
the rest is idled. I only brought that up in an attempt to level the
field between the two. You really can't compare them.

 

Ray Andraka wrote:

BTW, the efficiency I was referring to on a uP is the utilization of the
gates. Each instruction only uses a fraction of the logic in the uP;
the rest is idled. I only brought that up in an attempt to level the
field between the two. You really can't compare them.

I did understand, and objected to this assertion. I'm half EE and half
computer science, and have worked both fields for 35 years.

The way to get a huge bang for the buck with RC is to generate
hundreds, or thousands of mini state machine driven dedicated function
processors, much is the same way as you build pipelines of dedicated
function processing elements for DSP on FPGAs with distributed
arithmetic. You drop them into the fpga as a mesh fabric for 2D
algorithms, as a pipeline for 1D algorithms, and even as a flattened 3D
mesh if necessary. Highly regular connectivity, short routing, and
locally optimal placement are all not just possible, but highly likely,
with the right tools. Specialized array processing applications are
likely targets. Most of the demos I've worked with fill an fpga, and
have a VERY small number of idle LUTs. It's been painful to get par to
do the right thing, thus my frustration with the existing tools, and a
growing understanding of why they are what they are, and why that is
wrong for where we are heading and how our usage fundamentially is
different that the current tool chains design strategies.

FPGAs are a poor fit for non specialized functions which are largely
sequentlal and lack any dominate computational kernel, with a few
exceptions.

Others like wire speed network stacks and applications which can be
pipelined, and similar application structures with streaming data are a
strong fit with high degrees of parallism from the pipelined streaming
data. There are a few other cases, most of which also exploit either
replication or pipelining with streaming data. Any where we can
disconnect from sequential memory operations to distributed LUT/FF
memory with well defined operations in parallel is a good fit. I
suspect we will find others as well, as our experience builds with this
technology.

Addtions planned for FpgaC over the next year all target functionality
to support applications with this profile. The distributed arithmetic
to support finite difference kernels and matrix operations are high on
my list, for the same reasons as they have been hugely sucessful in the
DSP community. If you review the feature requests in the fpgac project
on sourceforge, you will find the start of a laundry list of things we
need to address over the next year to reach long term goals. Those
goals include automatic partitioning of applications between netlists
and more traditional processors or virtual machines (p-code or java vm
like) to get the best resource utilitization for parallel sections of
code, and sequential non-pipelinable code sections. This is a very
large project to be incrementally implemented over a period maybe as
long as several years. Some of it is well defined applications of
traditional practice to fpga computing, other parts of it are in effect
research projects as we break new ground to address problems with the
technology, problems with mapping existing practice to this technology,
and just new ground where new uses or new implementations fundamentally
require a change in existing practice for fpga computing.

For the same reasons that it's futile to invest much energy into
assembly language program optimizations, we view hand optimization of
placement and netlists a very poor practice. That same energy invested
into incremental improvements in the tool chain, from compiler to
bitstream generation tools will yield long term benifits and push the
state of art until deminishing returns is reached at high utilitization
and high degrees of overall efficiency. It's not going to happen over
night, we don't have all the answers today, but I'm certain that none
of the road blocks visible today are long term problems.

 

[Jim Granville]

fpga_toys@yahoo.com wrote:

Ray Andraka wrote:

BTW, the efficiency I was referring to on a uP is the utilization of the
gates. Each instruction only uses a fraction of the logic in the uP;
the rest is idled. I only brought that up in an attempt to level the
field between the two. You really can't compare them.

This has been an interesting side-thread, but more from pushing the
ceiling aspects, than whether 100% fabric at 100% speed is really
possible, or not.

I did understand, and objected to this assertion. I'm half EE and half
computer science, and have worked both fields for 35 years.

The way to get a huge bang for the buck with RC is to generate
hundreds, or thousands of mini state machine driven dedicated function
processors, much is the same way as you build pipelines of dedicated
function processing elements for DSP on FPGAs with distributed
arithmetic. You drop them into the fpga as a mesh fabric for 2D
algorithms, as a pipeline for 1D algorithms, and even as a flattened 3D
mesh if necessary. Highly regular connectivity, short routing, and
locally optimal placement are all not just possible, but highly likely,
with the right tools. Specialized array processing applications are
likely targets. Most of the demos I've worked with fill an fpga, and
have a VERY small number of idle LUTs.

So that indicates that 100% fabric usage is not an impossible task ?

It's been painful to get par to
do the right thing, thus my frustration with the existing tools, and a
growing understanding of why they are what they are, and why that is
wrong for where we are heading and how our usage fundamentially is
different that the current tool chains design strategies.

Most Software suppliers I work with, will strive to improve their
tools, if given specific and clear examples of :
a) What detail is sub-optimal, and why
b) How that can be improved, without impact on other users/usage.

Remember, those that write these tools, do NOT actually use them,
so feedback from users that 'push' the tools, is very important.

A user might think their application area is too small, or too
specialised, but tool flow improvements can ripple across many
application areas, and also raise the average practical frequencies-
and that can get the vendors very interested.

It seems one 'stub' of an opensource project could be to handle this
Xilinx-User interface. Rather than try and rebuild their tools from the
ground-up, why not work with them to improve the tools ?
Yes, this is done a small detail at a time.

Anyone doing an RC-FPGA array, should have strong thermal management,
even up to the copper heat pipe schemes of the extreme gamers !

-jg

 

Jim Granville wrote:

So that indicates that 100% fabric usage is not an impossible task ?

I certainly don't think it's impossible for some designs, it is however
"difficult" with present tools.

It seems one 'stub' of an opensource project could be to handle this
Xilinx-User interface. Rather than try and rebuild their tools from the
ground-up, why not work with them to improve the tools ?
Yes, this is done a small detail at a time.

something of a chicken and the egg problem. Getting major changes into
the par design are VERY LIKELY to dribble out slowly over 5 years to
avoid
a major upset for the existing customer base.

Anyone doing an RC-FPGA array, should have strong thermal management,
even up to the copper heat pipe schemes of the extreme gamers !

Yep, in each of the large system design proposals I have made for the
last year that is a milled 1/4" copper plate heat sink in direct
contact with the fpga array, connected integral with a chilled water
heat exchanger. Just can not handle the heat density of a large RC
array with air. Austin may think that needing the max parameters for
these devices is a joke, but when you propose to put several thousand
of them in a 1M cube, your customers actually demand thermal and power
data as diligent engineering. While the lack of these specs for the
Xilinx product may sit will for some, it's a critical road block for
serious hit the ceiling hard designs. Putting a significant fraction of
a megawatt into a desktop box isn't childs play, or even a hobby
project, it starts with a lot of engineering before the software design
even is a dream.

 

[Phil Hays]

"dp" wrote:

You _cannot_ affect
the path of the electrons inside the conductor by a static magnetic
field, just as you cannot force them to exit the conductor.

Hall effect.

http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html


--
Phil Hays

 

[Symon]

"Phil Hays" <Spampostmaster@comcast.net> wrote in message
news:q8r6u1h32albkt9oqkq0vkatko9uudniiu@4ax.com...

Hall effect.


--
Phil Hays

Phil, you beat me by 3 minutes. Dammit!

Cheers, Syms.

 

[dp]

Phil Hays wrote:

"dp" wrote:

You _cannot_ affect
the path of the electrons inside the conductor by a static magnetic
field, just as you cannot force them to exit the conductor.

Hall effect.

http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html


--
Phil Hays

Hall effect has negligible values in conductors. On the other hand,
it may take place somewhere on the die, that might well be.
If the current does not flow out of the chip into the wires there
is no need to redistribute it. I hope everyone is happy now.

Dimiter

 

[Brian Drummond]

On 3 Feb 2006 06:33:45 -0800, "dp" <dp@tgi-sci.com> wrote:

Brian Drummond wrote:
...
the only way a simulator can see DC current
resulting from a static magnetic field is a software bug
or, worse, misconcepted basics behind the software.

I don't think he's talking about the magnetic field generating a DC
current; but modifying the path of one that exists from other causes
(the PSU).

Think about those moving electrons (beta particles) in a particle
detector; a static magnetic field certainly modifies their path.
(Thus you can determine their velocity from its radius)

I really regret I have to go back to this thread. I suggest everyone
posting more on this nonsense makes sure to consult at least
some high-school physics books first.

When the electrons move inside a conductor (metal), this effect
is seen as a mechanical force applied to the _conductor_.

Think about HOW that force is applied to the conductor.

Think about whether the presence of current (motion of electrons) is
significant in this process, or whether, as your version suggests, the
magnetic field and the conductor alone are sufficient.

It takes
electric rather than magnetic field to move electrons inside the
conductor.

That was never in debate.
But once they are in motion, what happens?

- Brian

 

[Paul Johnson]

On 3 Feb 2006 06:33:45 -0800, "dp" <dp@tgi-sci.com> wrote:

Brian Drummond wrote:
...
the only way a simulator can see DC current
resulting from a static magnetic field is a software bug
or, worse, misconcepted basics behind the software.

I don't think he's talking about the magnetic field generating a DC
current; but modifying the path of one that exists from other causes
(the PSU).

Think about those moving electrons (beta particles) in a particle
detector; a static magnetic field certainly modifies their path.
(Thus you can determine their velocity from its radius)

I really regret I have to go back to this thread. I suggest everyone
posting more on this nonsense makes sure to consult at least
some high-school physics books first.

I've got a Physics degree, and I expect and I'm not alone here.
Although, I have to admit, that was over 20 years ago...

The electrons (or beta particles, the origin does not matter)

They're the same thing

can be moved in vacuum or in a gas because they, when moving,
produce a magnetic field, which interacts with the static
magnetic field, exactly in the same way as two magnet pieces
interact with each other (i.e. results in a force applied to the
freely moving electron).

What is a 'static' magnetic field? This is, I think, your confusion;
see my other post. Two things: (1) - Maxwell's equations are concerned
with the rate of change of a magnetic field; not whether they're
'static', or 'moving', which is meaningless, and (2) magnetic and
electric fields are exactly the same thing; it just depends on you
frame of reference. One observer sees only an electric field; another
observer moving relative to the first observer sees a magnetic field.

When the electrons move inside a conductor (metal), this effect
is seen as a mechanical force applied to the _conductor_.

What's the difference? Certainly, a conductor is different from free
space; this is what the skin effect is about. But, in this case,
nothing happens when moving from free space into a conductor: there
are moving charged particles either in the conductor or in free space;
a force is applied to them. They respond to the force, and not by
leaking out of the conductor.

 

[Jim Granville]

paulleventis-public@yahoo.ca wrote:

Hi Joseph,

"Altera: hardcopy-II - these are structured ASICs. They look
appealing, but
I did not get the impression that there were many conversions (at least
as
of a year ago)."

We have many customers lined up to use HardCopy II, and have have had a
significant number of conversions in the original HardCopy devices; one
example is TI's DLP chipset (yes, I'm talking about those fancy HDTVs).
HardCopy II is particularly exciting because it uses a very efficient
fine-grained logic fabric and provides a choice of migration devices
allowing greater cost reductions than previous members of the family.
HardCopy II also provides a significant speed-up over the equivalent
Stratix II FPGA devices and cuts power consumption in half.

I don't know why LSI is exiting this market. But there are a few
advantages Altera has offering a structured ASIC over pure-play
structured ASIC vendors. First, we can leverage existing sales
channels and contacts from our FPGA products; selling a structured ASIC
is a lot more like selling an FPGA than it is selling a standard-cell
ASIC product.

Second, our customers can prototype immediately in an FPGA, and can
sell that prototype for as long as it takes them to finalize their
design and commit to the HardCopy II device. They can wait for their
product to take-off before migrating to HardCopy II for a
cost-reduction, or they can move immediately into HardCopy II in order
to attain speed, power and cost advantages.

Third, and certainly not last, we can leverage our software and
intellectual property from our FPGAs. We put a full-fledged CAD suite
(Quartus II) on the customer's desktop, allowing them to design,
iterate, and close timing before handing off the design to us. The
software is easy-to-use (especially by ASIC standards), giving
push-button RTL-to-Silicon results. In addition, we have a large
library of Altera and 3rd-party intellectual soft-IP that customers can
use in their designs that have been tested in numerous FPGA designs.
And HardCopy II devices incorporate much of the hard-IP from our FPGA
devices, such as PLLs, I/Os and RAMs, and work the same way as the
Stratix II FPGA.

Who bears the cost, if the hardcopy migrate fails ?

How many of the Hardcopy II have not worked after the move to ASIC,
and needed a re-spin ?

-jg

 

[John_H]

First, I would like to see the Xilinx take on these items as well. Although
I fell I "know" the issues, it's nice to have reassurance.

Comments below:

"Evan Lavelle" <me@seesig.com> wrote in message
news:0tl3129i2hvcfs7ok5vliafonvf37blhbh@4ax.com...

4 - EasyPath is not 'just the same' as the FPGA you were buying
before. When I last looked, it was a device that had failed test.
Perhaps someone from Xilinx could comment on whether this is true or
not. This matters, because fewer devices will fail testing when yields
go up, as they will. You're going to have to ask yourself whether
Xilinx will carry on selling you cheap devices when they could sell
them to someone else at full price.

At a structured ASIC presentation, I railed on the guy that said that Xilinx
was selling bad parts. It's been underscored here before that the parts are
*not* rejects from the main testing that get shoved over to the easypath
line in the same sense as harddrives with bad sectors that didn't need
"those" sectors. The parts are UNTESTED to begin with, have a yied% chance
of being a 100% good device, and are *guranteed* not only for your explicit
bitmap but for 100% LUT operation as well. 100% LUTs are good. 100% of the
routing and resources you need are also good. If you have an error in the
silicon, it doesn't burn a hole in your board; an unused feature or routing
segment doesn't work which is inconsequential. Keep in mind that devices
with redundancy have MANY chips that are shipped with KNOWN defects that are
just "programmed out." *IF* you have a defect with EasyPath, it won't screw
up the design that you submitted to them for 100% testing.

7 - I've seen (in several places) the claim that EasyPath devices are
cheap because they require less testing. I don't believe it. They're
cheap because they failed test in the first place, and so would have
no value at all without the EasyPath route. It would be nice to have a
definitive statement from someone in Xilinx if they happen to disagree
with this.

I worked at a company that produced a high-end piece of test equipment as
well as a low-end box. The difference in the hardware was *minimal* but we
opened ourselves to a market that required mininal NRE. The development for
the big box was already bought and paid for. We still made a decent profit
on the lower-cost box but it wasn't quite the margin of the more expensive
brother. The margin we lost was made up for in reduced NRE costs up front.
It's great when you can make *more* money by expanding your market without
losing your base.

It's *quite* probable that Xilinx doesn't save the cost difference between a
production FPGA and an EasyPath FPGA with just the savings in test time.
It's likely that they take a lower margin on the devices to keep customers
who might change to a lower-cost, higher NRE solution by lowering their
margins. They still make money. They don't need to provide the support and
development to support 50 1k/yr customers compared to 1 50k/yr customers.
Xilinx gets more profits. Customers get less costly solutions. The only
folks left out are those that had alternative paths to offer beyond the
Xilinx flow.


My thoughts, my opinions. I like the business case.
- John_H

 

[Austin Lesea]

Evan,

Thanks for bringing this up,

Answers below,

Austin

-snip-

1 - EasyPath has an NRE. I don't have real numbers, but Xilinx's
literature gives figures between $75K and $300K, and an MOQ of 50K
pieces. It's not cheap.
Nope. We ask that folks are serious. Just like for ASICs. Don't want

to waste our time on non-real requirements.

2 - If you commit to EasyPath, you can't change your design without
paying the NRE again. In this respect, EasyPath is the same as an
ASIC. You have to be absolutely sure that it'll work. Just like an
ASIC, in fact.
Not true: you may change any LUT contents that you already are using,

and you may change any IO standard on any pin you are already using.
There are other changes which are allowed. Try that with an ASIC! We
call it the ECO capability of EasyPath (some stuff we have to test 100%,
so you benefit).

3 - The RapidChip NRE, for a device with about the same capacity as a
very large Virtex-4, came in at about $100K - $150K, with much smaller
MOQs. And this is a *small* device.
RapidChip? Oh those guys that just left the business? Oh well. I could

offer you gasoline at 8 cents a gallon, and I am sure I would have a
long line at my station...

4 - EasyPath is not 'just the same' as the FPGA you were buying
before. When I last looked, it was a device that had failed test.
Not true: it is a device that is only tested for what you need.
Perhaps someone from Xilinx could comment on whether this is true or
not.
Commonly asserted by others to apply FUD.

This matters, because fewer devices will fail testing when yields

go up, as they will. You're going to have to ask yourself whether
Xilinx will carry on selling you cheap devices when they could sell
them to someone else at full price.
We will start wafers just to meet EasyPath. It is that cost effective.

And, we do just that.

5 - As I said in my other post in this thread, there is no comparison
between EasyPath and even a 'structured' ASIC when it comes to
capacity, performance, and power consumption.
Ohe really? I think one can comapre them. Some areas (like leakage) the

ASIC will win. Some areas (like 10 Gb/s MGTs and a PPC, and a TEMAC)
the EasyPath will win, as these IPs are not even available all together
in 90nm!

6 - You can (or could) get RapidChip prototypes in about 8 weeks from
handoff. I don't have EasyPath figures, but it's not going to be a lot
less than that.
Yes. Except that now, RapidChip will arrive "never." When EasyPath

arrives, there is nothing to do, but plug it in, and ship it. No
requalification is required: there is NO DIFFERENCE in what goes in the
socket. Re-qual costs can be substantial, and the re-qual can take
months...

7 - I've seen (in several places) the claim that EasyPath devices are
cheap because they require less testing. I don't believe it.
Well, I can't convince you without desrcibing why. And in describing

why, I will educate you. And I have no incentive to do that. You may
look up the patent if you wish.
They're

cheap because they failed test in the first place, and so would have
no value at all without the EasyPath route. It would be nice to have a
definitive statement from someone in Xilinx if they happen to disagree
with this.
Definitive statement: testing a product for one use saves an incredible

amount of money. Look at ASICs....

Where I agree with Austin is "I do not consider Easypath as a
competitor to ASICs". So, what on earth is the point of spending all
this (uninformed) effort knocking ASICs? If someone can get the
business model right, then Structured ASICs will fit very nicely into
the space between FPGAs and standard cell. And they will make no
difference at all to the vast majority of the FPGA market.
Oh, I don't know, sounds like you learned something today? And, you and

I agreed on something. Not a bad result for a thread.

 

[Evan Lavelle]

On Fri, 10 Mar 2006 13:35:14 -0800, Austin Lesea <austin@xilinx.com>
wrote:

2 - If you commit to EasyPath, you can't change your design without
paying the NRE again. I
Not true: you may change any LUT contents that you already are using,
and you may change any IO standard on any pin you are already using.

Point taken. On the other hand, though, how much useful fixing can you
do by changing LUT contents?

3 - The RapidChip NRE, for a device with about the same capacity as a
very large Virtex-4, came in at about $100K - $150K, with much smaller
MOQs. And this is a *small* device.
RapidChip? Oh those guys that just left the business? Oh well. I could
offer you gasoline at 8 cents a gallon, and I am sure I would have a
long line at my station...

You have missed my point, which is that your perception of NREs is
incorrect (and, by implication, that yours is out of line). LSI have
not, AFAIK, withdrawn RapidChip because its NRE was too low.

5 - As I said in my other post in this thread, there is no comparison
between EasyPath and even a 'structured' ASIC when it comes to
capacity, performance, and power consumption.
Ohe really? I think one can comapre them. Some areas (like leakage) the
ASIC will win.

Leakage is irrelevant to me. On my current device, the structured ASIC
wins hands-down on capacity, performance, power consumption, and unit
cost, as I said. Your implication that my client is incapable of
trading off these factors against NRE, delivery schedules, and risk is
surprising. That's what we all do in this business, every day. You
have your sweet point; the ASIC vendors have theirs. Don't knock it.

Some areas (like 10 Gb/s MGTs and a PPC, and a TEMAC)
the EasyPath will win, as these IPs are not even available all together
in 90nm!

How many ASIC vendors have you checked for this stuff? And did you
repeat the comparison for other processors?

7 - I've seen (in several places) the claim that EasyPath devices are
cheap because they require less testing. I don't believe it.
Well, I can't convince you without desrcibing why. And in describing
why, I will educate you. And I have no incentive to do that. You may
look up the patent if you wish.

Ok, so I'll educate you instead. Xilinx runs at gross margins in the
range of 62 - 66%. What that means is that, of every $ I pay, about
35% goes to the fab, and 65% goes to Xilinx. The test is included in
that 35%. How much does silicon test cost? Real figures are hard to
come by, but a figure of about 10% of silicon cost is generally used.
If we're generous, and allow you 20%, that means that only 0.2 x 0.35
- ie. 7c - of every customer dollar goes on test. Of course, you still
have to test EasyPath. Let's say that you save 50% of test. This means
that the maximum discount that you can offer for a half-test scenario
is 3.5%.

So where do your claimed figures of 30% - 80% savings come from? The
numbers don't add up. You could try to claim that you offer EasyPath
only on your more profitable lines, or that you cut gross margins for
EasyPath products, but I don't buy it.

So, EasyPath devices are *not* cheap because they require less
testing; that much is obvious. In fact, there are two ways to look at
this:

1 - If the devices actually *have* failed initial testing, and there
is a widespread view that they have, then you can offer a large
discount because anything is better than nothing;

2 - They're not cheap in the first place, because of the NRE costs.
However, we'd need some real numbers from you to decide if this is
true or not.

Definitive statement: testing a product for one use saves an incredible
amount of money. Look at ASICs....

No, it doesn't. If the silicon cost you *nothing*, then the biggest
discount you could offer would be 35% before eating into your gross
margins. And I can't believe that you do that, or that the silicon
costs you nothing. Oh, and the unit cost advantage of ASICs has
nothing to do with reduced testing.

Oh, I don't know, sounds like you learned something today? And, you and
I agreed on something. Not a bad result for a thread.

It's been some years since I was a regular here. However, I do
remember that the only Xilinx employee on c.a.f at that time was
always courteous and well-informed, and didn't indulge in marketing.

Evan

--
Riverside
emlat
riverside-machinesdotcodotuk

 

[Austin Lesea]

All,

And if it costs me X to see if the die is 100% good, and I only spend
1/4 X to see if it works for you, then my gross margin is higher, or I
can charge less and keep the same gross margin if I test for you, and no
one else.

The Easypath flow is patented as a business method.

The NRE is to develop the special test program to test just for your
requirement, and to handle all the overhead of a new marking, new part
number, etc.

If they didn't even charge enough for the overhead in the structured
ASIC business, no wonder they are all going broke while they ship their
150M$ a year (basically they wrap money around each part shipped).

Many people think that if we find a part is bad, we know what is bad:
that is not true. It costs a small fortune to identify any failure, on
any part. That is called failure analysis, and requires a whole team of
engineers working by hand. We do that on occasion, but try to avoid it
at all costs. Failure analysis is done for yield issues, and design
issues: not for a bad memory cell on one part!

Another way of saying this is if I run test program "A" and I fill
bucket for customers, and then I go to test program "B" and fill buckets
for cutomers, and then go to test program "C" and take all parts that
failed "A" and "B" (as well as new completely untested parts) and fill
buckets.

Did I care why anything failed "A" or "B"? No, I do not. All I care is
that it passes "C". How does this affect reliability? Not at all. We
have done reliability and qualification studies on Easypath (no
different that what you do for any ASIC, ASSP) that prove that Easypath
has perfectly acceptable reliability and life. These die had to meet
the same defect density requirements as regular product, and they had to
meet all other process requirements, so they are no different that any
other.

I direct you to read about LCD display "bad pixels." It turns out that
all those beutiful displays we buy have some bad pixels. How many?
Sometimes as many as 12 bad pixels are allowed, and they ship the display.

Do you care?

12 out of 1760 X 1024 X 3? As long as they are not in a row, or in a
cluster (read: as long as the application doesn't care) the display is
perfectly "good." Easypath is one better. We prove that there are no
faults that are visible.

Austin

Note: all figures above are merely examples of how Easypath works, and
not actual numbers (which turn out to be much more atttractive). Also
the test flow is not what we actually use, but an example of one flow
that would work.

John_H wrote:

Evan Lavelle wrote:
snip

No, it doesn't. If the silicon cost you *nothing*, then the biggest
discount you could offer would be 35% before eating into your gross
margins. And I can't believe that you do that, or that the silicon
costs you nothing. Oh, and the unit cost advantage of ASICs has
nothing to do with reduced testing.


Gross margins 101:

If the part costs you nothing then your gross margins can stay at 65%
and be - NOTHING!

 

[metal]

On 16 Mar 2006 11:03:58 -0800, fpga_toys@yahoo.com wrote:

Austin Lesea wrote:
The annual report includes CPLDs, FPGAs (all sizes), services, and storage.

Devil is in the details.

Yep ... and and the Devil is in the spin.

My family is from the show me state .... and I'd like to see the
numbers behind the spin that testing is responsible for a 25-80%
savings over a 50K FPGA order converting to easypath.

it would be interesting to take the many multi-million exec-pay
packages, and the billion-dollar stock buyback programs, which are
used to boost the stock artificially in order to trigger big bonus
payouts; and divide them over the number of chips sold.

Wouldn't surprise me to learn that it's a dollar per chip sold, or
even more...


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= East/West-Coast Server Farms - Total Privacy via Encryption =---