ESL Languages: Which One Is Right For Your Needs?
The question about ESL language is the right one comes up over and over again. As customers begin to understand the benefits of modeling and analysis at the system level, they must address this question as one of the first steps in getting started.
What language should be used for ESL—SystemC, SystemVerilog, UML or M? Technically, you can create an ESL/TLM platform in any language you would like. I’ve seen large corporations doing system-level modeling in all of these languages, and then some C/C++, VHDL, and even Java, have been used to do various levels of analysis at the system level. While much of the choice in language is subjective, it’s a good idea to have an understanding of the tradeoffs of using one language vs. another. These tradeoffs include language constructs and semantics, as well as issues outside the language itself—such as tool support, third-party IP availability and access to knowledgeable engineers.
While all of the mentioned languages have supporters, the two main languages I see organizations applying and trading off today are SystemC and System Verilog. At a very high level, the differences between the languages are pretty simple to characterize. SystemVerilog is primarily focused on verification and maintains all of the RTL level focus inherited from its Verilog base. The enhancements related to directed test generation, assertion definitions and coverage metrics are all very valuable capabilities, and all are closely tied to the RTL implementation domain. SystemC is C++. The libraries and standards that define SystemC extend C++ to be a language well suited to transaction-level model definition and simulation of this modeling level.
Because SystemC is based on C++, there are a huge number of experienced users and off-the-shelf examples and libraries that can be used for a wide range of functional modeling applications. The SystemC constructs add enough hardware-specific capabilities to allow the language to support TLM modeling without getting bogged down in the complexity introduced in addressing verification challenges.
I see many customers using both languages and using the languages together. For all of you who have explored the options for creating ESL models and simulations, what tradeoffs have you looked at? What were your ultimate decisions? I welcome any comments from readers to understand the choices between all of the possible ESL languages and methodologies.
–Jon McDonald, technical marketing engineer, Mentor Graphics
Tags: Add new tag, ESL, M, mentor graphics, System Verilog, SystemC, UML
March 23rd, 2009 at 9:02 am
This is a discussion that has become more common due to the advent of SystemVerilog. Until SystemVerilog’s arrival SystemC was used predominantly by C++ experts and ESL was very ad-hoc using MATLAB, C, Excel and HDL apart from SystemC. Now that SystemVerilog brought along the promise of advanced verification with dynamic stimulus generation, the ESL model for the first time was re-usable downstream during RTL and gate-level verification. The language used for ESL model can impact it’s usability in dynamic verification. See: http://www.mentor.com/products/fpga_pld/techpubs/requestpubs?selected=44629
I break the language choice into two categories.
Tops-down SystemC-ESL-to-RTL dynamic verification:
Tops-down verification as mentioned here means starting ESL modeling as part of the upstream process before RTL models are created. In the past (before SystemVerilog) ESL model done with SystemC was used for architecture analysis and creating input-output directed test vectors. Depending on the maturity level of design team they might have a large in-house and 3rd party IP reuse across projects. SystemC also has advantages in the TLM domain where there are constant improvements on the available 3rd party TLM IP for standard design blocks, bus interfaces, etc. SystemC is the best language for platform-based ESL modeling due to it’s TLM support. In this scenario plugging in SystemC ESL model in the SystemVerilog testbench (using DPI) for dynamic verification of RTL makes perfect sense. See http://www.mentor.com/products/esl/techpubs/requestpubs?selected=44812
Bottoms-up RTL block-level dynamic verification:
Bottoms-up verification as mentioned here means a block that is fairly complex for which one doesn’t have an equivalent ESL model or it would be hard to break a larger ESL model. In this case if one would like to use dynamic verification environment built using SystemVerilog then the integration will be easier to create the ideal expected data generator or the TLM model of the block under test using SystemVerilog. One could use SystemC but that involves using DPI for integration into SystemVerilog testbench as mentioned earlier. Staying in the same language (SystemVerilog) for the testbench and the TLM model makes a better sense from the point of view of integration issues that might arise when using SystemC along with SystemVerilog.
The bottom line is how readily a TLM model is available for advanced dynamic verification. Now-a-days pretty much any infrastructure (for example, MATLAB) provides some C-based API to invoke the ESL model. This C-based API can be mixed with SystemVerilog DPI. So one can continue using the language of choice for ESL modeling.
SystemC is well suited for ESL modeling due to its large set of IP availability, TLM standardization, standard bus interfaces at high level, etc. SystemVerilog, on the other hand, being an amalgamation of advanced testbench techniques like constraint random, functional coverage and assertions is well suited for testbenches.