High-level synthesis, verification and language

Abstract
The preferred high-level design methodology proceeds from high-level code to RTL code. Good verification practice requires that the input to High-level Synthesis (HLS) be verified first, via simulation (or some other analytical means), and then the output of HLS be verified, again via simulation or some other means. Using SystemC as the input language to HLS enables this flow, but using C as the HLS input language imposes a serious limitation on doing verification this way.

Introduction
High-level design has many advantages over the more commonplace design flow which begins with RTL code. Among the most compelling advantages is the improved verification efficiency which a higher level of abstraction offers. It is apparent to the point of being self-evident that when the source code of a design is created, there will be fewer errors if the source is at a higher abstraction level than if it is at a lower level. However, there is still a process required to verify the transformations which are applied to the design description as it proceeds through the design flow from creation to final realization.

Figure 1 shows the initial steps in the High-level Design (HLD) flow, without any of the verification steps shown. There is more than one way to place the verification steps in this flow, and the choice of where they go is heavily influenced by the high-level design language that is the input to the RTL Creation, or High-level Synthesis (HLS) step.

Figure 1. High-level design flow

Figure 2a shows how the verification steps fit if the HLD input language is "Plain old C"( PoC) - ANSI-C or C/C++ - and figure 2b shows where the verification steps fit if the HLD input language is SystemC. There is an additional verification step in the SystemC flow, which is labelled a validation step. For our purposes, verification means demonstrating that the design functions correctly. Validation means demonstrating that the design has the same functionality as a previous version of the design.

Interesting post, and indeed it makes much more sense to use SystemC than C, because to be synthesized into anything useful, you will have to rewrite a lot of code to the point that it won't really bear much resemblance to the original source. That said, writing SystemC code to design hardware is a PITA, and if you want to write something synthesizable by all vendors, you basically have to resort to RTL-like SystemC, which is about as ugly as it seems. Also, technically SystemC is not even a language, rather a huge pile of templates on top of C++ (which in itself is already pretty complex).

Why don't you use a modern language? A language that has first-class support for task-level parallelism and inter-task communications, that is a clean subset of the C syntax, without anything that makes no sense on hardware (like pointers and dynamic memory allocation). Oh and the compiler is open-source so you don't need to worry about us being acquired (like Forte and Synfora). Learn more at synflow.com and come discuss on our forum. Cheers!

John,
I agree with your position that verification of the architectural model should take place at a high level, not at RTL. Getting the verification flow right is where the biggest gains come from in moving to ESL design. However, Synfora offers this flow while maintaining design entry at the untimed C/C++ level. At this level, timing and parallelization is left to the compiler making the code easier to create and debug. In order to verify the architectural model at a high level PICO C Synthesis generates both bit accurate and thread accurate SystemC models to enable the superior verification flow that you outline. Readers can learn more at www.synfora.com
Andy Haines