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
Roger, Depending on speed, using an FPGA can be exactly like using a DSP. The use of the BRAM basically means you are building a custom DSP machine, which will 'execute' a fixed program (based on a FSM), manipulating the BRAM contents much like a DSP would bring operands in and out of the ALU, to and from memory. Personally, if something this slow would work, to make your life easier, you might consider Microblaze as the processor, and execute both program and data from BRAMs. That way the program (which may already be in c code) could remain in c code. Or, alternatively, use a "real" DSP processor, as (let's be honest) the FPGA may be extreme overkill for what you may be doing. If the speed there is just not fast enough, there may be hardened FFT filter structures that are serial, rather than parallel, which still may be fast enough (faster than a DSP), and yet use fewer resources (than a full parallel one). The SRL16s are particularly good at this, as you have up to 16 FFs for the SLICEs with SRLs/LUTRAM. Remember that a parallel multiply may not be needed, and a serial multiplier may be a lot less hungry (for resources, overall). Many extreme audio applications (see NAB conference) use serial processing of many audio streams at once on a signle FPGA for a superb cost/performance point. http://biz.yahoo.com/prnews/060419/sfw113.html?.v=30 Finally, if the problem can be partitioned in time into more than one piece, I have seen people calculate part 1, store results in an external SRAM, reconfigure, and then read in last part and calculate part 2, store results in external SRAM, etc... AustinArticle: 100951
I installed SP3 for ISE 8.1 (webpack) yesterday and used it for a bit. I then ran a multi-pass P&R, then, when it was done, killed the program and shut down my computer. When I started up today, ISE won't run. I get the start-up windows, but it appears to hang with the process _pn.exe running. Windows task manager reports that "Xilinx - ISE" is "Not Responding". Anyone else run into this? Is it just me, or does the Xilinx s/w appear to be getting worse? The user interface on 8.1 seems very slow when compared to 6.1. XST takes a lot longer than it used to. If it weren't for the updated speed files, I'd go back to 6.1 in a heart beat. John ProvidenzaArticle: 100952
Freechip, http://www.xilinx.com/products/design_resources/mem_corner/grouping/cam.htm I am not suggesting you switch to Xilinx, but we do have answers. Austin freechip wrote: > Hi, > I am working on a 10 Gb Ethernet project (deep packet inspection) and need > to implement CAM in my FPGA. I am using a Stratix GX and I don't think I > can use CAM (internal or external) in the stratix GX Dev Board. > > Let me know your thoughts about that. > > Thanks a lot.Article: 100953
"freechip" <freechip@hotmail.fr> wrote in message news:VqSdnSn0Kpv2YtXZRVn_vA@giganews.com... > > Hi, > I am working on a 10 Gb Ethernet project (deep packet inspection) and need > to implement CAM in my FPGA. I am using a Stratix GX and I don't think I > can use CAM (internal or external) in the stratix GX Dev Board. > > Let me know your thoughts about that. > > Thanks a lot. How big a (Ternary?)CAM do you need?Article: 100954
I found a work-around - I delete the bulk of the files from my working directory including the .ise file and now ISE starts up. I copied in an older 6.1 .npl file and told ISE to convert it to the newer 8.1 project file. John ProvidenzaArticle: 100955
"Roger Bourne" <rover8898@hotmail.com> wrote in message news:1145634375.780378.146980@t31g2000cwb.googlegroups.com... <snip> > BlockRAM. Great idea! I checked the timing specs of the blockram > module, and it seems pretty fast.1clock cycle to write and 1 clock > cycle for read. max freq of ~160MHz. No need for a complex multiplexing > network. In fact, there is no need for delay elements > (FFs)alltogether!. > > However, I never used RAM on an FPGA (that is the reason I did not > initially lean towards that solution). Is there some obvious, flagrant > , blatant drawback when using RAM , instead of FFs ? Especially since > there is 36 times more RAM bits than available FFs (288K vs 8K). And in > RAM, ALL the bits can be used! > > According to the timing waveform in the specs, it only requires 1 cycle > for read and 1 cycle for write --so I do not think loss of cycles > between data transters will be an issue, especially if the data rate is > ~150 times slower than the fastest clock available. The module that > performs the multiplication can thus be time-multiplexed. > > It is sounds like it is working on a DSP, rather than a FPGA, if one > foregoes the use of FFs...:-) > > -Roger If you want a dedicated port to a controller to allow on-the-fly update of coefficient values, a dual-port RAM would implement the controller on one port and the data I/O on the other. If you have a fixed configuration, you can dedicate one port for read, one for write, and your data can flow at the full 320 MHz BlockRAM rate. Dual-ports are great. Initializing BlockRAM contents always seems a little tough with the synthesis and simulation tools never quite making it practical to get everything flowing just right. If you look into the help or app notes from the various tools, you could have pre-initialized BlockRAMs for fixed coefficients to make life simpler. For your application, this really *is* best implemented in a DSP mindset; you can keep your resources low (1 MAC) and maintain the values in a register file with limited I/O in your algorithm. Since you have 100x+ the sample rate to do your processing, the system flows beautifully. The only question for me would be how complex the state machine or microcode would need to be to have the system work beautifully without adding a generic processor like the MicroBlaze or similar. This is where prototyping with pseudo-code and an Excel spreadsheet get me to my results with a simple implementation. For me, these kinds of tasks are great fun.Article: 100956
John_H wrote: > "Roger Bourne" <rover8898@hotmail.com> wrote in message > news:1145634375.780378.146980@t31g2000cwb.googlegroups.com... > <snip> > > BlockRAM. Great idea! I checked the timing specs of the blockram > > module, and it seems pretty fast.1clock cycle to write and 1 clock > > cycle for read. max freq of ~160MHz. No need for a complex multiplexing > > network. In fact, there is no need for delay elements > > (FFs)alltogether!. > > > > However, I never used RAM on an FPGA (that is the reason I did not > > initially lean towards that solution). Is there some obvious, flagrant > > , blatant drawback when using RAM , instead of FFs ? Especially since > > there is 36 times more RAM bits than available FFs (288K vs 8K). And in > > RAM, ALL the bits can be used! > > > > According to the timing waveform in the specs, it only requires 1 cycle > > for read and 1 cycle for write --so I do not think loss of cycles > > between data transters will be an issue, especially if the data rate is > > ~150 times slower than the fastest clock available. The module that > > performs the multiplication can thus be time-multiplexed. > > > > It is sounds like it is working on a DSP, rather than a FPGA, if one > > foregoes the use of FFs...:-) > > > > -Roger > > If you want a dedicated port to a controller to allow on-the-fly update of > coefficient values, a dual-port RAM would implement the controller on one > port and the data I/O on the other. If you have a fixed configuration, you > can dedicate one port for read, one for write, and your data can flow at the > full 320 MHz BlockRAM rate. Dual-ports are great. > > Initializing BlockRAM contents always seems a little tough with the > synthesis and simulation tools never quite making it practical to get > everything flowing just right. If you look into the help or app notes from > the various tools, you could have pre-initialized BlockRAMs for fixed > coefficients to make life simpler. > > For your application, this really *is* best implemented in a DSP mindset; > you can keep your resources low (1 MAC) and maintain the values in a > register file with limited I/O in your algorithm. Since you have 100x+ the > sample rate to do your processing, the system flows beautifully. The only > question for me would be how complex the state machine or microcode would > need to be to have the system work beautifully without adding a generic > processor like the MicroBlaze or similar. This is where prototyping with > pseudo-code and an Excel spreadsheet get me to my results with a simple > implementation. > > For me, these kinds of tasks are great fun. > This is where prototyping with > pseudo-code and an Excel spreadsheet get me to my results with a simple > implementation. pseudo-code ??? What exactly do you mean by peudo-code? -RogerArticle: 100957
Thanks. Good idea, but it doesn't change anything. I forgot to mention
above that it seems that this is more attached to the #() parameter
initialization part because using these INITs with a non-array
instantiation causes the same problem:
RAMB16_S36_S36 #(.WRITE_MODE_A("READ_FIRST"), .INIT_A(36'h012345678))
BRAM (.ADDRA(ADDRA), ...
-Allan
Article: 100958
Hello all,
Why xilinx is using edges to read from block RAM. That wont be a
problem in most cases. But i am trying to implement the 16 port
read/wrte RAM by a method suggested in an earlier post. The RAM is
constructed with lot of individual RAM units. And in this there is a
need to write to a RAM with input data XOred with data from other RAMs.
But if we need an edge to read from the memory content this is not
possible. Other method is to use +ve edge for reading and negedge for
writng. But this is also not possible because there is one more read is
required in the same cycle. Any comments.
regards
Sumesh V S
Article: 100959A 16 *port* RdWr memory requires the equivalent of about 256 BlockRAMs. You sure about this? Do you mean 16 entry? "vssumesh" <vssumesh_asic@yahoo.com> wrote in message news:1145638876.886174.164400@i39g2000cwa.googlegroups.com... > Hello all, > Why xilinx is using edges to read from block RAM. That wont be a > problem in most cases. But i am trying to implement the 16 port > read/wrte RAM by a method suggested in an earlier post. The RAM is > constructed with lot of individual RAM units. And in this there is a > need to write to a RAM with input data XOred with data from other RAMs. > But if we need an edge to read from the memory content this is not > possible. Other method is to use +ve edge for reading and negedge for > writng. But this is also not possible because there is one more read is > required in the same cycle. Any comments. > regards > Sumesh V S >Article: 100960
On 17 Apr 2006 22:03:58 -0700, "Andrew FPGA" <andrew.newsgroup@gmail.com> wrote: >Hi, >I have been unable to find any info/guidelines for PCB placement of the >DCI reference resistors. I.e. the resistors that attach to VRN and VRP. > My instinct says decoupling capacitors highest priority (closest to >FPGA package), DCI resistors next priority, and everything else lowest >priority. > >How senstive to noise are the VRP/VRN inputs? > >FPGA is XC3S200-4FT256 and I'm using 49R9 DCI reference resistors. > >Regards >Andrew Great resource for decoupling cap placement and component priorities: http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf According to this power distribution app note, page 12, placement of termination resistors takes precedence over decoupling caps. The DCI reference resistors function like termination resistors. I have designed four different working boards using Virtex II Pro and/or Virtex 4 chips, and always put the DCI resistors closest to the FPGA on the ball layer. I can usually squeeze in a bunch of 0.01uF 0402 caps in the first ring around the FPGA perimeter on the ball layer. More 0.01uF caps on the bottom layer. Next ring has 0.1uF caps on ball and bottom layers, etc. I always use side vias to power and gnd planes on my decoupling caps (Page 6) to minimize inductance. Never have room for two vias per cap lead (Fig 6D). Do a search on "DCI" in the Xilinx Answers database for more info. Hope this is helpful.Article: 100961
"Roger Bourne" <rover8898@hotmail.com> wrote in message news:1145638266.357322.108180@i39g2000cwa.googlegroups.com... > > John_H wrote: >> This is where prototyping with >> pseudo-code and an Excel spreadsheet get me to my results with a simple >> implementation. > > pseudo-code ??? > What exactly do you mean by peudo-code? > > -Roger Just writing down what ssteps you'd take to implement the code in your data path. It's helpful to "see" the data pipeline by looking at the steps and the loops to manipulate the data.Article: 100962
Brannon wrote: > I have an application that has 300 pins on a tri-stated bus. They have > a tight offset constraint for the output time. Driving the T on the > OBUFT for all those off the same line fails time spec because the > fanout (of 300) stretches the time a little too long. In Synplicity, > you turn on the duplicate register option, and it will duplicate the > last register on the T line 300 times so that the timespec will pass. > XST is clueless. It seems to not even care that it is failing timespec; > it does no register duplication to fix failed OFFSET constraints. I had > to duplicate the register myself by declaring a bunch of them. Anyone > else seen the same issue? I've done the same thing myself. I noticed that XST will duplicate a register to go into an IOB if it is also used internally (one register for feedback and another going out), but I haven't seen it duplicate registers to reduce fanout. If you also have a fast clock, be aware that the signal driving your 300 OBUFT D-FF's may have a tough time meeting the period spec... Good luck, GaborArticle: 100963
Allan wrote:
> Thanks. Good idea, but it doesn't change anything. I forgot to mention
> above that it seems that this is more attached to the #() parameter
> initialization part because using these INITs with a non-array
> instantiation causes the same problem:
>
> RAMB16_S36_S36 #(.WRITE_MODE_A("READ_FIRST"), .INIT_A(36'h012345678))
> BRAM (.ADDRA(ADDRA), ...
>
>
> -Allan
I know this sounds dumb, but could the order of parameters be the
problem?
In the simprims and unisim libraries I noticed that INIT_A is the first
parameter
in the list. Maybe...
RAMB16_S36_S36 #(.INIT_A(36'h012345678), .WRITE_MODE_A("READ_FIRST"))
BRAM (.ADDRA(ADDRA), ...
Article: 100964All, Placement close to the chip is preferred, but since the ratio is 1:1, 1: 1:1/2 or 1:2 (ie a 50 ohm resistor can be used for a 25 ohm drive strength, or a split 100 ohm termination for 50 ohms), the impedance is low enough that coupling to the pin and causing it to not terminate correctly is unlikely. There are DCI resistors for other companies chips which use a 10:1 ratio, so a 500 ohm resistor is used for a 50 ohm termination. One must be much more concerned with those resistors (as they are 10 times easier to couple to). I would not put the resistor ahead of where a bypass capacitor would go, (bypassing is more important IMHO), but I would place it within 2 to 3" of the device, and I would not place strongly switching traces immediately adjacent to that 2 to 3" trace! I typically use a 3X spacing rule for reference resistors (and reference voltage pins), so that the trace to these pins has 3 times the normal spacing between traces to them. That takes the cross coupling to 1/9 a normally spaced pair of traces, which should be sufficient (but you should check anyway!). Austin mr_dsp@myrealbox.com wrote: > On 17 Apr 2006 22:03:58 -0700, "Andrew FPGA" > <andrew.newsgroup@gmail.com> wrote: > > >>Hi, >>I have been unable to find any info/guidelines for PCB placement of the >>DCI reference resistors. I.e. the resistors that attach to VRN and VRP. >>My instinct says decoupling capacitors highest priority (closest to >>FPGA package), DCI resistors next priority, and everything else lowest >>priority. >> >>How senstive to noise are the VRP/VRN inputs? >> >>FPGA is XC3S200-4FT256 and I'm using 49R9 DCI reference resistors. >> >>Regards >>Andrew > > > Great resource for decoupling cap placement and component priorities: > > http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf > > According to this power distribution app note, page 12, placement of > termination resistors takes precedence over decoupling caps. The DCI > reference resistors function like termination resistors. > > I have designed four different working boards using Virtex II Pro > and/or Virtex 4 chips, and always put the DCI resistors closest to the > FPGA on the ball layer. I can usually squeeze in a bunch of 0.01uF > 0402 caps in the first ring around the FPGA perimeter on the ball > layer. More 0.01uF caps on the bottom layer. Next ring has 0.1uF > caps on ball and bottom layers, etc. > > I always use side vias to power and gnd planes on my decoupling caps > (Page 6) to minimize inductance. Never have room for two vias per cap > lead (Fig 6D). > > Do a search on "DCI" in the Xilinx Answers database for more info. > > Hope this is helpful.Article: 100965
Hi - On Fri, 21 Apr 2006 11:00:08 -0700, mr_dsp@myrealbox.com wrote: >On 17 Apr 2006 22:03:58 -0700, "Andrew FPGA" ><andrew.newsgroup@gmail.com> wrote: > >>Hi, >>I have been unable to find any info/guidelines for PCB placement of the >>DCI reference resistors. I.e. the resistors that attach to VRN and VRP. >> My instinct says decoupling capacitors highest priority (closest to >>FPGA package), DCI resistors next priority, and everything else lowest >>priority. >> >>How senstive to noise are the VRP/VRN inputs? >> >>FPGA is XC3S200-4FT256 and I'm using 49R9 DCI reference resistors. >> >>Regards >>Andrew > >Great resource for decoupling cap placement and component priorities: > >http://www.xilinx.com/bvdocs/appnotes/xapp623.pdf > >According to this power distribution app note, page 12, placement of >termination resistors takes precedence over decoupling caps. The DCI >reference resistors function like termination resistors. I don't think that this is the case. These resistors are not terminating a trace in any conventional sense; instead, they're acting as half of a resistive divider, the other half consisting of the N-channel or P-channel transistors inside the FPGA. The DCI cal circuit is looking at the voltage level on the DCI reference pin when the cal driver is on, to get an idea of whether the driver is higher or lower than the required impedance. It adjusts the driver impedance up or down based on the voltage it sees. I certainly wouldn't put these resistors too far away; you don't want noise coupling into the traces when the FPGA is trying to make a calibration measurement. But the distance shouldn't be super-critical, either. Bob Perlman Cambrian Design WorksArticle: 100966
All- Does XST provide any pre-defined macros or constants? For example: __BUILD_NUMBER __XST_VER that could be used in source code as contents of a logic revision register, or could be used to know which version of XST is in use? If this is not available, is there a way to kludge it that's "relatively automatic"? To Xilinx: I know that "ISE ain't Visual Studio", but helpful code maintenance items such as this could easily be implemented. -JeffArticle: 100967
Can anyone @Xilinx can confirm they read this and will take
care of it ?
Sylvain Munaut wrote:
> Hi everyone,
>
> I hope someone @Xilinx will read this.
>
> In the new EDK 8.1 the FSL access macros have changed
> name. And they also introduced _interruptible versions.
> Theses are defined in
> ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h
>
> The definitions for getfsl_interruptible and
> cgetfsl_interruptible are correct. But the ones for
> putfsl_interruptible and cputfsl_interruptible are
> incorrect. For example putfsl_interruptible is :
>
> #define putfsl_interruptible(val, id) \
> asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
> "addic\tr18,r0,0\n\t" \
> "bnei\tr18,1b\n" \
> : "=d" (val) :: "r18")
>
> and it should be :
>
> #define putfsl_interruptible(val, id) \
> asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
> "addic\tr18,r0,0\n\t" \
> "bnei\tr18,1b\n" \
> :: "d" (val) : "r18")
>
> Obviously val is a input in the case of a 'put' and not
> an output.
>
>
> Another related question : In my code, when a replace all
> non _interruptible versions by their _interruptible counter
> parts, it doesn't behave as excpected anymore ...
> Does theses version require some hw support ?
>
>
>
> Sylvain
>
>
>
> PS: I know I should submit a webcase but when I try to login
> I just get "Server Error" ... and so I obviously can't even
> submit a webcase about my problem of being unable to log in
> into the webcase ...
Article: 100968
Sylvain,
I got it.
I will find out what happened, and report back.
Thanks,
Austin
Sylvain Munaut wrote:
> Can anyone @Xilinx can confirm they read this and will take
> care of it ?
>
>
> Sylvain Munaut wrote:
>
>> Hi everyone,
>>
>> I hope someone @Xilinx will read this.
>>
>> In the new EDK 8.1 the FSL access macros have changed
>> name. And they also introduced _interruptible versions.
>> Theses are defined in
>> ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h
>>
>> The definitions for getfsl_interruptible and
>> cgetfsl_interruptible are correct. But the ones for
>> putfsl_interruptible and cputfsl_interruptible are
>> incorrect. For example putfsl_interruptible is :
>>
>> #define putfsl_interruptible(val, id) \
>> asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>> "addic\tr18,r0,0\n\t" \
>> "bnei\tr18,1b\n" \
>> : "=d" (val) :: "r18")
>>
>> and it should be :
>>
>> #define putfsl_interruptible(val, id) \
>> asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>> "addic\tr18,r0,0\n\t" \
>> "bnei\tr18,1b\n" \
>> :: "d" (val) : "r18")
>>
>> Obviously val is a input in the case of a 'put' and not
>> an output.
>>
>>
>> Another related question : In my code, when a replace all
>> non _interruptible versions by their _interruptible counter
>> parts, it doesn't behave as excpected anymore ...
>> Does theses version require some hw support ?
>>
>>
>>
>> Sylvain
>>
>>
>>
>> PS: I know I should submit a webcase but when I try to login
>> I just get "Server Error" ... and so I obviously can't even
>> submit a webcase about my problem of being unable to log in
>> into the webcase ...
Article: 100969
All,
Here is the answer:
"Hi,
Yes this is a bug. This issue is being fixed for the next EDK release
(8.2i). Also, your patches seem correct."
Austin
Austin Lesea wrote:
> Sylvain,
>
> I got it.
>
> I will find out what happened, and report back.
>
> Thanks,
>
> Austin
>
> Sylvain Munaut wrote:
>
>> Can anyone @Xilinx can confirm they read this and will take
>> care of it ?
>>
>>
>> Sylvain Munaut wrote:
>>
>>> Hi everyone,
>>>
>>> I hope someone @Xilinx will read this.
>>>
>>> In the new EDK 8.1 the FSL access macros have changed
>>> name. And they also introduced _interruptible versions.
>>> Theses are defined in
>>> ${EDK_HOME}/sw/lib/bsp/standalone_v1_00_a/src/microblaze/mb_interface.h
>>>
>>> The definitions for getfsl_interruptible and
>>> cgetfsl_interruptible are correct. But the ones for
>>> putfsl_interruptible and cputfsl_interruptible are
>>> incorrect. For example putfsl_interruptible is :
>>>
>>> #define putfsl_interruptible(val, id) \
>>> asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>>> "addic\tr18,r0,0\n\t" \
>>> "bnei\tr18,1b\n" \
>>> : "=d" (val) :: "r18")
>>>
>>> and it should be :
>>>
>>> #define putfsl_interruptible(val, id) \
>>> asm volatile ("\n1:\n\tnput\t%0,rfsl" #id "\n\t" \
>>> "addic\tr18,r0,0\n\t" \
>>> "bnei\tr18,1b\n" \
>>> :: "d" (val) : "r18")
>>>
>>> Obviously val is a input in the case of a 'put' and not
>>> an output.
>>>
>>>
>>> Another related question : In my code, when a replace all
>>> non _interruptible versions by their _interruptible counter
>>> parts, it doesn't behave as excpected anymore ...
>>> Does theses version require some hw support ?
>>>
>>>
>>>
>>> Sylvain
>>>
>>>
>>>
>>> PS: I know I should submit a webcase but when I try to login
>>> I just get "Server Error" ... and so I obviously can't even
>>> submit a webcase about my problem of being unable to log in
>>> into the webcase ...
Article: 100970Does anyone know if Altera has any prebuilt async fifo with different read/write ports? I am trying to target Cyclone device. The M4K blocks do allow variable width read/write ports but I cannot see any fifos made using those. TIAArticle: 100971
Try the lpm_fifo MegaWizard function. You can use separate read and write ports that are driven from two different unsynchronized clocks. "fpgabuilder" <fpgabuilder-groups@yahoo.com> wrote in message news:1145662324.330234.23380@u72g2000cwu.googlegroups.com... > Does anyone know if Altera has any prebuilt async fifo with different > read/write ports? I am trying to target Cyclone device. The M4K > blocks do allow variable width read/write ports but I cannot see any > fifos made using those. > > TIA >Article: 100972
Hi all, I am new to Modelsim and always use GUI to do all the work. I heard that we can use Tcl to control Modelsim to compile and run a batch of work, is there any example available? BTW, I use Verilog. Any suggestions will be appreciated! DavyArticle: 100973
Nope, that didn't do it either. I've tried some iterations of this theme with no success. Where would I find the libraries you mentioned to take a look at?Article: 100974
"aymmmm@gmail.com" <aymmmm@gmail.com> writes: > The final stage is to interface the Spartan-3 to a USB Bluetooth dongle > to support wireless voice and/or data communications modulated with > DSSS (IS-95 CDMA). > > I need to interface the USB dongle to the PS/2 port of Spartan-3 using > a PS/2-to-USB converter. Sorry, it's not going to work. USB-to-PS/2B converters only support PS/2 keyboards, mice, and similar devices on USB hosts. They don't let PS/2 hosts talk to arbitrary USB devices such as Bluetooth dongles.
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