>
>>>>
>>>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
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.
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.
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.
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.
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.
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).
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?
What must be done must be. What doesn't isn't. That's simple economics. You simply don't realize what you're asking.
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.
Don't kid yourself. It's never a deciding factor. I note you're using Windows.
I'm telling what my experience is. If you don't like hearing the facts, don't read. It really is that simple.
The entire design. To document every latch in the design you'd have to disclose the entire design. I thought that would be apparent.
You clearly haven't studied a modern microprocessor's microarchitecture. The innards are *not* easily understood.
Because they didn't disclose anything secret, you don't believe there is anything secret to be disclosed by publishing scan chains? Wow!
You clearly believe what you want to believe, no matter what others tell you to be the facts in the case. Oh well.
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.
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.
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.
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.
I think I do realize a fair amount, having come from chipset testing. Not all, but I know enough to be dangerous.
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.
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.
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.)
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.
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.
Of course, I don't think that. That's you now putting words in my mouth.
Actually, I'd like a clear example from you. So far, it's assurances and nothing more. I believe you have knowledge here, but I'd like to see the hand exposed for a second before I become convinced. So far, I accept the possibility but would like to see a specific case exposed.
As done in the PPro and beyond. Not obvious? It was discussed in the literature long before implementation by Intel.
Superscalar and out-of-order execution are areas where I might agree, except that I don't find that in the 8-bit micros I work on. And even then a lot of this has been in the literature for decades. I got quite a personal tour by Hennessey in the mid-1980's about these two areas, so I know much of the literature predates that point in time. So even here, I'd like to know specific cases that make the point.
On 8-bit micros this doesn't seem to be an issue. Instead, it seems that you want to bring in workstations to make your point stronger.
I'm going to hold off. I'm talking about 8-bit micros and you seem to be talking about workstation cpus. I'm fine with not disclosing the bleeding edge of high end cpu markets. Granted. I just don't see this being much of an argument in my sphere of embedded work. Maybe we could re-align the question between us along those lines and then continue?
I'm not sure what you mean to suggest. My comment was simply that I was wrong to overstate my own case at the end and that I really agree (or thought I did) with you that a manufacturer should dedicate 0% more die space for chaining bits than they already want to for existing, good reasons. With that in hand, I suspected we'd be in agreement. What this last comment of yours is about, I don't know.
Perhaps a re-summary of my position would help. I work with small, low power microcontrollers that effectively operate using bog standard ALUs and peripherals for scientific and commercial instrumentation. I assert that there is probably little, if anything, trade secret in my arena that would be exposed by the JTAG chain being documented. You can disagree and if you want try to convince me. It merely takes one good example that I'd agree is present on these pedestrian designs and probably should be kept trade secret, too. So far as my own limited experience together with your writing here goes, you still haven't presented an example. I agree that out of order and superscaler techniques do remain of some possible proprietary value to some, perhaps. But that doesn't intrude into my scale of this world. I have a very hard time understanding how a PIC14 family device would expose something tremendously trade secret if the JTAG chain were documented. You may be able to present an example, but I lack one right now.
The upshot is that I'd like to see the JTAG exposed. Manufacturers, you say, would prefer it wasn't. My experience with manufacturers mostly agrees with your point there. I'm not disagreeing with that. But I think there is a balancing point in here, somewhere, that isn't entirely on the side you present nor necessarily where I present it. And any progress towards more JTAG documentation I'd consider good progress.
Simple as that. Nothing to get angry over.
I just wish there was more documentation than there is. You won't win me over by telling me I should _want_ less, just for the manufacturers sake. I always want more because it places more control in my hands as a user of their tools and less in theirs. A balance I prefer, for obvious reasons.
I believe that you believe you had a need for information you didn't have. So?
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?
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.
Fine, I'll leave it as you have no clue what you're talking about.
When it was in Intel's direct interest, sure. Otherwise, not so much.
Obviously.
Good grief. You're equating a published standard to a proprietary microprocessor?
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'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.
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).
You don't think the design is a trade secret? Wow!
I've already told you other things that are in there that would fall under this umbrella. A competitor could get an idea of yields and process corners if he had access to some of that information.
You obviously haven't looked.
I've given you a list. Aren't you reading?
Do you know all about OoO? Pipelining, scoreboarding, renaming? There is craploads of stuff going on in a modern micro that you may not even know is happening.
How about Intel's microcode "repair" facility. They didn't appreciate that one getting out. That's a major facility but there are tons of trade secrets that no one wants their competitors to have. Process yields can be inferred several ways, given unlimited knowledge and access to the chip.
That's the only conclusion one can make from what you've said here.
I've given you *many* examples. I can't help it if you can't read.
There is more than one way to skin a cat. And PPro wasn't first, by a long STRETCH.
Ok, TIME OUT. You are now free to move the goal posts again.
What's the difference? The same issues apply. No one wants to give their design (or technology details) to the competition. No one even wants to spend the money to document this stuff for other's consumption. Once it's documented someone is likely to use the information in a design, freezing the design where the manufacturer doesn't want it frozen. The internal design becomes the architecture. No one wants that. In short, there are a hundred reasons to protect this stuff as trade secrets and not even one good one to publish it.
Ok, I'll slow down for you.... You said you'd prefer a company that disclosed over one that doesn't, but that you don't want to pay for the information. The company that doesn't use design rules that make full scan chains "free" is just peachy because they don't have the information. But! the company that does use design rules that contain this information but doesn't disclose the information is *evil*, even though they may be paying for that information themselves (you aren't).
They you care nothing about performance, cost, power, or anything else, but simple.
I *know* otherwise. ...if the scan chains are even there.
It's you who wanted information. I am trying to tell you how it is. I really don't care if you believe me or not.
You don't think the design itself is important? Sheesh.
I'd like them to send me a bushel of Bens, too. It's not going to happen because it's not in their interest, nor a real need of yours to use their product. If you have $1E8-$1E9, perhaps you can change their minds.
Angry? Annoyed at your thick head, perhaps.
You can wish for stars, but you stuck here on Earth. Get over yourself. You aren't the only one who has wishes. Manufacturers do too, and they have the information they need.
I think they do. I just think they draw the line too close to the chest.
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.
Absolutely.
Companies do what they feel is in their interest. Granted.
It needed more, though, than Intel wanted to provide to a broader market.
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.
So we have no disagreement then. I'd like more, at times, than what you imagine my market suggests from your numbers. (In general, my product areas are in the 2000-5000 per year, $2000-$3000 per piece area.)
The L2 was (I can't say now) a separate, wire-bonded chip in the package via the backside bus. Used to be 3 clocks to the L1, 6 to the L2. Can't say, now.
Which design.
Then I'm ignorant of how. No news, of course, to anyone.
I still would prefer a chip, other things equal, where this is documented and available.
I've done a design and tested it successfully, RTL. So believe I have more knowledge than many of what goes into a small 8 bitter.
Hand waving.
I had to learn about much of this at Intel. Next. I'm not talking workstation chips, remember?
I'm not talking about workstation chips. You keep at it.
No, there are others.
Only in gross strokes. Doesn't make a case. I'm focused on 8 bit, remember?
Indeed!
Which is exactly where they always were, in my mind. I never ever consider workstation cpus for my designs. Never have, never will.
I don't want to be more argumentative about all this. I know exactly what I want to have and why. You don't and you can't tell me I'm wrong. Sorry about that.
It is always work to educate others and to support the flow of information. I won't argue that there is a calculation that must be made. However, I still know what I'd prefer and what I'd choose, other things equal. None of this is making _any_ difference in that.
I honestly don't know why you work so hard to convince me I should be happier with less. So I'll stop here and suggest we simply agree that we've reached the end of discussion on these points. I'm glad enough for the options that do exist today and don't mind wishing for more in the future. At that sweet note, thanks very much for your time.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.