Maxim MAXQ MCU

I've just received some info on the new Maxim MAXQ microcontroller. It 
looks rather interesting and is aimed at the PIC/AVR/MSP430 part of the 
market. Whether we need another 8- or 16-bit architecture is debatable 
with cheap 32-bit devices like the LPC2000 becoming available, but I'd 
like to have a play with it.

Leon
-- 
Leon Heller, G1HSM
Email: aqzf13@dsl.pipex.com
My low-cost Philips LPC210x ARM development system:
http://www.geocities.com/leon_heller/lpc2104.html

Leon Heller wrote:

> I've just received some info on the new Maxim MAXQ microcontroller. It 
> looks rather interesting and is aimed at the PIC/AVR/MSP430 part of the 
> market. Whether we need another 8- or 16-bit architecture is debatable 
> with cheap 32-bit devices like the LPC2000 becoming available, but I'd 
> like to have a play with it.

  Any URL's or PDF's ?
If it's a new core, that would be brave. Anyone remember cyantechnology?

  Maxim could easily follow AnalogDevices (ADuC8xx), TI (MSC12xx), 
Cygnal (C8051F350) into the high performance ADC+uC market, but surely 
it's a
no-brainer to do this using their proven single clock C51 core, and 
their proven high end ADC experience.
  The MAX765x seemed a good 'first step' into the mixed signal arena.
-jg

Jim Granville wrote:
> Leon Heller wrote:
> 
>> I've just received some info on the new Maxim MAXQ microcontroller. It 
>> looks rather interesting and is aimed at the PIC/AVR/MSP430 part of 
>> the market. Whether we need another 8- or 16-bit architecture is 
>> debatable with cheap 32-bit devices like the LPC2000 becoming 
>> available, but I'd like to have a play with it.
> 
> 
>  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.

> If it's a new core, that would be brave. Anyone remember cyantechnology?
> 
>  Maxim could easily follow AnalogDevices (ADuC8xx), TI (MSC12xx), Cygnal 
> (C8051F350) into the high performance ADC+uC market, but surely it's a
> no-brainer to do this using their proven single clock C51 core, and 
> their proven high end ADC experience.
>  The MAX765x seemed a good 'first step' into the mixed signal arena.

There are basically two versions with the same architecture, the MAXQ10 
is 8-bits and the MAQ20 is 16-bits. They both have a 16-bit instruction 
word and a single 'MOVE' instruction on which all the other instructions 
are based. A Harvard memory organisation is employed, but access to 
program memory is available.  The stack is hardware, but a software 
stack can also be maintained. There is lots more stuff, but I can't be 
bothered to summarise it. 8-)

They also have several pages of simulated benchmarks showing how it 
compares with the PIC,AVR and MSP430.

Leon
-- 
Leon Heller, G1HSM
Email: aqzf13@dsl.pipex.com
My low-cost Philips LPC210x ARM development system:
http://www.geocities.com/leon_heller/lpc2104.html

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.

  Thanks, that's enough to find :
http://pdfserv.maxim-ic.com/en/ej/MER_3.pdf
  for the others who will be interested..

-jg

>  Thanks, that's enough to find :
> http://pdfserv.maxim-ic.com/en/ej/MER_3.pdf
>  for the others who will be interested..

  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

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.

"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.

"Robert Reimiller" <bob@certsoft.com> wrote in message
news:65c9308c.0402191804.1add1982@posting.google.com...
> 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.

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.

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)

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 &#4294967295; 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