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
Hello, i have a problem to realize the PCI interface..... can you help me???? how can i do?? i have ML455 board VIRTEX4 PCI how can i do to comunicate with bus PCI?? i have bought the CORE but i don't know how can i use it and how create a driver.. please help me. "bijoy" <pbijoy@rediffmail.com> ha scritto nel messaggio news:ee9d6b3.-1@webx.sUN8CHnE... > Hello all, > > We have made a PCI board using Xilinx PCI core. with master and target > capabilities. It works well with intel PCs, but with AMD PCs if i plug the > card the PC will not boot. > > Does any one had similar expereince ? Any pointers for the cause will be > helpful for me > > Thank you bijoyArticle: 106051
"John_H" <johnhandwork@mail.com> wrote in message news:tMyBg.7003$qw5.1533@trnddc06... > Mr. Ken wrote: > > I need to use only 5 out of the 8 cases, but for completeness's sake, > > a default case is needed in order to avoid unwanted latches. This default > > case isn't covered by simulation. As a result, it will bring the coverage > > down > > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > > > How do I treat this situation? > > Could you leave the default case blank (but still include the default) > and get better coverage numbers? If there's a statement saying "clear > the register" that will never be executed, it's still a statement that's > not covered. If it's blank, will the simulation coverage still have a > problem that the emty branch was never entered? Thank you. For safety's sake, in the default case, I set the registers/variables to zero. The reason is that, without this statement, design compiler will infer a latch for it if it's not a clocked statement. I could have put "//synopsys case full_case" but client's FPGA/ASIC synthesizer might get into problem.Article: 106052
"Markus Zingg" <m.zingg@nct.ch> wrote in message
news:vdj9d2hnlfdprab5q048vv0si9qiplrnf6@4ax.com...
> Hi Group
>
> I have to implement a design which requires an FPGA, but to do so
> among other things I obviousely first have to learn one of the two
> mentioned languages.
Doesn't seem that obvious to me... learn both! Your life will then be much
easier. :-)
For my part, I prefer the "look" of Verilog but the "feel" of VHDL, if that
makes sense. Both languages have good points and bad points, but on the
whole I like VHDL best. I'd say it has a longer learning curve than Verilog,
but once you've got to the top of it the view is much nicer.
Cheers,
-Ben-
Article: 106053>I need to use only 5 out of the 8 cases, but for completeness's sake, > a default case is needed in order to avoid unwanted latches. This default > case isn't covered by simulation. As a result, it will bring the coverage > down > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > How do I treat this situation? > What about taking the 5th case as the default case. That means having 4 selects and the default covers the 5th case and 6th to 8th. MartinArticle: 106054
Hi Ken, I know you're using Verilog, but in VHDL I might try defining the thing which does the selection as an integer of range 0 to 4 and see if that helped prevent the latch inference. HTH, Syms. "Mr. Ken" <Mr. Ken@asdf> wrote in message news:44d6aa86$1@news.starhub.net.sg... >I need to use only 5 out of the 8 cases, but for completeness's sake, > a default case is needed in order to avoid unwanted latches. This default > case isn't covered by simulation. As a result, it will bring the coverage > down > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > How do I treat this situation? > > >Article: 106055
I am a newer for FPGA. I am reading some vhdl codes of others. I find they often use some buffers in design, such as IBUF, OBUF, FDCE, FDCE_1,etc.I have checked these buffer function but still not very sure the reason why these buffers put there. Is there anybody kindly tell me what situation we need a buffer? Or just give me some materials of it. I can check it by myself. ThanksArticle: 106056
"Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1154368574.396239.245890@b28g2000cwb.googlegroups.com... > Mike Treseler wrote: >> eric.amundsen@gmail.com wrote: >> >> > We would really like to use a DDR2 SRAM (for reasons I don't >> > want to go into), but Mega-core doesn't support it. >> >> Anything wrong with this one? >> http://www.altera.com/literature/ug/ug_ddr_sdram.pdf > > SRAM != SDRAM :-) > Perhaps you should at least base your reply on the title of the document instead of the name of the link....or even better on more than just the title. In any case, Altera's MegaCore (see link above) supports both DDR and DDR2 memories. I'm kind of missing why the original poster is not seeing this as well. KJArticle: 106057
Markus Zingg <m.zingg@nct.ch> writes: > Hi Group > > I have to implement a design which requires an FPGA, but to do so > among other things I obviousely first have to learn one of the two > mentioned languages. I got the impression that europe seems to be more > vhdl centric whereas verilog seems to be more popular in the US but > this argument alone is for reasons beond the scope of this question > not so important to me. I have a strong background in C programming > (should that matter anyhow) and in general experience with embedded > systems, but FPGAs are new to me. I'm otherwise completely open and > alas wonder what you guys suggest I should choose. I'm mostly > interested in replies from people which know both languages cause > otherwise I fear that this thread ends up in some sort of religious > war... > I've seen this description on comp.lang.vhdl: http://groups.google.co.uk/group/comp.lang.vhdl/browse_thread/thread/ecda44d121d1905c/a1df8e111cd1fbd7?lnk=st&q=&rnum=1&hl=en#a1df8e111cd1fbd7 "Verilog was designed by a bunch of hardware guys who didn't know a thing about designing software. We had to beat on it before we could make any real work with it. VHDL was designed by a bunch of software guys who didn't know a thing about designing hardware. We had to beat on it before we could make any real work with it." Not that it helps you any! Personally, I prefer VHDL because the strong-typing means the compiler can catch lots of problems for you. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 106058
Try to convert back to ISE 8.1. I had the same problems with ise 8.2 where I had some bugs in the design and 8.2 stopped PAR without giving any information about the problems. With 8.1 I experienced the same problems but at least got an error message which helped me solve the problem. heiner Matthieu Cattin schrieb: > Hi, > > I'm using ISE 8.2.01i and Synplify 8.6.1 as synthesis tool. > For one of my project, I can synthesize but when I try to launch > implementation it stops quite imediatly WITHOUT ANY ERROR MESSAGE !!! > > Does anyone already have such a problem? > > Thanks for your help.Article: 106059
KJ wrote: > "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message > news:1154368574.396239.245890@b28g2000cwb.googlegroups.com... > > Mike Treseler wrote: > >> eric.amundsen@gmail.com wrote: > >> > >> > We would really like to use a DDR2 SRAM (for reasons I don't > >> > want to go into), but Mega-core doesn't support it. > >> > >> Anything wrong with this one? > >> http://www.altera.com/literature/ug/ug_ddr_sdram.pdf > > > > SRAM != SDRAM :-) > > > Perhaps you should at least base your reply on the title of the document > instead of the name of the link....or even better on more than just the > title. > > In any case, Altera's MegaCore (see link above) supports both DDR and DDR2 > memories. I'm kind of missing why the original poster is not seeing this as > well. Yes but the link is for SDRAM (Synchronous Dynamic RAM) while the O.P. asked about SRAM (Static RAM) SylvainArticle: 106060
I've got a Spartan-3 which is configured (in master serial mode) from an XCF04S, and which is also in a JTAG chain which looks like this: connector -> Serial PROM/XCF04S -> XC3S1000 -> 3.3V device ->- connector <---------------------------------------------------| The problem is that bank 4 on the Spartan-3 must have a VCCIO of 3.3V, and the dedicated JTAG and configuration pins on the Spartan-3 are powered on VCCAUX, at 2.5V. The last device in the chain is also a 3.3V-only device. I've read Kim Goldblatt's appnote on this (XAPP453), and the obvious answer is to use a 3.3V JTAG/programming connector, and to set the I/O voltage on the PROM to 3.3V. There are 4 inputs on the Spartan-3 which are overdriven (PROG_B, TMS, TCK, TMI) so they need limiting resistors on them. The problem is, I don't really like this. There are 4 (or maybe just 3) input-protection diodes in the Spartan-3 which are almost permanently on, at about 9.5mA each. The Spartan-3 data sheet says that the inputs won't be damaged if the input voltage is kept below about 3.1V, but the last thing I want is a 676-pin package with blown inputs which can't be configured. Am I just being paranoid? The other problem is that my VCCAUX regulator now has to potentially supply ~120mA instead of ~80mA. So, my plan B is to run JTAG and configuration at 2.5V instead. This means that VCCJ and VCCO on the XCFO4S are at 2.5V instead of 3.3V, and: 1 - the DIN input on the Spartan-3 has reduced noise immunity (2.5V input, 3.3V buffer), but this should be Ok 2 - the 4 JTAG inputs on the other 3.3V device in the chain also have reduced noise immunity; again, should be Ok 3 - the TDO from the 3.3V device gets back to the programming connector as 3.3V, instead of 2.5V. I can handle this with a 74AHC14 buffer (a spare from the JTAG drivers at the connector) 4 - INIT_B at the Spartan has an internal pullup to 3.3V, but the XCF04S has a 2.5V INIT_B input. However, the XCF04S data sheet says that the inputs are at least 3.6V-tolerant for VCCO at a nominal 2.5V. So, I can just pull up INIT_B to 3.3V anyway. At first sight, it seems to me that plan B is much better than plan A. Any thoughts? Thanks - EvanArticle: 106061
Hi all, I was just pondering the idea of "gurus" & I thought the following questions may hopefully make some interesting & entertaining discussion. Including people in this newsgroup & others working in the field, whom do you consider to be the present-day "gurus" in FPGA system design? ...I mean the people who are well known & highly respected for their work & contributions in this field. Who is your favourite guru & why? :) TonyArticle: 106062
Mr. Ken wrote: > "John_H" <johnhandwork@mail.com> wrote in message > news:tMyBg.7003$qw5.1533@trnddc06... > > Mr. Ken wrote: > > > I need to use only 5 out of the 8 cases, but for completeness's sake, > > > a default case is needed in order to avoid unwanted latches. This > default > > > case isn't covered by simulation. As a result, it will bring the > coverage > > > down > > > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > > > > > How do I treat this situation? > > > > Could you leave the default case blank (but still include the default) > > and get better coverage numbers? If there's a statement saying "clear > > the register" that will never be executed, it's still a statement that's > > not covered. If it's blank, will the simulation coverage still have a > > problem that the emty branch was never entered? > > Thank you. > > For safety's sake, in the default case, I set the registers/variables to > zero. > The reason is that, without this statement, design compiler will infer a > latch > for it if it's not a clocked statement. > > I could have put "//synopsys case full_case" but client's FPGA/ASIC > synthesizer > might get into problem. You can get the same thing as full_case by assigning X to all outputs in the default, but this again leaves the choice up to the synthesizer which means any simulation coverage will not be 100%. I like the idea of setting the default case outputs to one of the previously defined states better. Just my 2 cents, GaborArticle: 106063
Uwe Bonnes wrote: > End of June Eric(?) told that he had not had time yet to put something > into > the project he put on sourceforeg. Hopefully things change. There's code there now. (I checked it out from SVN and submitted a patch to get it to build under FreeBSD) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 106064
On Sat, 05 Aug 2006 19:02:31 +0200, Markus Zingg wrote: > Hi Group > > I have to implement a design which requires an FPGA, but to do so > among other things I obviousely first have to learn one of the two > mentioned languages. I got the impression that europe seems to be more > vhdl centric whereas verilog seems to be more popular in the US but > this argument alone is for reasons beond the scope of this question > not so important to me. I have a strong background in C programming > (should that matter anyhow) and in general experience with embedded > systems, but FPGAs are new to me. I'm otherwise completely open and > alas wonder what you guys suggest I should choose. I'm mostly > interested in replies from people which know both languages cause > otherwise I fear that this thread ends up in some sort of religious > war... > > TIA > > Markus I strongly prefer Verilog. It's C like which makes it much easier to read for a C programmer. It's very concise which also makes it easier to read and write. Like C it's easy to write very efficient code with Verilog. On the downside it's missing a lot of C's important features like structures and procedures. Verilog has simple functions and a weak task mechanism instead of C's procedures. However I haven't found that limiting. VHDL is a much more complex language than Verilog. VHDL code is very verbose, painfully so. However it does have capabilities that Verilog doesn't have. Where Verilog errs on the side of being to simple, VHDL errs on the side of being to complex.Article: 106065
I think Antti Lukats is one of them. Cheers, Ales Tony Burch wrote: > Hi all, > > I was just pondering the idea of "gurus" & I thought the following questions > may hopefully make some interesting & entertaining discussion. > > Including people in this newsgroup & others working in the field, whom do > you consider to be the present-day "gurus" in FPGA system design? ...I mean > the people who are well known & highly respected for their work & > contributions in this field. > > Who is your favourite guru & why? > > :) TonyArticle: 106066
Antti wrote: > http://inisyn.org/src/xup/ > > its already done! I was kind of hoping someone does it, > and voila, done... Have you (or anyone else) tried it with the Platform USB cable? I'd imagine it would be almost identical to the stuff that's on the S3E starter board but you never know how bloody minded some hardware companies can be ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8CArticle: 106067
Thank Antti for uploading them to your site. What is the difference between the uploaded PPClinux and Hydra PPlinux? Guru Antti wrote: > Hi > > I have uploaded the files once available from Pauls website at the > university in Australia > > http://hydraxc.xilant.com/CMS/index.php?option=com_remository&Itemid=41&func=select&id=11 > > the archive contains all that I fetched from the web when it was > available. I do not know exact reasons why the original pages are > vanished, but for me the files from there have been a big help to get > ppc linux working on Virtex-4 > > AnttiArticle: 106068
In the real hardware, anything could happen and the other 3 cases could be hit. I think you should leave that 1% alone because it simply indicates that your simulation doesn't handle error recovery. Any reasonable person wouldn't make a big deal of it if it's well explanined and documented. If you really want 100% coverage, I would suggest you think of a way to inject errors instead of playing with the semantics. HTH, http://home.comcast.net/~jimwu88/tools/ Mr. Ken wrote: > I need to use only 5 out of the 8 cases, but for completeness's sake, > a default case is needed in order to avoid unwanted latches. This default > case isn't covered by simulation. As a result, it will bring the coverage > down > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > How do I treat this situation?Article: 106069
"Jim Wu" <jimwu88NOOOSPAM@yahoo.com> wrote in message news:1154956186.805032.46370@h48g2000cwc.googlegroups.com... > If you really want 100% coverage, I would > suggest you think of a way to inject errors instead of playing with the > semantics. > Hi Jim, Yeah, that would work. You could force the simulation to set the case selector to the illegal values. This would give the 100% coverage needed. Cheers, Syms.Article: 106070
Josh Rosen wrote: > On Sat, 05 Aug 2006 19:02:31 +0200, Markus Zingg wrote: > > > Hi Group > > > > I have to implement a design which requires an FPGA, but to do so > > among other things I obviousely first have to learn one of the two > > mentioned languages. I got the impression that europe seems to be more > > vhdl centric whereas verilog seems to be more popular in the US but > > this argument alone is for reasons beond the scope of this question > > not so important to me. I have a strong background in C programming > > (should that matter anyhow) and in general experience with embedded > > systems, but FPGAs are new to me. I'm otherwise completely open and > > alas wonder what you guys suggest I should choose. I'm mostly > > interested in replies from people which know both languages cause > > otherwise I fear that this thread ends up in some sort of religious > > war... > > > > TIA > > > > Markus > > I strongly prefer Verilog. It's C like which makes it much easier to read > for a C programmer. It's very concise which also makes it easier to read > and write. Like C it's easy to write very efficient code with Verilog. On > the downside it's missing a lot of C's important features like structures > and procedures. Verilog has simple functions and a weak task mechanism > instead of C's procedures. However I haven't found that limiting. > > VHDL is a much more complex language than Verilog. VHDL code is very > verbose, painfully so. However it does have capabilities that Verilog > doesn't have. Where Verilog errs on the side of being to simple, VHDL errs > on the side of being to complex. First off, I learned VHDL because that is what my employer uses - which I suspect most people end up doing. That said, I'm presently trying to learn Verilog, in order to be more versatile. I was trained in digital logic, so I found VHDL fairly trivial to learn. Verilog doesn't appear to be all that difficult either. Note, I'm not talking about being an expert in all of the nuances - I'm still learning those - I'm talking about being able to get busy designing hardware. Also, the verbosity of VHDL can be managed. A lot of the stuff people complain about is optional. For example, you don't have to put the process/architecture/package/etc. name at the end. You can just "end" it. Same goes for a lot of other structures. You can also declare subtypes and types that reduce a lot of typing, and make things more clear. Yes, you do need to be fairly intimate with the language to get to this point, but once you do, you can describe hardware pretty darn quick. I will admit, there are still things in VHDL that bug me. Semicolon use, for example, almost seems arbitrary. I've gotten used to it, but I still occasionally foul up with semicolons.Article: 106071
I would say my top 4 are Rich Katz(Nasa) for anything to do with FPGA's in space and general design issues. For languages and programming I would definitely say Jonanthan Bromley(Doulos, there are more guru's at Doulos but he seems to be the uber guru :-) For complex core development I would choose Jiri Gaisler since his Leon core worked first time (he never prototyped it before I tried it out!) and last but not least I read all postings from Peter Alfke since he is one of the great expert in the field. Hans www.ht-lab.com "Tony Burch" <tony@burched.com.au> wrote in message news:44d72fa7$0$5107$afc38c87@news.optusnet.com.au... > Hi all, > > I was just pondering the idea of "gurus" & I thought the following > questions may hopefully make some interesting & entertaining discussion. > > Including people in this newsgroup & others working in the field, whom do > you consider to be the present-day "gurus" in FPGA system design? ...I > mean the people who are well known & highly respected for their work & > contributions in this field. > > Who is your favourite guru & why? > > :) Tony > >Article: 106072
Mr. Ken wrote: > I need to use only 5 out of the 8 cases, but for completeness's sake, > a default case is needed in order to avoid unwanted latches. This default > case isn't covered by simulation. As a result, it will bring the coverage > down > from 100% to 99%. It's kinda annoying to explain this 1% to customer. > > How do I treat this situation? The proper method is to cover all cases explicitly. As mentioned earlier, combining case #5 with any other cases into the 'when others ' branch is an acceptable approach that would also guarantee 100% code coverage. Designing to cover that last 1% is not just annoyance, it's helping to insure that each line of code in the design actually has been tested in simulation which should be a bare minimum to strive for in test coverage anyway. It's not saying that each line has been tested under each condition that it may encounter but at least each line has been hit. Depending on just what exactly you have in your source code there might very well be very good reasons for making sure your design has every base covered that you're not even considering. Not knowing what your code is I'm guessing that the signal that is the target of the case is probably one of the following forms: 1. An integer subtype (i.e. signal X: natural range 0 to 7) 2. A std_logic_vector subtype (i.e. signal X: std_logic_vector(2 downto 0) Since you're using 5 of the 8 explicitly in your design what happens if it powers up in states #6, 7 or 8? Presumably you have a reset that will move it out of that state but you can also have a 'when others' that takes you to a known state as well. Adding code to handle this doesn't necessarily impact your code coverage. For example, if your code is of form #2 then the simulator will initialize the vector to 'UUU' and your 'when others' cause will in fact get executed. If your code is of form #1 then the 'when others' code will not get exectured because X will get initialized to 0. But before you think that this is a 'good' thing, consider - The underlying real hardware may not be giving you that same initialization of X to 0. - If you (or somebody else) goes to reuse this code in some other design than their underlying hardware may not give that same initialization. In both of these situations you're setting yourself up for a situation where simulation does not match reality which can be difficult to debug. In that sense code using code of form #1 is less robust than that using form #2 since it is relying on a quirk of simulation that is not present in the underlying hardware. Making your design and testbench code cover that last 1% may seem annoying but in fact it does make your design more robust and possibly reusable and is good design practice. The fact that the tool is showing you that you have a potential logic error that you haven't considered is a good thing. KJArticle: 106073
ZHI wrote:
> I am a newer for FPGA. I am reading some vhdl codes of others. I find
> they often use some buffers in design, such as IBUF, OBUF, FDCE,
> FDCE_1,etc.I have checked these buffer function but still not very sure
> the reason why these buffers put there.
Maybe you are looking at a vhdl netlist.
Creating a netlist of buffers registers
and luts from vhdl source code is the
job of synthesis.
-- Mike Treseler
Article: 106074Evan Lavelle wrote: > I've got a Spartan-3 which is configured (in master serial mode) from > an XCF04S, and which is also in a JTAG chain which looks like this: > > connector -> Serial PROM/XCF04S -> XC3S1000 -> 3.3V device ->- > connector <---------------------------------------------------| > > The problem is that bank 4 on the Spartan-3 must have a VCCIO of 3.3V, > and the dedicated JTAG and configuration pins on the Spartan-3 are > powered on VCCAUX, at 2.5V. The last device in the chain is also a > 3.3V-only device. > > I've read Kim Goldblatt's appnote on this (XAPP453), and the obvious > answer is to use a 3.3V JTAG/programming connector, and to set the I/O > voltage on the PROM to 3.3V. There are 4 inputs on the Spartan-3 which > are overdriven (PROG_B, TMS, TCK, TMI) so they need limiting resistors > on them. > > The problem is, I don't really like this. There are 4 (or maybe just > 3) input-protection diodes in the Spartan-3 which are almost > permanently on, at about 9.5mA each. The Spartan-3 data sheet says > that the inputs won't be damaged if the input voltage is kept below > about 3.1V, but the last thing I want is a 676-pin package with blown > inputs which can't be configured. Am I just being paranoid? The other > problem is that my VCCAUX regulator now has to potentially supply > ~120mA instead of ~80mA. > > So, my plan B is to run JTAG and configuration at 2.5V instead. This > means that VCCJ and VCCO on the XCFO4S are at 2.5V instead of 3.3V, > and: > > 1 - the DIN input on the Spartan-3 has reduced noise immunity (2.5V > input, 3.3V buffer), but this should be Ok > > 2 - the 4 JTAG inputs on the other 3.3V device in the chain also have > reduced noise immunity; again, should be Ok > > 3 - the TDO from the 3.3V device gets back to the programming > connector as 3.3V, instead of 2.5V. I can handle this with a 74AHC14 > buffer (a spare from the JTAG drivers at the connector) > > 4 - INIT_B at the Spartan has an internal pullup to 3.3V, but the > XCF04S has a 2.5V INIT_B input. However, the XCF04S data sheet says > that the inputs are at least 3.6V-tolerant for VCCO at a nominal 2.5V. > So, I can just pull up INIT_B to 3.3V anyway. > > At first sight, it seems to me that plan B is much better than plan A. > Any thoughts? There are a lot of details there that will take some real work to understand. I just dealt with configuring a Spartan 3 and dealt with the whole thing by just using a separate JTAG port for the FPGA. I have spent some significant time looking into using JTAG for both development purposes and for boundary scan. The one thing I got from all corners is that you are much better off avoiding the various problems you may encounter (not just interface voltage issues) in a single scan chain by not connecting everything in one chain. Our in-house boundary scan expert does not like using the Xilinx parts because of various problems when doing the tests, even though they are not in the same scan chain. I have been told by nearly every chip vendor that they don't support chaining their product with other brands of chips if they support chaining at all! I think Xilinx software may actually be a bit better behaved when working with other chips in the scan chain, but I still would not recommend this depending on the other chips. TI says they support scan chains in their literature and was a major proponent a decade or so ago. But when I contacted support about using their DSP chip emulation software in a scan chain they recommended not to. It seems to be a common practice to disregard the chaining capabilities of JTAG unless you really have to save the board space. Instead give each chip a separate connector. During development this will let you use multiple tools at the same time and if you need boundary scan in manufacturing they make tools that will drive multiple chains.
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