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 never personally designed with PCI but Austin made note in the previous discussion that: "PCI at 3.3V REQUIRES reflective wave switching. That means the inputs have overshoot and undershoot BY DESIGN." Rob bob elkind wrote: > "Rob" <buzoff@leavemealone.com> wrote in message news:485DC7BF.9030200@leavemealone.com... > ... >> For PCI, the recommendation is to use 3.0V at the VCCIO pins; but for normal LVTTL type interface you can use 3.3V, I've done >> it. You just have to make darn sure that your transmission lines are designed properly. >> >> Take care, >> Rob > > Rob, what's the difference between PCI and 3.3V LVTTL, that one requires 3.0V and the other does not ? > > - Bob Elkind > >Article: 133251
"ertw" <gill81@hotmail.com> wrote in message news:cab9c099-e80f-47de-8e75-ca0a0e558ec7@m73g2000hsh.googlegroups.com... > Hi, I am planning to read an image sensor using an FPGA but I am a > little confused about a bunch of things. Hopefully someone here can > help me understand the following things: > > Note: The image sensor output is an ANALOG signal. Datasheet says that > the READOUT clock is 40MHz. > > 1. How is reading of an image sensor using an ADC different then > reading a random analog signal using an ADC? > > - Any random signal is read using nyquist theorem that is sample > the signal @ 2 times the highest frequency. > And the amount of data or memory required can be calculated > using: > Sampling rate x ADC resolution Nyquist relates to sinusoids and periodicity in the signal. The sampling period as it relates to Nyquist with your image sensor is the frame rate, not the pixel clock/ADC sample rate. The two are not related in a meaningful way. Fuhget about it. While reading Proakis, I remember distinctly thinking mathematics is the wrong language to impart an intuitive grasp of some topics for most folks. Discrete time signals would top my list of examples. (How do you take something so conceptually simple, and fill 120 pages with dense prose? Somebody should know the details, in all its glorious minutiae, if only to pass it to the next generation. But how much of it is useful to a practicing engineer?) > > - This is different in case of an image sensor ? Why ? Because > each pixel output is an analog signal and all of > that signal gets converted into a digital value ? Do I use an > ADC running at 40 MSamples/second since the > pixel output 40 MHz ? > How do I calculate the required memory ? Intuitively, you are capturing image frames. The pixel content makes sense only in context of the frame. Calculate the memory required to hold a complete frame. > > Is it simply 40 MS/s x 16 bits (adc resolution) for each pixel > or just 16 bits per pixel ? > If each frame is 320 x 256 then data per frame is - (320x256) x > 16 bits, why not multiple this by 40 MS/s like > you would for any other random analog signal ? Because each sample is at most one pixel, not an entire 320x256x16 frame buffer.Article: 133252
techG wrote: > Hi all, > I have a camera and a Virtex-5 FPGA, and i would like to store frames > in FPGA Block Ram. > In my design (that worked with Spartan-3E) i need to double camera > clock frequency, in order to get all data, because camera send data on > both clock edges. > The problem is the following: I can't use DCM, because camera clock > frequency is about 163 ns (~6 Mhz), and when I'm trying to generate > DCM (selecting Maximum Range Mode) , Xilinx Clock Wizard says that > "DLL Low Frequency Mode Range is: 19-32 Mhz, and DFS Low Frequency > Mode Range is 1-40 Mhz". > How can I avoid this problem? Do you think that I could use component > DCM of Unisim Library? Moreover, isn't there a VHDL 2X Clock > Multiplier that works fine? > > Giulio Hi Giulio, So, your input frequency is 6MHz. The wizard tells you that "DFS Low Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. Perhaps you should use your DCM in DFS Low Frequency Mode. HTH., Syms. p.s It's Hz not hz.Article: 133253
On Jun 22, 1:48=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > techG wrote: > > Hi all, > > I have a camera and a Virtex-5 FPGA, and i would like to store frames > > in FPGA Block Ram. > > In my design (that worked with Spartan-3E) i need to double camera > > clock frequency, in order to get all data, because camera send data on > > both clock edges. > > The problem is the following: I can't use DCM, because camera clock > > frequency is about 163 ns (~6 Mhz), and when I'm trying to generate > > DCM (selecting Maximum Range Mode) , Xilinx Clock Wizard says that > > "DLL Low Frequency Mode Range is: 19-32 Mhz, and DFS Low Frequency > > Mode Range is 1-40 Mhz". > > How can I avoid this problem? Do you think that I could use component > > DCM of Unisim Library? Moreover, isn't there a VHDL 2X Clock > > Multiplier that works fine? > > > Giulio > > Hi Giulio, > So, your input frequency is 6MHz. The wizard tells you that "DFS Low > Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. Perh= aps > you should use your DCM in DFS Low Frequency Mode. > HTH., Syms. > p.s It's Hz not hz. If I remember right (I am at home on this beautiful sunday) the output frequency then must be above 19 MHz. So you would have to multiply by 4 and then use a flip-flp to divide by 2. The suggested use of the DDR input seems to be best, it gives you two parallel bits at the 6 MHz frequency. If you prefer 12 MHz, I could mention "my" frequency doubler from "six easy pieces". There are several solutions... Peter AlfkeArticle: 133254
On Jun 22, 10:48=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > Hi Giulio, > So, your input frequency is 6MHz. The wizard tells you that "DFS Low > Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. Perh= aps > you should use your DCM in DFS Low Frequency Mode. > HTH., Syms. > p.s It's Hz not hz. I believe the problem is that the clock doubler is one of the DLL (not DFS) outputs, where the minimum input frequency, even in low frequency mode, is 19 MHz. Regards, -- Hauke DArticle: 133255
Rob wrote: > I've never personally designed with PCI but Austin made note in the > previous discussion that: > > "PCI at 3.3V REQUIRES reflective wave switching. That means > the inputs have overshoot and undershoot BY DESIGN." > > Rob And that should be fine as long as the overshoot falls within the acceptable range of the FPGA such as that defined by the Altera Cyclone III Device Datasheet: DC and Switching Characteristics, table 1-2, right? Big table, second page, hard to miss (at least for some readers). There's an added advantage for modern CMOS drivers that are actively driving the line: not only does the PCI clamp help out but the driver actively pulls reflections back *down* to the positive rail when driving logic high; FETs are bidirectional, after all, and the IBIS models show the data to support this. It's the non-driving FPGA I/Os that are subject to the reflective wave that are under the greatest stress. Even then, however, short PCI busses don't overdrive long enough to create problems for many lower speed signals like PCI. Add other devices along the path and you have other PCI clamps adding together to tame the reflections. I'd appreciate any feedback on this perspective. Engineering discussions often fall on deaf ears when application notes or data sheets say "don't do this" even though it's followed with "unless you perform due diligence." - John_HArticle: 133256
Hauke D wrote: > On Jun 22, 10:48 pm, "Symon" <symon_bre...@hotmail.com> wrote: >> Hi Giulio, >> So, your input frequency is 6MHz. The wizard tells you that "DFS Low >> Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. >> Perhaps you should use your DCM in DFS Low Frequency Mode. >> HTH., Syms. >> p.s It's Hz not hz. > > I believe the problem is that the clock doubler is one of the DLL (not > DFS) outputs, where the minimum input frequency, even in low frequency > mode, is 19 MHz. > > Regards, > -- Hauke D I see your point. I suggest multiplying by 4 and then dividing by two using clock enables in the fabric. Cheers, Syms.Article: 133257
On Jun 22, 10:48 pm, "Symon" <symon_bre...@hotmail.com> wrote: > techG wrote: > > Hi all, > > I have a camera and a Virtex-5 FPGA, and i would like to store frames > > in FPGA Block Ram. > > In my design (that worked with Spartan-3E) i need to double camera > > clock frequency, in order to get all data, because camera send data on > > both clock edges. > > The problem is the following: I can't use DCM, because camera clock > > frequency is about 163 ns (~6 Mhz), and when I'm trying to generate > > DCM (selecting Maximum Range Mode) , Xilinx Clock Wizard says that > > "DLL Low Frequency Mode Range is: 19-32 Mhz, and DFS Low Frequency > > Mode Range is 1-40 Mhz". > > How can I avoid this problem? Do you think that I could use component > > DCM of Unisim Library? Moreover, isn't there a VHDL 2X Clock > > Multiplier that works fine? > > > Giulio > > Hi Giulio, > So, your input frequency is 6MHz. The wizard tells you that "DFS Low > Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. Perhaps > you should use your DCM in DFS Low Frequency Mode. > HTH., Syms. > p.s It's Hz not hz. Unfortunately, I can't use 2xClockOutput in DFS Low Frequency Mode :( Thank you all for the help, I'll try both ways: 1) using a DCM and dividing the 4x output by two (can I use another DCM for this purpose?) 2) using IDDR flip-flops GiulioArticle: 133258
On Jun 22, 5:05=A0pm, techG <giuliopul...@gmail.com> wrote: > On Jun 22, 10:48 pm, "Symon" <symon_bre...@hotmail.com> wrote: > > > > > techG wrote: > > > Hi all, > > > I have a camera and a Virtex-5 FPGA, and i would like to store frames > > > in FPGA Block Ram. > > > In my design (that worked with Spartan-3E) i need to double camera > > > clock frequency, in order to get all data, because camera send data o= n > > > both clock edges. > > > The problem is the following: I can't use DCM, because camera clock > > > frequency is about 163 ns (~6 Mhz), and when I'm trying to generate > > > DCM (selecting Maximum Range Mode) , Xilinx Clock Wizard says that > > > "DLL Low Frequency Mode Range is: 19-32 Mhz, and DFS Low Frequency > > > Mode Range is 1-40 Mhz". > > > How can I avoid this problem? Do you think that I could use component > > > DCM of Unisim Library? Moreover, isn't there a VHDL 2X Clock > > > Multiplier that works fine? > > > > Giulio > > > Hi Giulio, > > So, your input frequency is 6MHz. The wizard tells you that "DFS Low > > Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. Pe= rhaps > > you should use your DCM in DFS Low Frequency Mode. > > HTH., Syms. > > p.s It's Hz not hz. > > Unfortunately, I can't use 2xClockOutput in DFS Low Frequency Mode :( > Thank you all for the help, I'll try both ways: > 1) using a DCM and dividing the 4x output by two (can I use another > DCM for this purpose?) > 2) using IDDR flip-flops > > Giulio Giulio, I would advise against using a second DCM: It creates additional jitter, and it makes it reallycomplicated to solve your inherent phasing problem: When you multiply by 4 and then divide by 2, you have a 50% chance of picking up a wrong phase relationship between your 6 and 12 MHz clocks. Here is one solution: Use the 24 MHz clock to generate a delayed version of your 6 MHz clock. Then control your divide-by-2 flip-flop such that it can change state only when both your 6 MHz signals have the same level. Use an XOR. I think the DDR method, or "my" frequency doubler are better solutions. Peter AlfkeArticle: 133259
hello. i am trying to set up ethernet interface between my pc and a XUP Virtex2Pro board, and want to use tcp/ip. xilinx edk seems to have the lwip stack as a library. is it necessary to use this library, or can one still implement tcp/ip by suitably changing the ethertype/length field in the frame? in my case, only one pc will communicate, and the physical address will not change... so, can i write a frame receive handler to strip the header and ip addresses to access data? my real concern is the pc side... will setting the ethertype field to tcp/ip work or is it necessary to use lwIP? pls reply asap thanks vikramArticle: 133260
Joseph H Allen wrote: > So in either of these, you typically simulate and have all signals dumped to > a huge output file (using $dumpvars(0); $dumpon; for vcs or $shm_open(...); > $shm_probe(..); for ncsim). Then you can explore the design hierarchy and > choose which signals to view in vcs -RPP or simvision. The same is true for > even icarus verilog with gtkwave. In my mind this might work for small designs, but the huge amount of signal logging slows down the simulation. I usually like to log just part of the signals needed, which is the normal way Modelsim works. I never understood the way vcs liked to work, it felt so unintegrated (in the past, the new GUI is and quite good copy of modelsim gui :)) > However with modelsim it looks like there is no way to do this. Instead, > when you add a signal to the viewer in the GUI, it re-runs the entire > simulation to get the new signal. Am I missing something or is this really > how it works? I can't believe that it would really work this way. In the beginning of simulation just add "log -r /dut/interesting_module/*" and after that you can add signals from that block also after the simulation to the viewer. And you can also open the wave from the GUI after the simulation, or open many different waves logged from different places and merge or compare them in the GUI (open dataset functionality etc) > (Also the crippled free modelsim is slower than icarus). And I have seen Modelsim SE to be much faster than VCS in some designs. Each design is different beast in terms of simulation speed and what simulator is the fastest. Unfortunately none of the free simulators support mixed language simulations, and almost all of the designs I see commercially are mixed language, so it's quite hard to test the speed differences. --KimArticle: 133261
Hi group, Another video by me to showcase another application I made. Just to show can be done with a Spartan 3E Starter Kit, creativity and some free time. Don't be afraid to ask for code ;) Enjoy! http://vimeo.com/1206340 (more info on the other side of the link) Regards, -SergioArticle: 133262
vikram wrote: > in my case, only one pc will communicate, and the physical address > will not change... so, can i write a frame receive handler to strip > the header and ip addresses to access data? > my real concern is the pc side... will setting the ethertype field to > tcp/ip work or is it necessary to use lwIP? Of course you don't *need* lwIP - it's "only software" after all - but how much work you need to do depends on how much IP functionality you require, and I'm guessing it's more than you think. I wrote a simple diagnostic suite for a custom Altera-based board that received an ICMP echo (ping) and sent a response without an IP stack. However, attempt to do much more than that and your software effort starts to increase dramatically. If you're only interested in, for example, receiving UDP packets and not much else, you're probably OK on a well-behaved system (no fragmentation etc). You need to check the ethtype field, filter unwanted addresses etc etc and do some simple parsing on the IP/UDP headers in order to locate the data. Of course you still need to interface to the MAC driver, which may or may not be trivial depending on the driver itself... 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: 133263
On 23 Jun., 00:02, Hauke D <hau...@zero-g.net> wrote: > On Jun 22, 10:48=A0pm, "Symon" <symon_bre...@hotmail.com> wrote: > > > Hi Giulio, > > So, your input frequency is 6MHz. The wizard tells you that "DFS Low > > Frequency Mode Range is 1-40 Mhz". Notice how 6 is between 1 and 40. Per= haps > > you should use your DCM in DFS Low Frequency Mode. > > HTH., Syms. > > p.s It's Hz not hz. > > I believe the problem is that the clock doubler is one of the DLL (not > DFS) outputs, where the minimum input frequency, even in low frequency > mode, is 19 MHz. So? Instead use the CLKFX output in maximum range mode to provide a 24MHz clock and read in the data on every second clock cycle. (Do NOT divide the clock using DFFs, instead use clock enables). Kolja SulimmaArticle: 133264
Peter Alfke wrote: > On Jun 22, 5:05 pm, techG <giuliopul...@gmail.com> wrote: > I think the DDR method, or "my" frequency doubler are better > solutions. > Peter Alfke Hi Peter, The DDR method makes the logic more complicated. You have to deal with two samples every clock cycle. As for "your" frequency doubler, in the right hands it can be a useful tool. However, with a simple synchronous solution available using a DCM, I wouldn't recommend this path, especially for beginners. YMMV, Syms.Article: 133265
On 2008-06-19, _TK_ <tom_kuhn@btopenworld.com> wrote: > My problem is, that presented with a read / write API functions I have > no idea as to what I *should* be writing to or reading from the FPGA > and to which registers (instruction / test). My goal (at least for > now) is to sample the state of every pin on the device. This information is usually provided in BSDL (Boundary Scan Description Language) files. Try to ask Quicklogic about this. (A quick search at quicklogic.com didn't turn up anything when I tried it.) /AndreasArticle: 133266
Symon (symon_brewer@hotmail.com) wrote: : Jeff Cunningham wrote: : > : > Speaking of FPGA alternatives, this recently caught my eye. Don't know : > much about it, but it sure looks cool: : > : > http://www.tilera.com/products/processors.php : > : > -Jeff : Jeff, : Where have I seen that before? : Ah yes, http://en.wikipedia.org/wiki/Transputer : Syms. One of the things that strikes me about the Transputer is that it was parallel hardware designed hand-in-hand with parallel software. Not C/C++ It seems odd that there is so much convergence happening between a very complex highly sequential CPUs and functionally simple, highly parallel FPGA type devices, with lots of innovative hardware flying about. All this convergence is happening in hardware, but for it to really work don't the software environments need to do the same... --- cdsArticle: 133267
Kim Enkovaara <kim.enkovaara@iki.fi> writes: > Joseph H Allen wrote: > >> So in either of these, you typically simulate and have all signals dumped to >> a huge output file (using $dumpvars(0); $dumpon; for vcs or $shm_open(...); >> $shm_probe(..); for ncsim). Then you can explore the design hierarchy and >> choose which signals to view in vcs -RPP or simvision. The same is true for >> even icarus verilog with gtkwave. > > In my mind this might work for small designs, but the huge amount of > signal logging slows down the simulation. I usually like to log just I've used this methods for many years for large ASIC designs. It slows down the simulation, but I find this much more effective than running the simulation again. Also it's more cost effective to release the expensive simulation license and use the cheaper waveform viewer for debugging. You can even run the simulations during the night and have the VPD (TRN, SST or whatever you prefer) files waiting for you the next morning. > part of the signals needed, which is the normal way Modelsim works. > I never understood the way vcs liked to work, it felt so unintegrated > (in the past, the new GUI is and quite good copy of modelsim gui :)) I never understood the way Modelsim liked to work :-) I prefer DVE over Modelsim any day. I guess it's a matter of taste. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 133268
Hello, I've been searching the internet for days now and still I'm not sure about what I am trying to do. Okay now, I've got a software implementation in ANSI-C for a complex database searching. The database is a proprietary format where I am saving data, which has to be given as a result, depending on the input data. Problem is, the software implementation is far to slow. Now I am looking for alternative ways for a faster implementation and came across the idea to implement the whole database searching as electronic circuit in an FPGA. The database is of course far too big to save it inside an FPGA, e.g. the BlockRAMs of a Spartan3. Therefore external memory has to be used, slowing down the throughput. Target is a database searching of 262144 elements with 16 bit each in maximum 220 ms. Does anybody have experience with FPGA based database handling or similar tasks? Your urgent response will be highly appreciated! Regards Norman BollmannArticle: 133269
On 23 Jun, 14:00, "Norman Bollmann" <wirdnichtgele...@gmx.net> wrote: > Hello, > > I've been searching the internet for days now and still I'm not sure about > what I am trying to do. Okay now, I've got a software implementation in > ANSI-C for a complex database searching. The database is a proprietary > format where I am saving data, which has to be given as a result, depending > on the input data. Problem is, the software implementation is far to slow. > > Now I am looking for alternative ways for a faster implementation and came > across the idea to implement the whole database searching as electronic > circuit in an FPGA. The database is of course far too big to save it inside > an FPGA, e.g. the BlockRAMs of a Spartan3. Therefore external memory has to > be used, slowing down the throughput. Target is a database searching of > 262144 elements with 16 bit each in maximum 220 ms. > > Does anybody have experience with FPGA based database handling or similar > tasks? Your urgent response will be highly appreciated! How slow is the software solution? Are you sure it can't be done on a faster PC? Have you tried searching in parallel? i.e. 64-bits at a time. That would mean you need to search 64k entries in 220ms. That's 3us per entry. You can execute quite a few instructions on a PC in that amount of time. A dataset of that size will fit in to your cache too. JonArticle: 133270
Norman Bollmann wrote: > > > Now I am looking for alternative ways for a faster implementation and > came across the idea to implement the whole database searching as > electronic circuit in an FPGA. The database is of course far too big > to save it inside an FPGA, e.g. the BlockRAMs of a Spartan3. > Therefore external memory has to be used, slowing down the > throughput. Target is a database searching of 262144 elements with 16 > bit each in maximum 220 ms. > > Hi Norman, If I understand correctly, you want to do one 16 bit compare per 800ns. That's easy to do with an FPGA and some memory. You can go maybe 3 orders of magnitude faster than that with (say) a 64 bit DDR2 external memory. The FPGA companies and others sell development boards with memory on them. HTH., Syms.Article: 133271
On Mon, 23 Jun 2008 15:00:09 +0200, "Norman Bollmann" wrote: >Problem is, the software implementation is far to slow. In which case the algorithm is probably bad. Modern database technology is pretty darned good, and is largely limited by storage access speed. I think you should start by looking at better ways to index your database, rather than going for more brute-force speed. >Target is a database searching of >262144 elements with 16 bit each in maximum 220 ms. Do you really mean this? Only half a megabyte of data? That's easily small enough to fit into main memory of any reasonable computer. At 220ms per 256K words you have nearly a microsecond to work on each word - enough time for dozens or even hundreds of machine instructions. Are your numbers wrong? If not, there's something sadly wrong with your software. >Does anybody have experience with FPGA based database >handling or similar tasks? Your urgent response will >be highly appreciated! I'm sure it can be done, and I'm vaguely aware of hearing of people doing such things, but you haven't yet made a case for needing it. FPGAs can provide impressive speedup for some types of sorting and indexing tasks, but it is often harder to decide how to keep the datapath busy than it is to decide what to do with the data when you've got it inside the FPGA fabric. Database problems tend to have patterns of address activity that fly around all over the place, as a strong function of the data itself, under control of complicated algorithms. That's something that software tends to be much better at than hardware. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 133272
Hi, I have designed a VHDL single clock FIFO with write pointer that can either be confirmed or cleared that is the read side of the fifo does see the write counters only when these have been confirmed by the write side. One application can be the confirmation of a packet including a checksum at the end. If the checksum is not correct the whole packet is not released to the read side of the FIFO. Confirmation and clearing of the write pointer does also work while read pointer is in progress (that is reading a packet received and confirmed before). Now I want to implement the same mechanism for dual clock fifo. As a starting point I am using the Xilinx paper "xapp131.pdf" to build a dual clock fifo. What is your opinion about integrating that write pointer confirm / clear mechanism into the Xilinx module ? Where do you see pitfalls on confirming / clearing the write pointer on dual clock fifo? Thank you for your opinion. Rgds AndreArticle: 133273
On 23 Jun, 11:42, christopher.saun...@durham.ac.uk (c d saunter) wrote: > Symon (symon_bre...@hotmail.com) wrote: > : Jeff Cunningham wrote: > > : > > : > Speaking of FPGA alternatives, this recently caught my eye. Don't know > : > much about it, but it sure looks cool: > : > > : >http://www.tilera.com/products/processors.php > : > > : > -Jeff > > : Jeff, > : Where have I seen that before? > : Ah yes,http://en.wikipedia.org/wiki/Transputer > : Syms. > > One of the things that strikes me about the Transputer is that it > was parallel hardware designed hand-in-hand with parallel software. > > Not C/C++ > > It seems odd that there is so much convergence happening between a very > complex highly sequential CPUs and functionally simple, highly parallel > FPGA type devices, with lots of innovative hardware flying about. > > All this convergence is happening in hardware, but for it to really work > don't the software environments need to do the same... > > --- > > cds The new XMOS devices (out of the same stable as the transputer) are intended to bridge the gap between FPGAs and processors: http://www.xmos.com/ LeonArticle: 133274
Is the concept of "Content addressable memory" known to you? http://en.wikipedia.org/wiki/Content-addressable_memory
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