EDK : FSL macros defined by Xilinx are wrong

Duane,

Yes! Exciting, but not very high volume. 12 XCV1000's. Times 2.

Austin

Duane Clark wrote:

Austin Lesea wrote:

pd....

-snip-

Aerospace posses issues with ionizing radiation.


Which is why we offer the QPro series, and have onging research into
solving all the problems in these applications.


I'm surprised you didn't mention that quite a few FPGAs, including
Xilinx FPGAs, have been roaming around the surface of Mars for the past
two years. And while a few mechanical parts are starting to wear out,
the FPGAs are still going strong.
 
fpga_toys@yahoo.com wrote:
Phil Hays wrote:

Of course, this was an extreme example, and this was decades ago. I'm
sure the business has changed. Still, I'm not convinced that test
costs are quite as low as you assume.


From the 2005 annual report 36.6% of revenues are cost of sales, of
about $576M. There are a few direct costs listed in that same report
which probably are just under half of that which are fixed costs for
buildings, IP, and other payments, dropping the remaining direct costs
per dollar under $0.25. Not included are labor costs, or direct wafer
cost payments, etc to be taken out of that 25 cents. I strongly suspect
from that, testing isn't as much as a penny or two.

So, we know from the gross margins of the annual report, that testing
isn't 50% or even 25% as you may have experienced in the past. I
suspect the big changes over the last couple decades are investments
like BIST style testing to facilitate screening without expensive
testers driving full test coverage as we saw in the 1980's.

Two years ago, the marketing spin was "The Virtex-II EasyPath solution
offers a 25% to 80% cost reduction with production quantity deliveries
(thousands of units) in as little as 8-10 weeks". That level of
discount based on test costs alone doesn't play with the numbers
reported by the annual report. Most of that discount has to be single
piece to volume discounts, or other incentives - not testing costs.
I think everyone understands that
a) test costs are real, and significant
but
b) they are not 100% of the discounts offered in Easypath.

The rest is 'amortisation allocation' and simple marketing politics.
What exact proportion ? - does it matter ?


However, you will never get a marketing spin merchant to admit that;
they NEED something to pitch, so that ALL users do not ask for
discounts :)

-jg
 
Nick C,

I thought it was issued, but I may be in error. That would make it
"pending." Either that, or I can't find it either. Lots of Xilinx
patents to crawl through...

Austin
 
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.
 
Phil Hays wrote

I used to work for a semiconductor company. Test costs were sometimes
very significant, as the test equipment was expensive. Some complex
logic parts had long test times, and for one part I worked on the test
cost was roughly a quarter of the selling price, and roughly half of
the total cost.
A while back, Intel used to say that test costs were about the same as
fabrication costs. I expect they meant the variable costs, not the (fixed)
capital costs. And this was in the '80s, with a product which would not have
had even a fraction of the built-in self-test possible in a big FPGA.
 
Subhasri krishnan wrote:
Hi all,
I am having problems debugging my memory controller. My initial idea is
to capture a frame and display the same frame continuously. But I see
problems in the pattern captured (some spots with colours that arent
expected to be there). When I simulate the controller it works as it is
expected. I understand that the timing has to be right and I modified
everything so that its alright. The input pattern is a simulated timing
generator to generate vga timing (640 x 480 @ 60Hz).

I think that the problem lies with an asynchronous fifo used to buffer
data at 25Mhz. The controller can take data from here at 100Mhz and
write into memory. Can anyone see a potential problem with this? I use
an async fifo for output buffering and there is no problem here. Also
can i use 2 clocks in the same module? some 'always' loops operating at
1 clock and the others at another clock?

Can someone think of a test that I do to figure out the problems? I
tried using different lenght fifos, with and without fifo and digging
into memory location and can do some minor corrections but I am not
able to spot any major mistake.
Any help is greatly appreciated.
Provide a counter that writes 1,2,3 etc on the transmit side of the
memory controller. Write a checker that raises a flag when you get
anything out of sequence.

If you have chipscope, then this may give you enough of a trigger that
you can 'scope your datapath. If you don't on the other hand, then you
probably want to write some datapath sampling code (For instance, that
writes data into a blockram, and stops writing when your trigger
condition is reached). This assumes that you have a mechanism to get
data out of your chip. (Should be obvious, but in your checker, you
should make sure the data is qualified correctly when checking :))


Jeremy
 
Subhasri krishnan wrote:
Hi all,
I am having problems debugging my memory controller. My initial idea is
to capture a frame and display the same frame continuously. But I see
problems in the pattern captured (some spots with colours that arent
expected to be there). When I simulate the controller it works as it is
expected. I understand that the timing has to be right and I modified
everything so that its alright. The input pattern is a simulated timing
generator to generate vga timing (640 x 480 @ 60Hz).

I think that the problem lies with an asynchronous fifo used to buffer
data at 25Mhz. The controller can take data from here at 100Mhz and
write into memory. Can anyone see a potential problem with this? I use
an async fifo for output buffering and there is no problem here. Also
can i use 2 clocks in the same module? some 'always' loops operating at
1 clock and the others at another clock?

Can someone think of a test that I do to figure out the problems? I
tried using different lenght fifos, with and without fifo and digging
into memory location and can do some minor corrections but I am not
able to spot any major mistake.
Any help is greatly appreciated.


Thanks
Subhasri.K
I am not understanding what you are saying. See if I am correct:

- You are having trouble with your memory interface (to a framebuffer).
- The memory controller is running at 4x the dot clock (100Mhz)
- There are bad pixels in certain areas?

If so then I would suggest looking at the VHDL code that is responsible
for reading in the data and placing it into an internal buffer in the
FPGA. The random wrong dots suggest this would be a problem (it could
also suggest that you may be pushing the memory too far).

-Isaac
 
This thread has gotten much too esoteric and also too confrontational.
It is really quite simple and intuitively obvious:

Everybody agrees that the manufacturing cost of chips grows
overproportionally with die size.
That's because, at a given defect density (=manufacturing quality
standard), a larger die is more likely to contain a defect than a
smaller die. Let's assume a percentage yield of 50% for a very large
perfect die.
The percentage yield for a 5 times smaller die would be much higher,
85% or more. (This can be proven mathematically).
But we will also get that same higher percentage yield from the big
chip when we test only those 20% of the chip area that are really
needed by the user's design.
(Believe it or not, the average design uses less than 20% of the real
chip resources, even when the designer is using every CLB and BlockRAM
and thinks the chip is really full. You can call that the curse of
programmable logic and the reason for its higher cost than custom
circuits. Lots of internal circuits are unused in any specific user
implementation. But every design leaves different things unused.)
Throw in less testing cost, and EasyPath becomes a good business
proposition. We do not have to go "dumpster diving" to make money with
it. It's all basic statistics and some sound reasoning. No need to
analyze our Annual Report either.
Peter Alfke
 
On Thu, 16 Mar 2006 12:33:27 +0000, John C <brakepiston@yahoo.co.uk>
wrote:

Reading the LSI Strucutred ASIC fiasco thread has made me think.
People are saying the FPGA revenues are going to grow, so....

Which markets are FPGA heading into?

I mean, at the moment there's Comms, Medical, Military, Consumer.

Where are they going next?

Automotive I guess is coming, as is aerospace. You could put the two
together, as control electronics.

How about seeing them in a PC?

What are your views on the matter?
hmm....looking at the writing on the wall economically....

PC-mkt: no growth...expect a decline.

mil/aero: a new slaughter every year should keep this going; but
overall volume is questionable....

Automotive: US mfg car-sales are off 20-40% in only a few months;
Delphi in bankruptcy, Dana just filed BK, GM itself hasn't filed yet
but is technically already bankrupt and is teetering on the edge of
filing....Ford credit downgraded to junk...25,000 layoffs in Canadian
auto-mfg....about that many just announced in US; and I think many
many more to come...

The chinese are making lots of claims of millions-per-year new cars on
the road; but even a touch of recession in the rest-of-world will
trash the chinese economy (which is massively export-based). I.e.,
don't count on automotive to grow. Also, automotive generally doesn't
need speed beyond uController ability; and the volumes are high; so
price matters.

Medical: who can afford it any more? Medical is topping...costs are
out of sight, and medical expenditure correlates with jobs (paid
insurance); and jobs in industrialized nations like US, Europe, etc.
are evaporating like dew in the sun...

Consumer: ha ha ha.... Real estate bubble has been pricked...sales
off --45%-- in Florida over the past 60 days....San Diego
similar....and virtually all economic "growth" over the past 5 years
has been RE/consumer driven; NOT industrial/mfg growth.

The past few years of spending-binge were fueld by conversion of
equity to cash, then to debt. No more RE apprecation, no more equity
to tap....and just a 10% drop in avg. RE prices will put -30%- of
ARM's underwater. Consumer-bucks are about to dry up in a serious
way...

And consumer products are generally high-volume, low power, and
cheap....which doesn't sound to me like a great FPGA market.

My overall impression is a flattening of FPGA sales...chip sales in
general really. Again, plenty of signs of it already....

In a depression, who needs the latest PC, or another cell-phone? What
you -need- is FOOD, shelter, and fuel....



----== 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 =---
 
On Thu, 16 Mar 2006 08:41:48 -0800, Austin Lesea <austin@xilinx.com>
wrote:

John C,

Automotive is happening (big) right now.

Latest (can't say which) luxury car has 10+ Xilinx FPGAs in it.

One car.

10+ FPGAs.

Replaced all the microcontrollers.

Why? Because the microcontrollers can not be maintained for ten years,
whereas the car maker can always buy any future version of our FPGA, and
put their old VHDL/verilog into it. Maintaining stock for all cars sold
for replacement assemblies for ten years was driving the maker broke
(pun intended).
This doesn't make sense to me. It's my impression that, if anything,
the situation for fpga's is WORSE than uC's. As far as being able to
get parts for many years; and especially for having new parts work in
10 yr old sockets. Just thinking of our discussion of 5v I/O over the
past couple weeks as one example of where new parts won't go in old
sockets...

Heck, the pinout is never even the same, when you need it to be... LOL

Consumer is going gangbusters. LCD TV's, plasma panel TV's. Why?

Austin
I will note that LCD inventory is piling up worldwide. While your
technical points of the desirability of fpga's may well have merit;
I'm not sure that we'll see total volumes climb.

Overall, I was fascinated to read your outlook right after posting my
own views; which are driven by macroeconomic factors. It will be very
interesting to see which of our scenarios has played out 2-3 years
from now!



----== 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 =---
 
On Fri, 17 Mar 2006 07:51:27 +1300, Jim Granville
<no.spam@designtools.co.nz> wrote:

Austin Lesea wrote:
John C,

Automotive is happening (big) right now.

Latest (can't say which) luxury car has 10+ Xilinx FPGAs in it.

One car.

10+ FPGAs.

Replaced all the microcontrollers.

Why? Because the microcontrollers can not be maintained for ten years,
whereas the car maker can always buy any future version of our FPGA, and
put their old VHDL/verilog into it. Maintaining stock for all cars sold
for replacement assemblies for ten years was driving the maker broke
(pun intended).

?!? - I'm hoping this is just Austin's enthusiasm, because if the
Luxury Car vendor really believed this, that is truly scary.

Would YOU drive off, in your luxury car, in 10 years time, where
they had 'just respun' the VHDL code, thru new tools, into the
newest FPGA ( _and_ assuming that newest FPGA _AND_ PCB will physically
fit at all !? ).

This is nothing but a lawyer's feeding trough....

-jg
ROFL....

also, a point I was going to mention in an earlier response...

Luxury car is a tiny tiny fraction of automotive sales....20k/year,
100k/year maybe.

On a side-note, as someone who has restored and made profitable use of
a lot of older test-equipment over the past 3 decades; it scares the
shit out of me to visualize half the planet running on stored-charge
chips which are -destined- to lose their code. Most especially in the
most critical applications, i.e. auto, aerospace, etc.; due to the hot
environment.

Whole freaking world's going to come to a grinding halt as devices
start failing over the next decade or two... <g>


----== 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 =---
 
On Thu, 16 Mar 2006 14:47:19 -0800, Austin Lesea <austin@xilinx.com>
wrote:

But I do trust engineers will do the best job they can given the tools....
there is absolutely no evidence that that assumption is valid.

in fact, there is ample evidence all around us, that engineers will do
whatever they're told; and that they produce -enormous- numbers of
sub-optimal designs; along with many truly awful designs as well.


snip
Why? Because the microcontrollers can not be maintained for ten
years, whereas the car maker can always buy any future version of our
FPGA, and put their old VHDL/verilog into it. Maintaining stock for
all cars sold for replacement assemblies for ten years was driving the
maker broke (pun intended).


?!? - I'm hoping this is just Austin's enthusiasm, because if the
Luxury Car vendor really believed this, that is truly scary.

Would YOU drive off, in your luxury car, in 10 years time, where
they had 'just respun' the VHDL code, thru new tools, into the
newest FPGA ( _and_ assuming that newest FPGA _AND_ PCB will physically
fit at all !? ).

This is nothing but a lawyer's feeding trough....

-jg


----== 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 =---
 
Austin Lesea wrote:

Jim,

Hee hee.

Just the facts, Jim. When we see the PO for hundreds of thousands of
chips, we have to believe they are doing something with them. Believing
what they told us is one option.
What _exactly_ did they tell you ?

It was not the target I found surprising, but the _reason_ you offered.

I _can_ think of some reasons to use FPGA on the higher priced/lower
volume vehicles, but I find it very hard to believe a car companies
design engineers, (or even middle managment!), truly believes they :

".. can always buy any future version of your FPGA, and put their old
VHDL/verilog into it. Maintaining stock for all cars sold for
replacement assemblies for ten years was driving the maker broke (pun
intended)."

Then what ? Do they think that any future version will drop into the
same socket ? ( err Socket ?! ) .... ROTFL.

How is this use any different from the latest version of Windowz
controling the police car's computer dispatch system?
Well, we can only hope those 10 FPGAs are going into the
marketing froth interior, and not something like Airbag, Traction
control, Fuel Injection....

-jg
 
Austin Lesea wrote:
Sorry can't do. That would require an NDA, and a reason.
I've lost track of the number of NDA's I'm party too ... have no
problem taking yet another bit of information to the grave. The reason
is harder to come up with ... that would be your call.

Seems I can't convince you of anything.
That is OK, I have gotten over that.
Keep me honest,
When you can convince me that taking to zero an item which is less than
10% of the total pricing structure, will generate 25-80% cost savings
to the customer, I will have seriously impaired facilities. Simply
Amdhal's law applied to cost/price structures.

Even Peter's example changing yields from 50% to 85% only reduces the
total price by a few percent. Consider Peters example with some
additional numbers -- 50% yeild on a $100 wafer with 100 parts, is $2
for each good part in silicon costs, to which testing, packaging, fixed
production costs, and gross margin is added bring the total price of
each part to $100 as an example. Increasing yield to 85%, only drops
the silicon cost to $1.18, which at most would be an $0.82 drop in
silicon cost and make roughly a $1.00 change (or 1% of price) in price
since all the other costs, such as testing, packaging, fixed production
costs, and gross margins (R&D, admin/sales, and stock holder return)
dominate the per unit price. Assuming that testing costs as much as raw
die, then 80% reduced testing will only change the cost from $2 to
$0.40, saving $1.60 which might impact the price by another $2. Thus,
by Peters example, based on yield increases, and testing saved, the net
expected benifit to the customer would be $3 out of $100, or a 3%
savings.
 
Mr Toy, I have never claimed 80% saving from reducing the testing cost.

But I have shown, by a hypothetical example, that we can double the
yield, and thus cut the EasyPath basic manufacturing cost in half. We
can thus sell these parts for half price, while maintaining our usual
margins.

You do not have to explain to us how we are running, or how we should
be running our business.
I have been an electronics engineer since 1957, and Xilinx has been
quite successful in its 21-year history.
When we need your advice, we'll let you know.

Peter Alfke, not ashamed to put his name under his writings.
 
actually before anyone replies to this. I checked up the mode pins and
one of them werre not soldered properly.
did check that before. but seemed like i did a mistake the first time.
sorry and thanks
 
Peter Alfke wrote:
But I have shown, by a hypothetical example, that we can double the
yield, and thus cut the EasyPath basic manufacturing cost in half. We
can thus sell these parts for half price, while maintaining our usual
margins.
And you DID NOT show that. Cutting die/test costs in half does NOT also
cut packaging, post packaging test, intelectual property(amotized R&D),
labor and other direct/indirect costs in half as well. Amdhals law of
diminishing returns applies here when evaluating the cost savings of
the die to the finished product, as the die/test cost is not the only
cost, and very likely not the majority of the cost. SO, the math is
simple ... cutting die/test in half, DOES NOT allow sale of the parts
for half price with the usual margins as you clearly assert above.
Thus, it remains speculation just where the quoted 25-80% savings comes
from.

Taking your example above to the logical limit, if a customer is able
to directly contract with (pay) the fab to provide their wafers free to
Xilinx, and waves all xilinx testing costs, then the final packaged
parts would be completely free. IE there are no packaging, intelectual
property, other direct and indirect costs. That would be the ONLY way
the math would work as you suggest above.
 
Ralf,
I want to know how can i connect this to PCB?
Laura


Ralf Hildebrandt 寫道:

laura_pretty05@yahoo.com.hk wrote:

I mean how can I connect the sensor to the FPGA board, how to connect
the pin on FPGA board? Thanks.

(I am not shure, if I understand you right.)
Most UP2 Education Boards are shipped with no pins at the FLEX_EXPAN_X
connectors. You have to solder some by yourself.

Ralf
 
On a sunny day (Thu, 16 Mar 2006 17:37:03 -0800) it happened austin
<austin@xilinx.com> wrote in <dvd3p2$p6714@xco-news.xilinx.com>:

Jim,

OK, here is the problem:

If you buy Froto's uP, they make a new one every year, and you have no
choice but to switch to the new unit, or stock enough of the old units
to serve your entire replacement need.

So, the car company goes to Froto, and say "Froto: attention! We want
the same uP guaranteed for a long time."
mmmm
a new 8052 comes out every year.
We had 'clockless' 8052 here discussed not so long ago.

Not agianst FPGA in cars, just generally scared of electronics in essential
parts in cars ..connector corrosion, no brakes, engine control responding
to local cell-phone tower... you read the news.
Lost if discussion on that in for example sci.electronics.design.

the funniest thing I did read was the Japanese (think it was) police will get a device
(transmitter) that can remotely stop a getaway car.....
I was sort of thinking how long it would take before the bad gusy controlled the police car...

Now we have viruses and worms in RFID tags already,
http://www.rfidvirus.org/index.html
Now viruses and worms in the CPU embedded in the cars....

But OK nothing beats FPGA for speed and versatility.
 
Peter Alfke wrote:
Mr Toy, I have never claimed 80% saving from reducing the testing cost.

But I have shown, by a hypothetical example, that we can double the
yield, and thus cut the EasyPath basic manufacturing cost in half. We
can thus sell these parts for half price, while maintaining our usual
margins.
Only if you consider margin as a percentage of sales. That may be
standard practice, but the implication may not immediately be clear.
Under your above explanation, you would be making only about half as
much money per chip with easypath devices as with regular devices, and
it seems that your willingness to do that is a source of a fair chunk
of the savings.
 

Welcome to EDABoard.com

Sponsor

Back
Top