Embedded - 429: Start With Zero Trust

Episode Date: September 29, 2022

We spoke with Duncan Haldane about creating hardware schematics by writing software code, three dimensional circuits, and bio-inspired jumping robots.   Duncan is the CEO of JitX (jitx.com). They recently received Series A funding and are currently hiring engineers. Please mention that you heard about JitX here on Embedded. While earning a PhD at UC Berkeley, Duncan (@DuncanHaldane) also worked on Salto (video) and OpenRoach (github). Transcript

Welcome to Embedded. I am Elysia White alongside Christopher White. This week we'll be talking about software-defined hardware, jumping robots, and origami. Our guest is Duncan Haldane. Hi, Duncan. Welcome. Hello. Thanks for having me. Could you tell us about yourself as if we met at an Embedded Systems Conference lunch? My name is Duncan Haldane, and I'm one of the co-founders of Jidex. Jidex lets engineers write code to design circuit boards. Before Jidex, I got my PhD building bio-inspired robots at the University of California at Berkeley.

Okay, and software-defined code to make circuit boards. That seems dangerous. Yeah, it's actually... 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? And 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'll posit that it's actually a bit safer than the usual approach. Yes, but they don't have anybody to blame. But I have a lot of questions about that, and we should do lightning round first, where we ask you short questions. We want short answers.

Are you ready? I'm ready. Is a bristlebot a robot? It is not. Is it awkward sharing your name with a Nobel Prize winner? Not too bad. I get a lot more requests to review convinced matter physics papers, though. Is it awkward sharing your name with a Nobel Prize winner? Not too bad. I get a lot more requests to review Convinced Matter physics papers, though.

Do you do the reviews? I do not. I say, like, you want the other Duncan. CC, other Nobel Prize Duncan. What's the best color for a PCB? Green. Hardware or software? It's got to be both be both cranes or frogs

crane the construction or the bird I'm gonna go with bird it's an origami question oh it's an inclusive question I'm gonna go with crane do you normally complete one project or start a dozen

start a dozen what Start a dozen. What is your favorite fictional robot? Marvin from the Hitchhiker's Guide radio series. If you could teach a college course, what would it be? Computational design. What is a tip that everyone should know? When you're sautéing food, preheat the pan before adding oil. Why?

Because all of the recipes you read online are like, add oil and wait until it shimmers. But it turns out you can't get the pan hot enough before your oil starts burning. So yeah, it's actually way easier to cook if you heat up the pan first, then add oil, then your food. Okay, when I was introduced to you 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 okay yeah yeah yeah yeah maybe i should ask you, what exactly was that other than alacia bait? So origami robots are what was my first project at Berkeley. The lab I was in was doing bio-inspired robots, and they made these small systems, about palm-sized, 30 grams or so.

And we made them out of cardboard. And there's this process to kind of 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 like really robust mechanism. And you can use that to build all kinds of robots that are lightweight and fast and robust. Like most robots you can't throw against a wall and have them still work, but this origami process, you could. Was it because of the joints being made out of flex circuits or something else?

Yeah, so I think it was the light weight of it than being just 30 grams or so. It gives a lot of robustness. The cardboard was fast and cheap to work with. The flexors were made out of PET, usually. So the same plastic you find in soda bottles.

And you worked on a robot called Salto. Could you describe it? Yeah, so Salto is what I did after the origami robotics work. I made this little six-legged origami cockroach, and then I took it down to the FEMA disaster training site in Menlo Park and was like, okay, how does it perform on Rebel, like Rebel of the actual scale that you'd expect to see in a collapsed building? And the answer was not at all. This was kind of depressing. So I wanted to design a robot that could move in that scale. So how do you, I still want it to be small,

but how do you take a small robot and have it move in sort of human scale environments? And through some biological studies, I kind of looked to nature for inspiration and found that it's a class of like jumping animals that do really, really well. So Salto was studying those animals for inspiration and found that it's a class of like 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? And so you made this robot that is extremely bouncy. I mean, it's like a bouncy ball almost. Yeah. Does it have any control?

Yeah, it does have control. And I think Salto is technically my first robot. The cockroach was more like a bristlebot. So robots, for me, sense, plan, act. So you have to understand your surroundings, figure out what you're going to do to modify your environment or yourself, and then act on it. So 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 robot around and it'll bounce and take care of itself. You just saw the video. Can you describe the bouncing for people? I encourage people to look at it. It's like a one-legged thing and it can jump. It evokes a frog or a toad jumping to me. But it doesn't land, really. Well, in one part of the video,

it jumps and then it bounces again off a wall and then continues jumping um so i encourage people to check it out the video we'll put that in the in the show notes but yeah it's it's a very cool idea because most of what we see from robotics is let's make people or androids or animals, four-legged animals. Or manufacturing equipment. And I think taking inspiration from some other parts of the animal kingdom is a really good idea. So where did that go? Was it kind of a terminal research project or something that's still buzzing around your

brain? I think there's other folks that have picked up the Salto torch and they're using it. The robots I 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. And just seeing that design work open up new research opportunities was what I found really interesting. It was terminal for me because I got really fed up with hardware design tools. Because I was designing spatial linkage in my head and then trying to unfold it to 2D in a way that could be laser cut. And I did that in AutoCAD with no meaningful reuse of my work. And I went to conferences and I saw people that were able to do less science because they couldn't do that hardware design task.

And I'm like, that just wasn't okay. And I talked to my colleagues in the biology department and they didn't 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. I mean, 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.

During debug, it's always upside down. And 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? Yeah, so my road to Jidex actually led through mechanical first. So I was designing these spatial origami mechanisms and I didn't have any design tools

and no one else in the lab could really do this work and make their own robots. So I took a class from Jonathan Bachrock, who's one of my co-founders now, in the architecture department. So they were doing computational design of buildings, treatments is what they referred to them in architecture.

And 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. So he showed that instead of typing out a design, you can always type out a design, but that's not really a productive way to work. And what you really want to do is write code that automates your hardware design process. So you can kind of break it down into stages and just write a little piece of code for each one. And then you can change parameters up here, like number of legs, and then the output should be like a design ready to fabricate.

And from there, we expanded the idea into electronics as well. Because, you know, I was designing robots from scratch, including the circuit boards and all the firmware. And then we actually got a lot of interest when we started applying this to electronics. It's a little odd to me. I mean, we had a guest recently who allowed us to be hardware engineers because he was a hardware engineer and didn't trust software engineers. They just thought differently.

And I have to admit that while I'm very pleased to get that moniker, I have to admit that hardware engineers and software engineers think differently. Yes. And I am never going to end up being able to use LabVIEW or KiCad.

Let's just accept that about myself now. But if you give me typey, type keyboard i am all over it do you do you really think hardware engineers are going to use this tool yes i do and they already are and you pointed out that hardware engineers are not software engineers that doesn't mean you can't make a language for hardware engineers that lets them script. People love scripting. You should see the Excel sheets and cathedrals of constraints that hardware engineers build. And they write Python to test some boards. They write MATLAB to analyze some systems.

So they're already doing simple coding. And that's all. So we have that constraint engineering. So you need to just be able to script to write code that designs electronics. You can't rely on them to be software engineers because they're not. At least he's very skeptical of this. I'm slightly less skeptical,

but for different reasons. Is this akin to... Let me ask a question slightly differently. Is this akin to OpenSCAD, where unlike most 3D CAD programs where there's 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? Yeah, great question. So I used OpenSCAD when we were doing the mechanical design tools at Berkeley. I think it's very similar in that you have code in and designed object

out. And for OpenSCAD, that's like an STL. That's what you get. So there's 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 theHDL for that matter. So it's less like some of the declarative UI frameworks where you're stating how things are. You've actually got a full programming language that can perform functions and iterations and conditionals and things. Exactly. Okay.

Why would you need a conditional in... Do you know how many times I reach for conditionals in declarative languages? I know, but... They're not there! 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? Oh, the conditional happens before you reach

board level. It's about putting your design together in a productive way. For this circuit, I'm designing a voltage divider, but I also want to insert a database query so I can pull relevant resistors to load into the solver. You can

do that from the exact same interface and say connect this exact pin to this exact pin. And you can do that from the exact same interface that say, like, connect this exact pin to this exact pin. So it's 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's at least one weird thing

that's going to make it work or get a little bit more performance. So it's not so much something like, if this is the debug build, add, you know, expose the bit more performance. So it's 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's deeper than that.

You can go off and do, like you said, database queries and do things based on the results of that. If DigiKey has this part in stock. This is really cool. And 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. And then I can change one flag, which is this production build, and remove all of that. I think one of our customers, Geocene, wrote an article to that effect where they prototype on a set

of multiple boards, and then production version just kind of squishes all those together. And 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.

Now, I'm not super familiar with PCP design tools. I've used KiCad a little bit to try to make some small hobby things. But how would one, for the ignorant, how would one go about doing something similar in a normal PCP design schematic capture tool? Is that easy or is that impossible? Two separate schematics? Yeah, it's two different designs.

And you just hope that you got it right. Okay. 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? That hasn't been a focus, actually. With JITX, we took the stance that the input to JITX needs to be high-level engineering requirements. So 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 then the output of the product right now is a detailed schematic that's also rigorously checked for correctness. So that you're confident that when you do the placing route, it's not going to explode when you plug it in. 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. Somebody put in the capacitors that were the right level and not just random like I would choose. Someone chose voltage dividers that are available in voltage... For me, someone used a voltage divider is the level I'm at.

Well, but for me, I will design a voltage divider and not really think about the fact that resistors come in certain values. You should use those values and not just random. But seriously, is it verifying the netlist and that there's no weird loops or missed connections, or is it is it kind of it's verifying the netlist and that there's no weird loops and missed connections or is it deeper yeah so it's kind of starts at connectivity um a whole class of errors that are currently kind of caught by erc in the schematic tool if you add all the data that That's the rules thing? Yeah.

You can set pin types and then configure this matrix of rules if you can't connect two inputs together, except for when you can. You can't have traces too far or too close together. Yeah, and that's physical rules, but I'm talking just basic schematic level. Okay. All those kind of connectivity things where you might swap the Indian-ness of a bus or something are just turned into compiler errors.

Like, you just can't make that kind of incorrect design. And then there's another level of correctness, which is... I know, you should stop. 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. Excellent. I'll send banking details later because that's the next level of checks.

You have your schematic review checklist and hardware engineers will run through this checklist to make sure that inputs and outputs are appropriately connected. And we've automated that level of checking in GenX. The IO levels are correct. They're GenX. The IO levels are correct. They're correctly connected.

The voltage levels are correct. The power supplies are correctly given and outputting power. You're not going to explode your capacitors. All of those, it's kind of, because we found that you need that to actually have reusable code that writes hardware. It's no good writing, like I can write a script and it'll make a circuit, but if I don't know that that circuit is correct, it's 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. So when you model a part and say, like, this is a digital output pin and it has these properties based on the voltage properties of this pin, and you just have to make it very productive to add that information so that your boards work when they come back from the factory.

How many designs and boards make it worth it to do this. I mean, if I have a one-off motor controller, I mean, that's not very many parts, and it's not that hard to put together, says the person who had to have somebody. Thank you, Casey, for putting together my board. Yeah. who had to have somebody. Thank you, Casey, for putting together my board. Yeah, so right now, JITX is targeted at professional electrical engineers.

So they need to move fast. They need to ship usually a lot of boards. That's what we're targeting with our initial product. I don't know what the cutoff is. I really enjoy using JITX for small projects like around the house. It's just fun. And the checks saved me, even on those small projects, because there's always something that I missed.

Like I almost had an undervoltage lockout error and I was sleepily designing this little IoT widget, and the checks saved me. So even on a small design, I saved two weeks and a couple hundred bucks. And on large designs, yeah, you get a lot more value from the checks. Because your components are more expensive and you have several thousand components to analyze. I'm thinking ahead in ways that may not make any sense. But in Python, you can import modules that bring you all kinds of functionality. So I'm sitting here thinking, well, at least you can just import, you know, motor controller

and then have that be a parameterized function that generates a motor controller to her design spec. Like, why doesn't that exist? Well, I'm thinking about children's toys where we had the same base circuits. There were only like five circuits. And it was just, we would put them together differently for different toys and the number of buttons. And this sort of thing would make sense for that because we would, you would say, grab this and this and mash them together. Yeah, you guys got it.

I'll let you take it from here. This is exactly what technology is for. I have a small tangent about test-driven development. Are you familiar with that concept? Yeah, I was actually about to write a little article on it, but I want to hear your take. So,

in test-driven development, you often want a piece of code, and you write the the test for it and you let the test fail. And then you write the code to fix it. And you were talking just a few minutes ago about making sure boards didn't blow up. I just wanted to know, did you use test-driven development to make sure the boards wouldn't blow up by initially generating boards that did blow up? And if so, can I have those? I like

fire. Yeah. I've just had a little pop so far. I haven't done some 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 kind of writing the first checks in

GDEX. I was like, you know what, I'm going to model this fairly simple circuit, and as I go along, all the things I'm checking in my head when I read a data sheet and then read another data sheet and make sure two components are going to work together, I'm actually going to turn those into checks, and

I'm going to stick those in the component. And they saved me immediately. So I did model the component. So it was like I could legally make this netlist. But when I ran those checks that I wrote, the tests, let's say, they said like, well, you forgot to connect this ground pin. And this pin is about to be burned out by 5 volts. 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? KiCad and Altium right now. We'll be adding extensions for the other ones as they are desired.

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? Yes. So that's one thing we've worked a lot on recently, and that was the big thing to clear before we released general availability. Because professional engineers, they have an in-flight design, and they need to update it or fix it or check it. So we can read in existing CAD files and generate GEDX code in a way that's nice and reusable. So 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. And so it's just a way for people to get started faster.

Generated code tends to be difficult. How different is the code you write for your own projects from what comes out of the generator? Not different at all. We've worked a lot on improving the ergonomics of the generated code. And we used a lot of programming language techniques, intermediate representations. And it turns out, yeah, you can actually make pretty good generated code. It does not have to be spaghetti. Are you having trouble getting EEs to trust the output?

Yeah, that's the default, is that electrical engineers start with zero trust because that kind of vigilance is what you need to make hardware work. Exactly. That's there every day. So what we do is we, well, everything's open.

You write your code, it's open code. You can read it and then you can inspect the data that it creates and then you can export the CAD file and it'll be like your CAD file as if you wrote it yourself. And then we do things like draw a schematic to make it more understandable and make it easy to just dig in

and pick out every little piece of code to understand exactly what added this capacitor it's interesting because while you're 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 and it might be complicated but electrical engineers i assume are good at reading schematics and verifying in their heads and things so it's out that a human can look at. And it might be complicated, but electrical engineers, I assume, are good at reading schematics and verifying in their heads and things. So it's comprehensible. The output of a compiler is machine code, which some people can read and interpret, but not very well after it's compiled because the optimizations are such that it's incomprehensible. So that's

kind of an advantage on your side is that you can prove to a double E, well, this schematic, do you like this schematic? And they say, yes. And then you say, well, I generated it from this code. And then, you know, you've 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?

And you're like, I have no idea. It's incomprehensible. So that's interesting to me i do wonder though is there a future where jitx produces incomprehensible electronics because you've optimized things such that a normal electric electrical engineer would not produce a schematic like that yeah i think incomprehensibility or at least unfamiliarity, comes in more on the physical design side. Yeah, okay. Like, this layout, is this really the best you can do?

And for us, what that means is you have to prove that it's good. You have to run some detailed analysis simulations to know in a very rigorous way exactly how good it is. And my goal for Jidex is that it does allow for optimization, and I'll know that it's really, really working when you can design better hardware with JITX than without it. And that's the overall goal. There's a lot of...

It's not just about enabling new engineers. It's about making all hardware better. 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? I have been told that it is very important that should I ever become proficient with schematic capture to never trust the auto router. Are you going to tell me that I should start trusting your auto router? I feel like we shouldn't call it an auto router.

So I think there are auto routers out there. You did say you output schematics. Yeah, he's before all that. And auto routers are for gerbers. Yeah, so the router is for the physical design. Right. Right. And we are making our own auto router, routing algorithms, let's say, to kind of bridge the schematic and the physical design. And that happens for pin assignment.

And so engineers are usually swapping pins to make things easier to route, so you can do it on fewer layers, use fewer vias. And so we built these routing algorithms as a way to aid that optimization. And as they develop, I think

they will be a useful tool. So actually being able to do boards with 100% automation, where you also not just the schematic that's checked, but placed and routed components. And this is kind of a different type of auto-router. It's meant for optimization

over saying, like, I've got this fixed placement of components and you're not allowed to swap anything. And I give you no electrical constraints because I don't have the way to add those to an autorouter and do your best. And the results are predictably not good when people don't trust the autorouter.

Like, that's why. One of the things that schematic capture has gotten so much better in the last probably decade or more is that there are more parts in their libraries and you don't 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?

I think about a million. There's a bunch of sources for parts online. But for the library generation, we found it's actually a lot more productive to just make it programmatic. So everything in JITX you can drive with parameters. Because it turns out, you know, if you're 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. So it turns out there's actually no one good library and it's always design dependent. So we focused on automating that part. So maybe you can squeeze a bit more yield out of your boards just by default. So I think the library challenge, you know, 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. There's a balance between that level of flexibility and the complexity of making sure all of the correct optimizations and flags are chosen. And I think that's where a lot of the distrust from electrical engineers might come in. How are you going to deal with that?

We've dealt with it so far by just make it fast, interactive, obvious what the knobs are, adding a lot of facilities and language to understand exactly what this interface is. It's not just closed code and all these locked-off parts of the software. You can just inspect it and see exactly what it's doing. So I think that transparency

is the thing that helps the most. Okay, at the risk of doing visual stuff on a podcast, can you give a sense for just starting from scratch, say somebody's trying out JetX, what does it look like to do a simple port? Say a 555-driven Blinky or a guitar pedal, for example, with an the knob amp and a buffer and input and output and nine volts. I don't know. Some, some simple,

it's a really detailed guitar. No, no, no, no. Like it doesn't, you know, half a dozen to a dozen parts.

Like what is, what did the language look like for a simple, for, for like the, the hello world of Jidex? Yeah. So the language is designed to look, to read how you think.

So do you want to do this line by line of how do you think? And I'll tell you what the code looks like. Because typically it says add this part, here's the 555, and I'm going to pass an argument to it. I want this in a stable

setup. And you produce this frequency. That's a common parametric an argument to it and they're like i want this in like a stable like setup right and here you produce this frequency okay that's like a common parametric function to just like set up this 555 circuit and then i'll add the chip and the you know associated housekeeping components to get it producing this output and then you yeah you add your connectors and you typically make that a we have bundles which is just like a connection of pins and other bundles so maybe you have like Yeah, you add your connectors and you typically make a bundle. We have bundles, which is just like a connection of pins and other bundles. So if you have like this SPST switch or whatever interface you have, you kind of net these high-level things together.

And then you run your design. It creates a schematic and a board immediately. So it's like we have an interpreter shell that's just very interactive. So you type your code and your schematic board starts showing up and you can get in there and change the code, change your parameters, and then check the design. So you're going to run the design checks, make sure it's going to work, and then export to CAD and it'll emit to KiCAD or Altium board schematic part library. It'll do a real-time component optimization so you can actually order all the parts.

And then from there, you're going to do your place and route in the existing design tool. So modeling the circuit, will it do things like frequency analysis? I think that's coming next. So we've been focusing the analysis on checks. And this is kind of like continuous integration style stuff.

It's not for optimization, but it's rather just make sure you're in the realm of it actually operating correctly. But we'll be hooking back into Spice soon to create some automated model synthesis to just run more checks without the user having to write more code and i think once we have that spice hook you can start bringing in things like harmonic balance analysis to to really get fancy and so how many lines of code would that 555 blinky end up being yeah it depends that's the fun thing okay uh because you can raise the abstraction level up to whatever you want it could be one line of code. Well, once I've written, I mean, are there pre-existing modules I can just say 555 Blinky, or would I have to develop that up from scratch?

Yeah, actually, that's how we start people. So we had my lead product designer, didn't know anything about circuitry, so I had him follow Chris Gamble's Getting to Blinky. This is why I use this example. Yeah, and then I had him follow Chris Gamble's Getting to Blinky. This is why I use this example. Yeah, and then I had him do it in JITX. Everybody makes this module

where you configure it with your high-level parameters, your intent, which when it's configured as an oscillator, it's just, what's the frequency? And now that's a high-level module, and then you could stack that up into a higher-level thing of, you know, I want a parametric number of Blinkies,

or I want to change this into a polyphonic synth or something. And you just get to reuse the same circuit. I have this question about KiCad's definition language, S-K-I-D-L. But it sounds like what you do is pretty different. Is that right? Yeah, so Skittle is, I think, Dave's project. It's not just KiCad. So he has his own separate project.

I think it produces KiCad files and I think it imports KiCad files. It's similar in that you're writing code to design hardware. The differences are just we've been focused on features professional engineers need. Like it needs to work with Ultium. It needs to hook into a PLM database. It needs a schematic because that's like a legal requirement for professional engineers.

So I think that's the main difference. But it's very similar in spirit. And it's Python-based. Yeah. So he wrote it in Python. And I have a hardware architect who was actually a Skittle user before he joined JITX. And his feedback on the Python thing is like, it works if you write it in a Pythonic way. Python doesn't have a 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. And we used a macro system to, like I said, make it so it's very clear to an electrical engineer what this line of code means and to write that code correctly and get informative messages when it's not correct.

I'm going to ask a software engineering-centric question. What developing languages is a peculiar, arcane realm of expertise. What did you take inspiration from when designing

the language? Is it something that's kind of new from scratch, or did you have certain things you were kind of picking from other software development languages? For Jidex, we did it from scratch or did you have certain things you were kind of picking from other software software development languages for jadex we did it from scratch we actually started uh as a design contractor using jadex so we would take on uh my contract design work and use jadex 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, kind of read in a simple way, so we don't want a bunch of parentheses everywhere. So it kind of reads like Python.

Those are the primary sources of the language design. I put it somewhere between C and Python given how little I've looked at it. Yeah, it's a good gut check. It does seem like the problem you're solving is distinct from

general software development, so it would have its own expressive ways of expressing things and perhaps concepts that don't map easily. Yeah, I think on the technology side, we find ourselves using a lot of programming language techniques to make it more tractable to write this kind of software. You had a question for us. I've written here, but do you want to ask it in your own words? So my question for you is, imagine hardware design was free. You've got a pile of virtual hardware engineers that will design and optimize anything you want, all the way through to production.

So when you think back to projects you've worked in the past, when would that hardware design power have made the most difference? And what would have been different? And how would the world be different now? I've had so many product ideas. And I get to the point of having a prototype and putting it together and realizing it is so hideously ugly that I really can't 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.

And then at the bottom, there'd be a little battery and a controller, and it would check your posture. But having had one of our listeners make a 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 and then 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're asking about or something else I am yeah I always try to think about the impact that we're trying to have on the world. My hypothesis is like, if you make hardware engineering more automated, the world would

be better. And I think in this case, it'd be, you have this idea, your tool should support and say like, okay, this is what you asked for. Is this what you want? And then you can have, I would hope, for a more interactive conversation with that tool rather than take a sequence of steps and look at the end result and be kind of fed up with it. I'm going to answer for me in a way that maybe is not what you're after. Like Elysia, I've had ideas in the past past but i've stopped a lot earlier it's like as soon as i realized oh this requires custom electronics no thank you um that's gotten a

little easier in recent years because the adafruit spark fun mode of okay you buy six modules and you hook them together and now you've got a prototype um so where i think where i think it would make a difference for people like me who aren't electrical engineers but who want who have ideas that are electrical electronics projects or want to make prototypes is taking that sort of spark front adafruit approach to modularity and making it so the custom boards are just as easy to do as that. Ah, import this board from Adafruit and that board from Sparkfront and mash them together into one. Not even necessarily that so much, not even specifically those boards,

but the thing that does that. So like, oh, okay, I need three accelerometers, I need to hook those up to a STM32 and I need, you know, the power and all that stuff. Um, and spit me out a board that does all of that and is compact enough to be a prototype. That would, that would be really cool. Um, to me, because then I could skip all of the, everybody's trying to make their lives easier, right? I I'm interested in the software part, the firmware part, and the final product and making something work and less so on the electronics. I just want the electronics to work. I don't want to be bothered with them.

Yeah. But where my skepticism rises up is for decades, there have been products that claim to do this for software as well it's like here's your program that writes your program for you and i get that these are completely different spaces and that's kind of what i was alluding to with the output being comparable and and visualizable by a human versus a software output so it's not really a valid skepticism but yes it sounds great but from my perspective it'd be most useful at the prototype stage for me i think companies would find different attractiveness yeah that sounds like a i felt the same thing in grad school. That's why we have it free for educational use.

This thing should enable. There's a lot of ideas and a lot of projects that just die before they could get out there and seem interesting. It turns out the bar for making those work, making those electronics, is actually not that high. Doing it for software is actually a much higher bar. But yeah, I get it. That's one of the reasons I wanted to start this company.

I think there's a lot of ideas that just need a little more space. Just a little bit to push them over the edge. You said all the way to production. And in my example, a large part of my problem, it turned out to be mechanical because electrical, I work close enough that I understand most of what's 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's never going to be good. You stop at the electrical part, right? I still have to worry about how to get the button working. For now. Yeah, we started with electrical because this was the, I think, the biggest opportunity for automation.

If you can send a well-constructed zip file to a factory, they can send you a pretty complex circuit board back. But JITX means just-in-time everything. Remember, 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. And then next, I think, is more electromechanical integration. We're 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, and I'm excited to be doing that next. So, little robots, like OpenRoach,

can you make those with JITX now, or do they need additional mechanical consideration? So OpenRoach was one of my grad school efforts. I kind of 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 don't need to do any design

work at all. You can just kind of make this thing. And that didn't really work out because everyone wanted to do something a little different. Like 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's actually one of the final straws of like, you know what? I'm going to go fix design tools. Has it been strange for you to go to take that step back from I'm going to make things to I'm going to make things that make things? Yeah, it was always, it was a step back. Because like what I really loved doing and what I was like like my track was research professor. I loved science. But I saw

this as like, you know, if I'm going to be a research professor, my students are going to be grinding out the exact same thing. And I just couldn't have that. I just wasn't okay with all these projects not making it out into the world.

What you need is a language that defines grad students. Exactly. Actually, that should have been one of our lightning round questions, was academic or industry. And you've chosen industry for now. Is that a choice that may go back and forth or probably here here are going to stay here it's a good question uh industry was the best choice for making jadex happen you know we talked about it being all sorts of things was it a collaboration between professors was it an open source project we kind of looked at the problems that needed to be solved as like you know a startup is probably the best vehicle to

address these things so we did a startup. And I'm thinking about Jidex right now and Jidex's future. I'm not sure what I'm doing afterwards, but there's a lot to be done to automate hardware design like this. You mentioned being a contract designer. But Jidex, now you just got a funding round and things have changed a little bit for the company. Where are you? What are you doing? Yeah, so we were

hardware contract designers. Well, we worked on the early technology, but as soon as it was stable enough, we switched to releasing it as a product so someone can use Jidex themselves because that's just a better way to help a larger number of people. Today, we just announced our Series A from Sequoia Capital

and we are 18 people based in the Bay Area working on JITX and making this tool be the best it can be. You said you weren't sure about what's going to happen after JITX. Do you have plans for while you are at JITX? Yeah, so with the Series A,

we're 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 JITX and go back to a CAD tool. And building out a database of components that's meant to optimize designs, meant also stay on top of the component supply chain issues. And the person who's 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? That's a good question. Turns out, I think, you know, we're going to be looking at... Yeah, well, we're doing flexible electronic design quite soon. Because it turns out that's like one of the best applications for the autorouter we just are nearly finished with.

So maybe that's the road. We go with origami electronics and then maybe just origami. When you talk about 3D routing, that's where you have to talk about origami to some extent. But there's a difference between folding and bending. And most circuits prefer to be bent and not folded. Yeah, it's a matter of a radius. And you're hiring. What are you hiring for?

We are, yes. We're 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.

Ah, yes. Those people who are your seeds. Evangelists. Evangelists, yeah, that's the word. So let me ask you some detailed questions about JITX. Like, is it a standalone application? Is it cross-platform? It runs in VS Code.

I was about to ask, do you have a VS Code extension as a joke? No, we have a VS Code extension as a very serious release mechanism. Oh, okay. It's cross-platform, works Mac, Linux, Windows, and it works locally. So it primarily works on your local machine, your data stays on your local machine, and we also have some cloud services where you can pull down component models from a database.

And it's not like Dolly, where you ask for a circuit board that's a calculator and outcomes. Darth Vader holding a popsicle? Yeah. Not yet. You did mention AI in some of your marketing kind of literature and stuff what does that mean to you so we use ai methods to build solvers okay um we use of machine learning

is pretty scarce because the most important thing was that it's good uh explainable and repeatable and so this is the correct answer. Thank you. Okay, good. Yeah, and we use solvers so you can make code that's more reusable. So we scraped all STM32 microcontrollers. And we made it so that you can actually swap any microcontroller in for

any other microcontroller. And to do that, you need to write some solvers. Like, well, how do you connect these IOPins to all your peripherals? We use a solver for that. Did you pull in the SVD files to do that? That seems like the easiest way to do it.

The debug definition files that the JTAG things use. Generates, or CMSIS requires. We pulled in XML files from the Cubemax project that kind of sets up your... Okay, those are... That's probably better.

I think they're the same, actually. The same? Oh, okay. Or they're generated from the same originals. Yeah, we try to find these little, like it was a little treasure trove of data, right? And it actually describes their entire product line with enough information to significantly automate the design of it. And it was, you know, it was a great find. Okay, so this is probably not something you really want. automate the design of it. And it was, you know, it was a great find. If, okay.

So this is probably not something you really want to know, but the SVD files are for all of the processors that are cortex based. Ah, so, okay. And I think they are either that XML format or very, very similar to it. And it's from CMSIS, which is from

ARM, and 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 register definition, which you don't care as much about, but it tells you which pins can be SPI, which pins can be I2C, that kind of thing, which you probably

do care about. Yeah, okay. It generates a new one every time you touch the hardware. can be iSportsy, that kind of thing, which you probably do care about. Yeah, okay. Unless it's Cypress and it generates a new one every time you touch the hardware. This information does not apply to PSoC. I feel like that should be on all PSoC information. To go back to AI just for a second, one thing I've been noticing is that people, when they see somebody say AI in their product product they start to get a little twitch yeah which which is is not equally distributed across industries like if you have an ai photo

retouching program people are like cool if you have an ai something that's making something people get nervous because they think machine learning now because machine learning is so deeply tied to ai um has have you noticed that when discussing with people, or not so much? Yeah, I think it comes up when people expect me to be like selling a bunch of hype about an AI-powered autorouter, which would somehow magically solve all problems without knowing any detailed electrical constraints. So I think it's a matter of expectations

is how it shows up to me. But I mean, pragmatically speaking, you can use AI methods in some places to write software more easily with a smaller group of people. There's some things that it's really well suited for. And you also have all the data center people racing to make these algorithms run as parallel and as fast as possible. And you can ride that wave for some parts of your software.

But when you want something that's repeatable and demonstrable and checkable for correctness, you say the word solver, and that means we're going to do it the same way each time. Or you say finite element analysis. It means we're not going to get random answers at different times of the day. 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. And it's not just run it again

to see if it will work this time. I want a Monte Carlo schematic generator. Yeah. I mean, it has its place. Stochastic optimization algorithms are fun to play with, but you don't want them guaranteeing properties about your design. But you can use it to kind of search a space or optimize in a way that's interesting.

What is your least favorite FAQ question? What question on your FAQ page do you wish didn't have to be there? I don't know. I'm always excited to answer questions. I think my least favorite ones are the missing ones. I always wonder, someone shows up to my website and they're like, what do they want to know? What question have I not answered yet? Do you think there's other kinds of abstraction and automation

already available in the hardware world? I haven't seen much abstraction. That one was kind of something we had to build a lot ourselves. There's a lot of little pockets of automation, though. There's antenna optimizers and circuit designers and all these little spot tools that are

locally pretty good. Well, you kind of notice there's no way to connect them to the rest of your system. You can put numbers into a voltage divider solver, but it doesn't connect to the inventory you have in the warehouse. Why do you think this hasn't been done before? I think the reason is largely historical. So back in the 80s, 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. And then it happened for FPGAs, so people don't draw schematics to program FPGAs anymore. But boards stayed pretty simple until, like, 2008, and you start having things like the iPhone. But by then, you then, the big CAD companies

are kind of, they found their zone, and it was not really caring about PCB design tools, focusing on IC, and so you kind of ended up with this tool stagnation because the board stayed simple until the companies kind of calcified in what they do well. And now things are weird, right?

So devices have like three radios and as much AI as possible, and it's battery-powered and it's flexible and 3D. And you're designing it with basically the same tool that people were designing those boards back in the 80s. And that just stopped working well. So now we have a pretty serious productivity problem, and you're stacking on the component shortage caused a lot of extra work, and it's also just harder to find electrical engineers now.

So we're left with this opportunity. If you can actually meaningfully improve how people can design hardware, now it's pretty valuable. And the opportunity is there in circuit boards. All right, cool. I don't know that you've 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. No, I have some ideas. Duncan, I believe you were going to give us a coupon code. Yes. So I can offer a free month of JITX for Embedded FM listeners. So just use our website, JITX.com, to sign up and mention Embedded FM. And Duncan, do you have any thoughts you'd like to leave us with? I think what I'd like most is just to hear from designers.

We're launching JITX because it's ready to use and it's helpful, but I know it's not perfect. And 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. Our guest has been Duncan Haldane CEO of Jidex there'll be a link in the show notes to that and a few other things

thanks Duncan thank you thank you to Christopher for producing and co-hosting thank you to Anita Pagan 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 at embedded.fm or hit the contact link on embedded.fm. And now a question 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 with the simple, then comes the complex, and by superior enlightenment, one often reverts in the end to the simple, such as the course of human intelligence.