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
Luc, There is always "room for one more." As for what Lattice is offering, I have said it is impressive, and has some really nice features. I have also said that their fab partner is "world class" and presently on the cutting edge. How they will proceed to 45nm, and then 32nm, and so on is of course another matter altogether... Look at Altera: they can't influence TSMC, so they have no high speed 65nm process. Nada, nothing, nowhere. They are just too small to influence TSMC's business model. If TSMC leads with the low power cell phone process, then we will continue to have a 1-2 year lead on every technology cycle. Crikey! That has got to hurt! I will venture to say that our 200 Xilinx FAEs and our 200 disti FAEs are the best in the world, and that there is no company that can even come close to our support. The experience (some 25+ SI experts), the RocketLabs (12 locations, the use of millions of dollars of equipment, combined with experts, and working designs), our 40+ MGT characterization reports for every possible standard....the list is actually too long to list here! Not to mention, that no one has a 'Peter Alfke' (12,000 hits on Google), nor an 'Austin Lesea' (827 hits -- after all, I am still pretty much the 'baby' here at Xilinx!). We are just crazy enough to help anyone succeed (with Xilinx FPGAs). I have in no way suggested that Lattice has any failings whatsoever, other than suffering from being small. Personally, I love a challenge, and since Altera offers none, Lattice is welcome to join the game. AustinArticle: 120476
It looks like the basic tool setting doesn't have Virtex-E in the pick-list. Xilinx (in the form of an FAE or Austin) can tell what the last version is that natively supports the Virtex-E or if there's a way to enable it in current tools. Have you considered building your own dynamic coefficient multiplier? If you have a large number of multipliers, it's helpful. If you have one or two, it's probably not worth the effort. The task ends up pretty simple since you're using three memories with a total of about 37 bits to generate 3 values you add together. It's just a matter of programming those 37 LUTs through (ideally) shift registers. The intelligence to generate the coefficient stream is a few LUTs and a lot of thought. "Marlboro" <ccon67@netscape.net> wrote in message news:1181249528.963483.273840@w5g2000hsg.googlegroups.com... > I'm gonna use the luxury multipliers then, althought port B will be > updated once per day :))) I have newer ISEs handy but have not > installed them yet. Is that true ISE 9.1 doesn't support Virtex-e or > just the Wizard? > > On Jun 7, 3:35 pm, "John_H" <newsgr...@johnhandwork.com> wrote: >> "John_H" <newsgr...@johnhandwork.com> wrote in message >> >> news:136god3hjd0oa7f@corp.supernews.com... >> >> > The Xilinx Multiplier v9.0 from the architecture wizard has a >> > constant-coefficient multipler. >> > What are you using to generate the dynamic constant multipler? >> >> I missed that the subject line specified CoreGen 7.0. >> I don't know that there's an equivalent multiplier in CoreGen 9.1.01i. >> The same "Multiplier v9.0" came up in CoreGen that was in the >> Architecture >> Wizard. >> There was also no "Virtex-E" family listed in the default menu of this >> newer >> tool version.Article: 120477
"austin" <austin@xilinx.com> wrote in message news:f49qvq$pau1@cnn.xilinx.com... > Mike, > > Wow. 0.5UI is a lot of margin. It really is. > > And, yes, I think we can recover some more "eye" for you, and increase > your margin further. > > I suppose since no one has emailed me for the "bad" anti-resonant > powerpoint slide, we don't have any "unbelievers" here. > > Fact is, doing a sweep of IO switching over frequency will show if there > are any "really bad" places in your power distribution network (vs > frequency). > > Doing a network analysis (using a variable frequency RLC meter, or a > VNA -- although a VNA is not very good at milli-ohm impedances), will > confirm that at some frequencies, the bypassing is all but non-existent. > > Austin I'm a believer *and* I'd like to see the slides but I figure it would be more useful in an application note than as a stand-alone slide that I'd lose on my hard drive somewhere. I'd love to see proper power-distribution design used more widely.Article: 120478
On Jun 6, 9:36 pm, Ken Ryan <newsr...@leesburg-geeks.org> wrote: > antoine.ver...@gmail.com wrote: > > Hi, > > > I'd like to get some help from experienced people because I'm really > > running low on ideas here.. I'm a beginner in FPGA/LwIP and I can't > > seem to make it work using Xilinx EDK 8.2i. > > > I've been creating a project using BSB including onewire, uart, emac > > and the external memory and using PPC. > > Once I am in the project manager, I did all of the required > > modifications to boot up on the bram and execute the code from the > > external memory, set up the -llwip4, checked the lwip 2.00a and set up > > the MAC address. > > Once i compile, it works fine, initializing a server code I took as an > > example and printfs display everything is fine but it is impossible to > > connect to the card or even ping it. > > > Could someone give me a hint about what I m doing wrong? > > Just a few "silly" questions: > > Did you go through the section of lwip documentation talking about > configuring xilkernel? > > Did you also include -lxilkernel? > > I assume you're appropriately setting IP address and mask? > > Did you try building the example design in the lwip page on the xilinx > website (there are several, pick the one closest to your hardware)? > > Did you try turning on the verbose debugging switched in the lwip and > xilkernel driver configs? > > I'm sure none of those are news, but sometimes I find I missed something > basic... > > ken well, I didn t bother about the xilkernel since i want to use the raw api or should i set something anyway? I tried building several code including the 663 example from xilinx, everything runs fine, no errors but no connection detected.Article: 120479
by request ... deleted ... Best Regards, A_RequesterArticle: 120480
austin wrote: <snip> > If a dedicated bank, or even dedicated hard IP (which they also offer > for some interfaces) looks like a great idea, then perhaps some future > offering from Xilinx might have something similar. Until then... Hard IP is certainly the pathway for highest performance, so it is a question of when, not if. FPGAs also overlap with devices like this : http://investor.amcc.com/releasedetail.cfm?ReleaseID=247168 For $14/10K, you get 2.5GBps PCI express, GBit Etherenet, 480 MHz USB and a 1000DMIPS PPC CPU - and if all that allows you to choose s smaller/cheaper FPGA, for 'just the programmable stuff' (it only has to save $14...), then that design combination gets traction. -jgArticle: 120481
I would like to use Virtex5 FPGA to output 16 differential channels at 800Mbps source synchronously. I am planning to use bufio to minimize the clock skew internally. Bufio has about 50ps skew on the clock input of 16 oserdes. I would like to know roughly how much output skew will be there between the 16 channels. Thanks. MavrickArticle: 120482
While trying to minimize my microcode implementation to implement a small 6502 CPU, eventually I designed a new Forth CPU: http://www.frank-buss.de/vhdl/forth-cpu2.html I would like to have a full Forth system for it, which could run at about 4 MIPS with a 50 MHz clock on a FPGA with internal block RAM. This could be at least doubled with some more thinking about the RAM interface. With this system I can implement a 6502 CPU emulation :-) But first I would like to hear some comments. What do you think about the instruction set architecture (ISA)? Any ideas how to modify the VHDL code (see bottom of the page) or the ISA to use less LEs, but without impact on the compactness of code for the CPU? At the bottom of the page you can find a full Quartus 7.1 project for testing it. Looks like adjusting some settings can increase or decrase the number of LEs by 20% and more. E.g. when changing "Auto RAM replacement" to "On" in "More Settings" in "Analysis & Synthesis Settings" increases the LE count from 590 to 697 LEs, which is strange, because I would expect that replacing registers and logic with RAM should save LEs, and if not, the compiler should not use it. When the design is finished, I want to implement an assembler for the system in Forth. How could the mnemonics look like and are there any good examples of assemblers in Forth, which could be used to implement my ISA? For testing, an emulator would be nice, too, but this should be easy to implement, because of the simple and orthogonal ISA. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 120483
Mavrick, In general, each IO off the clock distribution is ~ 10ps. So 16 IO's, 160 ps. If you route the IOs across to another Xilinx part, and 1 for 1 connect them to a bank in the same fashion, then the skew between IOs cancels at the receiving end the skew induced at the driving end. I would draw a picture to illustrate, but I can't draw very well with ---, ...., and ||||! I think you get the idea. If you route across to some other device, then you may have to take this skew into account, as well as the package skew, and make all lengths exact to compensate. Even from X to X, you may have to take the "flight time" of the package into account. AustinArticle: 120484
On Jun 7, 3:54 pm, Eric Smith <e...@brouhaha.com> wrote: > willwestw...@gmail.com writes: > > I hope I explained ok here. I'm having trouble putting this behavior > > into codes in VHDL. Someone has any idea? > > How would you design it with logic gates (and flip-flops, if required)? > > Once you know that, you can just do the same thing in VHDL. Yes you can do it in logic gates, but I want behavior modeling. If using FF and logic gates, it would make this totally a netlist coding. Here is the Requset, Reset, and Acknowledge again: Request(0 to 3): 0000 1010 0110 1101 0010 1001 0001 1000 1011 1011 1000 0101 1001 Reset: HHHHLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLHHHHLLLLLLLLLLLLLLLLLLLLL Ack(0 to 3): 0000 1000 0010 0100 0010 1000 0001 1000 0000 1000 1000 0100 0001 I also plan to convert this code into Verilog, C or C++ later on, so if you have algorithm or codes in those languages, it's fine too.Article: 120485
On Jun 7, 9:22 am, Mavrick <dmo...@comcast.net> wrote: > Thanks Jim. I will read about the Adept software. I am trying to use about 100 oserdes in a source sunchronous application. The oserdes output is brought external to the V5 FPGA. But at this point I am trying to understand the factors that can introduce skew on the source synchronous output at the output pins of the FPGA. > > Three factors come to mind are > > (1) Clock skew - This can be mitigated by using bufio instead of bufg (2) Internal Trace routing mismatches from oserdes to the the pad - Don't know how to mitigate this one consistantly. (3) Internal routing mismatch from internal flip-chip pad to the fpga pin (?) - This can possibly mitigated by adjusting the board trace lengths. > > Basically I am trying to minimize the skew. Any guidance along those lines will be great. > > Thanks. Not sure what exactly you are trying to do. The BUFIO input can only come from a clock capable pin, so I don't know how you are going to forward a clock for your source synchronous application. Also the BUFIO can only reach max 40 IOs in V5. BUFIO is mainly for source synchronous data capture application. Cheers, JimArticle: 120486
Grant Stockly wrote: > I'm trying to figure out what kind of performance I could get out of an > FPGA. After describing the project I'm wondering if it would be better > to use a hardware micro and a CPLD??? IMHO an FPGA is overkill and a micro+CPLD would be perfectly adequate. You're basically implementing a sector buffer and bus protocol conversion - given the access times involved you'd easily be able to implement the bulk of the smarts in software on a modern micro. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 120487
Austin, Can you please explain why the skew is multiplication of # of outputs and clock skew? This means that if I have 32 outputs then the skew from one output to the other will be 320 ps. For 64 outputs it will be 640ps. At some point this may become difficult to support by the target device. MaverickArticle: 120488
Patrick Dubois wrote: > I > sold the idea around here to use the Avnet FX12 mini-module as a nice > solution to ethernet connectivity. I thought that there would be lots > of working examples for it (as ethernet seems to be its biggest > selling point). Wrong. Hoboy, you stepped on a rant there. :-) I initially procured the Avnet v2pro FF672 board with the comm3 module. I figured, how could I go wrong, there's an example design that does 90% of what I want to do - the only bit missing was a specialized gigabit serial link that I could adapt from a previous design. I checked out the board, the example seemed to work OK, so I proceeded with my design. Then sometime later I connected the board to my company's intranet - instead of a private wire link. Wham, the TCP stack fell over, crashed the processor hard. This was my introduction to xilnet. Then I realize that EDK didn't support the 91C111 MAC that was on that board - I'd have to port an ethernet stack myself. The Avnet demo was a hacked-up port of xilnet with a very rudimentary driver, and completely useless for anything halfway realistic. I actually started down the path of porting Linux to the board, when I discovered another problem. The comm3 module uses all 3.3V signaling to the FPGA. The FF672 board has a bank voltage select to support it. Unfortunately *some* of the I/Os come from a fixed 2.5v bank. So Avnet's stack was driving about a half-dozen 2.5v inputs with 3.3v levels. I considered switching to the comm2 module, but when I looked at the schematics I saw the same problem. Eventually I got hold of someone in the know at Avnet; turns out that was a known design bug, known for a long time (through two design generations!). My mood wasn't helped by the complete and utter failure to get their SystemAce Module to work (I eventually gave up and tossed it in a drawer to rot). Normally when one uses one of these development boards one is just fiddling with it or experimenting. Sometimes we want to embed it into a product, if it's appropriate. This was to go into some equipment with a fairly long expected lifetime, so I couldn't afford to have hardware I knew would eat itself. $4500 and six weeks down the drain. I turned the Avnet sales rep's ears around for that one. Avnet is great with the vast majority of what they do, but it'll be a long time before I consider another of their development boards for anything more sophisticated than fixing a short table leg. Now I'm going through the process of finding all the other little surprises (I went to an ML405 board; much better piece of hardware thought it took me a while to port my rocketio design). OK, I'll quit frothing now... kenArticle: 120489
antoine.vernay@gmail.com wrote: > well, I didn t bother about the xilkernel since i want to use the raw > api or should i set something anyway? > I tried building several code including the 663 example from xilinx, > everything runs fine, no errors but no connection detected. Well, I believe xilkernel is theoretically needed even with raw api. In any case, I've never tried raw mode myself, but I thought I saw posts in this NG that said raw mode doesn't actually work yet. You might try pulling out the driver layer from some of the demo code (there is a Temac_Test application somewhere, in the lwip demo maybe?) and see if you can build up something from there? kenArticle: 120490
Mavrick, It is called the speed of light in silicon. The clock distribution has skew with distance. All chips have this to some degree or another. If a design has no skew at all, it is called a "customer ASIC" which was designed to be that way. It is not required to make an interface work, so it just has to be taken into account. AustinArticle: 120491
I have upgraded to EDK 9.1 and am trying to generate the HDL simulation files. I have successfully compiled both the ISE libraries and the EDK libraries. They live in C:\xilinx_sim_libs and C: \xilinx_sim_libs\EDK respectively. I have set the EDK to point to both those paths. Whenver I click 'Simulation->Generate Simulation HDL Files' I get the following pop up error: "ISE Sim Library: XPS can not get library information from the path <C: \xilinx_sim_libs>. Please make sure it contains the libraries compiled with the same simulator and HDL as you set in the GUI, and with current EDK/ISE version." If I click OK, it takes me to the 'Edit->Preferences' screen. The paths are set up correctly. I fiddled around with those paths (switched '/' to '\') and I got the same error but for both the ISE libraries and the EDK libraries. I recompiled the ISE libs making sure that the correct simulator path was chosen. I did this in GUI b/ c it won't work directly from the EDK. Anyways, everything seems in order. This worked for EDK 8.2. I think I got the same error, but the software continued generating the sim files correctly. Any advice?Article: 120492
"austin" <austin@xilinx.com> wrote in message news:f4a388$pba1@cnn.xilinx.com... > Mavrick, > > In general, each IO off the clock distribution is ~ 10ps. So 16 IO's, 160 > ps. > > If you route the IOs across to another Xilinx part, and 1 for 1 connect > them to a bank in the same fashion, then the skew between IOs cancels at > the receiving end the skew induced at the driving end. > > I would draw a picture to illustrate, but I can't draw very well with ---, > ...., and ||||! > > I think you get the idea. > > If you route across to some other device, then you may have to take this > skew into account, as well as the package skew, and make all lengths exact > to compensate. > > Even from X to X, you may have to take the "flight time" of the package > into account. > > Austin I had never thought about this, but I'll bet your internal edge times are starting to get close to the intra-silicon transit times. Do you (Xilinx) do any type of termination on the clock distribution nets? If so, it seems like you'd have to use end termination (as opposed to source termination). Wild and weird stuff! BobArticle: 120493
Bob, As per my understanding using the bufio the fpga internal clock tree skew is 50 ps. I am still not able to understand the 10 ps skew per fpga output pin and you multiply that by the number of outputs used. Is this 10ps skew due to mismatch in trace routing inside the fpga? If so why we need to multiiply by the number of pins used? MavrickArticle: 120494
Wojtek, If you are using "derive_pll_clocks", there is no way to customize the generated clock name, so you only get the two choices. But you do not need to use "derive_pll_clocks". Instead, you can simply add your own create_generated_clock statements, and use the "- name" argument to name your clock exactly the way you want it. The best way to do this is to first call derive_pll_clocks, and then look for the messages that indicate exactly the generated clocks that were created. Then copy the commands into your golden SDC file and then simply modify the "-name" argument. You can also check the generated clocks from "report_sdc" or you can use "write_sdc" to generate a copy of the SDC with the generated clocks (but be careful to give write_sdc a different file name not to overwrite your golden SDC file). Obviously, this is a tradeoff between: 1) the convenience of TimeQuest generated PLL clocks for you and ensuring that you always get the right clock every time you change the PLL settings. But having to use the pre-defined clock name 2) the flexibility to name the clock your own way, but forcing you to have the discipline to change the SDC file every time you change the PLL settings We are considering adding a way to rename the clock, exactly to allow users to get the best of both worlds, but we currently do not have any release date for that. Hope this helps and that you are enjoying the benefits of TimeQuest. -David Karchmer TimeQuest teamArticle: 120495
Wojtek, I forgot to say that if you are using Quartus II V7.1, TimeQuest will cross check the clocks defined in the SDC with the PLL settings, and will give warnings if it finds any differences. This in case you go with the explicit create_generated_clocks but you forget to edit the SDC after modifying the PLL settings. -DavidArticle: 120496
Mavrick wrote: > Bob, > > As per my understanding using the bufio the fpga internal clock tree skew is 50 ps. I am still not able to understand the 10 ps skew per fpga output pin and you multiply that by the number of outputs used. Is this 10ps skew due to mismatch in trace routing inside the fpga? If so why we need to multiiply by the number of pins used? > > Mavrick My interpretation of Austin's comment in a bad analogy: A mail truck delivers the clock edge to each house (each oserdes) driving at a speed that gets 10 ps between mailboxes. If the clock distribution is a single wire for those oserdes, it's like one street for the mailman, all happening one direction.Article: 120497
On Jun 7, 3:44 am, Grant Stockly <g...@stockly.com> wrote: > I have been trying to find the time to start a project with an FPGA > for a while and I think I've finally found one. I've messed around > with my Digilent FPGA development board but I have never created a > full featured standalone application. Get your application working on that. You can't even buy the parts to build a one-off board for the price of the digilent board with the chips already installed. > I want to take a modern FDC I/O controller and connect it to my Altair > with an 8080 processor. I understand the S-100 connections and the > operation/connections of the FDC controller. The thing I need advice > on is the FPGA in the middle. You might want to think about using a flash memory card instead of a physical disk... a bit more reliable and even easier to source today. > I have not completed my research, but I don't think the 8080 is fast > enough to keep up with a 1.4MB disk. This is one reason I would need > the FPGA, to buffer one sector of data and then handle transmission to > the FDC IC. If you are only handling a sector, you may be able to use a state- machine like architecture rather than a processor core. All you really have to do is grab the data from one sector quickly, and then let the 8080 read it out more slowly. Or maybe you can build a DMA state machine and dump it into memory? I'm almost suprised the controller doesn't have the sector buffer built in, but then I guess that would have been a non-trivial amount of memory in that day and age. Keep in mind that you can let the disk spin between sectors - you don't have to pull them off consecutively. If you figure out the inter sector time that you can actaully read consecutively, you can devise a sector interleaving format to minimize the waiting. > Another reason I will need an intermediate device (the FDC is 8 bit) > is because I want the controller to be compatible with all MITS > software. To do this I will need to emulate the simple MITS hard > sector disk controller. Understanding the controller is not a problem > for me. I would assume controllers of that vintage would be state machines and not microprogrammed machines... but then I could be wrong. Generally things like this are easier to accomplish with a microcontroller, quite likely not needing an FPGA or CPLD at all - the challenge is communication with the host. If you need to present a register interface or something dependent on the host's timing, there having and FPGA to bridge the busses could be good. But the possibility exists that a really fast micro could even talk the 8080 bus transactions in software! But it should all be implementable in a state machine, too. > What would the suggested core be for a project like this? If I have a > 100,000 gate FPGA running with a 50MHz oscillator, how fast should an > average risc core run? A small one if you want a little FPGA. Clock speed is not going to be an issue, since you can do the timing critical stuff (host bus interface) with state machine logic rather than processor cycles.Article: 120498
Mavrick wrote: > Bob, > > As per my understanding using the bufio the fpga internal clock tree skew is 50 ps. I am still not able to understand the 10 ps skew per fpga output pin and you multiply that by the number of outputs used. Is this 10ps skew due to mismatch in trace routing inside the fpga? If so why we need to multiiply by the number of pins used? I get 1mm as around 5ps (0.67 vf), so you can get the order of the physical skews from that. -jgArticle: 120499
PLEASE HELP: I also have a question on Asynch. RAMs:
In my design I have a bank of memory made up of 64 reg[31:0]'s. They
get synthesized into latches, and kill my timing because of a huge 64
X 32 sensitivity list.(See below).
How else can I synthesize a 64X32 block of Memory with Asynch Read,
Asynch Write, and where the Data_In
shows up immediately on the Data_Out?
Can I do it with Xilinx CoreGen Modules?
always @ (rd_address or q0 or q1 or q2 or q3 or q4 or q5 or q6 or q7
or q8 or q9 or qa or qb or qc or qd or qe or qf
or q10 or q11 or q12 or q13 or q14 or q15 or q16
or q17
or q18 or q19 or q1a or q1b or q1c or q1d or q1e
or q1f
or q20 or q21 or q22 or q23 or q24 or q25 or q26
or q27
or q28 or q29 or q2a or q2b or q2c or q2d or q2e
or q2f
or q30 or q31 or q32 or q33 or q34 or q35 or q36
or q37
or q38 or q39 or q3a or q3b or q3c or q3d or q3e
or q3f)
begin
case (1'b1) // synopsys full_case parallel_case
rd_address[0]: DO = q0;
rd_address[1]: DO = q1;
rd_address[2]: DO = q2;
rd_address[3]: DO = q3;
rd_address[4]: DO = q4;
rd_address[5]: DO = q5;
rd_address[6]: DO = q6;
rd_address[7]: DO = q7;
rd_address[8]: DO = q8;
rd_address[9]: DO = q9;
rd_address[10]: DO = qa;
rd_address[11]: DO = qb;
rd_address[12]: DO = qc;
rd_address[13]: DO = qd;
rd_address[14]: DO = qe;
rd_address[15]: DO = qf;
rd_address[16]: DO = q10;
rd_address[17]: DO = q11;
rd_address[18]: DO = q12;
rd_address[19]: DO = q13;
rd_address[20]: DO = q14;
rd_address[21]: DO = q15;
rd_address[22]: DO = q16;
rd_address[23]: DO = q17;
rd_address[24]: DO = q18;
rd_address[25]: DO = q19;
rd_address[26]: DO = q1a;
rd_address[27]: DO = q1b;
rd_address[28]: DO = q1c;
rd_address[29]: DO = q1d;
rd_address[30]: DO = q1e;
rd_address[31]: DO = q1f;
rd_address[32]: DO = q20;
rd_address[33]: DO = q21;
rd_address[34]: DO = q22;
rd_address[35]: DO = q23;
rd_address[36]: DO = q24;
rd_address[37]: DO = q25;
rd_address[38]: DO = q26;
rd_address[39]: DO = q27;
rd_address[40]: DO = q28;
rd_address[41]: DO = q29;
rd_address[42]: DO = q2a;
rd_address[43]: DO = q2b;
rd_address[44]: DO = q2c;
rd_address[45]: DO = q2d;
rd_address[46]: DO = q2e;
rd_address[47]: DO = q2f;
rd_address[48]: DO = q30;
rd_address[49]: DO = q31;
rd_address[50]: DO = q32;
rd_address[51]: DO = q33;
rd_address[52]: DO = q34;
rd_address[53]: DO = q35;
rd_address[54]: DO = q36;
rd_address[55]: DO = q37;
rd_address[56]: DO = q38;
rd_address[57]: DO = q39;
rd_address[58]: DO = q3a;
rd_address[59]: DO = q3b;
rd_address[60]: DO = q3c;
rd_address[61]: DO = q3d;
rd_address[62]: DO = q3e;
rd_address[63]: DO = q3f;
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