Prop2 features not found on other offerings?
prof_braino
Posts: 4,313
in Propeller 2
Its been a while and I am out of touch with Prop2. Does the Prop2 design have any features NOT found on other offerings? Is the Prop2 a unique set of otherwise readily available features?
The Prop1 was interesting due to its deterministic execution, does the prop2 offer the same?
Personally, I would have been happy with a Prop2 that was identical to Prop1, manufactured on a smaller (22nm/14nm today?) process, just smaller and faster. Any "smaller/faster otherwise the same" design on the table?
Thanks!
The Prop1 was interesting due to its deterministic execution, does the prop2 offer the same?
Personally, I would have been happy with a Prop2 that was identical to Prop1, manufactured on a smaller (22nm/14nm today?) process, just smaller and faster. Any "smaller/faster otherwise the same" design on the table?
Thanks!
Comments
Adds interrupts too, and HUB exec.
Not for 22nm, as the mask costs are enormous.
P2 is done at an affordable process, but will be significantly faster than P1.
Plenty of features not found on other MCUs.
Streamer & Smart Pin Cells are quite unique, and would need a FPGA to duplicate.
16 Cores is also quite rare, XMOS is about the only other embedded device close to that, tho some MPUs / ARMS now come in multiple cores.
Prop2 should pair nicely with boards like Raspberry Pi et al.
The Cogs are still just as deterministic.
The 16-clock round robin Hub access still exists albeit only on 16-long address spacing. Accessing consecutive longs on incrementing addresses will be 17-clock intervals. Every second long will be 18-clock intervals. More random locations is a little more jittery.
There is also optional bursting transfer modes (SETQx and RD/WRFAST) for consecutive addresses that can transfer up to a long per clock per Cog. These can provide fast deterministic HubRAM accesses with caveats, one biggie being the data locations must be consecutive addresses.
SmartPins and Streamers offer new options to do less bit-bashing and therefore less constraints on determinism.
That's a really interesting comparison, Chip. Thanks. And to add to that last point of "something between a microcontroller and an FPGA..." that is programmed in PASM/C/C++/Forth/Spin/Basic/JS/Python instead of Verilog. That is cool
--Edited to add JS/Python, since they're surely on their way--
Actually, Chip, given an ideal timing alignment, what is the shortest turnaround on a plain RDLONG? I'm thinking RDLONG can be notably quicker on the ideal address spacing and a string of WRLONGs might even be able to write every second long and keep up with the hub rotation ... using SETQ would be superior in this case but for wider spacings I see it being useful to know the options.
I think 5 clocks is the fastest a RDLONG can run in. So, maybe if you were to read/write every 11th (16-5) long address, you could get optimal throughput for coordinated writing and reading from separate cogs. WRLONG is a lower-overhead instruction, so RDLONG will be the limiter.
If 16 cores is not an enormous differentiator between the P2 and most other MCU's I don't know what is.
The very idea that you can load the thing up with what are effectively 16 totally independent programs with no timing interaction between each other makes building systems much easier. Being able to chop and change software components without any weird side effects is great.
I know Chip is keen on that down to the metal programming with no OS or libraries and other gunk. Which is great for those that want to get into it.
But even for those who are not into getting down to such details it's a huge advantage. We can use objects created by those that do:)
I always find myself using the word "FUN" a lot when describing/using the Propllers 1 & 2 .
Sometimes I have to go back to the "others" which is a experience I don't enjoy at all.
My favorite feature is the elegant assembly language.
I see the Prop's cogs, not so much as CPUs, but as programmable peripherals which along with the unrestricted access to any pin allows us to shape the silicon to our needs, rather than us being shaped by the silicon. Also, a lot of these other micros are obsolete within a couple of years anyway, they just aren't flexible enough to adapt.
Now we are in a new position: we first answer the question: how can I do it, using the propellers unique features, and next: What to do, that others can't and everbody wants? The prop is located in a different class, so should be used to solve different class tasks.
The play station educates kids to play, the lame station educates kids by playing.
What P1 user wouldn't want that !?!
J
The rational being that If you want low power the P1 is not going away. If you want more, faster there is the P2. If you want both, tough, physics does not allow it.
Things may have changed a bit since the year or two I last saw this discussed. I suspect not by much.
P2 uses a speed-optimized process, and that means higher static Icc.
IIRC Chip has mentioned Static Icc targets in ~ 1mA region, rather than some uA.
That said, there was work done to speed reboot of P2, and it is a static CMOS process, so you could likely do a co-operative power management design, where a small, low power MCU (EFM8SB1 or similar) manages the power envelope and clocks.
eg Lowering Vcc to some Ram-retention figure (value tbf) will significantly lower Icc, then wakeups to raise Vcc and speed the Clock would be faster than a reboot, and give a sleep-resume type operation.
It might be possible (with care) to use the Lower Freq Osc in P2, plus a P2 pin, to self-modulate Vcc, but that would likely have a higher Icc than a paired MCU.
Conventional 'power down' in CMOS is to stop the clock, did you mean also Power Supply Switch elements ?
I don't think P2 has any Power Supply switch (too hard to emulate in a FPGA for one), but I understand it does have clock region enables ( & enables on things like VCO/PLL).
Static power is not a function of clock, it is a leakage across the whole device.
Chip gave frequency values for oscillators / temp recently, don't think I saw Icc values for the Oscillator Cells ?
At the Verilog level, almost all flops have enables. During synthesis, most of those will wind up being clock-gated. So, if the synthesis tool perceives that a cog-enable signal is a semi-global clock qualifier, it may gate all that cog's clocks with that cog-enable signal. There is no powering-down of silicon sections in this design, though, which is common practice in much higher-density processes. We are probably going to have a quiescent current draw in the 1.8V logic section of about 1mA, just from VDD-to-GND leakage. The I/O pins which run at 3.3V, on the other hand, have leakages of only nano-amps, which are negligible.
Do you have any indications from OnSemi of a RAM retention Vcc-Core voltage ( & expected Icc), and maybe Vcc-Icc point, for Clocking from LF_Osc (20kHz?) .
How far down in Vcc, did you simulate the LF_Osc ?
I'd expect the VCO-PLL to not tolerate Vcc changes, but LF_Osc may be able to work over a wider range.
Isn't that 1MB?
The target actual silicon size is 512KB.
I only tested the low-freq OSC at the corner cases. I'm sure it will run down to very low voltages, as it's just a Schmitt-trigger relaxation oscillator.
I don't know how low VDD can go before the OnSemi static RAMs lose their data. I would think they could go very low, though, as they use 6T SRAM cells.
It seems reasonable that if you had a means to drop VDD, you could wait around for some turn-back-on event while using the 20KHz RC oscillator mode, before returning VDD to 1.8V.
Thanks. Another reason to get some more P123 boards.
Rich
I like the P1, but it's very frustrating to be always running out of cogs or memory or both.
Working with P2 is very liberating in that regard.