Beyond RTL part 2: Domain-Specific Languages

This is the second part of my “Beyond RTL” series, where I examine alternatives to Register Transfer Level (RTL). The first part talks mostly about High-Level Synthesis, its genesis, and the state of the art of free and commercial tools that transform C/C++/SystemC to RTL. I highlighted the fundamental limitations that these tools have when it comes to transforming sequential software to hardware. In this post I present the other type of alternatives to RTL, using Domain-Specific Languages (DSLs). Domain-Specific Languages have the advantage of being more suited to a particular task than general-purpose languages. We’ll see first internal DSLs (a DSL that is embedded in a host general-purpose language), and standalone DSLs (a language on its own, that can be used for hardware design but not exclusively).

In the case of hardware design, internal DSLs are not so much an alternative to RTL as an alternative to the languages used to write RTL hardware, namely Verilog and VHDL. Examples include MyHDL (based on Python, see also Migen) and Chisel (based on Scala). These DSLs add a few hardware-specific syntax/semantics, restrain the host language’s constructs that can be used for synthesis to a well-behaved subset, allowing the rest in testbenches (this is how we call “tests” in hardware design). Although SystemC is generally presented as a C++ framework for system modeling, it can also be considered a DSL given the numerous changes/restrictions in syntax and semantics compared to vanilla C++. Hardware DSLs have the advantage to proposemodern alternatives to the ageing Verilog and VHDL languages, sometimes with significant improvement (the best example in my opinion how MyHDL models “current/future value” compared to VHDL/Verilog signals) while benefiting from a full-fledged language and development tools.

The main downside is that we have once again the same dilemma as in Verilog and VHDL: what constructs of the language can I use in simulation, and conversely, how do I write code that is suitable for synthesis? In the examples I mention (and probably in other similar embedded DSLs), the host language is often large or complex. If you think for a moment about the extent of what you can write in C++ (sub-classes with virtual destructors and friends, anyone? ^^), how do you limit yourself to the comparatively tiny subset that SystemC forms? An IDE (Integrated Development Environment) helps a lot when writing code (when designing hardware too, see the excellent post Philippe Faes of Sigasi wrote about this), but to be helpful in this case, the IDE must be aware of the DSL’s syntax and semantics, which is generally not the case.

The second family of DSLs that can be used for hardware design arestandalone DSLs. Like internal DSLs, there are a lot of standalone DSLs, I’ll give three examples related to hardware design, but feel free to suggest additional languages if you’d like to see them included in this post!

Let’s start with what is probably the most well-known DSL in the Electronic System Level market, Bluespec SystemVerilog (BSV). BSV is a powerful language that is architecturally transparent, which means that it is the role of the designer to express the architecture. BSV combines the most powerful aspects of Haskell (type inference, parameterization, polymorphism) with a SystemVerilog-like syntax (I highly recommend reading the first chapter of BSV by Example to learn about the key ideas behind BSV).
Another interesting language is a DSL for dataflow programming, which has been standardized by MPEG as RVC-CAL (based on CAL). This language coming from academia allows the description of architecture-agnostic dataflow programs composed of actors that send each other tokens via FIFOs. It is possible to generate efficient hardware implementations from RVC-CAL programs, depending on how the program is written.
Finally, we have created our own standalone DSL for hardware designhere at Synflow, which we have named Cx. Cx is a simple C-like language dedicated to hardware design. We have created Cx based on our experience with compiler development and hardware design, and because we were not satisfied with existing languages: we wanted to have a language that could be mapped simply to efficient, clean hardware, and that looked familiar, so it would be be easy to learn and to use.