Summary
As circuits and electronic components become more complex, visual circuit building tools are more difficult to use effectively. If you wish that you could just write your circuits in Python then you’re in luck! Dave Vandenbout created a library called SKIDL that brings the power and flexibility of Python to the realm of Electrical Engineering and he tells us all about it in this weeks show.
Preamble
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
- I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.
- When you’re ready to launch your next project you’ll need somewhere to deploy it. Check out Linode at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for running your awesome app.
- Visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch.
- To help other people find the show you can leave a review on iTunes, or Google Play Music, and tell your friends and co-workers
- Join our community! Visit discourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.
- Your host as usual is Tobias Macey and today I’m interviewing Dave Vandenbout about SKIDL, a library for designing and validating circuit layouts.
Interview
- Introductions
- How did you get introduced to Python?
- Can you describe what SKIDL is and the problem that you were trying to solve when you first started it?
- Most of my experience designing circuits has been done using a graphical tool. If you are using Python for the entire layout does it become difficult to understand the overall circuit without the visual representation?
- Is there a way to generate a circuit diagram from the SKIDL code for a visual reference?
- It seems that there is a substantial amount of electrical knowledge required to be able to design and build schematics in code. For someone who is more of a hobbyist or is just starting to work with circuit design are there any facilities of SKIDL to assist with that understanding?
- What does the testing and validation process of a generated circuit look like?
- What does the internal architecture of SKIDL look like and what are some of the biggest challenges that you have faced while building it?
- For the generated netlist does SKIDL take into account voltage losses due to the lengths of the traces in the final PCB and does it have any facilities to optimize the overall layout for space and efficiency?
- Sometimes a circuit board is meant to be accessible for maintenance or even display purposes. Is it possible to specify the arrangement of components to make them more aesthetically pleasing or to space them so that they are easier to access physical interface ports (e.g. GPIO pins or I2C buses)?
- What are some of the most interesting or surprising uses of SKIDL that you have seen?
Keep In Touch
Picks
- Tobias
- Dave
- Ball 4 by Jim Bouton
Links
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
[00:00:14]
Unknown:
Hello, and welcome to podcast. In it, the podcast about Python and the people who make it great. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode@linode.com/podcastinnit, and get a $20 credit to try out their fast and reliable Linux virtual servers for running your next app or experimenting with something you hear about on the show. You can visit the site at www.podcastinit.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. And to help other people find the show, you can leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media. Your host usual is Tobias Macy, and today I'm interviewing Dave Vandenbout about Skittle, a library for designing and validating circuit layouts.
So, Dave, could you please introduce yourself?
[00:00:56] Unknown:
Hi, Tobias. I work for and run a small company, XS Corporation, that makes field programmable gate array circuit boards. And as part of that work, I use a open source schematic and PCB layout program called KiCad. And part of my, effort in in using that was to develop this Skittle, language that is an add on for Python.
[00:01:19] Unknown:
And is Skittle an anagram for something, or is it just a sort of whimsical name for it? Or I'm just really bad at coming up with names. So, it stands for schematic KiCad design language. Yeah. Well, naming naming is 1 of the hard problems in computer science. Nobody will fault you for that. Exactly. So how did you first get introduced to the Python programming language?
[00:01:40] Unknown:
Back in 2011, I had a friend who was trying to build some boards with a little camera a little camera chip from a cell phone, and it wasn't documented at all. And he said maybe you could figure out how to talk to this chip and what the registers mean. So, I got 1 of the, little camera modules and and hooked it up to an FPGA. And then I talked to that FPGA through some c plus plus library that I had, but I wanted to put a GUI on the front of it. And I said, now, know, maybe I'll learn how to use Python to do that. So I learned how to use Python to build the GUI, and then I interfaced to the c plus plus programs through through c types, which is about the worst way possible to introduce yourself to Python, but, that's where I kinda got started with it.
[00:02:28] Unknown:
Yeah. You gotta start somewhere. And if the first experience is painful, then it just means that all your Yeah. Subsequent experience where you're not doing c types just feels like the best thing ever. Exactly. Yes. And I've converted a lot of programs that I had done in c plus plus over to Python now and and,
[00:02:44] Unknown:
with a much easier to port it to other systems now than it than it was before.
[00:02:49] Unknown:
Right. When I first started school for computer engineering, the first language they started us off with was c plus plus which was a little painful and a bit of a steep learning curve. And then, after that, it was Java, which after c plus plus Java felt terse and, eloquent. Right. So by the time I found Python, I was like, woah, this is amazing. I started off with c plus plus back in, like, 1990.
[00:03:10] Unknown:
And, it was understandable then, but I've gone back and I've looked at some c plus plus, modern c plus plus now. And I and I look at it and I I cannot understand it. It looks like it's kinda like, when liberal arts went through that deconstructed phase where where they took all the old classics and reinterpreted them based upon modern ideas, and nobody can understand what they meant anymore. And, I looked at the C+ and I said, you know, I I just can't figure out what you're trying to say with this anymore. So I was glad to get involved with Python. Like you said, it's a it's a lot clearer and and a lot more expressive, at least in my view, than c plus plus. You need c plus plus for embedded systems and things like that. But, but if if I'm not in an embedded world, then I'm gonna try to use Python.
[00:03:51] Unknown:
Yeah. And even these days, things like Rust and, even other programming languages like NIM or Crystal are starting to edge into that space as well. Right. Or even depending on the how restrictive of an embedded system you're running, you can still even use Python if you're using something like MicroPython. Mhmm. Right. Yeah. I've been interested in the MicroPython running on the ESP 8266
[00:04:11] Unknown:
boards. Get yourself a embedded Python system for a buck and a half. Yeah. So you touched briefly on what Skittle is. So I'm wondering if you can dig a bit deeper into that and share the problem that you're trying to solve when you first started working on it. It. Okay. So when you're building an electronic system, you typically have 4 phases in it, and it's kinda like writing a program. And the first phase is always planning. Define the goal, what functions you're gonna need, what their architecture is gonna look like for the electronic system. The next phase after you've done that is, designing a schematic. In that phase, you select the circuit components and you create interconnections that carry signals from 1 pin on 1 component to the pins of other components. The output from this phase is what they call a netlist, and that is just a list of each wire or as they call them, they call them nets, hence the name netlist. And each net is just a list of pins on each component that is attached to that net. So it says this wire goes between these pins, and those are the pins that connects to. And you can think of it as kinda like, an intermediate code, like you might get out of the front end of compiler. It it describes the logic, but it doesn't really describe all the details of it. And this is a portion where Skittle comes into play. The next phase is called layout, and that's where you take the netlist and translate it into the physical pattern of wire traces between the chip packages on a circuit board. And a lot of factors come into play here. This is where you're moving the the chip packages around, and you're trying to reduce the length of the physical wires that go between the chips because you want them as short as possible so that they they don't slow down. And, you want the chips packed as closer together as possible because you wanna use a small board because it's cheaper. This is kind of similar to the phase in in where you're generating machine code from the intermediate code and where you're concerned with things like reducing the code size and limiting the asset access to off chip memory, things like that. So those 2 phases between hardware design and and code and, comp compilation are kinda similar. And once you've done the layout, then you've got a description of where the chips are gonna go on the board and how they're connected and where the wiring traces should be physically on that board. So you send that information off usually in the form of what they call Gerber files, and you send it off to a board fabrication house. And a couple weeks later or, you know, couple of days, if you're willing to pay a couple $1, 000, they will send you back a nice circuit board, and you can mount components on the board. And and then you can start to exercise it with various electrical inputs and look up what the outputs are doing and things like that. And at this point, it's similar to to testing a compiled program. And in fact, most of the curse words you hear are the same between both domains. And followed by that, you, the last phase, which is probably the most important phase is when things don't work, then you get into the assignment of blame and the persecution of the innocent and so on and so forth. But but that's basically the circuit design set of phases you go through. And the schematics when I started off, which is back in the late seventies, we used to draw those on drafting tables, and and then we'd extract the net list from that from those drawings manually, and then we translate that into PCBs using rubyliss, sheets that we cut with X Acto knives, or we'd use this black tape and decal stuff that we put down on mylar on mylar sheets, and then we photograph it in exposed boards, and do all these nasty things that that meant that once you put once you design a circuit, you really did not want to change it. All these methods have been supplanted by electronic design automation software. And if I say EDA, that's what I mean, electronic design automation.
And that's all really took hold in the in the late in the late seventies and has replaced all the manual stuff that we used to do. And both schematic and layout software tools largely try to replicate processes, those manual processes from earlier in the seventies. You know, the the layout of this of the schematic on the on the drawing board is now replicated on the computer screen, and the cutting of the, of the mylar, of the rubylith traces, things like that is is done graphically on a computer screen by just laying out the traces. So both types of tools, both schematic, the schematic entry tool and the PCB layout tool are graphical in nature or or at least they have been. The problem is that the graphical metaphor for the schematic parts doesn't really work anymore, and it probably hasn't worked since the nineties. Back in the old days, circuits used to be made from really simple components like resistors, capacitors, transistors, small scale integration logic. All of these had easily recognized symbols. You know, the symbol for an AND gate, the symbol for a transistor, and they all had just a couple of pins on them. And each 1 had a a very well defined function in signal flow. You knew current went in 1 end of a resistor, and it came out the other end. There were 2 terminals. You know that a transistor had a base with there's a little current went in there. And if you tickled it with a little current, that transistor would act like a switch, and it would close. So you understood what was going on. And when you put all those components together in schematic, you could look at the schematic, and you could understand it by looking at the the overall signal flow. And it usually went from right to left across the page, and the simple functions got applied to the voltages and currents along the way. And you you could figure it out by look just by looking at it. And to prove that to prove the value of that schematic in terms of 180 degrees, so the top goes to bottom and left goes to right, and then flip it a 180 degrees, so the top goes to bottom and left goes to right, and then look at the schematic and try to explain it, then you're in your mind, you're trying to figure out where the signal is going, what's happening, whether because you've lost all of that pattern recognition about what's going on with the normal format for how it's normally laid out. So it takes about 10 times as long. So there's a lot of value in that schematic with those simple components back in the seventies. And, you know, the it's kinda like when you flip the schematic over, it's kinda like trying take a you take a program and remove all your syntax, coloring, and your white space, and then try to interpret that program, and it just gets a whole lot more difficult. And that's what schematics used to give you. But we don't make the circuits from those simple components anymore. At least, you know, they're still there. But, now we've got much bigger chips. We've got modern processors, and we got a 6, and we got FPGAs, and these can have over a 1000 pins. In fact, some of the FPGAs go up to 2, 000 pins. And signals are going all over the place. They're going into pins. They're coming out of pins. Sometimes the signals are analog. Sometimes they're digital. And they can actually switch from analog to digital while the circuit is operating, with with some of these with some of these chips. At least that's possible. Although, mainly, they stick as being either analog or digital. And there's a lot of programming in the chips. Your microcontrollers have programs. The FPGAs have programs.
So there's a lot of hidden internals in the chips now. So most of the components now when you draw a schematic, they're rectangular blobs with pins on them. They're just big bags of pins, and there's no general signal flow for a chip. You can't just look at 1 of these microcontrollers and say, oh yeah, the signals go in on the left and they're going to come out on the right. It all depends on how it's programmed and whether those pins are gonna be inputs or outputs, or how they're gonna be shifted around. So if you take a modern schematic with all these blobs with pins on them, and you look at it, and then you flip it over a 180 degrees, it makes as much sense that way as it made the first blade. In other words, it makes no sense. But people still try to use graphical schematic editors to design those circuits with these big chips. And when you have a 1, 000 pin chip, you're typically using a multi sheet hierarchical schematic.
If you've ever done that, you're endlessly fiddling with moving these chips around on the sheet, trying to get 1 close to the other, draw the wires in between them, adjust the wires so that they make sense and that they run from 1 to the other. You're trying to put meaning into the schematic that probably isn't really there. You're trying to drag it out and it's it's gonna resist you to do that. Then you combine that with the fact that the EDA software usually has the worst GUI ever created because it was built by engineers that were trying to design circuit boards, not by software programmers that knew how GUIs are supposed to be put together. So you get all these these arcane operations. You don't have cut and paste like you do in a word processor. It's it's always something a little bit strange and skewed that looks kinda like cut and paste but doesn't act the same way. So you get all these errors just caused by the tool itself and by the way you're trying to interact with it. So it's possible that maybe schematics just don't work for us anymore. And I'm on a, I'm on a news group or an information board for for KiCad, and people write in with their problems and other people, you know, try to try to solve it. And people are always on there asking about schematics. How do I do a hierarchical schematic? How do I do a global signal, and how do I keep it from interfering with a local signal? And how do I cut and paste blocks between the different sheets of the schematics? You know, it's always, the nitty gritty details of how to draw the schematic is is always open to question. And 1 day somebody came on and said, you know, I don't wanna do schematics anymore. I just wanna write the netlist directly. I just wanna say this pin goes he you know, starts here, goes over here. That's a lot like writing machine code directly, which is possible, but, you know, not recommended. And, but I thought that's a good idea.
May not be a good way to do it, but that's a good idea so that you can manage the details a lot more easily without always having to fiddle with the details about where the wire they're going to and to make everything look nice. So I figured somebody already had done something like this because it seemed like an obvious good idea. So I went looking around and I found a program already that was called p phdl that was invented out at, Brigham Young University back in 2011 or so. And it's written in Java, and it has all these features for just wiring together chips using using, text language that they invented. It's also a little bit restricted to that particular problem domain. It has a special syntax.
So in that aspect, it's kind of like, so many EDA tools. It's always gonna be a little bit quirky. But it never really seemed to catch on that well. It's been pretty quiet, the news groups, on that since 2000 12. I think the the main developers at the university went on and went to industry. I think they graduated, and the the language is still there. You can still download it. You can still use it, but the news groups are really pretty pretty much like ghost towns. So I but I liked it. I like p h t l. Not its syntax or the Java implementation, but I like the overall gestalt of it. So, I also had some experience in another program called my HDL, which is a digital hardware description language that's built on top of Python. And it's just a package you can download, and it hijacks all the Python machinery so you can describe and simulate digital hardware and then output either VHDL or Verilog code that can be compiled right into an FPGA. So, you know, you can stay strictly in Python and get all of your simulations worked out, get all your architecture details worked out. And only then do you have to generate some Verilog or VHDL and and do the detailed programming into the FPGA. And that brings all the Python libraries into play that you can use during your simulations to to do things like, get more visualization and visualization into the into the process and things like that. And that's something that wasn't in and things like that. And that's something that wasn't in PHGL.
Like I said, it was kind of restricted just to describing schematics, and it didn't have anything else, any other general purpose language functions in there. So anyway, I took the good ideas from PHL, which were, you know, how to hook circuits together in a iterative, repetitive way, with with a very, concise kind of, kind of a textual, format. And I reimplemented those as a Python package like my like my HDL. And that's what Skittle turned out to be. And, it looks, you know, it looks out for the circuitry details while letting you express the design using all the good features of Python. And, the good thing I like about it is that it hijacks Python. So it kind of rides along on the back of Python. And then as Python gets better and better, Skittle gets better and better at the same at the same time. And that means that you you don't have to spend as much effort, improving Skittle. There's a lot of people out there working on Python that are gonna be doing it for you. So, that's pretty much
[00:16:57] Unknown:
where it came from and and how it got started, and, so we can go from there. That was, definitely very informative. I've had a bit of experience working with things like VHDL, which it sounds like having my HDL probably would have made my life a bit easier when I was working on that. And I can definitely sympathize with the lack of, I guess, accuracy in dealing with some of the visual layout tools for building circuits because my experience with that was generally kind of frustrating of trying to figure out how to actually get the traces to, you know, properly connect between ports. And also, as you said, a lot of the chips that we're working with these days, they really aren't amenable to being able to visually decipher what it is that's actually happening on the board which Right. Again, is not even necessarily laid out ahead of time at the time when the circuits are even being defined. Right. There are any number of different possible approaches to it, especially with the, inclusion of things like GPIO or I2C ports where there's not even any telling what's gonna be placed on the other end of it in terms of the voltage requirements or the, you know, input output signals and which pins those are gonna be fired from. As I said, most of my experience of working with these circuits has been done using a graphical tool. But I can also see where being able to actually visualize the circuit as you're working on it could be valuable as well because, well, it isn't as informative as it used to be. Being able to understand a a different representation of it rather than just the abstract code that's being used might be useful. So I'm wondering if there is any sort of method for which you can actually run your Skittle code to generate graphical output of the circuit diagram whether it's by importing the netlist into something like KiCad or any other mechanism that you've got built into it. Right now, there's not. I suspect
[00:18:34] Unknown:
that maybe you could use some of the existing tools for generating graphical depictions of a program. Maybe some of those who come into play with Skittle. Or you might be able to have Skittle since it's just generalized Python. As it's generating its netlist, it could also be outputting something into, like, a graph vis program, and then graph vis could be used to kind of straighten it out and and give you a signal flow. But you mentioned VHDL, I've worked with VHDL and had to look at the gate level realizations of what the VHDL code does, which is something that you never want to have to do. But when things go wrong, you have to sometimes. And what you get is a big old glop of of gates with this maze of wires running in between them. And they try to do a good job of of moving the signals from left to right across the page. And and and so it's not like the signals are feeding back into the beginning of the circuitry and things like that. But even as good as they do that, it's still not a representation that's gonna be easy to understand for a large circuit because it's still gonna be a large circuit. It's still gonna have hierarchy in it. You're still gonna be have to be diving in between pages, going from 1 page to another unless you just blow the whole thing out so it's flat onto a single screen and try to try to move around, pan your way through that. But, even that, once you've flattened it out like that, you've lost all of your structure.
All the hierarchy in a way tries to tries to tell you what the circuit is doing. It tries to put some structure on it, so it's easy to understand. So if you take all the hierarchy out, then you've got a flat circuit and that's also difficult to understand. But if you leave the hierarchy in and you gotta go dialing around between the pages and tracing signals from 1 to the other, it all is gonna be difficult to understand no matter how you do it. I guess the question is is what kind of information you're looking for in that schematic, and how can you get the equivalent out of something like Skittle? I guess that I'm throwing the question back to you is when you get that schematic and you look at it, what do you wanna see? What do you wanna try to figure out from that? Right. Yeah. And I think that's also probably largely dependent
[00:20:42] Unknown:
on the level of experience of the person who's working on the schematic of, you know, are they somebody who's just starting out and they need that visual representation to be able to conceptualize what's actually happening. Right. Or is it getting to the point where having that visual representation is so inherently meaningless because of the level of complexity that's involved that they would be better suited just learning and training themselves to be able to understand how the overall process is working just through the representation in the code. Right. Well, here's the good thing about it is you don't have to choose.
[00:21:15] Unknown:
You get you can have the best of both worlds if you want. When you're starting out, there's no reason why you can't start out with a schematic editor. If you're doing small circuits, schematic editor is just fine for doing that. It's only when you get up to the the bigger circuits that you really need to think about maybe using something like Skittle. Now if you and if you wanna get experience with using Skittle and trying to, you know, form in your head a mental model of of what Skittle does, you know how the schematics work. You can actually take a schematic, at least in KiCad. You can generate a netlist from it, And then you can pass that netlist through another little program that I've got in addition to Skittle that's called, netlist to Skittle. And it'll take that netlist from whatever schematic you've created, and it will generate a Skittle program from that. So then you so you can, you know, do your circuitry in the schematic out of there, pass the netlist through that netlist to Skittle, and you could look at the equivalent Skittle code for that. And you can say, oh, I see this resistor here is over here in the code. Here's how it's connected to these pins. Here are where the nets are. This is how those are connected together. So you can do a 1 to 1 comparison and and get some experience going from a, a format that you know over into a format that you don't know. And then you can translate that knowledge about how to do Skittle for a small circuit into doing Skittle for a much larger circuit.
[00:22:34] Unknown:
It also seems like that would be a useful way of building up a library of modules where you're visually designing a small component piece of the overall circuit, generating the net list, and then translating that to the Skittle code, which you can then turn into a function and then just compose all the various Exactly. Components together with the Skittle code to build the overall circuit. Right. That's, that's also a good way to to do that to I mean, that that can also bring in a lot of existing modules that are already out there that are implemented as schematics. All
[00:23:11] Unknown:
Python module that you can use. I mean, if you've ever tried to take a schematic from somebody else and use it in your own schematic, it's always a question about how to get that thing merged in there. At least in KiCad, it is. But, we already know how to do all that merging of of modules with you know, subroutines and things in Python and almost every other language. So it makes it a lot easier to use modules from to take modules from 1 person to another.
[00:23:37] Unknown:
And, as you mentioned, 1 of the more difficult pieces of the hardware integration phase is the actual testing process. So I'm wondering what kinds of facilities
[00:23:47] Unknown:
and processes are in place for Skittle programs to actually try and preempt some of that, by using unit testing or also just, I know that it has some built in validation for Mhmm. Making sure that you don't have open loops or invalid circuits in the program. Right. Yeah. The, if you look at schematic editors, you don't have any of those things. I mean, you more or less you do your you do your circuit, you know, you do your schematic, and then you visually check it to make sure that it corresponds to what you think it is. You can try to run it through a SPICE simulator, but, you know, there if you've got a microcontroller in your schematic, then that's not gonna be simulated in SPICE. So, you know, it's it's not an analog simulation anymore.
So when you do a schematic the way that we've done them for years now, then then in a lot of cases, you're just eyeballing it and trying to figure out, you know, you're trying to figure out if it works or not. And then you go on ahead and have it manufactured. And then you then when you get it back, you test it in hardware, and and you throw all the jumper wires onto it, you know, trying to and cut and trace and trying to make it work that way. With Skittle, you've got the ability the same ability that you have with schematic, editors, which is it it does simple checks for you. It can check to make sure that you don't have an unconnected pin on a device. It can check to make sure that you don't have 2 drivers on the same net that are driving against each other, which can cause, you know, damage to 1 or both devices. It can check that you don't have, like, a 1 pin net where you've connected a net from 1 pin on the device, but you haven't made a connection to anything else. So it's just kinda hanging out there flopping around. So it does all those simple checks, but you can also this is a feature I haven't put out publicly yet, but can also attach attach little routines to your to certain nets that check though that do specialized checks on those nets. So that, if you need to have a certain fan out or if you can't have a certain fan out on a net, it will check that and you can set the fan out level to make sure that it doesn't connect to too many other pins and slow the circuitry down. So by having those little specialized subroutines that you can hang on to nets, you can do some more detailed checking. But overall, in terms of testing, if you've got programmable types of devices out there that they have substantial internal operations going on. Those are just really hard to test unless you've hooked them up to some kind of an external simulator that can hook up to the hook up to your other circuit simulator, and they kind of pass the information back and forth. But you don't really see as much of that. In fact, you you never really see that in hobbyist level circuitry.
[00:26:20] Unknown:
Yeah. I was I was just gonna ask about the possibility of having circuit emulators for things like microcontrollers
[00:26:25] Unknown:
or ARM chips or something like that to be able to some of the inputs and then, you know, determine the outputs for various pins depending on what the inputs are from the circuit. But That seems like the kind of thing that you could probably get rigged up by the fact that, you know, that Skittle is Python based. It seems like something you might be able to get rigged up, if you had some experience at at working with those other simulation programs. I don't think you'd have much much luck doing that with a with a standard schematic other program, though. So wondering what
[00:26:55] Unknown:
the internal architecture
[00:26:56] Unknown:
or the, design approach that you took for building Skittle looks like and also some of the biggest challenges that you faced while working on it? Well, Skittle is really pretty simple internally. There are prob let's see. You got a you've got a class for libraries, and those libraries just hold on to the to the list of parts. So what Skittle does is it goes, it works in concert with the KiCad library system. And it goes through and reads all the libraries and and forms an internal library from all those external libraries. It just has all these part objects in it. Each part, you know, object is a is a in the part class. And, basically, they're just big bags of pins. There are these pin objects, the pin class, and those just implement the pins that go under the device. And pins can be assigned to another class called the net class, which stores pins between various devices and make sure that if you're on a net, you can query the net and say, alright. What pin objects do you have hold of? And you can get a list of those. And then you can ask those pin objects, okay. What part are you a member of? And then it can tell you, well, I'm pin number 1, and I belong to the microcontroller part that's over here. And then the other guy can say, oh, I'm pin number pin number 2, and I belong to the resistor that attaches over there to the VCC supply. So I'm a pull up pin. I mean I'm a pull up device, that kind of thing. And then you have the you have a a bus object which is really just a collection of net objects bundled together. So you can have these multi bit buses, which are obviously useful for microcontroller and and FPGA data pads. And then you have at the very top level, you have what's called a, a sub circuit or a circuit class that holds on the entire in the entire netlist and, is responsible for dumping it out at the very end and, doing the, the, engineering rules check on it to make sure that the nets aren't floating or that they don't have too many drivers on and things like that. So those are basically the 4 or 5 classes that are involved there. And if you look at the code, and, again, I'm an engineer.
I'm not a trained computer scientist. So the criticism I lay against the schematic editor tools is being written by engineers. Same criticism can be applied to Skittle. I did I did the best that I could, but it's all pretty simple code. The, the hardest problem I had in there was was the nets and keeping everything tied together because when you tie, you know, you have to able to tie 1 pin to another pin and form a net dynamically, or you have to be able to tie a pin to a net, or you have to be able to tie a net to a pin, all these different combinations. For a while there, I was having trouble with the nets would drop pins that they would disassociate from 1 net, and they'd get lost. And I had to figure out, you know, because objects were being copied around, all of a sudden, the the object copies weren't being linked to this to the pins that they were supposed to, so they were getting dropped out. So I had to go through a lot of rigmarole trying to trying to figure that out. But I finally got the net class. Once I got the net class working correctly, then it made everything pretty simple, from a syntactic point.
It made the way that the Python syntax was for connecting the nets and the pins together became much simpler once I got the net class straightened out in my head as to how it should work. But that's really, you know, you know, those are the kind of kinds of challenges. I think though that when I got done with it, it's it's like a, you know, it's like 3, 000 lines of of code and it probably half of that is comments. But I stop and I look at it. I say, you know, somebody that really knew what they were doing has probably got a probably got a way to take an existing Python module and write maybe 300 lines of code to go around that, and they could probably do the whole thing.
[00:30:33] Unknown:
Yeah. Well, if anybody out there is interested in, refactoring it or trying to see if they can, improve the overall code efficiency of it, then, I'm I'm assuming that you would welcome any contributions on that front. Yeah. I mean, it's, it's out there. It's on GitHub. And, it's, anybody who wants to go and take a look at it, be my guest. Usually, the largest barrier to anything like this is just getting it started and getting it out there. And then Right. The, subsequent optimizations, it makes it a lot more likely that somebody else will come along and improve on something versus actually going and starting it on their own because, you know, the the act of creation is usually the hardest act. The act of modification is a, much smaller step to take. Yeah. I was reading,
[00:31:17] Unknown:
reading some article a couple weeks ago. It says, you know, there really are 2 classes of programmers, and they're not they're not they don't really overlap that much. But there's the guys that wanna go out there and get something working. They wanna create something, and that's their their whole impetus. And then there's the other guys that are the optimizers, and they like to take something that's already existing. And they like to they like to cut all the fat out of it and make it work really smooth and make it work really well. And, I probably need probably need 1 of those guys to go through the code and and and and fix it up.
[00:31:50] Unknown:
Well, thank goodness that we have both of those kinds of programs around. Exactly. Otherwise, I'm sure that, a lot of the software that we are running and relying on would be even scarier than it already is.
[00:31:59] Unknown:
Yeah. Yeah. A lot of it is really scary. I was looking through some some code for another project the other night, and, and, it was also written by an engineering. And even I even I was gassed at it.
[00:32:12] Unknown:
So, you touched on this briefly, but, a lot of times when you're building the actual schematic and the PCB layout from the netlist, 1 of the things that you wanna try to optimize for is shortening the traces and optimizing for our space layout in terms of voltage efficiency, but also thermal dissipation and things like that. So I'm wondering if there's any facility built into Skittle for being able to, optimize some of the overall layout for that. There isn't anything built in for that, and I'd I'm not really sure that,
[00:32:42] Unknown:
you can handle that at the schematic level. That's those issues are typically handled when you get over into the PCB layout software. That that's where you you start to, move the the chips around on screen and you say, well, I I can see all these nets that are going in between these particular pins. So I'm gonna try to get this chip over close to that chip, you know, because, the wires will be shorter. But then, know, oh my god. When I move that chip, then there's another chip over here or another connector over here. And now I've got all these long wires go over here, so I gotta make a trade off. And then he said, well, now I've got too many, too many chips together in this area, and it's gonna get hot here. So do I have to spread them out a little bit? Do I have room for, for a for a heat sink to put on top of these chips, or are they gonna interfere with each other? Is, you know, is the case gonna get in the way of this? You know, so on and so forth. It typically tends to be, part of the of the physical trade offs you made. You make it in the in the PCB layout program. And, you know, that's the place where the graphical nature of the PCB layout program makes a lot of sense because, you get to tap into that that human intuition about how to spatially arrange things. There are some places that Skittle could be in improved to help that out a little bit.
1 of the things is if you're doing a hierarchical design where you've got say you've got a module that is a crystal oscillator and crystal oscillators typically have a couple of little capacitors attached to them. So you want to enclose that inside of a instead of a module that whenever you want a crystal oscillator in your design, you just call that module and it drops down the crystal and a couple of capacitors for you. Well, it would be nice if when you did that, if when you generated a netlist, you also generated something like a like a position coordinate file that said, okay, this this crystal and these 2 little capacitors, they're kind of related to each other so they should go close to each other in the circuit board. So that when you get your initial netlist imported into the PCB layout editor, these 3 components get initially placed close to each other. So you can see, yeah, they're all kind of related to 1 another. And that would probably help a lot in terms of laying out your board because if you design it in stiddle, you might be pulling in all kinds of components depending upon what module that you what modules you use. And those they might be modules you've never even seen before that you got from somebody else. And you don't know all the components that are going on in there that are getting instantiated in there. So it would be helpful if you could look at the final the final or the initial screen in the layout of everything and say, oh, I called this module and all of these parts are a part of the module, and they're all grouped together. So I know they all are associated with 1 another. So I better kinda try to keep those grouped with each other and, and keep them close and and tie together. So I think there's a place for Skittle to play a role in some of the initial layout. But that's really, at this point, all I can see that that I can do at that, you know, during that phase of the of the of the design process.
[00:35:42] Unknown:
And are there any interesting or surprising uses of Skittle that you've seen or even, interesting uses that you've put it to that you didn't anticipate being able to use it for when you first created it? I really only got it finished,
[00:35:56] Unknown:
in in September of last year, and and I I I announced it on, the Python list on Reddit and went over like a lead balloon. So I didn't get a lot of uptake from that. So I don't think that there's many people using it, and, I've just been kicking the tires out right now doing doing simple designs with it and trying to, flush out any problems that are going on with it. So I don't think it's it's really gotten to the point where where some strange, unknown application has been found for it that wasn't kind of anticipated already. Hopefully, that'll happen in the future if more people decide to use it. And for anybody who's interested in either working in electrical engineering at a hobby level or somebody who's potentially, considering it for a career, what are some of the pieces of advice or recommended reference material that you think that you can point out? Well, there's tons of tutorials, you know, how to make a circuit board. There's tons of YouTube tutorials, how you know, about the same thing and also shows you how to assemble these things. The software for laying out or for doing schematics and for doing, the circuit boards that are now, commonplace, open source, and and free. You can download the KiCad, suite of tools, and it's under continuous innovation now with the KiCad team. They're they're improving the schematic editor and the and the PCB layout software, and it does a whole lot more than it than it used to do. And it's probably as good as other software that you, you know, pay several $100 for. So, it's a good place to get started. There are KiCad information groups that you can go to and ask questions and and get guidance.
I mean, it's it's not like it was when when I was just starting out where I tried to find you you'd have to find books on this stuff. Right now, all you gotta do is type in circuit board design and enter your browser, and you're you're on your way. And I found that the the communities that are that are, hosted around this subject area, they're pretty friendly. You don't get too many crusty old guys like me that'll bite your head off. Are there any other topics or questions that you think we should address before we start to close out the show? I think I've talked I think I've talked myself out. I I I think that, anything else I say, I'm gonna just go into the, the fields of idiocy if I haven't gotten there already. But, yeah. I think I think I've covered Skittle. If if you're interested, just go to GitHub, type in Skittle and take a look at it. I got the the website, there implemented so that it goes through the, through some tutorials on I'm adding more, postings there every week to try to just explain what goes on when you when you're trying to use Skittle. And, so go and take a look. And, if you if you use it, let me know about it. Let me know, especially, if it causes a problem for you because those are the things I wanna fix.
[00:38:41] Unknown:
Well, I'll be sure to add all those things into the show notes. And if there's any, preferred, contact method that you'd like people to use to reach out to you, I'll be sure to put that in the show notes as well. Okay. With that, I will move us on into the picks. Okay. For my pick today, I'm going to choose, I recently got a new backpack because the 1 that I had had was starting to fall apart. So, if you are in the market for a new backpack, the tectonic backpack from Samsonite is actually pretty nice, well done, solid construction. The laptop compartment is very well padded, which is 1 of the things that I like to look for in a bag. So all around, I'm pretty happy with it. So, if anybody else wants to take a look, I don't think they'll be disappointed. Do you have any pics for us today, Dave? Yeah. I've only got 1. Everybody should read Ball 4 by Jim Boutin. It was written back in 1970,
[00:39:27] Unknown:
and, it's just a story about a year that this guy spent playing professional baseball.
[00:39:33] Unknown:
But to say that it's a baseball book is kinda like saying that Moby Dick is a book about fishing, but I think everybody should read it. Alright. Well, I appreciate the recommendation. We'll have to take a look at it. I appreciate you taking the time to share your project with us and, tell us more about Skittle and electrical engineering and, some of the different pieces that go into,
[00:39:52] Unknown:
that overall process. It's definitely something that I find interesting and, I've dabbled in a little bit, but, something that I'm sure would be interesting if I I had the time to dive into it more. So again, thank you for your time. So many interesting things that you that believe me. I'm 60 years I'm 60 years old. I'm still finding interesting things that that I'd like to dive into and there's just not enough time in the world to do it. Right. But I really appreciate you having me on the show and, I hope, brings out some more people that are interested in Skittle. So I appreciate,
[00:40:19] Unknown:
the opportunity to do that. Absolutely. Happy to have you.
Hello, and welcome to podcast. In it, the podcast about Python and the people who make it great. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. When you're ready to launch your next project, you'll need somewhere to deploy it, so you should check out linode@linode.com/podcastinnit, and get a $20 credit to try out their fast and reliable Linux virtual servers for running your next app or experimenting with something you hear about on the show. You can visit the site at www.podcastinit.com to subscribe to the show, sign up for the newsletter, read the show notes, and get in touch. And to help other people find the show, you can leave a review on Itunes or Google Play Music, tell your friends and coworkers, and share it on social media. Your host usual is Tobias Macy, and today I'm interviewing Dave Vandenbout about Skittle, a library for designing and validating circuit layouts.
So, Dave, could you please introduce yourself?
[00:00:56] Unknown:
Hi, Tobias. I work for and run a small company, XS Corporation, that makes field programmable gate array circuit boards. And as part of that work, I use a open source schematic and PCB layout program called KiCad. And part of my, effort in in using that was to develop this Skittle, language that is an add on for Python.
[00:01:19] Unknown:
And is Skittle an anagram for something, or is it just a sort of whimsical name for it? Or I'm just really bad at coming up with names. So, it stands for schematic KiCad design language. Yeah. Well, naming naming is 1 of the hard problems in computer science. Nobody will fault you for that. Exactly. So how did you first get introduced to the Python programming language?
[00:01:40] Unknown:
Back in 2011, I had a friend who was trying to build some boards with a little camera a little camera chip from a cell phone, and it wasn't documented at all. And he said maybe you could figure out how to talk to this chip and what the registers mean. So, I got 1 of the, little camera modules and and hooked it up to an FPGA. And then I talked to that FPGA through some c plus plus library that I had, but I wanted to put a GUI on the front of it. And I said, now, know, maybe I'll learn how to use Python to do that. So I learned how to use Python to build the GUI, and then I interfaced to the c plus plus programs through through c types, which is about the worst way possible to introduce yourself to Python, but, that's where I kinda got started with it.
[00:02:28] Unknown:
Yeah. You gotta start somewhere. And if the first experience is painful, then it just means that all your Yeah. Subsequent experience where you're not doing c types just feels like the best thing ever. Exactly. Yes. And I've converted a lot of programs that I had done in c plus plus over to Python now and and,
[00:02:44] Unknown:
with a much easier to port it to other systems now than it than it was before.
[00:02:49] Unknown:
Right. When I first started school for computer engineering, the first language they started us off with was c plus plus which was a little painful and a bit of a steep learning curve. And then, after that, it was Java, which after c plus plus Java felt terse and, eloquent. Right. So by the time I found Python, I was like, woah, this is amazing. I started off with c plus plus back in, like, 1990.
[00:03:10] Unknown:
And, it was understandable then, but I've gone back and I've looked at some c plus plus, modern c plus plus now. And I and I look at it and I I cannot understand it. It looks like it's kinda like, when liberal arts went through that deconstructed phase where where they took all the old classics and reinterpreted them based upon modern ideas, and nobody can understand what they meant anymore. And, I looked at the C+ and I said, you know, I I just can't figure out what you're trying to say with this anymore. So I was glad to get involved with Python. Like you said, it's a it's a lot clearer and and a lot more expressive, at least in my view, than c plus plus. You need c plus plus for embedded systems and things like that. But, but if if I'm not in an embedded world, then I'm gonna try to use Python.
[00:03:51] Unknown:
Yeah. And even these days, things like Rust and, even other programming languages like NIM or Crystal are starting to edge into that space as well. Right. Or even depending on the how restrictive of an embedded system you're running, you can still even use Python if you're using something like MicroPython. Mhmm. Right. Yeah. I've been interested in the MicroPython running on the ESP 8266
[00:04:11] Unknown:
boards. Get yourself a embedded Python system for a buck and a half. Yeah. So you touched briefly on what Skittle is. So I'm wondering if you can dig a bit deeper into that and share the problem that you're trying to solve when you first started working on it. It. Okay. So when you're building an electronic system, you typically have 4 phases in it, and it's kinda like writing a program. And the first phase is always planning. Define the goal, what functions you're gonna need, what their architecture is gonna look like for the electronic system. The next phase after you've done that is, designing a schematic. In that phase, you select the circuit components and you create interconnections that carry signals from 1 pin on 1 component to the pins of other components. The output from this phase is what they call a netlist, and that is just a list of each wire or as they call them, they call them nets, hence the name netlist. And each net is just a list of pins on each component that is attached to that net. So it says this wire goes between these pins, and those are the pins that connects to. And you can think of it as kinda like, an intermediate code, like you might get out of the front end of compiler. It it describes the logic, but it doesn't really describe all the details of it. And this is a portion where Skittle comes into play. The next phase is called layout, and that's where you take the netlist and translate it into the physical pattern of wire traces between the chip packages on a circuit board. And a lot of factors come into play here. This is where you're moving the the chip packages around, and you're trying to reduce the length of the physical wires that go between the chips because you want them as short as possible so that they they don't slow down. And, you want the chips packed as closer together as possible because you wanna use a small board because it's cheaper. This is kind of similar to the phase in in where you're generating machine code from the intermediate code and where you're concerned with things like reducing the code size and limiting the asset access to off chip memory, things like that. So those 2 phases between hardware design and and code and, comp compilation are kinda similar. And once you've done the layout, then you've got a description of where the chips are gonna go on the board and how they're connected and where the wiring traces should be physically on that board. So you send that information off usually in the form of what they call Gerber files, and you send it off to a board fabrication house. And a couple weeks later or, you know, couple of days, if you're willing to pay a couple $1, 000, they will send you back a nice circuit board, and you can mount components on the board. And and then you can start to exercise it with various electrical inputs and look up what the outputs are doing and things like that. And at this point, it's similar to to testing a compiled program. And in fact, most of the curse words you hear are the same between both domains. And followed by that, you, the last phase, which is probably the most important phase is when things don't work, then you get into the assignment of blame and the persecution of the innocent and so on and so forth. But but that's basically the circuit design set of phases you go through. And the schematics when I started off, which is back in the late seventies, we used to draw those on drafting tables, and and then we'd extract the net list from that from those drawings manually, and then we translate that into PCBs using rubyliss, sheets that we cut with X Acto knives, or we'd use this black tape and decal stuff that we put down on mylar on mylar sheets, and then we photograph it in exposed boards, and do all these nasty things that that meant that once you put once you design a circuit, you really did not want to change it. All these methods have been supplanted by electronic design automation software. And if I say EDA, that's what I mean, electronic design automation.
And that's all really took hold in the in the late in the late seventies and has replaced all the manual stuff that we used to do. And both schematic and layout software tools largely try to replicate processes, those manual processes from earlier in the seventies. You know, the the layout of this of the schematic on the on the drawing board is now replicated on the computer screen, and the cutting of the, of the mylar, of the rubylith traces, things like that is is done graphically on a computer screen by just laying out the traces. So both types of tools, both schematic, the schematic entry tool and the PCB layout tool are graphical in nature or or at least they have been. The problem is that the graphical metaphor for the schematic parts doesn't really work anymore, and it probably hasn't worked since the nineties. Back in the old days, circuits used to be made from really simple components like resistors, capacitors, transistors, small scale integration logic. All of these had easily recognized symbols. You know, the symbol for an AND gate, the symbol for a transistor, and they all had just a couple of pins on them. And each 1 had a a very well defined function in signal flow. You knew current went in 1 end of a resistor, and it came out the other end. There were 2 terminals. You know that a transistor had a base with there's a little current went in there. And if you tickled it with a little current, that transistor would act like a switch, and it would close. So you understood what was going on. And when you put all those components together in schematic, you could look at the schematic, and you could understand it by looking at the the overall signal flow. And it usually went from right to left across the page, and the simple functions got applied to the voltages and currents along the way. And you you could figure it out by look just by looking at it. And to prove that to prove the value of that schematic in terms of 180 degrees, so the top goes to bottom and left goes to right, and then flip it a 180 degrees, so the top goes to bottom and left goes to right, and then look at the schematic and try to explain it, then you're in your mind, you're trying to figure out where the signal is going, what's happening, whether because you've lost all of that pattern recognition about what's going on with the normal format for how it's normally laid out. So it takes about 10 times as long. So there's a lot of value in that schematic with those simple components back in the seventies. And, you know, the it's kinda like when you flip the schematic over, it's kinda like trying take a you take a program and remove all your syntax, coloring, and your white space, and then try to interpret that program, and it just gets a whole lot more difficult. And that's what schematics used to give you. But we don't make the circuits from those simple components anymore. At least, you know, they're still there. But, now we've got much bigger chips. We've got modern processors, and we got a 6, and we got FPGAs, and these can have over a 1000 pins. In fact, some of the FPGAs go up to 2, 000 pins. And signals are going all over the place. They're going into pins. They're coming out of pins. Sometimes the signals are analog. Sometimes they're digital. And they can actually switch from analog to digital while the circuit is operating, with with some of these with some of these chips. At least that's possible. Although, mainly, they stick as being either analog or digital. And there's a lot of programming in the chips. Your microcontrollers have programs. The FPGAs have programs.
So there's a lot of hidden internals in the chips now. So most of the components now when you draw a schematic, they're rectangular blobs with pins on them. They're just big bags of pins, and there's no general signal flow for a chip. You can't just look at 1 of these microcontrollers and say, oh yeah, the signals go in on the left and they're going to come out on the right. It all depends on how it's programmed and whether those pins are gonna be inputs or outputs, or how they're gonna be shifted around. So if you take a modern schematic with all these blobs with pins on them, and you look at it, and then you flip it over a 180 degrees, it makes as much sense that way as it made the first blade. In other words, it makes no sense. But people still try to use graphical schematic editors to design those circuits with these big chips. And when you have a 1, 000 pin chip, you're typically using a multi sheet hierarchical schematic.
If you've ever done that, you're endlessly fiddling with moving these chips around on the sheet, trying to get 1 close to the other, draw the wires in between them, adjust the wires so that they make sense and that they run from 1 to the other. You're trying to put meaning into the schematic that probably isn't really there. You're trying to drag it out and it's it's gonna resist you to do that. Then you combine that with the fact that the EDA software usually has the worst GUI ever created because it was built by engineers that were trying to design circuit boards, not by software programmers that knew how GUIs are supposed to be put together. So you get all these these arcane operations. You don't have cut and paste like you do in a word processor. It's it's always something a little bit strange and skewed that looks kinda like cut and paste but doesn't act the same way. So you get all these errors just caused by the tool itself and by the way you're trying to interact with it. So it's possible that maybe schematics just don't work for us anymore. And I'm on a, I'm on a news group or an information board for for KiCad, and people write in with their problems and other people, you know, try to try to solve it. And people are always on there asking about schematics. How do I do a hierarchical schematic? How do I do a global signal, and how do I keep it from interfering with a local signal? And how do I cut and paste blocks between the different sheets of the schematics? You know, it's always, the nitty gritty details of how to draw the schematic is is always open to question. And 1 day somebody came on and said, you know, I don't wanna do schematics anymore. I just wanna write the netlist directly. I just wanna say this pin goes he you know, starts here, goes over here. That's a lot like writing machine code directly, which is possible, but, you know, not recommended. And, but I thought that's a good idea.
May not be a good way to do it, but that's a good idea so that you can manage the details a lot more easily without always having to fiddle with the details about where the wire they're going to and to make everything look nice. So I figured somebody already had done something like this because it seemed like an obvious good idea. So I went looking around and I found a program already that was called p phdl that was invented out at, Brigham Young University back in 2011 or so. And it's written in Java, and it has all these features for just wiring together chips using using, text language that they invented. It's also a little bit restricted to that particular problem domain. It has a special syntax.
So in that aspect, it's kind of like, so many EDA tools. It's always gonna be a little bit quirky. But it never really seemed to catch on that well. It's been pretty quiet, the news groups, on that since 2000 12. I think the the main developers at the university went on and went to industry. I think they graduated, and the the language is still there. You can still download it. You can still use it, but the news groups are really pretty pretty much like ghost towns. So I but I liked it. I like p h t l. Not its syntax or the Java implementation, but I like the overall gestalt of it. So, I also had some experience in another program called my HDL, which is a digital hardware description language that's built on top of Python. And it's just a package you can download, and it hijacks all the Python machinery so you can describe and simulate digital hardware and then output either VHDL or Verilog code that can be compiled right into an FPGA. So, you know, you can stay strictly in Python and get all of your simulations worked out, get all your architecture details worked out. And only then do you have to generate some Verilog or VHDL and and do the detailed programming into the FPGA. And that brings all the Python libraries into play that you can use during your simulations to to do things like, get more visualization and visualization into the into the process and things like that. And that's something that wasn't in and things like that. And that's something that wasn't in PHGL.
Like I said, it was kind of restricted just to describing schematics, and it didn't have anything else, any other general purpose language functions in there. So anyway, I took the good ideas from PHL, which were, you know, how to hook circuits together in a iterative, repetitive way, with with a very, concise kind of, kind of a textual, format. And I reimplemented those as a Python package like my like my HDL. And that's what Skittle turned out to be. And, it looks, you know, it looks out for the circuitry details while letting you express the design using all the good features of Python. And, the good thing I like about it is that it hijacks Python. So it kind of rides along on the back of Python. And then as Python gets better and better, Skittle gets better and better at the same at the same time. And that means that you you don't have to spend as much effort, improving Skittle. There's a lot of people out there working on Python that are gonna be doing it for you. So, that's pretty much
[00:16:57] Unknown:
where it came from and and how it got started, and, so we can go from there. That was, definitely very informative. I've had a bit of experience working with things like VHDL, which it sounds like having my HDL probably would have made my life a bit easier when I was working on that. And I can definitely sympathize with the lack of, I guess, accuracy in dealing with some of the visual layout tools for building circuits because my experience with that was generally kind of frustrating of trying to figure out how to actually get the traces to, you know, properly connect between ports. And also, as you said, a lot of the chips that we're working with these days, they really aren't amenable to being able to visually decipher what it is that's actually happening on the board which Right. Again, is not even necessarily laid out ahead of time at the time when the circuits are even being defined. Right. There are any number of different possible approaches to it, especially with the, inclusion of things like GPIO or I2C ports where there's not even any telling what's gonna be placed on the other end of it in terms of the voltage requirements or the, you know, input output signals and which pins those are gonna be fired from. As I said, most of my experience of working with these circuits has been done using a graphical tool. But I can also see where being able to actually visualize the circuit as you're working on it could be valuable as well because, well, it isn't as informative as it used to be. Being able to understand a a different representation of it rather than just the abstract code that's being used might be useful. So I'm wondering if there is any sort of method for which you can actually run your Skittle code to generate graphical output of the circuit diagram whether it's by importing the netlist into something like KiCad or any other mechanism that you've got built into it. Right now, there's not. I suspect
[00:18:34] Unknown:
that maybe you could use some of the existing tools for generating graphical depictions of a program. Maybe some of those who come into play with Skittle. Or you might be able to have Skittle since it's just generalized Python. As it's generating its netlist, it could also be outputting something into, like, a graph vis program, and then graph vis could be used to kind of straighten it out and and give you a signal flow. But you mentioned VHDL, I've worked with VHDL and had to look at the gate level realizations of what the VHDL code does, which is something that you never want to have to do. But when things go wrong, you have to sometimes. And what you get is a big old glop of of gates with this maze of wires running in between them. And they try to do a good job of of moving the signals from left to right across the page. And and and so it's not like the signals are feeding back into the beginning of the circuitry and things like that. But even as good as they do that, it's still not a representation that's gonna be easy to understand for a large circuit because it's still gonna be a large circuit. It's still gonna have hierarchy in it. You're still gonna be have to be diving in between pages, going from 1 page to another unless you just blow the whole thing out so it's flat onto a single screen and try to try to move around, pan your way through that. But, even that, once you've flattened it out like that, you've lost all of your structure.
All the hierarchy in a way tries to tries to tell you what the circuit is doing. It tries to put some structure on it, so it's easy to understand. So if you take all the hierarchy out, then you've got a flat circuit and that's also difficult to understand. But if you leave the hierarchy in and you gotta go dialing around between the pages and tracing signals from 1 to the other, it all is gonna be difficult to understand no matter how you do it. I guess the question is is what kind of information you're looking for in that schematic, and how can you get the equivalent out of something like Skittle? I guess that I'm throwing the question back to you is when you get that schematic and you look at it, what do you wanna see? What do you wanna try to figure out from that? Right. Yeah. And I think that's also probably largely dependent
[00:20:42] Unknown:
on the level of experience of the person who's working on the schematic of, you know, are they somebody who's just starting out and they need that visual representation to be able to conceptualize what's actually happening. Right. Or is it getting to the point where having that visual representation is so inherently meaningless because of the level of complexity that's involved that they would be better suited just learning and training themselves to be able to understand how the overall process is working just through the representation in the code. Right. Well, here's the good thing about it is you don't have to choose.
[00:21:15] Unknown:
You get you can have the best of both worlds if you want. When you're starting out, there's no reason why you can't start out with a schematic editor. If you're doing small circuits, schematic editor is just fine for doing that. It's only when you get up to the the bigger circuits that you really need to think about maybe using something like Skittle. Now if you and if you wanna get experience with using Skittle and trying to, you know, form in your head a mental model of of what Skittle does, you know how the schematics work. You can actually take a schematic, at least in KiCad. You can generate a netlist from it, And then you can pass that netlist through another little program that I've got in addition to Skittle that's called, netlist to Skittle. And it'll take that netlist from whatever schematic you've created, and it will generate a Skittle program from that. So then you so you can, you know, do your circuitry in the schematic out of there, pass the netlist through that netlist to Skittle, and you could look at the equivalent Skittle code for that. And you can say, oh, I see this resistor here is over here in the code. Here's how it's connected to these pins. Here are where the nets are. This is how those are connected together. So you can do a 1 to 1 comparison and and get some experience going from a, a format that you know over into a format that you don't know. And then you can translate that knowledge about how to do Skittle for a small circuit into doing Skittle for a much larger circuit.
[00:22:34] Unknown:
It also seems like that would be a useful way of building up a library of modules where you're visually designing a small component piece of the overall circuit, generating the net list, and then translating that to the Skittle code, which you can then turn into a function and then just compose all the various Exactly. Components together with the Skittle code to build the overall circuit. Right. That's, that's also a good way to to do that to I mean, that that can also bring in a lot of existing modules that are already out there that are implemented as schematics. All
[00:23:11] Unknown:
Python module that you can use. I mean, if you've ever tried to take a schematic from somebody else and use it in your own schematic, it's always a question about how to get that thing merged in there. At least in KiCad, it is. But, we already know how to do all that merging of of modules with you know, subroutines and things in Python and almost every other language. So it makes it a lot easier to use modules from to take modules from 1 person to another.
[00:23:37] Unknown:
And, as you mentioned, 1 of the more difficult pieces of the hardware integration phase is the actual testing process. So I'm wondering what kinds of facilities
[00:23:47] Unknown:
and processes are in place for Skittle programs to actually try and preempt some of that, by using unit testing or also just, I know that it has some built in validation for Mhmm. Making sure that you don't have open loops or invalid circuits in the program. Right. Yeah. The, if you look at schematic editors, you don't have any of those things. I mean, you more or less you do your you do your circuit, you know, you do your schematic, and then you visually check it to make sure that it corresponds to what you think it is. You can try to run it through a SPICE simulator, but, you know, there if you've got a microcontroller in your schematic, then that's not gonna be simulated in SPICE. So, you know, it's it's not an analog simulation anymore.
So when you do a schematic the way that we've done them for years now, then then in a lot of cases, you're just eyeballing it and trying to figure out, you know, you're trying to figure out if it works or not. And then you go on ahead and have it manufactured. And then you then when you get it back, you test it in hardware, and and you throw all the jumper wires onto it, you know, trying to and cut and trace and trying to make it work that way. With Skittle, you've got the ability the same ability that you have with schematic, editors, which is it it does simple checks for you. It can check to make sure that you don't have an unconnected pin on a device. It can check to make sure that you don't have 2 drivers on the same net that are driving against each other, which can cause, you know, damage to 1 or both devices. It can check that you don't have, like, a 1 pin net where you've connected a net from 1 pin on the device, but you haven't made a connection to anything else. So it's just kinda hanging out there flopping around. So it does all those simple checks, but you can also this is a feature I haven't put out publicly yet, but can also attach attach little routines to your to certain nets that check though that do specialized checks on those nets. So that, if you need to have a certain fan out or if you can't have a certain fan out on a net, it will check that and you can set the fan out level to make sure that it doesn't connect to too many other pins and slow the circuitry down. So by having those little specialized subroutines that you can hang on to nets, you can do some more detailed checking. But overall, in terms of testing, if you've got programmable types of devices out there that they have substantial internal operations going on. Those are just really hard to test unless you've hooked them up to some kind of an external simulator that can hook up to the hook up to your other circuit simulator, and they kind of pass the information back and forth. But you don't really see as much of that. In fact, you you never really see that in hobbyist level circuitry.
[00:26:20] Unknown:
Yeah. I was I was just gonna ask about the possibility of having circuit emulators for things like microcontrollers
[00:26:25] Unknown:
or ARM chips or something like that to be able to some of the inputs and then, you know, determine the outputs for various pins depending on what the inputs are from the circuit. But That seems like the kind of thing that you could probably get rigged up by the fact that, you know, that Skittle is Python based. It seems like something you might be able to get rigged up, if you had some experience at at working with those other simulation programs. I don't think you'd have much much luck doing that with a with a standard schematic other program, though. So wondering what
[00:26:55] Unknown:
the internal architecture
[00:26:56] Unknown:
or the, design approach that you took for building Skittle looks like and also some of the biggest challenges that you faced while working on it? Well, Skittle is really pretty simple internally. There are prob let's see. You got a you've got a class for libraries, and those libraries just hold on to the to the list of parts. So what Skittle does is it goes, it works in concert with the KiCad library system. And it goes through and reads all the libraries and and forms an internal library from all those external libraries. It just has all these part objects in it. Each part, you know, object is a is a in the part class. And, basically, they're just big bags of pins. There are these pin objects, the pin class, and those just implement the pins that go under the device. And pins can be assigned to another class called the net class, which stores pins between various devices and make sure that if you're on a net, you can query the net and say, alright. What pin objects do you have hold of? And you can get a list of those. And then you can ask those pin objects, okay. What part are you a member of? And then it can tell you, well, I'm pin number 1, and I belong to the microcontroller part that's over here. And then the other guy can say, oh, I'm pin number pin number 2, and I belong to the resistor that attaches over there to the VCC supply. So I'm a pull up pin. I mean I'm a pull up device, that kind of thing. And then you have the you have a a bus object which is really just a collection of net objects bundled together. So you can have these multi bit buses, which are obviously useful for microcontroller and and FPGA data pads. And then you have at the very top level, you have what's called a, a sub circuit or a circuit class that holds on the entire in the entire netlist and, is responsible for dumping it out at the very end and, doing the, the, engineering rules check on it to make sure that the nets aren't floating or that they don't have too many drivers on and things like that. So those are basically the 4 or 5 classes that are involved there. And if you look at the code, and, again, I'm an engineer.
I'm not a trained computer scientist. So the criticism I lay against the schematic editor tools is being written by engineers. Same criticism can be applied to Skittle. I did I did the best that I could, but it's all pretty simple code. The, the hardest problem I had in there was was the nets and keeping everything tied together because when you tie, you know, you have to able to tie 1 pin to another pin and form a net dynamically, or you have to be able to tie a pin to a net, or you have to be able to tie a net to a pin, all these different combinations. For a while there, I was having trouble with the nets would drop pins that they would disassociate from 1 net, and they'd get lost. And I had to figure out, you know, because objects were being copied around, all of a sudden, the the object copies weren't being linked to this to the pins that they were supposed to, so they were getting dropped out. So I had to go through a lot of rigmarole trying to trying to figure that out. But I finally got the net class. Once I got the net class working correctly, then it made everything pretty simple, from a syntactic point.
It made the way that the Python syntax was for connecting the nets and the pins together became much simpler once I got the net class straightened out in my head as to how it should work. But that's really, you know, you know, those are the kind of kinds of challenges. I think though that when I got done with it, it's it's like a, you know, it's like 3, 000 lines of of code and it probably half of that is comments. But I stop and I look at it. I say, you know, somebody that really knew what they were doing has probably got a probably got a way to take an existing Python module and write maybe 300 lines of code to go around that, and they could probably do the whole thing.
[00:30:33] Unknown:
Yeah. Well, if anybody out there is interested in, refactoring it or trying to see if they can, improve the overall code efficiency of it, then, I'm I'm assuming that you would welcome any contributions on that front. Yeah. I mean, it's, it's out there. It's on GitHub. And, it's, anybody who wants to go and take a look at it, be my guest. Usually, the largest barrier to anything like this is just getting it started and getting it out there. And then Right. The, subsequent optimizations, it makes it a lot more likely that somebody else will come along and improve on something versus actually going and starting it on their own because, you know, the the act of creation is usually the hardest act. The act of modification is a, much smaller step to take. Yeah. I was reading,
[00:31:17] Unknown:
reading some article a couple weeks ago. It says, you know, there really are 2 classes of programmers, and they're not they're not they don't really overlap that much. But there's the guys that wanna go out there and get something working. They wanna create something, and that's their their whole impetus. And then there's the other guys that are the optimizers, and they like to take something that's already existing. And they like to they like to cut all the fat out of it and make it work really smooth and make it work really well. And, I probably need probably need 1 of those guys to go through the code and and and and fix it up.
[00:31:50] Unknown:
Well, thank goodness that we have both of those kinds of programs around. Exactly. Otherwise, I'm sure that, a lot of the software that we are running and relying on would be even scarier than it already is.
[00:31:59] Unknown:
Yeah. Yeah. A lot of it is really scary. I was looking through some some code for another project the other night, and, and, it was also written by an engineering. And even I even I was gassed at it.
[00:32:12] Unknown:
So, you touched on this briefly, but, a lot of times when you're building the actual schematic and the PCB layout from the netlist, 1 of the things that you wanna try to optimize for is shortening the traces and optimizing for our space layout in terms of voltage efficiency, but also thermal dissipation and things like that. So I'm wondering if there's any facility built into Skittle for being able to, optimize some of the overall layout for that. There isn't anything built in for that, and I'd I'm not really sure that,
[00:32:42] Unknown:
you can handle that at the schematic level. That's those issues are typically handled when you get over into the PCB layout software. That that's where you you start to, move the the chips around on screen and you say, well, I I can see all these nets that are going in between these particular pins. So I'm gonna try to get this chip over close to that chip, you know, because, the wires will be shorter. But then, know, oh my god. When I move that chip, then there's another chip over here or another connector over here. And now I've got all these long wires go over here, so I gotta make a trade off. And then he said, well, now I've got too many, too many chips together in this area, and it's gonna get hot here. So do I have to spread them out a little bit? Do I have room for, for a for a heat sink to put on top of these chips, or are they gonna interfere with each other? Is, you know, is the case gonna get in the way of this? You know, so on and so forth. It typically tends to be, part of the of the physical trade offs you made. You make it in the in the PCB layout program. And, you know, that's the place where the graphical nature of the PCB layout program makes a lot of sense because, you get to tap into that that human intuition about how to spatially arrange things. There are some places that Skittle could be in improved to help that out a little bit.
1 of the things is if you're doing a hierarchical design where you've got say you've got a module that is a crystal oscillator and crystal oscillators typically have a couple of little capacitors attached to them. So you want to enclose that inside of a instead of a module that whenever you want a crystal oscillator in your design, you just call that module and it drops down the crystal and a couple of capacitors for you. Well, it would be nice if when you did that, if when you generated a netlist, you also generated something like a like a position coordinate file that said, okay, this this crystal and these 2 little capacitors, they're kind of related to each other so they should go close to each other in the circuit board. So that when you get your initial netlist imported into the PCB layout editor, these 3 components get initially placed close to each other. So you can see, yeah, they're all kind of related to 1 another. And that would probably help a lot in terms of laying out your board because if you design it in stiddle, you might be pulling in all kinds of components depending upon what module that you what modules you use. And those they might be modules you've never even seen before that you got from somebody else. And you don't know all the components that are going on in there that are getting instantiated in there. So it would be helpful if you could look at the final the final or the initial screen in the layout of everything and say, oh, I called this module and all of these parts are a part of the module, and they're all grouped together. So I know they all are associated with 1 another. So I better kinda try to keep those grouped with each other and, and keep them close and and tie together. So I think there's a place for Skittle to play a role in some of the initial layout. But that's really, at this point, all I can see that that I can do at that, you know, during that phase of the of the of the design process.
[00:35:42] Unknown:
And are there any interesting or surprising uses of Skittle that you've seen or even, interesting uses that you've put it to that you didn't anticipate being able to use it for when you first created it? I really only got it finished,
[00:35:56] Unknown:
in in September of last year, and and I I I announced it on, the Python list on Reddit and went over like a lead balloon. So I didn't get a lot of uptake from that. So I don't think that there's many people using it, and, I've just been kicking the tires out right now doing doing simple designs with it and trying to, flush out any problems that are going on with it. So I don't think it's it's really gotten to the point where where some strange, unknown application has been found for it that wasn't kind of anticipated already. Hopefully, that'll happen in the future if more people decide to use it. And for anybody who's interested in either working in electrical engineering at a hobby level or somebody who's potentially, considering it for a career, what are some of the pieces of advice or recommended reference material that you think that you can point out? Well, there's tons of tutorials, you know, how to make a circuit board. There's tons of YouTube tutorials, how you know, about the same thing and also shows you how to assemble these things. The software for laying out or for doing schematics and for doing, the circuit boards that are now, commonplace, open source, and and free. You can download the KiCad, suite of tools, and it's under continuous innovation now with the KiCad team. They're they're improving the schematic editor and the and the PCB layout software, and it does a whole lot more than it than it used to do. And it's probably as good as other software that you, you know, pay several $100 for. So, it's a good place to get started. There are KiCad information groups that you can go to and ask questions and and get guidance.
I mean, it's it's not like it was when when I was just starting out where I tried to find you you'd have to find books on this stuff. Right now, all you gotta do is type in circuit board design and enter your browser, and you're you're on your way. And I found that the the communities that are that are, hosted around this subject area, they're pretty friendly. You don't get too many crusty old guys like me that'll bite your head off. Are there any other topics or questions that you think we should address before we start to close out the show? I think I've talked I think I've talked myself out. I I I think that, anything else I say, I'm gonna just go into the, the fields of idiocy if I haven't gotten there already. But, yeah. I think I think I've covered Skittle. If if you're interested, just go to GitHub, type in Skittle and take a look at it. I got the the website, there implemented so that it goes through the, through some tutorials on I'm adding more, postings there every week to try to just explain what goes on when you when you're trying to use Skittle. And, so go and take a look. And, if you if you use it, let me know about it. Let me know, especially, if it causes a problem for you because those are the things I wanna fix.
[00:38:41] Unknown:
Well, I'll be sure to add all those things into the show notes. And if there's any, preferred, contact method that you'd like people to use to reach out to you, I'll be sure to put that in the show notes as well. Okay. With that, I will move us on into the picks. Okay. For my pick today, I'm going to choose, I recently got a new backpack because the 1 that I had had was starting to fall apart. So, if you are in the market for a new backpack, the tectonic backpack from Samsonite is actually pretty nice, well done, solid construction. The laptop compartment is very well padded, which is 1 of the things that I like to look for in a bag. So all around, I'm pretty happy with it. So, if anybody else wants to take a look, I don't think they'll be disappointed. Do you have any pics for us today, Dave? Yeah. I've only got 1. Everybody should read Ball 4 by Jim Boutin. It was written back in 1970,
[00:39:27] Unknown:
and, it's just a story about a year that this guy spent playing professional baseball.
[00:39:33] Unknown:
But to say that it's a baseball book is kinda like saying that Moby Dick is a book about fishing, but I think everybody should read it. Alright. Well, I appreciate the recommendation. We'll have to take a look at it. I appreciate you taking the time to share your project with us and, tell us more about Skittle and electrical engineering and, some of the different pieces that go into,
[00:39:52] Unknown:
that overall process. It's definitely something that I find interesting and, I've dabbled in a little bit, but, something that I'm sure would be interesting if I I had the time to dive into it more. So again, thank you for your time. So many interesting things that you that believe me. I'm 60 years I'm 60 years old. I'm still finding interesting things that that I'd like to dive into and there's just not enough time in the world to do it. Right. But I really appreciate you having me on the show and, I hope, brings out some more people that are interested in Skittle. So I appreciate,
[00:40:19] Unknown:
the opportunity to do that. Absolutely. Happy to have you.
Introduction to Dave Vandenbout and Skittle
Dave's Journey with Python
Phases of Electronic System Design
Evolution of Schematic Design
Challenges with Modern Circuit Design
The Birth of Skittle
Visualizing Circuits with Skittle
Testing and Validation in Skittle
Internal Architecture of Skittle
Optimizing PCB Layout
Future of Skittle and Community Involvement
Advice for Aspiring Electrical Engineers
Closing Remarks
