Propeller 2 maximum frequency
enorton
Posts: 144
in Propeller 2
Hi All,
I heard the maximum frequency for the Propeller 2 is 320 MHz. Can I go higher than this if I provide active cooling? If I do provide active cooling what would be the theoretical maximum frequency I could go up to?
Thanks,
Eric
Comments
Experimental: maximum stable frequency using P2-EC32 MB in a room temperature without a case (up to 30C) is about 340 MHz.
The Eval board seems to be stable up to 360 MHz.
Over these frequencies, strange things starts to happen.
There is no way that a complex program will run over 380 MHz.
The PLL lose stability about 380-390 MHz too. I tested this by runing a simple one cog program at "410" MHz. The real frequency was about 390 MHz. PLL gave up.
Ok, thank you for this. Right now, I am running it at 300 MHz and need just a bit more speed. If I mount a heatsink to the top of the chip, will it improve performance? I am using the P2 dev board.
It actually depends on die/junction temperature. If the chip is working hard then it'll heat up more and that lowers the limit. So, inline with that, less heat-sinking will produce faster/higher rise in temperature. The Eval Boards have the best heat spreading/sinking.
Further reading - https://forums.parallax.com/discussion/comment/1545243/#Comment_1545243
Before trying to crank clock speeds, have you tried making your code more efficient? If you just need a little bit more, look into rewriting some of your code in assembly. C can't use all the available instructions to their full extent.
If you use the Eval, you can go to 350 MHz without problems. My Eval was running long hours at 354 MHz with 7 cogs active. The Eval is a heatsink itself, having a thick copper layer soldered to the underside of a P2, so adding a small heatsink on the top cannot help a lot.
Edge is smaller, and because of this, runs hotter with the same code running.
Make sure you verify the frequency you're calling for is what you're actually getting. At the top frequencies its possible for the PLL to slip down a bit ("free running") and its not always easy to notice this as digital video and serial comms are designed to accommodate a bit of slip
The max we've had P2 running at here is 372 MHz, exercising the cordic and many cogs. Dry ice helped
In my experience the P2 will do 320 mhz all day, every day, in any ambient that could be remotely tolerated by a human even in the short term. I have had some of these beasties installed on big motors inside the shroud where things get very warm… all without a hiccup.
If that frequency is reached then you are above the hubRAM read/write errors threshold. hubRAM data will already be corrupted by then.
PS: That limiting of frequency was designed into the sysclock PLL circuit. It was intended to prevent crashes from data corruption ... and almost achieves its purpose. The Cogs are reliable while butted against it but hubRAM accesses are not.
Much of this has to do with the technology process ... When I worked for National Semiconductor, the limitation for a 180nm process was 350MHz. This is due to substrate leakage at the transistor level effectively creating a low pass filter. To achieve 1GHz in the early days, the actual clock was phased so you would have four independent oscillators each running at 250MHZ but phase delayed 90 deg of one another resulting in a through put of 1GHz. Since the Propeller is not doing this then 350MHz is going to be close to the limit. You might find some odd balls, on the edge of the corner test that will exceed that but those are the exceptions.
We didn't notice much (any?) hub ram corruption. The test involved taking an image (from hub), rotating it using the cordic, and pasting it back to hub, and rendering it out to the display.
What we did see was consistent with Chip's 'wall of failures' where a whole lot of things went wrong at 384 MHz.
We also noticed a bit of a 'speed hump' where the P2 had to be cool to get past a certain initialisation point, but once it got past that, it didn't require as much cooling
These tests were on a P2D2 with its 12 MHz xtal, hence the slightly finer grain in frequencies. I think us getting 372 and others 360 (on a 20 MHz xtal) is consistent - nobody is getting 380 or more as far as I know
Many types of operations depend on hubRAM though. Particularly start up.
Eg: The data/code in hubRAM can be correct, but then COGINIT will corrupt cogRAM content upon reading of hubRAM. And therefore that cog will do strange things because it never loaded with valid code.
PS: I've been meaning to redo my high-wattage tests from years back for this very reason. I realise now that some cogs weren't always running correctly. At the time I didn't have a good explanation why there was variation in current draw across repeated runs. I had put it down to the speed of heating (Very short runs) and the resulting inability to measure the current in a consistent way (I only had a multimeter to eyeball).
It is heavily temperature dependent, so yes, you could check things on the workbench, but you would not want to ship a commercial product into the field, that was marginally clocked.
The code compiled is now about 270k in size and expect the firmware to grow another 90k. Not exactly an easy program to change to assembly even if I wanted to it would take me many months to do something like that. I made it as efficient as possible and all of it is written in c.
I cranked it up to 360 MHz and it seems to be ok. I don't notice much of a difference in application speed so I may just reduce the frequency back to 300 MHz to be on the safer/cooler side of things. Right now, I am in the application discovery stage and trying different ideas and seeing what I can get out of the chip. I am using all eight cogs as of now and it gets pretty toasty but not ouch burn my finger toasty...
The rule is - there is 1% of code that needs 99% of time. Rewriting this 1% to asm can make the program 10-20x faster. These are real numbers from my experience with Raspberry Pi 3. (the Pi4 is another beast with its out of order executing and optimizing-while-executing CPU)
Are you using the Catalina Optimizer? This can reduce code size and improve execution speed. Try adding -O5 to your Catalina command.
Ross.
Not yet. When I get close to finishing the project, I will apply the optimizer.
Preliminary re-testing shows a lot of prior errors but, funnily, the prior highest wattage test (nearly 5.5 Watts) at 360 MHz looks okay. And that'll be because that one was done using freezer packs and therefore was able to startup well below the hubRAM errors threshold.
I still need to retrieve my good multimeter to write up with more accurate re-tested current measurements.