Heard at ESC: Programmable analog ICs find a home in TCA system management

A number of configurable mixed-signal chips have come on the market in recent years, including those from Actel, Cypress Semiconductor, and Anadigm. Early on, these all tended to end up in the hands of experimenters. But of late, vendors have started to provide reference designs that slip these unique parts into specific applications, such as sensor conditioning, touch-panel interfacing, and the like. One such example, a growing relationship between Actel’s Fusion parts and the TCA community, may turn out to be the most technically interesting of the lot.

If you are not familiar with it, the Actel Fusion device combines a relatively conventional high-performance FPGA with a configurable array of parameterizable analog components. There is a substantial amount of on-chip Flash memory, and either of two ARM processors—the Cortex M1 or the ARM 7—can be implemented in the logic array. Perhaps through serendipity as much as clever planning, this combination of resources turns out to be just about right for implementing the system management functions specified in various versions of the Telecommunications Computing Architecture (TCA) standards.

At ESC, Actel and Pigeon Point Systems, a noted supplier of software for TCA system management, announced an agreement to cooperate on implementing TCA system management on the Actel Fusion devices. For designers of microTCA and Advanced TCA boards, this promises to offer a drop-in solution to a significantly thorny design problem. For SoC designers, it offers a window into an issue that increasingly they must face at the chip level: just how do you perform system management functions when the system—employing dynamic voltage-frequency scaling, power and clock gating, perhaps hot-swapping, and certainly failure recovery—is on a single chip?

The basic hardware layer of the problem is not that hard to specify. You have to be able to monitor analog quantities, such as supply voltages and currents, package or block temperatures, and perhaps shock or orientation, that define the physical state of the system. You have to have enough memory and computing resources to make accurate decisions based on this data. And you have to be able to control the digital and analog signals that manage the state of the system: standby pins, voltage set-points, alarms, cooling energy, check-point sequences and the like.

But Actel VP for systems solutions Yankin Tanurhan observes that the problem is more interesting than just a discussion of the hardware resources might suggest. He suggests that in addition to routine monitoring and energy management responsibilities, there are at least three levels of failure-related system management to think about. The base level comprises alerts and data logging, so that the user knows the system is failing and has a trail of bits leading to the misfortune. This in itself can require considerable local resources, since the middle of a system failure is not the best time to rely on a system CPU to provide back-up data and attempt a recovery.

At a deeper level, Tanurhan says, system management should attempt diagnosis. This can require both more computing resources and deeper access into the system. In the TCA world, it can mean access to the scan and BiST capabilities of individual chips on a board. In the SoC world, it can mean integration of system management blocks with the hardware test and diagnosis provisions at a very fine-grained level.

Finally, Tanurhan says, there is a level of system management that is still very much in the research phase, even for stable standards such as TCA. That is failure prediction. This means identifying plausible failure modes, characterizing them as the end-points of processes, rather than as discrete events, and finding system variables that reflect these failure processes, predicting a problem before the system actually fails.

Clearly this involves even deeper access to system variables, and enough computing power in the system management hardware to model and monitor complex processes. It also implies a detailed knowledge of system reliability—a level that may be more familiar to SoC reliability engineers than to rack-level systems folks. But in any environment, tying reliability data, failure models, and system monitoring into a predictive model is a goal more than a fact.

As an interesting side-light, in most systems the knowledge of failure modes grows over time. This suggests that it will be necessary to update a predictive system management block periodically. In the TCA environment, this is good news for Actel, which has figured out how to use the TCA remote software maintenance facility to reconfigure the Fusion FPGAs. In the SoC world, the implications are less clear, but just as interesting.