Home > Community > Blogs > System Design and Verification > customer questions about tlm driven design and verification
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

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

Customer Questions About TLM-driven Design and Verification

Comments(0)Filed under: System Design and Verification, C-to-Silicon, TLM 2.0, high level synthesis, system C

In the latest blog published by Ron Wilson there were two questions about our TLM-driven design and verification solution introduction. We would like to respond to these comments here:

1. "one line of SystemC generates three lines of RTL"

During our interview with Ron, we showed an example of one of our customers who wrote in parallel SystemC and RTL code. In this case the number of RTL code lines was 3X of the number of SystemC code lines and was based on control-centric design. Many customers report a much higher ratio. The SystemC source will mostly be untimed and not detail many of the low-level RTL requirements such as resource sharing and specific state machine. As such, it could be as small as 1/10th the size of the equivalent hand-written RTL (in the extreme cases, even smaller) for datapath-centric designs and 1/4th the size for control-centric designs. Abstracting away signals to use a TLM interface will also increase these ratios.

2. "Is the RTL OVM SystemVerilog or Verilog. Do we get to choose?"

It's not 100% clear whether you are asking "What language is the DUT that's output by C-to-Silicon?"; or based on your mention of OVM, whether you are asking about how testbenches relate to the code output by C-to-Silicon. Thus, allow us to provide answers from both a DUT and testbench angle -- let us know if we address your original question. First, from a DUT angle, The primary output of C-to-Silicon is IEEE-compliant synthesizable RTL Verilog. [Note the question is asking if this RTL is Verilog-95 or SystemVerilog --the answer is that it is v2k Verilog since it has to work on all downstream tools]. C-to-Silicon also can automatically wrap that RTL so it can be easily plugged-and-played into the higher-level design and/or testbench. W.r.t. to the testbench aspect of C-to-Silicon output: the architecture of OVM verification components is replicated across e, SV, and SystemC. Additionally, Cadence's IES-XL simulator supports e, SV, and SystemC -- and hence OVM -- so the choice of testbench for your C-to-Silicon created DUT is really up to you.

Team ESL


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.