>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>> >> if you happen to have one handy.
>>>>>>>>> >> Jon
>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>> >of the PCA counter in both places.
>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>> Jon
>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>Jon
>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>JTAG standards were forced to be about functional verification rather >>>>>>than measuring performance because of this.
>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>register. There is boundary checking, of course. But flashing and
>>>>It most certainly is not.
>>>Must be some other interface I remember, then. I was able to shift >>>out and examine almost every internal flip-flop state, for example. >>>Thousands of bits worth. Gave me access to pretty much everything, if >>>the designers included the bits into the serial chain. I'd use test >>>vectors which allowed me to set register values, both hidden and >>>observable to a programmer, etc., before taking an instruction step.
>>The designers don't want you to have that information. It's the >>family jewels. Emulation types get it only after signing a pile of >>contracts and giving up their first offspring.
>Normally, I suppose. I think the ARM7 documentation discloses much, >if not all. Or perhaps I'm wrong about that, as well. However, my >case was for a different processor.
Could be they've laid the whole design out hoping someone would copy it? Dunno, but this is usually *highly* sensitive information. We had a lot of hidden performance and feature switches in there that we certainly didn't want the user diddling with (or so much as knowing they were even there).
>>>>JTAG is a way to access internal registers >>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>take your point, for now. It's quite possible I've conflated JTAG >>>with something else.
>>No, these things are often accessible via JTAG. The interface could >>be "buggy" I suppose, though would highly doubt. It may not be well >>documented since it's not generally accessible by anyone outside the >>chip manufacturer.
>So are you saying that my original post is essentially correct, then?
Essentially, though different manufacturers may use it differently.
>That JTAG is at its fundamental level a shift register chaining >together state bits of possible interest? (It's how I'd imagined it >up to now, until Nico wrote to tell me I was wrong, but I admit not >being an expert in this area.)
That's pretty much it. "Of interest" may be the sticking point. Of interest to whom? The manufacturer has different uses than the user. Both may be accommodated in JTAG but the manufacturer my not disclose the information needed to get at the guts of the chip. For example, they may only disclose the boundary scan stuff for ICT and keep everything else a trade secret. The manufacturer may be able to get at every latch in the chip (as we did, though this was "free" because of the design rules) but I'd be very surprised to see one publish this information. ...if for no other reason than it changes from rev to rev.
JTAG is a requirement so why not use it for the kitchen sink too.
>>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>>> >> if you happen to have one handy.
>>>>>>>>>> >> Jon
>>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>>> >of the PCA counter in both places.
>>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>>> Jon
>>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>>Jon
>>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>>JTAG standards were forced to be about functional verification rather >>>>>>>than measuring performance because of this.
>>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>>register. There is boundary checking, of course. But flashing and
>>>>>It most certainly is not.
>>>>Must be some other interface I remember, then. I was able to shift >>>>out and examine almost every internal flip-flop state, for example. >>>>Thousands of bits worth. Gave me access to pretty much everything, if >>>>the designers included the bits into the serial chain. I'd use test >>>>vectors which allowed me to set register values, both hidden and >>>>observable to a programmer, etc., before taking an instruction step.
>>>The designers don't want you to have that information. It's the >>>family jewels. Emulation types get it only after signing a pile of >>>contracts and giving up their first offspring.
>>Normally, I suppose. I think the ARM7 documentation discloses much, >>if not all. Or perhaps I'm wrong about that, as well. However, my >>case was for a different processor.
>Could be they've laid the whole design out hoping someone would copy >it? Dunno, but this is usually *highly* sensitive information. We >had a lot of hidden performance and feature switches in there that we >certainly didn't want the user diddling with (or so much as knowing >they were even there).
>>>>>JTAG is a way to access internal registers >>>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>>take your point, for now. It's quite possible I've conflated JTAG >>>>with something else.
>>>No, these things are often accessible via JTAG. The interface could >>>be "buggy" I suppose, though would highly doubt. It may not be well >>>documented since it's not generally accessible by anyone outside the >>>chip manufacturer.
>>So are you saying that my original post is essentially correct, then?
>Essentially, though different manufacturers may use it differently.
Thanks. I'm glad to keep my prior mental model and discard Nico's distraction from it.
>>That JTAG is at its fundamental level a shift register chaining >>together state bits of possible interest? (It's how I'd imagined it >>up to now, until Nico wrote to tell me I was wrong, but I admit not >>being an expert in this area.)
>That's pretty much it. "Of interest" may be the sticking point. Of >interest to whom?
Yes. That is implied. This is the internals we are talking about and that can get into nitty-gritty implementation details if the manufacturer decides to expose any of that. They could just chain together obvious things only. But then it wouldn't be nearly as useful.
The manufacturer has different uses than the user.
>Both may be accommodated in JTAG but the manufacturer my not disclose >the information needed to get at the guts of the chip. For example, >they may only disclose the boundary scan stuff for ICT and keep >everything else a trade secret. The manufacturer may be able to get >at every latch in the chip (as we did, though this was "free" because >of the design rules) but I'd be very surprised to see one publish this >information. ...if for no other reason than it changes from rev to >rev.
Personally, I would like _everything_ out on the table and in plain view. Intel would provide regular specification updates on their chips, including changes in package designators, bugs that apply to one and not another, and so on. It should be no real issue to include the complete JTAG chain disclosed for each stepping and change, as well. And let users beware.
If someone doesn't want to worry their pretty little head over these things, they can leave it to some commercial vendor to do. If they want to, then they can. Simple.
But disclose.
>JTAG is a requirement so why not use it for the kitchen sink too.
Hehe. I sure would. Expose every single state bit to the chain. Combinatorials don't have state, so no worry. If it holds a state, chain it.
>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>> >> if you happen to have one handy.
>>>>>>>>> >> Jon
>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>> >of the PCA counter in both places.
>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>> Jon
>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>Jon
>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>JTAG standards were forced to be about functional verification rather >>>>>>than measuring performance because of this.
>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>register. There is boundary checking, of course. But flashing and
>>>>It most certainly is not.
>>>Must be some other interface I remember, then. I was able to shift >>>out and examine almost every internal flip-flop state, for example. >>>Thousands of bits worth. Gave me access to pretty much everything, if >>>the designers included the bits into the serial chain. I'd use test >>>vectors which allowed me to set register values, both hidden and >>>observable to a programmer, etc., before taking an instruction step.
>>The designers don't want you to have that information. It's the >>family jewels. Emulation types get it only after signing a pile of >>contracts and giving up their first offspring.
>Normally, I suppose. I think the ARM7 documentation discloses much, >if not all. Or perhaps I'm wrong about that, as well. However, my >case was for a different processor.
The ARM documentation specifies most internals behind the JTAG interface. The documentation on how to access the registers through JTAG is usually a few pages. The 100+ pages describe the rest.
>>>>JTAG is a way to access internal registers >>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>take your point, for now. It's quite possible I've conflated JTAG >>>with something else.
>>No, these things are often accessible via JTAG. The interface could >>be "buggy" I suppose, though would highly doubt. It may not be well >>documented since it's not generally accessible by anyone outside the >>chip manufacturer.
>So are you saying that my original post is essentially correct, then? >That JTAG is at its fundamental level a shift register chaining >together state bits of possible interest? (It's how I'd imagined it
No, like I typed before: JTAG offers a bunch of registers addressed by a command register. Generally speaking: If you want to read pins, you'll need to send a command 'read pins' followed by several reads of the data register.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... "If it doesn't fit, use a bigger hammer!" --------------------------------------------------------------
>>>So are you saying that my original post is essentially correct, then?
>>Essentially, though different manufacturers may use it differently.
>Thanks. I'm glad to keep my prior mental model and discard Nico's >distraction from it.
>>>That JTAG is at its fundamental level a shift register chaining >>>together state bits of possible interest? (It's how I'd imagined it >>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>being an expert in this area.)
>>That's pretty much it. "Of interest" may be the sticking point. Of >>interest to whom?
>Yes. That is implied. This is the internals we are talking about and >that can get into nitty-gritty implementation details if the >manufacturer decides to expose any of that. They could just chain >together obvious things only. But then it wouldn't be nearly as >useful.
The minimum, of course, is the boundary scan. That's a customer requirement for ICT. From there, it's a convenient port for the manufacturer.
>The manufacturer has different uses than the user. >>Both may be accommodated in JTAG but the manufacturer my not disclose >>the information needed to get at the guts of the chip. For example, >>they may only disclose the boundary scan stuff for ICT and keep >>everything else a trade secret. The manufacturer may be able to get >>at every latch in the chip (as we did, though this was "free" because >>of the design rules) but I'd be very surprised to see one publish this >>information. ...if for no other reason than it changes from rev to >>rev.
>Personally, I would like _everything_ out on the table and in plain >view. Intel would provide regular specification updates on their >chips, including changes in package designators, bugs that apply to >one and not another, and so on. It should be no real issue to include >the complete JTAG chain disclosed for each stepping and change, as >well. And let users beware.
You might like a vacation on the International Space Station too. It's not in the manufacturer's interest to tell you all his secrets. ...particularly ones that are trade secrets or you have no need to know.
>If someone doesn't want to worry their pretty little head over these >things, they can leave it to some commercial vendor to do. If they >want to, then they can. Simple.
It's not that simple. Documenting this stuff for others to use is difficult and it does change.
>But disclose.
What's in it for the manufacturer, other than losing control of their trade secrets and increased costs? What would you do with a listing of 10M latches?
>>JTAG is a requirement so why not use it for the kitchen sink too.
>Hehe. I sure would. Expose every single state bit to the chain. >Combinatorials don't have state, so no worry. If it holds a state, >chain it.
You forget what that costs. In the chips I worked on there was no cost because that was already done because of the design rules and JTAG was simply a convenient port to access these latch "chains". Other design methodologies may not make this so easy. Would you spend 10% of a chip's logic to do this? 20%? 30%?
>>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>>> >> if you happen to have one handy.
>>>>>>>>>> >> Jon
>>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>>> >of the PCA counter in both places.
>>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>>> Jon
>>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>>Jon
>>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>>JTAG standards were forced to be about functional verification rather >>>>>>>than measuring performance because of this.
>>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>>register. There is boundary checking, of course. But flashing and
>>>>>It most certainly is not.
>>>>Must be some other interface I remember, then. I was able to shift >>>>out and examine almost every internal flip-flop state, for example. >>>>Thousands of bits worth. Gave me access to pretty much everything, if >>>>the designers included the bits into the serial chain. I'd use test >>>>vectors which allowed me to set register values, both hidden and >>>>observable to a programmer, etc., before taking an instruction step.
>>>The designers don't want you to have that information. It's the >>>family jewels. Emulation types get it only after signing a pile of >>>contracts and giving up their first offspring.
>>Normally, I suppose. I think the ARM7 documentation discloses much, >>if not all. Or perhaps I'm wrong about that, as well. However, my >>case was for a different processor.
>The ARM documentation specifies most internals behind the JTAG >interface. The documentation on how to access the registers through >JTAG is usually a few pages. The 100+ pages describe the rest.
How do you know it's "most"? The architected registers are a *small* part of a design.
>>>>>JTAG is a way to access internal registers >>>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>>take your point, for now. It's quite possible I've conflated JTAG >>>>with something else.
>>>No, these things are often accessible via JTAG. The interface could >>>be "buggy" I suppose, though would highly doubt. It may not be well >>>documented since it's not generally accessible by anyone outside the >>>chip manufacturer.
>>So are you saying that my original post is essentially correct, then? >>That JTAG is at its fundamental level a shift register chaining >>together state bits of possible interest? (It's how I'd imagined it
>No, like I typed before: JTAG offers a bunch of registers addressed by >a command register. Generally speaking: If you want to read pins, >you'll need to send a command 'read pins' followed by several reads of >the data register.
On Sun, 08 Nov 2009 10:30:05 -0600, krw <k...@att.bizzzzzzzzzzz> wrote: >On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan ><j...@infinitefactors.org> wrote:
>>On Sat, 07 Nov 2009 18:59:39 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>On Sat, 07 Nov 2009 16:33:14 -0800, Jon Kirwan >>><j...@infinitefactors.org> wrote:
><snip>
>>>>So are you saying that my original post is essentially correct, then?
>>>Essentially, though different manufacturers may use it differently.
>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>distraction from it.
>>>>That JTAG is at its fundamental level a shift register chaining >>>>together state bits of possible interest? (It's how I'd imagined it >>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>being an expert in this area.)
>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>interest to whom?
>>Yes. That is implied. This is the internals we are talking about and >>that can get into nitty-gritty implementation details if the >>manufacturer decides to expose any of that. They could just chain >>together obvious things only. But then it wouldn't be nearly as >>useful.
>The minimum, of course, is the boundary scan. That's a customer >requirement for ICT. From there, it's a convenient port for the >manufacturer.
>>The manufacturer has different uses than the user. >>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>the information needed to get at the guts of the chip. For example, >>>they may only disclose the boundary scan stuff for ICT and keep >>>everything else a trade secret. The manufacturer may be able to get >>>at every latch in the chip (as we did, though this was "free" because >>>of the design rules) but I'd be very surprised to see one publish this >>>information. ...if for no other reason than it changes from rev to >>>rev.
>>Personally, I would like _everything_ out on the table and in plain >>view. Intel would provide regular specification updates on their >>chips, including changes in package designators, bugs that apply to >>one and not another, and so on. It should be no real issue to include >>the complete JTAG chain disclosed for each stepping and change, as >>well. And let users beware.
>You might like a vacation on the International Space Station too. It's >not in the manufacturer's interest to tell you all his secrets. >...particularly ones that are trade secrets or you have no need to >know.
I did have such a need, though. The details are ornery and it would be longer than I'm willing to go into to discuss and debate them here, so I won't go into all of them. But it was important for a particular product application area I had.
There are times when it is important. Other times when it would merely be a convenience.
>>If someone doesn't want to worry their pretty little head over these >>things, they can leave it to some commercial vendor to do. If they >>want to, then they can. Simple.
>It's not that simple. Documenting this stuff for others to use is >difficult and it does change.
As I already wrote, Intel did this just fine with their specification updates. Complete exposure of bugs, workarounds, and so on. Of course, because some customers needed the information. But keep in mind here that only a very few customers needed it. Most simply ignored them. Operating systems' people, compiler people, etc. The rest didn't need to know.
But it was public, hard for Intel to maintain, and done all the same.
Some things are left to 3rd parties to document well, too. But permitted.
Other things equal, I would choose a manufacturer that disclosed more of this information over one that chooses to disclose less. It's not a deciding factor most of the time, but I'd certainly take it into account. Considering that I may later find a need for some of the information, the fact that it was not like pulling teeth to get it would make a difference to me.
>>But disclose.
>What's in it for the manufacturer, other than losing control of their >trade secrets and increased costs? What would you do with a listing >of 10M latches?
The listing might be 10M for something Intel-like. But for most micros, it is certainly a lot less than that. Don't overstate the case to make a point.
What kinds of trade secrets would they lose? I've designed my own microcontroller before and downloaded it into an FPGA and ran code on it. I'm no expert by any stretch, but so far I find most of the micros I work with to be relatively easily understood. In cases where I've had to dig deeper the the manufacturer and had to get them to find the designer of a section developed 8 years back and not used elsewhere since (SiLabs F061), it took weeks to get it and didn't disclose anything I hadn't already written as a possibility to SiLabs in email beforehand. It was merely a matter of nailing it down. There was nothing there that came close to a secret, certainly not if I knew how it probably worked beforehand. I'm junior achievement level at these things.
I really doubt this whole argument. First, overstating the state. Second, I have yet to find anything I consider the least bit novel in microcontrollers, except perhaps some combinatorial stuff or analog. But not state. I'd be interested if you could elaborate just one such case that wouldn't be entirely obvious to a practitioner in the field just looking at the problem.
>>>JTAG is a requirement so why not use it for the kitchen sink too.
>>Hehe. I sure would. Expose every single state bit to the chain. >>Combinatorials don't have state, so no worry. If it holds a state, >>chain it.
>You forget what that costs. In the chips I worked on there was no >cost because that was already done because of the design rules and >JTAG was simply a convenient port to access these latch "chains". >Other design methodologies may not make this so easy. Would you spend >10% of a chip's logic to do this? 20%? 30%?
I shouldn't have overstated my own case. I really didn't mean to insist that a manufacturer should chain ALL state, so much as I felt that they should disclose all state they've decided may be worth chaining. And no, I wouldn't waste any die space they didn't already want to waste for chaining.
>>On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan >><j...@infinitefactors.org> wrote:
>>>On Sat, 07 Nov 2009 18:59:39 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>On Sat, 07 Nov 2009 16:33:14 -0800, Jon Kirwan >>>><j...@infinitefactors.org> wrote:
>><snip>
>>>>>So are you saying that my original post is essentially correct, then?
>>>>Essentially, though different manufacturers may use it differently.
>>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>>distraction from it.
>>>>>That JTAG is at its fundamental level a shift register chaining >>>>>together state bits of possible interest? (It's how I'd imagined it >>>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>>being an expert in this area.)
>>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>>interest to whom?
>>>Yes. That is implied. This is the internals we are talking about and >>>that can get into nitty-gritty implementation details if the >>>manufacturer decides to expose any of that. They could just chain >>>together obvious things only. But then it wouldn't be nearly as >>>useful.
>>The minimum, of course, is the boundary scan. That's a customer >>requirement for ICT. From there, it's a convenient port for the >>manufacturer.
>>>The manufacturer has different uses than the user. >>>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>>the information needed to get at the guts of the chip. For example, >>>>they may only disclose the boundary scan stuff for ICT and keep >>>>everything else a trade secret. The manufacturer may be able to get >>>>at every latch in the chip (as we did, though this was "free" because >>>>of the design rules) but I'd be very surprised to see one publish this >>>>information. ...if for no other reason than it changes from rev to >>>>rev.
>>>Personally, I would like _everything_ out on the table and in plain >>>view. Intel would provide regular specification updates on their >>>chips, including changes in package designators, bugs that apply to >>>one and not another, and so on. It should be no real issue to include >>>the complete JTAG chain disclosed for each stepping and change, as >>>well. And let users beware.
>>You might like a vacation on the International Space Station too. It's >>not in the manufacturer's interest to tell you all his secrets. >>...particularly ones that are trade secrets or you have no need to >>know.
>I did have such a need, though. The details are ornery and it would >be longer than I'm willing to go into to discuss and debate them here, >so I won't go into all of them. But it was important for a particular >product application area I had.
Why would you want access to the registers in an internal state machine, for example? What could you possibly do with the information? I hope you can see why the manufacturer doesn't want you to have this information.
>There are times when it is important. Other times when it would >merely be a convenience.
I surely can't see any reason to have this information. I can see a million reasons why a manufacturer wouldn't want you to have that information. You lose (though am unconvinced that you could possibly be losing anything).
>>>If someone doesn't want to worry their pretty little head over these >>>things, they can leave it to some commercial vendor to do. If they >>>want to, then they can. Simple.
>>It's not that simple. Documenting this stuff for others to use is >>difficult and it does change.
>As I already wrote, Intel did this just fine with their specification >updates. Complete exposure of bugs, workarounds, and so on. Of >course, because some customers needed the information. But keep in >mind here that only a very few customers needed it. Most simply >ignored them. Operating systems' people, compiler people, etc. The >rest didn't need to know.
That's a completely different kettle-o-fish. You really don't think Intel told the public every bug they had or exposed every diagnostic tool or (unannounced) feature?
>But it was public, hard for Intel to maintain, and done all the same.
What must be done must be. What doesn't isn't. That's simple economics. You simply don't realize what you're asking.
>Some things are left to 3rd parties to document well, too. But >permitted.
Where do you think those third parties get their information. You think it's free? I've been on that side. It would have taken tens or perhaps half-a-hundred to produce what you're asking, if it were in their interest to expose their design internals, and it most certainly is not.
>Other things equal, I would choose a manufacturer that disclosed more >of this information over one that chooses to disclose less. It's not >a deciding factor most of the time, but I'd certainly take it into >account. Considering that I may later find a need for some of the >information, the fact that it was not like pulling teeth to get it >would make a difference to me.
Don't kid yourself. It's never a deciding factor. I note you're using Windows.
>>>But disclose.
>>What's in it for the manufacturer, other than losing control of their >>trade secrets and increased costs? What would you do with a listing >>of 10M latches?
>The listing might be 10M for something Intel-like. But for most >micros, it is certainly a lot less than that. Don't overstate the >case to make a point.
I'm telling what my experience is. If you don't like hearing the facts, don't read. It really is that simple.
>What kinds of trade secrets would they lose?
The entire design. To document every latch in the design you'd have to disclose the entire design. I thought that would be apparent.
>I've designed my own >microcontroller before and downloaded it into an FPGA and ran code on >it. I'm no expert by any stretch, but so far I find most of the >micros I work with to be relatively easily understood.
You clearly haven't studied a modern microprocessor's microarchitecture. The innards are *not* easily understood.
>In cases where >I've had to dig deeper the the manufacturer and had to get them to >find the designer of a section developed 8 years back and not used >elsewhere since (SiLabs F061), it took weeks to get it and didn't >disclose anything I hadn't already written as a possibility to SiLabs >in email beforehand. It was merely a matter of nailing it down. There >was nothing there that came close to a secret, certainly not if I knew >how it probably worked beforehand. I'm junior achievement level at >these things.
Because they didn't disclose anything secret, you don't believe there is anything secret to be disclosed by publishing scan chains? Wow!
>I really doubt this whole argument. First, overstating the state.
You clearly believe what you want to believe, no matter what others tell you to be the facts in the case. Oh well.
>Second, I have yet to find anything I consider the least bit novel in >microcontrollers, except perhaps some combinatorial stuff or analog. >But not state. I'd be interested if you could elaborate just one such >case that wouldn't be entirely obvious to a practitioner in the field >just looking at the problem.
Register renaming. OoO execution. Prefetching algorithms. You name a unit of a modern microprocessor and there are easily a hundred trade secrets in there. There are likely that many debug, option, performance, or feature switches in there too.
>>>>JTAG is a requirement so why not use it for the kitchen sink too.
>>>Hehe. I sure would. Expose every single state bit to the chain. >>>Combinatorials don't have state, so no worry. If it holds a state, >>>chain it.
>>You forget what that costs. In the chips I worked on there was no >>cost because that was already done because of the design rules and >>JTAG was simply a convenient port to access these latch "chains". >>Other design methodologies may not make this so easy. Would you spend >>10% of a chip's logic to do this? 20%? 30%?
>I shouldn't have overstated my own case. I really didn't mean to >insist that a manufacturer should chain ALL state, so much as I felt >that they should disclose all state they've decided may be worth >chaining. And no, I wouldn't waste any die space they didn't already >want to waste for chaining.
So you're going to hold one manufacturer responsible for disclosure of their design because they use one set of design rules and not another because they don't use those same design rules? Illogical.
On Sun, 08 Nov 2009 15:58:55 -0600, krw <k...@att.bizzzzzzzzzzz> wrote: >On Sun, 08 Nov 2009 11:33:59 -0800, Jon Kirwan ><j...@infinitefactors.org> wrote:
>>On Sun, 08 Nov 2009 10:30:05 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan >>><j...@infinitefactors.org> wrote:
>>>>On Sat, 07 Nov 2009 18:59:39 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>>On Sat, 07 Nov 2009 16:33:14 -0800, Jon Kirwan >>>>><j...@infinitefactors.org> wrote:
>>><snip>
>>>>>>So are you saying that my original post is essentially correct, then?
>>>>>Essentially, though different manufacturers may use it differently.
>>>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>>>distraction from it.
>>>>>>That JTAG is at its fundamental level a shift register chaining >>>>>>together state bits of possible interest? (It's how I'd imagined it >>>>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>>>being an expert in this area.)
>>>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>>>interest to whom?
>>>>Yes. That is implied. This is the internals we are talking about and >>>>that can get into nitty-gritty implementation details if the >>>>manufacturer decides to expose any of that. They could just chain >>>>together obvious things only. But then it wouldn't be nearly as >>>>useful.
>>>The minimum, of course, is the boundary scan. That's a customer >>>requirement for ICT. From there, it's a convenient port for the >>>manufacturer.
>>>>The manufacturer has different uses than the user. >>>>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>>>the information needed to get at the guts of the chip. For example, >>>>>they may only disclose the boundary scan stuff for ICT and keep >>>>>everything else a trade secret. The manufacturer may be able to get >>>>>at every latch in the chip (as we did, though this was "free" because >>>>>of the design rules) but I'd be very surprised to see one publish this >>>>>information. ...if for no other reason than it changes from rev to >>>>>rev.
>>>>Personally, I would like _everything_ out on the table and in plain >>>>view. Intel would provide regular specification updates on their >>>>chips, including changes in package designators, bugs that apply to >>>>one and not another, and so on. It should be no real issue to include >>>>the complete JTAG chain disclosed for each stepping and change, as >>>>well. And let users beware.
>>>You might like a vacation on the International Space Station too. It's >>>not in the manufacturer's interest to tell you all his secrets. >>>...particularly ones that are trade secrets or you have no need to >>>know.
>>I did have such a need, though. The details are ornery and it would >>be longer than I'm willing to go into to discuss and debate them here, >>so I won't go into all of them. But it was important for a particular >>product application area I had.
>Why would you want access to the registers in an internal state >machine, for example? What could you possibly do with the >information? I hope you can see why the manufacturer doesn't want you >to have this information.
>>There are times when it is important. Other times when it would >>merely be a convenience.
>I surely can't see any reason to have this information. I can see a >million reasons why a manufacturer wouldn't want you to have that >information. You lose (though am unconvinced that you could possibly >be losing anything).
As I said, I don't want to get into the application details. We'd be going at that, at length, before settling down to a mutual understanding and I don't have the time or inclination, right now. But yes, I needed at least _some_ of that information at the time for legitimate application purposes.
Let me put this another way. Do you imagine that a manufacturer of a microcontroller knows _EVERY_ legimate use of such information, now and forever, and can then make the profound claim that no one ever has a valid use for such?
The answer is obviously, NO, they do not have that god-like perspective and do not know enough about every application space to say that much.
In all my years, I've only needed some of this just once. But when I needed it, I needed it. Let's leave it there.
>>>>If someone doesn't want to worry their pretty little head over these >>>>things, they can leave it to some commercial vendor to do. If they >>>>want to, then they can. Simple.
>>>It's not that simple. Documenting this stuff for others to use is >>>difficult and it does change.
>>As I already wrote, Intel did this just fine with their specification >>updates. Complete exposure of bugs, workarounds, and so on. Of >>course, because some customers needed the information. But keep in >>mind here that only a very few customers needed it. Most simply >>ignored them. Operating systems' people, compiler people, etc. The >>rest didn't need to know.
>That's a completely different kettle-o-fish. You really don't think >Intel told the public every bug they had or exposed every diagnostic >tool or (unannounced) feature?
Perhaps not. I don't have the perspective to say. I did work at Intel, had access to _some_ internal documentation during my chip testing days, and so have some meager measures about it. But I can say that a lot of the effort going on around me _did_ make it into the docs when it could be managed.
>>But it was public, hard for Intel to maintain, and done all the same.
>What must be done must be. What doesn't isn't. That's simple >economics. You simply don't realize what you're asking.
I think I do realize a fair amount, having come from chipset testing. Not all, but I know enough to be dangerous.
>>Some things are left to 3rd parties to document well, too. But >>permitted.
>Where do you think those third parties get their information. You >think it's free? I've been on that side. It would have taken tens or >perhaps half-a-hundred to produce what you're asking, if it were in >their interest to expose their design internals, and it most certainly >is not.
You want me to cite specifics? I'll just point to PCI, as a segue, where 3rd parties worked with Intel to develop published documentation that helped a great deal in providing practical knowledge to a hungry public. There are other cases.
I don't mean to say that this is a required path. I'm just suggesting that sometimes others may see a valuable market for it where the manufacturer may feel their own time is better spent elsewhere. That's all.
>>Other things equal, I would choose a manufacturer that disclosed more >>of this information over one that chooses to disclose less. It's not >>a deciding factor most of the time, but I'd certainly take it into >>account. Considering that I may later find a need for some of the >>information, the fact that it was not like pulling teeth to get it >>would make a difference to me.
>Don't kid yourself. It's never a deciding factor. I note you're >using Windows.
I think if you read my words, you will see me essentially agree with you, saying, "It's not a deciding factor." It's just that there was one case in my experience where it actually was, which is why I wrote "mostly" as a conditioning clause. But the thrust, not the side bar, of my point there is that I would tend to prefer having that information than not everything else equal. On that, I still stand.
>>>>But disclose.
>>>What's in it for the manufacturer, other than losing control of their >>>trade secrets and increased costs? What would you do with a listing >>>of 10M latches?
>>The listing might be 10M for something Intel-like. But for most >>micros, it is certainly a lot less than that. Don't overstate the >>case to make a point.
>I'm telling what my experience is. If you don't like hearing the >facts, don't read. It really is that simple.
Well, there certainly isn't that much state in the practical case I recall where I had access to the JTAG chain. I don't know where the 10M comes from, but I'll accept your statement that in some cases it may be there (like the x86, obviously, with the ROB and branch detection and so on... certainly if you add L1 cache to the chain.)
>>What kinds of trade secrets would they lose?
>The entire design. To document every latch in the design you'd have >to disclose the entire design. I thought that would be apparent.
I'm asking about trade secrets. It is apparent the design would be exposed. But I haven't seen much new under the sun, lately.
>>I've designed my own >>microcontroller before and downloaded it into an FPGA and ran code on >>it. I'm no expert by any stretch, but so far I find most of the >>micros I work with to be relatively easily understood.
>You clearly haven't studied a modern microprocessor's >microarchitecture. The innards are *not* easily understood.
Example? I'm intimately familiar with division, FP and integer, and various approaches in hardware. I think BIT (Bipolar Integrated Technologies) was the only company to develop a fully combinatorial FP divider. But regardless, I'm curious what is considered trade secret. An example that has been exposed and no longer is one, if appropriate, would make your point for me.
>>In cases where >>I've had to dig deeper the the manufacturer and had to get them to >>find the designer of a section developed 8 years back and not used >>elsewhere since (SiLabs F061), it took weeks to get it and didn't >>disclose anything I hadn't already written as a possibility to SiLabs >>in email beforehand. It was merely a matter of nailing it down. There >>was nothing there that came close to a secret, certainly not if I knew >>how it probably worked beforehand. I'm junior achievement level at >>these things.
>Because they didn't disclose anything secret, you don't
>>On Sun, 08 Nov 2009 11:33:59 -0800, Jon Kirwan >><j...@infinitefactors.org> wrote:
>>>On Sun, 08 Nov 2009 10:30:05 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan >>>><j...@infinitefactors.org> wrote:
>>>>>On Sat, 07 Nov 2009 18:59:39 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>>>On Sat, 07 Nov 2009 16:33:14 -0800, Jon Kirwan >>>>>><j...@infinitefactors.org> wrote:
>>>><snip>
>>>>>>>So are you saying that my original post is essentially correct, then?
>>>>>>Essentially, though different manufacturers may use it differently.
>>>>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>>>>distraction from it.
>>>>>>>That JTAG is at its fundamental level a shift register chaining >>>>>>>together state bits of possible interest? (It's how I'd imagined it >>>>>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>>>>being an expert in this area.)
>>>>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>>>>interest to whom?
>>>>>Yes. That is implied. This is the internals we are talking about and >>>>>that can get into nitty-gritty implementation details if the >>>>>manufacturer decides to expose any of that. They could just chain >>>>>together obvious things only. But then it wouldn't be nearly as >>>>>useful.
>>>>The minimum, of course, is the boundary scan. That's a customer >>>>requirement for ICT. From there, it's a convenient port for the >>>>manufacturer.
>>>>>The manufacturer has different uses than the user. >>>>>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>>>>the information needed to get at the guts of the chip. For example, >>>>>>they may only disclose the boundary scan stuff for ICT and keep >>>>>>everything else a trade secret. The manufacturer may be able to get >>>>>>at every latch in the chip (as we did, though this was "free" because >>>>>>of the design rules) but I'd be very surprised to see one publish this >>>>>>information. ...if for no other reason than it changes from rev to >>>>>>rev.
>>>>>Personally, I would like _everything_ out on the table and in plain >>>>>view. Intel would provide regular specification updates on their >>>>>chips, including changes in package designators, bugs that apply to >>>>>one and not another, and so on. It should be no real issue to include >>>>>the complete JTAG chain disclosed for each stepping and change, as >>>>>well. And let users beware.
>>>>You might like a vacation on the International Space Station too. It's >>>>not in the manufacturer's interest to tell you all his secrets. >>>>...particularly ones that are trade secrets or you have no need to >>>>know.
>>>I did have such a need, though. The details are ornery and it would >>>be longer than I'm willing to go into to discuss and debate them here, >>>so I won't go into all of them. But it was important for a particular >>>product application area I had.
>>Why would you want access to the registers in an internal state >>machine, for example? What could you possibly do with the >>information? I hope you can see why the manufacturer doesn't want you >>to have this information.
>>>There are times when it is important. Other times when it would >>>merely be a convenience.
>>I surely can't see any reason to have this information. I can see a >>million reasons why a manufacturer wouldn't want you to have that >>information. You lose (though am unconvinced that you could possibly >>be losing anything).
>As I said, I don't want to get into the application details. We'd be >going at that, at length, before settling down to a mutual >understanding and I don't have the time or inclination, right now. But >yes, I needed at least _some_ of that information at the time for >legitimate application purposes.
I believe that you believe you had a need for information you didn't have. So?
>Let me put this another way. Do you imagine that a manufacturer of a >microcontroller knows _EVERY_ legimate use of such information, now >and forever, and can then make the profound claim that no one ever has >a valid use for such?
Stop lying. I never said any such thing!
Let *ME* put it another way. Do you imagine that a manufacturer has no trade secrets to protect by not publishing their detailed design? Do you imagine that any manufacturer is going to let you tell them how to run their business?
>The answer is obviously, NO, they do not have that god-like >perspective and do not know enough about every application space to >say that much.
Again, stop lying (and dreaming). They don't give a rats ass whether you need something or not. They are *not* going to give you their design without some pretty clear incentives and guarantees. You want something for nothing. Again, you lose.
>In all my years, I've only needed some of this just once. But when I >needed it, I needed it. Let's leave it there.
Fine, I'll leave it as you have no clue what you're talking about.
>>>>>If someone doesn't want to worry their pretty little head over these >>>>>things, they can leave it to some commercial vendor to do. If they >>>>>want to, then they can. Simple.
>>>>It's not that simple. Documenting this stuff for others to use is >>>>difficult and it does change.
>>>As I already wrote, Intel did this just fine with their specification >>>updates. Complete exposure of bugs, workarounds, and so on. Of >>>course, because some customers needed the information. But keep in >>>mind here that only a very few customers needed it. Most simply >>>ignored them. Operating systems' people, compiler people, etc. The >>>rest didn't need to know.
>>That's a completely different kettle-o-fish. You really don't think >>Intel told the public every bug they had or exposed every diagnostic >>tool or (unannounced) feature?
>Perhaps not. I don't have the perspective to say. I did work at >Intel, had access to _some_ internal documentation during my chip >testing days, and so have some meager measures about it. But I can >say that a lot of the effort going on around me _did_ make it into the >docs when it could be managed.
When it was in Intel's direct interest, sure. Otherwise, not so much.
>>>But it was public, hard for Intel to maintain, and done all the same.
>>What must be done must be. What doesn't isn't. That's simple >>economics. You simply don't realize what you're asking.
>I think I do realize a fair amount, having come from chipset testing. >Not all, but I know enough to be dangerous.
Obviously.
>>>Some things are left to 3rd parties to document well, too. But >>>permitted.
>>Where do you think those third parties get their information. You >>think it's free? I've been on that side. It would have taken tens or >>perhaps half-a-hundred to produce what you're asking, if it were in >>their interest to expose their design internals, and it most certainly >>is not.
>You want me to cite specifics? I'll just point to PCI, as a segue, >where 3rd parties worked with Intel to develop published documentation >that helped a great deal in providing practical knowledge to a hungry >public. There are other cases.
Good grief. You're equating a published standard to a proprietary microprocessor?
>I don't mean to say that this is a required path. I'm just suggesting >that sometimes others may see a valuable market for it where the >manufacturer may feel their own time is better spent elsewhere. That's >all.
You've thrown up one of the biggies red herrings I've ever seen in any discussion. You applying for a job with Nancy?
>>>Other things equal, I would choose a manufacturer that disclosed more >>>of this information over one that chooses to disclose less. It's not >>>a deciding factor most of the time, but I'd certainly take it into >>>account. Considering that I may later find a need for some of the >>>information, the fact that it was not like pulling teeth to get it >>>would make a difference to me.
>>Don't kid yourself. It's never a deciding factor. I note you're >>using Windows.
>I think if you read my words, you will see me essentially agree with >you, saying, "It's not a deciding factor." It's just that there was >one case in my experience where it actually was, which is why I wrote >"mostly" as a conditioning clause. But the thrust, not the side bar, >of my point there is that I would tend to prefer having that >information than not everything else equal. On that, I still stand.
I'd prefer if they sent me a bushel of Banjamins too, but it's not going to happen. If you're a *big* (say 8 or 9 zeros) customer you might get a piece of the information you think you're owed.
>>>>What's in it for the manufacturer, other than losing control of their >>>>trade secrets and increased costs? What would you do with a listing >>>>of 10M latches?
>>>The listing might be 10M for something Intel-like. But for most >>>micros, it is certainly a lot less than that. Don't overstate the >>>case to make a point.
>>I'm telling what my experience is. If you don't like hearing the >>facts, don't read. It really is that simple.
>Well, there certainly isn't that much state in the practical case I >recall where I had access to the JTAG chain. I don't know where the >10M comes from, but I'll accept your statement that in some cases it >may be there (like the x86, obviously, with the ROB and branch >detection and so on... certainly if you add L1 cache to the chain.)
You don't know you had access to every chain. Add the L2 while you're at it. It's there (the access ports are, anyway).
On Sun, 08 Nov 2009 18:34:09 -0600, krw <k...@att.bizzzzzzzzzzz> wrote: >On Sun, 08 Nov 2009 15:49:17 -0800, Jon Kirwan ><j...@infinitefactors.org> wrote:
>>On Sun, 08 Nov 2009 15:58:55 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>On Sun, 08 Nov 2009 11:33:59 -0800, Jon Kirwan >>><j...@infinitefactors.org> wrote:
>>>>On Sun, 08 Nov 2009 10:30:05 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>>On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan >>>>><j...@infinitefactors.org> wrote:
>>>>>>On Sat, 07 Nov 2009 18:59:39 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>>>>On Sat, 07 Nov 2009 16:33:14 -0800, Jon Kirwan >>>>>>><j...@infinitefactors.org> wrote:
>>>>><snip>
>>>>>>>>So are you saying that my original post is essentially correct, then?
>>>>>>>Essentially, though different manufacturers may use it differently.
>>>>>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>>>>>distraction from it.
>>>>>>>>That JTAG is at its fundamental level a shift register chaining >>>>>>>>together state bits of possible interest? (It's how I'd imagined it >>>>>>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>>>>>being an expert in this area.)
>>>>>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>>>>>interest to whom?
>>>>>>Yes. That is implied. This is the internals we are talking about and >>>>>>that can get into nitty-gritty implementation details if the >>>>>>manufacturer decides to expose any of that. They could just chain >>>>>>together obvious things only. But then it wouldn't be nearly as >>>>>>useful.
>>>>>The minimum, of course, is the boundary scan. That's a customer >>>>>requirement for ICT. From there, it's a convenient port for the >>>>>manufacturer.
>>>>>>The manufacturer has different uses than the user. >>>>>>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>>>>>the information needed to get at the guts of the chip. For example, >>>>>>>they may only disclose the boundary scan stuff for ICT and keep >>>>>>>everything else a trade secret. The manufacturer may be able to get >>>>>>>at every latch in the chip (as we did, though this was "free" because >>>>>>>of the design rules) but I'd be very surprised to see one publish this >>>>>>>information. ...if for no other reason than it changes from rev to >>>>>>>rev.
>>>>>>Personally, I would like _everything_ out on the table and in plain >>>>>>view. Intel would provide regular specification updates on their >>>>>>chips, including changes in package designators, bugs that apply to >>>>>>one and not another, and so on. It should be no real issue to include >>>>>>the complete JTAG chain disclosed for each stepping and change, as >>>>>>well. And let users beware.
>>>>>You might like a vacation on the International Space Station too. It's >>>>>not in the manufacturer's interest to tell you all his secrets. >>>>>...particularly ones that are trade secrets or you have no need to >>>>>know.
>>>>I did have such a need, though. The details are ornery and it would >>>>be longer than I'm willing to go into to discuss and debate them here, >>>>so I won't go into all of them. But it was important for a particular >>>>product application area I had.
>>>Why would you want access to the registers in an internal state >>>machine, for example? What could you possibly do with the >>>information? I hope you can see why the manufacturer doesn't want you >>>to have this information.
>>>>There are times when it is important. Other times when it would >>>>merely be a convenience.
>>>I surely can't see any reason to have this information. I can see a >>>million reasons why a manufacturer wouldn't want you to have that >>>information. You lose (though am unconvinced that you could possibly >>>be losing anything).
>>As I said, I don't want to get into the application details. We'd be >>going at that, at length, before settling down to a mutual >>understanding and I don't have the time or inclination, right now. But >>yes, I needed at least _some_ of that information at the time for >>legitimate application purposes.
>I believe that you believe you had a need for information you didn't >have. So?
Which is fine. We can simply disagree here.
>>Let me put this another way. Do you imagine that a manufacturer of a >>microcontroller knows _EVERY_ legimate use of such information, now >>and forever, and can then make the profound claim that no one ever has >>a valid use for such?
>Stop lying. I never said any such thing!
>Let *ME* put it another way. Do you imagine that a manufacturer has >no trade secrets to protect by not publishing their detailed design? >Do you imagine that any manufacturer is going to let you tell them how >to run their business?
I think they do. I just think they draw the line too close to the chest.
>>The answer is obviously, NO, they do not have that god-like >>perspective and do not know enough about every application space to >>say that much.
>Again, stop lying (and dreaming). They don't give a rats ass whether >you need something or not. They are *not* going to give you their >design without some pretty clear incentives and guarantees. You want >something for nothing. Again, you lose.
I guess I don't know your point here. If what they provide is enough for an application, I'm fine. If not, I look elsewhere. I've had a case where I went elsewhere. I didn't lose out, luckily. I'd just like more options than fewer, here. Nothing crazy about that.
>>In all my years, I've only needed some of this just once. But when I >>needed it, I needed it. Let's leave it there.
>Fine, I'll leave it as you have no clue what you're talking about.
>>>>>>If someone doesn't want to worry their pretty little head over these >>>>>>things, they can leave it to some commercial vendor to do. If they >>>>>>want to, then they can. Simple.
>>>>>It's not that simple. Documenting this stuff for others to use is >>>>>difficult and it does change.
>>>>As I already wrote, Intel did this just fine with their specification >>>>updates. Complete exposure of bugs, workarounds, and so on. Of >>>>course, because some customers needed the information. But keep in >>>>mind here that only a very few customers needed it. Most simply >>>>ignored them. Operating systems' people, compiler people, etc. The >>>>rest didn't need to know.
>>>That's a completely different kettle-o-fish. You really don't think >>>Intel told the public every bug they had or exposed every diagnostic >>>tool or (unannounced) feature?
>>Perhaps not. I don't have the perspective to say. I did work at >>Intel, had access to _some_ internal documentation during my chip >>testing days, and so have some meager measures about it. But I can >>say that a lot of the effort going on around me _did_ make it into the >>docs when it could be managed.
>When it was in Intel's direct interest, sure. Otherwise, not so much.
Companies do what they feel is in their interest. Granted.
>>>>But it was public, hard for Intel to maintain, and done all the same.
>>>What must be done must be. What doesn't isn't. That's simple >>>economics. You simply don't realize what you're asking.
>>I think I do realize a fair amount, having come from chipset testing. >>Not all, but I know enough to be dangerous.
>Obviously.
>>>>Some things are left to 3rd parties to document well, too. But >>>>permitted.
>>>Where do you think those third parties get their information. You >>>think it's free? I've been on that side. It would have taken tens or >>>perhaps half-a-hundred to produce what you're asking, if it were in >>>their interest to expose their design internals, and it most certainly >>>is not.
>>You want me to cite specifics? I'll just point to PCI, as a segue, >>where 3rd parties worked with Intel to develop published documentation >>that helped a great deal in providing practical knowledge to a hungry >>public. There are other cases.
>Good grief. You're equating a published standard to a proprietary >microprocessor?
It needed more, though, than Intel wanted to provide to a broader market.
>>I don't mean to say that this is a required path. I'm just suggesting >>that sometimes others may see a valuable market for it where the >>manufacturer may feel their own time is better spent elsewhere. That's >>all.
>You've thrown up one of the biggies red herrings I've ever seen in any >discussion. You applying for a job with Nancy?
I was addressing the points one by one, not turning my argument on this small cog. This particular part of it really isn't central, so let's drop it then.
>>>>Other things equal, I would choose a manufacturer that disclosed more >>>>of this information over one that chooses to disclose less. It's not >>>>a deciding factor most of the time, but I'd certainly take it into >>>>account. Considering that I may later find a need for some of the >>>>information, the fact that it was not like pulling teeth to get it >>>>would make a difference to me.
>>>Don't kid yourself. It's never a deciding factor. I note you're >>>using Windows.
>>I think if you read my words, you will see me essentially agree with >>you, saying, "It's not a deciding factor." It's just that there was >>one case in my experience where it actually was, which is why I wrote >>"mostly" as a conditioning clause. But the thrust, not the side bar, >>of my point there is that I would tend to prefer having that >>information than not everything else equal. On that, I still stand.
>I'd prefer if they sent me a bushel of Banjamins too, but it's not >going to happen. If you're a *big* (say 8 or 9 zeros) customer you >might get a piece of the information you think you're owed.
So we have no disagreement then. I'd like more, at times,
...
>>>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>>>> >> if you happen to have one handy.
>>>>>>>>>>> >> Jon
>>>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>>>> >of the PCA counter in both places.
>>>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>>>> Jon
>>>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>>>Jon
>>>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>>>JTAG standards were forced to be about functional verification rather >>>>>>>>than measuring performance because of this.
>>>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>>>register. There is boundary checking, of course. But flashing and
>>>>>>It most certainly is not.
>>>>>Must be some other interface I remember, then. I was able to shift >>>>>out and examine almost every internal flip-flop state, for example. >>>>>Thousands of bits worth. Gave me access to pretty much everything, if >>>>>the designers included the bits into the serial chain. I'd use test >>>>>vectors which allowed me to set register values, both hidden and >>>>>observable to a programmer, etc., before taking an instruction step.
>>>>The designers don't want you to have that information. It's the >>>>family jewels. Emulation types get it only after signing a pile of >>>>contracts and giving up their first offspring.
>>>Normally, I suppose. I think the ARM7 documentation discloses much, >>>if not all. Or perhaps I'm wrong about that, as well. However, my >>>case was for a different processor.
>>Could be they've laid the whole design out hoping someone would copy >>it? Dunno, but this is usually *highly* sensitive information. We >>had a lot of hidden performance and feature switches in there that we >>certainly didn't want the user diddling with (or so much as knowing >>they were even there).
>>>>>>JTAG is a way to access internal registers >>>>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>>>take your point, for now. It's quite possible I've conflated JTAG >>>>>with something else.
>>>>No, these things are often accessible via JTAG. The interface could >>>>be "buggy" I suppose, though would highly doubt. It may not be well >>>>documented since it's not generally accessible by anyone outside the >>>>chip manufacturer.
>>>So are you saying that my original post is essentially correct, then?
>>Essentially, though different manufacturers may use it differently.
>Thanks. I'm glad to keep my prior mental model and discard Nico's >distraction from it.
>>>That JTAG is at its fundamental level a shift register chaining >>>together state bits of possible interest? (It's how I'd imagined it >>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>being an expert in this area.)
>>That's pretty much it. "Of interest" may be the sticking point. Of >>interest to whom?
>Yes. That is implied. This is the internals we are talking about and >that can get into nitty-gritty implementation details if the >manufacturer decides to expose any of that. They could just chain >together obvious things only. But then it wouldn't be nearly as >useful.
>The manufacturer has different uses than the user. >>Both may be accommodated in JTAG but the manufacturer my not disclose >>the information needed to get at the guts of the chip. For example, >>they may only disclose the boundary scan stuff for ICT and keep >>everything else a trade secret. The manufacturer may be able to get >>at every latch in the chip (as we did, though this was "free" because >>of the design rules) but I'd be very surprised to see one publish this >>information. ...if for no other reason than it changes from rev to >>rev.
>Personally, I would like _everything_ out on the table and in plain >view. Intel would provide regular specification updates on their >chips, including changes in package designators, bugs that apply to >one and not another, and so on. It should be no real issue to include >the complete JTAG chain disclosed for each stepping and change, as >well. And let users beware.
>If someone doesn't want to worry their pretty little head over these >things, they can leave it to some commercial vendor to do. If they >want to, then they can. Simple.
>But disclose.
>>JTAG is a requirement so why not use it for the kitchen sink too.
>Hehe. I sure would. Expose every single state bit to the chain. >Combinatorials don't have state, so no worry. If it holds a state, >chain it.
>Jon
This may become impossible as the caches on modern processors are in the megabit range already.
>>>>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>>>>> >> if you happen to have one handy.
>>>>>>>>>>>> >> Jon
>>>>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>>>>> >of the PCA counter in both places.
>>>>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>>>>> Jon
>>>>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>>>>Jon
>>>>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>>>>JTAG standards were forced to be about functional verification rather >>>>>>>>>than measuring performance because of this.
>>>>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>>>>register. There is boundary checking, of course. But flashing and
>>>>>>>It most certainly is not.
>>>>>>Must be some other interface I remember, then. I was able to shift >>>>>>out and examine almost every internal flip-flop state, for example. >>>>>>Thousands of bits worth. Gave me access to pretty much everything, if >>>>>>the designers included the bits into the serial chain. I'd use test >>>>>>vectors which allowed me to set register values, both hidden and >>>>>>observable to a programmer, etc., before taking an instruction step.
>>>>>The designers don't want you to have that information. It's the >>>>>family jewels. Emulation types get it only after signing a pile of >>>>>contracts and giving up their first offspring.
>>>>Normally, I suppose. I think the ARM7 documentation discloses much, >>>>if not all. Or perhaps I'm wrong about that, as well. However, my >>>>case was for a different processor.
>>>Could be they've laid the whole design out hoping someone would copy >>>it? Dunno, but this is usually *highly* sensitive information. We >>>had a lot of hidden performance and feature switches in there that we >>>certainly didn't want the user diddling with (or so much as knowing >>>they were even there).
>>>>>>>JTAG is a way to access internal registers >>>>>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>>>>take your point, for now. It's quite possible I've conflated JTAG >>>>>>with something else.
>>>>>No, these things are often accessible via JTAG. The interface could >>>>>be "buggy" I suppose, though would highly doubt. It may not be well >>>>>documented since it's not generally accessible by anyone outside the >>>>>chip manufacturer.
>>>>So are you saying that my original post is essentially correct, then?
>>>Essentially, though different manufacturers may use it differently.
>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>distraction from it.
>>>>That JTAG is at its fundamental level a shift register chaining >>>>together state bits of possible interest? (It's how I'd imagined it >>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>being an expert in this area.)
>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>interest to whom?
>>Yes. That is implied. This is the internals we are talking about and >>that can get into nitty-gritty implementation details if the >>manufacturer decides to expose any of that. They could just chain >>together obvious things only. But then it wouldn't be nearly as >>useful.
>>The manufacturer has different uses than the user. >>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>the information needed to get at the guts of the chip. For example, >>>they may only disclose the boundary scan stuff for ICT and keep >>>everything else a trade secret. The manufacturer may be able to get >>>at every latch in the chip (as we did, though this was "free" because >>>of the design rules) but I'd be very surprised to see one publish this >>>information. ...if for no other reason than it changes from rev to >>>rev.
>>Personally, I would like _everything_ out on the table and in plain >>view. Intel would provide regular specification updates on their >>chips, including changes in package designators, bugs that apply to >>one and not another, and so on. It should be no real issue to include >>the complete JTAG chain disclosed for each stepping and change, as >>well. And let users beware.
>>If someone doesn't want to worry their pretty little head over these >>things, they can leave it to some commercial vendor to do. If they >>want to, then they can. Simple.
>>But disclose.
>>>JTAG is a requirement so why not use it for the kitchen sink too.
>>Hehe. I sure would. Expose every single state bit to the chain. >>Combinatorials don't have state, so no worry. If it holds a state, >>chain it.
>>Jon
>This may become impossible as the caches on modern processors are in >the megabit range already.
Yeah, well.... Our discussion has been there and past it. I think it may be important to pass along internal registers and latches for diagnostic purposes (ALU output latch, it's input latches if different from visible registers, bus latches, etc.) But I'm not terribly keen on chaining megabytes of cache. A small instruction cache might be nice (for example, the few k of cache that may be present on TI DSPs or ARM chips.) Of course, I'm focused on 8-bit and a few 16-bit parts for the most part. So this cache stuff rarely impinges on my tiny world. I'd probably be happy for more disclosures of the cpu core and peripheral chains.
>>>>>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>>>>>> >> if you happen to have one handy.
>>>>>>>>>>>>> >> Jon
>>>>>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>>>>>> >of the PCA counter in both places.
>>>>>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>>>>>> Jon
>>>>>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>>>>>Jon
>>>>>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>>>>>JTAG standards were forced to be about functional verification rather >>>>>>>>>>than measuring performance because of this.
>>>>>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>>>>>register. There is boundary checking, of course. But flashing and
>>>>>>>>It most certainly is not.
>>>>>>>Must be some other interface I remember, then. I was able to shift >>>>>>>out and examine almost every internal flip-flop state, for example. >>>>>>>Thousands of bits worth. Gave me access to pretty much everything, if >>>>>>>the designers included the bits into the serial chain. I'd use test >>>>>>>vectors which allowed me to set register values, both hidden and >>>>>>>observable to a programmer, etc., before taking an instruction step.
>>>>>>The designers don't want you to have that information. It's the >>>>>>family jewels. Emulation types get it only after signing a pile of >>>>>>contracts and giving up their first offspring.
>>>>>Normally, I suppose. I think the ARM7 documentation discloses much, >>>>>if not all. Or perhaps I'm wrong about that, as well. However, my >>>>>case was for a different processor.
>>>>Could be they've laid the whole design out hoping someone would copy >>>>it? Dunno, but this is usually *highly* sensitive information. We >>>>had a lot of hidden performance and feature switches in there that we >>>>certainly didn't want the user diddling with (or so much as knowing >>>>they were even there).
>>>>>>>>JTAG is a way to access internal registers >>>>>>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>>>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>>>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>>>>>take your point, for now. It's quite possible I've conflated JTAG >>>>>>>with something else.
>>>>>>No, these things are often accessible via JTAG. The interface could >>>>>>be "buggy" I suppose, though would highly doubt. It may not be well >>>>>>documented since it's not generally accessible by anyone outside the >>>>>>chip manufacturer.
>>>>>So are you saying that my original post is essentially correct, then?
>>>>Essentially, though different manufacturers may use it differently.
>>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>>distraction from it.
>>>>>That JTAG is at its fundamental level a shift register chaining >>>>>together state bits of possible interest? (It's how I'd imagined it >>>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>>being an expert in this area.)
>>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>>interest to whom?
>>>Yes. That is implied. This is the internals we are talking about and >>>that can get into nitty-gritty implementation details if the >>>manufacturer decides to expose any of that. They could just chain >>>together obvious things only. But then it wouldn't be nearly as >>>useful.
>>>The manufacturer has different uses than the user. >>>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>>the information needed to get at the guts of the chip. For example, >>>>they may only disclose the boundary scan stuff for ICT and keep >>>>everything else a trade secret. The manufacturer may be able to get >>>>at every latch in the chip (as we did, though this was "free" because >>>>of the design rules) but I'd be very surprised to see one publish this >>>>information. ...if for no other reason than it changes from rev to >>>>rev.
>>>Personally, I would like _everything_ out on the table and in plain >>>view. Intel would provide regular specification updates on their >>>chips, including changes in package designators, bugs that apply to >>>one and not another, and so on. It should be no real issue to include >>>the complete JTAG chain disclosed for each stepping and change, as >>>well. And let users beware.
>>>If someone doesn't want to worry their pretty little head over these >>>things, they can leave it to some commercial vendor to do. If they >>>want to, then they can. Simple.
>>>But disclose.
>>>>JTAG is a requirement so why not use it for the kitchen sink too.
>>>Hehe. I sure would. Expose every single state bit to the chain. >>>Combinatorials don't have state, so no worry. If it holds a state, >>>chain it.
>>>Jon
>>This may become impossible as the caches on modern processors are in >>the megabit range already.
>Yeah, well.... Our discussion has been there and past it. I think it >may be important to pass along internal registers and latches for >diagnostic purposes (ALU output latch, it's input latches if different >from visible registers, bus latches, etc.) But I'm not terribly keen >on chaining megabytes of cache. A small instruction cache might be >nice (for example, the few k of cache that may be present on TI DSPs >or ARM chips.) Of course, I'm focused on 8-bit and a few 16-bit parts >for the most part. So this cache stuff rarely impinges on my tiny >world. I'd probably be happy for more disclosures of the cpu core and >peripheral chains.
>Jon
Focus noted,
The minimum i would expect it all of the programmer visible stuff and all the I/O stuff. This is pretty much the definition from the JTAG working group itself. It is not a whole lot, but it does describe the basic compromise originally made by the initial JTAG working group.
>>>>>>>>>>>>>On Oct 31, 12:28 pm, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>>>>> On Sat, 31 Oct 2009 09:10:27 -0700 (PDT), MooseFET
>>>>>>>>>>>>>> <kensm...@rahul.net> wrote: >>>>>>>>>>>>>> >On Oct 31, 12:36 am, Jon Kirwan <j...@infinitefactors.org> wrote: >>>>>>>>>>>>>> >> By the way, since you use SiLabs regularly and I've only been using >>>>>>>>>>>>>> >> their IDE for a month... How do you get it to display some 'cycle >>>>>>>>>>>>>> >> count' figure? I'd like to see an absolute figure, best of all, and >>>>>>>>>>>>>> >> take a snapshot of it from the debugger at the start of a routine then >>>>>>>>>>>>>> >> take a snapshot at the end of its execution and simply subtract. >>>>>>>>>>>>>> >> Rather than sitting there staring at the code and manually counting. >>>>>>>>>>>>>> >> Many other IDEs support this. I can display SFRs and set up a timer, >>>>>>>>>>>>>> >> but for one it may be too coarse (if I have the usual /12 going on) >>>>>>>>>>>>>> >> and requires that extra effort in software. I was hoping they simply >>>>>>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. One way I do >>>>>>>>>>>>>> >> this now is to loop a large block of code and use a timer and then >>>>>>>>>>>>>> >> divide to get a more accurate mean value. But it's a bit of a pain.
>>>>>>>>>>>>>> >> If there's nothing, that's fine. I'm just looking for a quick answer >>>>>>>>>>>>>> >> if you happen to have one handy.
>>>>>>>>>>>>>> >> Jon
>>>>>>>>>>>>>> >Put a break point either side of the routine and look at the contents >>>>>>>>>>>>>> >of the PCA counter in both places.
>>>>>>>>>>>>>> I see. I hadn't earlier been interested in setting up the PCA for >>>>>>>>>>>>>> such use and was hoping that the debug/jtag unit itself maintained a >>>>>>>>>>>>>> SYSCLK count I could display without involving software I write >>>>>>>>>>>>>> explicitly for the purpose (which, of course, I can do.) From the >>>>>>>>>>>>>> above response, I take it the answer is 'no.' Accepted.
>>>>>>>>>>>>>> Thanks for taking a moment on this for me, >>>>>>>>>>>>>> Jon
>>>>>>>>>>>>>The JTAG section appears to not know anything about what the clock >>>>>>>>>>>>>speed is other than requiring more than 32KHz to work.
>>>>>>>>>>>>I had incorrectly imagined that maybe because the JTAG actually clocks >>>>>>>>>>>>stuff in and out and in the process then also drives a single-step >>>>>>>>>>>>SYSCLK equivalent to advance through an instruction that it may >>>>>>>>>>>>provide that internal information on a display. It's very hard for me >>>>>>>>>>>>to imagine, when stepping using F11, that the JTAG uses the external >>>>>>>>>>>>clock. But perhaps my imagination is too limited.
>>>>>>>>>>>>Jon
>>>>>>>>>>>Jon, something to understand, standards are all about compromises. The >>>>>>>>>>>JTAG standards were forced to be about functional verification rather >>>>>>>>>>>than measuring performance because of this.
>>>>>>>>>>As I understand JTAG, broadly speaking, its simply a very long shift >>>>>>>>>>register. There is boundary checking, of course. But flashing and
>>>>>>>>>It most certainly is not.
>>>>>>>>Must be some other interface I remember, then. I was able to shift >>>>>>>>out and examine almost every internal flip-flop state, for example. >>>>>>>>Thousands of bits worth. Gave me access to pretty much everything, if >>>>>>>>the designers included the bits into the serial chain. I'd use test >>>>>>>>vectors which allowed me to set register values, both hidden and >>>>>>>>observable to a programmer, etc., before taking an instruction step.
>>>>>>>The designers don't want you to have that information. It's the >>>>>>>family jewels. Emulation types get it only after signing a pile of >>>>>>>contracts and giving up their first offspring.
>>>>>>Normally, I suppose. I think the ARM7 documentation discloses much, >>>>>>if not all. Or perhaps I'm wrong about that, as well. However, my >>>>>>case was for a different processor.
>>>>>Could be they've laid the whole design out hoping someone would copy >>>>>it? Dunno, but this is usually *highly* sensitive information. We >>>>>had a lot of hidden performance and feature switches in there that we >>>>>certainly didn't want the user diddling with (or so much as knowing >>>>>they were even there).
>>>>>>>>>JTAG is a way to access internal registers >>>>>>>>>addressed by commands. On top of JTAG there usually is a complicated, >>>>>>>>>buggy protocol to access CPU registers (and memory if you are lucky).
>>>>>>>>I'll try and remember what exactly it was I'd used before, then. I'll >>>>>>>>take your point, for now. It's quite possible I've conflated JTAG >>>>>>>>with something else.
>>>>>>>No, these things are often accessible via JTAG. The interface could >>>>>>>be "buggy" I suppose, though would highly doubt. It may not be well >>>>>>>documented since it's not generally accessible by anyone outside the >>>>>>>chip manufacturer.
>>>>>>So are you saying that my original post is essentially correct, then?
>>>>>Essentially, though different manufacturers may use it differently.
>>>>Thanks. I'm glad to keep my prior mental model and discard Nico's >>>>distraction from it.
>>>>>>That JTAG is at its fundamental level a shift register chaining >>>>>>together state bits of possible interest? (It's how I'd imagined it >>>>>>up to now, until Nico wrote to tell me I was wrong, but I admit not >>>>>>being an expert in this area.)
>>>>>That's pretty much it. "Of interest" may be the sticking point. Of >>>>>interest to whom?
>>>>Yes. That is implied. This is the internals we are talking about and >>>>that can get into nitty-gritty implementation details if the >>>>manufacturer decides to expose any of that. They could just chain >>>>together obvious things only. But then it wouldn't be nearly as >>>>useful.
>>>>The manufacturer has different uses than the user. >>>>>Both may be accommodated in JTAG but the manufacturer my not disclose >>>>>the information needed to get at the guts of the chip. For example, >>>>>they may only disclose the boundary scan stuff for ICT and keep >>>>>everything else a trade secret. The manufacturer may be able to get >>>>>at every latch in the chip (as we did, though this was "free" because >>>>>of the design rules) but I'd be very surprised to see one publish this >>>>>information. ...if for no other reason than it changes from rev to >>>>>rev.
>>>>Personally, I would like _everything_ out on the table and in plain >>>>view. Intel would provide regular specification updates on their >>>>chips, including changes in package designators, bugs that apply to >>>>one and not another, and so on. It should be no real issue to include >>>>the complete JTAG chain disclosed for each stepping and change, as >>>>well. And let users beware.
>>>>If someone doesn't want to worry their pretty little head over these >>>>things, they can leave it to some commercial vendor to do. If they >>>>want to, then they can. Simple.
>>>>But disclose.
>>>>>JTAG is a requirement so why not use it for the kitchen sink too.
>>>>Hehe. I sure would. Expose every single state bit to the chain. >>>>Combinatorials don't have state, so no worry. If it holds a state, >>>>chain it.
>>>>Jon
>>>This may become impossible as the caches on modern processors are in >>>the megabit range already.
>>Yeah, well.... Our discussion has been there and past it. I think it >>may be important to pass along internal registers and latches for >>diagnostic purposes (ALU output latch, it's input latches if different >>from visible registers, bus latches, etc.) But I'm not terribly keen >>on chaining megabytes of cache. A small instruction cache might be >>nice (for example, the few k of cache that may be present on TI DSPs >>or ARM chips.) Of course, I'm focused on 8-bit and a few 16-bit parts >>for the most part. So this cache stuff rarely impinges on my tiny >>world. I'd probably be happy for more disclosures of the cpu core and >>peripheral chains.
>>Jon
>Focus noted,
>The minimum i would expect it all of the programmer visible stuff and >all the I/O stuff. This is pretty much the definition from the JTAG >working group itself. It is not a whole lot, but it does describe the >basic compromise originally made by the initial JTAG working group.
