Home > Community > Blogs > Functional Verification > applying software driven development techniques to testbench development
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 Functional Verification blog (individual posts).


* 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: *

Applying Software-Driven Development Techniques to Testbench Development

Comments(0)Filed under: Incisive Enterprise Simulator (IES), Specman, debug, Funcional Verification, AF, e code, unit testing

Over the past couple of years there has been some interest in applying a software development technique called unit testing in the hardware development flow. One of the reasons is that unit tests allow customers to validate their testbench in isolation, enabling very fast and thorough tests. Some customers have developed their own framework to accomplish this testing. In the Incisive 13.2 release, Cadence has introduced this functionality with Specman/e to enable customers to apply the unit test approach to save long simulation times, since they can isolate functions and test them without actually running any simulation, thus improving the testbench quality and potentially reducing the debug time for testbench code more than 30%.

What are unit tests?

-          Simple and directed tests

-          Checks that a feature does something as expected (e.g. a parity calculation method returns the correct parity for a handful of values)

-          Created by the developer that develops/writes the source code


What are unit tests used for?

-          To check that the implementation of a small piece of code (e.g. a single method/function) is correct

Some customers may think that unit testing is an extra overhead, and there is little automation for creating test cases. So, why should they develop and use unit tests?

-          Customers can check the implementation of a method that normally takes many simulation cycles in no simulation time (e.g. a complex checking method which requires streams of input, output, and control data). in unit testing, you would provide all the input/output and control data, call the method, and check that is calculates the correct result

-          If other teams reuse code (and this happens a lot with verification code), they can check if the core testbench functions still work, or if something is broken

If you want some more details, have a look at this archived webinar - Testing the Testbench on the e-unit package and/or read the blog on Agile SOC ... Finally... A Reason For Me to Try Specman

Other references worthwhile reviewing are some articles and a unit test framework utility by AgileSOC

Happy testing,

-Hannes Froehlich


Leave a Comment

E-mail (will not be published)
 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.