A test-event module is a function that implements a specific semiconductor device test or event, usually using a set of randomly generated test parameters. The stress-test framework itself doesn't test any chip functionality, but it allows test-event modules that do to be plugged into it.
Best cpu stress test software#
The stress-test framework uses this same idea by providing a software engine to handle the stress test's basic execution and common functionality. An application hooks into the framework using a well-defined interface. Software frameworks are used to ease development of specific types of applications by providing a common execution engine and environment for them. Although I don't provide the complete framework, what's here should stimulate ideas for building your own stress-test framework. The remainder of this article describes the design of a software framework that you can use to build an expandable stress-test for a semiconductor device. This is where a stress-test framework comes in. Meeting these goals takes careful thought and planning.
Best cpu stress test code#
The trick, however, is to contain this wild side of the test in an organized manner so that you have reliable test code that's expandable and that aids in debugging as much as possible. The overall goal of the test is to uncover system-level interaction problems in the chip, and to do that, we must mix things up and cause many different events to occur with random patterns of operation.
Ideally, we want to avoid both of these extremes. The purpose of the test after all is to test the semiconductor device design, not to have stable test software. This conservative coding resulted in great test stability, but it also turned out to be no better at finding chip problems than a directed test since it was running tests in too much of a predictable sequential manner. Randomly selected test functions took turns running and interrupts were locked out at lots of points to avoid software conflicts along with other safeguards. My next attempt was to develop stress-test software that was extremely organized. The resulting intermittent failures were time consuming to debug. Or, for example, one test started at random changed the state of a general-purpose I/O that another test was using for a different purpose. Test functions in my test interfered with each other by sometimes using the same memory regions or peripheral resources. I quickly realized that although I was finding many problems, they were mostly in my own software! As I thought of more ideas to introduce chaotic and random events to the chip, I added them to the code. I used timer interrupts and had them run random tests while the main program was copying stuff around and starting other chip operations haphazardly, without much upfront planning. If these problems are excessive (or just rare in mission critical products) your product will have a reputation of unreliability or even instability.ĭuring my initial attempt to create a system stress test, my method was to dive in and write software that directly activated all the chip functions I could and have them execute at the same time. These problems usually manifest themselves as occasional lock-ups, data corruption, or other hard to reproduce anomalies.
With so much use, problems can be encountered when certain sequences and combinations of functions and events on the chip occur that have never been exercised in device testing. In turn, these electronic products will be used by thousands, even millions, of people each using the product differently. Why is stress testing so important for semiconductor designs? To illustrate, let's assume that it's common for a semiconductor device to be deployed in a variety of electronic systems with varying purposes. Using these tests, you can force lurking system problems to happen rather quickly before your product is shipped. These tests are normally run continuously and mostly unattended including on nights and weekends. In this case, stress testing consists of executing diagnostics software whose purpose is to get as many functions of the chip operating at one time in a continuous, intense, and random manner that greatly exceeds what occurs through normal use of the chip. The same concept applies to a chip design.
0 kommentar(er)
