Tabula. (FPGA start up)
in [FPGA]
|
From: -jg on 8 Mar 2010 14:57 On Mar 9, 7:25 am, Jon Elson <jmel...(a)wustl.edu> wrote: > -jg wrote: > I make a line of products that have multiple quadrature encoder counters > in FPGAs. I've been thinking that due to the digital filtering of the > inputs that is required, I could time multiplex the logic of these > counters pretty easily and save a bunch of space. The filtering runs at > 1 MHz! But, I could just as easily figure out how to do this in the HDL > of my choice, with just a little thinking. If you have spare BRAM, that can easily create many time-sliced counters, with a simple add/subt. At a guess, a Xmos part could likely manage ~32 x 32 bit quad counters, at 1MHz poll rates. -jg
From: rickman on 8 Mar 2010 16:18 On Mar 8, 1:25 pm, Jon Elson <jmel...(a)wustl.edu> wrote: > -jg wrote: > > On Mar 3, 12:22 am, Symon <symon_bre...(a)hotmail.com> wrote: > >> This lot seems to be revealing a bit more about their stuff. > > >>http://www.mercurynews.com/breaking-news/ci_14493616 > > > A better overview is here > >http://www.eetasia.com/ART_8800599499_499495_NT_b33fb563_2.HTM > > > Some of what Tabula say, reads more like a patent dance, than any > > technical explanation. > > > So, it is locally 1.6GHz, with time-sliced threads. > > It might save Logic and routing, but it will have no config-memory > > saving, and it ADDS the complexity of > > rapid config multiplex. (not to mention power impacts) > > Yeah. If you have a very linear procedure to perform, a processor (CPU) > can save an enormous amount of hardware, but at a severe time penalty. > But, the basic idea is kind of the same, share hardware and do the task > in smaller pieces, sequentially. maybe this Tabula concept is trying to > make a finer-grain move in that direction.> We already have Achronix climing 1.5GHz PLDs since 2008, and XMOS > > have 400-500Mhz hard-time-sliced cores shipping also. > > This sounds more interesting, and may be a more solid shift in technology..> Tabula have some rather quaint terminology, as they try to spin what > > they do, but designers have always tried to do more serially & > > pipeline, to save resource, if they can. > > > It seems their SW will do the 'thread slice & dice' for you, and that > > may be the critical point. > > > If that works, and you can debug it, it could be useful. If it fails, > > it will fail in a tangle. > > Definitely. I don't understand what they are trying to do well enough > to even know how hard this will be, but the debugging does sound quite > messy. Also, I suspect there are a variety of tasks where the Tabula > would be so totally a poor fit. > > I make a line of products that have multiple quadrature encoder counters > in FPGAs. I've been thinking that due to the digital filtering of the > inputs that is required, I could time multiplex the logic of these > counters pretty easily and save a bunch of space. The filtering runs at > 1 MHz! But, I could just as easily figure out how to do this in the HDL > of my choice, with just a little thinking. Multiplexing things like counters is not very efficient because of the granularity. A counter is no more complex in an FPGA than a 2 input mux. If you add a mux to share a counter in two processes you gain nothing. If you share a larger logic block then you can start to see some gains. That is in essence what a CPU does. It multiplexes a huge number of logic and arithmetic operations using the enormous muxes built into a RAM (which are essentially free, unlike in FPGAs. More appropriate might be doing your calculations bit serially. Often the limiting constraint on a design is the number of LUTs while FFs are sitting around collecting dust. A counter can be done bit serially with only a few more FFs and fewer LUTs than the parallel approach... if you have the time. The tabula approach seems to be the opposite of this where they multiplex the logic between fixed registers. So you can use the same registers and replace the logic. My expectation is that they will develop a methodology of some sort to allow this to be debugged. But I expect this won't be that much different from regular logic in an FPGA. They will need to give clear examples of how to code an HDL for this and you follow the examples. Then your simulation should catch most issues. Rick
From: Symon on 9 Mar 2010 13:30 On 3/2/2010 8:15 PM, Jonathan Bromley wrote: > progressive; they are fuelled by discontinuous > changes (the discovery and exploitation of > GMR-effect in disk drives, for example). You > don't immediately see a huge stepwise change > because of these innovations; there's no point > in creating something that's 10 times as good as > the competition, when something 1.5 times as good > will make you rich. So it appears to the casual > or ill-informed observer that things just go on > getting better without innovation, when in truth > it is innovation (and the pull of consumer demand) > that drives it all. > Hi Jonathan, A bit OT, and maybe just hype, but I saw this:- http://news.bbc.co.uk/1/hi/sci/tech/8556656.stm and thought of what you said! Cheers, Syms.
From: Jon Elson on 10 Mar 2010 19:00 -jg wrote: > On Mar 9, 7:25 am, Jon Elson <jmel...(a)wustl.edu> wrote: >> -jg wrote: >> I make a line of products that have multiple quadrature encoder counters >> in FPGAs. I've been thinking that due to the digital filtering of the >> inputs that is required, I could time multiplex the logic of these >> counters pretty easily and save a bunch of space. The filtering runs at >> 1 MHz! But, I could just as easily figure out how to do this in the HDL >> of my choice, with just a little thinking. > > If you have spare BRAM, that can easily create many time-sliced > counters, with a simple add/subt. > > At a guess, a Xmos part could likely manage ~32 x 32 bit quad > counters, at 1MHz poll rates. But, you'd QUICKLY run out of I/O pads! So, such level of multiplexing doesn't take much advantage of the possibilities. If a much larger task than quadrature counting was needed, then you'd get a bigger benefit. As it is in the project mentioned above, I'm tight on pins with a 144-pin Spartan 2 FPGA (there's a lot of other stuff on it than the 4 quadrature counters), but could add a few more counters. Jon
From: Jon Elson on 10 Mar 2010 19:06
rickman wrote: > Multiplexing things like counters is not very efficient because of the > granularity. A counter is no more complex in an FPGA than a 2 input > mux. If you add a mux to share a counter in two processes you gain > nothing. But, if you replace N counters with one adder/subtracter and a BRAM, it may well save real estate. Muxing 2 counters seems pointless, but maybe when it gets to replacing 8 counters with one add/sub block it pays off. Even at 8 units it may just be a lot simpler to leave it dedicated hardware. If I had the I/O lines, I could probably multiplex 40 counters at 1 MHz to one add/sub running at 40 MHz and save a BUNCH of area, but with the index pulse, each counter would take 3 inputs for 120 pins. We don't need 40 quadrature counters on one chip, anyway. Jon |