Sometimes I think we're directionally challenged in test and measurement. For 30 years or more we've clung to an outside-in point of view based on external testers and probes. Over the last few years though, it has become apparent that we can see more when we look from the inside out. Now, it's becoming clearer that T&M is even more powerful when we combine a bottom-up perspective with an inside-out point of view. The visibility into chips, circuit boards, and systems you'll see with these simultaneous perspectives will be, well, eye-opening.
This visibility -- or the lack thereof from the traditional outside-in perspective -- is turning T&M on its head. You see, chip, circuit board, and system designers are finding it increasingly difficult to migrate their work out of the design department and into manufacturing. What's holding them back is prototype bring-up.
Before a new product design can be released to manufacturing, developers must be able to say that it works the way it's supposed to. That requires validating and testing the hardware, and debugging the firmware that interfaces the hardware to the operating system and applications. That hardware/firmware interface is a critical plane in a system's hierarchical architecture. Given the trajectory of technology, the need for greater visibility at this juncture in the system will only increase over time as the sheer volume of firmware increases and as physical access to hardware diminishes.
Firmware: It's everywhere!
There seems to be no end to the number of general-purpose processing cores, embedded processors, digital signal processors, I/O cores, and other specialized processing elements being designed into systems. In addition, more on-chip intellectual property (IP) is being integrated into SoCs than ever before. Surely this will only continue to expand. What binds all of this together is firmware. If current trends are any indication, firmware will continue along this explosive track for several years to come.
Inside-out hardware visibility
Of course, testing would be exceedingly more powerful if greater visibility into firmware debug could be complemented by increased visibility into the hardware as well. Fortunately, it's happening. With tools based on instruments embedded in chips, designers can regain the access to hardware they've lost as probe access has disappeared.
For example, designers have come to the conclusion that test points on high-speed serial buses cause too many signal integrity problems. The result: Get rid of them entirely! And remember those pins on chips that once could be probed? They're gone, hidden underneath the silicon, or they're too small to be probed. That's why debug, validation, and test tools based on embedded instruments are becoming so critical. Through soft access, developers can debug hardware from the inside out and not worry about the absence of probe access from the outside in.
New methodologies for new visibility
Clearly, software debug and hardware validation/test have a lot in common. Looking at them together as integral parts of the same process, we can see the emergence of new holistic methodologies that speed up prototype bring-up and deliver new products to market faster.
An example use case might illustrate this point better. To get projects out on time, software and hardware engineering know they need to stop the finger-pointing and start working together. New debug, validation, and test methodologies would help because both disciplines can leverage the expertise of the other without individual engineers climbing a steep learning curve to become an expert in the other's discipline.
So, for example, a software engineer wants to collaborate with his hardware colleague, but he doesn't have the time or inclination to become a hardware expert. With a prototype bring-up methodology that integrates both a hardware and a software perspective, the software engineer can leverage his colleague's hardware knowledge by deploying simple push-button tests that rule out hardware-based discontinuities between the firmware and hardware or faults in the underlying hardware.
The task of system debug -- which is the ultimate goal -- is optimized by limiting and focusing the investigation immediately. The real cause of the bug is found quickly with less effort and the system moves into manufacturing sooner.
The historic silos differentiating software debug from hardware validation/test are rapidly fraying around the edges. They have to. Performing each one sequentially is too slow, and we know it doesn't work very well. Been there, done that.
Systems comprise both hardware and software, so why not debug both together? Why not debug the system, not the pieces that make it up? Doing both as part of the same methodology is the fastest and most effective way for developers to deliver their designs to manufacturing and the marketplace.