Increase your top speed to 80 MHz

Hi all,
 
I was under the impression that PIC32 would only run up to 72 MHz. Microchip was very careful to advertise the top frequency in all documents as being 72 MHz. In the process of scanning through the latest release of documents for the PIC32, I realised that we can now ramp up the speed to 80 MHz. The modification in the code is very simple since you only need to change the PLL multiplier to multiply by 20 instead of 18. The difference in power consumption is almost negligible and I assume that you can potentially gain up to 8 MIPS in the processing power of your system. Thanks Microchip, we like pleasant surprises.
 
Iraklis
 

And in the process of getting the last MIPS, don't forget to call  mBMXDisableDRMWaitState();

 
This disables the BMX waitstate for data access. This wait state is only needed in case a breakpoint at a data write must occur before the data is actually written. With zero wait states here, the data may already be written if the breakpoint occurs but it does give you quite some speed increase.

Hi zardoz1,
 
Thanks for highlighting the BMX wait state disable. I was not aware of the performance benefits it can introduce. I will probably need to read through the datasheets in detail to try and understand its exact use.
 
Iraklis

I think optimal performance at 80MHz is given by:
 
 
#pragma config FPLLMUL = MUL_20, FPLLIDIV = DIV_2, FPLLODIV = DIV_1, FWDTEN = OFF
#pragma config POSCMOD = HS, FNOSC = PRIPLL, FPBDIV = DIV_1
 
 
Combined with:
 
 unsigned int cache_status;

 mBMXDisableDRMWaitState();
 mCheConfigure(3);
 cache_status = mCheGetCon();
 cache_status |= CHE_CONF_PF_ALL;
 mCheConfigure(cache_status);
 CheKseg0CacheOn();

Hi zardoz,
 
I tried your recommendation on the optimum setup and although the system seems to behave correctly, it is taking an extra 15 mA. Any ideas where the extra power may be going? I assume that the processor has increased the throughput so it needs more power to operate. Even so, 15 mA is a lot of extra power if it is going to the core.
 
Iraklis

I think the extra power is consumed by the devices running 80MHz because of FPBDIV = DIV_1

Zardoz,
 
Funnily enough, the difference in power appears when I add the following lines:

 unsigned int cache_status; 
 
 mBMXDisableDRMWaitState(); 
 mCheConfigure(3); 
 cache_status = mCheGetCon(); 
 cache_status |= CHE_CONF_PF_ALL; 
 mCheConfigure(cache_status); 
 CheKseg0CacheOn();
 

I run the system with FPBDIV = DIV_1 and without the above code and the power consumption is reduced by 15 mA.
Iraklis
 

Ok, but do realize without those lines the speed of PIC32 is 'dramatically' lower.
 
Currently I am executing performance tests for my AVIX RTOS port for PIC32.
 
When I remove the lines:
 

 mBMXDisableDRMWaitState();
 cache_status = mCheGetCon();
 cache_status |= CHE_CONF_PF_ALL;
 mCheConfigure(cache_status);
 CheKseg0CacheOn();

 
The results of the benchmarks are only 32% of the results with those lines!!!!!!
 
So you have to make a tradeoff: speed versus power consumption.

Zardoz,
 
I fully understand and agree with you as far as performance benefits are concerned. I am just trying to understand where the extra power is going and I can only assume that it goes to the core. I cannot fully explain why the core needs more power but I suspect that by increasing the speed of the bus matrix, effectively we are increasing the core throughput which as a result needs more power to operate. I wouldn't mind understanding a bit more about what happens in the background but I guess I should be happy with the extra performance (for the moment).
 
Iraklis

As you might know (don't mind me telling ), power consumption of digital chips is related to the clockspeed. The highest power consumtion of digital circuits occurs while switching their binary state. As shown by the performance figures, when running full speed, a lot more switching is going on inside the core so I agree it is probably the core where the power is disipated.

hi

Typically in a pure digital CMOS diesign (CMOS being the important word here) yes power is related to clock speed, but so is voltage.

The power consumption of the device is

P = kCV^2 where k is a capcitance constant because essentially power in a CMOS device is needed mostly during switching because it's shuttling charge around in a very complex capacitor dance. 

in the case of the Microchip parts which have analog blocks on them then it becomes more complicated

P = P(analog/quiescent) + kCV^2

P(analog/quiescent) in this case is going to be dominated by on chip vcore reg (being a linear voltage regulator) and the ADC blocks.  The base number can be determined by  holding the part in reset and measuring the total amount of current going into the chips supply including the internal 1.8V core supply providing that all GPIO pins are either tri-stated or preferable not connected to anything.  While not completely accurate for the formal spec this result will tell you how much power chip needs regardless of it's power state.  Again during operation the ADC block wil consume more power both in the analog and digital domain but seperating the two factors out at this level is only useful to the actual designers of the part.

By normalizing out this base power you should see the power of the device in operation scale linearly with speed and with the square of the voltage

Speed and performancewise I have had success running the core @ 72 Mhz with only 1 wait state on the FLASH which seems, for me at least, to be the sweet spot for overall DMIPS performance.  Your mileage may vary. Note that this violates FLASH access time spec but there are several factors to balance out.  If the overall clock speed is lower you can run with fewer, even 0 wait states on the FLASH, which actually eliminates any performance gain seen be using the prefetch buffer.  Additionally executing from RAM can actually be slowe because now you are forcing arbitration between instructions and data on the same part of the bus controller and data always takes priority.

For devices like this in portable applications I'll shoot for maybe 50% of nominal clock speed and see how far off I am.   Truth be told I haven't done any real power measremeny yet so I don't even know what the nominal operation area for my applications are yet

cheers
bob m

Hi all,
 
When I saw microchip anounced the PIC32s able to run at 80mHz, I tried to get mine running even more quickly playing with the PLL to see what was it's true maximum. I've been able to run it up to 160mHz!!
 
Is there something I'm missing as I only have very basic knowledge of this new architecture? I tried with a test program wihch indeed ran twice the speed so it really seemed to be at that frequency.
 
I was using PLL divide at 1 and multiply at 20

I've been able to run it up to 160mHz!!

I have been doing the same experiments, also playing with the wait states and came to the same conclusion. What we must keep in mind is that we are doing those experiments at room temperature.

The figures provided by Microchip cover an entire temperature range. The 80MHz is specified over the entire temperature range.

Nevertheless, the architecture and its implementation look promissing.

I don't have any tools for that, but it would be interesting if someone could check how much power the pic is using at this frequency.

Hi,
 
I have just tried running the system at 160 MHz and my processor simply didn't do it. I disabled both the input and output dividers of the PLL and set the PLL itself to multiply by 20. The system simply ignored the settings and continued running at 80 MHz consuming identical amount of power as when it was properly setup to run at 80 MHz. Can you give me any clues of how you managed to increase the speed and how you measured the running speed.
 
Many thanks,
Iraklis

Heya!
 
The test program was simply a for loop doing 20k times a simple trigo/float operation. Each times the for loop ends, the red led is toggled and it starts over. I measured the time between led blinks at 80mHz and at 160mHz, it is not accurate but sufficient to see it was really twice the speed.
 
I dont know why but I'm no longer able to run it at this speed. The program doesn't start. But it is still working perfectly at 152mHz using 19x PLL multiply.
With the PIC32 starter kit, sometimes the memory isn't written right. After programming, the verify command returns errors. I have to reprogram it a second time before the verify succeeds.
 
It is weird that your PIC ignore the config and turns back to 80mHz... When I set settings too high, mine juste refuses to start.
Maybe this is due to the fail safe clock monitor, check that it is disabled.

ORIGINAL: TheDude

Heya!

The test program was simply a for loop doing 20k times a simple trigo/float operation. Each times the for loop ends, the red led is toggled and it starts over. I measured the time between led blinks at 80mHz and at 160mHz, it is not accurate but sufficient to see it was really twice the speed.

I dont know why but I'm no longer able to run it at this speed. The program doesn't start. But it is still working perfectly at 152mHz using 19x PLL multiply.
With the PIC32 starter kit, sometimes the memory isn't written right. After programming, the verify command returns errors. I have to reprogram it a second time before the verify succeeds.

It is weird that your PIC ignore the config and turns back to 80mHz... When I set settings too high, mine juste refuses to start.
Maybe this is due to the fail safe clock monitor, check that it is disabled.

 
80 mHz is awfully slow :)
 
Just kidding, I am sure you mean MHz instead of mHz

It seems that it is zardoz1 caching settings which were preventing me from using the 20x PLL. It runs without, but won't run with.
Though I can still run it a 19x PLL with these settings on.

It's really incredible the speed increase you get from them!
 
 
isa => No I'm serious, I'm attending the 'slowest MCU in the world Contest'

There will always be variations in the manufacturing process.  PC overclockers always include info about stepping or date codes when refering to their speed gains.  And there are variations withing steppings.  Chips cut from the center of the die may be slightly different from those at the edge.
 
I did read something on the MIPS site that the M4K core was rated to ~200Mhz at 130nm process.  But one must tightly control the process and not all devices will pass, thats why Intel sells Celery.  

It seems that it is zardoz1 caching settings which were preventing me from using the 20x PLL.

 
I don't know which settings you are referring to but I had no problem bringing PIC32 to an incredible speed.
 
I would like to state once more that this is nice but not meant to be done in professional applications since the 80MHz is guaranteed by Microchip over the entire temperature range and the high speeds we see are tested at room temperature.
 
To be on the safe side is use the Microchip spec's.