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?
Minicomputers used to have instruction set diagnostics. They were rarely used since most instruction set failures resulted in a machine that could neither load nor run the diagnostic.
OTOH, memory and peripheral diagnostics were often used.
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! :>
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.
This might also be useful where writeable control stores are in use and you need verification they have been written correctly.
--
******************************************************************** Paul E. Bennett............... Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA.
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!
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.
>
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
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!!
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:
(If there ever was the processor test mentioned, it never made it to CVS)
Theo
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............... Forth based HIDECS Consultancy Mob: +44 (0)7811-639972 Tel: +44 (0)1235-510979 Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
KK6GM schrieb:
Reminds me of the "DIAGNOSTIC PROGRAM" card which whas contained in the standard pac for the programmable HP 67 and HP 97 calculator. It helped me when I wrote an HP 67 simulator for my late TI Avigo (now ported to a Palm Tungsten and still in use :-) )
-- Dirk
To the best of my knowledge this is not a UL1998 requirement. A similar concept comes up in IEC-61508 on "single channel" computers, but this is CPU testing, not specifically instruction set testing. Single channel in this case refers to products containing only a single CPU. For products needing high levels of criticality dual cpus are usually used. One acting as a sophisticated watch dog on the main CPU.
More than instructions, CPU testing is typically looking for failures in bits in registers. A technique similar to memory testing is used at the register level.
-- Scott Validated Software Lafayette, CO __________ Information from ESET NOD32 Antivirus, version of virus signature database 5169 (20100603) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
There are a variety of ways to produce a reliable computer. I do a lot of work with automotive processors. The processors need to work over a wide temperature range and in some very bad electrical environments (think of the transients while starting a cold engine)
Part of the solution is processors that have error correcting registers. We are finding that some of the processors used in automotive are finding uses in other fields simply for the reliable operation.
Regards,
w..
-- Walter Banks Byte Craft Limited
When I worked on the Canadarm2 (the robotic manipulator on the International Space Station) there was a requirement that the CPU self-exercise the instruction set periodically. There was a redundant processor so the execution could be switched. I am pretty sure that this is common in space applications although I don't know if there is a MIL-STD or NASA standard that covers it.
I only worked with the requirements so I am not sure how it was implemented especially since I was laid off when times got tight.
-Aubrey
--------------------------------------- Posted through
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.