22 Mar
2010
22 Mar
'10
12:01 p.m.
Thank you for the response. Over the years, I
can't remember using a
logic analyser
more than two or perhaps three times. Since I usually work on projects
A logic analyser is actually more usually used for hardware debugging
(provided that hardware is not all inside an FPGA or similar where you
can't proble the signals [1]). A good analyser will let you find a timing
problem very quickly -- provided you know how ot use it and interpret the
results.
In my younger days, I thoguh that the reason I had problems debugging
digital hardware (both of my own desing and fixing commercial stuff) was
that I didn't have a logic anlyaser. I felt that was a 'wonder machine'
that would solve all my problems. I now realise that the main problem I
has was lack of experience (and intellegence), and that quite simple test
gear will find most poblems. I now have several logic analysers, and
while I do use them, and yes, they are sometimes essential for tracking
down the fault, they are not a replacement for a brain :-)
[1] It is sometimes claimed you can bring out internal signals in the
FPGA to spare pins on the device and conenct a logic analyser to them.
The problem is that any change to the FPGA configuration is likely to
internally re-route sginals which will significantlu alter the timing. So
if your logic design is poor, you will find glitches come and go ans you
change the signals you're looking at. And if oyur logic design is good,
you don;'t have problems anyway.
This is one reason why for one-off designes I am much happier wiring up a
few dozen TTL packages than using programmable devices. It's quicker to
build and debug.
by myself,
I would not have had access to one. The last time, the fellow in charge
of the project
was not able to program, was was a whizz at electronics and could
connect the logic
analyser faster than I could see what he was doing.
In addition, over 90% of my work for the past 20 years has been on the
PDP-11
which has mostly adequate tools to debug the code, especially now with the
The time I use a logic analyaser on the PDP11 (or any other minicomputer)
is to track down hardware fualts in the CPU to gate level.
Single-stepping the microocde, while very useful, doesn't pick up
problems when a gate is 'going slow'.
Similarly my technique for debugging an HP9810/9820/9030 'calculator' is
to connect a logic analyser to the test conenctor on the CPU control PCB
and trace the microcode. Armed witht he microcode source listing (it's
the same for all the machines), I can then see just what the CPU thinks
it's doing and see (a) if that's sensible and (b) if it's actually doing it.
[...]
As for your last point, your observation that when
instructions and data
reside
in cache, a logic analyser is not going to be very useful is an aspect I
had not
ever thought about as a potential problem. INTERESTING!!
There are 2 reelated problems. With a modern-ish microprocessor (external
program store, but things like instruction pipelines, prefetch buffers,
etc), you can't know what the CPU is actually doing at any point. If you
have an internal cache, it is of course even worse.
The other problem is that with microcontrollers, even if it's a simple,
old-fashioned, CPU sturctur, the entire program memory is on the same
chip as the CPU itself. You simply don't have access to the program store
address and data buses. So you can't know what the CPU is actually trying
to execute, or even what program locations it's read.
I do seriously wonder about the real value of such chips used in control
systems. I'd rahter have something simpler that I can show is working
correctly. It seems to me that a lot of the time the extra power of these
modern microcontrollers doesn't at anything useful to the final product.
-tony