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