Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > System Design and Verification > ip cannot be an efficient abstraction level without systemc
 
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).
 

Email

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

IP Cannot be an Efficient Abstraction Level Without SystemC!

Comments(0)Filed under: High-Level Synthesis, IP re-use, SystemC, RTL, TLM, EDN, hls, System Design and Verification, SoC, IP, system design, abstraction, IP assembly

EDN recently featured a lengthy article entitled "SOCs: IP is the new abstraction. Reusable IP, not system-level language, has become the new level of abstraction."

The point of view is that SoC design now is such a large undertaking that the best way to efficiently design one is to assemble IP from various sources into a platform, differentiate with software, and swap in different IP for derivative designs that target different requirements.

It all makes sense. However, where it goes wrong is in saying that SystemC has not delivered the next level of abstraction after RTL. This IP re-use and assembly vision does not work very efficiently unless the IP is developed in SystemC transaction-level modeling (TLM). Designing blocks in RTL would work in this vision, but it would be very inefficient, blunting many of the benefits. This is why many corporate design re-use initiatives have stalled, because of the significant amount of overhead required to re-use RTL.

RTL by its nature ("register transfer level") contains a significant amount of implementation-specific information. The RTL micro-architecture for a block going into a performance-driven application will need to be changed for a cost-driven application that needs the smallest area possible. And different process nodes bring different capabilities as well as challenges -- as you move to smaller nodes you get performance and size benefits that you can tweak your micro-architecture to take advantage of, but you will need to trade that off with power. Of course there are different libraries for a given process technology -- high-performance, low-power, etc. -- that you can use but which also require different RTL micro-architectures.

Designing in SystemC enables designers to focus on describing the functionality of the algorithm, and high-level synthesis (HLS) automates the process of generating RTL specific to a particular application's goals and process library. The implementation-specific details are captured in the HLS constraints, so your functional verification can focus only on the functionality. And once the functionality is verified, you can re-target without re-running functional verification at that level. This makes IP re-use, and especially derivatives of that IP, much more efficient. It also reduces some of the overhead stated in the article associated with learning the ins and outs of off-the-shelf IP.

And the system-level verification that needs to be performed is not feasible with RTL IP because it is too detailed, slowing down simulation performance and making debug tedious. It is mentioned that virtual prototypes are required for simulating the system software, but often the RTL IP functionality diverges from the virtual prototype. Again, these are things that can be solved by moving to a SystemC transaction-level modeling (TLM) use model. You can start out with high-level virtual prototypes and refine those toward a hardware architecture that can be synthesized by HLS, all within SystemC TLM.

TLM is essentially a higher-level abstraction of a particular communications interface. This is wrapped around the block's computation core. This provides a level of modularity between different bus architectures -- you can use the same computation core with different communications wrappers. This solves many of the assembly issues cited in the article where SoC teams are required to write RTL glue logic to connect all this inflexible IP.

Finally, when it comes to implementation, if you utilize HLS that's connected to implementation, you don't have to do a lot of the manual power and clock optimization techniques at RTL because that can be modeled in HLS. With the specific constraints passed automatically to RTL synthesis, the rest of the flow goes smoothly.

It's this last part that has really held back broader adoption of SystemC TLM for this purpose. If HLS can't produce something that will predictably close on your performance, power, and area goals, then you end up having to try to fix or re-write the RTL. But now with HLS tools like C-to-Silicon Compiler, which is tightly linked with Cadence's RTL Compiler synthesis, this problem is addressed.

So this is not a case of whether the new abstraction level is IP or SystemC. Both are, and for IP to work as an abstraction level, SystemC is required. What you use to get your job done is largely a function of your role. If you're in an SoC design group there will be a lot of IP assembly and perhaps some SystemC. But if you're in an IP design group or company, then SystemC will make your business much more efficient.

Jack Erickson

Comments(0)

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.