Subversion Repositories ion

\chapter{Design Notes}
\label{notes}
 
\section{Project Goals}
\label{goals}
 
    The first iteration of the project will be deemed finished when it can do
    the following:
 
\begin{enumerate}
    \item Run a minimal set of MIPS-I opcodes.\\
        Excluding unaligned load/store (formerly patented).\\
        Excluding all CPA instructions.\\
        Excluding all CP0 instructions related to TLB.\\
        Cache instructions will not be implemented as defined.
    \item Catch all undefined opcodes (and trigger exception).
    \item Operate in kernel/user mode as per the architecture definition.
    \item Handle exceptions in a manner compatible to MIPS-I standard.
    \item Code cache and data cache, even if not standard.\\
        No MMU and no TLB, and no cache-related instructions.
    \item Implement as much of CP0 as necessary for the above goals.
    \item Interface to external SRAM (or FLASH) on 8- and 16-bit data bus.
    \item Be no bigger than Plasma in a Spartan-3 or Cyclone-2 device, and
        no slower -- Plasma is used as a reference in many ways.\\
        Speed measured in raw clock frequency for the time being.
        (I.e. don't not consider stalls, interlocks, etc. yet)
    \item Interlock behavior of MUL/DIV and L* compatible to toolchain.\\
        That is, interlock loads instead of relying on a delay slot.
\end{enumerate}
 
 
    Unaligned load/stores are excluded not because of patent concerns (the
    patents already expired) but because they're not essential for a first
    version of the core. The same goes for all other exclusions.
 
    As of rev. 154 all the 1st block goals have been accomplished (but not very
    heavily tested; many bugs remain, probably).\\
 
    For a second iteration I plan on the following:
\begin{enumerate}
    \item Proper interlocking of load cycles (with no wasted cycles).
    \item External interrupt support.
    \item Trap handlers (instruction emulation) for unaligned load and store 
        instructions.
    \item Trap handlers (instruction emulation) for the most usual MIPS32 
        instructions.
    \item Some much needed optimization of the caches.
\end{enumerate}
    None of these things have been done.\\
 
 
    Note that 32-bit memory interfaces are not to be implemented any time soon, 
    mainly because I don't have any actual hardware with which to test it.
 
 
\section{Development status}
\label{status}
 
    The CPU is already able to execute almost any MIPS-I code (excluding some
    unimplemented instructions such as cache control).\\
    It can pass a basic opcode test and can execute some basic applications 
    compiled with standard gcc tools (specifically, it can run an 'Adventure' 
    demo and a tiny 'hello world' program, see section 6).\\
 
    Hardware interrupt support is entirely missing.
 
    The most important limitations are the very basic memory interface, with
    no support for SDRAM, and the absence of MIPS32 trap handlers -- which 
    means that the ubiquitous MIPS32 toolchains can't be easily used with 
    this core.
 
    The memory controller can already access external static memory (SRAM or 
    FLASH) on 8-bit and/or 16 bit buses. Still does not support SDRAM, nor 
    static RAM in other bus widths.
    My main development target is a DE-1 board from Terasic (Cyclone-2) and I 
    have focused in the kind of memory it has.
 
    Wait states can be configured at synthesis, see section 
    ~\ref{memory_map_definition}.
    Code sample 'memtest' takes advantage of this to do a basic test of the
    external SRAM, and code sample 'Adventure' uses both Flash and SRAM.
    All the code samples habe been tested with the cache enabled and disabled, 
    and they ship with the cache enabled (i.e. with C startup code that 
    initializes and enables the cache).
 
 
    The code samples can be found in the /src directory (see section 
    ~\ref{samples}).
 
 
    This is a summary of the state of the CPU at this time:
\begin{itemize}
    \item MIPS-I things not implemented
    \begin{enumerate}
        \item External hardware interrupts.
    \end{enumerate}
 
    \item Things implemented but not fully tested.
    \begin{enumerate}
        \item Rte instruction.
        \item Kernel/user modes.
    \end{enumerate}
 
    \item Things with provisional implementation
    \begin{enumerate}
        \item Load interlocks: the pipeline is stalled for every load instruction,
            even if the target register is not used in the following
            instruction. So that every load takes two cycles.\\
            The interlock logic should check register indices and stall only if
            there is a data hazard.\\
            Note that all that's needed is a better identification of stall
            conditions; the logic to enable a load instruction that does not
            stall to overlap the next instruction is already in place.\\
            The interlock logic needs a stronger test bench anyway.
        \item Documentation is too sparse and source code is barely commented.\\
        \item The D-Cache handles RAW hazards in a very inefficient way.\\
            Data refills in a SW+LW sequence should only be triggered when the
            SW invalidates the same line the LW is loading. Instead, the current
            cache triggers the data refill always (for a SW+LW sequence, that 
            is).\\
            This performance drag has to be fixed without ruining the clock rate
            (that's the catch).
    \end{enumerate}
\end{itemize}
 
\section{Performance}
\label{performance}
    In my main test system, a Cyclone-2 grade -7, the core
    with caches and with mul/div and all other necessary functionality, plus 
    a barebones UART, will be below 2500 LEs + 18 BRAMs, running at least at 
    50 MHz (with 'balanced optimization' on Quartus-II).\\
 
    As soon as the core is in a stable state I will include a few synthesis
    performance numbers for common configurations.\\
 
    As soon as I can build a dhrystone benchmark I will post results (and commit
    the code). The core needs a timer before I can do that.\\
 
    My first performance target will be a real R3000 at the same clock rate.
    I can anticipate that performance will be MUCH lower than that (by a factor 
    of 4 or more) due to the bus widths and the wait states, AND the inefficient
    cache implementation. I'll work on that as soon as the basic stuff is done.
 
\section{Next steps}
\label{next_steps}
    \begin{itemize}
    \item Implement efficient load interlock detection with no wasted cycles.
    \item Do whatever it takes to use standard C library functions.
    \item Alternatively, build a small C library replacement.
    \item Add a couple of benchmarks, including one with FP arithmetic.
    \item Modify the software simulator so it can boot uClinux.
    \item Make a uClinux port suitable for a R3000 derivative, from BuildRoot.
    \item Make a freeRTOS port suitable for a R3000 derivative.
    \end{itemize}
 
    Some of the above items are done, others are in progress and others
    are pipe dreams at this point.