Goto page Previous 1, 2
Jonathan Bromley
Guest
Fri Mar 05, 2010 9:32 am
On Fri, 05 Mar 2010 00:29:51 +0000, Symon wrote:
Quote:
time they ship product. Successful startups usually have something
that is *many* times better than the existing products, on some axis
almost entirely orthogonal to the prior metrics.
Mate,
Ever wonder if you've been doing this too long? Did you write that last
phrase with a straight face?
Aw, c'mon, don't give us a hard time. Sometimes we're so
exposed to that kind of MBA-speak that a bit of it leaks
into our heads unbidden.
At least Eric didn't talk about "crossing the chasm" (squirm).
--
Jonathan Bromley
Symon
Guest
Fri Mar 05, 2010 11:20 am
On 3/5/2010 8:32 AM, Jonathan Bromley wrote:
Quote:
On Fri, 05 Mar 2010 00:29:51 +0000, Symon wrote:
time they ship product. Successful startups usually have something
that is *many* times better than the existing products, on some axis
almost entirely orthogonal to the prior metrics.
Mate,
Ever wonder if you've been doing this too long? Did you write that last
phrase with a straight face?
Aw, c'mon, don't give us a hard time. Sometimes we're so
exposed to that kind of MBA-speak that a bit of it leaks
into our heads unbidden.
At least Eric didn't talk about "crossing the chasm" (squirm).
I forgot the smiley, sorry! I hope I've not upset the FPGA community? :-)
I particularly chuckled at 'almost entirely'. A bit like 'nearly
unique', or '82% pregnant'.
I wonder if a lot of small companies are stymied by the legal stuff
surrounding patent law. It seems the big boys patent anything and
everything, whether it's novel and innovative or not, and then use the
lawyers to kill anyone who tries to compete.
Here's a recent example:-
http://www.theregister.co.uk/2010/03/03/apple_htc_google/
I wonder if there should be some kind of vexatious litigant law, or a
SLAPP type law. I guess that's why these patent cases are never heard in
California which seems to have fairly sensible legislation in this area.
My iPhone has designed in California on it, why are Apple suing HTC in
Delaware?
Cheers, Syms.
Raymund Hofmann
Guest
Fri Mar 05, 2010 2:48 pm
On 2 Mrz., 22:28, -jg <jim.granvi...@gmail.com> wrote:
Quote:
On Mar 3, 12:22 am, Symon <symon_bre...@hotmail.com> wrote:
meanwhile, over in the other corners, anyone remember Triscend ?
I do.
I tried to use their Arm7 part.
I gave up after i discovered their P&R software Fastchip entirely
written in Java still sucked after giving it a new machine with lots
of memory and processing power.
But at that time a Arm7 MCU alone was quite interesting...
rickman
Guest
Fri Mar 05, 2010 7:32 pm
On Mar 4, 7:29 pm, Symon <symon_bre...@hotmail.com> wrote:
Quote:
On 3/4/2010 12:46 PM, Eric Smith wrote:
time they ship product. Successful startups usually have something
that is *many* times better than the existing products, on some axis
almost entirely orthogonal to the prior metrics.
Eric
Mate,
Ever wonder if you've been doing this too long? Did you write that last
phrase with a straight face?
Cheers, Syms.
Yeah, the funny thing is I understood it AND missed the inside joke
entirely!
Rick
Jon Elson
Guest
Mon Mar 08, 2010 7:25 pm
-jg wrote:
Quote:
On Mar 3, 12:22 am, Symon <symon_bre...@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.
Quote:
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.
Jon
-jg
Guest
Mon Mar 08, 2010 9:57 pm
On Mar 9, 7:25 am, Jon Elson <jmel...@wustl.edu> wrote:
Quote:
-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
rickman
Guest
Mon Mar 08, 2010 11:18 pm
On Mar 8, 1:25 pm, Jon Elson <jmel...@wustl.edu> wrote:
Quote:
-jg wrote:
On Mar 3, 12:22 am, Symon <symon_bre...@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
Symon
Guest
Tue Mar 09, 2010 7:30 pm
On 3/2/2010 8:15 PM, Jonathan Bromley wrote:
Quote:
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.
Jon Elson
Guest
Thu Mar 11, 2010 1:00 am
-jg wrote:
Quote:
On Mar 9, 7:25 am, Jon Elson <jmel...@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
Jon Elson
Guest
Thu Mar 11, 2010 1:06 am
rickman wrote:
Quote:
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
John_H
Guest
Thu Mar 11, 2010 5:08 am
On Mar 10, 7:06 pm, Jon Elson <jmel...@wustl.edu> wrote:
Quote:
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
The thing I liked about multiplexing large counters (I had about 7
values I needed to keep track of) was the reduction in readout logic.
If I use a distributed CLB SelectRAM for the count values, I can read
multiple values from the memory without adding (much) readout logic.
In my case, I had 27-bit counters which were only read after the
counting events so the CLB SelectRAM was single port. Seven 27-bit
counters and associated readout, implemented in around 60 LUTs. Not
bad. The "simple" approach would have been about 300 LUTs once
readout is thrown in.
-jg
Guest
Thu Mar 18, 2010 9:43 am
On Mar 3, 12:22 am, Symon <symon_bre...@hotmail.com> wrote:
Quote:
This lot seems to be revealing a bit more about their stuff.
and still more info
http://www.eeproductcenter.com/pld-fpga/brief/showArticle.jhtml;jsessionid=BPWGVULEVILDOQSNDLSCKHA?articleID=223800194
[" the chips will sample in third quarter and go into mass production
in Q4 2010. "]
["A1EC02, A1EC03, A1EC04, and the A1EC06 with between 220,000 and
630,000 look-up tables per device. All four parts have 5.5-Mbytes of
RAM, 920 parallel I/Os and 44 PLLs, Tabula said The A1EC06 has 1,280
multiplier-accumulator blocks. Designed for a range of applications,
ABAX devices will initially target the telecom, enterprise, and
wireless infrastructure markets and all the initial devices in the
family include 48 serial transceivers operating at between 55-Mbit/s
and 6.5-Gbit/s. "]
A1EC04 is $150 per unit for orders of 2,000 units
That's a lot of engineering...
-jg
Goto page Previous 1, 2
