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.