Leon's post to the Parallax Semiconductor forum gives parallax the opportunity to respond at least with an explanation about why JTAG is not necessary for Professional software development with Propeller and highlight acceptable replacements of methodologies typically expected of that class of customers.
Parallax probably has a lofty sales goal for Parallax Semiconductor customers. Most likely, they have not hit that sales goal yet with the set of super smart customers they already have.
If they do not conform to the needs of most users that are typical of the new class of customers,
Parallax Semiconductor may not be around very long. Nobody wants to see that.
I guess the only possible negative side effect of quibbling is that someone might get the idea that Parallax is not up to the task by themselves. If that's the case, yes we should stop quibbling
Thank you jazzed. I was beginning to get to serious about this topic, you are always there to keep that in check with a valid point and wording that makes one smile.
Let me see if I can summarize the objections to hardware debugging on the Prop II:
1. Hardware debugging uses interrupts, and interrupts are evil, hence we can't have them on the new Prop II and, hence, can't have hardware debugging either.
2. Hardware debugging is like an addictive drug that'll rot your mind and make you a poor programmer, so we don't need it.
3. I used JTAG once in 199x and it was flaky, therefore all JTAG interfaces are likely to be flaky, and we should avoid them at all costs.
4. NIH syndrome. The first Propeller didn't have hardware debugging, and we've gotten along fine with various kludges and hacks for years, so why implement it now and ruin our delightful masochism?
3. I used JTAG once in 199x and it was flaky, therefore all JTAG interfaces are likely to be flaky, and we should avoid them at all costs.
Come on Sal. I was just telling a story about JTAG that really happened and not putting it down. JTAG has value when used right, but like anything else it can be messed up, and when abused can be a problem. Hope that's clear.
JTAG is great for programming as well as debug/profiling and verifying the function of code bottom-up or otherwise especially on CPU/micros that have very little or no user accessible RAM.
I do not see how the Propellers ram is inaccessible. If you need to watch your code, code for that. There is nothing wrong with the various HW debuggers, though they can not accomplish any thing you can not accomplish with out them. How do you people debug when you are working with a standard CPU, no HW debugger there. I think the important thing for Parallax semiconductor is to better document the debugging procedure for the Propeller (both 1 and 2).
That can be a bit tough with 496 instuctions to work with, plus in general it will alter timings which is pretty detrimental when one of the selling points is highly deterministic timing.
That can be a bit tough with 496 instuctions to work with, plus in general it will alter timings which is pretty detrimental when one of the selling points is highly deterministic timing.
C.W.
Well so can watching code using HW methods. and yes it does make a program bigger.
davidsaunders,
x86 CPUs have had debugging facilities built in for a long time (goes back to the 386). It's pretty extensive in modern variants. It's not JTAG, but in some cases it's as much or more than JTAG provides.
I kept meaning to make one of those. Someone I know used to program a RAM with a capacitor soldered to it, unplugged it, and plugged it into the target.
I spent about half a decade involved in testing avionics software. Including Engine controllers for Rolls-Royce motors going into some AirBus or other, Primary Flight software for the Indonisian IPTN N-250, and the Primary Flight Computers of the Boeing 777.
At no time did I have to use a debugger to see what was going on. At no time did I see a debugger on the target hardware being used by the guys writing the code.
Simulators and test harnesses on host machines, yes. Hardware test rigs and test scripts for exercising the integrated hardware and software, yes. Static analysis tools, yes.
JTAG, what's that?
Debugger? If you need one it's too late.
JTAG has other uses apart from debugging. If many devices with JTAG, such as a DSP, and several FPGAs, are on a board, the JTAG chain can be used for hardware testing during manufacture. It can also be used for loading code into the various devices from one connector.
Now you have hit some nail or other on the head. As far as I remember originally the entire purpose of JTAG was as a means of testing completed PCBs.
If you can have one serial line that chains through all devices on a board you can set and read all the pins on all the chips at will thus being able to checkout board connectivity.
All this business about software debugging seems to have been bolted on later.
Looks like the X... company have discovered that JTAG is no use debugging networks of their chips, to slow, does not keep everything in sync. So they have something else now.
Yes, that was the original reason why it was developed. It was some time before it was realised that it could be used for downloading software and debugging.
Seems to me, having read this very entertaining back and forth on JTAG, that a software JTAG like is possible on Prop II, and that the objection is potential timing variances, and or system resources consumed.
The timing argument is a interesting one to me, because I read single stepping as being the primary feature desired. As for system resources, we have tools that can step through PASM now, and if the program is to be written in C, for the pros who want JTAG, a JTAG capable LMM kernel will do a lot. Finally, consuming a small amount of system resources on a chip where most things are done in software, doesn't seem at issue, unless one is forced to test at the maximum capacity of the device in real time. That seems to me a extraordinary requirement. Isn't that really "too late?"
Above it was suggested that a software JTAG is possible and even practical. I can't disagree, given a very large set of the desired features would be made available to those who desire it. Should be a serious project, IMHO. The nice thing about it, in true Propeller fashion, is one can go there or not, depending, keeping the hardware simple and lean.
So then, the core question is one of purity. Say it was possible to do 80 percent JTAG on the Prop through software, and some clever hardware and a few pins. Wouldn't that address most of the exceptions? Seems like it would. How does going the distance on ALL features differ from how JTAG features vary from device to device?
Edit: Another thought occurs to me. How many hardware exploits run through JTAG? I see a lot of them. Now I'm all for that kind of thing, being one who hates it when stuff I buy doesn't trust me enough to be re-purposed. Don't get me wrong on that, but there is a case for wanting to close things down. If Prop II has a solid code protect, with some encryption that matters, wouldn't being able to unload JTAG for the final delivery make a whole lot of sense? That could be positioned very well in some circles.
I think that JTAG on each cog will be required, though. That "other" company has JTAG on each core.
That "other" company also has an architecture and an instruction set so mind-bogglingly complex that you probably need a JTAG on each core!
Fortunately, the Prop architecture is so orthogonal and the instruction set is so simple that most of us can debug programs of arbitrary complexity with a single output pin. Being deterministic and having no interrupts to worry about also helps a lot.
I'm not saying JTAG wouldn't be useful - just that it is not so necessary on the Prop as it is on many other chips.
Comments
Parallax probably has a lofty sales goal for Parallax Semiconductor customers. Most likely, they have not hit that sales goal yet with the set of super smart customers they already have.
If they do not conform to the needs of most users that are typical of the new class of customers,
Parallax Semiconductor may not be around very long. Nobody wants to see that.
I guess the only possible negative side effect of quibbling is that someone might get the idea that Parallax is not up to the task by themselves. If that's the case, yes we should stop quibbling
1. Hardware debugging uses interrupts, and interrupts are evil, hence we can't have them on the new Prop II and, hence, can't have hardware debugging either.
2. Hardware debugging is like an addictive drug that'll rot your mind and make you a poor programmer, so we don't need it.
3. I used JTAG once in 199x and it was flaky, therefore all JTAG interfaces are likely to be flaky, and we should avoid them at all costs.
4. NIH syndrome. The first Propeller didn't have hardware debugging, and we've gotten along fine with various kludges and hacks for years, so why implement it now and ruin our delightful masochism?
Did I get them all?
-Phil
5. My software never has bugs, therefore I don't need a debugger.
I don't think that anyone actually said that in so many words, but it was implied.
Yeah that pretty much covers it
6: Propeller II design is already finalized.
And to any one that falls under Leons #5:
Where do I sign up for Become a Deity school???
-Phil
JTAG is great for programming as well as debug/profiling and verifying the function of code bottom-up or otherwise especially on CPU/micros that have very little or no user accessible RAM.
-Phil
I do not see how the Propellers ram is inaccessible. If you need to watch your code, code for that. There is nothing wrong with the various HW debuggers, though they can not accomplish any thing you can not accomplish with out them. How do you people debug when you are working with a standard CPU, no HW debugger there. I think the important thing for Parallax semiconductor is to better document the debugging procedure for the Propeller (both 1 and 2).
That can be a bit tough with 496 instuctions to work with, plus in general it will alter timings which is pretty detrimental when one of the selling points is highly deterministic timing.
C.W.
Well so can watching code using HW methods. and yes it does make a program bigger.
Call them as you will. I and many others still use these still produced, well designed devices.
I don't know about you guys, but when I used those "ancient" devices professionally back in the day, I used a full-blown ICE.
x86 CPUs have had debugging facilities built in for a long time (goes back to the 386). It's pretty extensive in modern variants. It's not JTAG, but in some cases it's as much or more than JTAG provides.
I couldn't afford one, so I used to write a monitor/debugger, put it into EPROM, and did my debugging in RAM via the serial port using my TRS-80.
I spent about half a decade involved in testing avionics software. Including Engine controllers for Rolls-Royce motors going into some AirBus or other, Primary Flight software for the Indonisian IPTN N-250, and the Primary Flight Computers of the Boeing 777.
At no time did I have to use a debugger to see what was going on. At no time did I see a debugger on the target hardware being used by the guys writing the code.
Simulators and test harnesses on host machines, yes. Hardware test rigs and test scripts for exercising the integrated hardware and software, yes. Static analysis tools, yes.
JTAG, what's that?
Debugger? If you need one it's too late.
Now you have hit some nail or other on the head. As far as I remember originally the entire purpose of JTAG was as a means of testing completed PCBs.
If you can have one serial line that chains through all devices on a board you can set and read all the pins on all the chips at will thus being able to checkout board connectivity.
All this business about software debugging seems to have been bolted on later.
Looks like the X... company have discovered that JTAG is no use debugging networks of their chips, to slow, does not keep everything in sync. So they have something else now.
The timing argument is a interesting one to me, because I read single stepping as being the primary feature desired. As for system resources, we have tools that can step through PASM now, and if the program is to be written in C, for the pros who want JTAG, a JTAG capable LMM kernel will do a lot. Finally, consuming a small amount of system resources on a chip where most things are done in software, doesn't seem at issue, unless one is forced to test at the maximum capacity of the device in real time. That seems to me a extraordinary requirement. Isn't that really "too late?"
Above it was suggested that a software JTAG is possible and even practical. I can't disagree, given a very large set of the desired features would be made available to those who desire it. Should be a serious project, IMHO. The nice thing about it, in true Propeller fashion, is one can go there or not, depending, keeping the hardware simple and lean.
So then, the core question is one of purity. Say it was possible to do 80 percent JTAG on the Prop through software, and some clever hardware and a few pins. Wouldn't that address most of the exceptions? Seems like it would. How does going the distance on ALL features differ from how JTAG features vary from device to device?
Edit: Another thought occurs to me. How many hardware exploits run through JTAG? I see a lot of them. Now I'm all for that kind of thing, being one who hates it when stuff I buy doesn't trust me enough to be re-purposed. Don't get me wrong on that, but there is a case for wanting to close things down. If Prop II has a solid code protect, with some encryption that matters, wouldn't being able to unload JTAG for the final delivery make a whole lot of sense? That could be positioned very well in some circles.
Fortunately, the Prop architecture is so orthogonal and the instruction set is so simple that most of us can debug programs of arbitrary complexity with a single output pin. Being deterministic and having no interrupts to worry about also helps a lot.
I'm not saying JTAG wouldn't be useful - just that it is not so necessary on the Prop as it is on many other chips.
Ross.