Chip, what things Prop2 will lack?
Ramon
Posts: 484
Chip, I have been thinking about what you said in other post:
""What do you guys think we need to develop in order for Prop2 to become something that can be easily interfaced to the world these days, and by "world" I mean smartphones, tablets, web, and so on.""
Real word for me has other meaning:
I think about high performance DAC/ADC (like Silicon Labs C8051F06x : 16 bit, 1MSPS).
LVDS to easily attach to LCD panels. (Why I should use a VGA to LVDS convertor from Prop to LCD pannel ... when I can attach the some other CPUs directly to LVDS first?)
Easy interface to SD cards (HIGH SPEED/Megabyte capable, not what Prop1 currently do on software).
Easy LPDDR interface (like Lattice MachXO2). LPDDR is fast, low power, and high capacity.
Easy AND high performance connectivity to USB 2.0 (like FTDI FT232H 40Mbytes/sec) or USB 3.0 interface. It seems to me that FTDI has no interest in USB3. Cypress FX3 is the only option. FX3 can do 3.2Gbps (32 bits @ 100Mhz). And I think 3.2Gbps is something that Prop2 can deal with. But FX3 is not easy for hobbyist.
And 10/100/1000 Ethernet connectivity. Complete 10/10/1000 capability. If It just only supports 10mbps, I'd prefer to buy a PIC or AVR with ENC28J60.
All protocols mentioned above are basically Input/Output (DAC/ADC,LVDS,USB,Ethernet), primary STORAGE (LPDRAM), and secondary STORAGE (SD, or also FLASH). They are all mass marketed and proved technology. So I think is a must to have. If Prop2 is just only more muscle, but cannot easily interface to "Real world" what's the point to have several Giga MIPS of computing power?
When Prop1 was born it was revolutionary because there was a easy way to interface with PS/2 keyboards, NTSC/PAL, and VGA interfaces.
That's what real world means for me, but maybe for other people it will be CAN, Profibus, or some other protocol I've never read before.
I will buy Prop2 when it will be available, as I bought prop1 several years ago. I follow this forum with great interest, and this is just to give feedback to make a better product.
""What do you guys think we need to develop in order for Prop2 to become something that can be easily interfaced to the world these days, and by "world" I mean smartphones, tablets, web, and so on.""
Real word for me has other meaning:
I think about high performance DAC/ADC (like Silicon Labs C8051F06x : 16 bit, 1MSPS).
LVDS to easily attach to LCD panels. (Why I should use a VGA to LVDS convertor from Prop to LCD pannel ... when I can attach the some other CPUs directly to LVDS first?)
Easy interface to SD cards (HIGH SPEED/Megabyte capable, not what Prop1 currently do on software).
Easy LPDDR interface (like Lattice MachXO2). LPDDR is fast, low power, and high capacity.
Easy AND high performance connectivity to USB 2.0 (like FTDI FT232H 40Mbytes/sec) or USB 3.0 interface. It seems to me that FTDI has no interest in USB3. Cypress FX3 is the only option. FX3 can do 3.2Gbps (32 bits @ 100Mhz). And I think 3.2Gbps is something that Prop2 can deal with. But FX3 is not easy for hobbyist.
And 10/100/1000 Ethernet connectivity. Complete 10/10/1000 capability. If It just only supports 10mbps, I'd prefer to buy a PIC or AVR with ENC28J60.
All protocols mentioned above are basically Input/Output (DAC/ADC,LVDS,USB,Ethernet), primary STORAGE (LPDRAM), and secondary STORAGE (SD, or also FLASH). They are all mass marketed and proved technology. So I think is a must to have. If Prop2 is just only more muscle, but cannot easily interface to "Real world" what's the point to have several Giga MIPS of computing power?
When Prop1 was born it was revolutionary because there was a easy way to interface with PS/2 keyboards, NTSC/PAL, and VGA interfaces.
That's what real world means for me, but maybe for other people it will be CAN, Profibus, or some other protocol I've never read before.
I will buy Prop2 when it will be available, as I bought prop1 several years ago. I follow this forum with great interest, and this is just to give feedback to make a better product.
Comments
USB can be done in software at 12MBPS, but probably not faster. Same with 10-BaseT.
Is this a trick question?
As you know the Props lack pretty much all the functionality on your wish list. As you have been following the Props history you also know that this is on purpose.
The Prop design philosphy, as I gather from listening to Chip, includes such things as:
Simplicity (Knowability as Chip put it in the recent conference)
Regularity (All pins are the same, all COG are the same, all COGs can access all pins equally, etc etc)
Timing determinism. Hence no interrupts and 8 COGs. Thats all part of simplicity for the user.
Flexibility. You have a clean slate of processing power to use as you like.
That is to say, soft peripherals not the chip designers selection of hardware blocks as you are offered with other devices. Which may or may notmatch up with your current product requirements. Which leads you to have to select a different device for each application.
One could throw all those peripherals on your list into the chip. Propbably would have to remove most of the COGs to get them in. There would be less flexibility (pins dedicated to functions etc). Probably have to add interrupts for the one remaining core to juggle all that I/O. There goes your simplicity and timing determinism.
It would be a pointless exercice as the end result would be "just another" MCU. Like all the ARMS, AVRs etc that are out there withall kinds of bells and whistles included and 3000 page user manuals. That market is saturated already.
No, the Props are something else.
Or, are you talking about developing Prop II boards with your wish list items included as peripheral chips?
Well, that is under discussion on another thread.
I think Chip asked the question because he was trying to prioritize and partition software development and was considering future hardware/software applications.
IMHO, here are the top three fails on my list:
1. The Prop2 completely lacks proprietary logic.
You can actually use the Prop2 any way you like... no subscription fees. Nothing that doesn't actually work. No missing logic.
2. Complete absence of overstatement or corporate hubris.
Parallax typically understates the power of its own technology. With the Prop2, I think we are seeing new levels of understatement.
3. Not a hint yet of an adequate metric. This was a problem for the Prop1 and the problem has been compounded with the Prop2.
This is a real problem for people who like to use numbers to compare things. With the Prop1, I campaigned tirelessly to get the counters included in the estimation of MIPS... and completely failed.
(Mostly I think this is because Chip doesn't like to scare people.)
I'm not giving up.
Here's the question again: ... if you count the instructions per second required to implement a counter in assembly... and then
tack that on to the estimated MIPS for the Prop2... what do you get?
If like me, you are a little tired of this kind of metric... how about a new metric: S/mW... smiles per milliwatt... or GPH... giggles per hour?
Rich
The heuristic value of the Prop1 and Prop2 cannot be overstated. They are purpose built and supported in such a way as to encourage learning.
There are a few other attempts out there, but nothing like the Prop line of micro-controllers.
1) Create your application in Verilog/VHDL and have a chip made or use an FPGA. This is a tough and complex thing to do and very expensive. It's hard to get an FPGA up and running for ten dollars or so.
2) Use XMOS chips. They are also based on the "software as silicon" idea and have tight CPU to I/O integration and deterministic timing. Much harder to work with hardware wise than the Props. They have the edge on memory in some devices. They have the edge in speed over the Prop I perhpas not the Prop II. You will want to use the XC language for serious work on them, not to the taste of some.
4) Build your own logic solution out of TTL and such. Big, slow, expensive, complex, old fashioned.
5) Use Propellers.
Now. If your app does not require what the above solutions can offer then perhaps any old off the shelf ARM or AVR is a better choice for you.
However if your app needs what those solutions offer then perhaps the Props are a very good, simple, cheap way to go.
But, there are some things that really need to happen on the software side to get a lot of attention, I think.
I know this is really early to make requests, but this is what I'd like to see:
1. USB serial interface using P2 pins. I don't care what speed.
2. 4-bit SD card interface
3. Graphics Library
4. mp3 decoding
5. jpg decoding
6. direct camera interface
I think all of these can be done, but maybe require assembly programming for best performance.
Wonder if Parallax has any plans to do these themselves...
I read before that prop2 core run at lower voltage than IO. How easy (or difficult) is to make a independent VCCIO power rail?
(like Xilinx Coolrunner-II CPLDs, and also some Lattice FPGAs: they have between 2 or 6 IO banks. And for pins that belongs to each banks you can choose severail IO voltages 1.5v, 1,8v, 2.5v, 3.3v ...). It's very flexible, and It reduces cost in parts for voltage translators.
It could be possible to add a hardware USB 2.0 controller to propeller?. I know this task may be too big, so I am thinking about third party license. Parallax already use FTDI chips for USB-Serial programmer. Do you think it could be usefull or possible to reach some agreement with FTDI to license FTDI USB intellectual property inside Prop2. I dream If we could have a Prop2 with FT232H inside.
I agree with what you said. We have several options: Propeller, CPLD, FPGA, old TTL, XMOS, or just "standard" microcontrollers (AVR, ARM, etc ...).
As you said: I can do the same application in propeller than in FPGA, XMOS or any current high-performance CPU. But It will be more expensive and difficult.
I think Parallax is at the TOP if we consider how it listen to and cares about it's customers (Founder and employe's replies in this forum, and other things like posting propeller 2 DE-0 nano verilog files in the forum prove this). And also I think that Parallax is the best of them if we consider the balance between EASY OF USE with FUNCTIONALITY for non-professional users.
Prop1 built-in video generator and easy PS2 keyboard/mouse connectivity was for me the most usefull functions. I would want the same success with other difficult to interface components, like high performance ADC/DACs, USB 2.0 or 3.0, gigabitethernet, or fast SD/SDHC.
There are a lot of FPGAs, CPUs, and MCUs that include this in their catalogs. But how many of them are really easy to use, or to design? NONE.
Of course it can be done outside the IC, but I think Parallax should try to do it inside the IC. Why? to have same "premium" and be able to increase price (yes I want to pay more, if someone make this), have more sales, and income. It parallax only focus to learning or hobbist, and does not get success in the industrial market, I think we will not expect to see any Propeller-III or Propeller-IV in the future. And I won't want to see that happening.
I agree Parallax is the best, never seen a company like it in the tech field.
I think the problem with your wish list is the constraints under which the Prop II is designed. It might be great to throw in USB, Ethernet etc etc hardware. Heck let's have all that for each cog. After all a guiding principal of the Prop design is regularity, all COGs the same.
But there are always constraints like:
1) The number of available transistors in your chosen technology.
2) The max power consumption you can tolerate
3) The cost of the finished product
4) The cost of licensing any standard IP cores to get things done
5) The limit on how much time you have to get the job done.
And so on.
From the recent conference I gather the Prop II is pretty much full in terms of available transistors. Going to a smaller technology would give more transistors but raise the development cost by a factor of ten or so. Not good unless you know you have huge sales volumes. Clearly with seven years of development time behind it the Prop II has to be out now, you can't keep working on it for ever.
Juggling all those constraints against what you want is what engineering is all about.
All in all the PII looks like a brilliant piece of work within all those constraints and while sticking to it's design philosophy.
No more hardware features will be added to Prop2 ... but we can start a wish list for Prop 3 :-)
Chip mentioned Parallax could do a 40nm geometry 1GHz+ version of Prop2 for ~$3M, so let's hope they sell a lot of P1's & P2's in the next couple of years.
Mind you, another older process comes to mind... 90nm
That would allow a 4x increase in density, and probably around 4x increase in speed... and I am guessing it would cost a lot less than a 40nm process.
90nm should allow for a 32 cog P2.5 with ~ 512KB of HUB running at 640MHz+, or possibly 16 cogs with 1MB of HUB @ 640Mhz+ .. add high speed SERDES, and 480mbps USB and 100mbps Ethernet should be quite possible.
16 cogs @ 640MIPS = 10.24 billion operations per second ... which is dual core PC performance range
I have often wondered where the sweet spot in the number of COGs might be.
I thing the 40nm Prop should be a 64 bit machine giving the possibility of cogs with src/dst fields able to address 32 million instructions !
640MHz -> 40M hub cycles/second per cog, with 4 longs per access = 40M * 4 * 4 = 640MB/sec bandwidth per cog
with the hardware threading, each thread now would run at the same speed as a non-threaded cog on p2!
Right now, P2 will have
160Mhz -> 20M hub cycles/second per cog, ie 320MB/sec per cog ... so a 16 cog "P2.5" would have twice the cogs, each 4x as fast, with double the hub bandwidth
That might be a nice, relatively easy/cheap, transition to the 40nm "P3" 1GHz+ monster...
FYI - I totally agree about going 64 bit for 40nm P3 ... yumm ... lot more cog ram...
By the way, from Chip's presentation at the conference I gather it's Chipmas Day today. At least for Chip. I'm kind of biting my nails here for him. I'm mean, what on earth does one do if they don't jump into life when you put the power on?
Frankly, we have barely scratched the surface of the FPGA emulations running at 60Mhz...
OOO! CHIPMAS!!!!
I am sure Chip will come up for air as soon as he has something concrete to tell us... but after all these years waiting for P2 chips we may not hear anything for a week or two from Chip.
Depending on the nature of the failure sometimes it's a quick diagnosis and solution, but other times it's not. For Propeller 1 we had a fully functional Schlumberger Focused Ion Beam (FIB) surgery center. This machine proved worth it's total cost because Chip was able to determine and repair the problem within a couple of days. The P2 uses a much tighter process and our FIB machine wouldn't have the precision to operate on a P2 failure, so we've taken it offline. If FIB work is required then Chip will go to a Bay Area lab.
Having been part of the SX introduction I remember it took several trips to the foundry before it functioned per spec. While I hope our situation is different we always have to be prepared for another round of TSMC. Financial planners wouldn't find any job satisfaction dealing with us in this situation because it involves too many unknowns.
I just talked with Chip and he'll be coming into Parallax Tuesday instead of today.
Thinking about it a bit, just now they are in the same bucket as Verilog/VHDL or XMOS and Xc solutions. I mean, are they simple for normal humans to program? Where is the documentation? Where are the tools? For sure not as simple as using a PASM in a COG from Spin.
You're being a bit dishonest. Normal people don't code commercial real-time systems. experienced engineers who know real-time systems do. If they are good, it's not a issue and not mysterious in the least.
As for the Prop. Where is the Parallax documentation that teaches people how to write time critical code in assembly.? IMS Parallax hasn't even put out a book on assembly language programming. Just bits and pieces in app notes. None of the gurus have been forthcoming in putting out a E book on the subject of hard real time coding for the Prop.
As for how difficult programming PRUs (+ core ARMs) is, time will tell. I suspect it's not going to rise to the level of doing the equivalent task with an FPGA, though. As for documentation, a Wiki is located here: Programmable Realtime Unit Software Development. Tools (with I gather more docs) can be downloaded here: PRU Software Development Package.
Isn't the implication here that doing real time means learning stuff? Sure looks like it to me. Where the abstractions pile up for various reasons, the need to punch down to the metal is still there and it still means actually knowing stuff to get it done too.
C + SPIN + PASM or any combination of those things on a P2 isn't a whole lot different. Frankly a P2 could potentially emulate / execute PRU code, and just serve the purpose as a core compatibility / helper chip type function.
Oh, and somebody needs to do a simple campaign, "Interested in PASM? Give the people who know it cold a call!" ...something like that.
You don't much documentation (although I agree there should be some). After all, you know how long each and every non-hub instruction takes: 4 clocks, with a 2 instruction pipeline. The difference here is that you know what the real time constraints are, and can calculate the code requirements. For examples, you have to look no further than the PASM drivers that Parallax and others have created. Each of those are carefully optimized for a particular use case, and provide valuable insight on how to get things done.
For a starters "real-time" has nothing to do with being commercial or not. Plenty of people here are doing real-time things with their propellers for hobby and other projects. Kids were writing real-time software for their C64's back in the 1980's. They called them "games".
"real-time" does not imply fast. It only implies you have to keep up with some external system so there are deadlines you have to meet with some specified degree of accuracy. It boils down to reading inputs at specified times and producing outputs at specified times.
The simple act of flashing a LED twice per second is an example of a real-time task.
Traditionally real-time has been the reserve of the experienced engineers, as you said. Basically because it can get very hard:
When you have many tasks to perform at the same time.
There may be interrupts to set up.
Those interrupts might need to be nested and or prioritized.
You may need a real time operating system to run many tasks.
Those tasks may need to be prioritized.
Do you want cooperative scheduling or preemptive?
What scheduling algorithm?
Things may be fast enough you need to go to assembler.
What about sharing data between tasks, mutual exclusion etc.
And so on and so on.
It's so hard that I have seen teams of experienced real-time systems engineers make a mess of it in avionics projects. Think Primary Flight Computer.
However as we see with the Prop this all gets boiled down to:
I need this task to run on time, throw it into a COG. Done.
Oh, I need it to run faster, do in in PASM which is easily added to your Spin objects. Done.
Of course there are limits to this. Like running out of COGs or raw speed but so it is with any platform.
Now, as for the case in point. An ARM processor running Linux. That's great but I have no real-time guarantees at all. OK let's slap some more little cores on their to handle that hairy stuff.
Now that would be really cool if I could fire up an IDE like the Spin Tool. Write my app in C, say, and right there in the app write the code I want run on a PRU or two. Then "normal people" would have use of that nice feature as simply as they do on the Propeller.
It's kind of unlikely that is going to happen. That was my only little point.
So Rod's point isn't so easily ignored or dismissed, for the fact is that in many commercial applications the argument that "normal people" can't use PRUs (which may or may not be true anyway) doesn't carry much weight. That said, for smaller projects -- in house, low volume, specialized -- and of course for the hobbyist or tinkerer, it does. So conversely, there is a market for something that combines Knowability. Ease of use. Flexibility. Power (enough power, anyway).
Again, I see that I'm splitting the difference here. I guess that's because while I'm not one to throw in the towel on the Propeller commercially, I believe it does have niches to fill, all the same I think it's important to be honest about the realities Prop faces in the marketplace.