> Jim Granville <no.spam@designtools.co.nz> writes:
>
>
>> Seems they now have post-layout numbers (but still tagged
>>simulations), and as often happens, the reality is not quite what they
>>hoped, and the claimed power margins have taken a hit...
>> Next will be numbers from real silicon :)
>
>
> And there are some very interesting numbers which will not
> be available in a while. E.g., MIPS/$... The threshold of
> adopting a new processor is rather high. For a new architecture
> to be competitive, it has to have some real strenghts. Just
> being "nice" is not enough.
Very true.
Since they are 'beating the MIPS/mA drum', I thought I'd
reality check into what real & shipping 'better process 80C51 variants'
come in at :
MAXQ (Simulated) = 3.3MIPS/mA -> 330 MIPS/W
Cygnal devices (Avail for some time) = 600-1100 MIPS/W
Philips P87CL888 (also avail or some time) = 700 MIPS/Watt @ 3V,
climbing to 1800 MIPS/Watt at 2V
Guess that explains why these devices are missing from the MAXQ
comparison line-ups :)
The P87CL888 is interesting in that it is an ASYNC 80C51 - ie each
opcode executes as fast as the silicon allows, then it goes onto the
next. Result is automatic thermal/Vcc tracking, and max possible time
spent in IDLE.
>
> When talking about speed, there are devices like Philips LPC21xx
> series. They are not 8-bit chips but they are rather reasonably
> priced and very fast with rather skinny power budget. <snip>
.. and also now the new ADuC7xxx devices from ADi ....
-jg
Reply by Ville Voipio●March 18, 20042004-03-18
Jim Granville <no.spam@designtools.co.nz> writes:
> Seems they now have post-layout numbers (but still tagged
> simulations), and as often happens, the reality is not quite what they
> hoped, and the claimed power margins have taken a hit...
> Next will be numbers from real silicon :)
And there are some very interesting numbers which will not
be available in a while. E.g., MIPS/$... The threshold of
adopting a new processor is rather high. For a new architecture
to be competitive, it has to have some real strenghts. Just
being "nice" is not enough.
When talking about speed, there are devices like Philips LPC21xx
series. They are not 8-bit chips but they are rather reasonably
priced and very fast with rather skinny power budget. Or low-end
eight-bit processors (small PICs, many 51s, ATtinys) with price
tags below one dollar. At the moment the Maxim/Dallas processor
do not seem to compete in the mainstream. They are more aimed at
people who want faster '51. MAXQ must target an entirely different
market, as there is no existing user population.
It'll be interesting to see the first real commercially available
products "later this year".
- Ville
--
Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by Jim Granville●March 17, 20042004-03-17
Paul Curtis wrote:
> "Jim Granville" <no.spam@designtools.co.nz> wrote in message
> news:JQcZb.25252$ws.3092325@news02.tsnz.net...
>
>> Acillies Heel: Not enough info, but the fixed stack looks a problem
> area.
>
> The hardware stack is a synthesis "variable" constant.
Which means what, in terms of real silicon ?
To someone in the field who has just blown the stack limit,
being told the 'hardware stack is a synthesis "variable"
constant' might not give much comfort.... :)
>
>> They have one of the strangest OPCODE descriptions I have ever seen,
>>so it is not possible to detemine the reach-corners ( and thus at
>>what data-sizes your code suddenly gets bigger )
>
>
> The instruction set is simple. It's not the instruction set you need to
> worry about, it's the other bits.
The instruction set gives important clues on the code-knee regions -
ie those thresholds, where you run out of reach of one level of opcodes,
and need more.
To look the best in benchmarks, you choose code to run just under
those knees, but the real world is not as flexible..
> The encoding of instructions is simple
> and ortogonal, but the Maxim journal doesn't go into much detail, so you
> need to wait for that. However, C compilers should fit well on the micro,
> if they're sufficiently tuned to the architecture.
>
>
>> Telling Omission ?: No benchmarks with 80C51, and eZ8 devices. Both
>>these have direct memory access opcodes, and the Z8 also includes a
>>register frame pointer. For the small data sets of embedded
>>microcontrollers, this makes for smaller code size.
>
>
> The controller is quite capable of running code at lightning speed. Its
> features are a real hoot!
You seem to know more than what MAXIM have published, I'll track this
with interest.
I still call it a brave move, esp. from someone like Maxim with
no previous own-processor track record, and unused to that market space.
-jg
Reply by Jim Granville●March 17, 20042004-03-17
Ville Voipio wrote:
> Jim Granville <no.spam@designtools.co.nz> writes:
>> Telling Omission ?: No benchmarks with 80C51, and eZ8 devices. Both
>>these have direct memory access opcodes, and the Z8 also includes a
>>register frame pointer. For the small data sets of embedded
>>microcontrollers, this makes for smaller code size.
>
>
> I think these omissions are due to two different reasons. The eZ8 is
> omitted because it is not one of the mainstream 8-bitters (AVR,
> PIC, MCS51). There are a lot of more or less promising cores
> around, and only a few were shown in the data. Naturally, MAXQ
> is positioned against (and among) the big players. It is not
> convincing to show that MAXQ is better than some medium or
> small player. (This does not rule out the possibility that MAXQ
> might lose when compared to some smaller architectures.)
>
> The question about '51 is more interesting, because (AFAIK) 51-based
> processors are the most common; very many manufacturers, numerous
> models, etc.
>
> However, one of the variant manufacturers is Dallas (i.e. Maxim), and
> I guess they'd hate to show any graphs where their processors are not
> winners. Especially the original '51 is dead slow at 12 cycles per
> instruction. The one-cycle versions are a lot more competitive but not
> necessarily winners in all cases.
You could be right, there will be internal politics...
Dallas(Maxim) have just released a family of Single Clock 89C51
variants, extending from their 89C420. Cygnal are now routinely
at 50-100MHz speeds.
> In other words, Maxim could not find tests where MAXQ would have
> been the best and '51 second best with safe margin to others :)
I also see their MAXQ document has been revised, perhaps after my
comments pointing to " Simulations � replace with MAXQ2000 post layout
sim numbers "
Seems they now have post-layout numbers (but still tagged
simulations), and as often happens, the reality is not quite what they
hoped, and the claimed power margins have taken a hit...
Next will be numbers from real silicon :)
Single clock jumps are nice, but this can come at the cost of a more
complex path, and so reduced MAX clock speeds can result.
Thus real MHz from real devices will be revealing, when it arrives...
-jg
Reply by Ville Voipio●March 17, 20042004-03-17
Jim Granville <no.spam@designtools.co.nz> writes:
> Telling Omission ?: No benchmarks with 80C51, and eZ8 devices. Both
> these have direct memory access opcodes, and the Z8 also includes a
> register frame pointer. For the small data sets of embedded
> microcontrollers, this makes for smaller code size.
I think these omissions are due to two different reasons. The eZ8 is
omitted because it is not one of the mainstream 8-bitters (AVR,
PIC, MCS51). There are a lot of more or less promising cores
around, and only a few were shown in the data. Naturally, MAXQ
is positioned against (and among) the big players. It is not
convincing to show that MAXQ is better than some medium or
small player. (This does not rule out the possibility that MAXQ
might lose when compared to some smaller architectures.)
The question about '51 is more interesting, because (AFAIK) 51-based
processors are the most common; very many manufacturers, numerous
models, etc.
However, one of the variant manufacturers is Dallas (i.e. Maxim), and
I guess they'd hate to show any graphs where their processors are not
winners. Especially the original '51 is dead slow at 12 cycles per
instruction. The one-cycle versions are a lot more competitive but not
necessarily winners in all cases.
In other words, Maxim could not find tests where MAXQ would have
been the best and '51 second best with safe margin to others :)
- Ville
--
Ville Voipio, Dr.Tech., M.Sc. (EE)
Reply by Paul Curtis●March 17, 20042004-03-17
"Robert Reimiller" <bob@certsoft.com> wrote in message
news:65c9308c.0402191804.1add1982@posting.google.com...
> Leon Heller <aqzf13@dsl.pipex.com> wrote in message
> > I've just received some info on the new Maxim MAXQ microcontroller.
>
> I noticed that they compared their architecture against PIC16 instead
> of PIC18 to make theirs look better.
However you look at it, if you set the MAXQ up correctly, it'll do quite a
lot in a small code space. It'd beat PIC18 too, I reckon, but I haven't
written a PIC18 compiler, it's just a thought experiment.
-- Paul.
Reply by Paul Curtis●March 17, 20042004-03-17
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:JQcZb.25252$ws.3092325@news02.tsnz.net...
> Acillies Heel: Not enough info, but the fixed stack looks a problem
area.
The hardware stack is a synthesis "variable" constant.
> They have one of the strangest OPCODE descriptions I have ever seen,
> so it is not possible to detemine the reach-corners ( and thus at
> what data-sizes your code suddenly gets bigger )
The instruction set is simple. It's not the instruction set you need to
worry about, it's the other bits. The encoding of instructions is simple
and ortogonal, but the Maxim journal doesn't go into much detail, so you
need to wait for that. However, C compilers should fit well on the micro,
if they're sufficiently tuned to the architecture.
> Telling Omission ?: No benchmarks with 80C51, and eZ8 devices. Both
> these have direct memory access opcodes, and the Z8 also includes a
> register frame pointer. For the small data sets of embedded
> microcontrollers, this makes for smaller code size.
The controller is quite capable of running code at lightning speed. Its
features are a real hoot!
-- Paul.
Reply by Robert Reimiller●February 19, 20042004-02-19
Leon Heller <aqzf13@dsl.pipex.com> wrote in message news:<40349cb6$0$6844$cc9e4d1f@news.dial.pipex.com>...
> I've just received some info on the new Maxim MAXQ microcontroller.
I noticed that they compared their architecture against PIC16 instead
of PIC18 to make theirs look better.
Reply by Jim Granville●February 19, 20042004-02-19
Partial information only, but they deserve a medal for courage.
Most telling text : " Simulations � replace with MAXQ2000 post layout
sim numbers " :)
Real, debugged device sampling would seem some way off. Microchip are
still tinkering/pre-release on their dsPIC some 3 years after the first
hoop-la.
Best looking feature : The deterministic cycle counts, and single
cycle DJNZ and RET(conditional)
Not mentioned anywhere are actual MHz limits, so this may be like the
1996 AVR data book I have with 24MHz specs, that soon lurched downward
as real numbers arrived from real corner silicon.
It will need to be probably > 30MHz to get on anyones' radar
Acillies Heel: Not enough info, but the fixed stack looks a problem area.
Code-Knee, or memory-reach are important comparison points, and the
info given is not enough to decide that.
They have one of the strangest OPCODE descriptions I have ever seen,
so it is not possible to detemine the reach-corners ( and thus at
what data-sizes your code suddenly gets bigger )
Telling Omission ?: No benchmarks with 80C51, and eZ8 devices. Both
these have direct memory access opcodes, and the Z8 also includes a
register frame pointer. For the small data sets of embedded
microcontrollers, this makes for smaller code size.
Software and emulation : ?
-jg
Reply by Jim Granville●February 19, 20042004-02-19
Leon Heller wrote:
>
>>> I've just received some info on the new Maxim MAXQ microcontroller.
>> Any URL's or PDF's ?
> No, I checked. The new chips are discussed at length in the Maxim
> Microcontroller Engineering Review Volume 3 I received in the post this
> morning.