Why Trust your Chip Success to an Afterthought?

At a recent DesignCon, I attended the panel, “The Same Chip Killers Keep Delaying Your Schedules – What Are You Doing About It?” consisting of Ed Sperling (Moderator/System-Level Design), John Busco (NVIDIA), Ravi Damaraju (Juniper Networks), Ramon Macias (NetLogic Microsystems), Sunil Malkani (Broadcom), and Bernard Murphy (Atrenta Inc).

I saw two common themes that I have observed at DAC, DVCon, and other hardware-focused conferences:

• Verification and system integration are a big portion of the development costs; we need more focus in those areas.
• EDA tools need to get even better and do more.

Verification and system integration are downstream in the design life cycle. Why is the focus there and not upstream during planning, architecting, and design? That’s like going to a doctor wanting a fix for your poor health while ignoring the fact that you are smoking, not eating right, and not exercising. There is more that can be done upstream in the design life cycle to reduce the burden on verification and system integration.

EDA tools are getting more complex, making them harder to learn, understand, and use all their capabilities. Enhancing them to do even more makes the situation worse. There is more that can be done to improve the methodology of how we use existing tools which will improve the design.

But the big eye-opening statement from the panel…, well actually it was two statements that, when put together, had a disturbing implication. One panelist (I don’t remember which) said that with regards to hardware design, too often software is an afterthought. Less then five minutes later, another panelist (again, I don’t remember which one) said that with regards to dealing with defects in the chip, software is a safety net allowing them to ship defective chips by using software workarounds. Why are companies risking the success of their product/company to an afterthought?

The industry is slowly turning in the right direction. Cadence’s EDA360 vision advocates having software dictate hardware design instead of leaving software to an afterthought. Walden Rhines, CEO of Mentor Graphics, has discussed the importance of ESL design tools to prototype system-level behavior before committing designs to silicon.

But this system-level view is not new to me. I have reaped the benefits of having implemented a combined hardware and software effort that is more unified and upstream-focused. My clients, attendees, and readers tell me how my concepts have been of value to them. The proof is out there. Focus on system-level and upstream efforts. Don’t let your safety net be an afterthought.

Being a Green Programmer

Much of what I read about Green Design involves building the product with recycled or renewable materials and consumables, and making the product recyclable at the end of its life. Hardware engineers can contribute to the green effort by influencing how the product is made and what it is made of. But what about software and firmware engineers? Their end product is a bunch of intangible bits flowing through hardware. Those bits don’t pollute the environment or end up in landfills. So how can they be green in their designs?

I came across the answer while reading about industrial designer Gadi Amit’s unusual approach to Green Design: make products so desirable that people just won’t want to throw them away. (Sacks, Danielle. “What’s Wrong With Green Design.” Fast Company Oct. 2010: 166-69. FastCompany.com. 1 Oct. 2010. http://www.fastcompany.com/magazine/149/whats-wrong-with-green-design.html.) Amit gave an example that the 8-year-old Palm Zire is still used today because it works well and people have an emotional connection with it. He then observed that in contrast, PCs at first work fast, but after a while get bogged down with old programs, temporary files, and bloated registries. Users often get so frustrated with their slow machines that they simply buy new ones and throw away the old.

In other words, Amit is encouraging us to make the product function so well that users will not want to throw it away. What a novel and green concept! Let me cite two examples from Hewlett-Packard.

The Hewlett-Packard 12C financial calculator was green before green was mainstreamed. It was introduced in 1981 and is still being sold in stores today, 29 years later. It is a well-designed product that well suits the financial community. HP did not set out to design a green financial calculator; they set out to design a top-notch calculator that exceeds the needs of their customers.

Several years ago while I was working in HP’s LaserJet printer design lab, management focused on a problem of decreasing sales. Research showed that the market was fairly well saturated and that the existing LaserJet customers would not buy new LaserJet printers because their old LaserJet printers were still working just fine. HP LaserJet printers were, in a sense, green because customers were happy to keep them longer before throwing them away.

What about your products? Are you working with customers to make sure you are producing what they want? Are you designing your software and firmware to the best of your ability? Producing top quality software and firmware that does what customers want should be part of an overall green strategy. But, you might say, those efforts will likely take longer and result in a more costly product. However, as Gadi said, “…more expensive objects … will create the economy and the justification to slow down the cycle of obsolescence.”

Of course, our efforts at Green Design might quickly bump into the pressures of fast-changing technology, marketing-induced consumer appetites for the latest and greatest gadgets, and business demands for steady or increasing revenue streams, but this is a topic for someone on the business side of technology to discuss. For now, think green and produce green code.

Verification: Can We Do More?

A comment in the GABEonEDA blog entry “Accellera Works Toward a Unified Verification Methodology (UVM)” recently caught my attention:

Silicon respins due to design errors not only have not diminished in number, they have actually increased. This is an indication that complexity has grown more than the ability of verification tools to detect errors.

The article continues by discussing the industry effort lead by Accellera and their member companies to improve verification. I attended Accellera’s panel discussion at the recent Design Automation Conference (DAC). DAC’s presentations and products that address verification, as well as other articles and blogs on the subject, illustrate the need in that area.

Verification is just one of many steps in the development life cycle of a product, starting from high-level design, through verification, and on to system test. Tools such as Electronic System Level (ESL) and co-simulations address one or more of these steps, but tools cannot address all concerns.

Effective methodologies, too, are necessary for successful product development. One very important methodology is collaboration between hardware engineers and firmware (embedded software) engineers from the first step to the last, from high-level design to system test. Tools such as virtual prototypes may help engineers collaborate, but tools will not make engineers collaborate.

For example, one infamous collaboration failure was the Mars Climate Orbiter, which crashed because of a metric vs. Imperial units clash between design teams. (More info.) In another notable collaboration failure, Airbus’ A380 jet was two years late and Airbus lost $16 billion because they did not invest to have all collaborating mechanical design teams use the same tool set. (More info, pages 9-13.)

Compared to the costs of such failures, collaborative methodologies can be fairly inexpensive to implement. For example, a collaborative methodology could have firmware team representatives review and sign off on hardware specifications and milestones. I saw how this one change alone saved hundreds of engineering hours and thousands of development money when my previous employer implemented this.

In addition to collaboration, here are a few other examples of methodologies that can support verification by eliminating or mitigating design flaws:

Register Layout Standard: Define and implement the same register layout standard across all blocks and in all chips, allowing leverage of verification modules. A standardized layout should include specifications such as which bits are mixed or separated across registers and how bits and registers should be added or deleted across versions. Not only will following a standard help the verification phase, it will also help firmware engineers write consistent and reusable firmware.

Standard Functionality of Common Modules: Define how an interrupt module or a DMA module behaves and use that behavior consistently throughout all blocks and across all chips. Where possible, use the same source files and instantiate them everywhere to minimize entry of defects. A standard verification suite for these common modules can then verify the functionality of all instantiations of that module.

Standard Documentation Format: Use the same standard document format and style for all blocks on all chips. The standard should entail both the correctness and completeness of documentation. Verification engineers and firmware engineers rely heavily on this.

Test and Debug Hooks: Allocate silicon space for test and debug hooks accessible through registers and retain those hooks when going to silicon. Errors found during verification can be corrected before tape out, but once in silicon form, corrections require expensive respins. Since we’re all human, design and verification errors cannot always be avoided. But if a test and debug hook left on the silicon allows firmware to work around a hardware problem, then we can eliminate that defect and still avoid a chip respin.

Albert Einstein said, “Intellectuals solve problems; geniuses prevent them.” Verification attempts to find problems after they’re already in the design. However, by implementing methodologies that prevent problems from entering the design in the first place, we can tap into some of that genius Einstein talked about.

Welcome to Hardware/Firmware Interfacings!

Welcome to Hardware/Firmware Interfacings. This blog focuses on interfaces. Primarily, it focuses on the interface between hardware and firmware in an embedded device. In addition, it focuses on the interface between hw and fw engineers developing the embedded device. It also focuses on the interface between customers using the embedded device.

You can find writings by hw engineers talking about hw engineering. You can find writings by fw engineers about fw engineering. But there is very little written about the interface between the two. Virtual prototypes and other similar tools do an excellent job of getting hw and fw engineers working together but if that is the first time they get together in a project, then it is too late. Hw and fw engineers should start collaborating at the beginning of the project, before the hw design is specified.

The goal of this blog is to provide readers with insights to improve the design, development, integration, and customer experience of the hw and fw aspects of embedded devices. Comments to the posts, whether in agreement or contrary, are welcome.

Just for clarification, let me define the term, “firmware.” It is also known as “embedded software” or in other words, it is the software buried in the embedded device that is being executed by an embedded processor that makes the device run. In some segments of the industry, “firmware” refers to the programming code that is downloaded into an FPGA to program the logic of the device. That definition of the term is not used in this blog.

Welcome aboard. See you in future posts.