JITX, a Way for Hardware Engineers to Write Codes

This is a very interesting episode, especially for hardware engineers. Duncan Haldane, the CEO, and co-founder of JITX joins us to share a very interesting approach to PCB design. JITX is a way for hardware engineers to write code to design circuit boards.

I know you are excited to hear more! Watch this episode or listen on the go. Be sure to check out the show notes and additional resources below.

Listen to Podcast:

Download this episode (right-click and save)

Watch the Video:

Show Highlights:

• Duncan talks about the Series A funding from Sequoia Capital and the general availability of JITX as an actual product.
• Duncan's path to engineering started in robotics
• How can an electrical engineer benefit from JITX? Duncan explained in detail
• JITX is very well integrated with Altium, it works natively with the existing designs and libraries 
• Hardware-generated code transforms the job of an engineer a little bit so that they don't have to manually look through all of the different specs for every component that they need
• JITX is a Nexar partner and uses Octoparts data, in addition, they built a different type of database that's meant for part optimization.
• Reusable expert hardware engineering knowledge is one of JITX’s ultimate goals
  • They are building full automation for boards, new kinds of routing algorithms, new kinds of placement algorithms, and checks for physical geometry
• The future is optimization
  • Zach and Duncan excitedly talked about AI, and how it can be used to drive some parameters to create new designs
• Electrical engineers’ job is secure, automation can help with the shortage, but will not replace electrical engineers’ jobs
• What the future looks like for JITX

Links and Resources:

Connect with Duncan Haldane on LinkedIn
Visit JITX website
Read JITX Launches General Availability And Announces $12M Series A From Sequoia Capital

Connect with Zach on LinkedIn
Visit Nexar website
Visit Octopart website

Claim the special offer for Podcast listeners only

Transcript:

Duncan Haldane:

JITX is a way for hardware engineers to write code to design circuit boards. So your input is like high level code that reads like engineering requirements. And the output is like a detailed schematic level design that's actually rigorously checked for correctness. So it should be passing the vast majority of your schematic checklist. And then we built a compiler that just turns out high level input into the output.

Zach Peterson:

Hello everyone and welcome to the Altium OnTrack podcast. I am your host Zach Peterson, and today I'll be talking with Duncan Haldane fresh off PCB West. Duncan is founder and CEO of JITX, a EDA company and they have an integration with Altium Designer and it's actually a very interesting approach to PCB design. Right now we're running a promo for Altium Designer for new subscribers. Make sure to check out the show notes and you'll see a link to access that promo. Duncan, thank you so much for joining us today.

Duncan Haldane:

Hi Zach. Thanks for having me.

Zach Peterson:

Yeah, absolutely. Someone from your company came up and talked to me last year at PCB West and now it's kind of cool to see you guys actually presenting at PCB West. So it seems to have come a long way. And I actually got back in touch with you because I saw your blog on the JITX website and announcing that you guys got some new funding and showing some examples of what you could do with your product and I thought it was all very interesting.

Duncan Haldane:

Yeah, well I'm glad you got back in touch. So we announced our series A from Sequoia Capital and the general availability of JITX. So now you can go to the website and start using it.

Zach Peterson:

So when you say general availability, is this an open beta?

Duncan Haldane:

Nope, like actual product.

Zach Peterson:

Like actual product. That's awesome. That's awesome. How does it feel to get to that point?

Duncan Haldane:

It feels great. When we started, we ran as a design consultancy to test the design tool and it was kind of a bit frustrating, the rate of helping people was pretty slow. A lot of people need hardware and the best way to serve them was with a product they can just use. So I'm just really excited to be at this point.

Zach Peterson:

So starting as a design consultancy, that's actually an interesting approach into developing a product because I know that some of the very large consulting firms have developed their own internal products that they later kind of transformed into a public facing, publicly accessible product. Was that your intent all along or did you come into this as a design consultancy and you're doing all of this and then you have this kind of eureka moment like, "Hey, we have this great tool that we've developed, we should make it available to everybody."?

Duncan Haldane:

So this was the plan all along. So we were testing this tool ourselves until it got good enough for professional engineers to use it. So our customers are professional engineers and hardware people. We don't have much time to evaluate new tools and it has to be pretty good immediately for it to be even considered. So we wanted to make sure ourselves that it was solid before releasing it, make sure it's stable, make sure it works, make sure it delivers value in the right ways.

Zach Peterson:

Sure, sure. So maybe before we talk a little more about the product, maybe you can give the audience a little overview of your background, how you came into doing all this. I find that everybody's path into the electronics world is varied and quite interesting.

Duncan Haldane:

Yeah, so my path was through robotics. I guess I started in high school, started kind of bolting things together and went down to the automotive pick yards and pulled things out of cars and turned them into robots. And that's when I first started doing electronics. But I think it became an everyday thing when I was getting my PhD at Berkeley, I was building robots and they were weird robots. I built a cardboard robot that was the fastest legged robot on earth and I built a jumping robot that weighs about a hundred grams, it was about a stick of butter and has a four foot standing vertical jump and it can jump off walls. And designing these, they're full custom because they were weird. So new materials, new manufacturing processes and custom mechanisms, materials, electronics, firmware, whole stack. So that's when I really started doing a lot of hardware.

Zach Peterson:

That's interesting. So I kind of came into this not knowing that I was going to do PCBs and manufacturing and hardware. I actually wanted to teach. So it's always interesting when I meet someone who is saying, "Yeah, I was building robots in high school."

Duncan Haldane:

Well and that was my plan as well. I built these robots but my job was research scientist and I was just supposed to discover new knowledge and I was like, "Well I can come up with this concept for a new way that robots can jump, or a new way they can run and I can write it down on paper in five minutes." And then I spend my days drawing shapes, because that's what design tools are. I drew my shapes on the screen, I drew my shapes for the circuit forward, I drew my shapes for the machine shop and then made drawings and then I went to see how well I could make the shapes and I was just starting from scratch on every robot. And it got to be pretty tough because in robotics it's an engineering and a science. So you engineer the robot so you can build a scientific platform and then share the result.:

But if you don't have a lot of hardware talent, then you can't design robots that are that complex. And if you do, then you spend all your time designing robots and less time doing the science. And that was kind of my path to JITX. I started building these as scientific instruments and I was on the research professor track, but then as kind of looked forward was like, "If I had students they'd be spending time like this too." So I would much rather make hardware engineering, much more reusable, much more productive and so you can design these things quickly and focus on the science.

Zach Peterson:

So maybe that informs the approach to how you got into JITX and then what JITX actually is. Is that a fair statement?

Duncan Haldane:

Yeah, no. So JITX is a way for hardware engineers to write code to design circuit boards. So your input is high level code that reads engineering requirements and the output is a detailed schematic level design that's actually rigorously checked for correctness. So it should be passing the vast majority of your schematic checklist. And then we built a compiler that just turns out high level input into the output. And to be clear, it's not a tool for software engineers to start designing hardware. This is like, it's for hardware engineers. So if you can write a script, some Python, some MATLAB, little firmware, that's plenty of coding knowledge to use JITX to create new designs.

Zach Peterson:

I have always been a believer that hardware engineers should know a little bit of coding, maybe not polyglot, but at least enough to be a little dangerous in some areas and then at least be able to speak to a firmware engineer that might be on their team. Is that the kind of level of background that you're thinking of here? Maybe they need to know a little bit of one language and they can just kind of jump in and figure it out.

Duncan Haldane:

Exactly. So we actually built this language purpose built for hardware engineers. The way we think as engineers, as designers, you can just kind of write that in code and then it becomes the source of truth for your design. Because hardware engineers, we kind of love scripting. We never see ourselves as software engineers, but scripting something's pretty good and we, it's very common to build cathedrals of Excel spreadsheets and then like, do all your design and calculations, maybe you've got a hundred of these things, maybe it's got 30 tabs and it's managing all your connectivity. And that's way more complex than a JITX design. So yeah, I think it's-

Zach Peterson:

I will admit I have a couple of those spreadsheets.

Duncan Haldane:

Right, yeah. So my feeling is, that should be a native part of your design, how you actually do design when you read PDFs, when you do calculations in spreadsheets, that should be a first class object of your design tool.

Zach Peterson:

So maybe for the audience out there who says, "Oh, coding, and I'm coding up a PCB," is there any way you could maybe make the process for getting from what you type in on the screen to the schematic that you output a little more tangible? What exactly is the code doing without, of course giving away the secret sauce?

Duncan Haldane:

No, we're pretty transparent by default. I think a lot of electrical engineers approach this with, "There's no way this could work." So you have to show them everything and let them touch everything. So I'm going to be fully open about this. So the way it works is, let's pick a project, IoT smart water meter. What's your intent for this? So at every level of the design, your code represents what you want. And at the top level that's very high level indeed like, "I need this transceiver, I want to use this battery, I need to make sure that this device lasts for six years in France on this battery." And that's really high level intent. And then you can feed those parameters down into things that generate circuits, design CRF side of things. Adds to the transceiver, adds the micro controller.:

And then you start getting a little lower level, where is it like, "Well I need a micro controller, give me an STM 32 that solves my pin assignment problem, L3 series, in stock." And that's one line of code. And then from the very same interface, there's always something weird on a design. So you can say, "I need this exact capacitor, wired exactly to this pin." So for all the, every design's got something a bit different to it. So from the same interface you can do this fully detailed specification, type out a net list if that's what you want to do. And then you hit compile and JITX generates a schematic and a board, or a system of boards, for your design.

Zach Peterson:

So it sounds to me like the input, when you say requirements, I think I can understand that, because it's like, generate, open parentheses, requirement, ABC, close parentheses, I'm overgeneralizing here, but you get where I'm going. And then I can imagine a set of stuff that happens underneath, which is probably coded in the back end or it's in a library somewhere and it's trying to balance those inputs with a library of available data that's related to the components that you selected and trying to pair up and find the best compromise between those components. Is that a fair way to describe it?

Duncan Haldane:

In general, yeah. So we're well integrated with Altium. So we also work natively with your existing designs and libraries and then you can start and enriching them with your intent of, "This little chunk of my schematic, I'd like to make parametric." So if we'd pick something like a micro controller, so we have a pin assignment solver, so you can represent all your requirements like, "I need a canvas and Quad SPI and two I2C ports and this collection of GPIOs." So we have an index of several thousand microcontrollers and a pin assignment solver, it says, "Here are the ones for which there's a valid solution." So I can choose a part from there or you can, here's a list, you can view it as a user and pick something more detailed. And then you have a function that says, "Okay, set up bypass for this micro controller, set up reset, set up clocks, set up the programming interface," and then you can drill down even further and say, "Okay, in the clocks, what are your timing requirements?" Okay you need to use a crystal resonator.:

And then at the very lowest level are the checks, and this is where all that high level magic just goes away and you're just implementing your schematic checklist. So this crystal oscillator says like, "Okay, well I'm going to look at the balance caps and their tolerance and the board parasitics and I'm going to check that the drive level is correct, that I'm not going to, the pullability is going to be within spec for my timing requirements." It's like all those detailed checks you do on a crystal resonator, those are automated at the bottom level, which means that's the only way you can rely on the stack of automation that you build up. Because at the bottom level it's just the best, how to check your design automatically.

Zach Peterson:

So using a catalog of tagged data, it really is trying to fill in the blanks using best practices or using data for intervening or intermediate components that can be easily broken down into a set of concrete instructions. And that's what you guys have done is the process and the concrete instructions and I guess the tagging of all of the component data, is that fair to say?

Duncan Haldane:

Yeah, I think the simple way to think about is, you write a circuit and then you write checks for that circuit and you embed them right inside. So you've got your power regulator and all of the schematic checks you need to run to make sure it's going to work. And now you can start building higher level interfaces on top of that. You can send that code to someone else and they can use your power regulator without you having to sign off on the schematic, basically. So when you have that level of checking correctness at the bottom level, you get to build higher levels of reuse on top of it.

Zach Peterson:

So you said something interesting here, which is send that power regulator for example, or that microcontroller circuit for example to somebody else. I'm imagining in this case when you say send that design to somebody, it's literally a code snippet.

Duncan Haldane:

Yeah, it's a code snippet and the really nice thing is it represents your intent. So it's not like, you could send a schematic to someone or you could send a schematic diff to someone and oh we colored the different parts, but what is this circuit for and how is it going to operate are not answered when you just share schematics. So yeah you can actually, I don't think we've innovated on software collaboration tools, because they're just already pretty good. But yeah, it's a great way to collaborate, especially on a system.

Zach Peterson:

Sure, sure. I think one of the things that starts to come up for some folks when they hear it's hardware generated by code, is that you're maybe trying to remove the engineer from the equation in some way. I don't see it that way, I see that-

Duncan Haldane:

No way.

Zach Peterson:

You disagree as well. I see it more as transforming the job of an engineer a little bit so that they don't have to manually look through all of the different specs for every component that they need. Instead there's something that can do that kind of mix and match and now it becomes the engineer's job to number one, control this tool. And then number two, be able to have a strategy to efficiently check the output to make sure that what was actually delivered is going to meet probably a whole set of other specifications that are very difficult to define in code. Is that a fair statement?

Duncan Haldane:

Exactly. Yeah. So JITX is very much a supporting technology. I think every hardware engineer you talk to wants to be designing a bit better, they want more productivity obviously, but they have a lot of really cool ideas that they never have time to test or not enough time at the bench to optimize the design or explore concepts. Or maybe they run out of time and they have to add some extra layers they know they could have saved if they had a little slack in the design cycle. So JITX is just supporting, you should have this computational tool handle the low level details, which are still important. You need productivity, you need to have a board that works the first time. But there's so much to add past that, no tool's going to automate creativity, but you can automate a lot of the really rote stuff.

Zach Peterson:

Yeah, that's what I've always felt as, especially as the EDA landscape kind of grows and evolves and embraces some of these more advanced computational techniques, including AI, that it's going to change the role of the designer like we've mentioned. But I think targeting those really rote types of tasks that no one really wants to do anyways and they outsource half of them anyways, that type of stuff. I think that's a really good strategy for developing future EDA products. And so what you're doing at the end of this is you're giving someone a schematic and you're giving them a placement, or at least just a set of components, and the nets are defined and the connections are defined. So then-

Duncan Haldane:

Yeah, so today it's a-

Zach Peterson:

Oh sorry, go ahead.

Duncan Haldane:

So when we export to Altium... So you import to Altium, start working in JITX, export back to Altium. So we export a schematic component library that's optimized for your specific stack up rules, materials and an initial PCB layout. And you could group it or organize it however you want, but it'll least show you, "Here's a dense, non overlapped packing of all your parts and this is what it looks like when you're thinking about how big this thing needs to be." And the final thing is the check report. So you're going to see, "Okay, here's the derating analysis for all your components, here's your IO checks, you made sure your power supplies are going to turn on, made sure there's not too much capacitance. We checked external connectors for ESD." So that verification report is the third output.

Zach Peterson:

So there really is a lot of data that you guys have gone through on components to be able to match up to these different requirements. Because you just brought up components and ESD. I think that's one of those things where engineers kind of rely on very large font lettering in a data sheet to ensure that they've actually picked the right component that's going to meet a spec like that, or maybe they're doing aerospace and it has to be rad-hard. So they're going to Google and they're saying, rad-hard, rad-hard power regulator, rad-hard ADC reference, so on and so forth. And that's how they're trying to find this stuff. And so it kind of relies on the part vendor to make sure that they've SEO'd their inventory well enough to make sure that you can actually find this. It seems to me like this type of system has an opportunity to put some of those maybe more, or I guess less well known parts in front of an engineer so that they can better find a compromise between all these different design requirements.

Duncan Haldane:

Definitely. Especially there's always, even if you're not rad-hard a new component you want to try maybe like, "Oh is this the power design I use GaN FETs for?" So if you can reduce the cost of that experiment, I think just all hardware gets better.

Zach Peterson:

Yeah, that's interesting actually, because you know brought up GaN FETs, I think this is a good example of something where someone may not know if that's what they need. And so if they were to just approach it by diving into data sheets or relying on the experience maybe of some of the people around them or their own experience, they might not even think to try this alternative approach to a design. But your system is able to say, "Well this is a feasible approach given your design requirements that you've defined."

Duncan Haldane:

Yeah, that's exactly what it's for. And what we're building now is, well a number of things, but among them is more data. So we systemize the data by writing checks. So when you think about, "How do I know that this resistor is going to work in my design?" Well it turns out if you write every single check you could care about for this resistor and the applications it gets used in, you kind of know how you need to model resistors. And then you can expand that out to other component categories. So that's one thing we're doing is, these optimizations need to be powered by data. And in this industry the data's not systematic. Nobody provides good data for an automated tool because there just hasn't been one like this.

Zach Peterson:

The data problem is interesting because I think the compiling of data around components to date has focused so much on just search, finding a component, finding a substitute. The part vendors, or the distributors I should say, they have pretty good systems for locating a component or at least a list of components that you can start to filter through. But at the end of the day, you're manually left to pinpoint something that's going to work decently well, you think, until you then have no choice but to dive into the data sheet. So I think they're only really indexing the highest level of data. So the footprint, the voltage rating, the cost, something like this.

Duncan Haldane:

Yeah, it's definitely variable. And I should say we're a Nexar partner, we use Octoparts data in conjunction with other things, but we did have to build a different type of database that's meant for part optimization. The types of queries that you do when you're trying to choose the best set of components are just different and not provided yet by the existing data tools. But because they're oriented around discoverability, I think they monetize through advertising largely. And they'll just say like, "Hey, we found your parts, we made your parts more discoverable, your parts are already great and we put them in front of someone. That's worth, keep sending us your data."

Zach Peterson:

Well I think there's value in that. I mean, I like to know that if the thing that's in my design is out of stock, I can very easily go onto Mauser or Digi-Key onto Octopart or wherever else, and it doesn't take horribly long to find something to replace it with that is in stock. So not to knock the platforms that are doing that, but I think you've hit on something which is that, they haven't gone nearly deep enough to actually be useful in any kind of automated tool. Are you guys really the ones on the forefront of doing that? Or are there any other companies who have really tried to go much deeper than just discoverability?

Duncan Haldane:

I haven't seen anyone, not to say that they don't exist, but in terms of turning engineering requirements into a set of parts you need to go search for and then searching for them, that's kind of a weird thing to do. I haven't seen anyone else do it.

Zach Peterson:

Maybe they're in stealth mode.

Duncan Haldane:

Maybe they're in stealth mode. I mean PCB was the fastest growing segment of EDA in the last couple years. And so people are paying attention now, which thank goodness. When we started, PCBs really need to be fixed. But things were improving in some areas really quickly, which is, it's great to see, it's great to see the attention in this space. So yeah, maybe there is a stealth mode company out there.

Zach Peterson:

Well if they're out there and they're watching this, hopefully they'll get in contact with you and maybe you will work together.

Duncan Haldane:

Yeah, they usually do.

Zach Peterson:

They usually do?

Duncan Haldane:

Yeah, startups don't really have competition. So ours is kind of a green field thing, and even if you're entering into the traditional PCB space, the odds that you encounter another startup and say like, "Oh, this other startup solves our problems," at getting customers, like 0% likely.

Zach Peterson:

Sure. So the approach here to generating designs, this is totally unique and when I first saw it, I realized there's probably this whole other group of young people who are interested in technology but who see hardware as maybe difficult for them to get into for one reason or another. Is one of the goals of JITX to really just expand the potential design audience or the potential group of designers that could then get into this field by just giving them another way to get to a piece of hardware? Is that really the goal here?

Duncan Haldane:

I think that comes next. So JITX is for professional electrical engineers, right now typical user has at least 5 to 10 years experience. But what I really wanted from JITX is, expert hardware engineering knowledge should be reusable. I think the ideal is think of all the hardware experts you know, and I'm sure you've had them on this podcast, what if their knowledge could be applied to every single design that goes out the door? I think that's really interesting. And once you start automating that level of design, then you can open up to other people that don't necessarily know that and will trust a piece of software to manage it for them, which I don't think describes professional engineers right now, that trust has to be built. But later, yeah, we have a lot of... So we're free for educational programs, typically master's PhD student, they've build some hardware already and they're like, "Well, just kind of looking back to my grad school days." They look a lot like that.:

And then we're also building full automation for boards. So new kinds of routing algorithms, new kinds of placement algorithms, checks for physical geometry because people entering the field need actually more automation than professionals. So not only are they a bit less willing to pay for things, but they also need more product. They really need an automater, they need someone to make sure that the power integrity of their board is at least decent. Usually they're not trying to do something too challenging, but I found that the product actually needed to support more automation before you get to really open it up to people that might not be hardware experts.

Zach Peterson:

Well, I'm going to just go the AI direction here for a moment, but I think anybody that knows about how those tools work, they might look at this and they say, "Well, it's just recycling old stuff and it's not really innovating," is the response to that to say, "Well it's helping you eliminate reinventing the wheel so you can focus on building the new and improved part of this system. And it really allows you to, I think, focus your efforts and build better in the area that really is new and there is no past data on it."? Is that a fair way to look at this?

Duncan Haldane:

I think that's a good way to approach it. So I think it's very much right now-

Zach Peterson:

Who wants to design the same old switching regulator 20 times?

Duncan Haldane:

Well, I think the future is optimization. So right now JITX automates model-based engineering and worst case circuit analysis. And that's really helpful, right?

Zach Peterson:

Oh yeah, definitely.

Duncan Haldane:

But then when you think about AI coming into this, I'm not going to use it for worst case circuit analysis. AI, think of it as a search tool. The analyses you do on circuit boards to make sure they're correct or predict computationally expensive. So you can use some AI techniques to say, "What about this design variation?" Just test all these different ideas very quickly. Have a human driving it to kind of do this what if analysis and search better. Rather than replacing, I think model-based engineering is model-based engineering and you don't need AI in there doing anything.

Zach Peterson:

The last time I had talked to anyone about bringing AI into this kind of generative design process, it was talked about in the same way I had read about in a paper from I think 2007 or 2009, not the newest paper, but it was on adaptive optimization. And essentially it's, the computer learns the best strategy for generating the design. Here it sounds slightly different, it's learning the best strategy for picking from a library of related designs based on certain parameters that are most important and then spitting those back out to you. Because I mean, random search algorithms or directed search algorithms, you know mentioned all of that is computationally expensive. I mean if AI is computationally expensive, I mean I could just imagine trying to do random search among a library of a million components. I mean we'd be sitting here for, until the end of our lifetime just waiting for a design to generate.

Duncan Haldane:

Yeah, yeah, I mean I think you can use AI for search in a number of ways. And it doesn't just have to be from a preset library. You can have AI drive some parameters to create new designs that it thinks are going to be good. You have AI kind of estimate how good it expects those to be before you proceed all the way down the realization. But what you see in the chip world is like, they're really using AI to optimize chips and it works. They have superhuman performance on specific structures, if you look at the PPA they can achieve. So to bring that to boards, you need what chips kind of already have, which is this dedicated verification software to actually make sure that whatever the AI dreams up is going to work.

Zach Peterson:

Okay. I like that you brought up the shift over to chips, because you're right, they are using it pretty heavily to do this kind of design generation. And I think for quite a while the PCB world has maybe lagged a little bit in terms of the design capabilities when you start comparing it to semiconductors, and I guess we could say the same thing with manufacturing, at least in some parts of the world, but the sophistication in semiconductors, it's just through the roof sometimes. When you look at it as an outsider, it really seems daunting. So bringing that kind of generative design capability from chips, or that same idea, into PCBs, what does that look like for the designer in terms of a day in the life? Are they just now, everybody's a systems engineer or is everybody just doing verification? Because if the computer is generating all the designs, what does that mean for the career of a PCB designer? I mean, so many designers are set to retire and we need to get a new qualified workforce in here, at least in the US and probably the rest of North America. So given that that's the case, I think we all need to know what to expect and communicate that to the younger generation if we want to convince that group of folks to actually jump in headfirst and become pro designers.

Duncan Haldane:

That was a great question. So on the verification side, there's a reason that we baked verification into the language. The fact that you say, "Here's how you choose a crystal oscillator and here's how you check a crystal oscillator." And it's the same thing that you put in your design because my co-founders had a previous project called Chisel, and this was a high level language for designing chips and it was developed at Berkeley along with RISC-V, spun out a company called SiFive using it 10 times more productive on the design generation side. And then verification becomes even more of the tall poll. So learning from that, you make verification into the language because computers are actually pretty good at verification. It's just a lot of details to track and that's fine. So hopefully nobody has to be more of a verification engineer.:

So my hope is that maybe they're more system designers, they're able to design more complex things or they're able to optimize more. They're able to just, what we need right now is just raw productivity so that we had to have JITX address the part that's not addressed by any design tool, like when you're Googling or reading spreadsheets or reading PDFs and then typing into spreadsheets. All that stuff that passes through the brain deserves a tool. And then I've been gratified by the response from education, by people in education, like the new people that want to enter the field, but they expect code, they expect a bit of automation.

Zach Peterson:

I didn't think about it like that, but that's actually a good point. Their expectation is that this should be a bit more automated in some way. And it seems like you're really working to serve that right now on the schematic side. But I think you had mentioned earlier also a bit more on the physical layout side, possibly the routing.

Duncan Haldane:

Yeah, that's right.

Zach Peterson:

Yeah. Okay, I'm going to get on my high horse for just a moment about automation, and maybe not a high horse, but maybe just kind of ask you to speculate a little bit. So I mean, one of the trends that you see throughout the history of, well I guess the history of the western world since the industrial revolution is, as new automation comes out, it creates a sort of stratification. Those who know how to take advantage of the automation, I guess do better than those who maybe don't understand how to take advantage of the automation or just refuse to for whatever reason, pick a reason, but for whatever reason it doesn't happen. Is that something that designers should be worried about or is this really the type of approach to design that the big boys, the Altiums of the world, are going to have to embrace and integrate in some way? In order to, first of all keep up with their competitors, but also to ensure that they're meeting those expectations of designers who are coming into the field and are expecting this kind of automation?

Duncan Haldane:

All right, good set of questions. So I don't think any electrical engineers should be worried about losing their jobs. We're in a labor shortage right now. All the companies I talk to can't hire enough electrical engineers and are now reaching for automation because they can't hire enough people. So if that's not job security, I don't know what is. I think you're right that not everybody is going to adopt automation. That's fine. Yeah, look back at Synopsys. So they did languages for chip design back in the eighties. So VHDL came out first as a simulation language and then Synopsys was like, "You know what? This code you're writing over here, we're going to generate schematics from your code and you're going to say what you want this circuit to do and we're going to produce an optimal circuit that does it." They had the biggest IPO of all time, if I think about 5% of the total user base. But that 5% could do massively better. That's what made the difference for Synopsys, they just help people optimize more, which I think is a really worthy goal. So it's not going to be everybody and that's fine. I think the people that it's not still have a lot of job security. And what was the other aspect of this kind of three part question?

Zach Peterson:

So are the big boys, the Altiums of the world, going to have to embrace this kind of approach because it gets to a point where everybody else is doing it and that just becomes the expectation?

Duncan Haldane:

Yeah, well I feel gratified that we've been embraced by Altium at least. And so we're trying to be good citizens. So we work with Altium data, which is not easy. So being able to consume it and then export it back into Altium is a major part of our development effort because there's a lot of data to handle correctly. So we haven't seen any pushback from the Altium or the big three, or I guess the other big two are Cadence and Mentor, because our tool doesn't compete with theirs. No ones really done this front end of hot requirements to schematic. Once you're in schematic land and board land, these tools are pretty good and there's no reason to reimplement that, and that goes for the chip side as well.

Zach Peterson:

Sure, sure. So I guess I'm wondering what's next for the platform beyond physical layout, in terms of what it can do and what maybe a developer could step in and do. Could the same approach be used for, let's say code firmware?

Duncan Haldane:

Yeah, so we've got some hooks into firmware. So like I said, we have that PIN assignment solver and the micro controller generator that would actually generate the firmware setup file, at least for STM32, who made that sort of thing easy. We're also building out our database so you can optimize better. And we are building hooks into the other CAD tools as well to expand the user base a bit, but really focused on Altium users these days.

Zach Peterson:

So in terms of the firmware generation, I imagine you're sitting spitting out source files and they probably have all the libraries and everything just packaged up in one area. And then you've got functions where users can then enter in their custom application stuff, whatever it is that needs to do internally, but you've at least generated all the connections that are needed to maybe interface with some peripheral or whatever else it may be.

Duncan Haldane:

Yeah. So for an STM32, when we solve the pin assignment problem and try to do it optimize for ability, we know all of the pin assignments, and you can also set all of... They basically expose a lot, so you can do a lot of automation with it. So they set these, what's the state of this pin? Is this pull up enabled? And then we also use that information in electrical checks as well. So yeah, that pin assignment set up goes back to, I think CubeMX, and that creates a CubeMX project file. And then your firmware sits where your firmware is and you can just use this CubeMX tool to generate the connection to your hardware, without trying to retranscribe everything every time there's an iteration.

Zach Peterson:

Sure, sure. Yeah. I think for anyone that's had to jump in and maybe go through open source stuff or try and find libraries for their components and then all of a sudden they realize, "Okay, I have to write these drivers for these peripherals," it can get a bit irritating having having to code everything. One thing that I think, or that I'm wondering about is, you're looking at one side of this right now, which is the CAD tool user. How much engagement have you gotten from the semiconductor vendors providing resources and data and anything else that you might need in order to build out the tool so that it can produce, I guess you could say more accurate designs or designs that can address a broader range of constraints?

Duncan Haldane:

Yeah, great question. So a good amount of interest. So what they'd like to be able to do is have a parametric reference design. So right now they have a static reference design, they have one board when application, or maybe one board and a bunch of applications,` every possible application you could squeeze onto it. But what if you could just say, "Well, what if I could just generate variations of this circuit for every possible need thar a customer might have?" It's like, Okay, now what if I could put those reference design generators together and have a system generator?" That's actually pretty straightforward. So that that's what we'd like to, if you're not partnered with us yet as a semiconductor, please reach out. I think it's a great tool for especially applications designs. Yeah, helps a lot.

Zach Peterson:

Almost like WEBENCH on steroids.

Duncan Haldane:

Yeah, so just kind of more generalized version.

Zach Peterson:

Yeah, exactly.

Duncan Haldane:

Yeah. So WEBENCH is pretty good for power and they're really smart about how they simulate and check these power designs, but it's hard to do that once you get to functional requirements of, "Okay, I need a building automation solution." And that draws on seven reference designs and how do you actually connect those things together becomes really challenging if you're not using a tool for it.

Zach Peterson:

Yeah. It's that next higher level up in the system and then connecting all the pieces together. Yeah, I see what you're saying. That would be really cool if all the semiconductor companies just released the JITX plugin or whatever piece of software is needed to interface with your tool and then, "Okay, I download this, now I've got access to all of microchip, download this other piece, I've got access to all of Silicon Labs," or whoever else.

Duncan Haldane:

Exactly. And then they can just design in their products to literally any board. Because engineers have to do that a lot anyway, especially with a component shortage, seeing churn and availabilities and you have to swap out major circuits all the time. And also semiconductor companies are doing pretty well. The leakage current of modern devices is shockingly low and they want that designed into legacy boards, but surprised nobody's got the capacity to do it.

Zach Peterson:

So you could very quickly generate that from an existing design based on some other functional requirement. So I mean this is just as much of a design update tool as it is a design generation tool from scratch.

Duncan Haldane:

Yeah, exactly. And that's why we're excited to be working closely with companies like Altium. So you've got these existing designs, you've got a great tool for finishing the rest of the design. So if you can attach this computational piece and maybe check your design a bit more or do a bit of component selection optimization and just be a bit more productive as a parallel path, then yeah, you're in a pretty good spot.

Zach Peterson:

That's excellent. That's great to hear. And I'm really excited to see how all of this is going to turn out, because these new approaches to CAD and these new approaches to building designs I think are so important. Especially like you've said, the younger generation expects a little bit of this already, and so it seems like you're going to be here to give them the tools that they need. So this is really interesting. So thank you so much for joining us today. We're getting a little up there on time, but definitely wanted to make sure that the audience out there gets introduced to JITX and we're going to have some great resources in the show notes and we encourage everyone to check out JITX and of course connect with Duncan.

Duncan Haldane:

Okay, thanks Zach. It was great being on.

Zach Peterson:

Yeah, absolutely. Thank you, thanks again. To everybody out there that's listening and watching on YouTube, we're having an Altium Designer promo going on right now. You can access the link to the promo in the show notes. We encourage you to sign up for Altium Designer if you haven't already. And last but not least, don't stop learning, stay OnTrack and we will see you next time.