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
> Stephen Williams wrote: > > OK, Xilinx was uniquely unhelpful this time, so I resort to this > list. My setup is a SystemACE connected to 1 or 2 Virtex2 FPGAs, > and also to a PPC405GPr running Linux. The second FPGA is optional, > and when the optional FPGA is installed, the JTAG is rerouted through > and a different ACE file supplied. The CF card contains a second > partition where the Linux fs (ext3) lives. Ed McGettigan wrote: > Not enough information on your problem. > 1) In the single Virtex-II case, what does the complete JTAG chain look > like? ACE.TDO --> FPGA1.TDI FPGA1.TDO --> ACE.TDI > 2) In the dual Virtex-II case, what does the complete JTAG chain look like? ACE.TDO --> FPGA1.TDI FPGA1.TDO --> FPGA2.TDI FPGA2.TDO --> ACE.TDI > 3) Have your connected the DONE pins of the Virtex-II devices together? Yes. The Init lines are also connected together and to the SystemACE. I thought at first that they were not, but I was mistaken. > 4) In the dual Virtex-II case, do both device go DONE? Yes, although my test for that is to note that them both respond on the PCI bus, and seem to function properly. Also, I note that I get the CFGDONE bit in the STATUSREG before I continue from u-boot. Oh, and they are Virtex-4, not Virtex-II. Although we have a V-II variant of the board as well. > 5) Which device is connected to the MPU port of the SystemACE device? The PPC405GPr, through CS1#. > 6) What holds the PPC405GPr in reset until both Virtex-II devices have > been configured? Nothing, the U-Boot bootstrap loader polls for the CFGDONE bit before u-boot is allowed to proceed with reading the kernel from the FAT FS. > 7) What exactly is a PPC405GPr, I think that this is discrete PPC405, > but which one? It is an IBM PowerPC405GPr. Part number IBM25PPC405GPR3BB333. We do not use any internal 405 cores, we use a discrete part that has PCI, SDRAM controllers, etc. The PCI bus of the PPC connects to the FPGA[s], so the FPGA devices show up as PCI devices to Linux. > 8) What exactly does this mean? > "The SystemACE driver is getting an error that the JTAG configurator > was unable to read the configuration stream from the CF." These are the error, status and control register contents when the Linux kernel discovers the error: CONTROLREG=0x10a STATUSREG=0x19035e ERRORREG=0x2098 The Linux kernel is 2.4.33-pre1 w/ the mvista SystemACE drivers for Linux 2.4. The error messages from the kernel driver are: CompactFlash write command failed CompactFlash sector failed to ready CompactFlash sector ID not found JTAG controller couldn't read configuration from the CompactFlash > 9) It sounds like you filed a case with our hotline, what number were > you assigned? Case # 628407 (The webcase person asked none of these questions.) - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 101301
http://www.dailytech.com/article.aspx?newsid=1920 So... I do see a possibility here.Article: 101302
"Antti" <Antti.Lukats@xilant.com> wrote in message news:1146249613.640327.248660@e56g2000cwe.googlegroups.com... > by stiff mean smaller pullup value than 47-100kohm? > > if that so then its something that is not well known - ASFAIK no FPGA > have stiff pull's before (or after configuration). > > Antti Antti, Read the Spartan-3 data sheet. It's been known to many engineers for quite some time that user-definable pullup and pulldown resistors are much stiffer than other gens. Spartan3E "fixed" those excessive values, returning to something more moderate. I just wish *I* had an answer for rickman. - John_HArticle: 101303
Eric Smith wrote: > > OK, but that still doesn't explain what "laws" were broken. .... come on now ... spliting symantic hairs are we? Shanon's work is described by some as a law, even though most of us understand it's really a theory that has never been proven mathmatically. Ditto with "Amdahl's Law" and a host of similar predictions. Common knowledge proofs based on state of the art and general exceptance, generally are considered informally as a law ... with Amdahl's speculations being just one of many widely held belief's as a folk "law". > "Common knowledge" is much different than "laws". Hardly, except maybe for some precise mathmatical niches. When I was taking engineering classes in the early 1970's one reather lengthy lecuture was on modems along with a detailed "proof" why modems would not get faster than 600 baud based on Nyquist Sampling Theorem, Shannon's work, and a few others. The rather lengthly presentation described spliting a 3K hertz bandwidth in half, for full duplex, choosing carrier freqencies that were not harmonics, and the minimum number of carrier cycles necessary to decode a symbol. In retrospect, the proof contained some assumptions that have since been invalidated, mostly because of improvements in the phone line noise factors. With lower noise (cross talk) came the ability to design around a higher bandwidth (Shannon's Theory).Article: 101304
Jan Panteltje wrote: > http://www.dailytech.com/article.aspx?newsid=1920 > > So... I do see a possibility here. Definitely cool. But only where an FPGA is truly handy. E.g. grid work. I think servers [e.g. SSL work] is best served with two processors than one and the FPGA. 8x200Mhz only provides 400MB/sec traffic to the CPU so really this is useful for tasks which either totally reside on the FPGA side of the board or have really high latency (e.g. PK work). The FPGA would have to beat ~3500 RSA-1024/sec before it would be worth more than an Opteron 275 (even more for the 285s) in the same socket. I'd see use for this in animation work though where an FPGA can raytrace a scene much faster than a CPU can and the work is high latency. Still cool though. Good to see people using the 940 socket for more than just Opterons :-) TomArticle: 101305
what you mean by 'user-defineable' rickman was talking about 'pre-configuration' mode pull-ups and those can not be user defined? AnttiArticle: 101306
tomstdenis@gmail.com writes: > The FPGA would have to beat ~3500 RSA-1024/sec before it would be worth > more than an Opteron 275 (even more for the 285s) in the same socket. What about the number of AES/sec?Article: 101307
tomstdenis@gmail.com wrote: : Jan Panteltje wrote: : > http://www.dailytech.com/article.aspx?newsid=1920 <snip> : 8x200Mhz only provides 400MB/sec traffic to the CPU so really this is : useful for tasks which either totally reside on the FPGA side of the : board or have really high latency (e.g. PK work). Sitting on the HT bus like that offers residence about as close as you can get to a mainstream CPU. Given the new HT3 stuff - faster and links possible over 1 meter - i.e. directly joining blades - I really like this aproach. Especially given the memory architecture that goes along with HT/Opterons. It's bringing mainstream CPUs and FPGAs back into the point to point multiple interconnect world of the TigerSHARCs and the old TI C40s. It feels a bit like a resurgence to the old British Transputer except with gate arrays mixing with CPUs on an equal footing in terms of connectivity. cdsArticle: 101308
Paul Rubin wrote: > tomstdenis@gmail.com writes: > > The FPGA would have to beat ~3500 RSA-1024/sec before it would be worth > > more than an Opteron 275 (even more for the 285s) in the same socket. > > What about the number of AES/sec? If it were triggered independently it'd be worth it. A 2.6Ghz processor [less than half the cost of this FPGA] can do upto 10,156,250 AES-128-ECB/sec with plain C code. That's roughly 160MiB/sec of throughput. Now, if you could have this thing trigger automatically. For instance, have an APIC that responds to interrupts from a network controller that would be a boost. The typical AES core takes ~14 cycles to encrypt but in FPGAs normally run at most at a couple hundred MHz at most [usually topping out between 100 and 200Mhz at most]. 200Mhz is 13 times less than 2.6Ghz which is equivalent to 182 cycles at 2.6Ghz. This is less than the 256 cycles that the Opteron takes but only marginally so. For the cost of it you'd be better served by dropping another Opteron in. A single 285 core could top out at 20.3M AES/sec which way more than the typical FPGA can hope to achieve. Where this would fly I think is on PDU work as I described tying directly to the network controller. You really need higher latency work. It should also be trivial to get ECC [especially binary field] PK much faster and lower latency on an FPGA than the typical Opteron. TomArticle: 101309
ISE 8 supports initialization of registers in an initial block, so
initial begin
array[0]=1234;
array[1]=5678;
.
.
array[11]=0101;
end
should do the trick.
-- Brian
Jeff Brower wrote:
> Steve, Peter and Austin-
>
> Can you give definitive instructions -- or point me to who can -- for
> initializing an array of registers?
>
> I need to initialize an array of registers in one way, set values
> differently upon Reset, and set values differently again during normal
> operation. I have this code:
>
> reg [31:0] array [11:0];
>
> // synthesis attribute INIT of array is 64'h0C0001820C000080;
>
> which is intended to initialize the first 2 elements of the array, but
> doesn't set any bits although XST appears to "accept" the INIT
> attribute. What is needed? The whole 384 bits set with one number?
> Can this be done using 384'hxxxx... syntax?
>
> I have opened a webcase through our local FAE, but after about 3 weeks
> have no clear answers other than to instantiate a RAM using CoreGen and
> use a .coe file, or read in a .dat file for simulation purposes but not
> synthesis. To use a RAM I would have to switch the array row/column to
> get XST to recognize asynchronous reads, and I have done that in other
> cases, but in this case I can't because I actually need 32-bit
> registers (they are accessible via a host processor).
>
> For something like array initialization, there has to be a solid answer
> -- hopefully some actual code showing how to do it.
>
> Thanks.
>
> -Jeff
>
Article: 101310c d saunter wrote: > tomstdenis@gmail.com wrote: > > : Jan Panteltje wrote: > : > http://www.dailytech.com/article.aspx?newsid=1920 > > <snip> > > : 8x200Mhz only provides 400MB/sec traffic to the CPU so really this is > : useful for tasks which either totally reside on the FPGA side of the > : board or have really high latency (e.g. PK work). > > Sitting on the HT bus like that offers residence about as close as you can > get to a mainstream CPU. Given the new HT3 stuff - faster and links > possible over 1 meter - i.e. directly joining blades - I really like this > aproach. Especially given the memory architecture that goes along with > HT/Opterons. It's bringing mainstream CPUs and FPGAs back into the point > to point multiple interconnect world of the TigerSHARCs and the old TI > C40s. HT links are not solely designed for speed. Latency is the key. 16 lanes of PCIe can compete just fine with a 16x16 1Ghz HT link in terms of bandwidth. Oddly enough the best tasks for this are things which don't return back to back [e.g. raytrace a scene]. What this does open the door for though is for mixed architecture systems. E.g. synthesize a MIPS core in the FPGA and map the DDR controller on to it. Then you have x86 and MIPS in the same system. That'd be cool. TomArticle: 101311
JJ (johnjakson@gmail.com) wrote: : In comp.arch (and others) there is a thread on this Opteron Virtex4 : coprocessor that sits in socket 940. : http://www.dailytech.com/article.aspx?newsid=1920 : http://www.theregister.co.uk/2006/04/21/drc_fpga_module/?www.dailytech.com : http://www.drccomputer.com/pages/products.html : I wonder what others think of this, at $4500 its way to steep for most : individual buyers who might happen to have a dual socket Opteron board : (I don't), but I wonder if companies like Digilent, Enterpoint and : others might see any opportunity to build a much lower cost edu version : that is more in line with the cost of an Opteron cpu chip say <$1k and : based on best Spartan3 or Virtex2,4 that can still use Webpack. John, I expect the $4500 reflects development costs and what the market will bear more than anything else - after all the only thing I've seen near it was the old Pilchard FPGA on a DIMM research project. : I also wonder how much faster exactly the HT link is over any of the : PCI interfaces. HT can be implemented much faster than parallel PCI but perhaps more importantly when used with an Opteron is that it's much more tightly coupled to the CPU. Looking at the upcoming HT3 I feel the best is yet to come. One of the posibilities that interest me is a V4 module sitting in a 940 socket with some MGTs wired up (space is tight - I realise that!) - if you happen to be dealing in high speed data aquisition and processing on the bit/word and (large) frame level then a tightly coupled FPGA/commodity CPU system is really quite exciting. cds : John Jakson : transputer guyArticle: 101312
Brian- Thanks Brian for your reply. > initial begin > array[0]=1234; > array[1]=5678; > . > . > array[11]=0101; > end For simulation only? Or will this work for synthesis. -JeffArticle: 101313
I think Steve Knapp explained: The "weak" pull-ups got too strong in S3, but they are now again made properly in S3E. Some people in Xilinx are overly concerned about the weakness, and thus the danger of crosstalk into these pins. Sometimes this paranoia leads to strong statements like "must". BTW, it is very easy to measure the resistor value: just short-circuit the pin to ground with a multi-meter. With lower supply voltages, lower thresholds and sometimes higher leakage currents, we all have to get away from the idea of 50 to 100k resistors.1k to 3.3 k are more meaningful values for external resistors that are supposed to define a level (unless it would affect power in ultre-low power designs) PeterAlfke, XilinxArticle: 101314
Usually constants are just absorbed into the code. If you have a large
amount and they are indexed then either block rams are used (pre-loaded) or
LUT-RAMS.
so
A <= x"45" or B
will set bits 0, 2 & 7 and put B into the rest of the bits.
Simon
"Aurelian Lazarut" <aurash@xilinx.com> wrote in message
news:e2soi1$d3p1@cliff.xsj.xilinx.com...
> Jon Elson wrote:
> >
> >
> > Roger Bourne wrote:
> >
> >> Hello all,
> >>
> >> I always wondered the following:
> >>
> >> How are constants implemented in an FPGA ? How many can be stored
> >> without causing bottlenecks (routing issues)?
> >> A quick scan of a Spartan3 indicated there is no ROM.
> >>
> >>
> > Actually, the LUTs of all FPGAs **ARE** ROMs! They are very SMALL
> > ROMs, but they are a ROM until you reconfigure the FPGA differently.
> Jon,
> this is not quite true (or at least doesn't apply to all Xilinx
> architectures)
> in virtex2/pro all LUTs can be loaded (serially in SRL mode) in later
> architectures some of them (SLICEM) can be used as RAM, more, some of
> our customers are using this feature, to reload coefficients for
> filters, or pixels for led displays, or to make "runtime reprogramable
> gates". More advanced users know that a lut used as logic, still can
> load bits in SRL mode, to reload the lut, and are taking advantage of
this.
> Aurash
> >
> > Jon
> >
Article: 101315Dave- > I don't have an answer for you, but since your code appears to be in > verilog, I wonder if you'd get a response by posting in > comp.lang.verilog Thanks very much for your reply. Yes posting on the Verilog group might bring some ideas so I will do that. But at the base, this is an XST issue. I can use UCF file, synthesis attribute -- whatever works. I just need to know what works in XST, for Xilinx FPGA devices, and be done with it. -JeffArticle: 101316
tomstdenis@gmail.com wrote: : HT links are not solely designed for speed. Latency is the key. 16 : lanes of PCIe can compete just fine with a 16x16 1Ghz HT link in terms : of bandwidth. : Oddly enough the best tasks for this are things which don't return back : to back [e.g. raytrace a scene]. I wouldn't call that odd - a modern CPU hiding behind caches with long pipelines is always going to struggle with low latency back/forewards/back/forewards shared tasks with an FPGA/Clearspeed/xxx - certainly interesting things happen with FPGA silicon and CPU silicon coupled in a SOC or on an FPGA but the clock rates are far below a dedicated CPU. On the serial / parallel issue I have a leaning towards parallel for simplicity when it comes to the FPGA code and latency, although serial has benefits for physical complexity and routing. Also it feels like they leap frog each other every few months in terms of bandwidth! The world is squeezing itself down a thin pipe these days though... : What this does open the door for though is for mixed architecture : systems. E.g. synthesize a MIPS core in the FPGA and map the DDR : controller on to it. : Then you have x86 and MIPS in the same system. : That'd be cool. An awfull lot of cool things are on their way...Article: 101317
Antti wrote: > Larry, > > the OP asked about using Xilinx Platform Cable for SPI programming, not > about altermatives. > > purchasing jtagkey for 139EUR (what ist just a box with ft2232c+lever > shifter) just to program an SPI flash only because Xilinx is doing so > bad with the support of their own cables in not so much an option. > > Xilinx USB platform cable could of course theoretically do spi > programming as it it based on Cypress FX2 + upgradeable CPLD, What CPLD do they use ? Why do they need a CPLD, given the FX2 ? > but xilinx is doing a bad job with the support of the cables. All the > xilinx SPI support seems to be done by some students, that would > explain why there is no support for USB platform cable, as such support > would require update for the usb platform cable and that info is was > possible not available for those who wrote the XSPI thing. > > Too bad - the Xilinx USB cable is quite nice piece of hardware but its > so closed design, that it well of course it could be reprorammed to be > Altera Byteblaste :) - firmware for this is now under GPL and available > (sure the PLD should be updated as well to be plain bypass) > > sorry for ranting - but I have had to mess up with some boards that are > using Xilinx CPLD+spi solution and are supposed to be programmed with > the xilinx SPI tool. And that experiences is just another 2 weeks of my > time wasted in frustration. > > Antti > > Xilinx - please dont get upset (again) - I say what I think, and I cant > (and dont wanna) change that. > > For the Xilinx Platform Cable issues there is a very elegant solution - > no work at required from Xilinx > just a matter of making a decision - so here it comes: > > IDEA for Xilinx > -------------------- > Open up the Platform USB Cable design in such manner that it could be > used > by 3rd parties, eg the Cable would still start and configure as it > normally does > but afterwards a secondary protocol could be used to reload new > firmware > and re-enumarate as new device with new host drivers. > > All that is needed from Xilinx is the decison that such use is OK and > some > small bits of information - all the rest would be done by the community > - > of course, everything that happens with the cable after the secondary > protocol is no longer under Xilinx control meaning that there is no > support required from Xilinx. This would allow the cable to be used > as SPI programmer or any some other gadget as required. 100% correct, but alas, this is the Xilinx that pulled the on-line store, and suffers the big-company-disease more and more... The cynic in me can just imagine the upper-echelons in Xilinx thinking : "But what if someone uses the Xilinx Cable to PGM an Altera or Lattice device !?!" - clutches for heart attack pills... :) Perhaps another USB_key could be used ? -jgArticle: 101318
IIRC, xilinx initial values (after config) and built-in set/reset
values must be the same (in fact, I know synplicity will take the reset
value for the initial value). If you really need "reset" values
different from initial ones, then you'll have to code a synchronous
reset in with your logic. You'd have to be careful that it does not
confuse your "logic" reset with a built-in reset function. Maybe if
you coded a reset for the initial value (then hardwired it to optimize
it out), and subsequent to that, a secondary "reset" function, that
might work:
This is in vhdl, but here's what I'd try:
init <= '0' -- hardwired off
process (clk) -- no async reset!
begin
if rising_edge(clk) then
if init = '1' then -- hopefully synth will take this as the "reset"
a <= initial_value;
elsif reset = '1' then -- this will just be part of operational logic
a <= reset_value;
else
a <= operational_value;
end if
end if;
end process;
You're out of luck if you need different initial and async reset
values.
Hope this helps,
Andy
Article: 101319HAHA!! they need the CPLD because then there is a need to update the CPLD what takes usueally about 40 minutes !!! they use a coolrunner, the CPLD is not protected and can be read back, those the cable could be cloned but it doesnt make sense todo so. xilinx Cable IV can be used as byteblaster (or any other LPT connected JTAg thing), and Xilinx platform cable could be used as USB blaster - those they are more flexible then the Altera dongles which can not emulate Xilinx cables :) AnttiArticle: 101320
Stephen Williams wrote: >> 8) What exactly does this mean? >> "The SystemACE driver is getting an error that the JTAG configurator >> was unable to read the configuration stream from the CF." > > These are the error, status and control register contents when the > Linux kernel discovers the error: > CONTROLREG=0x10a STATUSREG=0x19035e ERRORREG=0x2098 > > The Linux kernel is 2.4.33-pre1 w/ the mvista SystemACE drivers > for Linux 2.4. > > The error messages from the kernel driver are: > CompactFlash write command failed > CompactFlash sector failed to ready > CompactFlash sector ID not found > JTAG controller couldn't read configuration from the CompactFlash I had a quick discussion with our Linux/UBoot expert and the SystemACE designer as well as reading your original case that you filed with our hotline and we believe that the SystemACE driver code that you are using is resetting the SystemACE and causing another configuration of the devices in the chain. In the case of the single FPGA in the chain the SystemACE reconfiguration may complete and return control to the MPU port before another MPU access is made. While in the case of the two FPGAs in the chain the reconfiguration is still occurring when you attempt another MPU access. In any case you should not be reconfiguring the devices a second time (unless you really want to) and our Hotline had given you instructions on how to prevent the reconfiguration. If you would like to confirm this theory you can put a scope probe on the CFG_TCK pin from SystemACE and you should see it actively toggle, stop for a period of time after the 1st configuration and then restart again at some point before stopping permanently. >> 9) It sounds like you filed a case with our hotline, what number were >> you assigned? > > Case # 628407 > (The webcase person asked none of these questions.)Our The hotline engineer assign to your case did not ask any of these questions that I posed as your original query was very different from the one that you posed here on comp.arch.fpga, but I do believe that they did give you an answer that will resolve the problem when you implement it. Ed McGettigan -- Xilinx Inc.Article: 101321
Antti wrote: > the answer is almost always: Yes/No > > all the in-system-programming and JTAG stuff is not as much standard as > it could be. > > there have been many attempts to develop vendor neutral or at least > multi-vendor technologies but all attempts have failed so far. > > its seems that big boys have big issues playing it nicely in a (common) > sandbox, so almost all vendors have some 'special' things making the > 'generic' things not fully useable. > > xilinx has XSVF a binary version of SVF, some Xilinx parts can not be > programmed with standard SVF, > lattice has SVF-Plus > altera has its own flavors of JAM/STAPL > actel has its own flavors of STAPL > > if you think a SVF player is a SVF player is a SVF player, then no it > isnt, > same for JAM/STAPL So the issue is not whether one count send a properly formatted SVF file stream through a generic player and get a PROM/FPGA to become programmed, but that one can't easily get that SVF string in the first place. Bear with me, I really don't know. I just have in front of me a printout of "Serial Vector Format Specification" and some wishful thinking. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep."Article: 101322
rickman wrote: > People here are driving me crazy insisting that the Xilinx factory has > told them that you *MUST* tie the mode pins to either Vaux or GND. > After finding all the info in the data sheet and talking with support, > it looks pretty clear to me that the S3 parts have a very stiff > internal pull up and there is no need for an external pull up of any > kind, resistor or direct connection to Vaux. > > Am I misunderstanding? Why did the factory tell us before that the > mode pins *MUST* be tied to Vaux? Did we misunderstand what they were > saying? > > I promise this is the last time I will ask about this. I am totally > sick of going around this loop with everyone here. Design the PCB with options for SMD resistors, that can also be 0-Ohm shunts, and say 'define in production for valid logic levels'. That gets you past the design review, and closes the case :) -jgArticle: 101323
tomstdenis@gmail.com writes: > The typical AES core takes ~14 cycles to encrypt but in FPGAs normally > run at most at a couple hundred MHz at most [usually topping out > between 100 and 200Mhz at most]. 200Mhz is 13 times less than 2.6Ghz > which is equivalent to 182 cycles at 2.6Ghz. This is less than the 256 > cycles that the Opteron takes but only marginally so. I'd think if you're going to use such an expensive and exotic approach at all, you'd pipeline it to get one AES operation per cycle, maybe even more than one if you're doing something like EAX mode, or CTR mode ona large block in parallel.Article: 101324
Paul Rubin wrote: > tomstdenis@gmail.com writes: > > The typical AES core takes ~14 cycles to encrypt but in FPGAs normally > > run at most at a couple hundred MHz at most [usually topping out > > between 100 and 200Mhz at most]. 200Mhz is 13 times less than 2.6Ghz > > which is equivalent to 182 cycles at 2.6Ghz. This is less than the 256 > > cycles that the Opteron takes but only marginally so. > > I'd think if you're going to use such an expensive and exotic approach > at all, you'd pipeline it to get one AES operation per cycle, maybe > even more than one if you're doing something like EAX mode, or CTR > mode ona large block in parallel. Even with pipelining you're still on a fairly limited bus. At best you top out at whatever the bus between the two actually is. Keep in mind this is an FPGA and not ASIC. So chances are it won't clock that high anyways. My 200Mhz quote is just a really really optimistic quote. >From what I recall from my past job you'd be lucky to get something complicated like a PDU clocking higher than PCI freq [33Mhz]. So while you could get an AES core ~100Mhz it would only be doing CTR mode at most. Block ciphers are not where this will shine. Specially when the other processor is an Opteron. The trick to making good use of something like an FPGA isn't serial speed. Even if you designed a custom RISC ALU on the FPGA it'd clock probably around 50Mhz. Even with the best ISA you can craft for it the Opteron could EMULATE the thing faster than you could run it. Where the FPGA will shine is for tasks with a LOT of parallel computation. Think like 16 FPU pipelines or a single cycle GF(2) multiplier, etc, etc, etc. Other tasks where this would shine would be custom DSP filters, e.g. offload MPEG work. A FIR or IIR filter of significant delay [e.g. accuracy] could be constructed in a pipeline to get 1 sample/cycle at decent clock rates. Tom
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