Home > Community > Blogs > Industry Insights > user interview moving to constrained random verification
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

User Interview: Moving To Constrained-Random Verification

Comments(0)Filed under: Industry Insights, specman, verification, Functional Verification, e, MDV, random, Ericsson, Dahir, metric-driven

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

 

 

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.