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
Rolf V. =?iso-8859-1?Q?=D8stergaard ?= wrote: > > For a given design, what can be done to reduce the power consumption of > a Xilinx 3020 device? I think in terms of special routing, unused nets > etc. > > Anyone got any ideas on how much I could expect to reduce the power > consumption using "after-design" techniques only? 10%, or? Without knowing the details of the design, its impossible to guess what kind of power reduction you might achieve. However there are some basic guidelines. First the easy and obvious things: 1) Use 3020L if your design doesn't need the speed (3020A if it does). 2) Set the input threshold to CMOS. 3) Use makebits TIE option. 4) Avoid input and longline pullups unless you know those lines will be primarily high. 5) Run at 3V. For more power savings: Where possible, implement ripple dividers rather than synchronous. If your design has few FF's running from the main clock, you could use ACLK (instead of GCLK) and constrain your clocked logic to one or a few vertical columns. Whereas the GCLK net covers the entire device, the ACLK net drives a horizontal line which selectively drives vertical clock lines. Columns that contain no FFs using ACLK will not be driven. This might save a little power in the ACLK net. You can also use direct clocks to small blocks of logic (if you place manually to guarantee clock skew in the correct direction). You can place longline flags on little clock nets (by little I mean small enough to fit on a longline). Non global clocks can be gated off when not used. Be careful! Makebits TIE will tie unused inputs to anything it can, including fast clocking outputs. After doing the TIE look at the report and see if any unused inputs were hung on fast clocking signals. If so, you might try a re-route or manual re-connection of the unused inputs to slower moving signals. (Makebits usually seems to do an OK job, so you might not be able to improve on it). This might improve things 5% +- 10% :) Have fun, ScottArticle: 3176
Charles Gardiner ("100421,3461"@compuserve.com) wrote:
: Does anyone know if Crosspoint Solutions Inc., a FPGA manufacturer based
: in milpitas CA, have a page on the WWW?
: Thanks in advance,
: Charles
All I found about Crosspoint Solutions on the WWW are some infos
about the CP20K series at the synopsys site:
http://www.synopsys.com/partnerships/svp/cross_fsvp.html
Markus Wannemacher
---
Markus Wannemacher, FernUniverit"at Hagen, Lehrgebiet Informationstechnik
D-58084 Hagen, Germany E-Mail: Markus.Wannemacher@FernUni-Hagen.De
phone +49 2331 987 4547 WWW: http://www.fernuni-hagen.de/IT/wm.html
fax +49 2331 987 375 talk: wm@tokyo.fernuni-hagen.de
Article: 3177Article: 3178
Let me try it again... Does anyone know where (or if) I can get ECL or PECL (preferrable) gate arrays or FPGAs? I'm trying to design a high-speed (100 MHz) crossbar switch and I need some way to build multiple multi-bit 16-1 MUXs. I've looked at Lattice's CPLDs (1K, 2K, and 3K families), but I have serious doubts about their performance. I'm laess concerned with the propagation delay than I am about the output edge rates. I assume I can skew the clock for the receiving latch to compensate for the prop. delay (assuming I can fix it in a range), but I can't very well have a 10 ns period if I have 5ns (or more) edge rates. Any suggestions? -- Mike Filippo filippo@rice.edu http://www-ce.rice.edu/ce/members/filippo/htdocs/filippo.htmlArticle: 3179
In article <3177B0B0.41C67EA6@rice.edu>, Michael Filippo <filippo@rice.edu> wrote: > Does anyone know where (or if) I can get ECL or PECL (preferrable) gate arrays > or FPGAs? I'm trying to design a high-speed (100 MHz) crossbar switch and I need > some way to build multiple multi-bit 16-1 MUXs. I suggest the Xilinx XC3164, XC3190 or XC3195. The newest -1, and the upcoming -09 speed grade are very fast, and the wide mux can be implemented on Longlines.Of course, everything gets much easier if you can tolerate one level of pipelining. The problem with ECL ( PECL is just ECL run on +5V ) is the small logic swing and its absolute level,slightly negative with respect to the positive supply rail. Peter Alfke, Xilinx ApplicationsArticle: 3180
One of the questions I heard at FCCM this year was "when, if ever, will an FPGA coprocessor ship on every PC motherboard?" Looking at current approaches to FPGA "coprocessors", the answer must be "not any time soon". Consider that today's power user's CPU (such as a 200 MHz Pentium Pro or a 400 MHz Alpha 21164A) *running out of L1 cache* issues peak three or four instructions per 2.5-5 ns clock. Also consider that the current "low latency high bandwidth" approach to FPGA coprocessor integration is to hang the FPGA on the PCI bus. In this scenario, the kinds of quasi-general purpose computing problems that an FPGA coprocessor can usefully assist with are quite limited. Issuing a write and then a read back operation to the FPGA could easily take 10 PCI bus cycles (300 ns), even assuming no PCI bus contention. In that time a Pentium Pro could issue as many as 180 instructions; the Alpha, 480 64-bit instructions. Future versions of such processors will soon be doing VIS- or MMX-like limited bytewise 8-way SIMD parallelism, and eventually superscalar versions of same, so next year's 200-400 MHz implementations could issue between 500 (*) and 4000 (**) hand coded packed byte operations before that single FPGA write/read completes! (*) forthcoming 200 MHz PPro with MMX: 60 clocks x 1 8-byte MMX insn/clock (**) hypothetical 400 MHz Alpha with each integer unit enhanced for bytewise SIMD: 120 clocks x 4 8-byte insns/clock ((At peak speeds like 4e8 clocks/s * 4 issue/clock * 8 byte ops/issue, e.g. 1.2e10 byte ops/s, you have to agree that superscalar micros with bytewise SIMD are going to displace many computational FPGA applications on PC and workstation platforms.)) So as long as FPGAs are attached on relatively glacially slow I/O buses -- including 32-bit 33 MHz PCI -- it seems unlikely they will be of much use in general purpose PC processor acceleration. Sure, for apFrom: jsgray@ix.netcom.com(Jan Gray) Newsgroups: comp.arch.fpga Subject: On FPGAs as PC coprocessors One of the questions I heard at FCCM this year was "when, if ever, will an FPGA coprocessor ship on every PC motherboard?" Looking at current approaches to FPGA "coprocessors", the answer must be "not any time soon". Consider that today's power user's CPU (such as a 200 MHz Pentium Pro or a 400 MHz Alpha 21164A) *running out of L1 cache* issues peak three or four instructions per 2.5-5 ns clock. Also consider that the current "low latency high bandwidth" approach to FPGA coprocessor integration is to hang the FPGA on the PCI bus. In this scenario, the kinds of quasi-general purpose computing problems that an FPGA coprocessor can usefully assist with are quite limited. Issuing a write and then a read back operation to the FPGA could easily take 10 PCI bus cycles (300 ns), even assuming no PCI bus contention. In that time a Pentium Pro could issue as many as 180 instructions; the Alpha, 480 64-bit instructions. Future versions of such processors will soon be doing VIS- or MMX-like limited bytewise 8-way SIMD parallelism, and eventually superscalar versions of same, so next year's 200-400 MHz implementations could issue between 500 (*) and 4000 (**) hand coded packed byte operations before that single FPGA write/read completes! (*) forthcoming 200 MHz PPro with MMX: 60 clocks x 1 8-byte MMX insn/clock (**) hypothetical 400 MHz Alpha with each integer unit enhanced for bytewise SIMD: 120 clocks x 4 8-byte insns/clock ((At peak speeds like 4e8 clocks/s * 4 issue/clock * 8 byte ops/issue, e.g. 1.2e10 byte ops/s, you have to agree that superscalar micros with bytewise SIMD are going to displace many computational FPGA applications on PC and workstation platforms.)) So as long as FPGAs are attached on relatively glacially slow I/O buses -- including 32-bit 33 MHz PCI -- it seems unlikely they will be of much use in general purpose PC processor acceleration. Sure, for applications such as cryptography, image and signal processing, they might be a win, given a semi-autonomous problem which either fits in the FPGA and local storage, or which can employ DMA to stream data into or through the FPGA without much CPU intervention or management. A decimal order of magnitude less access latency could be achieved if FPGA vendors provide a way to directly connect their parts to the Pentium Pro external bus, as a peer of the memory/bus controller. A custom, dedicated Pentium Pro interface would probably be required, since FPGA configurable logic would be slow and electrically incompatible. Of course, the PCI ASIC crowd has the same latency problems, but they don’t have aspirations of changing general purpose computing. (Acknowledgement: this posting is a spin-off of a discussion with Mark Shand.) Jan Gray Redmond, WAArticle: 3181
Jan Gray wrote: > > One of the questions I heard at FCCM this year was "when, if ever, will > an FPGA coprocessor ship on every PC motherboard?" > > Looking at current approaches to FPGA "coprocessors", the answer must > be "not any time soon". (snip) > Alpha, 480 64-bit instructions. Future versions of such processors will > soon be doing VIS- or MMX-like limited bytewise 8-way SIMD parallelism, > and eventually superscalar versions of same, so next year's 200-400 MHz > implementations could issue between 500 (*) and 4000 (**) hand coded > packed byte operations before that single FPGA write/read completes! > (snip) > > So as long as FPGAs are attached on relatively glacially slow I/O buses > -- including 32-bit 33 MHz PCI -- it seems unlikely they will be of > much use in general purpose PC processor acceleration. Sure, for > applications such as cryptography, image and signal processing, they > might be a win, given a semi-autonomous problem which either fits in > the FPGA and local storage, or which can employ DMA to stream data into > or through the FPGA without much CPU intervention or management. (snip) The FPGA belongs on the CPU die. Once there it gets "free" use of much of the CPU's facilities (registers, cache, memory interface etc). This should allow the FPGA to achieve performance improvements over the CPU for operations too wierd to be contemplated in the normal instruction set. For example, think how easy it would be to rewire an ALU to perform CRC. I expect (hope) to see FPGAs on low end embedded chips as well. What else are we going to use all that silicon for! Cheers, ScottArticle: 3182
In article <Dpwv0C.zq@bri.hp.com>, andrew@warp6.bri.hp.com (Andrew Hana) writes: :-> signal_of_type_time <= signal_of_type_integer * 1 ns; :-> :-> signal_of_type_integer <= signal_of_type_time / 1 ns; :-> :-> :->Note that the space between `1' and `ns' is important!! :-> :->Andrew Thanks, Andrew! -- vijayArticle: 3183
Joe Hass wrote: > > I'm looking for an FPGA or EPLD to replace about a dozen CMOS > MSI and SSI parts. I expect to need about 40 I/Os. A very John, the Xilinx XC3030L part may be what you need. The static consumption is <30uA and the part will run down to 3V. Very nice, tidy part. -Andrew MetcalfeArticle: 3184
David A Willmore wrote: > > I'm tyring to drop in a EEPROM for one of these chips and I > can't find out what bus this part uses. First, am I SOL to > start with or is this possible? I can speak IIC, uWire, and > from there, SPI, et al are easy. (it's a serial protocol, > how hard can it be?) > > I don't have any Xilinx documentation, so can anyone give me > a hand? > > Cheers, > David David, the parts have a proprietary, high speed interface. Xilinx sell serial proms for these parts and also have specifications on their web site. Contact www.xilinx.com. The parts can be cascaded to make lkarger ones and are somewhat denser than standard eeprom parts. -Andrew MetcalfeArticle: 3185
I need to convert circuit netlists from xnf format to blif format. If anybody has such a tool (or knows where it's available) please let me know. Any help in this matter will be greatly appreciated. Khalid (email: khalid@eecg.toronto.edu)Article: 3186
I need large benchmark circuits for my research work on Multi-FPGA Field-Programmable Systems (FPSs). I am looking for circuits that consist of > 3K 4-LUTs plus flip flops. Since large circuits are hard to find, I could use 'synthesizable' VHDL/Verilog ASIC models. I have access to Exemplar and Synopsys synthesis tools. If anybody has such models (or knows where they are available) please let me know. Thanks in advance for any information on this matter. Khalid (email: khalid@eecg.toronto.edu)Article: 3187
Scott Kroeger (scott.kroeger@mei.com) wrote: : The FPGA belongs on the CPU die. Once there it gets "free" use of much of the CPU's : facilities (registers, cache, memory interface etc). This should allow the FPGA to : achieve performance improvements over the CPU for operations too wierd to be : contemplated in the normal instruction set. For example, think how easy it would be to : rewire an ALU to perform CRC. Hmm. Ever thought about how such a chip is going to switch context ? (Similar problems confront programable instruction sets.) : I expect (hope) to see FPGAs on low end embedded chips as well. What else are we going : to use all that silicon for! Graeme Gill.Article: 3188
Dear Friends,
I am designing a FPGA whose main function is a multi-channel DMA
engine. As you know that DMA engines consists of many counters.
The counters I need are not simple "incrementers". They are loadable,
count enable and asynchronous clear.
we all know that VHDL synthesizer from both Synopsys and Exemplar
can infer counter from VHDL operators "+" and "-". But they also
provide users with the alternative of technology independant
component instantiation for counters, called design ware with
Synopsys and Modgen with Exemplar. By chance my company have
them both.
Because the synthesized result of my design is so large that I
can not help suspect that the inferring style I used (please see
the sample code below) is not efficient.
I'd like to try the component instanitiation alternative. But
I will have to modify my source code. At least I have to rebuild
the design hierarchy when I extract the counter out of the state
machine. So before I do this engineering, I ask you
for any opinion about these two approaches.
With component instantiation appraoch, will there be any improvement on
the control signal generating logic, like LOAD CONTROL and COUNT ENABLE?
Regards,
Felix K.C. CHEN
-- the sample code
process: counter(RESETZ, CLK, state, count, ...)
begin
if (RESETZ='0') then
count <= 0;
elsif (CLK'event and CLK='1') then
case state is
when S1 =>
if (condition) then
count <= load_value_1; -- load the counter
end if;
when S2 =>
if (condition) then
count <= 0; -- clear the counter, a load too
end if;
when S3 =>
if (condition) then
count <= count + "1"; -- count up
end if;
when S4 =>
if (condition) then
count <= count + "1"; -- count up
end if;
when S5 =>
if (condition) then
count <= count + "1"; -- count up
end if;
when others =>
null;
end case;
end if;
end process;
--
---------------------------------
Felix, Kuan-chih CHEN (³¯ «a §Ó)
Associate Project Manager
System Product Division
D-Link Co., Hsin-chu, Taiwan
Email: flxchen@diig.dlink.com.tw
Machines and tools are only as
good as the people who use it.
---------------------------------
--
---------------------------------
Felix, Kuan-chih CHEN (³¯ «a §Ó)
Associate Project Manager
System Product Division
D-Link Co., Hsin-chu, Taiwan
Email: flxchen@diig.dlink.com.tw
Machines and tools are only as
good as the people who use it.
---------------------------------
Article: 3189
Since FCCM'96 just ended, I thought it would be time to repost the
updated FAQ. This FAQ has now doubled in size from earlier versions.
===================================================================
Comp.arch.fpga FAQ - Frequently Asked Questions List
1. Is there an FAQ for comp.arch.fpga?
Answer: No.
2. But, but what about my {PLD|FPGA|ASIC|Tools|...}+ questions??????
Answer: Forget it.
===================================================================
For more information, consult the following lists.
http://www.super.org:8000/FPGA/
http://www.<fpga vendor of choice>.com/
Article: 3190David A Willmore wrote: > > I'm tyring to drop in a EEPROM for one of these chips and I > can't find out what bus this part uses. First, am I SOL to > start with or is this possible? I can speak IIC, uWire, and > from there, SPI, et al are easy. (it's a serial protocol, > how hard can it be?) > David, Atmel makes a pin compatable EEPROM device that emulates the industry standard 17Cxxx FPGA configuration OTP proms. The AT17Cxxx devices are (re)programmable and can be loaded in system via an industry standard 2-wire serial protocol. The parts are available in 17C65 and 17C128 densities now and 17c256 early Q3 (July) - thay are available in 8 pin dip, 20 pin plcc and 20 pin soic. For more information e-mail me - check out http:/www.atmel.com or use our Fax-on-Demand 1-800-29-ATMEL (request documents 602, 603, 604 and 663). Regards, Martin. ------------------------------------------------------------------------- | Martin Mason | Snr FPGA/17Cxxx Applications Engineer | | Atmel Corp. | (email - me) martin@atmel.com | | 2325, Orchard Parkway | (email - support) fpga@atmel.com | | San Jose | (Fax) + (408) 436 4300 | | CA 95131 USA | (Tele) + (408) 436 4178 | ------------------------------------------------------------------------- |Need Atmel Lit. stuff ? WWW.ATMEL.COM or FAX-on-DEMAND 1-800-29-ATMEL | -------------------------------------------------------------------------Article: 3191
Andrew Metcalfe wrote: > > David A Willmore wrote: > > > > I'm tyring to drop in a EEPROM for one of these chips and I > > can't find out what bus this part uses. First, am I SOL to > > start with or is this possible? > > > > I don't have any Xilinx documentation, so can anyone give me > > a hand? > David, the parts have a proprietary, high speed interface. Xilinx sell serial proms for these parts and also > have specifications on their web site. > > The parts can be cascaded to make lkarger ones and are somewhat denser than standard eeprom parts. Microchip also makes these devices. They are 37LV36, 37LV64, and 37LV128, with 36, 64, and 128K memory respectively. Contact Microchip at 602 786 7200, or web us at http://www.ultranet.com/biz/mchip for datasheets, contacts, etc. David -- The views expressed in this message are mine and are not necessarily representative of Microchip Technology Inc. While every effort has been made to ensure accuracy, please don't be upset if I got something wrong. Just tell me.Article: 3192
"S.C.Lim" <elscl@lboro.ac.uk> wrote:
>Hi,
>
>Our research group is looking into purchasing circuits boards that will
>take one to a few Xilinx 4020 FPGA chips. These Boards are to be used
>for circuit verifications by downloading design using Xilinx's Xact
>cable. If the board contains multiple chips, they should all be able to
>be programmed using a single xact cable link.
>
>If you have such kind of boards avaliable for sale or know anybody who
>supplies them, please mail me at S.C.Lim@lboro.uc.uk.
-- I believe that Aptix offers such a board that accomodates multiple
FPGA devices. You can contact them via E-mail at sales@aptix.com
and they have a Web site at http://www.aptix.com, though I didn't find
much there.
=====================================================================
_
/ /\/ Steven K. Knapp E-mail: stevek@xilinx.com
\ \ Corporate Applications Mgr. Tel: 1-408-879-5172
/ / Xilinx, Inc. Fax: 1-408-879-4442
\_\/\ 2100 Logic Drive Web: http://www.xilinx.com
San Jose, CA 95124
=====================================================================
Article: 3193peter@xilinx.com wrote: > The problem with ECL ( PECL is just ECL run on +5V ) is the small logic > swing and its absolute level,slightly negative with respect to the > positive supply rail. Errr... that would be "The advantage of ECL is the small, non saturated, logic swing and it's nearness to the very quiet ground". ECL is inherently way less noisy than TTL. The PROBLEM with ECL is it's huge power consumtion, low integration levels, and large price tag. At any rate, Xilinx 3100-9 seems to compete very well in the traditionally ECL speed domain. Although we haven't used it yet, we are considering using it (instead of ECL) to drive a 200MHz parallel optical link.Article: 3194
I-cube makes a crossbar switch that may be just what you're looking for.
It claims to have a 150MHz clocked data throughput. It's fairly
fast at re-configuring, although it will take several cycles to configure
if you're using a single chip to switch a wide data path.
http://www.icube.com/NavMap.html
Also, Tri-quint makes some very fast (>1GHz) switches in a GaAs technology.
Also, if you're interested, I have used an ORCA 2C12 to implement a fully
buffered 4x4 crossbar with the following specifications:
4 input ports switched on a per-cycle basis to 4 output ports
via an array of sixteen 24-bit wide FIFOs. Can sustain a throughput
of 40ns per word per port. Can be ganged for arbitrary word width or
cascaded for arbitrary switch size. Each port is controlled by a 2-bit
destination address and a valid bit. 24-bit data is transferred as 12 bits
each on the rising and falling edge of a 40ns clock.
This design could be doubled in speed using the new 4000E with clocked,
dual-port RAM Although you'd probably have to trim the size to about 8 bits
wide. ORCA has announced a clocked-RAM version of it's chips, due out at the
end of 96?
Article: 3195Hi there, Could someone shed some lights on how to achieve the following task or share some references i could followup? I have an image application written in C running on a Sun Sparc 10. After hearing something about FPGA, I was wondering whether it is possible to implement the most expensive function in FPGA to speed up my application. Since I am not a hardware person, it is unclear to me how to proceed. Once the FPGA is programmed, how will my application (or the operating system) know to branch to the FPGA to execute that expensive function instead of executing the function in the old way? Regards! - Jay Please email response to li@cs.columbia.edu and I will post a summary if there are enough interests.Article: 3196
This is a multi-part message in MIME format.
---------------------------------582738540344227893964226250
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
--
*****************************************************************
name: Michael Koch __ ____
depart: Zentrale Tools | \ |_______
company: IMS - \_________|
adress: Allmandring 30a ____
70569 Stuttgart | /\ /\
Germany | / \ / \
phone: xx49-711-685 5897 _|___/ _\/ _\
fax: xx49-711-685 5930
psi-mail: PSI%45711010172::KOCH
e-mail: koch@mikro.uni-stuttgart.de
*****************************************************************
---------------------------------582738540344227893964226250
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Article: 3197In article <4likv7$6vq@fnnews.fnal.gov>, husby@fnal.gov (Don Husby) wrote: >. > > Errr... that would be "The advantage of ECL is the small, non saturated, logic > swing and it's nearness to the very quiet ground". ECL is inherently way less > noisy than TTL. > > The PROBLEM with ECL is it's huge power consumtion, low integration levels, > and large price tag. > > At any rate, Xilinx 3100-9 seems to compete very well in the traditionally > ECL speed domain. Although we haven't used it yet, we are considering > using it (instead of ECL) to drive a 200MHz parallel optical link. I agree 100%. My original statement was not all-encompassing. It only addressed the aspect of interfacing between ECL and CMOS/TTL voltage levels. In the '70s, I used to explain how ECL creates far less noise than TTL does, and can drive terminated transmission lines which TTL and CMOS have great difficulties with. Even today, ECL is still the silicon technology of choice for the highest possible speed, if cost, size, and power don't matter. But CMOS, inspite of its large voltage swing, is getting faster "every day". Incidentally, we call it XC3100-09, to imply that is faster than XC3100-1. Read the 09 as 0.9. We just got faster than we anticipated when we created the numbering scheme. A nice problem to have. Peter Alfke Xilinx ApplicationsArticle: 3198
WEB (SOMSER BBS) This BBS is working in Spain and his address is http://www.somser.hnet.es (194.177.1.171) Now weare in a periored of a test and going to working every day from 20:00 to 6:00 GMT and from 10:00 to 13:00 GMT 20.000 files. 10 GB on disk. No CDROM 50 files news for day plus 200 areas. you are guest WEB (SOMSER BBS) Nuevo BBS que es un BBS, el primero que existe en España La dirección es: http://www.somser.hnet.es (194.177.1.171) Estamos en periodo de pruebas y está en funcionamiento desde las 22:00 a las 8:00 y desde las 12:00 a las 15.00 GMT Tenemos más de 20.000 en disco. 10GB sin CDROM 50 ficheros nuevos cada día. Más de 200 areas diferentes. Estais invitados, esperamos vuestra conexion.Article: 3199
In <4lh55q$f8k@mailman.xilinx> "Steve Knapp (Xilinx, Inc.)" <stevek> writes:
>"S.C.Lim" <elscl@lboro.ac.uk> wrote:
>>Hi,
>>
>>Our research group is looking into purchasing circuits boards that will
>>take one to a few Xilinx 4020 FPGA chips. These Boards are to be used
>>for circuit verifications by downloading design using Xilinx's Xact
>>cable. If the board contains multiple chips, they should all be able to
>>be programmed using a single xact cable link.
>>
>>If you have such kind of boards avaliable for sale or know anybody who
>>supplies them, please mail me at S.C.Lim@lboro.uc.uk.
>-- I believe that Aptix offers such a board that accomodates multiple
>FPGA devices. You can contact them via E-mail at sales@aptix.com
>and they have a Web site at http://www.aptix.com, though I didn't find
>much there.
check out the `Guess' project at Griffith University...
http://www.cit.gu.edu.au/~davida/guess.html
Guess makes use of an Aptix AP4 reconfigurable logic board. This contains
up to 16 Xilinx 4010 Field Programmable Gate Arrays, plus a number of Aptyx
switch chips. The switches make it possible to connect the pins of the
Xilinx parts together, and thus the board is totally reconfigurable.
this may be of some help...
robyn@cs.jcu.edu.au
" ' Maybe the knowledge is too great and maybe men are growing
too small,' Lee said. ' Maybe kneeling down to atoms, they're
becoming atom-sized in their souls. Maybe a specialist is only
a coward afraid to look out of his little cage. And think what
any specialist misses - the whole world over his fence. ' "
`East of Eden' by John Steinbeck.
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