Empowering your hardware engineers

Your new embedded design becomes a reality when the first prototype arrives. This is an exciting time in any design cycle, but it can also be the most stressful. Sleep may not come so easily for the hardware team. When you think about it, the prototype is the realization of a new schematic, a new PCB layout, and a board full of new components. The likelihood of all these new design elements coming together and working out of the box are pretty slim.

Unfortunately today, many hardware engineers will acknowledge that they don’t thoroughly verify a new design. And this may be reflected in an Accenture report stating that the US alone saw $17B in consumer electronic returns in 2011. The reason for the poor verification coverage is generally time pressure and a lack of tools. Poor design verification practices manifest themselves in unexplained system crashes, hardware / software finger pointing, and delayed releases. It may not be surprising that Embedded Market forecasters report 52.1% of all 32 bit designs were behind schedule last year.

The fundamental problem is that there is a lack of hardware verification processes and tools for boards.  The development process moves from design to hardware / software integration, bypassing the critical hardware verification step. It is time to empower the hardware design team with the tools needed to confidently release prototypes to the software team, as well as releasing a design into production. A verification process will also eliminate the cost and time associated with unnecessary design spins.

A better prototype experience
When the hardware prototype arrives, the design team typically attempts to boot the application OS (e.g. Linux or Android) after doing some preliminary power and clock checks. The software team needs the prototype running Linux as soon as possible for software development, so what alternative do they have? What if you added a design verification step?

The objective of the prototype design verification process is to prove that the design and implementation (they are different) meet the functional requirements, and are production ready BEFORE final release to the software team, and ultimately manufacturing. With the right tools and process, this step should take less than a week. Trying to accomplish this with the application OS (e.g. Linux) is very challenging given the application OS was never intended for hardware verification. One of the fundamental benefits of an application OS is hardware abstraction, which is counter to the direct hardware access needed for hardware verification.  Another drawback of the application OS is a lack of functional tests and debug capabilities needed by the hardware team. Sure they can be created, but they are an afterthought, and at what cost?  

A better prototype experience would begin with a process with two important milestones: 1) design correctness and 2) production readiness. The process is supported by the tools which provide a functional test suite, direct hardware access, scripting for flexibility, and powerful debug capabilities for fast fault isolation.  Empowering the hardware team with the needed verification tools and processes will ultimately improve hardware quality, time to market, and eliminate the need for unnecessary design spins.

Design correctness
Design correctness is the first milestone verifying the design is logically correct.  Assume there are ten prototype boards.  If one board can pass all the functional tests, then the design is considered “correct”.  That is to say the schematic is correct and the PCB layout does not have any serious issues. That is not to say the design is production ready.

Functional testing is the best way to check out basic operation of the system and each component. Each functional test targets an element of the design. For instance, there are functional tests that cover memory, busses, displays, Ethernet, cameras, FPGAs, etc. A memory test will be comprised of walking 0’s/1’s, address bus, marching, burst, noise, and simultaneous switching output tests. The functional tests are continually improving from design to design so that test confidence is high. Performance tests follow a similar process. Running these throughput tests close to the hardware, as opposed to through the layers of an application OS, will provide more accurate results.

But what if a test fails? The verification tool needs to provide the flexibility to quickly isolate a design flaw. This is where direct hardware access for peeking/poking and scripting are critical. The hardware engineer needs to quickly create and run test variations without the need to generate C code. Using scripting, the engineer can look at the results and iterate quickly, without time-consuming compile and download cycles. Fault isolation in an application OS based environment can be difficult and usually requires pulling software engineers in and away from application development.

Once all the tests pass, the design correctness milestone is achieved.

Production readiness
Now that we are confident that the design is correct, the next step is to test for production readiness.  Remember, at this point we have one prototype fully operational. Now we want to run the remaining boards through a baseline functional test suite that exercises all elements of the board. This will tell us if we have any signal or power integrity issues, or any other marginal design elements. Looping on these tests will stress test the board and possibly expose a thermal problem. The final step in this process is to vary the clocks and power for margin testing. Problems found in this phase may be more difficult to find and fix. This is another instance where a powerful scripting language is necessary. By using a script to loop on a suspected area, while monitoring a temperature sensor or test, the results can quickly expose a marginal design.

Another variable in production readiness testing is fabrication and assembly. Your new design prototype may have some assembly challenges that can impact yields. These will also be exposed by the processes described above. After running the baseline tests, how many of the remaining nine boards passed, and what problems were discovered? You now have the information to update the design and confidently hand it off to software for application development.

Imagine having the right tool for the job...
Imagine having a verification and test OS (VTOS) built specifically for the purpose described above.  It is configurable for your hardware, and can help you verify a new prototype in less than one week. Figure 1 highlights some of the differences between an application OS and VTOS. The differences are striking.


VTOS provides the engineer with a rich and extensible verification environment.  The user executes commands from a PC that is attached directly to the prototype hardware or remotely, via a TCP/IP connection (see Figure 2).  Remote access can be very powerful for environmental chamber testing or running tests from your office with the hardware in the lab. Users can also test multiple prototypes concurrently, easily providing test consistency across all boards.


Commands are driven through an interpreter where functional tests can be executed and modified. The environment enables peeking and poking registers and memory, reading/writing GPIO, tracing test execution and much more. Finding a functional test failure is fast when you have the right tools.  Another capability involves downloading files for execution or writing to memory, including FLASH. If you have an FPGA in your design, you can program it with VTOS by downloading the bit file from the PC, allowing a highly iterative design process. With VTOS, prototype hardware is typically fully verified for design correctness and production readiness in less than one week.

Functional test suite
The functional test suite provides test coverage for SDRAM, FLASH, MMC, Ethernet, audio devices, cameras, displays, EEPROM, GPIO, I2C, power, RTC, sensors, UART, USB and more. The test coverage and effectiveness have grown over the verification of hundreds of new designs.

The hierarchical structure of the test suite allows for easy test creation and modification. The basic building block is a Low-level Command.  In the case of memory, it might involve clearing a single bit in memory. The next layer, which is Test Methods, builds upon the low-level commands. The Test Method could be a memory test march with a starting and ending address. Next is the Diagnostic Test that could include a burst access memory test. The top level is a Suite that combines a number of diagnostics for the specific purpose of a quick test versus comprehensive memory test.

Through scripting, a user can combine tests, changes test ranges, etc., at run time and without recompiling.  Scripting is also used to create the baseline quality test so you can test a board with the execution of a single command. This is a very powerful feature for “change testing” that can be used throughout the life of the hardware.

Device driver scripting
A major advantage of VTOS over Linux is simple device drivers.  VTOS device drivers are built to test basic device operation. This simplifies the task of creating a device driver dramatically.  With VTOS, the device driver can first be built in a script that allows for a highly iterative process of change and test – no compilation required. Once device operation is verified with the script, the steps can be easily moved to C and compiled into VTOS.

The functional test suite is applicable to new devices.  Let’s say you are using a brand new Ethernet chip that needs a device driver. After creating the VTOS device driver, you can immediately run the entire Ethernet functional test suite against the new part.  You immediately get the benefit of hundreds of tests.  New devices can be quickly verified against a proven functional test suite.

Empower the hardware engineer
With the current approach, engineers don’t have the time or the tools to thoroughly verify a new design and its implementation. Marginal hardware is commonly released to the software team.

Empower the hardware engineer with the right tools and processes for a critical design phase – the arrival of the prototype.  Implementing a design verification process based on a verification and test OS (VTOS), new designs can typically be verified in a week or less. Problems can be quickly isolated and fixed. The design can then be quickly tested for production readiness, improving manufacturing yields and product reliability. VTOS also transitions easily to the production floor, saving test development costs. Eliminate the stress and sleepless nights associated with the arrival of a new prototype.

About the author
Bob Potock is Vice President of Marketing at Kozio (www.kozio.com). Bob joined Kozio in 2011, bringing over 20 years of marketing and product management experience in the electronic design automation (EDA) industry.

Bob has held positions in engineering, product management, and marketing at companies that include Altium, Mentor Graphics, AT&T Bell Labs, Intel, and Burroughs. Prior to joining Kozio, Bob was Director of Marketing at Altium Inc.  Bob holds a BSEE from Case Western Reserve University and an MBA from Regis University.