- Hi everyone.
I'm Richard, a Ph.D. student
from University of California Berkeley,
and today I'm going to talk about
how circuit board design tools can
more meaningfully support design.
But first, since I assume not everyone here
lives and breathes electronics,
let's start with a motivating scenario.
So let's say a maker wants to build something.
Well fortunately, 3D modeling and 3D printing
are both widely approachable technologies so
mechanical parts like enclosures aren't really a problem.
And many modern devices, especially interactive ones
are built around electronics.
But thanks to the rise of plug and play kits
like .NET Gadgeteer
or beginner-friendly development platforms
like Arduino,
building simple prototypes also isn't a problem.
What is a problem, however, is getting
beyond curated gardens of simple prototyping.
If you can't find what you need
in a prototyping-friendly part
or the fragile mess of breadboard wires is unacceptable
then your next step is to design and
build a printed circuit board.
And many tools exist for printed circuit board design today
such as Eagle, Altium, and KiCad.
And all these share the same basic design paradigm.
Users start in graphical schematic capture
like you see there where they interactively add
and wire up abstract representations
of electronic components.
The circuit can then be opened in a board layout tool
where they place physical representations
of those components and route conductive traces
between them.
And given the usability engineering put into these tools
over the years learning the interfaces generally
isn't the problem.
Rather it's what the tools don't do.
Users must understand circuit design and all it's
intricacies like checking for maximum ratings
and compatibility.
And the thing is, graphical schematic capture
actually dates back to the 1980s as an improvement
over the then dominate technique
of entering the lists of parts and there connections
like that example over there.
However, today's world is very different.
Characterized by massive increases in computational power,
expectation of more automation and the need to serve
non-professional users.
That being said, there's been some recent work on improving
electronic design tools.
For example, circuit synthesis from resource requirements
with embedded design generation
and using behavioral level design to build hardware
with trigger action circuits.
But these systems mainly target designers
and really with the exception of a workshop study on novices
we don't know how much about how people design electronics
today.
Are we sure we're build the right thing
and will it scale beyond novices?
So, I think there's a lot we can learn
by examining current practices
and for designers of future systems knowing what works,
what doesn't, allows us not to repeat the same mistakes
or waste time-solving non-problems.
So, in the rest of this talk, I'll go over the methodology
and results of our study into current practices
and armed with our primary finding that
the bulk of the creative work happens in system architecture
outside tools.
We then propose a concept for tools that work at this
higher level of abstraction.
From that, we create a click-through mock-up
which we use to elicit feedback from
our list of initial participants.
There's several ways to approach such a study
but given the lack of existing work
we opt for breadth rather than depth.
Therefore, we ran a semi-structured interview study
examining design practices from idea to final device.
We started by asking for an overview of
the high-level design steps in this flow.
Then dove into detail about each step,
including tools used and pain points.
This wide scope allows us to not only learn
about board design practices
but also look for areas underserved by current tools.
Overall we interviewed fifteen participants
with experience levels ranging from beginners,
building LED boards, to industry professionals
working on power converters and consumer electronics.
Interviews averaged ninety minutes.
We then conducted open coding passes over transcriptions
and ended with codes preliminarily organized around
motivations and methodology.
From these, we looked for themes with design implications
for tools.
And while everyone's design process varied,
there was much similarities in the over-arcing steps.
From this, we were able to construct a superset flow
and this process starts with ideas and specifications.
which could be anywhere between user stories
like this led should blink when the button is pressed
and technical requirements for system interoperability.
However, these requirements
and generally, any step in the flow
often were revised later as designers learn more.
Next, would be refinement into a system architecture
often represented as a block diagram.
The goal here is to map how the implementation for the idea,
figuring out the high-level technical details
of how to build it.
These blocks could either be high level,
like microcontroller or LED.
Or low level specifying subcircuit designs
and part numbers for major components.
Or often a mix of both.
And as such, this free form nature was the important aspect.
And these diagrams were typically drawn with pen and paper
or graphics software.
Prototyping often follows with the goal being to validate
and iterate.
Hobby designers might wire up circuits by hand
while industry engineers might iterate on circuit boards.
Boards were built according to the current
dominant methodology of schematic capture,
followed by layout.
In schematic capture, concerns were very low level.
Mentions of layouts and readability
were basically as common as circuit design
and functionality.
Manual transcription was a common process here,
such as from reference schematics.
And board layout follows
but since this talk revolves around circuit design
i'll leave the details for the paper.
One unexpected but crucial finding
is that parts are selected at various points
throughout this design process.
Major ones like chips could be determined
during system architecting.
Supporting components would sometimes be specified
during schematic capture.
And generic passive components might not be finalized
until component ordering.
While at the end of the day,
all components must be fully specified,
this is a good indicator of which parts are important.
Overall, the most important take away here
is that significant design work happens outside
the PCB tools often on pen and paper
or with parts catalogs.
And as far as circuit design goes
once you get into schematic capture
a large chunk of it actually ends up being data entry
and transcription where there's much less creative freedom.
Basically, this data suggest that schematic capture
is a pain point.
There's a lot of manual and non-creative work.
So, how can we rethink circuit entry?
The system architecture level of design
seems to be a good place to start.
Participants generally enjoyed this stage.
And the block diagrams captured design intent
without getting to mirrored
and tedious implementation details.
Here's an example of such a diagram
for a data logger device.
Modeled of the abstraction our users described.
The ideas that a microcontroller records temperature data
to a micro SD card
and step down voltage regulator powers these parts
from an external supply.
One insight is that both the system architecture
and schematic are block diagrams
and so we can support this higher level of design
in a familiar interface.
In fact, some current tools do take a step in this direction
with hierarchy blocks where subcircuit can be placed
as a block or component.
The main difference though is support for ambiguity.
Architecture diagrams specify only
what the designer cares about,
which may not be a complete circuit needed to build a board.
For example, we ask for a step-down regulator
in our system architecture here.
But we didn't specify a particular part or even a topology
which are all choices necessary for a complete schematic.
In this example, I have chosen a linear regulator
but it would also be reasonable to have a buck converter.
And to build boards from this level of design,
what we need is a solver that can intelligently choose
between alternatives in this design space.
However, the intelligently part
requires a model of electronics to ensure a correct circuit
such as obeying maximum part ratings.
For example, if we decide to use that linear regulator there
it's inefficiency would lead to excess waste heat
and result in a very toasty component.
But if used the switching buck converter
its higher efficiency makes thermals much less of a problem
and once we have settle on a topology
and parts getting a schematic out
is just a matter of dropping in a subcircuit.
Yet there are also subtleties in getting this correct,
while the reference circuit structure
for buck converters is well known
choosing components is much more involved.
For example, TI has that application note,
right there, about sizing capacitors and inductors.
The insight here is that equations can be written
in a programing language and executable
so this component sizing process can be automated.
For example, the inductance equation shown right there
can basically be expressed as a function of the input
and output voltages.
But since we're using a programming language,
we might as well also instantiate the components
and their connectivity here too.
In fact, this hardware construction language approach
is common in chip design but for us,
it's a potential alternative to block diagrams.
So to recap, the idea here is to basically to allow users
to specify design at the system architecture level
and the solver would then chose a suitable implementation
for each high-level block,
for example, selecting the buck convertor
for the step-down regulator.
And this implementation could then be instantiated
by a generator that encapsulates the intricacies
of circuit design
but these concepts are just well, concepts.
There is still a lot of uncertainty.
Is this abstraction useful?
Is it sufficiently powerful?
And does it address real pain points?
So, we ran a set of follow up interviews
to pitch this idea to users and get feedback.
We built a click-through mock-up of a design flow
through the data logger design
that we've been using as a running example.
These add a degree of concreteness
and familiarity to an otherwise abstract purposal.
These mockups started with an empty canvas.
Then we showed adding one part interactively
and then we fast-forwarded to the system architecture
diagram that you've seen already.
The system would then solve this design
by choosing a concrete implementation
for the high-level blocks like we did
for a step-down converter.
And at this point, the design is functionally equivalent
to a full schematic.
Theoretically, exportable to a layout tool.
In the interface, the right pane shows details
of the selected block including parameters
to convey the parts model and a listing of refinement types
to indicate the solution space.
We also walk users though the harder construction language.
We started with the same data logger design
as a conceptual bridge then moved into
this buck converter example previously discussed.
We asked open-ended questions about advantages,
disadvantages, and applicability for each interface
compared with both each other and mainstream tools.
Ten of the fifteen participants returned
from the initial round of interviews returned
for this follow-up study.
Interviews averaged 46 minutes
and we used the same open coding procedure for analysis.
Overall, the reactions were positive.
One main benefit of our purposed approach was much tighter
integration.
This included integrational parts data
which could enable accurate circuit correctness checks.
This would automate a currently manual process that was
tedious and sometimes error prone.
Being able to select parts in the same design interface
was also convenient rather than flipping
between multiple websites and tools.
However, participants also noted that the system
heavily relies on libraries which has potential drawbacks.
One issue was trust and correctness.
Participants have various criteria to infer
the quality of third party libraries
such reputation of the author.
They also talked about post generation verification
which varied from connectivity spot checks
to confirming datasheet specs.
One insight was a comparison of block diagram interfaces
and hardware construction languages.
While all participants seemed to understand
the language approach and its power for parameterized
or repetitive designs it was seen as less useful for
more straight forward or connectivity designs.
Learning curve was a frequent mentioned disadvantage
and some just preferred a visual schematic.
Finally, an interesting but unexpected discussion
on interactions arose from the question about
acceptable solver run times.
There were two broad groups here, with an equal number
of participants in each.
The first group was fine with batch runtimes where
the solver could take minutes to hours.
Tools would be faster the manual processes
or churn away in the background perhaps even overnight.
The second group wanted interactive runtimes,
where solver operations would complete in seconds.
One idea was a modified version of the mock up flow
which could solve selective subsets of the design.
Overall, the mock ups indicate that the idea is definitely
promising.
However, while we try to maintain an internal consistency
and realism in our mock up flow its no substitute for having
the real system.
So are logical next step would be to implement the
system, run user studies and hopefully learn
more about effective design strategies.
Its also important to note that these results are not
necessarily limited to electronics.
High level design with support for ambiguity
could also be used in mechanical CAD.
One might, for example, design an enclosure like that
with a cut out point for a push button switch.
And the exact geometry of the cutout
would depend on the switch that is
ultimately selected.
Further more, the enclosure designs itself can be
be parametrized using generators instantiating the same
basic pattern in many sizes.
In summary, we observed that much of the creative work in
current electronics design practices happens outside
board design tools.
Our main design insights then, is that system architecture
level of design with support for ambiguity,
parts modeling and generator languages are potential
mechanisms to bridge this to a fully solved schematic
equivalent circuit.
We would like to thank all out participants
and funders.
And we hope that our findings will lay the foundation
for a new generation of tools that enable designers
to work more efficiently and effectively.
(clapping)
- {Professor] Okay, so time for a few questions
before we go into the coffee break
- [Audience Member] Thank you. Very cool talk.
So debugging a circuit that you built is very hard
but perhaps much, much harder is debugging a
circuit that someone else built, right.
So I think were you to build this tool you might
run into an issue similar to if you were doing
the auto complete system we saw before where
if it works, great.
If it doesn't now you have this problem of
learning what were the actual elements
that were instantiated here, how do they interact
and where do the issues arise.
But one thing that I noticed that's interesting
is in this concept of solver your sort of already
put thought into where these issue might occur.
What sort of gotchas and gimmes I need to pay attention to.
Is there anyway that you might be able to organize
or highlight to the user when things go wrong
which of these gotchas or gimmes might be there
relevant thing they should learn.
- I see. So, let me think about this for a moment.
I think our idea here is, we have the goal
at least is to have an sufficient electronics model
where in most cases you would not be able to mess up, right.
Like it would model things like absolute maximum voltages,
maximum currents which are probably the most
common issues.
Now of course there are higher level issues
like RF interference or possibly even thermals or like
higher, high frequency issues
and you know those are hard problems.
Maybe the solution is just we'll incrementally
play whack-a-mole with those
as people encounter those issues
and extend our models.
But yeah, debugging is hard.
- [Professor] More questions?
Okay.
Let's thank our speakers and Richard once more.
(clapping)
- [Professor] Okay, after the coffee break there's still
one more session for today.