Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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 :) -jgArticle: 98801
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... AustinArticle: 98802
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.... -jgArticle: 98803
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.Article: 98804
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.Article: 98805
henk <henk@mediatronix.com> wrote: > Just found this: > http://direct.xilinx.com/bvdocs/userguides/ug230.pdf How does USB programming work in that device? I don't find anything (on first and second glance) about that in the schematic. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 98806
anvesh wrote: > hello everyone..iam newbie to the world of fpga's..can anyone suggest > something frm where i can start my foray in to this field..iam exactly > looking to implement a risc processor in the altera board..i need to > program this thing in to the board using the quartus software...does > anyone of you have any hands on experience on this topic.. > > And what do you guys suggest is it better to use verilog or vhdl code to > implement this.. Why not use Altera's Nios processor core instead of rolling your own? Coding a simple RISC processor in one of those HDL's is not a difficult task, its the verification that will take a lot of your time. First you need to decide what your processor will do (its instruction set, its bit width, etc.) and start from there.Article: 98807
Uwe Bonnes schreef: > How does USB programming work in that device? > I don't find anything (on first and second glance) about > that in the schematic. It is just an integrated USB config option. See page 28. Henk www.mediatronix.comArticle: 98808
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 :)) JeremyArticle: 98809
henk <henk@mediatronix.com> wrote: > Uwe Bonnes schreef: > > How does USB programming work in that device? > > I don't find anything (on first and second glance) about > > that in the schematic. > It is just an integrated USB config option. See page 28. > Henk > www.mediatronix.com It could be nice to use it on own designs. A schematic would show what's needed... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 98810
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). -IsaacArticle: 98811
Hi folks, I am experiencing problems with my PowerPC design for a P50. The PowerPC consist of a simple for loop where it polls a custom OPB peripheral. When the software starts executing, I seem to get errors in the data from the polling function. I have added a ChipScope core and the waveform seems to indicate the reset seem to be flunctuating and this seem to indicate the DCM is maybe not locked properly or reset is actually flunctuating. The strange thing is that I have a signal which is the inverse of reset but the waveform does not seem to show it. I have step through the software using XMD and added a breakpoint within the function in GDB, and the software works fine and data is not corrupted but when I ran it the second time round, I get a SIGTRAP error in the debugger and the data in ChipScope and UART shows the data is corrupted and the reset signal fluctuating. I have scan thorugh the code and cannot see any problems with the code and the project, and also check the stack and the heap but I am allocating 128K of BRAM and the code is just a simple for loop with some drivers function. I am not using malloc in the code. The other thing is the design works fine for P70 and I have tried it in several boards with a P70, and also the code use for testing the P70 consist of more than 20 OPB peripherals whilst this code is just 2 peripherals. Any help will be great. Cheers Paul LeeArticle: 98812
eziggurat@gmail.com wrote: > I have added a ChipScope core and > the waveform seems to indicate the reset seem to be flunctuating and > this seem to indicate the DCM is maybe not locked properly or reset is > actually flunctuating. The strange thing is that I have a signal which > is the inverse of reset but the waveform does not seem to show it. Try an external reset. -- Mike TreselerArticle: 98813
II would like to find out what is the most sensible way to generate a text output file with timing measurements from a ModelSim simulation. Specifically, I have a long sequence of pulses in my simulation and I would like to generate a text file that looks something like: PW1 PW2 PW3 . . where PW1 is the width (in time) of pulse 1 etc... I do NOT want to use the cursors, as this would take days to do for numerous simulations and long pulse trains. I am aware of the ability to output a VDC (Value Change Dump) file but the format does not make sense to me and the ModelSim (XE Starter, 6.0) user manual is awfully unclear. I hope someone can help! Cheers, Peter.Article: 98814
let me inform u that yur english sux in a way that is of ur own making and that probably reflects on your study abilities too. I am sure that questions posted in good English get 1000 x better response than this deliberate trashing of a difficult but international language and I am sure you could spell I & you if you can spell Xilinx. I bet your English text books and magazines don't spell like you do. What the hell is with the kids these days that do not want to treat English with a little bit of respect. If I wrote my French or Russian the way so many destroy my language I am sure I would be cursed. If you are smart enough to do EE, the technical English isn't that difficult to atleast to spell words normally even if it is your n'th language. Spell like you see in your books please! John JaksonArticle: 98815
"PeterC" <peter@geckoaudio.com> wrote in message news:1142547784.464583.205400@j52g2000cwj.googlegroups.com... > II would like to find out what is the most sensible way to generate a > text output file with timing measurements from a ModelSim simulation. > > Specifically, I have a long sequence of pulses in my simulation and I > would like to generate a text file that looks something like: > > PW1 > PW2 > PW3 > . > . > > where PW1 is the width (in time) of pulse 1 etc... <snip> Verilog? Forgive me if I have my syntaxes all messed up - I typically don't do this stuff, just know that it can be done. Does time require the (parenthesis) or not? time hold; always @(posedge myPulse) hold <= $time(); always @(negedge myPulse) $display( " %t", $time()-hold );Article: 98816
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. How is this use any different from the latest version of Windowz controling the police car's computer dispatch system? (also true) There is a lot out there that is very scarey. Do I trust FPGAs any more than I trust anything else? Nope. But I do trust engineers will do the best job they can given the tools.... Austin Jim Granville 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 >Article: 98817
John, Sorry can't do. That would require an NDA, and a reason. Seems I can't convince you of anything. That is OK, I have gotten over that. Keep me honest, Austin -snip- > 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.Article: 98818
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 AlfkeArticle: 98819
Ahh, Verilog strikes again. I don't speak Verilog but I'm sure there would be similar constructs in VHDL. Thanks for the tip John, I will investigate.Article: 98820
Amen. I think an occasional typo happens, but this complete disregard for manners is deplorable. And: Urgent Help Needed with five exclamation marks is not the way to enlist free assistance. Who is responsible for teaching basic manners these days? It used to be our mothers... Peter AlfkeArticle: 98821
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 =---Article: 98822
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 =---Article: 98823
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 =---Article: 98824
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 =---
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z