Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > EDA/IP
?
?
EDA/IP??

Equip hardware engineers with right tools, processes

Posted: 13 Aug 2012 ?? ?Print Version ?Bookmark and Share

Keywords:PCB layout? verification and test OS? design process?

Your new embedded design turns to 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 $17 billion 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.

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.

Figure 1: Verification and test OS versus application OS.


1???2?Next Page?Last Page



Article Comments - Equip hardware engineers with right ...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top