Disc analyser news update
ggs at shiresoft.com
Sun Mar 21 10:48:13 CDT 2010
On Mar 21, 2010, at 5:15 AM, Jerome H. Fine wrote:
> >Tony Duell wrote:
>>> Sorry to barge in, but I don't think is exactly correct. On most ARM systems these days, for
>>> example, there are multiple hardware breakpoints inside the jtag debug logic which are
>>> not intrusive. They don't perterb the instruction stream at all until they are hit.
>> No, you misunderstood me. A breakpoint is intrusive in that when it is hit it stps the code execution (There are plenty of other debugging feautrs in some chip,s but they're not strictly breakpoints). For tyhe sort of thing I would use a microcontroller for (which involves generating precisely timed signals to control external hardware) I can't have my progrma suddenly being stopped for the debugger.
>> A logic analyser will grabe state and not stop the program running.
> In effect, what the logic analyser did was to display the results of stepping
> through about 100 instructions showing the data values and address pointers
> that were required as they were used by the program. This is exactly what
> a debugging session would be when a used to actually stop the program and
> then manually and visually inspects the values of interest. While the logic
> analyser is much more restrictive, its great advantage is that it does NOT
> change the timing of the operation since it captures any data it collects
> in real time and stores it in its own buffers outside of and apart from the
> system being tested without in any manner disturbing the system being
> tested by that observation. The logic analyser can do this because it
> is able to collect the data in its own buffer as the data is produced by the
> test system without regard as to when the trigger location or event in the
> system being tested will take place. When the event does occur, the logic
> analyser then takes a simple action. It stops accepting any more data and
> retains the snapshot of the previous bunch of instructions that preceded
> the event. It is like asking the breakpoint to take place at a certain location,
> then asking the system to reverse itself and run backwards to look at what
> HAD JUST HAPPENED during the previous 100 instructions. Obviously
> impossible to do with a breakpoint on the normal way, but that is how the
> logic analyser functions.
> Please correct my memory of how the logic analyser functions if I did
> not remember correctly - or if that is just one of the modes of operation.
> To accomplish to feat, the logic analyser probably has to run at least 10 times
> faster than the system being tested. (Tony, do you have any estimates?)
> With the fastest CPUs being used today, that is becoming increasingly MUCH
> more difficult. Tony, is that what you are concerned about as well, how the
> logic analysers are able to keep up?
We have (spread across a number of labs) some bus analyzers for the current crop (actually the just previous generation) of Intel CPUs. They are *hairy* beasts (a rack full of equipment + cables that bury the MLB). We take the systems to debug to them (the analyzers just aren't portable in any stretch of the imagination) and it usually takes about a day to get them set up. The fact that they can actually capture (reliably) the information flowing across a bus at 1066MHz is amazing. They cost in the neighborhood of $500K each. They're a bit of a pain to use (mostly due to mechanical & electrical setup) so we tend to use them only after we've spent considerable time debugging via other methods. What we usually find is that there's some corner case issue with the bus protocol.
TTFN - Guy
More information about the cctalk