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.

The second part of our series on modular interfaces deals with external memories. It’s unavoidable when you’re designing at an abstract level–at some point you’re going to need a memory. High level algorithms, by nature, make extensive use of loops that operate on arrayed datatypes. Not all HLS tools handle external memories well.  With some you have to schedule the memory interface by hand!  There are several different ways that Cynthesizer can implement those arrays for you, but it is when they become external memories that Cynthesizer’s modularity really shines.

Arrays In HLS
Let’s say you have an array in your design, maybe something like this:

sc_uint<16> mem[16];
…
for ( int i = 0; i < 16; i++)
{
    acc = acc + coeff * mem[i];
}

What can you do with it? Well, in Cynthesizer there are three things you can do. You can:

• Flatten it
  • Using a directive or command-line switch, Cynthesizer will flatten the array into individual registers. This is helpful if you want a short latency—your architecture will have access to all array locations in the fewest possible cycles.
• Make it an internal memory
  • Using Cynthesizer’s Memory Model Editor, you can create a memory model that Cynthesizer will allocate to store your array. This is good if you have a few extra cycles to spare and don’t want the added muxing of a flattened architecture.
• Make it an external memory
  • Using the same memory model, you can instruct Cynthesizer to implement the memory externally.  Cynthesizer will synthesize an interface to this memory for you. You will not have to worry about controlling the address, data or enable ports.

It is the ease of making a memory external (and the lack of changes required to your SystemC source code) that we will get into now.

Going External
So you want your array to be an external memory? First thing you need to do is build it. To do that you can invoke the Memory Model Editor in the Cynthesizer Workbench GUI. Here’s what it looks like:

[Click to enlarge]

There’s actually not that much you have to do here. We set “Word Size:” and “Number of Words:” both to 16 to match our array’s size and indices. The “Latency:” is 1 by default, and the “Setup time:” and “Output Delay:” should be a nonzero time value based on the data from your technology library. And since this memory will be external, the “Area:” is 0.

By default this will be a single-port memory. If you want something different you can click the “Ports” tab, where you can increase the number of ports, edit the names of the address and data lines, specify any enable lines or masking, associate each port with a clock or reset, and configure the ports as read-only, write-only or both.

But the real power for us is in the “Internal memories” and “External memories” boxes where you can specify chaining or registering of the memory I/O. That’s right, the SystemC memory model we create will be usable as either an internal or external memory.

So once we’ve generated the memory model (I called it “mem_part”), how do we use it? All you have to do is turn your array declaration into a memory port instantiation. Previously we had this:

sc_uint<16> mem[16];

now we have this:

mem_part::port<ioConfig, sc_uint<16> >  mem;

port<> is a templated class in the generated SystemC memory model that represents an external port connection. Its arguments are the I/O configuration, which can be defined for TLM or pin-level simulation, and its datatype. The memory model will also have to be connected to clock and reset but there are high-level functions available to do that.  Why, you ask, do we have to do all this?  Chances are you chose an external memory because it needs to be shared with other modules.  The classes like port<> make it possible to accurately simulate intermodule communication through a shared memory at the behavioral level.  With other tools that use ANSI C or don’t have customizable interfaces, you have to wait till you have RTL to verify anything like this.

What do you have to do to the source code? Well, nothing:

for ( int i = 0; i < 16; i++)
{
    acc = acc + coeff * mem[i];
}

The array access looks exactly the same as before. Cynthesizer knows to associate your array access with an external memory port, and it schedules the interface automatically based on your latency constraints.  The external memory has become a truly modular interface, and it was all created for you. If you generate RTL for this design you will see the synthesized interface in the port list:

module dut(clock, RSTN, inp_busy, inp_vld, inp_data, outp_busy,
           outp_vld, outp_data, mem_WE0, mem_DINw, mem_DOUTw,
           mem_Aw, mem_REQ0);
  input clock;
  input RSTN;
  …
  input [15:0] mem_DOUTw;
  output mem_WE0;
  reg mem_WE0;
  output [15:0] mem_DINw;
  output [3:0] mem_Aw;
  reg [3:0] mem_Aw;
  output mem_REQ0;
  …

Next time, we’ll take a look at the techniques used to build custom modular interfaces using Cynthesizer’s Interface Editor.

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.

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.