 Computers keep changing the world, but their power and safety is limited by their rigid design. The T2TILE project works for bigger and safer computing using living systems principles. Follow our progress here on T Tuesday Updates. This is the 51st T Tuesday Update. Let's get into it. Last time it was the Santa Fe Institute workshop on what is biological computation, with my answer being it's life is defining computation is defining meaning is defining life in a circle. It was about stickers. We sent out our 2019 commemorative hardware land T2TILE project stickers to fans around the world. We've had reports from California and Spain that people have got them. So that's fun. In this last week I was supposed to be working on cache update protocol stuff for true inner tile instead of just loop back on the tiles. Instead, I worked on the locking system, which is connected to the cache updates. And it was something that was sort of sink in my mind. It would be cool if I could do this. It would be better. It would be faster. And it would be more in its own way, more in the T2 way. So I went ahead and did it. So I want to talk about that a little bit. But there's also some new hardware. This new BeagleBone, the BeagleBone AI that was announced last week. I want to talk about that a bit as well. And then this week I want to get this lock state machine redesigned, settled, at least it's settled enough to try it out seriously and to start figuring out the corner cases a little better and then try to get back to caching. And then next week it's going to be the 52nd episode. I mean, that's like a year. That's a year. We could do anything special about it specifically. I don't know. We'll find out come back next week. All right. So, yeah. So we've been, we were building these power frame with these struts, basic struts that had a piece with a positive and a negative email and a female on it. As I've gotten more experience with them, in particular with these parts of the connectors that made up with these guys over here, I have started to see some issues with them. I don't know if you can really tell. But one of the tines, the little ladder hooks busted off on this one, on this one actually a big chunk of the whole upper latch came off. And another thing that happens fairly often is sometimes the clearances are tight enough that it's really quite hard to get these things to settle. So for all these things I wanted to do a little bit of a redesign. So I did some of that this week was just basically I got rid of one tooth. Whoops. And so this is what the original one looked like with the four ribs. I made a three rib one that and, oh, oh yeah. And also added a couple extra layers of plastic on the tongue, the thin part that tends to come out. And they, these, these work pretty good now. So they come apart cleaner. They're a little bit looser, which is good. I haven't, I've done a few of these things and I haven't had any of them not made properly. And they, and so maybe they're a little bit weaker. I don't know, but I think, I think overall this is the way to go. So I'm going to be switching over to them. All right. So that's the power zone. Yes. The people at Beagleboard.org along with Texas Instruments and so forth have come out with a new version of the Beaglebone, the Beaglebone AI, learning AI in the palm of your hand. And it was announced last week, people have been talking about it coming on the forums and so forth for a while. And, you know, there's a lot to like about the Beaglebone AI. It's got a gigabyte of memory. It's got a 16 gigabyte flash drive integrated on the board. So you don't have to have an SD card. You can if you want to, but you don't have to. And, and the TI, the new AM 5729 or new for the Beaglebone line anyway is really quite powerful. And from the point of view of the T2, you know, one point of it is that it's the same shape, the same mechanical headers, you know, header mechanical and header compatibility. But it's got twice as many of the programmable real-time units, the Prus, that really I would love to have. The Beaglebone greens that we're using have two pru cores on them. And so I'm having to divide them up. Each pru core is handling three intertile connections, three each, three each. And then they all have to take their own time to send the bytes off to Linux once packets arrive and are being pulled back and forth. The Beaglebone AI has four pru units. So we could cut down the duty cycle. We could have each pru just taken care of two directions. And I have a fourth pru left over to just be doing the management of data going back and forth. It could be a whole lot faster. You know, really what this Beaglebone AI is about is about these embedded vision engine eaves, these various accelerators that are designed for deep learning kind of stuff so that you can do like, you know, real-time frame rate, you know, video analysis and recognize water bottles and so on and so forth. We wouldn't be using any of that at least not anytime soon. And these things are 125 bucks or something to get started. But they are pretty nice and they would fit in the same hole as the Beaglebone green. So I had to order one. Here's what it looks like. There's the box inside the box. Oh, it's even got an antenna because it's got Bluetooth and Wi-Fi built in in addition to Gigabit Ethernet and so forth. So there's this little quick start guide. It's got a big old heat sink on the CPU and it's got an extra memory on the back to get to one gig. This thing is pretty well stuffed. It's USB-C powered and, you know, you can tie it to a PC. You can just plug in a keyboard and mouse with a micro HDMI connector. That's what I tried to do. And I got it powered up. I plugged in a micro HDMI to DVI connector and plugged it into a monitor. Couldn't get the monitor to light up. So not quite the out-of-box experience that one might have hoped for. On the other hand, it was easy enough to get into it with an Ethernet cable, which I have lying all over here to talk to the Beaglebone greens. And so I got into the Beaglebone AI without much trouble. And so I do what I always do, which is, you know, become rude. You know, it's funny. We trust you've received the usual lecture. Usually, well, respect the privacy. So the first time you invoke, you know, super user power, root power in Debian, it prints this little thing out, which is at this point, it's almost quaint, you know, thinking, you know, this little thing that you're going to buy zillions of. And it's talking to you as if you're, you know, administering a mainframe. Respect the privacy of others. Think before you type with great power comes great responsibility. Okay, yeah, it only does it the first time. Step one, of course, install Emacs. And then I tried to say, well, you know, can we build MFM? Can we build ULAM? Can we run MFM T2 on this thing? So installed the packages and cloned the repos MFM and ULAM and started to build. Things were going pretty fine. Build, build, not build. Thermal zone, zero critical temperature reached 95 degrees C, shutting down. Yeah, I noticed this thing was actually pretty hot. Of course, it did have that big heat sink on it. So okay, it has a heat sink that that's okay. The Beaglebone greens don't have a heat sink. At least not by default. I went and got my infrared temperature sensor. This thing is really hot. This is hotter than I want my steak. And that's just looking at the heat sink. I mean, who knows how hot it actually is down deep inside. 150 degrees Fahrenheit at the heat sink while this thing is running. And it's not like I'm actually doing any AI on it, you know. And or 74 point something in centigrade because I'm used to centigrade for, you know, CPU temperatures, even though I'm not used to it or anything else, because I'm still not very caught up to metric. But I found out how to dump out the temperatures 76,200. These are temperatures in units of milli Celsius. So it's saying 76.2 degrees centigrade in the different thermal zones. And as the compilation runs 81 degrees, 81 degrees, 82.6 in 84 degrees and so forth. You could just see it going up. And I was Googling around at this point and they're like, oh yeah, you should definitely buy a fan. Well, yeah, okay, sure. That's not good news for the idea that we could use the Beaglebone AI inside the T2 tiles. I mean, so look, here it is. Let's get rid of this thing for a second. All right, so here's my thing. And the heat sink goes all the way to the surface of the headers. Now, when it's mounted in the T2 tile, there's just about two millimeters above these headers to go before you get the other board, the PC board itself. So getting cooling in here would be quite the challenge. So I figured maybe I could slow the clock down, something like that. No, no, you can't. This thing, I mean, one of its features is it runs at 1.5 gigahertz, which is nice if you got speed. But in fact, the slowest it runs at is 1 gigahertz. So it was actually running at 1 gigahertz out of the box and I couldn't turn it any slower. That was the slowest thing it had. So I needed to do something for a fan. So I used the quick start guide and actually waving it back and forth. I could get the thing cooled down enough so that I had some chance of actually building this stuff. I started wandering through the log files, trying to see what's going on. This was from the previous thing. The log files are a little strange also. I mean, this is brand new. I don't want to dump on these guys because getting a piece of hardware out, getting a hardware software is not really, really hard, especially because BeagleBone, the BeagleBoard.org, it's mostly volunteers. So little rough edges, like the fact that the system log file that shows up out of the box is over 10 megabytes. It has all this stuff in it. And there are these little scary things. For example, there are kernel oopses that happen with the, where is it? Master, Eve2P1, whatever. For all I know, maybe this is harmless, but it's a little distressing to see. As I was looking through the log files, I said, yeah, it actually did see my monitor. What's the problem? P244W, that's definitely the model number of my monitor. So it saw it. So how come it didn't actually light up? It turned out that the connectors weren't seated far enough. These DVI connectors, they can be very finicky, it seems in my experience. And eventually I did get it to light up the monitor and got to see the BeagleBoard dog with his tongue sticking out and so forth. And there's a lot of stuff. There's 600 plus meg of RAM available. There's almost 10 gig of disk available even after all of the initial loads and so forth. And you can run Emacs because of course that's the first thing I installed. I always use XIs to test the display stuff, got the watching the temperatures. And again, it's 88 degrees Celsius, that's toasty. But I think this was distressing. I actually got internal compiler errors in the G++ compiler. It should be bulletproof. I suspect that might be due to temperature. I'm not sure. It happened a couple of times, but eventually I got the thing to build anyway. So I'm not sure how that could be anything but some kind of hardware unreliability. But clearly these things, a fan is not optional for the BeagleBone AI. But I got it built. And I started up and sure enough, this was doing the diffusion limited aggregation demo, the DLA demo, because that was the first one that compiled and I didn't want to wait anymore. The temperatures are almost hitting 90 degrees centigrade. But it aggregated and it actually worked. So that was pretty cool. Bottom line is the BeagleBone AI in the future for the T2 tile or the T2.5, something. Partly I don't know. I don't know the header layouts and stuff. The assumption would be probably have to end up doing a new board spin anyway. And if it was going to be a significant enough redesign for that, then maybe there would be a time to just sort of go to the T3 and think about FPGAs and all kinds of other things. So the BeagleBone AI may not be right, but it's got a lot of cool stuff in it. And I sure would love to get to redesign around having four of those co-processor peruse instead of just the two that we have available. But supposedly the main event is this cache update stuff in the lock state machine. I got myself so wound up trying to figure this out. I actually spent like a day plus writing a report to myself about what I was proposing to do. Redesigned the lock state machine for faster cache updates. And I'm actually going to put this in the repo for the T2 because it has a lot of background information that might be useful or so forth. But at least it's a part of the record. But here's the idea. So where's figure here? So this figure right here. So if intertile, the way it works is tile A decides he wants to have an event that would involve tile B. It tries for the lock between A and B. Tile B says, OK, you can have it. Once it's got the lock, it performs the event, figures out whatever changes are necessary, sends a cache update begins, sends cache updates saying this change, this change, this change, sends a cache update end packet at which point tile B sends back a cache update act, saying I got it, I applied it. And at that point tile A says release the lock and tile B says the lock is freed. That is a complete event. And the lock exchanges take microseconds and stuff, but they're actually the relatively faster part of the interaction. And what I thought of was if we let tile B release the lock, instead of having tile A do it, even though tile A is the one that took it. So in the sense of locking, you'd assume that whoever locked the door would be the one that would unlock it, but there's no reason why it has to be that way. And then you're sort of viewing the locking and unlocking not really as lock so much as just rapid signals. And if we had tile B, if we had tile A take the lock, tile B free the lock, then we could get rid of the cache update act packet entirely. And we could have something more like, we could have something like this, try to lock lock given, send cache update, release the lock and we're done. And this in my mind is our route to one air, you know, maybe we don't need it, maybe we do, but this is why I was going for it. And so it involves a bunch of changes. So we've got these little graphs. These are the state machine graphs. This is the current one, but whoops, this is that was the current one. This is the one that we currently bought the stuff that's in red. These guys is just getting set up. It's sitting in idle is normally where you are. And then either side might try to grab it and it goes from take to take in. And the other side goes from idle to given and then take goes to release and back to idle. And the idea was let's take release and move it over to the other side. And so did that. So now release is over on the given side. When I started working through it, it turned out that we needed an intermediate state. So the taken didn't go straight back to idle under certain circumstances. And in particular, the side that took the lock also needs to be able to free it. So that was the hole in this whole idea of mine, which of course I spent a tremendous amount of time developing the whole thing before I realized this obvious limitation. What is the obvious limitation? Well, tile A, the one that's having an event, it might need to take two locks between the northeast and northwest that they could both be involved. And it might be the case that it gets the northwest one but then is unable to get the northeast one because northeast goes and does something else. As a result it need now tile A needs to release the lock that it did get but in the original improved version the lock was being given released by the far side. The far side didn't know that the event was blown up. So now the version two intertile state, well a lock state machine, which this is implemented and I've been playing around with this and it's working for the basic case but I'm not entirely happy about how it's dealing with contested locks and so forth. The release procedure is the normal way that the guy who gave the lock says, okay, I applied your cache update, we are done. It goes through release. If the active side, the one that's having the event, tried to get multiple locks and failed, it goes through the drop procedure and they both end up releasing the lock either way. We'll see how it works. And that's coming along and that's it. So next week is the 52nd T Tuesday update. Thanks for being here. Have a good week.