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
John Larkin wrote: >And we sure will be more careful about oscillators and clock >distribution in the future... everything's getting too fast. It was >probably the move of the ground plane to layer 5 of 6 (the clock is >mostly routed on 6), and the fast/weak xo, that caused the problem. >Clock-on-the-bottom isn't ideal for noise immunity, either. The change in stackup might have made the problem worse, but daisy-chained clocks are a bad idea with high speed logic. It is better to star route them, with equal length lines from the clock driver to each destination with source termination resisters. For a fanout greater than 1, don't use the oscillator output directly, use it to drive a higher drive gate. Daisy chaining clocks is bad for signal integrity and for clock skew. -- Phil HaysArticle: 100001
"motty" <mottoblatto@yahoo.com> wrote in message news:1143866500.657560.28370@u72g2000cwu.googlegroups.com... >I have a digital receiver module needed in a MicroBlaze system that I > coded in Verilog. The module is responsible for accepting, parsing, > and storing receive data from a part our company makes. The part is > responsible for driving the clock and data at 26 MHz. Our internal > clock on our MicroBlaze embedded system is 38.4 MHz. > > I desinged the block as two separate modules. The first module is > basically a shift register that clocks in the serial data from the part > when an enable line goes high (also driven by the external part). This > module works in the 26 MHz clock domain. The second module is a state > machine that accepts 96-bit chunks of data from the previous module, > parses that data based on the format being sent (a MBlaze software > register setting), and stores it in 32-bit chunks in internal block > ram. This module works in the 38.4 MHz clock domain. > > So the part sends the enable signal and that tells the 26MHz shift > register to start clocking in data. After 96-bits are received, the > module sends a trigger to the state machine logic. The state machine > is in a WAIT condition - having already intitalized the data format via > a software write. The state machine grabs the 96-bit chunk, parses it > into 1 or 2 32-bit chunks (depends on format), discards the rest, and > stores the data in block RAM. > > I threw it in our MicroBlaze project, built the design, and started > testing. I have a pattern generator set up to simulate the protocol > that the extrenal part will be responsible for providing (our part is > in fab). I have to use the EDK software debugger in order to see the > data stored to memory. Everything appeared to be working fine. > However, after increasing the data in the pattern, it was obvious that > random errors were occuring in the data stored to RAM. There would > occassionlly be incorrect values stored. I had the data coming in as a > binary count and sometimes the count would glitch. It didn't occur > often, but we can't have any errors. > > So, I tried two things. The first was to put some synchronization flip > flops in the state machine. Initially I had my concerns about crossing > clock domains, but since I was going from a slower one to a faster one > I didn't worry much. I put a couple each for the data being passed > from the 26 MHz clock domain, and for the trigger being passed from the > 26 MHz clock domain. After building this, the problem still occurred. > > I then put a KEEP_HIERACHY constraint on the top level module that > instantiates the two modules discussed. Low and behold, that worked. > I have tested extensively and there have been no errors. > > Does anyone have any insight into why keeping the hierarchy intact > works? I always try to design correct hierarchies in my > modules...meaning hierarchy that makes sense. And all signals are > registered at module boundaries. To me, the design discussed above is > well-partitioned. I don't know what XST would "optimize" when the > KEEP_HIERACHY was NOT specified. Just curious if anyone had any input. > > I didn't check to see what area penalties, if any, occured after > placing the constraint. I doubt it would make much difference. > > Thanks! > Motty - It sounds like you did everything correctly. You shift in 96 bits in the 26MHz clock domain, and after the data has been shifted in and is stable, you assert a 1-bit trigger to the 38.4MHz state machine, right? And you re-sync the trigger (and only the trigger) with the 38.4MHz clock, right? If that's all true then you did nothing wrong and I can't explain the effect of the KEEP_HIERARCHY constraint. If you did anything different than what I described then you probably had probalems crossing the clock boundary and the effect of KEEP_HIERARCHY may have been a coincidence. Sorry, that's the best I can offer. By the way, the abililty to partition logic cleanly is a great skill to have. RobArticle: 100002
On Sat, 01 Apr 2006 15:30:32 +1200, Jim Granville <no.spam@designtools.co.nz> wrote: >swimmerphil1@gmail.com wrote: >> Hi all, >> I have a question pertaining to an Atmel microcontroller. I have a >> AT89C2051 flash microcontroller. I just wanted to verify that once I >> program the chip with a universal programmer I have, I can turn off all >> power to the chip without losing the data right? So the next time I >> apply power to the chip, it will still function as programmed right. >> thank you. > >Yes. >If that was NOT true, how do you imagine they would be used ? :) Could be he's more accustomed to FPGAs and the need to reprogram 'em at every startup (for many common architectures, at least)? -- Rich Webb Norfolk, VAArticle: 100003
I believe that is the sim tab in your workspace. If you change versions I would go for 6.1e since 6.0 has some annoying GUI bugs (like not remembering your window layout). Hans www.ht-lab.com "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message news:122qto1lb19mrb8@corp.supernews.com... > In ModelSim 5.7 I would drag or right click items from a pane called > Structure and drag them or add them to the Wave. Where is this or what is > the new procedure for 6.0? > > Brad Smallridge > Ai Vision > >Article: 100004
Hi all,
Is it possible to make Modular Design and Incremental Design flows
parallelly?
I explain:
-If we have 3 modules A, B and C. We make modular design to
implement each module by a team member.
-If for exmaple module A is very big. Is it possible to develop
it using Incremental design flow but as a module of the Modular flow?
Thanks in advance for answer
Mehdi
Article: 100005"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> a écrit dans le message de news:0fqr2215rti8fahr3s1li78ppg9pbqf19t@4ax.com... > On Sat, 01 Apr 2006 01:17:27 GMT, Joerg > <notthisjoergsch@removethispacbell.net> wrote: > > >Hello John, > > > >> > >> And we sure will be more careful about oscillators and clock > >> distribution in the future... everything's getting too fast. It was > >> probably the move of the ground plane to layer 5 of 6 (the clock is > >> mostly routed on 6), and the fast/weak xo, that caused the problem. > >> Clock-on-the-bottom isn't ideal for noise immunity, either. > >> > > > >If you don't have one already get a fast FET probe. I find that an > >indispensable tool to check fast clocks and stuff. The usual resistive > >divider into a coax works as well but it's more clumsy. Good FET probes > >come with neat low inductance connection tools. > > > We have a TDS3052 (500 MHz) scope with the 1 GHz fet probes. Next > would be the big ole 7104 (1 GHz) analog scope, with a 1 GHz fet > probe. Our ultimate weapon is an 11801 with an SD-14 sampling head, > .25 pF and 3 GHz at the probe tip. I love scopes. > > Interestingly, the fpga glitch stopped when the TDS probe was touched > on the clock pin of the 2nd FPGA, which added about 0.5 pF. > On time we had a CPLD interfacing two asics together. Debugged the protos/first runs, temperature tests,... All OK. Then we had one particular board, tested OK in July/August which developped random failure when coming back from vacation in september. A bit of investigation revealed that the asic interface wasn't behaving according to the datasheet (wrong sampling clock front IIRC). It worked OK with the July/August high temperatures (timings were marginally OK). In September not anymore. Whew, a few days later the client was launching a first 1000 boards run (CPLD soldered and not ISP). The boards were HDSL repeaters installed everywhere, often in particularly hard to access places. -- Thanks, Fred.Article: 100006
Rich Webb wrote: > On Sat, 01 Apr 2006 15:30:32 +1200, Jim Granville > <no.spam@designtools.co.nz> wrote: > > >>swimmerphil1@gmail.com wrote: >> >>>Hi all, >>>I have a question pertaining to an Atmel microcontroller. I have a >>>AT89C2051 flash microcontroller. I just wanted to verify that once I >>>program the chip with a universal programmer I have, I can turn off all >>>power to the chip without losing the data right? So the next time I >>>apply power to the chip, it will still function as programmed right. >>>thank you. >> >>Yes. >>If that was NOT true, how do you imagine they would be used ? :) > > > Could be he's more accustomed to FPGAs and the need to reprogram 'em at > every startup (for many common architectures, at least)? Yes, it was such a strange question it sent me to the Atmel data sheet to check if they assumed too much knowledge, but the second sentence says : "The device is manufactured using Atmel’s high-density nonvolatile memory technology" so I can't really fault that.... -jgArticle: 100007
Roger Bourne wrote: > Would you know if it matters whether or not Webpack or Foundation is > employed to design a Spartan XC3S400 FPGA?, family of Spartan 3 I > believe. WebPack 8.1i will work fine for the XC3S400. It supports Spartan-3 parts up to the XC3S1500, and Spartan-3E up to the XC3S1600E.Article: 100008
Hi Thanks all for the great advice. Now just one more question :). Would I be ok to use a power plane with multiple islands for the different voltages. Cheers JonArticle: 100009
On Sat, 01 Apr 2006 03:51:26 GMT, "Rob" <robnstef@frontiernet.net> wrote: >> Interestingly, the fpga glitch stopped when the TDS probe was touched >> on the clock pin of the 2nd FPGA, which added about 0.5 pF. > >I hate when that happens :) Yup. I spent most of the night once on such a problem, on a SOIC on my first big SMT board. Probing anywhere else on the net - even a via half an inch away - didn't fix the problem, nor did series termination, parallel termination, or capacitive loading on the via. Eventually the penny dropped - the significant parameter was not the probe's capacitance, but its _weight_. Somehow, of about 6000 joints on that board, this one had missed out on its dose of solder paste. A tiny spot of solder, and all was well. - BrianArticle: 100010
On Fri, 31 Mar 2006 16:05:11 GMT, "RobJ" <rsefton@abc.net> wrote: >Anyone using this tool from Mentor? If so, any comments about it would be >much appreciated. And any comments on how ModelSim + ModelSim Designer >compares to Aldec's Active-HDL environment would be even better. I currently >own ModelSim but am looking for a more complete environment (testbench >automation, graphical tools, code coverage, etc.). > >Thanks, >Rob It's OK, but it won't work with designs from older versions of HDL Designer or Renoir. This wasn't made clear when I bought it, so I am using it as a Modelsim seat alongside my (legacy) HDL Designer. - BrianArticle: 100011
maxascent wrote: > Hi > > Thanks all for the great advice. Now just one more question :). Would I be > ok to use a power plane with multiple islands for the different voltages. Sort of like the first question, you can get a lot of different answers and they will all be correct. I find splitting planes is ok. But it is not easy to do well. The resistance of a sheet like a PCB plane can be expressed as "squares". For a given material and thickness, there will be a given amount of resistance per square area. It does not matter what the overall shape is, it can be broken into squares of any size and each one will have the same resistance. I've been told that a typical PCB will have about 1 mOhm per square. So don't make your power planes sections too long and narrow or the resistance will start to be significant. In general, the power and ground plane coupling provides capacitance at the highest frequencies where caps are too high impedance to do much good. So don't skimp on the planes, keep them as large as possible. In the end you may need to add a second power layer or mix power and signals just because most parts require two voltages and running split power planes to the same part can be difficult.Article: 100012
> So, I tried two things. The first was to put some synchronization flip > flops in the state machine. Initially I had my concerns about crossing > clock domains, but since I was going from a slower one to a faster one > I didn't worry much. I put a couple each for the data being passed > from the 26 MHz clock domain, and for the trigger being passed from the > 26 MHz clock domain. After building this, the problem still occurred. I wouldn't have synchronised the data but re-timed the 'data ready' pulse into the 38MHz domain a few more clock cycles to make sure the data had settled when the ready pulse was detected. > I then put a KEEP_HIERACHY constraint on the top level module that > instantiates the two modules discussed. Low and behold, that worked. > I have tested extensively and there have been no errors. Have you tested after multiple P&R runs? You might have just had a lucky build or two that have been seeded differently because of the keep hierarchy constraint. NialArticle: 100013
Hi, I have developed board with a Spartan 2E. The Spartan is configured by an antifuse fpga with the SelectMAP mode. The configuration of M[2:0] is ok. The configuration stream is transferred at 2.5MBytes/s. It said in the datasheet that the busy flag is provide for frequency above 50MHz. But in my design, I see a high level on the busy flag. Somebody saw this kind of phenomena on Spartan 2E device? What was the origin of this phenomenon? Thank you in advance smuArticle: 100014
I agree with Clark, thats why the IP cores are for. The only matter is the physical connection cause the high frequencies of the wires you have to drive inside the fpga need to be shielded from noise. chech existing phy inteegrated chips. "Anonymous" <someone@microsoft.com> wrote in message news:zraXf.56091$915.5917@southeast.rr.com... > Dumb question: Since USB is just a two wire serial interface and all the > USB > solutions I've seen are simple, though speedy, microcontrollers why can't > the USB be inside the fpga? Seems like you can instantiate a small micro > running at 50 mhz or so with code in a couple block rams to do what the > fx2, > for example, does. Apparently, doesn't exist so there must be some reason? > > -Clark > > "Mike Harrison" <mike@whitewing.co.uk> wrote in message > news:37no22duhjkjtns5mh9kvock01039l4tum@4ax.com... >> On 30 Mar 2006 09:56:49 -0800, "johnp" <johnp3+nospam@probo.com> wrote: >> >> >I've used the Cypress FX2 in the past. It has a flexible >> >interface that can support byte or word interfaces. They >> >used to have sample driver code, I believe they now supply >> >only a pre-built driver, you may want to check. >> > >> >It's a very flexible part, but with the flexiblity comes the need >> >for additional design work. >> > >> >You might look at ?QuickUSB? that has a canned design with >> >the FX2, but I'm sure if it can handle full data rates sustained. >> > >> >John Providenza >> >> I used quickusb recently - removes the need to get involved in any of the > low-level USB stuff at the >> PC end, and supports various IO models - 8/16 bit, internal/external > addressing, with various fifo >> modes and UARTs plus a FPGA bitstream programming mode. Absolute minimum > pin count would be 8 data + >> 2 control + clock, but you'd probably need at least one extra for > framing/handshaking. >> http://www.quickusb.com > >Article: 100015
pinku wrote: > Hello Groups, > > I have a 1Gbps SERDES output from the Network processor. But as i have > 2 SERDES signal coming from the back plane, depending of SEL line i > have to connect one of the SERDES to network processor. So i am using > FPGA to interface this, which takes a SERDES input and I have FIFO for > transmit FIFO, recieve FIFO and FIFO controller and this FIFO is again > connected to another SERDES which in turn connect to the Backplane. So > i need 4 SERDES for implementing it. Will this intermediate Logic > create for end to end SERDES data transfer ? Is there any other way of > implementing this logic? I am planning to use Stratix GX FPGA. > > Please let me know your suggestion, > waiting for your reply, > Kumar Perhaps this is a silly response (since I don't know the timing of your data, for example whether you need to be able to switch data sources without losing any words during the switching), but would it be possible to just multiplex the serial data? For example, could you use two of these: http://www.analog.com/en/prod/0,,768_835_ADG3243%2C00.html or something similar? ChrisArticle: 100016
In article <442df4ce$1@clear.net.nz>,
Jim Granville <no.spam@designtools.co.nz> wrote:
>Ken Smith wrote:
>
>> In article <p6nq22l4nf53kqanjhu7d4ojn70nb933nm@4ax.com>,
>> John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
>> [....]
>>
>>>I wonder if anyone has ever kluged a bga layout, sort of like one of
>>>those jellyfish with a thousand tentacles.
>>
>>
>> More likely it would be a costly blind-via PCB that sits between the BGA
>> and the base PCB. (Vomit)
>>
>> When I do a board with CPLD on it, I sometimes wire the unused pins
>> together in some random arrangement. You can't get fast signals out and
>> back but you can do a few slow ones.
>>
>> On my current project I'm up to 380 out of 512 used. This is making me
>> nervous.
>
> Then I'll put the hex on this, by asking :
>" What could marketing possibly dream up, that could use more than
>the 132 spare pins !?" :)
Actually, it is spare macro cells. Not all macro cells go to pins.
I'm more worried about stuff like this:
process(MemClock)
...
if Request1 then Arb = "001"
elsif Request2 Arb = "010"
elsif Request3 Arb = "011"
...
end process
Oh oh a bug! Request 7 may never get to happen if all the others are
busy. It has got to get in at least now and then. I can add a couple of
flip flops to see if Request7 has been true for more than a cycle of
SlowClock and doctor the logic. Bummer! now it won't fit!
Telling marketing to "go fish" is easy compared to having to spin the PCB
late in the development.
--
--
kensmith@rahul.net forging knowledge
Article: 100017"Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:fnss22hl486nr858dj1b4bkj3d7bg550qc@4ax.com... > On Fri, 31 Mar 2006 16:05:11 GMT, "RobJ" <rsefton@abc.net> wrote: > >>Anyone using this tool from Mentor? If so, any comments about it would be >>much appreciated. And any comments on how ModelSim + ModelSim Designer >>compares to Aldec's Active-HDL environment would be even better. I >>currently >>own ModelSim but am looking for a more complete environment (testbench >>automation, graphical tools, code coverage, etc.). >> >>Thanks, >>Rob > > It's OK, but it won't work with designs from older versions of HDL > Designer or Renoir. This wasn't made clear when I bought it, so I am > using it as a Modelsim seat alongside my (legacy) HDL Designer. > > - Brian Hi Brian - Ends up I misunderstood what ModelSim Designer is. I thought it was a product that runs with ModelSim, but adds new features (automated testbench generation, HDL to graphics, etc.). I talked at length with a Mentor sales person yesterday and Designer is a stand-alone simulator and development environment meant to attract the "low-end" FPGA crowd (like me) away from Active-HDL. They just lowered the price from $5500 to $2500, so it caught my interest. But I already own ModelSim so I'm not looking to replace it. I found out that HDL Designer is really what I'm looking for, but HDL Designer is a $17.5K tool. Have you used HDL Designer? Any comments on it? Thanks, RobArticle: 100018
billu wrote: > Hi There, > > I've managed to compile a sample aurora protocol design using > Coregenerator, and simulated it using ModelSim. I have a couple of > questions at this point. > > I'm trying to download the design onto the board using IMPACT. All the > processes (Program, Get Device ID, Read Status Register.. ) seem to > work except the Verify process. Is that something that I should be > concerned about.Can I assume that design has been uploaded to the > board, once I run program, and it says program successful? I would say, yes you should be concerned if the verify doesn't work. But if the board seems to be running okay... ? > How do I test the design on the board. Is there a simple to way to > demonstrate a link between two transceivers and monitor the status. I'm > guessing theres something possible with Chipscope, but I dont have > access to the program. Probably the simplest test is to monitor the channel_up signal out of the core. Your monitoring should verify that the signal is steady, too. If that is good, then the link is good and you should be able to send/receive data with no problem.Article: 100019
faraz.khan@nssi.us wrote: > Can anybuddy tell me what are the most common methods of grabing > discrete from out side world. These signals have no vaid and are > asynchronous Hmm... from http://www.nssi.us/about.htm "NSS is an engineering company specializing in the development, modeling, verification, certification, and production testing, of safety critical Avionics Systems." Interesting...Article: 100020
Hi Rob, What you want is HDL Author and not the full HDL Designer which is indeed quite expensive. HDL Designer includes Design Checker (source code linter), HTML export and IBD's (which I never use). My experience is that once you start using HDL Designer you can't live without it :-) The only drawback of HDL Designer is the lack of SystemC support, Hans www.ht-lab.com "RobJ" <rsefton@abc.net> wrote in message news:gqxXf.21806$w86.16445@tornado.socal.rr.com... > "Brian Drummond" <brian_drummond@btconnect.com> wrote in message > news:fnss22hl486nr858dj1b4bkj3d7bg550qc@4ax.com... >> On Fri, 31 Mar 2006 16:05:11 GMT, "RobJ" <rsefton@abc.net> wrote: >> >>>Anyone using this tool from Mentor? If so, any comments about it would be >>>much appreciated. And any comments on how ModelSim + ModelSim Designer >>>compares to Aldec's Active-HDL environment would be even better. I >>>currently >>>own ModelSim but am looking for a more complete environment (testbench >>>automation, graphical tools, code coverage, etc.). >>> >>>Thanks, >>>Rob >> >> It's OK, but it won't work with designs from older versions of HDL >> Designer or Renoir. This wasn't made clear when I bought it, so I am >> using it as a Modelsim seat alongside my (legacy) HDL Designer. >> >> - Brian > > Hi Brian - > > Ends up I misunderstood what ModelSim Designer is. I thought it was a > product that runs with ModelSim, but adds new features (automated > testbench generation, HDL to graphics, etc.). I talked at length with a > Mentor sales person yesterday and Designer is a stand-alone simulator and > development environment meant to attract the "low-end" FPGA crowd (like > me) away from Active-HDL. They just lowered the price from $5500 to $2500, > so it caught my interest. But I already own ModelSim so I'm not looking to > replace it. I found out that HDL Designer is really what I'm looking for, > but HDL Designer is a $17.5K tool. > > Have you used HDL Designer? Any comments on it? > > Thanks, > Rob >Article: 100021
On Sat, 01 Apr 2006 13:22:47 +0100, Brian Drummond <brian_drummond@btconnect.com> wrote: >On Sat, 01 Apr 2006 03:51:26 GMT, "Rob" <robnstef@frontiernet.net> >wrote: > >>> Interestingly, the fpga glitch stopped when the TDS probe was touched >>> on the clock pin of the 2nd FPGA, which added about 0.5 pF. >> >>I hate when that happens :) > >Yup. > >I spent most of the night once on such a problem, on a SOIC on my first >big SMT board. Probing anywhere else on the net - even a via half an >inch away - didn't fix the problem, nor did series termination, parallel >termination, or capacitive loading on the via. > >Eventually the penny dropped - the significant parameter was not the >probe's capacitance, but its _weight_. Somehow, of about 6000 joints on >that board, this one had missed out on its dose of solder paste. >A tiny spot of solder, and all was well. > >- Brian That's the first reaction my engineers usually have: "it must be a bad solder joint, and the pressure from the probe fixes it." They haven't been right so far. JohnArticle: 100022
I suspect you've got a design problem that is accentuated by routing delays. I can't think of any reason that KEEP_HIERARCHY would effect something like this. After you receive the 96 bits from the external device, are more bits being shifted in or does the incoming data stream stop? If data is still being received, is it possible that the shift register has received another bit before the parallel data has been transfered to the MBlaze? Maybe you should try registering the 96 bits into a holding register when all 96 have been received. This gives quite a while for any delay in the 'valid' signal to cause the data to be handed off into the MBlaze clock domain. John ProvidenzaArticle: 100023
The OP wanted a "time efficient" approach for adding USB support. I suspect trying to embed USB IP inside a FPGA does not meet this requirement. Yes, you could add a USB core and a PHY and an embedded processor and write and debug a bunch of code.... Or you could leverage parts like the Cypress FX2 that provides several easy approaches to doing this. Which is more "time efficient"? John ProvidenzaArticle: 100024
rickman wrote: > In general, the power and ground plane coupling provides capacitance at > the highest frequencies where caps are too high impedance to do much > good. So don't skimp on the planes, keep them as large as possible. > In the end you may need to add a second power layer or mix power and > signals just because most parts require two voltages and running split > power planes to the same part can be difficult. Another right answer :-) But consider: while the capacitance is larger to have 100 sqare inches rather than 16, the point where the open edges of the PCB make the plane capacitance worthless due to replections (think quarter wave antenna here) is 2.5x worse. The bulk capacitance is better but the board capacitance will "open circuit" at a lower frequency. As Howard Johnson pointed out in last week's Xilinx webcast, that point is rather moot for modern BGAs with the chips separated from the board by the "masking inductance" to where those higher frequencies are a problem for the BGA package or the chip itself. Small power islands can be good as long as they have the appropriate decoupling to augment the power supply's response. Closer power/ground spacing means better capacitance - there are esoteric products that reduce the spacing to the 2 mil and under range but I don't know of any PCB houses that use it. Smaller planes are actually better if you have high frequency/current devices that have minimal impedance to the board when mounted where that "masking inductance" isn't an issue and the size of the board dictates where the distributed capacitance becomes less effective. Luckily we don't have many situations where that's a worry. Resistance to the island is a concern. Capacitance on that island is a concern. One of the larger problems is when designers reference signals to those power islands and cross from island-to-island without significant decoupling island-to-island resulting in horrific crosstalk. If you want to reference signals to split planes, make sure they have a return current path that can *also* jump the plane split.
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