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
"Peter Seng" <p.seng@seng.de> wrote in message news:<bb1o7f$66s$1@online.de>... > > 1) Tried maxjp (latest) does program the 18V02 but the programmed image > > give me some hint, what is maxjp - never heard, hardware, software, where > from ???? my mistake its naxjp from on japan fellow, programs Xc95 and XC18 just google on naxjp first hit is right unfortunatly the 18V02 programming did not work for me, dont know why.Article: 56151
>I suggest using the outputs of several different-length LFSRs to >generate a parallel word. Needless to say, the run length should all be >relatively prime, which is actually hard to avoid. >LFSRs are dirt-cheap especially using SRL16s in Virtex, and very fast. That seems like a great idea, but I'm not sure things are as simple as we would like them to be. I think this was mentioned a year or two ago. Somebody pointed out that the polynomials are not prime and may have factors in common. That's about the limits of my math skills. Or maybe I'm just confused. Another approach is to use N copies of the same polynomial but initialize the register with different starting values. I don't know how to select "good" values or verify that proposed values are good ones. -- 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: 56152
>If it doesn't have an assember.... >Then it is a pain. If it has an assembler OR it has a c compiler, then >it is really much more fun. >Picoblaze has assembler support, and MicroBlaze has c support. Good points. I'm thinking of the simple ROM based architecture where the PC gets loaded from a next-instruction field in each instruction. An assembler for that sort of system is really pretty simple. (The parser is the hard part.) All you need to do is recognize tokens and pack their values together into an instruction. Not quite that simple. There is also some work to assign instructions to locations and/or to pair up locations for the brancing logic. It is pretty simple if you have an example to start with. You just need to hack it to work with the appropriate tokens for your system. -- 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: 56153
Wong <tatto0_2000@yahoo.com> wrote: : Hi FPGA experts, : What are the differences between those Antifuse : FPGAs(One-time-programmable, OTP) and SRAM-based FPGAs(I called it : Many-time-programmable, MTP) ? ;) It's size verses flexibilty. Pick one. All fpga's consist of switches that can configure logic arrays. In a OTP those switches are set once at programming and never change. A SRAM fpga needs a sram bit behind every switch and some method to load those bits at powerup. OTP's are better IF you never have to change the pattern. Even a single pattern change can make the SRAM fpga a better choice. Some OTP vendors offer a custom part where they take your fuse file and create a mask with metal replacing the "on" switches. They are faster and possibly cheaper than programming for high enough volumes. John EatonArticle: 56154
Jim Granville wrote: > > Peter Alfke wrote: > > > > I am looking at revamping the FIFO cores, giving you many options: > > asynchr. vs synchronous, with exact empty and full > > extra one-clock-early empty and full indicators > > Interesting - this would allow a smaller fifo for > continual streaming output ? Jim, I do not understand. It's just a warning, one clock tick ahead... > > > programmable almost empty and full indicators, > > readable occupied size , > > etc > > Any additional suggestions? > > Newer UART fifos have a WDOG type feature, where a montostable timer > (runs at some multiple character time), generates an interrupt > if ever bytes are 'left in the FIFO', but under the interrupt threshold. > Allows a fully interrupt design, and avoids separate polling to > check for remnant data, which might be a noise side-effect. Since this is programmable logic, I suggest each user implements this in the logic fabric. Agreed? Peter > > -jgArticle: 56155
Pete Fraser wrote: > > Like the old NEC uPD42101. > > In clock, in enable, in reset (synchronous). > Out clock, out enable, out reset (synchronous). I find this too primitive, no Full or Empty, no "dipstick", etc > Contents can be read multiple times This is complicated and can have strange ramifications. Is this really desirable? Peter AlfkeArticle: 56156
Hi all, As someone mentioned the Altera DSP development kits have on-board ADCs and DACs. However, if you're interested in some other FPGA dev board that doesn't have these features, I'd suggest checking out El Camino's daughter card before building your own: http://www.elca.de/Products/prod%20andilabe.html This little card will fit on any dev board with "Santa Cruz" headers which are found on all the Altera Nios dev boards, Altera DSP Dev board, and a many other third-party dev boards featuring Altera FPGAs. Jesse Kempa Altera Corp. jkempa at altera dot com > Not yet. > I have a NIOS Stratix kit and will have a look at that subject soon. > There is a range of ADC/DAC available from different manufacturers. > They operate similarly. I'll possibly opt for an affordable 50Msample > pair. They shouldn't be too hard to add on a little board. > > > ReneArticle: 56157
rickman wrote: > You can put registers anywhere you want in a design. But neither Moore > nor Mealy machines have registers on the output values unless the > outputs happen to be the same as your state variables. I apologize for extending this recurring thread with distinctions that I don't really believe are useful. I see fitting gates for my HDL state-machine-like synchronous process as a job for my synthesis software. Synthesis is not concerned about the mealyness nor mooreness of my outputs or case statement. It does not really care if a flop is a state or output register. It just makes a netlist the sims like the code. If I stick to the standard synchronous process template, I have no combinational outputs to consider. However, the text-book machine models also work fine, so if you want to do one by the book, I will withhold judgment in the future. -- Mike TreselerArticle: 56158
Marc Randolph wrote: > > Howdy Peter, > > This might be more effort than you had in mind, but we've had a need > several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32 > bits out @ 50 MHz. And the reverse of course. While I'm dreaming, we > could use them in both BRAM and LUT RAM form. Expect it this fall, but probably only in BRAM form. The problem is that 1, 2 or 3 eight-bit words might get left stuck in the FIFO when it declares itself empty, because there is no more 32-bit word to be read. :-) I'll think about the other suggestions, but they may be unlikely. Peter Alfke > >Article: 56159
Mike Treseler wrote: > > rickman wrote: > > > You can put registers anywhere you want in a design. But neither Moore > > nor Mealy machines have registers on the output values unless the > > outputs happen to be the same as your state variables. > > I apologize for extending this recurring thread > with distinctions that I don't really believe are useful. > > I see fitting gates for my HDL state-machine-like synchronous > process as a job for my synthesis software. > > Synthesis is not concerned about > the mealyness nor mooreness of my outputs or case statement. > It does not really care if a flop is a state or output register. > It just makes a netlist the sims like the code. > > If I stick to the standard synchronous process template, > I have no combinational outputs to consider. > > However, the text-book machine models also work fine, > so if you want to do one by the book, I will withhold > judgment in the future. The point of making a distinction between Moore, Mealy and other FSMs is that, although your synthesis software may not care what is being synthesized, your design and analysis of the FSM operation is different for the various types. You can design any FSM that you can dream up. But if you want to use the tools that understand how FSMs work and assist you in your design, it helps if the common language is understood. Of course, I have not often used software to help me with FSM design. So the "definition" of Moore and Mealy may have changed. But FSMs with registered outputs are not at all the same as non-registered outputs unless your design happens to not care about the extra clock cycle delay. -- 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: 56160
Hi
I am developing a medium size reconfigurable project described in
VHDL. Modular Design flow is being applied in my project. I inserted
bus macros and I coded according to XAPP290 document. My project is
divided in two modules: reconfigurable module (client module) and
fixed module (memory controller module). The second phase of Modular
Design (Active Module Implementation Phase) has been performed with
errors. When map tool is performed for mapping reconfigurable module
(client module), that program issues the following error:
ERROR:MapLib:463 - Module reconfig_module contains multiple output
ports
connected to signal datain_from_module(10)
This is not allowed in modular design. Consolidate the ports into
one port
during the Initial Budgeting Phase. Or, if you are working with an
incomplete
modular design, use one of the following methods to ensure a unique
signal
drives each output port:
- Add buffers
- Replicate logic
See the answer database (http://support.xilinx.com) for more
information.
datain_from_module is a bus declared inside of top module. This signal
is connected in the "dataout" port declared inside of reconfig module.
The mapping error happens in this piece of code:
-------------------------------------------------
-- Register dataout contains the value to write
-- in memory at the moment of the write request
-------------------------------------------------
dt_out: process (reset, clock)
begin
if reset='1' then
dataout <= (others=>'0');
elsif clock'event and clock='1' then
if ld_dataout='1' then
if addr_count(0)='0' then
dataout <= x"48FFFF84";
else
dataout <= x"B700007B";
end if;
end if;
end if;
end process;
I tried to modify this piece of code and the map error disappeared.
However, this modification changed the behavior of client module,
turning the communication between client module and memory controller
module inconsistent. I read the Development System Reference Guide in
the Modular Design Chapter, and I didn´t find the point of my client
module that it needs for adding buffers and replicating logic. Can
someone find this point in the code? What can be happen in my project?
What kind of procedure someone can recommend? I appreciate any kind of
help.
Eduardo Wenzel Brião
Pontifícia Universidade Católica do Rio Grande do Sul - PUCRS
Porto Alegre city
Brazil
Article: 56161Here are the undisputed pros and cons: Antifuse advantages: Instant-on, needs no configuration PROM or other store, security is easier, and radiation tolerance is better for space applications. Antifuse disadvantages: one-time only programming (you have to throw the device away if you want to make any change) slow programming,( takes many minutes for larger devices) more restricted upper device-size limit ( no multi-mega-gate circuits) fewer sophisticated features (clock manipulation, RAMs, multipliers, etc) And a business aspect: Antifuse FPGAs represent a more specialized market, served by two relatively small suppliers. SRAM-based FPGAs are offered by the two big FPGA manufacturers plus some others, resulting in tougher competition and faster innovation. Yes, I am biased, but trying to be fair. Please no flames ! Peter Alfke, speaking for himself. Wong wrote: > > Hi FPGA experts, > What are the differences between those Antifuse > FPGAs(One-time-programmable, OTP) and SRAM-based FPGAs(I called it > Many-time-programmable, MTP) ? ;) > If one is using antifuse and would like to 'migrate' to SRAM-based, > what are the *important* considerations before the migration ? > As far as I know, one of the consideration would be the amount of > Sequential and Combinational cells are greatly 'sacrified' for RAMs in > SRAM-based FPGAs(compare both with the same amount of system gates). > Besides, SRAM-based FPGAs need external ROM during power-up to > download the bitstream. But look at Antifuse FPGAs, it is > S&C-cell-rich compare to SRAM-based and no extra device for > downloading the bitstream. > Any other considerations ? Please feel free to correct me if I am > wrong. > Thank you guys.Article: 56163
I don't know much about Semiconductor processes. But I wonder why it isn't possible to make FPGA's with some flash memory in there, enough to hold 2x the bit streams for the FPGA. A little Flash boot section (like CPLDS') of FPGA could be used to configure the rest of the FPGA from the Embedded flash. This means you can self configure with a protected bitstream, you can use the flash in your application if you like, etc etc. It also gives you NV ram in the FPGA which just can't be a bad thing. Seems like a simple idea - and a nice setup, is there a big technical barrier to such a setup? Is it comming? Should I have pateneted it? Are there already some out there? RalphArticle: 56164
Vaughn Betz wrote: > > Hi Leon, > > As Paul points out, some random bounce is pretty much unavoidable. To > minimize the bounce / get the best result, you can "seed sweep" which > basically runs the compiler multiple times with slightly different > starting point. By picking the best run, you can gain a little bit of > speed, by picking the luckiest compile. This also tends to cut the > random bounce from release to release, of course at the expense of > compile time. > > To do this, go to Tools->Tcl Scripts->Sweeper. The script is pretty > self-explanatory -- tell it what you want, and how many compiles > you're willing to do. > > You can also do this manually by using the "Initial Placement > Configuration" (sometimes called "Seed") setting in the > Assignments->Settings->Fitter Settings dialog. > > As Paul pointed out, another option is to back-annotate the placement > and/or routing to "lock in" the results of a good compile. All Altera > devices support back-annotation of placement. Only Stratix, > Stratix-GX and Cyclone support back-annotation of routing. > > When back-annotating placement to lock in performance, the best option > is typically to back-annotate and demote assignments to LABs (i.e. > don't lock down to the LE level). This reduces, but does not > completely eliminate bounce unless you also lock down the routing too, > and unfortunately locking down the routing isn't supported for the > 10K. Interesting - these tools are (slowly) becomming more like PCB design tools. Can you manually do a partial/local un-route, to support 'incremental compiles' ? ( which should be a LOT faster ? ) If a revison is fed into a route-back-annotated design, ( ie skip the manual un-route) how do the tools handle the conflicts ? -jgArticle: 56165
Ralph, The simple answer is that there is a real barrier to doing this. The cost. To stay ahead of competition and offer the most cost effective product, vendors choose to implement the latest FPGA with the latest process available: standard CMOS at .15, .13, .09, .065, etc..... If you choose a process that has flash technology, you tyically wait two years (or more) until after the same process geometry is available in CMOS. Where are we with FPGAs? Where are we with CPLDs? Both are at the absolute leading edge of their respective technologies, however FPGAs are farther down 'Moore's Curve'. The simple result? Yopu can have the new technology chip in CMOS for 1/4 the cost of the old technology chip with flash. Buying a separate flash is so cheap, that you can not make the economic argument to have them both on the same chip. The other problem, is that a little flash ram is not so little: 2.5 Mbytes. Austin Ralph Mason wrote: > > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? > > RalphArticle: 56166
Peter Alfke wrote: > > Marc Randolph wrote: > > > > Howdy Peter, > > > > This might be more effort than you had in mind, but we've had a need > > several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32 > > bits out @ 50 MHz. And the reverse of course. While I'm dreaming, we > > could use them in both BRAM and LUT RAM form. > > Expect it this fall, but probably only in BRAM form. > The problem is that 1, 2 or 3 eight-bit words might get left stuck in > the FIFO when it declares itself empty, because there is no more 32-bit > word to be read. :-) unless the system _guaranteed_ x4 byte streams, you would need a 'Valid' flag with each 8 bits anyway, so it would be a 36 bit ( or maybe 34 bit ) read. -jgArticle: 56167
Peter Alfke wrote: > > Jim Granville wrote: > > > > Peter Alfke wrote: > > > > > > I am looking at revamping the FIFO cores, giving you many options: > > > asynchr. vs synchronous, with exact empty and full > > > extra one-clock-early empty and full indicators > > > > Interesting - this would allow a smaller fifo for > > continual streaming output ? > Jim, I do not understand. It's just a warning, one clock tick ahead... I was thinking about a (possible) application, where sync state engines drive the FIFO, and no-pauses is a goal. If you wait for truly empty, then a pause must result, but a early empty might, with some gymnastics, allow full depth usage, and pre-empt the pause. More a mind-exercise than a real problem :) > > > > > programmable almost empty and full indicators, > > > readable occupied size , > > > etc > > > Any additional suggestions? > > > > Newer UART fifos have a WDOG type feature, where a montostable timer > > (runs at some multiple character time), generates an interrupt > > if ever bytes are 'left in the FIFO', but under the interrupt threshold. > > Allows a fully interrupt design, and avoids separate polling to > > check for remnant data, which might be a noise side-effect. > > Since this is programmable logic, I suggest each user implements this in > the logic fabric. > Agreed? > Peter Yes and no. Since you were taking the FIFO to the 'comprehensive' end of the scale, and I was also thinking of what the FIFO might be driving ( eg 'soft core' processors ), it seemed a logical thing to include such 'gotcha' captures into the FIFO. A SW designer ( I can feel the shudders ) who is doing an IP-paste job may not realise such a FIFO-remnant effect is even possible - it's a relatively 'late' feature in UARTS, so that field was slow to identify it. An experienced HW designer would, of course, anticipate such problems, and include FIFO-WDOG blocks from their library :) - jgArticle: 56168
As Austin also explained: What you suggest can be done, and has be done: in 1989 Xilinx made an XC3720, which was an XC3020 with on-chip nonvolatile configuration store, and it had the adantages you mention: self-contained and could easily be made secure. The problem was cost and performance. We used to joke: "Twice the price for half the speed". The price is higher because the chip is bigger: It has the extra storage cells, and it is made on a less advanced, (read bigger-geometry), process that can accomodate this mixture of device technologies. The chip is also slower for the same reasons. Most customers considered this a bad deal, and gladly bought the "normal" devices that somehow store their configuration externally. Undoubtably there might be a market for what you describe, but it would be for single-chip applications, where cost is secondary, and performance does not count. We think that this too small a market for us to engage in. Peter Alfke, Xilinx Applications Ralph Mason wrote: > > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? > > RalphArticle: 56169
Hal Murray wrote: > > >If it doesn't have an assember.... > > >Then it is a pain. If it has an assembler OR it has a c compiler, then > >it is really much more fun. > > >Picoblaze has assembler support, and MicroBlaze has c support. > > Good points. > > I'm thinking of the simple ROM based architecture where > the PC gets loaded from a next-instruction field in each > instruction. An assembler for that sort of system is really > pretty simple. (The parser is the hard part.) All you need > to do is recognize tokens and pack their values together into > an instruction. Not quite that simple. There is also some > work to assign instructions to locations and/or to pair up > locations for the brancing logic. > > It is pretty simple if you have an example to start with. > You just need to hack it to work with the appropriate tokens > for your system. On this path, there was mention a while ago in c.a.f of a (very old) uC core that used a LFSR as the PC. This solved a speed-bottleneck, (plus uses less logic) but needed more work in the assembler. Seems this could have real merit in the 'smallest cpu' direction. -jgArticle: 56170
Ralph Mason wrote: > > I don't know much about Semiconductor processes. But I wonder why it isn't > possible to make FPGA's with some flash memory in there, enough to hold 2x > the bit streams for the FPGA. A little Flash boot section (like CPLDS') of > FPGA could be used to configure the rest of the FPGA from the Embedded > flash. > > This means you can self configure with a protected bitstream, you can use > the flash in your application if you like, etc etc. It also gives you NV > ram in the FPGA which just can't be a bad thing. > > Seems like a simple idea - and a nice setup, is there a big technical > barrier to such a setup? Is it comming? Should I have pateneted it? Are > there already some out there? Austin has given the ecconomic-reason reply, but there is another pathway to get what you ask for, it just has not hit the FPGA sector yet. In Cellphones esp, there is growing stacked-chip deployment, and this needs some co-ordination between the die-layout teams, but the results allow DSP/FLASH/RAM to all be specialised 'best-process-fit' and importantly of late-selection sizes. There is no process-barrier to prevent this stack also including a FPGA - just needs the will and foresight to arrange things so the die can stack/bond. - jgArticle: 56171
Peter Alfke <peter@xilinx.com> wrote in message news:<3ED6492D.E3CF97AB@xilinx.com>... > Marc Randolph wrote: > >>Howdy Peter, >> >>This might be more effort than you had in mind, but we've had a need >>several times for an asymetric async FIFO... 8 bits in @ 155 MHz, 32 >>bits out @ 50 MHz. And the reverse of course. While I'm dreaming, we >>could use them in both BRAM and LUT RAM form. > > > Expect it this fall, but probably only in BRAM form. > The problem is that 1, 2 or 3 eight-bit words might get left stuck in > the FIFO when it declares itself empty, because there is no more 32-bit > word to be read. :-) Surely it isn't that hard to have a "flush" input pin that jumps the write pointer by whatever amount is necessary to produce the output word size? Or same concept, different method (less work on your part): a two bit input that provides an amount to add to the normal +1 increment of the write pointer (00 = don't add extra; 11 = +3). > I'll think about the other suggestions, but they may be unlikely. Darn! :-) Thank you again, MarcArticle: 56172
rickman <spamgoeshere4@yahoo.com> wrote in news:3ED5FB2E.D1EF6320@yahoo.com: > Fred Viles wrote: >> >> rickman <spamgoeshere4@yahoo.com> wrote in >> news:3ED3A6C7.229A5223@yahoo.com: >> >> >... >> > The second will have an ARM MCU and a large CPLD. >> >... >> >> There are JTAG probes available for ARM, at least, that have no >> problem with there being mulitple TAPs on the JTAG chain. >> (MultiICE from ARM and MAJIC from EPI, just to name two). >> Unless your CPLD programmer can't handle it, you shouldn't need >> to provide for isolating the TAPs in this section. >>... > To the best of my knowledge, the number of devices in the chain > has little to do with the hardware. I belive it is entirely up > to the software. Well sure. For some definition of "software" which varies depending on the probe you choose. E.g. for MultiICE it's an RDI compliant DLL on the PC, and for MAJIC it's firmware in the probe itself. For a cheap parallel port bit-banger like a Wiggler, it's host software either in a shared library or directly in the debugger. But I guess I don't understand how that observation is relevant to the question of whether your target board needs to isolate the various TAPs or not. I would think the only question is whether the probe+software you will use for each device supports the device not being the only TAP on the chain. I don't know about your CPLD, so I was just pointing out that for the ARM, at least, the answer can be yes. > I am not up to speed on the many suppliers of > debugging hardware and software for the ARM yet. I have heard a > lot of recommendations, but not many provide info on *why* one > combination is good or bad. That's a big subject to cover. There are a *lot* of products on offer from a lot of companies, not to mention the freeware/hobbiest options. They all have strengths and weaknesses, and what makes one a better solution than another is largely dependent on your particular needs. Do you need download performance? Multi-TAP support? Multi- Processor support? RTCLK support? ETM support? Networkability? Support for a particular debugger? Low cost? etc. >... - FredArticle: 56173
Followup to: <3ED659EA.F20FBA79@xilinx.com> By author: Peter Alfke <peter@xilinx.com> In newsgroup: comp.arch.fpga > > Here are the undisputed pros and cons: > > Antifuse advantages: > Instant-on, needs no configuration PROM or other store, security is > easier, and radiation tolerance is better for space applications. > > Antifuse disadvantages: > one-time only programming (you have to throw the device away if you want > to make any change) > slow programming,( takes many minutes for larger devices) > more restricted upper device-size limit ( no multi-mega-gate circuits) > fewer sophisticated features (clock manipulation, RAMs, multipliers, etc) > You're forgetting one: yield. Because an antifuse FPGA is OTP, no testing done at the factory can guarantee that every device will program correctly. I don't know that the fallout percentage is nowadays -- for all I know it might be negible -- but still... -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 56174
Jim Granville wrote: > > > On this path, there was mention a while ago in c.a.f of a (very old) > uC core that used a LFSR as the PC. This solved a speed-bottleneck, > (plus uses less logic) but needed more work in the assembler. > Seems this could have real merit in the 'smallest cpu' direction. > Not worth the trouble. Dedicated carry has made binary counters as efficient and almost as fast as LFSRs. Was different 10 and 20 ears ago... Peter Alfke
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