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
fpga_toys@yahoo.com wrote:
> Allan Herriman wrote:
> > How about inferring BRAM for the sboxes? That's what many
> > implementations do. (I'm assuming the point of the exercise is to
> > compare the results of an implementation written in C with one written
> > in a more conventional HDL.)
>
> May seem strange, but the point wasn't to do a head to head comparison
> with other HDL's. I've some interest in crypto algorithms and have been
> on a search for "projects" which I can use as examples for the FpgaC
> release. The changes for technology mapping F5/F6 muxes has been on my
> list since last summer. AES and PCI examples just drove the point home
> it should be now, not later.
Well after a few hours of google I did find:
http://web.nps.navy.mil/~dcanrig/pub/sboxalg.c
Which after some serious hacking to reduce to define macros compiles
into just over a hundred luts or so, about a 15-20% savings over using
LUT rams and MUX's which would be a little over 128 LUT's per Sbox. I
suspect with some floorplanning that's faster than routing to use
BRAMs.
He has some HDL for the same algorithm, so when I'm done we can do a
head to head with XST.
Article: 98726
ywz.oct13@gmail.com wrote:
> the question is if i do not use variable for the 1st mtd; hw else can i
> do to get rid of that error.
> Is there a data type which i can use to make it work? or is there
> something which i overlooked?
The variable declaration must be inside
a process and must include a type.
See the testbench here:
http://home.comcast.net/~mike_treseler/
Article: 98727I got the listed number, say, 287.9Mhz and 72Mhz without put the multi RAM block into the data pipeline. That's why I don't understnd why the maximum frequency of clk isn't 1/3 of that of clkx3. Because in the whole synthesis, the usage of clk is to provide the input to DCM, which generates clkx3. Will it bother you too much if I put my code here? Thanks a lot.Article: 98728
laura_pretty05@yahoo.com.hk wrote: > My Altera FPGA boards is UP2 development kit-programmable logic for > education, with MAX EPM7128S &FLEX 10K EPF10K70 devices. Look at the board: there all pins of the FLEX_EXPAN_X pin rows are numbered. (Only the numbers for pin 1,2 and 59,60 are printed. This is the one row on the FLEX_EXPAN_X tables. The other row gives the internal pin number of the FDGA. If you make pin assignments, this internal pin number has to be used. RalfArticle: 98729
drmali2001@gmail.com wrote: > Does anybody have a suggestion on how to make the Spartan 3 starter > board a host on a LAN? You will need an ethernet adapter. The usual approach is to buy it as an add-on module or to use an old ISA ethernet card that is fully documented (vs one of the ones that itsn't). If you buy an add-on module all the protocol stuff may be taken care of for you, if you use the card you are going to have to have something on the FPGA capable or running what is basically "software" - in theory you might do it with logic, but in practice you will want a processor core in there to runa program. It is also possible to couple the ethernet signals fairly directly into the FPGA. See fpga4fun.com for an example - but again, you'll need to run protocol "software" somewhere in the device. > Also, how can we connect a USB camera device to the Spartan 3 starter > board? What hardware and software are required for this purpose? This is close to impossible. Implementing device side USB has several possibilities, but talking to a USB device is a far more complicated task because you must play the host function. You'll either need to add a USB host controller chip and software to run it, or make your own USB host controller in the FPGA. Both of your questions suggest that an FPGA, or at least an FPGA alone, may not be the right platform for your application. Have you considered a small controller board which might already include ethernet and USB host capabilities? What is the driving requirment for an FPGA architecture? Perhaps you can find a controller board that also has a user FPGA.Article: 98730
Hi all, I've got a VHDL design for Stratix Altera FPGA with several differents clocks (5). There's a clock generator which is configured by the user. So some parts in design can work at different clock frequency. How can I P&R under Quartus 5.1 for these differents clocks frequency. I have synthesize it with one clock. Do I synthesise with all the differents clocks (each design with each clocks) and test which design works better ? Or synthesize the module where the clock frequency can change and put the 5 architectures and select the good architecture for the desired clock used by "soft" VHDL ? Do you have ideas for these multi-clocks design ? Thanks.Article: 98731
Jim Granville wrote: > Hi Steve, > Good to hear from someone in Xilinx > > Steve Lass wrote: > >> First, let me try to address the reason why the ISE file is binary. A >> binary file >> allows us to manage concurrent reads/writes which is critical in >> making all >> the GUI applications work together. Binary files are faster and more >> efficient. >> Right now, there is a bug that is making the ISE file much larger than >> it needs to be. > > > So how can _that_ be faster and more efficent ? Did no one notice this ? > Such an error would have been spotted very quickly with ASCII files.... I will not claim to know all the details, but suffice it to say, if the ncd was ASCII, runtimes would be much longer. > > Also, a binary file can be more robust and requires less error > >> checking. > > > Yeeessss, only until said file gets corrupted, and then it becomes a > brick wall. Moving across tool versions also a risk area, and likely > to be a minefield.... > >> >> Access to the data in the ISE file is often important, so providing >> the capability >> to import and export is key. Check answer record 21067 for info on >> how to >> do this. Other than the GUI, the standard way to add info into the >> ISE file is >> Tcl, however, 8.2i will be required for this capability. > > > and recovery from a corrupted file is done the same way ? > > Seems to me if you must use binary for your convenience, that you > should also provide an easy ASCII import/export as well. I agree 100%. > > That way, users CAN archive a 100% ASCII project ( and some (most?) > WILL prefer to do this ), but they can also reap the benefits(?) of > binary files during re-iterations. > >> > When is 8,2i due for release ? June. Steve > > -jg >Article: 98732
Hello all, Are there any CSV formated files available with the pinout/names/etc information for xilinx FPGA parts? I've been using the BSDL files to get most of the information, but hand-coding 1k plus pins is both error- prone and tedious... Anyone know of a place that has this sort of information: A1,PWR,BANK0,... B13,TDI,BANK0,... B13,/FOOSIG,BANK0,... I don't mind multiple lines (one for each type of signal a pin can be configured for). If this is currently not available, would xilinx be able to make something like this available? I figure that the data is already available in some form, and would just need to be massaged some to be able to be put up for a download... Thanks for any info, -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 98733
Steve Lass wrote: > First, let me try to address the reason why the ISE file is binary. A > binary file > allows us to manage concurrent reads/writes which is critical in making all > the GUI applications work together. Binary files are faster and more > efficient. "Faster and more efficient?" We're using fairly fast machines and while I understand that parsing a text file might be inefficient, it's certainly not going to be the limiting factor when compiling, placing and routing. Being able to hand-edit and diff a configuration file, as well as adding comments to one, far outweighs any slight performance hits. > Right now, there is a bug that is making the ISE file much larger than > it needs > to be. Also, a binary file can be more robust and requires less error > checking. I would imagine that it's easier for the human being who needs to use the project file to spot and fix errors if the file is plain text. What sort of errors are we talking about? It's a binary file now, and as such can only be created and modified by your tools. If there's a problem in the file, it was probably caused by a tool bug. > Regarding keeping intermediate files in a separate directory, that is a > great > idea. We are planning on allowing you to specify the directory structure in > the future. If Xilinx has just now realized this is a great idea, then it's clear that you don't eat your own dog food. (Sorry for reusing this metaphor, but it's apropos.) > Regarding creating a batch file from the GUI, you can just cut and paste the > commands from the command_log file. > > We do not hate version control and have plans to allow for integration with > your source control systems. Subversion! Subversion! Subversion! -aArticle: 98734
Steve Lass wrote: > I will not claim to know all the details, but suffice it to say, if the > ncd was ASCII, runtimes would be much longer. The NCD is an intermediate file created by the tools and I wouldn't put it into my repository. The files that need to be in revision control are the HDL sources (obviously), constraint files (UCF remains, thankfully, plain text), and a Makefile or the project file. In other words, anything that's used to drive the build process. These files need to be plain text so they can be diffed. But by all means, intermediate files should be considered transient, and should be designed for efficiency. (And put into their own directory so they can be deleted easily.) Note that binaries and build results are not normally kept in the repository. However, when I tag a design build for release, I include the .mcs or .jed or whatever is used to actually program the part. Tags are (either by agreement or enforced) write-once then read-only and immutable. -aArticle: 98735
MM wrote: > Since I upgraded Xilinx tools to ISE8.1SP2 I can start PCAD2004 while ISE is > running... This is all on XP... > > Any ideas? You CAN start PCAD or you CAN'T start PCAD? If you CAN'T start PCAD, perhaps you don't have enough memory? -aArticle: 98736
Since I upgraded Xilinx tools to ISE8.1SP2 I can start PCAD2004 while ISE is running... This is all on XP... Any ideas? Thanks, /MikhailArticle: 98737
Fabio Rodrigues de la Rocha wrote: > Hello, > > I'm using ISE 8.1 and I'm facing problems to synthesize my VHDL > project. This project was simulated in modsim without problems. The > synthesis process is on-going for several minutes. I would like to know > which kind of problem in my project could cause such behavior? > Thank you in advance, > Fabio Hello, I forgot to mention that I'm using the ISE webpack. I wonder if the webpack has some kind of delay in the synthesis step comparing with the ISE Foundation. FabioArticle: 98738
"Andy Peters" <Bassman59a@yahoo.com> wrote in message news:1142450118.100247.244370@j33g2000cwa.googlegroups.com... > > You CAN start PCAD or you CAN'T start PCAD? > > If you CAN'T start PCAD, perhaps you don't have enough memory? Sorry, the finger slipped off the key... I woudn't have asked the question if I could start it :)Memory is hardly an issue. I have 1GB, and the thing used to work before. Also, closing other apps doesn't seem to help either... But I should admit I haven't tried all possible combinations... Thanks, /MikhailArticle: 98739
Steve Lass <lass@xilinx.com> wrote:
>First, let me try to address the reason why the ISE file is binary. A
>binary file allows us to manage concurrent reads/writes which is critical
>in making all the GUI applications work together. Binary files are faster
>and more efficient.
If IPC (InterProcess Communication) is needed, why not use shared memory or
pipes (local stream) ..?
And such files if they need to exist should be seperate from any kind of
source data.
>Right now, there is a bug that is making the ISE file much larger than
>it needs to be. Also, a binary file can be more robust and requires less
>error checking.
Binary files are hard to rescue for anyone without access to the sourcecode.
If specification on how to generate the bitstream(s) were available.
It would enable independent developers to write tools. And avoid the issues
discussed to some extent.
>Access to the data in the ISE file is often important, so providing the
>capability to import and export is key. Check answer record 21067 for
>info on how to do this. Other than the GUI, the standard way to add
>info into the ISE file is
>Tcl, however, 8.2i will be required for this capability.
>Regarding keeping intermediate files in a separate directory, that is a
>great idea. We are planning on allowing you to specify the directory
>structure in the future.
This would be very useful for complex setups.
>Regarding creating a batch file from the GUI, you can just cut and paste the
>commands from the command_log file.
A configuration file would be better. To allow version control, loading from
a previous setup - modify and save.
>We do not hate version control and have plans to allow for integration with
>your source control systems.
What will this integration mean in practice ?
(so that potential users may give input)
>We are listening and taking your input seriously.
Not all corporations listen to their customers, so it's nice to see a positive
approach.
Regards
/Peter
Article: 98740>What are you doing with the data you read from the memory ? >Could it be that they are not used so that the synthesis tool >optimizes the complete read path away ? > >Rgds >Andr=E9 Thanks that you're trying to help me. data is my 64-bit data bus. So as you could see below I'm puting some data on the data bus during write op using output buffer primitives and buffer the data bus using inpit buffers for read op. GEN_D3: for n in 0 to DDR_DATA_WIDTH-1 generate DQ_OBUFT : OBUFT_SSTL2_II port map ( I => d2sdr(n), T => tristate_q(n), O => data(n) ); DQ_IBUF : IBUF_SSTL2_II port map ( I => data(n), O => read_data(n) ); end generate GEN_D3; After I'm fetching low- and hi-words from the buffered data bus (read_data) on rising and falling edges of the clock. So it does not seem that the synthesis tool (XSE in my case) optimizes the complete read path away.Article: 98741
Tobias Weingartner wrote: > Are there any CSV formated files available with the pinout/names/etc > information for xilinx FPGA parts? I've been using the BSDL files to > get most of the information, but hand-coding 1k plus pins is both error- > prone and tedious... Anyone know of a place that has this sort of > information: [ ... snip ...] I'm not sure which Xilinx FPGA family that you are using. Here are locations to the Spartan-3 and Spartan-3E pinout files. They're in CSV format but be sure to read the readme file for additional details. Spartan-3 FPGAs: http://www.xilinx.com/bvdocs/publications/s3_pin.zip Spartan-3E FPGAs: http://www.xilinx.com/bvdocs/publications/s3e_pin.zip --------------------------------- Steven K. Knapp Applications Manager, Xilinx Inc. General Products Division Spartan-3/-3E FPGAs http://www.xilinx.com/spartan3e --------------------------------- The Spartan(tm)-3 Generation: The World's Lowest-Cost FPGAs.Article: 98742
Tobias Weingartner <weingart@cs.ualberta.ca> wrote: > Hello all, > Are there any CSV formated files available with the pinout/names/etc > information for xilinx FPGA parts? I've been using the BSDL files to > get most of the information, but hand-coding 1k plus pins is both error- > prone and tedious... Anyone know of a place that has this sort of > information: > A1,PWR,BANK0,... > B13,TDI,BANK0,... > B13,/FOOSIG,BANK0,... > I don't mind multiple lines (one for each type of signal a pin can be > configured for). If this is currently not available, would xilinx be > able to make something like this available? I figure that the data is > already available in some form, and would just need to be massaged some > to be able to be put up for a download... > Thanks for any info, Look for "Spartan-3 FPGA Pinout Descriptions" under Support for the family required. -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 98743
On Wed, 15 Mar 2006 11:14:28 -0800, Andy Peters wrote: > Steve Lass wrote: > >> I will not claim to know all the details, but suffice it to say, if the >> ncd was ASCII, runtimes would be much longer. > > The NCD is an intermediate file created by the tools and I wouldn't put > it into my repository. > > The files that need to be in revision control are the HDL sources > (obviously), constraint files (UCF remains, thankfully, plain text), and > a Makefile or the project file. In other words, anything that's used to > drive the build process. These files need to be plain text so they can > be diffed. But by all means, intermediate files should be considered > transient, and should be designed for efficiency. (And put into their > own directory so they can be deleted easily.) > > Note that binaries and build results are not normally kept in the > repository. However, when I tag a design build for release, I include > the .mcs or .jed or whatever is used to actually program the part. Tags > are (either by agreement or enforced) write-once then read-only and > immutable. > > -a The 8.1 tools can still import the old .npl format, the problem is that they can't save a new project in the .npl format. If Xilinx would add an export to npl command I think everyone will be happy. There was no good reason to switch from an ascii file to a binary file because an ascii file is so much more flexible. The argument that there is a performance advantage to a binary project file is ridiculous, translating an ascii file to an internal format takes milliseconds. The advantages of an ascii file are huge. First off you can read it and see how everything is set. Secondly you can edit it, it's much easier to do things in Emacs then it is in any GUI. And finally you can generate them. I never generate ISE projects by hand. I do all of my designs with HDLmaker, http://www.polybus.com/hdlmaker/users_guide/, which generates scripts and make files for simulation (NCVerilog, ModelSim, VCS), scripts and project files for synthesis (XST, Synplify, and Precision), and project files for ISE (.npl) and for Quartus (.qpf and .qsf). Although I almost never use the GUI, the one exception is in the lab when running ChipScope, I have customers who are more comfortable with a GUI particularly those who are still using Windows. For them I need to be able to generate a project file. Fortunately .npl format still works but if Xilinx ever drops support for the .npl format it won't be possible to generate a project file anymore.Article: 98744
Andy Peters wrote: > These files need to be plain text so > they can be diffed. Not necessarily. Xilinx could also provide a diff tool for the file format. Of course with a FOSS source license so that you can create a plugin for the versioning system of your choice. But I agree that ASCII is the simpler way to go. Steve Lass wrote: > A binary file allows us to manage concurrent reads/writes which is > critical in making all the GUI applications work together. Maybe you should split into multiple files. Your comments sounds as if the tools interact a lot via the project files. That is not something that belongs into a repository. What is needed there is mainly information about what files belong to the project and the project settings selected by the user. This is only a few hundred bytes. A lot of that information is ascii strings anyway. Actually I do not see why concurrent read writes are easier in binary files than in ascii files. Fixed field width vs. dynamic field width makes a difference. But you can have fixed width ascii files as well. Kolja SulimmaArticle: 98745
metal wrote: > I've done qfp's, but never had a need to do BGA's; but am now > expecting it to come up soon; so I appreciate you taking the time to > give that detailed process-description. I'd second that :) That was an interesting post. JeremyArticle: 98746
Fabio Rodrigues de la Rocha wrote: > Fabio Rodrigues de la Rocha wrote: > >> Hello, >> >> I'm using ISE 8.1 and I'm facing problems to synthesize my VHDL >> project. This project was simulated in modsim without problems. The >> synthesis process is on-going for several minutes. I would like to >> know which kind of problem in my project could cause such behavior? >> Thank you in advance, >> Fabio > > > Hello, > > I forgot to mention that I'm using the ISE webpack. I wonder if the > webpack has some kind of delay in the synthesis step comparing with the > ISE Foundation. No. The only difference between WebPACK and Foundation is device support. If XST is taking too long, feel free to submit a webcase and we'll take a look at it. Steve > > FabioArticle: 98747
On Wed, 15 Mar 2006 12:47:45 +0100, Rene Tschaggelar <none@none.net> wrote: >metal wrote: > >> Does anyone know of freeware spread-spectrum cores; particularly DS ? >> >> I'm looking for something which basically takes serial-data in and >> drives a GMK modulator at the output. Small, configurable, and with a >> simple DS scheme that doesn't have stringent acquisition needs. >> >> Issues are cost (complexity) and power; not security or speed (1mb/sec >> is fine). >> >> ps; any suggestion of 'standard parts' would be appreciated as >> well... >> >> thanks much > >Yes, there is a spread spectrum clock generator : >The LTC6902 5kHz to 20MHz multiphase capable. >For 2.90$. > >Rene hello Rene, thanks for your reply....but that sounds like a motherboard/cpu clock generator....not an SS radio chip. I am looking for cores or IC's which generate or modulate an RF signal. ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 98748
On Mon, 13 Mar 2006 07:20:31 +1300, Jim Granville <no.spam@designtools.co.nz> wrote: >Eric Smith wrote: > >> metal <nospam@spaam.edu> writes: >> >>> agree 100% >>> >>> it is the FPGA makers who are awkward; not the supply voltage. >>> >>> imho, fpga makers have dropped the ball, by totally ignoring the >>> enormous markets of various mixed-signal products; where 5v is VERY >>> common...along with generally noisy environments. >>> >>> I have always been amazed that not a single fpga-maker has made a line >>> of small-to-medium sized parts targeted not for blazing speed and >>> monster computing functions; but rather, for 5v I/O, all >>> Schmitt-trigger inputs, and very low cost. >>> >>> Imho, such a line would sell like hotcakes. Instead of hard-silicon >>> MAC's and such, where are the hard-silicon counter/timer modules, etc. >>> ?? >>> >>> I'd love to be able to buy a $5 part with 64 or 128 flops, and a hard >>> block of 8 timer/counters (hardly any chip area in modern silicon). >>> I've got =dozens= of apps for such a part. >>> >>> In any case, it's not the users who are mistaken about 5v; but rather, >>> the fpga-makers...who are ignoring the -reality- of -ongoing demand- >>> for it, instead of embracing it via a profitable targeted >>> product-line. >>> >>> just m-h-o as one of those pesky 5v users, of course... <g> > > >> >> A good MAC is fairly complicated, and as a soft MAC takes up lots of >> FPGA real estate, so it makes sense to stick one or two on the die of >> larger parts since it's then a fairly small percentage of the part. Not >> all the customers benefit, but some benefit a lot, and the others aren't >> penalized much. >> >> But counter-timers don't take up much room in an FPGA, so if you go to >> hardwiring those, you don't gain anything, and you lose tons of flexibility. >> Inevitably the features of the hardwired timer-counter would never be quite >> what you need for any given design. There would be only a small penalty, >> but it would be borne by all customers. Very few would get any advantage, >> and the advantage would be very modest. The cost/benefit analysis is >> much worse than with a MAC. >> >> If you want them to build some other hardwired logic into their FPGAs, you'll >> need to come up with a *much* better example than that. > > How about speed ? > > However, what metal was talking about, is a CPLD, not a FPGA. > >He is looking at the bottom end of the spectrum. >Some vendors currently come close : > >Atmel have low power, 5V parts in the ATF150x series. >Xilinx have the CoolRunner2, with the larger ones having a divider >chain, but not 5V. > >but right now, no one has the twin features of 5V Drive and Schmitt Pins. > >-jg > thanks Jim, that's exactly correct. I think Eric missed my point; which was specifically about the industrial/mixed-signal market; relative to the ongoing discussion of 5v i/o. Eric, I also believe you're mistaken about timer/counters; which have been hardwired into virtually -every- microcontroller made since the dawn of time; and nobody has had a problem using them in their fixed configurations. And I think at least one or two engineers have found them to be an "advantage"... LOL Perhaps you are focused on "computing"; judging by your comment that a MAC is more "useful" than a timer-counter. I couldn't care less whether my chip has a MAC....I don't -do- massive high-speed computing with my logic. Sounds like you do....but there are many many MANY uses for logic in the world, besides running embedded linux... ps; jim is right, I had specifically mentioned a 64-128 cell part; not a 3,000 register fpga. In which case, using cells for timers eats up a $10 chip REAL fast....while the silicon cost for a few 16b hard counters on a chip like that would be near-zero... ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---Article: 98749
On Mon, 13 Mar 2006 08:28:12 +0100, Kolja Sulimma <news@sulimma.de> wrote: >metal schrieb: >>>Why ? - noise immunity, ease of interface : have you ever tried to >>>find a power MOSFET that can be driven from 3.3V ? > >But the additional circuitry required to drive the MOSFET from an FPGA >is so small and cheap compared to the power MOSFET that I do not see the >economic advantage of selecting the FPGA based on that criterion. >A driver in sc70-package will be hardly noticed in the layout next to a >power MOSFET and the additional cost of 3ct doesn't matter at all. > >Inputs can be made 5V tolerant by a single resistors. These are >available at virtually no cost in 0.5mm pitch 8x arrays. > >Schmitt-Triggers are only a little more cumbersome: You need a second >FPGA-pin and a single resistor. Or no additional pin and a driver in >sc70-package. > >If you dot need more than a few dozens of these pins the cost will not >even add up to the price difference between a 3.3V and 5V part. And you >are much more flexibale because you can also support all the other >voltages that show up in the control industry: 5.2V (PECL), 6V, 6.2V, >12V, 15V, 24V.... > >Kolja Sulimma Kolja, please tell me where to get these FET-drivers for 3 cents...<g> Further, you have just -doubled- my parts count per function. I'm mad now... <grin> Also, I think you are wrong to blithely dismiss a -doubling- of i/o pin usage. Perhaps you are thinking in terms of 500-pin chips; but most of these apps use 40-128 pin chips. I/O is -expensive-. And I'm not sure how you see that technique achieving the same noise-immunity of a true 5v schmitt input anyway. And how do you use the pins bidirectionally? It just doesn't sound like a practical thing to me. Your technique of using resistors on the inputs, and feeding them with 5-24v signals is not a good technique, imho. It can cause a lot of current flow; and can actually float the fpga supply up out of spec under certain conditions. Every additional connection is a reliability issue...and every additional part carries a penalty in board-space, assembly-cost, and inventory-costs. Basically, using a 5v logic chip is just far easier, cleaner, more robust; and it's almost always worth the price-difference in order to reduce parts-count, and size. ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! >100,000 Newsgroups ---= East/West-Coast Server Farms - Total Privacy via Encryption =---
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