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
Rob wrote: > John, > > You forgot one other possiblity: > > Get a job as a consultant in a large company, contact the local FPGA rep of > your choice, and tell them you need samples. Yeah, but the bean counters consider that theft when you leave out the front door with a few thousand dollars of samples that the Rep ordered for your client. So does the local DA if somebody files charges. I do projects every year or so that I ask for samples for under my own business name instead, mostly limited to connectors and passives, plus some prototype qty ICs. Mostly I just purchase Gray Market NOS stock in volume for pennies on the dollar, and design around it for short run builds. I prefer fixed price, or flat fee, contracts ... so it's easier to quote or bid based on my inventory rather than dealing with distribution pricing and availalbity uncertainty. When I need samples for a client build, it's seldom difficult to get them in the name of even a smaller client when I have a contract and PO for finished product and a build schedule. Having two SMT lines in my shop generally breaks the ice with a rep ... most students and hobbiests don't have the capacity to build 5,000 boards per month. The 10 zone N2 capable BTU and Vitronics 24" wide by 20 Ft long ovens along with the several Dynapert MPS318 and MPS500 pick and place machines pretty much solve that question with a quick tour of my facility. Designs with 0805 and larger parts I do in-house, everything else goes out to a CM. As you might guess, I design mostly with 0805 and larger parts for short runs and prototypes. If the run is too big for us, I don't worry about it and mostly use 0603 passives, or smaller if the client want's the density and is comfortable with the cost.Article: 101776
In article <445bc5dd$0$490$cc7c7865@news.luth.se>, <pbdelete@spamnuke.ludd.luthdelete.se.invalid> wrote: >>things now bringing high end commodity CPUs (as opposed to specialist DSP >>hardware) and FPGAs close together - offerings from Cray, SGI, this new >>opteron socketed thingie etc. Most of the fuss is around their use in >>reconfigurable computing so the offerings tend to be lacking for raw >>serial IO... > >>: Whats you acquisition area? > >>Starlight - astronomical adaptive optics. Potentially you can be talking >>about multiple CCDs of many thosands of pixels framing at over 1KHz... > >CCD -> Hyperthread -> FPGA -> Hyperthread .. other cpu(s). I'm not sure that a hypertransport-attached CCD is very practical: HT is a short-range interconnect, and I suspect it's fast enough that you'd have great difficulty implementing it in the rather peculiar fab processes required to make a CCD. I can't find a datasheet for a modern CCD, but the obsolete TC237 has only twelve pins, requires rather complicated digital waveforms on five of them, and outputs analogue pixel data on two more; you want to keep the ADC as close to the detector as possible, I'd have thought connecting the ADCs via an FPGA to gigabit-ethernet channels would be a reasonable way to go, leaving the problem of data acquisition from lots of gigabit ethernet connectors as one already solved by the WAN people. TomArticle: 101777
In article <QJW6g.613$8C.42@fe04.lga>, Ron <News5@spamex.com> wrote: >Tobias Weingartner wrote: >> Is this close to what you're looking at doing? >> >> http://www.hyperelliptic.org/tanja/SHARCS/talks06/bulens.pdf > >Thanks for the article Tobias. Parts of it look interesting, but no, >what they are doing bears little resemblance to what I have done. As I >said earlier, my ECM algorithm is coded entirely in Verilog HDL with no >connection to an external PC or anything else (nor any embedded >microprocessor core). Once it's programmed I turn it on (the number to >be factored is hard coded into the FPGA) and wait for it to factor the >requisite composite number and invoke a module I'll have to write myself >because Xilinx only provides VHDL examples of it's interface) that >displays the factor. I think you are entirely misguided in contemplating using ECM to factor 'hard' numbers such as the RSA Challenge ones; the expected number of operations would be so large that the calculation would take literally millions of years. There is a community (Dan Bernstein probably the mainstay of it) interested in factorisation using hardware, and the SHARCS conferences contain the people you'd want to talk to, but a straight ECM implementation hard-wired to factor a single number is not all that useful. If only because the pricing of larger FPGAs is not really competitive with the billion 64x64->128 multiplies a second that a $400 dual-core Opteron processor offers. TomArticle: 101778
I recently considered the 405 in its AMCC (formerly IBM) incarnation. This is the buggiest CPU I have seen. If the core you have (this is of course a big IF) has the same errata, it is hopeless. The worst bug I saw was one which said you can use the data cache in write through mode, otherwise memory can get corrupted... this has of course the implication that for every write to memory the thing will do a cacheline write to the SDRAM or whatever, full 32 bytes write. And there were many other bugs as well... I was also told the DMA engine would not burst the SDRAM accesses, but this may be not core-realted so you may be immune to that issue. OTOH, Ihave had experience with the 603e core (in the 82xx chips) and it works fine for me. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Alan Nishioka wrote: > Does anyone use the profiling tools with the Xilinx ppc405? > > I am trying to profile code on the ppc405 in a Xilinx XC2VP4. > It works for a simple test, but when I try the real code, it fails. > > The call stack seems to be getting corrupted. When I look at the > failure, the link register points to the instruction after mcount is > called (the profile code at the beginning of the function) so at the > end of the function it jumps back to the beginning of the fuction, ad > infinitem. > > I am using EDK7.1sp2. profile is using PIT for timer. > If someone else is getting this to work, I can keep trying. Otherwise, > I may give up. > > Alan NishiokaArticle: 101779
Thomas Womack wrote: > I think you are entirely misguided in contemplating using ECM to > factor 'hard' numbers such as the RSA Challenge ones; the expected > number of operations would be so large that the calculation would take > literally millions of years. You may very well be right Tom, but I am alas caught betwix the proverbial rock and hard place. There isn't even the most remote possibility that sieving would fit into the largest FPGA available today, so I am forced to go with the "next best" algorithm which is ECM. Keep in mind that there are a great many opportunities in ECM for parallelization and pipelining. As I mentioned in my original message, the record for ECM factoring the last I heard was 66 decimal digits. It may very well be that I am only able to extend the record by a couple of digits, but at least I will have done something to be proud of and learned a lot about FPGA programming in Verilog HDL. It sure beats sitting around and rotting my brain in front of the boob tube or playing chess on the Internet all day long (Playchess.com is great by the way). It takes me a long time to do a design because of health issues, but at least now I have all the time I need without worrying about schedules and budgets. In a way, I was sort of gambling that Moore's Law brings large and affordable FPGA's to market faster than the price of conventional computers drop. My plan was to be ready with a fully tested and functional ECM design whenever I was able to afford an FPGA large enough to fit my design. That time is now here, but I hadn't counted on the exorbitant prices of the software necessary to use most vendor's devices. I suppose I'll check on the synthesis capabilities of the free Icarus Verilog package that I use for simulation and see if there are any open source packages I might use to bypass Xilinx's outrageous prices for development tools. There is a community (Dan Bernstein > probably the mainstay of it) interested in factorisation using > hardware, and the SHARCS conferences contain the people you'd want to > talk to, but a straight ECM implementation hard-wired to factor a > single number is not all that useful. Even as proof-of-concept? Do you know of anyone else who has ever created an entire ECM factorization design in Verilog? :-) In any case, I think it makes a great hobby (except for the cost of course). If only because the pricing of > larger FPGAs is not really competitive with the billion 64x64->128 > multiplies a second that a $400 dual-core Opteron processor offers. One nanosecond per 64 bit multiply Tom? That seems a bit of a stretch but I won't quibble over details. So to multiply two 704 bit numbers together (depending upon how it's implemented of course) would require roughly sixty 64-bit multiplies and a bunch of adds. Even so, sixty nanoseconds per 704 bit multiply is pretty impressive. The problem with doing conventional multiplies in ECM is that you have to do a modulo operation after almost every multiply, and modulo is at least as costly in terms of both gate count and time consumption as a multiply; whereas I was able to eliminate a all explicit modulo operations altogether by combining it with my multiplication module. :-) Because of all the variables and simulation time constraints, it's impossible to get an average value for each ECM iteration for "real" data without being able to run a few test cases in real time on a real FPGA. As soon as I get that done I'll be happy to post the results (for better or worse). Regards, RonArticle: 101780
My apologies if my sarcasm wasn't perceived from my post. I am unequivocally not condoning that type of activity. It sounds like you can have much fun with the two SM lines you own. Take care, rob <fpga_toys@yahoo.com> wrote in message news:1146903703.046888.326090@i39g2000cwa.googlegroups.com... > > Rob wrote: >> John, >> >> You forgot one other possiblity: >> >> Get a job as a consultant in a large company, contact the local FPGA rep >> of >> your choice, and tell them you need samples. > > Yeah, but the bean counters consider that theft when you leave out the > front door with a few thousand dollars of samples that the Rep ordered > for your client. So does the local DA if somebody files charges. > > I do projects every year or so that I ask for samples for under my own > business name instead, mostly limited to connectors and passives, plus > some prototype qty ICs. Mostly I just purchase Gray Market NOS stock > in volume for pennies on the dollar, and design around it for short run > builds. I prefer fixed price, or flat fee, contracts ... so it's easier > to quote or bid based on my inventory rather than dealing with > distribution pricing and availalbity uncertainty. > > When I need samples for a client build, it's seldom difficult to get > them in the name of even a smaller client when I have a contract and PO > for finished product and a build schedule. Having two SMT lines in my > shop generally breaks the ice with a rep ... most students and > hobbiests don't have the capacity to build 5,000 boards per month. The > 10 zone N2 capable BTU and Vitronics 24" wide by 20 Ft long ovens along > with the several Dynapert MPS318 and MPS500 pick and place machines > pretty much solve that question with a quick tour of my facility. > > Designs with 0805 and larger parts I do in-house, everything else goes > out to a CM. As you might guess, I design mostly with 0805 and larger > parts for short runs and prototypes. If the run is too big for us, I > don't worry about it and mostly use 0603 passives, or smaller if the > client want's the density and is comfortable with the cost. >Article: 101781
John, You know the ropes, and probably have a set of trusted sources. I am happy that you have been successful. But you must understand that we can not support components purchased through non-authorized channels. Austin fpga_toys@yahoo.com wrote: > Austin Lesea wrote: > >>Cavet Emptor: if you buy through the gray market, do not complain when >>you get ripped off. > > > Certainly. On the other hand I generally turn fraud over to the FBI, as > it makes little sense to complain to anybody else, like Xilinx. I've > purchased gray market parts in volume without a problem for 35 years, > including high end Xilinx FPGAs. The last 6 years has been a gold mine > in bankrupt NOS sales from the DOT COM bust, plus recycling parts from > new never used boards from the same sources. In the VERY few cases I've > had problems, it's easily absorbed into the steep discount I get on > most gray market parts. > > Consider 18 Qty 2K reels of AVX TAJB226K004R for a lot price of $275 > including shipping that I picked up last month, which would have cost > about $3K through distribution at that Qty, and twice that a reel at a > time as I would normally purchase them -- 5-10% on the dollar is worth > a little risk. Most of the several hundred reels of parts I have in > inventory was purchased for a few pennies on the dollar -- as Gray > Market NOS parts at auction over the last 6 years. Ditto for another > several hundred trays of specialty ASICs, FPGAs, memory, PLDs and > processors. > > Ditto for several hundred NOS XC18V04's at a buck a piece, a couple > hundred NOS XCV1000E's at $15/ea plus another hundred pulls from the > same source at $3/ea. Some high value project boards are not worth the > Gray Market risks, but that is our clients choice. While in many cases > we can not ship pulls as new product for resale, we can use them to > build boards for captive in-house use, spares inventory, prototypes and > save the client quite a few dollars. > > Consider a few hundred pulls of XC2VP 30/40/50/70's at $35-55/ea, and > another few hundred XC2V6000 for a little less is a significant savings > for building prototypes, research designs, and spares inventory for > devices prices originally in the several hundred to several thousand > dollar range. A little risk isn't about getting lucky, it's about > buying smart. It allows us to low ball fixed price contracts and pass > the savings to our clients by sharing the windfall. It also allows > personal research projects that only large corporations could fund > using new distribution parts. > > And another several thousand pulls of XC4062XLA, XC4085XL, > XCV300/600/800/1000/1600/2000/2600 and XC2V parts as well, mostly down > in the $1-10/ea for parts smaller than XCV1000's. I seldom pay much > more for larger parts, a range that I've used for various projects over > the last 6 years. TechStar balls in bulk make reballing reasonably > cheap :). SolderQuik preforms for everything else. Bake, flip thru the > solder fountain to strip ball slag off, clean/flux and reball in a > fixture under A.P.E SMD-1000's. BG432/560 parts are certainly easier > than later parts. > > >>Sometimes folks are lucky and obtain an overstock device that someone >>could not use. But, since the packaging has absorbed moisture, one has >>to bake them before use, or the package will pop-corn when assembled >>(common to all packages nowadays). > > > Yep ... bake almost everything. Really isn't a problem to kit next days > build and put the whole thing in the oven for a day anyway. > > For low volume client builds, there are plenty of New Old Stock parts > at reasonable prices. And a Lot that people are holding at full retail, > waiting for someone that needs to short run an old design to avoid > regulatory certification if the design were changed for new parts. For > short runs (up to a few hundred boards) you don't need to be lucky, > just buy smart. > > Have Fun, > John >Article: 101782
> Alan Nishioka wrote: > Does anyone use the profiling tools with the Xilinx ppc405? dp wrote: > I recently considered the 405 in its AMCC (formerly IBM) incarnation. > This is the buggiest CPU I have seen. If the core you have (this > is of course a big IF) has the same errata, it is hopeless. Thank you for your response. The Xilinx ppc405 seems to work fine. My application runs great without the profiling code, but loops forever when -pg code is added (I admit I did not actually wait forever...) Since the link register seems to be getting overwritten, I think the problem is in the support software, but if someone else has gotten this to work, I can rule this out. Alan NishiokaArticle: 101783
If one wanted to develop an FPGA-based hardware accelerator that could attach to the average PC to process data stored in PC memory what options are there available. Decision factors are: + ease of use (dev kit, user's guide, examples) + ability to move data with minimal load on the host PC + cost + scalability (i.e. ability to upsize RAM and FPGA gates) + ability to instantiate a 32 bit RISC (or equiv) Someone recommended the TI & Altera Cyclone II PCIe dev board, which is said to be available soon. Any other recommendations? Also, what is the best way to move data between PC mem to FPGA? DMA? What transfer rates should one realistically expect? Thanks, Jeremy --- PDTi [ http://www.productive-eda.com ] SpectaReg -- Spec-down code and doc generation for register mapsArticle: 101784
Jeremy Ralph schrieb: > If one wanted to develop an FPGA-based hardware accelerator that could > attach to the average PC to process data stored in PC memory what > options are there available. Nice idea, but to beat a nowady CPU (Pentium 4 and Athlon 64 etc.) and a nowadays GPU (Nvidi Gforce whatever-is-uptodate etc.) is hard to achive even with the big guys in the business. (yeah, yeah, special task can be optimized to run faster on FPGA based hardware, but to speed up "normal" PC tasks is difficult) > Decision factors are: > + ease of use (dev kit, user's guide, examples) > + ability to move data with minimal load on the host PC > + cost > + scalability (i.e. ability to upsize RAM and FPGA gates) > + ability to instantiate a 32 bit RISC (or equiv) > Someone recommended the TI & Altera Cyclone II PCIe dev board, which is > said to be available soon. Any other recommendations? > Also, what is the best way to move data between PC mem to FPGA? DMA? Sure. > What transfer rates should one realistically expect? PCI is 133 Mbyte/s max. AGP is 2 GByte/s max. (AFAIK) PCI-Express is nx250 Mbyte/s (with n up to 16) MfG FalkArticle: 101785
Jeremy Ralph wrote:
> If one wanted to develop an FPGA-based hardware accelerator that could
> attach to the average PC to process data stored in PC memory what
> options are there available.
What could it accelerate? Modern PCs are quite fast beasts...
If you couldn't speed things up by a factor of, say, 300%, your
device would be useless. Modest improvements by several tens
of percents can be neglected -- Moore's law constantly works
for you. FPGAs are good for special-purpose tasks, but there
are not many such tasks in the realm of PCs.
> + ability to instantiate a 32 bit RISC (or equiv)
You already have a high-performance CPU on board, why do you
need another one? Use your FPGA to do something massively parallel
and let the CPU perform the CPU-ish stuff. The high rank Xilinx
devices contain one or more PowerPCs for that purpose and that
solution seems to be the best possible.
> Also, what is the best way to move data between PC mem to FPGA? DMA?
DMA is good, there are PCI frontend IP cores available.
> What transfer rates should one realistically expect?
132MiB/s when not overclocked.
Best regards
Piotr Wyderski
Article: 101786I just received my Spartan 3e starter kit and had to share my frustration... The huge DRAM and the fast FPGA seem to make this board ideal for video and sound processing. But.. why on earth does the board come with a 3bit VGA output? We do not live in the 80ies anymore. Adding a couple of resistors to get 8 or 12bit color resolution would hardly have changed the BOM. Even a video DAC is not expensive. Same goes to the audio output. The board has some nice DAC, but they forgot amplifier and usable output connectors. In contrast, this is a very nice concept: http://www.terasic.com/english/fpga_01.htm It just does not have the right FPGA. Does anybody have a suggestion how to solve the problem? Unfortunately, a hirose connector is also something that does not come in 2.54mm pitch.Article: 101787
motty wrote: > I am trying to find some opb_ipif timing diagrams. The Xilinx document > "DS404" has figure numbers and titles on the pages, but there are no > figures for the register timing! I have tried downloading two > different versions, on different computers, and still see nothing. > Other diagrams (FIFO timig) are fine. Both computers use Adobe Acrobat > 7.0. I hve looked at 3.01a and 3.01b versions of the doc. C:/EDK71/hw/XilinxProcessorIPLib/pcores/opb_ipif_v3_01_c/doc/opb_ipif.pdf (or wherever you installed EDK) has the figures and a note at the end saying 4/27/05 1.1 Fixed problem with missing figures. Alan NishiokaArticle: 101788
Austin Lesea wrote:
> This prevents piracy by decrypting the movie at the
> projector itself (at no time is the full digital information available
> for copying).
How do you prevent the pirates from stealing your private
symmetric AES key from the FPGA? _This_ is the hard part,
not the decryption process. I can easily implement an over
1Gbit/s 128-bit AES en/decryptor even on a Cyclone, but it
is meaningless, as the key is not (and cannot be) protected.
Best regards
Piotr Wyderski
Article: 101789pbdelete@spamnuke.ludd.luthdelete.se.invalid wrote: > What kind of cpu resources does fpga "compilation" (Analyse, Synthesis, etc..) > use on a cpu..? > > Integer/Branch/Bitshifting..? > Floating point..? > Will a pipeline cpu greatly improve speed..? I have found that cache size and FSB speed/size to be more of a determining factor of the compilation speed than clock speed. I would image this is because the data structures formed would get pretty large (and wouldneed to be frequently accessed). -IsaacArticle: 101790
Thanks Falk, for the numbers. Any reason why AGP couldn't be used for non-graphics streams? --- PDTi [ http://www.productive-eda.com ] SpectaReg -- Spec-down code and doc generation for register mapsArticle: 101791
"Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl> writes: > How do you prevent the pirates from stealing your private > symmetric AES key from the FPGA? _This_ is the hard part, > not the decryption process. I can easily implement an over > 1Gbit/s 128-bit AES en/decryptor even on a Cyclone, but it > is meaningless, as the key is not (and cannot be) protected. Use a Virtex II or Virtex 4 and it can be. There are degrees of protection. The protection available in the Virtex II or Virtex 4 isn't absolute, of course, but it would take tremendous resources to extract a key embedded in one. You wouldn't be able to read the key back out electrically due to the FPGA's own encryption system, which is based on triple DES or AES with a key in internal SRAM. To extract the application symmetric AES key, you'd have to be able to decap the FPGA without cutting power to it or shorting out any internal nodes, then microprobe it. And you'd have to know *where* to probe it; unless you had the original design files, just finding where the application key was stored would be an immense task. (Note that I'm not talking about finding out where the FPGA bitsream decryption key is stored; that would be relatively easy since you could use ANY decapped Virtex II/4 part to search for that. The application's decryption key would be somewhere inside the FPGA configuration.)Article: 101792
Hi Piotr, Thanks for your response. Please find my comments below: >>>What could it accelerate? Modern PCs are quite fast beasts... >>If you couldn't speed things up by a factor of, say, 300%, your >>device would be useless. Modest improvements by several tens >>of percents can be neglected -- Moore's law constantly works >>for you. FPGAs are good for special-purpose tasks, but there >>are not many such tasks in the realm of PCs. So let's say one was able to demo a 50% performance improvement for some specialized task using FPGA, custom RTL and HAL. Let's say the design is scalable such that with 8X FPGA gates I'd get a 8*50% performance improvement. Yes, FPGAs are costly and can't compare to ASICs... but 50% in an FPGA could mean 400% in an ASIC. Moore's law also holds true for ASICS and FPGAs. >>You already have a high-performance CPU on board, why do you >>need another one? Use your FPGA to do something massively parallel >>and let the CPU perform the CPU-ish stuff. The high rank Xilinx >>devices contain one or more PowerPCs for that purpose and that >>solution seems to be the best possible. If the 32 bit RISC was optimized for some specialized task, then it might make sense to have it alongside a high-performance CPU. For acceleration stuff I don't envision a RISC being too useful. More interested in prototyping some RISC centric soft-IP designs. Hoping to kill two birds with one stone and find a board that can be used for both applications. Cheers, Jeremy --- PDTi [ http://www.productive-eda.com ] SpectaReg -- Spec-down code and doc generation for register mapsArticle: 101793
"BoroToro" <beiermann@gmail.com> wrote in message news:1146955848.154397.42440@i40g2000cwc.googlegroups.com... > > I just received my Spartan 3e starter kit and had to share my > frustration... > > The huge DRAM and the fast FPGA seem to make this board ideal for video > and sound processing. But.. why on earth does the board come with a > 3bit VGA output? We do not live in the 80ies anymore. Adding a couple > of resistors to get 8 or 12bit color resolution would hardly have > changed the BOM. Even a video DAC is not expensive. Not all that difficult to add on another VGA interface with more bits. One of these could come in handy: http://www.winfordeng.com/products/brk15hd.php 4 bits for each colour will give you a handy 4096 colours to choose from. Red.Article: 101794
Jeremy Ralph wrote: > If one wanted to develop an FPGA-based hardware accelerator that could > attach to the average PC to process data stored in PC memory what > options are there available. > > Decision factors are: > + ease of use (dev kit, user's guide, examples) > + ability to move data with minimal load on the host PC > + cost > + scalability (i.e. ability to upsize RAM and FPGA gates) > + ability to instantiate a 32 bit RISC (or equiv) > > Someone recommended the TI & Altera Cyclone II PCIe dev board, which is > said to be available soon. Any other recommendations? > > Also, what is the best way to move data between PC mem to FPGA? DMA? > What transfer rates should one realistically expect? > > Thanks, > Jeremy FPGAs and standard cpus are bit like oil & water, don't mix very well, very parallel or very sequential. What exactly does your PC workload include. Most PCs that are fast enough to run Windows and the web software like Flash are idle what 99% of the time, and even under normal use still idle 90% of the time, maybe 50% idle while playing DVDs. Even if you have compute jobs like encoding video, it is now close enough to real time or a couple of PCs can be tied together to get it done. Even if FPGAs were infinitely fast and cheap, they still don't have a way to get to the data unless you bring it to them directly, in a PC accelerator form, they are bandwidth starved compared to the cache & memory bandwidth the PC cpu has. There have been several DIMM based modules, one even funded by Xilinx VC a few years back, I suspect Xilinx probably scraped up the remains and any patents? That PCI bus is way to slow to be of much use except for problems that do a lot of compute on relatively little data, but then you could use distributed computing instead. PCIe will be better but then again you have to deal with new PCIe interfaces or using a bridge chip if you are building one. And that leaves the potential of HT connections for multi socket (940 & other) Opteron systems as a promising route, lots of bandwidth to the caches, probably some patent walls already, but in reality, very few users have multi socket server boards. It is best to limit the scope of use of FPGAs to what they are actually good at and therefore economical to use, that means bringing the problem right to the pins, real time continuous video, radar, imaging, audio, packet, signal processing, whatever with some logging to a PC. If a processor can be in the FPGA, then you can have much more throughput to that since it is in the fabric rather than if you go through an external skinny pipe to a relatively infinitely faster serial cpu. Further, if your application is parallel, the you can possibly replicate blocks each with a specialized processor possibly with custom instructions or coprocessor till you run out of fabric or FPGAs. Eventually though input & output will become limiting factors again, do you have acquisition of live signals and or results that need to be saved. It really all depends on what you are processing and the rate it can be managed. John Jakson transputer guyArticle: 101795
Thomas Womack wrote: > In article <445bc5dd$0$490$cc7c7865@news.luth.se>, > <pbdelete@spamnuke.ludd.luthdelete.se.invalid> wrote: > >>things now bringing high end commodity CPUs (as opposed to specialist DSP > >>hardware) and FPGAs close together - offerings from Cray, SGI, this new > >>opteron socketed thingie etc. Most of the fuss is around their use in > >>reconfigurable computing so the offerings tend to be lacking for raw > >>serial IO... > > > >>: Whats you acquisition area? > > > >>Starlight - astronomical adaptive optics. Potentially you can be talking > >>about multiple CCDs of many thosands of pixels framing at over 1KHz... > > > >CCD -> Hyperthread -> FPGA -> Hyperthread .. other cpu(s). > > I'm not sure that a hypertransport-attached CCD is very practical: HT > is a short-range interconnect, and I suspect it's fast enough that > you'd have great difficulty implementing it in the rather peculiar fab > processes required to make a CCD. > > I can't find a datasheet for a modern CCD, but the obsolete TC237 > has only twelve pins, requires rather complicated digital waveforms > on five of them, and outputs analogue pixel data on two more; you > want to keep the ADC as close to the detector as possible, I'd have > thought connecting the ADCs via an FPGA to gigabit-ethernet channels > would be a reasonable way to go, leaving the problem of data > acquisition from lots of gigabit ethernet connectors as one already > solved by the WAN people. > > Tom One fast image sensor project I bumped into that was not an end user camera, was based on a cmos sensor, not that I have ever been impressed with cmos web or picture cameras. In that design I was told of a 4k x 4k sensor with 1KHz or so frame rates with multi stacking of cm size chips, the processing logic was in pixel blocks in a second layer. If the A/D conversion could have been done in pixel tiles parallel style, I am sure one could have put HT on it too (for bottomless $ budget). HT only makes sense in an interactive compute situation, not a input/output only one. The serial data rate would have been quite fast but as you say, better to use standard gig networking that you can use plug n play to any workstation. John JaksonArticle: 101796
In article <1146955848.154397.42440@i40g2000cwc.googlegroups.com>, BoroToro <beiermann@gmail.com> wrote: > I just received my Spartan 3e starter kit and had to share my > frustration... > > The huge DRAM and the fast FPGA seem to make this board ideal for video > and sound processing. But.. why on earth does the board come with a > 3bit VGA output? We do not live in the 80ies anymore. Adding a couple > of resistors to get 8 or 12bit color resolution would hardly have > changed the BOM. Even a video DAC is not expensive. It would, however, have used up more IO pins. I don't know if that was a consideration, but they do seem to share pins for the devices on the SPI bus. Does anyone know if doing PWM on the VGA output pins would cause Bad Things to happen to a typical monitor? -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 101797
Falk Brunner wrote: > Jeremy Ralph schrieb: > >> If one wanted to develop an FPGA-based hardware accelerator that could >> attach to the average PC to process data stored in PC memory what >> options are there available. > > Nice idea, but to beat a nowady CPU (Pentium 4 and Athlon 64 etc.) and a > nowadays GPU (Nvidi Gforce whatever-is-uptodate etc.) is hard to achive > even with the big guys in the business. (yeah, yeah, special task can be > optimized to run faster on FPGA based hardware, but to speed up "normal" > PC tasks is difficult) > >> Decision factors are: >> + ease of use (dev kit, user's guide, examples) >> + ability to move data with minimal load on the host PC >> + cost >> + scalability (i.e. ability to upsize RAM and FPGA gates) >> + ability to instantiate a 32 bit RISC (or equiv) > >> Someone recommended the TI & Altera Cyclone II PCIe dev board, which is >> said to be available soon. Any other recommendations? > >> Also, what is the best way to move data between PC mem to FPGA? DMA? > > Sure. > >> What transfer rates should one realistically expect? > > PCI is 133 Mbyte/s max. PCI-X 64-bits @ 133 MHz will give you around 1 GByte/s max in one direction. Most high-end server mother-boards have PCI-X rather than PCI. > AGP is 2 GByte/s max. (AFAIK) > PCI-Express is nx250 Mbyte/s (with n up to 16) Currently the maximum theoretical speed of PCI-Express is 2.5 Gbits/s per lane per direction as specified in the standard. That immediately drops to 2.0 Gbits/s per lane per direction due to 8b10b encoding. Then of course in practice the smallish nature of Transaction Layer Packet (TLP) sizes (i.e. the ratio of payload compared to header) cause further reduction in the useful data throughput. In reality you're looking at approximately 1.5 Gbits/s per lane per direction of real data throughput. The big advantage with PCI-Express is the seamless scalability and the point-to-point serial protocol. So a 16-lane PCI-Express end point should give you 24 Gbits/s in each direction of useful data throughput. Regards, Alif.Article: 101798
JJ wrote: > Jeremy Ralph wrote: >> If one wanted to develop an FPGA-based hardware accelerator that could >> attach to the average PC to process data stored in PC memory what >> options are there available. >> >> Decision factors are: >> + ease of use (dev kit, user's guide, examples) >> + ability to move data with minimal load on the host PC >> + cost >> + scalability (i.e. ability to upsize RAM and FPGA gates) >> + ability to instantiate a 32 bit RISC (or equiv) >> >> Someone recommended the TI & Altera Cyclone II PCIe dev board, which is >> said to be available soon. Any other recommendations? >> >> Also, what is the best way to move data between PC mem to FPGA? DMA? >> What transfer rates should one realistically expect? >> >> Thanks, >> Jeremy > > FPGAs and standard cpus are bit like oil & water, don't mix very well, > very parallel or very sequential. > > What exactly does your PC workload include. > > Most PCs that are fast enough to run Windows and the web software like > Flash are idle what 99% of the time, and even under normal use still > idle 90% of the time, maybe 50% idle while playing DVDs. > > Even if you have compute jobs like encoding video, it is now close > enough to real time or a couple of PCs can be tied together to get it > done. > > Even if FPGAs were infinitely fast and cheap, they still don't have a > way to get to the data unless you bring it to them directly, in a PC > accelerator form, they are bandwidth starved compared to the cache & > memory bandwidth the PC cpu has. > > There have been several DIMM based modules, one even funded by Xilinx > VC a few years back, I suspect Xilinx probably scraped up the remains > and any patents? > > That PCI bus is way to slow to be of much use except for problems that > do a lot of compute on relatively little data, but then you could use > distributed computing instead. PCIe will be better but then again you > have to deal with new PCIe interfaces or using a bridge chip if you are > building one. What about PCIe IP cores? That may be a better option than bridge chips since it keeps everything FPGA oriented. However, it does mean that the FPGA must have gigabit speed serial transceivers built in and that limits one's options a little bit. Regards AlifArticle: 101799
Dave Pollum wrote: > Paul wrote: >> hi, there, >> >> I want to set one of I/O pin as 3 state, how can I do this in Xilinx >> FPGA using Verilog? >> >> thanks > > You may want to ask in comp.lang.verilog. > > VHDL code: > -- this makes the output "out_pin" hi-impedance when "Z_enable" is a > '1'. > -- Otherwise, "out_pin" is assigned the value of "some_bit". > out_pin <= 'Z' when Z_enable = '1' > else some_bit; Moreover, you may need to constrain that pin as a tristate driver by explicitly specifying that to your synthesis tool outside of VHDL. Regards, Alif.
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