Moore versus TPL: The bomb has burst
Albert van der Horst
Read more at http://www.colorforth.com/blog.htm
I wish Chuck and GreenArrays success at this endeavour.
The outcome will be hopefully that the awesome GreenArrays technology can
be developed speedily and will become available to mankind,
instead of staying in the hands of patent sharks.
(See also http://www.greenarrays.com/ )
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Paul Rubin
> Chuck Moore has filed a suit against TPL, at last.
> Read more at http://www.colorforth.com/blog.htm
> I wish Chuck and GreenArrays success at this endeavour.
> The outcome will be hopefully that the awesome GreenArrays technology can
> be developed speedily and will become available to mankind,
> instead of staying in the hands of patent sharks.
The minute or two that I spent looking at the filing wasn't enough to
let me understand what the underlying dispute was, but it looks
unpleasant and it's always unfortunate when anything has to come to
that.
I have to wonder how valuable the GreenArrays technology really is.
There was another thread a couple weeks ago where possible applications
for the GA chips were discussed. As I remember, nobody could think of
any really convincing ones. So I get the impression that the GA guys
did some things that were pretty nifty from a technical point of view,
but got mixed up with the wrong crowd on the business and legal side.
Albert van der Horst
Apparently the business "partners" of Moore have collected (and
squandered) some $300 million in royalties for the MMP portfolio.
Doesn't sound like unconvincing technology. But I must say that I have
a hard time understanding what is going on, in that respect.
The pdf files on Greenarrays website is an interesting read,
especially the perspective of picojoules per operations.
Paul Rubin
> Apparently the business "partners" of Moore have collected (and
> squandered) some $300 million in royalties for the MMP portfolio.
Well THAT is interesting. I wonder how much of that was related to the
Forth array stuff, rather than (e.g.) the a-d converters.
> The pdf files on Greenarrays website is an interesting read,
> especially the perspective of picojoules per operations.
I see the page
http://greenarrays.com/home/documents/greg/WP003-100617-msp430.pdf
compares a GA array processor with a low powered general purpose TI
microcontroller. It says the GA chip does a 17x17 bit fractional
multiply with about 450 pJ of energy.
Let's try the same calculation for a current semi-mass-market graphics
coprocessor (NVidia GTX 480M Mobile Fermi):
http://www.anandtech.com/show/3740/nvidia-announces-gtx-480m
100 watts power consumption, 598 gigaflops
= (1e2 joules/sec) / (5.98e11 ops/sec)
= 1.72e-10 joules/op = 172 pJ / op.
So the Nvidia chip is already using less than half the energy per
operation of the GA chip, assuming (as is traditional in the DSP world)
that these flops include multiplications. Also the NVidia is doing
32-bit floating point arithmetic, so quite a lot more work per operation
than the 17-bit GA arithmetic.
Of course the 100 watt Nvidia part is not directly comparable to the
tiny GA4, but the most interesting GA product has always seemed to me to
be the big GA144 arrays. They have announced a little board with nine
GA144's on it and I thought of some possible uses for it, but in each
case, conventional DSP's seemed to make more sense. I wonder why they
don't compare the GA with a small DSP, since that's the obvious area
where you want a lot of MIPS and not a lot of memory. The GA's don't
have enough memory or i/o bandwidth for the compute-intensive
non-numeric tasks I can easily think of, though maybe I'm missing some.
I never had the impression that there was any magical process technology
in the GA chips, just clever and unique (Forth-oriented) CPU
architecture. But basic ALU operations are very well studied by now.
So I don't see how a part made on a 180 nm process can possibly beat a
part made on a 45nm or even 32nm process no matter how clever it is.
forther
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
> > Chuck Moore has filed a suit against TPL, at last.
> > I wish Chuck and GreenArrays success at this endeavour.
> > The outcome will be hopefully that the awesome GreenArrays technology can
> > be developed speedily and will become available to mankind,
> > instead of staying in the hands of patent sharks.
>
> The minute or two that I spent looking at the filing wasn't enough to
> let me understand what the underlying dispute was, but it looks
> unpleasant and it's always unfortunate when anything has to come to
> that.
>
> I have to wonder how valuable the GreenArrays technology really is.
> There was another thread a couple weeks ago where possible applications
> for the GA chips were discussed. As I remember, nobody could think of
> any really convincing ones. So I get the impression that the GA guys
> did some things that were pretty nifty from a technical point of view,
> but got mixed up with the wrong crowd on the business and legal side.
Is Hearing Aid device, tens times cheaper, than anything on the
market
not convincing enough?
Paul Rubin
> Is Hearing Aid device, tens times cheaper, than anything on the
> market not convincing enough?
I'd have to know more details to be convinced. Hearing aids are quite
expensive for various reasons including high markups. The cost of the
electronic hardware in them is almost insignificant compared to the
final price tag. So even if the GA chip (I'll guess this is a GA4)
replaces a $5 part with a $0.50 part, the hearing aid still costs
thousands. So I'd still like to know what the GA part is doing that
another part can't.
Marcel Hendrix
> On Oct 2, 1:30 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
[..]
> Is Hearing Aid device, tens times cheaper, then anything on the market
> not convincing enough?
The average end-user price of an hearing-aid in the Netherlands is
450 Euro. Are you saying that using a different chip is decreasing
that to 45 Euro?
I wouldn't be surprised if it made no (financial) difference to the
end-users at all (although one of the subcontractors for it might
like it, depending on how *low* their added value is).
Of course, if the price really goes from 450 to 45 Euro, next year
every major (and minor) chip manufacturer will come out with their
own chip designs. Maybe they will only bring cost down by a factor
of 9, but they will be packed with the kind of hi-tech algorithmic
features that a small company can never keep up with. Let alone
support.
-marcel
foxchip
In 2007 I traveled to Austria to help start a project to port
a sophisticated hearing enhancement system to Forth hardware.
This was not your typical hearing aid with an amplifier and
filter but a very complex non-intuitive algorithm for tricking
damaged human hearing into being able to recognize things.
Regular hearing aids, even those costing thousands of dollars,
really only sound good to people without hearing loss and
people with actual hearing loss tend to try them out then
stop using them.
The hearing enhancement system was first developed on a PC.
Then with much effort it was ported to a TI DSP system that
was a little smaller than a laptop, but it was still a little
like wearing a laptop on your chest. But people with hearing
loss reported that it provided significant help. People
without hearing loss don't think it sounds good because it
isn't just a louder and filtered signal, instead it
reconstructs things working hearing systems do to make it
sound natural again to the human brain.
So like the examples of the demo filters and the 3D
machine vision system for BMW this was another case of
a comparison of the size, cost, and power requirements for
DSP and Forth chip solutions. In some cases we also had
FPGA versions and Pentium versions that all did the same
thing for additional comparisons. It was another clear
case of conventional DSP losing badly on cost and power
required to do what needed to be done.
I think a number of examples were mentioned the last time
you asked about a DSP to Forth chip comparison. The hearing
enhancement system was shown at last year's Forth day and
many details were discussed. You can always review the video
at SVFIG if you have forgotten what has been said in the past
about it.
It is true that most 'hearing aids' are simple devices with
very few transistors. They have an amplifier and filter
and may be digital but have little else. The most
sophisticated ones currently on the market have a directional
noise filter. But that doesn't help much with people who
have hearing loss.
This 'hearing enhancement system' on the other hand uses
sophisticated DSP algorithms based on cutting edge knowledge
of how human hearing and perception actually work and how
they tend to degrade with age. It took many years of
research and years to develop and implement it on a PC.
It took considerable effort to port it to the TI DSP.
The first TI system was not big enough and had to be
upgraded so something almost laptop size to handle the job.
Then the code had to be optimized and some of it recoded
in C to get it to fit on the DSP. Yet the idea is that any
solution is going to have to compete with those tiny
simple devices that need only a few transistors, are
cheap, and can run off of hearing aid batteries.
The challenge was then to port the sophisticated hearing
enhancement system to something hundreds of times smaller
and lower power, something hearing aid scale. You can't
cram a laptop, a laptop sized TI DSP board, or a 100W
specialized deep-pipeline high-power graphic processor in
your ear. You would not want to deal with a 100 Watts
of heat from a computer running in your ear either.
And it would be hard to get a Pentium, TI DSP, or PC
graphics chip to run for very long on a tiny battery.
Best Wishes
foxchip
> > Is Hearing Aid device, tens times cheaper, then anything on the market
> > not convincing enough?
>
> The average end-user price of an hearing-aid in the Netherlands is
> 450 Euro. Are you saying that using a different chip is decreasing
> that to 45 Euro?
>
> I wouldn't be surprised if it made no (financial) difference to the
> end-users at all (although one of the subcontractors for it might
> like it, depending on how *low* their added value is).
If the poor folks could find something that actually worked they
would be willing to pay to hear again. The problem is that it is
a racket that takes advantage of old people with health problems.
For some people the issue is certainly cost. But the main issue
is that one can spend thousands and get something that doesn't
help at all. What is actually needed for those people is something
with some special algorithms that are simply beyond the
computational capabilities of most cheap low-powered stuff.
> Of course, if the price really goes from 450 to 45 Euro, next year
> every major (and minor) chip manufacturer will come out with their
> own chip designs. Maybe they will only bring cost down by a factor
> of 9, but they will be packed with the kind of hi-tech algorithmic
> features that a small company can never keep up with. Let alone
> support.
>
> -marcel
According to hundreds of test subjects with actual hearing
loss the quality of the hearing enhancement system is many
times better than that of the best hearing aids they have
tried before even those costing thousands of dollars.
The problem is that most hearing aids only work for people who
don't have hearing loss. People pay a few hundred to a few
thousand and then don't use them because they don't work.
The profit margin for the companies making them and selling
them tend to be very high. Often there are expensive fitting
sessions and adjustment setting sessions that don't really do
much except provide high profits.
Best Wishes
foxchip
> I have to wonder how valuable the GreenArrays technology really is.
> There was another thread a couple weeks ago where possible applications
> for the GA chips were discussed. As I remember, nobody could think of
> any really convincing ones.
You know that two things that people can't discuss are active
litigation and projects in development. People know that those
kinds of questions can't be answered in public by the people with
the answers so they ask people who have no knowledge of the subject
and should expect to get no answers or wrong guesses. It would be
foolish to draw conclusions based on that.
My experience is that people unfamiliar with the technology will
typically write programs that are one to two orders of magnitude
bigger and slower than they need to be. People with that level
of experience or less also tend to make their estimates of how
the technology would perform based on those first programs that
they would probably write. Chuck's idea for Green Array Chips
is that it will be best to have people who understand the
technology do the programming for the people who need it.
IntellaSys offered more conventional tools for more conventional
programmers to try to open the programming up to more people.
When I came to Chuck in 1990 with the idea of parallel Forth
chips there some people who had been doing parallel programming
in Forth. But for the most part the folks at the Parallel
Processing Connection considered UNIX to be a toy OS as
parallel processing was for the big boys with big toys usually
paid for by government programs. Since they thought that
UNIX was a toy OS they really didn't get the idea of a Forth
OS or that a Forth machine could be a lot simpler, smaller,
cheaper, and lower power than a machine with what is needed
for C. (And they considered C a toy language too.) And
people who programmed in Forth tended to not think in terms
of parallel processing.
So the folks doing parallel processing didn't understand
how we could fit so much in so little space and the
people doing linear processing didn't understand that
parallel processing isn't that hard. Those problems still
exist.
One thing I enjoy doing is describing programs to people
and then asking them for an estimate of what it would
take for them to code it. I think lots of programmers do
that. Hopefully people use something appropriate for a
job and know it is much more productive for that job than
other things.
Now twenty years later some things have changed. There are
many more people doing parallel programming in many languages
on many different platforms including DSP and clusters of
microcontrollers. But many Forth programmers still mostly
think serially and some still think about coding for
processors like 6502. Most discussions in c.l.f are
rehashes of research from the 80s. And there are still
many people who don't get things much better than they
did in 1990 and lots of people who think of Forth as
what they remember from the 70s.
Best Wishes
Andrew Haley
This sounds like a general-purpose arguemnt against any small firm
introducing innovative technology.
Andrew.
Marcel Hendrix
> Marcel Hendrix <m...@iae.nl> wrote:
>> forther <for...@gmail.com> writes Re: Moore versus TPL: The bomb has burst
>>> On Oct 2, 1:30 pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>>>> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
[..]
>>> Is Hearing Aid device, tens times cheaper, then anything on the market
>>> not convincing enough?
>> The average end-user price of an hearing-aid in the Netherlands is
>> 450 Euro. Are you saying that using a different chip is decreasing
>> that to 45 Euro?
[..]
> This sounds like a general-purpose arguemnt against any small firm
> introducing innovative technology.
Are there examples of small firms succeeding with innovative technology
in a huge *established* market -- by cutting the prices ten-fold?
I may of course be wrong in assuming that hearing-aids are a "huge market".
In the Netherlands there are many specialized shops selling these devices,
and they are heavily subsidized. I imagine the cost of the aid is dwarfed
by the overhead of these shops (advice, measurements, adjustment, service).
Also, there should be a large 'industrial design' component here -- people
don't like to wear visible apparatus. Nowadays the stuff is implanted or
transmits through the skin directly, making medical assistance and safety
standards necessary. So how could the price of the chip alone bring all
this overhead down to 10% of what it was before (the shops would simply
ignore it :-)
Now, I can imagine that the firms actually making the tiny bit of hardware
needed (for say 1 Euro) are interested in either paying only 10 cents for
the main chip, or having 10 times the performance of their competitors. I
could also be made to believe that the market for 10 cents/piece is
too small for any of the big IC manufacturers. But it looks like a shaky
deal for a small innovative firm. At best, it would result in better
hearing-aids, not in cheaper ones.
Of course, the argument could be that present hearing-aids are 10 times too
expensive for their actual performance, so with a good chip, average price
of the remaining ones would go down by a factor of 10. That however, would
require me to believe that the regulatory boards (at least in the Netherlands)
are full of technical nit-wits, the shops are led by snake-oil salesmen, and
good engineers never need any hearing-aid.
-marcel
Paul E. Bennett
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>> Chuck Moore has filed a suit against TPL, at last.
>> Read more at http://www.colorforth.com/blog.htm
>> I wish Chuck and GreenArrays success at this endeavour.
>> The outcome will be hopefully that the awesome GreenArrays technology can
>> be developed speedily and will become available to mankind,
>> instead of staying in the hands of patent sharks.
>
> The minute or two that I spent looking at the filing wasn't enough to
> let me understand what the underlying dispute was, but it looks
> unpleasant and it's always unfortunate when anything has to come to
> that.
I read the whole thing and am amazed that things were allowed to get that
bad.
> I have to wonder how valuable the GreenArrays technology really is.
> There was another thread a couple weeks ago where possible applications
> for the GA chips were discussed. As I remember, nobody could think of
> any really convincing ones. So I get the impression that the GA guys
> did some things that were pretty nifty from a technical point of view,
> but got mixed up with the wrong crowd on the business and legal side.
I have several project ideas that would occupy chips from the whole range
(GA4 to GA144) but until they sort out the wrangle and can concentrate on
producing real chips dependably then there is little point progressing any
of them. All the applications require low power devices. I am not discussing
any of them here though.
--
********************************************************************
Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
John Passaniti
wrote:
> I read the whole thing and am amazed that things were
> allowed to get that bad.
I can... at least for some of it.
Most of the companies I've worked for over the years-- directly or
indirectly-- are electronics manufacturers. And if there is one thing
I've learned by being part of those companies is that it takes a lot
of wildly different skills to run a company-- skills most engineers
don't have. Every now and then, I'll be in a company meeting where
something that seems trivial and stupid to me will be brought up.
I'll roll my eyes, look across the table to my fellow engineers, and
we'll share an unspoken "this is dumb" moment. Then, full of
ourselves, we'll continue to listen and hear from others about the
complex interconnected web of things we didn't consider. And as we
build in our heads the directed graph of those interconnections, we
start to see relationships between things we never considered before.
This is usually followed by a new-found respect for an aspect of the
business we under-appreciated.
If I was to start a business, I would do so by hiring others who can
do the things I can't-- or things I have no interest in doing. I'm
not a lawyer, so I would hire one. I'm a terrible salesperson, so I
would hire one. Dealing with supply chain management makes me angry,
so someone else would do that. And once you start to have more than a
few people in the company, you need a HR person, and there is no way
in hell that I'm ever going to deal with that insanity. And so in the
end, I would be dependent on others to do what they are presumably
good at.
There is another model. Where I last worked, my boss was an engineer
who started the company. He had an entrepreneurial interest and over
time, learned how to take on the various responsibilities needed.
Now, he's quite good at it, but the amount of time he spends doing any
actual engineering is nearly zero. And that's something he's
lamented.
I have never met Charles Moore and have no idea what skills outside
software and hardware engineering he has. But if he's like most
engineers, he probably prefers to surround himself with experts in the
various aspects of business he would rather not waste time on. And
that means he's going to be depending on others to do what they say,
deliver their best, and honestly report back to him the state of the
company.
Hindsight is always 20/20, and seeing where things started to go wrong
is obvious in retrospect. It wouldn't surprise me if Charles Moore
now looks back at certain past events that at the time he thought were
insignificant and now sees them a big huge flashing neon signs saying
"DANGER!" But at the time, he trusted those people, and thought they
were working in the best interest of the company.
> I have several project ideas that would occupy chips from
> the whole range (GA4 to GA144) but until they sort out the
> wrangle and can concentrate on producing real chips
> dependably then there is little point progressing any of
> them. All the applications require low power devices. I am
> not discussing any of them here though.
Unfortunately, your product ideas probably don't matter. Quoting from
Jeff Fox:
"Chuck's idea for Green Array Chips is that
it will be best to have people who
understand the technology do the programming
for the people who need it."
Well, that's one model. But in order to be profitable, it means that
GreenArrays will have to focus only on very high-volume applications
because the engineering resources of GreenArrays become the
bottleneck. You might have dozens of applications for the chips in
the pipeline, but if GreenArrays is doing the development, that is
going to be a hard limit on how many of those applications get
implemented with their chips. So the only applications that will be
developed are those that have a huge payoff and can fund and sustain
growth.
And then you have another problem. Traditionally, those high-volume
applications are the ones where the cost of developing an ASIC makes
sense. So taking these hearing aids as an example, whoever has the
idea will need to question if a generalized GreenArrays chip makes
sense over a chip specifically designed for the application. It may
be that a GreenArrays chip would be used initially to get the product
out to market quickly. But at some point after the product has proven
to be successful, some engineer is going to start thinking about
system costs. He'll notice that the software is now stable and is
going to question the cost of loading the code from an external ROM.
And then he'll ask why now that things are stable, why can't we hard-
code the DSP algorithms and make a chip that does *just* that. And at
that point, they don't need the GreenArrays chip anymore. Just create
an ASIC that hard codes the algorithm and has some non-volatile
storage to store coefficients related to the individual's particular
flavor of hearing loss. Once past the NRE costs of the ASIC, they
would have silicon that is simpler, smaller, and cheaper than the
system cost of the GreenArray's equivalent.
Now, maybe it doesn't matter. Maybe at the point where making a
dedicated ASIC makes sense, GreenArrays has made enough money from the
product that they don't care and they just move on to the next big
project. And hopefully, that project requires a reprogrammable
platform so that an ASIC down the road doesn't make sense.
I guess we'll see.
Paul Rubin
> You know that two things that people can't discuss are active
> litigation and projects in development. People know that those
> kinds of questions can't be answered in public by the people with
> the answers so they ask people who have no knowledge of the subject
> and should expect to get no answers or wrong guesses. It would be
> foolish to draw conclusions based on that.
I certainly agree with you about the litigation, which I didn't ask
about. Usually though, when a company releases a new chip or other
product, they have some application notes or other concrete suggestions
of how it can be used, or in many cases (chip improves straightforwardly
on existing ones) the uses are obvious. A dialogue like
Green Arrays: We have these cool new chips!
Prospective customer: Great! What are they good for?
GA: We can't tell you!
sounds like a good way to doom a business.
> One thing I enjoy doing is describing programs to people and then
> asking them for an estimate of what it would take for them to code it.
OK, I'd be interested in seeing some descriptions like that so I can try
making my own estimates. Keep in mind that I'm not a small-processor
embedded developer of course.
> My experience is that people unfamiliar with the technology will
> typically write programs that are one to two orders of magnitude
> bigger and slower than they need to be.
At least in the DSP and numerics fields, my experience is that it's more
about mathematics than technology, and experts in those areas never miss
a trick.
> People with that level of experience or less also tend to make their
> estimates of how the technology would perform based on those first
> programs that they would probably write. Chuck's idea for Green Array
> Chips is that it will be best to have people who understand the
> technology do the programming for the people who need it.
> IntellaSys offered more conventional tools for more conventional
> programmers to try to open the programming up to more people.
If you look at the sort of comparable area of stream processors, there
are tons of scientific papers and sites like gpgpu.org, where
applications are discussed, benchmarks compared, etc. Was there
anything comparable for IntellaSys products? What interesting things
were done with them?
> Most discussions in c.l.f are rehashes of research from the 80s. And
> there are still many people who don't get things much better than
> they did in 1990 and lots of people who think of Forth as what they
> remember from the 70s.
I notice the same thing about clf, and wonder if it's the same way on
the hardware side. I admire Chuck Moore as an innovator and I hope he's
doing things that make him happy and prosperous. But my impression of
the Forth chip industry is that it released a succession of products
that found their way into some niche applications without ever really
establishing dominance anywhere.
Paul Rubin
> I think a number of examples were mentioned the last time
> you asked about a DSP to Forth chip comparison. The hearing
> enhancement system was shown at last year's Forth day and
> many details were discussed. You can always review the video
> at SVFIG if you have forgotten what has been said in the past
> about it.
I remember some suggestions from the earlier discussion and don't
remember the hearing aid being mentioned at that time. I did find the
video and am downloading it now. I'll try to watch it in the next few
days. Going just by your description, it sounds like you've got some
good algorithms, but I'm perplexed as to how the GA chip beats a
conventional DSP for running them.
Paul Rubin
> I have several project ideas that would occupy chips from the whole range
> (GA4 to GA144) but until they sort out the wrangle and can concentrate on
> producing real chips dependably then there is little point progressing any
> of them. All the applications require low power devices. I am not discussing
> any of them here though.
That's pretty cool and I hope that the day eventually comes when you can
tell us more. Don't get me wrong, I wish GA all the success in the
world, I'm just having a hard time seeing the path to it.
Here is a page with some specs of some low power TI DSP's from a couple
of years ago, that seem to beat the GA chips in energy per multiply-add,
even though the GA chips aren't yet released:
http://www.insidedsp.com/tabid/64/articleType/ArticleView/articleId/269/Default.aspx
foxchip
> foxchip <f...@ultratechnology.com> writes:
> > I think a number of examples were mentioned the last time
> > you asked about a DSP to Forth chip comparison. The hearing
> > enhancement system was shown at last year's Forth day and
> > many details were discussed. You can always review the video
> > at SVFIG if you have forgotten what has been said in the past
> > about it.
>
> I remember some suggestions from the earlier discussion and don't
> remember the hearing aid being mentioned at that time.
I know it was mentioned in reviews of last year's Forth day.
But anything interesting on Forth day will not be discussed
in c.l.f.
> I did find the
> video and am downloading it now. I'll try to watch it in the next few
> days. Going just by your description, it sounds like you've got some
> good algorithms, but I'm perplexed as to how the GA chip beats a
> conventional DSP for running them.
That question involves a lot of hardware and software details.
The simple answer is that the designers say we need this many
MIPs to do this in real time and the hardware guys say that
the chip from TI that can do that is this big and we said we
thought we could do it with a much smaller and lower power chip.
When I was at MIT in the summer of 1978 Patrick Dennis gave
us a lecture on advanced machine architecture. We were
studying sound synthesis at the time.
He stated that for certain DSP tasks data-flow architecture
was a hundred times as efficient on a gate or transistor basis
than a conventional design storing programs and data in random
access memory. Our processors are small enough that they can
often be used in a data-flow mode where programs and data
circulate and get much more parallel execution than you could
with fewer bigger processors.
There are lots of trade secrets in the circuit design. The
tools used to create those DSP are detuned. They don't understand
how our circuits can work. There are lots of trade secrets in
the layout. The overall design needs half the stages for
computation as a conventional design. Programs are extremely
compact with many parallel operations just being a simple
read or write operation to a given processor. There is no
big honking system clock draining power and making noise.
They don't need complex and expensive cache and pipelines
because the internal computation model for stacks is simple.
Most people just think of multiplication when they think
of parallel processing. We don't since we profiled programs
and found that most of the multiplication that other people
were doing wasn't needed in things we saw. So we profiled
the hardware to match the profile of actual software and
not software for grand-challenge machines but for small
embedded apps and parallel embedded apps.
Multiplication is one of the weakest things, still 144
one-bit multipliers are about the same as nine word
multipliers on chip so in that respect it isn't all
that different than a DSP. The main differences are that
the parallelism is very simple, the software is very
compact parallel MISC Forth, the grain of parallelism
is finer, and the circuits are very low power.
Best Wishes
Paul E. Bennett
> "Paul E. Bennett" <Paul_E....@topmail.co.uk> writes:
>> I have several project ideas that would occupy chips from the whole range
>> (GA4 to GA144) but until they sort out the wrangle and can concentrate on
>> producing real chips dependably then there is little point progressing
>> any of them. All the applications require low power devices. I am not
>> discussing any of them here though.
The multi-core aspects of the Intellasys and GA chips with low power
requirements works for all of the ideas I have. Looking at many of the
other multi-core processors does not fill one with the same hope that Chucks
designs do (most suck too much power and give one horrendous headaches in
moving the data when one needs to). I can afford to wait at the moment.
forther
> Here is a page with some specs of some low power TI DSP's from a
couple
> of years ago, that seem to beat the GA chips in energy per multiply-add,
> even though the GA chips aren't yet released:
>
Not all the algorithms are multiply-add centric.
Albert van der Horst
Paul E. Bennett <Paul_E....@topmail.co.uk> wrote:
>Paul Rubin wrote:
>
>> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>>> Chuck Moore has filed a suit against TPL, at last.
>>> Read more at http://www.colorforth.com/blog.htm
>>> I wish Chuck and GreenArrays success at this endeavour.
>>> The outcome will be hopefully that the awesome GreenArrays technology can
>>> be developed speedily and will become available to mankind,
>>> instead of staying in the hands of patent sharks.
>>
>> The minute or two that I spent looking at the filing wasn't enough to
>> let me understand what the underlying dispute was, but it looks
>> unpleasant and it's always unfortunate when anything has to come to
>> that.
>
>I read the whole thing and am amazed that things were allowed to get that
>bad.
There is an advantage to this. The main issue is a lawyer who advises
a client about a contract between the client and ... himself,
being deceitful about it, actually lying about the main point of the
contract. Now in view of later conduct a jury will have an easier
time to understand and believe this.
[Disclaimer, my knowledge of US law are based on TV series like
Law and Order mainly.]
>
>--
>Paul E. Bennett...............<email://Paul_E....@topmail.co.uk>
Groetjes Albert
Albert van der Horst
A single marketing advantage can tip scales. If the GA chip has
a battery change once in ten years instead of every few weeks, that
could result in *all* hearing aid going over to a the GA chip,
even without any price differential. marketing people are dying to
find an edge over competitors.
I don't think that the hearing aid example should be beaten
to death. It shows me that there are markets where the GA chip
could succeed, without proving that the hearing aid market would
be that success.
John Passaniti
wrote:
> [Disclaimer, my knowledge of US law are based on TV
> series like Law and Order mainly.]
You know what I hate most about Law and Order and the various spin-
offs? The backing music. Mark Snow should be tied to a chair and be
forced to listen to his own chord washes for hours.
As you know from Law and Order, there is often a twist. The people
who you think are innocent sometimes turn out to be guilty-- or at
least have been partially responsible-- and vice versa. I know it
will be complete heresy to even state this here, but has the other
side in this case made any public filings, and if so, what defense do
they give?
rickman
> forther <fort...@gmail.com> writes Re: Moore versus TPL: The bomb has burst
I have often wondered why hearing aids cost as much as they do. We
all know that the components used only add up to a few dollars (or
euros). A hearing aid certainly costs no more than a cell phone and
should cost much, much less.
I have been looking at a processor actually targeted to hearing aids.
TI and ADI both make these devices with dual delta-sigma ADC/DAC on
board with a DSP. Low power and small size would make these parts
ideal for hearing aids. I think they are under $10 in quantity. So
how can a hearing aid cost be part driven? It has to be other factors
such as custom fitting and the fact that it is a medical device.
Rick
Wayne
> I have often wondered why hearing aids cost as much as they do. We
> all know that the components used only add up to a few dollars (or
> euros). A hearing aid certainly costs no more than a cell phone and
> should cost much, much less.
>
> I have been looking at a processor actually targeted to hearing aids.
> TI and ADI both make these devices with dual delta-sigma ADC/DAC on
> board with a DSP. Low power and small size would make these parts
> ideal for hearing aids. I think they are under $10 in quantity. So
> how can a hearing aid cost be part driven? It has to be other factors
> such as custom fitting and the fact that it is a medical device.
>
> Rick
That's right, I thought I head about hearing aid chips years ago?
--
Richard Owlett
NO!
gullible &/or ignorant users
incompetent &/or unethical prescribers/providers
Back when I was only in my mid 50's, I had noticed declining
hearing.
Now I've had a severe loss in one ear since multiple ear
infections about age 6. As a child/preteen I had regular hearing
exams. I've often described the response plots as resembling a
"picket fence". In my early 30's a friend prevailed on me to have
a detailed exam. There was a respected major medical center
available. I had many tests - including a bone conduction test.
Resulting diagnosis was hearing loss primarily due to nerve
damage and that a hearing aid for that ear would be unlikely to
be of any benefit. I saw the plots and they matched what I'd seen
for decades.
So ~15+ years later I tell my primary care physician that I think
my hearing should be checked. I'm referred to local medical
center in boonies of SW MO. I give the !#$*#$!&^ tech my medical
history INCLUDING the fact I've had hearing problems since a
child and that as an adult I had been diagnosed has having "nerve
deafness". I got the equivalent of a "screening exam" rather than
a detailed exam. Her reaction was to try to convince me to go for
an MRI to find the *RAPIDLY GROWING TUMOR CAUSING MY _SUDDEN_
HEARING LOSS*. "SUDDEN LOSS"???? Her test points were too widely
spaced to see what were strange about me and gave a nice smooth
curve. Besides which I'd had a similar envelope for almost a half
century. That's "sudden"?????
So a few years ago, the music director at church got hearing
aids. He liked the results. I asked him where. I contacted them
and asked what hearing tests they would do. They REFUSED to tell
me. Guess where I didn't go.
The local ads sound like "Snake Oil".
Wayne
wrote:
> There was another thread a couple weeks ago where possible applications
> for the GA chips were discussed.
Which thread was this I can't seem to find one?
> As I remember, nobody could think of
> any really convincing ones.
I've suggest a few, in line with volume CE electronics in previous
threads. The bigger problem is having reference platform of software and
hardware ready to go, to streamline implementation for people, which
really means Open Sourced solutions from GA private developers at this
stage due to the budget constraints. The market is really ready made
integrated components for many things (this is essentially what the
hearing aid is, and probably what they are aiming at). There is a limited
market outside of this, except if you can displace your PLD and discrete
component competitors, or as conditioning circuits on boards to displace
analogue electronics (which Misc isn't exactly designed for).
However, I was going to post an idea to displace integrated components
with with non set customizable components architecture, that would greatly
suite Misc.
I can't seem to find mailing lists for GA devices, where are they now?
Somebody told me sometime ago but I can't find that post.
Wayne
wrote:
> In 2007 I traveled to Austria to help start a project to port
> a sophisticated hearing enhancement system to Forth hardware.
> This was not your typical hearing aid with an amplifier and
> filter but a very complex non-intuitive algorithm for tricking
> damaged human hearing into being able to recognize things.
> Regular hearing aids, even those costing thousands of dollars,
> really only sound good to people without hearing loss and
> people with actual hearing loss tend to try them out then
> stop using them.
>
> The hearing enhancement system was first developed on a PC.
> Then with much effort it was ported to a TI DSP system that
> was a little smaller than a laptop, but it was still a little
> like wearing a laptop on your chest. But people with hearing
> loss reported that it provided significant help. People
> without hearing loss don't think it sounds good because it
> isn't just a louder and filtered signal, instead it
> reconstructs things working hearing systems do to make it
> sound natural again to the human brain.
I am interested. This is the preferred way, like the simple fact that the
brain can perceive base frequencies from the harmonic frequencies of those
frequencies (in the 80's, I think Phillips patented this for sound systems
that simulated base with frequencies less able to penetrate through walls
of apartments). I am interested in custom compensating for hearing loss
at particular frequencies, for person top person, by shifting those
frequencies (any harmonic advantage also an advantage) or the whole
spectrum. There was also a device in the 80's that allowed completely
deaf people to hear, that moved the frequencies to a second primitive
ultrasonic hearing mechanism (I think they stated as reptilian like). I
think it may have been behind the ear. Such things might extend battery
life and reduce complexity further.
foxchip
> What are they good for?
What was actually said was something more like:
They have very quick, very low power, microcontroller
and parallel processing technology. It is much quicker
than designs that use interrupts and less parallelism.
The technology takes advantage of Forth in its
hardware and software.
Benchmarks and many examples taking advantage of the
low power and fast response offered by the technology
have been shown and explained. They have shown
comparisons on problems that decompose to a fine
grain of parallelism easily and those that don't such
as those that require random access to very large
datasets.
For generic microcontroller use they have shown many
examples to demonstrate realtime performance and
event response. The use of digital software techniques
applied to the on-chip analog I/O processors to get
20-bit output at 96khz or I/O into the high megahertz
range have been shown and explained. DSP examples
have included generic filters, cordics, dft, fft,
soft-radio, wireless speakers, fm and waveguide
synthesis and other things. Other well known and
common fairly complex things like decoding H-264
encoded video were described. A compatible version
of the 3D automotive vision system that you see in
TV commercials was implemented and described. BMW
research provided the published comparisons for
the vision system comparison and developers
provided the comparisons to conventional
microcontroller and DSP chip alternatives. What
were provided were comparisons of power usage,
cost and performance over quite a range of
embedded applications.
They have been very open and answered all the
questions in forums and at many public presentations
for years and worked with a number of clients.
The technology is really good if you like
software written in Forth. Any more questions
about it?
Prospective customer: Great! What are they good for?
People are told that low-power, low-cost embedded
solutions are the target. Especially those that may be
out of your range now with other technologies.
If you have a problem to solve or an idea for use
then related questions can probably be answered.
If you can't ask them in public then don't. They
can't show you all the code that they have done or
that other people have or expose details of other
customer's plans where they are bound by
non-disclosure agreements.
If one filters out enough of the detail above
one could have a summary that reads:
"We have something cool."
"What's it good for?"
"We can't tell you."
That version makes a good story for people with ADD.
Best Wishes
foxchip
> > asking them for an estimate of what it would take for them to code it.
>
> OK, I'd be interested in seeing some descriptions like that so I can try
> making my own estimates.
>
> Keep in mind that I'm not a small-processor
> embedded developer of course.
I often try to describe things in generic terms so that
programmers most familiar with desktop computing can say
that they can imagine writing a program that does it.
Power is applied, software is launched from FLASH or ROM,
an OS gets loaded, a GUI gets launched. The user launches
a program to do such and such on this or that network.
It could be done on a PC or an embedded computer and
it could have been written in many computer languages.
Here's four:
One I asked about fifteen years ago was what do you need
for a program to put a computer into a low power sleep mode
so that when it sees a message arrive on a network it
will wake up to full speed, read the message and
execute it. How large is the program? (what is the rom/
flash/ram footprint of all the code needed?) What is
the latency between a message arriving and coming
out of low power mode to execute the message? What is
the cost of the system in transistors?
The most recently discussed in c.l.f was a metacompiler
for an ANS Forth system that was mentioned. How big
and complex do they need to be?
The most recently published one was a fairly simple
program, a simple loader that uses a single gpio pin
and a connection to other computers on a net. It goes
into a low power mode waiting for messages on the pin
for the net. It wakes up and processes a message that
arrived on a pin or from the network and executes it,
or loads it, or routes it out the program of variable
size. It can use any form of single-wire self-clocking
serial protocol on the single gpio pin used as needed.
But the protocol must be one that can also be written
by the same computer on a gpio pin.
It is a simple thing that should be pretty easy to
write in any language. It could be made to run on a
huge variety of hardware. The size of the source,
the object code, the computer to run it and the
speed it will run will vary a lot so estimates
vary.
the aha desktop system is a Forth system based on
ideas that challenge many of the assumptions in
Forth in the seventies and still present in ANS. Do
most of the words used in Forth need to be in the
name dictionary? Does a Forth compiler always
need a dictionary? Does a metacompiler need to be
pretty complex? How much room do you need for
boot code, an OS with desktop GUI w/ multiple
fonts, effects, graphics, drivers for the mouse,
rtc, video, network, ports, windows, widgets,
icons, and a Forth compiler that can compile
several hundred millions Forth source words
per second? How expensive is the processor you
need to run it?
Best Wishes
foxchip
> about mathematics than technology, and experts in those areas never miss
> a trick.
I think that the hearing enhancement system was a good
example as it was about anatomical research first and
mathematics later. Porting the knowledge of how
the implementation worked from matlab to an actual DSP target
proved to be quite difficult as it involved a whole set of
techniques that were unfamiliar to the researchers. The app,
matlab, DSP chip programming, and parallel Forth
programming all proved to be different domains of
expertise.
Porting again to parallel Forth involved another set of
techniques completely unfamiliar to the first sets of
experts. That's when Dr. Monvelishsky took over the
technical work.
With Green Arrays exposing colorforth based tools to the
public instead of ascii and ANSI based Forth I think it
makes for even more domain of expertise problems for
more people only familiar with older stuff or other tools.
> > lots of people who think of Forth as what they remember
> > it from the 70s.
>
> I notice the same thing about clf, and wonder if it's the same way on
> the hardware side.
I don't think so for Chuck but for some people yes.
Working with hardware can take you further away from
conventional black-box tools and more toward Forth
methods or more deeply into trusting conventionalism
and old standards and ways.
Chuck said he has been able to rethink Forth software
a number of times since he left Forth Inc. He says
OKAD II is the best example he has seen of Forth since
the start as he has learned and made improvements along
the way. Lots of things in it are different in it than
in Forth from the seventies or eighties.
Best Wishes
Wayne
<alb...@spenarnc.xs4all.nl> wrote:
> Apparently the business "partners" of Moore have collected (and
> squandered) some $300 million in royalties for the MMP portfolio.
> Doesn't sound like unconvincing technology. But I must say that I have
> a hard time understanding what is going on, in that respect.
I was telling somebody yesterday, basically, if you want an idea of which
professions are earning the most margin, take a look for the section with
most costly advertisements in the yellow pages. Not full proof by any
means, but what is owned and spent over time is a way to track where money
is going. Of, course, it doesn't mean that a party isn't innocent,
especially if they have suitably low, valid, and time validated, receipts
for validated amounts. The money could have been absorbed in valid
business expenses, under-performing business ventures, and the Global
Economic Crises.
Wayne
wrote:
> It says the GA chip does a 17x17 bit fractional
> multiply with about 450 pJ of energy.
>
> Let's try the same calculation for a current semi-mass-market graphics
> coprocessor (NVidia GTX 480M Mobile Fermi):
>
> http://www.anandtech.com/show/3740/nvidia-announces-gtx-480m
>
> 100 watts power consumption, 598 gigaflops
> = (1e2 joules/sec) / (5.98e11 ops/sec)
> = 1.72e-10 joules/op = 172 pJ / op.
> I never had the impression that there was any magical process technology
> in the GA chips, just clever and unique (Forth-oriented) CPU
> architecture. But basic ALU operations are very well studied by now.
> So I don't see how a part made on a 180 nm process can possibly beat a
> part made on a 45nm or even 32nm process no matter how clever it is.
But Paul, what happens when they move the chip from the 180nm process to a
sub 45nm process that they use in GPU's?
Wayne
<alb...@spenarnc.xs4all.nl> wrote:
> [Disclaimer, my knowledge of US law are based on TV series like
> Law and Order mainly.]
;) The best till last, good on you Albert, that was a good one. As a
fictional joke, my knowledge of American police work is also entirely
based on Miami Vice ;) .
forther
> I have been looking at a processor actually targeted to hearing aids.
> TI and ADI both make these devices with dual delta-sigma ADC/DAC on
> board with a DSP. Low power and small size would make these parts
> ideal for hearing aids.
The algoritm we use requires ~3200 mips. Do these devices provide that
kind of performance?
Stephen Pelc
<alb...@spenarnc.xs4all.nl> wrote:
>Chuck Moore has filed a suit against TPL, at last.
>
>Read more at http://www.colorforth.com/blog.htm
There are some interesting links at:
http://www.eetimes.com/electronics-news/4209274/CPU-technologist-sues-patent-pool-firms?cid=NL_EETimesDaily
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
rickman
Algorithms for what?
Rick
forther
Hearing aids.
Brad
>
> NO!
> gullible &/or ignorant users
> incompetent &/or unethical prescribers/providers
>
that of pharmaceuticals) is due to monopolies protected by the
regulatory agencies. But I digress.
There's no reason you can't develop an open-source hearing test using
Forth and a good pair of headphones.
There are open source hardware projects on the net too, like openmoko
the cell phone. Maybe there should be an open source hearing aid
project.
-Brad
Brad
Preemphasis. Consider 10G Ethernet signals traveling across a big PCB
backplane. The high frequency components of the signal fade pretty
quickly with FR-4 material. But if the transmitter boosts the high
frequency components using preemphasis, by the time the signal gets to
the receiver it looks fairly normal. Not as high in amplitude, but
with a good eye.
Same thing with hearing aids. The loss isn't flat across the spectrum,
so you emphasize the lossy frequencies. But maybe I'm over
simplifying. I'm thinking FFT / IFFT but there are other ways. Also, a
C18 MISC MIPS isn't the same as a TI/ADI MIPS. Maybe the cost problem
is a case of waiting for DSPs to reach an economical process node. If
so, algorithms now, hardware later.
-Brad
rickman
Yes, I think the algorithms used by Jeff's associates are much more
complex than that. I'm not sure who forther is, but I guess he also
is in the same boat. 3200 MIPS is a lot of pre-emphasis.
I don't know of any devices that provide 3200 MIPS. TI has their high
end DSPs with 8 processors executing 8 instruction streams. But if
you look at what they do in a typical DSP application, they are not
that much different than a dual core DSP chip. For example, a FIR
filter has to fetch a data word and a coefficient for each sample in
the buffer when calculating a new output sample. That is two memory
operations and takes two processors of the 8 in the C6xxx family. In
the C5xxx family it is done by the addressing hardware which is not
counted as a processor. It has been awhile since I've looked at this
chip, but there are a number of similar processor functions that are
done in hardware in any other DSP. I rated the 8 processor C6xxx
devices as having only slightly more MIPS than a dual DSP with the
same clock rate. If you count these processors as MIPS in your
algorithm, I expect this algorithm can be done on a different DSP with
a lot lower MIPS rating, 3x to 4x.
Both TI and ADI have devices for hearing aids. Simply programmed DSP
between ADC and DAC. In fact, the TI part I was just looking at has
two "miniDSPs", one for each end, input and output. They are tailored
to performing just this sort of processing or actually filtering. I
don't think they will provide anywhere near 3200 MIPS. But they would
work well as pre-emphasis devices.
Rick
foxchip
> Preemphasis. Consider 10G Ethernet signals traveling across a big PCB
> backplane. The high frequency components of the signal fade pretty
> quickly with FR-4 material. But if the transmitter boosts the high
> frequency components using preemphasis, by the time the signal gets to
> the receiver it looks fairly normal. Not as high in amplitude, but
> with a good eye.
>
> Same thing with hearing aids. The loss isn't flat across the spectrum,
> so you emphasize the lossy frequencies. But maybe I'm over
> simplifying. I'm thinking FFT / IFFT but there are other ways.
The hearing aid racket is based on the idea that the problem
is a simply a different frequency domain filter in an aging
ear that can reverse by nothing more than an inverse filter.
That is what the hearing aids that don't work do. It is like
a person with good hearing adjusting the volume and having an
equalizer.
Hearing loss if far more complex than just lossy bands in
the spectrum! There may be a problem with noisy bands inside
the ear but it isn't in the sound coming in so can't be
filtered out. There was some explanation of the technical
details of hearing loss in the hearing enhancement system
presentation. It gives a good sense of what might be
required for actual restoration.
Since a volume control and equalizer help a sound system
sound better to people with good hearing people with
hearing loss are duped into thinking that hearing loss
can be improved the same way.
More sophisticated hearing aids today have a directional
noise filter that will track and filter out some of
moving noise sources in the environment. That helps some
but requires more processing than just an amplifier and
equalizer. The algorithms used for that usually require
more memory too.
One could do an open source hearing aid of the first
type of device that doesn't help, or even of the slightly
improved versions with directional noise filters because
the algorithms you need have been published.
The hearing enhance project is very different as it is
far more sophisticated. It does restoration by
modifying the sound so a damaged ear sounds more
like a normal ear to the brain. It doesn't sound
good to a person without hearing loss. All the
details of hearing loss and the algorithms the
scientists used to restore properties to the sound
are not public stuff. The idea was to combine new and
revolutionary algorithms that actually work with
hardware that can deliver them in real-time and with
little power.
Common hearing aid chips were designed to make
the first type of hearing aid and compete with
cheap analog hearing aids. They don't have the
computing power to do hearing restoration. Things
with the computing power were too big or too
power hungry for hearing aid batteries at first.
> Also, a C18 MISC MIPS isn't the same as a TI/ADI MIPS.
> Maybe the cost problem is a case of waiting for DSPs to
> reach an economical process node.
I think that cost isn't the big issue unless you want
very high volume with low margins. There are fifty
million people in America alone who need some sort of
hearing enhancement. Baby boomers can blame rock and
roll concerts. X and Y gen can blame earbuds that we
could hear from the other side of the subway. Some
people pay thousands of dollars but the hearing aids
available are not very sophisticated and usually don't
help much with the most common forms of hearing loss.
> If so, algorithms now, hardware later.
Exactly. At first the algorithms required were well
out of the range of low-power hearing aid processors
and the things with thousands of mips were too big
or too power hungry to fit.
First you find the scientists with the algorithms then
you find hardware that can go into a device. Then
comes the engineering work, etc. etc.
Best Wishes
Brad
> The hearing enhance project is very different as it is
> far more sophisticated. It does restoration by
> modifying the sound so a damaged ear sounds more
> like a normal ear to the brain. It doesn't sound
> good to a person without hearing loss. All the
> details of hearing loss and the algorithms the
> scientists used to restore properties to the sound
> are not public stuff. The idea was to combine new and
> revolutionary algorithms that actually work with
> hardware that can deliver them in real-time and with
> little power.
>
-Brad
foxchip
> Maybe you should apply for a NIH SBIR grant. This year it's PA-10-050.
It's not my algorithm, project, or program.
I had a little involvement a long time ago.
But thanks anyway.
Best Wishes
jmdrake
> Unfortunately, your product ideas probably don't matter. Quoting from
> Jeff Fox:
>
> "Chuck's idea for Green Array Chips is that
> it will be best to have people who
> understand the technology do the programming
> for the people who need it."
>
> Well, that's one model. But in order to be profitable, it means that
> GreenArrays will have to focus only on very high-volume applications
> because the engineering resources of GreenArrays become the
> bottleneck. You might have dozens of applications for the chips in
> the pipeline, but if GreenArrays is doing the development, that is
> going to be a hard limit on how many of those applications get
> implemented with their chips. So the only applications that will be
> developed are those that have a huge payoff and can fund and sustain
> growth.
Well I guess that's one interpretation of what Jeff said, but I don't
think it's accurate. Here's a part of the quote you left out:
"IntellaSys offered more conventional tools for more conventional
programmers to try to open the programming up to more people."
IntellaSys released tools based on ANS Forth. GreenArrays released
tools based on ColorForth. Pentium ColorForth is, of course, closer
to the the GA18 instruction set then is ANS Forth. So it seems the
idea is to try to get people more used to the ColorForth / machine
Forth paradigm rather than doing everything in house at GreenArrays.
John Passaniti
> Well I guess that's one interpretation of what Jeff said,
> but I don't think it's accurate. Here's a part of the
> quote you left out:
>
> "IntellaSys offered more conventional tools for more
> conventional programmers to try to open the programming
> up to more people."
But we're not talking about IntellaSys. We're talking about
GreenArrays.
What ultimately matters isn't Jeff's words or my interpretation. At
the end of the day, if GreenArrays wants people outside the company to
do significant development with their chips, they will have to provide
not just the tools, but a range of support services for developers
ranging from experienced to novice. They are going to have to provide
evaluation kits, reference designs, application notes, discussion
forums, and ideally IP (common peripherals, algorithms, protocols, and
so on). I doubt most experienced software and hardware developers
would have any problem slapping the chips down on a board, wiring up
some simple I/O, and getting a "hello world" application up and
running. But beyond that, programming a GreenArrays chip isn't just
writing code as with a conventional processor. It's also choosing the
physical processor to run that code, the messaging between processors,
and the partitioning of an application across groups of processors.
Those are for most developers new skills, and so you would expect to
see documentation that takes a complete, non-trivial application and
shows step-by-step the thought process used to break it down as
cooperative processes and implement it on the chip. I'm not expecting
a "GreenArrays For Dummies" hand-holding. But I think that with a new
paradigm, there needs to be something deeper than what has been
offered in the past. Merely offering the tools isn't enough.
I hope the GreenArrays folks get it, and certainly hope for the
literal interpretation of Jeff's words to be wrong.
I will also add this: Recently at work, we had an XMOS representative
give a presentation about their chips and the solutions they already
implement. Our particular interest in XMOS wasn't just in the chip,
but that they had an AVB solution available. So we sat through the
presentation, learned about the architecture, and talked about the AVB
and other IP they offered. As a software engineer, I'm very
interested in the chip for the exact same reasons why I'm interested
in the GreenArrays chips-- they both make interfacing to hardware
largely a software problem. That's appealing to me. It keeps
hardware in a domain I'm comfortable with.
So I was discussing this with the other engineers at work, and they
agreed that the XMOS chips are compelling... but there are some
practical concerns. What is the expected support lifetime of the
chips? Will the ever be available from multiple sources? What kind
of availability is there? What kind of support (such as field
application engineers)? These are questions that matter to our
company because we manufacture products. The answer to those simple
questions (and many others) is going to matter. It's not just a
matter of technology.
My point in saying this is that I can see that a company like
GreenArrays would be of interest mostly to two groups of people--
there are the hobbyists and experimenters on the low end, and there
are the companies at the high end that want to put their chips into
very high-volume applications. Hobbyists and experimenters don't have
to deal with product timelines and don't care about logistics. And
the big companies can afford to hire developers (or hire GreenArrays)
to develop their applications and get them to market quickly. In the
middle are companies like the one I work for. The kinds of
applications I can see where a GreenArrays chip makes sense to us are
ones where we might sell a couple thousand a year. Far more than what
a hobbyist/experimenter would need, but far less than the kind of high-
volume applications Jeff has referenced in the past. And then there
is development time on chip with a new paradigm. A smallish company
like the one I work for needs to get new products out on time and
tossing a new chip with a new paradigm is not the way to do that.
And, we don't have vast reserves of cash that a larger company has
that we can use to hire another developer or toss to GreenArrays to
develop the code for us.
So the question that my company and the vast middle ground of
companies like ours have to ask is if the GreenArrays chips are
compelling enough to enable some really unique products that can't be
done with conventional processors and design processes. Yeah, I
lament the power-hungry DSPs and the sometimes painful limitations of
the chips we use. But despite the many negatives, the fact is that we
are getting products out to market, making customers happy, and making
money in the process to pay our salaries and fund future development.
The simple reality is that when my boss comes to me and says, "this is
our next product," I have to provide an estimate of the time and
costs. And those numbers matter. After I provide my estimates, the
company has to then plan out important milestones around those
estimates. Production has to work out the timelines on getting parts,
Marketing has to plan advertising and campaigns, Sales has to set up
distribution channels, Finance has to work out how to fund all this,
HR may have to plan hiring people, Support has to learn about the
product and be ready to answer questions about it, and so on. So
based on technology I know (but don't necessarily love), I can provide
estimates of reasonable quality for all that to happen. But if you
asked me to do the same for a GreenArrays chip-- a architecture that I
find fascinating, but which I have no practical experience in
developing applications for-- then I can't say my estimates will be
sufficient for others in the company to base decisions on.
Maybe that changes over time. Maybe if GreenArrays gets some big
design wins and can fund some growth, they'll be able to afford to
provide not just support for the technology, but address all the other
concerns companies in the middle will have. Or maybe GreenArrays just
doesn't care about companies in the middle and never will.
I guess we'll see as the company moves forward. I'm hopeful, but the
success of GreenArrays isn't going to be just about cutting-edge
technology. It's also going to be about mundane stuff like support
and logistics. You can have the coolest technology in the world with
insane speed at incredibly low power. Great stuff-- but if it takes
more time to develop for an unfamiliar paradigm or logistical
guarantees in getting the parts in quantity can't be met or any number
of practical concerns aren't addressed, it doesn't matter.
jmdrake
> On Oct 5, 8:28 pm, jmdrake <johnmdr...@gmail.com> wrote:
>
> > Well I guess that's one interpretation of what Jeff said,
> > but I don't think it's accurate. Here's a part of the
> > quote you left out:
>
> > "IntellaSys offered more conventional tools for more
> > conventional programmers to try to open the programming
> > up to more people."
>
> But we're not talking about IntellaSys. We're talking about
> GreenArrays.
Actually we are talking about both. Jeff gave a comparison
about the way IntellaSys did things as compared to how
GreenArrays is doing things when it comes to third party
development. The ColorForth tools existed all along, but
rather than releasing them, IntellaSys decided to have
new tools released based on an ANS Forth shell simply
because they thought those tools would be better accepted.
But all of the actual chip programming was done in machine
Forth. In arrayForth you have a Pentium ColorForth shell
to access the GA18 ColorForth programming environment.
I've used both VentureForth and arrayForth, and while both
tool sets are good, the arrayForth tools are significantly
better. For instance in VentureForth if I want see what's
going on in memory, I have to type the address on the stack
and enter the "dump" command. In contrast arrayForth
has 16 words of one core that you have focused on the
screen at all time. You can scroll through the entire
128 word memory space. The memory that is displayed is
automatically updated as the simulator runs.
I recall some time ago Elizabeth saying that part of the
IntellaSys business model was to do custom programming
for customers. But they also took steps to make 3rd
party development feasible. The same is true for
GreenArrays. Not only are the tools free (some hardware
manufactures charge for their development kits) but
they've already started releasing detailed code tutorials.
For instance GreenArrays already has a tutorial up for
a multi-core implementation of the MD5 encryption algorithm.
http://www.greenarraychips.com/home/documents/pub/AP001-MD5.html
While IntellaSys did have some decent documentation, I
never recall seeing them release code for any complete
application like that. Back in 2008 when I wrote my
VentureForth parallel multiplication example, that was
probably the most sophisticated code publicly available.
http://primarycolorforth.blogspot.com/2008/01/seaforth-matrix-multiplication-example.html
And that's not saying much. Unlike the MD5 encryption
example, my code is just a "toy" programming exercise
to test distributing an "obviously parallel" problem
across multiple cores.
> What ultimately matters isn't Jeff's words or my interpretation. At
> the end of the day, if GreenArrays wants people outside the company to
> do significant development with their chips, they will have to provide
> not just the tools, but a range of support services for developers
> ranging from experienced to novice. They are going to have to provide
> evaluation kits, reference designs, application notes, discussion
> forums, and ideally IP (common peripherals, algorithms, protocols, and
> so on). I doubt most experienced software and hardware developers
> would have any problem slapping the chips down on a board, wiring up
> some simple I/O, and getting a "hello world" application up and
> running. But beyond that, programming a GreenArrays chip isn't just
> writing code as with a conventional processor. It's also choosing the
> physical processor to run that code, the messaging between processors,
> and the partitioning of an application across groups of processors.
The MD5 example I just referenced does all that. It seems that
GreenArrays is way ahead of you. ;) They're also way ahead of
where IntellaSys left off. No, evaluation kits aren't ready yet,
but they still have a funding issue that hopefully will be helped
some by this lawsuit (and hopefully they can survive either way
because lawsuits can be a crap shoot). Discussion forums? There's
already a ColorForth Google group and I've seen folks from
GreenArrays post there. I think that's good enough for now.
They don't exactly have a ton of employees at the moment. I'd
rather see them writing and releasing other sophisticated code
examples like MD5 and the simple oscillator example than getting
bogged down in discussions that may or may not even be pertinent.
> Those are for most developers new skills, and so you would expect to
> see documentation that takes a complete, non-trivial application and
> shows step-by-step the thought process used to break it down as
> cooperative processes and implement it on the chip. I'm not expecting
> a "GreenArrays For Dummies" hand-holding. But I think that with a new
> paradigm, there needs to be something deeper than what has been
> offered in the past. Merely offering the tools isn't enough.
John, you REALLY need to check the GreenArray website. They have
both "GreenArrays For Dummies" and sophisticated code apps. They
have a series of short videos now showing you step by step on how
to get arrayForth up and running, use the editor, and run the
simulator. (Stuff that hopefully most engineers would be able to
figure out from the text documentation anyway). And they have two
code walk-throughs of sample applications. The website suggests
there will be more.
> I hope the GreenArrays folks get it, and certainly hope for the
> literal interpretation of Jeff's words to be wrong.
Well you don't have to "hope" on this one. Your interpretation
was in fact wrong. ;) I'm not even sure it was really "literal".
Not unless the phrase "understands the technology" is supposed to
only apply to people who work at GreenArrays. But that
interpretation doesn't hold considering the fact that when
GreenArrays was formed there were already people outside the
company who understood how to distribute programs across the
SEAForth chips. Porting from VentureForth to ArrayForth is
really not that difficult.
See: http://primarycolorforth.blogspot.com/2010/03/matrix-multiplication-example-ported-to.html
The issue isn't that GreenArrays doesn't want third party
development. The issue is that GreenArrays isn't focused
on making and supporting tools for people who'd rather
program in something other than ColorForth. Remember this
is the 3rd company to generate significant buzz around
MISC technology. The first, iTVc, said on it's website
that it was going to release tools for programming in
assembly, C, Forth and Java.
See: http://web.archive.org/web/20010604084427/www.itvc.com/Technology/
(Side note: They never made a general release of anything.
I still hope someone will eventually put this code in the
public domain. It's not doing anyone any good right now.)
"Assembly" of course was machine Forth and "Forth" was
ANS Forth. I don't know if the C or Java compilers were
ever written, but I'm sure your aware of the stories
Jeff had about the ANS Forth programmers at iTVC. While
there is an ANS Forth compiler for the GA chips, I doubt
you'll see anyone hired this time who ONLY knows ANS
Forth. IntellaSys moved away from the "This is an ANS
Forth computer with a Forth like assembly" model, to
more fully embracing the underlying machine Forth code,
but with an ANS Forth shell. GreenArrays could have
gone that same direction because, as I understand it,
Jeff wrote VentureForth and so he could have done the
same thing again for GA. But that would mean supporting
two environments. My understanding is that Chuck and
his team never adopted VentureForth and always did
everything from a ColorForth environment.
So GA does seem, to me anyway, to be aimed at
facilitating third party development, as long as
the third parties are willing to learn ColorForth.
In a way it's no different from initially having
to learn Objective-C if you wanted to program for
the iPhone.
> I will also add this: Recently at work, we had an XMOS representative
> give a presentation about their chips and the solutions they already
> implement. Our particular interest in XMOS wasn't just in the chip,
> but that they had an AVB solution available. So we sat through the
> presentation, learned about the architecture, and talked about the AVB
> and other IP they offered. As a software engineer, I'm very
> interested in the chip for the exact same reasons why I'm interested
> in the GreenArrays chips-- they both make interfacing to hardware
> largely a software problem. That's appealing to me. It keeps
> hardware in a domain I'm comfortable with.
>
> So I was discussing this with the other engineers at work, and they
> agreed that the XMOS chips are compelling... but there are some
> practical concerns. What is the expected support lifetime of the
> chips? Will the ever be available from multiple sources? What kind
> of availability is there? or What kind of support (such as field
> application engineers)? These are questions that matter to our
> company because we manufacture products. The answer to those simple
> questions (and many others) is going to matter. It's not just a
> matter of technology.
Those are all good questions. But I don't think they are the types
of questions a fledgling chip company can easily answer. At some
point you have to have "early adopters". People who don't mind
breaking out of the "chicken and egg" cycle and at least making the
minimal investment needed to learn the technology. It sounds like
they're already working with some partners, so "field application
engineer" support is apparently already available, but the current
number of GA employees is severely limited. Once they have more
money coming in, they can hire more people solving one chicken
and egg problem. Of course the pool of people outside the company
who already understand the technology and could be hired is also
limited. As more people download the freely available tools, go
through the examples, and implement their own programs, another
chicken and egg problem is solved. If folks spent as much time
learning ColorForth as people spend arguing over it there wouldn't
even be a problem. ;)
Well the question you should ask yourself is a personal one. What do
you want your hobbies to be? In the time it took you to compose this
USENET response, you likely could have downloaded arrayForth,
installed it, got it up and running, typed in the simple oscillator
code and walked through it. You might even be able to go through the
MD5 code. And what would you have sacrificed? Some time posting on
comp.lang.forth? And sure, it's your choice on how you spend your
free time. I guess my point is that being a "hobbiest" and working
for a real company doesn't have to be mutually exclusive.
> our next product," I have to provide an estimate of the time and
> costs. And those numbers matter. After I provide my estimates, the
> company has to then plan out important milestones around those
> estimates. Production has to work out the timelines on getting parts,
> Marketing has to plan advertising and campaigns, Sales has to set up
> distribution channels, Finance has to work out how to fund all this,
> HR may have to plan hiring people, Support has to learn about the
> product and be ready to answer questions about it, and so on. So
> based on technology I know (but don't necessarily love), I can provide
> estimates of reasonable quality for all that to happen. But if you
> asked me to do the same for a GreenArrays chip-- a architecture that I
> find fascinating, but which I have no practical experience in
> developing applications for-- then I can't say my estimates will be
> sufficient for others in the company to base decisions on.
Then if you really find the architecture "fascinating", find time
off the clock to learn how to use it. Or wait until other
GreenArrays customers prove the technology for you. Maybe you'll
be able to convince your boss to hire away a programmer from one
of these early adopter companies, or some hobbiest who's shown
good work. Lot's of ways to get around this.
> Maybe that changes over time. Maybe if GreenArrays gets some big
> design wins and can fund some growth, they'll be able to afford to
> provide not just support for the technology, but address all the other
> concerns companies in the middle will have. Or maybe GreenArrays just
> doesn't care about companies in the middle and never will.
Or maybe you'll care enough about the technology itself to actually
learn ColorForth off the company clock so you can program for it.
Maybe you'll subscribe to the GreenArrays blog feed so that you'll
know about application examples as they as they are posted instead
of waiting for an announcement on c.l.f. Maybe you'll get someone
from your company to contact GA sales, marketting or business
development departments and direct pertinent questions there instead
of just assuming GA "doesn't care about companies in the middle".
Did XMOS just show up at your doorstep, or did someone from your
company contact them first?
> I guess we'll see as the company moves forward.
Yep. We'll see.
jmdrake
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
> > Chuck Moore has filed a suit against TPL, at last.
> > Read more athttp://www.colorforth.com/blog.htm
> > The outcome will be hopefully that the awesome GreenArrays technology can
> > be developed speedily and will become available to mankind,
> > instead of staying in the hands of patent sharks.
>
> The minute or two that I spent looking at the filing wasn't enough to
> let me understand what the underlying dispute was, but it looks
> unpleasant and it's always unfortunate when anything has to come to
> that.
The underlying dispute is that Dan Leckrone entered into an attorney
client relationship with Chuck Moore back before the "iTVC" days,
promised to help Chuck commercialize his technology, was initially
helpful, but started royally shafting Chuck once the big bucks
started rolling in from companies like Intel and AMD. There's
also a lot of Chuck Moore history in there that I didn't know.
For instance I had no idea he was working with a French company
before working with iTVC. That's were Leckrone was helpful,
getting him out of the French relationship, helping him establish
a relationship with iTVC, and then helping him get his patent
assignments back from iTVC. Where things got off track is with
the commercialization agreement (ComAg). Chuck apparently thought
he was merely licensing the MMP portfolio to Leckrone to sub
license it to others, but Leckrone drew the papers up as an
assignment.
Leckrone then allegedly didn't even live up to the
commercialization agreement as written. He never did the
required quarterly income reports, never fully fulfilled the
promise to commercialize the technology, took money from the
MMP royalties to commercialize other patent portfolios that
didn't benefit Chuck, and ultimately killed the whole array
chip project.
Chuck is seeking damages, which he doesn't think he's going to
collect since TPL is facing insolvency, and a cancellation of
the ComAg, and with that return of control of the MMP to
Chuck. Basically if Chuck and PTSC win, the remaining value
of the MMP portfolio goes back to them, cutting out the TPL
middle man. The key patents that are currently making money
were issued in 1998. Patents last 20 years, so the fight is
over who gets what royalties between now and 2018.
> I have to wonder how valuable the GreenArrays technology really is.
> There was another thread a couple weeks ago where possible applications
> for the GA chips were discussed. As I remember, nobody could think of
> any really convincing ones. So I get the impression that the GA guys
> did some things that were pretty nifty from a technical point of view,
> but got mixed up with the wrong crowd on the business and legal side.
Well hopefully companies won't value technology based on USENET
discussions. ;) There were already interesting apps developed
back in the IntellaSys days such as 3D vision, software defined
radio, and wireless speakers. But unfortunately these apps never
made it past the "working prototype" stage. There were interesting
talks, and you'd occasionally get "block diagrams" showing how the
code was laid out, but not the code itself. For example this paper
on software defined radio:
http://www.intellasys.net/templates/trial/content/WP_RFProcess.pdf
I think any application where you might want to connect things
wirelessly, but you don't need the overhead of bluetooth or Wifi
would be a place where these chips would be good considering they
can drive an antenna directly.
Encryption is another area. In this case GreenArrays has gone
beyond simply releasing block diagrams to releasing code:
http://www.greenarraychips.com/home/documents/pub/AP001-MD5.html
Also people outside of GA are looking at massively parallel, very
simple low power cores for doing DSP.
See: http://www.ece.ucdavis.edu/~anhttran/files/papers/VCL_JSSC_04_2009.pdf
Note that one of the authors used to work at IntellaSys.
Albert van der Horst
John Passaniti <john.pa...@gmail.com> wrote:
<SNIP>
>
>I guess we'll see as the company moves forward. I'm hopeful, but the
>success of GreenArrays isn't going to be just about cutting-edge
>technology. It's also going to be about mundane stuff like support
>and logistics. You can have the coolest technology in the world with
>insane speed at incredibly low power. Great stuff-- but if it takes
>more time to develop for an unfamiliar paradigm or logistical
>guarantees in getting the parts in quantity can't be met or any number
>of practical concerns aren't addressed, it doesn't matter.
That's what I hope for. A couple of millions is not much for
the bankers and lawyers, but it is when it is used to hire
enthusiast engineers to do a job that inspires them.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Paul Rubin
> [re applications of GA chips]
> Well hopefully companies won't value technology based on USENET
> discussions. ;) There were already interesting apps developed
> back in the IntellaSys days such as 3D vision, software defined
> radio, and wireless speakers. But unfortunately these apps never
> made it past the "working prototype" stage. There were interesting
> talks, and you'd occasionally get "block diagrams" showing how the
> code was laid out, but not the code itself. For example this paper
> on software defined radio:
>
> http://www.intellasys.net/templates/trial/content/WP_RFProcess.pdf
Thanks, that is interesting, though most of those examples sound
well-suited to conventional DSP's.
> Encryption is another area. In this case GreenArrays has gone
> beyond simply releasing block diagrams to releasing code:
> http://www.greenarraychips.com/home/documents/pub/AP001-MD5.html
I looked at that article and found it interesting as a description of
how to program the GA chips by partitioning problems across multiple
nodes. It was quite enlightening for understanding the thinking behind
the architecture. But it seems like a pretty terrible way to do crypto
in practice. Do they have any benchmarks for that implementation?
> Also people outside of GA are looking at massively parallel, very
> simple low power cores for doing DSP.
Unfortunately as far as I can tell, conventional DSP's beat the GA
implementation by quite a large margin in energy per DSP operation, not
too surprising since general purpose processors have to do a lot of
extra work for what DSP's do completely in hardware.
So many of these examples are DSP-like that I think the GA chips would
be much more interesting if some or all of the nodes had hardware
multipliers. That would increase their usefulness quite a bit IMO.
The GA processor may make the most sense as a cell that the user can
drop onto an FPGA or ASIC in combination with other stuff.
Paul Rubin
> But Paul, what happens when they move the chip from the 180nm process
> to a sub 45nm process that they use in GPU's?
Right now I think the GA at 180nm is using about 6x the energy for a MAC
operation as the low power TI DSP at 90nm. So even assuming the 4x area
reduction corresponds to a 4x power reduction, the GA is still doing
worse.
And I'm not even convinced it's only as bad as 6x. I believe that the
TI is doing a 17x17 MAC into a 40-bit accumulator, i.e. it's multiplier
gives a double-width product. The GA "multiply step" operation seems to
only operate at single width. So the GA doc is not describing a
comparable operation when it says the F18 can multiply in 20 cycles or
whatever it is. It really takes about double that to do a DSP-like
multiplication,, if I understand the (rather badly documented) +*
operation correctly.
Albert van der Horst
Zooming in on this weak point (multiplication) doesn't say much about
the usability of the chip in general, much less about its power
consumption. The GA documentation is (too) fair illuminating this
point.
My impression is that Chuck let this weak point because it
matters not much.
I was thinking lately about my "digital sine generator" and suddenly
realized that the GA possibilities turned my ideas totally around.
Paul Rubin
> the usability of the chip in general, much less about its power
> consumption. The GA documentation is (too) fair illuminating this
> point.
That's the thing though, most of the examples mentioned here, by me and
others, are in fact typical DSP-like problems that are indeed
multiplication-intensive. If there's a place in the GA documentation
that gives other types of examples in any convincing way, I haven't
found it yet.
I don't think the multiplication weakness is necessarily fatal to
the GA concept, but I think the most straightforward cure may be
to add multiplication to the processor.
> My impression is that Chuck let this weak point because it
> matters not much.
Foxchips said the same thing, but I'm having a somewhat hard time seeing
it. The hearing aid application again sounds DSP-like, and to the
extent it's not dominated by multiplication, a lot of what's left sounds
like node-to-node communication that wouldn't be necessary on a normal
DSP whose multiplication is fast enough to not need parallel nodes.
> I was thinking lately about my "digital sine generator" and suddenly
> realized that the GA possibilities turned my ideas totally around.
I'm not sure what the digital sine generator was supposed to do.
I've thought of one possible cryptographic use: elliptic curve
signatures on large binary fields (see dnscurve.org for a high-volume
application of this). It might be possible for the GA chip to beat a
conventional processor at this. But I haven't figured out yet whether
this makes sense.
More traditional crypto algorithms like the SHA family don't seem to fit
that well on the GA. RSA is of course multiplication-intensive and well
suited for DSP's.
Most other non-numeric applications I've considered are bandwidth
intensive (error correction for a disk array, must be able to keep up
with a RAID running at full tilt), or memory intensive (search indexing,
basically a lot of in-memory sorting), or make more sense on an FPGA
than a general purpose processor. The software-defined radio example of
having the GA's i/o pins drive the radio directly was kind of
interesting, but was more about the i/o than the GA's unique
computational setup. And again, it would have benefited from high-speed
multiplication.
It might be possible to put the initial ingestion phase of a search
engine (i.e. unicode conversion, Porter stemming, token hashing) onto a
GA and save some power compared to using a conventional processor. For
a Google-sized indexing operation, the power savings might be
significant. It could possibly be helped a little more by adding a
programmable routing mesh between nodes on the chip, allowing some
parallel sorting to happen on the chip. But the headache of deploying
special hardware for something like that sounds hard to justify no
matter what. And if it turned out to be useful, then it could be killed
off pretty fast by having some new special-purpose instructions added to
general purpose processors, like desktop cpu's these days generally have
multimedia instructions designed to speed up the discrete cosine
transform.
So I keep scratching my head and seeing a solution in search of a problem.
Paul Rubin
> They have been very open and answered all the questions in forums and
> at many public presentations for years and worked with a number of
> clients. The technology is really good if you like software written
> in Forth. Any more questions about it?
One issue is most of what I've read has been on the GA site,
which doesn't discuss as many application details as some of
the other possible places you mention. If you have any other
url's, I'd be interested in taking a look at them. I did watch
the hearing aid video presentation and I found it interesting.
> If you have a problem to solve or an idea for use then related
> questions can probably be answered. If you can't ask them in public
> then don't.
I don't have any applications that I can't ask about in public. The
applications that I can think of at all, so far, I mostly can answer for
myself. The answer usually turns out to be either: 1) use a
conventional microcontroller; 2) use a DSP; or 3) use an FPGA. I'm not
an embedded developer so maybe there are a lot of possibilities that I'm
overlooking. But so far, I'm still trying to identify the killer app
where the GA beats all of the above.
Paul Rubin
>> > One thing I enjoy doing is describing programs to people and then
> Here's four:
>
> One I asked about fifteen years ago was what do you need
> for a program to put a computer into a low power sleep mode
> so that when it sees a message arrive on a network it
> will wake up to full speed, read the message and
> execute it. How large is the program?
That sounds like more of a hardware question, but I think plenty of
cpu's have a sleep/wake mode so that when you toggle some pin, the cpu
wakes up. AVR's and PIC's have something like that, I think. This
doesn't seem too relevant to the question of what to do with a big F18
array like the GA chips.
> The most recently discussed in c.l.f was a metacompiler for an ANS
> Forth system that was mentioned. How big and complex do they need to be?
I'm not sure what you mean by a metacompiler. If you just mean
a plain old Forth compiler then the traditional implementation
techniques are well known and you need a few KB. The ANS dictionary
is around 350 words IIRC. We spent a bunch of time discussing
how to implement the symbol table.
> The most recently published one was a fairly simple program, a simple
> loader that uses a single gpio pin and a connection to other computers
> on a net.
Again this doesn't sound like a software question.
> How much room do you need for boot code, an OS with desktop GUI w/
> multiple fonts, effects, graphics, drivers for the mouse, rtc, video,
> network, ports, windows, widgets, icons, and a Forth compiler that can
> compile several hundred millions Forth source words per second? How
> expensive is the processor you need to run it?
Several hundred million words per second sounds difficult even for fancy
desktop systems with today's hardware. That's well over a gigabyte per
second, which is faster than a SATA channel by a sizeable margin. It
does seem possible to write a much saner and faster GUI system than what
we see on today's desktops, and doing the lower levels in Forth is
fairly plausible. It could be organized something like the old
Postscript-based window systems; the resemblance between Postscript and
Forth is of course well known. To some extent, the spirit lives today
in AJAX-style web applications, where the server exports some
application-specific high-level operations to client side Javascript
through remote http calls.
Wayne
wrote:
> Wayne <news_putmy...@optusnet.com.au> writes:
>> But Paul, what happens when they move the chip from the 180nm process
>> to a sub 45nm process that they use in GPU's?
>
> Right now I think the GA at 180nm is using about 6x the energy for a MAC
> operation as the low power TI DSP at 90nm. So even assuming the 4x area
> reduction corresponds to a 4x power reduction, the GA is still doing
> worse.
I was asking about the GPU comparison. I too would like to see much
better multiplication performance on Misc, as the step multiply does not
go too far on 700 mhz, but it is what it is and targeted at the market it
is. Was there any conditions that caused this result, and any presumption
that most target tasks do not require a 40 bit accumulator, so it did not
really matter?
Wayne
wrote:
> So many of these examples are DSP-like that I think the GA chips would
> be much more interesting if some or all of the nodes had hardware
> multipliers. That would increase their usefulness quite a bit IMO.
>
> The GA processor may make the most sense as a cell that the user can
> drop onto an FPGA or ASIC in combination with other stuff.
Yes, I agree, but I think they wish to keep some control of priority
secretes.
Paul, I think a reason behind the multiply step is that a proper
multiplier takes up a lot off logic. I think I remember it was something
like 16000 gates on the RTX (16 bit) with it's own timing, so a
significant number of cores can be lost this way and the minimum power
consumption lifted (though I do not know what energy conservation methods
GA would employ. One of their big aim is the lowest power consumption
base level compared to lowest end programmable circuits and DSP. I would
be interested in hear how you think it compares to these?
Thanks
Wayne.
Wayne
wrote:
> On Oct 5, 8:17 am, Brad <hwfw...@gmail.com> wrote:
[Preemphasis]
>> Same thing with hearing aids. The loss isn't flat across the spectrum,
>> so you emphasize the lossy frequencies.
> The hearing aid racket is based on the idea that the problem
> is a simply a different frequency domain filter in an aging
> ear that can reverse by nothing more than an inverse filter.
> Hearing loss if far more complex than just lossy bands in
> the spectrum! There may be a problem with noisy bands inside
> the ear but it isn't in the sound coming in so can't be
> filtered out.
> The hearing enhance project is very different as it is
> far more sophisticated. It does restoration by
> modifying the sound so a damaged ear sounds more
> like a normal ear to the brain. It doesn't sound
> good to a person without hearing loss. All the
> details of hearing loss and the algorithms the
> scientists used to restore properties to the sound
> are not public stuff. The idea was to combine new and
> revolutionary algorithms that actually work with
> hardware that can deliver them in real-time and with
> little power.
>
> Best Wishes
Jeff, wouldn't what I suggested earlier be a simpler compromise for bass
induced deafness, that would require a fraction of the processing power,
allowing a simpler chip that lasts longer? It is not based on emphasis of
frequencies, but shifting frequencies out of the bad range (amplitude
emphasis would probably lead to increased deafness over time). A similar
thing could be done for distorting frequencies (even deemphasis of
amplitude.) Though a modification map could be programmed in for troubled
ranges as well. That might serve as a good basis for a cheap Open Source
hearing aid in directional form, simulating the directional response curve
of human hearing and perception, but that might get part way into what
they are doing). All pure alarm/warning/notification tone frequencies
would have to be retained as is and possibly mixed with a shifted version.
Previous:
> ...like the simple fact that the brain can perceive base frequencies
> from the harmonic frequencies ofthose frequencies...Phillips
> patented..that simulated base with frequencies. I am interested in
> custom compensating for hearing loss at particular frequencies, for
> person top person, by shiftingthose frequencies (any harmonic advantage
> also an advantage) or the whole spectrum. There was also adevice in the
> 80's that allowed completely deaf people to hear, that moved the
> frequencies to asecond primitive ultrasonic hearing mechanism (I think
> they stated as reptilian like). I think it
> may have been behind the ear. Such things might extend battery life and
> reduce complexity further.
Thanks
forther
> The GA "multiply step" operation seems to only operate at single width.
Brad
> Several hundred million words per second sounds difficult even for fancy
> desktop systems with today's hardware. That's well over a gigabyte per
> second, which is faster than a SATA channel by a sizeable margin.
But then colorForth source files are small and probably cached. Also,
colorForth is pre-digested to some extent. If the compiler finishes
before I can get my finger off the Enter key, that's plenty fast.
Actually, 1/4 second delay is the typical threshold at which users
start to get annoyed, when an operation is expected to be instant.
-Brad
John Passaniti
> Foxchips said the same thing, but I'm having a somewhat
> hard time seeing it. The hearing aid application again
> sounds DSP-like, and to the extent it's not dominated by
> multiplication, a lot of what's left sounds like node-to-node
> communication that wouldn't be necessary on a normal DSP
> whose multiplication is fast enough to not need parallel nodes.
Such inter-node communication isn't necessary with a DSP chip, but
what it does do is result in less power being consumed, since each
node is only active when it needs to be. The GreenArrays chips are
more geared towards dataflow-style processing. And if you've ever
played with data-flow such environments for signal processing (like
Max/MSP and PureData) you know how surprisingly efficient they can
be. It's because each processing element only fires when it actually
has something to do.
I'll also add this: Back in the early 90's, I worked for a company
that made signal processing gear for musicians. Back then, the cost
of DSP horsepower was high, so if you could find a way to pull off an
effect without tons of multiplies, it meant you could both lower costs
and cram more effects into the unit.
One class of effects that most every musician wants are good reverbs.
These days, many high-quality reverbs are implemented using
convolution. You go into a space that you think sounds good, fire off
impulses, and then sample the reflections from that impulse. Then to
do the reverb, you just convolve the audio against the sampled
reflections. That gives you very good (and very accurate) reverbs.
Great stuff, but it requires lots of multiplies, and it wasn't going
to happen in the early 90's with gear priced below $400.
So instead, our reverbs were constructed using time-domain elements--
mostly allpass filters and delays. What you're effectively doing with
reverbs based on such a design is modeling aspects of a room, most
notably reflections. There is a lot of "secret sauce" beyond that in
tweaking the delay taps to avoid resonances and other artifacts. One
of the more amusing is that it's common to modulate some taps slightly
to help smear-out the audio. This doesn't of course happen in
reality-- walls tend not to move back and forth by a foot or more at
around 5Hz in most spaces! But despite it not reflecting a physical
reality, it's a tweak that makes it sound better.
The point I'm making is that there is often more than one way to do
the same thing. If you have the raw DSP horsepower and you want a
really good quality reverb, convolution is the way to go. It's stupid-
simple and gives great results. But if you can't afford the DSP
horsepower, you can still get a quite-good reverb with simpler time-
domain elements and careful tweaking.
So it's possible that the GreenArrays folks are planning on pulling
off some of the DSP algorithms using alternate methods.
A practical example of this would be pitch transposition. There are
some forms of hearing impairment where the individual simply can't
hear certain frequency ranges. For such individuals, bumping up the
amplitude of those frequencies isn't going to help. But what can help
is to map those frequencies from one band to another. So if someone
has lost a critical range (such as 400Hz to 1kHz) but still hears okay
in another frequency band, you can map those frequencies around.
Depending on how you do it, everyone now sounds like Barry White or
Mickey Mouse. But the brain adapts.
So, how do you map frequencies? One way is to take a FFT to move the
audio from the time to frequency domain. Once there, you can move the
coefficients around for the bands of interest. Then you take an IFFT
and go back from frequency to time domain. And again, great stuff,
but that requires a *lot* of multiplies per second. But there are
alternatives.
Years ago before digital electronics, pitch transposition was done
using tape and spinning heads. Audio would be written to tape around
a drum. Then, two heads would spin around inside the drum and and
read audio off the tape. Toss in some cross-fading between the heads
at the right frequency, and what you end up with the audio pitch-
shifted up or down. One can easily map this mechanical model to
digital electronics-- the tape becomes a memory buffer, and the heads
are just taps. The cross-fading is driven by a LFO. Put it together
correctly, and what you end up with is a pitch transposition that
requires far less multiplies. This is how we did pitch transposition
back in the early 90's.
Is this time-domain pitch transposition as good as the frequency
domain version? No. But it's still pretty good.
Again, is this the kind of thing the GreenArrays people are looking
at-- replacing accurate but computationally expensive algorithms with
less-accurate but also less expensive algorithms that are geared more
for the capabilities of the GreenArrays chips? I don't know, but it
seems likely. Scads of multiplies are one way to do DSP, but it's not
the only way.
rickman
I remember in school I was told that one of the old programmers from
the early days has a rule of thumb that his routines should be no
larger than a screen which was 24 lines. Too bad we don't use the
same rule of thumb with usenet posts. I know I've broken that rule
plenty of times. I just don't have the time to keep up with this
thread.
Rick
John Passaniti
> I remember in school I was told that one of the old
> programmers from the early days has a rule of thumb
> that his routines should be no larger than a screen
> which was 24 lines. Too bad we don't use the same
> rule of thumb with usenet posts. I know I've broken
> that rule plenty of times. I just don't have the
> time to keep up with this thread.
As Dr. Ruth used to say, size doesn't matter. What matters is the
content. There are plenty of people who write very short messages,
but who never back up their statements with examples or
justification. I don't think such messages are terribly useful, but
those who enjoy such statements are free to differ. I'm not defending
the times I or others are verbose. But I am pointing out that
counting lines is not the best way to judge the value of a message.
rickman
Yeah, so says everyone with a tiny... well you know what I mean.
Brevity is the essence of wit and a message can clearly be too long.
Heck, I literally don't have the time (or interest) to read such an
epic tome. But then like they told Jack Nicholson in China Town,
"It's just the forth usenet group"...
Rick
rickman
wrote:
> On Thu, 07 Oct 2010 17:06:31 +1100, Paul Rubin <no.em...@nospam.invalid>
Depends on how you measure power consumption. On paper all sorts of
chips look good. But until you evaluate them for your application you
can't say. If the power is half another chip, but it spends three
times as long doing the calculation because of the multiply
implementation, did you gain or lose?
Rick
foxchip
> I'm not sure what you mean by a metacompiler. If you just mean
OK. Never mind the questions about Forth software.
I only asked because of your many other statements about
Forth software. I had wondered on what your comments
on Forth software were based.
Best Wishes
foxchip
wrote:
> Jeff, wouldn't what I suggested earlier be a simpler compromise for bass
> induced deafness, that would require a fraction of the processing power,
> allowing a simpler chip that lasts longer?
Yes.
Best Wishes
foxchip
> But then colorForth source files are small and probably cached.
Colorforth does have source in RAM not files on a disk
in a file system. Of course the question being addressed
was not about colorforth but aha.
aha also does not keep source in disk files. But it also
does not use the same format as Pentium colorforth. aha
take source compression to the next level past colorforth
and does the same with shifting of some of the forty year
old compiler loop into edit time instead of compile time.
The idea was to take ideas from colorforth to the next
level and adapt them to MISC architecture.
The idea isn't source in bytes, source in files, or the
forty year old Forth compile loop. But it is a decade
old now and I have revisited some of the ideas to make
it simpler, smaller, and faster.
Colorforth only removed searching the dictionary for numbers
by identifying them at compile time and using color tokens
in the source to replace a bunch of Forth words. Using
tokenized source compressed in a different way than Pentium
colorforth Aha moved many of the words out of the dictionary.
It also moved the dictionary out of the compiler. Everything
is still there in the source and you can't see any difference
in an editor. But what is left in the compiler is very
small and fast.
The idea is that it doesn't make sense to use your compiler
to find your typos since a smarter editor improves the programmers
productivity by shortening the tool chain. And the idea is
that the Forth compiler can be smaller and faster. Forth
source is compressed by the editor so that the compiler
doesn't waste time, effort, and memory doing dumb things.
> Also,
> colorForth is pre-digested to some extent. If the compiler finishes
> before I can get my finger off the Enter key, that's plenty fast.
When people have slow compilers they don't compile often.
Most people won't even talk about it.
They may end up with source and object and executable file
representations trying to avoid actual compiles. Traditional
Forth just tried to make the compiler fast and small compared
to the ugly multi-pass stuff, linked stuff, and stuff reduced
in size and speed by being done on top of common file systems
instead of faster Forth blocks.
Over the years I learned how sometimes I could expand a
compressed thing faster than I could copy it, or how I
could compile something faster from source than I could
copy or load the compiled version of it. I could make
source smaller and less error prone and make the compiler
smaller, faster, and simpler too. This way smaller systems
can handle larger programs. A one dollar processor can
compile Forth source faster than traditional compilers do
on thousand dollar machines, and the programs are smaller
too.
People throw around terms like 'fast' or say that they
don't care or that they have small programs. But people
ignore the fact that programs may be compiled millions
of times in their lives or more. So it is a little like
the volume variable in embedded systems, one penny
multiplied by a million units adds up as does one
microsecond multiplied by a million compiles.
Forth programmers
begin do do edit compile loop test loop repeat
They may compile many times in a day and a team may
end up compiling a program every few seconds somewhere
so speed does matter in the real world.
> Actually, 1/4 second delay is the typical threshold at which users
> start to get annoyed, when an operation is expected to be instant.
Sure. I recall that back in the mid-nineties that we could
compile a small application on the PC using gForth in only
fifteen seconds while the same thing took over five minutes
in ProForth for Windows. It is a good thing the programs
were small.
People with long compile times usually won't talk about
them even when you ask. But they do complain a lot about
the kind of compilation of serious programs that can take
several days or that are always given a full week in the
company schedule.
Now if Forth programs were not compiled often or only ever
compiled once like many other things then Forth would be
very different.
Best Wishes
Albert van der Horst
rickman <gnu...@gmail.com> wrote:
>
>
>I remember in school I was told that one of the old programmers from
>the early days has a rule of thumb that his routines should be no
>larger than a screen which was 24 lines. Too bad we don't use the
>same rule of thumb with usenet posts. I know I've broken that rule
>plenty of times. I just don't have the time to keep up with this
>thread.
But at least learn how to snip.
>
>Rick
Wayne
> On Oct 8, 1:54 am, Wayne <news_putmynamehere...@optusnet.com.au>
> wrote:
[power requirement comparison multiplication GA]
> Depends on how you measure power consumption. On paper all sorts of
> chips look good. But until you evaluate them for your application you
> can't say. If the power is half another chip, but it spends three
> times as long doing the calculation because of the multiply
> implementation, did you gain or lose?
>
> Rick
True enough, but they gain the minimum runtime power (which is, I think,
what they were aiming for, not me, I don't care the quicker it does it's
tasks and then goes into sleep mode, within reason, the better). I think
the most important thing is for data to arrive as fast as it can be
processed, I also prefer it to processed fast, I could really give GPU's a
run for their money in 3D ray tracing.
But I was restricting the argument down simply to multiplication
performance, rather then performance across other tasks.
Thanks
Wayne.
Wayne
wrote:
[The history of color forth and aha refinements]
I'm going to mention the "O" word. I get like a very sick old man myself,
it makes the amount of things I can do less, and changes the types of
things I can do. Like you Jeff, there is a lot of talented people around
here, who have learned and experienced lots of unique things. If anything
would happen to any of us, then those experiences would likely largely
disappear with us in the fog of this time, like these posts.. I would
like to suggest that you could write a book, at the level of thinking
forth, on these experiences and refinements explaining them to future
generations, where they can advance them. I think some, other people
could also write such short books. Still others could contribute a
chapter on their experiences to a combined book of their experiences, and
a kitchen sink/wiki book on forth techniques would also be worth a
combined effort. I'm talking about technical books, but personal books
could also be done. They would be left to the public domain
(+archive.org) after a period of time. I think such books are well worth
buying, as ebooks or as whole books.
Actually, thinking along the lines of the book, "Home Computer Wars" one
of my most cherished, the history of Chuck and the Forth/Misc chips would
make an interesting read and more. Has anybody done extensive write
ups/books and information on the professional and personal side of Chuck's
life?
Thanks again Jeff
Wayne.
Wayne
I find that the sicker I am the lower my cognitive ability and the less
ability I have to read long posts (you can read in between the lines here
about others). Maybe they just don't have much to say, I find convoluted
issues often require longish explanations for comprehensive clarity. What
really gets me is Jeff's posts, but mostly filled with goodies ;)
Elizabeth D Rather
> On Oct 7, 5:06 pm, Brad <hwfw...@gmail.com> wrote:
> > But then colorForth source files are small and probably cached.
> The idea isn't source in bytes, source in files, or the
> forty year old Forth compile loop. But it is a decade
> old now and I have revisited some of the ideas to make
> it simpler, smaller, and faster.
>
The "forty year old Forth compile loop" is pretty much ancient history
for most modern Forths, too.
...
>> Also,
>> colorForth is pre-digested to some extent. If the compiler finishes
>> before I can get my finger off the Enter key, that's plenty fast.
>
> When people have slow compilers they don't compile often.
> Most people won't even talk about it.
The Forths I use (SwiftForth and SwiftX) also compile quite significant
applications before I can get my finger off the enter key. So, the
"slow compiler" isn't a problem, and to me sacrificing universally
readable text source would be an inconvenience.
...
> People throw around terms like 'fast' or say that they
> don't care or that they have small programs. But people
> ignore the fact that programs may be compiled millions
> of times in their lives or more. So it is a little like
> the volume variable in embedded systems, one penny
> multiplied by a million units adds up as does one
> microsecond multiplied by a million compiles.
>
> Forth programmers
> begin do do edit compile loop test loop repeat
>
> They may compile many times in a day and a team may
> end up compiling a program every few seconds somewhere
> so speed does matter in the real world.
Yes, *instantaneous* compiles are what you want. That's a little more
explicit than "fast". Fortunately, they are available. I suspect Jeff
may be a little out of touch with modern Forths.
>> Actually, 1/4 second delay is the typical threshold at which users
>> start to get annoyed, when an operation is expected to be instant.
>
> Sure. I recall that back in the mid-nineties that we could
> compile a small application on the PC using gForth in only
> fifteen seconds while the same thing took over five minutes
> in ProForth for Windows. It is a good thing the programs
> were small.
The "1/4-second rule" works for me.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Andrew Haley
> On 10/9/10 12:59 AM, foxchip wrote:
>>
>> When people have slow compilers they don't compile often.
>> Most people won't even talk about it.
>
> The Forths I use (SwiftForth and SwiftX) also compile quite significant
> applications before I can get my finger off the enter key. So, the
> "slow compiler" isn't a problem, and to me sacrificing universally
> readable text source would be an inconvenience.
I agree completely. The key technology here is source code control
systems: I now can't imagine life wihtout them.
Andrew.
foxchip
> Yes, *instantaneous* compiles are what you want. That's a little more
> explicit than "fast". Fortunately, they are available. I suspect Jeff
> may be a little out of touch with modern Forths.
Maybe, but then again I was discussing software we got from
Forth Inc. when I was complaining about slow stuff that was
such a problem.
> > Sure. I recall that back in the mid-nineties that we could
> > compile a small application on the PC using gForth in only
> > fifteen seconds while the same thing took over five minutes
> > in ProForth for Windows. It is a good thing the programs
> > were small.
>
> The "1/4-second rule" works for me.
Maybe so but the compiler I mentioned with the five minutes
compiles was one that we bought from Forth Inc. and
5 minutes is greater than 1/4 second. The $4000 per copy
ProForth for Windows compilers we bought from Forth Inc.
didn't have any such rule.
You recall that we bought those because of the claims that
it was well written, had professional quality documentation,
and professional quality support. I found it the buggiest
Forth I ever seen, found the documentation was simple auto
generated stuff useless to all but newbies as we already
knew what DUP did. The big problems as you recall were
that support was simply totally and completely non-existent.
Bugs were a far bigger problem than the slowness
especially because we had to deal with them all on our own.
Forth Inc. kept insisting that MPE should support the
product because they wrote it and MPE insisted that
Forth Inc. should support it because they sold it to us
and took our money. Both companies insisted that
support was simply not their responsibility. And
support came there none despite the forty or
fifty grand that changed hands.
We got support from Tom Zimmer on Win32Forth within
hours for free and found that gForth worked well too.
We could compile the same apps much faster (and
without all the bugs that required work arounds) with
other Forth instead of the one where we had to take
coffee breaks while it ran. As I recall you said that
the whole episode was most unfortunate for everyone.
Unfortunate for the unhappy customer and the $40,000
we paid was not exactly a fortune for Forth Inc.
either. But it was better I think than the dirty
end of that stick.
Best Wishes
Elizabeth D Rather
> On Oct 9, 8:58 am, Elizabeth D Rather<erat...@forth.com> wrote:
>> Yes, *instantaneous* compiles are what you want. That's a little more
>> explicit than "fast". Fortunately, they are available. I suspect Jeff
>> may be a little out of touch with modern Forths.
>
> Maybe, but then again I was discussing software we got from
> Forth Inc. when I was complaining about slow stuff that was
> such a problem.
>
>>> Sure. I recall that back in the mid-nineties that we could
>>> compile a small application on the PC using gForth in only
>>> fifteen seconds while the same thing took over five minutes
>>> in ProForth for Windows. It is a good thing the programs
>>> were small.
>>
>> The "1/4-second rule" works for me.
>
> Maybe so but the compiler I mentioned with the five minutes
> compiles was one that we bought from Forth Inc. and
> 5 minutes is greater than 1/4 second. The $4000 per copy
> ProForth for Windows compilers we bought from Forth Inc.
> didn't have any such rule.
That was how many years ago? I'm speaking of modern Forths (i.e.,
available today).
Brad
> Sure. I recall that back in the mid-nineties that we could
> compile a small application on the PC using gForth in only
> fifteen seconds while the same thing took over five minutes
> in ProForth for Windows. It is a good thing the programs
> were small.
>
-Brad
Bernd Paysan
> Forth Inc. kept insisting that MPE should support the
> product because they wrote it and MPE insisted that
> Forth Inc. should support it because they sold it to us
> and took our money. Both companies insisted that
> support was simply not their responsibility.
It's pretty obvious that you should buy from the maker to get support ;-).
> We got support from Tom Zimmer on Win32Forth within
> hours for free and found that gForth worked well too.
And the best support is the one you don't need at all, because it just
works.
--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/
Paul Rubin
it: a $50 programmable wristwatch development kit from TI.
http://processors.wiki.ti.com/index.php/EZ430-Chronos
the intended application is a sports watch with things like a pedometer
and heart rate monitor, but it seems like a good Forth host. The watch
includes:
- MPS430 20 mhz 16-bit processor with
- 32K of flash and 4K of ram
- 11-cycle 32x32=64 hw multiplier (16x16 is faster)
and 180 cycle hw AES encryption
- 3 axis accelerometer, useful for pedometer, gesture recognition etc.
- temperature sensor
- 250 kbit low powered RF comms, range of a few feet, can communicate
with chest sensor (heart rate), bicycle-mounted sensor, or a USB
dongle (included) plugged into a PC
- pressure sensor (touch screen I guess)
- 96 segment numeric (not dot matrix) lcd display
- 30m water resistance
Unfortunately the RF is some Zigbee-like thing and not Bluetooth. It
would be awesome if the watch could communicate directly with a
Bluetooth-equipped PC or cellular phone with no extra RF crap.
Anyway, the CPU looks like a very plausible Forth target, so I thought
I'd mention it here. It comes with various C development tools but
I didn't notice anything about Forth in the stuff I looked at.
Wayne
wrote:
> Maybe this has been mentioned here before but I don't remember seeing
> it: a $50 programmable wristwatch development kit from TI.
>
> http://processors.wiki.ti.com/index.php/EZ430-Chronos
>
> the intended application is a sports watch with things like a pedometer
> and heart rate monitor, but it seems like a good Forth host. The watch
> Anyway, the CPU looks like a very plausible Forth target, so I thought
> I'd mention it here. It comes with various C development tools but
> I didn't notice anything about Forth in the stuff I looked at.
Somewhere recently I mentioned my desire to do a watch based on a GA chip
with a bit of a dot matrix display (though some of the extra features of
the TI chip would be handy if they were available separately to use with
GA). What do you think of the GA, I think the GA would stretch enough?
There are also plenty of color java mobile phone watches out there on
ebay, some for less than $100 and I think many ARM based ones.
I wish you the best on your adventures, it is an idea who's time has come,
not to mention there are some serial executable flash memories and Forth
based GUI OS's out there ;) .
Thanks
Wayne.
forth...@forthfiles.net
I had the pleasure of meeting with TI last week and had a demo of the
Beagle Board (awesome piece of kit) and also the MSP430.
They had an MSP430 based digital watch, which was linked wirelessly to
the Beagle Board. The Beagle Board, running a Debian flavour of Linux
(IIRC) was sporting a full GUI and showing a real-time projection of
where the watch was in 'space' (X Y & Z) as well as accelerometer
data.
Pretty impressive for a little watch.
Regarding the MSP430, it's very suitable for a Forth. Well, certainly
no less suitable than other contemporary processors. It has a small
instruction set, I can't remember how many now, but significantly less
than the TMS9900, which has 69. I think the MSP430 has ~30ish
instructions.
In terms of it's instruction set, it's actually similar to the 99xx
family. In typical TI fashion, there are loads of variants with
varying amounts of memory, and peripherals. Selecting the right part
is complicated. There is a free assembler (and other tools) available.
A nice part.
foxchip
> Maybe this has been mentioned here before but I don't remember seeing
> it: a $50 programmable wristwatch development kit from TI.
>
> http://processors.wiki.ti.com/index.php/EZ430-Chronos
There is a presentation on a Forth for that watch scheduled
for SVFIG next month.
Best Wishes
Paul Rubin
> Somewhere recently I mentioned my desire to do a watch based on a GA
> chip with a bit of a dot matrix display (though some of the extra
> features of the TI chip would be handy if they were available
> separately to use with GA). What do you think of the GA, I think the
> GA would stretch enough?
I don't think the GA makes sense for this purpose, because of the amount
of external stuff you'd need, plus the difficulty of writing interesting
wristwatch apps in 64 words of code per node. The TMS430 in the watch
has a much higher level of integration including 32k of program flash,
4k of ram, hardware multiplier, and hardware AES encryption, as
described earlier.
> There are also plenty of color java mobile phone watches out there on
> ebay, some for less than $100 and I think many ARM based ones.
I think those are basically normal GSM phones strapped to your wrist,
that are huge, have to be recharged every day and all that sort of
thing. This TI is more like a normal watch, normal looking and runs on
a watch battery for years if you don't use the power-hungry features
(wireless communications, heavy computation) too often. I'm thinking of
it as a cryptographic authentication token or cell phone tether, so it
would typically only be doing power-hungry operations maybe a dozen
times per day, each lasting a few seconds tops.
rickman
> Wayne <news_putmynamehere...@optusnet.com.au> writes:
> > Somewhere recently I mentioned my desire to do a watch based on a GA
> > chip with a bit of a dot matrix display (though some of the extra
> > features of the TI chip would be handy if they were available
> > separately to use with GA). What do you think of the GA, I think the
> > GA would stretch enough?
>
> I don't think the GA makes sense for this purpose, because of the amount
> of external stuff you'd need, plus the difficulty of writing interesting
> wristwatch apps in 64 words of code per node. The TMS430 in the watch
> has a much higher level of integration including 32k of program flash,
> 4k of ram, hardware multiplier, and hardware AES encryption, as
> described earlier.
The code size is not a limitation. The GA chips can execute code from
an off chip source, which I believe can be a serial flash. I don't
see any details on this, but they do mention it in some of the docs.
I'm not sure why you mention the 4 kB of RAM on the MSP430 as the
GA144 has more than that. The hardware multiplier is irrelevant as
the F18 CPU can run rings around the MSP even doing the multiply one
bit at a time. Ditto the AES encryption I would be willing to bet.
The flash is worth mentioning, but only in that the GA parts require a
separate flash to boot from. That's not really a big deal unless
there is a serious space constraint. But for a watch, the main
limitations are 1) Cost and 2) I/O count. The GA144 may have enough I/
O to drive a watch LCD, but the GA4 and likely the GA32 won't have
enough for a useful watch with time and other features to control.
Rick
Paul Rubin
> I'm not sure why you mention the 4 kB of RAM on the MSP430 as the
> GA144 has more than that.
I'd have expected the GA144 was too big and uses too much power for a
watch. I thought we were talking about the GA4.
> The hardware multiplier is irrelevant as the F18 CPU can run rings
> around the MSP even doing the multiply one bit at a time.
I'm skeptical of that, at the power levels we're talking about.
> Ditto the AES encryption I would be willing to bet.
If the GA MD5 implementation is anything to go by, I have doubts
about that too, but I suppose it's possible.
> The flash is worth mentioning, but only in that the GA parts require a
> separate flash to boot from. That's not really a big deal unless
> there is a serious space constraint. But for a watch, the main
> limitations are 1) Cost and 2) I/O count.
I think space is relevant in a watch too ;-). The MPS also has a bunch
of on-chip mixed signal stuff, used for the wireless comms and so forth.
rickman
> rickman <gnu...@gmail.com> writes:
> > I'm not sure why you mention the 4 kB of RAM on the MSP430 as the
> > GA144 has more than that.
>
> I'd have expected the GA144 was too big and uses too much power for a
> watch. I thought we were talking about the GA4.
I'm not sure we are talking about a real watch or the TI "watch".
Once you start adding features like wireless, it is no longer a watch
and you can't expect it to resemble one. For example, the battery is
drained at about a 1 uA rate by a watch. If you add wireless it only
has to be used for maybe 10 seconds a day before it will cut the
battery lifetime significantly. In reality, you wouldn't use either
device for a watch since a standard watch chip will do the job and
cost a small fraction of either part.
Still, how much ram do you need to operate a watch? I think a couple
dozen bytes would do the job. One of the four processors on a GA4
could do the computations. The problem with a GA4 is the I/O count.
It has less than a dozen I/O, 10 I think.
> > The hardware multiplier is irrelevant as the F18 CPU can run rings
> > around the MSP even doing the multiply one bit at a time.
>
> I'm skeptical of that, at the power levels we're talking about.
But you haven't done any work to verify it... Check out the MSP430
white paper on the GA web site. They compare the two devices in great
detail and in general the GA chip is lower power for doing the same
work. The F18A CPU uses only 55 nA while idle and there is no clock
to be concerned with drawing power while the processor is idle due to
the async clock design. So what is important is how much work is to
be done since there is virtually no power being wasted while the CPU
is idle.
The white paper says the F18A uses about 47 times less energy to
perform a simple op like an ADD. They estimate the F18A multiply
routine uses 5 times less energy and they are being conservative by
using the typical power level for the MSP430 without accounting for
engaging the multiply hardware.
Everything I've read about the GA chips is impressive. I just wish I
knew more about how to use them. With the tiny RAM I can see it may
be a challenge to learn to program them.
One possible exception is the analog I/O. They use counters to
perform the ADC conversion which seems to work like an integrating
converter. This is great for eliminating noise, but it only gets you
16 bits if you run under 60 kHz sample rate (and it may be more like
30 kHz). I guess that's not a big limitation. Otherwise it is a the
best compromise between high resolution and fast speed I've seen in a
CPU. That is one of the issues I have with the SmartFusion chips from
Actel. The digital does a good job of being everything to everyone.
The analog, not so much. Most chips give you a speed and a max
resolution with little to trade off. If either one doesn't work for
you, forget it. The GA approach is much more flexible.
I haven't found anything on the analog output. I assume they intend
for it to be PWM, possibly sigma-delta modulated. But there are
problems with that unless you have a good analog driver. I think the
GA144 has a separate analog voltage pin labeled +a, but I can't be
sure. The power labeling is not explained that I can find. They show
+a, +c and +i. I expect the +c is core Vdd and the +i is I/O Vdd and
the die attach paddle is the only ground. The GA4 seems to have only
Vcc and ground with nothing separate for analog. So it will be
interesting to see what sort of analog I/O they can produce from
this.
> > Ditto the AES encryption I would be willing to bet.
>
> If the GA MD5 implementation is anything to go by, I have doubts
> about that too, but I suppose it's possible.
Why? What info do you have on the MD5 implementation?
> > The flash is worth mentioning, but only in that the GA parts require a
> > separate flash to boot from. That's not really a big deal unless
> > there is a serious space constraint. But for a watch, the main
> > limitations are 1) Cost and 2) I/O count.
>
> I think space is relevant in a watch too ;-). The MPS also has a bunch
> of on-chip mixed signal stuff, used for the wireless comms and so forth.
But the GA4 is only 2 x 2 mm and you can get very tiny flash
memories. I can't see that being a problem for even spy hardware...
hmmm... very tiny size, very low power, spy gadgets would actually be
a real showcase app except you'd have to kill everyone you showed it
to!
Rick
Paul Rubin
> I'm not sure we are talking about a real watch or the TI "watch".
TI.
> Once you start adding features like wireless, it is no longer a watch
> and you can't expect it to resemble one. For example, the battery is
> drained at about a 1 uA rate by a watch. If you add wireless it only
> has to be used for maybe 10 seconds a day before it will cut the
> battery lifetime significantly.
The wireless i/o runs at 250 kbit/sec so in one obvious setup as a
cryptographic authentication token, receiving a 1024 bit challenge text
and sending a 1024 bit digital signature takes 4 milliseconds each way.
If you do that to log into your cell phone 100 times a day, that's 0.8
seconds per day of wireless time, not too bad.
Anyway, you may be overestimating the amount of power needed by the
radio. Think of bluetooth cellular phone earpieces, which run for weeks
(standby) or quite a few hours (talk) on batteries with less capacity
than the coin cell in the watch. I believe the watch uses that
Zigbee-like wireless because it takes even less power than bluetooth.
I'd have preferred bluetooth anyway, for interoperation with cell pones.
> Still, how much ram do you need to operate a watch? I think a couple
> dozen bytes would do the job.
One of the TI applications is a heart rate monitor. The watch receives
wireless data from a chest strap sensor, so logging your heart rate
every few seconds during a workout might use a kilobyte or so per hour.
At the end of the workout you'd upload the log to your computer.
For crypto, I might want a few hundred bytes of keys and related info.
Having 4k available makes it possible to program in a fairly
unconstrained style.
> But you haven't done any work to verify it... Check out the MSP430
> white paper on the GA web site. They compare the two devices in great
> detail and in general the GA chip is lower power for doing the same
> work.
Hmm, ok, I'd forgotten that paper, but I'd want to see some more
detailed comparisons, preferably independent, to not be slanted in the
GA's favor. E.g. the multiplication comparison assumes 4 cycles to move
data in and out of registers for each multiplication on the MSP430, but
for a typical DSP or cryptographic calculation you wouldn't do it that
way, you'd have a bunch of MAC's into a wide accumulator.
> They estimate the F18A multiply routine uses 5 times less energy and
> they are being conservative by using the typical power level for the
> MSP430 without accounting for engaging the multiply hardware.
But they are counting twice as many MSP430 cycles than they've shown are
really needed. Maybe they're right and I'm missing something, but I'd
have to see a detailed code comparison to be convinced.
Anyway though, as you say, running the radio probably swamps out cpu
power consumption in most applications doing anything interesting.
>> If the GA MD5 implementation is anything to go by, I have doubts
>> about that too, but I suppose it's possible.
> Why? What info do you have on the MD5 implementation?
There is an article about it on the GA site and it's informative and
repulsive at the same time ;-).
> But the GA4 is only 2 x 2 mm and you can get very tiny flash
> memories. I can't see that being a problem for even spy hardware...
Right, the GA4 makes more sense for a wristwatch than the GA144.
Although, it would be more attractive if they did a more SOC-like
version with lots more ram and some flash per node. I also wonder if
they could have applied that low-power asynchronous CPU approach to a
conventional architecture instead of the F18.
rickman
> rickman <gnu...@gmail.com> writes:
> > I'm not sure we are talking about a real watch or the TI "watch".
>
> TI.
>
> > Once you start adding features like wireless, it is no longer a watch
> > and you can't expect it to resemble one. For example, the battery is
> > drained at about a 1 uA rate by a watch. If you add wireless it only
> > has to be used for maybe 10 seconds a day before it will cut the
> > battery lifetime significantly.
>
> The wireless i/o runs at 250 kbit/sec so in one obvious setup as a
> cryptographic authentication token, receiving a 1024 bit challenge text
> and sending a 1024 bit digital signature takes 4 milliseconds each way.
> If you do that to log into your cell phone 100 times a day, that's 0.8
> seconds per day of wireless time, not too bad.
>
> Anyway, you may be overestimating the amount of power needed by the
> radio. Think of bluetooth cellular phone earpieces, which run for weeks
> (standby) or quite a few hours (talk) on batteries with less capacity
> than the coin cell in the watch. I believe the watch uses that
> Zigbee-like wireless because it takes even less power than bluetooth.
> I'd have preferred bluetooth anyway, for interoperation with cell pones.
I think we have some disagreement here. A watch runs for a year or
more on a 150 mAHr, 1.5 V cell and a bluetooth device runs for a few
of weeks on a LiIon cell with about the same power capacity. Or if it
is used for talking it only runs for a few hours.
I guess I'm kind of lost as to what the point is. If you add other
devices, the power profile changes dramatically depending on the
application. What are we discussing exactly?
> > Still, how much ram do you need to operate a watch? I think a couple
> > dozen bytes would do the job.
>
> One of the TI applications is a heart rate monitor. The watch receives
> wireless data from a chest strap sensor, so logging your heart rate
> every few seconds during a workout might use a kilobyte or so per hour.
> At the end of the workout you'd upload the log to your computer.
>
> For crypto, I might want a few hundred bytes of keys and related info.
> Having 4k available makes it possible to program in a fairly
> unconstrained style.
Ok, but that is not a watch anymore. I can't say 4 kB is
"unconstrained". Again, I'm lost as to what the point is. The MSP430
is not exactly the same as the GA144 or the GA4. If you want to
discuss the suitability of the GA parts for an app, what app are you
referring to?
> > But you haven't done any work to verify it... Check out the MSP430
> > white paper on the GA web site. They compare the two devices in great
> > detail and in general the GA chip is lower power for doing the same
> > work.
>
> Hmm, ok, I'd forgotten that paper, but I'd want to see some more
> detailed comparisons, preferably independent, to not be slanted in the
> GA's favor. E.g. the multiplication comparison assumes 4 cycles to move
> data in and out of registers for each multiplication on the MSP430, but
> for a typical DSP or cryptographic calculation you wouldn't do it that
> way, you'd have a bunch of MAC's into a wide accumulator.
And with the 5 to 1 advantage reduced by a factor of 4 the F18 still
comes out on top without measuring the extra power used by the
multiplier.
> > They estimate the F18A multiply routine uses 5 times less energy and
> > they are being conservative by using the typical power level for the
> > MSP430 without accounting for engaging the multiply hardware.
>
> But they are counting twice as many MSP430 cycles than they've shown are
> really needed. Maybe they're right and I'm missing something, but I'd
> have to see a detailed code comparison to be convinced.
>
> Anyway though, as you say, running the radio probably swamps out cpu
> power consumption in most applications doing anything interesting.
Certainly transmit power is not trivial. Receivers can be pretty
light, but that is usually done by using a low duty cycle.
> >> If the GA MD5 implementation is anything to go by, I have doubts
> >> about that too, but I suppose it's possible.
> > Why? What info do you have on the MD5 implementation?
>
> There is an article about it on the GA site and it's informative and
> repulsive at the same time ;-).
I didn't see that one. What is repulsive about it?
> > But the GA4 is only 2 x 2 mm and you can get very tiny flash
> > memories. I can't see that being a problem for even spy hardware...
>
> Right, the GA4 makes more sense for a wristwatch than the GA144.
> Although, it would be more attractive if they did a more SOC-like
> version with lots more ram and some flash per node. I also wonder if
> they could have applied that low-power asynchronous CPU approach to a
> conventional architecture instead of the F18.
I think having more RAM would defeat the design. There is more RAM on
the GA144 than on many of the MSP430s, but that depends on the model,
no? Some MSP devices have more others less. Same with the GA
devices.
I don't know how an application needs to be broken down to run well on
the GA chips, but I expect it is a bit like the stack usage. If you
work on small pieces you don't need so much. But it may require
swapping out to external RAM. They seem to cover the memory interface
in several places, specifically an SDRAM interface. They mention 40
mW of overhead when running. SDRAM has very low power standby modes,
particularly mobile SDRAM. The GA doc doesn't seem to cover that.
They also mention that a static RAM would be lower power due to the
absence of refresh.
It looks like the GA144 will be the first part out of the door at GA.
I wonder how far behind the GA4 and GA32 will be? I am giving thought
to the idea of putting together an eval board for the GA4. That could
be seriously tiny and low power! At full speed the GA4 will use less
than 20 mW and that is around 2800 MIPS!!! Even if half the
processing capability is wasted on I/O this is still an amazing
device. I just need to learn how to use it.
Rick
Paul Rubin
> I think we have some disagreement here. A watch runs for a year or
> more on a 150 mAHr, 1.5 V cell and a bluetooth device runs for a few
> of weeks on a LiIon cell with about the same power capacity.
The TI watch uses a CR2032 lithium coin cell which is about 220 mah, 3V,
if that matters. Bluetooth headsets go as low as 70mah, 3.7v.
>> For crypto, I might want a few hundred bytes of keys and related info.
>> Having 4k available makes it possible to program in a fairly
>> unconstrained style.
>
> Ok, but that is not a watch anymore. I can't say 4 kB is
> "unconstrained". Again, I'm lost as to what the point is.
By "unconstrained" I just mean I can program small apps in a natural
style, not trying to squeeze out single bits and cycles all over the
place.
> The MSP430 is not exactly the same as the GA144 or the GA4. If you
> want to discuss the suitability of the GA parts for an app, what app
> are you referring to?
Here is an obvious app for the watch: you want to sign your laptop onto
a secure remote computer using an SSL or SSH private key contained in
the watch (so that if someone gets accessed to the laptop, they don't
get the key). You start the SSL client on your laptop and press a
button on the watch, the lapop sends a 1 kilobit packet to the watch,
the watch does an RSA decryption and sends back the 1 kilobit result.
So this operation uses a few milliseconds of RF transmission time plus a
second or so of DSP-like computation on the watch. The watch itself
needs a few hundred bytes of keys and a few hundred more bytes of ram
for temporary results.
> And with the 5 to 1 advantage reduced by a factor of 4 the F18 still
> comes out on top without measuring the extra power used by the multiplier.
I'd like to see some actual measurements before believing in that 5:1
advantage. The GA code that I looked at burned an awful lot of cycles
shuffling stuff between cpu's or juggling the stack, that would have
been no-ops on a conventional processor with registers. GA programs
also going to have to spend a lot of time loading and unloading program
code.
> [MD5] I didn't see that one. What is repulsive about it?
http://www.greenarraychips.com/home/documents/pub/AP001-MD5.html
> I think having more RAM would defeat the design. There is more RAM on
> the GA144 than on many of the MSP430s,...
Yes but it's scattered across all the nodes. I mean more RAM to be
able to run reasonable sized programs without having to constantly
shuffle code in and out of a 64 word window.
> At full speed the GA4 will use less than 20 mW and that is around 2800
> MIPS!!! Even if half the processing capability is wasted on I/O this
> is still an amazing device. I just need to learn how to use it.
I'll be interested in seeing how that works out. I'm not a hardware guy
but I can understand the notion that GA has made some interesting
technical advances in low powered hardware. They then apply those
advances to what seems to me to be a very cumbersome and limited CPU
architecture. It would be neat if they could also apply the low power
technology to a more usable architecture.
Albert van der Horst
Paul Rubin <no.e...@nospam.invalid> wrote:
<SNIP>
>
>I'd like to see some actual measurements before believing in that 5:1
>advantage. The GA code that I looked at burned an awful lot of cycles
>shuffling stuff between cpu's or juggling the stack, that would have
>been no-ops on a conventional processor with registers. GA programs
>also going to have to spend a lot of time loading and unloading program
>code.
You have to adapt your coding style if not way of thinking to those
chips. I've been actually coding a parallel sieve, and cannot confirm
your speculations here.
Note that the parallel sieve has the functionality of a program that
requires an array of 130,000 elements in conventional coding. I didn't
use any storage *at all*, even the primes remembered stay on the stack
all the time.
So put up your sleeves. The arrayforth simulator is available for
free, no need to wait for the chips.
<SNIP>
>
>I'll be interested in seeing how that works out. I'm not a hardware guy
>but I can understand the notion that GA has made some interesting
>technical advances in low powered hardware. They then apply those
>advances to what seems to me to be a very cumbersome and limited CPU
>architecture. It would be neat if they could also apply the low power
>technology to a more usable architecture.
Rephrased, let's insist on "programming FORTRAN in any language".
Groetjes Albert
rickman
wrote:
> In article <7x7hh2wdop....@ruckus.brouhaha.com>,
> Paul Rubin <no.em...@nospam.invalid> wrote:
> <SNIP>
> >I'd like to see some actual measurements before believing in that 5:1
> >advantage. The GA code that I looked at burned an awful lot of cycles
> >shuffling stuff between cpu's or juggling the stack, that would have
> >been no-ops on a conventional processor with registers. GA programs
> >also going to have to spend a lot of time loading and unloading program
> >code.
Stack juggling may seem like wasted ops, but there can be a lot of
inefficiency in loading and storing registers as well. If you don't
believe the benchmarks others have done, don't try to second guess
with half information. If you want to know then put some effort into
it. Don't keep knocking the design without knowing any facts.
> >I'll be interested in seeing how that works out. I'm not a hardware guy
> >but I can understand the notion that GA has made some interesting
> >technical advances in low powered hardware. They then apply those
> >advances to what seems to me to be a very cumbersome and limited CPU
> >architecture. It would be neat if they could also apply the low power
> >technology to a more usable architecture.
>
> Rephrased, let's insist on "programming FORTRAN in any language".
That is clearly a problem with a new, unique architecture, users have
to learn how to use it. I wonder myself how this design will work in
the real world. Also, how will it work in the hands of those who
aren't used to thinking in the way necessary to use these parts. You
have to admit that a 64 word RAM will be a major barrier to apps that
require large programs. We really haven't seen much info on how
performance will be impacted by these issues.
I also am curious about how the comms is intended to work. If a
processor "sends" a message to another, does it stop as soon as the
first word is written to the port, or does it stop only when a first
word has been written and not read or does it stop as soon as the
first word is written and idles until that word is read?
Rick
Paul Rubin
> If you don't believe the benchmarks others have done, don't try to
> second guess with half information. If you want to know then put some
> effort into it. Don't keep knocking the design without knowing any
> facts.
Er, I'm saying I want to see benchmarks before believing anything.
What benchmarks do you know of that have actually been done? That
paper comparison with the MSP430 is not a benchmark, it is handwaving.
Benchmark means running actual application code on real devices and
making actual measurements, and AFAIK that has not been done so far.
rickman
How is it hand waving? It is exactly the sort of comparison I would
do before getting serious with evaluation. They aren't even shipping
chips yet, do you really expect them to have test cases with
applications? As others have said the development software is
available and you can look at the code generated for your
application.
I see a problem with their marketing in that they don't seem to be
targeting any market segment. Even if a device is being marketed
widely, it is very common to provide app notes and even eval boards
for your expected markets. I would be very interested in developing
eval boards, but I can't figure out what the markets will be.
Rick
Paul Rubin
>> paper comparison with the MSP430 is not a benchmark, it is handwaving.
It's handwaving because they didn't measure the speed or power
consumption of any real programs. They just did a theoretical
calculation of the energy costs of a few individual instructions and
operations.
> They aren't even shipping chips yet, do you really expect them to have
> test cases with applications?
They're not shipping chips to customers but they have some in their own
facilities and yes, I expect them to test applications on them.
The one code sample I've seen from them is the MD5 hash function, so
that will do for a start. Their application note says MD5 benchmarks
are forthcoming, so I'm awaiting the results with interest.
> As others have said the development software is available and you can
> look at the code generated for your application.
I'd like to see benchmarks before I even consider expending my own
resources to application development. If the gurus who designed the
chips aren't capable of writing some sample applications and testing
them, then I have no hope of it.
> I would be very interested in developing eval boards, but I can't
> figure out what the markets will be.
Me either. We sort of had this discussion already, but most
applications I can think of that want monstrous amounts of computation
also want DSP-like capabilities.
rickman
> rickman <gnu...@gmail.com> writes:
> >> paper comparison with the MSP430 is not a benchmark, it is handwaving.
> > How is it hand waving?
>
> It's handwaving because they didn't measure the speed or power
> consumption of any real programs. They just did a theoretical
> calculation of the energy costs of a few individual instructions and
> operations.
Yes, I am aware of that, but I still don't think it is "hand waving".
That term implies that they aren't discussing any relevant facts. But
then I guess you are saying their analysis is not "relevant". I don't
really agree with that as this may only be a first order
approximation, it is highly useful because of the degree of
difference. But we will see for sure once someone does develop and
app for their device. The problem is who will develop the same app
for the MS430?
> > They aren't even shipping chips yet, do you really expect them to have
> > test cases with applications?
>
> They're not shipping chips to customers but they have some in their own
> facilities and yes, I expect them to test applications on them.
I would love to see some specific info on apps, but it is way too
early for that. I would not expect to see details that you would not
call hand waving until the first chips ship. Until they I expect they
have higher priority tasks at hand.
> The one code sample I've seen from them is the MD5 hash function, so
> that will do for a start. Their application note says MD5 benchmarks
> are forthcoming, so I'm awaiting the results with interest.
You never did say what you didn't like about the MD5 hash information
they did supply. Can you give any specifics?
> > As others have said the development software is available and you can
> > look at the code generated for your application.
>
> I'd like to see benchmarks before I even consider expending my own
> resources to application development. If the gurus who designed the
> chips aren't capable of writing some sample applications and testing
> them, then I have no hope of it.
You know it is not an issue of their being "capable", but rather their
being available. That will all come in time.
> > I would be very interested in developing eval boards, but I can't
> > figure out what the markets will be.
>
> Me either. We sort of had this discussion already, but most
> applications I can think of that want monstrous amounts of computation
> also want DSP-like capabilities.
I was giving this some thought. The lack of a single cycle multiply
instruction can limit performance for classic DSP, but I expect that
is not such an issue with 144 processors on a chip. A FIR filter can
easily be broken down into parallel tasks as can an FFT. I don't know
how many cycles the multiply takes, but it looks like the F18 can do
at least 10 MMACS. Using just 64 of the CPUs for this would result in
640 MMACS. That is comparable to the high end DSP chips but at lower
power levels.
I think the key limiter will be the size of the RAM. An external RAM
can be attached, but this may mitigate some of the advantages... not
sure. Their power analysis shows that even with an SDRAM attached,
this chip is very low power. That seems to be the key advantage. So
a cell phone base station app may do better with the C64xx chips they
are currently using, but a cell phone may do better with a GA chip.
But then again, a base station might gain some significant advantage
using such a low power device in place of the typical barn burner
chips from TI.
Actually, those are the technical issues which may limit the utility
of the GA devices. But I am pretty sure the real limiting factor to
the adoption of the GA devices is just the fact that they are so
different from the mainstream. Even if a few key apps are implemented
using the GA devices, how much inertia is there behind the current way
of doing DSP and similar apps?
One place where I don't expect much inertia is in the toy market.
From what I have read from those who design for that market, they
don't give a rat's rear how you do it. The designers seem to be an
independent crowd who do what they want as long as they get results.
It would be very possible that one of the first high volume apps for
the GA chips will be done by a toy maker. But then you may never hear
about it since they are more secret than the CIA...
BTW, the starting price for qty 10 GA144 chips is $20 each. I wonder
what the GA4 chips will cost? I'm very interested in the GA32 chip,
but they aren't even talking about hardware for that one yet. I just
saw the part mentioned in one of the app notes somewhere. I expect it
would have 20 CPUs on the periphery and could have up to 40 I/Os
perhaps? I see some periphery nodes have up to 4 I/Os, maybe they
will put 4 I/Os on each and give us 80 I/Os for the package. That
would be more MCU-like. Oh well, just random thoughts. I'll just
have to wait for the designs to jell and parts materialize.
Rick
Albert van der Horst
rickman <gnu...@gmail.com> wrote:
>On Oct 29, 2:12=A0pm, Paul Rubin <no.em...@nospam.invalid> wrote:
>> rickman <gnu...@gmail.com> writes:
>> >> paper comparison with the MSP430 is not a benchmark, it is handwaving.
>> > How is it hand waving?
>>
>> It's handwaving because they didn't measure the speed or power
>> calculation of the energy costs of a few individual instructions and
>> operations.
>
>Yes, I am aware of that, but I still don't think it is "hand waving".
>That term implies that they aren't discussing any relevant facts. But
>then I guess you are saying their analysis is not "relevant". I don't
>really agree with that as this may only be a first order
>approximation, it is highly useful because of the degree of
>difference. But we will see for sure once someone does develop and
>app for their device. The problem is who will develop the same app
>for the MS430?
Exactly. We have now completed the parallel pi program for the
GA144 with two generators. This runs in the emulator in 130,000
cycles for 10,000 primes and 1M3 for 100,000 primes, using
half of the GA144 plus 13 nodes. This translates to 1,3 mS or
let's say a couple of milliseconds.
Now comes the fun part, shaving of a few cycles here and there, using
8 generators for an expected speed up of 5. (As a reference the
infamous byte benchmark (sieve of 8000) takes 50 mS on my Pentium 90
in lina).
Nice touch, it is superlinear, 10 times as much sieving cost last
than 10 times as long.
This is not some pie-in-the-sky stuff. A very similar program
has run on the SEAFORTH chip. That is not an emulator, but
real silicon.
Now where can we find some one who would program some (whatever) sieve
program on the MS430? Just to find out that the chip is beaten? Sorry
but Ruby's handwaving about how the MS430 may be better is not good
enough.
The ball is in the other court. You have to beat my 3 mS.
I claim the GA144 is superior. Prove me wrong.
>> > They aren't even shipping chips yet, do you really expect them to have
>> > test cases with applications?
>>
>> They're not shipping chips to customers but they have some in their own
>> facilities and yes, I expect them to test applications on them.
>
>I would love to see some specific info on apps, but it is way too
>early for that. I would not expect to see details that you would not
>call hand waving until the first chips ship. Until they I expect they
>have higher priority tasks at hand.
>
>
>> The one code sample I've seen from them is the MD5 hash function, so
>> that will do for a start. =A0Their application note says MD5 benchmarks
>> are forthcoming, so I'm awaiting the results with interest.
>
>You never did say what you didn't like about the MD5 hash information
>they did supply. Can you give any specifics?
>
>
>> > As others have said the development software is available and you can
>> > look at the code generated for your application.
>>
>> I'd like to see benchmarks before I even consider expending my own
>> resources to application development. =A0If the gurus who designed the
>> chips aren't capable of writing some sample applications and testing
>> them, then I have no hope of it.
>
>You know it is not an issue of their being "capable", but rather their
>being available. That will all come in time.
I can't believe Rubin is saying this. What is he thinking? That Chuck
Moore is designing a chip, that his own people can't write something
for? While *I* can get a reasonable idea based on their emulator.
<SNIP>
>
>Rick
Paul Rubin
> That term implies that they aren't discussing any relevant facts.
Nah, there were relevant facts that they pointed to and gestured at,
which is what makes it handwaving. With no relevant facts it would
have been mere smoke blowing ;-).
> But we will see for sure once someone does develop and app for their
> device. The problem is who will develop the same app for the MS430?
If there are no apps for the device, does that suggest that the device
itself is premature? I'm pretty sure that if a company such as Intel
develops a new cpu, they test many apps on it under simulation long
before they actually fab any silicon.
There is also the Seaforth chip, that had a similar architecture to
the GA. Maybe there are some benchmarks for that?
> I would love to see some specific info on apps, but it is way too
> early for that. I would not expect to see details that you would not
> call hand waving until the first chips ship. Until they I expect they
> have higher priority tasks at hand.
As above, I'd expect them to develop and test applications long before
any chips are made.
> You never did say what you didn't like about the MD5 hash information
> they did supply. Can you give any specifics?
Did you look at it? It is horrendously complex compared with a
traditional implementation. One could say the complexity is because the
MD5 algorithm is ill-suited to the GA architecture, but that suggests
the architecture has room for improvement.
> I was giving this some thought. The lack of a single cycle multiply
> instruction can limit performance for classic DSP, but I expect that
> is not such an issue with 144 processors on a chip.
Foxchip compared the GA144 to a traditional chip with 9 multipliers.
Of course it is up against large FPGA's with 100's of multipliers...
> A FIR filter can easily be broken down into parallel tasks as can an
> FFT. I don't know how many cycles the multiply takes, but it looks
> like the F18 can do at least 10 MMACS.
What's an MMAC? You mean multiply-accumulate? That would take 20
cycles or so on the F18, plus burn a big chunk of the available program
ram if the loop is unrolled (otherwise it uses more cycles), if I
understand it correctly.
> I think the key limiter will be the size of the RAM. An external RAM
> can be attached, but this may mitigate some of the advantages... not
> sure. Their power analysis shows that even with an SDRAM attached,
> this chip is very low power.
Which chip? The CPU? Don't forget that the ram chip also uses power,
and you want some external program flash as well, and that means more
power, especially since these parts now have to drive high-frequency
signals to other packages. And the extra packages mean more space,
more cost, etc. Back to the MPS430, that part includes flash and
ram and many other functions, whose power consumption is included
in the MPS430's spec. With the GA, all that stuff has to be added
up separately.
> Actually, those are the technical issues which may limit the utility
> of the GA devices. But I am pretty sure the real limiting factor to
> the adoption of the GA devices is just the fact that they are so
> different from the mainstream. Even if a few key apps are implemented
> using the GA devices, how much inertia is there behind the current way
> of doing DSP and similar apps?
It will be interesting if the GA can show really major advantages
compared with traditional parts.
>
> BTW, the starting price for qty 10 GA144 chips is $20 each. I wonder
> what the GA4 chips will cost?
I hope it will be competitive. Keep in mind that the MSP430 starts
around 35 cents in 1k quantity (qty 10 is not specified). A basic
"launchpad" development board is $4.30 (www.ti.com/launchpad-pr-es). It
makes me wonder why anyone messes with Arduinos.
John Passaniti
> The ball is in the other court. You have to
> beat my 3 mS. I claim the GA144 is superior.
> Prove me wrong.
I certainly understand that you have to walk before you can run. And
I appreciate the effort you're putting into learning this architecture
and reporting back what you've found. But what is the value of
parallel sieves and PI generators when benchmarking the GA144?
We know that the SeaForth and GA144 are likely going to target some
classes of DSP applications. And we know a central claim is that
software can replace hardware interfaces. So wouldn't it be a bit
more prudent to wait for claims of superiority when real-world
applications (or at least algorithms) that target those domains are
available? And as a bonus, while you might have some difficulty in
finding someone who is motivated to write a sieve or PI generator,
you'll likely have little difficulty finding code for something, ummm,
useful to compare against.