Periodic instruction set testing - done it? heard of it? [Embedded]

Prev: Barcode scanner reverse engineering
Next: Advice/info about extracting ROM dump from 20-year-old COPS microcontroller?

From: KK6GM on 19 May 2010 16:51

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?

From: Jim Stewart on 19 May 2010 17:45

From: D Yuniskis on 19 May 2010 19:03

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?

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).

This was highly processor specific. It was a bit of an art form to
figure out which instructions to test first and (theoretcially)
build on knowledge of their "success" to test more complex
instructions -- based on which resources were called into
play for each opcode, etc.

Likewise, you verified a small region of memory as "functional"
before using it *in* your tests (after all, if you can't
reliably store temorary data used by your tests, how can you
expect to test anything?).

The same sort of things applied to testing memory. E.g., you
would test core planes doing *multiple* reads of each location
(since a core has to be rewritten once it is read -- to restore
the data that was *read*!). With the advent of semiconductor
memory, you also would test the refresh logic to verify that
the devices could remember *really* instead of just
"temporarily" (nowadays, good CMOS memory testing should
do likewise).

I haven't seen anything like this done since the ~1980.

OTOH, I always build comprehensive test suites that run at
POST (as well as "continuously, in the background") for any
peripheral logic tied to a processor. Here, the assumption
is similar to that used in testing the original *large*
CPU's -- a peripheral device (external to the processor)
can have failed without its effects influencing the
processor per se.

How exhaustively you do this depends on the type of market
you are addressing, the budget (NRE + RE + DM + DL) you have
and your expectations of the product. And, what do you
think you are going to do if the hardware tests as "FAIL"?
How do you tell the user -- given that you "know" you are
broken (i.e., how do you know that you will be able to
RELIABLY convey this information to the user? :> )

In critical applications, if my code discovers /* CAN'T HAPPEN */
actually *has* happened, it just locks up *hard* and hopes that
hardware failsafes (watchdogs) bring the system to a safe state.
Doing otherwise could just as easily *cause* a problem!

I suspect with modern geometries getting so d*mn tiny, there
is probably a concern that flaws can "grow" over time. And,
other external conditions could affect the operation of the
processor subtly (i.e., a sagging supply).

Of course, it is possible that they mean something entirely
different in their discussions! :>

From: Paul E. Bennett on 20 May 2010 13:26

From: Grant Edwards on 20 May 2010 14:14

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?

--
Grant Edwards grant.b.edwards Yow! Hey, waiter! I want
at a NEW SHIRT and a PONY TAIL
gmail.com with lemon sauce!

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