Control bits and Memory (Data and Program)

[ouverson]

Was going through Unit 5.1: Von Neumann Architecture this morning and there seemed to be a discrepancy in control bits going in and out of Memory.

Slides: https://docs.wixstatic.com/ugd/56440f_96cbb9c6b8b84760a04c369453b62908.pdf

Slide 86 shows the ROM32K having one input and one output. This lines up with HDL spec: ROM32K(address= ,out= );

Slides 5 and 13 (all data, address, and control buses) show control bit going IN to Memory; doesn't specify whether that is Program or Data memory.

Slide 12 shows a control bit coming OUT of Program memory.

Could you please help me understand the control bits within the context of Memory: both Data and Program.

Thank you.

[WBahn]

I'm assuming that those slides are sync'ed to some video or audio that explains the point they are trying to make with each one. Without that, there's not enough context to be sure.

The early slides are talking about the a very generic case and not the Hack architecture specifically.

The Hack architecture discussion doesn't start until Slide 28.

In the specific architecture of the Hack, the instruction memory is ROM and only has an address bus for input. If it were a physical part, it might have pins that enable you to write to it, but that would be used to program the part before it was installed in the computer (or, with certain parts and system designs, you can do what is known as "in-circuit programming" of them). The point, though, is that the program the Hack is running is preloaded into the ROM and the Hack has no ability to change it. The RAM, on the other hand, needs a write-enable (or load) input bit since the Hack CAN change the contents of that memory.

[ouverson]

It looks to me that Noam is separating both Data (RAM) and Program (ROM) as he is discussing the Von Nuemann architecture. But no worries. I think I can track with most of what was covered without getting hung-up on an arrow possibly pointing in the wrong direction.

I see what you're saying about the ROM, RAM and the control bits. That makes sense with slides 28 on and the last project.

Thanks again for the timely help.

[WBahn]

ouverson wrote

It looks to me that Noam is separating both Data (RAM) and Program (ROM) as he is discussing the Von Nuemann architecture. But no worries. I think I can track with most of what was covered without getting hung-up on an arrow possibly pointing in the wrong direction.

I see what you're saying about the ROM, RAM and the control bits. That makes sense with slides 28 on and the last project.

Thanks again for the timely help.

There are a couple of schools with regards to nomenclature.

One (which seems to include most of the schools in the U.S. and I don't know where else) makes a distinction between two types of stored-program computer, the von Nuemann architecture and the Harvard architecture. The other, which seems to include Israel as best I tell, makes a distinction between two types of von Nuemann architecture, the Princeton architecture and the Harvard architecture.

So in the U.S. terminology, whether the data and code reside in the same memory makes the difference between a von Nuemann Architecture machine and a Harvard Architecture machine, but both are examples of a stored-program machine.

In the other terminology, whether the data and code reside in the same memory makes the difference between a Princeton Architecture machine and a Harvard Architecture machine, but both are examples of a von Nuemann machine.

So when the authors talk about a von Neumann machine or architecture, they are referring to the broader concept of a stored-program machine and whether the instructions and code reside in the same memory is immaterial.

In some architectures, some of the bits form the instruction ROM aren't decoded by the CPU and, instead, go directly to other devices, so saying that the instruction ROM sends outputs to the control bus is not incorrect, in general. I don't know if this is what the authors were thinking of or not when they made the slides. Given the number of slides and how they were most likely made, it's also quite possible that they got a bit sloppy with one of them.

[ouverson]

Thanks for details. It was spot-on what I needed.