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
Without divulging any secrets (hell,I do not even work in that division of Xilinx, so how would I know?): The biggest problem in integrating an A/D converter is deciding on its parameters. Should it be a slow, high-precision sigma-delta type, or successive approximation, or a fast flash converter? Single channel or multi- channel? The trouble is that these are irreversible decision. You cannot morph a slow 12-bit converter into a fast 8-bit converter (like you do easily in the digital domain). So it's a battle of temperature sensors vs industrial control, vs audio, vs video. Tough choices! Note: Virtex5 has a multi-input 10+-bit A/D converter in every chip. It's called System Monitor. It had problems in Virtex-4, so we disabled it there, but it works perfectly in Virtex-5. Peter Alfke, Xilinx Applications =================== On Mar 7, 10:47 am, "news.t-online.de" <carlhermann.schleh...@t- online.de> wrote: > Hi, > I just got a newsletter stating the Spartan3AN being available now. While > these Spartan3AN are market as "new non-volatile" FPGAs, this might (IMHO) > be misleading. For my understanding "non-volatile" would mean no > configuration on power-ON (as e.g. ACTEL AntiFuse) rather than Config-Eprom > being integrated in FPGA chip's housing (being a separate die as well). > Nevertheless this definitely is a nice appraoch, saving space and copper > traces on PCB. > As always, as soon as the new chip is on market the question on next > enhancements arises. Any truth in rumors stating next generation Spartan (or > what it will be called) has integrated Analog-Digital Converters? > > CU, Carlhermann SchlehausArticle: 116351
news.t-online.de wrote: > Hi, > I just got a newsletter stating the Spartan3AN being available now. > While these Spartan3AN are market as "new non-volatile" FPGAs, this > might (IMHO) be misleading. For my understanding "non-volatile" would > mean no configuration on power-ON (as e.g. ACTEL AntiFuse) rather than > Config-Eprom being integrated in FPGA chip's housing (being a separate > die as well). Most of the FPGA architectures I know of, all load the config : I'm not sure even anti-fuse devices have the fuses actually in the signal path. (imagine the tpd cost, of those fuse-program circuits ! ) So, what we are really talking about, it the time taken to load the config. Some are largely parallel, some are parallel-serial, and some are pure serial (3AN). I see your point, and "loader included" might be more accurate than "new non-volatile", as that claim also implies a certain security level that other "non-volatile" alternatives DO offer. > Nevertheless this definitely is a nice appraoch, saving > space and copper traces on PCB. > As always, as soon as the new chip is on market the question on next > enhancements arises. Any truth in rumors stating next generation Spartan > (or what it will be called) has integrated Analog-Digital Converters? I thought ADCs were already in FPGAs, but targeting temperature and Vcc verification tasks, not mUXd to Pins (die is likely to be rather noise for that..? ) -jgArticle: 116352
"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message news:1173293293.597472.321940@p10g2000cwp.googlegroups.com... > On Mar 7, 10:41 am, "John_H" <newsgr...@johnhandwork.com> wrote: >> "Symon" <symon_bre...@hotmail.com> wrote in message >> >> news:esmu00$mnc$1@aioe.org... >> >> > Hi Peter, >> > Yes, thinking about it again, you're absolutely right. I dredged back >> > though my memory and the situation I so badly recalled was a double >> > data >> > rate circuit near the toggle limit of the part. I needed to synchronise >> > phase alignment between two signals, one in the rising and one in the >> > falling edge clock domains. To do this I had the output of a falling >> > edge >> > FF feeding the input of a rising edge FF. By changing the falling edge >> > FF >> > to a latch (transparent when clock is high), I gained extra set-up time >> > for the rising edge FF, as the latch passed data through a little >> > earlier. >> > Many thanks for correcting me, and putting the record straight. >> > Best regards, Symon. >> >> I've come up with this approach myself, subsequently seen it mentioned in >> an >> app note, and now find you've concluded the same circuit is useful in >> this >> situation. >> >> More engineers should be exposed to this one application where a latch is >> indespensible. Without it, DDR domains can get messy. >> >> The one sad thing about it, in my opinion, is that the Xilinx timing >> tools >> don't treat this case well. My recollection is that the setup is >> referenced >> to the wrong edge giving me no chance to get clean numbers by only >> including >> latch_d_q path tracing. >> >> - John_H > > Hi John, > Could you please tell which application note you are talking about. > > Thank you. > > Weng I thought it was XAPP250 http://www.xilinx.com/bvdocs/appnotes/xapp250.pdf but a quick scan of the document and search for "latch" came up empty. Some of the techniques I've been using lately are mentioned in that article as are the ones in XAPP671. Ah, there it is. Mentioned on page 4 and elaborated on page 11: http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf Fun with silicon! - John_HArticle: 116353
On Mar 7, 5:35 am, Philip Herzog <p...@arcor.de> wrote: > it.st...@gmail.com wrote: > > I would to interface a CMOS image sensor to my FPGA. I'm looking for > > low-end sensor and a matching lens. Nothing fancy or several mega > > pixels - just the bare minimum. > > We were looking for something similar like a mobile phone camera, but > you can't get them in low quantities and they have a very short lifetime. > > ST seems to address this market now - look athttp://www.st.com/stonline/products/families/imaging/imaging.htm > Can't give you a lot of experience yet, we're just evaluating. > > - Philip > -- > I wouldn't recommend sex, drugs or insanity for > everyone, but they've always worked for me. > (Hunter S. Thompson) Sparkfun has some pretty sweet CMOS image sensors for not a whole lotta $: http://www.sparkfun.com/commerce/product_info.php?products_id=637 JohnArticle: 116354
> > I thought ADCs were already in FPGAs, but targeting temperature and > Vcc verification tasks, not mUXd to Pins (die is likely to be rather > noise for that..? ) > Hi Jim, The Virtex-5 is the first Xilinx device to support an ADC, and most other FPGAs (and FPGA companies!) don't have integrated ADC's at all. The Virtex-5 System Monitor solution has an ADC core (200K/s), with internal voltage sensors (Vccint and VccAux), and Temperature, plus a dedicated high bandwidth input channel, and 16 channels that are optional digital or analog IO. So no valuable pins used, unless you want to. To answer your question on noise: noise performance is very good, due to all input channels being fully differential (and there is support for bipolar and unipolar signals on all input channels). Also, due to the speed of the ADC, and to further suppress noise, averaging can be turned on for every channel, while still maintaining a high sample rate. Other features include automatic sequencing of the channels, and alarms are available to warn you if the internal sensors detect dangerous voltage/temperature conditions. For more info see: http://www.xilinx.com/systemmonitor Or UG192: http://direct.xilinx.com/bvdocs/userguides/ug192.pdf Plug in chipscope to a Virtex-5 FPGA and it will read back the internal voltage / temperature sensors live on a nice graph for you! Hope this helps JohnArticle: 116355
Marlboro wrote:
> Assume we have this VHDL model
>
> process(sig) begin
> if ( sig = '1' ) then
> q <= '1';
> elsif ( sig'event and sig = '0' ) then
> if ( cke = '1' ) then
> q <= 0;
> end if;
> end if;
> end process;
>
> Is there anything wrong?
Yes. "sig" is used as an asynch preset *and* a clock.
-- Mike Treseler
Article: 116356
On 6 Mar 2007 13:28:59 -0800
"Patrick Dubois" <prdubois@gmail.com> wrote:
> Instead of ditching VHDL for Verilog, you might want to consider
> Synplify instead of xst. I am using some tidbits of VHDL-200x in my
> current design and xst produced a wrong netlist from that vhdl. I have
> access to Synplify for my master's degree (thankfully) and I ran that
> piece of code through Synplify. The post-synthesis simulation showed
> that the result from Synplify was correct, contrary to xst (v9.1 btw).
Well, i burned my fingers with Synplify when i was doing my
master thesis a year ago. Within half a year i found a dozen
of bugs, just by implementing something that is nothing more
than an optimized 64 bit adder. Ok, all but two bugs were
related to the Altera backend and worked fine when choosing
Xilinx instead. But still....
Attila Kinali
--
Linux ist... wenn man einfache Dinge auch mit einer kryptischen
post-fix Sprache loesen kann
-- Daniel Hottinger
Article: 116357"Rebecca" <pang.dudu.pang@hotmail.com> wrote in message news:1173287508.007535.163210@c51g2000cwc.googlegroups.com... > Hello, Bill: > Thank you very much for your response. > Buf after I set up the enviroment variable and run the route again, I > got the same error several hours later. What can I do? > I will set the DCM as the top level file and try. Did you restart ISE after setting this variable? /MikhailArticle: 116358
John McGrath wrote: >>I thought ADCs were already in FPGAs, but targeting temperature and >>Vcc verification tasks, not mUXd to Pins (die is likely to be rather >>noise for that..? ) >> > > > Hi Jim, > The Virtex-5 is the first Xilinx device to support an ADC, and most > other FPGAs (and FPGA companies!) don't have integrated ADC's at all. > The Virtex-5 System Monitor solution has an ADC core (200K/s), with > internal voltage sensors (Vccint and VccAux), and Temperature, plus a > dedicated high bandwidth input channel, and 16 channels that are > optional digital or analog IO. So no valuable pins used, unless you > want to. > > To answer your question on noise: noise performance is very good, due > to all input channels being fully differential (and there is support > for bipolar and unipolar signals on all input channels). > Also, due to the speed of the ADC, and to further suppress noise, > averaging can be turned on for every channel, while still maintaining > a high sample rate. > > Other features include automatic sequencing of the channels, and > alarms are available to warn you if the internal sensors detect > dangerous voltage/temperature conditions. > > For more info see: > http://www.xilinx.com/systemmonitor > > Or UG192: > http://direct.xilinx.com/bvdocs/userguides/ug192.pdf > > Plug in chipscope to a Virtex-5 FPGA and it will read back the > internal voltage / temperature sensors live on a nice graph for you! > > Hope this helps Thanks for the details - good to see it's nice and flexible. Can you comment on the OP's question : "Any truth in rumors stating next generation Spartan (or what it will be called) has integrated Analog-Digital Converters? " - would seem likely, once a block is finally proven on a process, all the hard work is done. -jgArticle: 116359
Hi, I would like to know what are the common methods of introducing delays as low as 10ps between two outputs in an FPGA. I do not currently have a specific FPGA in mind. I am just looking for a general answer. I know there are DCMs but this usually adds jitter and one needs to wait for the DCM output to phase lock before the signal is stable and it might take too long in our case. Basically I would want to power up a board and have the delay be set in as short a time as possible. I also need to minimise jitter to a minimum so that the two signals are NEVER high at the same time. Thanks for any answer. AmishArticle: 116360
On Mar 7, 4:02 pm, Attila Kinali <att...@kinali.ch> wrote: > Well, i burned my fingers with Synplify when i was doing my > master thesis a year ago. Within half a year i found a dozen > of bugs, just by implementing something that is nothing more > than an optimized 64 bit adder. Ok, all but two bugs were > related to the Altera backend and worked fine when choosing > Xilinx instead. But still.... Another good reason to do post-synthesis simulations... Doesn't that suck? I mean, how often do software guys find run-time bugs in gcc for example? It seems less common than VHDL synthesis bugs (but I'm probably biased, since I do more VHDL than software...). PatrickArticle: 116361
Jim, > Can you comment on the OP's question : > "Any truth in rumors stating next generation Spartan (or what it will be > called) has integrated Analog-Digital Converters? " > > - would seem likely, once a block is finally proven on a process, all > the hard work is done. That is true. If enough customers when surveyed answered that the "system monitor" added value to their devices, then I am sure the block is under consideration for inclusion. The real difficulty is that this block consumes area which is wasted for anyone who doesn't need it. With the constraints on pricing for Spartan parts, cost is everything. This also presumes that there will be a new Spartan part on 65nm, and exactly how this is featured is not something we can discuss here. Does it favor lower static power at the cost of system speed? Or, does it have medium speed, and medium static power (and no one is happy)? As you may be well aware, the ITRS roadmap has some serious issues: http://www.itrs.net/Links/2006Update/2006UpdateFinal.htm and even more depressing: http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=197700884 Technology has slowed to a crawl: three years between nodes is now the optimistic prediction. Speed is hardly faster, leakage is far worse, dimensions can not be made smaller (unless you don't care about yield). The 'fast' train has hit the "foothills" and we need to do more than just make everything smaller (and get speed, power, and cost improvements). We now have to consider what our customers need (wow, what a concept!), and decide how we may be able to add value. Triple oxide, strained silicon, strained Ge-Si, silicon on insulator, multiple voltages, multiple Vt's for nmos and pmos: the toybox is empty. We have no hi-K gate dielectric (yet). How do we 'improve'? Even Intel and AMD have completely revised their stories: it is no longer about clock speed but "multicore" and "multicore+graphics processor." I have heard at a conference someone ask the Intel presenter "isn't where you are going where FPGAs have already been?" AustinArticle: 116362
Amish, The only method I am aware of is hand routing. 10ps is too small to really be able to hold to in all cases. With 35ps p-p jitter (minimum) in any FPGA, and +/- 10 ps route matching (due to process variations chip to chip), this may be impossible. Austin axr0284 wrote: > Hi, > I would like to know what are the common methods of introducing > delays as low as 10ps between two outputs in an FPGA. I do not > currently have a specific FPGA in mind. I am just looking for a > general answer. > > I know there are DCMs but this usually adds jitter and one needs to > wait for the DCM output to phase lock before the signal is stable and > it might take too long in our case. Basically I would want to power up > a board and have the delay be set in as short a time as possible. I > also need to minimise jitter to a minimum so that the two signals are > NEVER high at the same time. Thanks for any answer. > Amish >Article: 116363
"axr0284" <axr0284@yahoo.com> wrote in message news:1173304789.265305.168410@p10g2000cwp.googlegroups.com... > Hi, > I would like to know what are the common methods of introducing > delays as low as 10ps between two outputs in an FPGA. I do not > currently have a specific FPGA in mind. I am just looking for a > general answer. > > I know there are DCMs but this usually adds jitter and one needs to > wait for the DCM output to phase lock before the signal is stable and > it might take too long in our case. Basically I would want to power up > a board and have the delay be set in as short a time as possible. I > also need to minimise jitter to a minimum so that the two signals are > NEVER high at the same time. Thanks for any answer. > Amish The jitter you get from having the FPGA in your signal path will far outweigh the delay difference you're looking for. To get delay resolution down to about 100 ps in the Spartan 3 family devices, for instance, carry chains can be manipulated in interesting ways. To get below 10 ps resolution, you really need a precision external circuit. For arbitrary tunable delays, I've worked with I/Q modulators in the past to generate a phase-shifted clock with sub-degree granularity (though not necessarily sub-degree precision) using DACs and RF devices. You can easily achieve 10 ps granularity through this external clock control; it makes it easier to keep the edges clean when the timing edges don't rely on the FPGA. - John_HArticle: 116364
Probably the EDK didn't take the changed file. I will check first and let you know the result, Thank you for all your help.Article: 116365
I am using xilinx tools in an unix system to do the P&R and generate the bit file. I am using a batch mode script to go through the steps. Currently I am running impact in gui mode ( either from UNIX or Windows) to generate the MCS files for the EEPROMs. Is there any way to run the impact in batch mode in UNIX to generate the MCS files? I was not able to get the information lookig at the help information available. Thanks for your help. -DipuArticle: 116366
Hi, Being familiar with FPGA design and implementation flow and illiterate with ASIC corresponding one. My question is the following what are the main similarities/differences between designing and implementing an algorithm on these two different targets? in particular what are the design/implementation practises and user tasks needed in ASIC and not in FPGA implementation and vice versa? at the end what is the most widely tool used in asic? many thanksArticle: 116367
On Mar 7, 2:26 pm, dipum...@hotmail.com wrote: > I am using xilinx tools in an unix system to do the P&R and generate > the bit file. I am using a batch mode script to go through the steps. > Currently I am running impact in gui mode ( either from UNIX or > Windows) to generate the MCS files for the EEPROMs. Is there any way > to run the impact in batch mode in UNIX to generate the MCS files? I > was not able to get the information lookig at the help information > available. Under windows, impact creates a file called _impact.cmd in the current working directory. This is either the directory you ran impact from, or C:\Xilinx if you start it from the program menu. 1. Build your mcs from the gui the way you usually would 2. Copy _impact.cmd to a new file (eg. mcs.cmd) and run: 3. impact -batch mcs.cmd I don't run impact under unix, so I don't know what it does. Alan NishiokaArticle: 116368
Austin Lesea wrote: <snip> > As you may be well aware, the ITRS roadmap has some serious issues: > > http://www.itrs.net/Links/2006Update/2006UpdateFinal.htm > > and even more depressing: > > http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=197700884 > > Technology has slowed to a crawl: three years between nodes is now the > optimistic prediction. Speed is hardly faster, leakage is far worse, > dimensions can not be made smaller (unless you don't care about yield). > The 'fast' train has hit the "foothills" and we need to do more than > just make everything smaller (and get speed, power, and cost > improvements). We now have to consider what our customers need (wow, > what a concept!), and decide how we may be able to add value. > > Triple oxide, strained silicon, strained Ge-Si, silicon on insulator, > multiple voltages, multiple Vt's for nmos and pmos: the toybox is > empty. We have no hi-K gate dielectric (yet). How do we 'improve'? > > Even Intel and AMD have completely revised their stories: it is no > longer about clock speed but "multicore" and "multicore+graphics > processor." I have heard at a conference someone ask the Intel > presenter "isn't where you are going where FPGAs have already been?" You are right, tho some milestones are pushed out, as they prove less essential than some believed : 450mm wafers is one (if die sizes are not going up, why should wafers ? ), and immersion is delayed by advances in masking and then, other technolgies suddenly look closer This in todays news : http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=35MFW2NZDZ2VMQSNDLSCKHA?articleID=197800524 "..sample a 90-nm 128-Mbit phase change memory to customers in the first half of 2007. Mass production could begin before the end of 2007 the chip giant said." I have to be impressed - remember, this is intel (!), and aren't those times lines quite similar to today's just-sampling FPGAs .... So, I went looking for speed info, and found this :However, he did say that PRAM's random read access latency is very :comparable to DRAM. "Phase change memory fundamentally has a very fast :read speed, and how the bandwidth is depends on how it's configured in :the actual end product," said Kimoto. PRAM does not show in the foundries plans at moment, but a stacked die PRAM + FPGA, with wide access bus, would be near term do-able : mainly dependant on the FPGA volumes being large enough to interest the big memory players... -jgArticle: 116369
Jim, As I said, how do we IC designers "add value?" If the ITRS mad dash has slowed to a crawl, other technologies might 'catch up' and actually become useful.(!) We used to complain that we didn't have time to mess with dram+logic (or eprom+fpga: put you favorite combination here) on the same device, maybe now we do? AustinArticle: 116370
On Mar 7, 12:16 pm, "John_H" <newsgr...@johnhandwork.com> wrote: > "Weng Tianxiang" <wtx...@gmail.com> wrote in message > > news:1173293293.597472.321940@p10g2000cwp.googlegroups.com... > > > > > > > On Mar 7, 10:41 am, "John_H" <newsgr...@johnhandwork.com> wrote: > >> "Symon" <symon_bre...@hotmail.com> wrote in message > > >>news:esmu00$mnc$1@aioe.org... > > >> > Hi Peter, > >> > Yes, thinking about it again, you're absolutely right. I dredged back > >> > though my memory and the situation I so badly recalled was a double > >> > data > >> > rate circuit near the toggle limit of the part. I needed to synchronise > >> > phase alignment between two signals, one in the rising and one in the > >> > falling edge clock domains. To do this I had the output of a falling > >> > edge > >> > FF feeding the input of a rising edge FF. By changing the falling edge > >> > FF > >> > to a latch (transparent when clock is high), I gained extra set-up time > >> > for the rising edge FF, as the latch passed data through a little > >> > earlier. > >> > Many thanks for correcting me, and putting the record straight. > >> > Best regards, Symon. > > >> I've come up with this approach myself, subsequently seen it mentioned in > >> an > >> app note, and now find you've concluded the same circuit is useful in > >> this > >> situation. > > >> More engineers should be exposed to this one application where a latch is > >> indespensible. Without it, DDR domains can get messy. > > >> The one sad thing about it, in my opinion, is that the Xilinx timing > >> tools > >> don't treat this case well. My recollection is that the setup is > >> referenced > >> to the wrong edge giving me no chance to get clean numbers by only > >> including > >> latch_d_q path tracing. > > >> - John_H > > > Hi John, > > Could you please tell which application note you are talking about. > > > Thank you. > > > Weng > > I thought it was XAPP250 > > http://www.xilinx.com/bvdocs/appnotes/xapp250.pdf > > but a quick scan of the document and search for "latch" came up empty. Some > of the techniques I've been using lately are mentioned in that article as > are the ones in XAPP671. Ah, there it is. Mentioned on page 4 and > elaborated on page 11: > > http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf > > Fun with silicon! > > - John_H- Hide quoted text - > > - Show quoted text - Hi John, Thank you for your suggestion. Silicon is living and money to me. WengArticle: 116371
Well I was writing this at the same time. During builds sorry. Hi Rebecca, =E2=80=A8I guess that didn't fix it sorry. First you just said the E word oh the pain of EDK. I pray you have a very very nice boss with deep pockets. If EDK only worked the same way as Xilinx stated life would be great however they blame training. Ok when I added DDR2 to my design(custom board) I also had the same problem needed another DCM that was in ISE. Please try removing the Global clock buffer from your DCM(ISE) output and see if that fixes the problem. Or use the Coregen version of the DCM and see if that fixes it. An even though you have output declared as a BUFG in Corgen that sometimes fixes it. Also you maybe running out of resources. 1st try this I don't think you need this try removing it Locked_BUFG_INST : BUFG port map (I=3D>LOCKED_OUT_Buf, O=3D>LOCKED_OUT); Ok I am guessing you don't have a nice boss that gave you the recommended computer with 16G. So have you ever used the FPGA Editor? Cheers, BillArticle: 116372
On Mar 7, 9:59 pm, "axr0284" <axr0...@yahoo.com> wrote: > Hi, > I would like to know what are the common methods of introducing > delays as low as 10ps between two outputs in an FPGA. I do not > currently have a specific FPGA in mind. I am just looking for a > general answer. > > I know there are DCMs but this usually adds jitter and one needs to > wait for the DCM output to phase lock before the signal is stable and > it might take too long in our case. Basically I would want to power up > a board and have the delay be set in as short a time as possible. I > also need to minimise jitter to a minimum so that the two signals are > NEVER high at the same time. Thanks for any answer. > Amish Actually, in theory I think you would be able to introduce delays in the order of 10ps. However controlling these is totally different matter. Back in the day, and I have to say for the record that I'm not that old, we used to introduce delays using the old fashioned RC tau way. So you might be able to relay certain bank or I/O by adding carefully calibrated RC network. Having said that, I don't think you would be able to have tight control over the timing simplying because what you'r asking more is more that what component imperfections can offer you. Another thing to keep in mind is the drive introduced by your measing device.Article: 116373
Signal propagation velocityon a pc-board is fairly stable and well- controlled at half the speed of light, i.e. 6 inches or 15 cm per nanosecond. You are asking for 1% of that, so figure 60 mil/10 ps or 1.5 mm/10 ps. Pretty small ! Peter Alfke On Mar 7, 1:59 pm, "axr0284" <axr0...@yahoo.com> wrote: > Hi, > I would like to know what are the common methods of introducing > delays as low as 10ps between two outputs in an FPGA. I do not > currently have a specific FPGA in mind. I am just looking for a > general answer. > > I know there are DCMs but this usually adds jitter and one needs to > wait for the DCM output to phase lock before the signal is stable and > it might take too long in our case. Basically I would want to power up > a board and have the delay be set in as short a time as possible. I > also need to minimise jitter to a minimum so that the two signals are > NEVER high at the same time. Thanks for any answer. > AmishArticle: 116374
"axr0284" <axr0284@yahoo.com> wrote in message news:1173304789.265305.168410@p10g2000cwp.googlegroups.com... > Hi, > I would like to know what are the common methods of introducing > delays as low as 10ps between two outputs in an FPGA. I do not > currently have a specific FPGA in mind. I am just looking for a > general answer. A transmission line external to the FPGA of the appropriate length would be about the best approach for something that small. Kevin Jennings
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