CS154 Lab8:PageTableWalkerinPyRTL

University of California, Santa Barbara Dept. of Computer Science
Lab8:PageTableWalkerinPyRTL
Assigned:
Due:
Points:
Wednesday, February 28th, 2024
Wednesday, March 6th, 2024
100
• MAYONLYBETURNEDINONGRADESCOPEasPYTHONfiles(seebelowfordetails).
• There is NOMAKEUPformissedassignments.
• Westrictly enforce the LATE POLICY for all assignments (see syllabus).
Goals for This Lab
During this lab you will learn how to build a Page Table walker in PyRTL. In doing so, you
will learn the basics of Virtual Memory implementations in hardware.
Figure 1: From the Lecture Slides on Page Table Walkers (via David Wentzlaff from
Princeton). Notice how each entry in the page table will lead to a new page
©J. Balkind, 2024
CS 154
Page 1
University of California, Santa Barbara Dept. of Computer Science
Task andBackground
Your task is to implement a 2-level Page Table Walker. Recall from class that
virtual addresses used by programs are translated into physical addresses before accessing
memory. All the translations are held in a data structure in memory called a page table.
Using a page table with 1 level results in page tables that are too large. Instead, we use
hierarchies of page tables (see the figure above). Each level’s page table holds the offset into
the next level’s page table until you reach the final level where the physical page numbers
are located. A page table walker is a piece of hardware which traverses this hierarchy. The
traversal of this hierarchy takes two memory accesses.
Provided Files
Wehaveprovided the skeleton file ucsbcs154lab8_ptw.py, where you will need to
implement your page table walker. You will upload the solution to gradescope as
ucsbcs154lab8_ptw.py
Inputs and Outputs
Inputs:
Alarge part of this lab involves decoding input signals. There are 4 input signals:
“virtual_addr”: This is the virtual address. The virtual address should be split into three
components shownbelow:
Each offset corresponds to the offset from the page location to get to the desired
entry. The offsets are listed in order of usage, so offset 1 is the offset to use in the
first step of the walk, offset 2 in the second step, and offset 3 to get the physical
address.
“new_req”: 1 if there is an incoming request for translation, 0 otherwise in which case you
should do nothing.
“reset” : If 1, then reset the state back to 0 (stop translating)
“req_type” : 0 if the request is a read, 1 if the request is a write
©J. Balkind, 2024
CS 154
Page 2
University of California, Santa Barbara Dept. of Computer Science
Outputs:
“physical_addr”: the translated address signal ONLY WHEN THE PAGE WALK IS FINISHED
(until then it should stay 0x0)
“dirty”: 1 if the page table had the dirty bit enabled
“valid”: 1 if the page table had the valid bit enabled
“ref”: 1 if the page table had the ref bit enabled
“finished_walk”: 1 if the walk has finished, i.e. the physical address is ready
“error_code”: one of four options dictated by the table below:
Error Code
000
Meaning
Noerrors
Stages it can be seen on
States 0b00 0b01 0b10
001
010
100
Page Fault during walk
States 0b00 0b01 0b10
Trying to write entry which is not writeable State 0b10
Trying to read entry which is not readable
Other Important Signals/Pieces:
State 0b10
“state” : current state of the page table walker (more to be discussed below)
“page_fault” : You are not required to output this signal directly but it can help in
simp