Today’s digital devices are ever so configurable. In days
past, a device with 100-200 registers to configure in a design was considered
large. By today’s standards, this is tiny. Many technical reference manuals on
a single device exceed 3,000 pages and many of these pages are devoted to the configurability
of the part. Chapter upon chapter in these massive tomes describe every possible
bit and every conceivable configuration option.
And then there are the test engineering departments that
take pride in understanding all of the functional code that the designers and
software engineers have developed for a given part on a particular design. Or,
there’s the opposite school of thought that believes that the test engineer should
start with the test specification and write his own test code without looking
at any test software developed previously. In the end, we labor over functional
test and diagnostic code that often never sees daylight beyond the
manufacturing test floor.
Of course, we also spend a lot of time developing test code
for designs where device-specific functional diagnostics is absolutely
necessary. In particular, this is the case for designs that feature FPGAs or
ASICs. Device knowledge is critical even if the diagnostic code is only used on the production floor and nowhere else.
Where’s the value to
your customer?
When you come right down to it, we spend too many days/nights, weeks and weekends
writing code for device configuration, production test and system test. The
question I’d like to raise is: What is the value of these home grown tests? Do
they provide intrinsic and tangible value to your end customer? Does your end
customer value or pay more for your products because of all the effort you’ve
put into coding tests when there are alternatives that will save a tremendous
amount of time and money? Or, do we develop these test routines just because that’s
the way we’ve always done it? How much time and effort is spent during test
development only to have the device that triggered all this effort replaced in
the next generation of the design? As we all know, diagnostics and test are very
specific to a particular board design; so, how much re-use of test code do we really
get?
Why not adapt with
the times?
Way back when, we did
all test and diagnostic development in assembly code and scoffed at using C.
But eventually, we caught on to the concepts of abstraction and finally relented.
We started using C. At that point there were tools being developed for
“automatic code generation” and many of us were scared for our jobs and scoffed
at the idea and the technology. In spite of the best efforts of companies like
Hewlett-Packard that championed such tools, they were weakly adopted across the
industry. In the end though, the language development community saw something
here. Eventually, C++ and C# were introduced and they took code structure
knowledge to a whole new level. Moreover, tools such as the debuggers that
support certain programming languages got a whole lot more sophisticated.
So technology progresses and we, as engineers, must learn and
adapt to the changes progress brings. In fact, we have adapted in some areas,
but in others we still cling to NIH (not
invented here). Nowhere is this truer than with the development of test and
diagnostics. This is especially hard to understand when you realize that there
are companies that build effective and efficient test and diagnostic development
tools based on device-specific models. Using these sorts of tools is much more
cost effective in dollars and time spent vs. coding your own tests from scratch.
Besides, no sooner will you develop test code for a certain
device than a new generation of the device will come out. Technology is
advancing at an unprecedented rate. The number of new devices introduced every
year is mind boggling. For example, new CPUs, which you might consider the most
comprehensive type of device and the most configurable, now come on the market
every 18 months or less. How do you keep up with that? It’s time to adapt and concentrate
on differentiating your product on features and capabilities, not on an area
like production test and diagnostics that your customer
rarely, if ever, considers. Reducing the time you spend on test and diagnostics
– even when they are device-specific – is easier than you think. You owe it to
yourself to check out model-based tools like Processor-Controlled Test (PCT) the
next time you’re faced with re-inventing the test wheel. Take a look at PCT’s
test development capabilities.
