429: Start With Zero Trust
Transcript from 429: Start With Zero Trust with Duncan Haldane, Chris White, and Elecia White.
EW (00:00:07):
Welcome to Embedded. I am Elecia White, alongside Christopher White. This week we will be talking about software defined hardware, jumping robots and origami. Our guest is Duncan Haldane.
CW (00:00:21):
Hi Duncan. Welcome.
DH (00:00:23):
Hello. Thanks for having me.
EW (00:00:25):
Could you tell us about yourself as if we met at an embedded systems conference lunch?
DH (00:00:33):
My name is Duncan Haldane and I am one of the co-founders of JITX. JITX lets engineers write code to design circuit boards. Before JITX, I got my PhD building bio-inspired robots at the University of California at Berkeley.
EW (00:00:48):
Okay. Software defined code to make circuit boards. That seems dangerous.
DH (00:00:57):
<laugh>. Yeah, we found the number one thing that people want is actually much stronger guarantees of correctness from their electronics of, when I order this board, will it explode when I plug it in? It turns out if you use code design hardware, you can be a lot more productive, avoid a lot of errors completely and then also rigorously check your design. So, I will posit that it is actually a bit safer than the usual approach.
EW (00:01:25):
Yes, but they do not have anybody to blame. I have a lot of questions about that. We should do lightning round first, where we ask you short questions. We want short answers. Are you ready?
DH (00:01:34):
I am ready.
CW (00:01:36):
Is a Bristlebot a robot?
DH (00:01:38):
It is not.
EW (00:01:40):
Is it awkward sharing your name with a Nobel Prize winner?
DH (00:01:44):
Not too bad. I get a lot more requests to review condensed matter physics papers though.
CW (00:01:50):
Do you do the reviews? <laugh>
DH (00:01:52):
I do not. I say "You want the other Duncan." And I cc other, Nobel Prize, Duncan.
CW (00:01:58):
What is the best color for a PCB?
DH (00:02:01):
Green.
EW (00:02:03):
Hardware or software?
DH (00:02:05):
It has got to be both.
CW (00:02:07):
Cranes or frogs?
DH (00:02:10):
Crane. The construction or the bird?
CW (00:02:12):
I am going to go with bird.
EW (00:02:13):
That is an origami question!
DH (00:02:16):
Oh, it is an inclusive question. I am going to go with crane.
EW (00:02:21):
Do you normally complete one project or start a dozen?
DH (00:02:24):
Start a dozen.
CW (00:02:25):
What is your favorite fictional robot?
DH (00:02:29):
Marvin from the Hitchhiker's Guide radio series.
EW (00:02:33):
If you could teach a college course, what would it be?
DH (00:02:35):
Computational design.
CW (00:02:38):
What is a tip that everyone should know?
DH (00:02:41):
When you are sauteing food, preheat the pan before adding oil.
CW (00:02:45):
Why? <laugh>
DH (00:02:47):
Because, though all the recipes you eat online are like "add oil and wait until it shimmers", it turns out you cannot get the pan hot enough before your oil starts burning. It is actually way easier to cook if you heat up the pan first, then add oil, then your food.
EW (00:03:02):
Okay. When I was introduced to you, there was a section in the introduction about origami robots, which listeners will realize that was like the key. I mean, you could just say those words to me and I would be like, "Ok! Yeah! Yeah! Yeah!" Maybe I should ask you, what exactly was that, other than Elecia-bait?
CW (00:03:23):
<laugh>
DH (00:03:25):
<laugh> Origami robots was my first project at Berkeley. The lab I was in was doing bio-inspired robots. They made these small systems about palm sized, 30 grams or so, and we matted them out of cardboard. There is this process to take cardboard and combine it with a flexible material to form joints. Then laser cut this thing and fold it up into a 3D shape, that ends up being this really robust mechanism. You can use that to build all kinds of robots that are lightweight and fast and robust. Most robots, you cannot throw against a wall and have them still work. But this origami process, you could.
EW (00:04:07):
Was it because of the joints being made out of flex circuits or something else?
DH (00:04:14):
I think it was the light weight of it. Them being just 30 grams or so gives a lot of robustness. The cardboard was fast and cheap to work with, and the flexers were made out of PET, usually. The same plastic you find in soda bottles.
EW (00:04:31):
You worked on a robot called Salto. Could you describe it?
DH (00:04:35):
Yeah. Salto is what I did after the origami robotics work. I made this little six legged origami cockroach. Then I took it down to the FEMA disaster training site in Menlo Park. How does it perform on rubble? Rubble of the actual scale that you would expect to see in a class building? And the answer was, "Not at all." <laugh>. This was kind of depressing. I wanted to design a robot that could move in that scale. I still wanted it to be small, but how do you take a small robot and have it move in human scale environments?
DH (00:05:14):
Through some biological studies, I looked to nature for inspiration and found the class of jumping animals that do really, really well. So Salto was studying those animals for inspiration, and then applying that to robotics, to figure out how to make a better kind of jumping robot. So how do you get power and controllability.
EW (00:05:38):
So you made this robot that is extremely bouncy. I mean, it is like a bouncy ball almost.
DH (00:05:45):
Yeah.
EW (00:05:47):
Does it have any control?
DH (00:05:49):
Yeah, it does have control. I think Salto was technically my first robot. The cockroach was more like a Bristlebot. So robots, for me, "Sense. Plan. Act". Right? You have to understand your surroundings, figure out what you are going to do to modify your environment or yourself, and then act on it. My background was mechanical engineering, so I ended up designing this pretty complex eight bar mechanism, that made all of the controls sort of decompose into six linear independent feedback laws, that you can just drive the around and it will bounce and take care of itself.
EW (00:06:27):
You just saw the video?
CW (00:06:28):
Yes.
EW (00:06:28):
Can you describe the bouncing for people?
CW (00:06:30):
I encourage people to look at it. It is like a one-legged thing and it can jump like- It evokes a frog or a toad jumping, to me.
EW (00:06:39):
But it does not land really.
CW (00:06:40):
Well in one part of the video, it jumps and then it bounces again off a wall, and then continues jumping. I encourage people to check out the video. We will put that in the show notes. It is a very cool idea, because most of what we see from robotics is, let us make people or androids or four-legged animals.
EW (00:07:05):
Or manufacturing equipment.
CW (00:07:07):
I think taking inspiration from some other parts of the animal kingdom is a really good idea. So where did that go? Was it a terminal research project, or something that is still buzzing around your brain?
DH (00:07:23):
There are other folks that have picked up the Salto torch and they are using it. The robots are designed at Berkeley. I built them as experimental platforms. So people took the cockroach robot and they added a jumping leg or a tail or a shell that helps it move through rough terrain. Seeing that design work open up new research opportunities was what I found really interesting.
DH (00:07:46):
The frustration- It was terminal for me, because I got really fed up with hardware design tools. I was designing spatial linkage in my head, and then trying to unfold to 2D in a way that could be laser cut. I did that in AutoCAD with no meaningful reuse of my work.
DH (00:08:04):
I went to conferences and I saw people that were able to do less science, because they could not do that hardware design task. That just was not okay. I talked to my colleagues in the biology department and they did not know how to design hardware, so they could do less science. And that just started bugging me, a lot! Which is when I met my co-founders at Berkeley.
EW (00:08:27):
This 3D problem I totally understand. The number of prototypes I have dealt with, especially with flex circuits, where you have to put the battery here and the screen here and it folds over, and during debug it is always upside down. So you were thinking about something that combines the electronics necessary to run something like that, but also the mechanical necessary to show how you go from flat to folded?
DH (00:09:03):
Yeah, so my road to JITX actually led through mechanical first. I was designing these spatial origami mechanisms, and I did not have any design tools. No one else in the lab could really do this work and make their own robots. So I took a class from Jonathan Bachrach, who is one of my co-founders now, in the architecture department. They were doing computational design of buildings. What treatments, as they referred to them in architecture. I used that class as a time to learn about computational design, and start building this folded origami robot design tool that was software driven.
DH (00:09:41):
He showed that, instead of typing out a design- You can always type out a design, but that is not really a productive way to work. What you really want to do is write code that automates your hardware design process, so you can break it down into stages, and just write a little piece of code for each one. You can change parameters up here, like number of legs, and then the output should be a design ready to fabricate.
DH (00:10:04):
From there, we expanded the idea into electronics as well. Because, I was designing robots from scratch, including the circuit boards and all the firmware. We actually got a lot of interest when we started applying this to electronics.
EW (00:10:22):
That is a little odd to me. We had a guest recently who allowed us to be hardware engineers, because he was a hardware engineer and did not trust software engineers. They just thought differently. I have to admit that while I am very pleased to get that moniker, I have to admit that hardware engineers and software engineers think differently.
DH (00:10:48):
Yes.
EW (00:10:51):
I am never going to end up being able to use LabVIEW or KiCad. Let us just accept that about myself now. But if you give me typey typey keyboard, I am all over it. Do you really think hardware engineers are going to use this tool?
DH (00:11:12):
Yes, I do. They already are. You pointed out that hardware engineers are not software engineers. That does not mean you cannot make a language for hardware engineers that lets them script. People love scripting. <laugh> You should see the Excel sheets and cathedrals of constraints that hardware engineers build. Now they write Python to test some boards, they write MATLAB to analyze some systems, so they are already doing simple coding. We have that constraint in JITX, you need to just be able to script, to write code that designs electronics. You cannot rely on them to be software engineers because they are not.
CW (00:11:52):
Elecia is very skeptical of this. I am slightly less skeptical, but for different reasons. Is this akin to OpenSCAD where, unlike most 3D CAD programs where there is a lot of mousing around and dropping components and doing almost painting and carving and all the things you have to do when designing 3D parts, OpenSCAD is a descriptive declarative language where you write in text and on the right side of the window comes up the 3D stuff and you can parameterize things that way. Was that something in your mind? Or is this a parallel convergent evolution kind of thing?
DH (00:12:35):
Yeah, great question. I used OpenSCAD when we were doing the mechanical design tools at Berkeley. I think it is very similar in that you have code in and designed object out. For OpenSCAD that is like an STL, and that is what you get. There is a difference, in that JITX is embedded in a general purpose programming language. So you can actually write arbitrary code to design, and not just the limited semantics of something like OpenSCAD, or VHDL for that matter.
CW (00:13:07):
So it is less like some of the declarative UI frameworks, where you are stating how things are. You have actually got a full programming language that can perform functions and iterations and conditionals and things.
DH (00:13:22):
Exactly.
CW (00:13:23):
Okay.
EW (00:13:25):
Why would you need a conditional in-
CW (00:13:28):
Do you know how many times I reach for conditionals in declarative languages?
DH (00:13:32):
<laugh>
EW (00:13:32):
I know, but-
CW (00:13:33):
They are not there!
EW (00:13:34):
Is it a conditional that will end up being on the board, or is it a conditional that is going to end up being in manufacturing?
DH (00:13:43):
Oh, the conditional happens before you reach board level. It is about putting your design together in a productive way. You are like, okay, for this circuit, designing a voltage divider, but I also want to insert a database query so I can pull relevant resistors to load into this solver. You can do that from the exact same interface that say like, connect this exact pin to this exact pin. It is a way to use pretty powerful solvers at the same level of like, I need to describe this one weird thing, because on each board there is at least one weird thing, that is going to make it work or get a little bit more performance.
CW (00:14:23):
So it is not so much something like, if this is the debug build, add, you know, expose the JTAG port, and if not cut it off. It is deeper than that. You can go off and do, like you said, database queries and do things based on the results of that?
EW (00:14:39):
If Digi-Key has this part in stock-
CW (00:14:41):
No, this is really cool.
DH (00:14:45):
You mentioned the JTAG example. Actually we did that one. So I specify this is a debug build, and I want all these extra jumpers and these exposed interfaces and extra LEDs and put it on one side and be very verbose with labels. Then I can change one flag, which is this a production build, and remove all of that. I think one of our customers, GeoScene, wrote an article to that effect, where they prototype on a set of multiple boards and then production version squishes all those together.
DH (00:15:13):
When we designed JITX we said each line of code should be a line of intent. And, "this is a debug build" is a line of intent, so you should be able to change that to production, and have the rest of your design just update.
CW (00:15:27):
Now I am not super familiar with PCB design tools. I have used KiCad a little bit to try to make some small hobby things. For the ignorant, how would one go about doing something similar in a normal PCB design schematic capture tool? Is that easy or is that impossible?
EW (00:15:47):
Two separate schematics?
CW (00:15:48):
Yeah.
DH (00:15:48):
Yeah. It is two different designs. You just hope that you got it right.
CW (00:15:52):
Okay.
EW (00:15:54):
The going from 2D flat to a 3D circuit, how does that work for you? Is that still part of JITX, or was that not kept as you grew the company?
DH (00:16:10):
That has not been a focus, actually. With JITX we took the stance of, the input to JITX needs to be high level engineering requirements. You need to know what the circuit is supposed to do, if you expect to do anything smart about it. So your input should look a lot like your engineering requirements list. And the output, of the product right now, is a detailed schematic that is also rigorously checked for correctness, so that you are confident that when you do the place and route, it is not going to explode when you plug it in.
CW (00:16:43):
What does correctness mean to you? As a software engineer, correctness of electronics, to me, means somebody understood how circuits work, which I do not.
EW (00:16:55):
Somebody put in the capacitors that were the right level, and not just random like I would choose.
CW (00:16:59):
<laugh>
EW (00:16:59):
Someone chose voltage dividers that are available in voltage-
CW (00:17:05):
No, for me, someone used a voltage divider, is the level I am at.
EW (00:17:08):
For me, I will design a voltage divider, and not really think about the fact that resistors come in certain values, and that you should use those values and not just random.
CW (00:17:19):
But seriously, it is verifying the netlist, and that there are no weird loops or misconnections? Or is it deeper?
DH (00:17:29):
Yeah, it kind of starts at connectivity. A whole class of errors that are currently kind of caught by ERC in the schematic tool. If you add all the data.
CW (00:17:41):
That is the rules thing?
DH (00:17:45):
Yeah, you can like set pin types and then configure this matrix of rules of, you cannot connect two inputs together, except for when you can.
CW (00:17:52):
<laugh>
EW (00:17:52):
And you cannot have traces too far or too close together.
DH (00:17:56):
Yeah, that is physical rules. But I am talking just basic schematic level. All those connectivity things where you might, like, swap the endianness of a bus or something, are just turned into compiler errors. You just cannot make that kind of incorrect design. And then there is another level of correctness, which is-
EW (00:18:15):
No, you should stop there.
CW (00:18:16):
Do you have a thing that prevents us from making TX and RX on UARTs backwards? Because if so, we can just end the podcast here, and I will give you all my money.
DH (00:18:26):
Excellent. I will send banking details later. Because that is the next level of checks. You have your schematic review checklist, right? And hardware engineers will run through this checklist to make sure that inputs and outputs are appropriately connected. We have automated that level of checking in JITX. Like, the IO levels are correct, they are correctly connected, the voltage levels are correct, the power supplies are correctly given an outputting power, you are not going to explode your capacitors. All of those.
DH (00:18:57):
We found that you need that to actually have reusable code that writes hardware. I can write a script and it will make a circuit, but if I do not know that that circuit is correct, it is kind of worthless from a productivity point of view. So we found that to actually get reusability on hardware, you need to be able to basically embed these checks in with your circuit, right?
DH (00:19:23):
So when you model a part, you say like, this is a digital output pin and it has these properties based on the voltage properties of this pin. You just have to make it very productive to add that information, so that your boards work when they come back from the factory.
EW (00:19:38):
How many designs and boards make it worth it to do this? If I have a one-off motor controller, that is not very many parts, and it is not that hard to put together. Says the person who had to have somebody- "Thank you Casey, for putting together my board." <laugh>.
DH (00:20:05):
Yeah. Right now JITX is targeted at professional electrical engineers. They need to move fast. They need to ship usually a lot of boards. That is where we are targeting with our initial product. I do not know what the cutoff is. I really enjoy using JITX for small projects, like around the house. It is just fun!
DH (00:20:28):
The checks save me even on those small projects, because there is always something that I missed. Like, I almost had an undervoltage-lockout error, when I was sleepily designing this little IoT widget and the check saved me. So even on a small design, I saved, you know, two weeks and a couple hundred bucks. On large designs, you get a lot more value from the checks, because your components are more expensive and you have several thousand components to analyze.
CW (00:20:56):
Yeah, I am thinking ahead in ways that may not make any sense. Like in Python, you can import modules that bring you all kinds of functionality. So I am sitting here thinking, well at least can just import motor controller. And then have that be a parameterized function that generates a motor controller to her design spec. Why does not that exist?
EW (00:21:20):
I am thinking about children's toys where we had the same base circuits. There were only five circuits and we would put them together differently for different toys, and the number of buttons. This sort of thing would make sense for that, because you would say, grab this and this and mash them together.
DH (00:21:42):
Yeah, you guys got it. You take it from here. This is exactly what the technology is for.
EW (00:21:49):
I have a small tangent about test-driven development. Are you familiar with that concept?
DH (00:21:53):
Yeah, I was actually about to write a little article on it, but I want to hear your take.
EW (00:21:59):
In test-driven development, you often want a piece of code and you write the test for it and you let the test fail. Then you write the code to fix it. You were talking just a few minutes ago about making sure boards did not blow up. I just wanted to know, <laugh>, did you use test-driven development to make sure the boards would not blow up, by initially generating boards that did blow up? And if so, can I have those? I like fire.
DH (00:22:31):
<laugh> Yeah. I have just had little pops so far. I have not done more of the ambitious power electronics. Yeah, I found it did save me. So when I was doing test-driven development, was when I was writing the first checks in JITX. It was like, you know what, I am going to model this fairly simple circuit. As I go along, all the things I am checking in my head when I read a data sheet, and then like read another data sheet, and make sure two components are going to work together, I am actually going to turn those into checks and I am going to stick those in the component. They saved me immediately! So I did model a component, like I could legally make this netlist, but when I ran those checks that I wrote, the tests, they said like, "Well you forgot to connect this ground pin, and this pin is about to be burned out by five volts."
EW (00:23:23):
You said it goes to a schematic. I saw a video where I know you can load it to KiCad, and I assume Altium and EAGLE and whatever else is out there.
DH (00:23:38):
KiCad and Altium right now. We will be adding extensions for the other ones as they are desired.
EW (00:23:46):
Can it go the other way? Can I start something in a schematic, and then dump it to some format that will then go into JITX, so I can get these checks?
DH (00:23:59):
Yes. That is one thing we have worked a lot on recently. That was the big thing to clear, before we release general availability. Because professional engineers, they have an in-flight design, and they need to like update it or fix it or check it. So we can read in existing CAD files and generate JITX code in a way that is nice and reusable. Now you can say, "Oh, I can take this power circuit, and make it parametric and add checks to it, and now I can reuse it across all my other designs." It is just a way for people to get started faster.
EW (00:24:31):
Generated code tends to be difficult. How different is the code you write for your own projects, from what comes out of the generator?
DH (00:24:46):
Not different at all. We have worked a lot on improving the ergonomics of the generated code. We used a lot of programming language techniques, intermediate representations, and it turns out you can actually make pretty good generated code. It does not have to be spaghetti.
EW (00:25:05):
Are you having trouble getting EEs to trust the output?
DH (00:25:10):
Yeah, that is the default, is that electrical engineers start with zero trust, because that kind of vigilance is what you need to make hardware work.
EW (00:25:19):
Exactly.
DH (00:25:20):
That is there every day. What we do is, everything is open. You write your code, it is open code, you can read it. Then you can inspect the data that it creates, and then you can export the CAD file, and it will be your CAD file as if you wrote it yourself. Then we do things like draw schematic, to make it more understandable. And make it easy to like just dig in and pick out every little piece of the code, to understand exactly what added this capacitor.
CW (00:25:50):
It is interesting because while you are paralleling some things from software development, one of the things that does not super parallel is the output. Like, you get a schematic out that a human can look at. It might be complicated, but electrical engineers, I assume are good at reading schematics and verifying in their heads and things. It is comprehensible. The output of a compiler is machine code, which some people can read and interpret, but not very well after it is compiled, because the optimizations are such that it is incomprehensible.
CW (00:26:23):
That is kind of an advantage on your side is that you can prove to a EE, "Well this schematic, do you like this schematic?" And they say, "Yes!" And then you say, "Well I generated it from this code." Then you kind of won. Whereas with software, if somebody comes up with a new programming language, and you hand them an object code and say, "Do you like this?" "I have no idea, it is incomprehensible." That is interesting to me. I do wonder though, is there a future where JITX produces incomprehensible electronics, because you have optimized things such that a normal electrical engineer would not produce schematic like that?
DH (00:26:59):
Yeah, I think incomprehensibility, or at least unfamiliarity, comes in more on the physical design side. Like, this layout, is this really the best you can do? For us, what that means is you have to prove that it is good, right? You have to run some detailed analysis simulations to know in a very rigorous way exactly how good it is.
DH (00:27:23):
My goal for JITX is that it does allow for optimization, and I will know that it is really, really working when you can design better hardware with JITX than without it. That is the overall goal. It is not just about enabling new engineers, it is about making all hardware better, right? How do you actually take the best of how humans know how to design hardware, and make it so you can apply that knowledge to every single board that goes out the door?
EW (00:27:54):
I have been told that it is very important that should I ever become proficient with schematic capture, to never trust the autorouter. Are you going to tell me that I should start trusting your autorouter?
DH (00:28:11):
I feel like we should not call it an autorouter.
EW (00:28:17):
You did say you output schematics.
CW (00:28:19):
He is before all that.
EW (00:28:20):
And autorouters are for Gerbers.
DH (00:28:25):
Yeah. The router is for the physical design, right? We are making our own autorouter, routing algorithms, let us say, to bridge the schematic and the physical design. That happens for pin assignment, right? Engineers are usually swapping pins to make things easier to route, so you can do it on fewer layers, use fewer vias. We built these routing algorithms as a way to aid that optimization. As they develop, I think they will be a useful tool.
DH (00:29:02):
Actually being able to do boards with a hundred percent automation, where not just the schematic that is checked, but placed and routed components. This is a different type of autorouter. It is meant for optimization, over saying, "I have got this fixed placement of components, and you are not allowed to swap anything, and I give you no electrical constraints because I do not have the way to add those to an autorouter, and do your best." And the results are predictably not good when people do not trust the autorouter. That is why.
EW (00:29:36):
One of the things that schematic capture has gotten so much better in, with the last probably decade or more, is that there are more parts in their libraries. You do not have to type in all of the pitch information for a part, and the size, and make sure you get every little thing out to three digits. How many parts are in your library?
DH (00:30:06):
I think about a million. There is a bunch of sources for parts online, but for the library generation we found it is actually a lot more productive to just make it programmatic. So everything in JITX you can drive with parameters. It turns out, if you are making a lot of something, or a device that goes to space, you actually need to customize the land pattern. You know, the thing that attaches the component to the board, for your specific set of materials, and for your specific environment.
DH (00:30:39):
It turns out there is actually no one good library and it is always designed dependent. So we focus on automating that part. Maybe you can squeeze a bit more yield out of your boards just by default. The library challenge, we have these importers you can just bring in your existing library, but past that I think you need this library to be a bit smarter, a bit more capable and actually help engineers cut waste at the factory.
EW (00:31:11):
There is a balance between that level of flexibility, and the complexity of making sure all of the correct optimizations and flags are chosen. I think that is where a lot of the distrust from electrical engineers might come in. How are you going to deal with that?
DH (00:31:35):
We have dealt with it so far by, make it fast, interactive, obvious what the knobs are, adding a lot of facilities, language to understand exactly what this interface is. It is not just closed core code and all these locked-off parts of the software. You can just inspect it and see exactly what it is doing. So I think that transparency is the thing that helps the most.
CW (00:32:01):
At the risk of doing visual stuff on a podcast, can you give a sense for just starting from scratch. Say somebody is trying out JITX. What is it like? What does it look like to do a simple port, say a 555 driven blinky? Or a guitar pedal, for example, with an op amp and a buffer and input and output in nine volts? I do not know, some simple-
EW (00:32:29):
He wants a really detailed guitar pedal.
CW (00:32:31):
No. Half a dozen to a dozen parts. What does the language look like for a simple, for the "Hello, World!" of JITX?
DH (00:32:43):
The language is designed to read like how you think. Do you want to do this line by line, of like how do you think? And I will tell you what the code looks like.
CW (00:32:53):
Sure.
DH (00:32:54):
Typically, it says add this part, here is the 555, and I am going to pass an argument to it. I want this in a stable setup, right? And produce this frequency.
CW (00:33:07):
Okay.
DH (00:33:08):
That is a common parametric function, to set up this 555 circuit and then I will add the chip, and the associated housekeeping components, to get it producing this output. Then you add your connectors and you typically make that bundles, which is just like a connection of pins and other bundles. Maybe you have this SPST switch, or whatever interface you have, and you net these high level things together.
DH (00:33:36):
Then you run your design. It creates a schematic and a board immediately. It is like, we have an interpreter, a shell, that is just very interactive. You type your code and your schematic board starts showing up. You can get in there and change the code, change your parameters. Then check the design, so you can run the design checks, make sure it is going to work. Then export to CAD, and it will emit to KiCad or Altium. Board, schematic, part library. It will do a real time component optimization, so you can actually order all the parts. From there, you are going to do your place and route in the existing design tool.
CW (00:34:11):
Right.
EW (00:34:15):
Modeling the circuit, will it do things like frequency analysis?
DH (00:34:21):
I think that is coming next. We have been focusing the analysis on checks. This is kind of like continuous integration style stuff. It is not for optimization, but it is rather just make sure you are in the realm of it actually operating correctly. But we will be hooking back into SPIs soon, to create some automated model synthesis, to just run more checks without the user having to write more code. I think once we have that SPIs hook, you can start bringing in things like harmonic balance analysis, to really get fancy.
CW (00:34:53):
How many lines of code would that 555 blinky end up being?
DH (00:34:57):
It depends. That is the fun thing. Because you can raise the abstraction level up to whatever you want. It could be one line of code.
CW (00:35:06):
Are there pre-existing modules I can just say 555 blinky? Or would I have to develop that up from scratch?
DH (00:35:13):
Actually that is how we start people. My lead product designer did not know anything about circuitry. So I had him follow, I think it was, Chris Gammell's "Getting to Blinky".
CW (00:35:24):
This is why I use this example.
DH (00:35:27):
Then I had him do it in JITX. Yeah, everybody makes this module, where you configure it of your high level parameters, your intent. For this, when it is configured as an oscillator, it is just what is the frequency? Now that is like a high level module, and then you could stack that up into a higher level thing of, I want a parametric number of blinkies, or I want to change this into a polyphonic synth or something. You just get to reuse the same circuit.
EW (00:35:54):
I have this question about KiCad's definition language, SKiDL. It sounds like what you do is pretty different. Is that right?
DH (00:36:06):
Yeah, SKiDL is, I think, Dave's project. It is not just KiCad. He has his own separate project. I think it produces KiCad files, and I think it imports KiCad files. It is similar in that you are writing code to design hardware. The differences are just we have been focused on features professional engineers need. Like, it needs to work with Altium, it needs to hook into a PLM database, it needs a schematic. Because that is a legal requirement for professional engineers. So I think that is the main difference. But it is very similar in spirit.
EW (00:36:39):
And it is Python based.
DH (00:36:42):
Yeah. He wrote it in Python. I have a hardware architect, who was actually a SKiDL user before he joined JITX. His feedback on the Python thing is, "It works if you write it in a Pythonic way." Python does not have like strong type system, which is one of the things we have to make it easier to write JITX code. So I think the ergonomics are a bit different. We used a macro system to make it so it is very clear to an electrical engineer what this line of code means, and to write that code correctly, and get like informative messages when it is not correct.
CW (00:37:19):
I am going to ask a software engineering centric question. What developing languages is a peculiar, arcane <laugh> realm of expertise? What did you take inspiration from when designing the language? Is it something that is kind of new from scratch, or did you have certain things you were picking from other software development languages?
DH (00:37:47):
For JITX, we did it from scratch. We actually started as a design contractor using JITX. So we would take on contract design work, and used JITX behind the scenes to do as much of it as possible, and then rewrite JITX. Until the language actually converged to something that was really, really productive, and could express all the constraints that you need to care about for doing boards. We wanted it to be simple, read in a simple way. Like, we do not want a bunch of parenthesis everywhere. It kind of reads like Python, those are the primary sources of the language design.
EW (00:38:28):
I put it somewhere between C and Python, given how little I have looked at it.
DH (00:38:33):
Yeah. It is a good gut check.
CW (00:38:34):
It does seem like the problem you are solving is distinct from general software development. So it would have its own ways of expressing things, and perhaps concepts that do not map easily.
DH (00:38:51):
I think on the technology side, we find ourselves using a lot of programing language techniques, to make it just more tractable to write this kind of software.
EW (00:39:00):
You had a question for us. I have it written here, but do you want to ask it in your own words?
DH (00:39:07):
So my question for you is, imagine hardware design was free. You have got a pile of virtual hardware engineers, that will design and optimize anything you want, all the way through to production. When you think back to projects you have worked in the past, when would that hardware design power have made the most difference? What would have been different? How would the world be different now?
EW (00:39:33):
I have had so many product ideas, and I get to the point of having a prototype and putting it together and realizing it. It is so hideously ugly, that I really cannot bring myself to continue working on it. I wanted to do this shirt that put accelerometers and motors, small vibe motors, across your back in a T formation. At the bottom, there would be a little battery and a controller and it would check your posture.
EW (00:40:09):
Having had one of our listeners make the little motor accelerometer board for me, and putting it all together and putting it on a shirt, and making the vibration happen and realizing the shirt had to be pretty tight, I took it to show it to some folks. But it was so ugly, and it was so clear that the difficulty was in the wiring and not in any of the other pieces. Is that the sort of thing you are asking about or something else?
DH (00:40:43):
I am, yeah. I was trying to think about the impact that we are trying to have on the world. My hypothesis is, if you make hardware engineering more automated, the world would be better. In this case it would be, you have this idea, your tool should support and say, "This is what you asked for. Is this what you want?" Then you can have, I would hope for, a more interactive conversation with that tool. Rather than, I am going to take this sequence of steps, look at the end result, and be fed up with it.
CW (00:41:16):
I am going to answer for me, in a way that maybe is not what you are after. Like Elecia, I have had ideas in the past, but I have stopped a lot earlier. As soon as I realize, "Oh, this requires custom electronics. No, thank you." <laugh>
CW (00:41:31):
That has gotten a little easier in recent years because of the Adafruit, SparkFun mode of, you buy six modules and you hook them together and now you have got a prototype. Where I think it would make a difference for people like me who are not electrical engineers, but who have ideas that are electronics projects or want to make prototypes, is taking that sort of SparkFun, Adafruit approach to modularity, and making it so that custom boards are just as easy to do as that.
EW (00:42:10):
Ah, import this board from Adafruit, and that board from SparkFun, and mash them together into one.
CW (00:42:15):
Not even necessarily that so much. Not even specifically those boards, but the thing that does that. So like, "I need three accelerometers, I need to hook those up to a STM32, and I need the power and all that stuff. Spit me out a board that does all of that, and is compact enough to be a prototype." That would be really cool to me, because then I could skip all of the- Everybody is trying to make their lives easier, right? <laugh> I am interested in the software part, the firmware part, and the final product, and making something work, and less so on the electronics.
EW (00:42:53):
I just want the electronics to work. I do not want to be bothered with them. <laugh>
CW (00:42:56):
Yeah. Where my skepticism rises up is, for decades there have been products that claim to do this for software as well.
EW (00:43:05):
<laugh> It is true.
CW (00:43:07):
Right? It is like, here is your program that writes your program for you. I get that these are completely different spaces. That is what I was alluding to, with the output being comparable and visualizable by a human, versus a software output. So it is not really a valid skepticism. Yes, it sounds great, but from my perspective, it would be most useful at the prototype stage, for me. I think companies would find different attractiveness.
DH (00:43:37):
Yeah, I felt the same thing in grad school. That is why we have it free for educational use is, this thing should enable. There are a lot of ideas and a lot of projects that just die before they could get out there and seen and interesting. Turns out the bar for making those work, making those electronics, is actually not that high. I think doing it for software is actually a much higher bar. Yeah, I get it. That is one of the reasons I wanted to start this company. I think there are a lot of ideas that just need a little more space. Just a little bit to push them over the edge.
EW (00:44:19):
You said all the way to production. In my example, a large part of my problem turned out to be mechanical. Electrical, I work close enough that I understand most of of what is going on there. But cabling, buttons... I mean I can drill a hole into a box, and usually my boxes are Tupperware, sorry. But that is never going to be good. You stop at the electrical part, right? I still have to worry about how to get the button working.
DH (00:44:52):
For now. Yeah, we started with electrical, because this was, I think, the biggest opportunity for automation, right? If you can send a well constructed zip file to a factory, they can send you a pretty complex circuit board back. JITX means "just in time, everything". I started from the mechanical side, so people are already designing systems of boards in JITX, and you can actually look at what your system would look like when you split it up this way.
DH (00:45:18):
Next I think is more electromechanical integration. We are also going down the scale of looking at advanced packaging. But as a roboticist, getting the circuitry to fit around all the complex mechanisms is always- It needs attention. I am excited to be doing that next.
EW (00:45:38):
Little robots like OpenRoACH. Can you make those with JITX now, or do they need additional mechanical consideration?
DH (00:45:50):
OpenRoACH was one of my grad school efforts. I went to the robotics conferences like, you know what, maybe they need a platform, so I can open source one of my robot designs, and I can make it so you can use commonly available parts, and you actually do not need to do any design work at all. You could just make this thing.
DH (00:46:08):
That did not really work out, because everyone wanted to do something a little different. They wanted it bigger or smaller, or to have different legs, and they would have had to basically been able to redesign it from scratch, to make that happen. So that was actually one of the final straws. It was like, you know what, I am in go fix design tools.
EW (00:46:28):
Has it been strange for you to take that step back from, I am going to make things to, I am going to make things that make things?
DH (00:46:37):
Yeah, it was a step back. What I really loved doing- My track was research professor, right? I loved science, but I saw this as, if I am going to be a research professor, my students are going to be grinding out the exact same thing. And I just could not have that, right? I was not okay with all these projects not making it out into the world.
CW (00:47:04):
What you need is a language that defines grad students.
EW (00:47:08):
<laugh>
DH (00:47:11):
<laugh> Exactly. They are working on it.
EW (00:47:12):
That should have been one of our lightning round questions was, academic or industry? You have chosen industry for now. Is that a choice that may go back and forth? Or probably going to stay here?
DH (00:47:26):
It is a good question. Industry was the best choice for making JITX happen. We talked about it being all sorts of things. Was it a collaboration between professors? Was it an open source project? We looked at the problems that needed to be solved, and it was like, a startup is probably the best vehicle to address these things. So we did this startup. I am thinking about JITX right now, and JITX's future. I am not sure what I am doing afterwards, but there is a lot to be done to automate hardware design like this.
EW (00:47:57):
You mentioned being a contract designer, but JITX now, you just got a funding round, and things have changed a little bit for the company. Where are you? What are you doing?
DH (00:48:13):
Yeah, so we were hardware contract designers while we worked on the early technology. As soon as it was stable enough, we switched to releasing it as a product, so someone can use JITX themselves. Because that is just a better way to help a larger number of people. Today? Yeah, we just announced our Series A from Sequoia Capital, and we are 18 people based in the Bay area, working on JITX, making this tool be the best it can be.
EW (00:48:44):
You said you were not sure about what is going to happen after JITX. Do you have plans for while you are at JITX?
DH (00:48:50):
Yeah, with the Series A, we are going to be scaling beyond just a schematic, and bringing on our physical design algorithms. So you can actually optimize entire designs before you leave JITXs and go back to a CAD tool. And building out a database with components, that is meant to optimize designs. Also stay on top of the component supply chain issues.
EW (00:49:13):
The person who is going to be doing the origami piece, so that I can have my light up octopi that are curved, creased fancy things. When do you hire that person?
DH (00:49:26):
A good question. We are going to be looking at-
EW (00:49:26):
Serious Q. <laugh>
DH (00:49:31):
Yeah, well we are doing flexible electronic design quite soon. Because it turns out that is one of the best applications for the autorouter we are nearly finished with. Maybe that is the road. Go with origami electronics. And then maybe just origami.
EW (00:49:46):
When you talk about 3D routing, that is where you have to talk about origami to some extent. There is a difference between folding and bending, and most circuits prefer to be bent, not folded. <laugh>
DH (00:50:01):
Yeah, it is a matter of a radius.
EW (00:50:05):
And you are hiring. What are you hiring for?
DH (00:50:08):
We are, yeah. We are hiring software engineering roles, like for the front end to help us build JITX the product. Also opening up roles for hardware designers that want to be working in JITX, and building examples and writing about them.
EW (00:50:24):
Ah, yes! Those people who are your seeds.
CW (00:50:31):
Evangelist.
EW (00:50:32):
Evangelist. Yeah, that is the word.
CW (00:50:35):
Let me ask you some detailed questions about JITX. Is it a standalone application? Is it cross platform? Is it web based?
EW (00:50:42):
It runs in VSCode!
CW (00:50:43):
I was about to ask, do you have a VSCode extension? As a joke. Does it?
DH (00:50:48):
No, we have a VSCode extension as a very serious release mechanism.
CW (00:50:52):
Oh, okay.
DH (00:50:52):
It is cross platform, works on Mac, Linux, Windows. And it works locally. So it primarily works on your local machine. Your data stays on your local machine. We also have some cloud services, where you can pull down component models from a database.
CW (00:51:09):
It is not like DALL-E, where you ask for a circuit board that is a calculator, and out comes...
EW (00:51:18):
Darth Vader holding a Popsicle.
CW (00:51:19):
Yeah. <laugh>
DH (00:51:21):
Not yet.
CW (00:51:22):
You did mention AI in some of your marketing literature and stuff. What does that mean to you?
DH (00:51:30):
We use AI methods to build solvers. Use of machine learning is pretty scarce, because the most important thing was that it is explainable and repeatable.
EW (00:51:41):
Repeatable.
CW (00:51:43):
This is the correct answer. Thank you.
DH (00:51:45):
Okay, good. We use solvers so you can make code that is more reusable, right. So we scraped all STM32 microcontrollers, right? We made it so that you can actually swap any microcontroller in, for any other microcontroller. To do that you need to write some solvers, like how do you connect these IO pins to all your peripherals? We use a solver for that.
EW (00:52:08):
Did you pull in the SVD files to do that? That seems like the easiest way to do it.
CW (00:52:13):
The debug definition files that the JTAG things use.
EW (00:52:16):
CMSIS it generates, CMSIS requires.
DH (00:52:20):
We pulled in XML files from the CubeMX project, that sets up your-
EW (00:52:24):
Okay. Those are-
CW (00:52:25):
That is probably better.
EW (00:52:27):
I think they are the same, actually.
CW (00:52:29):
The same? Oh, okay.
EW (00:52:29):
Or they are generated from the same originals.
DH (00:52:32):
Yeah. We try to find these little, like it was a little treasure trove of data, right. It actually describes their entire product line, with enough information to significantly automate the design of it. It was a great find.
EW (00:52:47):
This is probably not something you really want to know, but the SVD files are for all of the processors that are Cortex based.
DH (00:52:56):
Ah! Okay.
EW (00:52:58):
I think they are either that XML format or very, very similar to it. It is from CMSIS, which is from ARM. They define how the SVD files are supposed to be set up. They include all of the pin definition, and the cores, and then all of the registered definition, which you do not care as much about. It tells you which pins can be SPI, which pins can be I2C, and that kind of thing. Which you probably do care about.
DH (00:53:23):
Yeah! Okay. I will check it out.
CW (00:53:25):
Or it is Cypress and it generates a new one every time you touch the hardware.
EW (00:53:30):
<laugh> "This information does not apply to PSoC." I feel like that should be on all PSoC information. <laugh>
CW (00:53:36):
To go back to AI just for a second, one thing I have been noticing is that people, when they see somebody say AI in their product, they start to get a little twitch.
EW (00:53:45):
Ooh, yeah.
CW (00:53:48):
Which is not equally distributed across industries. Like if you have an AI photo retouching program, people are like cool.
EW (00:53:54):
Ooh, neat.
CW (00:53:55):
If you have an AI something that is making something, people get nervous because they think machine learning now, because machine learning is so deeply tied to AI. Have you noticed that when discussing with people, or not so much?
DH (00:54:08):
Yeah, I think it comes up when people expect me to be selling a bunch of hype about an AI powered autorouter, which would somehow magically solve all problems, without knowing any detailed electrical constraints.
CW (00:54:22):
<laugh>
DH (00:54:22):
So I think it is a matter of expectations, is how it shows up to me. Pragmatically speaking, you can use AI methods in some places, to write software more easily with a smaller group of people. There are some things that it is really well suited for. You also have all of the data center people racing to make these algorithms run as parallel and as fast as possible. You can ride that wave for some parts of your software.
EW (00:54:54):
But when you want something that is repeatable, and demonstrate-able, and checkable for correctness, you see the word "solver" and that means we are going to do it the same way each time. Or say, finite element analysis. It means, we are not going to get random answers at different times of the day.
DH (00:55:17):
Yeah. And the mechanism of how it found that thing, and determined that design, can be explained, and debugged, and optimized in a very transparent way.
EW (00:55:29):
And it is not just, run it again to see if it will work this time. <laugh>
CW (00:55:33):
Yeah. I want to up Monte Carlo schematic generator.
DH (00:55:38):
Yeah, I mean it has its place. Stochastic optimization algorithms are fun to play with, but you do not want them guaranteeing properties about your design. But you can use it to search a space, or optimize in a way that is interesting.
EW (00:55:50):
What is your least favorite FAQ question? What question on your FAQ page do you wish did not have to be there?
DH (00:56:00):
I do not know. I am always excited to answer questions. I think, my least favorite ones are the missing ones. I always wonder like, someone shows up to my website, and what do they want to know? <laugh> What question have I not answered yet?
EW (00:56:12):
Do you think there are other kinds of abstraction and automation, already available in the hardware world?
DH (00:56:19):
I have not seen much abstraction. That one was something we had to build a lot ourselves. There is a lot of little pockets of automation though. There are antenna optimizers, and circuit designers, and all these little spot tools that are locally pretty good. You notice there is no way to connect them to the rest of your system. You can put numbers into a voltage divider solver, but it does not connect to the inventory you have in the warehouse.
CW (00:56:50):
Why do you think this has not been done before?
DH (00:56:53):
Hmm. I think the reason is largely historical. Back in the eighties, people started writing code to design circuits, and they were doing it for chips because chips got too complex to do any other way. And you could make better designs by writing code, than drawing schematics. Then it happened for FPGAs, so people do not draw schematics to program FPGAs anymore.
DH (00:57:16):
But boards stayed pretty simple until like 2008, and you start having things like the iPhone. By then, the big CAD companies found their zone, and it was not really caring about PCB design tools focusing on IC. So you ended up with this tool stagnation because the board stayed simple, until the companies calcified them. What they do well.
DH (00:57:41):
Now things are weird, right? Devices have like three radios, and as much AI as possible, and it is battery powered, and it is flexible, and 3D. And you are designing it with basically the same tool that people were designing those boards back in the eighties. That just stopped working well. So now we have like a pretty serious productivity problem. And you are stacking on the component shortage, caused a lot of extra work. And it is also just harder to find electrical engineers now. So we are left with this opportunity, if you can actually meaningfully improve how people can design hardware, now it is pretty valuable, and the opportunity is there in circuit boards.
CW (00:58:27):
All right, cool.
EW (00:58:28):
All right. I do not know that you have entirely convinced me, but I do have some ideas for other products, so. Hmm. And I know he wants a guitar pedal. I can just see it in his eyes.
CW (00:58:40):
No, I have some ideas.
EW (00:58:41):
Duncan, I believe you were going to give us a coupon code.
DH (00:58:46):
Yes. I can offer a free month of JITX for embedded.fm listeners. Use our website, jitx.com to sign up and mention embedded.fm.
EW (00:58:58):
And Duncan, do you have any thoughts you would like to leave us with?
DH (00:59:02):
I think what I would like most is just to hear from designers. We are launching JITX because it is ready to use and it is helpful, but I know it is not perfect. We really want it to be the best it can be. So, if you have any thoughts about this or what you want from your design tools, please reach out.
EW (00:59:21):
Our guest has been Duncan Haldane, CEO of JITX. There will be a link in the show notes to that and a few other things.
CW (00:59:29):
Thanks Duncan.
DH (00:59:31):
Thank you.
EW (00:59:32):
Thank you to Christopher for producing and co-hosting. Thank you to Anita Pagin for pointing me in the direction of Duncan, and to our Patreon listener slack group for their help with the questions. And of course, thank you for listening. You can always contact us at show@embedded.fm or hit the contact link on embedded.fm.
EW (00:59:51):
Now a quote to leave you with. I searched for quotes about origami and ended up with Voltaire. "One always begins with the simple, then comes the complex, and by superior enlightenment one often reverts in the end to the simple. Such is the course of human intelligence." Voltaire, Dictionnaire philosophique.