Forte CynCity

Last time, I looked at the verification advantages of using SystemC for HLS. This time, I want to explore another important capability of SystemC that makes it far superior to ANSI C for hardware design.

I’m talking about structural hierarchy. SystemC supports hierarchy while ANSI C does not. Structural hierarchy means submodules, connected together and executing concurrently. Use of hierarchy is the traditional mainstay of hardware designers for breaking down complex designs into a group of smaller, more manageable designs that are easier to design and verify.

Here are some of the advantages that come from SystemC’s support for hierarchy:

Unit-Level Verification
It’s easier to build a testbench that can stimulate all the critical corner cases in a design when it’s a smaller block. Also, signoff requirements like code coverage are easier to meet when you have controllability at the smaller block boundary. Making sure that every line of source code is covered requires a designer to find the correct sequence of input values to exercise every code branch. With a small block you don’t have to try to trick the upstream blocks into producing the right stimulus, you can just have the testbench present whatever stimulus you need. In large blocks this may be impossible altogether.

Connections and Interfaces
Working at the submodule level allows designers to isolate the complex interfaces and channel connections between them. ANSI C HLS tools, as mentioned in the previous post, do not accurately represent concurrent hardware. This can really cause problems designing and verifying interfaces because the handshaking and transactions all occur simultaneously. The simulation semantics of SystemC let you examine interfaces and channels at the pin-level and make it straightforward to code your own interfaces with whatever protocol you need. SystemC-based HLS also allows you to encapsulate the details of a particular protocol in a set of classes and easily switch from one interface to another without changing your module’s source code–but that’s the topic of a future posting!

Architecture Design
In HLS design there is a step between algorithmic design and RTL generation: architectural design. This step takes the untimed algorithmic code and decides how major portions will be implemented in hardware to best meet QoR requirements, i.e. whether a particular array be an external memory or a flattened register. Some of this is done through synthesis directives or constraints, but a handy tactic is being able to partition a section of code into a nice hierarchical submodule. This, and its verification advantage, is talked about more in John Sanguinetti’s recent EETimes EDA DesignLine article.

Faster Runtimes
Everything will run faster with smaller modules. The blocks will get through behavioral synthesis scheduling more quickly and the generated RTL will run through logic synthesis tools faster. The block-level testing will go faster because smaller blocks compile and run in simulators faster as well.

Teams of Multiple Designers
Teams usually work in parallel, with multiple teams designing and verifying multiple blocks in parallel. Hierarchy makes design maintenance easier, makes it possible to keep a consistent set of code for HLS and verification, and keeps designers from stepping on each others’ toes.

Reuse
When the next-generation design is derived from your current design,having the design broken into manageable blocks makes it much easier to reuse some of those blocks without an entirely new verification effort. It also improves your ability to figure out which blocks will have to be changed, or how to fit together a combination of old, new and modified blocks to meet the new requirements.

SystemC supports our familiar friend–structural hierarchy–and allows you to use many of the same techniques you are accustomed to for managing the complexity of design and verification tasks. Gee, using SystemC for HLS is just like having a real hardware language, only with higher levels of abstraction available. No wait, it’s not like that–it’s exactly that! And that’s what you really need for practical high-level hardware design.

The “language war” in high-level system (HLS) design has been waging for a while now. You’ve probably read a lot of online publications touting the advantages of using SystemC over ANSI C to design at an abstract level. If you were to take what everyone is saying and boil it down to a few key points, they might sound something like this:

• ANSI C is a sequential language.
• ANSI C cannot execute two subroutines or functions concurrently.
• ANSI C executes your code in a single flow, one line after another.
• ANSI C-based HLS tools either limit themselves to single-block designs or provide a proprietary mechanism to mimic concurrency.
• ANSI C HLS tools don’t give you a way to accurately simulate what a real piece of hardware does.

• SystemC, on the other hand, is a standardized superset of C++ that supports multiple concurrent processes.
• SystemC supports hierarchy and modules.
• SystemC allows communication between those modules at the transaction or pin level.
• SystemC gives hardware designers the ability to tackle the very complex design and interface tasks they face every day.

Notice first I said “superset of C++” instead of “language.” That’s because SystemC is indeed not a language: it’s a family of C++ classes specifically geared toward hardware design constructs like modules, ports, concurrency, clocks, resets and channels.

The list above is short, but to see what far-reaching consequences these points have for hardware designers, consider the following:

Let’s say you use an ANSI C tool that can only work with single blocks. If you have a multiple block system, you can produce each block one at a time. But there’s a catch: how do you verify that system? According to the tool, that’s your problem. It’s up to you to somehow stitch these blocks together in RTL and do all the verification in RTL.

If you use an ANSI C tool that mimics concurrent simulation using proprietary libraries or other non-standard techniques, you are locked into that proprietary flow. Want to drive yourself crazy? Just try using this flow to create some IP cells and distribute them to your customers. Those customers will have to use (and own) the same tool just to run a simulation.

The proprietary library approach also takes liberties to get your ANSI C code to act like real hardware. To emulate the dataflow of your design they will typically have you partition the design so each block is a subroutine, and require you to call proprietary APIs inside the subroutines to manage that dataflow. One common approach is to have you conditionally execute the algorithms inside the subroutines depending on the availability of data reported by these API calls.

Sound messy? It is. And when you consider that it takes an API call (also proprietary) to determine if there is data in the channel, then you start to understand how these libraries are rudimentary static simulators at best.

If you have a fairly simple design that has a sequential algorithm, can be controlled by a single finite state machine, processes the same number of inputs and outputs every cycle, and uses a limited set of interfaces to communicate, then ANSI C may work fine for you. But the truth is that real projects aren’t that simple. Complex designs have multiple processes operating concurrently, they communicate with things like external memories and they send data through interfaces that must be customizable.

If you use the SystemC classes for HLS design, you have a real built-in, event-driven simulator to support your verification efforts. SystemC supports multiple modules that can execute concurrently, can share data in memories, and can synchronize their execution using real signal-level protocols. In other words, it allows you to attack the biggest design problems by breaking them down into multiple blocks and connecting them with channels that follow a protocol.

And with SystemC, you can easily simulate these blocks together to make sure everything is working correctly.

Can you do all this with ANSI C? You could, but how much time are you willing to spend writing the specialized hardware classes that already exist with SystemC?

There’s a lot more I could say about this, but I’ll let someone else do it for me.  John Sanguinetti, Forte’s CTO, just published this article in EETimes’ EDA DesignLine that takes another look at the verification angle.

Next time, I’ll take a little deeper look into another important advantage of SystemC in HLS design: its support of structural hierarchy.