and to reality check the comments on RAM, on the Prop II device, try this new release from Toshiba :
The TMPM327C3D has an ARM Cortex-M3 core operating at frequencies up to 144MHz and
is available with 1.5MBytes or 3Mbytes of integrated eDRAM, allowing it to support respective display resolutions from typically WQVGA to WVGA without the need for external RAM.
An additional 320Kbytes of SRAM is available for program and data storage. An
integrated graphics engine, video input and digital RGB output further reduce external
component count, while a special bus structure reduces CPU load during display and audio
decoding. Built-in connectivity includes USB 2.0 High Speed Host Control, SDHC control, a
3-channel CVBS decoder, I2C and I2S interfaces.
No price hints yet, but 3Mbytes of integrated eDRAM is eye watering stuff.
Sounds like this loads code into SRAM, no mention of if it will also Execute In Place from QuadSPI Flash, but many new arms now offer that too ?
and to reality check the comments on RAM, on the Prop II device, try this new release from Toshiba :[/i]
No price hints yet, but 3Mbytes of integrated eDRAM is eye watering stuff.
Yep, that's the trend. Even the LPC1768 I use has 512KB of FLASH and 64KB RAM. Newer chips are being built with the latest 40nm and 28nm processes. The PropII, I believe, will be built with a process several generations old, and hence, will only be able to have 128KB of hub RAM due to limits on die size. Cog RAM is limited by the 9-bit limit on source/destination addresses hardwired into the instruction set.
Yep, that's the trend. Even the LPC1768 I use has 512KB of FLASH and 64KB RAM. Newer chips are being built with the latest 40nm and 28nm processes. The PropII, I believe, will be built with a process several generations old, and hence, will only be able to have 128KB of hub RAM due to limits on die size. Cog RAM is limited by the 9-bit limit on source/destination addresses hardwired into the instruction set.
Yeah I think thats a good move (cannibalising the ROM for more RAM).
Based on that the prop2 may end up having a truly unique 185.5 kB or something, depending on the available physical space
More importantly, it also means we can run a sweepstake for the person that has the closest guess to the final amount of RAM (Beau and Chip disqualified from entering!)
I bet they round it to the nearest unit power of two. So some address bits will be unused, but able to be masked easily.
That was a great overview today. Did anyone else pick up on the idea of a series? So, we will get Prop II, then some versions after that. Prop III might not be for a while, with a few trade-offs being made to address niches with Prop II core design.
I think internal EEPROM would have been a very big win with commercial users because even the rudimentary security provided by the "code protection fuse" of a PIC provides a substantial level of protection against code compromise by anyone but large corporations and governments. What this does for the commerical guy is provide a speed bump of sorts - at least in the USA if your competitor defeats a code protect fuse, reverse engineers your IP, and sells something you can stick it to them in court through the Digital Millenium Copyright Act. The key to making your lawyers effective and nasty is that you can show that an 'extraordinary' level of effort is needed to recover the code.
I think for an *external* EEPROM its so wide open you wouldn't have a decent case. At any rate, that's why I can't use Prop I in my real world products - I just can't protect the IP.
A year ago I was strongly of the opinion that Prop2 should provide support for a JTAG device. I most profoundly don't think so any more. What changed is that I spent the last year using JTAG on ARM7 chips from ADI. What I think now is that JTAG is a horrid waste of six precious I/O pins. I would gladly trade it for a simple diagnostic serial port, using one pin, connected to an ASCII terminal.
This isn't a hypothetical comparison. On my desk right now, six inches from my left elbow, are an ARM7 and a Prop. They are tied together by an SPI. Debugging of the ARM is via JTAG, and debugging of the Prop is via video from a single cog. The video connection allows me to monitor anything I specify, in real-time, real fast, without having to stop execution. JTAG, on the other hand, is strictly post-mortem. I have to stop execution to view anything meaningful. (Semi-hosting is a joke. It's far too slow, and dogs down the processor so badly that the results I DO get are completely artificial.)
Unfortunately for post-mortem inspection, the rest of the world doesn't stop. It is a ridiculous way to 'view' what is going on. I suppose I could remove the JTAG pod and program a bit-banged serial port on one of the liberated pins, but that would further complicate (and interfere with) an already messy ISR. The beauty of the Prop is that the cog providing diagnostic I/O is utterly transparent (to the point of invisibility) to the other operations on the chip, and yet can provide monitoring as fast as 32-bits per microsecond.
In fact the Prop is so effective as a debugging tool that I now use it to debug the ARM7. All the remaining bugs are in the ARM code, anyway.
My 44 cents worth is give us 1 GHz cogs for Prop 2. You see the interest in the supercomputer thread for a build it yourself supercomputer. For Prop 3 give us 12 GHz cogs. Instead of incremental improvements, make a giant leap.
The Prop's independent cogs do provide for some useful debugging. As long as the other cogs aren't stepping on the I/O pins, a watchdog cog can drive a video or serial output. I've never used the debugging tools that some people have implemented, but it looks like they would be very helpful. I have used a spare cog to monitor memory locations and print out debug information in the past.
Just a thought, the current P8X32A with additional IO to fill a 68 pin QFP and 64K RAM would be a good idea (squeeze in extra 2 cores even better).
For my applications (most of them) the prop 2 is overkill (and possibly more expensive than say a LPC17xx which we currently use) and the P8X32A is lite on memory and IO.
Money is not everything. (you should read Drive! by Dan Pink)
However, they only hoped to get 160Mhz, they didn't promise it. They also planning deliver a lot more in hardware then previously expected (particularly with the I/Os and with math). They might still get 120Mhz instead of 100Mhz, we won't really know until we get some actual silicon.
Hmm, I think in this case peformance scales linearly with clock rate. The Prop 2 specs on the Parallax Semiconductor site say that the 160 MHz was "planned", which is a little stronger than "hoped". 100 MHz single-cycle instructions are still good, but only 62.5 percent as good as 160 MHz.
Things just take longer to make than I imagine they would, then they run slower than planned.
If you happen to need those features that slow the architecture down, though, you might not mind if the chip ran at only 10MHz, because 500MHz wouldn't have been enough, otherwise. The texture mapping, CORDIC, and Goertzel circuits are examples of this. Then, there are some instructions which can inc/dec patterns, maintaining the numbers of 1's and 0's. A couple of us at Parallax have had to code those discretely (for reasons which none of us could recall, exactly), and we all remember it being a huge headache. Now there are instructions for that - and they even have to be multicycled at 100MHz. They'll save you a whole program, though.
A lot of the signal delay comes from the sheer amount of mux'ing that must be implemented to handle all of the result contributors. Then there's the data-forwarding circuits, which add right to the critical paths. A simpler chip would have run faster.
... I would gladly trade it for a simple diagnostic serial port, using one pin, connected to an ASCII terminal.
.... debugging of the Prop is via video from a single cog. The video connection allows me to monitor anything I specify, in real-time, real fast, without having to stop execution. JTAG, on the other hand, is strictly post-mortem. I have to stop execution to view anything meaningful. (Semi-hosting is a joke. It's far too slow, and dogs down the processor so badly that the results I DO get are completely artificial.)
Unfortunately for post-mortem inspection, the rest of the world doesn't stop. It is a ridiculous way to 'view' what is going on. I suppose I could remove the JTAG pod and program a bit-banged serial port on one of the liberated pins, but that would further complicate (and interfere with) an already messy ISR. The beauty of the Prop is that the cog providing diagnostic I/O is utterly transparent (to the point of invisibility) to the other operations on the chip, and yet can provide monitoring as fast as 32-bits per microsecond.
You need to separate the Pin-Cost, from the information pathway.
You are using Video, but that also costs pins, and also requires the user has compatible hardware.
So if we avoid the JTAG pin costs, and focus on the information, what is needed is a low pin cost, high speed link to the PC.
That way you get similar information, without stopping the target, and in a very user-portable way.
I think the next generation debug links, will use smarter silicon than 'FT232R' UARTS, and that trend is already seen :
** Nuvoton use a 32 bit M0 CPU in their Nu-Link, which comes as half of their $20 EVB
** CooCox have a LPC13xx USB uC for their link - I expect that will flip to the M0 LPC11Uxx when it is real enough.
** Arduino have changed to a Mega8U/16U/32U, for the link
** SiLego use a Cypress PSoC, and provide waveform generation, and capture, on their Pgm/Emulate tools
I'd like to see tools that can Generate Test/Stimulus clocks, and Logic probe / Frequency/time measure
With those small USB micros, all that is just SW.
Of course, they would have a Boot/Pgn pathway, and a fast streaming 'Live' debug ability too.
If I was choosing a uC it would be the LPC11Uxx as that has the best timer support, for high resolution frequency counters.
On the Prop2, I'd allow a 2 pin CLK-DATA port/shift register, perhaps even shared with the Boot i2c, for really low impact...
Considering the relative speed and ease with which a chip design can be synthesized from an HDL file, I think it would be fantastic to have two flavors of Prop II. One would have all the great features and the other would be lean and mean for speed. Any spare real estate in the lean-and-mean Prop could be devoted to more hub RAM or a bare bones stand-alone development system in ROM. (I favor the latter. A self-hosting Prop is SO enticing to me!)
I always want my last pound of flesh!
If the instruction execution clock has to be slower, could the counters still run faster???
I have already asked that question in another thread.
Counters should always run at the masimum possible speeds, but having said that, 100MHz for a 32 bit Sync re-load counter,
is quite a good speed. 200MHz, is likely to be tough, but yes, that would be nice.
It takes a very leading edge FPGA to deliver > 150MHz wide counters.
The 65nm Lattice MachXO2, specs 146MHz for a wide counter.
Prop 2 is a couple of generations back from that, but does not have the fabric overheads.
I just reread the top post again to get a feel of things.
The first question that springs to mind is "which markets (applications) is the prop 2 intended for?".
Perhaps the parallax guys can shed some light on this.
I have used the P8X32A in several contract designs and I am currently designing with it for one of our products. It is quite OK as an embedded controller albeit with no code security etc but as I have said before lite on memory and IO. I think this device should have had its memory and IO expanded as I have several applications that I could throw it into is this was so. I would also think time to market for such a device would be faster than the prop 2.
However when I look at the prop 2 specs I immediately compare it with our workhorse device the LPC1754 which clocks @100MHz, with good IO and peripheral support and we can buy it at $3.90 (500+ price), with no need to add an EEPROM and second regulator for additional cost.
Comments
The TMPM327C3D has an ARM Cortex-M3 core operating at frequencies up to 144MHz and
is available with 1.5MBytes or 3Mbytes of integrated eDRAM, allowing it to support respective display resolutions from typically WQVGA to WVGA without the need for external RAM.
An additional 320Kbytes of SRAM is available for program and data storage. An
integrated graphics engine, video input and digital RGB output further reduce external
component count, while a special bus structure reduces CPU load during display and audio
decoding. Built-in connectivity includes USB 2.0 High Speed Host Control, SDHC control, a
3-channel CVBS decoder, I2C and I2S interfaces.
No price hints yet, but 3Mbytes of integrated eDRAM is eye watering stuff.
Sounds like this loads code into SRAM, no mention of if it will also Execute In Place from QuadSPI Flash, but many new arms now offer that too ?
Yep, that's the trend. Even the LPC1768 I use has 512KB of FLASH and 64KB RAM. Newer chips are being built with the latest 40nm and 28nm processes. The PropII, I believe, will be built with a process several generations old, and hence, will only be able to have 128KB of hub RAM due to limits on die size. Cog RAM is limited by the 9-bit limit on source/destination addresses hardwired into the instruction set.
Now I'm little angry.
If You like that ones -- Why You are on this forum?
Why are you angry? Sure I like the LPC1768, but I also like the Propeller, which is why I'm on this forum.
Just because I like the propeller doesn't mean I can't like other processors, now does it?
Based on that the prop2 may end up having a truly unique 185.5 kB or something, depending on the available physical space
More importantly, it also means we can run a sweepstake for the person that has the closest guess to the final amount of RAM (Beau and Chip disqualified from entering!)
That was a great overview today. Did anyone else pick up on the idea of a series? So, we will get Prop II, then some versions after that. Prop III might not be for a while, with a few trade-offs being made to address niches with Prop II core design.
I think internal EEPROM would have been a very big win with commercial users because even the rudimentary security provided by the "code protection fuse" of a PIC provides a substantial level of protection against code compromise by anyone but large corporations and governments. What this does for the commerical guy is provide a speed bump of sorts - at least in the USA if your competitor defeats a code protect fuse, reverse engineers your IP, and sells something you can stick it to them in court through the Digital Millenium Copyright Act. The key to making your lawyers effective and nasty is that you can show that an 'extraordinary' level of effort is needed to recover the code.
I think for an *external* EEPROM its so wide open you wouldn't have a decent case. At any rate, that's why I can't use Prop I in my real world products - I just can't protect the IP.
V/R
Mike
This isn't a hypothetical comparison. On my desk right now, six inches from my left elbow, are an ARM7 and a Prop. They are tied together by an SPI. Debugging of the ARM is via JTAG, and debugging of the Prop is via video from a single cog. The video connection allows me to monitor anything I specify, in real-time, real fast, without having to stop execution. JTAG, on the other hand, is strictly post-mortem. I have to stop execution to view anything meaningful. (Semi-hosting is a joke. It's far too slow, and dogs down the processor so badly that the results I DO get are completely artificial.)
Unfortunately for post-mortem inspection, the rest of the world doesn't stop. It is a ridiculous way to 'view' what is going on. I suppose I could remove the JTAG pod and program a bit-banged serial port on one of the liberated pins, but that would further complicate (and interfere with) an already messy ISR. The beauty of the Prop is that the cog providing diagnostic I/O is utterly transparent (to the point of invisibility) to the other operations on the chip, and yet can provide monitoring as fast as 32-bits per microsecond.
In fact the Prop is so effective as a debugging tool that I now use it to debug the ARM7. All the remaining bugs are in the ARM code, anyway.
http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php
It's supported by most JTAG interfaces, like the Rowley CrossConnect Pro that I use. It works very well.
-Phil
The Prop's independent cogs do provide for some useful debugging. As long as the other cogs aren't stepping on the I/O pins, a watchdog cog can drive a video or serial output. I've never used the debugging tools that some people have implemented, but it looks like they would be very helpful. I have used a spare cog to monitor memory locations and print out debug information in the past.
Dave
For my applications (most of them) the prop 2 is overkill (and possibly more expensive than say a LPC17xx which we currently use) and the P8X32A is lite on memory and IO.
Cheers.
That's a bit like having your salary cut in half, then saying that "money isn't everything."
A drop from 160MHz to 100MHz is a big drop, especially considering that all of the other performance-enhancing factors would be there either way.
However, they only hoped to get 160Mhz, they didn't promise it. They also planning deliver a lot more in hardware then previously expected (particularly with the I/Os and with math). They might still get 120Mhz instead of 100Mhz, we won't really know until we get some actual silicon.
If you happen to need those features that slow the architecture down, though, you might not mind if the chip ran at only 10MHz, because 500MHz wouldn't have been enough, otherwise. The texture mapping, CORDIC, and Goertzel circuits are examples of this. Then, there are some instructions which can inc/dec patterns, maintaining the numbers of 1's and 0's. A couple of us at Parallax have had to code those discretely (for reasons which none of us could recall, exactly), and we all remember it being a huge headache. Now there are instructions for that - and they even have to be multicycled at 100MHz. They'll save you a whole program, though.
A lot of the signal delay comes from the sheer amount of mux'ing that must be implemented to handle all of the result contributors. Then there's the data-forwarding circuits, which add right to the critical paths. A simpler chip would have run faster.
You need to separate the Pin-Cost, from the information pathway.
You are using Video, but that also costs pins, and also requires the user has compatible hardware.
So if we avoid the JTAG pin costs, and focus on the information, what is needed is a low pin cost, high speed link to the PC.
That way you get similar information, without stopping the target, and in a very user-portable way.
I think the next generation debug links, will use smarter silicon than 'FT232R' UARTS, and that trend is already seen :
** Nuvoton use a 32 bit M0 CPU in their Nu-Link, which comes as half of their $20 EVB
** CooCox have a LPC13xx USB uC for their link - I expect that will flip to the M0 LPC11Uxx when it is real enough.
** Arduino have changed to a Mega8U/16U/32U, for the link
** SiLego use a Cypress PSoC, and provide waveform generation, and capture, on their Pgm/Emulate tools
I'd like to see tools that can Generate Test/Stimulus clocks, and Logic probe / Frequency/time measure
With those small USB micros, all that is just SW.
Of course, they would have a Boot/Pgn pathway, and a fast streaming 'Live' debug ability too.
If I was choosing a uC it would be the LPC11Uxx as that has the best timer support, for high resolution frequency counters.
On the Prop2, I'd allow a 2 pin CLK-DATA port/shift register, perhaps even shared with the Boot i2c, for really low impact...
-Phil
I agree with this. Of all the changes to the plan, the raw clock speed is not likely to have a large impact on what I do with Prop 2.
If the instruction execution clock has to be slower, could the counters still run faster???
But I guess in reality, this is no 1GHz ARM or equivalent. We are not going to run a modern Linux.
I have already asked that question in another thread.
Counters should always run at the masimum possible speeds, but having said that, 100MHz for a 32 bit Sync re-load counter,
is quite a good speed. 200MHz, is likely to be tough, but yes, that would be nice.
It takes a very leading edge FPGA to deliver > 150MHz wide counters.
The 65nm Lattice MachXO2, specs 146MHz for a wide counter.
Prop 2 is a couple of generations back from that, but does not have the fabric overheads.
The first question that springs to mind is "which markets (applications) is the prop 2 intended for?".
Perhaps the parallax guys can shed some light on this.
I have used the P8X32A in several contract designs and I am currently designing with it for one of our products. It is quite OK as an embedded controller albeit with no code security etc but as I have said before lite on memory and IO. I think this device should have had its memory and IO expanded as I have several applications that I could throw it into is this was so. I would also think time to market for such a device would be faster than the prop 2.
However when I look at the prop 2 specs I immediately compare it with our workhorse device the LPC1754 which clocks @100MHz, with good IO and peripheral support and we can buy it at $3.90 (500+ price), with no need to add an EEPROM and second regulator for additional cost.
Just some musings...................