Home > Community > Blogs > System Design and Verification > systemc it s neither complicated nor belligerent
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).
 

Email
* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

Cadence Contacts

Global Office Locator
Find Offices worldwide »

Sales Inquiry
Request for Product information »
Cadence Channel Partners »

Corporate Headquarters
Cadence Design Systems, Inc.
2655 Seely Avenue
San Jose, CA 95134
Phone: 408.943.1234
* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

SystemC: It's Neither Complicated Nor Belligerent!

By Jack Erickson on January 24, 2011Comments(5)Filed under: High-Level Synthesis, ESL, SystemC, TLM, System Design and Verification, system, C to Silicon, C++I was recently talking to a customer who was looking to move up in abstraction from RTL to SystemC for all the usual good reasons (increased verification productivity, broader micro-architecture exploration, easier re-use, etc). However he was concerned that the learning curve for his team would be too high. He specifically referenced an article by one of our competitors that positioned SystemC as something different from C++ (and according to the article was apparently once at war with it), and then went on to describe all the nuances associated with the choice of which elements of the design to model in which "language."

Having recently come from the RTL world myself, I understand the customer's concerns. He knew how to get his design done using RTL. Now he was going to have to learn multiple languages, figure out where to apply each, and presumably use different paths to get through verification and synthesis.

If you're designing a real chip, you don't have time for that.

Let's see if we can simplify a bit: C++ is a superset of C. SystemC is a superset of C++.

A little more detail:

  • C++ adds pre-built constructs like classes, objects, and templates to the base C language to make it more re-usable.
  • SystemC adds pre-built constructs like hierarchy, ports, concurrency, transaction-level queues, signals, and fixed point datatypes to make it easier to use C++ for hardware design.

This is nice because if you have the tools to properly support SystemC, then you can connect algorithm/system design directly to production hardware design, and move most of the verification and micro-architecture exploration to a higher level of abstraction.

So if you're designing a (insert your design here....really, it works for any type), you would first develop the algorithm and test its effectiveness, throughput, etc. using C/C++. Once you are satisfied with that, you then use the SystemC constructs to provide further detail as to how this algorithm would map to hardware. This means the dataflow architecture and associated control logic, the memory architecture, the communication protocols, and so on. However you do not need to allocate logic to clock cycles, model state machines, model resource sharing, or other implementation details. The high-level synthesis tool will take care of that. Yes, the interfaces should be cycle-accurate (that's a blog post for another day). But the point is that the whole thing is designed in high-abstraction SystemC, verified in SystemC using existing verification methodologies, and synthesized together down to RTL according to the goals of the target application and the capabilities of the process library.

If you want a bit more explanation, I suggest you check out Mark Warren's webinar from back in December:

Practical application of high-level synthesis in SoC designs

Mark does a great job explaining things in terms hardware designers can relate to. And we can start diving down in to some more details in this space.

But to start with, don't be overwhelmed. Yes, the old C-based and HLS tools required a lot of methodology overhead, but the modern tools like C-to-Silicon and Incisive verification are finally unlocking the significant benefits of SystemC hardware design.

Jack Erickson

 

Comments(5)

By manrajgujral on January 24, 2011
I am a student at the moment, moving from Verilog/Sys. Verilog to systemC next semester.
As of now, I am confident to model a system from an ASM chart to Verilog/Sys Verilog. And, to be honest, it took a while to get hang of the sequential and combinational parts.
I hope SystemC is how you've put it. (i've had C/C++ before too). Looking forward to it

By Gene Bushuyev on January 25, 2011
No, it's not complicated, just convoluted and very much outdated. Naturally, for beginners and experts alike I recommend GBL library instead of SystemC.

By David Black on January 26, 2011
SystemC is neither convoluted nor outdated. I am concerned that you would push your own relatively new products in this area. I note that your products are only supported on Windows. The GBL library does not appear to be available separately without the tools, which require licensing.It is unclear if it is truly open-source or what body of engineers has reviewed it. Your credentials are decent.

By manrajgujral on March 14, 2011
Well. I am well into my next semester now, and here’s the thing
1. Moving from VHDL to Verilog was a relief.
2. Moving from Verilog to System Verilog was again a huge improvement. Though it wasn’t a big change, but one felt Sys. Verilog was a natural evolution of Verilog.
3. Sys. Verilog to SystemC seems like a step back. It is like going back in time.
Reasons:
Sys. Verilog has these concurrent events which can be modelled so easily. Simple logic for e.g.:
(a) For a wire/logic definition for signals is so neat. Compare it to sysC where you need to first define the mode "sc_in" , then define the type "sc_bool" ...define the size, if any, then define the signal name.
(b) Rising edge and falling edge can only be done for signals defined as "sc_clk" is seems. (Maybe there are options that i haven’t heard)
(c)where is the concatenate command in SysC? It is so easy to manipulate arrays and bits in Sys Verilog by using simple "{}" that the designer doesn’t have to bother doing the right-shits and then ORing...or any basic level coding - which could easily result in more coding time and error prone too.
Well, I have just listed random things from the top of my head. These are the first impressions to Sys C, and maybe I am too naive in this area, but as a beginner - that’s my feedback. It feels like a step back.

By rradhakr on March 15, 2011
SystemC should be primarily used for modeling algorithms at a high level of abstraction. The primary reason for moving to a higher level of abstraction is simulation speed. You don't want to verify functionality at the RT-level. Do not fall into the trap of thinking at the RTL level of abstraction for SystemC.  
There reason that algorithm designers/architects in chip companies do not use Verilog --its too low level.
Abstraction level makes a much larger impact on simulation speed than language.  C++ is significantly easier and more compact for writing high abstraction than Verilog.  SystemC adds to the wide usage of C++ by adding hardware-specific concepts and more importantly, concurrency/parallelism capabilities. SystemC's data types offer a lot of operations (concat, range,etc) for coding flexibility.
Once you have a valid SystemC model, you can use High-Level Synthesis (HLS) to generate a RTL model. One of the benefits of HLS is that it allows the architect/designer to model the designs functionality without any concern for microarchitectural implementation details --like what happens in any specific clock cycle.   As you get more experience coding SystemC for HLS, you will see the huge benefits of the code being easier to write, read and debug, plus it simulates so much faster.  Let the HLS tool, like the Cadence C-to-Silicon Compiler do all the hard work of generating low-level RTL Verilog for the rest of your design flow.

Leave a Comment


Name
E-mail (will not be published)
Comment
 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.