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
On 25 Jan 2006 21:35:10 +0100, antonio bergnoli <bergnoli@pd.infn.it> wrote: >allanherriman@hotmail.com ha scritto: >> Dave Feustel wrote: >> >>>I am no longer running Windows. Are there any open source programs >>>for programming fpgas? I know about Icarus, but I don't think that >>>program actually programs chips. >> >> >> I know of no good (*) open source simulators or synthesis tools. >> You can forget about the back end tools - there are compelling reasons >> for these to be completely closed. > >think to consider ghdl for vhdl simulation. I use it dayly and it is >capable to compile the Xilinx unisim library and almost all simprim >(except dsp48) so you can use it for rtl design and even for post >synthesys and post map simulation. I have heard people say good things about GHDL, but it's a single language tool. It won't handle any of my Verilog code, and no free tool (of which I am aware) will handle mixed languge designs. Regards, AllanArticle: 95751
In sci.electronics.design Mike Yarwood <mpyarwood@btopenworld.com> wrote: > > "Davy" <zhushenli@gmail.com> wrote in message > news:1137726871.700967.266740@o13g2000cwo.googlegroups.com... >> Hi all, >> >> I am new to demodulation and FEC. >> >> How can I get each bit's soft-probability from the constellation? >> For example, the modulation method is 16QAM, How can I get >> P(bit1=0),P(bit2=0),P(bit3=0),P(bit4=0) from a symbol? <snip> "bayes theorem"+"soft input" should work. > > You could also look at page 72 to 74 of this for a very direct method; > http://4more.av.it.pt/docs/D4.4.pdf If you get any signal, is there a nice way of back propagating to get optimum probabilities?Article: 95752
On 25 Jan 2006 12:02:29 -0800, "Jeff" <jeff.ward@gmail.com> wrote: >Hi John, > >I guess it's a matter of tradeoffs: $9 cheaper, but the S3 board has >more switches, a VGA output, a serial output, and an PS/2 port. On a recent project I found the 8 big (i.e. not DIP) switches on the S3 starter board REALLY useful, for selecting 1 of n different sets of debug outputs to a set of pins connected to the scope, and also to select one of n signals to display on the seven-seg display. Saves a lot of recompiles to add debug functions to look at different internal states if you can have them all available at the flick of a switch...!Article: 95753
fpga_toys@yahoo.com wrote: > I should probably note that Xilinx leaches a hell of a lot of value off > open source by using Linux as a host platform for it's tools, GCC as > the main production compiler for PPC core software, GNU for the > libraries for PPC, and Linux in several forms as host operating systems > for it's product offerings. > > It's probably worth writing Austin, Peter, and the other regular usenet > posters from Xilinx and making it clear just how much Xilinx benefits > from open source, the Xilinx market created by open source, and the > developers which frequently volunteer their time supporting Xilinx open > source use. > I take umbrage to your assertion that Xilinx is a leach and doesn't contribute back to the open source communities. Xilinx has been a contributing Corporate Patron of Free Software Foundation for many years now https://www.fsf.org/donate/patron/index_html funding many open source projects through the FSF with our donations. In addition we funded, supported and developed the Virtex-II Pro and Virtex-4 PowerPC405 ports that are the parent post of this thread and then push for their release into the official Linux 2.4.x and 2.6.x PowerPC trees so that everyone will have access to them easily. Ed McGettigan -- Xilinx Inc.Article: 95754
"Nitesh" <nitesh.guinde@gmail.com> wrote in message news:1138228419.957001.253480@z14g2000cwz.googlegroups.com... > Let me rephrase my question. > I have a fpga pci card with a dual pci bridge between the virtex II pro > and the pci bus of the host computer to which this card is connected. > The processor bus connects fpga with the bridge. > The dual pci bridge from tundra is dma capable. I have changed a core > (A processor bus master/slave) in the fpga to provide this dma > functionality. My aim is to transfer data from the fpga to the host > memory. I can provide the source address which is an address of a > location inside the fpga. Now my problem is that what should be the > destination address ? I have to send the data to the host RAM. Since > this address has to be pre decided before a transaction can begin how > can I get this value in the fpga so that I can program this from the > fpga. As stated before, the software on the host computer side needs to allocate memory space for the DMA destination. If the address and size can be fixed, your task is simple. It's more likely that the memory allocation will be dynamic and the host system has to communicate the FPGA in some fashion what the address range is for the DMA. Then and only then should the FPGA do its DMA. You can't move data to the host memory, after all, if the host is executing out of the memory you're writing to. If the host allocates it, the memory won't be used by the operating system or other devices.Article: 95755
fpga_toys@yahoo.com wrote: > I should probably note that Xilinx leaches a hell of a lot of value off > open source by using Linux as a host platform for it's tools, GCC as > the main production compiler for PPC core software, GNU for the > libraries for PPC, and Linux in several forms as host operating systems > for it's product offerings. > > It's probably worth writing Austin, Peter, and the other regular usenet > posters from Xilinx and making it clear just how much Xilinx benefits > from open source, the Xilinx market created by open source, and the > developers which frequently volunteer their time supporting Xilinx open > source use. > I take umbrage to your assertion that Xilinx is a leach and doesn't contribute back to the open source communities. Xilinx has been a contributing Corporate Patron of Free Software Foundation for many years now https://www.fsf.org/donate/patron/index_html funding many open source projects through the FSF with our donations. In addition we funded, supported and developed the Virtex-II Pro and Virtex-4 PowerPC405 ports that are the parent post of this thread and then push for their release into the official Linux 2.4.x and 2.6.x PowerPC trees so that everyone will have access to them easily. (Double post as the same comments where in another thread) Ed McGettigan -- Xilinx Inc.Article: 95756
fpga_toys@yahoo.com wrote: > Ray Andraka wrote: > >>BTW, the efficiency I was referring to on a uP is the utilization of the >>gates. Each instruction only uses a fraction of the logic in the uP; >>the rest is idled. I only brought that up in an attempt to level the >>field between the two. You really can't compare them. > This has been an interesting side-thread, but more from pushing the ceiling aspects, than whether 100% fabric at 100% speed is really possible, or not. > I did understand, and objected to this assertion. I'm half EE and half > computer science, and have worked both fields for 35 years. > > The way to get a huge bang for the buck with RC is to generate > hundreds, or thousands of mini state machine driven dedicated function > processors, much is the same way as you build pipelines of dedicated > function processing elements for DSP on FPGAs with distributed > arithmetic. You drop them into the fpga as a mesh fabric for 2D > algorithms, as a pipeline for 1D algorithms, and even as a flattened 3D > mesh if necessary. Highly regular connectivity, short routing, and > locally optimal placement are all not just possible, but highly likely, > with the right tools. Specialized array processing applications are > likely targets. Most of the demos I've worked with fill an fpga, and > have a VERY small number of idle LUTs. So that indicates that 100% fabric usage is not an impossible task ? > It's been painful to get par to > do the right thing, thus my frustration with the existing tools, and a > growing understanding of why they are what they are, and why that is > wrong for where we are heading and how our usage fundamentially is > different that the current tool chains design strategies. Most Software suppliers I work with, will strive to improve their tools, if given specific and clear examples of : a) What detail is sub-optimal, and why b) How that can be improved, without impact on other users/usage. Remember, those that write these tools, do NOT actually use them, so feedback from users that 'push' the tools, is very important. A user might think their application area is too small, or too specialised, but tool flow improvements can ripple across many application areas, and also raise the average practical frequencies- and that can get the vendors very interested. It seems one 'stub' of an opensource project could be to handle this Xilinx-User interface. Rather than try and rebuild their tools from the ground-up, why not work with them to improve the tools ? Yes, this is done a small detail at a time. Anyone doing an RC-FPGA array, should have strong thermal management, even up to the copper heat pipe schemes of the extreme gamers ! :) -jgArticle: 95757
fpga_toys@yahoo.com wrote: > Phil Tomson wrote: > >>But then someone brought up the fate of JHDLBits: apparently the prjoject was >>squashed by Xilinx. Does anyone have any details about what happened? If >>someone succeeded in developing an open source ecosystem of tools built around >>XDL, would that project also suffer the same fate? (It would be nice to know >>before investing much time and effort in developing tools around XDL) > > > The status from the team a year ago was: > > "we are still trying to figure out a schedule with Xilinx > corporation on the release of the project. Xilinx funded the > research and > some parts of the project contained proprietary information, so > we have been > trying to come to an agreement. We are still hoping for a > release sometime > soon." > > I've asked a several Xilinx staff about it both on and off the record. > On the record, > no reply. Off the record, "it will never happen". The fine print in > Xilinx tools licenses > is a claim preventing reverse engineering of the chip layouts and > databases, even > though this is clearly visible to the user from several tools ranging > from the fpga > editor to the bit stream generator. From what I have been told, any > compilation of > data base details into an open source equivalent P&R to bitstream tool > as was done > by the JHDLBits team will result in a C&D Order from Xilinx. > > So, Xilinx let this team proceed, gained a lot of publicity from it as > marketing > collaterial, and then dashed the teams hopes of taking it open source. > I doubt > the team would have partnered with Xilinx had the outcome been clearly > stated > up front. They put a lot of energy into the project, then were told to > shutup and > walk away. > > Much of what the FpgaC project needs to support compile, load, and go > for Xilinx > product is trapped in this project, with a clear warning from Xilinx to > stay clear. > The likely outcome is to focus on other vendors which are more willing > to allow > open source investment in RC technologies which support their products. Keep in mind that some of this 'paranoia' is not driven by Xilinx, but by their more secretive customers. If they see too much ability to reverse-spin the FGA designs, they imagine their secret sauce is more at risk - or that someone may be able to virus attack, or time-bomb, a FPGA, for example. So they may not be able to give the lowest info, but it should be possible to create some middle format, that is able to be swallowed by P&R at great speed ( because it has very little to do ). That format would also be portable, so you are freed from tracking the device and even vendor increments. -jgArticle: 95758
So, I have a question regarding the assertion that the datasheet LUT count is "important information." Why? What is the real-world utility of that number? Do some people know up-front how many LUTs their design is gonna use, and then they just need an accurate LUT count to pick the best FPGA? The problem with programmable logic datasheets is that it's almost impossible to put any real, relevant information on them. A FEW things - number of SerDes transceivers, maybe user pin count, marginally available block RAM... are kinda useful, but for everything else, don't you really need to just do the design and see what device the tools tell you to use? I've written a couple of articles on/around this topic. My favorite was: http://www.fpgajournal.com/articles/20040706_tango.htm and people also seem to like: http://www.fpgajournal.com/articles_2005/20050510_worldsbest.htm KevinArticle: 95759
John Adair wrote: > You might want to have a look at our product Raggedstone1. It has the much > larger XC3S400-4FG456C part fitted. Programming cable is included and card > can be used in a PCI slot or stand-alone with the optional PCI I/O Header. > Details here http://www.enterpoint.co.uk/moelbryn/raggedstone1.html. As a learner and experimenter I like the look of that board, but how much does the Xilinx PCI core for the Spartan 3 cost? Paul.Article: 95760
In article <43d81e83@clear.net.nz>, Jim Granville <no.spam@designtools.co.nz> wrote: >fpga_toys@yahoo.com wrote: >> Phil Tomson wrote: >> >>>But then someone brought up the fate of JHDLBits: apparently the prjoject was >>>squashed by Xilinx. Does anyone have any details about what happened? If >>>someone succeeded in developing an open source ecosystem of tools built around >>>XDL, would that project also suffer the same fate? (It would be nice to know >>>before investing much time and effort in developing tools around XDL) >> >> >> The status from the team a year ago was: >> >> "we are still trying to figure out a schedule with Xilinx >> corporation on the release of the project. Xilinx funded the >> research and >> some parts of the project contained proprietary information, so >> we have been >> trying to come to an agreement. We are still hoping for a >> release sometime >> soon." >> >> I've asked a several Xilinx staff about it both on and off the record. >> On the record, >> no reply. Off the record, "it will never happen". The fine print in >> Xilinx tools licenses >> is a claim preventing reverse engineering of the chip layouts and >> databases, even >> though this is clearly visible to the user from several tools ranging >> from the fpga >> editor to the bit stream generator. From what I have been told, any >> compilation of >> data base details into an open source equivalent P&R to bitstream tool >> as was done >> by the JHDLBits team will result in a C&D Order from Xilinx. >> >> So, Xilinx let this team proceed, gained a lot of publicity from it as >> marketing >> collaterial, and then dashed the teams hopes of taking it open source. >> I doubt >> the team would have partnered with Xilinx had the outcome been clearly >> stated >> up front. They put a lot of energy into the project, then were told to >> shutup and >> walk away. >> >> Much of what the FpgaC project needs to support compile, load, and go >> for Xilinx >> product is trapped in this project, with a clear warning from Xilinx to >> stay clear. >> The likely outcome is to focus on other vendors which are more willing >> to allow >> open source investment in RC technologies which support their products. > > Keep in mind that some of this 'paranoia' is not driven by Xilinx, but >by their more secretive customers. > If they see too much ability to reverse-spin the FGA designs, they >imagine their secret sauce is more at risk - or that someone may be >able to virus attack, or time-bomb, a FPGA, for example. Was JHDLBits reverse engineering the bitstream itself? > > So they may not be able to give the lowest info, but it should be >possible to create some middle format, that is able to be swallowed >by P&R at great speed ( because it has very little to do ). > That format would also be portable, so you are freed from tracking >the device and even vendor increments. Isn't that sort of what XDL is supposed to be? If your theory is correct then Xilinx wouldn't have a problem with XDL based tools. It's really hard to guess what Xilinx's reaction would be to an open source XDL tool suite, but with the JDHLBits experience fresh in people's minds it's understandable why people are hesitant to invest much effort in such tools. PhilArticle: 95761
Thanks for taking the time to check; I should have been more specific. The http://vol.verilog.com/ location is accessible, but the registration process is broken. It appears to be a cgi-bin issue. I have the same problem at work and at home. The URL hosted at a university is also accessible, and requires no registration, but when you go to the table of contents, none of the links there to the various chapters appear to work. I also tried this from work and home, both times the browswer reports that there are errors on the page. I'm still searching for something that works... Any leads are appreciated! Eric "John_H" <johnhandwork@mail.com> wrote in message news:4bvBf.623$qg.495@news01.roc.ny... > "Eric Crabill" <eric.crabill@xilinx.com> wrote in message > news:dr5sd6$ng22@cliff.xsj.xilinx.com... > > Hi, > > > > I'm looking for a functional URL that hosts the Verilog tutorial by John > > Sanguinetti. Neither of these seem to work: > > <snip> > > It may just be your network that's having troubles. Access to your > company's web pages from outside is a bit dodgey right now. > >Article: 95762
Jim Granville wrote: > So they may not be able to give the lowest info, but it should be > possible to create some middle format, that is able to be swallowed > by P&R at great speed ( because it has very little to do ). > That format would also be portable, so you are freed from tracking > the device and even vendor increments. > > -jg > > > It is called XDL. XDL is basically a readable ascii text version of the NCDs, and there are converters to and from NCD. It gives you hooks into the tool flow anywhere between translate's output and bitgen's input. Seems those who keep yelling for open bit streams aren't bothering to look at what is available, or try working with pieces. They all seem to want full open bitstream without even understanding what all it entails to be able to successfully work with it. You could do pretty much everything they seem to be looking to do within the existing XDL framework, and it gives the ability to use parts of the existing tools so you don't have to develop the entire tool chain from soup to nuts. Pick a piece of it and plug it into the existing tools.Article: 95763
Dear all, I've just found that Xilinx has officially addressed the fifo16 data corruption issue in this Answer #22462: http://www.xilinx.com/xlnx/xil_ans_display.jsp?iCountryID=1&iLanguageID=1&getPagePath=22462&BV_SessionID=@@@@1727406672.1138227824@@@@&BV_EngineID=ccccaddgleemilecefeceihdffhdfkf.0 where a workaround both for the synchronous and the asynchronous case is described. Kudos to Xilinx for once! -dudesinmexicoArticle: 95764
Hello guys (Peter don't flame me please), so this is very off topic but we seem to have a connection to a current news story according to a blogger concerning the Entwistle murder case in Hopkinton MA. I was following/googling the current story looking for details on his supposed web scam activites and this blooger makes the connection to our little neighbourhood. http://www.huffcrimeblog.com/ www.embeddednt.com. The blooger doesn't know what the ENT website is about but if this is real IP on their site then it looks interesting to me. Wierder & wierder. transputer guyArticle: 95765
Kevin, If I have learned anything from this thread, it is that there are folks for which the "actual number" is a religious matter. Once the "actual number" is revealed in its glory, there are even a further class of folks who still doubt: there is still some nefarious untruth, or hidden secret that is intentionally not being revealed by the evil FPGA vendor. The Da Vinci Bit Code, if you will. They weave a web of untruths and half whispers with convenient coincidences to explain their troubles. Alas, all I can do is deal with those whose questions I can actually answer. Peter and I have decided that having the actual numbers is good, so we go to battle to do just that. No need to thank us. Thanks for your support, AustinArticle: 95766
I'm finishing up an FPGA Journal article called "Stop. Go. Yield. - Dude! Where's my Chip?" I'm looking for people that have had delivery problems with FPGAs - particularly situations where delayed volume shipments caused a substantial impact on your ability to deliver a product. If you're not comfortable posting here, you can contact me directly. I'll keep you anonymous on request. This will be a fair article, and the vendors will be able to give their views/input as well. Group disclaimer: After three years of carefully avoiding using this group to gather article input, I've now done it twice in less than a month. I promise not to make it a habit. In both cases, I needed information beyond the reach of our normal PR and design team channels. If you object, please let me know and I'll take your opinion into consideration. Kevin MorrisArticle: 95767
In article <QSVBf.14902$bF.4557@dukeread07>, Ray Andraka <ray@andraka.com> wrote: >Jim Granville wrote: > >> So they may not be able to give the lowest info, but it should be >> possible to create some middle format, that is able to be swallowed >> by P&R at great speed ( because it has very little to do ). >> That format would also be portable, so you are freed from tracking >> the device and even vendor increments. >> >> -jg >> >> >> > >It is called XDL. XDL is basically a readable ascii text version of the >NCDs, and there are converters to and from NCD. It gives you hooks into >the tool flow anywhere between translate's output and bitgen's input. > >Seems those who keep yelling for open bit streams aren't bothering to >look at what is available, or try working with pieces. They all seem to >want full open bitstream without even understanding what all it entails >to be able to successfully work with it. You could do pretty much >everything they seem to be looking to do within the existing XDL >framework, and it gives the ability to use parts of the existing tools >so you don't have to develop the entire tool chain from soup to nuts. >Pick a piece of it and plug it into the existing tools. I guess to answer the question posted in the subject of this thread "What happened to JHDLBits?", in looking at the JHDLBits thesis a bit more, it would seem that maybe JHDLBits got too intimate with the bitstream and that put Xilinx in a litigious mood (the bitstream is the 3rd rail it seems). It may be that developing open source tools around XDL would be permited by Xilinx (I'd like to think so) so long as we avoid doing anything to or with the bitstream. So let's forget about bitstreams and focus on XDL which is afterall non-encrypted ASCII. "...drop that FPGA and step away from the bitstream, or we send in the Lawyers!" PhilArticle: 95768
I want to thank everyone for their thoughtful, insightful, and provocative responses to my query. We've covered everything from politics to education to (strange as it seems) FPGAs. I've already contacted a number of you directly (and have a few more on my list), and I'm excited about the article. I'll post here when it's ready for publication, and we can all start a new thread about how badly I missed the boat. Thanks again! KevinArticle: 95769
Joerg wrote: > Hello Richard, > >> >> So just what does "a degree from a university" really mean? >> >> Yesterday I heard a news report that questioned whether or not average >> US college graduates were even literate -- their test criterion was >> related to reading product labels/instructions [I was driving at time so >> I was paying attention to other things ;] >> > > I don't know how it is today but in my days a masters degree meant that > you were very literate and had a rock solid knowledge base all the way > to Maxwell's equations. Else you would not hold that degree. IIRC only > about 17% of the year when I started made it. They had the "three > strikes rule". If you flunked an exam you could repeat once. Only one > exam could be attempted a third time and you had to request special > permission for that. Fail it again and you were out for good. Oh, and > that repeat exam came with the "exitement" of an aural where you were > grilled by the professor for a half hour or so. And no Xanax or Zoloft > or whatever in those days. > > That's very different from some multiple choice tests that ask you how > many appointees there are on a licensing board. > >> >> As to PE license, it's irrelevant to reality if not legality. >> I don't know how it is now. > > > Still is, in most states, due to the industry exemption. Take that away > and that state will slide down into the technological abyss. > > I have also had the "pleasure" to share your experiences WRT to young > grads. Universities still do not teach much practical engineering and > the kids today are not creative anymore in the ways we were. The demise > of Heathkit and those cool electronics surplus stores in town is an > indicator of that. Licensing is not going to make that situation any > better. Not by one iota. It would make it worse by taking older > engineers with real experience but non-ABET course work out of the work > force. Engineers who would then probably sue those agencies into oblivion. > > Regards, Joerg > > http://www.analogconsultants.com 1. It started with civil engineers first. (See code Hammarubi, more stringent for builders than doctors at first). [an indication of the relevant advancement of knowledge at the time]. 2. Licensing in America started in the early 1900's with the first engineering professional laws. At the time it was about "civil" engineers that designed and built our physical infrastructure (buildings and transportation systems). I has mutated since. -- JosephKKArticle: 95770
Kevin Morris wrote: > > So, I have a question regarding the assertion that the datasheet LUT > count is "important information." > > Why? What is the real-world utility of that number? Do some people > know up-front how many LUTs their design is gonna use, and then they > just need an accurate LUT count to pick the best FPGA? > It's great for migrating an existing design; if, say, you want to know how many 3S1600E's it takes to replace a 2VP70 without reverse engineering the marketing gate inflation factor for each datasheet. I also find it handy for a ballpark comparison between devices and vendors, bearing in mind differences in the turbo-bonus feature count. If you get really down-and-dirty with the parts, it's great to know things like how many N-bit cascaded add/sub stages will fit up/down and across a given chip, so you can floorplan up front; or, just to realize when the synthesizer has 'optimized' something to be twice as big as it should be. Here are some old ramblings on the subject of device LUT aspect ratio, where the concern is not just how many LUTs but how they are arranged: http://groups.google.com/group/comp.arch.fpga/msg/f0b651ac1d5d46bb Brian p.s. I remembered your 'tango' article about 5 seconds after I hit the post button on my last message, or I'd have included that link, tooArticle: 95771
Hi Jeff, I am planning on implementing a CPU as a personal project. I have a different dev board, but it is loaded with the XC3S200. May I ask the model number of the FPGA on your development board?Article: 95772
I have found that there is "clock high time violation" while timing verification using Altera QuartusII, with device "flex10K". I wonder whether this is caused by the pulse width, depending on gate delay, not long enough for driving FSM. Best Regards, YuQing, YouthArticle: 95773
That should have been split > > http://www.huffcrimeblog.com/ > http://www.embeddednt.com. > A purveyer of FPGA, DSP, FPU cores etc? > > transputer guyArticle: 95774
That's it ! Onetime I have changed my computer's clock, but i did'nt notice that i compile my design with the wrong date and since I come back to the right date it doesn't work. Thanks Gabor alexis "Gabor" <gabor@alacron.com> wrote in message news:1138197024.992933.177060@g44g2000cwa.googlegroups.com... > > kcl wrote: >> Hello, >> >> I get trouble to run a project(synthetize and p&r) It complete >> sucessfully >> all the steps but it doesn't validate it so when I try to remake just one >> step like the P&R it restarts also the synthetize as it has never been >> done. Also when I made a step instead of putting a green mark on this >> step >> when it have been done , it puts a a point of interrogation ( and not a >> red >> cross) >> >> for example : >> I make my project and synthetize it . ISE says me that it have been >> completed but it keeps the point of interrogation. Then I run the >> Implement >> Step and it restarts the synthetize first. As if I have done a a rerun >> command. >> >> If I make a full run (synthetize+translate+map+P&R) It validates all >> steps >> when they are finish (but still running the next step) with the green >> mark >> but when it finish the run all the step are unvalidate ( by a ? sign) >> >> does anyone have already meet these problem? >> >> I have already try to reinstall ISE (6.3 sp3) and remake all the project >> (just keeping the vhd) >> >> Thanks you for your answer. >> >> alex > > I've found that this is often a system problem. ISE keeps track of > source > module modification times and generated file creation times. If some > of the files are located on another computer these times may not be > directly comparable. This happens if the systems are not set to the > same time zone for instance, or sometimes if they don't use the same > operating system. It can also happen if the computers' clocks are not > set correctly. >
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