#691 – System Designer Lets You Try Every Part with Michael Gielda

Chris Gammell: This is The Amp Hour Podcast. Released March 23rd, 2025. Episode 691. System Designer lets you try every part with Michael Gieldo. Welcome to The Amp Hour. I'm Chris Gammell of Contextual Electronics.

Michael Gieldo: I'm Michael Gieldo. I'm co-founder of Ant Micro.

Chris Gammell: And you're back for the third time on The Amp Hour. Welcome back, Michael. Thank you. Thank you for having me so many times. Oh, it's a pleasure to talk to you. And we're going to be talking about all the things Ant Micro has been doing and kind of the various open source projects that you and Ant Micro are part of. So I'm excited to talk about that stuff. You and I are often, at this time of year, usually, this is going to come out a little bit later, but usually you and I are hanging out at the Zephyr booth at Embedded World. But I didn't make it there this year, and you're headed there in a day or two. So I'm sad I won't see you there.

Michael Gieldo: Yeah, I wish we could see each other there too. But I'm only going for one day this time. My team's there demoing a bunch of things. And indeed, we're at the Zephyr booth as well.

Chris Gammell: Yeah, that's great. Well, let's start right in there with Zephyr stuff. So you and I know each other from the Zephyr project. I think you were just re-elected as the chair, marketing chair. Is that right? Congratulations, Mr. Chairman. Thank you. Doing your work here in the AMP Hour, talking about marketing. And yeah, so how does AMP Micro kind of work with the Zephyr project? And what are some of the new things you've been working on in Zephyr?

Michael Gieldo: Yeah, oh, Zephyr has been pretty central to our story. We've been involved with the project since almost the very beginning. Because it just makes sense. It structures data. It makes microcontrollers a little bit more like Linux devices. For those of you who don't know, Zephyr is structured around device trees and data-driven flows that allow you to build your binaries and work with your hardware in a structured way. Which is kind of a difference from how some other operating systems do it or how people do it in the bare metal world. And because of that, we've always liked Zephyr and started using it many years ago for all of our projects. Whenever we can, of course, afford it, there are clients who want to use different things. But most of the time, if we can have a say, we're going to use Zephyr. And Zephyr...

Chris Gammell: Also, we should say that some of the hardware engineers listening right now, they lament the fact that it's more like Linux. But it's actually, as a hardware person kind of coming up the stack, I always think like, man, this is so crappy to learn that stuff. But once you do, you start to kind of like, you're like, I see it now. Okay. All right. All right.

Michael Gieldo: Yeah, that is a little bit true. Yeah, of course. So there are some downsides. Definitely Zephyr's, you know, build system and setup is sometimes challenging for people. And we're always trying to make the developer experience better. So, you know, all kinds of help in that regard is appreciated. But once you cover this initial kind of setup part, it scales really well. It's a really good tool to like build actual products that have variants, that can be ported across a range of hardware. All these kind of things that really become important as soon as you start rolling out, you know, complicated products. And this is what we do. So kind of Zephyr was a great choice for us. It doesn't mean it's a great choice for everybody maybe, but like predominantly, if you're really looking to use it for like professional purposes, the investment pays off. Definitely. Yeah.

Chris Gammell: How much has Ant Micro actually done that migration? Because like that's one of the things I always think about is like, okay, Zephyr is great. Like I've done some, you know, across chip porting type stuff. But like in practice, do you see companies like actually doing that? Like being like, all right, well, we're going from vendor A to vendor B because it is in Zephyr?

Michael Gieldo: Well, that does happen. It doesn't happen very often because I think people just prefer to have that option. They don't necessarily like to, you know, jump my controllers. If they're comfortable with a certain vendor, they'll probably use them for as long as they can. But at the same time, just having that possibility is important because you don't want to be stuck with a part that's no longer produced or something. We had this in the chip shortage times. Some of us have already forgotten maybe, but it was really, it was real, right? Like you could suddenly get stuck with a product that you can't make anymore. Yep. Yep.

Chris Gammell: That, I feel like that, it sounds bad, but that was good for the Zephyr project. You know, like a lot of the chip vendors were calling in micro and other companies to be like, hey, how do we get in on this? Because we want to be able to not only like have this as an option because our customers are asking for it. They're also asking it because new customers were walking the door and being like, hey, I can't get my chips from other vendor. I'd love to switch to you. Can you, can you supply this? And they're like, yes, we can. If only we had the firmware and software, higher level tools tooling built on top of it.

Michael Gieldo: Yeah, exactly. And I think maybe to illustrate how this is good, we should look at the device tree aspect and the way we use it with Renode and the Zephyr dashboard and so on. So essentially what we do is we look at the entire ecosystem of hardware supported in Zephyr and not just Zephyr, by the way. We're also using Uboot and Linux in that way. But concentrating on Zephyr specifically, Zephyr has a really good data set about, you know, hundreds of platforms. It's like 800 maybe right now where all of them are described in one way. And everyone's trying to make sure that this description is correct, up to date, useful, easily parsable. There are tools to, you know, to process this data. So we can take that data and process it to output Renode simulation files. And so if we have support for specific cores and peripherals that are included in specific SoCs on specific boards, that means that the layout, like how these things are arranged on the system bus and, you know, what's where, which chip has how many UARTs and so on. All of this information we're getting from Zephyr and we can just generate that automatically. And assuming we have a model for a specific, let's say UART or I2C controller, that'll just work. And we can essentially run as many as, I think, 620 platforms in Renode now because of this. And of course, like we historically knew it was possible to do this, but it wasn't before we tried. And we actually built the Renode Zephyr dashboard where we take Zephyr, we build it across all the targets. We run simulation and a huge, massive CI with like thousands of, you know, because there's like 12 binaries across 800 boards. So it's what, 10,000 different binaries that we built. And then we run all of them in Renode and actually most of them do run, right? So it's like binary compatible firmware running in simulation. The scale is like impossible without automation. We used to do this by hand. Obviously, we never got anywhere, you know, near that number, right? We had like 50 demos and we're super happy. Oh, we have 50 demos, right? Now we have like, I don't know, 5,000 demos more.

Chris Gammell: Yeah, that's wild. And when you say the binaries there, you mean like those are kind of the test programs or like the philosopher's table or whatever that's called? Like the test programs that are running actually on the core, interfacing with peripherals, like actually testing out the capabilities and showing that it's actually cross-compiling to all these different targets?

Michael Gieldo: Correct, yeah. So there's like some RAS tests, some AI-related stuff, Blinky. Obviously, these are like mainline Zephyr applications because those actually scale across a lot of targets.

Chris Gammell: Got it. Could you explain the, so Renode is, I think, something you and I have definitely talked about on the show before, but can you remind people what it is and then how people are using it?

Michael Gieldo: Absolutely. Absolutely. So Renode is a simulator that you can use to develop complex systems. We can do multi-node. We can do, you know, communication over interfaces like CAN, Ethernet, wireless. We can, of course, simulate single nodes too as a consequence, right? Like if your system has N nodes and N is one, then Renode can do it too. But I think it's most useful when you're building something complicated. And in fact, we've shown this recently. We've had a lot of interest from the space industry. You have a number of customers there. And pretty much all of them have fairly complicated systems because a satellite or some other like space-bound system just has to have like multiple microcontrollers in it. We have customers in automotive. Same story. In a car, you'll find like 100. 200, 300 micros in there. It's nuts.

Chris Gammell: Yes.

Michael Gieldo: So you can do that. And then, of course, this portability aspect, this scalability aspect becomes extremely important because you can't just imagine to be doing all of these things by hand.

Chris Gammell: Yeah, totally. So just to kind of draw a picture from Renode kind of down, Renode is kind of coordinating peripherals and cores and all that other stuff. But then what is actually doing the – so like you said, you know, the UART, if it's like a known UART, we can simulate that. What is actually doing that like implementation of the simulation there? Is that NSIM? Is that QMU? Is that some other – or is that actually Renode as well? It is Renode, yeah.

Michael Gieldo: All of this is Renode. We have both processor models and peripheral models. We sometimes interface with other tools for like physical simulation or similar things. So Renode is absolutely very easy to integrate with other things, but like for the core simulation capabilities, this is just Renode itself.

Chris Gammell: Okay. So you have your own model of like a Cortex-M33, for instance? For example. Yes. Yeah. Interesting. So then what – I guess you probably talked about the last time – one of the times you were on the show, but like what is – I guess I've learned more about Zephyr since then too. What is actually doing that under the hood then? So then that's just like Python code or C or some other language that's just responding to –

Michael Gieldo: Yeah. For the course, it's C. It's a translation library, as you call it. So you take instructions from one architecture, you translate it to another. And traditionally, that's been x86 as the host, right? So, I mean, most people used to only run x86 machines as their hosts, and then you would have to translate, let's say, ARM. But now with Apple, we actually also have the ability to do ARM as host. So it's basically translating from architecture A to architecture B, where those architectures could potentially be the same. But yeah, you're kind of – people have called Renode Docker for embedded, which is not accurate by any means, but it is kind of nice. And then it paints a picture of the metaphor.

Chris Gammell: Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Okay. Yeah. It's good for me because it's two things that I have no idea how they work. That is good. I know a little bit about both work, I think. Okay. That's cool. And then when people are kind of gluing it all together, like the automotive and the space examples are interesting. So then the – so someone's writing high-level control software – sorry, test software for like a car. They want to like test like user stomps on the brake. And then it fires system calls throughout the system and, you know, down the line, down over the CAN bus. And it does this and this and this. And it triggers this system and that system. And you like want to see the behaviors that respond as a result.

Michael Gieldo: Yeah. Exactly. And, you know, you can do it in many ways, of course. But like we believe that definitely simulation where you're running the real binaries is at least one of the ways you should be doing it, right? Because theoretically you could, you know, mock things and model things on a higher level and just, you know, like completely avoid the hardware-oriented stuff. But in practice, of course, a complicated hardware system has so many ways to fail that it's kind of better to have that kind of simulation capability in place where in the end you can take the production binaries and run the test and you're kind of saying, hey, look, I've tested those specific binaries and they do work. And also like in terms of continuous integration, it's just so nice to be able to, when you're contributing code into, you know, a systems firmware, you are testing the same exact binary firmware that you're compiling for your target machine. And maybe you even have hardware-in-the-loop testing. You should, right? If you're building a car and you'll be using those same binaries for, for like renal simulation and the hardware-loop simulation. I think this is very valuable.

Chris Gammell: Yeah. I feel like that was always a missing piece for me when I was like starting out with microcontrollers. I'm like, why would this matter? Like I'll figure it out when I'm on the bench, but it's just, when you think about, I think the car is a great level of complexity. Cause it's like, if you're working on the, I don't know, the, like a window controller, like a, you know, up, down window controller and the circuit board for that. And the firmware for that, because there is firmware in there now, I'm sure. And it's like tying up the Lin bus and somehow like the Lin bus actually triggers, you know, something down the line that like the ECU that's interfacing Lin bus to the canvas. And those are all tied together and like you cause a lockup, like way down the line, but if you don't know that until the integration stage, like when you're actually like pushing the down button on your window in the test car, like that's, that is a, that's going to throw everything in the chaos. Yeah, exactly. Yeah, exactly.

Michael Gieldo: So. But yeah, I mean, the car industry is kind of specific in that, you know, especially in that it's both like ancient and, and, and complex in some ways. But, but although it's close to people because everyone drives a car, but I can maybe use the example of the space industry in the sense that, you know, there's, there's a sudden boom in space exploration. There's a lot of companies building satellites and so on. And we've been helping people, you know, get their stuff to orbit. We have this great customer at Aerospace with whom we've been working kind of in a really rapid development project where, you know, from concept to orbit below one year. That was like the headline for it. Right. So I would build everything.

Chris Gammell: One year development and then like three years waiting for a launch window or something.

Michael Gieldo: No, no, actually with SpaceX, you can pretty much get your stuff into space. You know, we did have a delay actually. So there was this like little glitch somewhere last summer, but, but it was a delay of one month. Right. So it isn't so bad these days if you're launching something fairly standard. And so, you know, we, we could build like, you know, the whole thing and simulation, you know, and for example, like as in many projects, this one also kind of, you know, there was a change of hardware somewhere at some point. And the fact that the things we're using are portable, both Zephyr and Renaud, et cetera. It's like, okay, we're changing hardware now because reasons, but that's okay because the underlying abstractions are the same.

Chris Gammell: And so what was the thing doing?

Michael Gieldo: It's like a data center in space, let's call it. So a processing system that instead of beaming everything to earth, tries to process data on board. The, the main computer there is the Jetson Orin actually. And so, so that was kind of, I think maybe historical first, getting that to orbit. And of course, the Tero was doing, you know, the work related to making it right hard and so on. We've been helping them with building the hardware, but they're kind of in charge of making this, you know, space great. As you say, Nvidia chips aren't exactly, they're kind of big, small, small.

Chris Gammell: They're not by default. Yeah. They're just kind of consumer. Geometry is not great for rays. Yeah. Yeah.

Michael Gieldo: Yeah. But there's a company called Cosmic Shielding Corporation. That's also building those kind of shields for, for COTS hardware. And that's what they've been using.

Chris Gammell: Okay. That, yeah, I'm sure that helps. So yeah, this is a great project. My sci-fi, my sci-fi brain's like, oh, you could cover it in water. That helps with space rays. But is it, is it something else that actually, like, you don't want to put lead up there. Right. But for shielding. Yeah.

Michael Gieldo: But, but anyway, like these kinds of projects are really awesome to work on. And there's this real challenges and, and you can see how simulation just, just helps tremendously because, you know, you're not going to be able to, you know, test in, in the real, in the real world too much. We have also other customers who have been using Renaud in space context for, you know, testing. And we've even discussed like training where a lot of the time when, when you want to do training, you need like the full setup lying flat on your desk. And maybe you only have three of those. And every time you, you have to like get this thing running, you need actual engineers to, you know, turn it on and operate it for people to get trained in how to operate the mission. And the mission operators are not necessarily engineers, right? They might be, but they might be other kinds of people. And you can see how it's kind of almost crazy that in order to like run the training session, you actually have to, you know, take engineers out of their like room where they're developing the thing to actually operate it as well in the testing room. Whereas in the training room, right? Whereas with Renaud, you could potentially just kind of do all these tests and simulation. And because it's all like automated and scripted and there isn't like five different MCUs you have to flash or something. Then you just press a button.

Chris Gammell: Yeah, but how do you tie together the, so this is always my, this is always the push pull, right? It's like, so in that case, I have a very specific like simulation and training versus the reality thing. When I was at Samsung, oh, so many years ago, like 20, 2006. So they didn't let us touch the semiconductor processing equipment. They sent us to like a training center and like, you know, there was like using the control software that was not tied to the actual plasma etchers that were there. And so I like sat in a room for a week, just like clicking on a UI interface that was like, oh, and now the wafer has moved into the container, right? And it was like, I don't know if that's actually reality. And like, you know, like that's, so it's always that tying of the simulation to the reality. How do you, how do you actually validate that piece? Right. I mean, like the, the fact that it actually is doing in the physical world of what the simulation is saying.

Michael Gieldo: Yeah. Or the other way around, right? Like, sure. Yeah. Of course it depends on the industry, depends on your use case. So definitely, you know, replacing everything with simulation is not possible. But like, we're always talking about the Pareto principle where 80% of the time you probably want to be testing a simulation. And then like, once you know what's going on, once everyone's been trained and things are working, you know, you're pretty happy. You should still go and actually like, you know, see what the thing does in practice. But you reserve that to really iron out the last details. You don't go. And because like, very typically we've seen this over and over again, especially among our space customers. Many of them will reach out to us and say, you know, our hardware is not even available yet. Or we have two copies or something.

Michael Gieldo: Right. Right. It's so expensive. And so like. Or it's in space. Yeah. You can't, you can't just very simply scale it. Right. Like you'll have the barriers of like physical location of the teams or, or maybe someone's traveling or, and then with pre-note, they'll just grab a laptop and they'll do work. That's kind of the beauty of it.

Chris Gammell: What is the level of, I guess, so maybe that satellite's not a good example. If we can just switch back to the car for a second. Right. So like the, the actual like actuation of a thing. Right. So I guess it could be deploying solar cells. Right. So like I enter this command, it filters through all the different subsystems that needed to do it. And then a, you know, a little arm on the, on the satellite deploys a solar cell. So like in re-node, how do you actually, is it like you're watching a, a register and it's going from zero to one? Or is it like, there's some other kind of like visualization, like the, the thing has happened. Like how do, how does the user know that?

Michael Gieldo: Oh, that's a very good segue really, because yeah, we've been working on this. So obviously on some basic level, it's a zero turning to one. Right. But then you're thinking, okay, how can we, first of all, how can we like plug this into the external world? So that's not maybe the physical world, but I mean like a simulated physical reality. And that's one of the aspects we've been working on where, first of all, we have like a data ingestion format called re-node structure data, re-node sensor data, rest. And this rest format allows us to do rest.

Chris Gammell: That's confusing.

Michael Gieldo: R-E-S-D. Aha. Okay. And so basically you have a file that would kind of specify what data points happen at what points in time. So it's like one time axis and multiple data points potentially. We've been working on this with like some consumer electronics customers, logistics customers, and space customers to, you know, use rest to kind of have like a unified way to input data from the outside into re-node. And then, of course, the control loop happens in re-node and then, you know, outputs happen. And so that's the ingestion part. And I think this is kind of very useful to have standardized because, you know, you're not like getting those data points independently. But you can kind of, first of all, many customers have some data pools, right? They have specific data recorded maybe or some synthetic data generator and so on. So we only need to convert it to that format. And, you know, we can use whatever people have.

Chris Gammell: Make up a fake example. Can we go back to the two examples you were talking about or make up another example for like what would be in this res, reds, R-E-S-D-F, is that right? Reno structured data format?

Michael Gieldo: Reno structured data, sensor data. So just R-E-S-D without the F. R-E-S-D. No. So let's imagine like a number of data points as like acceleration, maybe temperature and pressure. Let's say. Yeah. So we used to build drones. We still do, right? So sometimes we have customers building drones. And, you know, you need like to know what the acceleration is. You maybe need to know what the ambient temperature is and pressure definitely need to know as well. So like you have those parameters and like all of them are important for a control loop. And, you know, you have a file where just the data points are specified. You feed that into Renode and it just like unfolds this data series, you know, in time. Renode has virtual time, right? So this virtual time kind of is correlated, right? And every time Renode runs, it's going to be the same like timeline, like things don't happen randomly. They can if you want them to, right? You can actually change the seed or you can randomize things by like if you want it. But by default, if you're just going to run the same script, it's going to run the exact same thing, the exact same way also. So, yeah, you have this data.

Chris Gammell: Because I imagine with like control data for a drone, it's tough to like, you can't like tune it in situ. You can't be like, oh, well, I'll just modify the PID, you know, the proportional element of, you know, the drone's response on rotor one because then it's going to crash. You can't do that like while it's flying.

Michael Gieldo: Maybe you could, but it's tougher, I feel like. Absolutely. Yeah, yeah. So that's one of the things where simulation helps in, you know, finding like testing in a wide variety of use cases. Because normally you would test things, of course. Like, of course, people when they're building products, they're not stupid. They're building those things and testing them in the field. But this testing typically takes like a lot of time. I remember when we were at university, Renode did not yet exist. Working on these kind of systems, like 80% of the time was just testing, right? And testing, I mean, like with a drone in your hands and or like sensors mounting things to walls and things like this. And then obviously you spend a lot of time testing, but you still don't test everything because you like you can't be bothered to, you know, do everything. In simulation, you're like, okay, I'm on a computer. I can just like be creative. I'll come up with a new test scenario and it only costs me more compute power, which can be parallelized, right? Like you can have a thousand Renode runs across a thousand servers. So in practice, you know, you start getting like creative in terms of like what kind of current test you're going to test. You can also do things like accelerate time. So if your system isn't like really busy, if it's not like busy looping on something, which is hard to simulate. But if it's mostly just reading something here and writing something there and maybe sleeping for a while, you can just squeeze the time. And you can take like a week's worth of data and compress that to, let's say, 15 minutes, right? And now you've tested the behavior of a system after a week, which normally takes a week, right? Yeah, right, right. And I remember this Boeing problem.

Chris Gammell: Accelerating the time, I can tell that this drone will not work at the heat death of the universe. Yeah, maybe that can't be tested easily.

Michael Gieldo: But I remember those problems where like something would happen after a year because like a counter would overflow.

Chris Gammell: Oh, yeah, that's a good one. Yep, exactly. 32 bits is only so much, huh?

Michael Gieldo: Yeah. So this can be testing simulation much easier. I'm not saying that, of course, you'll always catch it because you have to be creative enough to figure out that this could be a problem. But like if you figured out this could be a problem in real life, you wouldn't be able to test it very easily because, you know, you'd have to like write artificial maybe firmware and tests. Whereas in Reno, you take the production binary and just say, okay, let's see what happens if a year passes. Yeah, yeah. That's good.

Chris Gammell: That's good. What about the variety of kind of stimulus or stimuli, I suppose, that like how creative can you be there, right? Because it's like the temperature shoots up to, you know, 100 C. It's like, okay, it's not going to happen. But you could do that. I mean, like that would be like testing like boundary limits on center data, I guess. And maybe that would cause it. Absolutely.

Michael Gieldo: So, of course, we can't simulate like physically what's going to happen if 100 degrees happens and, you know, your hardware melts, right? This is not going to be something in testing Reno. Yeah. But in terms of the control loop. You're going to smack you in the face a different way. Yeah. In terms of the control loop, absolutely. You can do like borderline criteria that are very difficult to simulate in reality because, you know, you'd have to like heat up things very heavily. And that would break them in different ways. So testing the control loops in border criteria and border conditions, I'd say is also another great feature that you get with simulation.

Chris Gammell: Yeah. And I guess there's like combinatorial like weirdness that could happen too. So it's like, you know, the sensor one is doing this and sensor two is doing that. And for some reason those interact, you could have like, is there like data fuzzing you can do to like kind of cover? We've actually been doing fuzzing. Yeah. Yeah.

Michael Gieldo: We haven't done as much of it as I'd like yet, but I mean, this is a growing topic and I think, you know, more people want to do it once they realize that you, you know, actually can do it. And they've, they've run out of the simple things to test, you know, and then you realize, oh, we could do so much more.

Chris Gammell: Yeah. Yeah. That's interesting. Yeah. I mean, I imagine like you said with space customers too, like they only really get one shot. So they, they need to be really good at that stuff and like having.

Michael Gieldo: And when you, when you mentioned fuzzing, like it reminded me of like the work we're doing right now with AutoML for this kind of ties ties for me with, with our Kenning framework. Kenning framework, we have like this open source AI framework for well, portable AI, you, as you might guess, we're kind of fans of portability and reusability. And we're just demoing it at the moment as well this week. So it's kind of fresh on my brain. And basically it's called Kenning.

Chris Gammell: You said what's, what does Kenning stand for? Like, is that a topic? I don't actually know that.

Michael Gieldo: It's kind of a poetic expression means of expression in Icelandic sagas where you'd have like a metaphorical expression that would typically begin with the same letter for describing something, you know, like poetically describing a ship to be like the, the warrior of the waves or something, you know, that would be a Kenning.

Chris Gammell: I used to do that all the time too. Episodes one through 255 of the Empire were illiterative titles. So, yes. So that would be, I'm quite a Kenneringer myself. Do you have a skateboard baby? No.

Michael Gieldo: So basically, Kenning is also using Renode, by the way, for simulating things. And because we can kind of, you know, define AI scenarios and run them across a variety of hardware. And this AutoML feature that we're adding is like trying to figure out the right parameters for your, you know, AI workload. Right. So it's pretty much kind of associates with my head with this fuzzing problem that you mentioned. It's like you have to test a lot of things to figure out what's best. And with AutoML, you kind of do it. And if you have a simulator, you know, you don't have to have hardware to try that out and make it happen.

Chris Gammell: So in this case, the neural network that's running here, though, is basically creating the variety of inputs for the, like a sensor? Um, I mean, AI piece, I guess the better question. AI is used so broadly these days, Michael. It's just, it's everywhere. It's, it's infecting my brain.

Michael Gieldo: That is true. That is true. It's more about the parameters of the network, really. I mean, you can manipulate the sensor values too, of course, and see what happens. So like all of these things become variables. That's, that's maybe one of the reasons behind the complexity of the task is you both have like data sets, but also you have like maybe your neural net, for example, which has like, you know, thousands of parameters, sometimes millions, right? Like billions right now. Right. So, so, um, there's so many things to tweak and, uh, you have to have some way to benchmark if you're getting better or worse as you're tweaking those parameters. Um, so, okay.

Chris Gammell: So that's like you're creating like a feedback into the, into the control system, kind of like the, the AI control system that is.

Michael Gieldo: Yeah. Although it's kind of, it's, it's, you know, there's many ways to, to, to use this, but yes. Okay. On a high level.

Chris Gammell: Yes. So, well, maybe we can make it a real test. Actually, it's a board I have on my bench. It's for the analog devices, max 32, 690 EV kit.

Michael Gieldo: Perfect. Because this is exactly the kit that we're demoing with. We're actually working on this.

Chris Gammell: Well, I'm looking at your website. So that's, uh, that was a, that was a bit. You're smart. It was a lead. Uh, but okay. So you've created Docker image with the Zephyr, the Kenning Zephyr runtime. Hmm. So what is actually, what is the Kenning piece in on this kit? Right. So it has, it has the micros that you're targeting and stuff like that, but you're training it to do anomaly detection of something. Yeah.

Michael Gieldo: Yeah. I mean, anomaly detection is basically, you know, can be any data source that's just, you know, supposed to behave in a way, but sometimes, you know, we have weird behaviors. And it, I don't know even what our example is really tracking in terms of like the, the real variable that's being analyzed, but, uh, it doesn't really matter. Right. Because it's more about the. Right. Right. Right. Right.

Chris Gammell: It matters only for hardware wings who don't understand it. Like me, that's, that was me. Uh, so like a, so like a temperature sensor that might be on board. Right. And if it spikes up.

Michael Gieldo: Or a vibration sensor or something like, I think vibrations are often used because you can imagine how like something's vibrating at a certain like a frequency, you know, like something's running as normal. And suddenly, you know, the, the, the, the, the, the frequency changes. Right. And like, what does that mean? Maybe something's broken. Right. You're trying to detect that anomaly.

Chris Gammell: Yeah. And I feel like that's a, that's a really good example because writing just like a straight line, like threshold detection doesn't usually do the business there. Unless you're like, maybe if you're doing an FFT and you're like, oh, I always know that like the, you know, the third harmonic is going to spike or something like, maybe you do that. But like, if you want to cover lots of cases and just say normal, not normal, that's a very good use case because vibration has a lot of data generated and then some kind of weirdness that pops out as a not normal weirdness. You know, that's, that's, that's a good, that good use case. So, okay. Vibration.

Michael Gieldo: So. Yeah. So anyway, like it's, it's more about finding the right training parameters and, you know, like actually building the model for use on the microcontroller later. And, and, and, and, and, you know, that process in itself is complicated because, you know, if you, if you're going to like go and tweak everything yourself by hand, you're just going to be like, okay, am I getting better even? Maybe you are, maybe you aren't. Right. So that's where you're using kind of a, kind of control loop in a sense for, for like the training. And that's, that's basically what AutoML is.

Chris Gammell: Got it. So AutoML is the thing that's ultimately like the, the plumbing that's making it easier to build some of these models to like push down into the micro. Is that, is that a good.

Michael Gieldo: Yeah.

Chris Gammell: Yeah.

Michael Gieldo: Yeah. And you still need to like actually, you know, assess how it works in the end. So you have to have this like execution control loop. Right. But it's more about like, you know, executing it enough times that you run into this like optimal solution that you think is good with given your data. Right. And then you use that, that model for a while. And of course, like there are also more topics there, right? Because then you can kind of continue retraining that model to fit better to, to the actual scenario. But here we're talking more about, you know, the moment when you are developing the algorithm in the first place and trying to find the right parameters and tune them to the use case. Given a specific data set.

Chris Gammell: So another example that's from my past, that's just the counter example of why to use something like this, it would be like a co-op I did many, many years ago where I was like trying to detect, it was actually on an FFT type of thing. And I was like tweaking an FPGA and I generated the logic and I'd run it all through this different thing. And then like four hours later after my computer crunched on it, it'd be like, like the only thing I had in the output was like, again, it's just a zero or one. And it'd be like, nope, didn't do it. Start it again. So I'd get like two runs a day and it was just me clicking a button and then trying stuff in between, but there'd be no, there'd be no like loop cycling. It was always just Chris in the loop, clicking go and trying stuff and like having, I was a co-op, I had no idea what I was doing. And so, but like being able to actually like model this and run a bunch of scenarios, like it would be better to run a thousand inputs and get some actual better data on the output. Yes.

Michael Gieldo: And then feed that back in. Exactly. And that's kind of, I don't want to say it, but you know, like it's eliminating Chris from the loop, right?

Chris Gammell: Good. I, I didn't do much at all at that co-op because I, I, I mostly just sat around. I mean, like, honestly, I could have been doing other things. Yeah.

Michael Gieldo: Yeah. And also with like those small devices, remember that you have limitations like memory, you know, where maybe some of the models are really cool, but you can't run them anyway. They're just too, too big. So you have to like, you know, push the boundaries in different directions and see, you know, which, which kind of model works best given constraints. And I think this given constraints element is very interesting because what cunning does is, you know, you can look at not just one microcontroller. Like right now we're running this for this one example, microcontroller. But of course, like there's a lot of micros in the world, even a lot of devices, a lot of them. So you might imagine that you might formulate your automel problem in like, okay, given a family of microcontrollers with different memory sizes and capabilities, let me try to optimize where I'm optimizing across, not just like the parameters, the results, but also like, I'd like to use the cheapest possible micro. But at the same time, if that was like really cutting my performance in half, you know, or something, then maybe I'm not that interested in kind of over architecting this or over like simplifying this. I maybe I'm okay with using something bigger if it gives me better results. So you can start thinking like more cross-platform, cross like family. Cross-benefit analysis, really, right? I mean, that's almost what that is. And that maybe also brings us to like the system designer concept, right? Where one of the things that we're trying to do very heavily is, you know, try to reason about the world's hardware in a structured, systematic way. There's, you know, so much of it. And, you know, it's just hard to pick. And people tend to just gravitate towards whatever they have on their desk and what they like. And that's fine. Like humans are humans. It's good to use stuff that is, you know, sits well with you. But at the same time, if you could have some way to like have all of the world's hardware at your reach and the ability to like really pick what's best for your use case, I think that would be very valuable. And that's what we're trying to achieve. It's essentially a portal that we're building, which takes the data sources like Zephyr, like Renaud and Uboot and other things. We also have like an open source hardware repository, like a dataset, we can call it, which we constantly develop because we're building hardware, right? One of the things that we do is we build devices. And when you're building devices, you're building hardware. You're essentially putting together hundreds of components, right? And for all of those components, we have open source footprints and blender models so that we can, first of all, use them with Kaikad efficiently and in like a structured way. And secondly, we can generate really nice photorealistic visualizations. We've also recently like done like thermal simulations, like, you know, EMC simulations and so on, also with open source tools. So we're kind of building out like an open source toolkit for hardware design. You can really do great hardware design these days with open source tools. And we have this open source library that we also like digest as a data source and you put it all together and get like a Wikipedia of hardware. And that's what we're building.

Chris Gammell: Okay. So I went in and I clicked on the CH32 VWO3 EVT board and now I can go and simulate it in Renaud. I can build different things for it because it got ported to Zephyr, which is bonkers. So you kind of show all the things that are built, all the samples that are built for it, all of the things that are on the board. This is probably too simple, actually. Yeah.

Michael Gieldo: This is, this one actually isn't simulated yet. I mean, funnily enough, if you look at the, if you hover over the board itself, you'll see that the MCU there, you can actually click it, right? There's a hot area. You can click it. That's like the ESP32, which I don't know you've seen. It's been on the news recently. Not in a good way. So maybe you pick something else. Let's, let's grab a, we actually have a board called Environment Sensor. If you could take a look at that one. Okay. Because I think that showcases some of the things that are maybe not available as assets for other boards.

Chris Gammell: Yeah. That ESP32 thing was a bit overblown. I think I knew it when I saw it. I knew it when I saw it. It's not remote, actually. It's not remote execution or anything.

Michael Gieldo: Anyways. Yeah. But so here, if you look at that one, you'll have like a render and a photo side by side because we have this board. We've built that board. So we have a photo of it, but we have a render and like they're very hard to tell apart, right? Oh, yeah. That's cool. So either of those.

Chris Gammell: It's like a little drag slider. That's actually like the overlay of the render over top of the physical you're saying.

Michael Gieldo: Yeah. And you can even like the last button on the bottom is to like flip it around. And then you can see it's the render that turns around because of course we don't, we can't turn the photo around. We're working on like the ability to also just have a 3D rotatable board. It's kind of, you know, a bit more difficult because of the weight.

Chris Gammell: Yeah. It's like a key where they take 360 photos and they stitch them together. They don't even stitch them together. They just swap between them.

Michael Gieldo: Yeah. Yeah. You could do that. But generally speaking, like what interests us is, for example, the fact that we have, you know, we have the whole bomb with built-in KiCad and all of the components. If you hover over them, you're going to see that they're actually active. You can kind of click on one of them. If you click on the STM32, which we're using there, you're going to see like a specific enclosure. You're going to see that it's an instance of a specific SOC because this SOC exists in multiple enclosures. Right. And if you click at it again, you're going to, you know, go to, you know, what this SOC has inside and which boards it's found on and all these kind of things. So there's a lot of like interconnectedness. Yeah.

Chris Gammell: It's got five ADCs, three CAN, one CLOCK, four DACs, three DMAs. Okay. Yeah. And then how are those being used? Like those individual... So it's kind of like you're creating like logical kind of trees of all these peripherals and things like that. But ultimately, what do you do with those?

Michael Gieldo: Yeah. Maybe let's go to another board that actually has a simulation demo enabled for it. I just realized that this one doesn't. So maybe go with like some like 96 boards, AeroCore 2. This is also an STM, but this is like just a standard Zephyr target. And this one also has an SOC on it, as you can see. But it also has like all those Zephyr samples. And this time they say past, right? Oh, yeah. Okay. I see. And when they're past...

Chris Gammell: I will link all these things in the show notes for people too, if you want to follow along as you're listening. Sorry about that. This is the AeroCore 2 from S96 boards. Okay. And so we're just looking at this and clicking around on here. Yeah. I see. So now we're clicking on... So this is now simulated at the highest level. So Renode is simulating all of the peripherals that are on the boards. So the STM32 talking to... What else is on here? Buzzer?

Michael Gieldo: Yeah. Maybe not all of them because, of course, the samples do what they do, right? So Blinky blinks an LED and how it prints on a UART, et cetera. It would be interesting to have a test that just tries to test everything and just reacts to whatever is on the board. It's not completely impossible, but of course, this kind of demo does not really exist in Zephyr, so we're not running it. We could maybe build one. So anyway, point is, these have been executed in RCI. So for all of them, you'll see, if you click on them, you'll see the UART output and you'll see a trace. Those traces are actually pretty cool. It's like a standard tool that we're using, Speedscope. Can you full screen them, actually? Maybe not here, but in general, tracing is like something you get for free with Renode. And we're showing this, but of course, you can also download the assets. There's a button and all of these assets are available, and you can run this yourself in a collab, and you can run it locally. There's many ways you can reproduce those results. They're not stuck in our portal. This is just a way to visualize them, but this is all public information and all the binaries. We've heard it from a customer. That was a funny story. We went to customers, and they were like, oh, yeah, yeah, we're using your binaries to test stuff out. We're trying to run some Zephyr on some board, and we didn't want to compile our own binary. We just grabbed one from your portal and run it, and it worked.

Chris Gammell: So how would you imagine? So I look at this designer, the designer.antmicro.com, and it has, so the example of this AeroCore 2, how would you expect I would use this in design decisions that I'm making as a hardware designer or a firmware designer, as I moonlight as sometimes?

Michael Gieldo: On the most basic level, I mean, you can see what's supported in Zephyr, Renate, et cetera, which is already a nice feature. But more ambitiously, I think what we're looking for is you could click on this board and say, hey, I want to remix that specific board and build something similar but not quite the same. And we have that capacity generally because we have this VSD, this system designer. If you click it, there's an actual diagram editor in there, and this editor contains a lot of the things that are in the portal in general. But, of course, we're still working on making it good enough for you to be able to seamlessly just click, like, hey, let me rework that board and just change stuff around.

Chris Gammell: Okay, so it's kind of like a discovery tool sounds like for sure. So, like, I want to be in this ecosystem, so I want to see what's kind of enabled in this ecosystem. That actually is useful. But then, ultimately, what is the decision point that you expect someone would make versus maybe building up a board on their bench?

Michael Gieldo: I believe that, you know, a lot of the time when we're talking about systems, at least here at the micro, right? We would first start with, and even when customers approach us, right? They would start with some kind of a high-level diagram, essentially. Like, they would say, you know, I'd like a board that, you know, communicates over this over CAN and does this and, like, has those kind of sensors. And they're going to describe it to you in words, and maybe you tell them, hey, where's a grade, but maybe we should draw a diagram. And the first thing you do, typically, is you draw a diagram. And we saw this over and over again with people who draw a diagram, and that diagram would be, like, unstructured. And, you know, it would maybe contain errors because someone thinks that a certain device has four U-words, and it only has three, right? Ah, okay. Yeah. And it's, you know, it's not precise.

Chris Gammell: Yeah, and that's actually kind of interesting because that's often, like, a plumbing the data sheet kind of exercise that is non-trivial, right? I mean, like, especially if you're doing it across, you know, different families, different vendors, that alone could start to tease out some viable things. Yeah.

Michael Gieldo: Correct. Yes. So we're trying to automate that process where you're not, like, drawing on your napkin. You're drawing in a structured system that tells you if you're thinking wrong. And then once you draw this, it becomes a collateral, like, part of your project where you can verify your assumptions against what you drew in the first place. So you can, you know, maybe even draw an abstract SOC and say, you know, it has this, this, this, and this. And then maybe the system tells you, oh, you know, there's, like, 20 microns that fulfill your requirements here.

Chris Gammell: See, now that starts to get into, like, the... I always bristle so much. When all... People approach the amp hour and, you know, me and Dave and everyone else, they're just like, I will design the entire system for you. I'm not saying you're trying to do this, but it's like, we have this new AI tool and we'll figure stuff out. And we can design an Arduino from our AI tool. And I'm like, that's not useful. Like, the stuff you're talking about, useful. But, like, the, man, I get, I feel like a lot of the tools that are coming into the space right now are solving trivial problems. The stuff you're describing, some of that is non-trivial problems. And so, good. Thank you.

Michael Gieldo: Yeah, I mean, I think that's because we're always working with real projects, right? We're always having customers building pretty complicated stuff. We're doing some really nice, like, augmented reality projects right now or robotics, you know. They come with, like, a special set of problems that aren't Arduino level. And we're not, like, VC funded where we have to, like, show proof of concepts all the time for someone to be happy. I mean, we like showing proof of concepts because they're a good way to gather feedback. But, like, we're not forced to. And what we're really trying to solve is our own problem, right? Renode was created to solve our own problem. And so is system designers. Like, how do you navigate? So we recently came up with this funny feature where we just want to show all the SOCs being used across all of our customer cases. And this is already immense value. Like, this is very trivial to do because you just, I mean, we codified. So we use system designer internally, an internal instance to codify the projects that we work on, right? And those projects, you typically, like, say, you know, I have this board with this SOC on it. And I'm running this kind of binary on it, et cetera. So you have, like, hardware, software components. You're trying to match them. You're trying to build, like, a complete hardware, software bomb of your system. But, like, even the ability to just show, like, here's the amount of different microcontrollers and application processors we've been using in all of those projects. You sometimes realize, oh, my God, yeah, I didn't remember we did that, right? Like, human brain is really weird where after a while you just forget basic facts. And if you don't have a good system that keeps track of all this and you can just go back in history. So maybe if you go to explore and you take a look at, there's, like, the Axiom camera there. I might have mentioned it in the past. If you go explore Axiom Gamma for camera. Like, you can blow it up with the switch view button. It just explodes into a number of boards. And this is, like, the complexity of stuff that we've built in the past. And you just, after a while, just forget, like, what was the sensor used there? Like, was there, like, a Xilix Ultra Scale Board? Or maybe it was a Zinc? Or, you know, did we use a TK1 or a TX1? Like, and here you have all of this codified. And so you can kind of go back in time and revisit your past solutions and say, oh, that was actually a nice concept there. Let's maybe reuse this. And it's also a funny way to preserve. Like, you might be a fan of these kind of things where, you know, you kind of were excited about some devices that came up in the past. Like, were released into the market. And 10 years later, you can't even, like, buy them anymore. Right? So, and if you wanted to see what's inside, you can't because you can't see them. And nobody had bothered to document them like those 10 years ago. So we're not, of course, like, claiming that we're going to be, like, you know, the way back machine of all hardware. But you could use that in this capacity where, like, for example, documenting the Axiom project. This is in the past for us. This is many years ago. But it was still a useful exercise to do that. Yeah.

Chris Gammell: This seems like this one's a little bit more complex. Like, this is, I feel like one of the push pulls on this is going to be, like, I don't have time to document at this level. Right? This is, so, like, I'm sure what you'll say is, like, well, if you're starting from the beginning with it, then you, you know, you build it up over time. And you really start to see that sort of benefit. I can see some other benefits, though. So, like, going back to that, like, UART and, like, peripherals and things like that, that is a straight-ahead benefit for the smallest of boards that I could see. Does the system designer deal with the kind of the multi-assignment problem on chips? So, like, I have, so, like, for example, I use the NRF9160 a lot. That's a cellular module from Nordic. And it's great. And it talks about how it's got all these different peripherals, which I'm sure, actually, I should go to that chip here in a second. I'll go to that chip. But one of the problems is that you can only use four. So, like, you have all of these flexible SPI I2C UART, you know, blocks that are in there. But you only get four total. And so, like, there's that problem that, like, the firmware only allows it because there's only so many flexible blocks. And then there's also, like, the kind of multi-pin assignment problem where, you know, I might be using UART1 and I want to use I2C2, but I2C2 uses the same pins as UART1. So, like, how does that get kind of handled?

Michael Gieldo: That is actually a very good question because Analog Devices has been working on this. They have, like, a VS Code extension specifically for, like, pin maxing and these kind of, you know, problems. There's other vendors also looking at, you know, trying to solve this well. And we're kind of looking to, you know, create generic ways to do this. We don't have that featured in the designer itself yet, but I think this is kind of a necessary thing to solve. Yeah. So, at this point, no. Yeah, super useful, right? Because then it's, like... We're definitely looking at it, yeah. And there are, like, the stuff that Analog has done is actually open source. So, they've been really great in, you know, just going all in on, like, open source, which is good. Because, like, as long as it's, like, a single vendor standard, you know, the problem is that you'd have to support, like, 20 ways to describe it. And it's just not feasible to maintain this kind of thing. Whereas, if it's an open standard, you maybe can afford to figure out, like, a way to just share. Because it's just, you know, a thing you have to do. It's not secret sauce, really, right? It's kind of a frustrating thing that, oh, everyone always doesn't like dealing with, but has to. So, it would be great if we could just solve it for everyone, right?

Chris Gammell: Yeah, that would be good. I think another thing would be interesting for me is, again, like, thinking about this kind of tool. Having this, man, the number of times that a vendor would walk in and be like, yeah, I can sell you this great new chip. And it solves all your problems, needs. And, you know, you're using STM32. And I'm selling this free scale chip, rest in peace, free scale, or whatever it is, right? And then, you know, like, and then what they're saying to you, though, is, as the engineer is like, hey, engineer, I would like to waste your time. So, that you go and look if this is a possibility. And the engineer just says, no, I'm not doing that. Like, we kind of talked about this at the beginning. Like, why people don't switch chips in the first place. But if it was literally like the, if the salesperson walked in and they were very savvy and they had access to system designer. And for some reason, you signed an NDA with them as a customer. And you said, hey, take a look at this system design. See if your chips fit in. Give me a better price. Like, that would actually be a really interesting, like, use case as well, where now, like, I, as the engineer, I benefit from basically like a marketplace system. I benefit from Zephyr and seeing that, yes, actually, the code will be ported over to this new system. I see that, actually, yes, this new chipset that, you know, the vendor is pushing me on will cover all my use cases. And maybe even to the point of, like you were saying with all these simulations, they even went and ran it for me. Like, they ran some, like, test code on it. And, like, yeah, it's no problem. Like, that would be the ultimate, like, use case in my mind, where it's, like, truly making my life easier as a heart branch.

Michael Gieldo: Yeah, no, I mean, this is a great idea, of course. And this is, of course, out in the future still, right? Of course. Yeah, yeah, yeah.

Chris Gammell: I don't expect it to be, but I'm just dreaming this up as we're talking about it, right? But, like, these are the use cases.

Michael Gieldo: We kind of want to get to a point where whoever's more open and has better silicon wins, right? Like, it's as simple as that. And artificial barriers where people just try to wall people off and make their stuff, like, as, you know, weird and niche as possible just doesn't work anymore. And especially with the complexity of the current systems, like, they're getting, you know, bigger and you need, like, more skills to even program an MCU because maybe there's, like, you know, three cores of different architectures. And, you know, there's an N accelerator in it. And suddenly you're, like, struggling with a lot of things at the same time. And obviously, like, everyone's thinking about ways in which this could be simplified, but the worst possible result is everyone comes up with their own way to do it. And then, you know, you're still stuck with, okay, as long as I stick with, like, one vendor, maybe I'm fine. But, you know, I don't think that's a good reality. And historically, we've still been, you know, reusing solutions as much as we could. Nobody wants to really, like, jump around and switch microcontrollers all the time. But you do want to be able to just make a pick and just look at the features of the silicon, the price point maybe. But more importantly, just, like, the ease of use. And the ease of use, I think, should be measured in how much open source software is available for this MCU, right? That's my measure of ease of use. If there's Zephyr, if there's Reno, this, this, this, this, I'm like, I know I'm going to manage to run my stuff on this versus please download XYZ Studio and, like, sign three NDAs to get this binary. It's like, okay, I don't have time for this. Yeah.

Chris Gammell: Yeah. Well, I mean, I, I think there's some, I, I'm much closer to the side you're talking about with, you know, like, at least open source in that case is the ultimate backstop of, like, okay, I can get at the code. If I need to, I can always go and hire Michael and his team to, like, help me as well. That sort of thing is, is really important there, too. Uh, I feel like vendor support is another, like, kind of X factor that, again, as a hardware engineer in the past, it was always like, well, you know, yeah, we might pay another 20 cents for vendor A over vendor B, but their support team's amazing. And, like, literally then, but, like, the swap ability that we're talking about here, if you could, if you could say that and just removes that from the, from the scenario, like, okay, now we can just swap over to the whoever, whichever vendor is supporting us most. Right. We, our tooling runs across multi-vendor and if vendor A is going to help us more, we talk to them more, we give them more business. And it's like this dynamic, it's almost like a pricing power kind of thing where, yeah, maybe you're getting them on price, but you're also able to, like, shift business to them. And say, more of your chips will make it onto our boards, the better supported we are with manufacturing, with support, all that sort of thing, too.

Michael Gieldo: And by the way, these things are related, right? So, um, if you're a vendor and you're really providing good support to people and, uh, typically you're also more open because it's easier to, you know, support people well if things are just available and online and you're not spending your time just ship, sending people binaries over email. Right. Yeah. You're, you're writing good documentation. Maybe you're, you know, organizing webinars to explain things. You're, uh, still it's a lot of work to support customers if you're a Silicon company, but I think it gets infinitely easier if you're just more open. And, uh, so I think these things go kind of hand in hand a little bit. I mean, I could imagine, of course, a good, uh, you know, a vendor that provides open source data, but like zero support. That's fine. Like it would be a very interesting model too. Um, but I think typically what will happen is that, you know, the vendor will provide both like more open source collateral and better support just because, you know, even his own team is like, it's more productive. Right. They, they're like, they can navigate all of those things, uh, easily. And point to links. Like, you know, you can send someone a link. Right. And here's the thing you don't have to like say, please log in with your credentials. I remember we were buying some proprietary tool and like the amount of time we spent just like getting a license and trying to log in to places. And it's just ridiculous.

Chris Gammell: Is there anything more like defeating as an engineer to be like, you, you know, like, okay, I'm going to go sign up for this new tool. All right. It's proprietary. I'm fine. I'll get it, whatever. And you put in your information, you think you're getting a sign up and then it's like, thank you. We will get back to you in 48 to 72 hours. What? What? No, that is not how this is supposed to work. Yeah.

Michael Gieldo: Yeah. Of course. I wish everything was.

Chris Gammell: Shake your hand and say hello to you and make sure they get their commission.

Michael Gieldo: Yeah. I think that's, yeah, that's maybe one of the problems is there are things that you can just easily buy. And of course, a lot of the new SaaS wave companies and so on, they have a very different approach. Like you want to buy something and just click a button. It's there. So, so it's definitely, there is a good way to sell things that are proprietary. And, you know, come with like a good user experience and everyone's happy. So I definitely don't want to be like saying it has to be free. Otherwise, you know, go away. We ourselves, you know, charge people for services. So it's not that proprietary stuff is bad or charging money is bad. It's just like very often, unfortunately, experience is horrible on many fronts. You both pay for it, but also, as you said, you get like mistreated kind of. Yeah.

Chris Gammell: And yeah, it's like, oh, you're big, but you're not big enough to get all of our attention. So take the scraps you get, peon. Chris is at a small company right now.

Michael Gieldo: So, but in any case, we're trying to fix at least some of these problems. We're definitely not going to be able to fix everything. But the good thing is we're working with, you know, for example, right now, this demo with analog devices, right? Yeah, yeah, yeah. They've been really nice.

Chris Gammell: You were helping on the VS Code stuff as well? Because I had talked to Kevin. Oh, I forget Kevin's last name. Sorry. At analog. Kevin Townsend, I suppose. Townsend, yeah. And yeah, so I know he's doing a lot of the Zephyr stuff there. I tried out their tools. It's interesting. Oh, yeah.

Michael Gieldo: That is their great work. No, no, no. The initial set of plugins is absolutely them. But we're working on the AutoML plugin with them right now. And of course, they're basically doing things that we probably would have done just like they did to them, right? Like I saw the plugins they released last year, and I was really excited. It's good stuff, right? Well designed, you know, nice to look at, nice to use. So we're kind of following the playbook. And the AutoML plugin will be, you know, part of that family. Got it.

Chris Gammell: Yeah, I feel like having the, it has been a big unlock for a lot of the Zephyr tooling. You know, like when we, when Zephyr, yeah, when Zephyr was kind of getting started, not started, but like when I started with Zephyr at Goliath, at least, it was like a lot of command line only. And now there's just been more and more VS Code plugins. It just kind of brings, kind of like broadens the base, opens the tent a little bit more and makes it kind of more, it's not a pure IDE, right? It's not like a Eclipse IDE that gets delivered to you again as like a .exe that goes in on Windows, which some people expect. But I think it's, it's kind of a good middle ground that, that makes it a little more accessible.

Michael Gieldo: Yep. No, absolutely. I'm excited for Zephyr. Zephyr. And pretty much everyone is at least asking about Zephyr. Not everyone's using it yet, but it's definitely out there. And at some point, it'll just like the economies of scale just, just happen. And you have to use Zephyr because other people require it and, you know, you have kind of no choice almost.

Chris Gammell: Yeah, I think a lot of the vendors kind of following each other as well has been beneficial for, again, as hardware engineer. It's like, I get to see that they all want to put more support in and I'm happy to see it. And kind of more options that I can switch between is better for me. Kind of opens up.

Michael Gieldo: And sometimes we help them too, right? Like there's been vendors whom we've kind of brought on to Zephyr. And of course, like ultimately you want them to also build up the capacity internally. But, you know, sometimes you need a little push and that's what we're here for as well. That's great. Yeah.

Chris Gammell: We did not talk about your chip stuff. You've been doing Chips Alliance stuff. You've, I think the first time you came on, you were talking about Chips Alliance. Very quickly, what is kind of going on in the Chips Alliance world?

Michael Gieldo: Oh, lots of things. So maybe one major thing is Calyptra, a root of trust that's been kind of, that's joined Chips Alliance as a project. And that project involves some big guys like Google, Microsoft, AMD, and NVIDIA. And we've been helping them to, you know, first of all, just kind of maintain and develop the core, the RISC-V CPU core in that system. That's kind of at the core of the system, let's say. And then also some other, you know, peripheral IO as well as just like verification and some integration. So generally speaking, Calyptra is this root of trust project that multiple parties have aligned on. And, you know, they want to continue developing it so that ultimately everyone can adopt it for their chips that they're going to sell to them in the data center. And those chips will have like unified security. They will have, you know, the same RTL in there, the same software, making sure that, you know, the supply chain stays, you know, uncompromised, that everything's as advertised. So Calyptra is really, really a huge endeavor in trying to increase the security of servers, prevent like, you know, malicious actors and so on. And I think it's very important in these times. And like supply chain security in general is something that we look at from multiple perspectives also with the system designer, right? So I'm very happy that Calyptra is there. And I'm happy to be involved as well because it's a multi-party project where you have to collaborate. Like you're forced to collaborate, even though maybe in some other fields, those companies are rivals, right? But for security, they just have to figure out a way to make it uniform because you're not going to have 100 suppliers, you know, develop 100 different security solutions to be tested across like a number of cloud solution providers. You know, like the complexity explodes. You have to like unify, you have to standardize. And that's what Chips Alliance is about. It's like you find a common goal in the hardware space because in software, it's much more well-known as a problem and much more widespread to, yeah, we're going to build an open source project to solve everyone's problem. In hardware, it's a little bit less common. Of course, there are standards, right? But very few open implementations of standards. And that's what Chips Alliance is trying to change is that you don't only get a standard and now go implement your own version of it. And then everything's different anyway, or you have to like really carefully certify everything. But instead, it's like here's a standard, but also here's an implementation. Just go and use this implementation and we're going to like pull resources to develop this implementation together. Maybe with some, you know, different ways to modify it here and there. But like generally speaking, you know, 99% of what you're doing is exactly the same. So we can vouch for security. We can even like do a formal certification process, which, you know, you can just piggyback on, right? That's what Calypter is about. Okay.

Chris Gammell: Yeah, it's interesting. Yeah, we had a guest, Laura, on the show talking about, it was the first time I'd ever heard of Rude Trust stuff. So, you know, I'm not in the server world, but it did seem like the, how are you sure that the server you're talking to is the server you think it is? That is kind of always the, that feels like that's the core of things. And so it seems like the Calypter project is kind of helping move towards that, like again, across multiple vendors. And so that everybody kind of has a common language for understanding which server they're talking to at the time.

Michael Gieldo: Yeah. And as a last kind of comment here is that because everyone's kind of forced to collaborate here, you can also think about unifying workflows and building open source tools that help you be more efficient across companies. Not just inside a single company. We can just, we can afford, because a single company can always afford to just like, you know, purchase one stack from someone and sign all the relevant NDAs and just get going, right? But maybe company two does the same thing, except they're using a different vendor, right? And company three is using a mix. And then like, it's really hard to collaborate versus like thinking about how to build this into a scalable infrastructure where some of the tools are maybe open source and some of the tools are maybe more standardized so that you can, you know, more easily just make people exchange artifacts and talk about things without having to, you know, fully copy another company's setup top to bottom, right? Which might just be even impossible. So yeah, it's a fun challenge to have. And we're happy to be solving this. And there's a lot of good little open source projects that are kind of coming out of it because we kind of have to solve real problems.

Chris Gammell: Yeah, that's great. Well, Michael, where can people find out more about you, Ant Micro, Chips Alliance, stuff like that?

Michael Gieldo: Yeah, so we've actually built a new site called offering.antmicro.com. And this offering is like an interactive website with, you know, different parts of our work. So like hardware, software, AI, cloud, Renode, of course, and FPG and ASIC stuff. And if you go there, you'll see like a bunch of interactive slides with some cool graphics that, you know, you can kind of click around and make things happen to illustrate different, you know, problems that we're solving. So there's going to be a slide for Calyptra. There's going to be a slide for our work with Verlator, for example. There's going to be slide for many slides for Renode, actually, some slides for Kenning. So you'll be able to get a feeling for what do these things actually do. And the cool thing is because they're open source, most of the time you'll just get a link. And like, here's the GitHub repo, right? Or here's the log note that describes how to run it on your computer. That I think is the nicest part is that, yeah, it's kind of a sales pitch, but it's also like a repository of good technologies you can try out for yourself. This looks like index.js on here, huh?

Chris Gammell: The slide software, something like it. Sorry? The slide software that looks like the slide software is index.js, or no? I've used that for presentation.

Michael Gieldo: Yeah, I think the origin is based on reveal. Oh, cool.

Chris Gammell: Oh, reveal. Oh, maybe that's what it is. Yeah.

Michael Gieldo: Yep.

Chris Gammell: Okay, cool. Well, that's great. Yeah, this is a lot. You have a good eye for this, yeah. A lot of stuff in here. Wow, this is really cool. Okay, well, definitely offering.antmicro.com. Find Michael online, lots of different places. And yeah, thanks for being back. I'm sure we'll have you on a fourth time to talk about all the new things during the meantime. So thanks for being here, Michael.

Michael Gieldo: Thank you so much for having me. Have a good day. Cheers. Cheers.

Speaker ?: ! Bye.