pushed draft changes for the

cambridge document

docs/RISCV-FAT/Paper/paper.org

@@ -1,3 +1,5 @@
+#+LATEX_HEADER: \usepackage[inkscapelatex=false]{svg}
+
 * FAT Allocator without the TLB
 
 ** Abstract
@@ -13,10 +15,10 @@ are the technique expected to be used and the evaluation criteria for the follow
 2. To what extent does eliminating TLB impact the reduction in CPU clock cycles and memory access latency ?
 
 ** Proposed approach
-#+attr_latex: :width 300px
+#+attr_latex: :options angle=270
 #+CAPTION: FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.
 #+NAME: fig:RFPBRA
-[[./diagram/MainOverview.png]]
+[[./diagram/ProposedArchitecture.drawio.png]]
 
 FAT-Pointers based range addresses, combined with the capabilities of the CHERI architecture, introduce 
 bypassing the TLB hierarchy by incorporating additional metadata with memory pointers. 
@@ -29,9 +31,36 @@ over memory regions. The functionality of ranges encompasses several key aspects
 - Encoding Ranges as Bounds to the Pointer.
 - Instrumenting Block-Based Allocators with the FAT Pointer. 
 
-In figure [[fig:RFPBRA]], the green-highlighted section marks the unused space between the 48th and 64th bits 
+In Figure [[fig:RFPBRA]], proposes a hybrid system that operates alongside the MMU and enables the 
-within the FAT-pointer. This area of unused bits presents an opportunity to store additional metadata, 
+conversion of virtual addresses to physical addresses without requiring a TLB lookup or a Page Table Entry 
-potentially enhancing the capabilities of the memory management system. 
+(PTE) translation. To provide a basic overview, the red/orange line illustrates the standard translation 
+path from a virtual to a physical address, while the green line represents our proposed approach. 
+This method leverages CHERI capabilities to define memory ranges using bounds and to perform address 
+translation directly at the pointer level, rather than traversing multiple TLB caches and/or accesing the page table. 
+The diagram follows the SV39 addressing scheme.
+
+*** The standard translation procedure
+When a store, load or fetch instruction is issued, the virtual address, 39 bits in length, comprises several fields: 
+the Virtual Page Number (VPN) fields 2 to 0, each 8 bits wide and an 11-bit offset. The VPN is first checked within 
+the TLB hierarchy to determine whether a corresponding Physical Page Number (PPN) can be found. If it exists, the 11-bit offset 
+from the virtual address is reused to construct the physical address, which can then be used to access the desired memory location.
+If the translation is not present in the TLB hierarchy, a page table walk is initiated by consulting the PTEs. A PTE 
+can either reference another PTE or serve as a base PTE, as determined by its permission bits. For a 4 KB translation 
+entry, this lookup may require up to three memory access cycles to complete the PTE translation, excluding any additional 
+cycles incurred due to a TLB miss.
+
+*** Our approach
+We take advantage of the CHERI Capability 128 bit format and extend it by 16 more bits to store our custom offset. 
+On translation we only use VPN2 and keep the other VPNs identical to the PPN. In the conversional scheme this would be 
+only the case if we are allocating a giga page. In our case we just need a single VPN and PPN since we have use the bounds to dynamically 
+control the size of a page and using the proposed 16 bit offset to add to the VPN to get the PPN. This means the entire translation can be 
+done in single clock cycle. 
+
+*** Allocation approach
+For practical reasons when calling malloc from a C program which calls mmap under the hood for mapping memory we wouldn't change 
+much of calling kernel function calls such as pmap_store to create a PTE entry. But at hardware level we will extended 16 bits to 
+store the offset for getting PPN2 to construct the physical address. If the 16 bits is set of we will program the TLB flush instruction 
+(i.e Sfence.vma) to do nothing. This because we do not promote PTE entries to the TLB since they are not needed.
 
 #+attr_latex: :width 500px
 #+CAPTION: Toooba processor with pseudo code change to bypass DataTLB.
@@ -64,7 +93,6 @@ returned data written to the appropriate physical register. Generally, the memor
 the new access types, incorporate the Data TLB bypass mechanism, and include the necessary capability checks to ensure that accesses 
 are properly authorised.
 
-** Proposed evaluation
 The evaluation of the proposed FAT allocator implemented using CHERI-enhanced pointers on the RISC-V Toooba architecture 
 aims to assess both its performance characteristics and architectural implications, particularly in the context of removing 
 the Translation Lookaside Buffer (TLB) from the memory access pathway. The evaluation methodology is designed to address 

docs/RISCV-FAT/Paper/paper.tex

@@ -1,4 +1,4 @@
-% Created 2025-06-18 Wed 19:47
+% Created 2025-10-28 Tue 00:53
 % Intended LaTeX compiler: pdflatex
 \documentclass[11pt]{article}
 \usepackage[utf8]{inputenc}
@@ -12,6 +12,7 @@
 \usepackage{amssymb}
 \usepackage{capt-of}
 \usepackage{hyperref}
+\usepackage[inkscapelatex=false]{svg}
 \author{Akilan}
 \date{\today}
 \title{}
@@ -27,10 +28,10 @@
 \tableofcontents
 
 \section{FAT Allocator without the TLB}
-\label{sec:orga3b6b50}
+\label{sec:org3c371b1}
 
 \subsection{Abstract}
-\label{sec:org5961619}
+\label{sec:org77e5c87}
 This document explores an extension of the FAT allocator approach to memory management in RISC-V Toooba\cite{rugg_2022}. 
 CHERI introduces a fine-grained memory protection mechanism by embedding bounds and permissions directly 
 within pointers. Leveraging this model, we propose a system in which offsets are stored within the pointer itself, enabling 
@@ -38,17 +39,17 @@ direct memory access without reliance on traditional address translation mechani
 facilitates the design of a block-based memory allocator within physically contiguous memory. The sections expanded below
 are the technique expected to be used and the evaluation criteria for the following experiment. 
 \subsection{Research questions}
-\label{sec:orge1b3555}
+\label{sec:org86efcda}
 \begin{enumerate}
 \item How can embedding offsets within a FAT pointer (i.e CHERI pointer) improve memory accesses for a block-based allocator for the RISC-V CHERI modified Toooba architecture ?
 \item To what extent does eliminating TLB impact the reduction in CPU clock cycles and memory access latency ?
 \end{enumerate}
 \subsection{Proposed approach}
-\label{sec:orga716280}
+\label{sec:orga490a28}
 \begin{figure}[htbp]
 \centering
-\includegraphics[width=300px]{./diagram/MainOverview.png}
+\includegraphics[angle=270,width=.9\linewidth]{./diagram/ProposedArchitecture.drawio.png}
-\caption{\label{fig:orgf01f491}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
+\caption{\label{fig:org84f2a68}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
 \end{figure}
 
 FAT-Pointers based range addresses, combined with the capabilities of the CHERI architecture, introduce 
@@ -64,18 +65,45 @@ over memory regions. The functionality of ranges encompasses several key aspects
 \item Instrumenting Block-Based Allocators with the FAT Pointer.
 \end{itemize}
 
-In figure \ref{fig:orgf01f491}, the green-highlighted section marks the unused space between the 48th and 64th bits 
+In Figure \ref{fig:org84f2a68}, proposes a hybrid system that operates alongside the MMU and enables the 
-within the FAT-pointer. This area of unused bits presents an opportunity to store additional metadata, 
+conversion of virtual addresses to physical addresses without requiring a TLB lookup or a Page Table Entry 
-potentially enhancing the capabilities of the memory management system. 
+(PTE) translation. To provide a basic overview, the red/orange line illustrates the standard translation 
+path from a virtual to a physical address, while the green line represents our proposed approach. 
+This method leverages CHERI capabilities to define memory ranges using bounds and to perform address 
+translation directly at the pointer level, rather than traversing multiple TLB caches and/or accesing the page table. 
+The diagram follows the SV39 addressing scheme.
+\subsubsection{The standard translation procedure}
+\label{sec:orgb1a087e}
+When a store, load or fetch instruction is issued, the virtual address, 39 bits in length, comprises several fields: 
+the Virtual Page Number (VPN) fields 2 to 0, each 8 bits wide and an 11-bit offset. The VPN is first checked within 
+the TLB hierarchy to determine whether a corresponding Physical Page Number (PPN) can be found. If it exists, the 11-bit offset 
+from the virtual address is reused to construct the physical address, which can then be used to access the desired memory location.
+If the translation is not present in the TLB hierarchy, a page table walk is initiated by consulting the PTEs. A PTE 
+can either reference another PTE or serve as a base PTE, as determined by its permission bits. For a 4 KB translation 
+entry, this lookup may require up to three memory access cycles to complete the PTE translation, excluding any additional 
+cycles incurred due to a TLB miss.
+\subsubsection{Our approach}
+\label{sec:org8444c1b}
+We take advantage of the CHERI Capability 128 bit format and extend it by 16 more bits to store our custom offset. 
+On translation we only use VPN2 and keep the other VPNs identical to the PPN. In the conversional scheme this would be 
+only the case if we are allocating a giga page. In our case we just need a single VPN and PPN since we have use the bounds to dynamically 
+control the size of a page and using the proposed 16 bit offset to add to the VPN to get the PPN. This means the entire translation can be 
+done in single clock cycle. 
+\subsubsection{Allocation approach}
+\label{sec:org0b445b8}
+For practical reasons when calling malloc from a C program which calls mmap under the hood for mapping memory we wouldn't change 
+much of calling kernel function calls such as pmap\textsubscript{store} to create a PTE entry. But at hardware level we will extended 16 bits to 
+store the offset for getting PPN2 to construct the physical address. If the 16 bits is set of we will program the TLB flush instruction 
+(i.e Sfence.vma) to do nothing. This because we do not promote PTE entries to the TLB since they are not needed.
 
 \begin{figure}[htbp]
 \centering
 \includegraphics[width=500px]{./diagram/Toooba-codesnippet.png}
-\caption{\label{fig:org8363643}Toooba processor with pseudo code change to bypass DataTLB.}
+\caption{\label{fig:orgf8a8c01}Toooba processor with pseudo code change to bypass DataTLB.}
 \end{figure}
 \subsubsection{Implementation}
-\label{sec:org4e24323}
+\label{sec:orgb1f02ff}
-The figure \ref{fig:org8363643} above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture. 
+The figure \ref{fig:orgf8a8c01} above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture. 
 On the right-hand side, the pseudo-code of the BlueSpec\cite{bluespec} implementation highlights the modifications that we will need to do to the 
 memory pipeline in order to bypass the use of the Data TLB and instead utilise the offset from the pointer. The primary focus will be 
 on the memory pipeline.\\
@@ -101,21 +129,20 @@ to support out-of-order execution. Memory responses will be processed asynchrono
 returned data written to the appropriate physical register. Generally, the memory pipeline will remain unchanged, except to support 
 the new access types, incorporate the Data TLB bypass mechanism, and include the necessary capability checks to ensure that accesses 
 are properly authorised.
-\subsection{Proposed evaluation}
+
-\label{sec:orgc0caeea}
 The evaluation of the proposed FAT allocator implemented using CHERI-enhanced pointers on the RISC-V Toooba architecture 
 aims to assess both its performance characteristics and architectural implications, particularly in the context of removing 
 the Translation Lookaside Buffer (TLB) from the memory access pathway. The evaluation methodology is designed to address 
 the research questions with a focus on improvements in memory access and reductions in 
 latency for address translation.
 \subsubsection{BlueSpec simulator}
-\label{sec:org2206786}
+\label{sec:orgc16a3f1}
 To evaluate the proposed FAT pointer based memory management architecture, we plan to conduct simulations using the 
 Bluespec SystemVerilog (BSV)\cite{bsv} framework. Bluespec provides a cycle-accurate hardware simulation environment that 
 allows precise modelling of architectural behaviour, including custom memory pipelines, capability checking, and 
 physical address translation bypass mechanisms. 
 \subsubsection{Performance Metrics}
-\label{sec:orgf6cbf89}
+\label{sec:org17217ed}
 
 To quantify the performance benefits of the proposed system, the following metrics will be investigated:
 
@@ -135,7 +162,7 @@ An analysis of the number of instructions executed during allocation, deallocati
 determine whether the additional logic required for handling FAT pointers introduces meaningful overhead.
 \end{itemize}
 \subsubsection{System Resource Utilisation}
-\label{sec:org629ea18}
+\label{sec:orgfdcde67}
 
 \begin{itemize}
 \item \textbf{Cache behaviour}  
@@ -147,7 +174,7 @@ Although the system does not utilise a TLB, comparative analysis will be perform
 the performance cost typically incurred through TLB misses, thereby contextualising the advantage of their removal.
 \end{itemize}
 \subsubsection{Benchmarking Against Baseline Architectures}
-\label{sec:orgb71ca58}
+\label{sec:org1e3184e}
 
 A series of micro and macro benchmarks will be employed to compare the FAT allocator with traditional memory allocators that rely on virtual 
 memory and TLBs. Micro benchmarks will include fine-grained tests of memory operations, while macro benchmarks will involve application-level