Comments on: ESL Languages: Which One Is Right For Your Needs? http://chipdesignmag.com/sld/mcdonald/2009/02/19/esl-languages-which-one-is-right-for-your-needs/ Deep Insights for Chip Architects and Engineers Fri, 27 May 2011 08:05:12 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Shashi http://chipdesignmag.com/sld/mcdonald/2009/02/19/esl-languages-which-one-is-right-for-your-needs/comment-page-1/#comment-5 Shashi Mon, 23 Mar 2009 17:02:01 +0000 http://chipdesignmag.com/sld/mcdonald/?p=20#comment-5 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. 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.

]]>