Maxim MAXQ MCU

Started by Leon Heller February 19, 2004
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 &#2013266070; 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