Custom Search
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
Friends, I was trying to install Xilinx System Generator v 6.2 (evaluation) on my computer. I have Xilinx webpack 6.2i SP 3 with IP Update 1.1 for it & Matlab 6.5 (R13) But while installing it says "Can not find Code GENERATOR" installation. i checked environmet variable, XILINX = c:\Xilinx & that's where my installation is. Any Suggetions? Thanks NiravArticle: 73901
"H. Peter Anvin" wrote: > > Out of curiosity I ran a couple of syntheses+P&R using Quartus II > 4.1SP2 Web Edition. This is just synthesizing the mb_cpu as a top > level, with all ports going to auto-assigned pins (presumably, > internal use could be faster.) Frequency is as reported by Quartus > timing analysis. I obviously didn't do anything fancy to try to make > it any faster. > > None of these inferred any memory or DSP blocks. > > Device Optimization LEs used Frequency > > EP1C4F324C7 Balanced 2930 60.99 MHz > EP1C4F324C7 Speed 3010 76.38 MHz > EP1C4F324C6 Speed 3010 84.21 MHz > > EP1S10F484C7 Area 2849 70.55 MHz > EP1S10F484C7 Balanced 2931 71.89 MHz > EP1S10F484C7 Speed 3011 71.60 MHz(!) > EP1S10F484C5 Balanced 2931 90.88 MHz > > EP2C8F256C8 Balanced 2993 59.27 MHz > EP2C8F256C8 Speed 3075 60.72 MHz > EP2C8F256C6 Speed 3085(?!) 81.27 MHz > > EP2S15F484C5 Balanced 2502 94.79 MHz > EP2S15F484C5 Speed 2580 92.83 MHz(!) > EP2S15F484C3 Balanced 2504(?!) 126.04 MHz > > A few surprises: > > - Sometimes "Balanced" gives a faster design than "Speed" > - Sometimes the number of LEs/ALUTs change when the only thing changed > is the speed grade of the devices. Actually, I don't see that as such a surprise. I expect that the optimizations are structural and done before timing analysis. So any given structural change (such as duplicating a high fan out driver) may or may not improve the speed after routing even though it increases the amount of logic used. The fact that the number of LEs change with a change in speed grade would say to me that there is *some* timing analysis being done during synthesis and controls the ultimate result. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73902
Peter Alfke wrote: > > This seemingly simple question does not have a simple answer. There are too > many variables. Modern FPGAs are leaping ahead of ASICs in the use of the > tightest technology ( 90 nm today). Some FPGA structures are inherently as > efficient as in ASICs (BlockRAM, I/O, transceivers, hard microprocessors). > In other respects FPGAs can be far less efficient in their silicon use. But > FPGAs benefit from a very regular and tight chip-layout, and they are > manufactured by the multi-millions (as opposed to most ASICs). > And finally: Silicon is cheap, silicon area is not decisive, the total > manufacturing and distribution cost is! > Don't count the square microns, count the dollars. Another large hunk of chip cost is testing. And lets face it, testing a large, complex FPGA takes time on an expensive tester. An ASIC that would fit on an FPGA will be a lot cheaper to test. Of course Xilinx has that program that only tests FPGAs to the users test vectors, so I guess that can help limit that part of the total cost. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 73903
Craig, In my 26 years in telecom systems manufacturing, I was not a happy camper until I could design, sell, and supply FPGA based products. Almost every RFQ to FRP to product cycle had at least one class A recall (everything had to be field or factory retrofitted). The pain of this was so high, that I had a rule, called "Austin's rule of tens." Sell ten, recall, fix the bug. Sell a hundred, find and fix the next bug. Sell a thousand, find and fix the next bug. And so on, and so forth. One time I made it to 100,000 sold of one system, and sure enough, we had a bug that required a huge changeout of eproms (thank god it was the microprocessor code, and could be fixed by this method). The interesting thing about the phone business, is that eventually someone will do something you never thought of, and break it. And suddenly everyone will say "how could you have missed that?" With FPGAs, we could now reconfigure over the network, so if there was a bug, we could download a new FPGA image, and we were back up and running with minimum (or no) down time. Of course, many operating companies decided not to connect their systems to any network at all, so they still cost a lot of money to retrofit, as someone had to go to each system, and plug in their personal computer, and reload an image. Good news is that they did not have to take it apart (as we had to in the 'old days'). The one time we used an ASIC (as the requirement was slam dunk, no issues) we ended up throwing all the ASICs away because the (bell) operating company notified us that the requirements doc had a patented technique that they did not know of at the time. So rather than get a license for it ($$$), they removed it from the requirements document. Guess who paid for it? Right, not the op company. Read the contract. Back to FPGAs. As for writing reconfigurability into a product requirement, after awhile, it became pretty obvious that money could be saved, downtime could be avoided, by having such a feature. You just had to network everything in your network (not an easy task at all). Austin CraigR wrote: > In reviewing a specific requirement, my design team is debating the benefits > of in-field hardware upgradability. In the communications space, wondering > if most system developers require and use ICR in production when > implementing FPGA (instead of ASIC)? > > Craig > >Article: 73904
Followup to: <415C6D4D.85048A9B@yahoo.com> By author: john@bluepal.net In newsgroup: comp.arch.fpga > > That is a self-perpetuating prophesy. There is nothing inherently > incomprehensible about Forth, especially vs. C. It is a bit like saying > Chinese is hard to learn because you learned English as a small child. > When people refuse to work in Forth because there aren't many who work > in Forth, you can see how that perpetuates the problem. > Personally, I don't buy that. I learned FORTH *way* before I learned C, and I still find FORTH code written by others much harder to read. The difference is that my brain just isn't capable of holding the layout of the stack in my head, especially since it changes from verb to verb. C and most other 3G programming languages at least attempts at forcing you to give your data items names. > I can see some significant advantages to an interactive language that > you can run on the target without an emulator. The main advantage to FORTH, in my opinion, is that it is one of the very few languages which runs anywhere close to native speed, yet requires only a handful of bytes for its compiler. For embedded or microcontroller-class programming, that can be a *huge* win over having to cross-compile everything, especially, as you correctly point out, you can use FORTH as an interactive language, which among other things mean you can extract state and conduct experiments quickly. -hpaArticle: 73905
Uncle Noah wrote: > jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0409290048.63a5a067@posting.google.com>... > >>"Antti Lukats" <antti@case2000.com> wrote in message news:<cjbrus$csk$02$1@news.t-online.com>... >> >>>Hi All >>> >>>finally today the project maintainer at opencores uploaded the verilog >>>design files for MicroBlaze compliant IP-Core. Download is available at >>>opencores.com - as project aeMB !! >> >>How long before Xilinx try to get them to remove it do we reckon? >> >>Cheers, >>Jon > > > If Xilinx can establish a case against aeste (the developer of aeMB is > working for that company) it will be removed. The question is how much > information he had in his possession so that he produced a > (reportedly) successful MB implementation. > > If he didn't infringe any of Xilinx hardware patents, he should be OK. > BTW is the MicroBlaze instruction set patented??? If it is, it is very > sad, this can be prohibit you from e.g. implementing a GPL'ed > simulator??? I don't see a big issue with the opcodes, or Xilinx's possible reaction, but such reaction will be proportional to their preceived lost revenue. # Xilinx benefit if MicroBlaze is in the news # Such efforts expand usage of, and research in, MicroBlaze # It can be a usefull second opinion / benchmark # Xilinx will have trademark rights to MicroBlaze, so they can restrict use of the name. Other examples of this are 6805 uC and i2c instances. # The open source core is only a tiny portion of system development: you also have compilers/SWdebuggers/HWDebuggers/Libraries, and all of those will have Xilinx license restrictions for Xilinx FPGAs. Altera would not want to promote this, as they have NIOS. So, in terms of lost revenues of any signifincance, that leaves the ASIC business, and there it is a trade off of the cost to license the MB from Xilinx, vs do the whole chain 'in house', using the OS as a portion of that. Q: What does it cost to license MB for an ASIC ? -jgArticle: 73906
Jim, The license includes rights to use in an ASIC: http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=&sSecondaryNavPick=Design+Tools&iLanguageID=1&key=DO-DI-MBLAZE-SC http://tinyurl.com/4qpqb Read the licensing agreement terms for details. You are correct: the more microblazes (microblazing?), the better. Austin Jim Granville wrote: > Uncle Noah wrote: > >> jon@beniston.com (Jon Beniston) wrote in message >> news:<e87b9ce8.0409290048.63a5a067@posting.google.com>... >> >>> "Antti Lukats" <antti@case2000.com> wrote in message >>> news:<cjbrus$csk$02$1@news.t-online.com>... >>> >>>> Hi All >>>> >>>> finally today the project maintainer at opencores uploaded the verilog >>>> design files for MicroBlaze compliant IP-Core. Download is available at >>>> opencores.com - as project aeMB !! >>> >>> >>> How long before Xilinx try to get them to remove it do we reckon? >>> >>> Cheers, >>> Jon >> >> >> >> If Xilinx can establish a case against aeste (the developer of aeMB is >> working for that company) it will be removed. The question is how much >> information he had in his possession so that he produced a >> (reportedly) successful MB implementation. >> >> If he didn't infringe any of Xilinx hardware patents, he should be OK. >> BTW is the MicroBlaze instruction set patented??? If it is, it is very >> sad, this can be prohibit you from e.g. implementing a GPL'ed >> simulator??? > > > I don't see a big issue with the opcodes, or Xilinx's possible > reaction, but such reaction will be proportional to their preceived lost > revenue. > > # Xilinx benefit if MicroBlaze is in the news > > # Such efforts expand usage of, and research in, MicroBlaze > > # It can be a usefull second opinion / benchmark > > # Xilinx will have trademark rights to MicroBlaze, so they can > restrict use of the name. Other examples of this are 6805 uC and i2c > instances. > > # The open source core is only a tiny portion of system development: > you also have compilers/SWdebuggers/HWDebuggers/Libraries, and all of > those will have Xilinx license restrictions for Xilinx FPGAs. > > Altera would not want to promote this, as they have NIOS. > > So, in terms of lost revenues of any signifincance, that leaves the > ASIC business, and there it is a trade off of the cost to license the MB > from Xilinx, vs do the whole chain 'in house', using the OS as a portion > of that. > > Q: What does it cost to license MB for an ASIC ? > > -jg >Article: 73907
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:10llmgho78j6v6f@corp.supernews.com... > There doesn't appear to be any way to put timing constraints on the internal > signals of a design. I have a fast clock and a slow clock and it would be > best if I could put a timing constraint on the fast signals. You only need to constraint the fast clock. This constraint will be used to place/route all the signals that are clocked by the fast clock. HTH, Jim jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chipsArticle: 73908
My bad Craig, just thought that as you and that other Guy guy appear to be posting from the same IP address you might know him. "CraigR" <craigra@pacbell.net> wrote in message news:RLZ6d.4747$nj.3494@newssvr13.news.prodigy.com... > Nope. I did see that posting though. I am weighing cost benefits of ASIC > for field upgradability. > > > "Rotund Phase" <rotund_phase@hotmail.com> wrote in message > news:2s31qkF1furbmU1@uni-berlin.de... > > Are you also guys@altera.com? From the 'NV on-chip memory' thread? > > "CraigR" <craigra@pacbell.net> wrote in message > > news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com... > >> In reviewing a specific requirement, my design team is debating the > > benefits > >> of in-field hardware upgradability. In the communications space, > > wondering > >> if most system developers require and use ICR in production when > >> implementing FPGA (instead of ASIC)? > >> > >> Craig > >> > >> > > > > > >Article: 73909
Jim Granville wrote: > Uncle Noah wrote: > >> jon@beniston.com (Jon Beniston) wrote in message >> news:<e87b9ce8.0409290048.63a5a067@posting.google.com>... >> >>> "Antti Lukats" <antti@case2000.com> wrote in message >>> news:<cjbrus$csk$02$1@news.t-online.com>... >>> >>>> finally today the project maintainer at opencores uploaded the verilog >>>> design files for MicroBlaze compliant IP-Core. Download is available at >>>> opencores.com - as project aeMB !! >>> >>> How long before Xilinx try to get them to remove it do we reckon? >> >> If Xilinx can establish a case against aeste (the developer of aeMB is >> working for that company) it will be removed. The question is how much >> information he had in his possession so that he produced a >> (reportedly) successful MB implementation. >> >> If he didn't infringe any of Xilinx hardware patents, he should be OK. >> BTW is the MicroBlaze instruction set patented??? If it is, it is very >> sad, this can be prohibit you from e.g. implementing a GPL'ed >> simulator??? > > I don't see a big issue with the opcodes, or Xilinx's possible > reaction, but such reaction will be proportional to their preceived lost > revenue. To be honest I don't see this as a particularly big deal - the EDK is so cheap that it is a blip on the landscape for any serious commercial development work. Would you avoid paying $500 to get a free but unsupported version of a processor that may or may not have legal encumberances? For university/research purposes Xilinx are very reasonable in their donation of EDK licenses. Finally, you asked how much it is to license Microblaze for ASIC fab - it is a drop in the ocean compared to the cost of actually fabbing the chip. Microblaze is not like ARM - ARM is an IP company, Xilinx is a chip company. ARM must vigourously protect the ARM brand to keep their business model alive. Microblaze helps Xilinx sell FPGAs - there are no per-unit royalties for using it. One thing that would probably upset Xilinx would be to see a high-fidelity Microblaze clone on Altera devices - that would surely get the lawyers' attention, even if it is a bizarre form of flattery (Xilinx processor design on Altera fabric)! Regards, JohnArticle: 73910
H. Peter Anvin wrote: >>When people refuse to work in Forth because there aren't many who work >>in Forth, you can see how that perpetuates the problem. >> > > > Personally, I don't buy that. I learned FORTH *way* before I learned > C, and I still find FORTH code written by others much harder to read. Here is the crux of the problem. The OP stated that he was looking for help on a embedded system. ( orignal thread is gone and linix is not written in forth ) Yes, having experience with any language is going to create a better environment for development. However, a beginner using forth without a safty net ( i.e. mentor) is just crazy. The projects I have followed up on were just that. Beginners trying to bet the farm an a "quick language". My first forth was on a 6502 over 20 years ago. Nothing has changed. If forth works for you, great. But, if I follow up on one of your projects. It will be converted to C. hamilton AT dimensional DOT comArticle: 73911
Try also adding "LOCK_PINS" constraint to the LUTs. Jim jimwu88NOOOSPAM@yahoo.com (remove capital letters) http://www.geocities.com/jimwu88/chips "van de Kerkhof" <bvdk@NOSPAMMoce.nl> wrote in message news:1096438359.543142@news-ext.oce.nl... > Hi. > > I made a programmable lut delay. > Xilinx ise thinks it may optimize some luts away how can i prevent this. > > I use synplicity for synthesis. > > I already tried: keep keep_architecture syn_noprune syn_keep syn_preserve. > > Changing the lut init by making an other design will change the number of > luts it will optimize but it > should be possible to say dont touch the luts?? > > Bram > >Article: 73912
Austin Lesea wrote: > Jim, > > The license includes rights to use in an ASIC: > > http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?sGlobalNavPick=&sSecondaryNavPick=Design+Tools&iLanguageID=1&key=DO-DI-MBLAZE-SC > > > http://tinyurl.com/4qpqb > > Read the licensing agreement terms for details. > > You are correct: the more microblazes (microblazing?), the better. Thanks for the clarify. Source code is $19,995. I think ASIC port is covered by this clause :: "13. Non-Transferable. [] You may provide device programming files — bit-stream files or PROM files — and you may provide the data required to implement a silicon mask set to third parties without prior approval solely in order to manufacture the Licensed Product." and also by this WEB note "Xilinx also sells Fully Synthesisable Behavioral Source code." How much for the second pathway ? -jgArticle: 73913
Peter Alfke wrote: (snip regarding FPGA vs. ASIC in silicon used.) > But > FPGAs benefit from a very regular and tight chip-layout, and they are > manufactured by the multi-millions (as opposed to most ASICs). > And finally: Silicon is cheap, silicon area is not decisive, the total > manufacturing and distribution cost is! > Don't count the square microns, count the dollars. What I hear is even more important with current technology is NRE costs, such as masks. Stories are of mask sets in the million dollar range. -- glenArticle: 73914
I doubt that very much. I am convinced that FPGA testing is simpler and cheaper than ASIC testing. The secet is in the reconfigurability. We do not just apply external test vectors. We reconfigure tens and hundreds of times, and we have a lot of self-test engines that run in parallel inside the chip. And we can afford to spend a lot of engineering on our generic test methodologies, since they are amortized across >1 billion dollars in annual sales. ASICs have to develop new test methods for each design. But: What was the original question really about ? I think it was a meaningless "cute" question. Peter Alfke > From: rickman <spamgoeshere4@yahoo.com> > Reply-To: john@bluepal.net > Newsgroups: comp.arch.fpga > Date: Thu, 30 Sep 2004 16:54:28 -0400 > Subject: Re: FPGA vs ASIC area > > > Another large hunk of chip cost is testing. And lets face it, testing a > large, complex FPGA takes time on an expensive tester. An ASIC that > would fit on an FPGA will be a lot cheaper to test. Of course Xilinx > has that program that only tests FPGAs to the users test vectors, so I > guess that can help limit that part of the total cost. > > -- > > Rick "rickman" Collins > >Article: 73915
> From: glen herrmannsfeldt <gah@ugcs.caltech.edu> > Organization: University of Washington > Newsgroups: comp.arch.fpga > Date: Thu, 30 Sep 2004 16:26:50 -0700 > Subject: Re: FPGA vs ASIC area > > > > > What I hear is even more important with current technology > is NRE costs, such as masks. Stories are of mask sets in the > million dollar range. > > -- glen Here are some numbers: ASICS are only for extreme designs: extreme volume, speed, size, low power Cost of a mask set for different technologies: 250 nm: $ 100 k 180 nm : $ 300 k 130 nm: $ 800 k 90 nm: $1200 k 65 nm: $2000 k plus design, verification and risk. We in the FPGA business really know the price of ASICs, for (think about it) we really design and produce circuits as if they were ASICs. Our saving grace is that we sell them in large numbers to many customers. Peter Alfke >Article: 73916
Hi Ken, Thank you for your response. What frequncy are you running the NIOS? I tried simulating at 72MHz and I got only 2 words bursts. Are you using NIOS II? Regards, Zohar "Kenneth Land" <kland_not_this@neuralog_not_this.com> wrote in message news:<10lg0aca67jseaa@news.supernews.com>... > "zg" <zohargolan@hotmail.com> wrote in message > news:e24ecb44.0409241455.340ba130@posting.google.com... > > Hi All, > > > > I am trying to use the SDR SDRAM controller that is comming with the > > NIOS II development package. In the simulation it looks like this core > > supports only 2 words bursts. I couldn't find anything in the > > documentations. > > Am I correct? > > If this core supports bigger bursts then 2 words, any ideas what am I > > doing wrong? > > > > Thank you all > > Zohar > > Zohar, > > I'm working on a design that uses one 16MB sdram chip for most of its > instruction and data memory. I rely heavily on dma and other burst reads > and writes (ie cache) to get the performance I need. > > The sdram controller you're talking about is good enough to burst 480 32 bit > words in under 485 cpu clocks. It's a beautiful thing to watch in Signal > Tap as I get this performance. (Haven't explored the lenght limits above > 480 - my external fifo's AlmostFull level) > > I'm hammering that sdram (through the Altera sdram controller) nines ways to > Sunday and it performs flawlessly. > > I have some serious issues with the whole NiosI/II chain, but the sdram > controller has been a champ. > > KenArticle: 73917
If you're implementing different protocols on the same electrical lines I would thing FPGAs would be very attractive. However, I'm struggling with how to support new I/O requirements (i.e. technology didn't exist at time of initial development) without opening up our boxes to modify the line drivers/receivers. My domain is not 'strictly' communications, but we frequently have new requirements to add another RS422 channel or Ethernet or wiZbang I/O of-the-day. So how do you get drivers that have programable voltage swings, rise times, polarity, etc. so that you don't have to send the box back to the factory to make changes. Short of putting in DACs/ADCs on each signal line with waveform memory, it's tough to figure out a good solution for the ultimate in I/O flexibility. Perhaps rather than waveform memory, using opamps and just having a DAC that sets the voltage for the rails and receive threshold might work??? I've also been thinking about a special type of tiny connector 'insert' that plugs in (almost like a multi-terminal fuse) which provides translation from LSVD to real-world signal levels. This might work would be tough for signals that have to be transformer coupled. How is this problem solved? -bh "CraigR" <craigra@pacbell.net> wrote in message news:NbX6d.4661$nj.3114@newssvr13.news.prodigy.com... > In reviewing a specific requirement, my design team is debating the benefits > of in-field hardware upgradability. In the communications space, wondering > if most system developers require and use ICR in production when > implementing FPGA (instead of ASIC)? > > Craig > >Article: 73918
Followup to: <ca4d800d.0409301050.1c3d2339@posting.google.com> By author: sdatta@altera.com (Subroto Datta) In newsgroup: comp.arch.fpga > > Hope this helps. > > - Subroto Datta > Altera Corp. Indeed it does. Thank you! -hpaArticle: 73919
Nirav Shah wrote: > Friends, > I was trying to install Xilinx System Generator v 6.2 (evaluation) > on my computer. > I have Xilinx webpack 6.2i SP 3 with IP Update 1.1 for it & Matlab > 6.5 (R13) But while installing it says "Can not find Code > GENERATOR" installation. i checked environmet variable, XILINX = > c:\Xilinx & that's where my installation is. > Any Suggetions? > Thanks > Nirav Sorry, if I cannot give you real help. Once, when I was installing an old version (2.x) of XSG, this was a real ugly affair. Versions of Windows, Matlab, XSG must fit exactly, or nothing would have done. Cost me about two weaks, until everything worked fine. Then, Matlab upgraded to version 6.5, but I wasn't able to run XSG on that. Meanwhile I keep that ancient installation, and I don't upgrade at all. Xilinx and Mathworks people promised me that they would try hard to improve the installation procedure. You might want to contact Brent Milne from Xilinx (Brent.Milne@xilinx.com). He was the only person who really cared and contributed help. I'm really interested in your experience. BernhardArticle: 73920
totallyadmin wrote: > I was just wondering *roughly* how much area is required for a design > targetted to an fpga in comparsion to a standard cell asic? I'm really > looking for a ball park figure here - 2x, 5x, 10x, 50x, 100x the area > requirements? (I undersatand its heavily dependant on the particular > design) This is very dependent on the design (and process). One good question is also, can you achieve the needed performance with FPGAs without huge effort in optimising the design. FPGAs look very promising in data sheets but sometimes the reality is completely different. I have one good example I have seen. One big 0.13u design was scaled down 1/4, with 1/4 clock frequency to test an ASIC. This already needed 6* V2 6000 chips, and the 1/4 clock frequency was very difficult to achieve. Some structures seem to be very hard for FPGAs. For example complex muxing with normal synthesis can produce huge structures in FPGAs. One could optimise those with some hand constructed LUT structures. But that is insane. That code is not anymore portable across chip families or to ASICs. And the time and effort to make things like that is huge. Also power consumption is one real problem. If you would build an product with 10+ biggest FPGAs the power consumption would be huge (and PCB area). And if the communication needs between the chips is large, also the PCB is going to be full of signals and very hard to make. Just food of tought. There are places for FPGAs, and sometims ASIC is the only sane alternative for a sellable product. Prototypes are completely different, you don't need profit from them :) --KimArticle: 73921
>If you're trying to enable a regulator that doesn't include a current limit >from a supply that's already steady, bulk capacitance won't provide the >predictable ramp rate. "Hot swap" is probably the magic word to search on if you are browsing vendors web sites. There is a class of chips intended to limit the startup current. I think most of them can be used to solve the ramp up problem. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73922
>That makes it much *less* useful. When a CPU is put into an FPGA, it is >a real encumbrance to use external memory and the internal FPGA memory >is often not large enough for program storage. Having a hunk of NV >*rewritable* (such as flash) memory would be very useful for this sort >of app. When are SW programs *ever* mature??? My network router >already has a code update waiting to go into the Flash. But why is NV more interesting than general purpose SRAM? Are you looking for something big enough so that the normal config loading mechanism can't handle the extra load? (Say 10 times the config size.) My straw man to compare with would be lots more RAM on the FPGA, using current technology. (My guess is the market isn't there or somebody would have done it by now.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73923
> The pain of this >was so high, that I had a rule, called "Austin's rule of tens." >Sell ten, recall, fix the bug. >Sell a hundred, find and fix the next bug. >Sell a thousand, find and fix the next bug. >And so on, and so forth. I learned that rule over 15 years ago. I was babysitting for a large (for the time) email system that had just been hit with that sort of bug. (Fortunately, the guys who did the initial work were good friends of mine.) The rule was something like: "Every time the installed base goes up by a factor of 10 another fatal bug will crawl out of the woodwork." I think it's been true for any system I've worked on. For most sytems, you can get 10 in your lab and 100 with friendly customers. Then it gets interesting... (Scale by 10 one way or the other if that fits your system better.) > The one time we used an ASIC (as the requirement was slam dunk, no > issues) we ended up throwing all the ASICs away because the (bell) > operating company notified us that the requirements doc had a patented > technique that they did not know of at the time. So rather than get a > license for it ($$$), they removed it from the requirements document. Interesting point. I remember a time when an FPGA saved my bacon. Yup. Spec change. Just one bit. Trival to fix. So if you are considering FPGA vs ASIC, add the stability of your requirements to the decision process. Don't forget to consider bugs in the spec. Committees are great at writing complicated documents that don't work in obscure corner cases. Or don't specify what happens and 3 people make incompatible assumptions. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 73924
John_H, Austin, Uwe, Hal Thanks for all your anwsers ! Sylvain
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