Subversion Repositories ion

 
\chapter{SoC Module}
\label{soc_module}
 
The main purpose of the SoC module is to encapsulate the somewhat complex 
interconnection between the CPU and the Cache/Memory Controller module.
 
If some project demands that some piece of hardware be directly connected to the
CPU, bypassing the cache, this is where it should be -- an MMU comes to mind.
 
Any peripherals deemed common enough that they will be present in all projects
might be placed in the SoC module too.
 
In the current version of the SoC module, there is only one peripheral included 
in it -- a hardwired UART module. There is no penalty for placing peripherals 
ouside the SoC module, so there is no incentive to place them inside. This is 
an implementation option of yours.\\
 
Bear in mind that, in its current state, the SoC module is little more than a 
vehicle for building demos around the ION CPU. It is not meant as a real-world
SoC, though it might be deloped into one eventually.
 
\section{SoC Generics}
\label{soc_generics}
 
    The SoC needs to be configured upon instantiation by setting the following
    generics:
 
\begin{table}[h]
\caption{SoC module generics\label{tab_soc_generics}}
\begin{tabularx}{\textwidth}{ lll|X }
\toprule
Name & Type & Default value & Description \\
\midrule
\texttt{BOOT\_BRAM\_SIZE}      & integer    & 1024  & Bootstrap BRAM size in 32-bit words. \\
\texttt{OBJ\_CODE}     & t\_obj\_code & (void code) & Bootstrap BRAM contents. \\
\midrule
\texttt{CLOCK\_FREQ}   & integer    & 50e6  & Main clock rate. \\
\texttt{BAUD\_RATE}    & integer    & 19200  & UART baud rate. \\
\midrule
\texttt{SRAM\_ADDR\_SIZE} & integer & 17 & Size of SRAM address bus. \\
\bottomrule
\end{tabularx}
\end{table}   
 
The current version of the SoC is not very strict in the enforcement of limits 
for the generics. You are advised to use only 'reasonable' values. This will 
be fixed, eventually.
 
Generic \texttt{CLOCK\_FREQ} is only needed in order to compute the default 
baud period for the internal UART (from the value of generic \texttt{BAUD\_RATE}).
 
 
Generic \texttt{BOOT\_BRAM\_SIZE} will determine the size of the internal 
bootstrap BRAM. This generic \emph{can't be zero}; in the current version of
the SoC, the BRAM can't be disabled or omitted.
 
Note that if the size of the bootstrap BRAM is not enough to hold the whole 
bootstrap code provided in generic \texttt{OBJ\_CODE}, the code \emph{will 
be sineltly truncated!}. Usually this will result in an early crash.
 
Generic \texttt{OBJ\_CODE} is used at synthesis time to initialize the bootstrap
BRAM. This generic is meant to contain boostrap code, as seen in section 
~\ref{bootstrap_code}). It can be omitted, in which case the bootstrap BRAM
will be initialized to all zeros.
 
 
\section{SoC Ports}
\label{soc_ports}
 
\begin{figure}[h]
\makebox[\textwidth]{\framebox[9cm]{\rule{0pt}{9cm}
\includegraphics[width=8cm]{img/soc_symbol.png}}}
\caption{SoC module interface\label{soc_symbol}}
\end{figure}
 
\begin{table}[h]
\caption{SoC module interface ports}
\begin{tabularx}{\textwidth}{ lll|X }
\toprule
Name & Type & Width & Description \\
\midrule
clk                 & in    & 1  & Clock input, active rising edge. \\
reset               & in    & 1  & Synchronous global reset. \\
\midrule
sram\_address       & out   & 16 & Memory word address (bit 0 absent). \\
sram\_data\_wr      & out   & 16 & Memory write data. Only valid when one of the \\
                    &       &    & memory byte write enable outputs is active.\\
sram\_data\_rd      & in    & 16 & Memory read data. Latched when xxx. \\
sram\_byte\_we\_n   & out   & 2  & Memory byte write enable, active low.  \\
                    &       &    & (0) enables the low byte (7 downto 0) \\
                    &       &    & (1) enables the high byte (15 downto 8). \\
\midrule
io\_rd\_addr        & out   & 30 & I/O port read address (bits 1..0 absent). \\
                    &       &    & Only valid when io\_rd\_vma is high. \\
io\_wr\_addr        & out   & 30 & I/O port write address (bits 1..0 absent). \\
io\_wr\_data        & out   & 32 & I/O write data.  Only valid when one of the \\
                    &       &    & i/o byte write enable outputs is active.\\
io\_rd\_data        & in    & 32 & I/O read data. Latched when xxx. \\
io\_byte\_we        & out   & 4  & I/O byte write enable, active high. \\
                    &       &    & (0) enables the low byte (7 downto 0) \\
                    &       &    & (3) enables the high byte (31 downto 24). \\
io\_rd\_vma         & out   & 1  & Active high on i/o read cycles. \\
\midrule
uart\_rxd           & in    & 1  & RxD input to internal UART. \\
uart\_txd           & out   & 1  & TxD output from internal UART. \\
\midrule
interrupt           & in    & 8  & Interrupt request inputs, active high. \\
\bottomrule
\end{tabularx}
\end{table}
 
As you can see in figure~\ref{soc_symbol} (symbol generated by Xilinx ISE), 
the SoC has the following interfaces:
 
\begin{enumerate}
    \item Interface to external static asynchronous memory (SRAM, FLASH...).
    \item Interface to on-chip peripherals.
    \item Interrupt inputs.
    \item Debug port.
\end{enumerate}
 
These interfaces will be explained in the following subsections. The top module
for the demo supplied with the project (c2sb\_demo.vhdl) will be used for 
illustration.
 
\emph{NOTE}: This section needs a lot of elaboration -- ideally this should be 
equivalent to a datasheet in thoroughness and detail. This work, like many 
other parts of this project, will have to wait.
 
\subsection{SoC interface to static memory}
\label{soc_if_sram}
 
The interface to external memory in the SoC module is essentially that of the 
internal cache/memory controller. Its timing is described in section 
~\ref{cache_state_machine}.\\
 
The SoC inputs are meant to be connected straight to the FPGA i/o pins. The only
trick is the bidirectional memory data bus: as you can see, the SoC data buses 
are unidirectional and thus you will need to provide an interconnection
external to this module. This interconnection shall include the requisite 
3-state buffers:
 
\begin{verbatim}
sram_databus <= sram_data_wr when sram_byte_we_n/="11" else (others => 'Z');
\end{verbatim}
 
The top level \emph{c2sb\_demo} module can be used as a fully tested example of 
how to use this interface to connect to a common 16-bit-wide SRAM chip 
(ISSI IS61LV25616).
 
In reviewing the top module source, note that I had to adapt the dual 
byte-write-enable outputs to the SRAM
configuration of a single write-enable plus dual byte-enable inputs.
 
Note too that the static memory bus of the SoC module is used to access both the 16-bit wide SRAM 
and an 8-bit wide FLASH. These chips are connected to separate buses on the 
target board, so the top c2sb\_demo module needs to conflate both buses before connecting 
them to the SoC. This is why a multiplexor is used in the \texttt{mpu\_sram\_data\_rd}
bus. A real-world board would probably have the SRAM and the FLASH connected 
to the same bus, simplifying the interface logic.
 
 
\subsection{SoC interface to peripherals}
\label{soc_if_io}
 
    Every CPU access to an area designated as I/O (see ~\ref{soc_memory_map}, memory map)
    will trigger a read/write cycle on this interface.
 
    I/O ports are synchronous, byte accesible registers meant to be implemented
    within the FPGA. I/O ports do not support wait states.
 
    The I/O interface has separate input and output buses. 
 
    In an output cycle, one or more lines of signal \texttt{io\_byte\_we} will be
    asserted for one clock cycle. Signals \texttt{io\_wr\_addr} and \texttt{io\_wr\_addr} will
    be valid as long as \texttt{io\_byte\_we} is asserted.
 
    In an input cycle, \texttt{io\_rd\_vma} will be asserted for one cycle and the input
    data should be present at \texttt{io\_rd\_data} at the end of the following clock 
    cycle. The full read operation extends over two clock cycles.
 
\subsection{SoC interrupt inputs}
\label{soc_irqs}
 
    The present version of the CPU does not have support for hardware interrupts 
    and therefore these signals are not used yet and are unconnected. 
    Hardware interrupts will be implemented in some future version as 
    time permits.
 
\subsection{SoC debug port}
\label{soc_debug_port}
 
    The debug port is a VHDL record (\texttt{t\_debug\_info}, defined in 
    package \emph{mips\_pkg}), which holds some internal CPU status flags that 
    can be useful while debugging the core. It is not meant to be useful for 
    a real application.
 
    Currently the record holds only two flags:
 
    \begin{itemize}
    \item \texttt{cache\_enabled}, asserted when the cache is enabled.
    \item \texttt{unmapped\_access}, asserted when some access to an unmapped 
    address is made.
    \end{itemize}
 
    The current version of the demo connects these signals to some on-board 
    LEDs. 
 
 
\section{SoC Memory Map}
\label{soc_memory_map}    
 
    The \emph{memory map} determines the type of memory that is connected to 
    each of a number of predefined address rangess (see section 
    ~\ref{memory_map_definition}).
    It is defined in package \emph{mips\_pkg} and it is implemented in the 
    \emph{mips\_cache} module.
 
\begin{table}[h]
\caption{SoC module memory map\label{tab_soc_memory_map}}
\begin{tabularx}{\textwidth}{ lll|X }
\toprule
Address range & Type & Wait States & Intended usage \\
\midrule
\texttt{0xb8000000-0xbfffffff}   & BRAM    & 0  & SoC internal boot BRAM. \\
\midrule
\texttt{0x00000000-0x07ffffff}   & SRAM-16 & 2  & Off-chip SRAM. \\
\texttt{0x80000000-0x87ffffff}   & SRAM-16 & 2  & Off-chip SRAM. \\
\texttt{0x20000000-0x27ffffff}   & I/O     & 0  & On-chip I/O registers. \\
\texttt{0xb0000000-0xb7ffffff}   & SRAM-8  & 7  & Off-chip SRAM or FLASH. \\
\bottomrule
\end{tabularx}
\end{table}   
 
 
\section{SoC UART}
\label{soc_uart}    
 
    The current revision of the SoC includes a single peripheral, a hardwired 
    8-bit UART (file \emph{uart.vhdl}).
 
    This UART is an 8-bit module built for some other unrelated project of mine
    and commandeered to serve on this SoC. Therefore, it has some features
    (like its 8-bit interface) which are sub-optimal for this application and/or
    are not used.
 
    The UART is 'hardwired' because some of its operational parameters are 
    hardcoded and can't be changed even at synthesis time. Namely:
 
    \begin{itemize}
    \item Stop bits: 1.
    \item Parity: None.
    \item Bits per character: 8.
    \end{itemize}
 
    All other parameters can at least be configured at synthesis time, and 
    under some conditions can be configured at run time too. The interested 
    user must read the module source for a better explaination of these 
    features. This document will only deal with the UART module as it is 
    instantiated in the SoC.
 
 
    These are the UART control registers:
 
    \begin{table}[h]
    \caption{UART control registers\label{uart_control_regs}}
    \begin{tabularx}{\textwidth}{ ll|X }
    \toprule
    Byte Address & Word Address & Register \\
    \midrule
    \texttt{0x20000003}   & \texttt{0x20000000} & Tx/Rx Buffer \\
    \texttt{0x20000007}   & \texttt{0x20000004} & Status. \\
    \texttt{0x2000000b}   & \texttt{0x20000008} & Baud rate period, low byte. \\
    \texttt{0x2000000f}   & \texttt{0x2000000c} & Baud rate period, high byte. \\
    \bottomrule
    \end{tabularx}
    \end{table} 
 
 
    All of these registers are mapped to the byte address given in the table,
    that is, they are mapped on the \emph{low} byte of the 32-bit word they 
    belong to -- you don't have to worry about this unless you use a word 
    pointer to access these registers.
 
 
\subsection{UART Usage}
\label{soc_uart_usage}    
 
    Until hardware interrupts are implemented, you have to rely on polling to 
    use the UART.
 
    When you want to transmit, you wait until flag TxRdy is '1' and then write
    to the Tx Buffer. That will clear TxRdy until the transmission is done. 
    Writing to the Tx Buffer will NOT clear flag TxIrq. 
 
    Writing to the Tx Buffer while TxRdy is '0' will have no effect.
 
    When you want to read received data, you wait until RxRdy is '1' and then 
    read the Rx Buffer. Reading the Rx Buffer will clear flag RxRdy until a new 
    byte arrives.
    Reading the RxBuffer while RxRdy is '0' will return undefined data.
    Reading the Rx Buffer will NOT clear flag RxIrq.
 
    Of course, once hardware interrupts are implemented, you will use them 
    instead of polling, but this is the basic mechanics. Same as any old UART, 
    really.
 
 
 
\subsection{UART Status Register}
\label{soc_status_reg}    
 
    These are the flags present in the status register:
 
 
\needspace{7\baselineskip}    
\begin{verbatim}
  UART Status Register
 
      7       6       5       4       3       2       1       0
  +-------+-------+-------+-------+-------+-------+-------+-------+
  |   0   |   0   | RxIrq | TxIrq |   0   |   0   | RxRdy | TxRdy |
  +-------+-------+-------+-------+-------+-------+-------+-------+
      h       h      W1C     W1C      h       h       r       r     
\end{verbatim}
 
 
    Bits marked 'h' are hardwired and can't be modified. 
 
    Bits marked 'r' are read only; they are set and clear by the UART core.
 
    Bits marked W1C ('Write 1 Clear') are set by the UART core when an interrupt 
    has been triggered and must be cleared by the software by writing a '1'.
 
    \begin{itemize}
    \item Status bit TxRdy is high when there isn't any transmission in progress. 
            It is cleared when data is written to the transmission buffer and is 
            raised at the same time the transmission interrupt is triggered.
    \item Status bit RxRdy is raised at the same time the receive interrupt is
            triggered and is cleared when the data register is read.
    \item Status bit TxIrq is raised when the transmission interrupt is triggered 
            and is cleared when a 1 is written to it.
    \item Status bit RxIrq is raised when the reception interrupt is triggered 
            and is cleared when a 1 is written to it.
    \end{itemize}
 
    When writing to the status/control registers, only flags TxIrq and RxIrq are
    affected, and only when writing a '1' as explained above. All other flags 
    are read-only.
 
 
\subsection{UART Baud Rate Registers}
\label{soc_uart_baud_regs}    
 
    When the UART module generic 'HARDWIRED' is set to 'false', these registers
    can be written to in order to configure the baud rate -- see the source for 
    details.
 
    When the UART module generic 'HARDWIRED' is set to 'true', these registers
    are frozen and can't be modified. This is how the module is instantiated in 
    the current version of the SoC.
 
    In either case, these are write-only registers: reading them will return 
    the contents of the status register (simplified multiplexor).
 
    The baud rate is configured by loading these registers with the baud period
    in clock cycles.
 
 
\subsection{UART Interrupt}
\label{soc_uart_interrupts}    
 
    The UART can trigger an interrupt (i.e. assert its interrupt output for one 
    clock cycle) whenever a character is received or transmitted. The UART
    source explains in detail exactly when these interrupts are triggered.
 
    The interrupt status is kept in two flags on the status register that can 
    be used for interrupt polling. Note there's no way to tell what kind of
    interrupt we got other than looking at those flags.
 
    Since the current CPU revision does not support hardware interrupts, this
    feature is still unused and the interrupt line is unconnected.
    Again, details can be found in the UART module source.