Why is a new language necessary? Because most hardware designers are still stuck with RTL, and because today's High-Level Synthesis (HLS) does not live up to its promises.
Register Transfer Level (RTL) is pretty self-explanatory -- you think in terms of registers and how data flows from one register to the next. This closely matches what happens physically, which is another way of saying that it is a very thin layer of abstraction. In turn, this means that you spend a lot of time dealing with implementation-level details that would not concern you if you were working at a higher level of abstraction.
VHDL and Verilog are the two main historical languages for describing RTL designs. Both date back to the 1980s and -- in the grand scheme of things -- have seen little evolution since then. Recent efforts to improve on these two relics include open-source initiatives like MyHDL (RTL in Python) and Chisel (RTL in Scala). MyHDL is led by Jan Decaluwe, while Chisel was created at UC Berkeley with the goal of facilitating processor design.
At the other end of the spectrum, we have HLS. We can think of today's HLS as your manager's solution. It was sold to her or him (at a premium) as a way to increase productivity and obtain the same performance as RTL. The problem is that this is not what engineers see in practice. Outside of HLS's comfort zone (regular loop-and-array DSP code), you need to be a seasoned hardware designer to succeed in obtaining a good implementation. Why? You need to have the architecture in mind and be able to describe it to the tool, and knowing the result is generally hard to predict, since you have little control over scheduling.
The promise of HLS is that you describe your system using a software language, and you get good hardware. The reality is that you write this software representation either using a hardware-oriented framework or with hardware-specific pragmas, directives, types, and other tricks, in which case it's no longer software. All of this leads us to the question: "Why use software languages at all?"
Cx (formerly C~) is a new language for hardware design and verification. During the writing of our theses, we (Nicolas Siret and myself, the co-founders of Synflow) examined different solutions seeking to improve hardware design and verification, including HLS and domain-specific languages. Seeing that most solutions were not satisfactory, we decided to create a new language. What makes this language unique is that it is a good combination from both worlds -- hardware and software. We designed it based on our backgrounds -- Nicolas as a hardware designer and myself as a software engineer.
Cx is close enough to C in terms of syntax that it is easy to learn, and anyone with notions of the C-like "curly" syntax should be able to read and understand Cx code. This is a huge advantage over alternatives like SystemC that look nothing like normal code, which may explain why typical engineers need months of training before they can write good SystemC designs.
But it's more than syntax -- Cx is at an intermediate level of abstraction between RTL and HLS. By being higher-level than RTL, Cx makes it easier to go from specification to implementation in hardware. At the same time, it allows designers to retain enough control to create efficient designs. For example, Cx allows you to structure your code with functions and loops (for, while) while being cycle-accurate. You don't write state machines; it is the compiler's job to generate them from the code. A Cx design is structured in tasks that are instantiated and connected by networks. The language supports hierarchical descriptions (networks instantiating networks) and specialization: A generic task can be given parameters when it is instantiated to influence its structure or internal behavior.
Because Cx is a standalone language, rather than a subset or an extension of C/C++, the designer does not have to deal with things that do not make much sense in hardware, like pointers to access data or memory allocation. It also comes with good defaults -- for example, tasks are synchronous by default (no need to have/connect those "clock" and "reset" signals). Unlike with HDLs (and SystemC), you can actually declare your clocks, reset types, and whether a task should be combinational or sequential. Because this is explicitly stated in the code, rather than inferred, your code is protected from common mistakes, and it can be verified automatically.
In my next column, we will see how Cx compares to an HDL and to SystemC in practice when implementing an algorithm in hardware. In the meantime, I welcome your questions and comments.