Anyone who has designed a complex interface in RTL knows that one of the biggest chores is keeping track of the details, and it’s difficult to reuse the work you did before if any of the interface details change in any way.  If the data is a multidimensional array, the interface needs to know things like the row and column parameters so the array is formatted properly. If the data is moving from one thread or module to another, the interface needs to understand how to synchronize between them. And most interfaces require some kind of internal memory to temporarily store data in case the reads and writes happen at different speeds.

All in all, when you design interfaces in RTL you spend all your time and many lines of code getting all these details resolved. There’s no way to just say “take the data from here and put it over there.”

But in Cynthesizer there is, and it does it in a way that drastically reduces the amount of code you have to write and the time you spend verifying it. The keys to this are interface generation and packaging the details up so that you can write your algorithm at the transaction level. Keep reading and I’ll show you some hard data on that.

Interfaces ‘R Us
So I want to create an interface, a real complicated one. What do I do?

Well, in Cynthesizer there’s a tool called the Interface Generator. The Interface Generator is a combination of really sophisticated IP and a graphical editing window where you can create any custom, fully parameterized interface. This interface then becomes a packaged component (actually a set of C++ classes) I can use in a high-level SystemC design. Here’s a rundown of familiar interface types you can create in the Interface Generator:

• Buffer
  • Transfers data between two modules or threads through a shared buffer.

• Line Buffer
  • Transfers an array and stores multiple rows of data for reading.

• Circular Buffer
  • Transfers data over a circular buffer where the reading and writing operations are tightly synchronized.

• Streaming
  • Transfers an array of streaming data over one or more clock cycles.

• Trigger/Done
  • A master/slave architecture with acknowledgement signals at the beginning and end of data transfer.

• P2P Stream
  • A general form of Forte’s CynWare point-to-point interface with features for creating specialized fifos.

For each type of interface, the Interface Editor window in Interface Generator shows you a diagram of the read/write structure, a diagram of the access pattern for the datatype being transferred, and many related parameters that you can define for your needs. Best of all, the interface you create will have transaction-level functions like get(), put(), x_done(), next_y(), etc. that let your algorithm execute entire interface accesses with a single function call.

A Real Example
Let’s take a look at creating an interface part and using it in a SystemC algorithm. I will describe what I want the interface to do in words because it would be too daunting to describe in RTL.

I want an interface that does the following:

• Allows a reader and a writer to share an array of 16-bit unsigned integers

• Allows the writer to write to the array in groups of values, working from the beginning of the array to the end

• Allows the reader to read the array in groups of values working from the beginning of the array to the end

• Coordinates the activities of the reader and writer so that there is no need to store the whole array in memory or registers

Okay, that’s the basic function and it seems easy enough. But for something like this to work in the real world you need to cover that stuff I mentioned before—the details. And the details are things like this:

• Implement the internal buffer to be 1024 words long

• The writer puts the first group of input values (let’s say 2 at a time) in the first two words of the buffer (words 0 and 1), put the next group of inputs in the next two words of the buffer (words 2 and 3), etc.

• The reader gets the first group of output values (let’s say 8 at a time) from the first eight words of the buffer (words 0-7), get the next outputs by shifting once and reading the next eight words (words 1-8), etc.

• When the writer has put inputs in the last two words of the buffer, circle around and put the next inputs in the first two words of the buffer

• When the reader has grabbed outputs that go beyond the edge of the buffer, circle around and get the remaining values from the beginning of the buffer

• Maintain input and output buffer pointers to make sure the correct buffer contents are read or written

• Synchronize the interface at the beginning and the end of the algorithm’s execution

• Synchronize the interface at the beginning and the end of any iterating loop in the algorithm

• Fully handshake all interface accesses

Suddenly this is not looking so easy. If I was designing the old way I would have to create a buffer array, set up a bunch of pointer variables, make complicated address assignments to keep everything pointing to the right place, keep track of where I was in the memory to handle that circular wraparound requirement, and harness all reads and writes with some kind of ready/valid handshake. Sigh.

But now I’m using Cynthesizer. Here’s what the Interface Editor window looks like for an interface that does exactly what I need:

Note first I have chosen to create a circular buffer interface because of the wraparound requirement. In the “Reader” and “Writer” sections I can choose the size of the working set on each side of the interface. I need an array of two input values on the writer side and an array of eight output values on the reader side, so you see 2 and 8 in those boxes. Also, the output pointer needs to shift by one when read, so I entered 1 in the “Adjustment” box. Now all that’s left is to define what is transferred over this interface. In the “Parameter” section I’ve specified a sc_uint datatype, which is the SystemC standard for an unsigned integer, and given it a width of 16 in the “#Bits” box. Then I sized a “1D”, 1024-word buffer for the needed internal storage. Finally, I specify RAM2 as the memory part I want the interface to use to implement the buffer. I created RAM2 myself previously using Cynthesizer’s Memory Editor window. Please read Part II of this blog series for information on creating memories. I saved my interface as a part named my_if.
So “my_if” now exists as an interface part in my library. Let’s put it to good use in an algorithm that does something like this:

My module DUT needs to do the following:

• Read an input port din, calculate two values and put them in the interface. I’ll create a thread called writer() to do this.
• Get eight values from the interface, make a calculation with them, and write the result of that calculation to an output port dout. I’ll create a thread called reader() to do this.

First, I have to define a DUT module, declare the ports and threads and instantiate my interface:

SC_MODULE( dut ) {
    cynw_p2p< sc_uint<16> >::in		din;
    cynw_p2p< sc_uint<16> >::out	dout;
    my_if::direct<>	 		m_if;
    …
    void writer();
    void reader();
    …
    SC_THREAD( writer, clk.pos() );
    SC_THREAD( reader, clk.pos() );
}

In red I show an instance of my_if using the ::direct<> template class. This is one of the member classes in my_if, and it is used to represent an internal interface communicating directly between two threads. Conversely, there is a ::chan<> class to use when the interface is external and communicates between two modules.

Now in the DUT module we’ll define the writer() and reader() threads to interact with the interface.

void writer()
{
    …
    m_if.w_start_tx();
    // 512 gets (working set of 2; fills 1024 length buffer)
    for( int i=0; i < (1024/2); i++ ) {
        m_if.w_start_iter();
        vin = din.get();
        m_if[i*2] = vin;
        m_if[i*2+1] = vin+1;
        m_if.w_end_iter();
    }
    m_if.w_end_tx();
}

void reader()
{
    …
    m_if.r_start_tx();
    // 1016 puts (working set of 8 with read adjustment of 1)
    for( int i = 0; i < (1024-8)+1; i++ )
        m_if.r_start_iter();
        v1 = m_if[j];
        v2 = m_if[j*8-1];
        val = (v1 + v2)/2;
        dout.put( val );
        m_if.r_end_iter();
    }
    m_if.r_end_tx();
}

That’s it.  I’m done.

In red I have highlighted some more of the transaction-level member functions that save me a lot of time and keep my algorithm at a high level. They are:

• w_start_tx(), w_end_tx()
  • Synchronizes the algorithm on the writing side of the interface

• r_start_tx(), r_end_tx()
  • Synchronizes the algorithm on the reading side of the interface

• w_start_iter(), w_end_iter()
  • Synchronizes a loop iteration on the writing side of the interface

• r_start_iter(), r_end_iter()
  • Synchronizes a loop iteration on the reading side of the interface

So with the Interface Generator I defined a few parameters and instantly had a SystemC interface part loaded with powerful classes and functions, and using them I was able to describe the algorithm at the transaction level in just 58 lines. This same design in RTL would have taken well over 4600 lines!

Next time, we’ll conclude our series on modular interfaces with some final suggestions of things you should consider.

It’s interfaces. I’m not just talking about declaring ports and hooking them up. I’m talking about high-level, modular interfaces that encapsulate very complex I/O protocols into easy-to-use function calls. Most of the tools out there offer some kind of interface solution, but we think they miss the mark in giving you what you need to be successful. Some let you describe I/O behavior with standard ANSI C only to add the actual pin-level interface details later in synthesis (which, unfortunately, will be the first time you can actually verify the interface). Some offer only off-the-shelf interface IP but then provide no means of creating custom interfaces. We developed Cynthesizer with all of this in mind. Cynthesizer designs are written in SystemC, where the clock and pin level activity of an interface can be simulated before the tool is run. And Cynthesizer has a family of standard interface IP in addition to an editor where you can create any interface you want.

This is the first in a four-part series on designing and working with modular interfaces in Cynthesizer. Today I’ll be detailing the benefits of modular interfaces. In the coming weeks we’ll be talking about how useful they are with external memories, we’ll detail some of the techniques we use to build them, and we’ll show what exactly is available interface-wise from Forte.

What Is A Modular Interface?
When we talk to customers or prospects we use the word “transaction” a lot. And this is probably the best word to use in describing a modular interface. A transaction, in essence, is what is being communicated across a modular interface. A modular interface can be, for example, a burst write to a standard AHB bus model. Or it can be an exchange of data that follows a strict protocol in a fixed number of clock cycles. Or it can simply be the writing of a vector or datatype value with ready/valid handshaking. The modular interface combines the I/O protocol of your transaction (i.e. ports) with the actual functionality of the transaction. Whatever the case, to you as a user it is a single function call alongside your other high-level code.

Why Use Them?
There are many benefits to designing this way. Your code is much simpler and you can describe an algorithm in fewer total lines. Your design effort can concentrate solely on the core of the algorithm at transaction level, all while retaining the flexibility to write custom interface protocols. Your connections become easier because all the pins involved in the interfaces are encapsulated in high-level channels. But the real benefit is in verification. Since handshaking is built into a modular interface, all you need is one testbench to verify all of the RTL architectures your HLS tool produces. Also, as mentioned above, Cynthesizer interfaces correctly simulate the interaction of their clocks and pins at the behavioral level, before you run any synthesis. Remember that SystemC supports both TLM and pin-level I/O configurations. We can’t state enough how critical this is to your HLS success–once your interface is verified behaviorally, it stays verified all the way down to gates or anywhere you reuse it.

Without modular interfaces you would spend a lot of time down in the trenches of I/O protocol design. You would have to declare whatever ports are needed for your transaction, make sure the direction of the ports was correct, declare signals in the parent module to connect them with, and then make sure all the connections are correct. But then comes the hard part, writing some kind of handshaking or acknowledgement scheme so that you only read input data when it is valid and only write output data when the downstream module is ready for it. This means an manual assertion of a ready signal, followed by a loop that sits and waits on a valid signal, followed by reading the data and storing it properly. And remember, you will repeat this for every interface you have.

Just look at the difference of this code with modular interfaces:

in_data = inp.get();
out_data = my_function( in_data );
outp.put( out_data );

as compared to the same code written without modular interfaces:

inp_rdy = 1;
do {
    wait();
} while( !inp_vld );
in_data = inp.read();
inp_rdy = 0;
out_data = my_function( in_data );
do {
    wait();
} while( !outp_rdy );
outp.write( out_data );
outp_vld = 1;
wait();
outp_vld = 0;

And this is only for a basic ready/valid handshake. As the interface becomes more complex, the difference in the amount of code becomes more dramatic.

How Does SystemC Help?
We’ve touched on it already, but SystemC really lends itself to modular interface design. A SystemC modular interface has two sides: a tidy, transaction-level side like the .get() and .put() calls you see above; and a rougher, pin-level side where the gritty details of the cycle-accurate protocol are defined. Some people criticize SystemC because the OSCI synthesizable subset requires modules to have pin-level ports like sc_in<> and sc_out<>, but in this case it’s an advantage. While you as a designer work at a high level, it is the pin-level ports that are presented to your HLS tool. With the pins broken out, the tool can more optimally combine your interface protocol and datapath with the control FSM. Using modular interfaces does not mean sacrificing quality or reusability.

Next time, we’ll get into designing with external memories–a specific case where modular interfaces save loads of time and effort.

In a survey, 65% of the attendees said they have used or are now using SystemC and SystemC tools in their current flow. More than 52% said that they are using high-level synthesis (HLS) — the most of any category. So what does all of this tell us?

Well, it’s clear that SystemC and SystemC HLS have moved well beyond the trial phase. Some of the most respected companies in the world were discussing their methodologies in use today and their vision for the next couple of years. The user community for SystemC design is now setting the direction. Japan has been a leader in SystemC HLS since 2000, and the attendees made it clear they intend to continue the push forward.

Why SystemC?
This is a question that never seems to get old.  Maybe it’s because for years EDA marketeers have told us ANSI-C is all you’ll ever need! The fact is that ANSI-C cannot handle real design and verification needs and the designers in Japan know it. Those surveyed at SystemC 2010 Japan said their SystemC usage falls into these 5 categories (multiple answers allowed):

• 52.7% HLS
• 44.8% Functional verification
• 33.5% Virtual platform / software design
• 30.5% Architecture design
• 1.5% Other

So why use SystemC instead of ANSI-C? It’s true that ANSI-C and SystemC can both be synthesized, but that’s not where the problem lies. The problem is in the modeling and design environment that you need to build. Sure you can synthesize a serial algorithm in ANSI-C — but real designs have hierarchy, concurrency, control and complex interfaces where data is exchanged in parallel. What about modeling a virtual platform and the design architecture? You could add non-standard language extensions or develop your own event manager (effectively creating a custom simulator), but is that what you want to spend your time doing? Let’s face it — ANSI-C just doesn’t cut it. SystemC was developed specifically to rectify ANSI-C’s shortcomings for hardware design.

SystemC is a C++ class library that is “hardware aware,” and there’s a lot of online material to help you learn about its advantages. Forte’s CTO, John Sanguinetti, has written a couple of articles about the topic. I’d recommend reading “Transitioning from C/C++ to SystemC in high-level design” that appeared recently at Embedded.com, as well as “I can’t imagine designing hardware in C…” that appeared right here in Forte’s CynCity blog. Read these and you’ll see why ANSI-C doesn’t work for anything more than trivial hardware design.

Want more? There was a panel about it at DAC this year! And while they probably won’t admit it, even the EDA vendors who trashed SystemC a year ago are starting to sing a different tune.

He went on to say that good hardware had such a high level of parallelism, he didn’t see how a compiler could produce that from inherently sequential code like what is written in a standard, general-purpose programming language. In his words, “though I wouldn’t write in assembly language any more, the output of gcc is crap. If it can’t do a good job with sequential code, why should I believe that a compiler can do a good job producing parallel code?”

My answer to him was along the lines of, “well, it really isn’t all that hard, and our customers have produced lots of real designs using Cynthesizer,” but that wasn’t a very satisfying answer. Here is the answer that I didn’t have time to give my friend:

1. You’re right, you can’t use C. We need to define what we mean by a programming language. Verilog (and VHDL) is a hardware description language, not a “hardware programming language.” However, it is also a simulation language, with a lot of similarities to Simula (one of the groundbreaking early simulation languages). We’ve been designing hardware in a simulation language for 20 years, so the basic idea is not all that radical.
2. Though Verilog (and VHDL) is a simulation language, it is not a particularly rich one. It is object-oriented (modules are classes, and instantiations are objects), but it lacks a lot of features that object-oriented programming languages provide. What it does have, however, are bit-wise operators and data types, and a standard module class which has ports, threads, and submodules.
3. Actually, Verilog (and VHDL) is capable of representing hardware at a higher level of abstraction than RTL, but it has one big drawback: it isn’t used for algorithm development, implementation or publication. Really, the only language that doesn’t have that drawback is C (or C++). Java is a distant second, and the other popular languages aren’t really candidates (M?, Fortran?, Perl?, Python?, Ruby on Rails?, …).
4. This is where SystemC comes in. C++ is a rich object-oriented language which is nearly universal and, since it is a superset of C, the vast majority of algorithms which are published are in C++. Being an object-oriented language, C++ has the ability to support a hierarchy of layers of abstraction, implemented by libraries of classes. SystemC is a library of classes which implements a “hardware abstraction layer” in C++. You can write the same code in SystemC/C++ as you would write in Verilog, at the netlist level or at RTL. That’s not particularly interesting — algorithms aren’t written at RTL in any language. What’s important is that you can also write code at a higher level than RTL, using C++ constructs. And, you can take a C algorithm, stick it unchanged in a SystemC module (that is, make it a method in an SC_MODULE class), and you have a starting point for hardware implementation.
5. Now that we have a structure for describing concurrent processes (a hierarchy of modules is a collection of concurrent processes), we’ve got something that a compiler (or high-level synthesis tool) can work with. Extracting fine-grain parallelism from a sequential process is easy (at least conceptually) — compilers have been doing that for years. Managing concurrency between processes requires a bit more work, but there is enough information in the source code for the compiler to do a good job.
6. Finally, the world of parallel vector supercomputers spawned a rich set of code transformations in the compiler world which could expose possible parallelism in sequential loops. Many of these can be applied to hardware synthesis. The end result is that a great deal of parallelism can be realized from a hardware description in SystemC.
7. So, implementing parallel hardware from a SystemC description can be done effectively. Generally, this part of the problem falls into the category of scheduling. That is, creating an optimal (by some definition) state machine, or set of state machines, to implement the described functions. Scheduling is a critical part of the high-level synthesis process. But that is only part of the problem. The other part is to implement the desired schedule in the smallest amount of hardware possible. That generally is called allocation, and that is the subject for another article.

The conclusion is that you not only can imagine creating hardware automatically from a C-related programming language, it is being done successfully by today’s high-level synthesis programs. At least, we can say it is being done successfully by Cynthesizer. It has taken quite a bit of time and effort to develop the synthesis technology to the point we are at today, where the vast majority of hardware designs can be done successfully with high-level synthesis. This will have a profound effect on how people do hardware design in the coming years.

They don’t ask it because it seems too obvious, or they already think they know what to expect. But the answer is not so obvious. Pose the question to yourself right now before reading on… what was your answer?

If you chose “productivity benefits” or some form of “faster time-to-RTL,” you’d be right–well, sort of.  There are several values and we’ll discuss five of them here.

Productivity
Certainly HLS promises and delivers great productivity improvements over RTL. Raising the abstraction level of hardware design means that the functional intent of the design can be expressed in fewer lines of code. Fewer lines of code should, in theory, take less time to write. The HLS tool then does a lot of the work in transforming the high-level code into RTL, creating the control FSM and the datapath. Oftentimes our customers see productivity improvements for real designs of 2-10X over RTL. Roughly speaking, that’s a gate count somewhere between 300,000 and 1,000,000 gates per engineer-year. Not bad!!!

Predictable Timing Closure
It’s usually unexpected, but during the RTL creation process users find that HLS has great value in timing closure. State-of-the-art HLS tools extract information from the user’s technology library (.lib), and, along with the target clock frequency, can characterize the performance and cost of each part. Based on user constraints, it can choose which ones to use when building the FSM and datapath. Different tools do this differently, of course, with varied levels of accuracy. Forte’s Cynthesizer uses an internal synthesis engine to estimate the area, speed, and power of each part at the gate-level, and then efficiently packs the operators and control into each clock cycle. The result is an RTL architecture that gets through logic synthesis and place-and-route smoothly, because Cynthesizer scheduled it with the target technology and process in mind. Timing closure problems are virtually eliminated, saving months of time and effort.

Less Time In Verification
As many a marketing person has stated, “verification is greater than two-thirds of the RTL design process.” Sure, that’s probably true, but the reason is because of the RTL design process itself. Think about it. RTL designs have thousands of lines of code, are insanely complex, and the code doesn’t get to the verification team until the end of the design schedule, leaving little time to verify the design. And with incredibly slow RTL simulation times, it’s no surprise RTL verification would take so long.

What if the verification team had a super-fast, accurate model of the design months earlier in the design process, a model where the functionality, architecture, and even the interfaces are fully specified and “simulatable”?  A SystemC HLS model can provide just that–an early, accurate, fast, executable specification. Cynthesizer can then compile this model and produce a unique RTL architecture for each set of user directives (more on that later). More importantly, the RTL design can be automatically validated using the same SystemC testbench, significantly reducing the verification effort. There are even formal tools that can check equivalency between the high-level SystemC and the RTL. The result? An improved design and verification flow that lets you start verification much earlier in the process and reduces the overall design time.

True Design Reuse
Everybody reuses RTL, but the same comments about reuse come up every time: old RTL designs are difficult to modify, they have limited shelf life when changing clock speeds, and a lot of area is wasted when changing geometries because of inefficient silicon use. HLS provides true design reuse by eliminating the majority of implementation details from the model. A SystemC HLS model doesn’t include any technology-specific details of the design. It is focused on the functional aspects and relies on the HLS tool to add the implementation details. Because of this, many of the issues mentioned above in reusing RTL are never encountered:

• Modification of designs is only necessary if the function changes, and with fewer lines of code, the functional intent is much more clear.
• The shelf life of the IP is longer because it is not tied to a specific process and speed. The HLS tool can easily retarget the design for different technologies (even FPGA!) simply by changing the directives.

Quality of Results
Of course, no amount of productivity and verification improvements will really help if you can’t meet your performance, power and silicon area targets.  Designers looking to HLS for high-volume production designs are naturally skeptical that they can get better results with an HLS tool than by hand coding RTL. This is not unreasonable, and some of the other HLS tools are pretty good on productivity but force users to sacrifice QoR. This is simply not true for Cynthesizer. You can expect to achieve just as good a result using Cynthesizer as you would if you wrote RTL by hand. This is not done by waving a magic wand. The user has to apply engineering skill to organize the design and drive the tool to get the best results, but it’s been proven on numerous production chips that Cynthesizer lets users take HLS all the way to the finish line.

So, there you have it.  If you are looking to adopt HLS design, you now know what you can, and should, expect.

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.

• 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.