A Propeller is not a propeller unless it is balanced, and one "cog" makes it unbalanced. Two I would have thought the minimum because I can always count on one to be deterministic. But if we have the option of a very small P2 I would like to see a small package, none of this wide SOIC nonsense, they are monsters in the SMD world. Either the 38-pin TSSOP or TSSOP28 or even a TSSOP16 would be welcome. This means I can get away from PIC/ARM/AVR/8051s etc and just use P2xxxx everywhere, everywhere, everywhere...
A 4 I/O pin Prop in an 8 pin package would be massively expensive compared to the Tiny Atmels/PICs that come in that format. I doubt that having smart pins would compensate for that.
Minimum before I/O is 2 Vdd 2 Vss 2 xtal 1 reset so at least 8 I/O on top of that brings us to a minimum 16-pin package plus we don't know what size the silicon itself will be just as the P1 needs a larger package.
I compiled and tested the 1-cog arrangement just to be sure the changes worked all the way down. Yes, it wouldn't really be a Prop with just one blade.
Any size hub RAM can be accomplished. If you can't get a sufficiently large 32-bit RAM instance, you can always use two 16-bit RAMs in parallel with the same bit count as the 32-bit RAM. Or, use four 8-bit RAMs in parallel.
A single cog with 4 i/o in an 8 pin package would be cool. There are useful things that can be done with 4, or less, i/o pins.
perhaps, but whenever I've looked at 8 pin Parts, I've quickly run out of pins...
If you look at the small MCU market, as a litmus test, the price sweet spot (cents/io) is actually now 3mm parts in QFN20
eg EFM8BB1 (~31c) and STM8 (~36c) for quite capable parts, with Flash and In Circuit Debug.
P2 is not going to ever displace those, nor does it need to.
On second thought, I'll just have this data in the ROM. Objects will just do as configured, most likely, anyway. When a development host logs onto the chip, it will give this information.
This means the hardware is back to being "done" and I'll return to getting the next release ready.
That's what most vendors do.
They have a Device ID, a Package variant, and a revision - you may want two revision fields, one for Verilog and one for ROM release.
(more, if you have build-sets around Smart Pins)
The value loads somewhere as well, so run-time checks of target are possible.
Anyways, plenty of space in 1-2 32b quanta, to store all of that easily.
Does this mean we can have images we can test on smaller FPGAs? I like the 4 cog version with smart pins please
Of course. There will now be multiple compiles for most boards.
One FPGA target to consider would be the MAX 10 10M25 - that seems to be a firming choice now for P1V commercial work, and it may be much more in Parallax interests to have P2 being tested, than P1V being tested ?
ie how much, on the new Siding P2 scale, can fit into a 10M25 ?
What about the classic 40-pin DIP one? They are still popular form factors, at least to the hobbyist?
A module that has (eg) P1 pin-out could be expected fairly quickly, but the need for many ground pins for decoupling and Multiple Vcc pins n the package makes a direct DIP40 less than practical.
That said, I'm unclear on the PLL in P2, and if it can work with P1 crystal values ?
The PLL & PFD was rather limited in choices, last time I saw numbers.
A module that has (eg) P1 pin-out could be expected fairly quickly, but the need for many ground pins for decoupling and Multiple Vcc pins n the package makes a direct DIP40 less than practical.
That said, I'm unclear on the PLL in P2, and if it can work with P1 crystal values ?
The PLL & PFD was rather limited in choices, last time I saw numbers.
Ah, I forgot about these ground pins and the decoupling, thanks for reminding! However, some models of Microchip's PIC32 has a 28-pin form factor and they have a small amount of decoupling you need for the supplies.
Are these Prop2s interface-able to any of the SDRAM? I feel that the best would be at 8 megabytes - plenty to work on for making retro games!
I compiled and tested the 1-cog arrangement just to be sure the changes worked all the way down. Yes, it wouldn't really be a Prop with just one blade.
I compiled and tested the 1-cog arrangement just to be sure the changes worked all the way down. Yes, it wouldn't really be a Prop with just one blade.
NASA Monopteros - single blade wind turbine
If we are going to make a Cyclops, I need to get some flops out of the egg-beater to reduce the latency further.
Yes, a 1 Cog P2 just doesn't sit right. But a 2 Cog version ought to work at basically full speed because the instructions are 2 clocks and hub would be 1:2 clocks too. Fits nicely once the cogs get into alternate-clock sync.
A single core propeller could make sense in distributed systems, where the main point is to have consistent development tools
And in such a distributed system, there is now room for a couple of small FPGA's, with P2v interfaces, to ensure long term flexibility and further expansion.
Better than a Swiss Army knife with an ion drive:)
There's something just wrong about a 1 cog Propeller...
They'd be a flop. I don't think the Cog architecture is up to competing directly with Pic32's and M4 Cortex cores in terms of performance or cost on a one to one basis.
Stuff 4 cores in a package and IMO it becomes relevant.
But all of this is very far off, I want to see working and bug free silicon first and go from there.
They'd be a flop. I don't think the Cog architecture is up to competing directly with Pic32's and M4 Cortex cores in terms of performance or cost on a one to one basis.
I would agree, if it were not for the Smart Pin Cells.
The 1 COG is not there to sell 1 COG, far from it - it is there to configure the smart pins, and those are what the customer is buying.
Flexible USB is going to appeal to many, as is a sea of PWMs and Counters/Captures.
In many cases it will not compete with a M5 or M7, as much as sit nicely alongside one.,
That said, I would expect 2 COGS to be a more natural Family member minimum, but one-cog may make sense in FPGA's where the incremental cost of adding that extra COG is higher.
You would get the second cog almost for free, and it would make the code a lot simpler because any I/O would be handled by 1 cog and the smart pins, and the other cog would be left to do the grunt work.
But I could see two variants of 2 cogs...
* 32-64KB Hub RAM
* 512+KB Hub RAM
There are just going to be those times where a lot of Hub RAM is going to be wanted IMHO. If we had a big hub ram on a P1 variant, then the >32 pin requirement would be reduced significantly.
Comments
That means lot's of people will write lots of code for it.
Using interrupts/events of course because, well, you have to on a single processor.
All the unique wonderfulness of the Propeller is gone.
Something feels very wrong about a 1 COG Propeller.
Any tiny P2 still requires an external FLASH !!!
This is.a killer in any tiny P2 !!!
That is why I asked if OnSemi had internal flash options in 180nm.
FWIW OnSemi make Flash and EEPROM. eg CAT24C512.
Any size hub RAM can be accomplished. If you can't get a sufficiently large 32-bit RAM instance, you can always use two 16-bit RAMs in parallel with the same bit count as the 32-bit RAM. Or, use four 8-bit RAMs in parallel.
I wish I would have thought to ask them about Flash last week. I will ask this week. This would be important for small, inexpensive parts.
If you look at the small MCU market, as a litmus test, the price sweet spot (cents/io) is actually now 3mm parts in QFN20
eg EFM8BB1 (~31c) and STM8 (~36c) for quite capable parts, with Flash and In Circuit Debug.
P2 is not going to ever displace those, nor does it need to.
That's what most vendors do.
They have a Device ID, a Package variant, and a revision - you may want two revision fields, one for Verilog and one for ROM release.
(more, if you have build-sets around Smart Pins)
The value loads somewhere as well, so run-time checks of target are possible.
Anyways, plenty of space in 1-2 32b quanta, to store all of that easily.
One FPGA target to consider would be the MAX 10 10M25 - that seems to be a firming choice now for P1V commercial work, and it may be much more in Parallax interests to have P2 being tested, than P1V being tested ?
ie how much, on the new Siding P2 scale, can fit into a 10M25 ?
If Flash is available, then it might be possible to explore a simple Verilog ROM replacement. Do OnSemi charge for usage of their ROM blocks ?
That said, I'm unclear on the PLL in P2, and if it can work with P1 crystal values ?
The PLL & PFD was rather limited in choices, last time I saw numbers.
Ah, I forgot about these ground pins and the decoupling, thanks for reminding! However, some models of Microchip's PIC32 has a 28-pin form factor and they have a small amount of decoupling you need for the supplies.
Are these Prop2s interface-able to any of the SDRAM? I feel that the best would be at 8 megabytes - plenty to work on for making retro games!
NASA Monopteros - single blade wind turbine
If we are going to make a Cyclops, I need to get some flops out of the egg-beater to reduce the latency further.
I'll find out tomorrow. I'm anxious to know.
I can see one use area for a One-COG model, and that is simply as a Smart Pin Manager.
ie if someone wants to connect many Smart Pins to a larger host, they will need some means to configure those pins, and capture & send data.
And in such a distributed system, there is now room for a couple of small FPGA's, with P2v interfaces, to ensure long term flexibility and further expansion.
Better than a Swiss Army knife with an ion drive:)
They'd be a flop. I don't think the Cog architecture is up to competing directly with Pic32's and M4 Cortex cores in terms of performance or cost on a one to one basis.
Stuff 4 cores in a package and IMO it becomes relevant.
But all of this is very far off, I want to see working and bug free silicon first and go from there.
The 1 COG is not there to sell 1 COG, far from it - it is there to configure the smart pins, and those are what the customer is buying.
Flexible USB is going to appeal to many, as is a sea of PWMs and Counters/Captures.
In many cases it will not compete with a M5 or M7, as much as sit nicely alongside one.,
That said, I would expect 2 COGS to be a more natural Family member minimum, but one-cog may make sense in FPGA's where the incremental cost of adding that extra COG is higher.
But I could see two variants of 2 cogs...
* 32-64KB Hub RAM
* 512+KB Hub RAM
There are just going to be those times where a lot of Hub RAM is going to be wanted IMHO. If we had a big hub ram on a P1 variant, then the >32 pin requirement would be reduced significantly.