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
In article <1146975146.177800.163180@g10g2000cwb.googlegroups.com>, JJ <johnjakson@gmail.com> 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. Actually, that's what could make it the perfect marriage. General purpose CPUs for the things they're good at like data IO, displaying information, etc. FPGAs for applications where parallelism is key. I think the big problem right now is conceptual: we've been living in a serial, Von Neumann world for so long we don't know how to make effective use of parallelism in writng code - we have a hard time picturing it. Read some software engineering blogs: with the advent of things like multi-core processors, the Cell, etc. (and most of them are blissfully unaware of the existence of FPGAs) they're starting to wonder about how they are going to be able to model their problems to take advantage of that kind of paralellism. They're looking for new abstractions (remember, software engineering [and even hardware engineering these days] is all about creating and managing abstractions). They're looking for and creating new languages (Erlang is often mentioned in these sorts of conversations). Funny thing is that it's the hardware engineers who hold part of the key: HDLs are very good at modelling parallelism and dataflow. Of course HDLs as they are now would be pretty crappy for building software, but it's pretty easy to see that some of the ideas inherant in HDLs could be usefully borrowed by software engineers. > >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. Well, there's that DRC computing product that puts a big FPGA in one slot of a dual opteron motherboard passing data between the Opteron and FPGA at very high speed via the hypertransport bus. It seems like the perfect combination. The transfer speeds are high enough to enable lots of types of FPGA accelerator applications that wouldn't have been practical before. > >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. Certainly there are classes of problems which require very little data transfer between FPGA and CPU that could work acceptably even in a PCI environment. > >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. > One wonders how different history might be now if instead of the serial Von Neumann architectures (that are now ubiquitious) we would have instead started out with say, cellular automata-like architectures. CAs are one computing architecture that are perfectly suited for the parallelism of FPGAs. (there are others like neural nets and their derivatives). Our thinking is limited by our 'legos', is it not? If all you know is a general purpose serial CPU then everything starts looking very serial. (if I recall correctly, before he died Von Neumann himself was looking into things like CAs and NNs because he wanted more of a parallel architecture) There are classes of biologicially inspired algorithms like GAs, ant colony optimization, particle swarm optimization, etc. which could greatly benefit from being mapped into FPGAs. PhilArticle: 101951
In article <1146981253.226901.102660@i39g2000cwa.googlegroups.com>, JJ <johnjakson@gmail.com> wrote: >I always hated that the PCI cores were so heavily priced compared to >the FPGA they might go into. The pricing seemed to reflect the value >they once added to ASICs some 10 or 15 years ago and not the potential >of really low cost low volume applications. A $100 FPGA in small vol >applications doesn't support $20K IP for a few $ worth of fabric it >uses. It might be a bargain compared to the cost of rolling your own >though, just as buying an FPGA is a real bargain compared to rolling my >own FPGA/ASIC too. That's why OpenCores is so important. (http://opencores.org) As FPGAs become cheaper we're going to need an open source ecosystem of cores. They've got a PCI bridge design at Open cores, for example. BTW: it would also be nice to have an open source ecosystem of FPGA design tools... but that's a bit tougher at this point. PhilArticle: 101952
Jim, the idea itself is not really new. Indeed, it is well known to the community of people beeing interested in picosecond time resolution measurements. I have used a chain of 32 "carry-elements" (extremely fast interconnections between logic elements to make the carry bit move fast enough for long adders. a.s.o.) to construct a 110 ps resolution time interval counter with a ALTERA 10K30 gate array. If you want to use things like that seriously, keep in mind that the unit delays are highly dependand on chip temperature and supply voltage. There are some tricks available to remove theses dependancies or correct for them. For commercially available chips using such technology have a look at http://www.acam.de Regards Ulrich Bangert "Jim Granville" <no.spam@designtools.co.nz> schrieb im Newsbeitrag news:445fa229@clear.net.nz... > > This news is interesting > > http://www.eet.com/news/latest/showArticle.jhtml?articleID=187200783&pgno=2 > > You do need a hype filter when reading this, and many claims are > extropolation-gone-wrong, but the base idea already exists in ring > osc designs inside FPGA now. > > Seems ( with the right tools ) you could extend this inside a FPGA, by > creating a large physical ring (long routes), with the sprinkled > buffers. The physical delays would reduce the process variations in the > clock, and you get the phase taps 'for free'. > - but the tools _will_ need to co-operate :) > > We have done this inside CPLDs, and get appx 1.3ns granularity. > > With FPGAs the buffer delays are much lower, and the routing > can be made to dominate. > > Sounds like a project for Antti :) > > -jg >Article: 101953
SongDragon wrote: > I am looking for some assistance writing a driver and FPGA code to > handle DMA on a PCI Express system. The FPGA is a Xilinx V2P with a > Xilinx x4 PCIe LogiCORE (v3.0). Assuming the LogiCORE is capable of bus mastering, you need to instantiate a 'DMA controller' in your FPGA; either your own design or borrowed from another source. A 'DMA controller' can simply be a set of registers (sometimes referred to as 'descriptors') mapped into the host address space that allow the software to set a DMA transfer - source address, destination address, transfer size, control/status etc - hit a 'GO' bit, and generate an interrupt when it's done. If you want to get more fancy, add multiple channels, scatter-gather descriptors, request queuing, etc. From the back side of the PCIe core, all the DMA controller does is request the bus and issue a standard (burst in PCI-land) read/write to/from the source/destination addresses in the register. PCIe itself has no concept of 'DMA' - all it sees is another PCIe transfer. Exactly how you establish the transfer in the core is dependent on the backend interface of the LogiCORE. You shouldn't have to worry about the format of the TLP at all if there's a decent backend interface. > Are there any reference designs / > sample code available? A DMA controller IP core for PCI would still illustrate the concepts and give some insight into what you're up for. At the risk of muddying the waters further, there's a wishbone DMA core on opencores which can ultimately be used for PCI DMA transfers when connected to a PCI core (the opencores PCI core is a wishbone bridge so it bolts straight on). Might even be worth just looking at the doco for it. As for the driver, that will depend on what class of device you're implementing, especially if you're talking about windows. Your best bet there is to find an open-source/example driver for a similar device. If you're doing windows and need a 'grass-roots' high performance driver, prepare yourself for a frustrating and challenging time. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 101954
The problem with PWM here is that there is no filter on the output, so you get essentially an AC signal that will look pretty rough to a monitor expecting a DC signal. To get a true DC value out of that, you need some capacitance. It is possible that if you created a small adapter with three low-pass R-C filters for each signal, you might get acceptable results - even on an LCD. Alternately, you might be able to solder some capacitors directly to the connector and solder the negative terminals to ground. This depends on the resistance of the board traces - which may or may not be adequate.Article: 101955
Eight microseconds divided by 36 equals 222 nanoseconds. No obscenities please. Peter Alfke ================================== Ron wrote: > P.S. > Before someone catches my error, yes indeed you could run some of these > multiplies in parallel to cut the timing even more. The datasheet says > the Spartan-3E devices have between 4 to 36 dedicated multiplier blocks > per device, so depending on how many there are on the FPGA the 8 > microseconds I mentioned earlier could be cut by as much as 1/4 to > 1/36th to 22ns for 1024 bits!!! I will definitely have to look into this > at some point. It would be great if a multiprecision package for the > multipliers were already available in Verilog.Article: 101956
Peter Alfke wrote: > Eight microseconds divided by 36 equals 222 nanoseconds. Keyboard bounce. ;-)Article: 101957
On Mon, 08 May 2006 23:29:34 GMT, Mike Harrison <mike@whitewing.co.uk> wrote: >On Tue, 09 May 2006 07:56:10 +1200, Jim Granville <no.spam@designtools.co.nz> wrote: > >> >>This news is interesting >> >>http://www.eet.com/news/latest/showArticle.jhtml?articleID=187200783&pgno=2 >> >> You do need a hype filter when reading this, and many claims are >>extropolation-gone-wrong, but the base idea already exists in ring >>osc designs inside FPGA now. >> >> Seems ( with the right tools ) you could extend this inside a FPGA, by >>creating a large physical ring (long routes), with the sprinkled >>buffers. The physical delays would reduce the process variations in the >>clock, and you get the phase taps 'for free'. >> - but the tools _will_ need to co-operate :) >> >> We have done this inside CPLDs, and get appx 1.3ns granularity. >> >>With FPGAs the buffer delays are much lower, and the routing >>can be made to dominate. >> >> Sounds like a project for Antti :) >> >>-jg > >Just a silly thought - how about using a very long async delay path as a memory device - like the >mercury delay-line memories of olden times . Not useful but maybe an interesting exercise for those >with too much time on their hands.... It's tricky. If the process doesn't have exactly equal rise and fall times, duty cycle changes as the sig propagates, so either 1's or 0's get narrower and narrower until one of them disappears. There are TDC chips that use a long string of buffers to generate a lot of successive delays. They usually servo Vcc of the string to keep the overall delay and symmetry on target. JohnArticle: 101958
"Peter Alfke" <peter@xilinx.com> wrote in message news:1147107399.214122.95990@j33g2000cwa.googlegroups.com... > Part of the traditional military qualification of ceramic wire-bonded > parts (bonding wires essentially unsupported in the cavity) was a > centrifuge test at 20,000g (10 000 g for the larger parts.) > Plastic encapsulated parts are not tested this way, since the test is > considered meaningless (no chance to fail). > Peter Alfke > Peter....we've told you a million times not to exaggerate! 20,000 g's? That is amazing. BobArticle: 101959
Since this discussion is veering back and forth between being on-topic, I suppose I can throw my two cents in. I am both a professional and hobby FPGA developer. At work, I get all kinds of fancy Virtex and Stratix parts to target. At home, I have a Cyclone II 2C35 (on an Altera DE2 board) and the Xilinx sample pack I got for free. Both use free tools from Altera and Xilinx respectively. First, the silicon is interesting, but not terribly hard anymore. The basic features are common to all manufacturers. The real magic is in the mapping and PAR. Why else would someone pay for Synplicity software? Thus, the software tools that Ron disparages are probably worth the money considering what they do. I recognize that, and accept that it costs money to keep the tools up to date. That said, I wish vendors didn't feel the need to disown older parts when it isn't difficult to keep support as an option. I can still output from Microsoft Word to all kinds of strange, esoteric (and ancient) formats. Why can't Xilinx allow me to use the latest ISE to target strange, esoteric FPGA's? Simply make it an optional component. At the very least, let me download a support module from your website - if putting it on the DVD is too much trouble. As it stands, at work I have to keep a copy of ISE 4.2i, because it is the last version that supports the XC4000E series FPGA's - and it doesn't play well when install alongside 7.1i - which means a dedicated terminal just for 4.2i. This is BLOODY FRUSTRATING. I realize the parts are old, but they are still out there - and designs do occasionally need maintenance. BTW - Austin was bragging about a lot of military and space applications. Guys, we actually support those designs for more than 5 years. It would be helpful if your tools did as well. As for the cost issue, the webpacks cover all but the high-end parts. I have found them perfectly adequate for home use. I'm actually impressed that Xilinx or Altera offer free versions at all. Seriously, you get a VHDL/Verilog compiler, limited simulation, mapping and PAR - for free? That's almost absurd. The only tool I don't have at home is Synplify Pro - I end up using Quartus and XST. As a fairy tale wish, it would be nice if there was an academic pricing plan that could include guys like me that want to develop at home, without having to run to the office to compile something. Yes, it is a different market - but with just a little forethought, you could offer great pricing to students and hobbyists, while retaining the high-end corporate accounts. I would gladly pay several hundred for a _perpetual_ license that had restrictions on what commercial activities were allowed, yet let me play with the larger parts on boards from Digilent, BurchEd, etc. (I would even be OK with the software being tied TO the boards - maybe lock on the FPGA serial number via JTAG or something) Much like the GPL, if you want to do something outside the license, like start a business, you cough up for an unrestricted license. Yes, there would be a trust element, but since you are also the manufacturer, it wouldn't be difficult to see a spike in part orders. Something to think about - since I know I would like to play with the Virtex parts with embedded PPC cores - but can't afford to ante-up to the full package.Article: 101960
In article <G9R7g.135$7q7.106@fe05.lga>, News5@spamex.com
says...
> Mike Harrison wrote:
> > Presumably you could do it rather quicker using the S3's multiplier blocks.....
>
> Good point, but then I'd be tied into a particular FPGA. The multipliers
> are very impressive however. If I ever get my design to fit on
> something, then I can start taking advantage of things like the built-in
> multipliers to speed things up. Lets see, 18x18->36 bits in less than 5
> ns. For a 1024 bit multiply, it would take roughly 1,624 eighteen bit
> multiplies and a bunch of multi-precision additions, which translates
> into around 8 microseconds per 1024 bit word! Very impressive indeed.
The multipliers are built in dedicated logic, so using
them will allow you to fit a larger block into a given
device. IOW, using them will contribute directly to
making your design fit.
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 101961In article <1147142273.761777.130440@i39g2000cwa.googlegroups.com>, radarman <jshamlet@gmail.com> wrote: > The problem with PWM here is that there is no filter on the output, so > you get essentially an AC signal that will look pretty rough to a > monitor expecting a DC signal. To get a true DC value out of that, you > need some capacitance. It is possible that if you created a small > adapter with three low-pass R-C filters for each signal, you might get > acceptable results - even on an LCD. > > Alternately, you might be able to solder some capacitors directly to > the connector and solder the negative terminals to ground. This depends > on the resistance of the board traces - which may or may not be > adequate. There are resistors (few hundred ohms, different for the rgb than for the syncs) between the FPGA pins and the VGA connector. But two voices of experience have already chimed in saying that straight pwm without board mods doesn't work too well. And if you are going to do something like solder up capacitors, you may as well just make your own VGA port with as many bits as you want. -- David M. Palmer dmpalmer@email.com (formerly @clark.net, @ematic.com)Article: 101962
radarman wrote: <snip> > That said, I wish vendors didn't feel the need to disown older parts > when it isn't difficult to keep support as an option. I can still > output from Microsoft Word to all kinds of strange, esoteric (and > ancient) formats. That's partly because of lawsuits, when Microsoft has attempted to EOL products lines, which has meant excluding still-working-fine PCs. > Why can't Xilinx allow me to use the latest ISE to > target strange, esoteric FPGA's? Simply make it an optional component. > At the very least, let me download a support module from your website - > if putting it on the DVD is too much trouble. > > As it stands, at work I have to keep a copy of ISE 4.2i, because it is > the last version that supports the XC4000E series FPGA's - and it > doesn't play well when install alongside 7.1i - which means a dedicated > terminal just for 4.2i. This is BLOODY FRUSTRATING. I realize the parts > are old, but they are still out there - and designs do occasionally > need maintenance. BTW - Austin was bragging about a lot of military and > space applications. Guys, we actually support those designs for more > than 5 years. It would be helpful if your tools did as well. The short design life of tools has to be impacting their silicon sales, and as you point out, engineering support requires working tools. -jgArticle: 101963
Jerry Coffin wrote: > The multipliers are built in dedicated logic, so using > them will allow you to fit a larger block into a given > device. IOW, using them will contribute directly to > making your design fit. I was wondering about that. There would be a great deal of routing, shifting, etc., in a design that does multi-precision multiplication however, and as slow as the design I'm using now is, it's about as minimal as it's possible to get I think (basically a couple of shift registers, with test and conditional add). I think I'll go search around and see if I can find some sort of multi-precision multiplication module(s) in Verilog on the net somewhere just to get started quickly. If anyone happens to know of anything like that, please post a link. Thanks, RonArticle: 101964
Ron wrote: > Jerry Coffin wrote: > >> The multipliers are built in dedicated logic, so using them will allow >> you to fit a larger block into a given device. IOW, using them will >> contribute directly to making your design fit. > > > I was wondering about that. There would be a great deal of routing, > shifting, etc., in a design that does multi-precision multiplication > however, and as slow as the design I'm using now is, it's about as > minimal as it's possible to get I think (basically a couple of shift > registers, with test and conditional add). > > I think I'll go search around and see if I can find some sort of > multi-precision multiplication module(s) in Verilog on the net somewhere > just to get started quickly. If anyone happens to know of anything like > that, please post a link. Also look at the newest Lattice devices, they have DSP blocks, with more in them. If you can wear your 'humble and polite researcher' hat, you might be able to get a loan of the full tool chain :) It would be in their interests to have the flow tested on wide data paths. -jgArticle: 101965
Radarman, I agre with most of what you wrote, but I am not the boss here... One exception, though: " Why can't Xilinx allow me to use the latest ISE to target strange, esoteric FPGA's? Simply make it an optional component." Making the newest software compatible with XC3000 nd XC4000 would be a nightmare for our developers. They might declare it so difficult as to be virtually impossible. Backwards compatibility is a nightmare for any software developer (my son works at Apple R&D...) Otherwise you have some good ideas. It's just that our software developer have their plate full with urgent and vital projects, so that the things you mention often don't rise high enough. BTW, at work, I get some anusing comments about the insults I have to endure here. But they are so outlandish that they do not really hurt... Peter Alfke Peter AlfkeArticle: 101966
Phil Tomson wrote: > In article <1146981253.226901.102660@i39g2000cwa.googlegroups.com>, > JJ <johnjakson@gmail.com> wrote: > >I always hated that the PCI cores were so heavily priced compared to > >the FPGA they might go into. The pricing seemed to reflect the value > >they once added to ASICs some 10 or 15 years ago and not the potential > >of really low cost low volume applications. A $100 FPGA in small vol > >applications doesn't support $20K IP for a few $ worth of fabric it > >uses. It might be a bargain compared to the cost of rolling your own > >though, just as buying an FPGA is a real bargain compared to rolling my > >own FPGA/ASIC too. > > That's why OpenCores is so important. (http://opencores.org) As FPGAs > become cheaper we're going to need an open source ecosystem of cores. > They've got a PCI bridge design at Open cores, for example. > > BTW: it would also be nice to have an open source ecosystem of FPGA > design tools... but that's a bit tougher at this point. > > Phil Yes but open source and closed source are also like oil and water esp together in a commercial environment. If I were doing commercial work I doubt I'd ever use opencores but I might peek at it for an understanding of how it might be done or ask someone else to. On a hobbyist level, well I have mixed feelings about gpl too. I suspect the software world does far better with it since enough people support the gpl movement and there is a large user base for it. Hardware ultimately can't be made for free so it can't be the same model. John JaksonArticle: 101967
Jim, don't call it research. That word and "play" triggered this whole barrage of Ron's favorite obscenities. PeterArticle: 101968
That's what centrifuges are made for. They were invented to separate butterfat from milk, but now they also separate Uranium isotopes from each other. The automobile wheel may spin at 30 revs/sec = 2000 rpm, but centrifuges can do 100 000 rpms... Peter AlfkeArticle: 101969
Phil Tomson wrote: > In article <1146975146.177800.163180@g10g2000cwb.googlegroups.com>, > JJ <johnjakson@gmail.com> wrote: > > snipping > > > >FPGAs and standard cpus are bit like oil & water, don't mix very well, > >very parallel or very sequential. > > Actually, that's what could make it the perfect marriage. > > General purpose CPUs for the things they're good at like data IO, > displaying information, etc. FPGAs for applications where parallelism is > key. > On c.a another Transputer fellow suggested the term "impedance mismatch" to describe the idea of mixing low speed extreme parallel logic with high speed sequencial cpus in regard to the Cray systems that have a bunch of Virtex Pro parts with Opterons on the same board, a rich mans version of DRC (but long before DRC). I suggest tweening them, puts lots of softcore Transputer like nodes into FPGA and customize them locally, you can put software & hardware much closer to each other. One can even model the whole thing in a common language designed to run as code or be synthesized as hardware with suitable partitioning, starting perhaps with occam or Verilog+C. Write as parallel and sequential code and later move parts around to hardware or software as needs change. > I think the big problem right now is conceptual: we've been living in a > serial, Von Neumann world for so long we don't know how to make effective > use of parallelism in writng code - we have a hard time picturing it. I think the software guys have a huge problem with parallel, but not the old schematic guys. I have more problems with serial, much of it unnecessary but forced on us by lack of language features that forces me to order statements that the OoO cpu will then try to unorder. Why not let the language state "no order" or just plain "par" with no communication between. > Read some software engineering blogs: > with the advent of things like multi-core processors, the Cell, etc. (and > most of them are blissfully unaware of the existence of FPGAs) they're > starting to wonder about how they are going to be able to model their > problems to take advantage of that kind of paralellism. They're looking The problem with the Cell and other multicore cpus, is that the cpu is all messed up to start with, AFAIK the Transputer is the only credible architecture that considers how to describe parallel processes and run them based on formal techniques. These serial multi cpus have the Memory Wall problem as well as no real support for concurrency except at a very crude level, it needs to be closer to 100 instruction cycles context switches to work well, not 1M. The Memory Wall only makes threading much worse than it already was and adds more pressure to the cache design as more thread contexts try to share it. > for new abstractions (remember, software engineering [and even hardware > engineering these days] is all about creating and managing abstractions). > They're looking for and creating new languages (Erlang is often mentioned > in these sorts of conversations). Funny thing is that it's the hardware > engineers who hold part of the key: HDLs are very good at modelling > parallelism and dataflow. Of course HDLs as they are now would be pretty > crappy for building software, but it's pretty easy to see that some of the > ideas inherant in HDLs could be usefully borrowed by software engineers. > > Yeh, try taking your parallel expertise knowledge to the parallel software world, they seem to scorn the idea that hardware guys might actually know more than they do about concurrency while they happily reinvent parallel languages that have some features we have had for decades but still clinging to semaphores and spinlocks. I came across one such parallel language from U T Austin that even had always, initial and assign constructs but no mention of Verilog or hardware HDLs. But there are more serious researchers in Europe who are quite comfortable with concurrency as parallel processes like hardware, from the Transputer days based on CSP, see wotug.org. The Transputers native language occam based on CSP later got used to do FPGA design then modified into HandelC so clearly some people are happy to be in the middle. I have proposed taking a C++ subset and adding live signal ports to a class definition as well as always, assign etc, starts to look alot like Verilog subset but using C syntax but builds processes as communicating objects (or modules instances) which are nestable of course just like hardware. The runtime for it would look just like a simulator with an event driven time wheel or scheduler. Of course in a modern Transputer the even wheel or process scheduler is in the hardware so it runs such a language quite naturally, well thats the plan. Looking like Verilog means RTL type code could be "cleaned" and synthesized with off the shelf tools rather than having to build that as well and the language could be open. SystemVerilog is going in the opposite direction. snipping > >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. > > Certainly there are classes of problems which require very little data > transfer between FPGA and CPU that could work acceptably even in a PCI > environment. > The real money I think is in the problem space where the data rates are enormous with modest processing between data points such as bioinformatics. If you have lots of operations on little data, you can do better with distributed computing and clusters. > > snipping > > One wonders how different history might be now if instead of the serial > Von Neumann architectures (that are now ubiquitious) we would have instead > started out with say, cellular automata-like architectures. CAs > are one computing architecture that are perfectly suited for the > parallelism of FPGAs. (there are others like neural nets and their > derivatives). Our thinking is limited by our 'legos', is it not? > If all you know is a general purpose serial CPU then everything starts > looking very serial. > I was just reading up on the man, a far bigger "giant" in history than the serial Von Neumann computer gives him credit for which I never knew to my shame. The legacy stands because the WWII era didn't have too many tubes to play with so serial was the only practical way. > (if I recall correctly, before he died Von Neumann himself was looking > into things like CAs and NNs because he wanted more of a parallel architecture) > > There are classes of biologicially inspired algorithms like GAs, ant > colony optimization, particle swarm optimization, etc. which could greatly > benefit from being mapped into FPGAs. > > Phil Indeed John Jakson transputer guy Transputers & FPGAs two sides of the same process coinArticle: 101970
Hi jm, i noticed that the link to download the BFM Toolkit has gone away with the EDK 8.1 release. I don't know why. You can still use the "old" (i don't know if there are any "new" ones) models supplied with 7.1 for BFM simulation in 8.1. The BFM compiler itself (xilbfc) is already included in 8.1 Regards JensArticle: 101971
Symon wrote: > "JJ" <johnjakson@gmail.com> wrote in message > news:1146982987.316600.228410@i39g2000cwa.googlegroups.com... > > Alot of good stuff there but not exactly drive by reading. > > > > So what would you call someone that hasn't pre wiki'ed up on something. > > > > > > If we all went to wikipedia first, we could dissolve the news groups > > right? > > > Hi John, > Good points! I sense, rightly or wrongly, you have a little nervousness > about Wikipedia, and I share that. Who's to know what motivation someone has > had for posting stuff there? I am a little behind the curve and have heard of some fights over corrections, still it seems a good place to start for safe subjects. > I usually use Wikipedia to get a start on what to Google when I'm new to a > subject. So, if I had no idea how RFID worked, I'd start at Wikipedia. Then > do a few Google searches, and probably end up at somewhere like > http://www.rfidinc.com/ and ask questions on sci.electronics.design or maybe > alt.privacy. I doubt I'd ask on comp.arch.fpga, even though I know CAF is > the only place to be for the world's top digital engineers! :-) > As for this newsgroup, the peak level of expertise here is a lot higher than > in Wikipedia. If only for that reason, I don't see this newsgroup going away > anytime soon. The Wikipedia FPGA article is designed to give the absolute > beginner a place to start from. > Just MHO! > Best, Syms. Thats what I would do too, sometimes, not as often if I just want to jump right in to a favourite topic. Tthe RFID topic kept getting posted in c.a where it really was a total nuisance, shame about that group getting hammered into useless. ByeArticle: 101972
I just looked it up: 14,000 rpm and a radius of 10 cm generates 20 000 g. These numbers are not exotic at all. PeterArticle: 101973
Jim Granville schrieb: > > This news is interesting > > http://www.eet.com/news/latest/showArticle.jhtml?articleID=187200783&pgno=2 > > You do need a hype filter when reading this, and many claims are > extropolation-gone-wrong, but the base idea already exists in ring > osc designs inside FPGA now. > > Seems ( with the right tools ) you could extend this inside a FPGA, by > creating a large physical ring (long routes), with the sprinkled > buffers. The physical delays would reduce the process variations in the > clock, and you get the phase taps 'for free'. > - but the tools _will_ need to co-operate :) > > We have done this inside CPLDs, and get appx 1.3ns granularity. > > With FPGAs the buffer delays are much lower, and the routing > can be made to dominate. > > Sounds like a project for Antti :) No. The article is not talking about chained buffers for high timing resolution. Such a setup would still charge the clock lines from VDD and discharge to GND for each clock cycle. They are really talking about sending a wave around a transmission line. Standing wave clocking is an exotic but established technique in PCB design. At high frequencies you can use it inside ICs. A physical wave uses the same charge again and again, only resistive and EMI losses need to be refreshed by buffers PARALLEL to the transmission line. Also, there is virtually no clock skew. Kolja SulimmaArticle: 101974
Peter Alfke wrote: > Radarman, I agre with most of what you wrote, but I am not the boss > here... > One exception, though: > " Why can't Xilinx allow me to use the latest ISE to > target strange, esoteric FPGA's? Simply make it an optional component." > Making the newest software compatible with XC3000 nd XC4000 would be a > nightmare for our developers. They might declare it so difficult as to > be virtually impossible. Backwards compatibility is a nightmare for any > software developer (my son works at Apple R&D...) > Otherwise you have some good ideas. > It's just that our software developer have their plate full with urgent > and vital projects, so that the things you mention often don't rise > high enough. > BTW, at work, I get some anusing comments about the insults I have to > endure here. But they are so outlandish that they do not really hurt... > Peter Alfke > Peter Alfke There are many degrees of compatible : Easiest, is to first make sure they can co-exist - that's school-boy stuff. ie No real excuse for getting that wrong... [and I think this oops was radarman's main beef..?] Next degree of compatible is to freeze the back end/command line tools, but keep export of XNF or whatever, so the older P&R tools can be fed from newer front ends. To make the very newest SW compile to XC4000 is the wrong thing to do. Not only is it the waste of resource you mention, but it is also poor version-control. Someone doing maint changes, wants to use the _SAME_ tool chain it was created on. -jg
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