diff --git a/docs/RISCV-FAT/Paper/ProposedArchitecture.drawio.png b/docs/RISCV-FAT/Paper/ProposedArchitecture.drawio.png
new file mode 100644
index 0000000..6887003
Binary files /dev/null and b/docs/RISCV-FAT/Paper/ProposedArchitecture.drawio.png differ
diff --git a/docs/RISCV-FAT/Paper/ProposedArchitecture.drawio.svg b/docs/RISCV-FAT/Paper/ProposedArchitecture.drawio.svg
new file mode 100644
index 0000000..107a7ab
--- /dev/null
+++ b/docs/RISCV-FAT/Paper/ProposedArchitecture.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/RISCV-FAT/Paper/diagram/ProposedArchitecture.drawio.png b/docs/RISCV-FAT/Paper/diagram/ProposedArchitecture.drawio.png
new file mode 100644
index 0000000..6887003
Binary files /dev/null and b/docs/RISCV-FAT/Paper/diagram/ProposedArchitecture.drawio.png differ
diff --git a/docs/RISCV-FAT/Paper/diagram/ProposedArchitecture.drawio.svg b/docs/RISCV-FAT/Paper/diagram/ProposedArchitecture.drawio.svg
new file mode 100644
index 0000000..107a7ab
--- /dev/null
+++ b/docs/RISCV-FAT/Paper/diagram/ProposedArchitecture.drawio.svg
@@ -0,0 +1,4 @@
+
+
+
+
\ No newline at end of file
diff --git a/docs/RISCV-FAT/Paper/paper.org b/docs/RISCV-FAT/Paper/paper.org
index 8af1b2c..6230721 100644
--- a/docs/RISCV-FAT/Paper/paper.org
+++ b/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
-within the FAT-pointer. This area of unused bits presents an opportunity to store additional metadata,
-potentially enhancing the capabilities of the memory management system.
+In Figure [[fig:RFPBRA]], proposes a hybrid system that operates alongside the MMU and enables the
+conversion of virtual addresses to physical addresses without requiring a TLB lookup or a Page Table Entry
+(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
diff --git a/docs/RISCV-FAT/Paper/paper.pdf b/docs/RISCV-FAT/Paper/paper.pdf
index d76a8be..a49bb0e 100644
Binary files a/docs/RISCV-FAT/Paper/paper.pdf and b/docs/RISCV-FAT/Paper/paper.pdf differ
diff --git a/docs/RISCV-FAT/Paper/paper.tex b/docs/RISCV-FAT/Paper/paper.tex
index c86b6f6..25ed71a 100644
--- a/docs/RISCV-FAT/Paper/paper.tex
+++ b/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}
-\caption{\label{fig:orgf01f491}FAT pointer implementation with RISCV CHERI Toooba to strip the requirement of requiring a TLB.}
+\includegraphics[angle=270,width=.9\linewidth]{./diagram/ProposedArchitecture.drawio.png}
+\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
-within the FAT-pointer. This area of unused bits presents an opportunity to store additional metadata,
-potentially enhancing the capabilities of the memory management system.
+In Figure \ref{fig:org84f2a68}, proposes a hybrid system that operates alongside the MMU and enables the
+conversion of virtual addresses to physical addresses without requiring a TLB lookup or a Page Table Entry
+(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}
-The figure \ref{fig:org8363643} above illustrates the Toooba processor, showcasing all available pipelines to provide a broad overview of the architecture.
+\label{sec:orgb1f02ff}
+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