From zero to success in 12 months

Newton, MA— "When I hear about first-pass success for a new chip, it's usually baloney and I tune it out," said Mike Goldman, director of hardware engineering at ChipWrights and a 30-year veteran of the semiconductor business. But in the case of ChipWrights, the claim of such success isn't lunch meat of dubious composition. For its debut digital-signal processor (DSP), the CW4011, the company raced from design to working first silicon in just 12 months, and it achieved working silicon for a follow-on version, the CW4511, just five months after the start of the design.

ChipWrights pursued such challenging development schedules in an effort to hit what it saw as a window of opportunity in a market with huge growth potential—DSPs designed specifically for image-processing applications in mobile consumer electronics. "Most general-purpose DSPs are designed for communications applications," said John Redford, chief technical officer at ChipWrights. "They don't exploit the parallelism possible in image processing because that's harder to find in communications." Redford saw that a new DSP architecture could apply techniques from vector architectures to get high performance while meeting the low cost and low power needs of portable image-processing devices.

Clockwise from left: Joel Turner, director of software engineering; Mike Goldman, director of hardware engineering; and Matt Moniz, principal engineer.

ChipWrights is targeting the CW4511 for use in digital cameras. Camera manufacturers have traditionally handled image processing with custom chips or commercial fixed-function ASICs. Unlike these chips, the CW4x11 series is fully programmable, so camera manufacturers don't need a new chip when they want to change the features of their products—they simply reprogram the chip. They also can implement their own image-processing algorithms, gain the time-to-market advantages of code and design re-use, and protect their investment when imaging standards change. Furthermore, the chip's embedded RISC processor can perform control functions, eliminating the need for a separate CPU.

"Our window of opportunity for the chip was narrow," stated Pat Chiumiento, ChipWrights' VP of sales and a company founder. "We saw that no general-purpose DSP met the camera market's requirements for performance, price, and power consumption. Our architecture met those requirements, and added another 'P,' programmability."

Talks with potential customers validated Redford's vision of a need for a high-performance, low-power image-processing chip. Shortly after these talks, representatives of ChipWrights went to Japan to secure a partner who would design the chip into one of its products. That accomplished, the challenge became to quickly bring the architecture into reality as a high-quality chip with a complete software tool-set so new customers could easily incorporate the chip into their products.

"We made promises to potential customers we knew we could keep," Chiumiento added, "and they'd still roll their eyes. But we had confidence in our design and test engineers and in the total methodology of our organization."

ChipWrights' engineering approach relies on careful planning and on an almost military level of discipline in adhering to that plan throughout the specification, development, and verification cycle. Central to the process, according to Dawn Fitzgerald, VP of engineering and a ChipWrights founder, is teamwork and documentation. "It's key to have the right process in place at the right time, and the entire team must understand and accept the importance of capturing customer requirements and of documentation. The team has to have the discipline to document what will be built, how it will be tested, what procedures will be used, and each and every change along the way."

At the same time, said Fitzgerald, everyone in the process must look to the "voice of the customer" for guidance. All involved must keep in mind the customer's carefully documented requirements. Those requirements serve as a reference against which the ChipWrights' engineers must judge all specification, design, implementation, and verification decisions. "All of the founders took this view," noted Fitzgerald. "Once you truly commit to this viewpoint, it becomes contagious and can be brought to the entire organization."

To ensure its products meet customer requirements, the ChipWrights team reviews functional specifications across workgroups, including the design, verification, documentation, marketing, and software groups. All are encouraged to give feedback. After the review, the design and verification engineers work closely together, assigned as equals to projects, co-owning each module of the final chip. "There is a balance here," noted Fitzgerald. "Design and verification have equal weight in the process. We look at hardware and software as a system, and it is the same for design and verification. And both teams must make sure that their work is constantly checked against customer requirements. If the customer doesn't get what it wants, we lose."

The CW4511 eight-data-path SOC includes a fast RISC serial processor and extensive interfaces to support such feature as buttons, flash units, and LCDs.

Matt Moniz, principal engineer and head of ChipWrights' hardware verification effort, said, "We're starting with the same functional spec as the design engineers. We're involved at the very beginning exactly for that reason." After this point, however, Moniz sees the importance of disconnecting from the design team to some extent. "You work hard together at the beginning of the project to define how the chip or a particular block on the chip will work. Then the design team has to go off and figure out how it's going to implement that functionality. The verification team has to go figure out how it's going to prove that that implementation of the functionality is correct."

Naturally, the two groups interpret the same functional specification from two different perspectives, and sometimes they disagree. When the verification team uses vendor models to simulate a device such as an SDRAM interface, simulation tests might not respond as expected. The design may have implemented the interface in accordance with the original spec, but that spec may not accurately describe what the real-world interface needs to do.

Such conflicts may require a change in the original spec. "The key is to keep all the information documented," asserted Moniz. "Any change against the original specification must have a corresponding bug report filed against it."

At ChipWrights, a homegrown bug-tracking system e-mails bug reports to the responsible designer. If it proves out that the design is in error, the changes required are documented in the functional spec, in the test plan, in the updated design code and verification tests, and so on. The changes cascade down through this chain of documentation so that by the time the chip is produced, everyone knows exactly what it does, and the technical publication team has been able to describe its functions accurately. "There's a certain amount of overhead that goes with this," admitted Moniz, "but this is an important piece of the puzzle. With so many groups working independently from a common data point, it's important to make sure everyone knows about it if that data point changes. Otherwise, you might end up with a simulator that does something different from the chip or with tests that check for the wrong condition."

Moniz joined ChipWrights in August 2000, just three months before that autumn's COMDEX show. At the show, ChipWrights was slated to demonstrate a two-data-path DSP implemented in a field-programmable gate array (FPGA) and running a digital still camera. Adding to the pressure was the fact that the CW4011 chip was still in the specification stage. The effort to deliver on time required a handful of engineers from different backgrounds, who had never worked together, to develop the demo, verify that it worked, verify a new instruction set of about 1200 instructions, write applications for it, create a board to put it on, and ship it out to Las Vegas with sales and marketing people who knew how it worked.

"It was like running into a brick wall," said Moniz. "It was like, what do you do first? How do you break the problem down into small pieces so you can make forward progress on a daily basis? A lot of people worked really hard for those three months, and we delivered. We had the verification done before the design hit the FPGA, and that's the meat and potatoes of what my group does—pre-silicon verification. It [the first silicon] worked, and I think we still have it sitting in a display case somewhere as our first accomplishment." All in all, it took 12 months to go from design to the final chip (in silicon) plus the toolset to go with it. "Having verification early on in the process was crucial to making this happen," noted engineering VP Fitzgerald.

In general, ChipWrights' verification group begins with a focus on developing simple directed tests targeted at particular areas of the design. The first step is to develop pieces of the test bench that represent common functions, such as reading and writing to registers on the chip, getting access to memories, and accessing clocks. Developing the test bench is generally the responsibility of one engineer.

Once this work is complete, the other tasks are assigned to several verification engineers and performed in parallel, typically based on functional groups within the chip, such as I/O blocks, memory interfaces, and DSP blocks. For example, the design team may begin developing a video-input interface while a verification engineer writes a test plan for it and develops a test bench and tests for it. As the design becomes available, the tests are ready to go along with it.

"We've had times," said Moniz, "that the tests have been written and ready to go before the design has been started. This helps the design go much quicker because the designers already have diagnostics and simulations to help them determine whether or not their design is working."

Because the CW4x11 chip is intended as a general-purpose DSP for image processing, it can be dropped into any number of applications (such as digital still cameras, video cameras, and video-editing boards). As a result, the number of possible configurations is large. "One of the things we do," noted Moniz, "is make sure that all the bits that you can flip to make the chip behave differently do what they're supposed to do. That takes up about 60 to 70% of our verification time."

After verification, each verification engineer developed his or her tests in isolation from colleagues working on other aspects of the design. With each individual aspect of the design verified, the next step was to test design blocks as they interact with each other. "We try to get as much going on in the chip at once as is possible, similar to what an application would do," said Moniz. "When the chip ends up in a digital camera, it's throwing info around to all its interfaces. The DSP is fetching code from all sorts of different places, and everything is happening at once. Well, that's what we try to do. And it's been astoundingly successful to date. We had remarkable success with the 4011 right out of the box. We've yet to find any functional problems with the enhancements to the 4011 that became the 4511, and they've been up and running for several months now."