Is SystemC a subset of SV?

SystemVerilog
1

Hi
Was SystemC used in place of SV earlier for verification?

2

In reply to Gokul S:

This a a very broad question and answers to it will be highly opinionated. Here is my take:

SystemC is a library on top of an existing programming language, C++. It’s original goal was to provide hardware modeling concepts from Verilog and VHDL into a C++ environment. A few key hardware modeling concepts are:

  • bit-level data types and operators on those types
  • a scheduling algorithm that simulates massive amounts of concurrent threads
  • module hierarchy with signal connectivity.

You can model at a much higher level of abstraction and get much better performance than you can in Verilog. However, if you model at the same level of abstraction that you do in Verilog, you may have worse performance.

SystemVerilog is a hardware description and verification language that added concepts from C and Java into Verilog, as well as a number of verification concepts, like assertions, functional coverage, and constraint randomization from other sources.

SystemC was available in production a number of years before SystemVerilog, but both became IEEE standards in the same year (2005).

The UVM is a base class library that adds some of the concepts from SystemC, like transaction-level modeling, and reporting. (coincidentally, there was some overlap in the people the contributed to both SystemC and UVM)

If you want some more information on trends in verification, please check here:

3

In reply to dave_59:

Thanks for the info, Dave!

4

In reply to Gokul S:

I’ll throw some of my opinions at this from a RTL designer’s perspective. Perhaps not explicitly relevant to Gokul’s query and Dave’s response (both focusing on verification as is this forum…)

Caveat, I only “slide show” understand System C (or any of the other HLS variants). I’ve paid attention to them at conferences, and news, but never used any of them.

But from a Designer point of view System C (and other HLS type languages) are a poor choice IMHO. Dave pointed out some of the things that had to be “wedged in” (my words) to the language to support hardware modeling. These hacks/pragmas just show how poorly a choice the languages are for modelling hardware.

Now coming from the flip side, you can model at a higher level of abstraction quite nicely all within SystemVerilog. One can code up transaction level models (no clocks), object oriented design, arrays as first class citizens, floating point (reals) etc. All within SystemVerilog. Which allows for ease of integration with the rest of your RTL.

And since these datapath heavy algorithmic coding is only aiming at a small portion of my design - doesn’t it make more sense to approach the problem from RTL perspective and move up, instead of the reverse?

But there’s no tools that I know of that address the (Design) problem from this angle. (Verification is of course handled with OVM/UVM).

A pity no solution for us RTL guys, IMHO. For now, I keep an eye on System C, and other HLS news/announcements and continue to think a whole lotta “meh”.

My 2 cents…

Regards,

Mark

5

In reply to Mark Curry:

Thanks for the info, Mark!