Home > Community > Blogs > System Design and Verification > methodology is important but language matters part 2
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 System Design and 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: *

Methodology Is Important But Language Matters - Part 2

Comments(2)Filed under: System Design and Verification, Verification planning and management, ESL handoff, C-to-Silicon Compiler, High-Level Synthesis, verification, embedded software, virtual protoype, SystemC, TLM, TLM 2.0-driven design, TLM-driven design

In this blog, I would like to discuss the direction in the languages that will be chosen for TLM (or ESL) verification. Transaction-Level Models have been used for long time as simulation models. As we start to use more and more high-level synthesis, the link to design and implementation is becoming more important and as such, we need to develop also a mainstream verification environment that will support the new flow.

Extension of existing verification methodology is required

In order to help the industry (and the large number of verification engineers) migrate to a new level of abstraction, we will undoubtedly need to go through a time of "mixed-level abstraction" in which RTL and TLM models are verified together. Even when most new IP designs are created at the TLM level, many legacy models (written in RTL) will still need to be integrated. We cannot underestimate the infrastructure creation efforts in which verification engineers (and executives) have invested over the last 10-12 years; they will not throw away this environment overnight and the only acceptable solution will be incremental.

Therefore, the best way to get "buy-in" from existing verification engineers would be to help build an incremental verification environment (serving both RTL and TLM) on top of their existing one. I would also predict that the TLM testbench verification environment will eventually have the same requirements (or more) as today's RTL test bench: VIP, constrained random stimulus, Metric-Driven Verification, etc. however will provide much higher productivity.

A new TLM IP must be thoroughly verified (like RTL IP is being thoroughly verified today) and the resulting RTL will also need to be thoroughly verified. A simple verification environment at the TLM level will not be sufficient. Designers need to use the best-known methods for thoroughly and efficiently verifying a design model that will be implemented in Hardware, where the cost of failure is extremely high.  These best-known methods are based on Metric-Driven Verification simulation approaches which include automated constrained-random stimulus, self-checking, and coverage-driven metrics to measure completeness. These should apply to both TLM and RTL IP. The trick is to understand what needs to be verified at each level so the verification process will be optimized to each level.

You need to verify a design that will be implemented in hardware where the cost of failure is extremely high, so we should leverage the best known methods from the RTL verification world and adapt them. You would then naturally select a verification language for TLM (ESL) that has long-standing competence for advanced verification with the ones that have been used in the last 5-10 years and are still being used today for RTL verification - e or SystemVerilog. While there are methodology issues to resolve, the first step is to agree on the essential verification languages that will be used. Again, this does not mean that for certain tasks designers will not use other languages (SystemC, C, C++, etc.) for test benches or even as part of a software stimulus; however the main advanced verification environment (the one that the mainstream verification engineers need to build) will use the same language for RTL, TLM, and the mix of those.

So which verification language should be used?

If you are using e today for RTL verification, do not look further. In addition to its aspect oriented features and maturity level, e is a transaction level language since it was built independent of any design language or abstraction. This language allows you to handle TLM structures in a simple way and has been used with these models for long time. e is already being used to verify embedded SW and Cadence has already a product (Incisive Software Extensions) leveraging these capabilities. Even if you are not using e for RTL verification, you might want to take a look at e as a testbench language for TLM and leverage the benefits the language has.

SystemVerilog testbench obviously is going to be a good choice for customers who are dedicated to this language in RTL and would like to use the same testbench language for TLM and RTL.

Cadence is committed to support both SystemVerilog and e as advanced verification languages for hardware designs (which interact with embedded software) under test written in TLM, RTL and the mixed of those.

So, what does it mean to you?

Chose carefully the testbench language, you would like to use. There are advantages and disadvantages to each one of them.

It is important to mention that methodology, tools, and the way design and verification engineers build their environment are as important as the language, if not more so.

However, history has shown that we cannot ignore the issue of language - language unquestionably matters - when discussing TLM (or ESL) design and verification the same way that language matters when we communicate with the local community in different countries.

Cadence preferred language for TLM design is SystemC and for advanced verification testbench, e and SystemVerilog under the umbrella of OVM (now UVM) while SystemC (or C/C++) can be used as a simple testbench language for system engineers who would like to verify their own code or as part of the stimulus of the design produced by software engineers.

I know this is a topic that will create a lot of debate; therefore, I would be happy to hear your opinions.

Ran Avinun



By Jonathan David on February 9, 2010
I hope the ESL vendors are considering Mixed Signal upfront this time, instead of adding it as an afterthought which is what happened with Verilog, and is finally happening with SystemVerilog.
e - being a legacy language as well, will likely need some enhancements to be able to effectively address the Mixed-Signal space in which most SOC's sit today.  

By Team Specman on February 10, 2010
In response to Jonathan David's remark:
e - being a legacy language as well, will likely need some enhancements to be able to effectively address the Mixed-Signal space in which most SOC's sit today.
Specman has supported type REAL for years now, with many customers using it in an AMS flow, and others doing some clever statistics capturing & measurement (with vPlans and Enterprise Manager, no less)  Looks like we should do a blog post about this ...
Furthermore, the e language REAL syntax & semantics are in the process of being standardized in the next revision of IEEE 1647 targeted for this fall.  You can follow (and join) the Working Group here:
Team Specman

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.