How do SystemC simulations perform these days compared to C or C++?
About 5 years ago we used SystemC to develop models of our designs during the architecture exploration phase. Synthesis from SystemC was immature at that point, so we did not perform any synthesis from SystemC, but we had hopes to move in that direction. The stumbling block we hit was the performance of the SystemC models, which was somewhere between one and two order of magnitude slower than C or C++. We found that there was a lot of simulation overhead involved in using the SystemC data types, which was the primary cause of the poor simulation performance. Following that experience, SystemC was not used for subsequent projects.
If the tools or libraries for SystemC have improved since then, we may have to take another look at it. I've always believed that SystemC held great promise as an integrated synthesis and verification language.
Frank, you bring up an interesting point about the history of High Level Synthesis. The architects of C-to-Silicon Compiler were well-aware of the many shortcomings of the previous generations of HLS tools (Behavioral Compiler and Visual Architect were 2 or 3 generations ago).
Thus CtoS was designed from the ground-up to specifically address these shortcomings.
*SystemC adds value over C++ to better describe hierarchy, concurrency, and other hardware care-abouts in an _industry standard_ way (important to develop full methodologies!).
*Tight Integration to implementation flows means great QoR with predictable logic synthesis timing closure and ECOs.
*Complete design support means the big productivity gain works for all design logic –not just the datapath.
*And now since all the logic is driven by HLS, functional verification moves up to TLM which offers the largest productivity gains.
*Plus CtoS still you full visibility and control of everything via its very modern GUI (unlike those previous tools)
These add up to show why now is the time where technology is enabling the next required step up the design abstraction curve. And why many large, complex designs are being taped out using CtoS.
I was an earlier user of Cadence's previous HLS offering, back in the '90s when they bought an HLS tool from a Swedish company, integrated it into SPW and called it Visual Architect.
Back then we only used it on DSP designs, and we got similar big boosts in productivity compared to manual RTL coding -- but with many of the same caveats mentioned in this article: unfamiliar design flow, limitations on debug capability/visibility, etc. One benefit of that earlier HLS approach was that design capture was graphical, so it was at least a more familiar flow for existing SPW users.
Fast forward 15 years to today, and it looks like the deck chairs have been rearranged, but fundamentally, not that much has changed for HLS.
Back then, our HLS flow looked much like the flow described in the article, except that our design entry was in SPW + Visual Architect, which had high level models in C++ and the output was an RTL controller and an RTL DSP block. Back then we used Synopsys for RTL synthesis, but Cadence did have their Build Gates synthesis tool they bought from Ambit.
So today Cadence offers "C-to-Silicon". C++ models are now System C models that the user must write -- no more block diagram design capture -- Build Gates has been replaced with RTL Compiler (a big improvement), and Synopsys now owns the SPW tool. Let's not forget that Synopsys was also offering Behavioral Compiler back then, which fell by the wayside just as Visual Architect did.
Around and around in circles we go!
Our experiences at Cadence working with customer designs has shown that datapath-oriented designs require about 10x less lines of code in SystemC vs. RTL, while control-oriented designs are around 3-4x less lines of code. That's lines of code...the bigger efficiencies are gained in being able to verify and debug at a higher level and easier re-use, and these are less dependent on the nature of the design.