KA620

From: Paul Koning <pkoning_at_equallogic.com>
Date: Tue Mar 23 16:02:40 2004

>>>>> "ben" == ben franchuk <bfranchuk_at_jetnet.ab.ca> writes:

 ben> Paul Koning wrote:
>> Meanwhile, something like AXE is your best bet to catch unexpected
>> instruction interactions. It was used because it provides FAR
>> better coverage than conventional CPU diagnostics. Not alone, of
>> course -- you still want to pass regular diagnostics, and run all
>> the applications you can think of. And the microcode still has to
>> be carefully designed and coded. But AXE adds yet another level
>> of assurance to the implementation.

 ben> Forget the axe! Build simpler computers that work!

I don't think there ever has been a computer simple enough that you
could analyze its state space exhaustively. So the answer is a
combination of careful design and careful testing. AXE is a tool for
the latter.

By the way, most computers do work. There have been some spectacular
exceptions lately, but those ARE exceptions.

 ben> I don't still don't trust it! CPU diagnostics needs to be
 ben> designed into the CPU in the design not added later. But CPU's
 ben> nowdays are designed for speed not long life. Also what happens
 ben> when AXE or any other test finds a FAULT. Crash the system or
 ben> what?

AXE (as used at DEC) is an implementation verification tool, used as
part of the verification testing of a new implementation of a given
processor architecture (VAX or Alpha). It isn't run in the field, so
the question isn't meaningful. I'd assume that a failure would stop
the system under test and spit out lots of details about CPU state,
but I've never been close enough to be sure.

None of this has anything to do with speed, long life, etc. -- it's
just looking for design errors.

CT3 (the CDC 6600 analog) is a field service tool, and it spits out
details about what's wrong when it finds something wrong. At that
point the tech would have to start swapping modules, check wiring for
loose cables, etc. But that's an earlier generation system where
you'd expect CPU malfunctions in the field due to wear and tear.

      paul
Received on Tue Mar 23 2004 - 16:02:40 GMT