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
Austin wrote:
>The 'problem' here is that Virtex and Virtex E has 4 and 8
>respectively global clock resources so that in some cases
>where they want multiple banks of I/O's running at 622 Mb/s,
>they run out of clocks (and DLL's). Altera has even fewer
>clock resources.
I believe the 'problem' to which Rick was referring is
not that he had too many clock domains, but that the Xilinx
sanctioned Virtex-E method of doing 622 MHz input data, as
described in XAPP233, requires a separate, non-global,
intentionally-delayed-by-1-ns, half-rate clock input pin
adjacent to every two data pins.
If the data source provides 16 data bits and one 622 MHz
clock, this can be a bit tricky to accomplish on the board.
>So, the assumption is incorrect. The global clocks are quite
>adequate for the 311 MHz required for DDR at 622 Mb/s in Virtex E.
>There are many products running at 155 MHz in Virtex, and 311 MHz
>(622 Mb/s DDR) in Virtex E with one clock per 8 to 16 IO's.
The global clocks are adequate for the XAPP233 Virtex-E
DDR output mux macros, but I haven't noticed any Xilinx app.
notes stating that the global clock can be used to realize
the necessary timing for the input demux structure, across
16 inputs, on a Virtex-E, at 311 MHz DDR. ( for instance,
XAPP245 shows a 320 MHz DDR demux with one non-global
input clock pin per 8 RX bits, with 700 ps external delay )
It looks like the incorporation of the DDR mux/demux into the
IOBs in Virtex-II will make life much easier.
I'm also glad to see that the new Virtex-II LVDS I/O are
actually differential in all of hardware, software, and the
primitive and simulation libraries.
My past experiences with LVDS I/O support in the first few
releases of Virtex-E software could best be summarized by the
following riddle ;-)
Q: How many Xilinx software engineers does it take to count
the input pins on a Virtex-E differential input buffer?
BTW, have MAP & PAR for Virtex-II eliminated the previous
requirement to manually lock down ALL I/O's, of any type,
if ANY differential I/O buffers are used?
Brian Davis
Article: 30101>The mux's don't have to drive across the whole chip. Maybe they need to drive > to one of the CLB's that may be reached by the directs, doubles (or hexes), > making the amount of logic that can be reached quickly, large. I'm still not getting it. My picture is that I have a register on the left side of the chip and another register on the right side. Sprinkled in the middle are various registers and counters. I want to be able to load the register on the left from any of the others, including the one on the right. Same in the other direction. This is easy to understand with TBUFs. I might not like the answers, but it's easy to floor plan things so all the routing is as good as it will get. The pattern is clock, enable, tbuf drives longline, setup, clock. This fits well with a style that thinks of the problem as a specialized CPU like gizmo that gets driven my a microcoded engine. Most of the changes go into the microcode. The instruction format includes a field to specify which register drives the bus and another field for which register gets loaded. (Occasional hacks are handy to load several registers on the same cycle.) Are you using a mux in front of each register you want to load, or a shared mux feeding all the registers? If I assume a mux in the middle, then the nasty case is clock, routing-to-mux, delay through mux, delay through long-line like routing to get all over the chip, setup, clock. If I assume a mux in front of each register, the pattern is the same but some things have been pushed around. I'd guess the timing will be similar. Perhaps your test cases go faster because you didn't put registers that far apart so you don't have to route across the whole chip. If so, then the problem isn't TBUFs, it's the long line across the whole chip that they are driving. I could easily see that FPGA are now big enough that having a bus span the whole chip isn't useful very often. Did you try your test cases on a smaller chip? Perhaps TBUFs feeding not-so-long lines that only go part way across the chip would be interesting (aka faster). I'm assuming there would be a pair of good TBUFs at the segment junction that I could use to cennect them and/or put a register there to pipeline things. My straw man (not much thought) is that the right length would be to match the register transfer timing to what it takes to get through a (pipelined) RAM or multiply stage. Or maybe short segments collapses to something mux like if you have lots of local/medium routing resources. -- These are my opinions, not necessarily my employeers. I hate spam.Article: 30102
Austin, You can say that your parts will do the job. But when Xilinx came in to consult on the job, they said that the only way their product could clock data in at 622 MHz was to use 8 copies of the clock with one running to two adjacent data input pins. So the issue would seem to be one of internal routing of such a high speed clock. You are saying that you can input a 322 MHz clock and use both edges to clock the data in. I can't say why no one suggested that solution at the time this project was being conceived. I also can't say how practical this approach is in the application. The Altera parts are running on the board just fine. They use an ~80 MHz clock on the IO and use the PLL internally to regenerate the 622 MHz clock. The ~80 MHz clock is generated on the board from the 622 clock and is needed elsewhere. What I do know is that these guys are not slouches. They are some very good engineers and have no preference between Xilinx and Altera. They regularly use both vendors and only choose one vendor's parts if there is no way to use the other's. Otherwise the choice is made on price. So if the info we got was wrong, you may want to send your FAE's back to school. Austin Lesea wrote: > > Rick, > > I have not come to bury PLL's, but to praise them. In some applications, they are the > best way to solve the problem. Just be sure they work with the rest of the system. > > The 'problem' here is that Virtex and Virtex E has 4 and 8 respectively global clock > resources so that in some cases where they want multiple banks of I/O's running at > 622 Mb/s, they run out of clocks (and DLL's). Altera has even fewer clock resources. > > The Virtex II has 16 global clock resources. From any clock input to any IO FF the > maximum skew is +/-75 ps. The global clocks run quite nicely at 420 MHz (along with > the DCM's) for the 840 Mb/s SPI POS 4 application. > > So, the assumption is incorrect. The global clocks are quite adequate for the 311 MHz > required for DDR at 622 Mb/s in Virtex E. There are many products running at 155 MHz > in Virtex, and 311 MHz (622 Mb/s DDR) in Virtex E with one clock per 8 to 16 IO's. > > At 622 MHz, I think you are well out of the datasheet specifications on the clock > resurces and interconnect for any FPGA out there. It seems that for bit rates >500 > Mb/s, or clock rates > 500 MHz, everything will be done by serializer/deserializers on > chip, or "specialized" logic (ie dedicated hardware interfaces) due to the signal > integrity nightmares, and the collision with trying to make a general IO do magic. > > As an interesting aside, the input pins of anyone's package is typically series > resonant at ~650 MHz. What this means is that there is no signal on the input pin, > yet the signal (may) makes it to the IOB (the magic of transmission lines). Makes it > really hard to debug! > > Austin > > Rick Collins wrote: > > > Interesting that you mention the IO. At a company where I have done > > work, they needed a 622 MHz interface. The Xilinx solution using Virtex > > required multiple inputs for the clock. I assume that the global clock > > routing was not up to the task at that speed. With 16 data bits and 8 > > clock inputs, the resync problem was so large that they ended up using > > the Altera parts. They used 16 data inputs and a single ~80 MHz clock > > input. A PLL ran the clock back up to 622 MHz and the input FFs all ran > > off the same clock. > > > > So neither system really did what the designer wanted. But the Altera > > solution was the simplest at the time. -- 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: 30103
Hi, Any available code for a single-pole IIR lowpass filter implementation in VHDL? Filter equation: y(n) = px(n)+(1-p)y(n-1) The input are 16-bit 2's complement values DavidArticle: 30104
Hello everybody,
Iam having some sub blocks in my design, every block separtely works at 200 MZ and also every blocks are having registered Inputs and Ouputs.
I would like to know is it possible to make the design(top level) to work at same frequency as the sub blocks.
and also would like to know, does the place and route tool will do routing according to the timing constraint given while synthesis ?.
is there any book or site which can give introduction about ,how to do manual place and route in XILINX tool 3.1i foundation series .
regards ,
Manjunathan
Article: 30105On Fri, 23 Mar 2001 02:36:16 +0100, "Daniel Nilsson" <danielnilsson@REMOVE_THIShem3.passagen.se> wrote: >Hi. >I have a cpld (xilinx xc9500) in my system, mainly used for controlling >buffers, and I suspect I will need to add pull up or pull down resistors >where appropriate to prevent damage on system because of strange levels on >I/O pins during jtag programming or power-up. Is it common practice to do >like this, and if so, what are the appropriate values to add to force out >pins to a safe level (to prevent bustranscievers from being turned on) >during high-z ? > >/ Daniel Nilsson > > Your resistor must be low enough to assure that when all the gates you are driving consume their maximum input current a valid level is still maintained. Usually (for CMOS logic like HCT with high impedance inputs) 10K - 100K should work well. Best regards Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@IHATESPAMdurst.itArticle: 30106
It is recommended to connect unused pins to ground to conduct heat from the chip to the copper ground plane on the PCB. There are chip manufacturers that ask you to tie a few pins to group for that purpose. Gil. Pratip Mukherjee wrote: > WebPack shows all the unused pin as TIE and explains that: > TIE = Tie pin to GND or board trace driven to valid logic level > My question is do I really have to? If so, can I somehow do that internal to > the CPLD, without actually trying to run a trace (even worse, solder wires) to > all the unused pins? > > Thanks. > > Pratip Mukherjee > pratipm@hotmail.comArticle: 30107
The general PIC architechture is from the 70s, so any patent issues should be
resolved by know.
But you might want to check for features that were added later to the
architechture.
Also, in most countries it is alomost impossible to protect ISAs.
CU,
Kolja
Kent Orthner wrote:
> Does anyone know off-hand the licensing for these cores? Can we
> use a free 6502 core in a commercial product? Ditto for PIC-
> compatabile cores. I know that the licensing on Jan gray's
> web site (www.fpgacpu.org) specifies no commercial uses.
>
> Some of these other cores might be free but the instuction sets
> copyrighted? (I'd like to put together a instructoin-compatable
> PIC core, but I can't figure out if I'd be allowed to use it. )
>
> Anyone know?
>
> -Kent
>
> > Gaston Biessener wrote:
> > > I am working on a product design that is tentatively planned to be
> > > based around a Spartan-II device with a small Micro-P core implemented
> > > in the FPGA as the system controller.
>
> Phil Hays <spampostmaster@home.com> writes:
> > Might checkout:
> >
> > http://www.fpgacpu.org/
> >
> > http://tech-www.informatik.uni-hamburg.de/vhdl/vhdl.html
> >
> >
> > --
> > Phil Hays
Article: 30108
Hello Everybody !!
after doing implementaion using XILINX tool,in post layout timing report it showed us maximum frequeny is 191 MZ ,but in pad report it has given a net having delay of 8.711 ns. then how is possible to work under that much frequency.
and we checked the net delay with fpga editor it showed the same(8.711 ns). i would like to know where is the error?.
thanks in advnce.
regards,
Manjunathan
Article: 30109"Ray Andraka" <ray@andraka.com> wrote in message news:3ABA5C75.68E00301@andraka.com... > Does anyone know of any commercially available boards offered with the XCV812E > on it? Looking for one for a fast prototype. > Hi Ray, Hunt Engineering do one - http://www.hunteng.co.uk/info/fpga-dsp.htm and follow the links to the FPGA2 module. Can be coupled to ADC and so forth. All the best, Ralph Weir Hunt Engineering http://www.hunteng.co.ukArticle: 30110
Pete Dudley wrote: > > Has anyone tried implementing reduced precision floating point arithmetic in > an fpga? > > With the new Virtex II 18 bit multipliers it occurred to us that we could do > floating point multiplies pretty efficiently if we reduced the mantissa size > from 23 bits to say 17 so that the mantissa multiply would fit in the hard > multipliers. > > We want to miniaturize an algorithm that currently executs on a fabric of > Mercury PowerPC nodes in floating point of course. By the way, I have some pipelined single precision fp add and mul edif module that I might consider to make available (fro free of course) on the Web. The module are targeted over the Virtex family and show relatively good performance compared to commercial cores (see floating point library www.annapmicro.com) : up to 112 Mhz for the FP mul on a virtexE-8. However, since putting this on the web take me some of my very precious time :)) , i won't bother doing it unless enough people are really interested. Steven > > -- > Pete Dudley > Sandia Labs > Albuquerque, NM > padudle@sandia.govArticle: 30111
Hi. I am looking for an unbiased price comparison of boundary scan tools from the various vendors. (JTAG, Asset, Corelis, Goepel, Intellitech, Acculogic, etc. (any others??)) Any info. or web sites would be appreciated.Article: 30112
Originally I had a 5V target system containing a PZ5128, this was programmed using the target CPU by bit-bashing the contents of a BIF file generated by the XPLA programmer software (as detailed in XAPP326 - Simplified in-circuit programming...). This worked perfectly. However now I have to use an XCR3256XL (3.3V) device in a 5V target system. I've re-made the design in WebPACK from a schematic and created a new BIF file. Bit-bashing this file into the device has no effect what so ever. The JTAG pins appear to be driven with the correct bit patterns. The PORT_EN pin is connected to the CPU RESET signal (active low) which is low as the system powers up and then goes high (although the port is also reserved in the design configuration). I've even put level translators in the TDI, TMS, TCK lines so the device JTAG port is driven at 3.3V rather than 5V but to no avail. Has anyone got any experience of this process with this device as at present I can see no solution. Many thanks in advance Ian McCarthy ianmccarthy@casella.co.ukArticle: 30113
It doesn't have to be a kludge of any sort. The strobes are generated at the PC end in rigorous synchronization with the PC, and the entire transfer and handshake can be accomplished with just a pair of dual-rank registers on the nWAIT/RDY signal. The strobes, as I wrote before are preceded by settled data, so if you gate latches on the data path and synchronize the handshake with the data path registers downstream from the latches by clocking the registers from the rising edge of nWAIT/RDY, yet leave the latches' gates open until the falling edge of nWAIT/RDY all setup and hold times will be satisfied, yet the task of synchronizing the data transfer between the host PC and the downstream data path logic is effected with only two D-flops. In short, if you open the data gate with the occurence of one of the derived strobes (DataRd, DataWr, AddRd, AddWr), and close it with the falling edge of nWait/RDY, yet clock the downstream registers with the handshake, generated from a dual-rank register also used to feed back the OR of these strobes to the nWAIT/RDY signal, there's no risk of metastabile results to speak of. It's also pretty simple to do in a CPLD. Dick On Mon, 19 Mar 2001 07:04:06 -0000, hmurray-nospam@megapathdsl.net (Hal Murray) wrote: >>I' like to use a CPLD/FPGA (Xilinx) to receive data from the parallel >>port (EPP-mode) of my PC. >> >>Is it a good style to react direct on the edges of the port signals (e. >>g. adress/data strobes) or would it be better to use a fast PLD-Clock to >>sample the port and then to evaluate the signals in a clocked logic? > >I think you didn't provide a critical chunk of information. What >are your goals/priorities? > >What are the relative importances of bandwidth, correctness, design time? >... > > >If you run all the async signals through the standard pair of FFs >then you (probably) won't have any problems from metastability. > >That will cost you 1.5 cycles (average) of round trip time which >turns into reduced bandwidth. > >If your top goal is max throughput, then you are almost forced >to use some kludgy logic driven off the strobes. Fortunately, >that is (probably) small enough that you can get it right. > >-- >These are my opinions, not necessarily my employeers. I hate spam. >Article: 30114
Hello All, Granted, you are the Brahma of software,the Vishnu of exemplary skills. You still need a Pundit to changeyour corporate destiny. So, you are the creator of pathbreaking software; the preserver of competitive capabilities. How come you still haven't been spotted by this Pundit based in the US for the past eleven years? Software Pundits Inc. is a leading provider of unique and innovative technology solutions for the top software companies in the US. The likes of CISCO, Lucent, Alcatel, Bay Networks, 3Com, Ascend, Nortel and Seimens. With a strong clientele in the niche areas of networking and telecom markets, and still expanding its market strengths Hello, My name is Vikram. I represent Software Pundits, Burlington, MA. If you are looking for a challenging position in a cutting edge technology, we might be the answer for you. We have projects in different parts of the country and we try to accomodate our pundits(Consultants)needs. I am very much interested in talking to you. My number is 781-229-6655 X 229. If interested, please send me a copy of your resume to speed up the process. Please call me or leave me your information to call you back at your convenience. Your time is very much appreciated Thanks Vikram Article on Pundits: http://masshightech.com/displayarticledetail.asp?art_id=46311Article: 30115
On 3/22/2001, 4:56:31 PM, Eric Smith <eric-no-spam-for-me@brouhaha.com> = wrote regarding Re: Looking for Processor Core info/advice: > Tom Dillon <tdillon@dilloneng.com> writes: > > We have worked with a open source 6502 core. We spent some time > > optimizing it for the Spartan family. > Can you make your Spartan optimized version available? Yes. As soon as we get it to a released state it will be on our web site= . Regards, Tom Dillon Dillon Engineering, Inc. http://www.dilloneng.comArticle: 30116
Hello All, I have a timing problem with a 41-bit accumulator in a XC40150XV device. Due to the long carry path in the accu, I can not reach the desired frequency. Acually I use the accu from the Xilinx Core Generator V1.5 Do someone know wether there is an alternative core module, which I can use. I know, that there is a Carry-Lookahead Adder for faster operation. Is it usefull to create an accumulator of this type of adder by hand, or is there a core module available? Christian MartinArticle: 30117
Here's a direct quote from the Xilinx data book: " All I/Os are 3-stated and pulled high by the IOB resistors during system programming. If a particular signal must remain low during this time, then a pulldown resistor may be added to the pin". The internal pullup is about 10K. -- Remove "-x-" from address to e-mailArticle: 30118
hello, a simple question, how many bits should be allocated to cover the natural speech signal dynamic ? I have never seen an implementation related to speech processing on FPGA. Is that because there is no need for Mhz speed ?Article: 30119
Article: 30120
tstArticle: 30121
catherina schrieb: > > hello, > > a simple question, how many bits should be allocated to cover the natural > speech signal dynamic ? Normal telefone uses 12 bits compressed to 8 bits (A-law, U-law). But ists also a matter of sampling frequency (8kHz for telephone) > > I have never seen an implementation related to speech processing on FPGA. > Is that because there is no need for Mhz speed ? Depends on how fast you speak (Maybe the rappers need MHz performance ;-)))) -- MFG FalkArticle: 30122
Klaus suggests-> >As for EVERY chip, EVERY unused should be tied to a defined Or perhaps, use a CPLD with internal programmable pullups on each pin.Article: 30123
Hi, The xilinx tool will do routing according to the timing constraint. For synthesis, there are many optimization options, and some can affect timing. For manual place and route, see the Floorplanner and FPGA Editor manual.Article: 30124
SNUG Boston 2000
September 10-12, 2001
Third Annual Synopsys Users Group
Boston Marriott Newton =
Newton, Massachusetts
CALL FOR PAPERS!
An Invitation to Contribute =
Share your experiences - the success of our users group depends on the
active participation of users who are willing to share their experiences
with others. If you have information on high-level or physical-design
methodology, or experiences with Synopsys tools that would be of
interest to other users, you are encouraged to present at SNUG Boston
2001. =
Abstracts will be accepted from March 7 to April 13, 2001. To submit
your abstract, contact the SNUG Boston Technical Committee at
snug_tech@synopsys.com. Please include the names of all authors, your
company, contact information (email, phone number, etc.) and the title
of your abstract.
*SNUG Author Deadlines*
March 12 - April 13, 2001 Call for Papers
April 27, 2001 Acceptance of Abstract
May 11 , 2001 In-Depth Outline due
June 8 , 2001 Draft Paper due
June 29 , 2001 Final Paper due for Print**
July 13, 2001 Draft Slides due
July 30 , 2001 Final Slides due for Print
September 10-12 , 2001 SNUG Boston 2001 Conference
For more information on authoring a SNUG paper, visit the SNUG Author's
kit: http://www.snug-universal.org/boston/akit.htm
Preliminary topics include: =
Physical Synthesis/Timing Closure
Describe design methodologies, timing-closure flow solutions, lessons
learned, or tips related to the use of Synopsys Design Planning products
including Chip Architect, FlexRoute, PrimeTime=AE, or Physical Compiler. =
Synthesis Strategies and Experiences
Users present ways to push Design Compiler? to achieve the best results
with respect to timing, area, power and/or runtime. These techniques
will include compile options, DC variables, and HDL coding styles for
synthesis. Users share experiences with automation techniques for
synthesis. Of special interest is exploration of changes and
enhancements to Design Compiler over the last few releases. We're also
interested in user papers that discuss experiences with Library
Compiler?. =
Deep Submicron/Large Designs/Low Power
This session concentrates on the unique challenges of submicron and
low-power design techniques that may involve large design, deep
submicron and high-clock speeds. Papers provide experience with
automating scripts for submicron design, special techniques for managing
wireloading, and non-linear delay modeling. =
Physical Analysis and Modeling for Deep Submicron SoC
This session is different than the Physical Synthesis session, listed
above, in that it invites structured-custom IC and ASIC designers to
share how Synopsys' Nanometer Analysis tools are implemented in their
flows. This session concentrates on recent and emerging challenges
related to mixed-signal design, and physical effects encountered while
using process technologies smaller than 0.18mm. In the race towards high
speed (GHz!) and low power (sub-volt!) designs, designers must have
solutions for accurate characterization, modeling, verification and
physical extraction. =
FPGA & PLD Synthesis =
Concentrating on the unique challenges of programmable logic, the tricks
and techniques used for designing and synthesizing FPGAs or PLDs will be
presented. Incremental synthesis, fanout control, and floorplanning
issues relative to FPGAs will also be part of this section. =
High-Level Verification/Simulation Techniques =
The higher the level a design is coded, the faster it can be simulated,
thus more verification can be done in the time-to-market window. But
there are many challenges to ensure that high-level verification also
meets your needs for properly testing the device. This session calls for
papers on behavioral system modeling approaches when given design
descriptions and performance goals. System-level strategies covering
design functional verification using HDLs and VCS? or VSS? are also
covered. Users share experiences in developing a test bed to verify
combined hardware and software systems for large complex designs. We're
also interested in user papers that discuss experiences with VERA=AE and
CoverMeter. Further discussion includes the verification/simulation
strategies to ensure design correctness. =
Higher Levels of Abstraction/Behavioral Synthesis =
User experiences with behavioral synthesis are explored in this session.
Topics include high-level design techniques, behavioral scheduling,
datapath synthesis, pipeline retiming, and integration with other ASIC
design and verification tools. Other topics include the methodology for
top-down design and high-level techniques for DSP design. =
Hardware/Software Co-design =
Authors are invited to submit original papers describing recent
experiences in designing and verifying embedded processor-based ASIC/SoC
systems. This includes the methodologies used, and tools required, to
handle tasks of verifying both the hardware and software before physical
prototypes are available for these systems. Authors are encouraged to
share their insights on the use of the Synopsys Eaglei=AE
hardware/software tools, Cyclone=AE, VSS, Flexmodels and VCS, and the
overall impact on the project. Explore system-design objectives: users
experience with system development, verification and integration. =
Makefiles Methodology/Configuration Management =
This popular session addresses the increased effort to automate and
extend the synthesis process through scripting. The session includes
case studies by users who have taken advantage of the power of Make,
Perl and even Tcl to drive synthesis iterations, to extend dc_shell, and
to manage complex designs. =
Design Reuse =
This session includes a practical methodology for design reuse and
Intellectual Property integration based on real-world experiences.
Issues and guidelines are explored. Does anybody really have a working
design reuse methodology in place? Let us know about it and how it
works. =
Design-For-Test (DFT)
This session focuses on strategies and real-world experiences
implementing a manufacturing test strategy (DFT) for large SoC-type
designs. Various SCAN and isolation techniques are explored in the
context of core-based designs. Techniques used to interface a DFT
solution (full or partial) with synthesis and power will be included. =
Module Compiler =
This session explores the use of Module Compiler? to achieve high
performance datapath designs, focusing on effective datapath synthesis
strategies, coding styles, and integration with other ASIC design tools.
User experiences with datapath synthesis are shared.
Static Timing Analysis
This session explores strategies and user experiences using a static
verification flow, concentrating on highlights and lowlights of static
timing analysis using PrimeTime. =
Formal Verification =
This session explores strategies and user experiences using a static
verification flow, concentrating on formal verification using
Formality=AE. =
------------------------
Brian Kane
Boston SNUG Technical Committee Chairperson
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