What are your 3 most wanted features from a P1.1? Now with bonus questions!
mark
Posts: 252
If you could only pick 3 additional things to add to the current P1 (regardless if it required a different process), what would they be? I have a feeling most responses would be similar.
In no particular order, I'd go with:
1) more hub ram
2) more I/O
3) increased clock speed
What if you could eliminate something, and put something else in its place? What would it be (be reasonable, here). This is difficult. Not sure if I can strike a good balance, but I'll give it a shot. Remove all the video generators from the cogs except for one, but make it more capable (is there enough bandwidth?). The other I'm pretty torn on, but I'll shoot: remove a cog and add some USB hardware functionality.
B.. B.. B.. BONUS ROUND!
What 4th additional feature would you add? This was a bit tough, but I think I'd go for hardware MUL.
In no particular order, I'd go with:
1) more hub ram
2) more I/O
3) increased clock speed
What if you could eliminate something, and put something else in its place? What would it be (be reasonable, here). This is difficult. Not sure if I can strike a good balance, but I'll give it a shot. Remove all the video generators from the cogs except for one, but make it more capable (is there enough bandwidth?). The other I'm pretty torn on, but I'll shoot: remove a cog and add some USB hardware functionality.
B.. B.. B.. BONUS ROUND!
What 4th additional feature would you add? This was a bit tough, but I think I'd go for hardware MUL.
Comments
My top 3?
The design in Chip's head commited to Verilog ready for FPGA testing Real Soon Now.
A successful test period.
A successful first run of silicon.
Now, that will be the fastest track to any new P-whatever.
1. Indirect addressing
2. Relative addressing
3. An LF Shift Register gated to I/O pins.
Lots more, but these I would use a lot.
Cheers,
Peter (pjv)
Where are you seeing the $16.8150 price? I see it for $30.00 (at arrow).
Edit: oh wait. You weren't talking USD, were you?
http://www.findchips.com/search/BEMICROMAX10
Shows Verical at Stock 342 Price $16.8150
and
https://www.verical.com/pd/arrow-development-tools-unsorted-BEMICROMAX10-903846?utm_source=FindChips&utm_medium=invListing&utm_campaign=FC2015
Shows the $16.8150, but I see it also says in the fine print Minimum: 3 Increment: 1
- so that's the 3+ price.
1. Lots more Hub RAM (128KB minimum)
2. Hub access single clock (2 clocks in P1)... gives 1:8 instead of 1:16 access
3. Instructions to support hubexec (minimum)
(a) JMPRET as relative
(b) AUGD/AUGS/AUGDS (permits jump and calls in hubexec mode
These would be nice but in no way mandatory to the above...
4. Simple Serial Input using either the counters or video block to accumulate serial, clocked either by internal counter or external pin
5. More I/O... 48-64 total would be nice although hub ram of 128KB+ would overcome most of my requirements
6. 8 ADC pins would be nice, but sigma delta is mostly fine in P1
7. 160MHz would be nice
8. More Cogs
9. 1 or 2 cogs with 8KB cog ram would be nice (supported by relative JMPRET and an indirect MOV instruction)
10. MUL and perhaps DIV would be appreciated by a number of people.
11. Reduce ROM to a simple Boot mechanism with optional Monitor (since no Spin Interpreter, a soft Spin Interpreter would be used which would encourage some extensions and speedup to the Spin Interpreter - IMHO the fixed ROM interpreter has basically blocked the soft interpreters from being used.
12. I'd really like to see a way of adjusting the internal HS Oscillator to get 80-100MHz at 1% or 2% accuracy. Often then we could avoid the external xtal.
13. Seems unlikely, but I would really like to see some FLASH in the chip so that the external EEPROM (or SPI Flash) would not be required. Even 4KB-8KB would be worthwhile. BTW it's a costly thing to do
1. More counter modes.
2. Programmable PLL filter time constant.
3. Counter output programmable to not just OUTA, but also to DIRA and input to another counter.
4. (Do I get four?) More counters per cog.
And, yes, keep the asynchronous PLL counter outputs.
Do you get the impression that the P1 is all about its counters? Well, yes, it really is!
-Phil
P2 will give you those
As FPGA prices continue to fall, and FPGA boards drop in price too, I think a FPGA-optimized/Tuned P1V has potential.
So, lets run the list against something like a MAX10
No real issues here, easy to extend the counter control to do other things
Smallest MAX10 has 101 io
MAX10 includes 12bit 1 MSPS ADC - and a lower speed, Die temperature ADC too.
Not sure what the FPGA speed would be, it will be >> 20MHz now.
116 MHz is an obvious design target, as that is the on-chip OSC and FLASH speed spec
That one is trickier, on present price curves, less COGS is more practical, ie combine a P1 with a P1V
Bigger MAX10 are coming, for those who want more COGs.
Adding Threading may allow limited COGS to do more.
Design/coding decision, no FPGA restriction
MAX 10M08 has 24 18x18 Multipliers for free
A design decision, but the MAX 10M08 has 47.25kB of RAM and 172KB of FLASH.
That makes being able to partition code into FLASH more interesting, as it frees RAM for Data
That in turn makes self-modifying code deprecated, but still valid in RAM (not practical in Flash-fetch)
MAX 10M08 has a 116MHz osc & 2 PLLs and that claim these broad PLL specs
fIN (29) Input clock frequency 5~472.5 MHz
fINPFD Phase frequency detector (PFD) input frequency 5 ~325 MHz
fVCO (30) PLL internal voltage-controlled oscillator (VCO) operating range 600~1300 MHz
Precision is ?? but with Flash and a Temperature die sense, Trim and Compensate seem do-able ?
Not in a MAX10, 172KB of Flash is included
The Flash memory has a parallel mode, 116MHz clocked, but sustained data is not quite 116MHz.
10M08 timing looks to be ~ 50% data density with some address delay, so would be quite similar to
the Access delay and Streaming bandwidth of 1 x QuadSPI Part at 116MHz.
That similarity makes an Execute In Place SPI engine more compelling, along with maybe more focus on Skip opcodes (in small branches it is faster to skip a few bytes than issue a new address)
PLL's tend to need significant die area, so the PLL count may need to be limited.
On a FPGA branch, I see MAX10 has 2 Analog PLLs even in the smallest model, so a SysCLK PLL and one Counter PLL looks possible.
That makes time of flight code possible.
( I think P2 loses the Counter PLL's due to the area cost ?)
No mention of Adjustable Filter on Max 10, but the PLL has quite wide dynamic range on PFD, and VCO is 600~1300MHz so final out would be divided from that.
5MHz min PFD seems the main constraint.
.... and maybe some means to merge with a WAITPxx, for wait-timeouts
AND
JMG: "As FPGA prices continue to fall, and FPGA boards drop in price too, I think a FPGA-optimized/Tuned P1V has potential."
Exactomento... Once the Parallax's current board is shipping, I would like to see Parallax go back, pick a cheaper FPGA, design a nice big board with all the bells and whistles, complete with
... and why not release the prior P2 with a cheap license... makes sense to me.
No product --> no income ?
? A Max10 cannot replace a P1, where a P1 works fine.
Parallax make and sell a lot of Boards now, with Semiconductors on them, not made by them.
The BeMicro board is an obvious starting point for development, but I'm sure a Board with a Prop + Max10 would be easy to run up as the development matures.
A P2 would be expected to come in cheaper than a P1.M10, so high volume chip sales would only be lost to M10 if there was some spec it covered, that P2 did not.
It's all way over my head, but your counter magic never ceases to amaze me. If you wouldn't mind to elaborate on these more capable counter modes you mentioned, what are some examples of what you would be able to do with them?
Cluso, it's all doom and gloom for you atm, you getting a case of paranoia or something?
However, Phil has found/done some of the best unusual uses for the P1 I have seen. I certainly would put this up there as important.
Phil, I presume you would like the MUL as well - or a MAC ?
Interesting. I hadn't considered things like shift registers, captures, and quadrature decoding to be counter modes but I certainly see how those would be desirable.
What is an up/down counter? One that can go either way depending on external inputs?
1)more RAM
2)more Cogs
3)more IOs
Subtract
1)The requirement to be programmed. I would prefer to just tell the Propeller what I wanted it to do and it would do it, without a single keystroke
1) add an ADC
2) add a DAC
3) make the P1 available in different package sizes including something like a 20-pin DIP, even if it meant only 4 cogs and one VDG in that variant.
That won't be easy. At the very least, it'll also require you to click your heels together twice.
Neat! Is the P1 die too big to fit in a DIP20 package? It would be cool to internally tie the unused pins together in some fashion for cog<->cog comms/flagging.
I believe the bounding box should include the following:
1) Power dissipation
2) Packaged, tested, product cost through distribution
3) Cost to deploy in modest volume on a PCB
4) PCB area for minimal reference design
5) Cost to develop, simulate, and tape out
Once one thinks about these things, people who say they want 64 IOs will quickly realize that probably means a BGA, no more hand assembly of prototype PCBs and a device-on-board BOM cost of $25 or more with a footprint of more than 1" square. For many implementation, these are non-starters.
It's the lack of goals (power goal) that caused the P2 to fail. And it's the lack of product understanding that makes these rants all rather pointless. Features have real costs and unless one has real goals against which to measure those costs, then all features are pretty much equal. And the device looks like a kitchen sink. And it's never delivered.
If one doesn't care about costs, then there's no need for a P2 as there's plenty of FPGA options available. The problem with FPGAs is cost, power and board space.
Adding significant functionality (ADC, DAC, UART, CAN, etc) is also pretty difficult to justify. The requirements for these things is remarkably application dependent. How many bits should that ADC and DAC be? What's the requirement for Vref? How much buffering is needed for UART or CAN FIFOs? These are the considerations that cause the PIC roadmap to have 100 parts. Parallax has struggled for 6 years to go from 2 to 3 parts.
I believe the goals are critical. I'd suggest they should be:
Cost at DigiKey - Less than $20 @Q1, Less than $10 at Q1000
Power - Less than 1 Watt
Package - suitable for hand assembly, which bottoms out at LQFP or maybe TSSOP
PCB Space - less than 1" square including device, bypass caps, EEPROM, programming header, crystal
Beyond that, there are a couple of obvious shortcomings in the current architecture:
1) Insufficient memory per core
2) Insufficient memory on the SOC
3) Insufficient core count
4) Poor interpreter performance for SPIN
5) Lack of addressing modes in the cores
6) I'd recommend a one single precision float engine on the SOC (not per core) and the same for an integer mul/div engine
7) Tools
For 1, 2 & 3, I'd suggest simply doubling is plenty.
For 4, doubling the per-core memory may be enough to double the performance of the interpreter - but it's worth exploring the interpreter and perhaps adding an instruction or two where those could significantly reduce the number of instructions per interpreter op.
For 5, an indirect load/store is sufficient
For 6, this needs to be smaller than a core or it makes more sense to use a core. However, looking at instruction support to improve the performance of assembly language IEEE float is important if a core is the solution.
For 7, the situation today is pathetic. The tools simply suck in terms of features, generated code quality. This is a far more important area for investment than anything else. Adding record types, link-time dead code elimination, compile-time constant expression folding, short circuit evaluation and a few other trivial features would have a massive impact on code size (meaning available memory space) with the P1.
While I might agree with you, the purpose of the thread wasn't so much about absolute realism, but just a mere curiosity of what additional [reasonable] functionality people would have desired in an updated P1. I purposely limited the number to 3 primary additions, otherwise it would just lead to a laundry list which would possibly include everything plus the kitchen sink. This way, it forces participants to really distill their wants to a few fundamental features. After all, I did want to retain some semblance of the P1. This thread isn't intended to be taken seriously to the point where it should be expected that any of this would happen, but I did hope people would take the spirit of the discussion serious enough to not give completely absurd responses. I was just curious about what all the various members felt were the most important to them, and it turned out more varied than I expected which I think is really cool. I think hearing a lot of different opinions can be a great way to learn something.
Well done, you have pretty much defined P2
- however this sub topic area is called
Propeller 1 Verilog Code Development
and the question asked, was "features from a P1.1", which means starting with P1V
P2 is an adventure that's been running for years. And, since there's no specification for what's being cooked up, there's no real opportunity to constructively critique it.