#519 – Simulating Embedded Hardware with Michael Gielda

Chris Gammell: A quick note before we start, I selected the wrong microphone, and so my audio sounds like crap. Our guest sounds great. He's talking about some really interesting stuff, so I hope you stick with it. I promise to do better in the future, and my apologies. This is The Amp Hour Podcast, released November 29th, 2020. Episode 519, Simulating Embedded Hardware with Michael Gielda. Welcome to The Amp Hour. I'm Chris Gammell of Contextual Electronics.

Michael Gielda: Hi, I'm Michael Gielda. I'm VP Business Development of Antmicro, and I'm also Chair of Marketing of Chips Alliance, as well as Vice Chair of Marketing of RISC-V International.

Chris Gammell: So that's a couple of things there, Michael. Michael, you've got your work cut out for you.

Michael Gielda: Yes, although I must say all these things are related. It's very easy to wear those hats, because if you believe in the mission of the orgs you represent and their conversion, then you're kind of doing several things at the same time, but it's not a problem.

Chris Gammell: Yeah, and I think I started hearing about Antmicro when I started hearing about RISC-V, and then, of course, I heard it from Tim Ansell over and over and over again, because he speaks very, very highly of you, and he introduced us, and I appreciate that from Tim. So could you tell us, what is the connection between Antmicro and RISC-V?

Michael Gielda: Yeah, the connection runs many years. Actually, you know, we're one of the original founding members of the organization. It all leads back to a workshop at CERN, where we went and met the original RISC-V guys, you know, the people from Berkeley and Sci-5. And since we... It actually dates back to probably 2010, when we started dabbling in open hardware in general. We were early adopters of OpenRisk, probably one of the few companies that actually kind of did some business with OpenRisk, the niche thing that it was. And we always believed that hardware has to go along the same route of software, you know, just being open source, being more collaborative. So we had been early adopters of these kind of open hardware-related things, but for a long while, it felt very lonely, right? You couldn't really get any serious business going.

Chris Gammell: Right. Hey, guys, how about we all build our own chips? What if we just all go to the fabs and build a completely open ISA? Hey, that would be great. And crickets.

Michael Gielda: It sounded fairly crazy pre-2014, 15. Yeah, exactly. It sounded like you were the only person that wanted that. So it all changed there at CERN. And somewhere around the middle of this decade, RISC-V was formed, and we got on board extremely early alongside Google and a couple of others. And since then, it's just been a constant story of working with open hardware. It's not to say that we only work with RISC-V, right? Actually, we're also a member of OpenPower, right? But which kind of is also really great to have been open sourced last year as an ISA. But we also do, you know, ARM development. We kind of, we're very agnostic to technology. It's just that we have obviously a strict preference for open source. And here is the convergence point of RISC-V, which is an open ISA. And it also kind of brings together an entire community of people that care about this kind of thing.

Chris Gammell: Right, right. Okay. So you guys work with a lot of chipsets and people listening now are like, okay, but what do they do? And so can you tell us about Renode and then kind of how Ant Micro kind of fits into that whole ecosystem then? Sure.

Michael Gielda: So Renode is one of the tools that we build because we believe when you do something, you also have to think about the workflows, about the tools. How are you doing things? Whether you're just copy pasting what other people did or you're kind of inventing new ways. So on the ground level, we are actually a service organization. We build things for people that need them. But having said that, we just don't do anything. We will provide engineering services that are based on open source and preferably they are open source engineering services. So whatever we do gets open sourced. Renode is a tool that we build for ourselves. So even though we do services, we have a lot of R&D internally as well that kind of feeds that kind of service organization. And Renode is one of the earliest tools we've built. It's been around since 2010 in some form. It's a simulator, of course, open source that allows you to just build embedded systems faster. Since a lot of our work is in embedded systems or as some other people call it, edge AI systems. Renode helps you to kind of build out those systems quicker because it allows you to simulate them without the hardware, which just makes you able to work on your computer and possibly put this development in a CI context, you know, on a server. And then you can also use the software, execute tests, gather metrics without touching hardware.

Chris Gammell: Yeah, this is this seems like it seems like if I had to simulate or if I had to assimilate what or that's not even the right word either. But basically, if I had to say what AntMicro does is basically you guys are the pure distillation of software coming to hardware. It feels like because a lot of the things you're saying there, like CI, which is continuous integration and all these simulations. I mean, it's just it really allows you to bring software methodologies into the hardware world. Whereas, you know, there was pieces there before. There's always been scripting and similar things in there, but not maybe at the same level and the same confidence level that people would build entire systems and simulate entire systems and work all the way through to an end goal. Is that a fair assumption?

Michael Gielda: Absolutely. I mean, I think you summarized it really, really well. We always say we're a software oriented company that's working with hardware. So even when we build hardware, we always try to make sure that we do it in a software way. Our engineers that are like nominally, you know, hardware slash electrical engineers, they also have to know how to program. We kind of try to think how we can avoid all those proprietary and uncollaborative ways of building things and instead transition to us crypt oriented and CI driven flows as we can. There's a lot of difficulties in doing so, but it's a worthwhile thing to try to think about these difficulties and how they can be worked around.

Chris Gammell: Right. And so when someone is using Renode and they're like, you know, the page talks about like assembling a system. Is it basically like you're building the actual chipset and all the peripherals on board? So like say I have like an STM32F403 or something like that. I only care about certain peripherals on that. So I care about the core, the Cortex-M4. I care about the SPI peripheral, something like that. And am I piecing that together? Or like what is the actual implementation then when people are building up these simulations for their use cases?

Michael Gielda: So how Renode works is it observes the world which is built from blocks. Like every IP vendor, every, you know, kind of silicon manufacturer actually and board manufacturer, right? They'll take some components that pre-exist. Very rarely will they actually build something from scratch. They'll take some components, put them together, and that's what you see in the end. That's what you program against, that's what you build. A board like the STM32F4 or something will have obviously the STM chip on it, but it'll also have a bunch of peripherals externally, potentially some sensors and IO and so on. Even inside the chip, it's still a modular design. So like the entire portfolio of STMs, microcontrollers, they will have families that share quite a lot of, you know, internal building blocks in perhaps in different configurations. If you observe how these things are built from, you know, abstraction levels of complexity, but on all of those levels you have clear building blocks, you start to realize that a lot of the work is not just in like implementing what's needed, but also putting together those abstractions in a clever way to save yourself redundancy and work that's not really needed. So how reNode works is it tries to capture that kind of those abstractions in interfaces and classes and models that can be reused and reconfigured. So if you want to build like a virtual STM32 board, practically you put together a bunch of things in a config file instead of like writing code. And I think that's a very important psychological change as well. So like it has implications that go very deep because theoretically, of course, you could write all of these things in code and compile them. It would work. But at the end of the day, if you're really after just like modeling a system and running your software, you don't really want to be compiling your simulator, right? You want to get your simulator and just use it as a tool. So it's a tool that clearly separates the development perspective of it, of the tool itself, with the user perspective. And the user, of course, probably is a technical person, but they don't necessarily need to understand how reNode works internally to use it.

Chris Gammell: Yeah, I feel like, especially coming in from the hardware side, I'd love to have like a, you know, from a confidence perspective as well. Like along, you know, as long as these different blocks have been vetted and, you know, there's confidence in the system, which I'm sure there is, you know, I'd love to be able to just, you know, pull in and just say, hey, here's a spy block. Here's an external sensor. Here's the core. I don't want to, I'm probably will just forego the entire process because of that complexity. And this seems like it kind of fast forwards and allows people to access it easier as well.

Michael Gielda: Yeah, absolutely. I mean, we have right now cases where like one of the local universities is using reNode for, you know, kind of just classes, right? And we're also kind of building a module for an edX course that's already has, you know, 6,000 people signed up where you want to put reNode in front of them and have them develop for reNode. And you don't want them to have the feeling of, oh, this is harder than my dev board, right? You want the opposite. You want them to be like, this is exactly the kind of software oriented experience that I know from other types of development, right? Like if people are into web design or they're into developing some kind of command line software and something, it's just so easy to get started. You grab a project from GitHub and you can start hacking in five minutes. With hardware, it's like you order your board, you open up like some, you know, a manual.

Chris Gammell: Install the tool chain.

Michael Gielda: Yeah, hook it all up, download tool chains, so many things. We can't avoid everything. Like you still need the tool chain to compile a binary, right?

Chris Gammell: Yeah, right, right, right.

Michael Gielda: But like, well, okay, actually we have demos. We have pre-compiled binary demos that we also ship because we just saw if your first five minutes experience is, oh, just go compile your own binary and then you can run reNode. A lot of people get discouraged. But if you tell them, look, here's a pre-compiled thing, you can run it in three minutes.

Chris Gammell: Yeah, start with this, get the dopamine flowing, and then eventually you'll come back and try it again with your own customization. Yep. Yeah, and that's really great from the, it's interesting you mentioned the educational aspect too, because one thing in COVID era of like, you know, people being a lot more remote, and you're really just generally thinking about remote, maybe even outside of education. The ability to access what you think is hardware, right, or what looks like, you know, a set of IO or looks like a set of registers, from the software perspective, it's not that big a difference. But it can have a lot of logistical implications, right? So if you're running a class of 6,000, like you mentioned, now you don't have to ship out 6,000 bores. You have to worry about shortages, which is another problem that's happening in the supply chain right now. It's just like, you just ship bits instead of atoms, and that's really great for making things more widely available.

Michael Gielda: Yeah, absolutely. I mean, look at what Docker did for development, for example. We've been called the Docker of Embedded, which I like. It's not precise, right? But it's kind of a cool, catchy phrase.

Chris Gammell: Yeah, and I feel like that's a, the software people love it too. So it's like, you know, like, yeah. Can you explain what Docker is for the hardware folks out there that don't know what it is?

Michael Gielda: I probably think most people do. But yeah, Docker is a containerization framework that just allows you to run software anywhere because you package it up into a container that runs on top of your operating system, but it's an isolated thing. It's both isolated. That's the one good thing. And it's also kind of reproducible top to bottom, right? So kind of you're not worried that whatever you're running, another person's going to be running the same thing, but getting something a little bit wrong. Kind of what you have with dev boards and so on connecting your wire differently.

Chris Gammell: Yeah, I kind of think about like a virtual box or something like that as well, right? So like a shrunk down version of virtual box without running an entire OS. You're running just the portions that you need inside this thing. And then you have the inputs, outputs, so you might be able to access like a IP, like the Ethernet element of it and be able to push packets in and out of it. But yeah, it's like a much, much shrunk down version of a whole system. Yeah.

Michael Gielda: So getting back to the logistics, I mean, what containers did for many domains of human activity was to just simplify collaboration and reproducibility and scalability of things, right? That's really an inflection point where things started scaling very rapidly and people started doing things like continuous integration, partly because it's not that continuous integration wasn't possible before, but it's just gotten so easy with containers and things like this. So I guess it's the same with simulation. It's not that these concepts are new. It's more like once they get past a certain point where things are just easy to do, more and more people start to do it. So the logistics aspect is, I think, actually one of the most important ones. It's not about, you know, we have engineers that come to us and say, oh, I've been doing simulation for a few years, so how's your thing better? And we're like, well, if you have been doing simulation for years, that's great. You're probably going to find Renaud very useful, but it's not that this will necessarily change your life. It's going to change the life of the people that didn't use simulation before. We're trying to make it easy enough for them to transition from like zero to one. And we see that the group of people that are effectively using simulation and day-to-day development is very, very small as compared to, you know, everyone should be doing it, right? There is no reason why you shouldn't try to put your development into a computer, because if you put it in a computer, it starts being scalable. It starts being reproducible. You can just, you know, if Renaud, you can just take a snapshot of your work and just send it to a colleague and they're going to run it. And they're going to have like binary, the same thing that you're running without any possibility of difference. Whereas, of course, if you try to do the same with like a physical set of hardware on your desk, you're going to get something wrong anyway. And besides the time it takes to ship someone an actual, you know, hardware kit or a set of hardware kits, it's just, it doesn't happen. In reality, we always say testing in embedded systems, like in most places, it doesn't really exist. Like people avoid testing if they can.

Chris Gammell: Well, because then it's all, it's all field testing at that point, right? It's, it's all, it has to be in the physical realm usually. And then there's a ton of overhead that's associated with that.

Michael Gielda: You shift testing to your users. That's what people do. Yeah. And we know that because we have customers, right? Like we have customers that come to us to build very serious, you know, industrial embedded products, right? And most of the time testing is not really on their mind. We have to like remind them of the fact that, Hey guys, testing is a great idea.

Chris Gammell: Yeah. Okay. So I am one that does not test at least in the, so I have this new project that I've been working on that I talked about, that I talk about a lot. It's like a, so it's got a NRF 52 on it and it's got a cell modem. It's got a bunch of peripherals and stuff like that. Is that something that would be a good use case that we could kind of use as an example here?

Michael Gielda: Absolutely. I mean, we're actually adding a NRF based platform right now for both for like Google's TensorFlow Lite team that we're working with and kind of reworking their CI to be automated with Renaud.

Chris Gammell: Got it.

Michael Gielda: And also the Harvard course, that's actually the platform they're using. So it's a great example.

Chris Gammell: Okay. So, so right now here's actually a good example. So I have a firmware developer. He logs into from far away. He logs into a laptop that's sitting on my bench. The laptop sitting on my bench is using a, a J link to program a, the board. It's got a serial terminal coming off of it that goes back into USB to serial to that laptop so that he can quote unquote, see everything. There's USB. There's a, a webcam that was very, very proud of setting up this whole thing. But it sounds like all this stuff would be kind of obviated by the idea that like, if it's just sitting as a known simulation target, he could not do that anymore. Is that, is that right?

Michael Gielda: Exactly. Yeah. And, and you know what, if he actually did this, that's exactly what I'm talking about. When I say we have people coming over and saying, Oh, I already like set up this extremely complicated mechanical rig that can test things.

Chris Gammell: Right. Yeah.

Michael Gielda: Physical realm. Right. I mean, like, great. Like, it's very good. You did this because like, if you don't have simulation, you should do that. You should test your things. And once you do that, your incentive to do simulation kind of decreases a little bit. I, I, I, I still think that people should do simulation, but like, I'm talking about the people that didn't have the opportunity to set up this hundred unit, you know, rig in their server room. And with COVID and with distribution of work that you have to do suddenly, like even accessing this kind of infrastructure, even if you have it right. It becomes so difficult sometimes that people turn to us and say, okay, I've tried physical, but like, we need to see.

Chris Gammell: Like, I can give you, I can give you a great example. It's yesterday. Bilal was like, Hey, can you check and see if the spy signals are actually firing on this board? And it's like, okay, so now I have to like check that. And I'm happy to do that, of course, but he has to, he's then dependent on the remote person being near the hardware. And if you have a hundred units set up in your server room, you either have to somehow tell that the LEDs are blinking or that the signals are going properly, whatever. Whereas I imagine it's simulation. You just see the signals going or not.

Michael Gielda: Yep. It's exactly. The physical realm is very indirect, right? So you only see that something's happening because you're looking at the LED blink. Now, whether the LED's actually blinking when the things happen, how do you know, right? Like, sure, you're relying on your software being correct, but perhaps it isn't. That's what you're testing. So the thing you're testing is kind of influencing your testing procedure itself and things get hard.

Chris Gammell: Yeah. So, so how would then, okay. So then we're going to replace this janky hardware setup I have, and we're going to create a simulation of the board. How then, so, you know, Balal's right in firmware. He's making a binary that he is then loading onto this physical hardware. What does it look like then when it gets loaded into a simulation in this case? Like what is the actual, what are the mechanics of doing that sort of thing?

Michael Gielda: I mean, you just have to turn on Redo. Do you have to instantiate the platform? Which assuming that there is a script that describes that platform, it's a one line command. And of course, inside that script, there's a bunch of things because we're, you know, setting up this, this platform and potentially doing a bunch of things. But after that, you just load the binary and you start. Okay. So it's three lines of scripting that gets you there.

Chris Gammell: That's a lot of work, man. Oh, geez. Versus like having a webcam. I mean, it's so easy. Okay. Okay. So you load it in though. And then what is the actual, like, what do you, what do you see? Is there like visualization? Is there like plotting? Like what, or is it all kind of configurable in that you can kind of quote unquote, see whatever you want there.

Michael Gielda: Excellent question. So basically we try to, to integrate with external tools for doing things that those tools do well, right? Like, I mean, we're always tempted to create our own tools for everything. We're engineers after all, but in reality, of course, you don't really want to redo the work of many brilliant people. It's not that we necessarily need to reinvent the wheel. In many places, the analyzers, as we call them, already exist. A good example is Wireshark where, yeah, we could write our own packet analyzer that analyzes, you know, IP packets and so on. But actually people have already done that, right? What you need to do is hook up to those tools and provide them with the data that they need. And so we have one specific thing that we wrote that we think is very useful and we just didn't see another way of having it easily, which is, you know, given the fact that we're a simulator, we can actually produce trace data. So the execution of a specific binary, right? If you just let it run. What's going to happen is instruction is going to get translated and executed. And then it's going to access some memory addresses and peripherals and stuff like that, right? This is great data that you can actually get from Renaud interactively. Of course, you can always just, you can stop and read that data. You don't even have to stop, right? You can read that data online while things are running. But like one thing we did recently, and that's the Renaud 1.11 release includes what we call metrics analysis, which is we can extract this data from the runtime. And then we take that trace. We can put it in whatever, like we can analyze in a Jupyter notebook if you want, right? And produce graphs of like executed instructions and what cores are working at various times of the execution. So you could, of course, see that perhaps your cores are not really under very heavy load. You're thinking that you have a multi-core code until you actually look at whether the code is multi-core. And I mean, these things are not completely unfeasible of hardware because there are like tracing units inside cores and stuff like that. But in Renaud, you don't actually have to code anything or include any kind of instrumentation in your code because it's the simulator that's pretending to be your hardware, right? And since we're pretending to be the hardware, we have all the information about what the software is trying to do to the hardware. We can essentially store this trace information as abundantly as we want.

Chris Gammell: Right, yeah. No memory limits. I mean, or really the limits of the system, which is much more massive than an embedded system might have or even maybe an external probe might have.

Michael Gielda: Yeah, so I mean, Renaud is a CLI-based tool mostly that has a very good API. And then, you know, we are, of course, working on a lot of different crazy ideas. And, for example, this relationship with Google, the thing that we're building in terms of TensorFlow Lite and metrics stuff and generally measuring how well ML code executes on small embedded platforms. I think this will generate a lot of dedicated tooling as well, right? But in areas where the tooling exists, like network analysis, it just doesn't make sense to try to do it yourself. You just have to figure out the formats that people use and then you just generate the data in a format that can be then analyzed with further tools.

Chris Gammell: Okay. So then you mentioned that you can also have, you can also simulate like external sensors. So I'm going to give an example of a sensor that I have. So I have like a LIS-D2 sensor. It's like an accelerometer on board, right? That's one of the sensors I have. What does that look like when that's actually configured in the system as well? Or is that configured in the system? What does it take to push something like that into a system like this?

Michael Gielda: We have a bunch of accelerometers modeled. So basically just added to a config file. We have what is called a REPL files, the Renate platform files, hence REPL. And because we have REPL, RESC, and, you know, the RE prefix and then the actual name, the format. So in the REPL file, you'll find probably a sensor hooked up somewhere. Or if you want to hook it up, you just add it. You can also add it online. Of course, you can always add it from the CLI in runtime as well. But like, of course, normally you'll do it in a script. And then if you have the accelerometer hooked up to your whatever it is, I2C, whatever is the interface of that sensor, then you'll just have a virtual accelerometer to which you can potentially, for example, feed data from a file, right? And that's, again, a command, like feed data from file. You give a file name, and then those data points will just be fed into Renate. And, you know, the software will assume that that's the readout they're getting, right?

Chris Gammell: Right. Yeah. Yeah, I guess that's the thing that I'm wondering about is, okay, so now thinking about moving things towards testing and what you want to actually test on a test stand. So, you know, you might want to push in. So to move outside my example, but you might say you're making like a, I don't know, like a quadcopter controller or something like that. You might, for some reason, want to actually test some function of the, maybe you're having motor controllers that you want to drive in certain ways, but you want to simulate the accelerometer that is causing that motor controller to do this thing in response. You would need some way to actually stimulate the system so that you can then measure the system. And I assume then you could even, you know, measure the output of a motor driver as well. And so it just comes down to like, I just think about like, then everything becomes a test vector, right?

Michael Gielda: Yep, exactly. And, you know, actually you have to be a little bit clever about these things because once you move to simulation, you realize, okay, I can now do testing that doesn't make testing easy, right?

Chris Gammell: What do you mean by that?

Michael Gielda: So if you want to test whether something's actually working, how do you do that? If you don't have an opportunity to do that because it's just hard, you just ignore the problem and your conscience is free, right? But if you actually have the possibility to test things properly, you realize, okay, testing is a thing in itself. It needs very clever thinking. So we have the ability to feed data from files. Now, how many files should you have? How many scenarios should you test?

Chris Gammell: Right. And is it actually impactful on the actual output, right? I mean, like, does it actually matter to do this sort of thing? Or is it just testing because it's the thing you've always tested, right? When you've done the quadcopter board, you've always tilted it back and forth to make sure the motors go. And it's like, okay, well, maybe that's actually not testing anything of use here.

Michael Gielda: Exactly. So if tilting it back and forth is the only thing you can do, you will do that and you'll sleep well because, like, that's the only thing you can do. So if suddenly you're presented with, like, the universe of opportunities to test things, you're like, oh, my God, now I actually have to do it.

Chris Gammell: Right. I'm going to be here a while. Yeah. And I guess that does come down to, I mean, that's how any test engineer understands, like, the scope of testing and coverage and stuff like that. That becomes a big thing because that directly ties to your efficiency and how many units you can get through. But, yeah, for people that are coming in new, I would imagine that that's it. Then we could become very burdensome.

Michael Gielda: Yeah. But I'm joking, of course. I mean, it's a good thing to be able to test. And in the usual scenario, right, we have this example of TF Lite and kind of gesture recognition, right? TF Lite is TensorFlow Lite, is that right? TensorFlow Lite, Micro, actually, it's a long name. OK. So the TF Lite team, the micro team inside TF Lite, they want to enable, you know, machine learning on the very edge with very small devices like micro control level, sub milliwatt, you know, $1 per unit kind of thing. And to do that is very tricky because it's very resource constrained. So you have to really pay attention to what you're doing and test a lot of things. And very often it's not that things are not going to work per se, but like you'll run out of memory and then it's not useful anymore because you have to grab a very expensive board to run this. So how do you put this awesome ML capability into a very small footprint? There's a lot of development involved to make that happen and then clever optimizations you have to do and verify whether your optimizations don't actually break what you're doing. So we have this test scenario for gestures, right? And obviously what you easily think of is, OK, I'm going to like record some gestures that should be recognized, right? Save that data to a file and try to see whether data from those files actually gets recognized as gesture still in simulation. That's like the most basic test you can do. And we have an example online how to do that. And it's already great. Like this story testing so many things. It's testing whether your drivers work, getting the data from the sensor, tests whether the ML pipeline is correct and so on and so on. So there is this kind of Pareto thing going on where after the initial terror of, OK, I have all the opportunities in the world to test. What do I test? You quickly come up with, OK, these are the things I could easily do with Renode that are going to give me a very good indication of whether my thing didn't completely break down. And people will always come to us at conferences and so on and say, oh, but what if? And like, yeah, there are kind of cases that you're not going to be able to test, right? But that's not the point. Currently, people are just not testing things for the most part. And that's the problem. Right.

Chris Gammell: Yeah. And I think the focus on the repetition, like going back to continuous integration. So I'd imagine that when you're doing these builds and you're doing, so you're building software and every time you do a commit, you want to do a full test of the system. Right now, that would be super burdensome, right? I know that like I go, maybe I'll do 10 commits and then finally, OK, well, I get the software to build. That's great. I'm going to go try it on the unit now. And I'll do a test and test something specifically and hope it works and keep going from there. But the idea here would be every time I do a commit now, it goes into a pipeline, it does a build, it verifies it builds, it then pushes it down to the device and then, or sorry, it pushes the binary that's been compiled to the simulation. And then it also takes in all this data and checks if that works. Is that how that would go?

Michael Gielda: Absolutely. A very good point. Yeah. So it's not only the fact that it's hard to test, it's also the repeatability. If there's a human factor in the testing, right, I mean, people get bored very easily. So even if something's a one minute procedure, which sounds OK, right? Like taking a minute to do something doesn't seem terrible. But if you're going to do it a thousand times, you're obviously going to skip the 990 times and just do it 10 times, which is worse. Like you want to do it a thousand times. A computer can do it a thousand times.

Chris Gammell: So I always talk about my own. And so one of my personal faults is when I get really frustrated with something and something's not working, I do this thing called thrashing where I'll just change a bunch of stuff. So to give a really stupid example, I might say I had jumpers on a PCB. I might go and change a bunch of jumpers and try it again, change a bunch of jumpers, try it again with this firmware that's not working. And then there's no guarantee then when I go and I'm like, oh, I got it working. And then I go and write some more code and I try that. And now are the jumpers in the right spot? I don't know. Like, I mean, I could go and check, but there's a very obvious like point of human error there that could be occurring in that the jumpers aren't set. And it sounds like in this case, using this simulation checks that the jumpers, in this case, virtual jumpers, are always set properly. Yeah.

Michael Gielda: I really like how you think about Reno because that's exactly the kind of points that we've always been making. If you go back to 2010, when we, you know, more or less started the company, Ant Micro was built with this mindset of we have to make things repeatable and verified. Like if you're working with something and it's not working, you shouldn't do what you're doing. You're a human. You're going to do it, which you just described, right? I'm not saying that we're not human, but like our approach has always been to...

Chris Gammell: Ant Micro, get rid of all the humans. Got a new t-shirt for you, Michael. There you go.

Michael Gielda: So the point is humans make errors and it's okay. We're computer scientists. We know we make errors. We are trying to figure out ways to be productive, to focus on the stuff that's really creative and get rid of the human errors everywhere. And so what we noticed early on is that when we're working in this physical realm, it's like always what you described. You get something wrong and then you try to figure it out. You move things around. You, you know, change jumpers and things like this. It's unstructured.

Chris Gammell: I mean, hell, you go out to lunch, right? I mean, you come back after lunch and you're like, what was I even doing? You know, like, was that supposed to be there? I don't know. Yeah.

Michael Gielda: Yeah. It's so many vectors, right? So we always say just observe the minimum, you know, change that you possibly can and see whether things improved. And even before we had Renode and even in places where Renode couldn't be used because, I don't know, we didn't support that platform. We always had this mindset where if you're testing and things are not working, just get back to the simplest possible scenario. Just like eliminate any complexity. Get a blinky. Get a blinky. And then go one step further, one step further. And of course, doing it manually is just frustrating, but it's still worthwhile. We still think it's useful to do it that way. But if you get superpowers with the tools that you're using, suddenly getting back to first principles and then get simple, right? It actually gets pleasant and nice and a preferred way to work. And then people start doing it universally. Yeah. So, I mean, we are focused on working that way even when the right tools don't exist. And in some spaces, they don't. Like, if you look at ASIC development, at least still today, they don't exist. But you should try to think that way. And then you will eventually create the tools needed because you'll see, okay, that approach is working. And how do I make that approach universal? How do I make it easier to apply in practice? And that's when people realize, okay, I need simulation tools. I need, like, linders. I need things that help me to do it more effectively.

Chris Gammell: Yeah. Yeah. So, I know James Grenning, and he does, like, tester-driven development. And so, I've read some of his stuff on firmware and stuff like that. And it does always seem like, in firmware specifically, like, where there's hardware in the loop, one of the struggles was always, like, creating tooling to make these things happen, right? Like, how do you write the tests before? And so, it was, like, it was almost, like, decoupled from the hardware. It was, like, how do you have to write a test and then you have to interact with the firmware. But it's not even thinking about it. It's just, like, thinking about that function instead of thinking about the thing that's out there, the hardware that's out in the field. And so, this is basically saying, like, oh, no, no, the hardware is out in the field. It's just not really hardware. It's, like, virtual hardware.

Michael Gielda: Yep. I think we, that's another point. We have to make hardware irrelevant in a sense. So, all those kind of tool chains that people have, all those, like, different IDs, tools, everything. I mean, these are tools of the trade, yes. But ultimately, what you want to do is you want to execute code and get stuff done. And all those differences you really want to encapsulate somehow and make it easy to work with hardware. That's what RISC-V is doing, by the way. That's what Chipsalign is trying to do. You know, we're trying to make hardware almost boring, just like software is boring, right? Like, you start a website and, you know, you create your React app with this kind of automated scaffolding script. And you don't even know what's going on inside. We like to know, like, we're this kind of weird company that loves to dig into everything. So, it's not that you shouldn't ever bother and see what's inside. But most of the time, you don't need to be looking all the time what's inside. You want this to just work. And the way to get it to work is through tooling.

Chris Gammell: Right. And I think that probably resonates with people here, too. Like, most of the time, people, like, you know, people like to dig in, of course, into fun problems in hardware and things like that. And sometimes even make low-level hardware designs, like, you know, transistor-based designs, things like that. But when you're trying to, like, get a job done, usually it's more on the application level or, like, the functional level of, like, I just need Wi-Fi to work. I don't care how it works. You know, it's just, like, I need to make sure when I push a TX packet to it, it sends it to the network. Like, that's what needs to happen, you know, that kind of thing. I think that is becoming, just because people are asked to do more with less these days, too, it becomes almost a necessity for jobs, you know, just to get things done.

Michael Gielda: Yep. You mentioned networking here, and I think that's a good thing to focus on, too. So, very early on in Reno's development, we realized, okay, getting one device to work is great, but what if you suddenly want to work with a network of devices? We realized that this is even harder, because there is practically no possibility of reproducibility and traceability in such a setup. Like, you know, you have multiple devices communicating, and very seldom will you get them to actually do the exact same thing twice, because there are, you know, multiple things. You program them independently most of the time, and they might be different architectures, even, or at least there are different boards running different software. So, how do you build a network in a testable way? Right. And simulation, again, becomes the answer, because, of course, in our tool, it's just one virtual setup. It's one time flow that you completely control. All those devices exist in one world. You can position them virtually in different places and see what happens. We have the ability to, you know, kind of say, hey, this radio only reaches, you know, 10 meters out, and that other device is 11 meters away. So, yeah, the packet's going to get lost. What happens then? How do you test your protocols, you know, in practice?

Chris Gammell: Yeah, if you're having, like, 50% loss of your packets, then is your retry working properly? Like, and I can imagine if you're in the real world, yeah, you could, you know, put some stuff in between the two things and hope for the best. But, you know, like, getting that exactly 50% packet loss that you might see sometimes in the field, it's like, oh, you might not get that in reality.

Michael Gielda: Yep, and I think you touched upon a very important thing about testing this kind of stuff as well, where you should actually care about getting a 50% packet loss more than testing whether a wall of the concrete type breaks your system, but the wooden one doesn't, right? I mean, yeah, these are on some level important things that people are working with and the researchers are researching, and they should. But in your practical use case, you mostly care about, okay, what happens to my protocol if my signal gets interrupted? For whatever reason, right? The reason's not really important. The effect is important. The packet got lost. What happens now? We can simulate that very easy. We can't simulate a wooden wall, right? Like, it's, there is no possibility to simulate that physical reality. I mean, you could.

Chris Gammell: If you had enough time, you could, right? Yeah. But it's kind of silly, right? It's kind of outside the scope, yeah. Yeah, right, right, right. Yeah, I mean, a lot of this stuff sounds like, I mean, so that specific thing, what that triggered in my mind, I was thinking, like, this is what NASA does all the time, right? Because they just have to simulate every single scenario. They have to get every single, like, you know, all the retry protocols, all of their RF stuff, every scenario that they expect to see in space. They can, they don't get to send, you know, they don't get to send more than one thing, so they have to simulate it. It's almost like bringing NASA level stuff to the masses, it feels like.

Michael Gielda: Again, I like your recap very, very much. I hope someone from NASA's listening, right? I'm your new marketing person.

Chris Gammell: Sorry, you're out of a job. Get the humans out of the loop.

Michael Gielda: Yeah. We need more marketing people, so if you're listening and you want to do marketing for us, reach out.

Chris Gammell: That's great. One thing I wanted to ask before we move on from this stuff is, what happens if, like, how do you verify that the simulation is actually representing reality? Like, what is the, how do you validate that piece?

Michael Gielda: That's one of the tough questions we get asked. And obviously, there are no simple ways to do this other than just verifying with a lot of software. That's basically what's our approach. It's worked for us very well, where ultimately what we care about is running software, right? So if all the software that we know is running as it should, probably the models are good enough. How we create the models is typically based on data sheets. And of course, like, data sheets can also contain errors.

Chris Gammell: No, those have never been wrong. I've never gotten a bad data sheet.

Michael Gielda: Or, you know, you might get something wrong and it happens from time to time. So, and many people say, oh, haha, you have no way to guarantee that these things are correct. Well, yeah, but so what, right? Like, it's, you are effectively trying to improve a very broken reality. And if you get it right 99% of the time, and over time as well, since it's an open source project, things just get better on their own accord. Like, people find bugs, yeah, and then they file issues and issue pull requests and the models get improved. And, you know, we have so many people using Renaud now that if all of these people's software works, what's the chance of the models being wrong? It's, you know, it really goes down to almost zero. Having said that, of course, yeah, it would be great to have, you know, formal proof and so on. And there's people working on these kind of things as well. It's just that it seems the most practical approach is just to go and get it done and be aware of the fact that, yes, the models can be imperfect. But for the most part, you don't really care about them being imperfect because you're testing very specific things. Like, if you look at the coverage of software against what hardware enables, very often we see that the software is using, like, 10% of the hardware's functionalities at most, right? I mean, it's using the CPU very, very much, right? Or some, but in terms of the IO and the registers, and you're just using a very small subset of what's available. So modeling everything and trying to get it perfect might be, you know, eons of work where you don't really have the time, right? You want to model as much as needed, as well as you can, and make it available to people, and then improve it iteratively over time.

Chris Gammell: Mm-hmm. Yeah, and I think that that actually leads me to my next question here because it seems like, so looking at your GitHub page, it seems like a lot of the stuff that is on there is kind of these higher end, you know, like you've mentioned, you know, you're targeting AI, ML type stuff, you know, machine learning, artificial intelligence, stuff like that. Do you find the people that are mostly using it are in that kind of high-complexity software environment trying to maximize throughput versus, you know, someone like me who's doing, like, tiny embedded systems trying to, you know, make a, you know, little widget that has sensors connected? Like, what is, what would you say the split is in terms of the community? Oh, I think your use case is great, right? So it should be fairly well-splitted. Sure, yeah. I'm not saying it's a bad use case. I'm just saying, like, who's really into it? I mean, part of it might also be just the nature of the person using it, right? I imagine someone using, like, a Jetson Nano is a, you know, very smart software person who's, you know, like, I just, I have no need for that sort of thing, right? And so, like, I'm not writing a ton of software for it, so the tooling might not have been, the testing tooling might not have been a priority versus someone who's doing, you know, low-level sensor type stuff.

Michael Gielda: Sure. So disclaimer, we don't simulate a Jetson Nano today, right? Like, we do want to do that, but it's a fairly complex thing. But in terms of the complexity, I think it tends to be that people that hit some kind of a complexity problem start thinking, okay, how could I actually test this, right? So currently, I guess that our users would be more like power users that really kind of need Renode because otherwise they can just get by with, like, I'm going to test manually, right? But we do want to reach out to more people, and that's going to happen with this edX course and other things where we do believe Renode's very useful for a lot of use cases, not just the most complex ones. But I think there's a natural affinity amongst people that are trying to solve complex problems to look for tools that are going to help them to do that. Like, RISC-V is a good example where we have a lot of usage in the RISC-V world because, like, RISC-V is trying to push some boundaries, right?

Chris Gammell: Right, yeah.

Michael Gielda: It's not as easy to program against RISC-V yet because, you know, software is mature, but it's not, like, arm-level mature yet. Yeah, right. You know, there's a lot of stuff out there, but there's still a lot more stuff coming. And so we see all those customers and users in spaces where they're trying to achieve something unique and something, you know, that's pushing the boundaries somewhere. That's when they will turn to new methodologies, new workflows, and they'll potentially run into Renode and start using it versus people who have just gotten by doing simpler stuff and it's worth for them. And, you know, I still think they could benefit from using Renode, but I wouldn't necessarily want to, like, push them to say, you know, you'll use Renode and your development experience will get 10 times as good. Perhaps it won't, right? Because your thing is just not complicated enough to warrant having to use that additional tool.

Chris Gammell: Right. So, yeah. Yeah, there's, like, some crossover point between, like, the investment of time and the, you know, like, the benefit you're going to get out of it. But over time, as someone gets better at it, that investment of time will probably amortize over multiple projects as well.

Michael Gielda: So having said that, we are currently integrated with the Arduino IDE, right? Oh, yeah. Oh, cool. That would probably expose us to a lot of people with, you know, that are not necessarily pushing any boundaries. They're just trying to build this blinky thing. And that's okay, too, right? I mean, Renode and this kind of way of thinking should just be universal. We assume that it's, we don't necessarily want to gate it against people that, oh, your use case is too simple. We don't want to enable you, right? No, it's like, we want to enable everyone that wants to use it.

Chris Gammell: Yeah. Yeah, and it's enabling a methodology, you know, there's Reno behind it, but it's like this idea of, like, testing and having, you know, abstracting out hardware, basically. Which I can imagine, you know, for the amount of people that are coming into the Arduino world from the software world specifically, it probably would actually match up really well. So that's great. Yep. So let's talk about the RISC-V stuff. So how, how did then, does that play in? So people are free to go and use the RISC-V open ISA and build their own thing, right? Build their own chip. And they often start, you know, they simulate for, they simulate the actual silicon that's happening internal to the chip. How does that tie into the AntMicro ecosystem? Are you enabling that simulation at the transistor level of, you know, a RISC-V design? Okay.

Michael Gielda: Okay. So transitional, transitional level simulation, and generally speaking, HDL simulation, this is, of course, a bit of a different field that we're also active in, right? So this is not really related to Renote as such. Sure. You'd very often use tools like Verilator. I mean, perhaps even more complicated, you know, simulation tools if you're really interested in building the low-level phenomenon, the ASIC. But if you're interested in the digital behavior of the ASIC, but you kind of want to test it on a deeper level, that's where you'd use HDL simulation with things like Verilator. There's also proprietary tools that people use for that. But, like, that's where we think Verilator and what perhaps comes after that is the way. You know, you want it to be open source. You want it to be available to anyone, even if it's complex stuff. You want as many people as you can looking at the problem and joining forces to develop, you know, open source silicon. So we're putting a lot of weight and development effort into things like Verilator, which is enabling people to work with, you know, hardware software co-development. I mean, Renote's enabling that, too, because people use it for that kind of stuff. But, of course, Renote's more into behavioral simulation for software development, right? If you're interested in the hardware as such, you might also combine Renote with Verilator. We have that capability to co-simulate parts where part of the system is fixed and known, and then you simulate that in Renote. But then there's a peripheral or DMA or whatever that you simulate in your HDL simulator. And you're looking whether your development is going the right way. And most of the system is simulating very fast. And the part that you care about is simulated slower. But since it's just a part, the overall result is pretty good. So we have that capability. And, of course, there's other tools in that space. Sci-Fi and Berkeley, they're doing a great job with FireSim. That's like a simulator for chisel-based designs that you can run in the cloud. And you simulate the entire chip at the same time. So, yeah, that's a fascinating area as well that we also want to revolutionize. So we want to tell people, hey, this is all possible using open source tools. And once you get to open source tools, you can have workflows that you can put in CI, make available to everyone, show it to the world, and collaborate around.

Chris Gammell: Yeah. Yeah, I imagine. So Tim was back on here talking about the open source PDK. And we're very excited about that. One thing that always comes up whenever I think about the idea of making a chip, it's like, okay, well, first off, where the hell do I start? That's obvious. But then when you think about that application level thing, first off, why do people want to do this? I actually really like that example you gave of, like, so now you have captured data of someone, like, waving their arms or, like, a gesture, and you're trying to make that better. And right now, with the OpenML people, or not the OpenML, but the, sorry, the light, TF light. The TF light thing is basically writing software to, like, push that onto a fixed piece of silicon that's out there, low-cost fixed piece of silicon. What I'm imagining this, the Verilator and this kind of co-hardware software thing would be is now you have someone waving their arms. You have that captured as a data file. Now you have the system simulated as well at the behavioral level. But you might then go and try and make a custom piece of silicon that really, really efficiently could capture and process what that data is. Is that kind of the thought there? Is that what you're thinking is happening, or how does the actual...

Michael Gielda: Yeah, we'd always wanted to close that feedback loop, where silicon manufacturers, they think they know what software people need, and that's not true. They don't. They're getting better, and they're, you know, hiring some clever people, but ultimately, it's the software people that know what they want. And very often, like, so many times in our history, we'd bought a piece of silicon and then just felt very sorry that it's not doing exactly what we want. Like, you just compromise.

Chris Gammell: Do you have an example of that? Like, what was the actual compromise on that that didn't fit your need?

Michael Gielda: Very often, it's just one missing interface. Like, if only it had this one extra interface here, that would be applicable to just those awesome scenarios. But as it stands, like, you have to add more chips and complexity and, you know, software. Like, you effectively patch up whatever the hardware is missing, and you never tell... Like, you never get back to the silicon vendor and tell them that, right?

Chris Gammell: Right, right. It's like, hey, ST, you gave me five URs, and I needed six, and I did... That last UR really mattered, you know? Like, that kind of thing, right?

Michael Gielda: Yeah, yeah. You never get that. They try to get that feedback from you, but, like, there is no way you're going to give them that feedback easily. So, in fact, we're still very often, you know, they do talk to some people, right? They just talk to a subset of people.

Chris Gammell: Sure, yeah. And usually the ones that are paying the most. I mean, because, yeah, it's just... I mean, it's like a power distribution, pretty much.

Michael Gielda: And these are the people that are paying the most today, right? These are not the people with potential use cases, so it's a chicken neck problem that you're facing. So, I think FPGAs solve a part of that problem. And we think that FPGAs will become, you know, much more used than earlier. Where you need some flexible hardware, you know, you need to kind of adapt your platform as time passes to specific machine learning use cases. FPGAs are a great answer because you can just change whatever is running inside of them, adapting to your use case over time. You don't have to, like, tape out a new chip. You just kind of push a new bitstream onto it. So, in that sense, FPGAs solve a part of this problem. But if you really want to go down and optimize a chip to a very deep level based on your use case, that's exactly where, you know, simulation comes into play. That's exactly where open source PDK is coming into play. If we democratize this ability to build chips, people will finally have the ability to not be afraid of thinking that way. Because right now, if you thought, okay, my hand-waving will influence chip making, it's ridiculous, right? It feels ridiculous to be making that statement. But in fact, it should be like a researcher, you know, kind of takes a specific thing into question, right? And so he says, okay, we should be able to devise a very good algorithm to detect gestures. But the current hardware does not support that very well. So what? I can create my own hardware. I can kind of look at what's needed on the hardware level, like model, implement that, you know, kind of simulate that first, like test this approach. And if that approach seems to work, if I'm getting much better performance for this specific use case, let me go and just get my chip made that does this. This is possible. This is going to happen in some years, sure. But there is no reason why this shouldn't be possible. We have people in the security domain that prototype stuff in Renate first. They see whether this has any, like effectively what they're modeling is performance, right? Because they're trying to, it's Dover Microsystems, a company doing, you know, security chips that kind of guard, they call it CoreGuard, right? It guards your, you know, code from executing malicious stuff. So your CPU from executing malicious code. And they're looking at various ways to protect this. So they're going to experiment with various like guards they can put in place, policies, they call them. And of course, the best policies would be the most stringent ones, but very stringent policies result in a huge performance decrease. So these guys have been working with NXP and putting that IP into their nice gen platform where they have been using Renate to see, you know, which approaches work best and kind of cut away the approaches that just don't make sense from a performance perspective. And focus on whatever matters, like whatever gives them a good Pareto optimization of this gives me a lot of security. But at the same time, it doesn't give me a huge performance decrease. And then after they've done modeling and Renate, they're going to go and implement the actual hardware code that eventually gets taped out in a chip. So that's how we want people to work, right? So FPGAs are one way, of course, because they're awesome. You can just change them in runtime, but ultimately you'll also be able to kind of build chips that cater for a specific use case.

Chris Gammell: Yeah, I think that is the workflow of the past, but also the future of like, you know, have an idea, try it on FPGA, you know, optimize, optimize, optimize, and then eventually move towards like a custom chip solution. And I think maybe what happens with some of the chip solution or the open PDK and, you know, more fabs hopefully opening up is like, it just gets faster and easier. The people are like, oh, well, I'm not going to do another rep in FPGA. I'm just going to go straight to a chip. You know, that kind of thing would, you know, in a near term future, I could see that happening where democratization of chip shuttle runs can be really, really beneficial in that way. Yeah. So Ant Micro is listed on the microchip and you guys are a site and you guys are working with the PolarFire. How do you actually interface with an FPGA? Like, so what tools then do you hook into and how does that interact with some of the other tooling that you've built up?

Michael Gielda: So, of course, very later is the default thing that we talk about there because it allows you to just grab your, you know, FPGA code, put it into through very log and then hook it up to Renaud and get it co-simulated. When it comes to, like, FPGA stuff that we work with, like, for example, Litex, which is a configurable system on chip generator that you can, you know, run inside an FPGA. You can have some RISC-V cores or if you don't need cores, you can also have just different kinds of IO peripherals. So Renaud, for example, gives you the ability to extract that Litex configuration and generate this platform definition file based on that. So we're looking at specific FPGA IPs ecosystems that are in a way fixed, right? Like, sure, you can change them because that's what FPGAs are. You can completely change everything that goes on inside them. But we try to kind of see, identify, you know, places where we could possibly simulate those things in a consistent way, in a configurable way. But the configuration is not, like, you don't have to hand code that configuration. You can just read it out and build that system easily in Renaud. Yeah, and then there's a bunch of things, of course, that we're doing on FPGA front that today doesn't connect to Renaud because we've been talking about Renaud all the time. Right, yeah.

Chris Gammell: There's more to get micro. It's a part of what we do. They're taking out humans in more ways than one, folks. Sorry, I'll stop doing that. That's my last time. I promise. Maybe, probably my last time.

Michael Gielda: I'm just laughing because, you know, if I confirmed what you just said, I'd be in trouble. But, yeah.

Chris Gammell: I'll just keep saying it and you can just nod your head silently as all of our audience members will.

Michael Gielda: Okay. Yeah, and it's a podcast so people can't see great. That's right. That's right. So, the point is, we're doing a lot of stuff in FPGA space and, like, open source FPGA tool chains, right? We're working with QuickLogic, you know, building their current and next-gen FPGA platforms where they will have completely open source tooling. Even better, one of the things that we're doing for Skywater PDK Shuttle Run, which, by the way, is closing. And, like, the first window is closing this week, basically.

Chris Gammell: Get your stuff in now, folks. Yeah, I think it's, like, the first of December or something. I think it was, yeah, early December, I thought.

Michael Gielda: End of November, actually. Okay. The 30th, I think.

Chris Gammell: Oh, you know what? Probably by the time this show goes out. This isn't going out, unfortunately, until the 29th. So, if you're listening to this right now and it's Monday morning, get simulating, folks.

Michael Gielda: So, one of the Shuttle Runs there will be one with, you know, open FPGA fabric in it, right? Like, not just open FPGA as in, like, something you can target with open source tooling, which is cool enough. It is actually, you know, open source FPGA fabric that gives you the ability to potentially, you know, build your own FPGA, right? And that's the kind of thing that we're trying to enable. And, of course, ultimately, it still plugs back into Renode in some sense because once you get, once you make things easy to work with, configurable, somehow you end up doing simulation at some level, right? Because you want to, like, even if you tape out in your chip and you're kind of completely focused on chip making, I think that's the claim I've been making since the very beginning. Software people should get to say what their chips do, right? So, the development perspective, the application perspective, the user perspective should be in your mind, even if you're deep in the lab developing the next-gen chip. So, ultimately, many of the roads connect back to Renode anyway. But, like, I don't want to make it sound like you want to develop a chip here. Renode does this, right? Yeah, it's going to be part of your workflow. But, of course, many of the things that need to happen for those workflows to be improved are completely other tools. Like, we're working with, you know, system Verilog support and Verilator. We're working with OpenFPG tooling. We're working with, like, open source ASIC flows and the PDK. There's so many building blocks that need to, you know, come into place for this to really change. But it's happening right now, right? Like, there is so much development that I think it's beyond the point where it can be stopped. So, people can complain that it's taking away their business or they might be, I don't know, afraid of this new world that's going to happen when these things get open sourced. But I think it's already inevitable. It's more like you can try to stop it and make it go slower, yes. But slower is still happening.

Chris Gammell: Yeah, just lean in, folks. I mean, like, I think you're right. It does change. It changes the nature of, like, profit streams and stuff like that. And I think that's usually where people kind of clam up, especially, like, executives and things like that. And I just try and, like, whenever that happens, I don't try because no one in that position would ever listen to me. But what I usually do in my head is, like, I point to, like, Microsoft. I mean, look at Microsoft and, like, their shift towards open source. It's just been, I mean, it's been mind-boggling. And, like, how successful they've been in the face of that and just how they've been changing their company culture. I mean, like, Satya is just, the CEO has been instrumental in that from the top and stuff like that. But it's just, it's amazing to see companies that were so closed move towards open and, like, and still thrive in very, very big number of ways. It's crazy.

Michael Gielda: Yeah, it's crazy. But I would actually dare Microsoft to do to kind of go to the next level. Yeah, well, of course. Yeah, there's always more.

Chris Gammell: Yeah.

Michael Gielda: Right? I mean, yes, they've embraced open source very, very much. But, like, look at GitHub. Look, even VS Code, right? The nicest stuff about VS Code, like the remote collaboration features and so on, all closed, right? Like, the basic tool is open, but the nice stuff is closed. Or GitHub, right? Yeah, it hosts a lot of open source code, but it's a closed proprietary framework, right? And I'm not militant. I mean, I understand why they do it. I'm not going to complain, but it's more like... Don't worry, Stallman's not listening. Yeah, things are getting better. But they're far from ideal. There's still a lot of work to be done.

Chris Gammell: I'm just saying that, like, they were known for rejecting it outright in the past. And that's the only thing I'm saying. And, like, the shift towards it is the right move, I think.

Michael Gielda: Absolutely. I mean, you know, we are using a lot of their technologies. So I'm never going to complain about their shift to open source. I think it's great. And I think they did the completely right thing. But what I'm saying is we shouldn't just stop there. And we shouldn't say, okay, now our work is done. Even Microsoft is doing open source now. So our work is done.

Chris Gammell: Oh, I see. Yeah, right, right. Got it. Okay. And you guys have an open source section on your website about projects. You have lists Axiom, Migrant, RISC-V, Zephyr, and ECOS. It does get a rework.

Michael Gielda: So, like, this list is so incomplete. It's coming from, like, many years ago. And we're working on a new open source portal where, you know, we're going to be listing in hundreds of the projects that we're participating in. Not just a bunch. And the bunch there is just probably a little bit old stuff. Like, Reno, of course, is still there and growing. And, you know, Axiom is a 4K camera project that we were involved at one point. And it's an awesome project that's still living on. So I'm not saying that it's kind of dead, but it's more like our participation in it is not as active as it used to be.

Chris Gammell: Got it.

Michael Gielda: But there's, like, dozens or perhaps hundreds of new projects that we've since either started or got involved with. And the open source portal will summarize that much more neatly. So sorry if you hit that open source button on our page. I promise to kind of make that better. Certainly you should go to our GitHub and just see the number of contributions in various projects.

Chris Gammell: So how do you decide? So obviously, you know, you're paying engineers to do all this stuff. And how do you decide what to get involved in? I imagine, like we were just talking about with Microsoft, there's probably not a profit mode in all of this. And like you and I talked about before the show, you are very mission-driven as well. So in a world where you can work on everything and bring this kind of methodology to everything, how do you decide what to work on next? And then what ends up impacting your business as well? I mean, I guess.

Michael Gielda: We mostly decide based on actual impact factor in a sense. Like we look for things that are really broken and try to fix them. And then if you try to fix them and you just let go of the fact that you're looking for immediate profit, right? You're not looking for immediate profit. You're looking for profit further down the line. And so what's going to bring people money? Fixing problems, right? So you want to fix people's problems so that they feel inclined to pay you for having fixed them. And we're looking for areas where open source is not really very popular and we think it should be. And we build like open source baseboards. We build frameworks. We build tools wherever we see a need for them. So we're probably not going to build the next generation like a front-end framework, right? Just because that space is already very crowded and we might. We're crazy. We might actually go and build a next-gen front-end framework too. But probably look for us in spaces like hardware, like ASIC design, like PGA, where there's such a dire need for revolution, where we're just going to identify what needs to be done and try to do it. And obviously, we look for partners. We look for customers. So wherever there's customers like Google, Western Digital, you know, and others that are working with us and willing to pay for developing open source, we're going to go there and do that, right? Because that gives us a sustainable model to actually continue doing that over a longer period of time. But very often, our will to get involved with something precedes, predates any profit, right? We just see this is really broken. Let's just try to get involved. And obviously, over time, we're going to find a way to monetize that. And it always happens.

Chris Gammell: Sure. Yeah. I mean, yeah, I'm always surprised by people that, like, you know, they give their time to a project. And then that project goes somewhere or someone, you know, is looking to utilize that work that's been put out in the world. And it's like, you know, it's either midstream or it's, you know, at the beginning of the stream. And it's like, at some point, someone's going to say, oh, I just need this to work right now. I'm willing to pay this person to go make it work. So, yeah, I can see that being a – it's almost like a marketing in itself of, like, hey, we're doing this thing because we believe in it. But also, hey, look, all these services we provide, we can just do this more. You know, you got to pay us to focus on one thing. So, you guys are – like you said, you're a services org first. You know, you provide services, things like that. Renode is a project that has come out of this and become this thing that you use. But then is there – you had mentioned like an online, like a CI tool or tooling. Is there like a web tooling kind of thing that uses this? Or is it more like you pay someone at AntMicro to go and build up the tooling for an organization?

Michael Gielda: So, of course, we have organizations that don't want to share anything that they do and they just want to use open source tools internally and, you know, they have confidentiality reasons to do so. And, you know, they're users, right? And they pay us to develop something just for them. But we love when, of course, people are working on an open source project, but that's driven by a corporation. And the TF Lite guys is a good example, right? It's a Google project that is being done in the open. And for them, we're building a completely open source infrastructure for CI that is out there for everyone to see. So we have the ability to build those kind of things. We're using things like GitLab and BuildBuddy and all sorts of frameworks that allow you to run CI, present results, analyze them, and so on. So we have both, right? We have customers that just want to do something specifically for them. And that improves the core frameworks that we work with, that gives us revenue streams that kind of, it's a very important part of what we do. And we don't want to, like, discourage people from working with us because their stuff is closed. It's more like we can understand how it's not a switch. You just flip and suddenly you just release everything you do open source. Right.

Chris Gammell: Try one thing, one small thing that might be open and see if that goes in the future. But if not, that's okay. There's business cases to be closed sometimes too, yeah.

Michael Gielda: Effectively, of course, we do believe that we're going to advocate our customers to try to open source as much as they can, right? So it's just that it's a step-by-step process. You don't go to a big corporation and tell, like, who do you tell that? Like, you don't go to the CEO to talk to them. So you're going to be talking to some kind of a team that's very convinced they should be doing open source. But before they actually get the buy-in internally to do more open source and to influence their organization, it's going to take time. So we're fine with, like, implementing a system that's working internally for that company. And over time, since that system uses open source tools, you can convince them, hey, what if we did a public CI? Would your world collapse if that happened? And very often the answer is, okay, well, perhaps it's something we could do.

Chris Gammell: Yeah. It's like, if you're going to hire Ant Micro, don't expect to be sitting in a conference room and don't be surprised if they suggest something might be open at some point. That conversation is going to happen. It is. Yeah. That's great. I mean, I think that's, you know, you guys wear that on your sleeve and people know about that. And that's, it's, if they're surprised, they just haven't done enough, they haven't done enough research. So where do you see all this going? I mean, where, what's next in the wide swath of things that are out there? What are you, what are you most excited about in terms of all of the things that you guys are working on that is open?

Michael Gielda: Well, in terms of the things we're working with today, I'm of course excited about the FPGA stuff because it's really taking shape and gaining momentum. The ASIC things, you know, the PDK and so on also are, and I'm very excited for them, but it'll take a much bigger coalition of players to make it happen. And hence, you know, chips lines, hence risk five and so on. But yeah, I'm super excited for that too. I'm also excited for the things that we're, you know, like looking at and we know we're going to get involved with and things that are other people are working with. You know, open source self-driving from Com.ai or like medical research that kind of advancing this possibility that humans will eventually try to fight the results of aging, right? It's, I feel there's a huge field for open source to play a role in everything. And I'm very excited for the fact that we don't have those limits. Like we, and micro is never going to say, hey, this is the kind of stuff we don't work with. I mean, unless of course there's a problem with this stuff, but I mean, for fields of human activity, for fields of research, if there's innovation to be brought into those fields using open source, we're up for it. It's easy to do in hardware, you know, FPGAs, ASICs, in the sense that you can see the clear connection between software and those things. And then you can just rely on existing examples and just, you know, telling people, hey, look, it's worked for software. Why shouldn't it work for hardware? But it's worked for software. Why shouldn't it work for biology is like a perfectly fine argument I'm willing to hold in front of anybody. Or, you know, smart home or whatever. We were kind of looking at ways.

Chris Gammell: I'd say biology and smart home are very, very different. I know, I know.

Michael Gielda: I'm just, you know, that's why I'm throwing these things out there because it's not very structured. It's much easier to structure your argument in specifically, you know, semiconductors, software. You know, these are so well related that everyone sees the connection and it's hard to argue. But I'm willing to claim like open source design has always been on my mind. It's been inspiring me. Like, how would you go about, you know, kind of helping designers be more productive open source? I'm sure you could. And today it's a very proprietary landscape, right? But I don't see a reason why it should be so in 10 years. It's just that we're not tackling this problem right now because you just have to target what's feasible today.

Chris Gammell: Yeah, right, right. One foot in front of the other.

Michael Gielda: But I'd love to, right? Like, why wouldn't anyone? Why would someone say that the current situation is preferable to having something that's collaborative and people just, you know, working together on improving the tools and not just using them? I'd love to have like a community, not even a community, a society of tinkerers rather than a society of consumers and users of technology.

Chris Gammell: Yeah, that's a great lead in. And so I don't think we've talked about the Chips Alliance yet. What is the Chips Alliance?

Michael Gielda: This is an organization that tries to drive open source hardware development in a very broad sense of the word, both like IPs, both things that you make, but also how you make them, the tools. So there's those two pillars where, on the one hand, it's what people traditionally think about when they think open source hardware, right? Like open source cores, open source interconnects, open source IO peripherals. That's all within Chips Alliance's interest. But the second pillar of tools, I think is really cool because Chips Alliance also thinks, okay, if these things are going to be built in an open way, you also need them to be built in an open way, like in terms of tooling and workflows. You want people to be able to collaborate around these. So you don't want an open source IP core that then nobody can use because they can't pay half a million dollar license to work with it. You want people to actually be able to take that from GitHub and then run it on their own computer or perhaps in the cloud and proceed to eventually perhaps even making a chip based on that. And of course, that needs some money and infrastructure, but like today, building chips just needs a ridiculous amount of resources, way too much resources compared to what it could be. So it's bringing out the barriers in all sense of the word, both giving you like off the shelf stuff that just works. That's like one aspect, but also changing workflows so that anyone can get started easily.

Chris Gammell: Hmm. And so what does the actual, what does it take the form of? I mean, is this like a working group and it's like, there's kind of recommendations that are made or you discuss this stuff? What is the actual output of the Chips Alliance?

Michael Gielda: So it's a Linux foundation project that gets involved both with code and specs. And traditionally, let's take a project from Intel called AIB. Intel is a member, right? And they have this interconnect project where they develop the spec and the code alongside. And I think that's the best type of thing to do where you both have an open spec that other people can try to implement if they want, but you have a reference implementation. And I think Chips Alliance is really great for doing this where it's not just a spec body where we just come up with complicated specs and then hope that other people will understand what we mean. And it's also not just like an implementation, but we just do stuff. We don't know what we're doing, right? It's both. And of course, not all of the projects in Chips Alliance have a spec, right? Because sometimes you're just building a useful tool that doesn't really need a formal specification for 20 parties to adhere to. But things like interconnects, right? They do need specs.

Chris Gammell: Yeah, right. Yeah. Pin one has to hook up to pin one. You know, like you can't just be a, well, whatever you feel like.

Michael Gielda: So I think this combination of the tooling aspect of an IP aspect and then specs and code, I think covering all of these things, this is super ambitious, right? This is something that we're really trying to pull off that's not trivial. But at the same time, I think that's what makes Chips Alliance worthwhile. Because there are plenty of organizations that tackle much less complex problems. And RISC-V is one example. It's developing an ISA. It's still very hard to do that. And like the ISA is not the only thing. You need also an ecosystem around the ISA to make work. And I can see RISC-V currently expanding to cover so many more fields than it used to. And part of this is because RISC-V has realized, okay, we now need to be much broader to make RISC-V go to the next level. Right now, it's already super, super popular. There's a lot of companies and universities working with RISC-V. There's products. There's a lot of momentum. But to make RISC-V really omnipresent, you just need to take care of the entire ecosystem, not just like the ISA and that's it. Signal Chips Alliance, right? If you want to make open hardware successful, you can't just say, oh, the cores are successful. Mission done. Complete. Right? You need to think about how are people going to connect memories to my chip? How are people going to do AI acceleration? How are people going to do graphics? You know, there's so many complex problems in one. But I think that tackling this problem also on the methodological level will allow us to scale very rapidly once we're past some inflection point. So it's still pretty early in game. But I think that focusing the tools will help us also bring together the people that care about these things. And they will bring, like we already see organizations like Intel, they joined bringing in the AIP stuff. And, you know, they were looking for a good place for it to live. And they found us. And we're looking for these people that have this jewel that are sitting on and thinking, how will I make that a sustainable piece of silicon, piece of IP? And they look at the landscape and see Chips Alliance as this potential body that will make your thing successful and make it interoperable with other things and make your development workflow better all at the same time.

Chris Gammell: Yeah. It's interesting contrast actually to our guest last week. So last week, yours had worked at Tesla. And we were talking about a vertical integration and like how vertical integration basically removes some of the need for this sort of like the need to communicate between organizations, the less need for standard, less need for just specifications. Obviously, you're going to have that internally, but it's not going to be as much rigor around it because you might want to move faster. Do you find that this makes things move slower? Or what do you find is the ultimate benefit? Is it the interoperability that becomes the benefit?

Michael Gielda: Well, I think, you know, vertical integration shouldn't be contrasted with what open source does. I mean, essentially at AntMicro, because of using open source technology, we can have infinite amount of vertical integration, right? Like we do a lot of our own tools and frameworks because we are using open source so we can just integrate them together. Now, as a side effect, we also open source a lot of these changes. And the reason is if we get more people hooked on this, they're also going to contribute. They're also going to verify, validate our use cases. So I'm not seeing how these things are in contrast. I mean, sure, vertical integration makes your life easier in some sense. But combining vertical integration with open source, I think, gives you the ultimate benefit.

Chris Gammell: Oh, totally. Yeah. I'm not saying it's not good or bad. I'm just saying it seemed different. It's a good point about maybe it's not. They're not mutually exclusive. I guess the main thing that I think about is one thing we talked about was like the scale required to be truly vertically integrated because at that point you basically become the standard, right? You're big enough that like other people come in. Again, just use the Tesla example. It's like, oh, well, this is our plug interface. And then you just got to follow this plug because that's what we say it is. And in this, it's contrasted to this. It's a bunch of people saying, well, what is the plug actually going to be? And what is the best case for the plug? I think the benefit would be if you have a bunch of people looking at it before it's finalized, it's like, oh, well, why is it doing this? Let's actually change this and make it a little bit more useful to more people. So that actually could have one of the main benefits, I would think.

Michael Gielda: Yep. And I think that you make a valid point with the scale thing. So what open source enables is achieving that kind of thing without scale, in a sense. And then once you get the scale, sure, you can set your own standards. But by that time, I don't think you actually want to. I think if you become big on open source, which is what we're planning to do, you'll realize that, yes, you're hiring a bunch of smart people and you consider yourself a smart person. But that doesn't mean that you've just devoured all the knowledge of the world, right? Right. It's not the answer. So the collaboration perspective, the ability to collaborate that open source gives you, I think, just improves your vertical integration experience. Because you can just borrow ideas and code from other places and integrate that back into your stack. And the way you put these things together, the way you make these things work, that might still be unique to you, right? So we're not open sourcing all of our micro and our entire internal infrastructure and the way we do things and so on. We're open sourcing code that we work with. We're open sourcing tools. We're telling people how we work, yes. But you can't really copy what we do so easily. So in that sense, a company that wants to be vertically integrated and have some competitive advantage over others while being open source at the same time, they can still perfectly do that, right? They can open source all the building blocks. But the way they put them together, the company culture, all those things, it's, I think, unique to an entity. And it's very hard to just copy that one-to-one. You can try, but there's been many people that have tried to copy organizations and, of course, failed to do so. So I don't think code is equivalent to everything that a company does. So I still think a company that builds on top of open source can be vertically integrated and kind of protect their spirit in a sense, but at the same time be very open about the technologies it uses and collaborative around the code that they develop.

Chris Gammell: Yeah, no, I think you're right. I think you're right. And I think the culture is a big piece, like you're saying. Michael, where can people find out more about Ant Micro? And I think, actually, probably most relevant for this audience, how do people get started with Renode quickly?

Michael Gielda: Okay, so about Ant Micro, I think you just go to antmicro.com and there's a technology showcase. Like, if you scroll down, there's like a bunch of tiles with different blog notes that you can read about the things we do. That's where I mostly point people to. The open source portal, once created, that's where I want you to go as well, but it's not there. For Renode, just go to renode.io. Or you can just open the docs for it. And actually, go to GitHub. GitHub.com. And there in the readme, there's installation instructions. If you're on Linux, it's going to be very easy for you because you can download a tar file that contains the so-called Renode portable. And Renode portable is, I think, a 20-meg package that you just unpack and there you go. You run Renode. No dependencies.

Chris Gammell: Yeah, I actually clicked it before and it was, I think, like 8 megabytes. And it was, yeah, it was like a Debian file that you just click and...

Michael Gielda: Oh, yeah, yeah. You've already got the depth file, right? But I mean, there's also a portable file where you don't have any dependencies whatsoever. Because the operating system packages, they'll, of course, have some dependencies. Not anything dire, but you'll have to do a little bit of configuration. But the portable package, it comes with everything prepackaged. And it's a really good starting point because, you know, people want to see an effect in five seconds. And I understand. I'm the same. I see a new frame. I'm like, how do I try it out in five seconds? I don't have more time.

Chris Gammell: I'm going to spend the next three months on this thing, but I better get that five-second dopamine hit or else.

Michael Gielda: So look at using the Linux portable release. And if you follow those instructions, you're going to get going in, you know, five minutes. And then we ship with examples. So if you go to our documentation and you look at the supported boards, you're going to see, like, a bunch of boards. And for those boards, there is a single command to run a demo running on those boards.

Chris Gammell: Oh, that's cool.

Michael Gielda: Yeah. And you get a binary running. You get some console. You're going to get UART output in Windows. You're going to get a log of everything that's happening. And you're going to get an interactive terminal for your, you know, kind of interactive work. So once you turn reno down, you're going to see the terminal that this kind of monitor, as we call it, this interactive terminal. And then if you just enter that one command that runs the demo, you're going to see things happening. You're going to see, you know, like, you are spitting out things and logs saying, hey, we're accessing peripheral xyz. So that's what you should expect.

Chris Gammell: Yeah. That's cool. All right. Great. Well, we'll put links into that to everything here. But Michael, thank you so much for joining us here. You mentioned you're looking for marketing people. What other kind of people are you looking for?

Michael Gielda: Enthusiastic about open source and, you know, people that can actually understand the premise of what we're doing and why. And we're always, in general, not just in marketing, in all the roles, we're looking for people that want to stay around for a while and, you know, kind of understand that we're there not to just do some work, but we're there to change the world in good ways. Yeah. Yeah. So it's very hard to kind of pin down exactly the kind of people we're looking for. It's people that are excited. Of course, like, technically competent is important for us as well. Yeah. Just don't expose that capability for learning. So it's very much about the personality as well, not just about, like, a specific skill set. Sure, like, hackers and people that love to tinker with things and take them apart and, like, go step by step into figuring out how things work. That kind of mindset is very, very useful for working at micro. And if you combine that with this kind of affinity for learning and a certain type of personality. And I don't mean, like, again, I don't mean, you know, we don't want to say that we want to attract people that want to fight against the world. Right. We're not really fighting against things.

Chris Gammell: Not zealots, you're saying, but you're saying people that are passionate.

Michael Gielda: We're building. Yeah, we're building things. Right. We're helping to create things that are just better than what's existed before. We have respect for what's existed before. You can, you know, do a lot of things using proprietary technology. That's awesome. Right. Like, you can fly to the moon and you can, you know, build certain driving cars in a closed way, in an open way. And we're not saying one is necessarily always better than the other. But we're just saying the open way is our way. If you want to believe in this, if you want to work on those kind of things, come work for us. And if you don't, then it's fine. Like, you don't really need to work for us. That's also okay. You might work with us at some point as well.

Chris Gammell: Right, exactly. Work with the projects, the many projects you're starting or working on. Yeah, that's great. All right. Well, Michael, thank you so much. This has been really interesting. And I'm really excited to try out Reno. So thanks for that.

Michael Gielda: Okay, fantastic. Thanks a lot. Have a good day. Bye-bye.

Chris Gammell: Today's episode was brought to you by the raw, uncut, unsimulated generosity of our patrons. Join the club at patreon.com slash theampower and you'll feel the real-world implications of sponsoring us, like discounts on the atoms of an Ampower hoodie or t-shirt. A special thanks today to our corporate sponsor, Bino.

Speaker ?: We'll be right back.