Get email delivery of the Cadence blog featured here
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
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.
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.