Memory Hierarchy Model

a Physical mapping by James Slentz and Kristofer Eisenmenger

 Group and Responsibilities

Group: Kristofer Eisenmenger and James Slentz

Concept: James Slentz and Kristofer Eisenmenger
Concept Elaboration: James Slentz
Material Prep: Kristofer Eisenmenger
Assembly: James Slentz
Documentation: Kristofer Eisenmenger

James Slentz:
James “Jim” Slentz is a 4th year Computer Science major and the head student
manager for the University of Florida Men’s Football team. For this Physical
representation of Memory Heirarchy Jim took our abstract idea of a flowing water to
represent data and ironed out the details until it became a fountain. While Kris handled
the painting and texturing, Jim handled the assembly of the fountain. Troubleshooting
was handled as a team, yet Jim developed most of the solutions. The assembly itself was
sadly done twice. After the initial testing of the fountain Jim discovered that out textured
paint wasn’t water proof and the resulting mess actually broke the seals at each level
forcing the team to reattach the fountain levels.

Kristofer Eisenmenger:
Kristofer “Kris” Eisenmenger is a 4th year Computer Engineering major and
currently a full time student. Kris developed the idea that we should use flowing water to
model the data flow in the Memory Hierarchy. Kris also was charged with writing the
description of the source to target mapping. The Texturing was handled by Kris and he
found the “rock” spray-paint to use. However, this very spray-paint forced the team to
reseal the PVC layers. Kris redeemed himself when he found a waterproof sealant to
spray on the fountain.
 Memory Hierarchy has two very important concepts. First is the actual physical
hierarchy that data follows as it travels through a computer. Second is the amount of
time it takes to access data at each level. In this Physical mapping we address both of
these important concepts.
The source diagram found in Addendum A can actually be mapped into two
separate trees. First we have the doubly linked list data access tree, see Addendum B, in
which we see that Data can flow in either direction and from any level to the next and
back again. The address tree, Addendum C, shows that to find the data at each level we
must step through each level in sequence. However, when we combine the two trees we
see that while the address only lets us move down we are able to stop at any point and
retrieve the data.
The fountain portion of this project is a direct mapping of data flow. The water
itself is representative of the Data. All data in a memory hierarchy is either created in or
moved by the processor. Thus the plastic tank can be thought of as the processor. The
tall slender tubing would be the registers in the processor, they are very small and thus
fill up very quickly with data (in this case the water from our tank).
The next water tube (1.5 inch), working from the inside out, can be mapped to
level 1 of cache. Again it still fills up relatively quickly and in keeping with our data
flow the processor writes to registers first and then when it doesn’t have enough room
moves register information out along the memory hierarchy path.
The 4 inch pipe would be level 2 cache. Again we see that the data flow from our
target structure is upheld because it receives data from level 1 cache when that becomes
full. The level 2 cache then overflows into main memory.
In this representation main memory would be the 6 inch connector. Again the
data flow is preserved because it receives data from cache level 2 when that level
becomes full. In our physical representation the water also overflows out of main
memory, and back into the processor. We implemented this because it wasn’t practical to
force someone to shut off the pump just as main memory became full. In terms of the
processor we could think of this overflow as a memory or stack overflow. Thus any data
the processor sends is lost if memory is already filled with valid data.
The observer of the system is actually in control of the register lines in the system.
In this case the register lines are the valves in our water source. Thus the observer acts
like the fetch command inside the processor and retrieves the data by opening the desired
valve. The register level doesn’t have a valve rather if we turn off the data flow we then
allow data to be accessed at that level (much like a processor doesn’t allow you to read
and write at the same time).
We also map the memory write times to the amount of time it takes our pump to
fill each tube. Registers are written to very quickly, while each subsequent level takes
just a little longer to fill. The main memory level of course takes the longest since it is
the farthest away from our processor.
Addendum A
Source Structure
 Addendum B
Data Bus Mapping

Data bus memory lines can be effectively represented as a doubly linked list. This way
the idea of being able to insert a new memory module any where along the chain is
preserved. The reason that memory hierarchy is organized in its current form is because
each of the levels represents faster to slower memory, where registers are the fastest and
main memory is the slowest. We see from the tree that new memory modules can be
inserted anywhere along the chain so long as they preserve the backward and forward
links.

0.25 inch 1.5 inch 4 inch 6 inch

pipe pipe pipe pipe
CPU Registers

Level 1 Cache

Level 2 Cache

Main Memory

All data lines are

represented by the
cascade of water
between each level
 Addendum C
Address Line Mapping

The address lines are easily mapped to a singularly linked list. Here we cannont use a
DLL (doubly linked list0 because address locations in memory only map one way. The
DLL model would imply that one can address a location is higher memory relative to a
lower memory device. Thus we could have multiple address for each piece of data, since
an address would be relative to where we are looking from. The memory addresses must
be a linked list though because we want the flexibility to insert new memory modules
into the system. Just like the data bus mapping in Addendum B, a new module can be
inserted anywhere along the hierarchal chain.

Fill tube Valve A Valve B Valve C

CPU Registers

Level 1 Cache

Level 2 Cache

Main Memory

Human interaction is
the register line
because they
determine which
level data will be
accessed at. i.e. turn
the proper value to
drain the level