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
Hi all, Question on the clock routing in a Virtex 4 LX 25 that I haven't found the answer to today. I have an input clock, single ended, on a clock pin in the top half of the centre slice of the die. This clock has a IBUFG instantiated and is then connected to the clkin pins on two DCMs locked into the top half of the die and a BUFG which drives some clock monitor logic. The routing from the input buffer to the BUFG is on nice global pink (in fpga_editor) clock net, but the route to my two DCMs is on a normal general purpose net which Ts off this. Normally it is pretty direct, but depending on the build it sometimes goes through a couple of switch boxes. I am trying to stop this! I put a skew constraint on this net hoping to force it onto a global bus, but it just failed the constraint (~560 pS skew, 1.2nS delay to DCM pin if I remember correctly) The clock phase is important as I am sampling a DDR input bus, and I discovered this variation when I put some offset constraints on the input pins relative to phase shifted DCM output clock generated from this net. I thought the problem may be caused by having a BUFG on the same net, but removing this does not have any effect. I thought the software would use a direct connect from the IBUFG to the DCM input, and then adjust the phase of the DCM to compensate for the delay. (I am using a variable phase DCM here to dynamically tune my timing, is the routing delay from the IBUF a fixed offset???) If the routing is varing so much, is my input delay really being compensated? Perhaps it is the fact I am driving two DCMs which is breaking it, but I am a bit stuck with this? Using ISE software 9.1 sp3. Any thoughts anyone? Cheers, Mike.Article: 123076
Mike, I think perhaps you have figured it out: driving two DCM's from the same IBUFG and a BUFG may not be possible. Since you have FPGA_editor open, you should be able to see the direct path (only using IBUFG) to the DCM CLKIN pin. Are you able to place and route this path all by itself without issue? Obviously, this is the "normal" way of doing things, so this should work. Then see if you may add another CLKIN to that net (perhaps there is no way to do this -- FPGA_editor will show you the allowed control points....) If this is something you must do, and you use a variable phase shift, then the problem will be chip to chip variation. The jump off into regular routing can not be compensated for. As long as you remain without the classic use models, the data sheet specifications apply for worst case phase error. AustinArticle: 123077
"within the use model" not without.... AustinArticle: 123078
On Aug 14, 3:44 pm, Telenochek <elet.mir...@gmail.com> wrote:
> Hi everyone,
>
> I am using Xilinx ISE simulator for behavioral simulation of a large
> circuit.
> I would like to save simulated results, to avoid running the
> simulation again, which takes quite some time.
> However, when I use the "Save As" in Xilinx ISE, it DOES NOT save the
> results.
> I don't see any other options that would allow me to save data.
>
> My ISE version is 8.2.03i
>
> Any help would be greatly appreciated.
> Thanks!
> Tele
Hi Tele,
The current method of clicking on Save As in ISE is not implemented
and this is why it is not working. Although there is a way to get this
to work.
If you look in the ISE Simulator 9.2i docs, it has a section on how to
view simulation results after simulation:
Eventhough you have 8.2i, this will still work. The docs only had this
information in 9.2i that is why I pointed you to that doc.
Viewing a Waveform - Standalone Viewer
A simulation waveform can be displayed in the standalone isimwave
waveform viewer.
To View a Waveform in the Standalone Viewer
1. Save a copy of the simulation waveform you wish to view.
2. Open the simulation waveform in the isimwave viewer by
entering the follow command at a Windows=AE command prompt:
isimwave <filename>.xwv
where,
* <filename>.xwv is the file name of the simulation data file.
A static standalone waveform viewer opens and displays the waveform
for a previous simulation run. Waveform settings, such as markers,
dividers and signal order, are not stored in the .xwv file and will
not display in the standalone isimwave viewer.
Basically everytime you run a simulation in Proj Nav, you will get
a .xwv file and this can be opened standalone. For 10.1 Xilinx is
going to support the ability for you to save the waveform in the
simulation then you can go to file open in Project navigator and open
this xwv file. Then this will open inside project navigator. Currently
you can only do this using command line isimwave command.
Hope that this helps
Thanks
Duth
Note Currently this procedure can only be done through a Windows
command prompt. Integration of this procedure in the ISE=99 software is
currently being evaluated.
Article: 123079Evnin' Not final but a small step before Lattice is ready with their Linux (o; http://www.mico32.org/archive/articles/mico32_uboot.html cheers rickArticle: 123080
"Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message news:46c35630$1@clear.net.nz... > nospam wrote: >> m <martin.usenet@gmail.com> wrote: >> >> >>>On Aug 14, 3:42 pm, Peter Alfke <pe...@xilinx.com> wrote: >>> >>>>Huffman run-length encoding has been used successfully in early- >>>>generation fax machines. >>>>Whether that or any other compression (e.g. edge-detection) scheme is >>>>good, depends on the characteristics of the bitstream in question. >>>>Peter Alfke >>> >>>I should have also mentioned that there's a need to delay more than >>>one such pulse streams (at least four). That would require about >>>twenty 18K BRAMS...I use that many without going to a significantly >>>larger device. >> >> >> I think the description of your solution in your original post was rather >> confused. To me your "circular pulse transition list" needs to be a FIFO. >> If you >> only record transitions you need wide counters and FIFO to handle wide >> pulse spacing. A very long 1 bit FIFO is the opposite extreme. >> >> The optimum will be run length encoding with a FIFO width of something in >> between (assuming there is no pattern to the pulse data which a >> compression >> scheme could exploit). 1 bit to indicate the data state and n bits of >> count of clock cycles at >> that state. For multiple streams you can add more data bits and use only >> one set of encoding/decoding logic and one larger FIFO. > > A good idea, but what if you want co-incident edges ? > Perhaps a small phase-nudge field, that passes to the IO block, > and allow sequential FIFO unloads, but coincident IO edges ?. > > -jg The multi-bit data approach supports coincident edges. An event at time t presents a data value of 4'b0010 for a single pulse active. The event at time t+delta is 4'b0101 resulting in 2 pulses going active the same time as the original pulse deasserts. No nudging required.Article: 123081
John_H wrote: > "Jim Granville" <no.spam@designtools.maps.co.nz> wrote in message >>A good idea, but what if you want co-incident edges ? >>Perhaps a small phase-nudge field, that passes to the IO block, >>and allow sequential FIFO unloads, but coincident IO edges ?. >> >>-jg > > > The multi-bit data approach supports coincident edges. An event at time t > presents a data value of 4'b0010 for a single pulse active. The event at > time t+delta is 4'b0101 resulting in 2 pulses going active the same time as > the original pulse deasserts. No nudging required. Yes, you are correct, I was thinking of more compressed port-pointer storage, but if you store one-bit-per-port, then all ports can change. Becomes very like a dT logic anaylser in playback mode. -jgArticle: 123082
That did the trick -- I apparently wasn't searching for the right terms (SystemACE instead of just ACE). Thanks Kolja! On Aug 15, 2:29 am, "comp.arch.fpga" <ksuli...@googlemail.com> wrote: > On 15 Aug., 02:38, Kunal <kunals.spam.acco...@gmail.com> wrote: > > > I keep running into a System ACE problem on the ML405 when trying to > > get my own ACE file to load. > > > - I've properly formatted the CF card (as described in Answer Records > > #14456), and I've verified this by copying the demo files over and > > booting into them. The demos work fine, but when I select the custom > > ACE file from the menu, it fails and the ERR led turns on. > > Try the well hidden AR 25046http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountry... > > Kolja SulimmaArticle: 123083
Xilinx has three very similar kits: - Spartan-3A Starter Kit, - Spartan-3AN Starter Kit, and - Spartan-3A DDR2 SDRAM Interface Development Kit. Only the latter is promoted as supporting DDR2 @ 400 MHz, but the only difference listed between it and the Spartan-3A Starter Kit is the 133 MHz Crystal Oscillator and the lack of a 16 character, 2-Line LCD display. Is there some special about that kit, or will they all run the memory @ 400 MHz given the right oscillator? Thanks, TommyArticle: 123084
Tommy Thorn wrote: > Xilinx has three very similar kits: > - Spartan-3A Starter Kit, > - Spartan-3AN Starter Kit, and > - Spartan-3A DDR2 SDRAM Interface Development Kit. > > Only the latter is promoted as supporting DDR2 @ 400 MHz, but the only > difference listed between it and the Spartan-3A Starter Kit is the 133 > MHz Crystal Oscillator and the lack of a 16 character, 2-Line LCD > display. > > Is there some special about that kit, or will they all run the memory > @ 400 MHz given the right oscillator? > > Thanks, > Tommy No FPGA kits for low cost FPGA families will deliver 400 MHz DDR speeds. 400 Mbps/pin is more likely with most vendors supplying the 200 MHz DDR2 capability and a few up to 233 MHz. If you expect 800 Mbps/pin, you are mistaken. For support of 200 MHz DDR2 memories, it may be the other kits have troubles with routing that would support the needed timing. The "right" pins need to be selected for the highest speed support.Article: 123085
On Aug 15, 6:48 pm, John_H <newsgr...@johnhandwork.com> wrote: > No FPGA kits for low cost FPGA families will deliver 400 MHz DDR speeds. > 400 Mbps/pin is more likely with most vendors supplying the 200 MHz > DDR2 capability and a few up to 233 MHz. Thanks John. My bad, I should have written "DDR2 @ 400 MHz data rate", following the terminology of ug226. Anyway, I should had read ug334 as it answers my question. The answer is they can all do it (rev C of the Spartan-3A starter kit requires a rework though). Regards, TommyArticle: 123086
Hi Tommy, All three of these kits you mention have the slower -4 speedgrade component on them and will run the MIG-generated DDR2 controller at 133 MHz, giving you DDR2-266 performance. The recently announced support for DDR2-400 performance requires a faster -5 speedgrade component, and this solution was tested on Spartan-3A Starter Kits which had been built with the faster components. The demonstration design posted on the web will generally run in a slower -4 speedgrade component -- at room temperature and nominal supplies -- as a science experiment. If you want robust operation, you absolutely need the faster component. Eric -- and I believe all three of these kits have the oscillator. I think a natural question is "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message news:1187226750.867256.134160@i13g2000prf.googlegroups.com... > Xilinx has three very similar kits: > - Spartan-3A Starter Kit, > - Spartan-3AN Starter Kit, and > - Spartan-3A DDR2 SDRAM Interface Development Kit. > > Only the latter is promoted as supporting DDR2 @ 400 MHz, but the only > difference listed between it and the Spartan-3A Starter Kit is the 133 > MHz Crystal Oscillator and the lack of a 16 character, 2-Line LCD > display. > > Is there some special about that kit, or will they all run the memory > @ 400 MHz given the right oscillator? > > Thanks, > Tommy >Article: 123087
Ah, I know it's bad form to reply to my own post, but I noticed some straggling text at the end of my response, which is a note I forgot to complete... I believe all three of the kits actually have the 133 MHz oscillator. I think a natural question is why this isn't on the product descriptions. It has been the case on all of the Revision D kits I've material transferred to myself (now several dozen...) I've contacted the owner of the product descriptions and asked him to review your comments and correct any discrepancies. Given the content of my first post regarding DDR2 performance levels, if knowing the exact differences in the kits is going to affect your purchasing decision, please email me directly and I'll find someone with the answer for you. Thanks, Eric "Eric Crabill" <eric.crabill@xilinx.com> wrote in message news:fa0mc8$g2q2@cnn.xilinx.com... > Hi Tommy, > > All three of these kits you mention have the slower -4 speedgrade > component on them and will run the MIG-generated DDR2 controller at 133 > MHz, giving you DDR2-266 performance. > > The recently announced support for DDR2-400 performance requires a > faster -5 speedgrade component, and this solution was tested on Spartan-3A > Starter Kits which had been built with the faster components. The > demonstration design posted on the web will generally run in a slower -4 > speedgrade component -- at room temperature and nominal supplies -- as a > science experiment. If you want robust operation, you absolutely need the > faster component. > > Eric > > -- and I believe all three of these kits have the oscillator. I think a > natural question is > "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message > news:1187226750.867256.134160@i13g2000prf.googlegroups.com... >> Xilinx has three very similar kits: >> - Spartan-3A Starter Kit, >> - Spartan-3AN Starter Kit, and >> - Spartan-3A DDR2 SDRAM Interface Development Kit. >> >> Only the latter is promoted as supporting DDR2 @ 400 MHz, but the only >> difference listed between it and the Spartan-3A Starter Kit is the 133 >> MHz Crystal Oscillator and the lack of a 16 character, 2-Line LCD >> display. >> >> Is there some special about that kit, or will they all run the memory >> @ 400 MHz given the right oscillator? >> >> Thanks, >> Tommy >> > >Article: 123088
what's wrong with following error???? [root@184pc140 bin]# ./mb-gcc hello.c /home/devel/uclinux/bin/mb_tools/bin/../lib/gcc/microblaze/ 3.4.1/../../../../microblaze/lib/libc.a(write.o): In function `write': write.o(.text+0x34): undefined reference to `outbyte' write.o(.text+0x58): undefined reference to `outbyte' /home/devel/uclinux/bin/mb_tools/bin/../lib/gcc/microblaze/ 3.4.1/../../../../microblaze/lib/libc.a(read.o): In function `read': read.o(.text+0x2c): undefined reference to `inbyte' collect2: ld returned 1 exit statusArticle: 123089
On 16 Aug., 07:27, "Eric Crabill" <eric.crab...@xilinx.com> wrote: > Ah, I know it's bad form to reply to my own post, but I noticed some > straggling text at the end of my response, which is a note I forgot to > complete... > > I believe all three of the kits actually have the 133 MHz oscillator. I > think a natural question is why this isn't on the product descriptions. It > has been the case on all of the Revision D kits I've material transferred to > myself (now several dozen...) I've contacted the owner of the product > descriptions and asked him to review your comments and correct any > discrepancies. Given the content of my first post regarding DDR2 > performance levels, if knowing the exact differences in the kits is going to > affect your purchasing decision, please email me directly and I'll find > someone with the answer for you. > > Thanks, > Eric > > "Eric Crabill" <eric.crab...@xilinx.com> wrote in message > > news:fa0mc8$g2q2@cnn.xilinx.com... > Xlinx S3A starterkit (and I belive S3-AN) kit have 50MHz oscillator and to my knowledge DDR2 solution will NOT work at 200MHz bus rate Xilinx tools have BIG TROUBLE meeting timings at 133Mhz already I have hard times beliving that the same design woud work at 200MHz as science experiment (at room temperature) AnttiArticle: 123090
Hi, There's nothing wrong with the error. Quite the contrary. It shows you that the linker (ld) is able to do correct checks of the used references in your compiled object codes. Furthermore it is so kind to inform you about missing ones and that it can't proceed it's work unless YOU provide consistent sources and/or libraries to work with. ;-) So where do you think outbyte and inbyte come from? The linker wants to know. You have to tell it. Good luck Eilert kobelai15@gmail.com schrieb: > what's wrong with following error???? > > [root@184pc140 bin]# ./mb-gcc hello.c > /home/devel/uclinux/bin/mb_tools/bin/../lib/gcc/microblaze/ > 3.4.1/../../../../microblaze/lib/libc.a(write.o): In function `write': > write.o(.text+0x34): undefined reference to `outbyte' > write.o(.text+0x58): undefined reference to `outbyte' > /home/devel/uclinux/bin/mb_tools/bin/../lib/gcc/microblaze/ > 3.4.1/../../../../microblaze/lib/libc.a(read.o): In function `read': > read.o(.text+0x2c): undefined reference to `inbyte' > collect2: ld returned 1 exit status >Article: 123091
hi i am designing ahb arbiter . In which i am using hmaster_lock as output signal . when i am doing synthesis on xilinx 6.3 it is giving warning WARNING: FlipFlop hmaster_lock has been replicated 1 time(s) to handle iob=true attribute. pls help me why this warning is comming thanks ankurArticle: 123092
hi i am designing ahb arbiter . In which i am using hmaster_lock as output signal . when i am doing synthesis on xilinx 6.3 it is giving warning WARNING: FlipFlop hmaster_lock has been replicated 1 time(s) to handle iob=true attribute. pls help me why this warning is comming thanks ankurArticle: 123093
Thanks Austin, as always. I couldn't find anything in the documentation which said you couldn't directly drive two DCMs using the fast path, in fact Xilinx recommend driving the DCMs in parallel to avoid jitter accumulation. More editor playing required .... I can live with this as long as I constrain the net between the IBUFG and the DCMs well enough, I have a fair margin on my input bus, the output is source-synchronous so I don't care. If I move the DCMs to the BUFG side (so, IBUFG -> BUFG -> LOGIC + 2 DCMs) then I guess I will have to compensate for the BUFG delay in my DCM phase set up? Regards, /Mike "austin" <austin@xilinx.com> wrote in message news:f9vr9h$g1q1@cnn.xilinx.com... > Mike, > > I think perhaps you have figured it out: driving two DCM's from the > same IBUFG and a BUFG may not be possible. > > Since you have FPGA_editor open, you should be able to see the direct > path (only using IBUFG) to the DCM CLKIN pin. Are you able to place and > route this path all by itself without issue? Obviously, this is the > "normal" way of doing things, so this should work. Then see if you may > add another CLKIN to that net (perhaps there is no way to do this -- > FPGA_editor will show you the allowed control points....) > > If this is something you must do, and you use a variable phase shift, > then the problem will be chip to chip variation. The jump off into > regular routing can not be compensated for. As long as you remain > without the classic use models, the data sheet specifications apply for > worst case phase error. > > Austin >Article: 123094
Hi,
float deneme1;
float deneme2;
float deneme;
deneme1=1.1;
deneme2=1.1;
deneme=deneme1*deneme2;
I changed the code like that.still i am facing with the same error.
Article: 123095Hi, So how large is your program and how much memory do you have in your system? Göran "mfgunes" <mfgunes@yahoo.com> wrote in message news:EtadnXH3WauRYl7bRVn_vgA@giganews.com... > Hi, > > float deneme1; > float deneme2; > float deneme; > deneme1=1.1; > deneme2=1.1; > > deneme=deneme1*deneme2; > > I changed the code like that.still i am facing with the same error.Article: 123096
Hi,
I need to implement a fairly simple Compact Flash Interface on a
Spartan 3 400.
The only thing it needs to do is write incoming data on the card,
nothing else.
I want to do this with a simple state machine, and
the rough plan for this looks like this:
1=2E Check status register (mustn't be busy or request data (bits 7 and
3 =3D 0))
2=2E write sector number and LBA address
3=2E write the "write sector" command
4=2E write data
I have problems with point 1. :)
The card works in trueIDE mode.
I wanted to start the whole thing in pio mode 1 to see if it works at
all,
and then find the max. speed for the cards (maybe 4).
Anyway, I follow the timings for trueide mode from the cf paper:
[URL=3Dhttp://img442.imageshack.us/my.php?image=3Dtimingsgw1.png]
[IMG]http://img442.imageshack.us/img442/2521/timingsgw1.th.png[/IMG][/
URL]
I checked the timings with modelsim (they are ok), and also with a
oscilloscope:
[URL=3Dhttp://img459.imageshack.us/my.php?image=3Dosziscanik5.jpg]
[IMG]http://img459.imageshack.us/img459/6071/osziscanik5.th.jpg[/IMG][/
URL]
I monitored one of the address-signals to see when the address is
valid, and the iord-signal (low active).
My problem is, that I get bullshit from the registers.
I tried reading different registers, and here are some results
(with a small 16mb card and a big 2gb card):
feature register: 1111 1110 1000 0100 - FE84 - small
feature register: 0100 0000 0100 0000 - 4040 - big
Status register: 1111 1110 1000 0100 - FE84 - small
Status register: 0100 1000 0100 1000 - 4848 - big
LBA1: 0100 0000 0100 0000 - 4040 - big
0100 1000 0100 1000 - 4848 - gro=DF 2nd turning on
LBA1: 1111 1110 1000 0100 - FE84 - small
Sector count: 0100 0000 0100 1000 - 4048 - big
Sector count: 0100 0000 0100 1100 - 404C - 2nd big
Sector count: 0000 0100 0000 0000 - 0400 - big next morning
Sector count: 1111 1110 1000 0100 - FE84 - small
As you can see, I get totally different values, and they don't seem to
make sense.
Here's my slightly cut code for the state machine.
This does only read the status register and show the results on some
led:
http://www.mikrocontroller.net/attachment/25436/CF_SM.vhd
Any help/hint is highly appreciated.
Article: 123097"RCIngham" <robert.ingham@gmail.com> writes: > Keep increasing the memory until the error messages go away. > Ah, so that's how Word got as big as it did :-) > Note that "multiply by 0.5" is equivalent to "divide by 2" is equivalent > to (for integer variables) "shift right by 1". If you don't mind truncating instead of rounding: 5.0/2.0=2.5, which most people would expect to round up to 3. If you do it in integer land, 5/2 = 2 5 shr 1 = 2 with the bit representing .5 thrown away, unless you take pains to keep it. If this doesn't matter for your application that's fine. On a side note, I'd rather write (and then later read) "/2" if that's what I mean than use a shift (irrespective of rounding issues). A decent compiler will do the shift for me if that's the best way of doing it. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 123098
> Any help/hint is highly appreciated. there is one simple generic hint: before doing the VHDL statemachine etc, just connect the CF to Microblaze GPIO and write simple C program that bit bangs the CF, when that works on your board you know the HW connections are all ok, and that you know the interface. when that works then proceed with VHDL implementation AnttiArticle: 123099
First of all: Peters observation is correct. While even for a dynamic of 10:1 you should have more wires per routing channel, you do not see much of that in real fpgas for practical reason. A regular structure is simpler to design, test, write software for, etc. So I expect Xilinx to design the routing based on the requirements of the large parts. Maybe a little on the short side. This means that the small devices have more wires than needed. But as yield is an exponential function of size the economic impact of extra wires is not as important for smaller devices. However in some families you seed routing structures that only appear for larger devices. For example in Coolrunner the macrocells are grouped. The smallest device has only one group (dont remember the name of the group in Xilinx Lingo) with routing in the group. The next device has two groups, plus routing between them. Some families of some vendors increase the number of wires in all routing channels for larger devices or add an additional long distance routing ressource in the center of the FPGA for larger devices. Were you see rents rule in action is the design of the routing hierarchy of a single FPGA. Count the number of terminals of a Slice, of a CLB, of all CLBs connected to the same switchbox, of a clock region, of a half FPGA, of the whole FPGA. It is likely to grow roughly at the expected rate. On Aug 15, 7:14 pm, Pasacco <pasa...@gmail.com> wrote: > For example, suppose : > Xilinx FPGA has a regular structure of CLBs. > Each CLB contains one SWITCH BOX and 4 SLICEs. > Each SLICE has approximately 40 pins. > Each CLB has approximately 400 pins. > > Consider, device 1 has 100 CLBs and device 2 has 10000 CLBs. > > According to your posting: > Device 2 is supposed to have "100^1.5" times more wires than device 1. > Device 2 is supposed to have "100^2" more area than device 1. > Am I understanding correctly? Yes, were roughly. The better formulation is: A design in the large device is expected to use about that much more wires than a typical design in a large device. The manufacturer might chose to deviate from that for other reasons. Also, this is a typical value. Designs vary. A smith-waterman pattern matcher has a rent exponent of 0, so does an SRAM. > It was mentioned that: > -------------------------------------------------------------- > Number of wires grows at a rate of somewhat over g^1.5 and the area > of the wires (because the avarage length is g^0.5) grows faster than > g^2 > -------------------------------------------------------------- > > Could you please explain why : > > (1) Average length is "g^0.5", > ==> Does this 'length' mean by "wire length" ? > How did you obtain the value '0.5' ? What is the maximum distance in a chip with 100 LUTs laid out as a square? What is the maximum distance in a chip with 10000 LUTs laid out as a square? > (2) Number of wires grows over "g^1.5", > ==> How did you obtain the value '1.5' ? This is the result of Rents expirments in the 60ies. They have been verified many times in later experiments, also for FPGAs. Actually Rent counted terminals, but the wires are roughly proportional to terminals because must wires have a very low number of terminals on them. > (3) Area of wires grows faster than "g^2" ? > ==> How did you obtain the value '2' ? Number of wires times length of wires... Kolja Sulimma Kolja Sulimma
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