The only fly in the argument is that we need some way to take these high-level representations and transmogrify them into something that can actually be realized and implemented. How well I remember the mid-1990s when the buzz about behavioral synthesis first started to make the rounds. It all sounded so wonderful at the time! Sad to relate, however, our experiences with the early incarnations of this form of "high-level" synthesis technology left something to be desired.

The three big problems with the early high-level synthesis approaches can be summarized as follows. First, the input languages (typically traditional HDLs like Verilog and VHDL) were — if not "wrong" — then less than ideally suited for the task.

Second, the quality-of-results from these high-level synthesis tools was often unacceptable in that the output was typically too big and too slow (sometimes to the extent that it simply was not possible to tune the design to achieve the area and timing constraints). And third, it was difficult to verify the results in any reasonable way, because the process of high-level synthesis changed the timing of the code (with regard to the cycles in which actions occurred) to the extent that it wasn't possible to use the same testbench on the pre and post-synthesis representations of the design.

Arrggghhh (and I say that most sincerely), it's been a long slow haul over the last ten years. New tools have appeared hither and thither, each bringing a little something to the party, but none presenting the "all-singing-all-dancing" solution we were looking for. "Ah well," we kept on telling ourselves, "perhaps a solution will come in the not-so-distant future."

Perhaps the future is now

Well, perhaps the future really is now. I was chatting to the folks at Forte Design Systems recently, and I for one was jolly impressed with the epic tale they had to tell.

First of all, if we want to specify something at a high level of abstraction, we need an appropriate language to do it in, and one of today's stronger contenders is of course SystemC. Now, as I may have mentioned on occasion (to anyone who isn't fast enough to get out of the way), I pre-date most of EDA as we know it today.

When I was a young engineer, HDLs like Verilog and VHDL had yet to appear on the scene; similarly, object-oriented languages like C++ had still to make their debut. (Truth to tell, Verilog and VHDL might also be classed as being object oriented languages — but they aren't "rich" in this regard and we aren't used to thinking of them in this way).

Thus, like many engineers of my generation, I know enough to be dangerous writing in C (both software and hardware representations), but I never got around to dabbling in C++, which I therefore view with a certain amount of distrust. This is unfortunate, because when it comes to modeling hardware, you really can't do everything you need in standard C, which doesn't support concepts such as concurrency and bit accuracy.

Truth to tell, in-and-of-itself, C++ is also less than ideal because it doesn't offer native support any level of hardware abstraction. One answer to this conundrum is SystemC, which is based on C++ with a class library that supports clocks, concurrency, bit accuracy, and so forth.

The point is that we tend to assume everyone thinks the way we do. In this case, I've long taken for granted that everyone else regards C++ and related languages like SystemC with the same standoffishness as myself — but it's starting to dawn on me that perhaps I've been a tad hasty.

One of the points noted by the guys at Forte struck home when they mentioned a conversation with a customer in which they posed the question "How many of your designers are put off by C++/SystemC?" The customer replied "Well, my two best engineers know C++/SystemC and so do my two youngest engineers." Hmmm, we tend to forget that colleges and Universities are teaching the young folks all sorts of useful things these days.

The next concern is the power and robustness of the synthesis technology used to transmogrify the high level representations into their implementation-level counterparts. There's no point working with SystemC if you're only going to model things in RTL, because this doesn't let you easily explore the design space and its simulation speed is only a little higher than that of a traditional HDL.

What is required is a true high-level synthesis technology that allows us to capture designs at the algorithmic level and then generate architecturally-aware RTL that both meets timing and area constraints and is faster and smaller than the RTL we could generate by hand.

Is this too much to ask? Well, the folks at Forte would answer with a resounding "No, it jolly well isn't, because we can do it!" Over recent years, Forte's Cynthesizer has evolved into a true system-level synthesis tool. But before we look at Cynthesizer, let's take a step back and remind ourselves what a digital design team working with an algorithmically intensive design has to do.

We start with the algorithm in one form or another (traditionally this has been presented to the hardware team as a C/C++ model or as a paper specification). During the architectural phase of the design we perform tasks such as modular decomposition (this sounds better than saying "partitioning the design into modules") and structural elaboration.

Then, during the RTL phase, we introduce the concepts of cycle timing, scheduling, resource allocation, control path design and optimization, and data path design and optimization. Finally, we use RTL synthesis technology to generate the gate-level netlist we will ultimately use to build the little scamp.

So how does Forte's Cynthesizer help us on our quest? Well, it performs most of these tasks for us, which is music to my ears and causes a little tear to roll down my cheek. We start off with a behavioral-level model of the algorithm in SystemC.

This is augmented (or "wrapped" if you will) with a "protocol", which is a cycle accurate representation (also in SystemC) of the interface to and from the algorithm. The algorithm, protocol, constraints, and technology library information are then presented to the Cynthesizer tool (Figure 1).

Figure 1 — Cynthesizer performs painful, time-consuming tasks

In turn, the Cynthesizer performs all of the painful, time-consuming tasks for us, including the scheduling, cycle-timing, resource allocation, control path design and optimization, and data path design and optimization tasks noted earlier.

One key feature of Forte's approach is that — due to the use of the protocol (interface) portion of the design — the testbench used to verify the original SystemC model can also be used to verify the synthesized RTL representation. Furthermore, the same testbench can be run with the final gate-level implementation if required.

I think that, on occasion, we've all imagined the surprise on our friends' faces if we could take a modern electronic product such as a notepad computer, PDA, or cell phone back in time say 20 or 30 years and demonstrate it to them. Well, exactly the same thing applies to today's state-of-the-art tools like Cynthesizer.

If I could take this little rapscallion back just 10 years and exhibit it to my compatriots of the time, they would be agog with excitement and delight. And so, with that thought in mind, it's an official "Cool Beans" from me for the guys and gals at Forte. Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.