- All right, thank you!
So again, I'm Evan Strasnick,
I'm really excited to talk about Pinpoint,
a PCB debugging pipeline using
interruptible routing and instrumentation,
work done of course with my advisor Sean Follmer,
and Maneesh Agrawala at Stanford.
So, printed circuit boards are at the heart
of most of these devices that are comprising
our computing world.
Like this projector PCB which might be
in the display I'm using right now,
stretching my slides.
And they have a number of advantages.
They're compact, they're robust,
they're easily mass-produced.
But these PCBs also raise
significant challenges in debugging.
So to demonstrate the issues in debugging PCBs
with current tools,
I'll describe a small example board
and some bugs that we might encounter.
This is a simple game controller,
with a one axis joystick on the left,
and a capacitive touch button on the right.
So the first issue is access,
or how easily we can observe
or perturb behaviors within the circuit.
Here I'm having a problem where moving the joystick
has no effect on the signal,
and so I'm attempting to probe
the small pads beneath this mounted joystick
with a common tool like a multimeter
or an oscilloscope .
The compactness of PCBs and surface mount components
make simple observations like these
both challenging and error prone.
Next we identify issues of isolating
parts of a circuit while debugging.
Suppose I find a large amount of noise
coming from somewhere in my circuit.
The fastest way for me to identify the culprit
is to just try disconnecting parts of the circuit
and see how noise changes.
But, on a PCB,
components and connections are fixed with solder
and so they can't easily be modified.
So to isolate this capacitive sensing chip
from its power connection,
my best option might actually be to manually cut this trace.
And finally PCB debugging is hampered
by a slow pace of iteration.
It's likely the case that even if our capacitive button
works on a prototype version of our controller
like a breadboard, the capacitive characteristics
of the PCB will be different.
So therefore I'll need to adjust the value
of the sensing capacitor shown here,
and to do so I have to de-solder this component,
as I'm doing here with tweezers and a hot air gun,
and re-solder a new one.
Iteration is key to effective debugging
but unlike the more malleable breadboard,
we can't easily try out solutions
on a PCB without costly re-fabrication processes
that can take days when working with a PCB manufacturer.
So to address these three core issues,
our key insight involves augmenting the PCB
to make it more reconfigurable.
And to shift the debugging process
from using manual tools on hardware to using software.
We do this by adding in jumper pads,
pairs of test pads that we insert in series
into connections in the circuit.
We'll automatically instrument every connection
in our game controller schematic with one of these pads.
And in the result, each pin of each component
will be separated from the rest of the board
by a jumper pad.
Our fabricated board will include
these pads in the back side.
And as we'll see,
these jumper pads give us ways
to address the core challenges.
If we can probe them, we'll have easy access to
all signals in our circuit.
By controlling whether or not a pair of pads
is electrically joined,
we can isolate parts of the circuit at will.
And if we can connect external circuit elements
to any of these pads,
we'll be able to insert and replace
arbitrary and components in our circuit,
allowing us to iterate effectively.
But before I explain how we enable these interactions,
I'll quickly address existing solutions
for improving PCB de-bugging.
Our goals align with what we call in-circuit debugging.
An ongoing challenge to utilize the more
powerful tests at our disposal
without reworking an assembled board.
This includes various industry standard approaches like
optical pipelines from here,
for detecting structural issues,
or built in self test capabilities like J-tag,
to run tests from the pins of on board components.
While these techniques provide ways of detecting
particular bugs, fundamentally they can't modify
the underlying circuit topology while testing.
And therefore they don't facilitate isolation or iteration.
Work from our community has addressed similar
debugging challenges, but mainly within the
prototyping stages of circuit design.
The system to the left all target
breadboarded circuits and primarily improve access
by visualizing voltage, current, or code execution.
But debugging does not stop with the breadboard.
Making a PCB in fact brings all new bugs,
such as when mis-routing your pins
or encountering defects in the board.
Scanalog, earlier work from out lab leveraged
instrumented programmable boards to give
designers a prototyping platform with full access
isolation and iteration capabilities.
But as programmable mix signal hardware is not yet common,
we aim to bring these same types of interactions
to conventional PCBs in a tool that can be used
quickly and at low cost.
Which brings me to the design of our current tool, Pinpoint.
How does this actually work?
Well as before our first goal is to instrument
the user circuit with those jumper pads.
From a high level, Pinpoint's algorithm
adds a jumper pad for each connection
between a component and a net,
or a group of electrically joined components.
Here on the right, each component now can be
individually isolated from the others.
Pinpoint then determines where to place these
jumper pads on the board,
such that the backside of our game controller
now looks like this.
We'll find the best location for each pad
using a simulated annealing algorithm,
with a cost function that minimizes factors like
the lengths of addition routing required.
But ultimately we want programmatic control
over the boards connections.
And we want to debug in software with more
powerful testing techniques.
So for this, we need testing hardware that can
operate on the jumper pads that
we've put on the PCB.
We call this hardware Pinpoint's control board.
The control board connects the users PCB
with a software interface, through which they debug.
A set of analog multiplexers programmatically
route jumper pads on the users board,
to a USB oscilloscope and arbitrary waveform generator,
to not only probe the pads,
but also inject test signals into them.
Each jumper pad is bridged by a solid state relay,
which can programmatically open and close the
corresponding connection.
Control of these elements is all handled over
serial communication with a software interface
through and onboard microcontroller.
But we need one last element to interface
this control board to all the jumper pads
that we've put on the users PCB,
and to complete Pinpoint.
That final piece is a custom hardware interface
for each PCB that we call the Jig board.
During instrumentation, Pinpoint also generates
a design for a custom Jig board,
that the user fabricates with their original PCB.
The Jig has pogo pins which contact
the jumper pads on the users board.
So, to debug, the user simply mates
their game controller with the jig and
connects it to the rest of Pinpoint's hardware.
And so the entire system looks like this.
The users board, or what we call the device under test,
is mounted on the Jig board,
which aids the control board in performing tests
and observations.
The user can then debug entirely within
a software interface,
which I'll describe in a moment.
Now revisiting our bugs from before,
we can reflect on how this system
addresses our core challenges.
To observe signals from my thumb stick,
I can simply click on them in a software interface.
To isolate my capacitive sensor and determine
its impact on noise,
I can simply click on the corresponding jumper pad
to open that connection.
And to test out different capacitors on my board,
I can open the surrounding jumper pads
to disconnect the on board capacitor from the circuit.
And then, using a switch board
on the back side of the control board,
I can insert arbitrary components,
or even hear an entire breadboard.
On this breadboard I can try out different capacitors
until I find the ideal one for my circuit.
So combining these core strengths of
access, isolation, and iteration,
Pinpoint then offers a number of more powerful
testing features that I won't all be able to explain here.
One important feature however is the ability
to author and run high level unit tests.
A unit test combines actions like isolating
a part of the circuit, injecting a test signal,
and then measuring responses to make an assertion
about the circuits behavior.
Unit tests are particularly useful in supporting iteration.
When fabricating a new board,
the user can run all of their previously authored tests
to quickly verify it's functionality.
The user can author tests in a number of ways.
Our initial prototype supports measurements of
voltage, frequencies, period, and continuity between points.
Users can author these tests themselves using the
scripting language,
or they can import them from saved libraries.
For tests that utilize test signals,
users can define these signals using
a standard set of waveforms,
or by recording and replaying an observed signal,
or by specifying a list of points.
An example test might then look like this.
The user specifies an assertion that there is
no continuity between signal one and signal two.
And therefore this test will alert the user
when an unintended short is found.
Finally when our controller is in working order,
we can restore the PCB to a standard,
always connected state by soldering across the jumper pads.
We can always separate them again as needed,
if new bugs arise.
So to summarize, Pinpoint is an end to ends tool.
It first intervenes during the design stage,
preforming an automatic instrumentation
of the connections to the users circuit.
This stage automates a process that we call design for test,
in which foresighted designers will often
manually add dedicated test features
to improve their access during later debugging stages.
When the user fabricates their board,
Pinpoint produces that secondary design for the
custom jig board.
The user fabricates these two boards together,
or they can later produce the jig as needed
with rapid prototyping methods.
And finally when testing Pinpoint serves as test software,
offering a graphical interface for probing,
and test authoring.
That interface can carry out an entire debugging
session without touching the hardware.
This scope panel functions as a traditional
oscilloscope view to visualize signals clicked
either on the board or schematic representations
of the users circuit.
Scattered across these views we also see the
interruptible jumper pads added by Pinpoint.
By clicking on any of these points,
the user can isolate parts of their circuit on demand.
One simple, but effective, advantage of Pinpoint
is that it links the board and schematic representations
using metadata exported during the instrumentation process.
So as a result, the user can do all of their
debugging with references to their schematic design,
without needed to parse where those signals
lie on their board layout.
Below the scope lies a library of tests
that the user has created or imported,
and a command line through which they can
author and run them.
So we have additional details on the
evaluation of Pinpoint in our paper,
and we also walked through some representative examples
of how we can instrument different types of circuits
to debug different types of issues.
For the sake of time,
I'll describe just three of those here.
These examples were all commercially available PCBs
whose designs we downloaded and instrumented with Pinpoint.
In this first example we instrumented a very
simple analog accelerometer PCB.
The surface mount accelerometer is small,
and so it's easy for hidden solder bridge to form
beneath the component, like this.
Using another built in feature,
Pinpoint can automatically detect
common sources of error like these.
The users schematic specifies which components
should be electrically connected, and which should not.
So with a single command that combines isolating
parts of the circuit, injecting test signals,
and measuring responses,
the user can then generate the pair wide set of
continuity tests for all the connections on the board.
Allow means to automatically detect
short circuits like these.
In this next example,
we are debugging a digital alarm clock
to explore how Pinpoint can assist us
in debugging physical input interactions.
The issue we're having involves bouncing,
which is our clock reports multiple inputs when
we press this mechanical switch only once.
And probing the event reveals several brief
edges in the transition as seen here.
Since we've instrumented these push buttons,
we can first verify that the rest of our hardware
works in the absence of bouncing
by disconnecting the actual inputs,
and injecting a clear digital signal
with no bouncing to the micro control.
Then we can capture the actual bouncing behavior
from an observed input,
and then replay that test signal as needed,
while we tune our debouncing logic and software,
saving us the hassle of manually repeating this input.
In this next example we instrumented an FM radio PCB
to show how slicing and sub-circuit isolation
can help us to divide up problems when debugging.
So for example, when our audio is not playing,
we might need to check each sub-circuit separately.
First we can debug the FM receiver
by temporarily connecting its output
to an external speaker that we know works.
We can also debug the audio amplification stage
by connecting an external audio source,
like an MP3 player to its inputs.
So before I finish I want to address some of the
limitations of this prototype as well as our next steps.
Firstly, our paper discusses issues of scaling
Pinpoint for large or complex circuits,
like this mobile phone PCB.
Our first prototype supports a maximum of 16 jumper pads,
with 32 corresponding locations to probe.
We can of course arbitrarily increase this limit
by adding additional relays and using cascaded multiplexing.
But for now, designers of large boards are able
to specify which signals they want instrumented in this way.
We also discuss free space requirements,
and how much space is needed when instrumenting
a crowded board with this approach.
Future versions of Pinpoint could provide
intelligent assistance in cases where a designer
must make tough choices about where to instrument.
Also relevant in a discussion of scaling
our steps of manual assembly for large designs.
We've began exploring new ways to fabricate and
make jigs without any manual assembly.
Such as using flexible PCBs like this
adhere to the board with Z access conducted transfer tape.
Our paper also presents a detailed analysis of
the parasitic factors introduced
when instrumenting a PCB with Pinpoint.
To summarize our initial prototype works well
with negligible impact upon circuits,
like those that I've described in this talk.
But we have not designed it for use
of high frequency circuits above megahertz range.
And Pinpoints most fundamental limitation perhaps
involves impact on the designers original
routing of traces during instrumentation.
As I've said Pinpoint introduces jumper pads
such that any pin can be individually connected
or disconnected from its net.
In many cases this objective requires adding
new traces between components or moving existing traces,
such as in this case
where these three elements are connected on the same net.
Therefore, when designers are particular about
the routing on their board,
they can manually correct routing following instrumentation
on their own.
So with those improvements in mind,
I'll finish by summarizing what we find most
compelling about current version of Pinpoint.
It addresses the fundamental challenges of
PCB debugging by improving access, isolation,
and iteration in the debugging process.
It enables high level testing methods at low costs,
and with minimal overhead.
After designing a PCB as usual,
designers can simply run Pinpoint's instrumentation script,
and fabricate the jig to gain access
to this faulty bugging sweet.
And it represents a step towards our larger vision
of a world with fully reconfigurable hardware
for rich interactive design and debugging.
We hope that others will share in this vision,
so that we can effectively support designers
and students and fellow researchers,
as we continue to produce the next generation of devices.
So with that, I want to thank you all again for coming,
and I would be happy to answer questions.
(applause)
- [Announcer] Yep, questions, just raise your hand and,
we'll hand you a microphone.
- [Dan] Hi, Dan Eschbrook, University of Copenhagen.
This is really cool,
one of the big issues here I think is the
construction of the custom jig for every single board.
I'm wondering if you thought about a way to
standardize a jig if you ran all of the--
if you didn't care about messing with the routing
and put all of the pads in one particular
location in a pattern.
- Yes, so let me, let me sort of explain more about the jig,
and a few ways that we go about, you know,
with our assembly process.
So, firstly, the way that someone actually
constructs the jig is,
you can hand assemble with these pogo pins,
and of course these are all routed to the header row
that we've attached to the ribbon cable.
If this is sort of a laborious assembly process,
we have a rapid prototyping method that I didn't talk about,
where essentially you can laser cut your own jig,
using any material, insert those pogo pins into the slots,
and then simply connect it with jumper wires.
That's a quicker solution, and it's obviously low-cost,
but that leaves a jig that's sort of less persistent,
for further debugging sessions.
I think you're absolutely right that
manual assembly is one of the points of friction that
we really wanna address to make this really easy to use.
As I've said, our sort of, Holy Grail is to make jigs
that you don't have to do any assembly at all.
You simply print it onto a flex PCB,
and sort of adhere it to the board.
I agree that having a standardized pattern would be,
it would simplify this process a lot,
you could have one jig,
but as, you know,
we've done a lot of interviewing in working with designers,
and, you know, professional designers and researchers,
and everyone's very particular,
there's sort of an art to
the creation of your board and its routing.
So the, sort of, least that we can disrupt
your particular routing, that's our goal.
And that's why we put some effort into this
algorithm of sort of optimizing where those pads go.
But, it's a great question.
- [Audience Member] (mumbling)
I like this pretty much,
but I wonder, because you propose
(mumbling)
and someone proposed the breadboard,
and then now this one propose using PCB,
so how do you think, in the future,
how max will do their prototyping?
- Yeah, that's a great question.
I myself am very passionate about taking this, sort of,
richness of interaction,
and extending it across, really, the whole design process.
Which I think extends starting from the beginning,
where you sort of envision your circuit,
you specify its behavior,
create a design, maybe a simulation,
and then you prototype on a breadboard,
and then eventually you end up here with sort of a fine PCB.
And so, I think that, something that's really important is,
that we sort of, connect,
we have an infrastructure that allows us to
tie together all of those pieces of the process.
I think right now, we end up,
we create these one-off solutions for maybe, you know,
prototyping out a breadboard, or simulation tool,
and a lot of the information that the user puts in,
where the specifications that they make,
or even the problems that they solve,
that information all gets thrown away, I think,
when we sort of move from one to the other.
So, my goal is, you're saying is,
to take these same types of interactions,
with Scanalog and Pinpoint,
to start them as early as we can so that
when someone first starts their circuit,
they have all the support,
and then every time they create a test,
or they, you know, gather some data,
we can carry that information all the way through,
when you've built your prototype,
we already can help, you know,
as we have seen, with auto complete,
we can help suggest things to do in the circuit.
So, I think there's a lot of work to be done.
Really, from our whole community,
in taking these types of solutions that work for one.