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
Marcus <MJones@hotmail.com> wrote: > I just wanna get some feedback if I understood this correctly: > Althoug there is something out called gate-equivalent, it essentially > does not make sense to compare FPGA with ASIC implementations. The > reason is that ASICs actually require one gate for each logical > operation in a logical expression. For instance, d = a AND b OR c > requires two logical gates. In contrast, on FPGAs there are LUTS > that permit to implement any complex expression with up to 4 inputs > that do not produce more than 1 output. So that is basically the > reason why this gate-equivalent metric is not accurate since we > can never be sure how many logical expression are combined in a LUT. > Does this argumentation make a bit of sense? Well it does, but that doesn't stop people from doing it. It is nice to have a rough idea what size design is likely to fit into which FPGA size. If the FPGAs were only LUTs, then, on average, there might be a convenient conversion factor. Now that Block RAMs, multipliers, and even PowerPC processors are part of some FPGAs, it makes the process more complicated. FPGA vendors tend to count gates in those modules, though it is rare for a design to use them all. The common metric for ASICs is to count gates in terms of the number of transistor in a two input NAND gate (four in CMOS), and so divide the number of transistors by that number. That is a convenient unit, which may or may not scale. It seems that the real problem with gate measurements for FPGAs is that the vendors use a system that results in larger values than on is actually likely to get on a real design. That is confusing when one actually does it. Similar to EPA gas mileage, where we never get the stated mileage with actual driving. -- glenArticle: 146326
On Mar 11, 12:08=A0pm, Andy <jonesa...@comcast.net> wrote: > On Mar 11, 1:38=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > On Mar 11, 9:29=A0am, Andy <jonesa...@comcast.net> wrote: > > > > On Mar 10, 8:44=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > Andy, > > > > "Some synthesis tools may be getting smart enough to optimize an > > > > inferred latch from a combinatorial process into a clock enable on > > > > the > > > > corresponding register implied by the clocked process. But if there > > > > are any other combinatorial processes that use that latched output = of > > > > the first combinatorial process, then the latch cannot be replaced = by > > > > a clock enable on a register. " > > > > > I am interested in above your comment. Can you list an example to s= how > > > > "the latch cannot be replaced by > > > > a clock enable on a register" > > > > Example: > > > > A <=3D B when ENABLE; -- implies a latch for A > > > C <=3D A when rising_edge(CLK); -- a register using A > > > E <=3D A or D; -- another combinatorial function using A > > > > If not for E, the latch could be replaced by a clock enable on the C > > > register. I suppose C could still use a clock enable and the B input > > > directly, but it does not wholly "replace" the latch, because the > > > latch is still needed to derive E. > > > > Andy > > > Andy, > > We don't argue about the latch replacement as you show. What we argue > > about is when a fast next state signal StateA_NS is replaced by a > > slower latched version. > > It occurs if a condition in an if statement misses a signal assignment > > statement as we have been discussing about. > > > Weng- Hide quoted text - > > > - Show quoted text - > > I'm not sure why you are concerned about this. Everyone seems to agree > that inferring latches is not a good idea. The fact that it slows > performance (at least in FPGA's, see below) is just one more reason to > avoid them. > > It just so happens that in FPGAs, the clock enable mux is always there > on the front of the flip-flop, so there is no timing penalty whether > you actually use it or not, and adding a latch in front of it is > always slower. > > In other technologies, you have a choice of having a clock enabled or > regular flip-flop, with the latter being faster. Now the question is, > in such a technology, is the latch plus regular flop faster than the > clock enabled flop? > > Andy Andy, Thank you for your comments. WengArticle: 146327
-jg wrote: > The claim of Auto-generate test vectors is interesting. > Who pays for < 100% coverage 'issues' ? When have you seen ASIC with 100% test coverage. It is either impossible or the amount of vectors would be so huge that the tester time would make the chip very expensive. Tester time is quite big part of the chip price. > merely stacked, so die size has shifted to more process steps. Raw > silicon is actually quite cheap. Wafers are not that cheap. Altough big part of the cost are the process steps trough the fab. > If your package is IO bound, then die size claims are > totally illusory. You can pack IOs also inside the die, not only to the boundaries. IO bound vs. logic bound problems have diminished with some cell libraries. --KimArticle: 146328
On Fri, 12 Mar 2010 00:55:39 +0000, Marcus <MJones@hotmail.com> wrote: >Hi all, > >I just wanna get some feedback if I understood this correctly: > >Althoug there is something out called gate-equivalent, it essentially >does not make sense to compare FPGA with ASIC implementations. The >reason is that ASICs actually require one gate for each logical >operation in a logical expression. For instance, d = a AND b OR c >requires two logical gates. In contrast, on FPGAs there are LUTS >that permit to implement any complex expression with up to 4 inputs >that do not produce more than 1 output. So that is basically the >reason why this gate-equivalent metric is not accurate since we >can never be sure how many logical expression are combined in a LUT. > >Does this argumentation make a bit of sense? If it were that simple, one could come up with pretty useable metrics to compare them. Alas the situation is quite a bit more complicated which makes comparison difficult. The main difference between an ASIC and an FPGA is that FPGAs have embedded hard-macro blocks which have to be properly accounted. These embedded blocks are either direct replacement for gates (ala DSP blocks which have wide multiplier/adders which can be implemented in ASIC gates) or other embedded block which need extra IP in an ASIC (ala PLLs, Serial transceivers, memory etc.) Another condition which complicates this calculation is that not all logic which is available in an FPGA is usable in a given design because of routing restrictions. When you add the issue of having to use some of the FPGA LUTs just as buffers for routing replacement or to drive large fanout, it gets even more complicated. The bottom line is that if one is willing to separate the ASIC area requirement into IP blocks which are needed and the logic area which can be mapped to FPGA fabric + FPGA embedded IP, it's possible to do a pretty good comparison. But there is no simple rule of thumb which can give you the equivalent gate size of an FPGA without significant consideration of the actual design being mapped. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 146329
hello all , I have triggered the chipscope on some error signal and is getting triggered on error.But i am unable to analyse the cause of the error. Is there any way we can sample the previous 20 or 50 samples before trigger so that i can see which are the signals causing the error ? Thanks in advance.Article: 146330
Hi all; may someone explain to me how to add memory to store my microBlaze program if my system is out of memory? thank you in advance --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146331
On Mar 12, 6:34=A0am, saras <saras_rajg...@yahoo.co.in> wrote: > hello all , I have triggered the chipscope on some error signal and is > getting triggered on error.But i am unable to analyse the cause of the > error. Is there any way we can sample the previous 20 or 50 samples > before trigger so that i can see which are the signals causing the > error ? Thanks in advance. In the trigger setup window, there is a subwindow named capture. On the right hand side of the capture window is a field named position that defaults to 0. Enter how many samples you want to see preceding the trigger in that field. Regards, John McCaskill www.FasterTechnology.comArticle: 146332
weldat wrote: > Hi all; > may someone explain to me how to add memory to store my microBlaze program > if my system is out of memory? > thank you in advance > > > > --------------------------------------- > Posted through http://www.FPGARelated.com I think you have three choices: 1. Rerun the system builder wizard (if you saved the .bsb file after the first run) You will loose any changes you have done to the hardware. 2. Edit the memory component in XPS GUI. 3. Manually edit the hardware specification file for your system (.mhs) Rebuild hardware and remember to rerun address map auto generation. When you have updated your hardware you must update your software platform, and specifically your linkerscript. HTH, MagneArticle: 146333
On Mar 11, 4:55=A0pm, Marcus <MJo...@hotmail.com> wrote: > Hi all, > > I just wanna get some feedback if I understood this correctly: > > For instance, d =3D a AND b OR c requires two logical gates. > Not always true. It depends on the library, and the ability of the synthesis tool to utilize the library. The gate equivalent metrics all have a bit of bogus built in, and as others have pointed out, it is not as simple as you assert. RKArticle: 146334
On Mar 10, 4:23=A0pm, TudaPellini <elpell...@gmail.com> wrote: > Hi ASICFriends, > > I'm using XILINX ISE WebPack, release 8.2 (due to compatibility issues > with older projects). > Does anyone know how to make some symbol inputs to be "don't care" > inside an ISE schematic ? For example, at some mux inputs ? As we can > do on VHDL or Verilog ? > I expect that such issues would allow the synthesis tools to better > optimize the design. > Nowadays I manually tie every unused input to '0' (GND) or '1' (VCC) > sources and the synthesis tool really reduces and optmize the logic as > expected. However, I choose between '1' or '0' by my own analysis. > Is there a way to name these inputs on the schematic as 'X' or > something ? > > Greetings to you all > TUDA Pellini Two possible solutions: 1) Leave the pins "nc" in your schematic. 2) Build a net (pin) driver that sources an 'X', and connect it. Be prepared to deal with error messages up to and including a "blue screen of death". The schematic support in later versions of ISE is less than poor. RKArticle: 146335
Hey y'all -- Lately my company's been poking around at our overall design flow, trying to work out how to make things happen in better, more logical fashions. And one of the things that comes to mind is the pinning of FPGAs, i.e. determining which signal's going to go where. Traditionally around here, we've allowed the pinning to be pretty much at the PCB layout engineer's discretion with only minimal input from me, i.e. this has to go to a GCLK, these all need to be on the same I/O bank for voltage reasons. I was just wondering how everyone else fits actually bringing the signals out into the design cycle? Do you do the FPGA first, then let the placement tools pick your layout for you? Some kind of iterative process? Anyone with thoughts, feel free to share. Thanks, Rob -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 146336
On Mar 12, 12:29=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > Hey y'all -- > > Lately my company's been poking around at our overall design flow, > trying to work out how to make things happen in better, more logical > fashions. =A0And one of the things that comes to mind is the pinning of > FPGAs, i.e. determining which signal's going to go where. > Traditionally around here, we've allowed the pinning to be pretty much > at the PCB layout engineer's discretion with only minimal input from > me, i.e. this has to go to a GCLK, these all need to be on the same I/O > bank for voltage reasons. > > I was just wondering how everyone else fits actually bringing the > signals out into the design cycle? =A0Do you do the FPGA first, then let > the placement tools pick your layout for you? =A0Some kind of iterative > process? > > Anyone with thoughts, feel free to share. > > Thanks, > Rob > > -- > Rob Gaddi, Highland Technology > Email address is currently out of order Often it's too difficult to fully specify the FPGA such that pins are defined clearly what can be used and what can't. The normal design flow I've encountered is working iteratively with the layout designer. When a placement is determined, the nort/south/ east/west orientation is pretty reasonable to figure out what signals should be in which banks. The FPGA designer produces an initial pin placement without necessarily having a full design to back it up, based on what would work well from a routability standpoint. When "passed off" to the layout person, it's usually underscored what pins are tied to a bank (VCCIO issues) and which pins are absolute (GCLK, DDR interface). I've spent a couple days getting things manually pinned out so the layout should be clean: fewer vias, good escapes, decent signal integrity. Having a preference for surface signals versus buried signals, it's easy to define the outer two rows for top layer routing and rows further in for internal or back side signals. The more pins, the more trouble it is, perhaps, but the cleaner the interaction with the FPGA tool flow (UCF file ready early) and board layout.Article: 146337
On 3/12/2010 5:29 PM, Rob Gaddi wrote: > Traditionally around here, we've allowed the pinning to be pretty much > at the PCB layout engineer's discretion with only minimal input from > me, i.e. this has to go to a GCLK, these all need to be on the same I/O > bank for voltage reasons. > Rob, I do the same. The PCB routing is generally more restricted than the routing on the FPGA. With sub ns rise times, the PCB routing is very important. Cheers, Syms.Article: 146338
On Mar 12, 5:36=A0am, "weldat" <gweleki...@gmail.com> wrote: > =A0Hi all; > may someone explain to me how to add memory to store my microBlaze progra= m > if my system is out of memory? > thank you in advance I assume that "by out of memory," you mean that you do not have enough BRAMs to store the program. If so, then you need to provide some kind of non-volatile storage, like a flash EEPROM. You then need to determine whether the flash access time is fast enough to allow you to run the program directly out of it, or whether you need faster program memory, either by using BRAMs and banking or perhaps by adding external SRAM/SDRAM/DDR SDRAM. -aArticle: 146339
>From the official TIER website: "Support: Tier Logic intends support to be a differentiator from the mainstream FPGA vendors, who increasingly focus their support on only a few select customers, ignoring or providing poor-quality support to all but their largest accounts. Our approach is not to attempt to support thousands of customers, but to sign up to deliver high-quality support to every customer with whom we engage. Please register to get full access to the Tier Logic website." Peter says: They hired a 13-year Altera veteran as VP of marketing and sales. Where did he pick up such contorted writing and negative reasoning ? It is unprofessional, to say the least.Article: 146340
I searched on google. And there are a number of solutions to slove this error. Since I'm new to this technology i really dont understand what to do or how to find what exactly is causing this error. Please help. >ngdbuild 604 > >into Google, > >regards >Alan > >-- >Alan Fitch > --------------------------------------- Posted through http://www.FPGARelated.comArticle: 146341
On 13/03/10 00:46, Pallavi wrote: > I searched on google. And there are a number of solutions to slove this > error. Since I'm new to this technology i really dont understand what to do > or how to find what exactly is causing this error. Please help. >> ngdbuild 604 >> >> into Google, >> >> regards >> Alan >> >> -- >> Alan Fitch >> > > --------------------------------------- > Posted through http://www.FPGARelated.com OK, the first solution I found said "is there a space in your project path". So Is there a space in your project path? regards Alan P.S. Only about 4,500 hits to go... -- Alan FitchArticle: 146342
On Mar 11, 9:32=A0am, John_H <newsgr...@johnhandwork.com> wrote: > > I want better solutions to succeed. =A0*I* won't pursue vague promises > but I'll consider real information. =A0Big difference. I am also glad to hear from the Tier representative. I don't think of discussing the technical issues of their product to be spamming, even if it is from a "marketing" perspective. As to the "vague" promises, the bottom line of what Tier is offering is price... and we won't know that until we actually have a chance to compare apples to apples. Heck, you can't even compare Xilinx and Altera until you get them both in your office (tagging along with the local disti) and get hard quotes. We all know how there is no such thing as "list" price when it comes to used cars or FPGAs. In that regard, Tier is no different than X or A or L or the other A. RickArticle: 146343
On Mar 11, 2:08=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Mar 12, 3:32=A0am, John_H <newsgr...@johnhandwork.com> wrote: > > > > The TierASIC is tested with a scan-based ASIC methodology we added to > > > the silicon. The customer is not required to generate any test > > > vectors. Once you lock your design, you simply send us the bitstream > > > and we auto generate the test vectors for your ASIC. > > The claim of Auto-generate test vectors is interesting. > Who pays for < 100% coverage 'issues' ? > > > While I can understand the savings brought from removing the > > configuration memories and associated die size, I still envision the > > FPGA-like overhead as being significant since routing is such a large > > portion of typical FPGA resources. =A0 > > =A0The memory has not gone away, in the FPGA flow is it > merely stacked, so die size has shifted to more process steps. Raw > silicon is actually quite cheap. > > =A0Even in their ASIC flow, that 'memory ghost' remains, as the die size > is locked to the larger of the two possible choices. Their fpga to > asic step saving > is some process steps, testing savings, and yield gains > as they hope you are not using defects. > > =A0Where die size savings really kick in, is when they allow MORE logic > into what is a 'practical size ceiling' - but we still have no > indications of WHO their customers are ? - no logic or package info ?. > > =A0If your package is IO bound, then die size claims are > totally illusory. > > -jg Even if any given device size is IO bound, there is still a savings if they are able to build the same capacity using an more mature and less expensive processing technology. I seem to recall some number being quoted on a process that is not near the 45 nm currently used in FPGAs. I am sure their first devices won't be using the most expensive processes. RickArticle: 146344
On Mar 12, 2:33=A0pm, Peter Alfke <al...@sbcglobal.net> wrote: > From the official TIER website: > > "Support: > Tier Logic intends support to be a differentiator from the mainstream > FPGA vendors, who increasingly focus their support on only a few > select customers, ignoring or providing poor-quality support to all > but their largest accounts. Our approach is not to attempt to support > thousands of customers, but to sign up to deliver high-quality support > to every customer with whom we engage. > > Please register to get full access to the Tier Logic website." > > Peter says: > They hired a 13-year Altera veteran as VP of marketing and sales. > Where did he pick up such contorted writing and negative reasoning ? > It is unprofessional, to say the least. I hadn't seen that. I don't see this as "contorted", but rather very well stated without raising alarms. It is saying, without being a blunt instrument, that they are going to support all of their customers, but they are going to be choosy about their customers. They won't have thousands to support because they won't have thousands of customers. That sounds like the course TI has always taken with their automotive product lines, including their original ARM devices, that you couldn't even get a data sheet on unless you could show you would be buying millions. I ran into this wall with TI once. RickArticle: 146345
On Mar 11, 4:31=A0pm, whygee <y...@yg.yg> wrote: > Hello, > > Tier Logic wrote: > > All I can tell you is come get a quote and we can save you money. > > it is a curious statement ! > I assume that you have been too long in "stealth mode". > > Now I tell you this : > "show me your public price list, your products, > demo boards, detailed datasheet and distributors. > Then maybe I'll choose you for a project". > > I'll take the example of a competitor. > SiliconBlue has maybe "slow" chips > (according to only one test I did) but they got > it almost right for the rest, at least for me : > =A0 - decent development tool (not bloated) > =A0 =A0 =A0that installs easily on Linux AND Windows ! > =A0 - datasheet and other informations, enough to understand > =A0 =A0 =A0how it is ticking inside so it can be used > =A0 - at least one distributor that talks to anyone > =A0 =A0 =A0(even though the distributor is not large, > =A0 =A0 =A0 at least it does its job and doesn't scare potential customer= s) > =A0 - unit price that is decent is small quantities. > =A0 - ultra-low power is a plus but not critical for me. > > And still it's not functional enough for me. > Antti has developped for it and I'm curious. > Now before you can save me money, try to beat SBt, > and then... beat the others :-P > The Actel ProAsic3 family is working very fine > for me and wonder how it can be displaced. > > good luck, I'm curious, how many devices do you use in a year. I will bet if you use less than 100k and possibly, 1 million, you won't get their attention or even a quote. Any takers? RickArticle: 146346
On Mar 10, 8:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 10, 4:25=A0pm, Andy <jonesa...@comcast.net> wrote: > > > > > On Mar 10, 1:24=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > On Mar 10, 10:06=A0am, Andy <jonesa...@comcast.net> wrote: > > > > > On Mar 9, 12:15=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrot= e: > > > > > > I would strongly encourage you to change the RESET function from > > > > > asynchronous to synchronous. > > > > > On what basis do you make this recommendation, and what does this h= ave > > > > to do with latches? > > > > > Andy > > > > Synchronous versus asynchronous resets have been discussed at length > > > in other threads. > > > > Asynchronous resets have their place in a designer's toolbox, however > > > they should be used sparingly. =A0Some reasons to use these are for > > > handshakes crossing clock domains, anticipated loss of clock and > > > asynchronous inputs to the synchronous domain. > > > > In a synchronous domain, such as the original state machine example, > > > the asynchronous functionality offers no additional benefit in FPGAs > > > as the area cost is identical for both. > > > > Asynchronously asserting and de-asserting a reset across multiple > > > registers may/will result in the registers being released before and > > > after a clock edge due to large net delay and skew on the reset net. > > > This will result in different parts of a design coming out of reset > > > across clock boundaries and being out of sync with each other. > > > > Synchronous resets simplify timing analysis and timing closure withou= t > > > having to worry about the consequences of the asynchronous functions > > > and how to correctly constrain them. > > > > I often see problems with FPGA designs that are built with > > > asynchronous resets, but I have yet to see a problem with a FPGA > > > design that was traced to a synchronous reset. > > > > In an FPGA there is no downside to a synchronous reset, but there are > > > many pitfalls with an asynchronous reset. > > > > None of this has anything to do with a latch, which you also want to > > > avoid using in an FPGA. > > > > Ed McGettigan > > > -- > > > Xilinx Inc. > > > Given that most sources of reset signals are not already synchronized > > to the clock domain(s) that need resetting, both asynchronous and > > syncrhonous resets require at least the deasserting edge to be > > synchronized. Proper syncrhonization for each case takes the same > > amount of design effort and resources. > > > I will agree that getting the constraints set to make sure that the > > synchronous deassertion path meets timing in an asynchronously reset > > system can be non-obvious, but that is a tools issue, not a design > > issue (in other words, fix the tools!) > > > Given that an asynchronous reset reliably resets the circuit, > > regardless of the presence or stability of the clock signal, when an > > asynchronous reset is correctly designed, it is a more reliable reset > > than a synchronous one. > > > Andy- Hide quoted text - > > > - Show quoted text - > > I wouldn't take it as a given that most resets are not already > synchronized to the clock domains. =A0Resets are routinely used based on > termination count, end of packet, return to state0 from other states > or invalid states, etc.... =A0All of these cases would be within the > same clock domain. > > Placing the onus of creating a reliable design on software tools to > correctly determine the designer's intent for timing paths that are > "non-obvious" is not a working solution IMHO. > > The cons of an asynchronous reset significantly outweigh the single > pro that the reset will occur in the absence of clock. > > Ed McGettigan > -- > Xilinx Inc. I don't follow that at all. I use async resets all the time, but I use them appropriately. I don't expect them to release all FFs at the same time and design that way. That's all it takes. No magic, mo complex design techniques. I just don't assume a counter will have all bits start at the same clock cycle, give or take one cycle. But a binary counter will only increment the lsb if started at count 0. So it will start correctly if the rest of the bits are released in the next clock cycle or the one before. My state machine designs include a start state that is just to allow the state machine to release from reset. The list goes on. But nothing on the list is hard to understand or to implement. More importantly, an async reset and the small amount of logic required to release FFs from the async reset is less logic than adding a sync reset to every FF in the design. AND it will operate irrespective of the state of the clock! RickArticle: 146347
On Mar 10, 8:42=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Mar 10, 5:10=A0pm, -jg <jim.granvi...@gmail.com> wrote: > > > On Mar 11, 2:01=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > The cons of an asynchronous reset significantly outweigh the single > > > pro that the reset will occur in the absence of clock. > > > =A0For Logic 'buried deep', that would be correct, but > > for pin-drive logic, having a defined state BEFORE the clock, can be > > quite mission-critical. > > > =A0-jg > > I absolutely agree that asynchronous resets have a very valid use in > certain cases. =A0My position is that should be avoided in the general > case. > > FPGAs with the asynchronous global set/reset can also get you into > that known state before any clocks are applied. > > Ed McGettigan My understanding is the global set/reset is what we are talking about when we say "async reset". That is what it is mapped to in all of my designs. RickArticle: 146348
On Mar 12, 10:22=A0pm, rickman <gnu...@gmail.com> wrote: > > I'm curious, how many devices do you use in a year. =A0I will bet if you > use less than 100k and possibly, 1 million, you won't get their > attention or even a quote. > > Any takers? > > Rick They quoted "free NRE" for a purchase commitment of $100k, I believe. So if you want $100k worth of parts, I think they're already on board. I just don't have a clue as to whether these are low cost and performance devices, high performance and high density chips, or just what they're shooting for. If they don't hit the aggressive production nodes for the base layers (with a coarser layer 9 metal mask process for a cheaper customization) then how can they truly compete on the piece costs given the overhead for routing resources? Whatever.Article: 146349
hi rick ! rickman wrote: > On Mar 11, 4:31 pm, whygee <y...@yg.yg> wrote: >> Now before you can save me money, try to beat SBt, >> and then... beat the others :-P >> The Actel ProAsic3 family is working very fine >> for me and wonder how it can be displaced. >> >> good luck, > > I'm curious, how many devices do you use in a year. less than you :-) I have been qualified as a "creative" kind of guy by the Actel France manager. I have a very small, specialised niche market around Paris and I love it this way. > I will bet if you use less than 100k and possibly, > 1 million, you won't get their attention or even a quote. I can get quotes from others, so why not from TierLogic ? > Any takers? I'm curious :-) > Rick yg -- http://ygdes.com / http://yasep.org
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