#687 – The RP2350 with the Raspberry Pi Team

Chris Gammell: This is The Amp Hour Podcast. Released January 28th, 2025. Episode 687. The RP-2350 with Raspberry Pi Team. Welcome to the Amp Hour. I'm Chris Gammell of Contextual Electronics.

James Adams: I'm James Adams, CTO Hardware, Raspberry Pi. I'm Luke Wren. I'm a Principal Engineer at Raspberry Pi, working on digital design and firmware.

Liam Fraser: I'm Liam Fraser. I'm also a Principal Engineer at Raspberry Pi, doing a mix of hardware and software.

Chris Boris: I'm Chris Boris. I'm in the commercial team at Raspberry Pi, helping customers out in America.

Chris Gammell: Awesome. Well, welcome back, everybody, and welcome, Chris. You're a new face here. I'm glad to have you all back. Man, I think we should make the... This is not quite annual tradition, but I think it's close enough to annual that I'm going to just say it's the annual Raspberry Pi drop-in for the Amp Hour. It's great.

Liam Fraser: Thank you. Nice to be back.

James Adams: Absolutely. Good to see you.

Chris Gammell: So, RP-2350, that is the new hotness, and we're going to be talking about that here today. Let's get a little recap. I mean, so we last recorded with Liam and James, I believe, back in 2023. We were looking at the timing, and it must have been out of my mind because I was sleep-deprived because I had a new kid, and these guys joined me anyways. And it was cogent enough that we got to hear about some stuff. But we're going to also be talking about some... I think back then, it was not actually out yet, right? So, that was still talking about... Oh, that was the RP-1. My apologies. Yeah, so that was the RP-1 was being released. That is the helper chip on the CM5? No, sorry.

James Adams: Raspberry Pi 5, yes. Raspberry Pi 5, Southbridge.

Chris Gammell: Got it. Southbridge, yes. Okay, so now, RP-2350. You guys have so much silicon starting to get confusing. James, could you maybe give us a high-level overview of kind of just evolution, 2040 to 2350?

James Adams: Well, I'll put RP-1 in there anyway first because that's the first chip we ever started working on, and we talked about that in the previous episode that we did. So, I guess people can go and listen to that. But RP-2040, our first-gen microcontroller, dual Cortex M0. So, I mean, we learned a lot, right? What's significant about this? What were we trying to do? We were trying to design a microcontroller sort of almost with a blank sheet of paper, right? The way a lot of us within the business, you know, we're chip designers. We've done a lot of this stuff. It's kind of like, well, how would you design this thing if you had a clean sheet? And using what we'd learned over the many years of doing other sort of SOCs and ASICs and mostly bigger chips, right? So, we're not naturally or we weren't designing microcontrollers in past lives. We're designing the big SOCs, the stuff that's gone on the pies. And so, this was a first stab at it. And I guess I'll let some of the other guys sort of give a little bit more color. But I guess overall, we wanted it to be relatively cheap or very cheap on a fairly modern process node, which obviously helps with the price. Kind of deterministic. So, you could reason about how the machine worked and extract a lot of performance out of it, even though we had these kind of too low-end cores. Again, Luke could probably put some more architectural and Liam notes in here. And so, you know, we learned a lot with that. What it didn't have was any kind of security. And it didn't really have any, not a lot of thought to power consumption, right? So, you could put it into some deep sleep coma mode. But really, it's not a very low-power microcontroller, right?

Chris Gammell: And that's the 20-40-year speed. This is the 20-40. So, this is our kind of almost like... That was the clean sheet, right? That's the clean sheet. Got it. So, we're kind of like casting our mind back. RP-1 was in process. You're like, no, we're going to make a... In the meantime, while that's going, RP-20-40 is started. Clean sheet, make this thing. And it's not... You can't do everything on the first go. But now... That's right, yeah. You're setting the stage. I get it.

James Adams: You kind of have some spaces when you're designing chips, especially if you're waiting for the next version to come back. So, as well as RP-1, we sort of had a little bit of parallel and sometimes more focused bits of sort of serial work on RP-20-40. So, yeah, we learned a ton of that from the RP-20-40 program. And, of course, the new shiny is RP-2350, what we call Amethyst internally, which is the codename for the... Can we bleep that out?

Chris Gammell: Can we bleep that out?

James Adams: No, no, that's fine. You can call it. I think we probably called it Amethyst in another way. That has thoroughly leaked at this point. Got it. Okay.

Chris Gammell: Well, what I can start doing, though, is I can just start naming other gemstones and be like, oh, yes, well, now we have Peridot. Peridot? I don't know. You know, whatever the gemstone is.

James Adams: So, yeah, other internal projects may be named after other gemstones, but also maybe not because we seem to have tried to stick to a naming convention and that's only failed with some of the things.

Chris Gammell: Yeah, naming stuff. Naming stuff.

James Adams: Yeah, it's like things have names.

Chris Gammell: Okay.

James Adams: Don't read too much into it. But so, yeah, RP2350, Amethyst, the big thing was to add the security and the power states, really. I guess that was the idea. And it was supposed to be kind of like a fast follow to RP2040. It took a bit longer than we expected. But I think the results are good. And, of course, well, I guess what we learned was really power and security take an awful long time. And actually, it was a good thing that we did try and do them the first time around.

Chris Gammell: Yeah. Yeah.

James Adams: So, okay. That's my high-level view.

Chris Gammell: Okay. Those are really good. Security and power are definitely good things to drill. I think we're definitely going to drill down on those. What about some other? So, like you mentioned, Luke can maybe do some other architectural type things. Like one thing that always stood out to me from the data sheet is kind of the dual dual core. Is that a fair way to call it?

James Adams: Yeah. So, well, so the original brief for 2350 was take 2040, put dual core XM33, security, low power, six months. And it took a bit longer. And one of the things that snuck in a little bit of feature creep was the RISC-V cores. Because Evan's been trying to get me to put RISC-V cores in something for a long time. And we just kind of decided this was the chip. And I went home and I designed something that fits exactly into that socket. And, you know, they are small enough that you can kind of sneak them in without increasing the die size. I'd say they are mostly valuable on this chip for education. And that means both this chip in an educational context and also for our education in working with a new architecture and learning to implement these cores in the context of a traditional system like this.

Chris Gammell: And when you say fit them in that slot, is that like available silicon? Is that like the hooks that are using?

James Adams: I mean the hooks. I mean, so, you know, I worked on the processor integration for R20 through 50. And I kind of knew what shaped hole I wanted to fit a processor into. And it's designed to fit into that hole.

Chris Gammell: When you say design it then as well, it's taking kind of an off-the-shelf core that's already designed and kind of modding it or ground up RISC-V?

James Adams: It's completely, it's my from-scratch implementation of a RISC-V core.

Chris Gammell: That's really cool.

James Adams: I mean, it started with another one of my from-scratch implementations called Hazard-V, which is a five-stage pipeline that therefore has a lot of hazards. And I sure need three stages. So I had it running, you know, core marketing simulator in about a week. And then the remaining 10% of the work took about three years.

Chris Gammell: Yeah, that sounds right. Yeah. You didn't just take a week and then YOLO it? The YOLO core?

James Adams: I mean, once you have something running benchmarks, it's kind of fun to play with. But there's a lot of stuff you have to add to a processor to make it actually be useful. You know, hardware debug is kind of a big thing. Security hardware is a big thing.

Chris Gammell: And when you say then also like the kind of the hooks are there, is that like because just as an example, I know there's a bunch of external like third-party silicon cores that are in there. Like the spy bus, I2C bus, I remember from the docks and stuff like that. Sure. Does that bus get extended to like kind of the highways going past N33, but then it also connects to where the RISP-5 processor is?

James Adams: Yeah. Hazard 3 implements a bus protocol called HP5, which is a standard interface for attaching, you know, small scalar cores to memory. And you can detach another processor and attach Hazard 3 in exactly the same place. And everything talks the same language. Yeah. So things like Atomics working across different architectures.

Liam Fraser: Okay. Sorry, Luke. I was just going to say part of the reason that it's not sort of a four-core microcontroller is because architecturally, everything was designed for two cores. Yeah. So it's easier to sort of have a mux on the actual processor core itself. It would have been a much bigger change to, not a much bigger change, but like a simple example is like all the GPIO pins are designed to be able to interrupt processor zero or processor one. And then if you add two more processors, you've then got to rework all that kind of stuff. And it sort of, it grows as a problem. And also the more sort of masters that you add to your bus fabric. So if we were to add two more processors, it's then becomes harder to synthesize and meet timing and all that kind of stuff.

Chris Gammell: One thing that I always think about is the cost of adding stuff seems pretty high in silicon, but maybe you guys had kind of a chunk available. Like, was it, Luke had said that like Eben wanted to have something in there, but is it, was it budgeted for that space-wise or was it more like, well, you get a, I'm going to take a total guess here. You get a five by five, you know, die size and you can just fit in whatever you fit in.

James Adams: So the, the layout of this chip doesn't quite look like what you'd see if you see like an Intel or Apple die shop where it's all lots of little rectangles put together. So all of the standard cell logic in this chip is a single layout region, plus a separate one for the always on logic. And so it's all kind of squishy and compressible in the sense that all of the interconnected logic cells are placed as close to one another as they can be. And then you fill up the remaining space with filler cells. And when you add logic to the chip, it doesn't necessarily get bigger. You just drive up the utilization. And so routing gets harder and so on.

Chris Gammell: I see. Okay. So more crunching, crunching on the supercomputers, huh?

James Adams: Yeah. So the size of the chip isn't increased by adding logic to it necessarily. And they're pretty compact. Yeah. That's my roundabout answer. We have to not compare it to the ARM cores. So. I guess the fact that, yeah, you're not. Having this extra bus interface as well, right? It's kind of like, you know, hard mucks one way or the other. That also helps.

Liam Fraser: Yeah. Also, we gave ourselves more space because we added more pins. So because it goes to 48 GPIO pins, that naturally gives you more area on the inside to add logic to.

Chris Gammell: Got it. Okay. So then that kind of did drive some of the available space. It's just the large, like they're big landing pads, right? For like the wire bonding or I guess. That's right. Yep. Is it flip chip? I don't know how, what the end is. It's wire bonded.

James Adams: Yeah.

Chris Gammell: It is wire bonded.

James Adams: So you do, you do tend to, there's quite a lot of iteration with this stuff. But yeah, you're either what's called pad limited, which is the pads around the outside. You need a certain number for your feature set. And that means you've got the space in the middle, you know, because your X and Y is fixed. Yeah. Because you need to get the pads in. Or core limited, which means, yeah, the core is bigger than the pads and you could shrink it if you chucked some logic out. I think actually, in the end, it was very well balanced, this one. It is very well balanced. Hazard 3 helped out with that. And the core utilization was maybe a little bit higher than we would have been comfortable with, but everything fit.

Chris Gammell: Well, and then some of the practical stuff as well. Like, so there's the shared resources that is muxed. So then when I looked at some of the firmware that was implementing it, it's like you issue a kind of a boot up command and it's just saying A or B, right? That's kind of the idea.

James Adams: Oh, so we have a mask ROM on the device, which contains the boot code. And that will go out and look in Flash, for example, at start of day and retrieve the code that, you know, then eventually launches the user program. And you need to have some code on the chip to implement things like the cryptography for secure boot. And so there's a little binary header on your program that's stored in Flash that says, yes, I am a program for this chip. I'm this big. My entry point is here and so on. And there's just a flag in there saying if it's an ARM or a RISC-V binary. And so if you're an ARM core and you see a RISC-V binary, you reboot into the ARM cores. Sorry, into the RISC-V cores.

Chris Gammell: Maybe now for Chris as well, like when you guys were thinking about this sort of thing, you know, now you've had this out in the marketplace. Where are we seeing the kind of implemented, obviously me as a sometimes hobbyist, sometimes professional. I think sometimes professional is a good title for me generally. Sometimes professional. Chris Campbell, the sometimes professional. Where are we seeing this kind of thing going in, both, you know, production level, maybe hobbyist level as well?

Chris Boris: Yeah. So all sorts of different applications, to be honest. Many of the first customers for 2350 were existing 2040 customers who were able to basically take their 2040-based designs and drop in 2350. They're not pad compatible or drop in. You know, they're drop in from a software perspective. But the actual hardware design needs to be tweaked a little bit to take a 2350. Although the packages are roughly the same size, but there's a, you know, the hardware needs to be tweaked for 2350. So a lot of different companies jumped on that and released 2350-based versions of their existing 2040 products. And that's all sorts of different things from hobbyist boards to all sorts of other commercial products. But in terms of sort of net new customers for 2350, there's actually been some really fun ones. One of my favorite ones is actually satellites. So it turns out that 2350 and 2040 are actually very radiation resistant because we don't use on-chip flash. 2350 boots from external flash. And that flash could be all sorts of, you know, typically on most products, it's a quad spy external flash chip. But it could be an external MRAM chip. And MRAM happens to be extremely radiation resistant as well. So if you pair an MRAM chip with or a mast ROM with a 2350, you actually end up with a pretty cool radiation resistant processor system. And it turns out that some early customers of 2350 took their parts and did some radiation testing on them. And it turns out that they're very suitable to fly. So hopefully in the next, you know, year or so, we'll start seeing 2350 on the station in orbit.

Chris Gammell: Orbiting the Earth. Yeah, that's cool.

Chris Boris: Which is very exciting. Not super high volume, obviously, but really cool. So definitely wins the coolness factor. Certainly in my book anyway.

Chris Gammell: Yeah, I think when you guys are designing the Peridot or the Opal or whatever the next one is, I'm sure you guys, you know, you get that in the back of your mind. You get those good feels that you're making cool. I mean, you're already making cool things. But yeah, that's good.

Chris Boris: Pretty cool to be able to look up, you know, and see your stuff in space. Yeah, exactly. Looking forward to that.

Chris Gammell: Really, really, really hard.

Chris Boris: And I think there's already some 2040s up there as well. But 2250 is, you know, even better. I think it's actually going to be the main flight computer for a number of different satellites. Small sats mostly.

Chris Gammell: I would be remiss if I didn't bring up the impeccable timing you guys had with the chip shortage. And just, I mean, it was a great chip. The 2040 is a great chip. But boy, oh boy, was your timing amazing. Just, and like, and that, that has, obviously you guys have made good products. And it's, you know, interesting things. And you're listening to your audience. All of these good things. But boy, timing is just really, you know, all the people that were 2040 and now 2350. Like, they may have been 2040 because of the shortage. Like, it's just, you guys will always have that special place in my heart. Because like, I mean, I've got stuff right here that has 2040 on me. Like, yeah, you know, it's great.

Chris Boris: It certainly didn't hurt at all.

Chris Gammell: Are you guys cheering for another shortage? Is that what I'm hoping you're hearing? Oh, God, no. Oh, God, no.

Chris Boris: While it happens, one of us as well. Yeah, that's right. Yeah. It's great for the microcontroller product line. But not so much.

Chris Gammell: Don't you guys love calling the fab every day? Please, faster. Yeah. So that's one application. But there's a bunch of others I could chat about as well, if you'd like. Let's get one more. And then, yeah, I mean, I think probably some of these, too, that they lead right back into some of the stuff. I'd love to hear about power stuff, too. I think power is definitely right down the lane of. Are there any power ones that you're seeing out in the application space, Chris, that are really taking advantage of the new power stuff?

Chris Boris: So more than really power, it's actually just the general level of memory and compute for the very low price point that we sell the chip at. So power consumption. I think those sort of power sensitive applications will probably they actually take longer to build. So we haven't sort of seen so many of those to date. But we've seen plenty of things that are like high performance, hard real time stuff, especially things like drones, motor controllers, industrial controllers for sort of things with, you know, inertia. So lots of motor control, VFT drives, that kind of stuff, robotics applications, things that just require lots and lots and lots of compute for, you know, are sort of price sensitive in a lot of cases because of volume. So, yeah, there's quite a few of those.

Chris Gammell: Is there on board, there's encoders? I'm just looking through the data sheet now. So there are encoders on board. I mean, there are other hardware peripherals that actually help to feed into that kind of application space.

Chris Boris: A lot of customers are using PIO for that.

Chris Gammell: Oh, of course. Jeez. Maybe we should go right back. Yeah, that's another good topic here to touch on, too. Let's chat about PIO. Yeah, yeah. So PIO has changed. Obviously, you guys introduced down the 2040. It's on the RP1, I think you guys said last time you were here, but not super visible to the user. But then now it's been enhanced somehow as well. And I will say up front, I am not a PIO user in any way, shape or form. I am clueless. So maybe a quick reminder of what it is. How about that for other clueless, for our listeners that are clueless, not me. I mean, our listeners that are clueless.

James Adams: Yeah, sure. So PIO is a system of essentially really tiny stripped down processes that are excellent at high speed, highly deterministic bit banging of external interfaces and not so good at everything else. But they're tightly coupled to the processes in the system. And the idea is you take the timing sensitive part of a software peripheral. You push that onto the PIO cores, you offload it. And then you talk to them as if they were a regular peripheral through the DMA with the processes accessing FIFOs and so on, but maybe pushing more logic onto the processes. And the idea is if you want more UARTs, you can actually commit this soft resource to be more UARTs for you or more I2C or whatever else you want. But also it lets you do things that you would never put into hardware. So, you know, one of the examples we have in the data sheet is WS2812 LEDs, which we can do with zero overhead just by DMAing into a PIO state machine that is doing the little funny pulse width modulated serial you need for WS2812.

Chris Gammell: Yeah.

James Adams: You'd normally have to do that.

Chris Gammell: Nanosecond timing, right?

James Adams: It's, yeah, I mean, if you're trying to, there's some variation between the different serial LEDs on the market. If you want to get all of them, you need to get some pretty tight timing on it. Yeah. Yeah. And, you know, normally you do that with a SPI peripheral or something or an I2S by taking your bits one by one in the processor and assembling a byte buffer of pulse width modulated values, but you can just completely offload it into hardware. So it's for doing deterministic bit banging tasks.

Chris Gammell: Yeah. And that actually does feed right. So like encoders, you're saying as well, Chris, that like that was another kind of listening to little propellers and number of counters and stuff like that?

Chris Boris: Yes. We've got some customers out there who are using 2350 for real-time motor control stuff and robotics applications. Cool. And PIO plays a part in some of those designs. Yeah.

Chris Gammell: Hmm. So now what is different then? So 2040 to 2350, what is the difference then?

James Adams: I'd say it's more evolutionary than revolutionary. We've kind of tried to take a lot of feedback on board and fix the little things that irritate people. One of the things we hear a lot is so PIO is kind of a little four core subsystem and we have two of them on up 2040. So you have effectively eight PIO cores that you can offload IO tasks to. But those two four core clusters are not well coupled to one another. So you can't really communicate and synchronize between them. And so there are some features for communicating between those clusters on 2350. There are features for doing things like stopping and starting state machines in a completely synchronous way. And also we just pumped up the count because it's a, you know, from our point of view, that's a low engineering effort way of adding a feature. It's also just something people ask for.

Chris Gammell: Yeah, I think the first time you guys were on, someone was doing a VGA thing. I remember that and I've seen some of that since. But what's some of the wild stuff? Let's get an updated version of wild PIO stuff.

James Adams: I mean, I'm still fond of the DVI stuff. I got working back on up 2040 because it was just something we didn't design it to do. So we've seen a lot of people doing CAN bus with RP2040 with PIO. And actually CAN is kind of a fiddly, it's kind of like SQL C where you think it's just a shift register. And actually there's, if you draw out the whole flow chart, there are lots of different paths through it. And getting all that running on a bit bang system is actually quite impressive. Okay.

Liam Fraser: Yeah. Someone's done USB host controller and USB device controller all with PIO as well. Oh, wow. That's a good one. I think there's an Ethernet one that actually bit bangs like the Ethernet protocol itself only at 10 megabit. And you need a bunch of resistors to make it work.

James Adams: But yeah, there's a thing. RMII, I think I've seen, we've got someone talking to us at the moment who's looking at doing ULPI. So talking to a ULPI, USB 2.5, just, you know.

Chris Gammell: I don't know that one. Okay.

James Adams: Oh, so it's a parallel bus for talking to a USB high speed PHY.

Chris Gammell: Okay.

James Adams: And then you run the USB Mac, so to speak, in software.

Chris Gammell: Yeah, it's pretty wild stuff. I mean, there's not like a, I remember looking at like the megahertz count didn't go, like it was like 120 to 140, something like that. What was the difference?

James Adams: It was 133 up to 150. Okay. So, you know, this chip is a little harder to get up to timing than RPA2040 was because you have more complex memory protection in the processors. You've got more memory. So more routing to do to get the addresses to the RAM from the processors. And you've got more bus managers, so more concurrent accesses on the bus. And so there's more MUX involved. So getting up to timing is hard. And we added a little bit of LVT cells during layout too. So you can, one of the options you have when you place down standard cells. Voltage timeout? Low threshold voltage.

Chris Gammell: Okay.

James Adams: So you can, during layout, you can tweak the transistors to have different VTs and that gives you faster but leakier transistors or slower but less leaky transistors. And so you can, you know, at constant leakage, try and push the timing where you need it and then relax it where you don't and just push the freaky little higher. So, yeah, it was 133 up to 150. But the actual clock for clock performance is much higher.

Liam Fraser: It's worth noting as well that PIO was also extended to talk to the top, the new GPIO pins that we've got. I think we went from 30 to 48, didn't we? Yep. And then there's another sort of feature which isn't necessarily obvious externally. But one RP2350 DAI supports two packages, a 60-pin package and an 80-pin package, which is tricky to implement for us because there's an internal pin called package select, which is either 0 or 1. And then based on that, you sort of reduce the number of GPIO pins you have. But you can't just take, like, you know, you can't just use the bottom 30 GPIOs because it's kind of like you pick every other GPIO in the, around, you know, as around the edge of the chip. So there's lots of funky address remapping and stuff based on, because you want all the GPIOs to turn up as GPIOs 0 to 30, even though you might actually be talking to 0, 1, 3, 5, et cetera, based on the package select. The physical pin name versus like that.

James Adams: If you picture bonding out the DAI in a smaller package and you take, you know, GPIOs 0 to 30, and you take them all the way around the perimeter of the smaller package, you end up twisting the bond wires, and it's impossible to manufacture. And so, yeah, GPIO 47 in the big package is GPIO 29, the small one, and there are about 100 different places we have to hide this from you in hardware. Yeah.

Chris Gammell: Well, and I noticed on the website as well, the packaging, so you guys also now have memory packaging as well, right? So you guys stack it and...

James Adams: That's right. So we are working on these stacked. So we put the flash inside the package. We have internal samples of these. I don't think we've released any samples to customers yet, Chris, or have we? Just a few. Okay, yeah. But they've not, unfortunately, gone into mass production just yet.

Chris Gammell: Okay. Yeah, that's great. I mean, like, that is for tighter applications. I could see that being really useful. Are there other benefits to having it localized versus having an external, like, execute-in-place style QSPY? It's a physical style. A little bit of security.

Chris Boris: And security, is it? Yeah, like a teeny bit of security where, you know, you can't probe the bus signals quite so easily.

Chris Gammell: Not with that attitude, you can't.

Chris Boris: I mean, it's still, you know, yeah.

James Adams: You don't have to be very determined to get past that because they are still brought into package pins. Ask us if the amp hours say, ha, ha, ha, ha. Yeah. It's also just a part selection thing. You know, something we get feedback we get a lot is if I put an ARPA 2040 on a board, I have to select a crystal. I have to select a flash device. And just having it be in package means one fewer part to select, one less unique on your bomb. It solves the customer's problem. Yeah, it is a little bit smaller. I think we haven't released it because we have had, because we work on these packages and try and produce them at low cost, our kind of packaging vendor, you know, you have to stack the die effectively one on top of the other.

Chris Gammell: Yeah.

James Adams: And it depends on the size of the dies. And of course, you've got to kind of like bond both of these packages. And we have had a few issues with doing this in the kind of low cost way that we wanted to. I think we are now solving the problem. It's not a big issue. But, you know, these things always seem to take longer than you expect. Oh, totally.

Chris Gammell: I guess another benefit from me as a hardware designer is that like the not having to deal, it doesn't happen super often, but like, you know, having end of life on a particular external memory component. Basically, you guys are abstracting that for me because I expect buying that. Sorry, I don't remember the name. The 2357, something like that. Whatever the part number is, the 54, right? It's stacked together. And I expect just kind of the default behavior. I'm sure you guys have end of line testing. That's like, oh, yeah, the memory works, even though there was a package. You're sorry. There's a silicon change on the memory vendor. For me as the user, I just get to be like, easy. Like, that's worth paying for sort of thing, you know? I am lazy. Yeah. That's what I'm trying to say. So that's great. That's great. Cool. Well, let's talk a little bit about, so I'm going to go to Power now because you guys mentioned Power. And then I'd love to get into security too because you guys released a blog post recently. And that's been interesting about the security stuff. I'd love to get an overview of the features, but then also some of the things that have been coming out around there. So first off, Power. So, you know, kind of AB 2040 to 2350, what is some of the new lower power modes? And then I guess because I have you guys here, what are the challenges of doing that sort of thing too, you know, like to go lower power?

James Adams: Who wants to answer that one?

Liam Fraser: Liam? Yeah. Yeah, I can probably cover that. Yeah. So RP2040 is all one power domain. So it's either on or it's off effectively. There's some sort of low power retention modes in the memories where you can sort of, you can put them into a lower power state, but the contents is still there. So you're not turning the memories off. You're just sort of, you're unable to read them. So you're saying, I don't need to read you, turn your power down. And then if you want to read them, you can turn them back on later. And then we also had some modes where we had like a sleep mode where you could say, I only need to use the UART. So turn off the clocks to everything apart from the UART, for example. Yeah. And that would get you a bit of power saving. And then we also had like a dormant mode where you'd stop all the clocks until a, like a GPIO pin went high would be the usual application. And that, the dormant mode is quite nice because from a sort of software point of view, time just stops. And when you wake back up, you carried on from exactly where you were.

Chris Gammell: This is like, this is like cross marketing for severance or something like that. Yeah. The new season of severance coming out now, right?

Liam Fraser: Yeah. So, yeah. So then in 2350, we've introduced something called PowerMan, which is hardware that manages the sort of power states of the chip. So we have the processors and all of the sort of bus fabric and peripherals. We call that the switched core. And then we've got, we've split the SRAM into sort of two main banks. So there's SRAM Bank Zero, which is the first 256K. And then there's SRAM Bank One, which is the second 256K plus the two additional scratch rams. And then we've also got the EXIP cache, which is another 16K. And you can actually, so you sort of, I think your lowest power mode is you can actually, well, your lowest power mode is where none of that's on. And just the bit that's called always on, Aon is on. But your sort of lowest functional power mode where you've got processors and some RAM would be to use the switch core and just the EXIP memories. So basically all the processes.

Chris Gammell: The critical things in the EXIP and then you turn it in. Yeah.

Liam Fraser: So you get 16K. So you've got to do a bit of code golf to fit what you want in there. Yeah. And then, and then otherwise you can, you can either use half the RAM or, or sort of all of the RAM. But the, so the Aon part of it has the, has the power manager and it also has some, like a 32KHz oscillator that's on board. So you don't need an external crystal to use that. It's not super accurate. It's, you know, 32KHz-ish plus or few, you know, plus or minus a few KHz. Um, but it's, it's enough to sort of, uh, go to sleep every few seconds or go to sleep every, you know, however often you want. Um, the, the easiest way to use it is to sort of effectively, effectively, if you turn everything off, you're doing a, doing a fresh power on. Um, so, so if you say, you know, turn everything off and wake me up in five seconds, that's the easiest way to go into low power. Um, it, from a, from a sort of software point of view, because if you turn the processes off, then, and you do a fresh boot effectively, cause, cause everything's been turned off and then you turn back on, then that's quite easy to reason about because you've, you've just started again. Um, if you want to go asleep and sort of retain half of your memory, then you've got to sort of boot up, but then go, Oh, hold on. Don't boot in the normal way. Yeah. Because half my memory is still retained. And, um, yeah, getting the software right around that is, is, is, uh, is quite tricky. So we're still sort of, um, we, we have some examples definitely, but we're sort of working on our APIs for that and sort of improving how we can help users manage the, their low power states.

James Adams: Um, it turns out that, uh, it's, it's hard to build these things with all these different states. Cause of course your, your space of possibilities of what's on and what's off like explodes. And then it's hard to write the software when you have a machine. Yeah. Yeah. So always around the power is, is kind of hard and, uh, gets kind of exponential quite quickly.

Chris Gammell: Um, yeah, the software, the software hardware kind of dual opity there, like that, that dual nature seems really tough. I mean, you guys have primarily the C SDK, right? That's the, that's the main development feature vehicle rather that Raspberry Pi offers. And then other people build on top of that. Is it, is that the right way to think about it?

Liam Fraser: Yeah. I think, I think that would be fair to say. Yeah.

Chris Gammell: Yeah. So you guys don't do like an Arduino port or like a MicroPython, like other community members do that sort of thing on top.

James Adams: Yeah. So we have our C and C++ SDK and then MicroPython, uh, is, you know, using our SDK APIs to implement the MicroPython APIs. Um, there's an Arduino port which uses the SDK APIs. Um, and it's also just reference code for other ports. So the Rust port, you know, they can read our SDK source code and understand how to use the chip.

Chris Gammell: Yep. Okay. That's great. That's cool. And so then the APIs are ultimately like calling these different modes and saying, switch this on, switch this off. The thing I didn't understand what Liam was saying is like the, so like when you said like the having to, I understood the, the having to shuffle it yourself, but just from a practical, like, I don't, I don't, I don't, I've never had any thought about that. Someone's always done that for me. So I'm like, Oh, what do you actually do there? I'm very, very well taken care of. That's what I'm trying to say.

Liam Fraser: Yeah. Um, yeah. I mean, it, it depends a lot on, on the application, how much, how much memory you need and, and what you, you know, what you want to store and how much you want to go to sleep for. Um, I think we're still waiting to see what the sort of applications are. I mean, the, the, the usual, you know, the usual thought for like low power is, um, you know, temperature sensor that wakes up every 15 minutes or, or that kind of thing. Um, but yeah, as Chris was saying, I'm not sure we've got so many low power, um, low power customers yet using those features. So it'll be interesting to see what, what kind of things, uh, we get used for.

Chris Gammell: Yeah. Okay. Well, that's, that's great. I mean, uh, in terms of the other peripherals that are maybe, maybe mentioned this and I missed it because I was thinking of a power man joke in myself, in my head. Uh, it's coming. Don't worry. Uh, the PIO and the, uh, like other peripherals, like the kind of the bus peripherals that are around there as well. Those kind of all are just default shut off when like, those are another thing you can shut off or those tied to some of those half and half memory things or, um,

Liam Fraser: so yeah, all the peripherals are in the same group as the processors. So switch, so the switch core. So you're, you're either sort of all, all on or, or you're not in, in terms of like the hardware and then the memories are separate. So you can choose to leave some of the memories on regardless of what your, if your sort of main processes are on or not in case you wanted to save some state. Got it. Um, and there's, there's trade-offs there as well, as well, because, um, you know, booting from flash versus loading, you know, having code that's already in SRAM, depending on how often you're, you're, um, going to sleep, you need to sort of decide what's best for your application.

James Adams: Cause it, you're going to, going to use energy fetching stuff out of flash again. Right. Versus how much you've, you're using up in leakage, leaving the RAM turned on. Right. So that I think the pattern, is it fair to say, Liam, Luke, uh, it's fairly granular. Right. And so, yeah, it really does depend on the application and what you care about. There is kind of a curve of trade-off between, um, wake up latency and your, your actual, you know, power dissipation in the, in the low power state. Um, also from a design point of view, you asked about powering off peripherals. Um, you're, there's kind of a pressure to have as few power domains as possible because it improves your power routing integrity because, um, you have a load switches kind

Chris Gammell: of in line, that sort of thing.

James Adams: Uh, I, I mean, I think you would probably not actually have any switches in series just because that's actually where a lot of the IR drop is. Um, but if you just think of the, the power distribution grid that is over the top of, um, the chip and it's distributing the core power supply down to all of the, all those low voltage, um, digital cells, you don't want to chop that up too much because you end up taking more circuitous paths through it and you get, you see a higher source impedance. So we want to have as coarse the power domain as possible while still supporting, you know, the use cases we need. And we decided we have only two logic power domains. We have the tiny always on domain, which basically contains, you know, the configuration, the, the power up, power down sequencer, and a few scratch registers that let you get in and out of that state. And then the rest of the chip.

Chris Gammell: Like I said, I'm, I'm often working with someone else's stuff kind of at higher, higher, uh, levels of, of software and stuff like that. And so I, I'm mostly, I'm thinking about like, Oh, one thing I, one switch that I have is like, I turn off a UR to turn off an I square Cs. That's where the, where my question was coming from. Not, not actually understanding. Yeah.

James Adams: I mean, you can disable the clock to a UR and that saves you some dynamic power. You cannot individually power down the UR. Um, and this is also a placement density thing. If you start having regions defined for this is the UR, um, you're actually losing out on error. You could be placing more logic in.

Chris Gammell: Right. And that drives it. Yeah. That makes sense from the, the kind of the squishy nature you mentioned earlier on with the placed in route and stuff like that. This it's a, it sounds like just to map it to my own experience of like laying out PCBs, like you said, like you don't want to have a power plane that's like super snaky and like a bunch of them in between. And yeah, you could start to have weird effects.

James Adams: It's exactly the same thing. Just a lot smaller.

Chris Gammell: Yeah.

Speaker ?: Yeah.

Chris Gammell: Yeah. Right. Right.

James Adams: And of course you have to worry about which bits are on and which bits are off. And if, if the stuff that's on is trying to talk to the stuff that's off, what happens? Uh, therefore you end up having to, but obviously switches in, but then like sometimes isolation. So if your wires are trying to talk to a thing that's turned off, what happens? So you end up with the cells across the boundaries that make sure that that's electrically safe.

Chris Gammell: Yeah.

James Adams: And other strategies to, if the bus is trying to talk to some, something that you don't get, uh, anything, you know, it doesn't lock up because nothing's there. All of those kinds of problems feed into the, into the kind of design thinking and can, yeah, it can get, it can get quite complicated quite quickly. So keeping it simple is always better if you can.

Chris Gammell: Okay. Great. Well, now the important question, will Power Man be an animated character like AVR Man used to be? AVR Man? AVR. Do you guys remember that? It was like from Maker Fares, like very, very early on. No? You don't have to, you don't have to comment to other, other companies, mascots. I'm just saying that it lives out of my memory of AVR Man being a mascot that went to Maker Fares. So if Power Man wants to go, I guess we'd have like a raspberry on the chest. Could we force that on the world really?

James Adams: I don't know.

Chris Gammell: Is that fair? No. No. We just dreamed it up here. So yeah. That's good. Okay. Let's, let's talk. Let's get into, there's, there's a hard cut right there. Let's talk security too. Yeah. Right. Right. So let's talk the security stuff too, because you guys just released a blog post. There was also a bunch of talks at 38C3 around the 2350. Actually one of our former guests, Aiden Cullen did a thing and it was called out in the thing as well. And I saw a couple other names I recognized. So maybe we start with the blog post and then, actually no, let's not start with the blog post. Let's start with kind of the new features. Cause you mentioned 2040 to 2350, what are the, you know, what are the things that have been included that, that make it different, make it better? That sort of thing.

James Adams: Yeah. So we kind of have three goals with security. One of them is to control the code that runs on the device and make sure it is your code. One of them is to protect sensitive data that is stored either on device or on an external flash device. And the third one is to allow you to separate compartmentalize trusted and untrusted pieces of software running on the device. Um, so that last one, for example, if you have some encrypted storage and you have the key for that storage, you know, you've got some code that's implementing that storage service and you want that to be able to access the key. You don't want other bits of code like a JPEG decoder to be able to access the key. Um, and so this all starts with a piece of software that is etched into every chip called the boot ROM. Um, so we have a 32 K internal storage and this implements a secure boot protocol or, uh, you know, we have our own skill specification where you can apply a cryptographic signature to your binary and say, yes, this is my binary. I got the exact hash you did and therefore feel free to boot this. Um, so, so that's, um, kind of the, the root of trust for the devices. You can say, you know, this is a key that's installed into the one-time programmable storage on device that is immutable because it's hashed. The boot ROM software is immutable and therefore we know we only run your code. And then the other layers are kind of built on top of that.

Chris Gammell: And what about like historically? So were customers of the 2040 like screaming for this? Was it more like, well, we meant to do this anyways. Like what was the motivation? Yeah.

James Adams: I mean, we, we sort of predicted we had little sweepstakes before 2040 came out of, um, what were people going to ask for? And the big two were kind of, um, code protection, which are the first two things I just mentioned. Um, and low power states. And we were right. Everyone says, I want to protect my code. I don't want people to be able to dump my device and clone it. I don't want people to be able to read my firmware and reverse it. Um, and we've kind of tried to answer to that while keeping the, the implementation and, and the boot source code open.

Chris Gammell: Well, what else was on the list? I'm, I'm curious now. What was it? What was the, what was the dark horse on the list that didn't make it?

James Adams: More GPOs. Yeah. Yeah.

Chris Gammell: Those people asked for that. Yeah. I mean, there's a lot, but yeah, people always ask that you could have, they always want more. Well, a thousand and one more RAM as well.

Chris Boris: Yeah.

Chris Gammell: Oh, sure. Yeah. Yeah.

Chris Boris: Floating point.

Chris Gammell: Floating point. Okay.

James Adams: Yeah. So it's kind of, um, you know, if you describe it as those three features, it sounds like a really simple thing. Um, but there are so many ways it can go wrong. And this is kind of why this has been such a drawn out process to develop this chip is the constant. You keep on thinking you're done and then you find a new way to break your own chip. Right. And then once you release it onto the world, as we found out other people find ways to break your own chip and we're trying to get as close as we can on the first pass and then turn it over to the security community and see what, see what we find out. I mean, we did do some auditing, you know, on pre-production silicon before we went out to production before we released the chip, but you're always going to find more things. And we're just trying to be proactive about chasing down the issues we find.

Chris Gammell: From a design perspective too, like what did it, what did it take in terms of, uh, maybe well, I guess time resources for sure, but is, is it a significant overhead for like the, the silicon development process of like place and route or, you know, uh, area on the chip to, to put these kinds of features?

James Adams: So I would say the actual silicon area cost is almost negligible with the exception of some of the standard arm security features like the SAU and the dual MPs. Um, so those are memory protection units inside the processor that have just a lot of configuration and watch every address that goes out the processor. And therefore you have this high fan out comparative network in the processor that is large and affects your timing and your dynamic power. Um, it's more of a detail thing. And so the real cost I think is in the engineering time to go through every part of the design with a fine tooth comb and, and think, have we accidentally done all the other work here? So one of the things that's really tricky is, is resets, which you might think of as simple, but, um, you can, you know, you kind of think of the chip as booting in a straight line. And then there are all these little loops you can take to go back through parts you've already been through. And sometimes that doesn't behave in the way you think.

Chris Gammell: Especially when you have people with, uh, tugging on that voltage line too, right? They like doing that. Well, this is the problem.

James Adams: You design something to work in one way and then people explore all the ways in which it doesn't work. And there are way more of those than there are the ways that it works.

Chris Gammell: I keep forgetting that you started from the M33 core as well, right? So that's the, the arm side core. Does that, that has a secure memory enclave as well to it? Like how much, how much was coming from kind of the, the, the package you're buying and then, and then how much did you have to add on top of it as well?

James Adams: M33 implements the arm VATM security extension, which is kind of a duplication of the existing security states into a non-secure pair of states and a secure pair of states. So it's kind of, um, just a new split of privilege levels and memory protection inside the processor. So, so you can describe some memory as being accessible to secure accessible to non-secure and the processor will, for example, when it thinks I'm a secure processor at the moment, will not execute non-secure memory because you never want non-secure code to be able to influence the execution of secure code. Um, so that's the thing that is delivered. And then the thing that we build is extending that out into the system. Um, so for every peripheral, every UART, every R2C, you can say, this is a secure peripheral. This is a non-secure peripheral. And the processor tags every bus access it does saying, I think I'm in this security state at the moment. And you look up against the list and say, yes, you are allowed to access this. So we have filters throughout the system. Um, a particularly fun peripheral is DMA because DMA is something that does memory accesses for you on your behalf. Um, and so let's say you, uh, program the DMA to program the DMA to do a bus transfer. Could that bus transfer be more privileged than the originating transfer from the processor? So privilege has to be kind of monotonic through the system. You can, you could do things that are less privileged than you. You can never cause things more privileged than you to happen. And there are just a lot of places you can mess that up.

Chris Gammell: It's like sudo and silicon kind of thing. Yes.

James Adams: Yeah, exactly.

Chris Gammell: Yeah. Well, then what about on the RISC-V side of things as well? Did you have to re-implement a bunch of this stuff in the, the hazard three core as well?

James Adams: So with hazard three, I'll try and stick as much as I can to the standard RISC-V extensions. And so, um, RISC-V has a standard peripheral called the physical memory protection unit, PMP. And this is really meant for, um, applications processors to protect your system firmware, like your BIOS from the operating system. But on a microcontroller, um, it works to protect, um, your more privileged mode from your less privileged mode. And so, yeah, you can partition memory with the built-in memory protection, the processor in kind of a similar way to the way you can do it on the ARM cores. Um, and they also tag their accesses with the privilege. And so all of the system level filters, uh, work with the RISC-V cores as well. Yeah. The biggest missing piece on the RISC-V cores is actually a secure boot implementation in the ROM. It's a, there's a missing piece of software there to actually, you know, check software and see whether it should boot or not.

Chris Gammell: Um, that's the, the ROM that's loading from Flash? The mask ROM that's in the chip. Yeah. Yeah. Yeah.

James Adams: Um, which was largely a, a code size constraint. Got it. Um, so we actually don't have two copies of all of the boot code. We have all the boot code as native ARM code and then a little tiny ARM emulator that runs on the RISC-V cores. And that saves us most of the ROM space.

Chris Gammell: There's also a blog post we mentioned that, um, recently came out on the 14th and that's tied to some of the DEF CON stuff. And then also then 38C3. So like this is now a contest, but also then kind of getting community feedback based on what has actually been found. Right. Hmm.

James Adams: Um, I just wondered if it, is it worth talking to some of the other interesting security things that we've done before we get into the breaks, uh, just cause it might set, set the kind of context up like the things like the RCP, uh, and, um, how we kind of crawled over the boot ROM to, to make sure that there weren't bits of code that you could glitch easily. Uh, I'm not the one who should talk about that. This is, this is a Liam and a Luke thing, but, uh, so I shall let them go again, but, uh, Oh yeah, I, I sort of glossed over this. Um, so, uh, when you write software is kind of assumption that the processor does what it says in the processes manual, like if you add two and three, you kind of expect to get five and so on. Um, and people deliberately, you know, manipulate the chip from the outside to make it do other things and break every assumption you've made about your software in ways that, uh, with a bit of creativity, you can circumvent all of the software checks you put in place to make sure you only boot the, um, the first customer's firmware, not anybody else's firmware, for example. Um, and so we have some hardware to detect this deliberate manipulation and, uh, bring the chip to a fail safe state rather than continuing in undefined way that might result in doing something it shouldn't in, you know, in leaving the, uh, the security model. Um, so we have a few things. We have some glitch detectors, um, but, um, basically detect loss of timing closure on the system clock. So if you, um, take a transistor and you put a really fast negative pulse on the, um, DVDD, you're actually, um, bringing all of the transistors supplies closer to their threshold. And so they are switching more slowly. And so you can break all of the setup constraints on, on the flops in the chip and you can break all of the, all of the assumptions about how the, um, how the chip operates. So the processor might, um, not write back the result of an instruction. It might calculate the wrong value. It might access the wrong address. It might, uh, write back more data than it's supposed to, and actually trash every register. Um, and it's kind of an interesting topic because nobody really knows what the processor does when you inject faults. It's kind of a difficult thing to actually measure, but you can have models. Um, like you say, I'm going to assume that someone can make the, the processor skip instructions being executed and then go through and exhaustively tests the, the code in the boot ROM and say, um, you know, throughout this entire boot process of a hundred thousand cycles, you can take any three and skip that instruction and the chip either boots correctly or does not boot. Um, and so we, we have, you know, a test harness where we can emulate the ROM and, and do this exhaustively. Um, we also have some other hardware. So we have a coprocessor on the arm core that kind of does hardware checked assertions. So, you know, you have like assert statements in your code.

Chris Gammell: Yes.

James Adams: Um, where you can say, I think this is a property that is true on this line of code. Uh, and if you're doing this normally, then you'll break to a debugger and it'll say, Hey, you were wrong or it'll print our message. Um, so we have this, uh, we have hardware assert statements essentially that are sprinkled throughout the ROM and let us check basic consistent properties of the code and detect that's going off the rails and bring the chip to a safe halt.

Chris Gammell: And that is the redundancy coprocessor, the RCP. Is that right? Yes. The RCP. Yeah. Got it.

James Adams: Um, and, and all of this is, is trying to enforce that point one of you can control what runs on the device versus what doesn't. But this, um, fault injection, it's kind of table stakes for, for security these days. Um, you know, any, any board grad student with a Pico and a MOSFET can make a chip that doesn't think about this, run their code.

Chris Gammell: You know, it's just called a coprocessor. Is this like another, I just, I feel like when I hear about all these things, you know, you've got the PIOs, those are kind of like, they're state machines, but they're kind of like tiny, tiny processors. And then you get the RCP. It's like, eh, it's tiny processor. You know what I mean? Like how many processors are in this thing, guys? Oh, we got an extra two RIS-5s in there. You know? So like, are they giving you too much silicon? Should we, should we pair you up with Matt Ben? He could just throw some other designs in there. You know, like he could just, so.

James Adams: It's a super loose term here. Coprocessor means some hardware that is coupled to the processor over its coprocessor bus. Which is just a bus that lets you transfer 64 bits in and out of the processor or issue signals to the external hardware to tell it to do an operation. So it's not a processor.

Chris Gammell: Have you thought about like just putting like no hacking in the laser etch on top of the chip? And you can let that all the silicon.

James Adams: I think if we were just really nice to each other, we wouldn't have to do the security stuff. And it would save us a lot of time and money.

Chris Gammell: Yeah. That's a good point. Yeah. We should talk to people. Okay. Well, since we know that's not going to happen, this is interesting that, and this is, I guess, does this exist other places? I don't hear about it, but also I'm, you know, I interview security people. I am not a security person myself. So like, are there other people doing this sort of thing?

James Adams: I mean, so people doing super hardened designs like for smart cards and stuff are definitely thinking about fault injection. The thing that is a little different about this chip is that we documented it. So, you know, if you assign a gold-plated NDA, you might find out about the hardware countermeasures for a smart card chip you're developing firmware for. You can't tell other people about it.

Chris Gammell: Otherwise, it's just like an API. Like they just say, here's an API. Don't ask questions.

James Adams: Well, you might get the hardware details, but it'll be, you know, Chris can speak more to that.

Chris Boris: Quite often, actually, some other chip vendors, microcontroller vendors that sell secure microcontrollers, they'll sell them on an open market. But to actually get even get the software to turn on the security features, you need to sign NDAs and you have to jump through hoops and do vetting and so on and so forth. So you might buy a chip that has security in it, but until you do XYZ and, you know, come to terms with the chip vendor, you might not be able to even turn that stuff on. So it's basically unusable. And even when they do tell you how to turn it on, they're probably not going to tell you how it works. And you're probably not going to get registered definitions and you, you know, et cetera, et cetera. So it makes it very, you know, very, very hard for customers to, to certain types of customers to build secure products. We've taken a very different approach to that. We think it's better.

Chris Gammell: Are you guys targeting secure? I mean, aside from just like the making, manufacturable products that aren't going to be ripped off, that sort of thing, you know, or sideloaded with alternate firmware, that sort of thing. Are there people specifically in the security industry that are interested in RP2 XXX parts that are asking for this stuff as well?

Chris Boris: Well, I mean, I think it's going to be up to our customers to decide, you know, whether they, you know, what they want to build on top of the 2350. But, you know, we hope it's going to be broadly applicable to all sorts of different applications that have, you know, security in mind. Right. But it's ultimately, it's going to end up, you know, it's going to be up to the customer what they, you know, they pitch. Sure, sure. But our hope is that, yeah, it's going to be pretty, pretty good.

Chris Gammell: I'm just saying that what I'm hearing is that this caused a lot of strife internally and time and money, money and time is money. And so like someone's asked, like, where is, where is the motivator here? Right. Like not saying that I'm like, oh, well, just, you know, don't do anything. Right. But at all of these micro decision points, you guys were saying, well, should we keep going with this or should we just, yeah, whatever security. Right. And you kept, you kept going with it. That's good. That's the thing that a lot of people like about it. But something was telling you to do that. It could have been a person. It could have been a customer. It could have been, you know, it's like, what is the, what is that thing? Let me put on my journalist hat.

James Adams: I mean, Chris, you said something interesting, which is people in the security industry, but this is actually kind of everyone's problem. So we have some new EU legislation coming in, which affects us too. And people are being made to think harder about the security of all of their products because you don't want, you know, malicious firmware running in your home. Right. And so we want to be able to provide secure boot, a safe over the air upgrade cycle, including power on self-test for your image and so on. And it's all kind of built on this foundation of being able to provide a high assurance initial boot. And so we've spent a lot of time on that foundation.

Chris Gammell: Cool. Okay. So you guys are just kind of looking down the road saying, this is a thing that we would like, we want it, but it's also a competitive advantage. Yeah. Yeah, totally. Okay. And that's great. That's good product planning. Right. And that's, yeah.

Chris Boris: Yeah. We're also quite early in the 2350 journey and we wanted to, you know, get as much sort of feedback on the chip as we could early on before it ends up in, you know, various different applications where, you know, when, when, you know, glitch attacks do, you know, transpire, then, you know, there's a huge install base, et cetera, et cetera. So now is the time to, to, to get things found and fixed.

James Adams: Yeah. I mean, we really didn't know what we were going to find throwing this out into the world. And so, you know, I think we went on this security journey. I think we, we, we definitely talked about doing this and putting it out there for people to hack because how do you really know what you're, you know, what, where you are in security if you, if you don't see what people, you know, how people break it. And I think we've learned a few things. I think it's fair to say, and I'm not a security expert, uh, that most of the guys did have quite a hard time finding issues. So it took quite a long time. You know, we had our $10,000 bounty out there for a while before we doled it. And then we did get four entries in reasonably quick succession, but they'd taken quite a long time to get there. And I guess the other point is this is all, you have to have physical access to the chip, right? And if you're doing things like putting an individual key in each chip, okay, possibly if you break something, you can read the firmware. But if it's, if it's something else, uh, like, um, uh, um, uh, where, where you care less about that and you care about, you know, like, um, um, sort of, um, verifying that your, whatever your thing is, is, is the real thing, right? Like EV charger or something like that. Um, then, uh, then the individual key per device thing, uh, uh, means that it's only useful for that particular device if you've broken it. Um, so, so things like, you know, it really depends on the application, but also, yeah, we just want to be open about this because people don't do this. This is new, right? To kind of expose yourself like this.

Chris Gammell: Um, yeah, that's great.

James Adams: Hopefully this is, this is also kind of like a good thing, right? This is just a thing that helps others, not just, uh, not just us. Right. Um, because, you know, the bad guys for sure, uh, know how to break other vendors chips. We've, you know, we know a lot of other chips have security holes. Um, people tend not to talk about it, but they should, right. You know, uh, and, and we'll learn new stuff.

Chris Gammell: What about key storage? Is there any like, like a private key storage locally on board, like HSM style?

James Adams: Um, so we have eight kilobytes of one time programmable memory on board, antifuse based memory, and we have hardware based protection to, uh, either permanently disable reads or writes to part of that array or to, um, uh, what to, to one shot disable, um, parts of that until the next reset. And so this is our intended mechanism for storing, um, symmetric or private keys on device is you make those available to an early bootloader at boot, and then the bootloader uses it and then wipes its memory and then disables access to the key until the next boot.

Chris Gammell: But like, like, can you do like certificate signing on, on board and stuff like that, or would that have to be in software?

James Adams: Uh, so we don't have, we deliberately do not have any hardware that touches, uh, private or symmetric keys. And the reason is that you will always have, um, power side channels. So if you implement these things in software, which actually to call it, XM33 is at 150 megahertz gets you quite a lot of cryptographic throughput. Um, you can work around that. Um, if you have that in the hardware, you kind of just have to write a really embarrassing erratum saying, do not use that security hardware. Which we don't want to do. Yeah. Yeah. And for the same reason, we don't touch, um, sensitive key material in the boot ROM. That's exclusively done post boot.

Chris Gammell: Yeah. I mean, I've played around with some of the ones, some of the third party ones that are doing like enclave type stuff. And that's what I was asking about the, uh, like trust zone is on the M33 as well. Like that, that I think is optional on M33. It is.

James Adams: We have all of that turned on. So that is, um, what I referred to earlier is the call exam security extension. That's also known as trust zone for call exam. And it is kind of a, you know, it's a, a branding term for having more privilege levels.

Chris Gammell: Yeah. Right.

James Adams: That lets you, um, separate out the, um, you know, separate out secure versus non-secure memory. You can also have interrupts targeting different security domains. And so you, you really have two cores in each core, each of which is a separate from the other one, right? You have, you have two threads of execution. Two cores. Yeah. Got it. So you have two, two stacks too. Yeah. So this is probably a good time to point out, uh, because yeah, we, you do your cryptographic stuff in software. Um, that, uh, the next thing we're doing is we are, um, as the blog post says, um, we've got an AES implementation that, um, uh, we want people to, uh, start looking at. Uh, we think is, um, it's software implementation. Uh, which is hopefully more immune to the kind of, um, you know, these kinds of attacks, like looking at the, the, the power, uh, traces and stuff. Uh, so this is something we're also looking at, right. Um, and trying to, um, build, build pieces that are secure or at least, uh, much more secure or at least a known, you have at least an understanding of where they're not secure. Right. Um, so we're continuing the fun. Uh, we haven't really, we haven't released that like, Hey, it's here yet, uh, but it's coming, uh, alluded to in the, in the, in the, in the blog post, uh, on the security challenge.

Chris Gammell: Let's talk about the blog post as well. So there's a couple of things called out there. Um, like I said, I saw some familiar names like Dr. Colin O'Flynn and, uh, uh, Aiden Cullen and stuff like that. So, so what are the things that were, that were ultimately found in the, so extracting anti-fuse secrets. I'm just reading header headers here. I don't actually, I know what any of these things mean and signature check in single instruction fault with laser injection. Oh, wow. USB bootloader, single injection fault with supply voltage injection. It hazardous threes. I have no idea what that is. Where do you want to start? Wiggling things and then shooting lasers at things. Is that a good summary? Is that a, should we start with the lasers?

James Adams: I'll do a quick one on lasers. Uh, just, just, just from the point of view that, um, is it worth talking about the sort of structure of the challenge? Yeah, maybe that's a good one. Do you want to go on? Look, you, you, you, so, so the challenge we put together is you have a chip with a secret stored in its one time programmable storage and with secure boot enabled. And we want you to tell us the secret and the main way we want people to go about this is finding exploits in our secure boot process. And we kind of expected the whole queue of people to be there at DEF CON in the first week saying, Hey, here are all the ways it's broken. Um, because it's kind of a classic thing where you spend lots of time thinking about the fine details and the fault injection. And then you kind of leave the front door open cause you've locked the back door too hard. Um, and you, you have trivial, you know, you can create crafted, um, flash contents or you can inject crafted packets into the USB that just break the chip wide open in a way that doesn't even necessarily require physical access. And we're quite pleased that all of these exploits are ways of getting stuff out of the chip. If you have access to the chip and you can desolder it, uh, or you can, you know, put a probe on it or you can decap it and use a novel imaging techniques on it. Um, yeah. So do you want to go through maybe James from top? Well, I was going to do a high level. Uh, so there's, there's sort of three different ways of disrupting the logic. So you've got your kind of voltage on the chip that you can, we've sort of talked a bit about, so you can kind of glitch it. You can drop the voltage, um, and you can, uh, use, uh, build systems that can look at the state of, of the, of the processor, either, uh, you know, either specific times or that you can sort of monitor the voltage and then glitch it based on what you see. Uh, and that can, as we've sort of explained, that can kind of do lots of different things in the logic. You don't really know you're doing random things, skipping instructions, um, causing, uh, corrupt, uh, data, et cetera. So there's a voltage glitching laser fault injection is one where you literally fire a laser into the silicon. Um, silicon is quite, um, um, transparent to, uh, so the infrared, and I guess, uh, quite a lot of photons of a, of a laser get, basically get into your transition. You can get into your transistor into your transistors and, and cause again, trouble. And that one's interesting because, you know, with the, with the voltage disruption, that's kind of disrupting the whole voltage plane in the chip, right? Your whole rail, uh, whereas the lasers can get down into very, very fine, you know, small points of, of logic, right? Um, which is interesting. And then of course, uh, the other one is EM fault injection where you similar to the lasers, but you have a teeny tiny coil and you, you cause, uh, a, a targeted, you know, strong magnetic field in the area. And again, that, that can induce currents in the tiny wires in the chip and upset the logic, but in a much more localized, uh, way. Right. Um, so, so those are, well, I guess, well-known techniques, um, for kind of disrupting the logic inside the chip. Um, and that, that, I was going to say that that's my summary. I think that the, the, the detail of the breaks, I'll let, uh, uh, Liam, uh, talk about, I guess I'll, I'll, I'll, I can, I can talk about the, um, the, um, my favorite one, which is the, uh, the, uh, the PVC, the extracting the fuse data, uh, using a, a Fib machine and this passive voltage contrast.

Chris Gammell: Um, uh, so this is a machine.

James Adams: So that's a fine ion beam. So this is a machine that's often, often used when you're doing chip debug, right? So, uh, if you have some weird fault in the chip or you're trying to cut a trace or something, you know, actually physically inside the die, you could use this very, very tiny ion beam. I think they're kind of gallium ions that basically blast down through the silicon, open up little holes and channels, cut traces. Um, you can actually deposit metallization. So you can kind of rewire the circuit. You can even sort of draw little pads on and then use microprobes. Once you've got the thing back to the lab to kind of probe, probe voltages. Um, so it's a, it's a fun technique, but there's also, uh, this thing called passive.

Chris Gammell: I thought I couldn't feel any worse about my soldering. And then I hear the people doing that kind of stuff.

James Adams: Yeah.

Chris Gammell: Like I could totally attach a wire to the board that I did, you know, like it's huge, but yeah, no people are doing fib stuff. Okay. All right. Cool. Cool. So yeah. So fib is fun.

James Adams: And then this, this passive voltage contrast is basically, uh, if you have, uh, as far as I understand it is if you have, uh, so you have bits of metal inside the chip and if they are connected somehow to, uh, effectively ground, like either directly or through, through kind of diodes, if they're connected to bits of circuitry, they tend to, to, to have a path to ground. If the thing's turned off, um, you get a, you get, uh, the, the sort of ions don't build up. They kind of pass to ground. If you've got floating stuff, I think the ions build up and you, and you don't. Right. And then you can actually using a special detector, you can kind of see this, right. You get, you know, darker areas and lighter areas. And so what the, what the guys did was they took the OTP and the OTP is built from, um, the way these, uh, these work, uh, they basically, they're the gates of the transistors, uh, are stressed and eventually effectively break down, but in a way that you can't really see, right. There's a sort of a, uh, you get a leakage path through the gate, uh, and that's either a one or a zero leakage path or no, no leakage path. Um, but what they're able to do is effectively strip everything away from the tops of the transistors all the way down to the gates and then use this, um, passive voltage, um, to see the state of the bit, right. Because obviously the gate, if it's got a leakage path, it's one color. And if it's not got a leakage path, it's got different color.

Chris Gammell: So you can literally just kind of like seeing this photo, the IO active photo that they, they contributed. Like it like literally looks like a, almost like an abacus of like seeing, seeing the digital number kind of next to each other there. That's cool.

James Adams: Yeah. So, I mean, it's not quite as simple as that because the way the memory is built, you've got the, you only get the bitwise or of the, the two sort of adjacent memory cells. So you still need to do a little bit of work, but they've proved that you can see the, see, see things in this way. Right. And this is going against the general kind of, um, uh, consensus, I suppose, industry consensus that this stuff is, is harder to hack. Right. And these guys have just kind of blown it open. So, uh, so yeah, that was some interesting learning for us. And there, you know, there are relatively simple ways to mitigate this by scrambling and such. So it's something we're now going to take away and look at, but, um, but, uh, but yeah, that was definitely my favorite. Yeah. The vendors love to tell you, you can't read the bits out with a scanning electron microscope. They just don't talk about the other types of microscope. You never want to see the words novel technique in an email either. I'm not sure about the study. Ah, yeah.

Chris Boris: It should be noted that this is, um, this, that attack is probably applicable to other 40 nanomies chips that use that same IP as well. So this is sort of, um, that's, that's something that could be applied to other pieces of silicon too. It hasn't actually been done yet, but maybe, maybe it will be in the future.

Chris Gammell: I always think about these kind of, so like they're, they're basically, they're decapping first, then they're shooting it with like this fancy, fancy pants thing. But doesn't the, isn't the one-time programmable like secret for each chip as well? Or it's, it's, you said it's at boot?

James Adams: I mean, yeah, exactly. So you, this is a, this is a thing that takes quite some effort and then B, you're only going to get one key out of it. Right. And if it's unique per device, well, okay, you can probably, well, you may well have destroyed your device, but if you did get the key, you can probably decode the, the, the firmware. But if the firmware is using other methods to talk back to base, it's just one device. You know, you're not going to get any other, other benefit from it. Right.

Chris Boris: Yeah.

James Adams: I think it's likely that you smoke the device in the process as well.

Chris Boris: You probably do. You're probably not going to be phoning home after it's been fibbed.

Chris Gammell: James Bond is on a mission to get someone's car keys. And what he does is he runs them over with a tank. And then from the, the goop that's left on the ground, he pulls the car keys out and then he goes and unlocks it. That's like the, that's like, feels like that's the analogy to me. I don't know, I don't know about you guys.

Speaker ?: Yeah.

James Adams: Yeah. I mean, don't, don't, just don't, don't use the same key for every device right now.

Chris Gammell: Well, that's, yeah.

James Adams: Rule number one.

Speaker ?: Yeah.

Chris Gammell: This is great. I mean, so now you guys have done this kind of competition, I guess, challenge, you said. Is it, is that going to be an ongoing thing for future silicon? You think as well, I guess, should people be kind of winding up when they see a new microcontroller release, they should be like, oh yeah, get out the fib, get out the blib, whatever the next generation of novel technique is. Is that like a ongoing thing you think?

James Adams: Yeah. I mean, this has gone fantastically well. We hoped to learn things and we certainly did learn a lot of things from it. So there's a question about new chips. There's a question about 2350. I think as we get to a larger install base of upper 2350, we maybe won't do this style of challenge again because our ability to fix the silicon becomes more limited. Yeah. But I think if you bring out a new design, you really want people to try and break it and you want to be as transparent as possible because you kind of want to help people break it so you can fix it. So I think the short answer is we'll kind of adapt, adapt over time, right? Depending on what customers think, what we see. And as Luke said, they're kind of in store base.

Chris Boris: I believe this challenge was pretty unique in terms of a silicon company such as ourselves going out to the hacking community and basically painting a big target on our back and offering a nice juicy cash reward. Right.

Chris Gammell: We would love to be on the screen at both DEF CON and, you know, chaos communication Congress.

Chris Boris: I mean, it was great from many, many different aspects, but also I think a lot of people had quite a lot of fun in the community too. So we definitely, we got some great feedback from the people who, you know, been basically playing with this chip for the last six months.

Chris Gammell: Well, so this kind of leads into kind of the what's next on, I think specifically for the, you know, I don't need to know the next chip set that's after this. I'd love to hear it out off camera, but I'm guessing you guys won't tell me anyways, and that's fine. And, but this has some stuff that you're thinking about, you know, maybe, maybe doing some changes to specifically to the 2350 kind of next, next spins of the, of the silicon and stuff like that. One thing I was curious about that I don't think we've talked to anyone in the past about, maybe you guys, is just what is the logic behind that? Like, how do you decide when to start doing that? When to start, what to put in, what not to put in, you know, how extensive the changes are, what are the available, you know, remedies you have for that sort of thing? Like, what is, what is the next step now that you know, some of this stuff, some of the other errata that you guys have, how do you start making, you know, continuously improving this part that people already like?

James Adams: Sort of from a management level, I guess, we collect the data, right? So you have a big spreadsheet of all the, all the problems and issues and guys like Neum and Luke Gawain, then look at the kind of implementation, right? So you can apply an effort, effort factor, and you then also have a kind of like desirability factor. And you also have a kind of risk factor, right? If you're going to change this, what's the risk? Um, and so that's broadly how we decide sort of from a management perspective, I suppose. Um, but yeah, I, does someone want to talk about the kind of more nuts and bolts side of it and how we do the kind of logic changes and, and, uh, et cetera. Yeah. I mean, one of the big questions you have cost wise is can this be done, um, with a surgical change to just the metal and vial layers of the chip, or is this a complete, uh, re-spin of the chip, right? So, um, taking Aiden Cullen's attack as an example, there are about five or six different things there, which happened in a row that should never have happened. And each one of those can be individually tweaked to say, you know, you know, to just narrow down the avenue of that attack. Um, and what you can do is you can, um, rewire existing logic gates in your design to tweak the way that logic behaves. You can, uh, occasionally fish out a spare gate from somewhere and wire it up. Um, the, it is really a question of how the logic has been synthesized and, um, whether you have the timing budget available to do it. Um, so I'll give an example of something we do not intend to fix, um, the SIO spin lock erratum, where if you read, if you write to a 128 byte, um, offset from the spin lock, you actually decode the spin lock. And that's because the, um, decode mask for those registers is one bit too small. That's in some very timing sensitive logic. And so we're not able to get in there and, you know, wire out to a new gate and wire back in, in time. Um, but then things like the OTP are running much slower and that's something that makes it much easier to go in and just edit the metal stack, um, to, to change how the logic works in terms of how we do it. It goes back to just understanding your own design really well. Um, because you have to debug, not just the source code that we actually work on to define the design logically. So we use a language called Verilog to design the chip. And then there's a process that looks kind of like compiling a linking software that turns that into, um, an actual piece of artwork that you can turn to silicon. Um, you then actually have to debug your design at the gate level and further down, um, and, and understand how those two things correspond. But you do have tools that help you. There's a tool called logical equivalence checking, which can basically take the Verilog and it can take what this sort of gate level net list, we call it, you know, cause it's the, here's all the gates and has his other wired up. And it can basically tell you if they are, you know, identical logically. Um, so that these sort of things help, but you do, as Luke says, you have to kind of drill down and understand how did the compiler interpret this Verilog code and what gates is it, you know, you literally people drawing out pages of gates and figuring out how, you know, what's the compiler done and how's this stuff working and then how do we fix it? Yeah. I mean, there are kind of different approaches because the hard part is not actually changing the logic to make it behave correctly. It's knowing what change you've made just because the correspondence between the gate level implementation of your chip and your sort of logical level description that you designed is, is so non-obvious. And one approach you can say is I'm just going to change these gates. It simulates fine. I think I did the right thing. And then I'm going to have a, a register. It's called a chicken bit to enable that logic. And I'm going to prove that if that register is off, then the logic is the same as it was. And then, and you can then just de-risk it and say, I don't particularly mind if I know exactly what this change did, because I know that I can disable it and go back and that de-risks the change you made. We kind of go for a second approach, which is for every change we make to the gates, we want to have an exactly logical equivalent change to the Verilog. And this means sometimes the way you fix it is kind of three sides of a square. It's not the most obvious. Oh, I had a one here that should be a zero. I'm going to just change that because that completely ripples out and makes the design behave differently in lots of little places. You have to kind of think laterally about it.

Chris Gammell: You said you go back and you actually change the Verilog, which seems good, especially for evolutionary type stuff to the next jump. So you don't make the same mistake again, I'm guessing. But how do you maintain the kind of the place and route stuff? Do you like lock parts of the design and say, none of this changes, only go and re-simulate this little thing that needs to change? Or sorry, only go and place and route that?

James Adams: Yes, you do not rerun place and route. You take the actual GDS or higher level description and you just tweak it. You make patches. Yeah.

Chris Gammell: But you said the Verilog is also changed to match.

James Adams: Yes. And the purpose of that is two things. It's knowing exactly what change you've made, because if you can't describe it in the original code, you don't understand it. And it's also making sure that that fix is then picked up in future uses of that hardware. So we use Git to track the versions of our code and we want that check to Git so we can just pick up that patch for the next next chip. Got it. Yeah. And you also need it to simulate, right? I mean, you have several levels of simulation, right? One which is effectively simulating the Verilog, one which is taking this entire gate level net list and simulating it, which is much, much slower. But you've got to check the fix works on all of these, right? And as Luke says, keep it for posterity as well. Your Verilog and your gates all need to match. And all the simulations, because building the chip, we have a huge raft of simulations to check function and make sure it all works, regressions that need to pass.

Chris Gammell: It almost sounds like, just to map it to PCBs, it's like you're saying, we're going to fix the Verilog. That's like going back, changing the schematic, make sure the value is right, that the things look right logically. So you could put it into Spice, changing the layout that's like the GDS style layer. And then what I thought you were going to say when you said just change the metal layer, metalization layer is like, oh, you just go and tweak the Gerbers and like add a little box in the Gerbers. But that would be very dangerous, right?

James Adams: No, these are pretty much Gerbers. GDS is just Gerbers for chips.

Chris Gammell: Oh, GDS is Gerbers. Okay. I figured GDS is more like a layout. No? Yeah. It's like one being like a programmatic and like, you know, instead of just like Gerbers to me are like effectively like a bitmap, you know, like SVG. Yeah.

James Adams: I mean, Gerbers are a vector image format. GDS is a vector image format. And it's literally, you've got shapes for this is a bit of metal. This is a fire.

Chris Gammell: Yeah. Oh, okay.

James Adams: Yeah. And that's what's actually turned into your masks. Obviously you run it back through the DLC, right? And we have DLC for chips, just like you have DLC for circuit boards. And you make sure that you've done something that's legal from a process point of view and it's still manufacturable. Right, right. And you haven't accidentally created a short between power and ground, which happens.

Chris Gammell: I've definitely never done that. Yeah.

James Adams: I guess two other interesting sort of bits of information on that. One is that Luke actually mentioned it before. When you've placed all your cells, your gates inside the chip, you have sort of holes because the gates are kind of rectangles or squares and they kind of stack together between the power grids and you have sort of places where the routing goes. But yeah, you end up potentially with holes and you actually fill those with filler cells and the filler cells are kind of reprogrammed into different things, right? So you have a whole ton of spare kind of sort of programmable logic cells sprinkled around, which does help when you're trying to do these metal modifications to, you know, try and if you need an AND gate over here or a NOT gate, you know, to find them, they're hopefully fairly local to where you need them so that you're not going to screw your timing up. And I guess the other interesting thing is, much like a PCB, you have layers of metal. I think this chip has seven, well, eight, I think if you count the RDL. And via, right? So there's a layer that is the connectivity via layer and then there's the layer that's the metal layer. And the more you change, the more expensive it gets, right? So, you know, sort of rule of thumb, I think, for 14 nanometers, which may be out of date now is about $50,000 per layer. So also what you're trying to do when you're doing these metal fixes is reduce the number of layers that you're using, right? And also that does mean that when you do fix stuff, you may, that sort of potentially changes your decision, right? You might certainly for, you know, often you want to batch things up, right? And fix lots of things at once because you're probably going to end up changing, I know, several layers. And that makes it better to fix everything, right? Rather than just try and do one and one and one, if that makes sense, right? So as soon as you've used one layer for one fix, you might as well use it for another fix. So batching the fixes together, it's useful.

Chris Gammell: Would there ever be a, I mean, obviously you guys have working, working silicon with some, you know, some things that you want to change, but like, is there ever a time when silicon companies just go, yeah, we're just going to keep the Verilog, rerun everything else, right? And just like do a, like a full spin all the way down, or is that way too risky?

James Adams: No, that happens. That's a, that's an all, all, all layers change, they call it. Um, if you have transistors at the bottom that need to change, um, especially in analog stuff, often that's what you need to do. Um, obviously very expensive because you've got a whole, a whole mask set, you know, the whole thing.

Chris Gammell: Right. Right. When they ship you the mask, you're like, we don't need it. You can hang these on the wall. We don't need this. Oh, that's pricey. Yeah.

James Adams: It's a longer iteration time as well. So if you get a bunch of wafers made of your design, you can get them held at contact. So you stop after you've built the transistors and before you start putting the metal one, and if you then made a metal change, it's a less time to get the masks changed and just have those wafers be finished off.

Chris Gammell: It's interesting kind of piecing together very, very old episodes. So like when Jerry Ellsworth used to come on and she, she would talk about like when toy makers would kind of start with like the, the sea of gates, like you talked about and just change the metal, you know, basically put in ROM, put in, you know, I think they made ROMs using SRAM or something like that, or probably just JK flip-flops. I don't even know. And then they would start from the, the sea of gates kind of themselves.

James Adams: And then just, so I think what Jerry is talking about there is what's called a ULA or an uncommitted logic array, which is a basically a chip with a bunch of uncommitted gates on it, which is designed to be strapped up to create a new chip. And that saves you the cost of, um, you know, making the masks for the base layers, which are some of the more expensive masks on the chip. And also saves you the, um, the lead time of getting all those masks made and getting all the, the process steps done. It's kind of almost like an FPGA, but with real gates.

Chris Gammell: Like a one-time programmable FPGA sort of thing. Programmable with wires. Yeah. Yeah. Uh, I, I know we're, you guys have been very generous with your time. Uh, two, two, two last questions. Uh, one is generally, you know, you'd mentioned kind of the, the best, the 2350 is kind of still at the beginning of its, its life cycle and stuff like that. And one thing I think about when I think of life cycle for silicon is, is die shrinks. And you guys are very cost conscious. Anyways, there's obviously cost downsides doing that, but then you also get cost benefits of more die per wafer sort of thing. Is that something that you consider in the future? Is that not really a, I guess that would be a all layers thing. Cause you have to make them tinier, right? But is that worthwhile? Is that something that would be, make sense for, for your organization?

James Adams: I, let me talk about that. Um, no, I think is the answer for something like 2350. I think once we have, you know, made all our metal, uh, changes that we, we, we, we, we're going to make, it will then be produced, um, as is for kind of forever, right? We don't like to obsolete products. Certainly like as long as 14 nanometer fabs are open, we will be producing these chips. That's the idea. Um, die shrink. It may make sense for legacy manufacturers that are on really old processes where maybe the fabs are disappearing. Right. But generally what happens is for things like 14 nanometer, these older processes, they do actually get cheaper over time. I mean, there is a bit of sort of supply and demand, but it's, it's kind of, you know, it, it would be such a big effort to move it to a different, um, um, processes. It's, it's kind of not worth it. Right. Um, unless you're, you're forced to write the fab closes, but that's, that's very, very unlikely to happen. I mean, die shrink in terms of literally just shrink the artwork down is not really a thing anymore on the smaller geometries. I think 14 nanometers is actually about where that runs out. 45 to 40, I believe was a shrink. Um, but you're now looking at a new, a new process and a re-implementation of the chip. And if you're doing all of that work, you may as well just, you know, change everything. Yeah.

Chris Gammell: And 33 becomes the M55 or U55 or whatever it is. Yeah. Yeah.

James Adams: Also parts of the design, like we have, um, you know, high voltage pads. You know, five volt tolerant. They're now 5.5 volt max. Uh, and those are a certain size because you have, you can only support certain electrical field intensity inside the transistors in the, in the pads. And that doesn't get any smaller. Um, but the cost per unit area does go up as you go down to, to smaller processes. So there's kind of a scale. Got it. Yeah.

Chris Gammell: Yeah. I kind of figured as people go smaller and smaller on the logic side too, then you start to like smush together chips and you have processing where like you have super low core voltages on the main processors. And then you have like the, like you said, the higher voltage stuff, maybe a separate than that sort of thing.

James Adams: Yeah. You get weirder and weirder rules because the main transistors get smaller and you have weird rules in, um, some of these smaller nodes, like your polysilicon layer, uh, has to, uh, sort of strike one way and not the other way, for example. So, uh, some of these IPs, you can't rotate them and things like that. Right. Uh, uh, it just lots and lots of more, more weird rules that, uh, you know, tend to turn up as you get smaller and smaller. Uh, and of course then you've got the, the move from things like, you know, the kind of flat, uh, geometry to the FinFET stuff, which is all new and weird again. Um, so yeah, it's not, it's not really possible to go, just go shrink 14 nanometers to, I don't know, 28 or something. It just doesn't really work anymore.

Chris Gammell: Hmm.

James Adams: So these shrinks like 45 to 40 are like a really tiny shrink, right? Just like a little, we just shrunk it a little, really a little tiny bit and we made a few more tweaks and off you go. But, um, it's not a real shrink, uh, of, of actually just taking the geometry and making it like half the size of X and Y or, or two thirds or whatever.

Chris Gammell: Well, one thing that, well, the last question I had was actually already answered, I think, which was the kind of the future of the RP2040, because like you had said, you know, like keep making it, why not? But then, you know, there's, we've kind of talked about some of the benefits. It's, it's still a great chip. I still use it, uh, daily. Um, so like when you guys think about that over time, is it, uh, kind of maintenance mode? Is it, uh, enhancement mode? Is it like, what, what, what is the 2040s kind of, uh, when you think about it?

James Adams: Um, so I guess same as what I've just said, uh, you know, we're going to just keep making it. Um, it's quite popular. It's popular. Um, we, yeah, it's very popular. You know, it's, it's nice and simple. If you don't need security, it's, it's great. If you, you know, if you don't really care about really low power, it's great. Um, and yeah, I guess in terms of chip production, it's in, it's in full production maintenance mode in terms of, you know, we, we do, we keep a good eye on the, uh, the kind of, cause every chip is tested, right? So every time you saw your wafer up, you put it in, uh, in its package, uh, and then you, then you put it in a tester and it does a ton of tests on each chip to make sure that the chip's good. And you can monitor the data that comes off that. And you also do, uh, uh, what we call package qualification, uh, fairly regularly just to check that the, the kind of quality of the package, the materials aren't causing any issues. And that's kind of it really. Um, it's just, that's mass production. And, uh, so, so I guess that's for 2040, that will just continue.

Chris Boris: It's a teeny bit cheaper as well than 2350. So for super price sensitive applications, there's a cost saving there. And we've also been super careful with the SDK to make the SDK, um, multi sort of chip targetable. So single platform. So you can build the same software for both the 2040 and 2350 just with build command difference. So, so very straightforward to, to, to run both in parallel with the modern software.

Chris Gammell: That's great until you guys are making the 2452 or whatever that, you know, like, you know, 10 years from now and you're still carrying the 2040 with you. So you're like, why did we think of this? That's good. I mean, for the, me as a user, right. That's great. Actually, you know, yeah.

James Adams: We have discussions every week of, oh, we can just change this one thing. I'm like, nope, you got it wrong the first time. We're now stuck with it. Yeah. So it's hard. The software's hard. Yeah.

Chris Gammell: Yeah. Yeah. Yeah. It totally is. Can I ask one more question? Sorry. So, uh, the Pico is the, the development board you guys build. Pico two has the 2350 on it. Uh, there are different variants that including the, uh, the with and without wifi and stuff like that. And, um, you know, are there other things that we should expect from that? Are there, you know, is that still the best way to get started with things? Like just, I should mention the Pico because I feel like that's where people are starting and they're like, why are you talking about RP 2340, 2350 rather? It's the Pico two. And I'm like, oh no, it's yeah.

James Adams: Uh, what can we say about Pico? Um, yeah, I mean, uh, I think we've already said this with the, the headed versions will launch at some point soon. Um, so we have the kind of the castellate module. So Pico is both, uh, a module that you can solder in yourself and a reference design and, and just, and a dev board. Um, so, and you have the wireless and non-wireless options and we'd like to produce these headed versions where you can easily put them into a breadboard and plug in the, uh, the debug, um, with a connector. Uh, so that, so those are coming. Um, I can't really say any more than that. I mean, it's a nice little form factor. We try and keep things simple and keep the cost down. Uh, so, um, and obviously third parties have a lot of other interesting, more full fat and more expensive, uh, options. Uh, so they, I, they, we kind of mostly leave those guys to cover those bases because we just concentrate on the kind of higher volume of a cost thing. Um, and that, that seems to work pretty well.

Chris Gammell: I guess one thing I'm thinking about with the Pico is like the, you have these kind of the new stack chipsets as well. And that's kind of some, some of, although obviously not all of the functionality that I see on the, uh, on the Pico. And so like, are the stack chipsets going to end up on the Pico at some point? Like you're going to kind of dog food like that where you use your own stack modules or you still have external.

James Adams: I mean, it's, it's possible, right? But the, the stack chip, um, it really is just like having the external chip just in the package, right? You even bond to the pins. You just don't connect the pins to an external flash. It's, it's just inside. So functionally, it's really no different at all. Uh, if we did a variant of Pico that required the space of that flash, right? Uh, then, uh, then I can, I guess we could use it. Uh, we don't, we don't have anything in the pipeline, uh, but it's not impossible.

Chris Gammell: Great. Well, guys, thank you for coming back. Uh, congratulations on being a public company. We haven't talked about that here, but, uh, you guys are public now and, uh, that's exciting. That seemed like a great launch on the London stock exchange. I believe. Is that right? London stock exchange. That's right. That's right.

James Adams: Um, uh, hopefully, uh, the thing I can say is it's not changing us internally. Uh, obviously we have, uh, lots of kind of, uh, um, when you become a public company, you have to report numbers and scrutiny. Yeah. That's, that's all the scrutiny things and you have to make sure.

Chris Gammell: Hello, analysts. Are you listening? Are you still, are you sleep? If you're listening and sleeping, not sleeping, then we congratulate you for listening to all the Silicon stuff. You're a great analyst.

James Adams: So, yeah. So we, we hope that we're, we're not going to be changed by this, uh, but it's, it's a cool thing for Roswell part because it's, it's given us visibility. It's, it's, uh, you know, it, uh, it makes people, uh, um, yeah. I want to talk to us right now. We're, we're a serious company.

Chris Gammell: Yeah. I was hoping all you guys would have Maseratis, you know, like a little Silicon during the day, a little cruising around in Maseratis at night. You know, that, that's what I was hoping for for you guys. But, uh, if it's just more money that goes into Silicon development, I'm also okay with that. You know, that benefits me directly. All right, guys. Uh, thanks so much for being here. Really appreciate it. And, uh, looking forward to the next one. And the next time you guys come on to talk about the RP two zero to whatever the next thing is. So thank you for being here.

James Adams: Cool. I guess next year then, right? We'll, we'll make it a, let's do it.

Chris Gammell: Let's do it.

James Adams: Thanks for having us on. Thanks Chris. Thanks Chris. Yes.

Speaker ?: Thanks Chris. Thanks Chris. Thank you.