Electronic components aging

Did you look at the pictures from the Fukushima nuclear power station control rooms ? The reactors were built in the early 1970's and based on those pictures, original equipment was still used at least in the control room.

The operation license was extended by 10 years, just before the tsunami, so we can just guess, if the original equipment would have been used to end of that period or replaced just for the 10 year extension.

A Canadian nuclear power company just recently tried to hire PDP-11 assembler programmers to keep some auxiliary systems running until

One reason for using very old systems in heavy industry is the certification process, which would have to be done for each replaced system.

In some cases the requirements have become harder, but some old systems might be accepted with those historical requirements. Thus the owner tries to keep the old system running as long as possible with small incremental replacements but still remaining within the original requirements and certification.

US military is interested in 6502 programmers. 8085 is offered in a rad-hardened version. etc. This when folks are walking around with thousands of times the processing power in their phones! :-/

Until recently, I kept a 9-track tape operational, here, to support some legacy products (can you spell "boat anchor"?)

It's not just certification but, often, the molasses pace that acquisition processes move in some industries. E.g., when I visited the Cheyenne Mountain Complex, they were installing computers they had ordered 10 *years* earlier! (Um, doesn't that make them *inherently* obsolete? And, these are what is protecting us from The Russkies??)

Witness the exorbitant prices some folks want for ancient hardware.

One firm I worked at was scurrying to find Apple ]['s in order to keep producing a product senselessly based on that platform. I wonder if the customers paying $30K+ realized the Apple therein was acquired at a garage sale, etc. :-(

I worked on a "tester" for *core* memory for a US bomber in the late 70's. Core? WTF?? (actually, there are good reasons to use core -- size NOT being one of them!)

I have some JAN microminiature tubes of recent production. Good reasons, yes... just not many! ;-)

Tim

They are also used in ASIC, simple cores with low Qs. 4000 for 6502. 6000 for 8085. A modern chip like ARM7 needs at least 700,000 transistors. I am looking into a mid range core like BM32, around 200,000 Q, 32 bits C machine.

Why? Qs are free. Pins are expensive.

But they are better used elsewhere. Qs also complicates the synthesizer and often runs into tool limits. I don't need VM, pipelines, predictive branchings, etc., just bare bone C machine.

Synthesizer? Tool limits? Are you trying to reinvent the wheel on a shoestring? Why would you bother? It's all been done for you and it's cheap. An M0 goes for about halfa buck, these days.

Yup. And *most* applications really don't tax their processor. Esp if you take advantage of smaller geometries/fabs to increase clock speeds on those older designs. Having the real estate to devote to other "non CPU" functionality is usually a bigger win -- esp if it eliminates another package or three! (and, consequently, cuts power dissipation by eliminating sets of pad drivers -- or, lets you move to an even smaller package!)

Aside from address manipulation, think of how often your 32b register is processing 8 or 16 bit values!

Many small processors could really benefit from larger address spaces -- bigger TEXT and/or DATA -- esp if these could coexist on the same die as the processor.

I particularly favor good counter/timer modules. With just a few "little" features you can enhance a tiny processor's capabilities far beyond what a larger, "bloated" processor could do (e.g., effectively trim interrupt latencies to *0* in certain classes of problems).

"Newer is always better", right? :-/

I remember the first semiconductor memory boards we used in Nova2's (or maybe 3's?). Really cool to see all those (identical) chips in neat rows and columns (I think it was 4K on a 16x16 board?).

But, it was *really* disappointing to "discover" (d'uh!) that the machine no longer could *retain* it's program image in the absence of power! Every startup now required IPL from secondary storage. From the user's standpoint: "Gee, that sucks! Now, tell me again, why is this an IMPROVEMENT??"

Can you get one as a "soft core" though? One you can integrate as part of the firmware on a FPGA?

Without paying the million dollar license that is.

Let say for prototyping, XC6SLX9, since they have a cheap enough startup to ol package. However, the LX9 can only implement around 100K Q, not even a bare bond BM32. We can probably strip some instructions such as floating p oint multiple and division.

We need 32 bits data, perhaps 24 bits address.

Yes, that what we are trying to find. The right soft core on the right FPG A.

For example:

BM32 is a 32 bits CPU with 16 registers. First 9 are general purpose. Oth ers are special registers such as AP, FP, SP, PC, PSW and PCB. I don't thi nk we need the Process Control Block pointer, so we will change it to Port Control Block pointer. Any port I/O should be relative to the PCB pointer. AP & FP could be general pointers as well.

R0-R8:GP R9:FP R10:AP R11:PSW R12:SP R13:PCB R14:ISP R15:PC

Immediate Mode MOVW &0x12345678,% r2 84 4F 78 56 34 12 42

Deferred Displacement Mode MOVB *0x30(% r2),% r3 87 D2 30 43

Not for $.50 worth of FPGA fabric.

No.

It's a loser, all the way around. You might find an acceptable hard core but soft cores are a loser, for many reasons.

Speaking of which, what IS available in off-the-shelf counter/timer support? I've still got a few DAQ cards with AMD's 9513 counter chips, which I KNOW are obsolete, but what's the modern replacement?

The 9513 had five 16-bit counters, lots of modes, and topped out at 10 MHz; you could make an 80-bit counter, and test it once during the next many-lifetimes-of-the-universe.

I don't think there is a "free-standing" counter/timer "chip". Nowadays, most MCUs have counters of varying degrees of capability/buginess built in. So, we're supposed to learn to live with .

But many of its modes were silly. I.e., configuring it as a time-of-day clock/calendar? Sheesh! What idiot decided that a MICROPROCESSOR PERIPHERAL needed that capability? Can you spell "software"?

It also had some funky bugs, was a *huge* die (for its time and functionality), etc.

A lot of counter/timers are really "uninspired" designs, lately. Its as if the designer had *one* idea about how it should be used and that's how you're going to use it!

The Z80's CTC, crippled as it was (not bad for that era), could be coaxed to add significant value -- if you thought carefully about how you *used* it!

E.g., you could set it up to "count down once armed", initialize the "count" to 1 (so, it "times out" almost immediately after being armed), set it to arm on a rising (or falling) edge AND PRELOAD THE NEXT COUNT VALUE AS '00' (along with picking an appropriate prescaler and enabling that interrupt source)

As a result, when the desired edge comes along, the timer arms at that instant (neglecting synchronization issues). Then, "one" cycle (depends on prescaler) later, it times out and generates an interrupt. I.e., you now effectively have an edge triggered interrupt input -- but one that has a FIXED, built-in latency before it is signalled to the processor.

The magic happens when the counter reloads on this timeout and, instead of reloading with '1', uses that nice *big* number that you preloaded in the "reload register". AND, STARTS COUNTING that very same timebase!

So, when your ISR comes along, it can read the current count and know exactly how long ago (to the precision of the timebase) the actual edge event occurred. EVEN IF THE PROCESSOR HAD INTERRUPTS DISABLED for a big portion of this time! (or, was busy serving a competing ISR, etc.).

The naive way of doing this would configure the device as a COUNTER, preload the count at '1' and program the input to the desired polarity. One edge comes along, counter hits '0'/terminal_count and generates IRQ. Then, *hopes* you get around to noticing it promptly (or, at least *consistently*).

The "smarter" approach lets you actually measure events with some degree of precision without having to stand on your head trying to keep interrupt latencies down to .

I first designed high reliability products for Aerospace in 1975 using Mil- HBK-217. It was based on generic components with stress factors for environ ment, design stress levels or margin based on actual field reliability data .

It is based on the assumption that the design is defect-free and proven by test validation methods and the material quality is representative of the f ield of data collected, which would be validated by vendor and component q ualification. The overall product would be validated for reliability with Highly Accelerated Stress Screening (HASS) and Life Test (HALT) methods to investigate the weak link in the design or component.

Failures in Test (FIT) must be fixed by design to prevent future occurrence s and MTBF hours are recorded with confidence rates.

The only thing that prevents a design from NOT meeting a 50 yr goal is lack of experience in knowing how to design and verify the above assumptions fo r design , material & process quality.

You have to know how to predict every stress that a product will see, and t est it with an acceptable margin requirement for aging, which means you mus t have the established failure rate of each part.

This means you cannot use new components without an established reliability record. COTS parts must be tested and verified with HALT/HASS methods.

In the end, pre-mature failures occur due to oversights in awareness of bad parts, design or process and the statistical process to measure reliabilit y.

The '217 methodology has been discredited pretty thoroughly since then, though, as has the Arrhenius model for failures. (It's still in use, because the alternative is waiting 50 years, but AFAICT nobody trusts the numbers much. The IBM folks I used to work with sure don't.)

It's pretty silly when your calculation predicts that reliability will go _down_ when you add input protection components or a power supply crowbar.

Cheers

Phil Hobbs

Our gear is, in the field, many times more reliable than 217 or Bellcore calculations, and the failures tend to be point issues, not random component failures. Once noticed, most of the failures can be understood and the products improved. So if our designs were perfect, MTBF would be much better than what we are seeing.

Well....adding parts reduces OVERALL reliability due to the fact they can (and will) fail. Some parts,when they fail can induce spikes or surges that will stress "protected" parts. So, in some (specific) cases it is not silly.