Electronics have long been a part of our everyday lives, and are typically built on circuit boards.
Recently, the maker movement and falling costs have made design more accessible than ever.
Yet, mainstream board design tools still revolve around schematics.
This representation is much lower level than device architectures, while also being insufficient to support circuit design beyond data entry.
To align design tools with how people think about devices, we built a board-level hardware description language based on a block diagram model.
In our language, this example blinky LED code directly corresponds to the block representation, including block declarations and connections
Extending this with hierarchy allows it to scale across levels of abstraction, from system architectures, to subcircuits, to components.
Our example device’s IndicatorLed block itself is a block diagram, containing LED and resistor blocks.
Furthermore, defining the contents of these blocks programmatically, as generators, encapsulates design knowledge and methodology into code.
The IndicatorLed block automatically calculates the size of the resistor using the input voltage and by applying Ohm’s Law
This brings several advantages:
First, generators enhance re-use by adapting blocks to work in a wide variety of applications, instead of the limited conditions one block works under.
Second, generators separate interface from implementation.
Users only need to know what a block does and how to use it, without knowing how it works.
The knowledge of experts is packaged to be usable by relative novices.
Complex subcircuits like buck converters can be instantiated with a single line and without needing deep knowledge of sizing equations.
A type hierarchy over these parts also enables abstraction.
Similar to modern programming languages, this defines categories of parts, and more importantly, high-level interfaces.
The buck converter would be an abstract type, implemented by subtypes of concrete circuits built around specific controller chips.
Functionality-wise, abstract blocks can be substituted, or refined, with subtypes.
This block polymorphism preserves low-level control by supporting generic libraries that leave refinements open to system builders.
However, real parts do have physical limitations that ideal abstract parts don’t.
An electronics model enables correctness checks on refinements, such as maximum currents on this buck converter.
We also provide a graphical interface that complements the HDL with a more familiar and intuitive block diagram visualization,
and allows selection of refinements from a list of options, such as choosing the buck converter or overriding the default resistor type.
During compilation, the HDL and refinements are checked for model consistency. The generated netlist can then be imported into a mainstream board layout tool.
As with these example devices, the system can produce working and practically useful boards.
The more complex one, the datalogger, has a discrete microcontroller chip and subcircuit, and utilizes library power blocks like buck converter generators.
The top-level HDL is structured like a system architecture diagram, while libraries handle the heavy lifting of implementing those blocks.
To gauge usability, we ran a study focusing on realistic usage and recruited 3 participants with board design and programming experience.
After a tutorial session, we worked with them to establish an appropriate project, particularly one with a clean system architecture diagram.
All participants completed their designs, spending an average of 5 hours in our system to get to a schematic-equivalent.
Overall, participants liked the high level of design and libraries, which provided encapsulation and correctness-by-construction.
For example, these could reduce datasheet reading while preventing subtle mistakes, like forgetting pull-down resistors.
Participants also found the electrical model checks useful,
though also cautioned that these are still more sanity checks than design assurance, as the model isn’t comprehensive.
And while generators and part models are more time-consuming to write, this could have the benefits of re-use and sharing.
In the larger picture, trust and quality may be issues with using community libraries.
Most notably, all participants asked for tighter visualization integration for working with HDL.
Beyond simply a more familiar representation, this could also highlight structures not obvious in the HDL like unconnected pins.
For more details, including data models and implementation notes, check out our full paper.
We’re also open-source on GitHub, if you want to play with the system.
In conclusion, we’ve presented a hardware description language for building PCBs
using generators and block polymorphism to raise the level of design and capture expert knowledge.
We hope this lays the foundation for more efficient and accessible board design, towards the large-scale, community-driven collaboration seen in software engineering.