Printed circuit boards, or PCBs, are part of almost every modern electronic device.
In current mainstream practice, the circuit design is done in interactive schematic capture, where users place and wire up abstract components on a sheet.
This component-based, low-level representation makes schematics very flexible.
However, this also makes working with them tedious and difficult, requiring significant electronics expertise.
Recent work on hardware description languages, or HDLs, aims to bring benefits from software development to electronics design.
However, writing code to produce boards is an unfamiliar workflow for most current electrical engineers.
So, in this work, we explore how to bridge textual code and graphical schematics, using an integrated development environment, or IDE approach.
We build our IDE for Polymorphic Blocks, a board HDL which we presented at UIST last year.
Polymorphic Blocks has a schematic-like structure, with the basic elements being:
blocks, like this indicator LED,
and connections between these ports, like to the microcontroller.
The real power of an HDL is the ability to programmatically generate pieces of this schematic.
For example, we can wrap the LED and connections in a for loop to create an array of LEDs.
or even choose the resistor part number from a parts table.
Ultimately, this compiles down to netlists, which can then be laid out to produce real working boards, like these examples.
Participants in the user study all suggested better integration with the HDL writing process.
That is the primary motivation for this work.
Our IDE consists of the standard code editor, augmented with a block diagram interface.
We keep the text interface because it is still the most common way to write code
From the code, we can automatically produce a block diagram visualization.
This behaves similarly to schematic tools, except edits to the diagram also generate code in the HDL.
This provides users the flexibility of using either or both interfaces, as they prefer.
For example, to insert a block from the graphical interface, we start in the library browser.
We can filter parts by text search, then insert it into the design.
This also generates the line of code.
Since there are many valid positions to insert the new code, with code style often an important consideration, we leave the choice to the user by inserting at the caret.
The caret then advances past the new text, allowing for multiple edits in a row.
To provide a responsive interface, we add the block into the diagram speculatively and without requiring a lengthy full recompilation.
This assumes the new code results in exactly one block, and is indicated by the hatched fill.
The IDE also helps users connect ports by synthesizing relevant information not obvious from the HDL, such as:
highlighting the required but not-yet-connected ports, like these power and ground ports in red,
and once a port is selected, dimming out incompatible ports.
Like with block insertion, this generates code at the caret and speculatively updates the block diagram.
The code itself can also be edited at any time.
This allows the use of programming constructs not supported in the GUI, such as arraying resistors with a for loop.
Manually recompiling updates the visualization and allows continued operations on the block diagram.
The video figure and paper details a few more GUI operations, such as pinning footprints and inspecting block properties.
To get early feedback, we recruited four participants from a wide range of backgrounds, all with prior board design and coding experience.
Our study design starts participants with a detailed tutorial document, including step-by-step walkthroughs of IDE features and explanations of the generated HDL.
Then, we gave participants a standard project, a USB-powered light sensor with a visual readout.
Participants were free to use, or not use, IDE features as they deemed fit.
We concluded with a semi-structured interview.
One main observation was that all participants blended use of the graphical and code interfaces in their design flows.
Where participants wrote HDL using graphical edits, they also used the textual interface to refactor and rearrange the generated lines of code.
However, half of our participants used the text editor as the primary way to produce HDL, rather than the schematic-like graphical interface.
This seemed to be from a combination of individual preference and clunkiness in the caret-based editing flow.
Yet, IDE features were still helpful for writing textual code, such as using the block diagram as a reference, or the library browser to discover parts.
Our main takeaway is that hybrid graphical and textual interfaces provide something for everyone and can effectively support diverse workflows.
Furthermore, consistent with prior work, the simplest tools also tend to be the most widely applicable and used - here, the block diagram visualizer and library browser.
An important lesson from feedback on caret-based editing is the need to preserve flow, instead of forcing users to jump between positioning the caret and actions on the graphical interface.
Alternative ideas include smarter automatic placement that understands stylistic factors,
or refactoring tools that could split the reorganization into a separate phase.
All that being said, do keep in mind that this was a relatively simple, small, and short study, especially in the context of professional design tools that take much longer to learn.
We hope this kind of tooling can blend the best of textual and graphical editing, and ultimately encourage the adoption of powerful HDLs that enable easy and efficient hardware design for everyone.