Building a 256-Byte RAM in a Digital Logic Simulation

[00:00:01]Hello everyone and welcome back to the series where we've been exploring some basics of how computers work. Our efforts thus far have culminated in this little setup here containing two 4-bit registers each able to remember a single number. And so for example, we could store the number 15 in the first one and let's say 10 in the second one. Then using our alou, we're able to take those two values and do any calculation we want. so long as it's addition or subtraction. So, I'll set it up to do 15 minus 10. And then if we pulse the clock, we can see the answer now stored over here. That's obviously incredibly exciting, but there's still some ways to go before we could reasonably call this a general purpose computer. And problematically, we're already rather running out of room in this little simulation program. So, I've been gradually tinkering away on a new version that's at last ready to be put to the test today.

[00:00:59]As you can see, it looks pretty similar, but there are some important differences. For example, the input pins are now standalone elements rather than being tethered to the side of the screen, which means that we can now zoom in and out and roam around to our heart's content. Plenty of space to build a computer. The input pins, by the way, now also come in 4-bit and even 8- bit varieties so that we don't need to manually manage all those individual wires, which I hope will make our lives a bit less tedious as we try to build more elaborate things. All right, the first elaborate thing I'd like to try tackling today is the main memory of our computer. Because while these individual registers are great for remembering single values that are being worked with right now, we're going to want something a lot larger where we can store the results of our various calculations and access them later as the need arises. So let's crack open one of these registers just to remind ourselves of what's inside. And to no great surprise, it simply contains four one-bit registers.

[00:02:00]We could certainly build our main memory out of these, but they contain a bunch of logic mainly for handling synchronization with the clock signal that we don't really want to be duplicating over and over for every bit of memory. It would just be kind of wasteful and slow, I think. But we've now arrived at our fundamental building block of memory that we constructed from a pair of norates where each output feeds back into the input of the other to keep a single bit of data locked firmly in place.

[00:02:28]So, I think our plan should be essentially to just create a giant grid of these little latches that we can activate individually based on a given memory address. Let's give that a try. And we should probably start somewhat small with just a 4x4 grid perhaps. And that means that we'd need a 4bit address to cover all 16 latches.

[00:02:51]We could think of the bottom two address bits as specifying the row and the other two bits as specifying the column. So this bottom left latch, for example, we could say should only be active if both the row and column address bits are zero. And the latch next to it should only be active if the row is zero and the column is one and so on and so forth. Okay, let's quickly create a new chip to help us out with this address detection. So this will have a two- bit input. Let's imagine those are the column bits of the address. And we wanted to simply decode that into four individual output bits that indicate whether column 0 is active or column 1, column 2 or column 3. I think that should be easy enough. We can just plop in four and gates over here and wire these up to each of the outputs.

[00:03:42]Then to detect an input of zero, we simply need to test for both input bits being zero. So let's quickly invert both of the inputs, then wire them up to the first and gate. And we can of course see output zero now lighting up. Even easier than this is detecting an input of three since we just need to know if both inputs are on. And so we can wire them up to this and gate directly. All right, let's then handle the detection of an input of two, which just means that the first bit must be off and the second bit must be on. Finally, to detect an input of one, it's obviously the other way around. The first bit is on and the second bit is off. Okay, let's save this little decoder chip and I'll specify in the name that it's decoding a two bit input in particular. Just for fun, here's a real life version of the chip we just built. So currently zero is selected.

[00:04:37]Then one two and three. All right. Now going back to our grid of latches. Let me move these along to give us some space here quickly. And then we can bring in two of our new decoder chips. One for the columns and one for the rows. And of course we'll want to feed the memory address input into these two decoders.

[00:05:01]Then as we were talking about earlier, we can have an AND gate over here that just says that if row zero is enabled and column Z is enabled, then this bottom left latch will be open for business. It's going to be a bit annoying to add in and gates for every latch, though. So, let's actually make another little chip to help us out here.

[00:05:21]I've set this up with the same data and store inputs as the latch, but then also these new row and column inputs. To make use of these, let's add in a latch and an endgate. Actually, I suppose we'll need two of them. The first and gate tests if the row and column are both active, meaning that this latch has been selected, and only if that's the case, and the store signal is on, will we want to write the input data into the latch. We also only want to output the data from the latch if it is selected.

[00:05:52]Otherwise, we just want it to be essentially disconnected. And in this simulation, we can do that using the three-state buffer that we've talked about previously. So, let me just grab that from the chip library quickly and wire it up. All right. So we can see that when the latch is not selected, the output signal here is just black, indicating that it's outputting neither a high logic level nor a low logic level, but rather it's just completely disconnected. And only if both the row and column inputs are on, will it actually output the state of the latch.

[00:06:25]So currently that happens to be high.

[00:06:27]The initial state is just random, but we can try storing a zero in there instead.

[00:06:32]And now we can see that the output is low.

[00:06:35]Okay, let's give this little sort of one bit memory cell a name. Maybe MEM1 for short. I quickly want to mention, by the way, that real world memory cells are extremely optimized, of course, using as few as six transistors and many clever ideas to make the whole thing as small and reliable as possible. We would need a much more advanced simulation to delve into all of that, but I hope to get there someday.

[00:06:59]Also, this latchbased approach is actually only used for fairly small memory chips, like a handful of megabytes at most, because while it's very fast, it takes up quite a lot of physical space. So, memory in the realm of gigabytes is typically constructed out of capacitors instead, though somewhat smaller ones than I'm holding here. Capacitors store electrical charge. So, if we plug this in, currently it's empty, which we can represent as a zero. But if we send some power its way, it will quickly charge up and we can call that a one. Then when the input goes away, the charge remains.

[00:07:32]So it's remembering a single bit of information. Am I charged or not charged? What's a bit tricky though is that if we want to read the data, then the capacitor will be discharged, meaning that the memory is lost. And the charge also annoyingly just leaks away over time. And we're talking fractions of a second at tiny scales. So this kind of memory requires some extra circuitry to constantly read and rewrite its entire contents to keep it nice and fresh. That sounds a little ridiculous, but the fact that one bit of memory can be stored with just a single capacitor and one transistor to enable or disable the output makes it very compact. This by the way is known as dynamic memory due to the constant refreshing. Whereas our latchbased approach is called static memory.

[00:08:18]Also, while we're on this brief terminology tangent, I want to add that both of these require a constant source of power, of course, otherwise the data is lost. And so, they're examples of volatile memory. To remember stuff, even when powered down, the data has to be transferred to some slower kind of persistent memory. So, that could be, for example, one of these old spinning discs with this little arm that swings out and is able to store data longterm by changing the magnetic polarity of tiny regions on the disc. Anyway, I should stop rambling and let's return instead to the simplicity of our simulation where we have our column and row decoders set up already, but now we're going to create a grid of those memory cells we made. And let's wire these all up. So, we've got to get all the row and column bits connected to each chip while doing our best to keep things at least reasonably tidy.

[00:09:12][Music] Okay, that's the rows finished. And now for the [Music] columns. With that done, let's give it a quick test. So, just focusing on the first two address bits. That seems to be selecting the rows correctly. And then let's toggle the last two bits. And that does seem to be selecting the columns correctly as well.

[00:09:40]So next up, we of course need a data input and that also needs to be wired up to every [Music] cell. Then we'll need a store input. But we should think ahead a little bit here because to expand on this, we'll want this little grid of 16 cells to itself become a cell in a larger grid. So this actually needs its own row and column inputs. And let's be diligent about coloring these consistently. And then we can bring in a pair of ant gates and set them up just like in the first cell we made. And with that done, we can hook up the store [Music] signal. Okay, that's all the inputs handled, but we still need to collect the outputs from all of the cells. And we've made things easy for ourselves by ensuring that only one cell can be actively outputting its data at any time. So we can simply run a little wire through here to directly join together all of the outputs. And finally, like before, we'll again want the output to only be enabled if this cell is selected. All right, let's do a quick test to see if this thing is actually working. So first of all, we can maybe try storing a zero at the current address and then turn off the store signal. We can see that it is indeed outputting zero now and we could turn the data signal back on, but it doesn't do anything of course unless we tell it to actually store that data again. All right, let's also flick through a bunch of different addresses.

[00:11:22]And we can notice the output changing since the startup state of each latch is random as we've seen before. And finally, let's try disabling one or both of the row and column inputs here. And if either of them are off, then the whole cell becomes inactive. It's not outputting anything. And our store signal doesn't do anything either. Oh, it looks like we finished just in time for a surprise inspection.

[00:11:46]Uh, okay. If you have a look over here, you'll see the address bits. Never mind.

[00:11:51]Apparently, my water is far more interesting.

[00:11:57]Okay, I don't think you should be drinking on the job. So, time for the inspection at last. Some headbutts, some sniffing, all standard testing procedure, of course, and a little bribery to end with just in case there are some design flaws that require overlooking. All right, he says it's perfect. So, let's give this thing a name. And since it's made out of 16 memory cells, I guess we can just call it ME16.

[00:12:24]All right, the time has now come to take this new cell and construct another 4x4 grid. We'll again need a 4bit address to be able to select each of these 16 cells, plus another four address bits on top of that, of course, for the address input of each cell. So, let's bring in an 8 bit input for our address here and split that into two 4-bit values. one going to the address input of the cells and the other being split up and decoded into the column and row bits as before. Then let's hook up those column lines quickly and the row lines as well.

[00:13:20]We'll then also want a data and store signal, but I'm not planning to make another grid out of this new cell. So, we can leave out the row and column inputs this time and instead just go ahead and wire the two of these up. So, that's data done. And now we can do the store signal.

[00:13:46]Finally, we can just join all the outputs together on a single bit line like before since again only one of those outputs will be active at any time. Okay, that is done. So the top four address bits select one of the 16 bit memory cells in our grid. So we can see that this one here is selected at the moment. And then the bottom four address bits determine which of the one bit cells will be selected inside of there. So in total we're able to address 16 * 16 which is to say 256 individual bits of data. Let's call this then me 256. 256 bits is not super helpful though because obviously we typically want to store numbers not single bits of data. So, let's take this latest memory cell and just duplicate it eight times to give us 256 bytes of data instead.

[00:14:43]And we can add in an 8bit output pin and just connect the outputs of all the cells up to that. It would also be nice to have a decimal display of the output value. So, let's quickly grab one from the library here and then wire that up as well.

[00:15:06]As we can see, the current value happens to be 197. This display is something we built in a previous video. You might recall if you've seen that episode with all this double double stuff and binary to decimal decoding. It was a surprisingly long and intricate journey just to display some numbers.

[00:15:28]But because it's a bit of a pain, I have also, by the way, added in a somewhat lazier option of just automatically displaying the decimal value under the pins. So you don't have to suffer through all that if you're building this yourself. Anyway, let's get a move on with the inputs. We'll have our store signal as always and an 8bit address and data input.

[00:15:49]By the way, I've decided to color this incoming data in purple this time rather than red like we've done before just to help differentiate it from the output data [Music] here. All right, let's wire up the memory address next and finally the store signal. With that, we at last have our 256 bytes of addressable memory. So, let's flick through some addresses just to see the different values that happen to be stored in there at the moment. And of course, we can overwrite them with whatever data we want. So, at address 255, let's store a value of 150, for example. And then to test this a little, let's go to some other address and store a different value in there.

[00:16:43][Music] Now we can try returning to the previous address. And sure enough, our old value is still safe and sound. Just for fun again, here is a real life version of our chip, more or less anyway. So I'll plug this in here and then let's just mess about with it for a moment. So here's address 1, 3, 7, and 15. And let's store a zero in there.

[00:17:12]All right, that seems to work. So, let's head over to some other address. Here's address 14. And we can store maybe a value of 12 in there. Then, let's go back to address 15 where we can see our zero still waiting patiently for us. And let's just try overwriting that with some other value. All right, it's working nicely.

[00:17:32]What's great about this type of memory is that at least if you're not fiddling with the switches by hand, it takes the same amount of time to jump from one address to any other, which is in contrast, of course, to something like the hard drive disc we briefly considered earlier, which has to physically spin and swing its little arm around, meaning it can take shorter or longer depending on where it needs to go. But because the order of access doesn't matter for our memory here, it's an example of random access memory or of course RAM for short. Having said that, some programmers nevertheless do spend a lot of time worrying about the order in which they're requesting data from it.

[00:18:10]And that's because computers typically have a large amount of relatively slow dynamic RAM, which is that memory made from capacitors we talked about before, but then also a much smaller amount of this very fast static RAM called the cache, snuggled right up close to the CPU to minimize the commute. When some data is requested, the computer first goes to the cache to see if it's already in there by any chance, and if not, it has to go all the way to the slower main RAM to fetch it. On the journey back, it optimistically lugs along a load of surrounding data which it plops into the cache. The hope being, of course, that the next memory request will be at a nearby address. So, it can grab the data from the cache then to save itself another long road trip. We're not going to worry about any of this in our little simulation, but I thought it was worth just briefly mentioning anyway.

[00:19:00]All right, we're almost done for today.

[00:19:02]But there is one thing bothering me about our RAM chip here, which is that it's not synchronized with a clock. This means that we have to be very careful that the store signal is never on while we're busy changing the address value because otherwise we'll be overwriting data willy-nilly. That is easy enough to avoid while we're doing everything by hand, but it can introduce annoying race conditions once these inputs are instead being controlled by other parts of the computer. So, I'm going to try and just hack something together quickly to address the issue. Okay, firstly, I've made now this 8- bit register just out of eight one-bit registers since we've built that nice clock synchronization into these.

[00:19:44]Just as a reminder, the idea is that new data can only be stored into the register in the brief moment where the clock signal changes from low to high.

[00:19:54]Altering the inputs when the clock signal is already high does nothing. And also when it's low, nothing can happen.

[00:20:00]Of course, it's again only on the so-called rising edge of the clock that changes to the inputs take effect, letting us keep everything nicely synchronized.

[00:20:11]My plan now is to take our asynchronous RAM and just interact with it through these two synchronous registers for the address and data. So let's wire up the outputs of those as the inputs to the RAM chip. And then we should connect up the store signal here as well. Next, let's set up the inputs for the registers. And the data register should only be updated if the store signal is on, but the address can be updated either way. So we can just set its store input to always be on. Finally, let's add in an output pin and a decimal display. All right, let's give that a try. So if we set some data over here and alter the address, even though the store signal is already on, the RAM is getting its input from the registers and so it's not affected until we trigger the clock. That's great. Although it's worth noting that this would be risky in the real world since signals take time to settle into a stable state. So for instance, in the brief moment where the output of the address register has not quite stabilized yet, if the store signal is already on, we could be in trouble. A solution to that might be to write the store signal itself into a register along with perhaps some additional logic that delays it by one clock cycle to ensure that the address has had time to settle down. Thankfully, the simulation is a lot more forgiving in terms of timing though, and we can safely assume here that our signals will all arrive ready at the RAM chip at the same instant.

[00:21:43]One slight annoyance that remains, however, is that if we're simply retrieving data from RAM, let's say from address 51, for example, it's a bit bothersome to have to wait for the next clock pulse before RAM will actually see that new address. So, let's try instead just hooking the address input up to RAM directly. And then since we don't need to worry about precise timing considerations, we can simply add in some logic that says that it's now only able to store data if both the store signals on of course and the input address matches the address in the register. That way the RAM's output is always based on the most upto-date address value, but it will only store data in the clock synchronized address.

[00:22:27]Okay, we should try this out. But this 8-bit equality chip over here, I've set up the inputs and outputs already, but we still need to implement the actual logic. First though, let's quickly make one little helper chip that simply tests if two one bit values are the same. And we actually already have something very close, the exclusive or which tests if two bits are different. So we can just invert the result of that to make an exclusive norate where the output is only high if both inputs are the same.

[00:22:59]We can then easily scale it up to 8 bit inputs by just using eight copies of the XNO gate along with a bunch of AND gates to check that the result is [Music] unanimous. Then let's just make sure that this is doing what we want. So if we change one input, we can see that the output has turned off. And then if we change the other input to match it, the output turns back on again.

[00:23:28]All right, with that done, our synchronous RAM should hopefully be working. Let's give it a quick test.

[00:23:33]I'll start by just storing a zero into address zero. Then let's flip through some different addresses. And we can see that the output is updating right away, but even though the store signal is still on, it's not overwriting the data in those addresses thanks to our little address test here. Okay, let's try setting some more data. Maybe we want to store the value 42 into address 85. So we can pulse the clock to write that in. Then let's go back to address zero and make sure our value of zero is still stored in there, which it is. And maybe we can try changing the data input, turning off the store signal, and then running the clock or changing the store signal without running the clock. And in both cases, the memory is unaffected as it should be. All right, let's finally return to address 85. And we can see that our value of 42 is still safe and sound over there. So, at long last, we have some nicely behaved random access memory that we can use in our little simulated computer. Okay, to end with let's take a brief trip down memory lane to see how far we've come. So, we can take a look inside of the asynchronous RAM with its eight cells each storing 256 bits. And we can peek inside one of those to see our grid of 16 cells each storing 16 bits of data. This cell over here is selected for the current address. So let's continue the journey down into there where we can see yet another grid of 16 cells. This time storing just one bit each. Again this one is selected. So let's look in there. And inside this cell, we at last find our humble latch, which we can open up to see the single bit of data that it's holding on to over here. So, it's been quite a journey to get to this point, but still a long ways ahead of us, of course. That is all for today, though. So, thanks for watching and for all the support from patrons of the channel. Until next time, cheers.

[00:25:39][Music]