Re: 8051 was My hat is off to Microchip and their CEO!
- From: Jon Kirwan <jonk@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 08 Nov 2009 17:11:28 -0800
On Sun, 08 Nov 2009 18:34:09 -0600, krw <krw@xxxxxxxxxxxxxxxxx> wrote:
On Sun, 08 Nov 2009 15:49:17 -0800, Jon Kirwan
<jonk@xxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 08 Nov 2009 15:58:55 -0600, krw <krw@xxxxxxxxxxxxxxxxx> wrote:
On Sun, 08 Nov 2009 11:33:59 -0800, Jon Kirwan
<jonk@xxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 08 Nov 2009 10:30:05 -0600, krw <krw@xxxxxxxxxxxxxxxxx> wrote:
On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan
<jonk@xxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 07 Nov 2009 18:59:39 -0600, krw <krw@xxxxxxxxxxxxxxxxx> wrote:
On Sat, 07 Nov 2009 16:33:14 -0800, Jon Kirwan
<jonk@xxxxxxxxxxxxxxxxxxx> 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.
Absolutely.
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, 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.)
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.)
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).
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.
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.
You don't think the design is a trade secret? Wow!
Which design.
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.
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.
But I haven't seen much new under the sun, lately.
You obviously haven't looked.
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.
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.
I've given you a list. Aren't you reading?
Hand waving.
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.
I had to learn about much of this at Intel. Next. I'm not talking
workstation chips, remember?
An example that has been exposed and no longer is one, if appropriate,
would make your point for me.
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.
I'm not talking about workstation chips. You keep at it.
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!
Of course, I don't think that. That's you now putting words in my
mouth.
That's the only conclusion one can make from what you've said here.
No, there are others.
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.
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.
I've given you *many* examples. I can't help it if you can't read.
Only in gross strokes. Doesn't make a case. I'm focused on 8 bit,
remember?
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.
As done in the PPro and beyond. Not obvious? It was discussed in the
literature long before implementation by Intel.
There is more than one way to skin a cat. And PPro wasn't first, by a
long STRETCH.
Indeed!
OoO execution.
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.
Ok, TIME OUT. You are now free to move the goal posts again.
Which is exactly where they always were, in my mind. I never ever
consider workstation cpus for my designs. Never have, never will.
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.
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?
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.
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.
Jon
.
- References:
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: Jon Kirwan
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: krw
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: Jon Kirwan
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: krw
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: Jon Kirwan
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: krw
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: Jon Kirwan
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: krw
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: Jon Kirwan
- Re: 8051 was My hat is off to Microchip and their CEO!
- From: krw
- Re: 8051 was My hat is off to Microchip and their CEO!
- Prev by Date: Re: useless, but cool
- Next by Date: Re: Stupid comments by an engineer
- Previous by thread: Re: 8051 was My hat is off to Microchip and their CEO!
- Next by thread: Re: 8051 was My hat is off to Microchip and their CEO!
- Index(es):
Relevant Pages
|