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 hope it is understood by now that all these complicated suggestions are unnecessary or counter-productive (pun intended). The whole counter, including its front-end is (and behaves like) a completely synchronous counter, with all outputs properly available about a nanosecond after each count clock tick. Let's keep simple things simple! :-) Peter Alfke, Xilinx ====================== Francisco Rodriguez wrote: > > "Erez Birenzwig" <erez_birenzwig@hotmail.com> escribió en el mensaje > news:x_bsb.1057$%o4.34282@news.xtra.co.nz... > > "Jim Granville" <jim.granville@designtools.co.nz> wrote in message > > news:3FB1470C.F22@designtools.co.nz... > > > I think item 4) was to cover capture of the counter at any > > > instant, and to cover the carry ripple. > > > I'm with Peter in questioning 4). > > > Carry ripple is certainly long, but this is on the .D side, and > > > determines the NEXT Clock delay. However any Capture is on the .Q side, > > > and all Q's will be fully sync (no ripple adders ) > > > Capture of both the prescaler, and long counter, can be clock > > > syncronous, and does not need any enables. > > > > 4) is to cover the fact that once you enable the +1 on the long carry > chain > > you can't > > sample it at the next clock cycle (It won't be ready by then), so you have > > to latch the > > previous value which is the new count value. > > > > The problem is that I must be able to sample the counter on every arbitary > > clock cycle > > therefore it must be glitch free. > > > It wouldn't be easier to always latch the low part? > That is, you build a circuit with a latency of 1 cycle to load a, and then > you have new a+1 result on every cycle. > > Something like this: > > process (...) > begin > if rising_edge(clk) then > a_low <= a_low + 1; > if (a_low = x"FFFF") then > enable_high <= '1'; > else > enable_high <= '0'; > end if; > if (enable_high = '1') then > a_high <= a_high + 1; > end if; > late_a_low <= a_low; > end if; > end process; > > And the output is > a <= a_high & late_a_low; > > Of course, additional logic is needed to load the counter with a predefined > value. > > Once you get a (correct) value on a (by the load operation, not shown > above), > a_low maintains the low part of the _next_ count, while a_high has the high > part of the _current_ count. > That is why you need to delay a_low by a clock period. > > I've tested a similar approach for a 64 bit counter running >200MHz on a > virtex2 -4 speed grade > although in my case the counter was built from 8 8-bit blocks. > > Regards > Francisco > > > The counter that I need doesn't require a clear but thanks for the > thought, > > it needs a load though. > > > > > > > > Capture and Clear (can be more application usefull), can > > > be done in a single clock with a little more .D side logic. > > > > > > Capture of fractional clocks, to push the time resolve better than > > > 1/clock speed, is challenging, but looks possible in modern FPGA. > > > > > > -jg > > > >Article: 62976
I am convinced that a generic version would inevitably be inferior in performance and/or price, compared to the dedicated one. I know that Ken and Göran used many Xilinx-specific features when they designed PicoBlaze and MicroBlaze. And I assume that the Altera guys were operating in a comparable way when they designed Nios. The generic ones will be the "worst of both worlds", unless you really believe in clairvoyant synthesis. Peter Alfke, XilinxArticle: 62977
"Fernando" <fortiz80@tutopia.com> wrote... > The problem I'm looking operates on data sets ~16GB. Computation > takes about 0.5 sec, compared with ~2 sec required to download > (@100MHz). BRAM is used as cache for bandwidth. Have you considered compressing one or all of your data sets? If you can compress the data sets, you will both reduce the bandwidth to the memory and the size of the memory buffer. We have seen vision applications where the data sets were binary templates, and simple compression schemes offered a 10x improvement in memory size/bandwidth, and only required a small decompressor to implement in the FPGA. The engineering cost for developing the compression algorithm and associated fpga logic was MUCH lower than the cost to layout and model a multi-DIMM pcb. Whether compression will help, all depends on what the data looks like. Also, if you are passing over the same data multiple times, as you would if you were using the same data to compute multiple results, it might benefit you to compute multiple sets of results per pass of the data. Depending on your problem, it might make sense to look at solution with the goal of minimizing the dataflow, rather than simplifying the computation. We have an engineering mantra here, "the pins are the most expensive part of the fpga". This is not only due to the fact that the number of pins on a die are proportional to the square root of the number of gates in a given device family, but also due to the fact that lots of traces on a board add to the cost of layout, verification, and fabrication. Regards, Erik Widding. --- Birger Engineering, Inc. -------------------------------- 617.695.9233 100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.comArticle: 62978
On Tue, 11 Nov 2003 18:10:33 +0100, rasti123@eunet.yu wrote: >Dear Allan, > >Thank you for your answer. When you say binary format, what precisely >do you mean? On the other hand I was thinking of using Xilinx NGC >netlist instead of EDIF. Do you think this would help? I have read >that NGC is a encrypted netlist format, and if there is no easy way of >converting NGC to EDIF, than maybe it would be a solution to my >problem. NGC would be better than EDIF. You will probably also have to ship something that will allow your customers to simulate the core. This is typically done by shipping a pre-compiled library (to suit whatever simulator your customers use) with an NDA (non-disclosure agreement). Regards, Allan.Article: 62979
> I am convinced that a generic version would inevitably be inferior in > performance and/or price, compared to the dedicated one. But, there's nothing like rolling your own for fun/educational purposes and then having something useful at the end of it all. I think it would also be easier to add new features and enhancements to your own design since the code was developed in your own way of thinking and coding style. In the end, maybe it will just be "yet another RISC core" on opencores.org, but at least it's yours and you'll have a good understanding of it's capabilities...even if all it can do is blink an LED! BPArticle: 62980
>You can use Virtex or Spartan-II to interface with 5V PCI bus >and retain full compliance per the specification. You can use >any of our devices, even Spartan3 and Virtex2Pro, with the 5V >PCI bus, but you need some level translators. This is certainly >a functional solution (I've tested it personally) but it is not >compliant with the letter of the specifications. Do you have any suggested parts for the level translators? I know about the IDT QuickSwitchs. >The specifications are pretty clear that you are allowed only >one component, and that is your "PCI component" and all bus >signals must attach directly to that one component. I don't really care about the rules just to check off the boxes. I'm willing to cheat if I can convince myself (and some friends?) that the total system will work solidly. There are two parts to that. One is in limited cases, say one fewer card on the bus. The other is in any configuration legal under the specs. How far did you bend the rules? How much testing/Spicing did you do? Do modern FPGAs have a low enough pin capacitance so that the added capacitance of something like a QuickSwitch fits the old rules? Or are they fast enough to go through an honest repeater type chip so there is only one bus load? Mostly, I'm just curious. If/when I get enough time, I'd like to build a hobby priced board that I can plug into something like PCI. For now, that's old 33 MHz 5V PCI. Spartan-II seems like the best bet. But the clocking in newer chips is attractive. If there is a solid way to connect them to old PCI, I'd add that to my list of chips to consider. Maybe if I wait a bit longer low cost systems will be readily available that have real 3V PCI slots. :) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 62981
hi read the answer database record no: 17165 and 14456 from xilinx. bye RamArticle: 62982
Followup to: <3FB15BB3.5B87@designtools.co.nz> By author: jim.granville@designtools.co.nz In newsgroup: comp.arch.fpga > > H. Peter Anvin wrote: > > > > I have no way to know how this is turning out. My current goal is to > > make sure it implements in < 1000 LEs on Cyclone, without using > > blockRAM for the register file. > > Isn't some form of BlockRAM a defacto standard on all > 'consider for new design' FPGAs - so not using that would > restrict your options ? > Some form thereof, yes, but I tend to run out of blockram a lot faster than running out of LUTs. Note that it's not that I'm saying you couldn't use it, I'm saying I want to be at < 1000 LE without using blockram. About 300-400 of that would be replacable with a blockram. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 62983
Followup to: <3FB16CEB.C46327DE@xilinx.com> By author: Peter Alfke <peter@xilinx.com> In newsgroup: comp.arch.fpga > > I am convinced that a generic version would inevitably be inferior in > performance and/or price, compared to the dedicated one. I know that Ken > and Göran used many Xilinx-specific features when they designed > PicoBlaze and MicroBlaze. And I assume that the Altera guys were > operating in a comparable way when they designed Nios. > The generic ones will be the "worst of both worlds", unless you really > believe in clairvoyant synthesis. > Of course. But it would have the advantage that it could run on either. -hpa -- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64Article: 62984
I want to purchase fifty Xilinx Platform Flash XCF01S online. It is not available at Avnet and NuHorizons and I am unable to find any other sales representative to purchase it. Can anyone please guide me from where can I purchase it? The order may be shipped to Pakistan or America. Regards Atif Research AssociateArticle: 62985
"H. Peter Anvin" <hpa@zytor.com> wrote in message news:borkpf$p7v$1@cesium.transmeta.com... > Followup to: <nZ%qb.101301$mZ5.680324@attbi_s54> > By author: "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> > In newsgroup: comp.arch.fpga > > > > This is true, except for generating the flags on the final add. Well, you > > can either generate all the flags, or only the signed or unsigned flags. > > For the intermediate adds only the carry, or lack of carry, from the high > > bit is important. To detect signed overflow or underflow (more negative > > than can be represented) requires comparing the carry into and out of the > > sign bit. > It depends. Some architectures define CF=0 to mean borrow-out from a > subtraction. Under that definition (used by the PDP-11, for example), > SUB is equivalent to NEG + ADD (a desirable property in my opinion); > under the "other" definition (as used by among others Intel processors > ever since the 4004), SUB ends up producing the opposite carry from > NEG+ADD. For unsigned arithmetic, or all except the most significant word of multiword signed arithmetic, yes, carry is the complement of borrow. Somewhere back in the thread I wrote that. For the most significant word or only word for signed arithmetic overflow/underflow must be computed differently. -- glenArticle: 62986
Hi Mark, > I have a question concerning the logic implementation techniques of > SRAM FPGAs and OTP FPGAs. > > Logic in Xilinx FPGAs is implemented in LUTs. Logic in Quicklogic > FPGAs is implemented in a multiplexer structure. > > Why does these two programming technologies use different techniques > to implement logic ? You mean because Quicklogic uses an OTP-Solution and Xilinx devices are reprogramable? I don't know the Quicklogic devices in detail, but I guess they are using so-called Antifuse Technology. One reason for such solutions is speed. In an SRAM/EEPROM-based device the junctions of the interconnect are made by transfergates and/or multiplexers. This costs time. In antifuse technology, connections are created more or less statically during programming. Another advantage of antifuse over the other technologies is that you do not need to have a memory cell that says whether some switch is "on" or "off". That is, you save chip area which makes it cheaper for production. Less power is needed as well. The reason why logic is implemented in a different manner might be induced by the basic technology. In an SRAM-based device it is perhaps more efficient to go the LUT-way. Another interesting side-effect here is that one can use the LUTs as small RAM-blocks in his design. While a LUT could be made well out of antifuse cells, a multiplexer structure yields perhaps to better speed characteristics. But I'm not the expert here. Regards, MarioArticle: 62987
Peter Alfke <peter@xilinx.com> wrote in message news:<3FB118A8.2B5D02BF@xilinx.com>... > As I had posted a while ago, the Virtex-II BlockRAM is surprisingly > efficient as a priority encoder. > Use one BlockRAM as a dual-ported 4K x 4 ROM. > Feed 12 inputs as address to one port, and the next 12 bits as address > to the other port. That gives you two sets of 4 outputs defining the > priority-encoded position in the two 12-bit inputs separately.No problem > with multiple 1s! Should work at 200+ MHz, but note that the BlockROM > is a synchronous device, it operates on a clock edge! > The remaining 8 inputs and the combining of the eight BlockROM outputs > can be done the conventional way, but might also be done in another > BlockROM (generating a second clock latency!) > Peter Alfke, Xilinx Applications Dear Mr Alfke, thank you for your proposal. Do you have some application note in which the connection of the ROMs is explained? How many ROMs are used at all? As I understand you there are used four ROMs? Do you mean with "to one port" the write address port and with "to other port" the read address port? Thank you for your help. Best regards A. Vazquez G&D System DevelopmentArticle: 62988
"Morten Leikvoll" <m-leik@online.nospam> ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:d28sb.5758$mf2.78962@news4.e.nsc.no... > "óÅÒÇÅÊ úÏÒÉÎ" <zlogic@udm.ru> skrev i melding > news:boqoau$22r0$1@hq.mark-itt.ru... > > Hi, ALL. > > > > Problem with installation subj. > > In time installation the program java.exe is under abnormal condition > > finished. > > It happens in WIN 98 and in WIN XP. Processor - CELERON 1700. > > What to do, help me, please. > > My weak memory seem to remember something about java and this problem... You > needed the latest java runtime environment to install this? Hello. I have instslled JRE 1.3. All works. However only under WIN98. And me is necessary that all worked under WIN XP. Can I it make? And how? Beforehand thank.Article: 62989
>Showing my age here.... when I was routinely designing PCBs >around 8-10 years ago, I was often given a very hard time by >assembly subcontractors if I put vias inside an SMD pad - they >used to complain about solder hogging or some such manufacturing >folklore. What are the up-to-date design rules for putting vias >in or very close to a pad? That was the party line many years ago. The problem is that the solder dives into the via (surface tension) so you don't have as much solder left to make contact with the part. I think it's reasonably common now. It's another tool in the struggle to reduce the inductance on bypass caps. Check with your assembly house. Sometimes they fudge the hole size in the stencil for the solder paste, or use a thicker sheet to make the stencil. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 62990
"Anil Khanna" <anil_khanna@mentor.com> wrote in message news:<3f906bdc$1@solnews.wv.mentorg.com>... > Its all in the options. > > Right Click "Post-PAR Static Timing" and choose your report options. > > For analyzing specific paths - launch the "Timing Analyzer". > > Its much better in 6.1! > > "Muthu" <muthu_nano@yahoo.co.in> wrote in message > news:28c66cd3.0310122152.8de177d@posting.google.com... > > Hi, > > > > I am using ISE5.1i...XST synthesis tool. > > > > At the end of synthesis, XST generates defualt timing report for 1 or > > 2 paths. > > > > How can i generate a timing report after synthesis for more than 100 > > paths? > > > > ie., as like .twr after Place and route. > > > > And How can i measure the time dealy between 2 specific points... > > Points could be FF,mux or any logic > > > > Thanks in advance. > > > > Regards, > > Muthu Post PAR can only be run with the Map results Right. But i need to take the report from XST itself?Article: 62991
"John_H" <johnhandwork@mail.com> writes: > Great comments, Martin. > Thanks! > A point I'd add to the original poster's concerns about the "swiss cheese" > ground and power planes you can get with too many vias, some numerical work > has shown that - at least for closely spaced ground/power pairs - the added > impedance from the swiss cheese under a BGA package (much worse than a QFP) > is sub-nanohenry. Don't worry so much about the holes in the plane, worry > about the spacing between the planes (smaller is better, 4 mil perhaps?) and > good decoupling cap attachment. Two vias are often used on each end of the > decoupling caps in high speed designs to halve the impedance to the ground > and power planes. The "*very* short tracks" is a noteworthy comment as > well; it's easy to make a stiff decoupling cap a bit soft by adding a little > track between the pad and via(s). > Another trick I used that I forgot to mention is to populate groups of caps in a line with one large "pad" connecting them all. Through that pad go 2-3 vias per capacitor to reduce inductance. However, as the illustrious Lee Ritchey would point out I have no science to back up any claim that this is a "good" way of doing things... it feels right. At some point I intend to do some simulation and maybe even (gasp!) some measurements... Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 62992
> A point I'd add to the original poster's concerns about the "swiss cheese" > ground and power planes you can get with too many vias, some numerical work > has shown that - at least for closely spaced ground/power pairs - the added > impedance from the swiss cheese under a BGA package (much worse than a QFP) > is sub-nanohenry. Don't worry so much about the holes in the plane, Although watch out for accidentally created slots in the ground plane. If you're not sharing vias for decouplers to keep impedances down and you've a lot of them you can end up creating slots in the ground plane if you've many of them near each other. This can be easily done if your decouplers are neatly arranged on the same X/Y coordinates per side. Slots are very bad news for high speed signals. Just something to be aware of. Nial ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design www.nialstewartdevelopments.co.ukArticle: 62993
Hi, thanks for your reply. > Have you considered compressing one or all of your data sets? I will use compression for the output stream (results). For main memory I'm using floating-point, so I'd need lossless compression. I've never implemented any compression modules myself, but I don't think it can be done in realtime for the amount of data I need. I will gladly accept opinions from the group on this. > Also, if you are passing over the same data multiple times, as you would if > you were using the same data to compute multiple results, it might benefit > you to compute multiple sets of results per pass of the data. I am already doing something like that. Of course, limited by the amount of RAM inside the chip. There is also a fundamental time dependence in my algorithm, but we got around that parallelizing each step in between. > We have an engineering mantra here, "the pins are the most expensive part of > the fpga". This is not only due to the fact that the number of pins on a > die are proportional to the square root of the number of gates in a given > device family, but also due to the fact that lots of traces on a board add > to the cost of layout, verification, and fabrication. I completely agree, that's why I'm a little inclined towards serial solutions, but seems like those are not ready yet...at least for memory.Article: 62994
Thanks. However, I still have problems. The board can boot up with the = generated .ACE file which is in CF card. But the other data files can = still not be visited. How to let FPGA visit the data files in CF card?=20 Regards, YUWEI -----Original Message----- From: ram [mailto:ramntn@yahoo.com]=20 Posted At: 2003=C4=EA11=D4=C212=C8=D5 13:31 Posted To: comp.arch.fpga Conversation: How to visit the files in CF cards Subject: Re: How to visit the files in CF cards hi read the answer database record no: 17165 and 14456 from xilinx. bye RamArticle: 62995
Sorry, Erez and FPGA friends, Thank you for your advices. After making sure that OBUFs were instantiated properly, I further found out that I didn't check all my external pin connectors on the FF1152 board, which were welded by some company. I was so lucky (?) that I happened to use the specific external pin that was not well-connected to the GCLK pad on the board. Hence my clock was fed to that pad in vain. Everything went fine after I assigned the clock to another GCLK pad. Sorry for this result, but also thank you for your help :-) Regards, Merlin "Erez Birenzwig" <erez_birenzwig@hotmail.com> wrote in message news:<NYasb.998$%o4.33145@news.xtra.co.nz>... > I found out that the DDR FF is optimized out if you do not connect > it to a OBUF of some kind. > If you use a synthesis tool you might want to declare the pin as output > of some kind (Select IO), or just instantiate the OBUF directly in the HDL. > > Erez. > >Article: 62996
I thought just for fun let me try to digitize some video using the input comparator. I am stuck with 3.3 V I/O on Spartan 2 because of the proto board... So then CTT works on 3.3 V and 1.5 V rteference, should do something with 1.5 V signal... But now the problem: ERROR:Place:1747 - The IOB video_in is locked to site P110 in bank 3. This true violates the SelectIO banking rules. Other incompatible IOBs may be locked to the same bank, or this IOB may be illegally locked to a Vref site. Please ? of cause they may be, but they are not... consult the SelectIO application node. where would that be? ERROR:Place:993 - Due to Virtex SelectIO banking constraints, the IOBs in your design cannot be automatically placed. It's a Spartan 2, not a Virtex...! I did: // For the r2r ladder that drives the Vref is here: OBUF_CTT da0(.I(da_output[0]), .O(da_out[0]) ); OBUF_CTT da1(.I(da_output[1]), .O(da_out[1]) ); OBUF_CTT da2(.I(da_output[2]), .O(da_out[2]) ); OBUF_CTT da3(.I(da_output[3]), .O(da_out[3]) ); OBUF_CTT da4(.I(da_output[4]), .O(da_out[4]) ); OBUF_CTT da5(.I(da_output[5]), .O(da_out[5]) ); OBUF_CTT da6(.I(da_output[6]), .O(da_out[6]) ); OBUF_CTT da7(.I(da_output[7]), .O(da_out[7]) ); // The video is on the other side of the comparator... IBUF_CTT vidin(.I(video_in), .O(inbit) ); In the constraints file the ports are specified as normal. All these pins (and no other) are on bank 3. So what do I do wrong? Must be some silly thing... Simulation works fine, 8 bits video, 100 MHz clock, should at least do something..Article: 62997
Hi I'm looking for way to verify an ata/atapi-6 design. I could write one myself, but that would probably take a year or two, and that's not woth the effort. I need it to verify both functionality and timing of a device that shall be plugged onto the IDE bus, between the host and the device. So far I have found a solution from Yogitech (www.yogitech.com) that more or less does what I want, but only for ATA/ATAPI-4. I've searched the net, but haven't found much in addition to Yogitech. Do any of you know of anything that could be of interest, please emali me at frode at HOTEL DELTA DELTA dot NOVEMBER OMEGA, or post your reply here. NB: Since I'm crossposting this accross many groups, and haven't got a "reply-to" field, I'd of course be happy if the replies got to me per email ;-) -Frode, Norway.Article: 62998
Peter Alfke wrote: > > I am convinced that a generic version would inevitably be inferior in > performance and/or price, compared to the dedicated one. I know that Ken > and Göran used many Xilinx-specific features when they designed > PicoBlaze and MicroBlaze. And I assume that the Altera guys were > operating in a comparable way when they designed Nios. > The generic ones will be the "worst of both worlds", unless you really > believe in clairvoyant synthesis. > > Peter Alfke, Xilinx "Clairvoyant Synthesis", now that sounds like a good product! Is there a startup somewhere working on that? I can see product announcements touting the new FPGA CS that eliminates the need for product planners, designers and even testing as it would already know that the design was ready for production! No specs to write, no coding to compile and even simulation could be skipped. Just think of the design you want and out pops a bit file. Boy, what will they think of next? -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 62999
"Bruce P." wrote: > > > I am convinced that a generic version would inevitably be inferior in > > performance and/or price, compared to the dedicated one. > > But, there's nothing like rolling your own for fun/educational > purposes and then having something useful at the end of it all. I > think it would also be easier to add new features and enhancements to > your own design since the code was developed in your own way of > thinking and coding style. In the end, maybe it will just be "yet > another RISC core" on opencores.org, but at least it's yours and > you'll have a good understanding of it's capabilities...even if all it > can do is blink an LED! > > BP When I was in school we worked on a paper design of a microcoded processor as a teaching tool. We had homework on it and had to design new features on our exams. I even had a question about it on my Masters comprehensive exam. I approached my professor about designing a simulation of it to run on the Univac mainframe for the undergrad students to learn from. But I guess I was ahead of my time as he did not see the value in that. Or maybe he had the foresight to see the complications it might create :) I guess this is a pretty common thing at Universities now. All they have to do is get you a FPGA design package with a simulator. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAX
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