 Next up, I'd like to introduce Michael Gielda. Michael is the co-founder of M-Micro and the chair of the Chips Alliance Outreach Committee, as well as the chair of the marketing for the Zephyr project. So I get to spend a lot of time with Michael. And he's involved in many open source software projects and is a very strong believer in open source as the best way of doing things, as well as the open hardware projects related to software-driven tools and methodologies such as AI, FPGAs, and ASIC development. He'll be talking about organizing the hardware ecosystem with open source and at Micro's Visual Display Designer. And with that, please welcome Michael. Hello, everyone. I like how I'm speaking after and ask for the second year in a row. And in some sense, we're talking about the same thing. So yeah, I'm going to tell you about a visual system designer we're building and how we're trying to organize the hardware ecosystem with open source. If you're building products, you're probably not of the faint of heart. You're probably pretty brave because before you start, you don't even know what you're embarking upon. The hardware landscape is pretty complex. There's so many choices. There's so many components to pick from. There's software framers, tools. You're going to pick your testing strategy. There's quite a lot of stuff. You have to decide upon and much of this. You have to decide upon upfront because you have to plan for a product that's going to be physically made to plan for availability and things like this. And so the choices that you have to make are extremely interdependent, right? You have to pick your hardware in terms of also the software tools you're going to use. You have to pick your operating system. Perhaps the vendor you pick has some kind of tooling that you like to use or perhaps you hate to use. Perhaps there's chips that you'd like to use but are not available in the market anymore. Perhaps you have experience with a certain chip. So there's so many things you have to think about, but all of them are not free for you to choose from. You have to pick a certain subsection of the ecosystem. And worse still, the ecosystems within that hardware landscape are often competing and disjoint, right? There's people trying to say, oh, I want my competitive advantage, so let me just build my own thing. And of course, sometimes it's good. You need plurality, but very often it's frustrating where you have so many different ways of doing the same thing, right? Like you pick a vendor and then they have their own tooling ecosystem and you're stuck because perhaps you'd like to use a little bit of this, a little bit of that, you can't, right? These are disjoint systems. Fortunately, of course, in reality, if you're building hardware, you are building physical things and there are patterns in the real world. If people are building chips, they're basing those chips on existing IPs. They're not reinventing the wheel all the time, right? They're kind of churning out silicon that's kind of similar in a way and everyone's kind of using similar tools underneath and so on. There's only so many ways in which you can remix all the things and reinvent the wheel here. So in fact, there are patterns. But the problem is the patterns are scattered amongst data sheets. The heads of FAEs, perhaps the internet forums, you know, there's there's only place you have to draw upon to actually figure out what's going on. Like how is this one chip related to that other one and why is this register here not doing the thing I'm expecting it to do? And of course, like if you have experience, you'll start to learn how to kind of go around these kind of problems. But nevertheless, it's always a little bit of a frustration, especially if you're on a schedule, right? Fortunately, we have things like Linux. We have things like Zephyr. We have projects where hundreds of people, thousands of people are working together to uncover those patterns, right? To uncover the patterns, to encode them in device trees, encode in subsystems, as Anas was just saying. So clearly, you're not alone, right? I mean, it might feel like you're alone sometimes. But fortunately, there's an ecosystem to help you and Zephyr and Linux are kind of key to solving some of those problems for us. And my company is providing open source tools and engineering services and helping people join this ecosystem, convincing vendors, convincing product companies to adopt Zephyr, for example, to kind of join this big party and explain to them that it's best if they standardize. They don't just do their own thing if they actually go and do things as they should be done. And so we can say that our work is kind of trying to find order in the chaos. And that is kind of how I like to think about it, because it really helps understand why we're so stubborn in promoting open source. And one of the cornerstones of our work to figure out how the hardware system works is ReNode, which is an open source simulator that, of course, requires us to understand how hard it was working to be able to model it and to be able to represent how it's working. And we've been trying to figure out the hierarchy of the hardware and how can we make things work together. It's been a pretty wild journey since 2010. And in a sense, we're kind of trying to enable a unified workflow. Like we want to put your hardware in your computer so that you can work with it in a streamlined way without having to figure out like, oh, for this board, I have to connect my cables this way and so on. It's trying to kind of normalize the way you work with hardware. Of course, in the end, you will need to have the hardware to build a product. But for many things that you're going to do, we'd like you to be working in simulation because it's just so much more streamlined. And in this endeavor, especially in the last few years, we've gotten to a point where we realized, okay, we can use the data encoded in things like Zephyr to do a really crazy kind of endeavor where we have the Zephyr dashboard where we're testing against several hundred Zephyr targets. And we can run 273 boards as of the time of this keynote. We're taking the firmware that gets compiled for the actual hardware, and we can run the same firmware in simulation. And this is only possible because there's so much data encoded in Zephyr that we can read from. There's device trees, there's configs. We can just kind of parse this and figure out what to do, how to simulate those boards. Eventually, we have to write the simulation models. We can't get that data for free. But the data about how things are connected and so on, this is really, really valuable. This is really helping. And we're doing the same endeavor for Uboot now, and we're working also to bring this to Nadex. So generally speaking, we're trying to figure out how to parse all this data that exists in the ecosystem to just support everything. And based on this data, we'd also build a portal where you can explore the data. Like you take the data, you parse it, you do stuff with it, and then you realize, oh, we could actually show the data back to the users, right? And we have this portal where you can browse the boards and SoCs and SoC components, and you can kind of click through it and figure out, oh, this SoC is actually found on those boards. And it's all there, of course. Like you can also browse the Zephyr GitHub, but it's going to be a little bit harder to do that. With Renopedia, you can also see the results of those CI's we're running, see the firmware samples actually replicate them. You can run them in the cloud. So there's quite a bunch of stuff you can do with Renopedia. But I spoke about last year, so I don't want to kind of dwell on this. In parallel, we actually saw another journey that was in front of us. So we've been building hardware since almost the same time as Renoed, and we've been building PCBs and mechanical design and so on, building real, real products. And if you think about hardware, especially if you're doing open hardware, it's also all about structure. So you're building bombs. You're building schematics. You're connecting things up. You're kind of tracking inventory. You're doing a lot of data mining and categorization and so on, just to stay sane, just to be able to actually build a product. So if you have all the structure, you can actually use it. And of course, if you're in micro, you're probably going to build a portal. And so that's how the open hardware portal was born. And the open hardware portal, even this visualization here, like the similarity to any actual interplanetary weapon systems is completely unintended. So even that portal is kind of generated from components and the visualization is kind of completely generated by a CI flow. And what it is, it's a database of components with KiCut footprints, with Blender models that we're giving to the world. It's completely free. It's open. And this is, of course, stemming from our endeavor in building open source hardware. We have dozens of open hardware boards and all of the components on those boards are in the portal. And you can also use them yourself. You can mix and match them and so on. And we have, of course, photo-realistic 3D renders. These are not photos. These are renders of boards. And the entire portal is kind of built around the idea of again mining this data. So you can kind of browse the schematics interactively. There's a really cool tool called KiCanvas we're using for this. So you can view the schematics in the client. You don't need to install anything. You can look at stackups. You can actually also use this for other boards. So this is not an microboard, right? This is a Silicon Labs board that, of course, on a forum somewhere we found a bomb for the board on Gerbers. So we could visualize it too, right? Because the flow is open. It's kind of completely portable to anything. So yeah, it's kind of cool stuff. But then you start thinking about it and you have Renopedia. You have the Hardware Portal. In some sense, this is the same landscape, right? I mean, SOCs are both physical components and also those entities that you program against, right? So it's just two ways of approaching the same problem. So we decided that we have to build another tool, which is called the Visual System Designer that I wanted to introduce to you today. What it is, it's simply a block diagram editor, right? Like, we take all the data, we expose it to you as a user in the form of a database of components you could pick from, and then you can just connect them up, wire them up on a block diagram level. We're specifically not trying to do a schematic editor, at least not at this stage. It's more of a block diagram editor. And so you can represent existing boards, you can build new ones, and you can kind of just bring order to this ecosystem one block diagram at a time. And of course, you can remix boards, like you can grab an existing board, delete something, add something, and then you can actually generate the device tree from that board. That's kind of what we're really aiming for. And with that device tree, you can also generate a re-note files because the whole concept of the re-note PDF stuff is also based on the fact that we can take a device tree and generate a re-note configuration. So you can pretty much also generate firmware, actually, I don't have a slide for it, but you can do that too. So that, in reality, you can just build some custom simulated hardware and run some firmware on it in a few clicks. And even on a basic level, just communicated requirements in a structured way has been a godsend. It's really kind of useful to give people a tool where they can actually represent their thoughts, where it makes sense, where things are connected in a way that actually is probably going to work. And one more thing, of course, we're kind of connecting that back into the re-note PDF and the OpenHeart portal. So in that kind of sidebar of components, you can kind of go back to the other portals, read more, see what kind of boards this SOC is found on, or perhaps download a KiCat footprint for the component you want to use. So it all becomes an interconnected system of frameworks. But there's more. We're also, I was talking about this two weeks ago at the RISC-5 summit, because we're also very active in RISC-5 and OpenHardware. We also want to enable people actually building ASICs with this. I mean, obviously not building ASICs as in, designing RTL, but in sense of the architectural development and exploration and trying to figure out what your chip's going to do. We think it's going to be a useful framework. So if you have those IP blocks, and you want to build an SOC, we believe that this is going to be a good tool for you as well. And what makes us believe this even more is the fact that we also have the ability to simulate ASICs. And we can also co-simulate with variators. So if you have real RTL for your IP blocks, you can use variator to co-simulate them. And of course, if you can wire it all up in this diagram editor, you're going to find it a bit easier to reason about your system. And of course, like we've been very active in machine learning as well, helping people build machine learning accelerators. And we believe there's a huge use case there as well. Ironically, the tool itself is coming from our AI team because the AI team built a pipeline editor for their own AI work so that it can hook up AI models. And we just told them, hey, what if we used for hardware? And that's where we are. So it is really related to it as well. So for us, it's just the beginning. Obviously, we haven't really gotten as far as you would like. And there are many things that I'm not even speaking about that I haven't in mind for this. But what's important to understand is that by using this designer, by even creating it, by having to catalog and document and figure out the hierarchy for all these things, we're learning so much about the hardware that we're targeting. And we're also talking to people figuring out those hierarchies. We're also feeding this data back because we're able to contribute back into Zephyr, for example, adding stuff to Compat Strings or trying to figure out new ways to represent data. I loved Marty's talk about the system device trees. Yesterday and so on. It's like there's so much going on in this space, also with Risk 5 and Chips Alliance and so on, that we believe we can really make a difference here. And this also connects very well to the idea of software bombs and hardware bombs. So yeah, we just think it's a very good opener for something really cool. And so we'd like to really talk to everyone that's building SoCs, building songs, boards, components, sensors, so that first of all, we can figure out how to represent the things. And second of all, we can figure out a way to just expose them in the visual system designer for you. And also, of course, if you're a product developer, we feel your pain. You can come to us and get our help to actually build things. But while we're building them, we're also going to improve the system. We're also going to represent your things in the blood diagram editor. We're going to add your stuff to the libraries and so on. So please do come to us. And if you're interested in these things, we have a booth. If you just go out, you'll see us. So we're very happy to talk to you and try to figure out how to organize this ecosystem a little bit better. Thank you very much.