IC verification key: ‘Do it step by step, don’t cut corners’
The EDA industry hasn't come up with a silver bullet to reduce the amount of functional verification IC engineers need to perform to get chips out the door in a timely manner, but a DesignCon panel advises adherence to a strict methodology to better your chances of producing chips that avoid respins.
By Michael Santarini, Senior Editor -- EDN, February 8, 2008
The EDA industry hasn’t come up with a silver bullet to reduce the amount of functional verification IC engineers need to perform to get chips out the door in a timely manner, but adherence to a strict methodology can better your chances of producing chips that avoid respins.
That was the main takeaway from a panel simply titled “ASIC Verification,” held Tuesday afternoon at DesignCon 2008.
The panel was moderated by EDA industry analyst Gary Smith. Panelists included Tom Borgstrom, director of solutions marketing at Synopsys; David Garau, senior staff engineer at Teradici Corp; Terry Hulett, vice president of architecture and hardware engineering at NetEffect; and Juergen Jaeger, senior director of ASIC verification marketing at Synplicity.
Smith noted that as a former methodologist at LSI Logic, the designers joked about a rule they called “the three miracle rule.” “If your IC design has no miracles, the product will end up being behind the market,” he said. “If you pull off one miracle, you are going to stay up with the market. If you pull off two miracles, you’ll lead the market. And if you have three miracles you are trying for you’ll probably go out of business.”
The reason is that designers can often design products that are too complex to verify in a timely manner. As part of Borgstrom’s talk, he noted that the verification process can account for anywhere from 30 to 70% of overall IC development time—the actual time it consumes is a subject of great debate—what isn’t is that functional verification takes too long.
Indeed, both Smith's and Borgstrom’s observations seemed to ring true to Hulett and Garau, whom in their presentations both outlined how they deal with verifying complex designs that incorporate new bleeding edge features and are able to get designs out the door in a timely manner but only by sticking to a strict verification methodology.
Hulett said that a key to verifying chips is following a strict methodology and trying not to cut corners. “The key to doing something like this is to do everything in the right order,” he said. “Don’t skip steps, don’t put all your energy into one verification step vs. another. Do everything in the right order and follow the flow.”
Hulett said that for the last 10-Gb Ethernet chip design, which integrated complex functions on a single die, his group wrote a 1200 page specification on how the architecture was going to work internally.
“We did that before we ever wrote a single line of C code for our transaction based model,” he said. After the specification was complete, the company wrote a C based transaction level model. The group then built its verification environment around the C model. It then developed the RTL. The company took on the RTL with two verification testbenches.
“One was a very classic testbench with different layers of complexity and the other defined a decision tree and synthesized test cases off that decision tree,” Hulett continued. “They were two radically different approaches to creating the stimulus, but my reason for doing that was two moth-eaten blankets will keep you much warmer than one moth-eaten blanket. There is no such thing as one verification plan that is going to find every bug. The more ways you can layer it, the better off you are.”
After getting simulation up and running, Hulett’s group used formal verification, specifically 0-In from Mentor, to verify assumptions at the module level of the design. Hulett noted they found a few bugs with the formal tool and a couple would have been show stoppers. After that, the group built from scratch a hardware prototype of the IC on an FPGA-heavy PCB to test the design running in the real world. The group designed a custom card instead of using a commercial prototyping board to make sure the prototype suited the design’s interconnect needs and work in servers.
“We then got our software up and running and in the end, we still ended up with bugs,” Hulett said, noting those bugs weren’t big and it allowed the team to ship first silicon on time.
Hulett said that the approach isn’t unique, but that designers need to be reminded not to get ahead of themselves. “Don’t get your RTL development before you specify what you want to do; don’t try to build your testbenches before you have even written a model of the system behavior you are trying to emulate in your ASICs,” said Hulett. “Do it in the right order and you will end up with success, even if it takes longer than you like.”
Hulett noted that the project took two years to complete and that, in retrospect, one of the things he believes could have been improved was developing the hardware verification prototype. He noted the group started developing the board too early in the design process. Because of this, the group then ran into issues discovering the origins of bugs. Some were in the chip design, but others were caused by the tools they used to program their design into the FPGAs in the prototyping system. But Hulett noted that developing a prototyping system is a very needed step because it allows you to catch bugs in the real world.
Garau’s talk mainly focused on the prototyping board his team developed to verify Teradici’s first chip targeted at “hardware accelerated remote desktops over Ethernet” and how it used the system to catch bugs in the real world. To verify the design, the group built an elaborate verification system to verify the two card system. One card goes into the host PC that is being “remoted,” while the second card goes into the user’s desktop. The company used the same chip for the client and host cards. To prototype, or what Garau called “emulate,” the extremely complex system, the company used a Dini prototyping board as the primary board and added custom cards to handle analog and unique functions. The company built in quite a bit of debugging functionality into the protyping board.
“Despite all the debugging functionality we still had very limited debugging visibility,” said Garau. The company used Synplicity’s Identify product, which is essentially a synthesizable logic analyzer that goes into the FPGA. “However, the memory depth of the tool was somewhat limited, so a lot of times what we were doing was trying to figure out what stimulus we could throw into our verification environment to actually catch bugs in verification,” Garau said.
Garau said it was easy to find bugs with the tool and prototyping system, but it wasn’t easy to pinpoint the location of bugs. “You still need a very good verification testbench in order to find the actual bugs,” he said.
Garau said that with a bit of work they got the platform up and running and caught functional bugs with it.
The prototyping system also helped with other things. “The first one is that it helped us get a head start on firmware development,” said Garau. “Essentially we had a year head start before the actual chip came back so when the silicon came back we were ready to go with actual functional debug firmware, which was a huge plus.”
He said the prototyping system was especially useful in testing the system working with various drivers, operating systems, and peripheral devices like mice, keyboards, and webcams.
“There isn’t a testbench available that can provide that kind of functionality. Even if it could you would have to be simulating for eons. What this allowed us to do was investigate what the different operating systems were doing, what the different platforms were doing and actually tune our algorithms and RTL so we had a functional device. Without the RTL, you are talking a couple of spins, minimum, to just get that information,” Garau said.
Garau noted that for the next chip, the company will likely develop a custom prototyping system instead of using a commercial system so that it can better integrate analog and custom functionality into the system.
