We Don’t Need Graphic Design. We Do Need Graphic Views

Many years ago, there were attempts to (re-) introduce a graphical entry approach to building RTL design. The Renoir product was one example. The idea has some initial appeal. You describe the behavior in a small block using (textual) RTL but the larger structure of instances and higher-level connectivity can be described as a schematic or flow diagram or something similar.

These attempts were not successful for all sorts of reasons. In part, this area is great example of the devil being in the details. The concept is very appealing on a small design with small components, but a large component in an SoC may have 1k or more ports (full ports, not bit-blasted) which would be a nightmare to connect graphically. And an SoC top level can easily need 100k connections. Even in small subsystems, you can type or auto-generate connectivity faster. It simply isn’t practical to create and edit large netlists graphically.

Another problem with graphical creation and editing is that the graphical view has to become the source-controlled view (so the RTL becomes a derived view), otherwise you would lose schematic layout information on checkin. And by the way, that layout is a real pain. Significant effort has to go into creating a readable diagram, effort that has no value to the ultimate purpose of the design. Why bother?

Text editors, augmented by spreadsheet or other generators, remain the easiest way to assemble and modify these large netlists. Fancier approaches tend to generators, as in generators for bus fabrics where you specify major interfaces, protocols and other parameters and let the generator build the RTL. You still need to source-control spreadsheet and configuration information as views, but these are textual (CSV or similar for a spreadsheet), and in standard or defacto standard formats so present no particular problem for any source management system.

So, forget about graphics? Well, not quite. Graphic creation and editing is a proven dead-end, but graphic viewing is a different story. A well-organized view can be a real help in debugging connectivity, also in navigating the design. The view can be generated directly from the RTL with no need to go through any special formats. The RTL is the golden source (as it should be) and is source-code controlled. The graphical view is a derived and stateless view – reconstructed from scratch on each read-in.

Sigasi (who I introduced in a blog a couple of weeks ago) sees significant interest in this concept from its FPGA customers. They already like the auto-complete, code-template and real-time debugging options in Sigasi Studio, which they find make VHDL/SV more accessible to people not so familiar with hardware development. They are very much opposed to graphical creation/editing which they feel cannot fit with agile development flows, but they see graphical viewing having a big opportunity. It is curious that these requirements are coming up in FPGA designs and in the context of agile development flows. This may be an indication of growth in software developers moving into (some) hardware development in Maker and IoT markets.

Of course we will always want to fiddle with the views to emphasize aspects that are of current interest. Philippe Faes, the CEO of Sigasi tells me they are working on a number of methods to support this kind of fine-tuning, either driven directly from the HDL or from a Tcl side-file.

Sigasi Studio supports this approach today for VHDL and is planning to add support for SystemVerilog. You can learn more HERE.

More articles by Bernard…