Subversion Repositories ion

\chapter{Hardware Demo}

\label{hw_demo}

\section{Pre-generated demo}

\label{pregenerated_demo}

    The project includes a few synthesizable code samples, including a

    'Hello world' demo and a memory tester. Only the 'hello' demo is included

    in pre-generated form, the others have to be built using the included

    makefiles -- assuming you have a mips toolchain.\\

    'Pre-generated' in this context means that all the vhdl files necessary for

    building the demo are already included with the project, including the

    configuration package that contains the program's object code, and the only

    tool needed is the synthesis tool.

    The pregenerated demo is included just for convenience, so that you can

    launch some small application on hardware without installing a C toolchain.\\

    A constraints file is provided ('/vhdl/demo/c2sb\_demo.csv') which includes

    all the pin constraints for the default target board, in CSV format. This

    constraints file is shared by all demos targeted to the DE-1 board.\\

    The default target board is TerasIC's DE-1, with a Cyclone-II FPGA

    (EP2C20F484C7). This is the only hardware platform the core has been

    tested in, so far.\\

    I have used the free Altera IDE (Altera Quartus II 9.0). This version of

    Quartus does not even require a free license file and can be downloaded for

    free from the altera web site. But if you have a DE-1 board on hand I guess

    you already know that.\\

    I assume you are familiar with Altera tools but anyway this is how to set up

    a project using Quartus II:

    \begin{enumerate}

        \item Create new project with the new project wizard.

            Top entity should be c2sb\_demo.

            Suggested path is /syn/altera/(project name).

        \item Set target device as EP2C20F484C7.

            This choice tells the synth tool what speed grade and chip package

            we'll be targetting.

        \item 'Next' your way out of the new project wizard.

        \item Add to the project all the vhdl files in /vhdl and /vhdl/demo,

              except mips\_cache\_stub.vhdl and sdram\_controller.vhdl.

        \item Add to the project all the vhdl files in /vhdl/SoC.

        \item Select file c2sb\_demo.vhdl as top.

        \item Import pin constraints file (assignments-\textgreater import assignments).

        \item Create a clock constraint for signal clk (51 MHz or some other

            suitable speed which gives us some minimal slack).

        \item In the device settings window, click "Device and pin options...".

        \item Select tab "Dual-Purpose pins".

        \item Double-click on nCEO value column and select "use as regular I/O".

            IMPORTANT: otherwise the synthesis will fail; we need to use a FPGA

            pin that happens to be dual-purpose (programming and regular).

        \item Select 'speed' optimization.

        \item Save the project and synthesize.

        \item Make sure the clock constraint is met (timing analyzer report).

            There is a random element to the synthesis process, as you know,

            but the core as shipped should pass the constraint.

        \item Program the FPGA from Quartus-2

        \item If you have a terminal hooked to the serial port (19200/8/N/1) you

            should see a welcome message after depressing the reset button.

            (by default this is pushbutton 2).

    \end{enumerate}

    In the present version, the synthesis will produce a lot of warnings. The

    ugliest are about unused pins and an undeclared clock line. None of them

    should be really scary.\\

    Note that none of the on-board goodies are used in the demo except as noted

    in section ~\ref{porting_hw_demo} below.\\

    In order to generate the demos (not using the pre-generated file) you

    have to use the makefiles provided with the code samples. Please see

    the sample readme files and the makefiles for details. In short, provided

    you have a MIPS toolchain installed and Python 2.5+, all you have to do

    is run make (which will automatically build all the vhdl files where they

    need to be, etc.) and run the synthesis.\\

\section{Porting to other dev boards}

\label{porting_hw_demo}

    I will only deal here with the 'hello' demo, the process is the same

    for all other samples that don't involve external FLASH.\\

    The 'hello' demo should be easily portable to any board which has all of

    this:

    \begin{itemize}

    \item An FPGA capable enough (the demo uses internal memory for code).

    \item At least 4KB of 16-bit wide external, asynchronous, old-fashioned SRAM.

    \item A reset pin (possibly a pushbutton).

    \item A clock input (uart modules assume 50MHz, see below).

    \item RXD and TXD UART pins, plus a connector, header or whatever.

    \end{itemize}

    The only module that care at all about clock rate is the UART embedded into

    the SoC module. It's hardwired to 19200 bauds when clocked at 50MHz, so if you

    use a different frequency you must edit the generics in the demo entity

    accordingly -- the demo generics are passed all the way down to whatever

    module needs them.\\

    The UART has hardly been tested at clock rates other than 50MHz and has not

    passed any independent test bench; try the core first at 50 MHz.\\

    Though there is no reset control logic, the reset input is synchronized

    internally, so you can use a raw pushbutton -- you may trigger multiple

    resets if your pushbutton isn't tight but you'll never cause metastability

    trouble.\\

    Assuming you take care of all of the above, the easiest way I see to port

    the demo is just editing the top module ports ('/vhdl/demo/c2sb\_demo.vhdl')

    to match your board setup. The only tricky part is the interface to FLASH

    and SDRAM.\\

    All the code in this project is vendor agnostic (or should be, I have only

    tried it on Quartus and ISE). Specifically, it does not instantiate memory

    blocks (relying instead on memory inference) or clock managers or buffers.

    This has its drawbacks but is an stated goal of the project -- in the long

    run it pays, I think, and it certainly makes the porting easier.\\

\section{'Adventure' demo}

\label{adventure}

    There is another demo targeting the same hardware as the 'hello' demo above:

    a port of 'Adventure'. The C source (included) has been slightly modified

    to not use any library functions nor any filesystem (instead uses a built-in

    constant string table).\\

    Build steps are the same as for the hello demo (the make target is 'demo').\\

    Since the binary executable is too large to fit internal BRAM, it has to be

    executed from the DE-1 onboard flash. You need to write file 'adventure.bin'

    to the start of the FLASH using the 'Control Panel' tool that came with your

    DE-1 board. That's the only salient difference. That and the amount of SRAM;

    The 512KB present on the DE-1 are enough but I don't remember right now

    what is the minimum, please look at the map file. This should only matter

    if you want to port to another board.\\

    The game will offer you an auto-walkthrough option. Answer 'y' and it will

    play itself for about 250 moves, leaving you at an intermediate stage of

    the game from which you can play on.\\

    Now, admittedly 'Adventure' is no standard benchmark and even running it to

    completion does not guarantee that there are no bugs hidden in the cache or

    any of the opcodes.

    On the other hand, when you get to the \emph{maze of twisty little passages}

    you know you have a computer, finished or not. The 'Adventure' demo is

    great as a confidence builder.\\

    Besides, running Adventure on a computer built by myself is something

    I've always wanted to do :)\\