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
In article <fUNU4.25973$sB3.8788@news.indigo.ie>, "Eircom" <keith@suparule.com> wrote: > Can some one explain > > What is a macrocell > It's use > > keith@suparule.com > Please try to help yourself. You have presumably started looking into a pld of some description and found this reference. Read its description in a datasheet and if you don't understand because its badly written or not in your first language we will all be happy to help. Rob Sent via Deja.com http://www.deja.com/ Before you buy.Article: 22701
New, low cost, no fuss FPGA prototyping kits. Burch Electronic Designs www.BurchED.com.au The massive 20% off opening sale has been extended for just a few more days! Prices absolutely, positively have to go back up on Friday 26th May 2000! At this price, grab a couple for your lab before the sale ends! We are now listed at OptiMagic Programmable Logic Jumpstation (thanks to Steve Knapp). Check out and compare at: http://www.optimagic.com/boards.html ************ Announcing new, low cost, no fuss FPGA prototyping kits - real FPGA tools for real-world prototypes. These are the lowest cost, easiest to use FPGA prototyping kits on the market! Your favourite FPGA vendor is supported - Xilinx, Altera, Atmel, Lucent and Actel. Strength in simplicity: - FPGA (5K to 10K gates) on a board - Easy connection - FPGA pin numbers labelled on both sides of the board - Prototyping area - add what you want - Canned crystal oscillator module plus other components included - Configuration download pod board included - PC parallel port interface capability - Low cost - Easy! **************************************** OPENING SALE - 20% off the normal price! **************************************** ...An excellent time to grab a bunch of these for your lab, or maybe one for your student project. Pictures, specs, resources and online shop at Burch Electronic Designs: www.BurchED.com.au P.S. Lots and lots of uses. Here's some: - Prototype a module of your design for demonstration purposes, or to increase confidence in the module for a final target design. - Build them into one-off systems or special purpose test equipment. - Have a couple on hand for when you need to try out that circuit quickly (generally happens at midnight :) ). - Student projects (digital logic design, computer architecture, DSP, telecomms etc. etc.).Article: 22702
What is the best (easiest/fastest/most efficient) way to get verilog modules into a xilinx fpga design which was created using viewlogic's viewdraw schematic capture tool? Thanks, MarkArticle: 22703
Hello, We're looking for software to program jtag devices. Our requirements are that it be ms-dos based. Currently the only devices we need support for are AMD/Vantis M4-256/128 and Xilinx 9572. Are there any other programs besides JTAGPROG from http://www.jtag.com/ , or are they the only game in town? Thanks for any replies. Best regards, TrentArticle: 22704
I'm just curious. Has anyone used the LVDS lines in Altera's
20KxxE Apex parts? Actually any experiences with the devices at all
would be greatly appreciated.
Thanks!
Tim.
Article: 22705In article <392216F8.78E9786D@earthlink.net>, Ashok Mahadevan <ashokm1@earthlink.net> writes >Hello, > > I am a *very* new user to this FPGA stuff and I am using the >schematic capture feature in Altera MAX+Plus II 9.6 Baseline for >my design and have the following questions: > <<snip>> Try looking at what you can do in AHDL (Altera Hardware Description Language). Most of the benefits of text input (parameterisation, conditional & repetitive compilation) without the difficulty of VHDL. Look at http:\\www.freecore.com for some very good tutorials on this. -- Steve DeweyArticle: 22706
thanks for the verification. one thing, though, is there any specification for the time the pad begins switching versus when it hits 1.4v (as the datasheet gives for LVTTL). thanks again! -- douglas armstrong Spanuza Research Marc K. <marck@omneon.com> wrote: : Douglas, : Tiockp is the relevant time for outputs clocked in the IOB. It's the time : from clock edge at the IOB K pin to output pad valid, but you do need to : take the adjustments into account for drive strength, slew rate, and I/O : type. : Tioop is for outputs which are not clocked in the IOB. It's the time from : the IOB O pin to output pad valid, but you'd need to add the delay getting : to the IOB O pin, which includes routing delays and CLB delays. : Pin-to-pin output parameters are, paraphrased, "what's the delay from the : clock input pad to an output pad whose IOB is clocked?" If you use a DLL, : the internal clock net is delayed 0ns (that's zero ns) from the input clock : pad, so the delay from the clock pad is the same as the delay from the : internal clock net, i.e. Tiockp. (Okay, purists, the former is 0.2ns greater : than the latter, worst case, which is probably due to the delay through the : IBUFG.) If you don't use a DLL, there's an additional delay from the clock : pad through a global clock buffer to the internal clock net--the DLL is : useful because it compensates for this delay. : If you're clocking your outputs at the IOBs and you're using a DLL, I think : the Tickofdll is the relevant parameter, with adjustments. If you're not : using a DLL, then use Tickof. : If you're not clocking your outputs, you'll need to implement your design to : get the correct timing, which the timing analyzer provides (you won't need : to know or care about Tioop). But that's rather risky, because routing : delays can easily dwarf the 3-5ns Tickof, and a preliminary design which : shows promising timing could turn into a final design with bad timing. : The safest approach, if you can justify it, is to assume you can't use a : DLL, design with Tickof, and then go ahead and use the DLL. : MarcArticle: 22707
> thanks for the verification. one thing, though, is there any
> specification for the time the pad begins switching versus when it hits
> 1.4v (as the datasheet gives for LVTTL). thanks again!
>
Douglas,
That's a toughie, even for somebody involved with the design of the
chips, and I am not affiliated with Xilinx, let alone one of the Virtex chip
designers.
I can say this: the best you can absolutely rely on is that the delay to
1.4V will fall between the minumum and the maximum for the conditions
(device type and speed, and output slew and drive strength), and that's
quite a spread. The Xilinx datasheets don't differentiate between the slew
of or delay to rising and falling edges, which are probably different.
Perhaps the IBIS models could give you a better idea.
If it's truly important to know how early or how late an output *could*
start changing, worst case, I'd look at the equation associated with Table
14 on page 32 of the Virtex v2.1 specification, or the corresponding one for
Virtex-E. The final term implies a slew rate that is constant and depends on
output loading. You would need to determine the worst case minimum/maximum
clock to output delays (for example 1.0ns/3.6ns for Tickofdll of an XCV50,
fast slew, 12ma drive, with DLL) and then use that last term (slew rate) of
the above-mentioned equation to determine how much earlier the output would
have started switching in order for it to reach 1.4V at the specified time,
taking into account the adjustments for fast/slow slew rate and the drive
strength.
Personally, unless you're trying to do something more than communicate
with ordinary digital logic, you shouldn't even worry about all this. Assume
the minimum and maximum clock to output delays are the minimum and maximum
for Tickof or Tickofdll, as appropriate, for your device type, output slew
rate, and output drive strength. Then make sure that minimum delay meets the
hold time requirement of the external devices, and the maximum delay meets
the setup time requirement.
Okay, I didn't answer your question, but I'm not sure there is a correct
answer.
Marc
Article: 22708So is it better to have the DLL on the FPGA drive the clocks of components or to have a traditional clock multiplier with multiple outputs drive them and make sure there is no clok skew? We have a lot of parts to clock, SRAM, SDRAM, PCI, etc.. which approach is better? We're using non -E parts which means only 4 DLLs. Now, the system clock should drive one DLL directly (with feedback to itself) for the internal logic. So the same IBUFG input from the global clock pin system clock can safely be split to multiple DLLs which drive normal OBUFs (not BUFGs)? Should each DLL drive multiple OBUFs to go to each component with equal length traces or can it only drive one OBUF which has to then be split with an outside part to drive each component. Also, what are the PCB layout concerns for the feedback pin? I'm assuming it needs a IBUFG pin. And that it should be routed with an equal length as the traces going to th eother components. Where is it best to split the trace? does it matter much? But I have hesitations of one OBUF driving the clock of, say, three PCI components and the feedback pin.. Thanks in advance! Marc K. <marck@omneon.com> wrote: : Tom, : Here's another idea, if you've locked the output clocks and they're : impossible to route with low enough skew, but it will take two global clocks : and two BUFGPs and two DLLs. : Take your reference clock and feed it to the first DLL's input. This DLL : drives a global clock through a BUFGP, so the BUFGP output must feed back to : the DLL. Use this clock for only one thing: driving the 4 (or more, possibly : many more) output clocks. You'll need a special circuit to make sure the : output clocks are all closely phased. I use two flops, one clocked on the : positive edge, one clocked on the negative edge, arranged as a 2-bit gray : counter (D1 <= !Q0, D0 <= Q1), and take Q0 ^ Q1 (actually, I used Q0 XNOR : Q1) out to the IOB O pin directly. You'll need one instance of this clock : circuit for every output pin, but if you place the flops and the XOR LUT : into a single CLB (two slices, since you're using two different clock edges) : right next to the output pin and make sure routing from the flops to the LUT : to the IOB O pin is controlled (via constraints or manual routing) you : should be able to get better than +-500ps skew among all the output clocks. : As I said, you can have many more than 4 of them, and they can be : distributed across the chip. The second DLL is used as your primary internal : clock. Take one of your clock outputs, route it back to the second DLL, use : a BUFGP with it. That's your clock for all internal logic. Again, since : you're using a BUFGP with the DLL you'll need to feed back this second : BUFGP's output to this second DLL. This clock will be phased to the output : clocks, so you can use it to drive data out and bring it back in. You will : add two DLL's worth of jitter to this clock, though. : One other thing: you'll probably want to make sure the first DLL has 50% : duty cycle compensation turned on. : Good luck, : MarcArticle: 22709
"Douglas Armstrong" <site@typhoon.xnet.com> wrote in message
news:8g1s12$d6e$1@flood.xnet.com...
> So is it better to have the DLL on the FPGA drive the clocks of components
> or to have a traditional clock multiplier with multiple outputs drive them
> and make sure there is no clok skew?
It's less risky but more expensive to use the external clock multiplier
(I'll refer to it as a clock driver from now on). That is, until you try
using the FPGA and find it works fine. Then it's just more expensive.
>
> We have a lot of parts to clock, SRAM, SDRAM, PCI, etc.. which approach
> is better? We're using non -E parts which means only 4 DLLs. Now, the
> system clock should drive one DLL directly (with feedback to itself) for
> the internal logic. So the same IBUFG input from the global clock pin
> system clock can safely be split to multiple DLLs which drive normal OBUFs
> (not BUFGs)? Should each DLL drive multiple OBUFs to go to each component
> with equal length traces or can it only drive one OBUF which has to then
> be split with an outside part to drive each component.
>
If all the clocks (SRAM, SDRAM, PCI, etc.) are the same, my previous
statement still applies. If they're not, then you'll run out of DLLs with
more than two clock domains. From my most recent post, you need two DLLs and
two global clocks inside a Virtex (-E or not) to provide the internal logic
clock and the mechanism for driving many output clocks from all over the
chip with minimal skew. This means a Virtex (-E or not) part can handle two
independent clock domains with my "special" clocking scheme. From my earlier
post (really XAPP132, which I referred to several times as XAPP133, sorry),
you still need two DLLs per clock domain if you're driving output clocks,
and you need to manage pin locations and routing carefully for multiple
outputs. The bottom line is, either way, if you choose to use the Virtex
part to drive output clocks, you can drive more than one. How many depends
on which technique you choose. If you have any thoughts about using clock
drivers to buffer clocks, use them at the oscillator and match trace lengths
to each driven device, including the Virtex part. As I said at the
beginning, that's the safe way to go. Normal clock routing rules apply to
all clocks, no matter the technique or source. Serpentine routing and
matched trace lengths are important. Too much loading can cause problems.
Termination is vital.
Also, don't bother sending a global clock pin through an IBUFG to multiple
DLLs. It doesn't buy you anything, unless you need several divided clocks,
e.g. /2 and /3. One DLL driving one BUFG can drive every single clock in the
device. If you're thinking of using more than one DLL to drive OBUFs
directly with the same clock (for routing purposes, I suppose), I'd advise
against it. I don't think you could rely on the outputs from the two DLLs
matching up.
Personally, if you have just one or two clock domains, I recommend the
"special" clocking I mentioned in my previous post. You don't need external
clock drivers for SRAM, or SDRAM, or PCI, etc., and the Virtex part will
provide as many buffered clocks as you want. Are you driving 16 SDRAMs? You
can choose to use 1, 2, 4, 8, or 16 separate clock outputs. And so on. The
Virtex OBUFs aren't quite as strong as a clock driver, so you need to keep
that in mind.
> Also, what are the PCB layout concerns for the feedback pin? I'm assuming
> it needs a IBUFG pin. And that it should be routed with an equal length
> as the traces going to th eother components. Where is it best to split
> the trace? does it matter much? But I have hesitations of one OBUF
> driving the clock of, say, three PCI components and the feedback pin..
>
I've seen it done both ways on other chips. It all depends on your skew
budget. For what it's worth, I'd work hard to balance the load on each
output clock, and use a dedicated output as the feedback, complete with the
provision for a small capacitor to ground, so if you find there's a little
skew you want to correct for, you can. I'd match the trace lengths, and that
little capacitor would probably be 10pf or so, or, more accurately, it would
match the capacitive loading for your other clock lines. Also, the feedback
pin will go to an IBUFG.
By the way, just so you know, I've never used my "special" clocking scheme
exactly as I've described it. I've used it for output only, as a
source-synchronous clock for a transmit channel, and I didn't need to lock
the internal clock to the output. Instead, I relied on the phase
relationship of the internal clock to the output clock and to the output
data. Doesn't that fill you with confidence? The only difference between
what I've done and what I suggest is that I used just one DLL for the
internal logic clock and as the source for the "special" clock drivers. I
have looked at the routing and measured the skew among the output clocks,
though, and I have 4 coming off opposite sides of an FG456 package, and
there's about +-200ps skew among all 4 clocks. Taking that into account
along with XAPP132, I have complete confidence you can use the Virtex to
drive all the clocks you could want.
I hope this helps more than it confuses.
Marc
Article: 22710I've a small problem, i don't know how to perform a DCT (Discrete cosine transform) implementation using FPGA for a picture for example, i can compute DCT on a paper but not in XILINX for an FPGA, if some one can help me, don't hesitate to do it !! Thx in advance SEBArticle: 22711
Hello! I am currently in the R & D phase of a potential new product. We need to have a replicated microprocessor, but have it running at far greater speeds than currently available through the normal manufacturer. We are more than willing to use the much larger FPGA's out there to accomplish this. Anyone who has experience in creating/emulating computer designs with FPGA's, please get ahold of me. I will discuss more and have greater in-depth questions. Regards, Jim W. KrychArticle: 22712
Simon, Could you pass along any identifying numbers for the XC1804 devices you were using? For example, date codes of JTAG device ID ? I want to avoid repeating your discovery. -Dave Simon Ramirez wrote: > > Peter, > There have been many problems in the JTAG Programming of Xilinx FPGAs. > I believe that SP6 solves many problems but at least one problem remains. > We found that the SPROM had to be the FIRST device in the chain or it > doesn't program properly. Also watch out for possible bad XC1804s -- the > first ones had real big headache problems in them. > There are two kinds of problems here -- software problems in the JTAG > program and hardware problems in the SPROM and possibly elsewhere. Xilinx > will readily admit to the software problems if you probe them enough. > Getting data from them on hardware problems is next to impossible. > Simon > > > The boundary scan (JTAG) chain is built up in the following way: > > > > Parallel Cable III -> Virtex 600 -> XC95144XL -> XC1804 -> back to > > Parallel Cable III > > > > Chain intitialization is working, the JTAG SW gets the correct device > > information. > > The Virtex 600 can be configured and the circuit is working fine. > > The CPLD 95144 hasn't been tried to configure yet. > > > > Are there any known bugs which can occur in this kind of JTAG chain? > > > > Are there any known bugs concerning the JTAG programmer software? > > > > Are there any known bugs concerning these brand new kind of PROM? > > > > Any kind of information concerning our problem is welcome. > > > > > > Regards > > > > Peter Schulz > > Signaal > > > > > > > >Article: 22713
In article <3924b101$1_2@athena.netset.com>, J.W. Krych <jwkrych@n2net.net> wrote: >Hello! > >I am currently in the R & D phase of a potential new product. We need to >have a replicated microprocessor, but have it running at far greater speeds >than currently available through the normal manufacturer. > >We are more than willing to use the much larger FPGA's out there to >accomplish this. Anyone who has experience in creating/emulating computer >designs with FPGA's, please get ahold of me. I will discuss more and have >greater in-depth questions. In general, you take a performance hit on an FPGA. You might be able to, with some careful layout, be able to hit 100+ MHz but not tha much faster, depending on how tightly you pipeline it. (The LEON1 runs at 40 MHz, SPARC clone). Question: Just how much performance do you need, and what is your base machine? Could you translate your code to a more modern microprocessor? A StrongARM is pretty cheap and pretty darn fast, and there are others out there as well. If you would see a significant speedbump by switching to an FPGA, you might even be able to get away with just a software emulation on a modern, high performance embedded processor. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 22714
You're not likely to outperform a processor chip by emulating it on an FPGA, unless it is really old technology. Where FPGAs gain an advantage over microprocessors is when you can create a circuit optimized for the task at hand rather than generalized to handle a wide variety of tasks (eg microprocessor). That said, you can make a fairly fast microprocessor in an FPGA, but you need to architect it to take advantage of the FPGA structure. Commercial CPU chips generally do not map into the FPGA architecture very well. "J.W. Krych" wrote: > Hello! > > I am currently in the R & D phase of a potential new product. We need to > have a replicated microprocessor, but have it running at far greater speeds > than currently available through the normal manufacturer. > > We are more than willing to use the much larger FPGA's out there to > accomplish this. Anyone who has experience in creating/emulating computer > designs with FPGA's, please get ahold of me. I will discuss more and have > greater in-depth questions. > > Regards, > > Jim W. Krych -- P.S. Please note the new email address and website url -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com or http://www.fpga-guru.comArticle: 22715
"J.W. Krych" schrieb: > > Hello! > > I am currently in the R & D phase of a potential new product. We need to > have a replicated microprocessor, but have it running at far greater speeds > than currently available through the normal manufacturer. > > We are more than willing to use the much larger FPGA's out there to > accomplish this. Anyone who has experience in creating/emulating computer > designs with FPGA's, please get ahold of me. I will discuss more and have > greater in-depth questions. Have a look at www.arccores.com Maybe they can help you. Regards, Norbert HoppeArticle: 22716
Hello, Are there any vendor independent printed magazines about VHDL and/or FPGA/ASIC designs available? If yes, where can I get them in Germany? Thanks in advance, ThorstenArticle: 22717
In article <39214516.DFEB2C69@utc.fr>, Sebastien Favard <Sebastien.Favard@utc.fr> wrote: >I open a new topic... (after the famous :) "Init/ line - CRC error ???") Of course, it would be nice to know what factor on the previous thread was the cause of the problem, so that you could advance to this new topic. > >I have buying a new XC5202 and I have progress on the programmation >process step. > >Firstly, the HDC and LDC/ lines are correctly pull up and pull down >respectively. So the FPGA was sick??? >During the FPGA programmation step, the header is correctly detected and >its bits are reported on DOUT. Just after the header, DOUT is hold at 5V >:) and during the data stream, no crc error ic occured. > Thats encouraging. >But after these things Done is hold at low and never pull up. So I think >that I have a problem like my length count or perhaps my startup process >? I use in fact CCLK to startup the FPGA, so I put some CCLK rising edge >after the data stream to force my FPGA to start up. Are you using the default startup sequence. Default selects CCLK for the startup sequence. (which I recomend) Do you have a pullup resistor on the done pin, 4.7K ohms. How many extra clocks are you giving the FPGA. I usually give it an extra 16, just to be sure. (Do not change length count, just give it extra clocks) One test for the length count value being too low a value is to give the chip 16777216 extra clocks, and see if it goes done (i.e. causes the 24 bit counter to roll over. At the end of the bitstream, you can append '01010101...' bits and keep clocking the FPGA. The FPGA should output these bits on DOUT if the chip has reached the "finished" stage, but there is a problem with length count. > >Perhaps anyone has an idea about my new problem ! (maybe the >FPGA banished me ;-) ) Keep trying. Hopefully once you have it all going, you will look back on your problems and wonder why it didn't just work first time. By the way, are you aware that the 5200 series is not a "preferred" product for new designs. Spartan and Spartan II devices are faster, have more features (like decent I/O cells, better carry logic, and on-chip RAM), and they are cheaper. >Thanks a lot, >Sebastien, All the best, Philip FreidinArticle: 22718
Eircom wrote: > > Can some one explain > > What is a macrocell > It's use > > keith@suparule.com The programmable logic jump station has some useful pages, such as FAQ on programmable logic and it does explain about macrocells. http://www.optimagic.com/ Regards Lee. -- Lee Weston, Philips Semiconductors, CS-DM Southampton, SO15 0DJ, UK mailto:lee.weston@philips.com seri:weston@ukpsshp1 phone: +44(0)1703 702 701 x6471 fax +44(0)1703316303Article: 22719
Hi We at Nallatech would be happy to provide training and support for our products. Regards Allan -----Original Message----- From: A. [mailto:ahmad@frognet.net] Posted At: 18 May 2000 05:39 Posted To: fpga Conversation: Traning for Nallatech?? Subject: Traning for Nallatech?? Hi all.. we have Nallatech Virtex XV800 board. Is their any short training courses into how to use it? Thank you in advanced.Article: 22720
Hi, I'm looking for a 68k - core in order to replace an old 68000 design with an fpga. does someone know an 68k core and where to get it. 68020 would be fine. thanks HolgerArticle: 22721
J.W. Krych <jwkrych@n2net.net> wrote: > I am currently in the R & D phase of a potential new product. We need to > have a replicated microprocessor, but have it running at far greater speeds > than currently available through the normal manufacturer. As mentioned by others, this is not a good fit for an FPGA. One exception might be a product announced by quicklogic that puts multiple ALUs and RAM on a chip with an FPGA fabric: http://www.quicklogic.com/devices/dsp There's a guy in my field (High Energy Physics) that for years has been proposing to build a chip with many simple/fast CPUs optimized for processing multiple real-time streams of data. He has designs and software that you may be able to use: http://www.3d-computing.com/ -- Don Husby <husby@fnal.gov> http://www-ese.fnal.gov/people/husby Fermi National Accelerator Lab Phone: 630-840-3668 Batavia, IL 60510 Fax: 630-840-5406Article: 22722
In article <8g35hv$sdu@newsserv.vs.dasa.de>, Holger Azenhofer <holger.azenhofer@vs.dasa.de> wrote: >Hi, > >I'm looking for a 68k - core in order to replace an old 68000 design with an >fpga. >does someone know an 68k core and where to get it. >68020 would be fine. VLSI Concepts offers a 68000 object code compatible core: V68000 See http://www.vlsi-concepts.com/V68000.html or contact Ed Hepler: hepler@vlsi-concepts.com for more informationArticle: 22723
Jean-Luc Nagel wrote: > > Rick Collins wrote: > > > How many boards do you think you will need? If the quantity is sufficient, I am > > sure that someone will work with you to add such a board to their product line. > > Well the quantity is rather small because we would only use these boards for a > small number of demos. The asic is anyway the goal. > Ok I guess I will forget PC104+ ! :) > > -- > Jean-Luc Maybe you can explain a little more about what you are doing and why you are looking for a PC/104+ board rather than a standard PCI board. Is your final product going to be PC/104+? Is there a reason that you can't use a PCI to PC/104+ adaptor? I have read that there are sources for such a converter board. -- Rick Collins rick.collins@XYarius.com remove the XY to email me. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 22724
In article <8g01ig$6rs$1@okapi.ict.pwr.wroc.pl>,
tbrychcy@sensor.ime.pz.zgora.pl says...
> Hello,
>
> I would like translate the part of vhdl source to verilog. Please about
> correct translation the fragment of vhdl.
>
> process(READ,RESET)
> begin
> if (RESET='1') then
> BYTE<='0';
> elsif (RISING_EDGE(READ)) then
> if (CS='1' and BACK='0') then
> BYTE<=not BYTE;
> end if;
> end if;
> end process;
always @(posedge READ or posedge RESET)
if (RESET)
BYTE <= 0;
else if (CS & ~BACK)
BYTE <= ~BYTE;
--
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.
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