Browse files

refactored Section 3

added PDF
  • Loading branch information...
1 parent fa5e6f0 commit 5662cd1bceed55e3508cf41906dcdc4d0d59fa81 Shinpei Kato committed Sep 19, 2012
Showing with 93 additions and 76 deletions.
  1. +93 −76 Sec3_Design.tex
  2. BIN farm.pdf
@@ -7,19 +7,16 @@ \section{Compiler and Debugging Environment}\label{sec:design}
\caption{Specification of GF100 microcontroller.}
\hbox to\hsize{\hfil
-Name & HUB & GPC\\\hline
-Architecture & Fermi & Fermi \\\hline
+Name & HUB & GPC\\\hline
Number of units & 1 & 4\\\hline
-Bit & 32bit & 32bit\\\hline
-Code size & 16,384 byte & 8,192 byte\\\hline
-Data size & 4,096 byte & 2,048 byte\\\hline
-% \multicolumn{4}{l}{type-1\,: enumerate$BEy(B\quad type-2\,: enumerate*$BEy(B}\\
-% \multicolumn{4}{l}{type-3\,: Enumerate$BEy(B\quad type-4\,: ENUMERATE$BEy(B}\\
+Bit & 32bit & 32bit\\\hline
+Code size & 16,384 byte & 8,192 byte\\\hline
+Data size & 4,096 byte & 2,048 byte\\\hline
@@ -43,7 +40,7 @@ \subsection{Microcontroller}
\subsection{Compiler Implementation}
@@ -62,22 +59,14 @@ \subsection{Compiler Implementation}
be tested by our debugging tool described in the later section.
To summarize, our compiler takes the following stages:
\caption{Code generation stages of LLC.}
- \begin{center}
- \includegraphics[width=12cm]{./img/llvm_code.pdf}
- \end{center}
- \caption{Examples of C source code and output code.}
- \label{fig:llvm_code}
\item[ (1) Clang]\mbox{}\\
This is a frontend of C language that generates LLVM IR code
@@ -97,7 +86,7 @@ \subsection{Compiler Implementation}
Our implementation adds a new configuration called nvuc
(NVIDIA Micro-Controller) to support NVIDIA's GPU
- microcontrollers under the LLVM infrastructure.
+ microcontrollers under LLVM.
\item[ (3) LLVM to envyas]\mbox{}\\
This stage divides the generated assembly code into code and
@@ -106,78 +95,106 @@ \subsection{Compiler Implementation}
the Envytools suite.
The bootstrap code is also unified into the binary images
in this stage.
\item[ (4) envyas]\mbox{}\\
This is a final assembly stage for the microcontroller, which
generates the byte code of the firmware.
-\item[ (5) hex to bin]\mbox{}\\
-``hex to bin'' converts to the data portion split Step (3) to an executable file.
-\item[ (6) Running the firmware]\mbox{}\\
-There are two ways to run the firmware: incorporating the firmware into the device driver, or using the debugging support tool.
-The device driver and the debugging support tool load the binary file of the firmware at boot time.
+\item[ (5) hex to bin]\mbox{}\\
+ This stage translates the hexadecimal byte code to the binary
+ format so that the firmware can execute on the
+ microcontroller.
+\item[ (6) Running the microcontroller]\mbox{}\\
+ The compiled firmware is loaded on the microcontroller by the
+ device driver.
+ We also support a debugging tool that launches the firmware
+ in the same way as the device driver for development
+ purposes.
-Figure \ref{fig:llvm_code} shows example of C language source codes, LLVM IR code, and assembly code.
-Left is C language source codes, center is LLVM IR code that is generated by \ref{section:flow}(1), right is assembly code that is generated by \ref{section:flow}(3).
+\subsection{Debugging Support}
-\caption{Flowchart of Debugging Support Tool}
+ \begin{center}
+ \includegraphics[width=3cm]{./img/loader.pdf}
+ \end{center}
+ \caption{Flowchart of our debugging tool.}
+ \label{fig:loader}
-\caption{Flowchart of Our Firmware }
-\subsection{Debugging support tool}
-Debugging support tool is to load the firmware, to send commands and data, and to display a register value of GPU.
-Figure \ref{fig:loader} shows the flow of this tool flow, we describe use it.
-Microcontrollers memory space map to CPU memory space in MMIO (Memory Mapped IO).
+We support a debugging tool to load the firmware, send commands and
+data, monitor the status, and display register and memory values of the
+Figure~\ref{fig:loader} shows control flow of our debugging tool.
+The following are the details of each block in the flow:
-\item[ (1) Load the firmware]\mbox{}\\
-Debugging support tool load the HUB firmware and GPC firmware executable code to mapping address by MMIO.
-After the load completion, this firmware runs by set a flag in the specified register.
-\item[ (2) Sends commands and data]\mbox{}\\
-A processing on microcontroller is suspended until receives a command.
-The debugging support tool sends the command.
-After an interrupt is executed by the command, the processing is resumed,
-\item[ (3) Display a register] \mbox{}\\
-The microcontroller has the register may be used freely on the host side.
-The register is used for execute completion flag by the traditional firmware.
-Thus we assumed that the register is used for the same purpose during debugging time,
-the register value is displayed.
+ \item[(1) Load Firmware]\mbox{}\\
+ Our debugging tool uploads a set of firmware programs on to
+ the HUB and the GPC microcontrollers.
+ The uploaded firmware programs start execution when a flag is
+ set in the specified register.
+ \item[(2) Send Command and Data]\mbox{}\\
+ The microcontroller is event-driven.
+ It is totally suspended in an idle state.
+ When it receives a command from the debugging tool through
+ the PCI bus, the interrupt handler is invoked and its
+ execution is resumed.
+\item[(3) Display Register Value] \mbox{}\\
+ The microcontroller has a set of registers that may be used
+ by the debugging tool for any purpose.
+ There are also several important registers relevant to
+ firmware execution.
+ The debugging tool hence displays the values of these
+ registers to notify what is happening.
+\subsection{Firmware Development}
+In this paper, we present the most basic firmware program for NVIDIA's
+GPU microcontrollers.
+We develop this firmware entirely using our compiler and debugging
+This is indeed the initial step toward fine-grained GPU resource
+management using microcontrollers, and enhanced functions could build
+upon this work.
+ \begin{center}
+ \includegraphics[width=12cm]{./img/firmware.pdf}
+ \end{center}
+ \caption{Flowchart of our basic firmware.}
+ \label{fig:firmware}
-\subsection{Firmware development}
-In this section, we describe the our developing firmware on HUB.
-Figure \ref{fig:firmware} shows that firmware flow chart.
-The Firmware is started by setting the value in the register.
+Figure \ref{fig:firmware} shows control flow of the basic firmware
+developed in this paper.
+The following are the details of each block in the flow.
-\item[ (1) initialize]\mbox{}\\
-The firmware sets the interrupt handler and get the data when started.
-Next then Step(2).
-\item[ (2) sleep]\mbox{}\\
-The firmware makes the shift to the standby state, which wait for the receive command by the device driver or the debug support tools.
-The firmware interrupt occurs when the firmware received command, which started ``ihbody''.
-\item[ (3) ihbody] \mbox{}\\
-``ihbody'' enqueued command, and then it releases wait state of firmware.
-\item[ (4) work] \mbox{}\\
-``work'' function is called when the wait state of firmware is released.
-``work'' calls the function after the dequeue.
-It will check the end flag of firmware after the function execution.
+ \item[(1) initialize]\mbox{}\\
+ The firmware configures the interrupt handler, and receives
+ the default set of data when started.
+ \item[(2) sleep]\mbox{}\\
+ The firmware enters the standby mode in the main event loop,
+ waiting for the next command issued by the device driver or
+ the debugging tool.
+ Upon every arrival of the command, an interrupt is generated
+ on the microcontroller, awakening the firmware in the
+ ``ihbody'' function.
+ \item[(3) ihbody] \mbox{}\\
+ This is an interrupt handler invoked by the command.
+ All we have to do here is to enqueue the corresponding
+ command, and releases the standby mode to resume firmware
+ execution.
+ \item[(4) work] \mbox{}\\
+ This is a main body of the firmware.
+ It is called when the firmware is released from the standby
+ mode.
+ The basic procedure of this function is to dequeue a pending
+ command one by one, and call the function corresponding to
+ the command.
+ If the specified flag is cleared, we destroy the firmware.
-We can recognize from what has been said that the firmware controlled by execute the function is better suited command.
Binary file not shown.

0 comments on commit 5662cd1

Please sign in to comment.