Sarmad Dahir, ASIC designer at Ericsson in Stockholm, Sweden,
is part of a significant ongoing shift in functional verification - the move
from directed testing to constrained-random test generation and metric-driven
verification (MDV). In a recent conversation I learned more about why and how Dahir's team made the move, what the advantages are, and what lessons were learned.
Ericsson has a long history of using constrained-random generation, especially at the block level. Dahir's team adopted this methodology for top-level verification of mobile platform ASICs. When Dahir joined Ericsson two and a half years ago, some of those ASICs were still verified using directed C language test cases. In such instances, he said, "there were two teams,
one that developed the ASIC and another writing test cases in C. That was very
time consuming. Sometimes the software was ready weeks after the hardware RTL
was ready."
"We realized the environment was inefficient. Since we're
short in the number of people doing verification here, we decided to consider
other options, and that is how we came across the idea of using commercial eVCs
[verification IP] to run test cases." And that's the approach that Dahir
took, using the Specman platform from Cadence along with AXI, AHB, and APB
eVCs. The eVCs provide test sequences and act as both masters and slaves.
Advantages of the New
Approach
Constrained-random testing is much more efficient than the
old directed test approach, Dahir said. "Random testing makes things easier,
because you won't have to target every possible scenario." This translates into
a time savings - perhaps 30 percent for the overall verification process. In
the old directed test environment, Dahir said, it took 1-2 weeks to rewrite
testbenches and resume verification after new RTL came in. With Specman, this only
takes a couple of days.
Not only is the constrained-random approach much faster, but
"we have much better confidence that our verification is actually good," Dahir
said. "So it's not only the time we're saving, it's the quality of the
verification we're getting."
MDV provides some important benefits. Dahir's group uses Incisive
Enterprise Planner to develop and track a verification plan, and Incisive
Enterprise Manager to execute regression runs. Whenever new tests are run,
these tools are used to monitor and collect functional coverage data. "In the
old environment, we didn't have any clue as to what was going on inside the
chip," Dahir said. "Here, we have a much clearer view of what we have actually
verified."
Phased Verification
Dahir is verifying multi-processor SoCs used in devices such
as smartphones and laptops. These chips have multi-AMBA protocol bus
architectures. Designers have a strong focus on low power consumption, and they
use multiple power domains.
Verification in Dahir's team includes several distinct phases:
- AXI subsystem IP level - verify
the interconnect matrix using the Specman Constraint Management System
(CMS). Hook up active agents on all interfaces.
- Top-level phase 1 - include RTL
subsystems and replace active slave agents with passive ones. (This phase
is still running random traffic, but against RTL subsystems).
- Top-level phase 2 - include AHB
multilayer interconnect. Verify transactions crossing between AXI, AHB,
APB with generic scoreboard.
- System-specific extensions - use
monitors and checkers to verify system-specific functionality.
Dahir uses the Specman vr_ad
package for module-level register and memory verification, and uses it to drive
directed configuration sequences. His group has also built a library of
constrained-random test cases, coverage, and checkers.
Lessons Learned
The transition to constrained-random testing did not
happen overnight. Engineers had little or no experience with Specman or the e
language when the process started. In a presentation at CDN Live! EMEA in 2009,
Dahir noted that while the first project took 3 months to build the environment
and get CMS up and running, the second project required only one week to
accomplish this. Dahir said that only two engineers, himself and colleague
Michael Carlberg, worked on the new Specman testbench.
One piece of advice: "Don't try to do the full chip at
once." That's why Dahir's team developed a bottom-up approach comprised of
several phases, as noted above. "First, verify only the bus itself. Then you
have a platform to build on," he said.
The new approach doesn't completely replace C directed
tests. "They're still being used because we need to deliver software," Dahir
said. But for hardware verification, the new approach has many advantages. "If
someone is not using constrained-random test generation, my view is that they
should get started. It will save time and it's much more efficient," Dahir
said.
Richard Goering