In circuit debuggers are very valuable when interrupts and multiple tasks are going on, but that's not really the issue as each COG is pretty much running on its own. I could see the value of being able to break or read/write to Hub memory as thats a shared resource that has the potential for some other COG to potentially step on.
The argument then comes down to whether its worth putting that logic in silicon. Let me suggest an alternative course. As the PropII is being developed in FPGA anyway, that might be the place to put it. Yes the FPGA is more expensive than final silicon, but its a debug tool, that could be offered to the customer base. Yes the hobbyists will balk at the cost, but the engineering side of the world, time to market is way more important than a few hundred or even thousand in cost. You could even offer it to select customers ahead of PropII availability. This is actually a pretty common practice for big complex ICs and systems.
PASD can single stepping self modifying code. You can not set a breakpoint on a modified instruction, but single stepping is not done with setting temporary breakpoints. It works more like a LMM loop, the instructions are copied to one of the 12 longs at begin and exeuted there. Only for jumps, I set temporary breakpoints to get the right next address, and so a jmpret writes the right returnaddress.
But you are right with other limitations of PASD, especially: more then one ORG or 'long val[noparse][[/noparse]n]' are not supported. Many of the limitations can be overcome with more software effort, but others would need some propeller hardware support.
@parallax
For me the most important instruction set extension is a new hub instruction that can reset another cog without reloading it.
Such a 'cogreset id' is easy to implement (IMHO) and brings some interrupt possibility to the propeller. If it is also possible to store the actual PC, where this 'interrupt' occurs in a (shadow-)register then it is perfect.
This allows not only better Debuggers, but is also the solution for implementing timeouts for 'waitpeq/waitpne' and other endless loops. With such an instruction, one cog can act as a interrupt controller for all other cogs.
@ Arndy : Thanks for the clarification. Somewhere in PASD LMM running my code which is an LMM itself interpreting Spin Bytecode it all went horribly wrong. As I said, that's not a dismissive criticism of PASD in itself, it could be a life's work having to deal with these complex forms of coding people can come up with.
...The argument then comes down to whether its worth putting that logic in silicon. Let me suggest an alternative course. As the PropII is being developed in FPGA anyway, that might be the place to put it. Yes the FPGA is more expensive than final silicon, but its a debug tool, that could be offered to the customer base. Yes the hobbyists will balk at the cost, but the engineering side of the world, time to market is way more important than a few hundred or even thousand in cost. You could even offer it to select customers ahead of PropII availability...
Now THIS is a good compromise, and this could get a virtual full-speed "chip" into people's hands long before the actual chip is shipping. The FPGA version could be loaded with debugging support, too,·as it has plenty of extra capacity. Even without debugging support, it would let people begin software development ahead of time. I warn, though, that the cost would likely be $1,000, or more, as the Altera chips we're using cost several hundred dollars, themselves.
1. What are the security implications of releasing your IP in FPGA form? Can the Altera chips be hacked to gain access to the design archtiecture? The Altera chips are configured with a huge proprietary bit stream, and they are very expensive, anyway. I think it would be a lot easier to just reinvent the cicuitry than hijack this setup.
2. How would a pre-release beyond Parallax's office walls affect the Prop II's ultimate patentability? I don't know, or·even care to know. Patents are ugly business that we don't plan on pursuing.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/17/2008 10:23:40 PM GMT
Chip Gracey (Parallax) said...
Now THIS is a good compromise, and this could get a virtual full-speed "chip" into people's hands long before the actual chip is shipping. The FPGA version could be loaded with debugging support, too,·as it has plenty of extra capacity. Even without debugging support, it would let people begin software development ahead of time. I warn, though, that the cost would likely be $1,000, or more, as the Altera chips we're using cost several hundred dollars, themselves.
Sounds like a win-win situation. Can you specify what to buy? ... or ...
Perhaps Parallax will provide a kit/initial support·for early adopters?
Might buy two or three if there was a way to rent them out [noparse]:)[/noparse]
Thanks.
...Can you specify what to buy? ... or ...
Perhaps Parallax will provide a kit/initial support·for early adopters?...
If we do this, we'd likely design a PCB with whatever is required built onto it. These FPGA's always come in several-hundred-pin BGA packages that are a bear to deal with. It's possible that we might be able to make use of some standardized platform that either Altera or one of their partner's makes. We'll see how things shape up. In any case, the FPGA would not be able to emulate any analog pin functions, but do all the digital stuff just fine.
OBC said...
$1000. a hit.. yup, that knocks guys like me out.. [noparse]:([/noparse]
Really knocks most all of us, NO?
Myself, I'd just wait for Prop II than payout a grand for something that isn't a real Prop II. I don't want a BGA version when a 80(+) pin package will do the whole task. And probabliy come in a 'ProtoBoard version' anyway. That's what most of us are waiting for. IMHO.
And that's why it was floated as a professional tool, for the hobbyist paying $1000 to get an advanced copy of chip that would be availible months later and at a small fraction of the price makes no sense. But to a professional, being able to get thier product to market months earlier is easily worth the cost.
I'm convinced now that the FPGA idea is a reasonable compromise for those who demand onboard debugging and are willing to pay for it. I'm more skeptical about any time-to-market advantages, though. The debug-enabled FPGA tool will take extra time to develop and document which, if done ahead of time, and given Parallax's limited development resources, will likely delay the chip introduction itself. Even the months waiting for the first chips to roll out of fab comprise time that would otherwise be given to software development and documentation. So the only real advantage to buying the FPGA tool in advance is that you'd be ahead of those who don't buy it, but not ahead of where you'd have been if the thing was never developed. I think the maximum benefit to the most people would accrue from getting the chip out as quickly as possible, then doing the FPGA dongle if there's still a demand for it.
I agree Phil. Time to market for production is critical and more important than a "special".
Of course any chip house, fabless or not, must deal with lead times and the potential for a "rock".
ADDED: ... and given such potentials, devices are simulated and tested until everyone is sick [noparse]:)[/noparse] I expect that Parallax does much much more in support of getting it right the first time than many can imagine. Verilog test benches, perhaps system C simulations. Hardware is actually ahead of software in their art because of pressures to get it right the first time ....
Paul Baker (Parallax) said...
I am fairly certain that a comprehensive debugger for a multiprocessing system where the entire system can be debugged simultanously has never been done in the entire history of computing. What exactly are you going to do with 8K longs·worth of variables staring you in the face for every step (and thats not counting hub memory), and more simplistically how would you display it all (have tabs and scroll bars, so everytime you want to look someplace different you have to go on a hunting expedition)?
Hmmmm. I've been programming for 20 years and this whole concept of "we don't need a debugger" is mystifying. My time is worth way more than that.
As a programmer for multi-processing game machines like the PlayStation 2 I can assure you there are plenty of debuggers that handle multiprocessor systems with ease. I can't fathom writing code without a debugger to verify the expected results, and many times during PS2 debugging I debugged multiple chips simulateously to see what was happening; a debugger becomes MORE necessary with multi-processors. Try background loading a large complex 3D environment from a slightly scratched disc before a player arrives in the world at the spot where it's needed while trying to render the world they can see, allocate memory for models, textures, AI data, keep music and sounds playing, check input, etc., etc. all simultanesouly and when it dies try and figure out why using printf (which shows up in a huge messy log since it came from many sources and runs at 60 frames per second). The PlayStation 2 also has may different kinds of processors from 16 bit to 128 bit.
I bought a propeller chip so I could exploit every last cycle of every last COG, otherwise I'd use a traditional processor. I was really shocked to find out it didn't have debugging support.
Out of curiosity, do you use software to layout your schematics and circuit boards? That to me is the same as using a debugger. You _could_ draw and layout everything by hand, create net lists by hand, etc., but why waste time and money when you find out you made a silly mistake somehwere? Or that you could make a PC board smaller? Less EMI noisy perhaps? Find better suppliers using your net list? etc.
That's what debuggers do, they not only verify the expected results and help you track down problems, they also give you another view of your system you didn't have before and that allows you to make ever better choices in your design. Alog with debugging, you also get profiling almost for free since the mechanism to single-step hardware is present and you can sample the instruction pointer to gather data, etc.
Finally, I think the FPGA way is pretty interesting, especially if license your IP in Verilog or VHDL.
Comments
In circuit debuggers are very valuable when interrupts and multiple tasks are going on, but that's not really the issue as each COG is pretty much running on its own. I could see the value of being able to break or read/write to Hub memory as thats a shared resource that has the potential for some other COG to potentially step on.
The argument then comes down to whether its worth putting that logic in silicon. Let me suggest an alternative course. As the PropII is being developed in FPGA anyway, that might be the place to put it. Yes the FPGA is more expensive than final silicon, but its a debug tool, that could be offered to the customer base. Yes the hobbyists will balk at the cost, but the engineering side of the world, time to market is way more important than a few hundred or even thousand in cost. You could even offer it to select customers ahead of PropII availability. This is actually a pretty common practice for big complex ICs and systems.
PASD can single stepping self modifying code. You can not set a breakpoint on a modified instruction, but single stepping is not done with setting temporary breakpoints. It works more like a LMM loop, the instructions are copied to one of the 12 longs at begin and exeuted there. Only for jumps, I set temporary breakpoints to get the right next address, and so a jmpret writes the right returnaddress.
But you are right with other limitations of PASD, especially: more then one ORG or 'long val[noparse][[/noparse]n]' are not supported. Many of the limitations can be overcome with more software effort, but others would need some propeller hardware support.
@parallax
For me the most important instruction set extension is a new hub instruction that can reset another cog without reloading it.
Such a 'cogreset id' is easy to implement (IMHO) and brings some interrupt possibility to the propeller. If it is also possible to store the actual PC, where this 'interrupt' occurs in a (shadow-)register then it is perfect.
This allows not only better Debuggers, but is also the solution for implementing timeouts for 'waitpeq/waitpne' and other endless loops. With such an instruction, one cog can act as a interrupt controller for all other cogs.
Andy
I think 2 instructions.
'cogreset id'
and
'cogrestart id'
from saved "actual PC"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Some concerns with the FPGA approach:
1. What are the security implications of releasing your IP in FPGA form? Can the Altera chips be hacked to gain access to the design archtiecture?
2. How would a pre-release beyond Parallax's office walls affect the Prop II's ultimate patentability?
-Phil
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 3/17/2008 10:23:40 PM GMT
Perhaps Parallax will provide a kit/initial support·for early adopters?
Might buy two or three if there was a way to rent them out [noparse]:)[/noparse]
Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
Really knocks most all of us, NO?
Myself, I'd just wait for Prop II than payout a grand for something that isn't a real Prop II. I don't want a BGA version when a 80(+) pin package will do the whole task. And probabliy come in a 'ProtoBoard version' anyway. That's what most of us are waiting for. IMHO.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
-Phil
Of course any chip house, fabless or not, must deal with lead times and the potential for a "rock".
ADDED: ... and given such potentials, devices are simulated and tested until everyone is sick [noparse]:)[/noparse] I expect that Parallax does much much more in support of getting it right the first time than many can imagine. Verilog test benches, perhaps system C simulations. Hardware is actually ahead of software in their art because of pressures to get it right the first time ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jazzed·... about·living in·http://en.wikipedia.org/wiki/Silicon_Valley
Traffic is slow at times, but Parallax orders·always get here fast 8)
Post Edited (jazzed) : 3/18/2008 7:14:32 PM GMT
Sorry, couldn't resist.
-- Remy
As a programmer for multi-processing game machines like the PlayStation 2 I can assure you there are plenty of debuggers that handle multiprocessor systems with ease. I can't fathom writing code without a debugger to verify the expected results, and many times during PS2 debugging I debugged multiple chips simulateously to see what was happening; a debugger becomes MORE necessary with multi-processors. Try background loading a large complex 3D environment from a slightly scratched disc before a player arrives in the world at the spot where it's needed while trying to render the world they can see, allocate memory for models, textures, AI data, keep music and sounds playing, check input, etc., etc. all simultanesouly and when it dies try and figure out why using printf (which shows up in a huge messy log since it came from many sources and runs at 60 frames per second). The PlayStation 2 also has may different kinds of processors from 16 bit to 128 bit.
I bought a propeller chip so I could exploit every last cycle of every last COG, otherwise I'd use a traditional processor. I was really shocked to find out it didn't have debugging support.
Out of curiosity, do you use software to layout your schematics and circuit boards? That to me is the same as using a debugger. You _could_ draw and layout everything by hand, create net lists by hand, etc., but why waste time and money when you find out you made a silly mistake somehwere? Or that you could make a PC board smaller? Less EMI noisy perhaps? Find better suppliers using your net list? etc.
That's what debuggers do, they not only verify the expected results and help you track down problems, they also give you another view of your system you didn't have before and that allows you to make ever better choices in your design. Alog with debugging, you also get profiling almost for free since the mechanism to single-step hardware is present and you can sample the instruction pointer to gather data, etc.
Finally, I think the FPGA way is pretty interesting, especially if license your IP in Verilog or VHDL.
Thanks for listening,
Brett