Microchip PIC32MZ Flash Microcontroller is the World's Fastest 32-bit MCU

[Bill Giovino]

http://microcontroller.com/news/Microchip_PIC32MZ.asp

The Microchip PIC32MZ runs at 330MIPS at 200MHz and easily competes against the Cortex-M4.

Includes a Microchip PIC32MZ block diagram and friendly roadmap for the PIC32 family.

Bill Giovino
http://Microcontroller.com

[Don McKenzie]

Check out the errata. No Hi-Speed USB or SQI support and various other cripple-ware items.

http://ww1.microchip.com/downloads/en/DeviceDoc/80000588A.pdf



--
Don McKenzie

All Olimex products now 30%+ off normal Olimex Prices.

Now 50% OFF. Only $18 for an Olinuxino Linux PC:
http://www.dontronics-shop.com/olinuxino.html

The World's Cheapest Computer:
DuinoMite the PIC32 $20 Basic Computer-MicroController
http://www.dontronics-shop.com/the-maximite-computer.html
Add VGA Monitor/TV, and PS2 Keyboard, or use USB Terminal
Arduino Shield, Programmed in Basic, or C.

[Paul Rubin]

Bill Giovino <billg...@gmail.com> writes:
> http://microcontroller.com/news/Microchip_PIC32MZ.asp
> The Microchip PIC32MZ runs at 330MIPS at 200MHz

What does this mean about being the fastest MCU? Why is it interesting,
since there are SOC's running at 1ghz and faster, not to mention vector
DSP's and that sort of thing? Also, the PIC32MZ doesn't appear to have
any floating point arithmetic, unlike the M4 which it seems to position
itself against. It would be more interesting if the PIC had IEEE double
precision, since the ARM M4F only has single precision.

[Simon Clubley]

On 2013-11-20, Don McKenzie <5...@2.5A> wrote:
> On 20-Nov-13 4:34 PM, Bill Giovino wrote:
>> http://microcontroller.com/news/Microchip_PIC32MZ.asp
>>
>> The Microchip PIC32MZ runs at 330MIPS at 200MHz and easily competes against the Cortex-M4.
>>
>> Includes a Microchip PIC32MZ block diagram and friendly roadmap for the PIC32 family.
>>
>> Bill Giovino
>> http://Microcontroller.com
>
> Check out the errata. No Hi-Speed USB or SQI support and various other cripple-ware items.
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/80000588A.pdf
>

That's one hell of a errata list; it looks like the PIC32MZ was released
at least 6 months too early.

If anyone is thinking of using the PIC32MZ, you _really_ need to check out
the above errata list as the first document you read.

Simon.

PS: I loved how the workaround for the Hi-Speed USB mode not working was
to use the Full Speed mode instead. :-)

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Bill Giovino]

On Wednesday, November 20, 2013 2:24:33 AM UTC-6, Paul Rubin wrote:

http://microcontroller.com/news/Microchip_PIC32MZ.asp
By fastest MCU, I mean a general-purpose device - a microcontroller (not an SoC) with Flash and SRAM and peripherals. 330MIPS at that class is the best I've seen.

Thanks for your interest and your questions here, I will do my best to get your answers to your other questions and get back to you.

[Anders....@kapsi.spam.stop.fi.invalid]

Simon Clubley <clubley@remove_me.eisner.decus.org-earth.ufp> wrote:
> On 2013-11-20, Don McKenzie <5...@2.5A> wrote:

>> Check out the errata. No Hi-Speed USB or SQI support and various other cripple-ware items.
>> http://ww1.microchip.com/downloads/en/DeviceDoc/80000588A.pdf
> That's one hell of a errata list; it looks like the PIC32MZ was released
> at least 6 months too early.

At the same time, it's released late. I can't imagine anyone
otherwise willingly releasing a chip with several marquee features not
working.

Sadly this seems par for the course for Microchip. Pretty much all of
their chips have long errata lists, and many of the errors are of the
serious kind.

> PS: I loved how the workaround for the Hi-Speed USB mode not working was
> to use the Full Speed mode instead. :-)

The PIC32MZ starter kits are advertised as shipping with 4MB of SQI
flash installed. I can only wait for the early adopters start asking why
they can't get it working on Microchip's forums.

-a

[Tim Wescott]

IEEE double precision takes a lot more hardware to get really fast
operation.

I sometimes wonder if there wouldn't be a way to implement double-
precision floating point in hardware that wouldn't take up more space
than 'fast' single-precision FP, but at the cost of a few clock ticks.
For a lot of algorithms, a double-precision calculation that happened 1/4
as fast as an in-hardware single-precision calculation would still be far
better than either taking the precision hit of 32-bit, or the speed hit
of software synthesized 64 bit.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

[edward....@gmail.com]

Have not seen any docs yet. If they are following the path of dsPIC30, it will likely have 40 bits accumulator and barrel shifter. It should make double-precision much faster.

[Paul Rubin]

Tim Wescott <t...@seemywebsite.please> writes:
> IEEE double precision takes a lot more hardware to get really fast

> operation.... For a lot of algorithms, a double-precision calculation

> that happened 1/4 as fast as an in-hardware single-precision
> calculation would still be far better

Right, that's what I had in mind, it shouldn't take much more hardware
to use the same DSP blocks to do double precision while taking a 4x
slowdown for multiplication and division, and hopefully not much worse
than 2x for addition. For transcendentals you might need slightly
larger ROM tables for coefficients.

The Intel Quark might be of interest:

http://arduino.cc/en/ArduinoCertified/IntelGalileo

It has a 400 mhz Pentium-class processor which presumably includes
double and extended precision, plus it has various other stuff that make
it nicer in some ways than a Beaglebone, while staying in the same
general price class ($70 at Mouser).

[Ulf Samuelsson]

And you are sure that this is faster than the Atmel AT91SAM9XE
ARM926 based flash microcontroller which been around for 3-4 years?
Running at 180 MHz but different architecture/flash and it
can execute out of external SDRAM, which the PIC32MZ
cannot do, according to the block diagram.

It is not clear what kind of bandwidth you will get from the flash,
but most flash memories will not run more than 20 MHz
so running out of DRAM is typically faster.

You can of course argue that it is cheating, but
if the definition is that you have internal SRAM and Flash,
then the SAM9XE fits.

In a real application, you are going to have problems if peripherals
have to be handled in interrupes, and not with DMA,
and the PIC32MZ only has 8 channels, which is not a lot.

BR
Ulf Samuelsson

[edward....@gmail.com]

> It is not clear what kind of bandwidth you will get from the flash,
> but most flash memories will not run more than 20 MHz
> so running out of DRAM is typically faster.

If i read it correctly, PIC32MZ requires 2 wait states at 200MHz. So, program flash is probably running at around 70 to 80MHz. BTW, flash instruction path is 128 bits with 16K cache.

[dp]

On the e300 core (and likely on others I am not so intimately familiar
with) Freescale have the FPU doing 2 cycle FMUL, FMADD etc. on 64 bit
operands and 1 cycle on 32 bit ones. Works fine, on 400 MHz core
clock they talk about 800 MIPS which if not 100% practically usable
does help, interleaving FPU with integer (and perhaps more importantly,
load/store) instructions does work OK (I have managed a 2.2 cycle total
within a 64 bit FIR loop, load/store included).
Now how did they compromise die size vs. performance I have no idea,
I am just a user of theirs.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Tim Wescott]

What chips does one find that core in?

Thanks.

[dp]

On Thursday, November 21, 2013 4:53:52 AM UTC+2, Tim Wescott wrote:
> On Wed, 20 Nov 2013 18:42:12 -0800, dp wrote:
>
> > On Wednesday, November 20, 2013 6:55:34 PM UTC+2, Tim Wescott wrote:

> ...

> >> IEEE double precision takes a lot more hardware to get really fast
> >> operation.
> >>
> >> I sometimes wonder if there wouldn't be a way to implement double-
> >> precision floating point in hardware that wouldn't take up more space
> >> than 'fast' single-precision FP, but at the cost of a few clock ticks.
> >> For a lot of algorithms, a double-precision calculation that happened
> >> 1/4 as fast as an in-hardware single-precision calculation would still
> >> be far better than either taking the precision hit of 32-bit, or the
> >> speed hit of software synthesized 64 bit.
> >
> > On the e300 core (and likely on others I am not so intimately familiar
> > with) Freescale have the FPU doing 2 cycle FMUL, FMADD etc. on 64 bit
> > operands and 1 cycle on 32 bit ones. Works fine, on 400 MHz core clock
> > they talk about 800 MIPS which if not 100% practically usable does help,
> > interleaving FPU with integer (and perhaps more importantly,
> > load/store) instructions does work OK (I have managed a 2.2 cycle total
> > within a 64 bit FIR loop, load/store included).
> > Now how did they compromise die size vs. performance I have no idea

> > I am just a user of theirs.
>
> What chips does one find that core in?

The one I am using is the MPC5200B (watchout for the old 5200, still
available but much buggier etc.). I have also used it on the 8240 (too
old to consider now); they also have the MPC5125 and the MPC5121 (I have
just been eyeing these, never used one).

I should detail the 2.2 cycles - I do these reading/writing 32 bit FP
data, just the MAC loop is done 64-bit (using FMAD.d , 64*64+64 ).
Loading a 32 bit FP automatically converts it to a 64 bit one,
storing as .s does 64 ->32 (rounding included). I would expect the same
speeds for r/w with 64 bit data (the bus to the cache is 64 bit wide)
but I have not tried that.

[Rocky]

On Thursday, November 21, 2013 1:25:06 AM UTC+2, Ulf Samuelsson wrote:
> 2013-11-20 06:34, Bill Giovino skrev:
>
> > http://microcontroller.com/news/Microchip_PIC32MZ.asp
>
> >
>
> > The Microchip PIC32MZ runs at 330MIPS at 200MHz and easily competes against the Cortex-M4.

> In a real application, you are going to have problems if peripherals
> have to be handled in interrupes, and not with DMA,
> and the PIC32MZ only has 8 channels, which is not a lot.

Actually more. Things like the Ethernet have dedicated DMA which is not part of the general DMA pool.

[David Brown]

From the picture it looks like there are dedicated DMA's for the
Ethernet, CAN, USB, SQI and crypto engine - which is nice.

One thing that can make a big difference to usability is whether the
data cache is synchronised with these DMA channels (i.e., does the cache
snoop their transfers?). I've worked with processors where the
dedicated Ethernet DMA was not snooped - you have to make sure your
Ethernet buffers are mapped to non-cached memory areas (assuming the
processor has an MMC or MMU supporting that), or you have to add extra
cache flush and invalidate code for any accesses.

But given the state of the errata for this chip, it is a toss-up whether
such snooping works or not.

It's a shame that Microchip have released this device in its current
state. The MIPS microAptiv core is a great cpu, and it would be good
for the market for ARM to get some real competition. But with these
half-tested devices from Microchip being the best-known general
microAptiv microcontrollers, there is a real danger that people will
assume the /core/ is bad rather than just incompetence of Microchip's
test engineers combined with over-enthusiastic PHB's and sales folk.
With the current errata - full of modules that simply don't work and
have no fixes or workarounds - this chip should never have been released
for the general public.

[Simon Clubley]

On 2013-11-21, David Brown <da...@westcontrol.removethisbit.com> wrote:
>
> It's a shame that Microchip have released this device in its current
> state. The MIPS microAptiv core is a great cpu, and it would be good
> for the market for ARM to get some real competition. But with these
> half-tested devices from Microchip being the best-known general
> microAptiv microcontrollers, there is a real danger that people will
> assume the /core/ is bad rather than just incompetence of Microchip's
> test engineers combined with over-enthusiastic PHB's and sales folk.
> With the current errata - full of modules that simply don't work and
> have no fixes or workarounds - this chip should never have been released
> for the general public.
>

So the question becomes _why_ have they released it now ?

It was pointed out in another message that evaluation boards have been
released which depend on these non-working features.

That means after a few months have elapsed and these problems have been
(hopefully) fixed, some people are still going to start with a negative
impression of the PIC32MZ instead of starting with a neutral impression
of the PIC32MZ based on it's capabilities at that time.

IOW, I don't see how releasing it now instead of taking the hit caused
by another delay could have ever been considered to be a good idea.

Simon.

[Tim Wescott]

Just four days ago I searched through the documentation for that chip,
and I came to the conclusion that the FPU only supported single-precision
floating point in hardware. Aside from having to go tell a customer that
I had my head buried in my assumptions, I guess I should be pleased to be
wrong.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[Joseph H Allen]

In article <l6lh4k$1it$1...@dont-email.me>,

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>So the question becomes _why_ have they released it now ?

Maybe a competitor is about to release something...

Wish is had floating point like stm32f4.

--
/* jha...@world.std.com AB1GO */ /* Joseph H. Allen */
int a[1817];main(z,p,q,r){for(p=80;q+p-80;p-=2*a[p])for(z=9;z--;)q=3&(r=time(0)
+r*57)/7,q=q?q-1?q-2?1-p%79?-1:0:p%79-77?1:0:p<1659?79:0:p>158?-79:0,q?!a[p+q*2
]?a[p+=a[p+=q]=q]=q:0:0;for(;q++-1817;)printf(q%79?"%c":"%c\n"," #"[!a[q-1]]);}

[John Devereux]

jha...@TheWorld.com (Joseph H Allen) writes:

> In article <l6lh4k$1it$1...@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>>So the question becomes _why_ have they released it now ?
>
> Maybe a competitor is about to release something...

Like ADI CM4xx? 240MHz M4.

<http://www.analog.com/en/processors-dsp/cm4xx/products/index.html>

> Wish is had floating point like stm32f4.

--

John Devereux

[lang...@fonz.dk]

they know everyone is using cortex so the have to com up with some sort of
argument as to why they should all get learn a new architecture, they can only get in one place, and get new tools

-Lasse

[Stef]

In comp.arch.embedded,

Tim Wescott <t...@seemywebsite.really> wrote:
> On Wed, 20 Nov 2013 19:11:24 -0800, dp wrote:
>
>> On Thursday, November 21, 2013 4:53:52 AM UTC+2, Tim Wescott wrote:
>>> On Wed, 20 Nov 2013 18:42:12 -0800, dp wrote:
>>> >
>>> > On the e300 core (and likely on others I am not so intimately
>>> > familiar with) Freescale have the FPU doing 2 cycle FMUL, FMADD etc.
>>> > on 64 bit operands and 1 cycle on 32 bit ones. Works fine, on 400 MHz
>>> > core clock they talk about 800 MIPS which if not 100% practically
>>> > usable does help,
>>> > interleaving FPU with integer (and perhaps more importantly,
>>> > load/store) instructions does work OK (I have managed a 2.2 cycle
>>> > total within a 64 bit FIR loop, load/store included).
>>> > Now how did they compromise die size vs. performance I have no idea I
>>> > am just a user of theirs.
>>>
>>> What chips does one find that core in?
>>
>> The one I am using is the MPC5200B (watchout for the old 5200, still
>> available but much buggier etc.). I have also used it on the 8240 (too
>> old to consider now); they also have the MPC5125 and the MPC5121 (I have
>> just been eyeing these, never used one).
>>
>

> Just four days ago I searched through the documentation for that chip,
> and I came to the conclusion that the FPU only supported single-precision
> floating point in hardware. Aside from having to go tell a customer that
> I had my head buried in my assumptions, I guess I should be pleased to be
> wrong.

Where you looking for cpu's with dual-precision FP? Did you find any
smallish ones? I'm looking for such a processor myself and it seems only
the bigger CPU's have DP FP. Seems to start with Cortex A5 and this e300.
Processors like M4 and SHARC only have single precision FPU's.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

To get something clean, one has to get something dirty.
To get something dirty, one does not have to get anything clean.

[Anders....@kapsi.spam.stop.fi.invalid]

Joseph H Allen <jha...@theworld.com> wrote:

> Wish is had floating point like stm32f4.

MIPS/ImgTec only announced their first microcontroller core with FP
support a few months ago (and I'd really rather not Microchip tried to
roll their own. If they did the errata sheet would probably mention
something about badgers mauling your face.)

-a

[edward....@gmail.com]

> > Wish is had floating point like stm32f4.
>
> MIPS/ImgTec only announced their first microcontroller core with FP
> support a few months ago (and I'd really rather not Microchip tried to
> roll their own. If they did the errata sheet would probably mention
> something about badgers mauling your face.)
>

FP aside, i am more interested in the 12 bits A2D and 512K sram. Hopefully, they won't mess up these too badly. At least they have 64 pins package. Most M4 start with 100 pins.

[Tim Wescott]

The MPC5200 seems to be the most embeddable one that I've found.

DP floating point hardware is just big; that probably drives the "only
big processors have DP floating point" issue.

What are you doing? You may be able to solve your problem with fixed-
point arithmetic and cleverness -- in my recent search, had I not talked
my way into a spot on a big processor I would have seriously considered
64-bit fixed point, and there's a huge class of control system problems
that just can't be done with 32-bit floating point that work great with
32-bit fixed point.

[rickman]

Some people like to dig into the guts of things and compare on features
they can't measure. I don't care a rat's rear how big the FPU is, I
care about the measurable features, price, cost, power, package size.
The die size may impact these, but so do many, many other parameters.
So I worry about the results I can see, not the ones I can't.

--

Rick

[Olaf Kaluza]

Bill Giovino <billg...@gmail.com> wrote:


>By fastest MCU, I mean a general-purpose device - a microcontroller
> (not an SoC) with Flash and SRAM and peripherals. 330MIPS at that
> class is the best I've seen.

So take a look at this:

http://www.renesas.com/products/mpumcu/superh/sh7200/child/sh2a_features.jsp

360Misp at 200Mhz, and the Errata is short because SH2 is old.

Olaf

[Olaf Kaluza]

Ulf Samuelsson <u...@notvalid.emagii.com> wrote:

>It is not clear what kind of bandwidth you will get from the flash,
>but most flash memories will not run more than 20 MHz

Buy Renesas, they can do 100Mhz with 0Wait and if it is not fast
enought, use a SH7264 with 1MByte internal Ram.
Ups...there is now a new SH7268 with 2624KByte internal Ram!

>In a real application, you are going to have problems if peripherals
>have to be handled in interrupes, and not with DMA,
>and the PIC32MZ only has 8 channels, which is not a lot.

The SH2A had 16 Register bank to switch very fast for every IRQ. :-p

Oh..and 64kByte Dualport Ram is cute, too....

Olaf

[Ulf Samuelsson]

I dont know how you come to that conclusion
200 / (1+2) = 66 MHz.

And as someone else pointed out, the Renesas parts can run the flash at
100 MHz.

BR
Ulf

[edward....@gmail.com]

On Saturday, November 23, 2013 2:38:22 PM UTC-8, Ulf Samuelsson wrote:
> 2013-11-21 01:55, edward....@gmail.com skrev:
>
> >> It is not clear what kind of bandwidth you will get from the flash,
> >> but most flash memories will not run more than 20 MHz
> >> so running out of DRAM is typically faster.
>
> > If i read it correctly, PIC32MZ requires 2 wait states at 200MHz.
> > So, program flash is probably running at around 70 to 80MHz.
> > BTW, flash instruction path is 128 bits with 16K cache.
>
> I dont know how you come to that conclusion
> 200 / (1+2) = 66 MHz.

Good catch on my bad math. Should have said 60 to 70 MHz.

> And as someone else pointed out, the Renesas parts can run the flash at
> 100 MHz.

Or you can run it on sram at 200MHz+.

On a 80MHz MX, i have done OC 120MHz.

On a 200MHz MZ, perhaps we can try 300MHz.

Be sure to be able to stop SRAM OC with boot option. Otherwise, you might not be able to reprogram the chip.

[Stef]

In comp.arch.embedded,
Tim Wescott <t...@seemywebsite.really> wrote:
> On Fri, 22 Nov 2013 11:20:36 +0100, Stef wrote:
>>
>> Where you looking for cpu's with dual-precision FP? Did you find any
>> smallish ones? I'm looking for such a processor myself and it seems only
>> the bigger CPU's have DP FP. Seems to start with Cortex A5 and this
>> e300.
>> Processors like M4 and SHARC only have single precision FPU's.
>
> The MPC5200 seems to be the most embeddable one that I've found.
>
> DP floating point hardware is just big; that probably drives the "only
> big processors have DP floating point" issue.

So far I have similar findings, thanks for the confirmation.

> What are you doing? You may be able to solve your problem with fixed-
> point arithmetic and cleverness -- in my recent search, had I not talked
> my way into a spot on a big processor I would have seriously considered
> 64-bit fixed point, and there's a huge class of control system problems
> that just can't be done with 32-bit floating point that work great with
> 32-bit fixed point.

This is a measurement that requires (amongst other things) a non-linear
fitting procedure with the Levenberg–Marquardt algorithm on a few thousand
samples. We already found that disabling denormals does not significantly
affect the results (but it is noticeable) and gives a huge speed increase.

Going back to 32-bit floating point or 64/32-bit fixed point will require
testing on a lot of data and of course modifying the code (there are
also some math lib functions involved in the calculation). This is not off
the option list, but needs to be compared with 'safe' solutions (sticking
with double precision floating point).

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

He: Let's end it all, bequeathin' our brains to science.
She: What?!? Science got enough trouble with their OWN brains.
-- Walt Kelly

[Stef]

In comp.arch.embedded,

Stef <ste...@yahooI-N-V-A-L-I-D.com.invalid> wrote:
> In comp.arch.embedded,
> Tim Wescott <t...@seemywebsite.really> wrote:
>> On Fri, 22 Nov 2013 11:20:36 +0100, Stef wrote:
>>>
>>> Where you looking for cpu's with dual-precision FP? Did you find any
>>> smallish ones? I'm looking for such a processor myself and it seems only
>>> the bigger CPU's have DP FP. Seems to start with Cortex A5 and this
>>> e300.
>>> Processors like M4 and SHARC only have single precision FPU's.
>>
>> The MPC5200 seems to be the most embeddable one that I've found.
>>
>> DP floating point hardware is just big; that probably drives the "only
>> big processors have DP floating point" issue.
>
> So far I have similar findings, thanks for the confirmation.

Just had a better look at the Cortex-Rx, I somehow skipped over this one
earlier. The R4 always has a double precision FPU, the R5 and R7 have an
option for double precision or optimized single precision.

TI has for instance the Hercules safety controllers with R4 core,
starting at LQFP-144 packages. Interesting, not sure it can handle the
memory requirements for our application (which are still under
investigation btw).

The safety aspect of these controlers may be a plus for the intended
application.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

There comes a time in the affairs of a man when he has to take the bull
by the tail and face the situation.
-- W.C. Fields