Posted by s.aragon on 27 April 2017 - 9:00am

By Edward Fisher, Agile Tomography Group, School of Engineering, University of Edinburgh, and Software Sustainability Institute fellow

Originally posted  at edwardmdfisher.com.

Here at the Software Sustainability Institute, we strive to promote best practices in software development for research. Better Software, Better Research. That’s the motto. But does this need to be restricted to software languages such as C, C++, Python or Java? Or should it be restricted to the ideals of open data and open code?

My view is that sustainability can also be significantly included in other domains that use textual description as part of the design process. My role within the Agile Tomography group here in Edinburgh is to develop hardware, firmware and software that enables custom designed, precision instruments to perform often in harsh environments. If we go down a custom route for something simple such as a data acquisition system, the role of the scientist or engineer must touch upon everything from PCB design, analogue and digital circuits, embedded firmware and digital logic, and indeed embedded software running remotely from the end user’s personal computer. Depending on the application of an instrument, we may become involved in the physical layer of a communications system—the very nature of how bits of data are transmitted, encoded or how the protocol is adapted to the needs of the application. Quite simply this must be done in a sustainable manner; otherwise, project complexity will quickly swamp us.

So how can sustainability help hardware and firmware development and what problems arise if sustainability is not incorporated from the start? To investigate, I'll let you all into what hardware, firmware and embedded software engineers typically develop, what we get frustrated by and of course what can be done to prevent the proverbial, and painful, head and wall interaction during strenuous debugging activities.

Text as Software and Hardware

Verilog and a related language called VHDL are textual descriptions of digital logic. We can model or describe an AND gate, an OR gate or a complex system such as an Ethernet medium access controller (MAC). We can describe structures that act as memory, or state machines that allow other circuits to be controlled in a deterministic way. Both languages can be used to describe physical gates that can be "synthesised" onto silicon integrated circuits (ICs), or onto reconfigurable logic devices called field programmable gate arrays (FPGAs), i.e. literally a large 2D grid of configurable logic cells.

In the case of silicon designs, despite being a textual description, the design becomes hardware, as once that silicon design goes to manufacture, it literally becomes set in stone. For Verilog used for FPGAs, the design is still synthesised to physical logic gates, i.e. hard, but as we can change the design or the connections between gates, the design is described as firm rather than hard. It inherently allows some of the adaptability that makes software "soft".

The clue however for sustainability, and the inherent link with the Institute, is that Verilog, VHDL and SystemC are all written as a text file. With inputs, outputs, sub-processes, functions, modular designs, comments, data types, error handling and many other concepts from the software development handbook, the role of the development team, or even the lone developer, can be made more sustainable, more robust, more transferable, more open, and better experimental data can be obtained. The motto "Better Software, Better Research" now becomes "Better Firmware, Better Research" and "Better Hardware, Better Research".

So, what do we mean by a textual description of hardware or firmware? To find out, let’s describe a simple flip-flop, possibly the lowest of the lowest level in computer architectures. In this context, several flip-flops create a hardware register no different to the registers used to hold data near the arithmetic unit of the CPU in your computer.

In terms of code, this looks very similar to some software languages. Perhaps the only differences are Verilog specific syntax and keywords such as "always" or "reg". But what does this do? Well, it is an 8-bit register that is clocked synchronously with a global system clock, perhaps 100MHz or 1GHz. It accepts a control signal: that if high ("1") allows the register to iterate by one. It can be reset in a manner asynchronous with the clock and, as with all good descriptions, it includes all states that are part of the flip-flop’s truth table—hence the hold state.

The Institute strives to get best practices into the minds of the developers within academia. But where should we start with hardware and firmware descriptive languages? What software best practices can be directly ported into the world of digital flips-flop registers, AND gates, OR gates and digital counters?

As code developed within industry shows, Verilog and VHDL are highly amenable for software development concepts. This may include code headers, robust commenting of cidem logical naming conventions and variable parameterisation able to accept a wide variety of settings and values for cross application usage. Code that ends up widely used and shared by many within a team, within a company or within a research group may also have a highly modular design, perhaps unit and sub-unit testing, robust version control, and of course will hold the ideals of design for test (DFT) and design for reuse or adaptability as central themes.

Hardware and firmware developers working within the academic sector should not be afraid of these concepts, although the uptake of sustainable practices is painfully low in many university engineering departments. In the long run, the choice to implement a version control server may be hard work especially if the design team is predominantly a single developer as with my custom data acquisition system development. But that shouldn’t stop the use of the underlying principle, as I can safely say from experience that managing multiple versions without robust version control can be its own source of that fabled head banging on the wall!

Within industry, the above concepts are the bare basics of the development role, if your code is insufficiently readable for another developer, it simply will not be used for release into a complex product. The risks to a company’s profits and reputation are too great to allow sloppy code to be included. In the worst case, code without sustainability included from the moment the empty file was created will need an experienced developer to debug it, and the timelines for a product will be extended or deadlines will be missed.

Let’s take one of the key sustainability concepts and see what it implies for development and what would happen if we just "didn't bother". Let's use naming conventions as an example, again as I've had first-hand experience of where this can become a problem.

Naming conventions when developing code allow a set of developers to easily read each other’s code, to easily distinguish which out of different types of interface two signals are or to separate data signals from control signals. For the flip-flop register description above we had "sys_clk" and "enb_iterate", this seemed reasonable as the lower-case allowed these wires to be separated from the upper-case registers ("OUR_REG" etc.). But what if we instead named the reset to "r" and the register to "r_c" (both of which I've seen before). An experienced developer could quickly go through the code and find that "r" is the reset, but from the modules port list, i.e. its inputs and outputs, we may have only "r" and "r_c". If the developer only knows the code implements a counter, then "r_c" could be easily be mistaken for "reset counter" rather than "register counter".

Likewise, I've also seen someone call a digital register's (D flip-flop) output as "Q", quite simply as the typical international logic symbols for flip-flops, OR gates and AND gates often use "Q" to denote the gate's output. But in a complex system, you cannot have multiple buses called "Q", and you cannot have a counter output and a control output both called "Q" or something like "Q1" and "Q2". When asked to debug such a piece of code, which bus should we look at with an oscilloscope? If the developer chose not to provide any documentation of what "Q1" and "Q2" are, then the debugging engineer is forced to go back to the code, pick apart variables, debug and fix, and most likely rename variables to fit with the robust naming convention within the rest of the design…

Sound frustrating? Very!

Conclusions

So, what should the Software Sustainability Institute recommend if you are new to developing firmware of silicon hardware using Verilog, VHDL or SystemC? Above all, don’t be afraid to include software sustainability as part of your development, it will reduce debugging overheads, it will help manage large complex systems and allow projects to be managed better if another developer or even your future self comes along. Concepts such as code parameterisation may even save you from extra work in the long run as creating a serial interface for an 8-bit system, a 16-bit system or a 32-bit system becomes trivial.

In the end, though, new developers should think about the risks of poor code within their project. If results are poor because of data glitches, perhaps time-consuming debug is needed, which may prevent you getting that all-important paper out of the door. The overhead of hardware, firmware and software sustainability is low when compared to the risks of not doing so. Of course, you could be lucky, but then why take the chance in a complex system?

Believe me; it will be worth it.