Customer Questions About TLM-driven Design and Verification

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