Prev: Barcode scanner reverse engineering
Next: Advice/info about extracting ROM dump from 20-year-old COPS microcontroller?
From: Mel on 20 May 2010 14:22
Grant Edwards wrote:

> On 2010-05-20, Paul E. Bennett <Paul_E.Bennett(a)topmail.co.uk> wrote:

>> That takes me back to the mini-computer era. Especially the clients
>> that needed it built into their installation because they wanted to
>> be extremely confident that their system was calculating the right
>> results.
>>
>> It was just a case of checking that all the right flags were set
>> after a specific set of data was put through the instructions.
>
> How do you do that without assuming that instructions are executed
> properly? Is there a second, independantly designed and built
> processor whose results are compared with the first one?
>
> Or is there some reason to beleive that some particular subset of the
> CPU instructions can be relied upon but the rest cannot?

ISTR one would debug the minimum bootloader -- the one-card boot or the
three-card boot -- using the console switches. Then the test program would
have some kind of hope of running to test everything else.

Mel.
>


From: Walter Banks on 20 May 2010 14:46


Grant Edwards wrote:

> How do you do that without assuming that instructions are executed
> properly? Is there a second, independantly designed and built
> processor whose results are compared with the first one?
>
> Or is there some reason to beleive that some particular subset of the
> CPU instructions can be relied upon but the rest cannot?

One approach was implementing a finite state machine that would
not exit unless instruction test or some defined subset worked. I
worked a minicomputer instruction set way back and got the fun
job writing some of the instruction tests. Plenty of coffee and late
nights. The real task was actually making sure that we could not
get a false positive and trust a failed computer.

Regards,


Walter..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com







From: Grant Edwards on 20 May 2010 16:00
On 2010-05-20, Walter Banks <walter(a)bytecraft.com> wrote:
> Grant Edwards wrote:
>
>> How do you do that without assuming that instructions are executed
>> properly? Is there a second, independantly designed and built
>> processor whose results are compared with the first one?
>>
>> Or is there some reason to beleive that some particular subset of the
>> CPU instructions can be relied upon but the rest cannot?
>
> One approach was implementing a finite state machine that would
> not exit unless instruction test or some defined subset worked. I
> worked a minicomputer instruction set way back and got the fun
> job writing some of the instruction tests. Plenty of coffee and late
> nights. The real task was actually making sure that we could not
> get a false positive and trust a failed computer.

It sounds like that may have actually been somewhat useful.

I can't say the same for the vast majority of the "self test" code
I've seen on micro-controller systems (without any redundancy). The
usual methodology seemd to be:

1) Assume that 99.9%[1] of the hardware works

2) Spend weeks writing code to try to test the remaining .1%

Since there was no way to force failures in the 0.1% you could test,
you never knew if the tests you did write worked.

[1] Or whatever percentage was required to boot up and start running
code.

--
Grant Edwards grant.b.edwards Yow! BARRY ... That was
at the most HEART-WARMING
gmail.com rendition of "I DID IT MY
WAY" I've ever heard!!
From: Theo Markettos on 20 May 2010 20:37
D Yuniskis <not.going.to.be(a)seen.com> wrote:
> Hmmm... ages ago (minicomputer era) we would have test routines
> that exercised each of the instructions and addressing modes in
> a processor. To verify the processor "worked". Back then, the
> processor was many square inches (feet, in many cases!) so
> different parts of the board physically were responsible for
> different features (e.g., you could lose one slice of a register
> file while nothing else was affected in the processor).

Here's a chunk of ARM code, that tested IO on ARM2 and ARM3 (and perhaps
ARM1 too if its origins date back that far, which it might). It's designed
to only use three instructions - ADD, LDR and B - to minimise use of
instructions that haven't been verified yet:

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/OldTestSrc/Attic/ExtIO?rev=4.1.1.1

(If there ever was the processor test mentioned, it never made it to CVS)

Theo
From: Paul E. Bennett on 21 May 2010 14:19
Grant Edwards wrote:

> On 2010-05-20, Paul E. Bennett <Paul_E.Bennett(a)topmail.co.uk> wrote:
>> KK6GM wrote:
>>
>>> Over at avrfreaks.net the question of periodic instruction set
>>> testing has come up, in particular as a requirement (apparently, it's
>>> not exactly clear) in UL1998. I've never heard of such a thing. Can
>>> anybody tell me anything about this subject, such as, is it actually
>>> done, and if so, how?
>>
>> That takes me back to the mini-computer era. Especially the clients
>> that needed it built into their installation because they wanted to
>> be extremely confident that their system was calculating the right
>> results.
>>
>> It was just a case of checking that all the right flags were set
>> after a specific set of data was put through the instructions.
>
> How do you do that without assuming that instructions are executed
> properly? Is there a second, independantly designed and built
> processor whose results are compared with the first one?
>
> Or is there some reason to beleive that some particular subset of the
> CPU instructions can be relied upon but the rest cannot?

There was always an expectation that you would get a match if the
instruction under test toggled the processor status flags to the expected
particular state and no match would mean there was a problem. There was a
hierarchy of instruction test order and with the processors I was dealing
with you had a few ALU operations to test out first before you started
memory testing. Then would come the more complex instructions.

It was all so long ago and I would be delving into ancient history for the
details (assuming I had kept those particular notes).

--
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett(a)topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Barcode scanner reverse engineering
Next: Advice/info about extracting ROM dump from 20-year-old COPS microcontroller?