Drawing schematics has been an essential part of electronics design for decades. Technolution has developed its own programming language to replace the drawing of schematics: the Hardware Description Language (HDL). Designing with HDL is quicker and more transparent and stimulates the use of building blocks.
Article from Objective 22, 2014
One drawing says more than a thousand words, but sometimes one word says more than a thousand little lines in an electronic schematic. A schematic is well suited to explain the functioning of an electronic circuit. But the more details the schematic contains, the less transparent it becomes. You might be able to understand the schematic of an analog circuit, even if all of the information is included in one image. Digital circuits, however, consist of so many connections that it is easy to lose sight of the whole. Some chips have more than a thousand connections. That means drawing a line from every single joint to another component.
Frustration and inspiration
To give just one example: connecting a piece of memory in a schematic means drawing 64 lines. Doing this by hand carries the risk of drawing wrong connections, even though you are only dealing with a single function: linking two data buses with each other. It is easy to write that down in words: connect data bus X with data bus Y. Drawing schematics for large and complex digital products and keeping them up to date is extremely labor intensive. The frustration that comes with the amount of drawing that has to be done and the corresponding risk of errors inspired us to think further: surely it must be possible to do this differently? More compactly, with a description instead of a drawing? Because part of the work is already done in words. The input for programmable logic is VHDL, a language that describes functions in the FPGAs. FPGA tooling produces a table that describes what happens at the edges (interfaces) of those chips, including all of the pins and their functions.
What is HDL?
HDL designs electronics with words; it is a domain-specific language (see the boxed text on page 7). HDL describes which parts are required to implement a function and how those parts are connected with each other. It makes it easier to input information. It means you can write ‘connect data bus X with data bus Y’ without having to draw 64 lines. Where necessary, you can include terminating resistors in the same line of text, meaning that you can implement 64 resistors in a single line. HDL is an object-oriented language. This means that you can assign all kinds of characteristics to your components, which the compiler will automatically check or use, for example whether the exit of chip 1 is compatible with the entry of chip 2. You can’t see that in a schematic.
The HDL compiler
The compiler reads in the HDL and checks it for syntactic and semantic errors. The compiler then carries out the calculations written in HDL and reports the results. Once the compiler has made a model of the entire circuit, automatic checks are performed. The last step is to generate the input for a PCB layout package and a corresponding Bill of Materials (BOM).
Component versus function
Every component in a design is there for a reason, but in a schematic you can’t see which one anymore. In a traditional schematic, you first calculate the resistors you need. That calculation is given in a separate document. Schematic and document have to be constantly synchronized. In HDL, the designer can simply write down in the design how he calculated the resistor that he has used. If something in this calculation changes, the HDL compiler will calculate the new value and will automatically adjust the resistor. This makes the design transparent and consistent. Furthermore, in HDL the designer only specifies a component’s required characteristics. In this way he makes the essence of his design choices explicit. We are choosing to write down only the crucial characteristics. In this way, it is possible to fit several components into the design. The compiler subsequently matches the components in the database with the specified characteristics, and chooses one component. General guidelines can be added to the design, such as measurements or preferred suppliers.
The compiler thus selects the right component on the basis of the parameters specified and calculated. The database contains maybe ten or twenty suitable components from which it can choose. If the selected component is not available anymore for a following product, this does not mean that the design has become useless; if the compiler is run again, it will again choose a component from the database – without requiring an elaborate redesign. In the same way, migration of technology (for example to smaller components) can be realized simply by changing a number of parameters. The measurements of the components can be specified in one part of the design. The compiler will then only select devices with the specified measurements. In schematics, adjustments like these cost a huge amount of work.
Timing constraints and physical requirements can also be displayed efficiently in HDL. What is the minimum or maximum distance between components? To what extent may the lines in the same data bus differ in length? In schematics, these issues don’t contribute to greater transparency, if they can be added at all. That is why an additional document is often required, necessitating more work for the designer and the layouter and increasing the chance of errors. In HDL these parameters are linked to the objects that are being used in the design; meaning that they are written into the design. It also means that they are automatically collected by the compiler.
Drawing versus language
Working with HDL can still go together with drawing a schematic. Even apart from the sketches and doodles that every designer makes on pieces of paper or whiteboards to organize his thoughts and create an overview. A schematic is still the best choice for certain types of circuit, such as analog schematics in which you want to be able to see what way the current runs. That is why we have included the option to add a schematic in the HDL compiler. An electrical supply, for example, or an analog filter. The compiler translates the schematic into HDL, and subsequently processes and checks the result in the same way as it does with handwritten HDL.
Highlighting the risks
Checking a schematic can be a lot of work. It’s much easier in HDL. The HDL compiler carries out a number of automatic checks. A logic-level check inspects whether output and input are compatible. And, on an even more basic level: did you connect the inputs with the outputs and not accidentally with each other? At least one transmitter and one receiver have to be fitted on each net (i.e. all connections linked to one copper trace). And if there is more than one transmitter, you have to check that they are not transmitting at the same time. These are small, simple mistakes that can now be checked very quickly with HDL. Any errors will become evident during the compiling process; you don’t have to wait anymore until the PCB is on the test bench. This means fewer design reviews are required and the predictability of the project is enhanced. The costs of an error rise at every successive stage of the project, so solving errors at an early stage saves money.
Short design cycles and building blocks
HDL allows you to realize a design more quickly and to make smaller iterations. This means that HDL is particularly suitable for Agile methodologies. And because it is text, versions can be easily compared: what has changed in a new version compared to the previous one and who made the changes? It is therefore easier to manage different versions.
HDL also makes it easier to put together an IP library. Our designers don’t have to reinvent the wheel all the time, but can simply reuse elements that were made previously by a colleague. Although this can also be done with schematics, in practice it doesn’t happen very often, because a ready-made IP block often doesn’t fit the scale of another schematic. In HDL you can use parameters to adjust the IP block to fit the scale of the environment in which it is going to be used. You can continue to build on the ideas (IP/building blocks) that others have had. If you have an amplifier as an IP block, you don’t have to think about it anymore. In this way you are able to solve ever bigger problems.
Innovation in processes
Apart from developing and delivering innovative products, we also like to look at our processes in an innovative way. We are constantly reviewing the way we work in our company: is it possible to do this more efficiently, better, more predictably, cheaper, with higher quality or more quickly? If so, we put it into practice. If the tools required for this are not available, we make them ourselves. HDL is a good example of our internal innovation. By reflecting constantly on our way of working and on the tools we use, we remain alert: old, well-worn paths don’t always lead to the brightest future.
We were excited about HDL ideas from the start and we therefore developed and implemented them in our own design processes. Of course this was a learning curve and it required a process of familiarization that has cost time, but the colleagues working with HDL quickly adopted it and are giving positive feedback. Since then we have made a number of significant designs with HDL, designs that have resulted in working PCBs.
We’re not there yet: we’re continuing to develop and optimize HDL. The current version can be used quickly and easily and has reduced the chance of mistakes. The experience we have obtained with HDL has provided us with a long list of ideas about possible further developments. We’ve made a roadmap for HDL and will continue to develop the necessary tools. We are challenging other designers and clients to come and experience HDL for themselves and to work with us on the HDL roadmap.
Programming languages such as Java, C and C++ can be used for all kinds of problems. But sometimes you’re trying to find a solution for a very specific application; that is not easy in a generic language. In that case, a domain-specific language or DSL can be useful. A DSL is a tailor-made language, designed specifically for a particular application or domain. It contains terminology and logical constructions that are used in that specific field. The language is designed in such a way that the designer can express more easily what he wants to achieve, in terms that people acquainted with the domain would use. SQL is a well-known example for databases, but you could also think of a language that a designer with traffic engineering expertise might use to describe the behavior of the traffic lights at an intersection. This means that the design can be read and understood by people who don’t know how to program, but who do have knowledge of that field.
DSL represents a higher functional level of abstraction compared to languages such as Java, and it is very suitable for model-based designs. But you can also develop a DSL for image processing, for instance to link a number of processing stages.