Subversion Repositories openrisc

\input texinfo   @c -*-texinfo-*-

@c %**start of header

@setfilename orpsoc.info

@settitle ORPSoC manual 0.1

@include config.texi

@c %**end of header

@copying

This file documents the OpenRISC Reference Platform SoC, @value{ORPSOC}.

Copyright @copyright{} 2010,2011 OpenCores

@quotation

Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.2 or

any later version published by the Free Software Foundation; with no

Invariant Sections, with no Front-Cover Texts, and with no Back-Cover

Texts.  A copy of the license is included in the section entitled ``GNU

Free Documentation License''.

@end quotation

@end copying

@setchapternewpage on

@settitle @value{ORPSOC} User Guide

@syncodeindex fn cp

@syncodeindex vr cp

@titlepage

@title @value{ORPSOC} User Guide

@c @subtitle subtitle-if-any

@c @subtitle second-subtitle

@author Julius Baxter

@author OpenCores

@author Issue 2 for @value{ORPSOC}

@c  The following two commands

@c  start the copyright page.

@page

@vskip 0pt plus 1filll

@insertcopying

Published by OpenCores

@end titlepage

@c So the toc is printed at the start.

@contents

@ifnottex

@node Top

@top Scope of this Document

This document is the user guide for @value{ORPSOC}, the OpenRISC Reference Platform System on Chip project.

@end ifnottex

@menu

* Introduction::

* Project Organisation::

* Getting Started::

* Reference Design::

* Board Designs::

* ORDB1A3PE1500::

* ML501::

* S3ADSP1800::

* Generic Designs::

* Software::

* GNU Free Documentation License::  The license for this documentation

* Index::

@end menu

@node Document Introduction

@chapter Introduction

@cindex introduction to this @value{ORPSOC}

@value{ORPSOC} is intended to be a reference implementation of processors in the OpenRISC family. It provides a smallest-possible reference system, primarily for testing of the processors. It also provides systems intended to be synthesized and programmed on physical hardware.

The reference system is the least complex implementation and consists of just enough to test the processor's functionality. The board-targeted builds typically include many additional peripherals.

The next section in this document outlines the organisation and structure of the project. The section ``@emph{Getting Started}'' goes through getting the project source and setting up any necessary tools. Each following section outlines a particular implementation of an OpenRISC-based system, beginning with the reference system. Each implementation section has an overview of the structure of the project (which probably won't vary much between the implementations), a section on setting up the required tools, running simulation, and if applicable, backend and debugging steps. There may be additional sections on modifying or customising each implementation system.

@c ****************************************************************************

@c Project Organisation

@c ****************************************************************************

@node Project Organisation

@chapter Project Organisation

@cindex organisation of @value{ORPSOC} project

@menu

* Overview::

* Software::

* RTL::

* Testbenches::

* Reference And Board Designs::

@end menu

@node Organisation Overview

@section Organisation Overview

The @value{ORPSOC} project is intended to serve dual purposes. One is to act as a development platform for OpenRISC processors, and as a development platform of OpenRISC-based SoCs targeted at specific hardware.

Organising a single project to satisfy these requirements can lead to some overlap and redundancy. This section is intended to make the organisation of the project clear.

The reference implementation based in the root (base directory) of the project contains enough components to create a simple OpenRISC-based SoC. Each board build is intended to implement as fully-featured a system as possible, depending on the targeted hardware.

The project is organised in such a way that each board build can use both the reference implementation's RTL modules and software, as well as its own set of RTL and software. The reference implementation is limited to what is available in the RTL and software directories in the root of the project, and is not technology dependent.

The following sections outline the organisation of the software, RTL, and board designs.

@node Software Organisation

@section Software

The @code{sw} path contains primarily target software (code intended for cross-compilation and execution on an OpenRISC processor.) There is also a path, @code{sw/utils} containing custom tools, intended to be run on the host, for manipulation of binary software images.

Driver software, implementing access functions for hardware modules, are found under @code{sw/drivers}.

There is a minimal support library under the @code{sw/lib} path. Both drivers and support library are compiled together to create a library called @code{liborpsoc} which is placed in @code{sw/lib}.

All CPU-related functions are made available through the file @code{cpu-utils.h} which is located in @code{sw/lib/include} and depending on the CPU being used, can be used to switch between different CPU driver functions. All CPU drivers are under the @code{sw/drivers} path.

@emph{Note:} It is expected in the future that the OpenRISC toolchain based on newlib will provide all of the necessary support software provided in this CPU-specific driver path. When the first release of the newlib-based toolchain occurs it is expected the software in ORPSoC will be changed to use this toolchain instead.

Test software is found under @code{sw/tests}. Typically, each is for a specific module, or for a particular capability (eg. tests for the UART capability are under @code{sw/tests/uart}, rather than @code{sw/tests/uart16550} which.) There are no specific rules here.

Under each test directory are two directories, @code{board} and @code{sim}, containing appropriate test software. Code for simulation will produce less printfs and aim to execute within realistic timeframes for RTL simulation. Board targeted test software is obviously written with the opposite considerations in mind and be more verbose and perhaps run orders of magnitudes more tests.

@node Software Test Naming

The rules for naming software tests are important to adhere to, so the automation scripts can locate them. The test directory name must be a single word (potentially with underscores), and then the tests must be in files of the format @emph{testdirname}-@emph{testname}.extension, eg. @code{uart-simple.c} or @code{or1200-fp.S}.

@xref{Software} for further details.

@node RTL Organisation

@section RTL

The HDL code layout conforms to those outlined in the OpenCores.org coding guidelines. http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf

There are, however, some naming restrictions for this project.

The directory name (presumably the name of the module, something like @code{uart16550}) should also be the name of the top level file, eg. @code{uart16550.v}, and the top level module should also be simply this name, eg. @code{module uart16550 (...);}.

This will avoid confusion and help the scripts locate modules.

@subsection Verilog HDL

All RTL included in the project at this point is Verilog HDL, although it would be fine to add VHDL to a board build.

@node Testbench Organisation

@section Testbench

For each design in @value{ORPSOC} there will be a testbench instantiating the top level, and any required peripherals.

Despite this being far from a thorough verification platform, it is considered useful to be able to perform enough simulation to ensure that the fundamental system is correctly assembled and can communicate with the peripherals.

It is expected that by running the command @code{make rtl-test} in each board's simulation run path, a basic simulation of the system initialising should be run.

@node Organisation of Reference And Board Designs

@section Reference And Board Designs

The goal of the reference design is to provide an environment to develop and test OpenRISC processors (also, potentially, basic components.) The goal of the various board-targeted designs is to provide ready-to-go implementations for hardware.

@subsection Module Selection

Typically, a board-targeted design will wish to reuse common components (processor, debug interface, Wishbone arbiters, UART etc.)

The project has been configured so a board build will use modules in the ``common'' RTL path (@code{rtl/verilog/}) @emph{unless} there is a copy in the board's ``local'' RTL path ( @code{boards/vendor/boardname/rtl/verilog}) or the board includes an external module in @code{boards/vendor/boardname/modules}.

For example, in the event that modification to a module in the common RTL set is required for it to function correctly in a board build, it's advisable to copy that module to the board's @emph{local} RTL path and modify it there. Simulation and backend scripts should then use this board-specific version instead of the one in the common RTL path.

@c ****************************************************************************

@c Getting started

@c ****************************************************************************

@node Getting Started

@chapter Getting Started

@cindex source files for @value{ORPSOC}, downloading

@menu

* Supported Platforms::

* Obtaining Project Source::

* Required Tools::

@end menu

@node Getting Started Supported Platforms

@section Supported Host Platforms

@cindex host platforms supported by the @value{ORPSOC} project

At present the majority of  @value{ORPSOC}'s development occurs with tools that run under the GNU/Linux operating system. All of the tools required to run the basic implementation are free, open source, and easily installable in any modern GNU/Linux distribution.

Unless indicated otherwise, support for the project under Cygwin on Microsoft Windows platforms cannot be assumed.

@node Getting Started Obtaining Project Source

@section Obtaining Project Source

@cindex getting a copy of the @value{ORPSOC} project

The source for @value{ORPSOC} can be obtained from the OpenCores subversion (SVN) server.

@example

@kbd{svn export http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2}

@end example

@node Getting Started Required Tools

@section Required Tools

@cindex tools and utilities required for @value{ORPSOC}

Performing the installation of tools required to design, simulate, verify, compile and debug a SoC is not for the faint hearted. The various sets of tools must be first installed, and the user's environment configured to allow them to run correctly.

First the host system must be capable of building and running development tools, next the various compilers, simulators and utilities must be installed, and finally, if required, additional tools to interact with the built design are installed. Once complete, the set up rarely needs to be touched, and results in greatly improved productivity.

The required tools can be divided into four groups.

@itemize @bullet

@item

Host system tools - things like gcc, make, texinfo.

@item

Target system toolchain and software - the OpenRISC GNU toolchain, with gcc cross-compiler, support libraries, the GNU debugger (gdb), OpenRISC port of various OSes and RTOS, etc.

@item

Electronic design automation (EDA) tools - preprocessors, simulators, FPGA tool suites, etc.

@item

Debug tools - tools providing control over the system on target

@end itemize

The first two items are likely to be the same for most of the designs included in @value{ORPSOC}, however the final two can vary greatly depending on the FPGA vendor, part and configuration, and the application of the SoC design.

There will be a section on the tools for each design in @value{ORPSOC}. This section is intended to provide a list of tools required for each particular build. Any lengthy instructions on installing a particular tool will be attached as an appendix, which can be references by several build prerequisite lists in order to save repetition of information.

Anyone implementing their own board port is encouraged to document, as best they can, any problematic tool installations and contribute them to this document.

@c ****************************************************************************

@c Reference Design chapter

@c ****************************************************************************

@node Reference Design

@chapter Reference Design

@cindex reference design

@menu

* Overview::

* Structure::

* Tools::

* Simulation::

* Synthesis::

@end menu

@node Reference Design Overview

@section Overview

The reference design included in @value{ORPSOC} is intended to be the minimal implementation (or thereabouts) of a SoC required to exercise an OpenRISC processor. Very little apart from the processor, memory, debug interface and interconnect modules are instantiated.

The primary role for this design is to implement a system that an OpenRISC processor can be instantiated in for for development purposes. The automated testing mechanism, capable of compiling, executing and checking software on the design, is used as a method of regression testing for the processor as it is developed. After features are added or modified in the processor, new software tests can be added to the existing suite, checking for the expected functionality and ensuring legacy behavior is also unchanged.

The design can be simulated two ways. The first uses the standard event-driven simulators such as Icarus Verilog and Mentor Graphics' Modelsim. The second method involves creating a cycle accurate (C or SystemC) model from the Verilog HDL description using the Verilator tool.

The simulations begin with the desired software image preloaded in memory. For debugging the design, the models provide an interface to the system allowing the GNU debugger to control the target processor in a manner similar to that of physical hardware.

The design is not intended for implementation on an FPGA or ASIC, rather purely for development and testing in simulation environments. The board targeted builds in the @value{ORPSOC} project, however, are intended for implementation on hardware.

@node Reference Design Structure

@section Structure

@menu

* Overview::

* RTL::

* Software::

* Simulation::

@end menu

@node Reference Design Overview

@subsection Overview

The reference design's paths are all based in the root directory of @value{ORPSOC}. This is different from the board-targeted builds, which are based in their specific board paths.

As synthesis and physical implementation is not intended for the reference design there are no @code{syn} or @code{backend} paths in the root directory of @value{ORPSOC}.

@node Reference Design RTL

@subsection RTL

At present only Verilog HDL is included in the reference implementation of @value{ORPSOC}, as the open source tools intended to simulate the design do not support VHDL.

The directory structure consists of an @code{rtl} directory in the root, and a @code{verilog} path under that. Within the @code{rtl/verilog} path, each module has its own directory.

External modules using the OpenCores structure can be put under each boards @code{modules} directory. The scripts will the look for verilog files under @code{modules/<module_name>/rtl/verilog}.

A common Verilog include path, @code{rtl/verilog/include} directory is used. The Verilog HDL include files for each module should be moved here. This allows each @value{ORPSOC} implementation (board design) to maintain their own include path, and thus configure the modules for their specific implementation.

@node Reference Design Software

@subsection Software

The software run on the reference design is found in the @value{ORPSOC} root directory, under the @code{sw} path.

The test software for the or1200 processor is found under @code{sw/tests/or1200/sim}.

A minimal set of drivers is built into @code{liborpsoc}, and they are found under @code{sw/tests/drivers}.

In addition to these drivers, a set of support C functions is build into @code{liborpsoc}, which are found in the @code{sw/lib} path.

@node Reference Design Simulation

@subsection Simulation

The simulation of the reference design is run from the @code{sim/run} path.

The script controlling simulation is the file @code{sim/bin/Makefile}.

The generated output is kept in the @code{sim/out} path, and is cleared away when @kbd{make clean} is run.

When the Verilator-processed cycle accurate model is built, it is done in the @code{sim/vlt} path, which is also cleaned away when @kbd{make clean} is run.

@node Reference Design Tools

@section Tools

@menu

* Host Tools::

* Target System Tools::

* EDA Tools::

* Debug Tools::

@end menu

@node Reference Design Host Tools

@subsection Host Tools

@cindex host tools required

Standard development suite of tools: gcc, make, etc.

@node Reference Design Target System Tools

@subsection Target System Tools

@cindex target system tools required

OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.

@node Reference Design EDA Tools

@subsection EDA Tools

@cindex EDA tools required

RTL simulation: Icarus Verilog (also compatible with Mentor Graphics' Modelsim)

Cycle Accurate Simulation: Verilator, Verilog-Perl, System-Perl, SystemC

@node Reference Design Debug Tools

@subsection Debug Tools

@cindex Debug tools required

None. The target is purely simulation, no extra utilities are required to debug.

@node Reference Design Simulation

@section Simulation

@menu

* RTL::

* Cycle Accurate::

* Results::

@end menu

@node Reference Design RTL

@subsection RTL

@cindex rtl simulation of reference design

All simulations of the reference design are run from the @code{sim/run} path.

@subheading Running RTL Regression Test

The simplest way of starting a run through the regression test, using the default RTL simulator, Icarus Verilog, can be done with:

@example

@kbd{make rtl-tests}

@end example

This will compile the software and RTL, and run a new simulation for each software test. Defining which tests are run is the variable @code{TESTS}, set by default in the @code{sw/bin/Makefile} script. Other default options are that a processor execution log is generated (in @code{sim/out/@emph{testname}-executed.log}), but VCDs are not.

@subheading Running An Individual Test

An individual test can be run, by specifying the test name through the @code{TEST} environment variable (which must correspond to a file in @code{sw/tests/@emph{module}/sim/} where @code{@emph{module}} is the name of the module to be tested. In the following example the test @emph{or1200-basic} is run.

@example

@kbd{make rtl-test TEST=or1200-basic}

@end example

@node Running A Set Of Specific Reference Design RTL Tests

@subheading Running A Set Of Specific Tests

A specific set of tests can be run in the same fashion as the regression tests but with the actual tests to run set in the @code{TESTS} environment variable.

@example

@kbd{make rtl-tests TESTS="sdram-rows uart-simple or1200-mmu or1200-fp"}

@end example

@node Providing A Precompiled ELF Executable

@subheading Providing A Precompiled ELF Executable

It's possible to specify the path to an OR32 ELF executable to be run in simulation instead of test software. Use the @code{USER_ELF} environment variable to specify the path to the ELF to run.

@example

@kbd{make rtl-test USER_ELF=/path/to/myapp.elf}

@end example

The ELF will be converted to binary format, and then converted to a VMEM to be

loaded into the model for execution at runtime.

@node Providing A Custom VMEM Image

@subheading Providing A Custom VMEM Image

It's possible to specify the path to a pre-existing VMEM image to be run in simulation instead of test software. Use the @code{USER_VMEM} environment variable to specify the path to the VMEM image to be run.

@example

@kbd{make rtl-test USER_VMEM=/path/to/myapp.vmem}

@end example

This VMEM file will be copied into the working directory, and renamed according to what the simulated memory expects.

@node Options For Reference Design RTL Tests

@subheading Options For RTL Tests

There are some options, which can be specified through shell environment variables when running the test.

@table @code

@item VCD

Set to '1' to enable @emph{value change dump} (VCD) creation in @code{sim/out/@emph{testname}.vcd}

@item VCD_DELAY

Delay VCD creation start time by this number of timesteps (used as a Verilog @code{#delay} in the testbench.)

@item VCD_DELAY_INSNS

Delay VCD creation start time until this number of instructions has been executed by the processor. Useful for creating a dump just before a bug exhibited and correlated to an instruction number (from execution trace file.)

@item END_TIME

Force simulation end (@code{$finish}) at this time.

@item DISABLE_PROCESSOR_LOGS

Turn off processor monitor's execution trace generation. This helps speed up the simulation (less time writing to files) and avoids creating very large execution logs (in the GBs) for very long simulations.

@item SIMULATOR

Specify simulator to use. Default is Icarus Verilog, can be set to @code{modelsim} to use Mentor Graphics' Modelsim. No others are supported right now.

@item MGC_NO_VOPT

When using Modelsim (specifying @code{SIMULATOR=modelsim}), if the version does not include the individual @code{vopt} executable, specify @code{MGC_NO_VOPT=1} when compiling.

@item VPI

Pass @code{VPI=1} to have the an external JTAG debug module stall the processor just after bootup, and then provide a GDB stub (interacting with the Verilog sim via the VPI) to allow control of the system in a similar fashion to that of a physical target controlled over JTAG via a debug proxy application. The port for GDB is hard-coded to 50002. See the code in @code{bench/verilog/vpi/c} for more details.

If running with Modelsim, ensure the path @code{MGC_PATH} is set and points to a directory containing a path named @code{modeltech}, which should be the Modelsim install.

@end table

@node Reference Design Cycle Accurate

@subsection Cycle Accurate

@cindex cycle accurate simulation of reference design

@subheading Running Cycle Accurate Regression Test

The simplest way of starting a run through the regression test using the cycle accurate model can be done with:

@example

@kbd{make vlt-tests}

@end example

This will build the cycle accurate model and run a new simulation for each software test. Defining which tests are run is the variable @code{TESTS}, set by default in the @code{sw/bin/Makefile} script.

@subheading Running An Individual Test

An individual test can be run, by specifying the test name through the @code{TEST} environment variable (which must correspond to a file in @code{sw/tests/@emph{module}/sim/} where @code{@emph{module}} is the name of the module to be tested. In the following example the test @emph{or1200-basic} is run.

@example

@kbd{make vlt-test TEST=or1200-basic}

@end example

@subheading Generating Cycle Accurate Simulator Executable

The cycle accurate model is somewhat similar to the OpenRISC architectural simulator, in that it can be run as a standalone application, although it is not as configurable at runtime. The standalone application can be built with the following command from the @code{sim/run} path.

@example

@kbd{make prepare-vlt}

@end example

The resulting executable will be @emph{Vorpsoc_top} in the @code{sim/vlt} path. Run it with the @emph{-h} option for usage instructions.

@subheading Generating Automatically Profiled Cycle Accurate Simulator Executable

An automatic profiling and compilation set of commands in the script can be used to create a higher performance cycle accurate model. The following make target will first compile the cycle accurate design to generate profiling outputs, run some software, and recompile using the profiling information.

@example

@kbd{make prepare-vlt-profiled}

@end example

@subheading Cycle Accurate Model Executable Usage

The executable generated by running any of the above commands is in the @code{sim/vlt} path. The usage options can be listed by running it with the @code{--help} switch.

@example

@kbd{Vorpsoc_top --help}

@end example

A short list of options is given here.

@table @code

@item -f @var{file}

@itemx --program @var{file}

@cindex @code{-f}

@cindex @code{--program}

Load software from OR32 ELF image @var{file}

If unspecified, model attempts to load VMEM file @code{sram.vmem}

@item -v

@itemx --vcd

@cindex @code{-v}

@cindex @code{--vcd}

Dump VCD file

@item -e @var{value}

@itemx --endtime @var{value}

@cindex @code{-e}

@cindex @code{--endtime}

End simulation after @var{value} simulated ns

@item -l @var{file}

@itemx --log @var{file}

@cindex @code{-l}

@cindex @code{--log}

Log processor execution trace to @var{file}

@end table

@node Reference Design Results

@subsection Results

@cindex output from simulation of reference design

The following files are generated from the event driven simulation. For output options of the cycle accurate model, see the section on Cycle Accurate Model Executable Usage.

@subheading Processor Execution Trace

A trace of the processor after each executed instruction is generated by both the event and cycle accurate models.

In the event driven simulations, the log is created by default, and is stored in @code{sim/out} and will be named @code{@emph{test-name}-executed.log}.

@subheading Processor SPR Access Log

A list of processor special purpose registers (SPR) accesses is created when processor logging is enabled.

These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-sprs.log}.

@subheading Processor Instruction Excecution Time Log

A list of when each instruction was executed is generated when processor execution logging is enabled.

This is useful when debugging with VCD, and detecting at what time the problematic instructions were executed.

These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-lookup.log}.

@subheading Processor Report Mechanism Log

The use of the processor's report mechanism is commonplace in the test software, as it allows for the checking of intermediate values after simulation.

These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-general.log}. This is not optional.

@subheading Value Change Dump (VCD)

When VCD files are generated they are placed in the @code{sim/out} path, and are named @code{@emph{test-name}.vcd}. They should be viewable with programs like @emph{GTKWave}.

@node Reference Design Synthesis

@section Synthesis

The reference design is not intended to be synthesised, and thus no backend scripts are provided. See the sections on the board-specific builds.

@c ****************************************************************************

@c ORDB1A3PE1500 board build chapter

@c ****************************************************************************

@node ORDB1A3PE1500

@chapter ORDB1A3PE1500

@cindex ORDB1A3PE1500 board build information

@menu

* Overview::

* Structure::

* Tools::

* Simulating::

* Synthesis and Backend::

* Programming File Generation::

* Customising::

@end menu

@node ORDB1A3PE1500 Overview

@section Overview

The ORDB1 (ORSoC development board 1) with Actel A3PE1500 FPGA is supported by this build.

As the ORDB1 is intended to be a daughter board for a variety of I/O boards its options for configuration are extensive.

This board port of ORPSoC implements an example of a configurable system, with many cores that can be enabled or disabled as required by the expansion board's capabilities.

The port was mainly developed with the ORSoC Ethernet expansion board (OREEB1), and was used with the OpenRISC port of the Linux kernel and BusyBox suite running network applications.

This guide will overview how to simulation, synthesize and customise the system.

@node ORDB1A3PE1500 Structure

@section Structure

Note that in this chapter the term @emph{board path} refers to the path in the project for this board port; @code{boards/actel/ordb1a3pe1500}.

The board port's structure is similar to that of a standalone project which accords with the OpenCores coding guidelines. However, all software and RTL that is available in the reference design is also available to the board port, with any local (ie. in the board's @code{rtl} or @code{sw} paths) versions taking precedence over the versions available in the reference design.

The Verilog RTL specific to this board is under @code{rtl/verilog} in the board path. The @code{include} path in there is the place where all required definitions files, configuring the RTL, are found.

Backend files, things such as PLLs and buffers generated by Actel's @emph{smartgen} tool, are found in the board's @code{backend/rtl/verilog} path.

@node ORDB1A3PE1500 Tools

@section Tools

@menu

* Host Tools::

* Target System Tools::

* EDA Tools::

* Debug Tools::

@end menu

@node ORDB1A3PE1500 Host Tools

@subsection Host Tools

@cindex host tools required ORDB1A3PE1500

Standard development suite of tools: gcc, make, etc.

@node ORDB1A3PE1500 Target System Tools

@subsection Target System Tools

@cindex target system tools required ORDB1A3PE1500

OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.

@node ORDB1A3PE1500 EDA Tools

@subsection EDA Tools

@cindex EDA tools required ORDB1A3PE1500

RTL, gatelevel simulation: Mentor Graphics' Modelsim

Synthesis: Synopsys Synplify (included in Actel Libero Suite)

Backend: Actel Designer (included in Actel Libero Suite)

Programming: Actel FlashPRO (included in Actel Libero Suite)

This has been tested with with Libero versions 8.6, 9.0sp1 and 9.1 under Ubuntu Linux. It is recommended the very latest version available be used.

@node ORDB1A3PE1500 Debug Tools

@subsection Debug Tools

@cindex Debug tools required ORDB1A3PE1500

or_debug_proxy, ORPmon

@node ORDB1A3PE1500 Simulating

@section Simulating

@cindex simulating ORDB1A3PE1500

@subheading Run RTL Regression Test

To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.

@example

@kbd{make rtl-tests}

@end example

The same set of options for RTL tests available in the reference design should be available in this build. @xref{Running A Set Of Specific Reference Design RTL Tests}.

Options specific to the ORDB1A3PE1500 build.

@table @code

@item PRELOAD_RAM

Set to '1' to enable loading of the software image into RAM at the beginning of simulation.

If the chosen bootROM program (set via a define in software header file in the board's @code{sw/board/include} path) will jump straight to RAM to begin execution, then the software image will need to be in RAM for the simulation to work. This define @emph{must} be used in that case for the simulation to do anything.

@end table

@node ORDB1A3PE1500 Synthesis

@section Synthesis

Synthesis of the board port for the Actel technology with the Synplify tool can be run in the board's @code{syn/synplify/run} path with the following command.

@example

@kbd{make all}

@end example

This will create a EDIF netlist in @code{syn/synplify/out}.

Hopefully it's all automated enough so that, as long as the design is simulating as desired, the correct set of RTL will be picked up and synthesized without any need for customising scripts for the tool.

@node ORDB1A3PE1500 Synthesis Options

@subsection Options

The following can be passed as environment variables when running @kbd{make all}.

@table @code

@item RTL_TOP

Default's to the designs top level module, @emph{orpsoc_top}, but if wishing to synthesize a particular module, its name (not instantiated name) should be set here.

@item FPGA_PART

Defaults to A3PE1500 but if targeting any other set it with this.

@item FPGA_FAMILY

Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.

@item FPGA_PACKAGE

Defaults to PQFP208 but if targeting any other set it with this.

@item FPGA_SPEED_GRADE

Defaults to Std but if targeting any other set it with this.

@item FREQ

Target frequency for synthesis.

@item MAXFAN

Maximum net fanout.

@item MAXFAN_HARD

Hard limit on maximum net fanout.

@item GLOBALTHRESH

Threshold of fanout before promoting signal to a global routing net.

@item RETIMING

Defaults to '1' (on) but set to '0' to disable.

@item RESOURCE_SHARING

Defaults to '1' (on) but set to '0' to disable.

@item DISABLE_IO_INSERTION

Defaults to '0' (off) but set to '1' to enable. Useful when synthesizing individual modules not intended as a top level.

@end table

@node ORDB1A3PE1500 Synthesis Warnings

@subsection Checks

The following is a list of some considerations before synthesis.

@itemize @bullet

@item bootrom.v

If the bootROM module is being used to provide the processor with a program at startup, check that board software include file, in the board's @code{sw/board/include} path, is selecting the correct bootROM program.

Do a @kbd{make distclean} from the synthesis run directory to be sure that the previous bootROM file is cleared away and regenerated when synthesis is run.

@item Clean away old leftovers

If the unwanted files from an old synthesis run are still there before the next run, it's best to clean them away with @kbd{make clean} from the synthesis run directory.

@item Check Command Line Options

If using any command line settings, they can be checked by passing them to the following make target: @kbd{make print-config}

@end itemize

@node ORDB1A3PE1500 Place and Route

@section Place and Route

Place and route is run from the board's @code{backend/par/run} path with the following command.

@example

@kbd{make all}

@end example

This will create a @code{.adb} file in the same path.

All steps, up to and including programming file generation are done here. FPGA device programming must be done using the programming FlashPro tool under Windows if using a free license.

@node ORDB1A3PE1500 Place and route options

@subsection Options

Most of the design's parameters are determined by processing the @code{orpsoc-defines.v} file and extracting, for example, the frequency of the clocks entering the design.

The following can be passed as environment variables when running @kbd{make all}.

@table @code

@item FPGA_PART

Defaults to A3PE1500 but if targeting any other set it with this.

@item FPGA_FAMILY

Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.

@item FPGA_PACKAGE

Defaults to ``208 PQFP'' but if targeting any other set it with this.

@item FPGA_SPEED_GRADE

Defaults to Std but if targeting any other set it with this.

@item FPGA_VOLTAGE

Defaults to 1.5 but if targeting any other set it with this.

@item FPGA_TEMP_RANGE

Defaults to COM but if targeting any other set it with this.

@item FPGA_VOLT_RANGE

Defaults to COM but if targeting any other set it with this.

@item PLACE_INCREMENTAL

Defaults to off.

@item ROUTE_INCREMENTAL

Defaults to off.

@item PLACER_HIGH_EFFORT

Defaults to off.

@item BOARD_CONFIG

Defaults to @code{orsoccpuexpio.mkpinassigns}

@end table

@node ORDB1A3PE1500 Constraints

@subsection Constraints

A @emph{synposys design constraints} (SDC) file, and @emph{physical design constraints} (PDC) file are generated automatically by the scripts. The main Verilog defines file is parsed to detect which modules are included in the design, and generates the appropriate constraints which are embedded in the Makefile.

The PDC relies on the @code{BOARD_CONFIG} environment variable to indicate which pin assignment file to pull into the Makefile (they live in @code{backend/par/bin}). The PDC also depends on the actual contents of the main place and route Makefile, @code{backend/par/bin/Makefile}.

By default these should have support for the peripherals included with ORPSoC. Double check, however, that the correct constraints are set, by running the following command before starting place and route.

@example

@kbd{make pdc-file sdc-file}

@end example

These can be generated and edited and then used when running place and route, they will not get replaced.

@node ORDB1A3PE1500 Programming File Generation

@section Programming File Generation

The @code{.adb} file resulting from place and route can be opened in the Actel @emph{Designer} tool and a programming file generated there.

Once this programming file is created, Actel's @emph{FlashPro} can used to program the ORDB1A3PE1500 board.

@node ORDB1A3PE1500 Customising

@section Customising

The versatile nature of the ORDB1A3PE1500 means the design that goes on it must be equally versatile, if not more so.

The following sections have information on how to configure the design.

@node ORDB1A3PE1500 Customising Enabling Existing Modules

@subsection Enabling Existing RTL Modules

The design relies on the Verilog HDL @emph{define} function to indicate which modules are included.

There are only a few modules included by default.

@itemize @bullet

@item Processor - @emph{or1200}

@item Clock and reset generation - @emph{clkgen}

@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}

@end itemize

The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.

Inspect that file to see which modules are able to be included. At present the list includes USB 1.1 host controller and/or slave interface, I2C master/slave core, and SPI master cores.

These cores should be supported and ready to go by just defining them (uncomment in the @code{orpsoc-defines.v} file.)

@node ORDB1A3PE1500 Customising Adding Modules

@subsection Adding RTL Modules

There are a number of steps to take when adding a new module to the design.

@itemize @bullet

@item RTL Files

Create a directory under the board's @code{rtl/verilog} directory, and name it the same as the top level of the module.

Ensure the module's top level file and actual name of the module when it will be instantiated are @emph{all the same}.

Place any include files into the board's @code{rtl/verilog/include} path.

@item Instantiate in ORPSoC Top Level File

Instantiate the module in the ORPSoC top level file, @code{rtl/verilog/orpsoc_top/orpsoc_top.v}, and be sure to take care of the following.

@itemize @bullet

@item Create appropriate @emph{`define} in @code{orpsoc-defines.v} and surround module instantiation with it.

@item Add required I/Os (surrounded by appropriate @emph{`ifdef })

@item Attach to appropriate bus arbiter, declaring any signals required. Be sure to tie them off if modules is not included.