EDA start-up Breker has a plan for better IC verification

By Michael Santarini, Senior Editor -- 5/23/2007

EDA start-up Breker has a plan for better IC verification EDA start-up Breker Verification Systems wants to help you reduce the amount of testbench generation and overall verification you need to do by helping you create a comprehensive IC-verification plan upfront in the functional-verification process and to help you drive better test vectors into your current verification environment. The company calls its first tool, Trek, a graph-based functional-test-synthesis technology.

Breker founder Adnan Hamid, formerly of AMD and Cadence, developed cell-characterization technology while at AMD. Hamid notes that designers spend two-thirds of the design process doing verification and claims that, for every line of RTL code, verification engineers must write 10 lines of verification-testbench code to check that it is functionally correct. Over the years, he’s discovered that a lack of effective planning has caused much of the verification problem. “We have not come up with any rational way to think about how to plan to verify a design, how to capture that plan in some form that is understandable, and then how to get from that to execution,” says Hamid. Many teams today typically create a spreadsheet plan, essentially a laundry list of things that require testing. That method is often error-prone and ineffective. Other design groups have no organized plan, instead using a “spray-and-pray” method in which they simply apply constrained random-test generation using an automated testbench tool. “That whole story is: Throw random numbers at your design and hope that it hits all the corner cases, and, if it doesn’t, then come back and spend a bunch of time incrementing functional coverage points,” says Hamid. He notes that users typically must repeat the process until they think they have it right or tire of doing it. Hamid’s idea with Trek is to help engineers start with the end goal and the end function of the design in mind and then create a plan to meet that goal.

Other companies have tried to create graph-based planners, but the graphs became too big. To solve this problem, Breker applies dependency resolution to graphs, which constrains what a graph can do. “Once you’ve combined dependencies with graphs, you can come up with a process to construct a verification plan that says, ‘Start with the outcome that needs testing and then break that [outcome] down step by step to think about what inputs you need to test that outcome,” he says. This approach lets you express complex verification plans with little code. “We are seeing a 10-times or better reduction in the amount of code we need to write to come up with a graph-based plan versus a traditional testbench,” he says.

Users feed Trek text-based source code or a graphical file—verification IP (intellectual property) or subgraphs that Breker or the user develops. They then create a plan hierarchy and dependencies. “Once you have a graph, you can do presimulation analysis to see what portions of the graph are reachable and where you are going to spend your verification time, given the way you’ve written the verification plan, and you can estimate how much simulation you will need to run to get coverage of the plan,” he says.

After running those steps, the tool then generates functional-test vectors to run in the verification group’s environment. “We not only generate input stimulus for the design, but also check that the resulting outputs are correct,” says Hamid. This feature is important for directing random-test generation and for helping users know whether they have done enough verification. “When you use a graph-based verification plan and you start out thinking about the outcome you want to test and start solving for the inputs that will give you that outcome, you know the outcome, so checking is straightforward.” With the plan as a graph, you can traverse the entire plan with 100% coverage. It takes 100 to 500 simulation cycles to achieve this coverage, depending on the size of the design.

The tool displays the verification plan in a graph that illustrates hot spots, showing what areas of the design have coverage. “It’s a quick way to dive in and say, “Why haven’t we reached this node? Is there a dependency that kept us out of there, or did we not run enough simulation?’” Once you find a hot spot, you then check on whether you incorrectly described a graph or dependency or whether you did too little simulation. If neither is the case, an error in the design is likely the cause. You can then go back to your verification environment and home in on that section of the design to solve the problem.

The company currently offers subgraph modules for TCP/IP (Transmission Control Protocol/Internet Protocol), RDMA (rate-division multiple access), SSL (Secure Sockets Layer), Fibre Channel, SONET (synchronous optical network), and PCIe (Peripheral Component Interconnect Express). Users can add these subgraphs to their larger graph-based verification plans. The tool can also interface with third-party-IP bus-functional models for the generation of test cases. Prices for the tool start at $32,000 for an annual subscription.

© 2009, Reed Business Information, a division of Reed Elsevier Inc. All Rights Reserved.