What are the actual clock specifications of the P2?
M1k3y
Posts: 24
So I'm pretty new to the propeller 2 and struggling a bit with the documentation.
I'm specifically unsure about the supported/intended clock speeds of the chip, as I need it to be as fast as possible while still being stable.
For example in the hardware manual (web documentation 2022-11-01) it states in the table on page 26 "The VCO frequency should be kept within 100 MHz to 350 MHz" but on page 27 it states "The PLL's VCO is designed to run between 100 MHz and 200 MHz and should be kept within that range".
I'm probably missing something here, but to me those two statements contradict each other.
I also managed to accidentally run my eval board at 400 MHz before (calculated the clock settings wrong).
So the question is: How fast can it actually go RELIABLY?
Comments
The answer is basically "it depends".
So the only "hard" number available is the 180 MHz and anything above is up to the silicon lottery?
That'll make things interesting for my project, as reliability is critical and the thermal environment could become challenging. That won't leave many instructions as I need to process some incoming data every 320ns.
Seems I have gotten really lucky though with my eval board as the accidentally configured 400 MHz seemed to be stable for several minutes before I realized why exactly my serial data was messed up beyond recognition.
Getting to 300 MHz reliably is pretty easy, even with 2 layer board.
Might want to stick with Parallax designs if need reliable operation at 350 MHz...
Well, I'll have to look into it more once the code for the time critical portion is done and I start designing the PCB.
I need to run the chip at a multiple of 50MHz (the project contains an RMII 100 MBit Ethernet Interface). I'm currently running at 300 MHz, but I might be able to go as low as 150 MHz if I can get the relevant portion optimized enough. In this case I would prefer stability over performance, as long as I can manage the critical code path in the available time slot.
In any case, I'm still highly impressed with the capabilities of the chip and what possibilities the smart IOs and some of the weirder Instructions open up.
Is this the RMII ethernet that @ManAtWork just recently posted? Or a new one?
I'd suggest targeting 300 Mhz if you can do a 4 layer board.
Maybe 250 Mhz if a 2 layer board and want to be sure...
It's a new one. I started before thinking about checking in the forum or obex.
However after stumbling over the one from @ManAtWork yesterday, it seems I made it quite similar to his and will definitely compare my implementation with it once it is done. He has some very good ideas, especially the alignment method for the preambel. However there are some differences as I'm also processing and redirecting the data in the ethernet frame to different buffers as they are being received. The whole point of using the propeller in my project is to move data between components with as little latency as possible. (also I'm coding in C and currently fighting the p2llvm over "wrong" instructions in my inline asm. I'll probably try the p2gcc or catalina in the coming days.)
For the clock speed, I'll just optimize my code to run in as few cycles as possible and determine the required speed from there. If my project works as intended, the p2 will be located in a closed case sandwiched between multiple other components and very little room for airflow, so I'll go for as low a clock as I can manage.
Here's some testing I did on the borderline - https://forums.parallax.com/discussion/comment/1550912/#Comment_1550912
Running at the PLL limit, Cogs are stable but hubRAM read/write corrupts.
The PLL's VCO can obviously go higher than 200 MHz. It can go below 100 MHz too but it gains a notable wobble below 60 MHz. I believe 200 MHz is its design sweet spot for high stability.
@M1k3y the C in Flexprop is pretty good these days. Inline assembly works there.
If that's the flexcc compiler, I already tried it. It sadly turned out to be very limited and missing a lot of C functionalities.
If you want very high confidence for critical reliability a target clock speed of 200 or 250MHz would be good to work towards and should give decent margin in PVT variation. If you have concerns and access to an oven and you are not planning high volume production you could test each unit over the full temperature range or as a burn in test to validate it. Probably good to do this for the entire system anyway if it's critical to be reliable.
At the moment it is only a personal project, but it might have some serious potential as a product if I can manage to pull it off. There are a LOT of different components and systems that need to work together to make my vision come true and the propeller only takes a small but important part in moving the data around. In the worst case it can be replaced with an FPGA, though the propeller is definitely better suited for what I need (and surprisingly also cheaper).
When I have a first full scale prototype up and running (which will contain by itself somewhere between 18 to 36 propellers spread across 3 main units) I will definitely test it to destruction, including "extreme" thermal environments (I'm planning up to 60°C ambient in direct sunlight as the system is a human interface. If a human can't survive the environment for at least 30 minutes, my system also doesn't need to). But if this concept will ever become a product, there will definetly be some end-of-line testing and burn in for every unit. The stability is critical in a way, that the system is useless if it can't work reliably, but it's not so bad that someone could get injured if it fails, even if it starts sending wrong data.
Catalina is ANSI C (C89). You probably won't like it either then.
Catalina is very good.
Another option is riscvp2 …
That does c and c++
riscvp2 looks interesting, but I'm not a big fan of the JIT concept (for my current project). There are a lot of hard realtime requirements for my application.
What I'm mainly looking for is to write my high level management logic in C while delegating multiple COGs to the realtime part of the application, either completely written in assembler or assembler wrapped in some C code that prepares the COG for it's task and then enters it's own main loop running assembler only.
I still need to learn a lot about programming to make this project run. I have no formal education in programming and my low level experience comes down to smaller projects on AVRs and RISC-V in C, a bit of inline assembly and a few very small assembly only programs.
So I learn as I go and try to stay with tools and languages I have some experience with. That's why I'm specifically looking for a modern C compiler that works good with inline assembly. I had hoped the p2llvm project would be the solution I was looking for and the C part works like a charm. Inline assembly also works, but it seems to not know about a lot of the more obscure instructions the p2 has but are critical in achieving the required performance (mergew and setword being two examples. mergew alone would require 26 instructions and 4 registers with prepared magic numbers alone to emulate with the fastest implementation I could find. It is needed for the RMII receiver where I only have 96 Clocks @300MHz to handle the incoming long).
My lack of experience also causes the biggest pains for me working with the propeller. Coming from AVRs and similar architectures, the platform is quite a challenge to get accustomed to. Also the dispersed and sometimes hard to understand documentation is not helping either.
I feel your pain but it's only by jumping in and coding that you'll learn. I also came over from the AVR/x86 side, so don't be too discouraged with the learning curve, start simple and work your way up. I'm sure you've found this page by now with links to different documents, in different stages of editing/completion (possible abandonment?)
https://www.parallax.com/propeller-2/documentation/
In this list Chip's Silicon document is obviously very good to study to help understand all the capabilities of the P2 as well as the Spin Manual for the Spin Language documentation. Even if you don't intend to use it long term for a compiler, I'd recommend at least learning how to download and use Eric Smith's Flexspin compiler toolchain and the loadp2 utility as they will let you quickly jump in and mess about with simple test programs to help learn how the P2 works along the way. In general the SPIN2 language is very straightforward to follow if you already know some C and you can hack up test programs and test PASM2 ideas very quickly before the full implementation is done.
There's a PASM2 Assembly Language Doc and spreadsheet summary in the list, plus Ada's online hyperlink search tool here helps lookup instructions quickly and can be a useful quick reference when programming:
https://p2docs.github.io
In general C has been the cause of a range of historical problems in the evolution of the Propeller chips and their tools. Some people were dead against it (I'm not one of them) and wanted to avoid it like the plague, this left it out in the cold and one of the results of this is that it lacks a native full-featured port of GCC toolchain for P2 (it did get one for P1 but that's hardly well supported and has not kept up with GCC releases to my knowledge). I'm not sure what state the P2LLVM project got to as I was never able to get it working on my system, although nowadays I have a newer M2 Pro Mac Mini so it might have some chance of working now - will need to retest at some point. Seems like you're happy with the C side of things there which is a good sign.
Remember also that the forum members here are usually willing to answer questions posted if you run into problems etc. Good luck.
Thank you for the kind words and references. I'm aware of most of the documentation you are referencing and have already dug into it a lot. Ada's online hyperlink search looks awesome, I'll definetly check it out in depth.
I'm also in no way discouraged by the learning curve. While it is steep, it's a really rewarding experience to discover all the capabilities and possibilities to (ab-) use the different parts of a new component. I already have a few example programs running and since the weekend I'm successfully receiving and decoding Ethernet Frames (at least up to the IP header, I still get a headache thinking about endianess) although I'm not yet capable of continually receiving data. I guess I'll also give the flexspin toolchain another go. While the C side was frustrating for me, spin2 might also be viable for the non-realtime parts of the system.
I can see how C or other high level languages are not really equipped to make good use of the instruction set of the p2. However it's kind of sad that there is not even an official compiler that can make limited use of the p2 available as it could still provide an easy entry point for people coming from AVRs/Arduino or similar platforms.
It would be good to get Prop GCC working for P2... I think there is a version around that works. Think the other Micropython port used it. Haven't seen mention of it in a long time though...
I use VSC with FlexSpin so I can write the high level part of the project in C and use Spin and assembler for the low level stuff. The only drawback of FlexC is that it doesn't support packed structs. So you have to make sure that your network packets actually have the expected layout and use memcpy/bytemove to force the correct alignment if necessary.
A really great feature of VSC is that you can use FlexSpin as compiler and PNut as debugger. For example you can send real time data to a scope display. This requires some tuning of the Json scripts. I don't know if that's already in the docs.
There is also LLVM , which has been maintained by @n_ermosh
https://github.com/ne75/p2llvm
https://forums.parallax.com/discussion/174028/p2llvm-update
@M1k3y complained earlier about inline assembly issue with LLVM...
Wonder if it's even supposed to work...
inline assembly is working in the llvm port. It compiles correctly and works with various propeller specific instructions like augs, testp, dirh and similar. So it is definetly working for the p2. It is just missing some of the data manipulation instructions. They were probably not added as they are technically not needed and can be implemented with some of the common instructions. I opened an issue for it on github: https://github.com/ne75/p2llvm/issues/17
However I will try something different in the coming days. A friend of mine is very active in the MicroZig project of the zig language. I have previously tried zig and really like it. It has also the ability to compile zig to C (which schould output ANSI C) and it is rather simple to embed asm into it. He has opened a pull request yesterday to add propeller 1 and 2 as build targets in zig ( https://github.com/ziglang/zig/pull/21563 ). I 'll try and use it in combination with the Catalina compiler.
A comment on the 180 MHz spec: It's very conservative in the original tradition of silicon manufacturing. It's the sort of spec that enterprise servers will conform to.
Making reference to "silicon lottery" is a term that only makes sense for modern gaming PCs where the CPUs are already spec'd as fully overclocked parts, and then some. Particularly for "boost" frequencies, where heavy cooling solutions are required to achieve said spec. They are spec'd for literally running right on the thermal borderline of crashing.
As for what is reliable on the Prop2, it is complicated. The chip can burn some notable Watts when pushed. But then it can also be quite cool running even at a decent frequency if the software isn't doing a lot.
I'm unsure if there is even a spec for the thermal resistance of the exposed pad. It got lost if there was. That definitely needs documented.
Alright, that's mostly what I took away from this.
The 180 MHz are "guaranteed stable" for the full thermal and electrical range, but it can easily go (far) beyond it but might become unstable at higher temperatures. As the device is rated to an operating temperature of up to 105°C, with my thermal constraints (human safe environment) 200-250 MHz should still work without problems.
>
Is this what you are thinking of...?
Parallax Propeller 2 (P2) Microcontroller Thermal Specifications
Attached is a "work in progress" document I started writing a few years ago before being shifted to another task.
At a glance it seems almost complete enough to share here in forums, and might be helpful for someone - at least for the theory on how to estimate power use and thermal limits.
Huh, I presume that was gleaned way back during the design rounds of the Prop2. Something of an oversight that it's never been in the datasheet.
I took those specs from the internal On-Semi datasheet for the P2, so we can be certain they are correct values for TJ max and θJA.
Hmm, so at 5.0 Watts the heatsink would need to be kept below 20 degC - https://forums.parallax.com/discussion/comment/1528470/#Comment_1528470
And that is for the 180 MHz spec. To sustain the 360 MHz I used in that test, it would need the heatsink at something like -250 degC! Scrap that ...
Testing shows that 360 MHz crashes at about 80 C - https://forums.parallax.com/discussion/comment/1551043/#Comment_1551043
Make that 60 for some buffer zone: 60 - 5.5 * 20.6 = -53.3.
So the heatsink at -50 degC should work.
I've not looked at your calculations; maybe we are not quite aligned. But one thought: On-Semi does tend to be very conservative, so those "might" be their target / guaranteed specs rather than what was measured whilst overclocking. (I really don't remember now).