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
> I've previously had problems with XST + hierarchy + registered > tristates, with a 'fix' being placing the IO tristate stuff all > at the top level. What would be nice is a latched IOB tristate primitive. Brad Smallridge AiVisionArticle: 130201
"FPGA" <FPGA.unknown@gmail.com> wrote in message news:b799694d-48d2-4ebb-92e4-0953385d8a52@b64g2000hsa.googlegroups.com... >I wish to design a FIFO to tansfer data from a high speed clock > domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use > the cores available from any of the vendors. If I was you, I really would use a vendor-supplied core. Xilinx and Altera (and I suspect others) provide these free and they've been well tested in many, many designs. The port names may differ between different vendors but you can make the FIFO virtually vendor-agnostic by providing a trivial wrapper to name the ports as you wish.Article: 130202
Antti wrote: > I used PIC when PIC15C54 was "hot", as they had almost > no competition. I changed to AVR as they are better. Better for some things, not for everything. I had several designs using PICs for which AVRs would not have been fast enough. (There are faster AVRs now, but there are faster PICs too.) If one were to pick parts purely on technical merit of the parts, both would win some designs. However, there's also the tradeoff of saving development time by using parts and tools with which one is already experienced.Article: 130203
Antti wrote: > and yes, maybe i need another anti-virus thing ;) Mike Treseler wrote: > My favorite is linux ;) Antti wrote: > when the day comes, when > *) ALL FPGA vendors see Linux as PRIMARY O/S > *) ALL JTAG and ISP cable vendors support linux as PRIMARY O/S > > I would say it too. but I have to wait :( Why wait for *everything* to work on Linux? *Everything* doesn't work on any operating system, including Windows. *Most* things I need to do work fine on Linux, in fact, generally better than they work on Windows, so I mostly use Linux. For the few things that don't work on Linux, I use Windows (usually in VMware).Article: 130204
<chithrakn@gmail.com> wrote in message news:f5fb70fd-bad5-466d-bd7c-81c0d304b7a8@s12g2000prg.googlegroups.com... > Hi! > we constantly got an error which said 'waiting for core to be armed'. I bet your clock is/has stopped. HTH.,SymsArticle: 130205
On Mar 17, 2:04 pm, sky46...@trline4.org wrote:
> Dilan<dilan2...@gmail.com> wrote:
> >hi,
> > i am going to use easics tool for generating crc32 verilog code
> >(8bit input) (www.easics.com/webtools/crctool) . i was able to
> >implement correctly.but i need more info to how use this crc to
> >generate FCS of a ethernet packt.
> >i heard about there must be some bit reversal before applying to crc
> >generator. but i am not clear about it .can any one guide me to what
> >have to data stream before applying to crc and when checksum created
> >if further processing had to be done on checksum
>
> The crc you need to apply is the CRC32 AUTODIN II. This is to be applied to
> all bits after the frame start. In 10/100M ethernet each 4-bits is in
> reverse order (low nibble - high nibble). So you may need to swap these
> before feeding the bits to the crc32 generator.
>
> A C example of this crc is at:
> http://darwinsource.opendarwin.org/10.3/text_cmds-30/cksum/crc32.c
>
> You can use it for verification this way:
> cat pktdata | cksum -o 3 | perl -ne 'if( /^(\d+)/ ){ printf("%08X\n",$1); }'
>
> A tip is to capture some packets and use them as reference to verify your
> crc is correct. Watch out for the order of bits coming out of the crc
> generator aswell, sometimes these may need swapping aswell.
> A quick way to find accidential bit swaps is to display the number in
> binrary like this: perl -e 'printf("%032b\n",2);'
>
> Hope this helps you a bit.
tahanks sky46. i try to download above c file but i borweser can
locate the c file.
i think some thing wrong with URL. i really appritiate if u can post a
verilog code for
this implemntaion.i found following c code from other forum . it seems
it works correctly. but i don't know whether this is the one you
mentioned as crc32 atuodin II . following is the c code
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
#include <stdio.h>
int main(void)
{
unsigned char data[] =
{
0x00, 0x0A, 0xE6, 0xF0, 0x05, 0xA3, 0x00, 0x12,
0x34, 0x56, 0x78, 0x90, 0x08, 0x00, 0x45, 0x00,
0x00, 0x30, 0xB3, 0xFE, 0x00, 0x00, 0x80, 0x11,
0x72, 0xBA, 0x0A, 0x00, 0x00, 0x03, 0x0A, 0x00,
0x00, 0x02, 0x04, 0x00, 0x04, 0x00, 0x00, 0x1C,
0x89, 0x4D, 0x00, 0x01, 0x02, 0x03, 0x04, 0x05,
0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D,
0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13
};
unsigned int crc_table[] =
{
0x4DBDF21C, 0x500AE278, 0x76D3D2D4, 0x6B64C2B0,
0x3B61B38C, 0x26D6A3E8, 0x000F9344, 0x1DB88320,
0xA005713C, 0xBDB26158, 0x9B6B51F4, 0x86DC4190,
0xD6D930AC, 0xCB6E20C8, 0xEDB71064, 0xF0000000
};
unsigned int n, crc=0;
for (n=0; n<sizeof(data); n++)
{
crc = (crc >> 4) ^ crc_table[(crc ^ (data[n] >> 0)) & 0x0F]; /*
lower nibble */
crc = (crc >> 4) ^ crc_table[(crc ^ (data[n] >> 4)) & 0x0F]; /*
upper nibble */
}
for (n=0; n<4; n++) /* display the CRC, lower byte first */
{
printf("%02X ", crc & 0xFF);
crc >>= 8;
}
printf("\n");
return 0;
}
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
it works correctly but when try to implement it on verilog it gives me
wrong answer.please check the following verilog code
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
module FCS_CAL(clk,data,enable,crc_out,reset);
input clk;
input [7:0] data;
input enable;
input reset;
output [31:0] crc_out;
reg [31:0] crc_out;
reg[3:0] crc_table_adr;
reg[31:0] crc_table_data;
always @(crc_table_adr) begin
case (crc_table_adr)
4'h0:crc_table_data=32'h4DBDF21C;
4'h1:crc_table_data=32'h500AE278;
4'h2:crc_table_data=32'h76D3D2D4;
4'h3:crc_table_data=32'h6B64C2B0;
4'h4:crc_table_data=32'h3B61B38C;
4'h5:crc_table_data=32'h26D6A3E8;
4'h6:crc_table_data=32'h000F9344;
4'h7:crc_table_data=32'h1DB88320;
4'h8:crc_table_data=32'hA005713C;
4'h9:crc_table_data=32'hBDB26158;
4'hA:crc_table_data=32'h9B6B51F4;
4'hB:crc_table_data=32'h86DC4190;
4'hC:crc_table_data=32'hD6D930AC;
4'hD:crc_table_data=32'hCB6E20C8;
4'hE:crc_table_data=32'hEDB71064;
4'hF:crc_table_data=32'hF0000000;
endcase
end
always @(posedge clk)begin
if(reset==1 && enable==0) begin
crc_out=32'h00000000;
end
if(reset==0 && enable==1) begin
//crc = (crc >> 4) ^ crc_table[(crc ^ (data[n] >> 0)) & 0x0F]; /*
lower nibble */
crc_table_adr=crc_out[3:0] ^ data[3:0];
#100 crc_out=(crc_out>>4)^crc_table_data;
//crc = (crc >> 4) ^ crc_table[(crc ^ (data[n] >> 4)) & 0x0F]; /*
upper nibble */
crc_table_adr=crc_out[3:0] ^ data[7:4];
#100 crc_out=(crc_out>>4)^crc_table_data;
end
end
endmodule
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
thanks
regards
dilan
Article: 130206Jim Granville wrote: > Jecel wrote: > > [4 bits is optimal] > > Do you mean a 4 bit CPU, or a nibble-serial design of a larger > 16/20/24/28/32 bit CPU ? In my case it was a nibble-serial implementation of a 16 bit processor. Antti is asking for large addresses, so the software should probably see 24 to 32 bits. John_H wrote about shift registers in Xilinx FPGAs. I agree and have created some a really tiny design for a waveform generator using this. The problem I mentioned was that you need parallel addresses, however, and the shifts won't help you there. With a serial external memory you never need the whole address at once and might be able to avoid some registers. The instruction register might also have to be parallel, but by being smart when designing the instruction format you can avoid needing all the bits all the time. -- JecelArticle: 130207
Hi, I have been called for a Xilinx internship (Computer / Electrical Engineering) interview. Could any of you please let me know what kind of questions may be asked? Thanks,Article: 130208
On Mar 17, 8:35=A0pm, austin <aus...@xilinx.com> wrote: > Bish, > > Have your professor contact the Xilinx University Program. > > http://www.xilinx.com/univ/ > > We provide the software tools you will require. =A0Many of our partners > also supply their tools also to universities and schools under their > programs (Mentor, Synopsys, Cadence). > > The V2 Pro Digilent University board is supported, and as a XUP member, > you send a coupon to "redeem" your FPGA (which then makes the board > complete). =A0Commercial users need to pay the full price of the FPGA to > have one on the same pcb. > > There are newer (V5) boards for universities in the process, so your > professor needs to contact the XUP program, and ask there. > > Nothing wrong with the V2 Pro board, however. > > The next versions of the Mars rovers will "upgrade" from Virtex 2, to > Virtex 2 Pro, and in the process, go from less than 1 MPH, to as fast as > you can run (from what I have heard). > > As far as soft processors go, a Spartan 3 board, with one of the largest > S3 parts, would also be an excellent choice (and low cost). =A0Again, the > Digilent site is a good place to look. > > http://www.digilentinc.com/Products/Detail.cfm?Prod=3DS3BOARD&Nav1=3DProd.= .. > (with 3S1000, for example)http://www.digilentinc.com/Products/Detail.cfm?P= rod=3DPMOD-HB3&Nav1=3DPro... > h-bridge for motor controls (many other pcb's available, too) > > Austin Thanks for the answers. Since we don't have the experience with any other boards other than pretty old XSA board with Spartan II, it's bit difficult to select the board.Article: 130209
On Mar 17, 4:37=A0pm, "David Spencer" <davidmspen...@verizon.net> wrote: > "FPGA" <FPGA.unkn...@gmail.com> wrote in message > > news:b799694d-48d2-4ebb-92e4-0953385d8a52@b64g2000hsa.googlegroups.com... > > >I wish to design a FIFO to tansfer data from a high speed clock > > domain(320 MHz) to low speed clock domain(40 Mhz). I dont wish to use > > the cores available from any of the vendors. > > If I was you, I really would use a vendor-supplied core. Xilinx and Altera= > (and I suspect others) provide these free and they've been well tested in > many, many designs. The port names may differ between different vendors bu= t > you can make the FIFO virtually vendor-agnostic by providing a trivial > wrapper to name the ports as you wish. If for some (strange) reason you want to roll your own, you face three challenges around the FULL flag: You must detect FULL fast enough, within a 3 ns period. And you must release FULL in response to a read clock, without getting into metastable problems. And you must compare the two counters without decoding glitches. All this is stuff the we core designers have solved already for you, at much higher speed... Peter Alfke, XilinxArticle: 130210
On 18 Mrz., 01:11, Eric Smith <e...@brouhaha.com> wrote: > Antti wrote: > > I used PIC when PIC15C54 was "hot", as they had almost > > no competition. I changed to AVR as they are better. > > Better for some things, not for everything. I had several designs using > PICs for which AVRs would not have been fast enough. (There are faster > AVRs now, but there are faster PICs too.) > > If one were to pick parts purely on technical merit of the parts, both > would win some designs. However, there's also the tradeoff of saving > development time by using parts and tools with which one is already > experienced. yes agreed, at the beginning where it was PIC16C84 vs AT90S1200 it was clear win for AVR, but microchip has no so many new chips that they defenetly win designs where AVR do not fit because of lack of functions or speed or other details. well both PIC and AVRs are no loosing against 32 bit low cost MCUs eh, I am writing just now "My first STM32" book ;) a ARM that cost less 3 usd runs at 72mhz (also from internal osc!) and has USB and 64KByte flash.. why think of 8 bit micros for designs where the 3 usd price is acceptable? sure for sub 1 usd prices 8 bit MCUs are considered. AnttiArticle: 130211
HI, I suggest u to once look into elastic buffers may be tht'll help you...........Article: 130212
Check the clock you attached to ILA clock input...Article: 130213
Try to make clear what you did to prove the Xilinx mistake. Ask specific questions. This is the strategy to get Xilinx expert to your case. Basic questions lead to basic answers. Specific question can lead to changes in Xilinx documentation :-)Article: 130214
On Mar 18, 2:28=A0am, chithr...@gmail.com wrote: > Hi! > =A0We are students working on implementing FFT on FPGA, virtex 4. We > used Chipscope to test our code and capture signals off the hardware > while its running. > when we tried to test an 8 bit adder using chipscope, in the ILA core, > we constantly got an error which said 'waiting for core to be armed'. > We understand that this indicates that appropriate trigger signal has > not been provided. We've tried everything possible but we're not able > to figure out how to provided an appropriate trigger. > > some of the things we tried: > 1) specified the two 8 bit inputs as trigger > 2) specified the clock as trigger. > > Both the above had failed. So please help us by telling how to > proceed. This happens mostly when you dont connect a clock input to the ILA.Article: 130215
> tahanks sky46. i try to download above c file but i borweser can
>locate the c file.
>i think some thing wrong with URL. i really appritiate if u can post a
>verilog code for
http://opengrok.creo.hu/dragonfly/raw/src/usr.bin/cksum/crc32.c
or google for "This code implements the AUTODIN II polynomial used by "
Btw, capture some real packets and use them for verification.
This data:
00000000 41 42 43 44 45 46 47 48 31 32 33 34 35 36 37 38 |ABCDEFGH12345678|
Should generate the crc32 number:
3E EF 64 89
00111110111011110110010010001001
echo -n ABCDEFGH12345678 | cksum -o 3 | perl -ne 'if( /^(\d+)/ ){ printf("%08X\n",$1); }'
Article: 130216Hello everyone, My project has several ADC channels with 16bit data up to 24kSPS. There is no need for each ADC sample to be sent ASAP to the microblaze, as the data is processed in chunks of 200 samples. A previous (non-xilinx) version of this project used a FIFO and a burst read over a PCI bus to a pentium processor. Now, reading about FSL it seems that the microblaze has to execute an instruction to get every sample of data? What I want is the lowest overhead - given that I can use a FIFO, would the FIFO with DMA route be better suited to my needs than FSL? Thanks, Mark.Article: 130217
On 17 Mrz., 23:07, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > * 32 bit registers, say block of 16 (use 32 LUTRAM == 16 LUT/LC) > > * serialized can run from spi flash up to 320MBit with > > http://www.winbond.com/NR/rdonlyres/4C63AD62-967C-4B72-AF85-1F5984E8B... > > * can address large code space > > * can run at high fabric clocks (due to lack of parallel buses and > > parallel ALUs) > > > now a bit-serialized CPU to the above spec can be done. > > it would use less than 100 slices. > > > if anyone is willing to desing this CPU, I may have funds for it, > > really please... > > Did you mean you have someome to fund this, or that you could do it > if someone funds you ? > http://code.google.com/p/serial-processor/wiki/ProjectFunding current funding... > > > hm at 320MB/sec spi streaming, we get byte reads at 40Mhz from serial > > flash! > > and you can add a second SPI chip, if you want to double the > bandwidth to 80MB/Sec. > Of course, the jump latency does not improve, but a matched core design > would minimise jumps. > Short-Skip opcodes are an obvious cadidate. > > -jgArticle: 130218
Hi, I'm attempting to get the xps_ll_temac talking to an SGMII PHY (Vitesse 8211), with little success. The board doesn't have a dedicated 125MHz differential clock, so I'm deriving the 125MHz clock internally with a DCM, driving the ll_temac's MGTCLK_P signal with it, and setting the C_INCLUDE_IO param to zero to direct EDK that this clock drives the MGT clock directly (no IBUFDS). I understand this is not ideal but I didn't lay out the board! The C_TEMAC0_PHYADDR param is set to the default 0b00001, and when I do a PHY address scan I can see the internal Rocket IO phy at this address. I can read the MII mgmt interface regs at this PHY address, and they correspond with the values expected for the SGMII / 1000BaseX internal Phy as described in the ll_temac datasheet (Tables 62-73 in the DS). However, despite having wired up the MDIO and MDC pins on the board to the external PHY and connected to the ll_temac, and having strapped the PHY's relevant config pins to give a PHY address of 0b01000, the phy address scan turns up nothing. It's not clear to me if, when using SGMII or 1000BaseX, the external PHY's MII registers should also be visible, in addition to the RocketIO PHY. A quote from the datasheet doesn't really clarify: "The MII Management inteface is used ...in the case of SGMII...to access PHY registers internal to the Hard TEMAC silicon component..." This suggests there's no "pass through" to the MII interface on the board (MDIO / MCD). In that case, how can I talk to the PHY chip's MIIM interface to get it into the correct configuration? Here's the values I see on MII registers 0-31 on PHY address 0b00001 (the internal RocketIO phy). They correspond to the expected values. 0: 1140 1: 01C8 2: 0028 3: D400 4: 0001 5: 8001 6: 0004 7: 2001 8: 0000 9: 0000 10: 0000 11: 0000 12: 0000 13: 0000 14: 0000 15: 8000 16: 0003 17: 0000 18: 0000 19: 0000 20: 0000 21: 0000 22: 0000 23: 0000 24: 0000 25: 0000 26: 0000 27: 0000 28: 0000 29: 0000 30: 0000 31: 0000 Any advice or input greatly appreciated. Even better would be a reference design using the ll_temac in SGMII mode. The cosest I've found is an old EDK8.2 era ML410 SGMII design, that uses the earlier incarnation of the TEMAC cores (not ll_temac). Thanks, JohnArticle: 130219
"Abhi" <rkabhi@gmail.com> wrote in message news:77ebf9da-469a-48f6-859e-0cc78a704324@s12g2000prg.googlegroups.com... > Hi, > > I have been called for a Xilinx internship (Computer / Electrical > Engineering) interview. Could any of you please let me know what kind > of questions may be asked? > > Thanks, I suspect they will ask you the kind of question that will allow them to decide whether you are suitable for the position or not. Is that not the purpose of an interview?Article: 130220
On Mon, 17 Mar 2008 14:28:50 -0700 (PDT), chithrakn@gmail.com wrote: >Hi! > We are students working on implementing FFT on FPGA, virtex 4. We >used Chipscope to test our code and capture signals off the hardware >while its running. >when we tried to test an 8 bit adder using chipscope, in the ILA core, >we constantly got an error which said 'waiting for core to be armed'. >We understand that this indicates that appropriate trigger signal has >not been provided. We've tried everything possible but we're not able >to figure out how to provided an appropriate trigger. > >some of the things we tried: >1) specified the two 8 bit inputs as trigger >2) specified the clock as trigger. > >Both the above had failed. So please help us by telling how to >proceed. First specify the trigger condition as all X'es, (essentially, trigger immediately), and see if it runs. If not, suspect the clock is not connected. If it does run, then clock is OK but your trigger condition is not occurring ... specify simpler trigger conditions until you find out why not... - BrianArticle: 130221
On Tue, 18 Mar 2008 02:28:23 -0700 (PDT), markmcmahon@hotmail.com wrote: >Hello everyone, > >My project has several ADC channels with 16bit data up to 24kSPS. > >There is no need for each ADC sample to be sent ASAP to the >microblaze, as the data is processed in chunks of 200 samples. A >previous (non-xilinx) version of this project used a FIFO and a burst >read over a PCI bus to a pentium processor. > >Now, reading about FSL it seems that the microblaze has to execute an >instruction to get every sample of data? >What I want is the lowest overhead - given that I can use a FIFO, >would the FIFO with DMA route be better suited to my needs than FSL? Do you mean the lowest hardware overhead, the lowest software overhead, or something else? This might affect the answer. - BrianArticle: 130222
On Mar 18, 6:35 am, John Williams <jwilli...@itee.uq.edu.au> wrote: > Hi, > > I'm attempting to get the xps_ll_temac talking to an SGMII PHY > (Vitesse 8211), with little success. > > The board doesn't have a dedicated 125MHz differential clock, so I'm > deriving the 125MHz clock internally with a DCM, driving the > ll_temac's MGTCLK_P signal with it, and setting the C_INCLUDE_IO param > to zero to direct EDK that this clock drives the MGT clock directly > (no IBUFDS). I understand this is not ideal but I didn't lay out the > board! Did you consider the jitter requirements when using the DCM to generate the clock for the MGT? > Any advice or input greatly appreciated. Even better would be a > reference design using the ll_temac in SGMII mode. The cosest I've > found is an old EDK8.2 era ML410 SGMII design, that uses the earlier > incarnation of the TEMAC cores (not ll_temac). I've used 9.1 w/ the ML410 and the SGMII ethernet and the plb_temac. I have not tried to yet on 9.2 w/ the new xps_ll_temac, but the old version did not support SGMII. One item of note is make sure you have all the necessary clocks hooked up (or disconnected). I recently ran into an issue where I had the GTX_CLK connected to the hard_temac in 9.1 and my MII interface was not working. Found out that it was because that clock was not to be connected when using only a MII interface. HTH, MikeArticle: 130223
On Mar 17, 6:21 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > > I've previously had problems with XST + hierarchy + registered > > tristates, with a 'fix' being placing the IO tristate stuff all > > at the top level. > > What would be nice is a latched IOB tristate primitive. > > Brad Smallridge > AiVision You can make your own. This was done for a DDR reference design (forget which one). The issue is not that the registers need to be at the top of the hierarchy, but at the same level as the pin. So if you have a module that contains all of the IOB components and assign the pin in the port mapping, it should do what you want. Regards, GaborArticle: 130224
John_H wrote: > On Mar 17, 1:29 pm, FPGA <FPGA.unkn...@gmail.com> wrote: > <snip> >> And I would like to design my own in either case. > <snip> > > So why are you asking us? ;-) It looks like p171 of http://www.google.com/url?sa=t&ct=res&cd=7&url=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DaQd4QYNV88EC%26pg%3DPA161%26lpg%3DPA161%26dq%3Dverilog%2Bfifo%2Bgray%26source%3Dweb%26ots%3DfY7n_OHYFN%26sig%3DkArkUjHVCE_M87AwKkrU61gWaz0%26hl%3Den&ei=rr3fR_qqJ5qMiwGyqZjRBQ&usg=AFQjCNGottyhGBvcjXugi1wBigp7dDB8wA&sig2=ormNgEQa4GqcdBc-ULwKxQ has a reasonable FIFO. I can't pull one of my FIFOs out of a work file and I did my taxes yesterday instead of throwing together a FIFO for you. The flags shouldn't be a big problem for you if you're willing to wait an extra cycle for the Gray counters to settle out. Having an empty on the read side means the empty de-asserts only when there's a word has long since settled in the buffer memory and asserts only in the read clock's domain. Similarly with the full flag on the transmit side, the full asserts with the transmit clock but could be a clock worth of delay late for de-assertion due to the Gray count registration from the read domain to the write domain. For a "complete" constraint set, the timing path from the point where the Gray count is registered in the new timing domain to where the values are used should be reduced by any metastability delay *or* registered twice. It would be easy enough to reduce a 25ns period to 23ns or less and not have any significant metastability issues but cutting down a 3125ps period by 2ns would be miserable. For the 320 MHz domain, registering the Gray count twice would be a solid way to go. Gray counters are pretty easy. Handling metastability for these slow-acting flags is pretty straightforward. What tends to get the designer is an incorrect FIFO size or a software guy that thinks the way to clear a FIFO is to just read n words rather than reading until the empty flag asserts. If the hardware guy doesn't have past-end read/write handling in place, errant behavior will produce errants. If after looking at the Google Books example you still aren't sure what to do, let us know. I can cobble some Verilog together that I'll happily share, untested. - John_H
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