Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/901 Thanks!
My name is Casper, and I
am here to talk to you about
designing PCBs, that's printed
circuit boards with code.
So just a little bit about me, I'm
a freelance electronic engineer and
software developer, and
he pictured here two of my
current projects. One is a virtual
reality check controller.
Another is a Braille eBook
reader.
And I love writing code.
And I love open source and especially
open source electronics.
People coming together, working on
something from all over the globe really
inspires me. So, um,
you know, as I said, I love electronics
and I love code, uh,
but I don't actually enjoy designing
electronics all that much.
Uh.
Uh, I get very frustrated
with the design tools, and
this is how typically you
design a printed circuit board.
You have your schematic tool on one side
where you define your components in the
connections between them, and then you
move over to your layout, to where
you then route those connections and
place your components.
Uh,
so if you're designing digital hardware,
if you're designing something to be
running run FPGA, you can
actually use schematic entry as well.
Uh, but a hardware description
languages were invented in the 80s,
and that's pretty much how
we largely now design digital
circuits, uh,
because, uh, schematic
entry for this sort of tasks becomes
very confusing.
Uh, this is a little puzzle I found.
If you go to the URL there, you can get
it and you can try and solve it.
Um.
So we use code to describe logic
circuits because it's much easier to
manage the complexity.
Uh, so these are known as hardware
description languages.
Uh, this is about a
very log their, um.
Or is it.
Yes, it is.
So if you're doing
schematics and
especially with high Pinchao and
components such as ESPNews
schematics are really just, uh,
there's a lot of labels and they jump all
over the place and it's kind of hard to
follow what's going on, really.
And it's very tedious to find
hundreds of connections that just
kind of go in parallel.
So, uh, that's
the motivation behind
exploring the space of of using
code to, uh, to
define, uh, to define
neckless from or to
to make schematics.
So can we use HD for analog circuits?
Well, there's actually,
uh, analog and mixed signal extensions
to the popular HD,
uh, very like a was defined in
1993 and it was
then merged into AMS, which
stands for analog and mixed signal.
And in 2000,
um, there's also, uh,
uh, analog and mixed signal extension for
video.
Uh, and there's another one that
I came across in a paper from 1999
called The Circuit Description Language,
though I couldn't find any implementation
of it. Uh,
so the focus of these is simulation
and verification, really.
So rather than just do pure schematic
entry, you are describing the behavior
of your circuit and you need to know
a lot of details about the behavior of
your components.
So.
What we want.
Well, what I want anyway, is something
to do, schematic entry
to do create net lists
rather than an
analog simulation.
Because it's a lot less work, um,
so I came across this, which is
called the PCB
hardware description language,
and this is a project from 2011.
Uh, it has quite a clean syntax
for defining, uh,
devices and their connections
is the more advanced features that kind
of didn't fit on this slide here.
Uh, but
there's this kind of slight notation to
do connections in parallel and
of and you can it
has a sort of, uh, native modular system.
So you have all your different circuits
spread across different files.
So it's a new language,
uh, which has its pros and cons.
And you get a clean syntax,
uh, but it's not as expressive as
a general purpose language.
Uh, this is a compiler.
It's written in Java and
it cannot binet this for quite a few
different PCB design tools.
It does some natively.
And then, uh, there's some translation
software for others.
It also has an Eclipse plugin, so you can
write descriptions with the help of an
idea, too.
I didn't manage to try this yet.
Um,
the next one I came across is skiddle.
So this is Python.
Um, there's a bit
of operator overloading going on here.
So even if you're used to reading Python,
you might be a bit confused, but
it's essentially a set of classes to help
you design circuits.
And you can do the rest of your design
in the kickout layout to,
um, there's another
recent one, which is another
reason, uh, kind of embedded the
domain space civic language for
designing circuits in Python, which is my
circuit.
Uh.
And this is also this
is quite in flux at the moment, so this
slide kind of went out of date in the
last few days on the example
of how the circuit is defined
there. And it has
some very interesting experimental
features.
Uh, so
one of one of the one of those ideas is
to break your components up into into
different, uh, sub functions and
then to find connections on those.
And it also does, uh,
footprint definitions and layout.
Um, so.
Skittle and pie circuit, the the
the pros of it really you that you've you
can define something once
and reuse it, that's the idea of it.
And you can use Falo slice
notation and other programing features
to, uh, speed up the design
process.
There's some issues with it.
So it's hard to visualize what's going on
from code to your
actual Netlist
or your circuit.
Uh, circuit definitions can still be very
tedious, so
it's hard to associate footprint's
and then make sure those footprints are
right. Make sure your
connections are right.
And if you if there's any mistake in
there, it can be it could would
be quite hard to debug.
So I'm going to address some of these,
um, visualizations.
So even though I find drawing
schematics quite tedious, I like to read
them and I like to refer to them.
They're really useful.
Uh, uh, visual
too. So,
um, I
was experimenting a bit with trying to
add visualizations to some of these
languages, and I contributed
this to skittled.
So this is, uh,
graph is graph. If you don't know.
Graph is it's a brilliant program where
you can program it programmatically,
define your, uh,
graphs.
And so.
So I tried to make this look
kind of similar to a schematic, so, you
know what's going on, but it's obviously
it's not a schematic, but it
has similarities.
And we haven't really tried to
scale this up yet.
But this
is kind of the initial experiment,
um, by circuit already
has a graph as output as well,
uh, which the creator,
David Kraven, did.
Uh, the reason
this looks like this is because in
Pieszecki you can do layout as well.
So there's, uh, there's
initial implementation of a sort of
interactive viewer where you can click
on, uh, your nodes
on the graph and then it highlights
what's going on in your layout.
Um.
So quite recently, I came across this
project called Netlist Asaji, and that
takes your Yosses, uh,
so your your, uh,
output from very long, uh,
and it tries to
well it draws quite,
quite good, quite well.
I'm really impressed with the schematics
that it comes up with.
This is using Clay.
Yes. Or well, very soon it's going to
be using the the
successor, which is outrageous.
So that's the eclipse layout, Colonel.
And that uses very similar algorithms
to what's being used in graphics to
layout these graphs.
Um.
So me and the
creators, Neil Turley, have been
experimenting a bit with you,
using this for analog and mixed signal
schematics, and these are some of the
initial, uh, kind of
products of that experimentation.
And while it's not exactly
what people will draw, it's quite
readable.
And, um,
I'm I'm I'm fairly happy with it.
Something the notes about is that the
the flow of it has to be
defined. So your your schematics
will generally flow using
this from, uh,
the follow up up to
down and and left
to right.
So as we scale this up, it'll
be interesting to see if that actually
doesn't make it.
I think it will make, uh,
schematics much more readable because all
the schematics defined in this way will
flow in the same direction and will be
easier to follow.
Uh, it'll be interesting to see
how to scale this up for
higher hierarchical schematics.
Um, so I'm
really looking forward to experimenting
more with this.
So kind of on the
second point, that is still quite
tedious to actually define your circuits
even in code.
Um.
Ah, I, I created
something called, uh, Electro Grammar,
which is currently a JavaScript module
to pass electronic component
descriptions.
Uh, so the idea here
is that as electronic
hobbyists or engineers, we already use
quite a specific language
to restrict to language
to to describe what
our circuits and the components.
So, uh.
If we if we take advantage of that,
what people already know, we could
get a use that for as
a programmatic input as well.
So as it as I said, this
is a JavaScript module.
I'm working on a python part to
contribute to that that to these
other, uh, domain
specific languages in Python.
Um.
So.
I've been playing with this idea of also
kind of, uh, creating another another
domain specific language possibly in
JavaScript, uh,
which just to confirm what's law, which
is everything that can be written in
JavaScript, will be written in
JavaScript.
Um.
So my goals
with this would be to make it easier
to design a reason about certain
circuits and use static
analysis to make it
very hard to create bugs and
weather, JavaScript is the best, uh,
uh, choice for that goal.
I'm not sure yet. So maybe at some
point we will switch language.
Uh, and,
uh.
Yes, I'd love to have an interactive
editor where you can visualize your
circuit with something,
uh, something like, uh, Netlist SPG
and edit the code
at the same time.
So you're probably wondering about, uh,
whether you should use these projects
to define circuits.
And I don't know.
I think if you're interested in the idea,
you should definitely try it out.
I wouldn't use it for anything
important yet.
Um, so
Dell was created and it's
I think when I tried it, it's
it's it's it it works for previous
versions of ego and not news.
So, um, I
think it is it hasn't seen much use.
So there's been some bitrate skiddle
I would say is alfer.
I sort of just coming up with these
terms, these are not official kind of
from the creators.
Um and my own
experience, I haven't even got started
yet, so.
I've glossed over a bit, um,
the layout and footprints, but there's
there's domain specific languages
as well for creating footprints
and layouts.
Kickout Matri is one for kickout.
Uh, and
I haven't tried it, but it looks
pretty good, actually. And people do use
it quite a bit, uh, in
my circuit.
Uh, there's also, uh,
a language in it for creating footprints
and, uh, there's
some experimental layout and
routine using Asanti Sarver's,
um.
I also created an experiment about a
year ago to mix
rocket scheme and s
expressions, uh,
the expression format into an
editor.
Uh, though that hasn't seen much
work lately.
Um.
So.
I guess the question is
just to step back a bit, what what
what do we want to achieve by making
hardware design more like software?
And really, we want to be able to,
um,
we want to be able to have
a fast iteration cycles and iterate on
our design so that we
we get to somewhere
quicker if
we want to use programing constructs
for a faster
and better design process.
So I've kind of talked a lot about that
already. And really we want
modularity and reusability.
So
the I haven't covered much of that, but
all of these languages really have,
uh, modular systems
so that you can reuse bits of code and
and hook onto them and.
Yeah, hopefully make use of other
people's work and kind of collaborate in
that way, and
I'd be amazed to mention, not to mention
my own project here,
which is a website,
a service to
kind of a registry for for electronic
designs.
So my hope here is really that,
um.
That this can become a
collaborative space for
people to reuse other people's
circuits, um.
So I think I've finished a bit earlier,
um, I really want to thank
all the creators of all these projects
because really largely I'm presenting
other people's works and kind of my
thoughts on top of that.
So Brendan Nelson, uh,
and and others that
have created Dave Vanderbilt
on skiddle and David Kraven on
circuit and Neil Turley
for analysis as assuages.
And of course, all the contributors to
Gref is an elk that make this kind of
experimentation possible.
We go now to the Q
and A, the signal like Angels signals
that the Internet has no questions.
So please line up at the microphones
if you have any questions
for our speaker. COSPAR,
there is someone already ready at
microphone number two, please.
Um, which of the solutions
is most robust if you want to do
simulations, or is it possible
maybe to export it to a space or
something?
Who?
Um,
the.
I don't know, I think if you want to
do a simulation, you should look into the
the various solutions
and possibly or one you probably
don't want to write spies directly.
Yeah, thanks.
Microphone number four, please.
Oh, uh, can you say something
about the process, the process
of the placement of the circuitry?
So as the interface to the
spies is one very interesting
aspect, but on the other hand, I
want to have an interface
for the actual placing of the
components.
Did you think about this?
Uh, yeah. So, uh,
uh, so for both.
Well, for Dell, you really exposed
to Ocado ego or then
use the translation program to
translate it to another program.
Um, so you then
you do your layout in those programs.
Uh, the same for scale
you export to Python.
Uh, sorry to kickout and
then do your layout in kickout seconds.
It's only one really uh, experimenting
with doing layout programmatically.
Um.
Microphone number three, please.
Are your experiments with Netlist
SVG Skins published anywhere
so that we can build on
that and yeah.
Working on stuff.
Yeah, yeah, they merged into Netlist,
says Fidge.
It's not only my work, it's Neil
Turley working on it as well.
We're kind of both experimenting on it
and it's just being merged into the
massive branch of landlessness squidgy
and all the other links are in
the FA plan.
Uh, does that include the stuff
to interface it with the other programing
languages you listed above?
Uh, no.
Well, that's kind of, uh,
largely imaginary at this point.
So what we need to do is Outpost's
up, uh, Yosses Netlist,
uh, and then use less
SPG
for that. It's it seems pretty
straightforward to once we get around
to it, I think, OK,
there is someone that's microphone number
four.
OK, so my question is,
do you think it would be possible to
create an automatic router constraint,
perhaps based that could
actually work for placement
of the elements?
I I don't know
what I find in
the experiments that are being done on
Pieszecki really interesting, um,
whether they're actually going to lead
somewhere, I don't know.
Um, yeah, I can't comment much
more on that, unfortunately.
Thank you.
Thank you for the talk as well,
signal angel, are there any more
questions? There are no more questions
from the Internet and I think you also
run out of questions.
So COSPAR, thank you again for
the talk. And please give him a warm
round of applause.
Thank you very much.