My hat is off to Microchip and their CEO!
David L. Jones
I recently reviewed the new Microchip PICkit3 compared to the old PICkit2
and pretty much hammered the people responsible on behalf of those who have
found the PICkit3 upgrade rather lacking:
http://www.eevblog.com/2009/10/21/eevblog-39-pickit-3-programmerdebugger-review/
At it turns out, not surprisingly the video made it's way all around the
Microchip offices, even to the desk of their CEO.
As with any multi billion dollar corporation, I expected either deathly
silence or a nasty letter from their lawyers.
But it turns out Microchip really do care about their products and
customers, and really do listen, so they seriously took it as constructive
criticism.
So not only was my blog well received at Microchip, I got a lengthy call
from none other than the Microchip CEO Steve Sanghi, thanking me for the
blog and raising the issues. He pointed out a few factual errors which was
fair enough, but admitted they could have done the PICkit 3 better and most
importantly are working to fix the issues and give customers what they
expect.
They have even posted this hillarious video response in record time:
http://www.youtube.com/watch?v=3YUvlrVlNao
I am absolutely blown away by their honesty and responsiveness, and it
starts from their CEO down.
Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
Dave.
--
---------------------------------------------
Check out my Electronics Engineering Video Blog & Podcast:
http://www.eevblog.com
Trevor Wilson
"David L. Jones" <alt...@gmail.com> wrote in message
news:a7nGm.354$hJ2...@newsfe13.iad...
**Nice one Dave.
--
Trevor Wilson
www.rageaudio.com.au
JERD
"Trevor Wilson" <tre...@SPAMBLOCKrageaudio.com.au> wrote in message
news:7kud90F...@mid.individual.net...
The power of one person (Dave)
Well done!!
JERD
Dirk Bruere at NeoPax
I'll take a look at the PIC for my next project.
--
Dirk
http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.blogtalkradio.com/onetribe - Occult Talk Show
DJ Delorie
"David L. Jones" <alt...@gmail.com> writes:
> http://www.youtube.com/watch?v=3YUvlrVlNao
Sigh, I've been in that type of meeting before. Not as Mr Head, of
course.
Mark Harriss
What's the PIC architecture like these days?, I heard it was always
pretty messy in terms of memory and a real pain to program in assembly.
Still it can't be much worse than some of the MAXQ series.
David L. Jones
> DJ Delorie wrote:
>> "David L. Jones" <alt...@gmail.com> writes:
>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> Sigh, I've been in that type of meeting before. Not as Mr Head, of
>> course.
>
>
> What's the PIC architecture like these days?, I heard it was always
> pretty messy in terms of memory and a real pain to program in
> assembly.
Tons better.
They have the PIC18 series which is more C friendly than the old 16 series,
the 16 bit PIC24 series which is quite nice, and the new 32 bit PIC32 series
based on a MIPS 4K core. Plus the dsPIC too.
And why would you want to program in assembler anyway for all but niche
areas?
Even the old 16 series is not messy if you use a good C compiler, it takes
care of any issues for you.
Dave.
--
================================================
Les Cargill
> DJ Delorie wrote:
>> "David L. Jones" <alt...@gmail.com> writes:
>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> Sigh, I've been in that type of meeting before. Not as Mr Head, of
>> course.
>
>
> What's the PIC architecture like these days?, I heard it was always
> pretty messy in terms of memory and a real pain to program in assembly.
>
You order ones with enough memory internally. The ones I've used were
USB connected and the easiest programming I've ever done. The
external pins are all either built in or macros in a .h file. I
honestly never checked
> Still it can't be much worse than some of the MAXQ series.
--
Les Cargill
Martin Riddle
"David L. Jones" <alt...@gmail.com> wrote in message
news:a7nGm.354$hJ2...@newsfe13.iad...
You can add Altera to the list, I received an email from them about some
issues I had with their website.
Many people lurk here.
Cheers
Martin Riddle
"DJ Delorie" <d...@delorie.com> wrote in message
news:xny6mt2...@delorie.com...
That�s because you don�t have a MBA ;D
Cheers
a7yvm1...@netzero.com
Microchip's always been a cool company, but a shite MCU architecture.
Sorry, Microchip. I'll use your DACs though!
DJ Delorie
And *that* is why I refuse to get an MBA :-)
Swanny
Maybe you don't understand the benfits of MH architecture.
Nik Rim
"Swanny" <swa...@nospam.org> wrote in message
news:72uGm.50908$ze1....@news-server.bigpond.net.au...
Tell me what they are. (Genuine question)
thanks
a7yvm1...@netzero.com
Swanny
Briefly, the Modified-Harvard architecture used in the PIC devices
separates the program memory from the data memory, in other words
separates the ROM/FLASH program memory from the RAM. In the case of the
PIC, the program memory bus width is larger than the data memory bus
width, allowing transfer of the complete instruction op code in fewer
cycles (many instructions take only 1 cycle).
The PIC peripheral bus (ie that accessible through external pins) uses
the same bus as the data memory and hence is also isolated from the
program memory. From a security perspective this allows sensitive data
(such as encryption keys etc) to be stored in program memory and be
completely inaccessible from the outside (provided the fuses are blown
after programming). The Microchip devices are particularly good in this
respect.
Nik Rim
thanks Swanny, that makes sense.
Al Borowski
> Briefly, the Modified-Harvard architecture used in the PIC devices
> separates the program memory from the data memory, in other words
> separates the ROM/FLASH program memory from the RAM.
[...]
Yes, but there's more to to a uC core then choosing between Harvard or
Von Neumann. I think most of the PICs quirks come from the other
decisions made.
The PIC (up to 16 bit cores anyway) is an accumulator architecture -
you have to funnel everything through the W register. AVRs for
instance have 32 registers which is nowhere near as clunky. The PIC
has dedicated memory for the Stack and is a PITA to save/restore local
variables. PICs have fun issues with banking and paging (not so much
in the 16 bit core thankfully). Personally, I think the most annoying
thing about programming PICs in assembly are the btfsc (test a bit in
'file', skip the next instruction if it's clear) and btfss (same thing
but skip if set) instructions. Why they couldn't just call these ifbit
and ifnbit, I don't know :-)
Back to the OP, great job Microchip on the video. It's a nice contrast
to TI, who recently sent misleading DMCA notices to people who tried
installing after-market OSs on their graphics calculators (
http://news.cnet.com/8301-30685_3-10374284-264.html )
Cheers,
A;
Spehro Pefhany
<alt...@gmail.com> wrote:
>Mark Harriss wrote:
>> DJ Delorie wrote:
>>> "David L. Jones" <alt...@gmail.com> writes:
>>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>>
>>> Sigh, I've been in that type of meeting before. Not as Mr Head, of
>>> course.
>>
>>
>> What's the PIC architecture like these days?, I heard it was always
>> pretty messy in terms of memory and a real pain to program in
>> assembly.
There are really several PIC architectures.. the 12-bit instruction,
(PIC16F54, PIC12F509 etc.) the 14-bit instruction (most other PIC16F,
16 bit instructions (PIC18) (PIC17 is a dead end), the PIC24/DSPIC,
and the PIC32. They've also extended the instruction sets in a couple
of families. The 12-bit type is the most limiting, but also the most
parsimonious with resources. Even C can't hide the ugliness there, but
in most cases you won't notice or care because the tasks are
relatively simple. For example, IIRC constant arrays can't exceed a
page in size (256 bytes).
>Tons better.
>They have the PIC18 series which is more C friendly than the old 16 series,
>the 16 bit PIC24 series which is quite nice, and the new 32 bit PIC32 series
>based on a MIPS 4K core. Plus the dsPIC too.
>And why would you want to program in assembler anyway for all but niche
>areas?
IThe PIC18 is quite pleasant to program in assembler... just use
access ram for everything you can, and you don't have to think much
about banking. About the only thing I miss is an indexed plus offset
addressing mode, and I think they have that in the extended
instruction set mode, but I have not played with that (there are some
trade-offs or it would not have to be another mode).
As to the C vs. asm question.. well, if you have to have a USB or
Ethernet (or Bluetooth) stack then you're in C territory. For less
than 16 k bytes of program memory, assembler probably deserves a look,
especially if you're not doing C-like things. And it depends on the
skill set and prior experience the programmer has, as well as whether
it's worth wringing out what is usually a << 2:1 improvement in
program memory size and performance.
>Even the old 16 series is not messy if you use a good C compiler, it takes
>care of any issues for you.
>
>Dave.
The Hitech C compiler (even the free 'lite' one) works pretty well,
though I've found some irritating bugs. It will even generate useful
code for the 12-bit instruction chips.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
MooseFET
> > Briefly, the Modified-Harvard architecture used in the PIC devices
> > separates the program memory from the data memory, in other words
> > separates the ROM/FLASH program memory from the RAM.
>
> [...]
>
> Yes, but there's more to to a uC core then choosing between Harvard or
> Von Neumann. I think most of the PICs quirks come from the other
> decisions made.
>
> The PIC (up to 16 bit cores anyway) is an accumulator architecture -
> you have to funnel everything through the W register.
Going with accumulator model allowed Microchip to make the processor
with fewer transistors. It is a trade off that can break either way.
If you have a limit on the chip size you can make a higher performance
processor that is harder to program.
[....]
> in the 16 bit core thankfully). Personally, I think the most annoying
> thing about programming PICs in assembly are the btfsc (test a bit in
> 'file', skip the next instruction if it's clear) and btfss (same thing
> but skip if set) instructions. Why they couldn't just call these ifbit
> and ifnbit, I don't know :-)
Does ifbit mean skip if the bit is set or do the instruction if the
bit is set?
>
> Back to the OP, great job Microchip on the video. It's a nice contrast
> to TI, who recently sent misleading DMCA notices to people who tried
> installing after-market OSs on their graphics calculators (http://news.cnet.com/8301-30685_3-10374284-264.html)
>
> Cheers,
>
> A;
I still prefer the 8051. It is way better.
[ducks]
baron
Absolutely hilarious ! :-)
I enjoyed both videos.
Good on ya Dave.
--
Best Regards:
Baron.
TheM
> Nik Rim wrote:
>> "Swanny" <swa...@nospam.org> wrote in message
>> news:72uGm.50908$ze1....@news-server.bigpond.net.au...
>>> a7yvm1...@netzero.com wrote:
>>>> Refurbished LEDs? LOL!
>>>> Microchip's always been a cool company, but a shite MCU architecture.
>>>> Sorry, Microchip. I'll use your DACs though!
>>> Maybe you don't understand the benfits of MH architecture.
>>
>>
>> Tell me what they are. (Genuine question)
>> thanks
>>
>>
>
> Briefly, the Modified-Harvard architecture used in the PIC devices
> separates the program memory from the data memory, in other words
> separates the ROM/FLASH program memory from the RAM. In the case of the
> PIC, the program memory bus width is larger than the data memory bus
> width, allowing transfer of the complete instruction op code in fewer
> cycles (many instructions take only 1 cycle).
Just like with AVR, practically everything 1 cycle except branches.
M
Raveninghorde
So do I. The 8051 family was/is great.
But I found the varients of 8051 I used were obsolete on more than one
occassion causing problems. I'm still sourcing SAB80C517 at silly
prices for example.
I first used the PIC for very low cost apps around 1990 and found that
there was always an upgrade path which didn't obsolete my designs.
Secondly Microchip always have product available. I recall one rep
trying to convert me to the ST6. Then he said ST are behind on
production and delivery was 4-6 months.
There are better micros than the PIC from an engineering perspective
but they are hard to beat from a production view point.
Jon Kirwan
I'm using one from SiLabs, right now. Last 8051 project I did was
back in the early 1980's. (Still have a box of about 100 80C32 chips
in perfect shape.) For this app, I needed a much faster floating
point ln(x) function (achieved under 18 microseconds) and found myself
spending some time coding assembly on it. No question in my mind that
this processor was designed with hand-coded assembly in mind, though.
Very easy to use efficiently for a human coder, though I do have to
check the book often to see if a particular instruction supports a
particular mode of access, yet just the kind of thing to seriously
complicate a compiler's life.
>But I found the varients of 8051 I used were obsolete on more than one
>occassion causing problems. I'm still sourcing SAB80C517 at silly
>prices for example.
I gather that Atmel has an AT89 line that includes an external bus and
so does SiLabs. Not sure how either of these would score on not
obsoleting designs, though.
>I first used the PIC for very low cost apps around 1990 and found that
>there was always an upgrade path which didn't obsolete my designs.
Yes. I've been using PICs since the late 1980's.. just around the
very month that Parallax entered the public fray. Nobody likes the
bare-bones ALU design for the smaller-width instruction families --
it's design guts lay out on the floor, plain to see. But Microchip
has maintained a very serious commitment to upgrade pathways over the
entire time I've been involved (just after they decided to move beyond
the "million unit rice cooker customer" days and place them into a
broader marketplace. I couldn't have guessed then how strong that
commitment would be. But they seem to well know what is important and
they have clearly (to me) worked very hard to _earn_ the respect they
have gained. And it's been so on almost every good business front.
One begins to realize after experiencing such a company's commitment
to their customers, if that realization isn't already at hand, just
how relatively unimportant an instruction set is to all these other
business factors.
>Secondly Microchip always have product available. I recall one rep
>trying to convert me to the ST6. Then he said ST are behind on
>production and delivery was 4-6 months.
Well, Microchip has had their days with delays (the wait for the
18F252 from using the 18C252 comes to mind) but they have tended to be
shorter than longer delays.
>There are better micros than the PIC from an engineering perspective
>but they are hard to beat from a production view point.
In all the time I've used them, they have consistently maintained a
solid professional use pathway that simply doesn't break. I have old
tools that they no longer make (ProMate II) and yet they still support
it without question or quibble. If I have so much as a flaky power
switch they want me to send it in and fire off a replacement with
shipping included for the "bad" one, so that I don't even miss a
single second of use. Same for the modules that plug into it. Their
tools are supported, decades it seems after they don't sell them
anymore. That takes commitment on their part.
I find wringing of hands over the instruction set to be relatively
badly placed. There are a lot more important things to focus on and
on those areas Microchip has done a yeoman's service across the board.
Obviously, I use other manufacturers too. It's _very_ hard to find a
1MHz 16-bit SAR ADC anywhere in Microchip's monolithic cpu fold, for
example. But none of have compared quite as well on the business
issues over the years.
Jon
David L. Jones
Also when looking for a long term investment in micros you may have to
consider the companies viability.
Microchip are essentially the only micro manufacturer actually making monay
and doing quite well at present. All the others are losing money
hand-over-first and some are in a very bad state. All the fanboys scream
Atmel, but they haven't made a cent since they started, and are probably the
most unstable in terms of long term viability.
Jon Kirwan
I will turn this question around on its head in a moment. Your point
is made, but there is another view, too.
>Microchip are essentially the only micro manufacturer actually making monay
>and doing quite well at present.
I place this at the feet of the quality of their business managers and
their clear recognition of the right priorities in forging lasting
business relationships. I am sure that there are excellent technical
resources developing microcontroller products at all of the other
businesses. Perhaps just as good as found at Microchip -- I simply
can't compare them because I'm not informed about it. But I do know
how they operate their business model. And I have been little other
than impressed with it. So while I'm sure that poor technical quality
would kill them (so I'm sure they do have good technical resources),
so also would a poorly arranged set of priorities in their business
design. And their competition, from my experience, do not come very
close, sad to say. Almost to a company, though they differ in the
reasons why I think they hang themselves on some point or another.
>All the others are losing money
>hand-over-first and some are in a very bad state.
I would tend to imagine this would give them a clue. Standing on the
outside as a consumer of these kinds of products, I have no question
at all why Microchip is doing well. It's actually pretty easy to see
why they are successful. They are committed to a mutual relationship
in business and they actually _work_ at earning their respect, day in
and day out. They just don't slip up on this.
If they do fail, it will only be because the entire field is in a nose
dive. Not because they didn't get the business issues right.
>All the fanboys scream
>Atmel, but they haven't made a cent since they started, and are probably the
>most unstable in terms of long term viability.
I don't know much about Atmel. I developed one commercial product
using their AT90S2312, I think. From start to finish, it took me 4
days to write it and the experience was excellent during the process
because I never needed to actually call for any support from Atmel and
the part worked well. Later, when considering an AT91 from Atmel's
French arm, experiences turned significantly sour because I did have
to involve them. And that's the last time I considered using Atmel
for professional use -- I still like them for personal projects where
I know in advance I'm not depending on them for anything serious.
I tend to imagine that it is Atmel's own fault for ordering it's
business priorities wrongly. At least that's a consistent theory from
my short experience with them. I would have NO problem specifying an
Atmel part for some hobbyist project. But that's about where I draw
the line. And just perhaps, others have also learned from experiences
not unlike my own. Perhaps they are paying the piper, now. But I
can't say. Might be for entirely different reasons.
Love your web site, when I get time to enjoy it!
Jon
Bob Larter
> They have even posted this hillarious video response in record time:
> http://www.youtube.com/watch?v=3YUvlrVlNao
>
> I am absolutely blown away by their honesty and responsiveness, and it
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
Very cool, Dave.
BTW, I loved your #40 blog[0], but I'm worried that it could get you in
trouble. Have your bosses discovered your blog yet?
[0] I've worked on several Doomed Projects myself.
--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------
krw
<raveninghorde@invalid> wrote:
8051s, in several performance varieties (parallel one-clock to the
original serial 12-clock ALU), are now available as FPGA soft cores.
Obsolete chip? Just synthesize. Haven't quite figured out why I want
to buy FPGA fabric to do an 8051, though. ;-)
>I first used the PIC for very low cost apps around 1990 and found that
>there was always an upgrade path which didn't obsolete my designs.
>
>Secondly Microchip always have product available. I recall one rep
>trying to convert me to the ST6. Then he said ST are behind on
>production and delivery was 4-6 months.
>
>There are better micros than the PIC from an engineering perspective
>but they are hard to beat from a production view point.
I don't see much use for the larger PICs. We're using a PIC-24 but
it's more than overkill and just too weird.
MooseFET
[.. was PIC now 8051s ..]
>
> I'm using one from SiLabs, right now.
Just one? One of my designs is about to go into production with two
F120s
clocked at nearly 90MHz. One of them is just about fully busy. The
other
has many microseconds to spare.
> in perfect shape.) For this app, I needed a much faster floating
> point ln(x) function (achieved under 18 microseconds) and found myself
> spending some time coding assembly on it.
Do you really need true floating point? do you really need ln() or
would log2() do? 18 microseconds seems a little slow.
Doing log2() of a 32 bit floater can be fairly quick if you don't
care
much about how much code space you use.
> No question in my mind that
> this processor was designed with hand-coded assembly in mind, though.
> Very easy to use efficiently for a human coder, though I do have to
> check the book often to see if a particular instruction supports a
> particular mode of access, yet just the kind of thing to seriously
> complicate a compiler's life.
Real men code in assembly anyway.
David L. Jones
> David L. Jones wrote:
>> They have even posted this hillarious video response in record time:
>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>
>> I am absolutely blown away by their honesty and responsiveness, and
>> it starts from their CEO down.
>> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>
> Very cool, Dave.
> BTW, I loved your #40 blog[0], but I'm worried that it could get you
> in trouble. Have your bosses discovered your blog yet?
Yes, my company is fully aware I do it, and I work within their blogging
guidelines (yes, they actually encourage us to do this sort of thing).
But all of those projects are from previous companies (now mostly folded),
so no problem!
Jon Kirwan
<kens...@rahul.net> wrote:
>On Oct 30, 2:09�pm, Jon Kirwan <j...@infinitefactors.org> wrote:
>[.. was PIC now 8051s ..]
>>
>> I'm using one from SiLabs, right now.
>
>Just one? One of my designs is about to go into production with two
>F120s clocked at nearly 90MHz. One of them is just about fully busy. The
>other has many microseconds to spare.
I'm clocked at 24MHz. Which is fine enough. I think it's about 422
SYSCLKs. At 90MHz, that would be more like 4.5 microseconds. But I'm
not there.
>> in perfect shape.) �For this app, I needed a much faster floating
>> point ln(x) function (achieved under 18 microseconds) and found myself
>> spending some time coding assembly on it.
>
>Do you really need true floating point? do you really need ln() or
>would log2() do? 18 microseconds seems a little slow.
It's running on 24MHz, not 90MHz, for one thing. And it needs 20
precision bits in the result with an input value possessing a good 30
bits (the compiled result of thousands of other measurements.)
>Doing log2() of a 32 bit floater can be fairly quick if you don't
>care much about how much code space you use.
Well, I'm good already. Plus, it is custom-tailored to the job.
>> �No question in my mind that
>> this processor was designed with hand-coded assembly in mind, though.
>> Very easy to use efficiently for a human coder, though I do have to
>> check the book often to see if a particular instruction supports a
>> particular mode of access, yet just the kind of thing to seriously
>> complicate a compiler's life.
>
>Real men code in assembly anyway.
I think better programmers are well experienced in using assembly and
will use it as appropriate, taking into account the tasks and clients.
Lacking such experience is the loss of a significant mental and
practical toolset that could otherwise be brought to bear on problems.
That doesn't mean every application gets coded entirely in assembly.
Jon
Don McKenzie
> You aren't going to believe this...
>
> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2
> and pretty much hammered the people responsible on behalf of those who have
> found the PICkit3 upgrade rather lacking:
Dave, compliments of Spehro Pefhany, the MC PICkit3 story made it to the
Piclist also:
http://old.nabble.com/Microchip%27s-customer-relations..-excellent-response-td26128622.html
Hope you can read it there without going through the login hoops
Cheers Don...
--
Don McKenzie
Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
Web Camera Page: http://www.dontronics.com/webcam
No More Damn Spam: http://www.dontronics.com/spam
Breakout, Prototype, Development, & Robotics Boards:
http://www.dontronics-shop.com/sparkfun-electronics.html
Jon Kirwan
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
Nico Coesel
>
>Also when looking for a long term investment in micros you may have to
>consider the companies viability.
Not really. Most of the cost for designing a product goes into the
firmware. If you use PIC and want to switch to another platform you'll
quickly learn that porting C code from or to PIC is almost impossible
for any real piece of firmware*. If you start out with say Renesas H8,
TI's MSP430 or any ARM flavor you'll find exchanging C code between
those is very easy.
* I know the pheripherals are different. Hardware drivers are least of
the problem though.
--
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!"
--------------------------------------------------------------
MooseFET
Put a break point either side of the routine and look at the contents
of the PCA counter in both places.
Jon Kirwan
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
dagmarg...@yahoo.com
> "Swanny" wrote:
> > Briefly, the Modified-Harvard architecture used in the PIC devices
> > separates the program memory from the data memory, in other words
> > separates the ROM/FLASH program memory from the RAM. In the case of the
> > PIC, the program memory bus width is larger than the data memory bus
> > width, allowing transfer of the complete instruction op code in fewer
> > cycles (many instructions take only 1 cycle).
>
> Just like with AVR, practically everything 1 cycle except branches.
>
> M
But don't the 10xx, 12xx, and 16xx PICs take 4 clocks per instruction
cycle? AVRs only take 1 clock per instruction (with the usual
exceptions).
--
James Arthur
MooseFET
The JTAG section appears to not know anything about what the clock
speed is other than requiring more than 32KHz to work.
Jon Kirwan
<kens...@rahul.net> wrote:
>On Oct 31, 12:28嚙緘m, 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嚙窮m, 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? 嚙瘢'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. 嚙瘢 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. 嚙瘢 was hoping they simply
>> >> counted SYSCLKs, on the debugger device end of things. 嚙瞌ne 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. 嚙畿ut it's a bit of a pain.
>>
>> >> If there's nothing, that's fine. 嚙瘢'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. 嚙瘢 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.) 嚙瘤rom the
>> above response, I take it the answer is 'no.' 嚙璀ccepted.
>>
>> 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
Mark Harriss
> "David L. Jones" <alt...@gmail.com> wrote:
>
>> Also when looking for a long term investment in micros you may have to
>> consider the companies viability.
>
> Not really. Most of the cost for designing a product goes into the
> firmware. If you use PIC and want to switch to another platform you'll
> quickly learn that porting C code from or to PIC is almost impossible
> for any real piece of firmware*. If you start out with say Renesas H8,
> TI's MSP430 or any ARM flavor you'll find exchanging C code between
> those is very easy.
>
> * I know the pheripherals are different. Hardware drivers are least of
> the problem though.
>
This is the kind of gotcha you need to know about in advance when
deciding what architecture to use.
M.Randelzhofer
"David L. Jones" <alt...@gmail.com> schrieb im Newsbeitrag
news:a7nGm.354$hJ2...@newsfe13.iad...
> You aren't going to believe this...
>
> I recently reviewed the new Microchip PICkit3 compared to the old PICkit2
> and pretty much hammered the people responsible on behalf of those who
> have found the PICkit3 upgrade rather lacking:
>
> At it turns out, not surprisingly the video made it's way all around the
> Microchip offices, even to the desk of their CEO.
> As with any multi billion dollar corporation, I expected either deathly
> silence or a nasty letter from their lawyers.
>
> But it turns out Microchip really do care about their products and
> customers, and really do listen, so they seriously took it as constructive
> criticism.
>
> So not only was my blog well received at Microchip, I got a lengthy call
> from none other than the Microchip CEO Steve Sanghi, thanking me for the
> blog and raising the issues. He pointed out a few factual errors which was
> fair enough, but admitted they could have done the PICkit 3 better and
> most importantly are working to fix the issues and give customers what
> they expect.
>
> http://www.youtube.com/watch?v=3YUvlrVlNao
>
> I am absolutely blown away by their honesty and responsiveness, and it
> starts from their CEO down.
> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>
>
> --
> ---------------------------------------------
> Check out my Electronics Engineering Video Blog & Podcast:
> http://www.eevblog.com
>
Sadly also the Microchip Serial Memory Programmer now is supported by MPLAB
only, the former standalone software SEEVAL32 (on the former programmer with
a COM port) was handy and easier to use.
see:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en535259
http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&WT.z_homepage_link=hp_go_button&KeyWords=DV243003&x=16&y=14
Anyhow the new product works fine and is cheap, and the Microchip response
is funny, and lets hope for an SW upgrade for the PICKIT3 and maybe also for
the serial memory programmer.
Does anybody use the pickit serial analyzer ?
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en028600
By the way Dave, your video blog is excellent !
MIKE
--
www.oho-elektronik.de
OHO-Elektronik
Michael Randelzhofer
FPGA und CPLD Mini Module
Klein aber oho !
Kontakt:
Tel: 08131 339230
m...@oho-elektronik.de
Usst.ID: DE130097310
MooseFET
> On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
>
>
>
> >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:
> >> >> 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
> >> >> 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.
> >> >> but for one it may be too coarse (if I have the usual /12 going on)
> >> >> 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
>
> >> >> 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.
>
> >> such use and was hoping that the debug/jtag unit itself maintained a
> >> SYSCLK count I could display without involving software I write
> >> 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.
I think that the clock is only needed to be able to stop the micro. I
doesn't seem to care that much about the clock when it is running or
already stopped. It gets very angry with me on the few cases where I
tried to stop a micro that had no clock.
>
> Jon
Jon Kirwan
My initial board was without a crystal, so just using the internal one
during initial code writing. Seems to work just fine. But I haven't
tried to disable it first, either.
In any case, thanks for the suggestion and removing my desire to keep
looking for a display on the debugger. It will save me bothering with
that silly hope anymore.
Jon
Bob Larter
> Bob Larter wrote:
>> David L. Jones wrote:
>>> They have even posted this hillarious video response in record time:
>>> http://www.youtube.com/watch?v=3YUvlrVlNao
>>>
>>> I am absolutely blown away by their honesty and responsiveness, and
>>> it starts from their CEO down.
>>> Two thumbs up to Steve Sanghi and the guys and gals at Microchip!
>> Very cool, Dave.
>> BTW, I loved your #40 blog[0], but I'm worried that it could get you
>> in trouble. Have your bosses discovered your blog yet?
>
> Yes, my company is fully aware I do it, and I work within their blogging
> guidelines (yes, they actually encourage us to do this sort of thing).
> But all of those projects are from previous companies (now mostly folded),
> so no problem!
Ah, good.
JosephKK
<jo...@infinitefactors.org> wrote:
>On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
><kens...@rahul.net> wrote:
>
>>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.
Jon Kirwan
As I understand JTAG, broadly speaking, its simply a very long shift
register. There is boundary checking, of course. But flashing and
debugging, too. In fact, many internal registers and various flip
flops are available that aren't all visible to the casual programmer,
as well. It's not rocket science or even vaguely difficult to count
cycles, as I gather it.
Jon
Nico Coesel
It most certainly is not. 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).
Jon Kirwan
wrote:
>Jon Kirwan <jo...@infinitefactors.org> wrote:
>
>>On Fri, 06 Nov 2009 22:03:24 -0800,
>>"JosephKK"<quiett...@yahoo.com> wrote:
>>
>>>On Sat, 31 Oct 2009 14:41:50 -0700, Jon Kirwan
>>><jo...@infinitefactors.org> wrote:
>>>
>>>>On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
>>>><kens...@rahul.net> wrote:
>>>>
>>>>>On Oct 31, 12:28锟絧m, 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锟絘m, 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? 锟絀'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. 锟絀 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. 锟絀 was hoping they simply
>>>>>> >> counted SYSCLKs, on the debugger device end of things. 锟絆ne 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. 锟紹ut it's a bit of a pain.
>>>>>>
>>>>>> >> If there's nothing, that's fine. 锟絀'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. 锟絀 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.) 锟紽rom the
>>>>>> above response, I take it the answer is 'no.' 锟紸ccepted.
>>>>>>
>>>>>> 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.
>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.
Jon
krw
<jo...@infinitefactors.org> wrote:
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.
>>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.
Jon Kirwan
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.
>>>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
up to now, until Nico wrote to tell me I was wrong, but I admit not
being an expert in this area.)
Jon
krw
<jo...@infinitefactors.org> wrote:
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.
Jon Kirwan
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
Nico Coesel
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.
krw
<jo...@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
>><jo...@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.
>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%?
krw
wrote:
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.
It's a floor wax *and* a desert topping.
Jon Kirwan
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.
Jon
krw
<jo...@infinitefactors.org> wrote:
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.
Jon Kirwan
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 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.
>>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.
>>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.
>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.
>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?
>>>>>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.
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.
Jon
krw
<jo...@infinitefactors.org> wrote:
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.
>>>>>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).
>>>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!
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.
>But I haven't seen much new under the sun, lately.
You obviously haven't looked.
>>>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?
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.
>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.
>>>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.
>>>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.
>>>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.
>>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.
>>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.
>>>>>>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.
>
>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.
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).
>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.
They you care nothing about performance, cost, power, or anything
else, but simple.
>I
>assert that there is probably little, if anything, trade secret in my
>arena that would be exposed by the JTAG chain being documented.
I *know* otherwise. ...if the scan chains are even there.
>You
>can disagree and if you want try to convince me.
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.
>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.
You don't think the design itself is important? Sheesh.
>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.
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.
>Simple as that. Nothing to get angry over.
Angry? Annoyed at your thick head, perhaps.
>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.
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.
Jon Kirwan
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
JosephKK
<jo...@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
>><jo...@infinitefactors.org> wrote:
>>
>>>On Sat, 07 Nov 2009 16:53:47 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>
>>>>On Sat, 07 Nov 2009 13:29:33 -0800, Jon Kirwan
>>>><jo...@infinitefactors.org> wrote:
>>>>
>>>>>On Sat, 07 Nov 2009 10:42:43 GMT, ni...@puntnl.niks (Nico Coesel)
>>>>>wrote:
>>>>>
>>>>>>Jon Kirwan <jo...@infinitefactors.org> wrote:
>>>>>>
>>>>>>>On Fri, 06 Nov 2009 22:03:24 -0800,
>>>>>>>"JosephKK"<quiett...@yahoo.com> wrote:
>>>>>>>
>>>>>>>>On Sat, 31 Oct 2009 14:41:50 -0700, Jon Kirwan
>>>>>>>><jo...@infinitefactors.org> wrote:
>>>>>>>>
>>>>>>>>>On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
>>>>>>>>><kens...@rahul.net> wrote:
>>>>>>>>>
>>>>>>>>>>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.
This may become impossible as the caches on modern processors are in
the megabit range already.
Jon Kirwan
"JosephKK"<quiett...@yahoo.com> wrote:
>On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan
><jo...@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
>>><jo...@infinitefactors.org> wrote:
>>>
>>>>On Sat, 07 Nov 2009 16:53:47 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>
>>>>>On Sat, 07 Nov 2009 13:29:33 -0800, Jon Kirwan
>>>>><jo...@infinitefactors.org> wrote:
>>>>>
>>>>>>On Sat, 07 Nov 2009 10:42:43 GMT, ni...@puntnl.niks (Nico Coesel)
>>>>>>wrote:
>>>>>>
>>>>>>>Jon Kirwan <jo...@infinitefactors.org> wrote:
>>>>>>>
>>>>>>>>On Fri, 06 Nov 2009 22:03:24 -0800,
>>>>>>>>"JosephKK"<quiett...@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>>On Sat, 31 Oct 2009 14:41:50 -0700, Jon Kirwan
>>>>>>>>><jo...@infinitefactors.org> wrote:
>>>>>>>>>
>>>>>>>>>>On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
>>>>>>>>>><kens...@rahul.net> wrote:
>>>>>>>>>>
>>>>>>>>>>>On Oct 31, 12:28锟絧m, 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锟絘m, 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? 锟絀'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. 锟絀 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. 锟絀 was hoping they simply
>>>>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. 锟絆ne 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. 锟紹ut it's a bit of a pain.
>>>>>>>>>>>>
>>>>>>>>>>>> >> If there's nothing, that's fine. 锟絀'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. 锟絀 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.) 锟紽rom the
>>>>>>>>>>>> above response, I take it the answer is 'no.' 锟紸ccepted.
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
JosephKK
<jo...@infinitefactors.org> wrote:
>On Sun, 08 Nov 2009 18:10:45 -0800,
>"JosephKK"<quiett...@yahoo.com> wrote:
>
>>On Sat, 07 Nov 2009 17:33:15 -0800, Jon Kirwan
>><jo...@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
>>>><jo...@infinitefactors.org> wrote:
>>>>
>>>>>On Sat, 07 Nov 2009 16:53:47 -0600, krw <k...@att.bizzzzzzzzzzz> wrote:
>>>>>
>>>>>>On Sat, 07 Nov 2009 13:29:33 -0800, Jon Kirwan
>>>>>><jo...@infinitefactors.org> wrote:
>>>>>>
>>>>>>>On Sat, 07 Nov 2009 10:42:43 GMT, ni...@puntnl.niks (Nico Coesel)
>>>>>>>wrote:
>>>>>>>
>>>>>>>>Jon Kirwan <jo...@infinitefactors.org> wrote:
>>>>>>>>
>>>>>>>>>On Fri, 06 Nov 2009 22:03:24 -0800,
>>>>>>>>>"JosephKK"<quiett...@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>>On Sat, 31 Oct 2009 14:41:50 -0700, Jon Kirwan
>>>>>>>>>><jo...@infinitefactors.org> wrote:
>>>>>>>>>>
>>>>>>>>>>>On Sat, 31 Oct 2009 12:50:09 -0700 (PDT), MooseFET
>>>>>>>>>>><kens...@rahul.net> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>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.
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.
Jon Kirwan
"JosephKK"<quiett...@yahoo.com> wrote:
>>>>>>>>>>>>>> >On Oct 31, 12:36锟絘m, 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? 锟絀'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. 锟絀 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. 锟絀 was hoping they simply
>>>>>>>>>>>>>> >> counted SYSCLKs, on the debugger device end of things. 锟絆ne 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. 锟紹ut it's a bit of a pain.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> >> If there's nothing, that's fine. 锟絀'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. 锟絀 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.) 锟紽rom the
>>>>>>>>>>>>>> above response, I take it the answer is 'no.' 锟紸ccepted.
Wonderful to meet in some common ground, then.
Jon