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 pictured here are two of my current projects, one is a virtual reality chair controller, another is a braille e-book 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 you'll notice I said I love electronics, and I love code, but I don't actually enjoy

designing electronics all that much. 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 and the connections between them, and then you move over to your layout tool where

you then route those connections and place your components. So, if you're designing digital hardware, if you're designing something to be run on an FPGA, you can actually use schematic entry as well. But hardware description languages were invented in the 1980s, and that's pretty much how

we largely now design digital circuits, because schematic entry for this sort of task becomes very confusing. 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.

So we use code to describe logic circuits, because it's much easier to manage the complexity. So these are known as hardware description languages. This is a bit of Verilog there.

Or is it? Yes, it is. So, if you're doing schematics, and especially with higher pin count components such as FPGAs, schematics are really just, there's a lot of labels, and they jump all over the place, and it's kind of hard to follow what is going on, really, and it's

very tedious to define hundreds of connections that just kind of go in parallel, so that's the motivation behind exploring the space of using code to define net lists, to make

schematics. So, can we use HDLs for analogue circuits? Well, there's actually analogue and mixed-signal extensions to the popular HDLs. Verilog A was defined in 1993, and it was then merged into AMS which stands for analogue and mixed-signal in 2000.

There's also analogue and mixed-signal extension for VHDL, and there's another one I came across in a paper from 1999 called the circuit description language, though I couldn't find any implementation of it.

So the focus of these is simulation and verification, really. So rather than just do pure schematic entry, you are describing the behaviour of your circuit, and you need to know a lot of details about the behaviour of your components. So what we want, or what I want anyway, is something to do schematic entry, to create

net lists, rather than analogue simulation, because it's a lot less work. So, I came across this, which is called the PCB hardware description language, and this

is a project from 2011. It has quite a clean syntax for defining devices and their connections. There are some more advanced features that didn't fit on this slide here, but there's a slice notation to do connections in parallel, and it has a native module system, so you

have all your different circuits spread across different files. So it's a new language which has its pros and cons. You get a clean syntax, but it's not as expressive as a general-purpose language. This is a compiler written in Java, and it can open net lists for quite a few different

PCB design tools. It does some natively, and then there's some translation software for others. It also has an Eclipse plugin, so you can write descriptions with the help of an IDE. I didn't manage to try this yet.

The next one I came across is Skittle, so this is Python. There's a bit of operator overlaying 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 kycad layout tool.

There's another recent one, another recent kind of embedded domain-specific language for designing circuits in Python, which is PyCircuit, and 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. It has some very interesting experimental features, so one of those ideas is to break your components up into different sub functions, and then define connections on those, and

it also does footprint definitions and layout. So, PhDL, Skittle, and PyCircuit, the pros of it are that you can define something once and reuse it. That's the idea of it, and you can use for loop, slice notation, and other programming

features to speed up the design process. There are some issues with it, so it's hard to visualise what is going on from code to your actual net list, or your circuit.

Circuit definitions can still be very tedious, so it's hard to associate footprints, and then make sure those footprints are right, make sure your connections are all right, and, if there's any mistake in there, it would be quite hard to debug. So I'm going to address some of these.

Visualisation, so, even though I find drawing schematics quite tedious, I like to read them, and I like to refer to them. They're a really useful visual tool, so I was experimenting a bit with trying to

add visualisations to some of these languages, and I contributed this to Skittle, so this is a graph-vis graph. If you don't know graph-vis, it's a brilliant program where you can programmatically define your graphs. So, I tried to make this look kind of similar to a schematic, so you know what is going

on, but 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.

PyCircuit already has a graph-vis output as well, which the creator, David Craven, did. The reason this looks like this is because, in PyCircuit, you can do layout as well, so there's initial implementation of a sort of interactive viewer where you can click

on your nodes on the graph, and then it highlights what is going on in your layout. So, quite recently, I came across this project called netlist SVG, and that takes your

output from Verilog, and it tries to, well, it draws quite good, I'm really impressed with these schematics that it comes up with. This is using ClayJS, or very soon it's going to be using the successor which is

the Eclipse layout kernel, and that uses very similar algorithms to what is being used in graph face to lay out these graphs. So, me and the creator have been experimenting a bit with using this for analogue and mixed

signals schematics, and these are some of the initial kind of products of that experimentation, and, while it's not exactly what people would draw, it's quite readable. And I'm fairly happy with it. Something to note is that the flow of it has to be defined, so your schematics will

generally flow using this from the flow up to down, and left to right. So, as we scale this up, it will be interesting to see if that actually doesn't make

... I think it will make schematics much more readable, because all the schematics defined in this way will flow in the same direction, and will be easier to follow. It will be interesting to see how to scale this up for hierarchical schematics.

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, I created something called Electrogrammer which is currently

a JavaScript module to parse electronic component descriptions. So the idea here is that, as electronic hobbyists or engineers, we already use quite a specific language to quite a restricted language to describe what are circuits and

the components, so, if we take advantage of that, what people already know, we could use that as a programmatic input as well. So, as I said, this is a JavaScript module. I'm working on a Python port to contribute that to these other domain-specific languages

in Python. So, I've been playing with this idea of also kind of creating another domain-specific

language, possibly in JavaScript, which just to confirm Atwood's law which is everything that can be written in JavaScript will be written in JavaScript. So, my goals with this would be to make it easier to design a reason about circuits,

and use static analysis to make it very hard to create bugs, and whether JavaScript is the best choice for that goal, I'm not sure yet, so maybe, at some point, we will have a search language, and, yes, I would love to have an interactive editor where

you can visualise your circuit with something like net list SVG, and edit the code at the same time. So, you're probably wondering about 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. So, PHDL was created, and it's, I think, when I tried it, it works for previous versions

of Eagle, and not newest, so I think it hasn't seen much use, so there's been some I'm sort of just coming up with these terms. These are not official kind of from the creators, and my own experience, I haven't even got started yet, so I've glossed over a bit the layout and footprints, but there's domain-specific

languages as well for creating footprints and layouts. KiCad is one for KiCad, and I haven't tried it, but it looks pretty good, actually,

and people do use it quite a bit. In PyCircuit, there's also a language in it for creating footprints, and there's some experimental layout and routing using SMT solvers.

I also created an experiment about a year ago to mix a Racket scheme and KiCad S expressions, the KiCad S expression format into an editor, though that hasn't seen much work lately.

So, I guess the question is, just to step back a bit, what do we want to achieve by making hardware design more like software, and really, we want to be able to have fast

iteration cycles and iterate on our design so that we get to somewhere. Quicker. We want to use programming 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, I haven't covered much of that, but all of these languages really have modular systems so that you can reuse code and hook into them, and, yes, hopefully make

use of other people's work and collaborate in that way. And I would be remiss to mention my own project here which is a website, a service to kind of a registry for electronic designs.

So my hope here is really that this can become a collaborative space for people to reuse other people's circuits. So, I think I've finished a bit early here.

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, Brent Nelson, and others, they have created Ph.D.L. Dave van der Boot on Skittle, and David Craven on PyCircuit, and all the contributors

to Graphis and Elk that make this kind of experimentation possible. We go now to the Q&A.

The signal angels signals that the internet has no questions, so please line up at the microphones if you have any questions for our speaker. There is someone already ready at microphone number two, please.

Which of the solutions is most robust if you want to do all the simulations, or is it possible maybe to export it to a spice or something? I don't know. I think if you want to do simulation, you should look into the Verilog solutions, and

possibly, or you probably don't want to write Spice directly. Microphone number four, please. Can you say something about the process of the placement of the circuitry?

So, the interface to the spice is one very interesting aspect, but on the other end, I want to have an interface for the actual placing of the components. Did you think about this? Yes, so, for both PHDL, you really export to Orkad or Eagle, or then use the translation

programme to translate it to another programme, so then you do your layout in those programmes. The same for Skittle, you export to Python, sorry, to KiCad and then do your layout

in KiCad. PyCad is the only one really experimenting with doing layout programmatically. Microphone number three, please. Are your experiments with netlist SVGs skins published anywhere so we can

build on that and work on our own stuff? Yes, they merged into netlist SVG. 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 master branch of netlist SVG, and all the links are in the file plan.

Does that include the stuff to interface it with the other programming languages you listed above? No, well, that's kind of largely imaginary at this point, so what we need to do is output Yoast netlists, and then use netlist SVG for that.

It seems pretty straightforward to, once we get around to it, I think. Okay. There is someone at microphone number four. Okay, so my question is, do you think it would be possible to create automatic router

constraint-based that could actually work for placement of the elements? I don't know. I find the experiments that are being done on PyCircuit really interesting.

Whether they're actually going to lead somewhere, I don't know. Yes, 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 Kasper, thank you again for the talk, and please give him a warm round of applause. Thank you very much.