OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [orpsocv2/] [doc/] [orpsoc.texi] - Diff between revs 650 and 655

Go to most recent revision | Only display areas with differences | Details | Blame | View Log

Rev 650 Rev 655
\input texinfo   @c -*-texinfo-*-
\input texinfo   @c -*-texinfo-*-
@c %**start of header
@c %**start of header
@setfilename orpsoc.info
@setfilename orpsoc.info
@settitle ORPSoC manual 0.1
@settitle ORPSoC manual 0.1
@include config.texi
@include config.texi
@c %**end of header
@c %**end of header
 
 
@copying
@copying
This file documents the OpenRISC Reference Platform SoC, @value{ORPSOC}.
This file documents the OpenRISC Reference Platform SoC, @value{ORPSOC}.
 
 
Copyright @copyright{} 2010,2011 OpenCores
Copyright @copyright{} 2010,2011 OpenCores
 
 
@quotation
@quotation
Permission is granted to copy, distribute and/or modify this document
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
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
Texts.  A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
Free Documentation License''.
@end quotation
@end quotation
@end copying
@end copying
 
 
@setchapternewpage on
@setchapternewpage on
@settitle @value{ORPSOC} User Guide
@settitle @value{ORPSOC} User Guide
 
 
@syncodeindex fn cp
@syncodeindex fn cp
@syncodeindex vr cp
@syncodeindex vr cp
 
 
@titlepage
@titlepage
@title @value{ORPSOC} User Guide
@title @value{ORPSOC} User Guide
@c @subtitle subtitle-if-any
@c @subtitle subtitle-if-any
@c @subtitle second-subtitle
@c @subtitle second-subtitle
@author Julius Baxter
@author Julius Baxter
@author OpenCores
@author OpenCores
@author Issue 3 for @value{ORPSOC}
@author Issue 4 for @value{ORPSOC}
 
 
@c  The following two commands
@c  The following two commands
@c  start the copyright page.
@c  start the copyright page.
@page
@page
@vskip 0pt plus 1filll
@vskip 0pt plus 1filll
@insertcopying
@insertcopying
 
 
Published by OpenCores
Published by OpenCores
@end titlepage
@end titlepage
 
 
@c So the toc is printed at the start.
@c So the toc is printed at the start.
@contents
@contents
 
 
@ifnottex
@ifnottex
@node Top
@node Top
@top Scope of this Document
@top Scope of this Document
 
 
This document is the user guide for @value{ORPSOC}, the OpenRISC Reference Platform System on Chip project.
This document is the user guide for @value{ORPSOC}, the OpenRISC Reference Platform System on Chip project.
 
 
@end ifnottex
@end ifnottex
 
 
@menu
@menu
* Introduction::
* Introduction::
* Project Organisation::
* Project Organisation::
* Getting Started::
* Getting Started::
* Reference Design::
* Reference Design::
* ORDB1A3PE1500::
* ORDB1A3PE1500::
* ML501::
* ML501::
* S3ADSP1800::
* S3ADSP1800::
* Atlys::
* Atlys::
* Generic Designs::
* Generic Designs::
* Software::
* Software::
* EDA tool notes::
* EDA tool notes::
* GNU Free Documentation License::  The license for this documentation
* GNU Free Documentation License::  The license for this documentation
* Index::
* Index::
@end menu
@end menu
 
 
@node Document Introduction
@node Document Introduction
@chapter Introduction
@chapter Introduction
 
 
@cindex introduction to this @value{ORPSOC}
@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.
@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 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.
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 ****************************************************************************
@c Project Organisation
@c Project Organisation
@c ****************************************************************************
@c ****************************************************************************
 
 
@node Project Organisation
@node Project Organisation
@chapter Project Organisation
@chapter Project Organisation
@cindex organisation of @value{ORPSOC} project
@cindex organisation of @value{ORPSOC} project
 
 
@menu
@menu
* Overview::
* Overview::
* Software::
* Software::
* RTL::
* RTL::
* Testbenches::
* Testbenches::
* Reference And Board Designs::
* Reference And Board Designs::
@end menu
@end menu
 
 
@node Organisation Overview
@node Organisation Overview
@section 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.
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.
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 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 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.
The following sections outline the organisation of the software, RTL, and board designs.
 
 
@node Software Organisation
@node Software Organisation
@section Software
@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.
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}.
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}.
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.
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.
@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.
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.
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
@node Software Test Naming
@subsection Software Test Naming
@subsection 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}.
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.
@xref{Software}, for further details.
 
 
@node RTL Organisation
@node RTL Organisation
@section RTL
@section RTL
 
 
The HDL code layout conforms to those outlined in the OpenCores.org coding guidelines. @uref{http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf}
The HDL code layout conforms to those outlined in the OpenCores.org coding guidelines. @uref{http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf}
 
 
There are, however, some naming restrictions for this project.
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 (...);}.
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.
This will avoid confusion and help the scripts locate modules.
 
 
@subsection Verilog HDL
@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.
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
@node Testbench Organisation
@section Testbench
@section Testbench
 
 
For each design in @value{ORPSOC} there will be a testbench instantiating the top level, and any required peripherals.
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.
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.
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
@node Organisation of Reference And Board Designs
@section 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.
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
@subsection Module Selection
 
 
Typically, a board-targeted design will wish to reuse common components (processor, debug interface, Wishbone arbiters, UART etc.)
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}.
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.
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 ****************************************************************************
@c Getting started
@c Getting started
@c ****************************************************************************
@c ****************************************************************************
 
 
@node Getting Started
@node Getting Started
@chapter Getting Started
@chapter Getting Started
@cindex source files for @value{ORPSOC}, downloading
@cindex source files for @value{ORPSOC}, downloading
 
 
@menu
@menu
* Supported Platforms::
* Supported Platforms::
* Obtaining Project Source::
* Obtaining Project Source::
* Required Tools::
* Required Tools::
@end menu
@end menu
 
 
@node Getting Started Supported Platforms
@node Getting Started Supported Platforms
@section Supported Host Platforms
@section Supported Host Platforms
@cindex host platforms supported by the @value{ORPSOC} project
@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.
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.
Unless indicated otherwise, support for the project under Cygwin on Microsoft Windows platforms cannot be assumed.
 
 
@node Getting Started Obtaining Project Source
@node Getting Started Obtaining Project Source
@section Obtaining Project Source
@section Obtaining Project Source
@cindex getting a copy of the @value{ORPSOC} project
@cindex getting a copy of the @value{ORPSOC} project
 
 
The source for @value{ORPSOC} can be obtained from the OpenCores subversion (SVN) server.
The source for @value{ORPSOC} can be obtained from the OpenCores subversion (SVN) server.
 
 
@example
@example
@kbd{svn export http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2}
@kbd{svn export http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2}
@end example
@end example
 
 
@node Getting Started Required Tools
@node Getting Started Required Tools
@section Required Tools
@section Required Tools
@cindex tools and utilities required for @value{ORPSOC}
@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.
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.
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.
The required tools can be divided into four groups.
 
 
@itemize @bullet
@itemize @bullet
@item
@item
Host system tools - things like gcc, make, texinfo.
Host system tools - things like gcc, make, texinfo.
 
 
@item
@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.
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
@item
Electronic design automation (EDA) tools - preprocessors, simulators, FPGA tool suites, etc.
Electronic design automation (EDA) tools - preprocessors, simulators, FPGA tool suites, etc.
 
 
@item
@item
Debug tools - tools providing control over the system on target
Debug tools - tools providing control over the system on target
@end itemize
@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.
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.
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.
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 ****************************************************************************
@c Reference Design chapter
@c Reference Design chapter
@c ****************************************************************************
@c ****************************************************************************
 
 
@node Reference Design
@node Reference Design
@chapter Reference Design
@chapter Reference Design
@cindex reference design
@cindex reference design
 
 
@menu
@menu
* Overview::
* Overview::
* Structure::
* Structure::
* Tools::
* Tools::
* Simulation::
* Simulation::
* Synthesis::
* Synthesis::
@end menu
@end menu
 
 
@node Reference Design Overview
@node Reference Design Overview
@section 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 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 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 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 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.
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
@node Reference Design Structure
@section Structure
@section Structure
 
 
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.
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}.
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
@node Reference Design RTL
@subsection 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.
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.
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}.
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.
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
@node Reference Design Software
@subsection Software
@subsection Software
 
 
The software run on the reference design is found in the @value{ORPSOC} root directory, under the @code{sw} path.
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}.
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}.
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.
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
@node Reference Design Simulation
@subsection Simulation
@subsection Simulation
 
 
The simulation of the reference design is run from the @code{sim/run} path.
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 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.
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.
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
@node Reference Design Tools
@section Tools
@section Tools
 
 
@menu
@menu
* Host Tools::
* Host Tools::
* Target System Tools::
* Target System Tools::
* EDA Tools::
* EDA Tools::
* Debug Tools::
* Debug Tools::
@end menu
@end menu
 
 
@node Reference Design Host Tools
@node Reference Design Host Tools
@subsection Host Tools
@subsection Host Tools
@cindex host tools required
@cindex host tools required
 
 
Standard development suite of tools: gcc, make, etc.
Standard development suite of tools: gcc, make, etc.
 
 
@node Reference Design Target System Tools
@node Reference Design Target System Tools
@subsection Target System Tools
@subsection Target System Tools
@cindex target system tools required
@cindex target system tools required
 
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
 
@node Reference Design EDA Tools
@node Reference Design EDA Tools
@subsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required
@cindex EDA tools required
 
 
RTL simulation: Icarus Verilog (also compatible with Mentor Graphics' Modelsim)
RTL simulation: Icarus Verilog (also compatible with Mentor Graphics' Modelsim)
Cycle Accurate Simulation: Verilator, Verilog-Perl, System-Perl, SystemC
Cycle Accurate Simulation: Verilator, Verilog-Perl, System-Perl, SystemC
 
 
@node Reference Design Debug Tools
@node Reference Design Debug Tools
@subsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required
@cindex Debug tools required
 
 
None. The target is purely simulation, no extra utilities are required to debug.
None. The target is purely simulation, no extra utilities are required to debug.
 
 
@node Reference Design Simulation Instructions
@node Reference Design Simulation Instructions
@section Simulation
@section Simulation
 
 
@menu
@menu
* RTL::
* RTL::
* Cycle Accurate::
* Cycle Accurate::
* Results::
* Results::
@end menu
@end menu
 
 
@node Reference Design RTL Simulation
@node Reference Design RTL Simulation
@subsection RTL
@subsection RTL
@cindex rtl simulation of reference design
@cindex rtl simulation of reference design
 
 
All simulations of the reference design are run from the @code{sim/run} path.
All simulations of the reference design are run from the @code{sim/run} path.
 
 
@subheading Running RTL Regression Test
@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:
The simplest way of starting a run through the regression test, using the default RTL simulator, Icarus Verilog, can be done with:
 
 
@example
@example
@kbd{make rtl-tests}
@kbd{make rtl-tests}
@end example
@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.
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
@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.
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
@example
@kbd{make rtl-test TEST=or1200-basic}
@kbd{make rtl-test TEST=or1200-basic}
@end example
@end example
 
 
@node Running A Set Of Specific Reference Design RTL Tests
@node Running A Set Of Specific Reference Design RTL Tests
@subheading Running A Set Of Specific 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.
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
@example
@kbd{make rtl-tests TESTS="sdram-rows uart-simple or1200-mmu or1200-fp"}
@kbd{make rtl-tests TESTS="sdram-rows uart-simple or1200-mmu or1200-fp"}
@end example
@end example
 
 
@node Providing A Precompiled ELF Executable
@node Providing A Precompiled ELF Executable
@subheading 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.
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
@example
@kbd{make rtl-test USER_ELF=/path/to/myapp.elf}
@kbd{make rtl-test USER_ELF=/path/to/myapp.elf}
@end example
@end example
 
 
The ELF will be converted to binary format, and then converted to a VMEM to be
The ELF will be converted to binary format, and then converted to a VMEM to be
loaded into the model for execution at runtime.
loaded into the model for execution at runtime.
 
 
@node Providing A Custom VMEM Image
@node Providing A Custom VMEM Image
@subheading 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.
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
@example
@kbd{make rtl-test USER_VMEM=/path/to/myapp.vmem}
@kbd{make rtl-test USER_VMEM=/path/to/myapp.vmem}
@end example
@end example
 
 
This VMEM file will be copied into the working directory, and renamed according to what the simulated memory expects.
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
@node Options For Reference Design RTL Tests
@subheading Options For RTL Tests
@subheading Options For RTL Tests
 
 
There are some options, which can be specified through shell environment variables when running the test.
There are some options, which can be specified through shell environment variables when running the test.
 
 
@table @code
@table @code
 
 
@item VCD
@item VCD
Set to '1' to enable @emph{value change dump} (VCD) creation in @code{sim/out/@emph{testname}.vcd}
Set to '1' to enable @emph{value change dump} (VCD) creation in @code{sim/out/@emph{testname}.vcd}
 
 
@item VCD_DELAY
@item VCD_DELAY
Delay VCD creation start time by this number of timesteps (used as a Verilog @code{#delay} in the testbench.)
Delay VCD creation start time by this number of timesteps (used as a Verilog @code{#delay} in the testbench.)
 
 
@item VCD_DELAY_INSNS
@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.)
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
@item END_TIME
Force simulation end (@code{$finish}) at this time.
Force simulation end (@code{$finish}) at this time.
 
 
@item DISABLE_PROCESSOR_LOGS
@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.
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
@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.
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
@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.
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
@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.
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.
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
@end table
 
 
 
 
 
 
 
 
 
 
@node Reference Design Cycle Accurate
@node Reference Design Cycle Accurate
@subsection Cycle Accurate
@subsection Cycle Accurate
@cindex cycle accurate simulation of reference design
@cindex cycle accurate simulation of reference design
 
 
@subheading Running Cycle Accurate Regression Test
@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:
The simplest way of starting a run through the regression test using the cycle accurate model can be done with:
 
 
@example
@example
@kbd{make vlt-tests}
@kbd{make vlt-tests}
@end example
@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.
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
@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.
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
@example
@kbd{make vlt-test TEST=or1200-basic}
@kbd{make vlt-test TEST=or1200-basic}
@end example
@end example
 
 
@subheading Generating Cycle Accurate Simulator Executable
@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.
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
@example
@kbd{make prepare-vlt}
@kbd{make prepare-vlt}
@end example
@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.
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
@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.
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
@example
@kbd{make prepare-vlt-profiled}
@kbd{make prepare-vlt-profiled}
@end example
@end example
 
 
@subheading Cycle Accurate Model Executable Usage
@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.
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
@example
@kbd{Vorpsoc_top --help}
@kbd{Vorpsoc_top --help}
@end example
@end example
 
 
A short list of options is given here.
A short list of options is given here.
 
 
@table @code
@table @code
 
 
@item -f @var{file}
@item -f @var{file}
@itemx --program @var{file}
@itemx --program @var{file}
@cindex @code{-f}
@cindex @code{-f}
@cindex @code{--program}
@cindex @code{--program}
Load software from OR32 ELF image @var{file}
Load software from OR32 ELF image @var{file}
 
 
If unspecified, model attempts to load VMEM file @code{sram.vmem}
If unspecified, model attempts to load VMEM file @code{sram.vmem}
 
 
@item -v
@item -v
@itemx --vcd
@itemx --vcd
@cindex @code{-v}
@cindex @code{-v}
@cindex @code{--vcd}
@cindex @code{--vcd}
Dump VCD file
Dump VCD file
 
 
@item -e @var{value}
@item -e @var{value}
@itemx --endtime @var{value}
@itemx --endtime @var{value}
@cindex @code{-e}
@cindex @code{-e}
@cindex @code{--endtime}
@cindex @code{--endtime}
End simulation after @var{value} simulated ns
End simulation after @var{value} simulated ns
 
 
@item -l @var{file}
@item -l @var{file}
@itemx --log @var{file}
@itemx --log @var{file}
@cindex @code{-l}
@cindex @code{-l}
@cindex @code{--log}
@cindex @code{--log}
Log processor execution trace to @var{file}
Log processor execution trace to @var{file}
 
 
@end table
@end table
 
 
@node Reference Design Results
@node Reference Design Results
@subsection Results
@subsection Results
@cindex output from simulation of reference design
@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.
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
@subheading Processor Execution Trace
 
 
A trace of the processor after each executed instruction is generated by both the event and cycle accurate models.
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}.
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
@subheading Processor SPR Access Log
 
 
A list of processor special purpose registers (SPR) accesses is created when processor logging is enabled.
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}.
These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-sprs.log}.
 
 
@subheading Processor Instruction Excecution Time Log
@subheading Processor Instruction Excecution Time Log
 
 
A list of when each instruction was executed is generated when processor execution logging is enabled.
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.
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}.
These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-lookup.log}.
 
 
@subheading Processor Report Mechanism 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.
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.
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)
@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}.
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
@node Reference Design Synthesis
@section 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.
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 ****************************************************************************
@c ORDB1A3PE1500 board build chapter
@c ORDB1A3PE1500 board build chapter
@c ****************************************************************************
@c ****************************************************************************
 
 
@node ORDB1A3PE1500
@node ORDB1A3PE1500
@chapter ORDB1A3PE1500
@chapter ORDB1A3PE1500
@cindex ORDB1A3PE1500 board build information
@cindex ORDB1A3PE1500 board build information
 
 
@menu
@menu
* Overview::
* Overview::
* Structure::
* Structure::
* Tools::
* Tools::
* Simulating::
* Simulating::
* Synthesis and Backend::
* Synthesis and Backend::
* Programming File Generation::
* Programming File Generation::
* Customising::
* Customising::
@end menu
@end menu
 
 
@node ORDB1A3PE1500 Overview
@node ORDB1A3PE1500 Overview
@section Overview
@section Overview
 
 
The ORDB1 (ORSoC development board 1) with Actel A3PE1500 FPGA is supported by this build.
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.
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.
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.
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.
This guide will overview how to simulation, synthesize and customise the system.
 
 
@node ORDB1A3PE1500 Structure
@node ORDB1A3PE1500 Structure
@section 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}.
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 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.
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.
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
@node ORDB1A3PE1500 Tools
@section Tools
@section Tools
 
 
@menu
@menu
* Host Tools::
* Host Tools::
* Target System Tools::
* Target System Tools::
* EDA Tools::
* EDA Tools::
* Debug Tools::
* Debug Tools::
@end menu
@end menu
 
 
@node ORDB1A3PE1500 Host Tools
@node ORDB1A3PE1500 Host Tools
@subsection Host Tools
@subsection Host Tools
@cindex host tools required ORDB1A3PE1500
@cindex host tools required ORDB1A3PE1500
 
 
Standard development suite of tools: gcc, make, etc.
Standard development suite of tools: gcc, make, etc.
 
 
@node ORDB1A3PE1500 Target System Tools
@node ORDB1A3PE1500 Target System Tools
@subsection Target System Tools
@subsection Target System Tools
@cindex target system tools required ORDB1A3PE1500
@cindex target system tools required ORDB1A3PE1500
 
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
 
@node ORDB1A3PE1500 EDA Tools
@node ORDB1A3PE1500 EDA Tools
@subsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required ORDB1A3PE1500
@cindex EDA tools required ORDB1A3PE1500
 
 
RTL, gatelevel simulation: Mentor Graphics' Modelsim
RTL, gatelevel simulation: Mentor Graphics' Modelsim
Synthesis: Synopsys Synplify (included in Actel Libero Suite)
Synthesis: Synopsys Synplify (included in Actel Libero Suite)
Backend: Actel Designer (included in Actel Libero Suite)
Backend: Actel Designer (included in Actel Libero Suite)
Programming: Actel FlashPRO (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.
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
@node ORDB1A3PE1500 Debug Tools
@subsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required ORDB1A3PE1500
@cindex Debug tools required ORDB1A3PE1500
 
 
or_debug_proxy, ORPmon
or_debug_proxy, ORPmon
 
 
@node ORDB1A3PE1500 Simulating
@node ORDB1A3PE1500 Simulating
@section Simulating
@section Simulating
@cindex simulating ORDB1A3PE1500
@cindex simulating ORDB1A3PE1500
 
 
@subheading Run RTL Regression Test
@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.
To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.
 
 
@example
@example
@kbd{make rtl-tests}
@kbd{make rtl-tests}
@end example
@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}.
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.
Options specific to the ORDB1A3PE1500 build.
 
 
@table @code
@table @code
 
 
@item PRELOAD_RAM
@item PRELOAD_RAM
Set to '1' to enable loading of the software image into RAM at the beginning of simulation.
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.
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
@end table
 
 
 
 
 
 
@node ORDB1A3PE1500 Synthesis
@node ORDB1A3PE1500 Synthesis
@section 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.
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
@example
@kbd{make all}
@kbd{make all}
@end example
@end example
 
 
This will create a EDIF netlist in @code{syn/synplify/out}.
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.
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
@node ORDB1A3PE1500 Synthesis Options
@subsection Options
@subsection Options
 
 
The following can be passed as environment variables when running @kbd{make all}.
The following can be passed as environment variables when running @kbd{make all}.
 
 
@table @code
@table @code
 
 
@item RTL_TOP
@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.
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
@item FPGA_PART
Defaults to A3PE1500 but if targeting any other set it with this.
Defaults to A3PE1500 but if targeting any other set it with this.
 
 
@item FPGA_FAMILY
@item FPGA_FAMILY
Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.
Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.
 
 
@item FPGA_PACKAGE
@item FPGA_PACKAGE
Defaults to PQFP208 but if targeting any other set it with this.
Defaults to PQFP208 but if targeting any other set it with this.
 
 
@item FPGA_SPEED_GRADE
@item FPGA_SPEED_GRADE
Defaults to Std but if targeting any other set it with this.
Defaults to Std but if targeting any other set it with this.
 
 
@item FREQ
@item FREQ
Target frequency for synthesis.
Target frequency for synthesis.
 
 
@item MAXFAN
@item MAXFAN
Maximum net fanout.
Maximum net fanout.
 
 
@item MAXFAN_HARD
@item MAXFAN_HARD
Hard limit on maximum net fanout.
Hard limit on maximum net fanout.
 
 
@item GLOBALTHRESH
@item GLOBALTHRESH
Threshold of fanout before promoting signal to a global routing net.
Threshold of fanout before promoting signal to a global routing net.
 
 
@item RETIMING
@item RETIMING
Defaults to '1' (on) but set to '0' to disable.
Defaults to '1' (on) but set to '0' to disable.
 
 
@item RESOURCE_SHARING
@item RESOURCE_SHARING
Defaults to '1' (on) but set to '0' to disable.
Defaults to '1' (on) but set to '0' to disable.
 
 
@item DISABLE_IO_INSERTION
@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.
Defaults to '0' (off) but set to '1' to enable. Useful when synthesizing individual modules not intended as a top level.
 
 
@end table
@end table
 
 
@node ORDB1A3PE1500 Synthesis Warnings
@node ORDB1A3PE1500 Synthesis Warnings
@subsection Checks
@subsection Checks
 
 
The following is a list of some considerations before synthesis.
The following is a list of some considerations before synthesis.
 
 
@itemize @bullet
@itemize @bullet
@item bootrom.v
@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.
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.
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
@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.
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
@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}
If using any command line settings, they can be checked by passing them to the following make target: @kbd{make print-config}
 
 
 
 
@end itemize
@end itemize
 
 
@node ORDB1A3PE1500 Place and Route
@node ORDB1A3PE1500 Place and Route
@section 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.
Place and route is run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make all}
@kbd{make all}
@end example
@end example
 
 
This will create a @code{.adb} file in the same path.
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.
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
@node ORDB1A3PE1500 Place and route options
@subsection 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.
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}.
The following can be passed as environment variables when running @kbd{make all}.
 
 
@table @code
@table @code
 
 
@item FPGA_PART
@item FPGA_PART
Defaults to A3PE1500 but if targeting any other set it with this.
Defaults to A3PE1500 but if targeting any other set it with this.
 
 
@item FPGA_FAMILY
@item FPGA_FAMILY
Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.
Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.
 
 
@item FPGA_PACKAGE
@item FPGA_PACKAGE
Defaults to ``208 PQFP'' but if targeting any other set it with this.
Defaults to ``208 PQFP'' but if targeting any other set it with this.
 
 
 
 
@item FPGA_SPEED_GRADE
@item FPGA_SPEED_GRADE
Defaults to Std but if targeting any other set it with this.
Defaults to Std but if targeting any other set it with this.
 
 
@item FPGA_VOLTAGE
@item FPGA_VOLTAGE
Defaults to 1.5 but if targeting any other set it with this.
Defaults to 1.5 but if targeting any other set it with this.
 
 
@item FPGA_TEMP_RANGE
@item FPGA_TEMP_RANGE
Defaults to COM but if targeting any other set it with this.
Defaults to COM but if targeting any other set it with this.
 
 
@item FPGA_VOLT_RANGE
@item FPGA_VOLT_RANGE
Defaults to COM but if targeting any other set it with this.
Defaults to COM but if targeting any other set it with this.
 
 
@item PLACE_INCREMENTAL
@item PLACE_INCREMENTAL
Defaults to off.
Defaults to off.
 
 
@item ROUTE_INCREMENTAL
@item ROUTE_INCREMENTAL
Defaults to off.
Defaults to off.
 
 
@item PLACER_HIGH_EFFORT
@item PLACER_HIGH_EFFORT
Defaults to off.
Defaults to off.
 
 
@item BOARD_CONFIG
@item BOARD_CONFIG
Defaults to @code{orsoccpuexpio.mkpinassigns}
Defaults to @code{orsoccpuexpio.mkpinassigns}
 
 
@end table
@end table
 
 
@node ORDB1A3PE1500 Constraints
@node ORDB1A3PE1500 Constraints
@subsection 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.
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}.
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.
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
@example
@kbd{make pdc-file sdc-file}
@kbd{make pdc-file sdc-file}
@end example
@end example
 
 
These can be generated and edited and then used when running place and route, they will not get replaced.
These can be generated and edited and then used when running place and route, they will not get replaced.
 
 
@node ORDB1A3PE1500 Programming File Generation
@node ORDB1A3PE1500 Programming File Generation
@section 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.
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.
Once this programming file is created, Actel's @emph{FlashPro} can used to program the ORDB1A3PE1500 board.
 
 
@node ORDB1A3PE1500 Customising
@node ORDB1A3PE1500 Customising
@section 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 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.
The following sections have information on how to configure the design.
 
 
@node ORDB1A3PE1500 Customising Enabling Existing Modules
@node ORDB1A3PE1500 Customising Enabling Existing Modules
@subsection Enabling Existing RTL Modules
@subsection Enabling Existing RTL Modules
 
 
The design relies on the Verilog HDL @emph{define} function to indicate which modules are included.
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.
There are only a few modules included by default.
 
 
@itemize @bullet
@itemize @bullet
@item Processor - @emph{or1200}
@item Processor - @emph{or1200}
@item Clock and reset generation - @emph{clkgen}
@item Clock and reset generation - @emph{clkgen}
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
@end itemize
@end itemize
 
 
The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.
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.
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.)
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
@node ORDB1A3PE1500 Customising Adding Modules
@subsection Adding RTL Modules
@subsection Adding RTL Modules
 
 
There are a number of steps to take when adding a new module to the design.
There are a number of steps to take when adding a new module to the design.
 
 
@itemize @bullet
@itemize @bullet
@item RTL Files
@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.
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}.
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.
Place any include files into the board's @code{rtl/verilog/include} path.
 
 
@item Instantiate in ORPSoC Top Level File
@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.
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
@itemize @bullet
@item Create appropriate @emph{`define} in @code{orpsoc-defines.v} and surround module instantiation with it.
@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 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.
@item Attach to appropriate bus arbiter, declaring any signals required. Be sure to tie them off if modules is not included.
@item Update appropriate bus arbiter (in board's @code{rtl/verilog/arbiters} path) adding (uncommenting) additional ports as needed.
@item Update appropriate bus arbiter (in board's @code{rtl/verilog/arbiters} path) adding (uncommenting) additional ports as needed.
@item Update board's @code{rtl/verilog/include/orpsoc-params.v} file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.
@item Update board's @code{rtl/verilog/include/orpsoc-params.v} file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.
@item Attach appropriate clocks and resets, modify the board's @code{rtl/verilog/clkgen/clkgen.v} file generating appropriate clocks if required.
@item Attach appropriate clocks and resets, modify the board's @code{rtl/verilog/clkgen/clkgen.v} file generating appropriate clocks if required.
@item Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.
@item Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.
@end itemize
@end itemize
 
 
@item Update ORPSoC Testbench
@item Update ORPSoC Testbench
 
 
Update the board's @code{bench/verilog/orpsoc_testbench.v} file with appropriate ports (surrounded by appropriate @emph{`ifdef}.)
Update the board's @code{bench/verilog/orpsoc_testbench.v} file with appropriate ports (surrounded by appropriate @emph{`ifdef}.)
 
 
Add any desired models to help test the module to the board's @code{bench/verilog} path and instantiate it correctly in the testbench.
Add any desired models to help test the module to the board's @code{bench/verilog} path and instantiate it correctly in the testbench.
 
 
@item Add Software Drivers and Tests
@item Add Software Drivers and Tests
 
 
In a similar fashion to what is already in the board's @code{sw/drivers} and @code{sw/tests} path, create desired driver and test software to be used during simulation (and potentially on target.)
In a similar fashion to what is already in the board's @code{sw/drivers} and @code{sw/tests} path, create desired driver and test software to be used during simulation (and potentially on target.)
 
 
@item Update Backend Scripts
@item Update Backend Scripts
 
 
If any I/O is added, or special timing specified, the board's backend main Makefile, @code{backend/par/bin/Makefile} and pinout files (in @code{backend/par/bin} will need to be updated.
If any I/O is added, or special timing specified, the board's backend main Makefile, @code{backend/par/bin/Makefile} and pinout files (in @code{backend/par/bin} will need to be updated.
 
 
The section in @code{backend/par/bin/Makefile} mapping signals to Makefile variables will need to have these new signals added to them. The section in the file begins with @code{$(PDC_FILE):} and is actually a set of long bash lines.
The section in @code{backend/par/bin/Makefile} mapping signals to Makefile variables will need to have these new signals added to them. The section in the file begins with @code{$(PDC_FILE):} and is actually a set of long bash lines.
 
 
Continuing the format already there should be easy enough. Remember that the @code{orpsoc-defines.v} file is parsed and it's possible to tell if the module is included by testing if the variable is defined.
Continuing the format already there should be easy enough. Remember that the @code{orpsoc-defines.v} file is parsed and it's possible to tell if the module is included by testing if the variable is defined.
 
 
For example, to add I/Os for a module called @code{foo}, and in @code{orpsoc-defines.v} a value @code{FOO1} is defined, we can add I/Os @code{foo1_srx_i} and @code{foo1_tx_o[3:0]} with the following.
For example, to add I/Os for a module called @code{foo}, and in @code{orpsoc-defines.v} a value @code{FOO1} is defined, we can add I/Os @code{foo1_srx_i} and @code{foo1_tx_o[3:0]} with the following.
 
 
@example
@example
@kbd{   $(Q)if [ ! -z $$FOO1 ]; then \
@kbd{   $(Q)if [ ! -z $$FOO1 ]; then \
        echo "set_io foo1_srx_i " $(FOO_SRX_BUS_SETTINGS) " \
        echo "set_io foo1_srx_i " $(FOO_SRX_BUS_SETTINGS) " \
        -pinname "$(FOO1_SRX_PIN) >> $@@; \
        -pinname "$(FOO1_SRX_PIN) >> $@@; \
        echo "set_io foo1_tx_o\\[0\\] " $(FOO_TX_BUS_SETTINGS) " \
        echo "set_io foo1_tx_o\\[0\\] " $(FOO_TX_BUS_SETTINGS) " \
         -pinname "$(FOO1_TX0_PIN) >> $@@; \
         -pinname "$(FOO1_TX0_PIN) >> $@@; \
        echo "set_io foo1_tx_o\\[1\\] " $(FOO_TX_BUS_SETTINGS) "  \
        echo "set_io foo1_tx_o\\[1\\] " $(FOO_TX_BUS_SETTINGS) "  \
        -pinname "$(FOO1_TX1_PIN) >> $@@; \
        -pinname "$(FOO1_TX1_PIN) >> $@@; \
        echo "set_io foo1_tx_o\\[2\\] " $(FOO_TX_BUS_SETTINGS) "  \
        echo "set_io foo1_tx_o\\[2\\] " $(FOO_TX_BUS_SETTINGS) "  \
        -pinname "$(FOO1_TX2_PIN) >> $@@; \
        -pinname "$(FOO1_TX2_PIN) >> $@@; \
        echo "set_io foo1_tx_o\\[3\\] " $(FOO_TX_BUS_SETTINGS) "  \
        echo "set_io foo1_tx_o\\[3\\] " $(FOO_TX_BUS_SETTINGS) "  \
        -pinname "$(FOO1_TX3_PIN) >> $@@; \
        -pinname "$(FOO1_TX3_PIN) >> $@@; \
fi
fi
       }
       }
@end example
@end example
 
 
@emph{(ensure there is no whitespace after the trailing backslashes.)}
@emph{(ensure there is no whitespace after the trailing backslashes.)}
 
 
It's a little hard to follow, but it's essentially one @code{set_io} line for each I/O line.
It's a little hard to follow, but it's essentially one @code{set_io} line for each I/O line.
 
 
First the line checks if the module's define was exported (which happens automatically if it's defined in @code{orpsoc-defines.v}.
First the line checks if the module's define was exported (which happens automatically if it's defined in @code{orpsoc-defines.v}.
 
 
Note that what is defined can be checked by running @kbd{make print-defines} in the board's @code{backend/par/run} path.
Note that what is defined can be checked by running @kbd{make print-defines} in the board's @code{backend/par/run} path.
 
 
The values of the bus settings variables depend on the desired I/O standards and other examples in the Makefile can be referenced.
The values of the bus settings variables depend on the desired I/O standards and other examples in the Makefile can be referenced.
 
 
The pin numbers need to be set in the @code{.mkpinassigns} which is included into the Makefile (according to the @code{BOARD_CONFIG} variable set when running the @code{make} command.)
The pin numbers need to be set in the @code{.mkpinassigns} which is included into the Makefile (according to the @code{BOARD_CONFIG} variable set when running the @code{make} command.)
 
 
These files are simple assignments of values to variables (and potentially then to other variables) which correspond to the variables finally used in the main Makefile.
These files are simple assignments of values to variables (and potentially then to other variables) which correspond to the variables finally used in the main Makefile.
 
 
The physical constraints file can be generated manually with the @kbd{make pdc-file} command.
The physical constraints file can be generated manually with the @kbd{make pdc-file} command.
 
 
@end itemize
@end itemize
 
 
@c ****************************************************************************
@c ****************************************************************************
@c ML501 board build chapter
@c ML501 board build chapter
@c ****************************************************************************
@c ****************************************************************************
 
 
@node ML501
@node ML501
@chapter ML501
@chapter ML501
@cindex ML501 board build information
@cindex ML501 board build information
 
 
@menu
@menu
* Overview::
* Overview::
* Structure::
* Structure::
* Tools::
* Tools::
* Simulating::
* Simulating::
* Synthesis and Backend::
* Synthesis and Backend::
* Programming File Generation::
* Programming File Generation::
* Customising::
* Customising::
* Running And Debugging Software::
* Running And Debugging Software::
@end menu
@end menu
 
 
@node ML501 Overview
@node ML501 Overview
@section Overview
@section Overview
 
 
The Xilinx ML501 board contains a Virtex LX50 part, varied memories and peripherals. See Xilinx's site for specific details:
The Xilinx ML501 board contains a Virtex LX50 part, varied memories and peripherals. See Xilinx's site for specific details:
 
 
@uref{http://www.xilinx.com/products/devkits/HW-V5-ML501-UNI-G.htm}
@uref{http://www.xilinx.com/products/devkits/HW-V5-ML501-UNI-G.htm}
 
 
The OR1200 core and Wishbone bus is set to run at 66MHz. The OR1200 core, as defined here, is almost fully featured, with every hardware arithmetic option enabled, and the largest possible cache configuration, of 1024 sets with 8 words per line which is 32 kilobytes of cache each for instruction and data buses.
The OR1200 core and Wishbone bus is set to run at 66MHz. The OR1200 core, as defined here, is almost fully featured, with every hardware arithmetic option enabled, and the largest possible cache configuration, of 1024 sets with 8 words per line which is 32 kilobytes of cache each for instruction and data buses.
 
 
Not all peripherals are supported, and adding support for each is a goal.
Not all peripherals are supported, and adding support for each is a goal.
 
 
At present the build contains a memory controller for the DDR2 SDRAM (based around a Xilinx MIG derived controller) and SSRAM. None of the other peripherals (VGA/AC97/PS2/USB/LCD) have controllers in the design yet.
At present the build contains a memory controller for the DDR2 SDRAM (based around a Xilinx MIG derived controller), SSRAM (remains to be verified), and CFI flash. None of the other peripherals (VGA/AC97/PS2/USB/LCD) have controllers in the design yet.
 
 
The OpenCores 10/100 Ethernet MAC can be used for Ethernet, but only with the PHY in 10/100 mode using the MII interface to the Marvel Alaska Ethernet PHY IC. There still may be bugs in the FIFO buffer configuration in the ML501's @code{ethmac_defines.v} file should not be changed.
The OpenCores 10/100 Ethernet MAC can be used for Ethernet, but only with the PHY in 10/100 mode using the MII interface to the Marvel Alaska Ethernet PHY IC. There still may be bugs in the FIFO buffer configuration in the ML501's @code{ethmac_defines.v} file should not be changed.
 
 
The ML501 build's scripts are capable of generating either a programming bitstream, @code{.bit}, file for direct programming of the FPGA via JTAG, or a flash image , @code{.mcs}, file which can be programmed into the on-board SPI flash which the FPGA can configure itself from on power-on. This flash image file may also contain a software image the processor can load at reset to, for example, present the user with the prompt for a boot monitor at power-on.
The ML501 build's scripts are capable of generating either a programming bitstream, @code{.bit}, file for direct programming of the FPGA via JTAG, or a flash image , @code{.mcs}, file which can be programmed into the on-board SPI flash which the FPGA can configure itself from on power-on. This flash image file may also contain a software image the processor can load at reset to, for example, present the user with the prompt for a boot monitor at power-on.
 
 
This guide is a work in progress, and provides the basics on simulating, building and modifying the design.
This guide is a work in progress, and provides the basics on simulating, building and modifying the design.
 
 
@node ML501 Structure
@node ML501 Structure
@section 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/xilinx/ml501}.
Note that in this chapter the term @emph{board path} refers to the path in the project for this board port; @code{boards/xilinx/ml501}.
 
 
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 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.
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.
 
 
 
The default configuration will result in a design which executes from the RAM at reset. For simulation, the @code{PRELOAD_RAM} option will need to be used to ensure the processor starts up correctly. To configure and simulate the build to boot from flash, see below.
 
 
Backend files, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
Backend files, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
 
 
@node ML501 Xilinx Environment Setup
@node ML501 Xilinx Environment Setup
@subsection ML501 Xilinx Environment Setup
@subsection ML501 Xilinx Environment Setup
 
 
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
 
 
 
 
@node ML501 Tools
@node ML501 Tools
@section Tools
@section Tools
 
 
@menu
@menu
* Host Tools::
* Host Tools::
* Target System Tools::
* Target System Tools::
* EDA Tools::
* EDA Tools::
* Debug Tools::
* Debug Tools::
@end menu
@end menu
 
 
@node ML501 Host Tools
@node ML501 Host Tools
@subsection Host Tools
@subsection Host Tools
@cindex host tools required ML501
@cindex host tools required ML501
 
 
Standard development suite of tools: gcc, make, etc.
Standard development suite of tools: gcc, make, etc.
 
 
@node ML501 Target System Tools
@node ML501 Target System Tools
@subsection Target System Tools
@subsection Target System Tools
@cindex target system tools required ML501
@cindex target system tools required ML501
 
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
 
@node ML501 EDA Tools
@node ML501 EDA Tools
@subsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required ML501
@cindex EDA tools required ML501
 
 
RTL, gatelevel simulation: Mentor Graphics' Modelsim
RTL, gatelevel simulation: Mentor Graphics' Modelsim
Synthesis: XST (from Xilinx ISE)
Synthesis: XST (from Xilinx ISE)
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
Programming: iMPACT (from Xilinx ISE)
Programming: iMPACT (from Xilinx ISE)
 
 
This has been tested with Xilinx ISE 11.1 under Ubuntu Linux.
This has been tested with Xilinx ISE 11.1 under Ubuntu Linux.
 
 
 
 
@node ML501 Debug Tools
@node ML501 Debug Tools
@subsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required ML501
@cindex Debug tools required ML501
 
 
or_debug_proxy, ORPmon
or_debug_proxy, ORPmon
 
 
@node ML501 Simulating
@node ML501 Simulating
@section Simulating
@section Simulating
@cindex simulating ML501
@cindex simulating ML501
 
 
Ensure the Xilinx environment has been setup before running all simulations for this board build. @xref{Xilinx Environment Setup}.
Ensure the Xilinx environment has been setup before running all simulations for this board build. @xref{Xilinx Environment Setup}.
 
 
 
 
@subheading Run RTL Regression Test
@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.
To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.
 
 
@example
@example
@kbd{make rtl-tests}
@kbd{make rtl-tests}
@end example
@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}.
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 ML501 build.
Options specific to the ML501 build.
 
 
@table @code
@table @code
 
 
@item PRELOAD_RAM
@item PRELOAD_RAM
Set to '1' to enable loading of the software image into RAM at the beginning of simulation.
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.
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
@end table
 
 
 
@node ML501 Simulating Boot From Flash
 
@subsection Simulating Boot From Flash
 
@cindex simulating ML501 flash boot
 
 
 
By default, the build will boot from RAM, but it is often useful to compile the design for FPGA so that it boots from a large software image in the 32MB CFI flash part (u-boot bootloader or a Linux kernel image, etc.)
 
 
 
It is, then, useful to be able to simulate this.
 
 
 
@subsubsection Configure the design
 
 
 
First, ensure the build is configured to boot from the flash memory. @xref{ML501 boot from flash configuration}.
 
 
 
@subsubsection Prepare the image
 
 
 
Next, generate an image to preload into the flash. @emph{Note}: this is not done automatically at present and must be done manually.
 
 
 
Create the executable for the program you wish to boot out of flash. Generate a binary of it using @code{or32-elf-objcopy} like so:
 
 
 
@example
 
@kbd{or32-elf-objcopy -O binary @emph{yourexe.elf} @emph{youroutputfile.bin}}
 
@end example
 
 
 
@emph{Note}: how to create software to execute out of flash on OpenRISC is not covered here, but it's likely an executable intended to execute from RAM will require subtle modifications to the reset vector code and linker script to ensure it executes from flash correctly. Consulting the OpenRISC project wiki is recommended.
 
 
 
Next, turn this into a VMEM image that the flash model can load. To do this use the tool found in the root @kbd{sw/utils} path called @kbd{bin2vmem}. Save this resulting VMEM it into the board's @kbd{sim/run} path and name it @kbd{cfi-flash.vmem}.
 
 
 
@example
 
@kbd{.../orpsocv2/sw/utils/bin2vmem @emph{youroutputfile.bin} -bpw=2 > \}
 
@kbd{.../orpsocv2/boards/xilinx/ml501/sim/run/cfi-flash.vmem}
 
@end example
 
 
 
The resulting VMEM file should consist of the program in 2-byte words  (the point of the @kbd{-bpw=2} switch.)
 
 
 
@subsubsection Run the simulation
 
 
 
As the software to be run is potentially not from ORPSoC's testsuite, and there's no way to override the name of the test being run in a way that allows things to compile correctly, simply run the following, and all results will be stored in the board's @kbd{sim/out} path prefixed with the name of the default test, @kbd{or1200-simple}.
 
 
 
@example
 
@kbd{make rtl-test}
 
@end example
 
 
 
The processor will now boot from @kbd{0xf0000100} and begin executing the image from the flash.
 
 
@node ML501 Synthesis
@node ML501 Synthesis
@section 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/xst/run} path with the following command.
Synthesis of the board port for the Actel technology with the Synplify tool can be run in the board's @code{syn/xst/run} path with the following command.
 
 
@example
@example
@kbd{make all}
@kbd{make all}
@end example
@end example
 
 
This will create an NGC file in @code{syn/xst/run} named @code{orpsoc.ngc}.
This will create an NGC file in @code{syn/xst/run} named @code{orpsoc.ngc}.
 
 
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.
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 ML501 Synthesis Options
@node ML501 Synthesis Options
@subsection Options
@subsection Options
 
 
Use the following command int the @code{syn/xst/run} path to get a list of the variables used during synthesis. Any can be set on the command line when running @code{make all}.
Use the following command int the @code{syn/xst/run} path to get a list of the variables used during synthesis. Any can be set on the command line when running @code{make all}.
 
 
@example
@example
@kbd{make print-config}
@kbd{make print-config}
@end example
@end example
 
 
 
 
@node ML501 Synthesis Warnings
@node ML501 Synthesis Warnings
@subsection Checks
@subsection Checks
 
 
The following is a list of some considerations before synthesis.
The following is a list of some considerations before synthesis.
 
 
@itemize @bullet
@itemize @bullet
@item bootrom.v
@item bootrom.v
 
 
If the bootROM module is being used to provide the processor with a program at startup (reset address in processor's define file is set to @code{0xf0000100} or similar), check that board software include file, in the board's @code{sw/board/include} path, is selecting the correct bootROM program.
If the bootROM module is being used to provide the processor with a program at startup (reset address in processor's define file is set to @code{0xf0000100} or similar), 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.
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
@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.
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.
 
 
 
 
 
 
@end itemize
@end itemize
 
 
@node ML501 Synthesised Netlist
@node ML501 Synthesised Netlist
@subsection Netlist generation
@subsection Netlist generation
 
 
To create a Verilog HDL netlist of the post-synthesis design, run the following in the board's @code{syn/xst/run} path.
To create a Verilog HDL netlist of the post-synthesis design, run the following in the board's @code{syn/xst/run} path.
 
 
@example
@example
@kbd{make orpsoc.v}
@kbd{make orpsoc.v}
@end example
@end example
 
 
@node ML501 Place and Route
@node ML501 Place and Route
@section Place and Route
@section Place and Route
 
 
Place and route of the design can be run from the board's @code{backend/par/run} path with the following command.
Place and route of the design can be run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make orpsoc.ncd}
@kbd{make orpsoc.ncd}
@end example
@end example
 
 
@node ML501 Timing Report
@node ML501 Timing Report
@section Post-PAR STA Report
@section Post-PAR STA Report
 
 
The @code{trce} tool can be used to generate a timing report of the post-place and route design.
The @code{trce} tool can be used to generate a timing report of the post-place and route design.
 
 
@example
@example
@kbd{make timingreport}
@kbd{make timingreport}
@end example
@end example
 
 
@node ML501 Back-annotated Netlist
@node ML501 Back-annotated Netlist
@section Back-annotated Netlist
@section Back-annotated Netlist
 
 
A post-PAR back-annotated netlist can be generated with the following command.
A post-PAR back-annotated netlist can be generated with the following command.
 
 
@example
@example
@kbd{make netlist}
@kbd{make netlist}
@end example
@end example
 
 
This will make a new directory under the board's @code{backend/par/run} path named @code{netlist} and will contain a Verilog netlist and SDF file with timing information.
This will make a new directory under the board's @code{backend/par/run} path named @code{netlist} and will contain a Verilog netlist and SDF file with timing information.
 
 
 
 
@node ML501 Place and route options
@node ML501 Place and route options
@subsection Options
@subsection Options
 
 
To get a list of options that can be set when running the backend flow, run the following in the board's @code{backend/par/run} path.
To get a list of options that can be set when running the backend flow, run the following in the board's @code{backend/par/run} path.
 
 
@example
@example
@kbd{make print-config}
@kbd{make print-config}
@end example
@end example
 
 
@node ML501 Constraints
@node ML501 Constraints
@subsection Constraints
@subsection Constraints
 
 
A Xilinx User Constraints File (UCF) file is in the board's @code{backend/par/bin} path. It is named @code{ml501.ucf}. It should be edited if any extra I/O or constraints are required.
A Xilinx User Constraints File (UCF) file is in the board's @code{backend/par/bin} path. It is named @code{ml501.ucf}. It should be edited if any extra I/O or constraints are required.
 
 
Eventually it would be good to dynamically generated this, based on what is included in the design, but for now this must be hand modified if modules are added ore removed from the design.
Eventually it would be good to dynamically generated this, based on what is included in the design, but for now this must be hand modified if modules are added ore removed from the design.
 
 
@node ML501 Programming File Generation
@node ML501 Programming File Generation
@section Programming File Generation
@section Programming File Generation
 
 
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make orpsoc.bit}
@kbd{make orpsoc.bit}
@end example
@end example
 
 
This file can then be loaded into the Xilinx iMPACT program and programmed onto the Virtex 5 part on the ML501.
This file can then be loaded into the Xilinx iMPACT program and programmed onto the Virtex 5 part on the ML501.
 
 
@node ML501 SPI programming file
@node ML501 SPI programming file
@subsection SPI programming file generation
@subsection SPI programming file generation
 
 
To generate a file, which can be programmed into the SPI flash on the board (and thus allowing the FPGA to be configured without using iMPACT each time) run the following command in the board's @code{backend/par/run} path.
To generate a file, which can be programmed into the SPI flash on the board (and thus allowing the FPGA to be configured without using iMPACT each time) run the following command in the board's @code{backend/par/run} path.
 
 
@example
@example
@kbd{make orpsoc.mcs}
@kbd{make orpsoc.mcs}
@end example
@end example
 
 
@node ML501 SPI programming file with software
@node ML501 SPI programming file with software
@subsection SPI programming file generation with software
@subsection SPI programming file generation with software
 
 
To generate a file, which can be programmed into the SPI flash on the board (and thus allowing the FPGA to be configured without using iMPACT each time) and also has a bootloader the processor can run (such as ORPmon) run the following command in the board's @code{backend/par/run} path.
To generate a file, which can be programmed into the SPI flash on the board (and thus allowing the FPGA to be configured without using iMPACT each time) and also has a bootloader the processor can run (such as ORPmon) run the following command in the board's @code{backend/par/run} path.
 
 
@example
@example
@kbd{make orpsoc.mcs BOOTLOADER_BIN=/path/to/bootloader-binary-file.bin}
@kbd{make orpsoc.mcs BOOTLOADER_BIN=/path/to/bootloader-binary-file.bin}
@end example
@end example
 
 
The image is allowed to be up to 256KBytes in size.
The image is allowed to be up to 256KBytes in size.
 
 
As the SPI flash on the ML501 is only 2MBytes in size, and the FPGA configuration image takes up almost 1.5MBytes, the final 256KBytes are reserved for a software image to be loaded at reset by the processor.
As the SPI flash on the ML501 is only 2MBytes in size, and the FPGA configuration image takes up almost 1.5MBytes, the final 256KBytes are reserved for a software image to be loaded at reset by the processor.
 
 
This mark (the last 256KBytes of memory) is at hex address @code{0x1c0000}. This value is passed to the @code{promgen} tool when creating the @code{.mcs} file, and is set in the board's @code{board.h} file so the embedded bootloader in the design knows which address to load from.
This mark (the last 256KBytes of memory) is at hex address @code{0x1c0000}. This value is passed to the @code{promgen} tool when creating the @code{.mcs} file, and is set in the board's @code{board.h} file so the embedded bootloader in the design knows which address to load from.
 
 
If changing the address of the bootloader, to accommodate a larger image for example, be sure to update the address in the @code{board.h} file and set the environment variable @code{SPI_BOOTLOADER_SW_OFFSET_HEX} to the hex address to embed the binary image at (hexadecimal value without the leading ``@code{0x}''.) Note that changing the address to load from in @code{board.h} will require the entire design is re synthesized.
If changing the address of the bootloader, to accommodate a larger image for example, be sure to update the address in the @code{board.h} file and set the environment variable @code{SPI_BOOTLOADER_SW_OFFSET_HEX} to the hex address to embed the binary image at (hexadecimal value without the leading ``@code{0x}''.) Note that changing the address to load from in @code{board.h} will require the entire design is re synthesized.
 
 
The file pointed to by @code{BOOTLOADER_BIN} should be a binary image with the  size of the image embedded in the first word.
The file pointed to by @code{BOOTLOADER_BIN} should be a binary image with the  size of the image embedded in the first word.
 
 
The tool @code{bin2binsizeword} in ORPSoC's @code{sw/utils} path can add the sizeword to a binary image. A binary image is something created with the processor toolchains @code{objcopy -O binary} option. A tool like ORPmon is a good candidate for being embedded in the SPI flash as bootloader software - a binary image is automatically created when it's compiled, usually named @code{orpmon.or32.bin}. To embed that, it would simply need to be passed to the @code{bin2binsizeword} like the following:
The tool @code{bin2binsizeword} in ORPSoC's @code{sw/utils} path can add the sizeword to a binary image. A binary image is something created with the processor toolchains @code{objcopy -O binary} option. A tool like ORPmon is a good candidate for being embedded in the SPI flash as bootloader software - a binary image is automatically created when it's compiled, usually named @code{orpmon.or32.bin}. To embed that, it would simply need to be passed to the @code{bin2binsizeword} like the following:
 
 
@example
@example
@kbd{bin2binsizeword /path/to/orpmon/orpmon.or32.bin orpmon-sizeword.bin}
@kbd{bin2binsizeword /path/to/orpmon/orpmon.or32.bin orpmon-sizeword.bin}
@end example
@end example
 
 
This @code{orpmon-sizeword.bin} file should then be passed via the BOOTLOADER_BIN option when creating the @code{.mcs} file to embed it.
This @code{orpmon-sizeword.bin} file should then be passed via the BOOTLOADER_BIN option when creating the @code{.mcs} file to embed it.
 
 
If once the FPGA configuration image, and a bootloader image is embedded in the SPI flash, the FPGA can be configured with ORPSoC and then the processor can load the bootloader (like ORPmon) with a single press of the board's @code{PROG} button. This makes developing on the board very easy.
If once the FPGA configuration image, and a bootloader image is embedded in the SPI flash, the FPGA can be configured with ORPSoC and then the processor can load the bootloader (like ORPmon) with a single press of the board's @code{PROG} button. This makes developing on the board very easy.
 
 
@node ML501 SPI flash programming
@node ML501 SPI flash programming
@subsection SPI flash programming
@subsection SPI flash programming
 
 
There are two ways to program the M25P16 2MByte SPI flash from the Xilinx iMPACT tool - @emph{direct} and @emph{indirect}. Direct programming means the Xilinx programmer has a direct connection from its pins to the SPI bus. It then performs SPI accesses on the bus to erase and program the part. Indirect programming involves the FPGA and sets up connections to the SPI via it. Indirect programming may be slower, but it is the only supported method as of ISE 12 onwards.
There are two ways to program the M25P16 2MByte SPI flash from the Xilinx iMPACT tool - @emph{direct} and @emph{indirect}. Direct programming means the Xilinx programmer has a direct connection from its pins to the SPI bus. It then performs SPI accesses on the bus to erase and program the part. Indirect programming involves the FPGA and sets up connections to the SPI via it. Indirect programming may be slower, but it is the only supported method as of ISE 12 onwards.
 
 
There may be a way of programming directly using the open source @emph{xc3sprog} tool, @uref{http://sourceforge.net/projects/xc3sprog/} , but the author is yet to figure out how, and would greatly appreciate anyone who can provide a quick rundown on how this could be achieved.
There may be a way of programming directly using the open source @emph{xc3sprog} tool, @uref{http://sourceforge.net/projects/xc3sprog/} , but the author is yet to figure out how, and would greatly appreciate anyone who can provide a quick rundown on how this could be achieved.
 
 
Once programmed, booting from the SPI flash to ORPmon prompt is about 3 to 4 seconds.
Once programmed, booting from the SPI flash to ORPmon prompt is about 3 to 4 seconds.
 
 
@node ML501 Direct SPI flash programming
@node ML501 Direct SPI flash programming
@subsubsection Direct SPI flash programming
@subsubsection Direct SPI flash programming
 
 
@emph{Note}: As of ISE 12, direct SPI flash programming is no longer supported. ISE 11 must be used if this method is to be used. Indirect SPI flash programming is the recommended method by Xilinx now. How annoying.
@emph{Note}: As of ISE 12, direct SPI flash programming is no longer supported. ISE 11 must be used if this method is to be used. Indirect SPI flash programming is the recommended method by Xilinx now. How annoying.
 
 
For a guide on how to actually set up the ML501 board to program the SPI flash, see the section under ``@emph{My Own SPI Flash Image Demonstration}'' on page 26 of the Xilinx UG228 document, @uref{http://www.xilinx.com/support/documentation/boards_and_kits/ug228.pdf} . Follow steps 1 to 4, and then 9 to 16, and supply the @code{.mcs} file generated here.
For a guide on how to actually set up the ML501 board to program the SPI flash, see the section under ``@emph{My Own SPI Flash Image Demonstration}'' on page 26 of the Xilinx UG228 document, @uref{http://www.xilinx.com/support/documentation/boards_and_kits/ug228.pdf} . Follow steps 1 to 4, and then 9 to 16, and supply the @code{.mcs} file generated here.
 
 
A more general explanation of direct SPI flash programming can be found in XAPP951- @uref{http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf}
A more general explanation of direct SPI flash programming can be found in XAPP951- @uref{http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf}
 
 
Be sure to set the @emph{CONFIG} switches to @code{00010101} (left-to-right when Xilinx logo in North-West of board) before attempting to program the SPI flash. The be sure to switch them back to @code{00000101} before attempting to boot the image.
Be sure to set the @emph{CONFIG} switches to @code{00010101} (left-to-right when Xilinx logo in North-West of board) before attempting to program the SPI flash. The be sure to switch them back to @code{00000101} before attempting to boot the image.
 
 
@emph{Note}: Direct SPI flash programming will require fly-leads from the Xilinx programming cable to the the board. See page 6 of XAPP1053 for a picture of this for a @emph{different} board, but to get the idea: @uref{http://www.xilinx.com/support/documentation/application_notes/xapp1053.pdf}.
@emph{Note}: Direct SPI flash programming will require fly-leads from the Xilinx programming cable to the the board. See page 6 of XAPP1053 for a picture of this for a @emph{different} board, but to get the idea: @uref{http://www.xilinx.com/support/documentation/application_notes/xapp1053.pdf}.
 
 
@emph{Note}: If leaving the SPI programming fly leads in place and attempting to boot the image, be sure to remove the @code{Vref} (@code{VCC3V3} on JP2) connection before attempting to boot. Be sure the configuration DIP SW15 is set back to the @code{00000101} position!
@emph{Note}: If leaving the SPI programming fly leads in place and attempting to boot the image, be sure to remove the @code{Vref} (@code{VCC3V3} on JP2) connection before attempting to boot. Be sure the configuration DIP SW15 is set back to the @code{00000101} position!
 
 
@emph{Note:} The other cable from the programmer (going to the JP1 header) @emph{must} be unplugged from the board before attempting to program the SPI flash.
@emph{Note:} The other cable from the programmer (going to the JP1 header) @emph{must} be unplugged from the board before attempting to program the SPI flash.
 
 
@node ML501 Inirect SPI flash programming
@node ML501 Inirect SPI flash programming
@subsubsection Indirect SPI flash programming
@subsubsection Indirect SPI flash programming
 
 
The indirect method of programming the SPI flash has the memory show up as an extrnal module off the FPGA when performing an automatic JTAG boundary scan.
The indirect method of programming the SPI flash has the memory show up as an extrnal module off the FPGA when performing an automatic JTAG boundary scan.
 
 
The following page has more information about the steps required. @uref{http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_p_configure_spi_bpi_through_fpga.htm} The @code{.mcs} file required is the one generated in previous steps in this guide.
The following page has more information about the steps required. @uref{http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pim_p_configure_spi_bpi_through_fpga.htm} The @code{.mcs} file required is the one generated in previous steps in this guide.
 
 
@emph{Note:} As we generate the @code{.mcs} file with bit/byte swapping disabled (with the use of the @code{-spi} option when running the promgen tool) we must disable iMPACT's automatic bit/byte swapping when programming the SPI flash. In ISE 12 this option is found by going to the @emph{Edit menu -> Preferences}, and  in the @emph{Configuration Preferences} category, set the @emph{SPI Byte Swap} option to @emph{Ignore Setting}.
@emph{Note:} As we generate the @code{.mcs} file with bit/byte swapping disabled (with the use of the @code{-spi} option when running the promgen tool) we must disable iMPACT's automatic bit/byte swapping when programming the SPI flash. In ISE 12 this option is found by going to the @emph{Edit menu -> Preferences}, and  in the @emph{Configuration Preferences} category, set the @emph{SPI Byte Swap} option to @emph{Ignore Setting}.
 
 
@emph{Note:} iMPACT from ISE 12 introduced errors in the software image when being programmed. It is advisable that versions of iMPACT from ISEs other than 12 are used until this bug is fixed.
@emph{Note:} iMPACT from ISE 12 introduced errors in the software image when being programmed. It is advisable that versions of iMPACT from ISEs other than 12 are used until this bug is fixed.
 
 
 
@node ML501 platform flash programming file
 
@subsection platform flash programming file generation
 
 
 
There are options in the backend makefile to generate programming files for the platform flash found on the ML501.
 
 
 
The following command will make the @code{orpsoc_platformflash.mcs} file which can be programmed into the flash via the iMPACT tool.
 
 
 
@example
 
@kbd{boards/xilinx/ml501/backend/par/run$ make orpsoc_platformflash.mcs}
 
@end example
 
 
 
This flash is designed to be loaded in the high-speed selectMAP mode, as it is formatted in such a way as it should be read out over a 16-bit data bus.
 
 
 
To program the platform flash, launch iMPACT, and initialise the scanchain.
 
 
 
Assign the orpsoc_platformflash.mcs file to the xcf32p part. @emph{Note:} I got a warning about the .mcs file not appearing to be a configuration file and that ``This file will not configure a Xilinx device in Serial or SelectMap modes and may not be intended for configuration.''
 
 
 
The option where the PROM is slave during programming was left enabled.
 
 
@node ML501 Customising
@node ML501 Customising
@section Customising
@section Customising
 
 
The large amount of peripherals on the ML501 means that things will want to be added or removed to suit the design.
The large amount of peripherals on the ML501 means that things will want to be added or removed to suit the design.
 
 
The following sections have information on how to configure the design.
The following sections have information on how to configure the design.
 
 
 
@node ML501 boot from flash configuration
 
@subsection Enabling Flash Boot Configuration
 
 
 
The following will outline how to make the OR1200 boot from the CFI flash part at reset.
 
 
 
In the board's @code{rtl/verilog/include/orpsoc-defines.v} ensure the following is uncommented:
 
 
 
@example
 
@kbd{`define CFI_FLASH}
 
@end example
 
 
 
In the board's @code{rtl/verilog/include/or1200_defines.v} ensure the following is uncommented:
 
 
 
@example
 
@kbd{`define OR1200_BOOT_PCREG_DEFAULT 30'h3c00003f}
 
@kbd{`define OR1200_BOOT_ADR 32'hf0000100}
 
@end example
 
 
 
All other @code{OR1200_BOOT_*} defines nearby should be commented out.
 
 
 
This will ensure that (1) the CFI flash controller is enabled, and (2) the OR1200 will go straight to its reset vector in the flash memory at reset. Note that this will completely bypass the bootrom (at @code{0xe0000000}) so its configuration now is meaningless. This is on purpose, as any init code can and should be handled by software in the flash (such as u-boot.)
 
 
@node ML501 Customising Enabling Existing Modules
@node ML501 Customising Enabling Existing Modules
@subsection Enabling Existing RTL Modules
@subsection Enabling Existing RTL Modules
 
 
The design relies on the Verilog HDL @emph{define} function to indicate which modules are included. See the board's @code{rtl/verilog/include/orpsoc-defines.v} file to determine which options are enabled by uncommented @code{`define} values.
The design relies on the Verilog HDL @emph{define} function to indicate which modules are included. See the board's @code{rtl/verilog/include/orpsoc-defines.v} file to determine which options are enabled by uncommented @code{`define} values.
 
 
These @code{`defines} will correspond to defines in the board's top level RTL file @code{boardpath/rtl/verilog/orpsoc_top/orpsoc_top.v}.
These @code{`defines} will correspond to defines in the board's top level RTL file @code{boardpath/rtl/verilog/orpsoc_top/orpsoc_top.v}.
 
 
There are only a few modules included by default.
There are only a few modules included by default.
 
 
@itemize @bullet
@itemize @bullet
@item Processor - @emph{or1200}
@item Processor - @emph{or1200}
@item Clock and reset generation - @emph{clkgen}
@item Clock and reset generation - @emph{clkgen}
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
@end itemize
@end itemize
 
 
The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.
The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.
 
 
@node ML501 Customising Adding Modules
@node ML501 Customising Adding Modules
@subsection Adding RTL Modules
@subsection Adding RTL Modules
 
 
There are a number of steps to take when adding a new module to the design.
There are a number of steps to take when adding a new module to the design.
 
 
@itemize @bullet
@itemize @bullet
@item RTL Files
@item RTL Files
 
 
@itemize @bullet
@itemize @bullet
@item Create a directory under the board's @code{rtl/verilog} directory, and name it the same as the top level of the module.
@item Create a directory under the board's @code{rtl/verilog} directory, and name it the same as the top level of the module.
 
 
@emph{or}
@emph{or}
 
 
Create a directory under the board's @code{modules} directory, containing a @code{rtl/verilog} directory, and name it the same as the top level of the module
Create a directory under the board's @code{modules} directory, containing a @code{rtl/verilog} directory, and name it the same as the top level of the module
 
 
@item Ensure the module's top level file and actual name of the module when it will be instantiated are @emph{all the same}.
@item Ensure the module's top level file and actual name of the module when it will be instantiated are @emph{all the same}.
 
 
@item Place any include files into the board's @code{rtl/verilog/include} path.
@item Place any include files into the board's @code{rtl/verilog/include} path.
@end itemize
@end itemize
@item Instantiate in ORPSoC Top Level File
@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.
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
@itemize @bullet
@item Create appropriate @emph{`define} in @code{orpsoc-defines.v} and surround module instantiation with it.
@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 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.
@item Attach to appropriate bus arbiter, declaring any signals required. Be sure to tie them off if modules is not included.
@item Update appropriate bus arbiter (in board's @code{rtl/verilog/arbiters} path) adding (uncommenting) additional ports as needed.
@item Update appropriate bus arbiter (in board's @code{rtl/verilog/arbiters} path) adding (uncommenting) additional ports as needed.
@item Update board's @code{rtl/verilog/include/orpsoc-params.v} file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.
@item Update board's @code{rtl/verilog/include/orpsoc-params.v} file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.
@item Attach appropriate clocks and resets, modify the board's @code{rtl/verilog/clkgen/clkgen.v} file generating appropriate clocks if required.
@item Attach appropriate clocks and resets, modify the board's @code{rtl/verilog/clkgen/clkgen.v} file generating appropriate clocks if required.
@item Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.
@item Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.
@end itemize
@end itemize
 
 
@item Update ORPSoC Testbench
@item Update ORPSoC Testbench
 
 
Update the board's @code{bench/verilog/orpsoc_testbench.v} file with appropriate ports (surrounded by appropriate @emph{`ifdef}.)
Update the board's @code{bench/verilog/orpsoc_testbench.v} file with appropriate ports (surrounded by appropriate @emph{`ifdef}.)
 
 
Add any desired models to help test the module to the board's @code{bench/verilog} path and instantiate it correctly in the testbench.
Add any desired models to help test the module to the board's @code{bench/verilog} path and instantiate it correctly in the testbench.
 
 
@item Add Software Drivers and Tests
@item Add Software Drivers and Tests
 
 
In a similar fashion to what is already in the board's @code{sw/drivers} and @code{sw/tests} path, create desired driver and test software to be used during simulation (and potentially on target.)
In a similar fashion to what is already in the board's @code{sw/drivers} and @code{sw/tests} path, create desired driver and test software to be used during simulation (and potentially on target.)
 
 
@item Update Backend Scripts
@item Update Backend Scripts
 
 
If any I/O is added, or special timing specified, the board's UCF file will need updating - see @code{boardpath/backend/par/bin/ml501.ucf}.
If any I/O is added, or special timing specified, the board's UCF file will need updating - see @code{boardpath/backend/par/bin/ml501.ucf}.
 
 
@end itemize
@end itemize
 
 
@node ML501 Running And Debugging Software
@node ML501 Running And Debugging Software
@section Running And Debugging Software
@section Running And Debugging Software
 
 
@node ML501 Debug Interface
@node ML501 Debug Interface
@subsection Debug Interface
@subsection Debug Interface
 
 
The debug interface uses a separate JTAG tap and some fly-leads must be connected from an @emph{ORSoC USB debugger} (@uref{http://opencores.com/shop,item,3}) to the ML501.
The debug interface uses a separate JTAG tap and some fly-leads must be connected from an @emph{ORSoC USB debugger} (@uref{http://opencores.com/shop,item,3}) to the ML501.
 
 
From the USB debugger, a fly lead must take the following signals to the following pins on header J4 on the ML501.
From the USB debugger, a fly lead must take the following signals to the following pins on header J4 on the ML501.
 
 
@itemize @bullet
@itemize @bullet
@item
@item
tdo - HDR2_6
tdo - HDR2_6
@item
@item
tdi - HDR2_8
tdi - HDR2_8
@item
@item
tms - HDR2_10
tms - HDR2_10
@item
@item
tck - HDR2_12
tck - HDR2_12
@end itemize
@end itemize
 
 
This corresponds to right-most column of pins on the J4 header, starting on the third row going down.
This corresponds to right-most column of pins on the J4 header, starting on the third row going down.
 
 
Supply and ground pins must also be hooked up for the USB debugger.
Supply and ground pins must also be hooked up for the USB debugger.
 
 
The left column of pins on J4 are all tied to ground. All pins on J7 (expansion header located adjacent to J4) are all tied to VCC2V5, 2.5V DC, and this is OK for supplying the buffers on the USB debug cable, and can be used. So essentially put the supply leads anywhere on J7 and ground leads anywhere on the left column of J4.
The left column of pins on J4 are all tied to ground. All pins on J7 (expansion header located adjacent to J4) are all tied to VCC2V5, 2.5V DC, and this is OK for supplying the buffers on the USB debug cable, and can be used. So essentially put the supply leads anywhere on J7 and ground leads anywhere on the left column of J4.
 
 
Once the debug interface is connected, the @code{or_debug_proxy} application can be used to provide a stub for GDB to connect to. See @uref{http://opencores.org/openrisc,debugging_physical} for more information.
Once the debug interface is connected, the @code{or_debug_proxy} application can be used to provide a stub for GDB to connect to. See @uref{http://opencores.org/openrisc,debugging_physical} for more information.
 
 
@node ML501 UART
@node ML501 UART
@subsection UART
@subsection UART
 
 
There are 2 ways of connecting to the UART in the design.
There are 2 ways of connecting to the UART in the design.
 
 
One is via the usual serial port connector, P3, on the ML501. This will obviously require a PC with a serial input and appropriate terminal application.
One is via the usual serial port connector, P3, on the ML501. This will obviously require a PC with a serial input and appropriate terminal application.
 
 
There is also a connection available via the USB debugger mentioned in the previous subsection.
There is also a connection available via the USB debugger mentioned in the previous subsection.
 
 
The following pins are used for RX/TX to/from the design on header J4.
The following pins are used for RX/TX to/from the design on header J4.
 
 
@itemize @bullet
@itemize @bullet
@item
@item
UART RX - HDR2_2
UART RX - HDR2_2
@item
@item
UART TX - HDR2_4
UART TX - HDR2_4
@end itemize
@end itemize
 
 
Again, supply and ground leads for the UART drivers on the USB debugger can be sourced from J7/left-column J4 as per the debug interface subsection.
Again, supply and ground leads for the UART drivers on the USB debugger can be sourced from J7/left-column J4 as per the debug interface subsection.
 
 
If both UART and debug interface are connected via the ORSoC USB debugger, this ultimately ends up with the first 2 pins on the right column of J4 as RX/TX for the UART then the JTAG TDO, TDI, TMS and TCK in succession down the right column of J4.
If both UART and debug interface are connected via the ORSoC USB debugger, this ultimately ends up with the first 2 pins on the right column of J4 as RX/TX for the UART then the JTAG TDO, TDI, TMS and TCK in succession down the right column of J4.
 
 
See the ML501 schematic (@uref{http://www.xilinx.com/support/documentation/boards_and_kits/ml501_20061010_bw.pdf}) for more details on these headers, and refer to the pinouts in the ML501 UCF, in the board's @code{backend/par/bin/ml501.ucf} file.
See the ML501 schematic (@uref{http://www.xilinx.com/support/documentation/boards_and_kits/ml501_20061010_bw.pdf}) for more details on these headers, and refer to the pinouts in the ML501 UCF, in the board's @code{backend/par/bin/ml501.ucf} file.
 
 
 
 
 
 
@c ****************************************************************************
@c ****************************************************************************
@c S3ADSP1800 board build chapter
@c S3ADSP1800 board build chapter
@c ****************************************************************************
@c ****************************************************************************
 
 
@node S3ADSP1800
@node S3ADSP1800
@chapter S3ADSP1800
@chapter S3ADSP1800
@cindex S3ADSP1800 board build information
@cindex S3ADSP1800 board build information
 
 
@menu
@menu
* Overview::
* Overview::
* Structure::
* Structure::
* Tools::
* Tools::
* Simulating::
* Simulating::
* Synthesis and Backend::
* Synthesis and Backend::
* Programming File Generation::
* Programming File Generation::
* Customising::
* Customising::
* Running And Debugging Software::
* Running And Debugging Software::
@end menu
@end menu
 
 
@node S3ADSP1800 Overview
@node S3ADSP1800 Overview
@section Overview
@section Overview
 
 
The Xilinx XtremeDSP Starter Platform - Spartan-3A DSP 1800A Edition is known as the s3adsp1800 board in ORPSoC.
The Xilinx XtremeDSP Starter Platform - Spartan-3A DSP 1800A Edition is known as the s3adsp1800 board in ORPSoC.
 
 
All information and resources relating to the board were sourced from Xilinx's board portal page:
All information and resources relating to the board were sourced from Xilinx's board portal page:
 
 
@uref{http://www.xilinx.com/products/boards-and-kits/HW-SD1800A-DSP-SB-UNI-G.htm}
@uref{http://www.xilinx.com/products/boards-and-kits/HW-SD1800A-DSP-SB-UNI-G.htm}
 
 
The build currently contains the bare essentials to get the board up and running some software on the OpenRISC processor.
The build currently contains the bare essentials to get the board up and running some software on the OpenRISC processor.
 
 
The system, at present contains the OpenRISC SoC system running at 25MHz with OR1200, Wishbone B3 arbiters, a Xilinx DDR2 memory controller (125MHz) with Wishbone wrapper and the OpenCores 10/100 Ethernet MAC. Debug capabilities are available via a ORSoC USB debug cable connected to pins on header J8.
The system, at present contains the OpenRISC SoC system running at 25MHz with OR1200, Wishbone B3 arbiters, a Xilinx DDR2 memory controller (125MHz) with Wishbone wrapper and the OpenCores 10/100 Ethernet MAC. Debug capabilities are available via a ORSoC USB debug cable connected to pins on header J8.
 
 
The S3ADSP1800 build's scripts are capable of generating a programming bitstream, @code{.bit}, file for direct programming of the FPGA via JTAG.
The S3ADSP1800 build's scripts are capable of generating a programming bitstream, @code{.bit}, file for direct programming of the FPGA via JTAG.
 
 
@node S3ADSP1800 Structure
@node S3ADSP1800 Structure
@section 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/xilinx/s3adsp1800}.
Note that in this chapter the term @emph{board path} refers to the path in the project for this board port; @code{boards/xilinx/s3adsp1800}.
 
 
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 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.
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, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
Backend files, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
 
 
@node S3ADSP1800 Xilinx Environment Setup
@node S3ADSP1800 Xilinx Environment Setup
@subsection S3ADSP1800 Xilinx Environment Setup
@subsection S3ADSP1800 Xilinx Environment Setup
 
 
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
 
 
@node S3ADSP1800 Tools
@node S3ADSP1800 Tools
@section Tools
@section Tools
 
 
@menu
@menu
* Host Tools::
* Host Tools::
* Target System Tools::
* Target System Tools::
* EDA Tools::
* EDA Tools::
* Debug Tools::
* Debug Tools::
@end menu
@end menu
 
 
@node S3ADSP1800 Host Tools
@node S3ADSP1800 Host Tools
@subsection Host Tools
@subsection Host Tools
@cindex host tools required S3ADSP1800
@cindex host tools required S3ADSP1800
 
 
Standard development suite of tools: gcc, make, etc.
Standard development suite of tools: gcc, make, etc.
 
 
@node S3ADSP1800 Target System Tools
@node S3ADSP1800 Target System Tools
@subsection Target System Tools
@subsection Target System Tools
@cindex target system tools required S3ADSP1800
@cindex target system tools required S3ADSP1800
 
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
 
@node S3ADSP1800 EDA Tools
@node S3ADSP1800 EDA Tools
@subsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required S3ADSP1800
@cindex EDA tools required S3ADSP1800
 
 
RTL, gatelevel simulation: Mentor Graphics' Modelsim
RTL, gatelevel simulation: Mentor Graphics' Modelsim
Synthesis: XST (from Xilinx ISE)
Synthesis: XST (from Xilinx ISE)
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
Programming: iMPACT (from Xilinx ISE)
Programming: iMPACT (from Xilinx ISE)
 
 
This has been tested with Xilinx ISE 13.1 under Ubuntu 11.04.
This has been tested with Xilinx ISE 13.1 under Ubuntu 11.04.
 
 
 
 
@node S3ADSP1800 Debug Tools
@node S3ADSP1800 Debug Tools
@subsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required S3ADSP1800
@cindex Debug tools required S3ADSP1800
 
 
or_debug_proxy
or_debug_proxy
 
 
@node S3ADSP1800 Simulating
@node S3ADSP1800 Simulating
@section Simulating
@section Simulating
@cindex simulating S3ADSP1800
@cindex simulating S3ADSP1800
 
 
Note that if this path is not set, simulations will not compile.
Note that if this path is not set, simulations will not compile.
 
 
@subheading Run RTL Regression Test
@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.
To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.
 
 
@example
@example
@kbd{make rtl-tests}
@kbd{make rtl-tests}
@end example
@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}.
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}.
 
 
Note that no OpenCores 10/100 Ethernet MAC (``ethmac'') tests will function correctly for the time being.
Note that no OpenCores 10/100 Ethernet MAC (``ethmac'') tests will function correctly for the time being.
 
 
Options specific to the S3ADSP1800 build.
Options specific to the S3ADSP1800 build.
 
 
@table @code
@table @code
 
 
@item PRELOAD_RAM
@item PRELOAD_RAM
Set to '1' to enable loading of the software image into RAM at the beginning of simulation.
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.
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
@end table
 
 
 
 
 
 
@node S3ADSP1800 Synthesis
@node S3ADSP1800 Synthesis
@section 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/xst/run} path with the following command.
Synthesis of the board port for the Actel technology with the Synplify tool can be run in the board's @code{syn/xst/run} path with the following command.
 
 
@example
@example
@kbd{make all}
@kbd{make all}
@end example
@end example
 
 
This will create an NGC file in @code{syn/xst/run} named @code{orpsoc.ngc}.
This will create an NGC file in @code{syn/xst/run} named @code{orpsoc.ngc}.
 
 
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.
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 S3ADSP1800 Synthesis Options
@node S3ADSP1800 Synthesis Options
@subsection Options
@subsection Options
 
 
Use the following command int the @code{syn/xst/run} path to get a list of the variables used during synthesis. Any can be set on the command line when running @code{make all}.
Use the following command int the @code{syn/xst/run} path to get a list of the variables used during synthesis. Any can be set on the command line when running @code{make all}.
 
 
@example
@example
@kbd{make print-config}
@kbd{make print-config}
@end example
@end example
 
 
 
 
@node S3ADSP1800 Synthesis Warnings
@node S3ADSP1800 Synthesis Warnings
@subsection Checks
@subsection Checks
 
 
The following is a list of some considerations before synthesis.
The following is a list of some considerations before synthesis.
 
 
@itemize @bullet
@itemize @bullet
@item bootrom.v
@item bootrom.v
 
 
If the bootROM module is being used to provide the processor with a program at startup (reset address in processor's define file is set to @code{0xf0000100} or similar), check that board software include file, in the board's @code{sw/board/include} path, is selecting the correct bootROM program.
If the bootROM module is being used to provide the processor with a program at startup (reset address in processor's define file is set to @code{0xf0000100} or similar), 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.
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
@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.
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.
 
 
 
 
 
 
@end itemize
@end itemize
 
 
@node S3ADSP1800 Synthesised Netlist
@node S3ADSP1800 Synthesised Netlist
@subsection Netlist generation
@subsection Netlist generation
 
 
To create a Verilog HDL netlist of the post-synthesis design, run the following in the board's @code{syn/xst/run} path.
To create a Verilog HDL netlist of the post-synthesis design, run the following in the board's @code{syn/xst/run} path.
 
 
@example
@example
@kbd{make orpsoc.v}
@kbd{make orpsoc.v}
@end example
@end example
 
 
@node S3ADSP1800 Place and Route
@node S3ADSP1800 Place and Route
@section Place and Route
@section Place and Route
 
 
Place and route of the design can be run from the board's @code{backend/par/run} path with the following command.
Place and route of the design can be run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make orpsoc.ncd}
@kbd{make orpsoc.ncd}
@end example
@end example
 
 
@node S3ADSP1800 Timing Report
@node S3ADSP1800 Timing Report
@section Post-PAR STA Report
@section Post-PAR STA Report
 
 
The @code{trce} tool can be used to generate a timing report of the post-place and route design.
The @code{trce} tool can be used to generate a timing report of the post-place and route design.
 
 
@example
@example
@kbd{make timingreport}
@kbd{make timingreport}
@end example
@end example
 
 
@node S3ADSP1800 Back-annotated Netlist
@node S3ADSP1800 Back-annotated Netlist
@section Back-annotated Netlist
@section Back-annotated Netlist
 
 
A post-PAR back-annotated netlist can be generated with the following command.
A post-PAR back-annotated netlist can be generated with the following command.
 
 
@example
@example
@kbd{make netlist}
@kbd{make netlist}
@end example
@end example
 
 
This will make a new directory under the board's @code{backend/par/run} path named @code{netlist} and will contain a Verilog netlist and SDF file with timing information.
This will make a new directory under the board's @code{backend/par/run} path named @code{netlist} and will contain a Verilog netlist and SDF file with timing information.
 
 
 
 
@node S3ADSP1800 Place and route options
@node S3ADSP1800 Place and route options
@subsection Options
@subsection Options
 
 
To get a list of options that can be set when running the backend flow, run the following in the board's @code{backend/par/run} path.
To get a list of options that can be set when running the backend flow, run the following in the board's @code{backend/par/run} path.
 
 
@example
@example
@kbd{make print-config}
@kbd{make print-config}
@end example
@end example
 
 
@node S3ADSP1800 Constraints
@node S3ADSP1800 Constraints
@subsection Constraints
@subsection Constraints
 
 
A Xilinx User Constraints File (UCF) file is in the board's @code{backend/par/bin} path. It is named @code{s3adsp1800.ucf}. It should be edited if any extra I/O or constraints are required.
A Xilinx User Constraints File (UCF) file is in the board's @code{backend/par/bin} path. It is named @code{s3adsp1800.ucf}. It should be edited if any extra I/O or constraints are required.
 
 
Note that if modules are enabled or disabled via their @code{`define} line in @code{orpsoc-defines.v} and they have I/O declared, then this I/O will need to be manually commented out of the UCF to avoid errors during mapping.
Note that if modules are enabled or disabled via their @code{`define} line in @code{orpsoc-defines.v} and they have I/O declared, then this I/O will need to be manually commented out of the UCF to avoid errors during mapping.
 
 
@node S3ADSP1800 Programming File Generation
@node S3ADSP1800 Programming File Generation
@section Programming File Generation
@section Programming File Generation
 
 
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make orpsoc.bit}
@kbd{make orpsoc.bit}
@end example
@end example
 
 
This file can then be loaded into the Xilinx iMPACT program and programmed onto the Spartan-3A part on the S3ADSP1800.
This file can then be loaded into the Xilinx iMPACT program and programmed onto the Spartan-3A part on the S3ADSP1800.
 
 
 
 
@node S3ADSP1800 SPI flash programming
@node S3ADSP1800 SPI flash programming
@subsection SPI flash programming
@subsection SPI flash programming
 
 
Unfortunately, it is particularly inconvient to program the flash memory that the FPGA can configure itself with at power-on.
Unfortunately, it is particularly inconvient to program the flash memory that the FPGA can configure itself with at power-on.
 
 
The iMPACT tool does not contain the appropriate facility to enable this, and a Windows-only tool provided from Avnet.
The iMPACT tool does not contain the appropriate facility to enable this, and a Windows-only tool provided from Avnet.
 
 
See Avnet's page on this board. @uref{http://www.em.avnet.com/spartan3a-dsp} and follow the links to ``Support Files & Downloads'' and the file named ``Programming the Intel S33 Flash'' is the guide. The following link may directly work to download the files: @uref{http://tinyurl.com/63k8r5c}
See Avnet's page on this board. @uref{http://www.em.avnet.com/spartan3a-dsp} and follow the links to ``Support Files & Downloads'' and the file named ``Programming the Intel S33 Flash'' is the guide. The following link may directly work to download the files: @uref{http://tinyurl.com/63k8r5c}
 
 
Another way is to load on a Microblaze design and somehow program the flash via the Xilinx GUI tool. This method will not be covered here. The XAPP number of the user guide to do this escapes me right now, but I'm pretty sure you don't want to have to do that.
Another way is to load on a Microblaze design and somehow program the flash via the Xilinx GUI tool. This method will not be covered here. The XAPP number of the user guide to do this escapes me right now, but I'm pretty sure you don't want to have to do that.
 
 
Potentially this flash could be programmed via the SPI core in this board build. This would result in having to flash the FPGA with the s3adsp18000 build image via JTAG first, before downloading SPI programming software with the FPGA configuration embedded in it, to be programmed into the SPI flash. This would probably be easy enough to do but the author did not have enough time to experiment it at the time of writing. Patches to this file's texinfo source describing how this could be done would be greatly appreciated.
Potentially this flash could be programmed via the SPI core in this board build. This would result in having to flash the FPGA with the s3adsp18000 build image via JTAG first, before downloading SPI programming software with the FPGA configuration embedded in it, to be programmed into the SPI flash. This would probably be easy enough to do but the author did not have enough time to experiment it at the time of writing. Patches to this file's texinfo source describing how this could be done would be greatly appreciated.
 
 
@node S3ADSP1800 Customising
@node S3ADSP1800 Customising
@section Customising
@section Customising
 
 
The large amount of peripherals on the S3ADSP1800 means that things will want to be added or removed to suit the design.
The large amount of peripherals on the S3ADSP1800 means that things will want to be added or removed to suit the design.
 
 
The following sections have information on how to configure the design.
The following sections have information on how to configure the design.
 
 
@node S3ADSP1800 Customising Enabling Existing Modules
@node S3ADSP1800 Customising Enabling Existing Modules
@subsection Enabling Existing RTL Modules
@subsection Enabling Existing RTL Modules
 
 
The design relies on the Verilog HDL @emph{define} function to indicate which modules are included. See the board's @code{rtl/verilog/include/orpsoc-defines.v} file to determine which options are enabled by uncommented @code{`define} values.
The design relies on the Verilog HDL @emph{define} function to indicate which modules are included. See the board's @code{rtl/verilog/include/orpsoc-defines.v} file to determine which options are enabled by uncommented @code{`define} values.
 
 
These @code{`defines} will correspond to defines in the board's top level RTL file @code{boardpath/rtl/verilog/orpsoc_top/orpsoc_top.v}.
These @code{`defines} will correspond to defines in the board's top level RTL file @code{boardpath/rtl/verilog/orpsoc_top/orpsoc_top.v}.
 
 
There are only a few modules included by default.
There are only a few modules included by default.
 
 
@itemize @bullet
@itemize @bullet
@item Processor - @emph{or1200}
@item Processor - @emph{or1200}
@item Clock and reset generation - @emph{clkgen}
@item Clock and reset generation - @emph{clkgen}
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
@end itemize
@end itemize
 
 
The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.
The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.
 
 
@node S3ADSP1800 Customising Adding Modules
@node S3ADSP1800 Customising Adding Modules
@subsection Adding RTL Modules
@subsection Adding RTL Modules
 
 
There are a number of steps to take when adding a new module to the design.
There are a number of steps to take when adding a new module to the design.
 
 
@itemize @bullet
@itemize @bullet
@item RTL Files
@item RTL Files
 
 
@itemize @bullet
@itemize @bullet
@item Create a directory under the board's @code{rtl/verilog} directory, and name it the same as the top level of the module.
@item Create a directory under the board's @code{rtl/verilog} directory, and name it the same as the top level of the module.
 
 
@emph{or}
@emph{or}
 
 
Create a directory under the board's @code{modules} directory, containing a @code{rtl/verilog} directory, and name it the same as the top level of the module
Create a directory under the board's @code{modules} directory, containing a @code{rtl/verilog} directory, and name it the same as the top level of the module
 
 
@item Ensure the module's top level file and actual name of the module when it will be instantiated are @emph{all the same}.
@item Ensure the module's top level file and actual name of the module when it will be instantiated are @emph{all the same}.
 
 
@item Place any include files into the board's @code{rtl/verilog/include} path.
@item Place any include files into the board's @code{rtl/verilog/include} path.
@end itemize
@end itemize
@item Instantiate in ORPSoC Top Level File
@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.
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
@itemize @bullet
@item Create appropriate @emph{`define} in @code{orpsoc-defines.v} and surround module instantiation with it.
@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 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.
@item Attach to appropriate bus arbiter, declaring any signals required. Be sure to tie them off if modules is not included.
@item Update appropriate bus arbiter (in board's @code{rtl/verilog/arbiters} path) adding (uncommenting) additional ports as needed.
@item Update appropriate bus arbiter (in board's @code{rtl/verilog/arbiters} path) adding (uncommenting) additional ports as needed.
@item Update board's @code{rtl/verilog/include/orpsoc-params.v} file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.
@item Update board's @code{rtl/verilog/include/orpsoc-params.v} file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.
@item Attach appropriate clocks and resets, modify the board's @code{rtl/verilog/clkgen/clkgen.v} file generating appropriate clocks if required.
@item Attach appropriate clocks and resets, modify the board's @code{rtl/verilog/clkgen/clkgen.v} file generating appropriate clocks if required.
@item Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.
@item Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.
@end itemize
@end itemize
 
 
@item Update ORPSoC Testbench
@item Update ORPSoC Testbench
 
 
Update the board's @code{bench/verilog/orpsoc_testbench.v} file with appropriate ports (surrounded by appropriate @emph{`ifdef}.)
Update the board's @code{bench/verilog/orpsoc_testbench.v} file with appropriate ports (surrounded by appropriate @emph{`ifdef}.)
 
 
Add any desired models to help test the module to the board's @code{bench/verilog} path and instantiate it correctly in the testbench.
Add any desired models to help test the module to the board's @code{bench/verilog} path and instantiate it correctly in the testbench.
 
 
@item Add Software Drivers and Tests
@item Add Software Drivers and Tests
 
 
In a similar fashion to what is already in the board's @code{sw/drivers} and @code{sw/tests} path, create desired driver and test software to be used during simulation (and potentially on target.)
In a similar fashion to what is already in the board's @code{sw/drivers} and @code{sw/tests} path, create desired driver and test software to be used during simulation (and potentially on target.)
 
 
@item Update Backend Scripts
@item Update Backend Scripts
 
 
If any I/O is added, or special timing specified, the board's UCF file will need updating - see @code{backend/par/bin/s3adsp1800.ucf}.
If any I/O is added, or special timing specified, the board's UCF file will need updating - see @code{backend/par/bin/s3adsp1800.ucf}.
 
 
@end itemize
@end itemize
 
 
@node S3ADSP1800 Running And Debugging Software
@node S3ADSP1800 Running And Debugging Software
@section Running And Debugging Software
@section Running And Debugging Software
 
 
This section indicates how to connect a USB JTAG debugger to the board to control the system. At present this setup has only been tested with the ft2232-based ORSoC USB debugger  (@uref{http://opencores.com/shop,item,3}).
This section indicates how to connect a USB JTAG debugger to the board to control the system. At present this setup has only been tested with the ft2232-based ORSoC USB debugger  (@uref{http://opencores.com/shop,item,3}).
 
 
 
 
See the USB debugger documentation and schematics on orsoc.se: @uref{http://orsoc.se/usb-jtag-debugger/}
See the USB debugger documentation and schematics on orsoc.se: @uref{http://orsoc.se/usb-jtag-debugger/}
 
 
Find more information about the Spartan 3 board (schematics, user guide, etc.) on the Xilinx site: @uref{http://www.xilinx.com/support/documentation/spartan-3a_dsp_board_and_kit_documentation.htm}
Find more information about the Spartan 3 board (schematics, user guide, etc.) on the Xilinx site: @uref{http://www.xilinx.com/support/documentation/spartan-3a_dsp_board_and_kit_documentation.htm}
 
 
@node S3ADSP1800 Debug Interface
@node S3ADSP1800 Debug Interface
@subsection Debug Interface
@subsection Debug Interface
 
 
The debug interface uses a separate JTAG tap and some fly-leads must be connected from an @emph{ORSoC USB debugger} to J8 on the S3ADSP1800.
The debug interface uses a separate JTAG tap and some fly-leads must be connected from an @emph{ORSoC USB debugger} to J8 on the S3ADSP1800.
 
 
From the USB debugger, a fly lead must take the following signals to the following pins on header J8 on the S3ADSP1800.
From the USB debugger, a fly lead must take the following signals to the following pins on header J8 on the S3ADSP1800.
 
 
@itemize @bullet
@itemize @bullet
@item
@item
tdo - D0
tdo - D0
@item
@item
tdi - D1
tdi - D1
@item
@item
tms - D2
tms - D2
@item
@item
tck - D3
tck - D3
@end itemize
@end itemize
 
 
Supply and ground pins must also be hooked up for the USB debugger. They can also be found on the J8 header (either V2.5 or V3.3 should work for VCC.)
Supply and ground pins must also be hooked up for the USB debugger. They can also be found on the J8 header (either V2.5 or V3.3 should work for VCC.)
 
 
Once the debug interface is connected, the @code{or_debug_proxy} application can be used to provide a stub for GDB to connect to. See @uref{http://opencores.org/openrisc,debugging_physical} for more information.
Once the debug interface is connected, the @code{or_debug_proxy} application can be used to provide a stub for GDB to connect to. See @uref{http://opencores.org/openrisc,debugging_physical} for more information.
 
 
@node S3ADSP1800 UART
@node S3ADSP1800 UART
@subsection UART
@subsection UART
 
 
There are 2 ways of connecting to the UART in the design.
There are 2 ways of connecting to the UART in the design.
 
 
One is via the DB89 connector, P2. This will obviously require a PC with a serial input and appropriate terminal application.
One is via the DB89 connector, P2. This will obviously require a PC with a serial input and appropriate terminal application.
 
 
There is also a connection available via the USB debugger mentioned in the previous subsection.
There is also a connection available via the USB debugger mentioned in the previous subsection.
 
 
The following pins on the J8 are connected to the same UART core as goes to the P2 connector. The two UART RX lines are logically ``AND''ed internally.
The following pins on the J8 are connected to the same UART core as goes to the P2 connector. The two UART RX lines are logically ``AND''ed internally.
 
 
@itemize @bullet
@itemize @bullet
@item
@item
UART RX - D4
UART RX - D4
@item
@item
UART TX - D5
UART TX - D5
@end itemize
@end itemize
 
 
Again, supply and ground leads for the UART drivers on the USB debugger can be sourced from J8.
Again, supply and ground leads for the UART drivers on the USB debugger can be sourced from J8.
 
 
@c ****************************************************************************
@c ****************************************************************************
@c Atlys board build chapter
@c Atlys board build chapter
@c ****************************************************************************
@c ****************************************************************************
 
 
@node Atlys
@node Atlys
@chapter Atlys
@chapter Atlys
@cindex Atlys board build information
@cindex Atlys board build information
 
 
@menu
@menu
* Overview::
* Overview::
* Structure::
* Structure::
* Tools::
* Tools::
* Simulating::
* Simulating::
* Synthesis and Backend::
* Synthesis and Backend::
* Programming File Generation::
* Programming File Generation::
@end menu
@end menu
 
 
@node Atlys Overview
@node Atlys Overview
@section Overview
@section Overview
 
 
The Atlys board is from Digilent and contains a Spartan 6 device.
The Atlys board is from Digilent and contains a Spartan 6 device.
 
 
More informatino can be found on the manufacturer's website: @uref{http://www.digilentinc.com/atlys/}
More informatino can be found on the manufacturer's website: @uref{http://www.digilentinc.com/atlys/}
 
 
Note that this board port is based on the ML501 and structure and use are very similar.
Note that this board port is based on the ML501 and structure and use are very similar.
 
 
@node Atlys Structure
@node Atlys Structure
@section 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/xilinx/atlys}.
Note that in this chapter the term @emph{board path} refers to the path in the project for this board port; @code{boards/xilinx/atlys}.
 
 
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 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.
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, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
Backend files, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
 
 
@node Atlys Xilinx Environment Setup
@node Atlys Xilinx Environment Setup
@subsection Atlys Xilinx Environment Setup
@subsection Atlys Xilinx Environment Setup
 
 
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
 
 
 
 
@node Atlys Tools
@node Atlys Tools
@section Tools
@section Tools
 
 
@menu
@menu
* Host Tools::
* Host Tools::
* Target System Tools::
* Target System Tools::
* EDA Tools::
* EDA Tools::
* Debug Tools::
* Debug Tools::
@end menu
@end menu
 
 
@node Atlys Host Tools
@node Atlys Host Tools
@subsection Host Tools
@subsection Host Tools
@cindex host tools required Atlys
@cindex host tools required Atlys
 
 
Standard development suite of tools: gcc, make, etc.
Standard development suite of tools: gcc, make, etc.
 
 
@node Atlys Target System Tools
@node Atlys Target System Tools
@subsection Target System Tools
@subsection Target System Tools
@cindex target system tools required Atlys
@cindex target system tools required Atlys
 
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
 
@node Atlys EDA Tools
@node Atlys EDA Tools
@subsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required Atlys
@cindex EDA tools required Atlys
 
 
RTL, gatelevel simulation: Mentor Graphics' Modelsim
RTL, gatelevel simulation: Mentor Graphics' Modelsim
Synthesis: XST (from Xilinx ISE)
Synthesis: XST (from Xilinx ISE)
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
Programming: iMPACT (from Xilinx ISE)
Programming: iMPACT (from Xilinx ISE)
 
 
This has been tested with Xilinx ISE 11.1 under Ubuntu Linux.
This has been tested with Xilinx ISE 11.1 under Ubuntu Linux.
 
 
 
 
@node Atlys Debug Tools
@node Atlys Debug Tools
@subsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required Atlys
@cindex Debug tools required Atlys
 
 
or_debug_proxy, ORPmon/u-boot
or_debug_proxy, ORPmon/u-boot
 
 
@node Atlys Simulating
@node Atlys Simulating
@section Simulating
@section Simulating
@cindex simulating Atlys
@cindex simulating Atlys
 
 
Ensure the Xilinx environment has been setup before running all simulations for this board build. @xref{Xilinx Environment Setup}.
Ensure the Xilinx environment has been setup before running all simulations for this board build. @xref{Xilinx Environment Setup}.
 
 
 
 
@subheading Run RTL Regression Test
@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.
To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.
 
 
@example
@example
@kbd{make rtl-tests}
@kbd{make rtl-tests}
@end example
@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}.
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 Atlys build.
Options specific to the Atlys build.
 
 
@table @code
@table @code
 
 
@item PRELOAD_RAM
@item PRELOAD_RAM
Set to '1' to enable loading of the software image into RAM at the beginning of simulation.
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.
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
@end table
 
 
 
 
 
 
@node Atlys Synthesis
@node Atlys Synthesis
@section 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/xst/run} path with the following command.
Synthesis of the board port for the Actel technology with the Synplify tool can be run in the board's @code{syn/xst/run} path with the following command.
 
 
@example
@example
@kbd{make all}
@kbd{make all}
@end example
@end example
 
 
This will create an NGC file in @code{syn/xst/run} named @code{orpsoc.ngc}.
This will create an NGC file in @code{syn/xst/run} named @code{orpsoc.ngc}.
 
 
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.
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 Atlys Synthesis Options
@node Atlys Synthesis Options
@subsection Options
@subsection Options
 
 
Use the following command int the @code{syn/xst/run} path to get a list of the variables used during synthesis. Any can be set on the command line when running @code{make all}.
Use the following command int the @code{syn/xst/run} path to get a list of the variables used during synthesis. Any can be set on the command line when running @code{make all}.
 
 
@example
@example
@kbd{make print-config}
@kbd{make print-config}
@end example
@end example
 
 
 
 
@node Atlys Synthesis Warnings
@node Atlys Synthesis Warnings
@subsection Checks
@subsection Checks
 
 
The following is a list of some considerations before synthesis.
The following is a list of some considerations before synthesis.
 
 
@itemize @bullet
@itemize @bullet
@item bootrom.v
@item bootrom.v
 
 
If the bootROM module is being used to provide the processor with a program at startup (reset address in processor's define file is set to @code{0xf0000100} or similar), check that board software include file, in the board's @code{sw/board/include} path, is selecting the correct bootROM program.
If the bootROM module is being used to provide the processor with a program at startup (reset address in processor's define file is set to @code{0xf0000100} or similar), 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.
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
@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.
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.
 
 
 
 
 
 
@end itemize
@end itemize
 
 
@node Atlys Synthesised Netlist
@node Atlys Synthesised Netlist
@subsection Netlist generation
@subsection Netlist generation
 
 
To create a Verilog HDL netlist of the post-synthesis design, run the following in the board's @code{syn/xst/run} path.
To create a Verilog HDL netlist of the post-synthesis design, run the following in the board's @code{syn/xst/run} path.
 
 
@example
@example
@kbd{make orpsoc.v}
@kbd{make orpsoc.v}
@end example
@end example
 
 
@node Atlys Place and Route
@node Atlys Place and Route
@section Place and Route
@section Place and Route
 
 
Place and route of the design can be run from the board's @code{backend/par/run} path with the following command.
Place and route of the design can be run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make orpsoc.ncd}
@kbd{make orpsoc.ncd}
@end example
@end example
 
 
@node Atlys Timing Report
@node Atlys Timing Report
@section Post-PAR STA Report
@section Post-PAR STA Report
 
 
The @code{trce} tool can be used to generate a timing report of the post-place and route design.
The @code{trce} tool can be used to generate a timing report of the post-place and route design.
 
 
@example
@example
@kbd{make timingreport}
@kbd{make timingreport}
@end example
@end example
 
 
@node Atlys Back-annotated Netlist
@node Atlys Back-annotated Netlist
@section Back-annotated Netlist
@section Back-annotated Netlist
 
 
A post-PAR back-annotated netlist can be generated with the following command.
A post-PAR back-annotated netlist can be generated with the following command.
 
 
@example
@example
@kbd{make netlist}
@kbd{make netlist}
@end example
@end example
 
 
This will make a new directory under the board's @code{backend/par/run} path named @code{netlist} and will contain a Verilog netlist and SDF file with timing information.
This will make a new directory under the board's @code{backend/par/run} path named @code{netlist} and will contain a Verilog netlist and SDF file with timing information.
 
 
 
 
@node Atlys Place and route options
@node Atlys Place and route options
@subsection Options
@subsection Options
 
 
To get a list of options that can be set when running the backend flow, run the following in the board's @code{backend/par/run} path.
To get a list of options that can be set when running the backend flow, run the following in the board's @code{backend/par/run} path.
 
 
@example
@example
@kbd{make print-config}
@kbd{make print-config}
@end example
@end example
 
 
@node Atlys Constraints
@node Atlys Constraints
@subsection Constraints
@subsection Constraints
 
 
A Xilinx User Constraints File (UCF) file is in the board's @code{backend/par/bin} path. It is named @code{atlys.ucf}. It should be edited if any extra I/O or constraints are required.
A Xilinx User Constraints File (UCF) file is in the board's @code{backend/par/bin} path. It is named @code{atlys.ucf}. It should be edited if any extra I/O or constraints are required.
 
 
Eventually it would be good to dynamically generated this, based on what is included in the design, but for now this must be hand modified if modules are added ore removed from the design.
Eventually it would be good to dynamically generated this, based on what is included in the design, but for now this must be hand modified if modules are added ore removed from the design.
 
 
@node Atlys Programming File Generation
@node Atlys Programming File Generation
@section Programming File Generation
@section Programming File Generation
 
 
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
 
 
@example
@example
@kbd{make orpsoc.bit}
@kbd{make orpsoc.bit}
@end example
@end example
 
 
This file can then be loaded into the Xilinx iMPACT program and programmed onto the Spartan 6 part on the Atlys.
This file can then be loaded into the Xilinx iMPACT program and programmed onto the Spartan 6 part on the Atlys.
 
 
 
 
 
 
@c ****************************************************************************
@c ****************************************************************************
@c Generic Design build chapter
@c Generic Design build chapter
@c ****************************************************************************
@c ****************************************************************************
 
 
@node Generic Designs
@node Generic Designs
@chapter Generic Designs
@chapter Generic Designs
@cindex Generic design information
@cindex Generic design information
 
 
@menu
@menu
* Overview::
* Overview::
@end menu
@end menu
 
 
 
 
@node Generic Build Overview
@node Generic Build Overview
@section Overview
@section Overview
 
 
The paths under @code{boards/generic} contain designs similar to the reference design, in that they are not technology specific, and used for development of certain features of the processor, or peripherals.
The paths under @code{boards/generic} contain designs similar to the reference design, in that they are not technology specific, and used for development of certain features of the processor, or peripherals.
 
 
These builds are a TODO, but should provide technology-independent builds, with any specialist modules required to debug, or assist in development or demonstration of a module.
These builds are a TODO, but should provide technology-independent builds, with any specialist modules required to debug, or assist in development or demonstration of a module.
 
 
 
 
@c ****************************************************************************
@c ****************************************************************************
@c Software section
@c Software section
@c ****************************************************************************
@c ****************************************************************************
 
 
 
 
@node Software
@node Software
@chapter Software
@chapter Software
 
 
@cindex software use of @value{ORPSOC}
@cindex software use of @value{ORPSOC}
 
 
This section details the structure of the software library included in @value{ORPSOC}.
This section details the structure of the software library included in @value{ORPSOC}.
 
 
@node Software Overview
@node Software Overview
@section Overview
@section Overview
 
 
The software provided with ORPSoC is intended to be of sufficient functionality to develop and test the designs, with some additional utility programs for board bring up.
The software provided with ORPSoC is intended to be of sufficient functionality to develop and test the designs, with some additional utility programs for board bring up.
 
 
The bulk of the software library consists of drivers and tests for the included RTL modules, focusing on the processor. A basic C library, implementing basic support functions such as printf, is included. This alleviates the prerequisite of a compiler with supporting C library installed.
The bulk of the software library consists of drivers and tests for the included RTL modules, focusing on the processor. A basic C library, implementing basic support functions such as printf, is included. This alleviates the prerequisite of a compiler with supporting C library installed.
 
 
Each board port may contain additional software drivers and tests in its own software directory, the structure of which mimics that of the main software directory.
Each board port may contain additional software drivers and tests in its own software directory, the structure of which mimics that of the main software directory.
 
 
@node Software Components
@node Software Components
@section Components
@section Components
 
 
This section outlines the different components of the software library in the @code{sw/} path in the root of @value{ORPSOC}.
This section outlines the different components of the software library in the @code{sw/} path in the root of @value{ORPSOC}.
 
 
 
 
@node Software Components Applications
@node Software Components Applications
@subsection Applications
@subsection Applications
 
 
There are some included applications, which are neither drivers or tests.
There are some included applications, which are neither drivers or tests.
 
 
Typically these will contain a @code{README} file in their directories which contain information on the software and its use.
Typically these will contain a @code{README} file in their directories which contain information on the software and its use.
 
 
In general, these are to be run on hardware, and thus will need to be compiled for a specific board. Be sure to pass the @code{BOARD} environment variable when compiling to pick up the appropriate board configuration. @xref{Software For Board Ports}.
In general, these are to be run on hardware, and thus will need to be compiled for a specific board. Be sure to pass the @code{BOARD} environment variable when compiling to pick up the appropriate board configuration. @xref{Software For Board Ports}.
 
 
@node Software Components Drivers
@node Software Components Drivers
@subsection Drivers
@subsection Drivers
 
 
Each RTL component may have a driver, which will be compiled into the liborpsoc library and be made available to applications and tests that use the library.
Each RTL component may have a driver, which will be compiled into the liborpsoc library and be made available to applications and tests that use the library.
 
 
Each driver path should contain its source and an include path for driver headers.
Each driver path should contain its source and an include path for driver headers.
 
 
@node Software Components CPU Drivers
@node Software Components CPU Drivers
@subsection CPU Drivers
@subsection CPU Drivers
 
 
An attempt has been made to make the interface to basic CPU functions as generic as possible. This can allow different CPUs to be implemented in @value{ORPSOC}.
An attempt has been made to make the interface to basic CPU functions as generic as possible. This can allow different CPUs to be implemented in @value{ORPSOC}.
 
 
The header file @code{cpu-utils.h} should be included to gain access to the CPU driver functions, such as timers, special purpose registers, memory access macros, etc. This header will, in turn, include the appropriate CPU driver header.
The header file @code{cpu-utils.h} should be included to gain access to the CPU driver functions, such as timers, special purpose registers, memory access macros, etc. This header will, in turn, include the appropriate CPU driver header.
 
 
@emph{Note:} What is included in the CPU driver, and how it should be interfaced is not documented yet, but in future every effort should be made to ensure a generic interface to CPU functions is used.
@emph{Note:} What is included in the CPU driver, and how it should be interfaced is not documented yet, but in future every effort should be made to ensure a generic interface to CPU functions is used.
 
 
At present only the OR1200 has a driver, but it is intended that alternate OpenRISC processors can be implemented into ORPSoC and a driver for it to be easily used in the library.
At present only the OR1200 has a driver, but it is intended that alternate OpenRISC processors can be implemented into ORPSoC and a driver for it to be easily used in the library.
 
 
The environment variable @code{CPU_DRIVER} is used to specify which driver is the CPU driver to be used at liborpsoc compile time.
The environment variable @code{CPU_DRIVER} is used to specify which driver is the CPU driver to be used at liborpsoc compile time.
 
 
@node Software Components Tests
@node Software Components Tests
@subsection Tests
@subsection Tests
 
 
Each test subdirectory contains directories for each target. Usually there's just @code{sim} and @code{board}, the difference between the two being longer run-time and use of UART for board-targeted tests.
Each test subdirectory contains directories for each target. Usually there's just @code{sim} and @code{board}, the difference between the two being longer run-time and use of UART for board-targeted tests.
 
 
@emph{Note:} Test directory names should not contain hyphens or underscores. Test software files should be named with the single test directory name first, followed by a single word, eg. @code{or1200-simple.c}.
@emph{Note:} Test directory names should not contain hyphens or underscores. Test software files should be named with the single test directory name first, followed by a single word, eg. @code{or1200-simple.c}.
 
 
Test names are referenced using this @code{module}-@code{testname} pair. The automated testing mechanism implemented by the Makefile scripts will always search the @code{sim} paths for tests, rather than the @code{board} paths.
Test names are referenced using this @code{module}-@code{testname} pair. The automated testing mechanism implemented by the Makefile scripts will always search the @code{sim} paths for tests, rather than the @code{board} paths.
 
 
@emph{Note:} There is no automated testing mechanism for the board-targeted software yet. It is anticipated that a testing harness for these will be developed, and we encourage users to help solve this problem.
@emph{Note:} There is no automated testing mechanism for the board-targeted software yet. It is anticipated that a testing harness for these will be developed, and we encourage users to help solve this problem.
 
 
@node Software Components Library
@node Software Components Library
@subsection Library
@subsection Library
 
 
The @code{lib} path in the root software directory is where the code for the minimal C library is located, and is the location of the @code{liborpsoc} archive file after its compilation.
The @code{lib} path in the root software directory is where the code for the minimal C library is located, and is the location of the @code{liborpsoc} archive file after its compilation.
 
 
@node Software Components Board
@node Software Components Board
@subsection Board
@subsection Board
 
 
The @code{board} path in the software directory may, in future, contain other board-specific code, but at present its @code{include} path houses just an important header, @code{board.h} used for configuring the software when compiling programs targeted at a specific board port.
The @code{board} path in the software directory may, in future, contain other board-specific code, but at present its @code{include} path houses just an important header, @code{board.h} used for configuring the software when compiling programs targeted at a specific board port.
 
 
This file contains mainly defines of things such as the CPU frequency and timer rate, peripheral base addresses, IRQ numbers, and other board-specific defines. Each board port should contain its own, and is one of the reasons for passing the @code{BOARD} environment variable when compiling software targeted at a specific board port - so its board-specific defines will be used instead of the reference design's.
This file contains mainly defines of things such as the CPU frequency and timer rate, peripheral base addresses, IRQ numbers, and other board-specific defines. Each board port should contain its own, and is one of the reasons for passing the @code{BOARD} environment variable when compiling software targeted at a specific board port - so its board-specific defines will be used instead of the reference design's.
 
 
@node Software Components Utilities
@node Software Components Utilities
@subsection Utilities
@subsection Utilities
 
 
The @code{utils} path contains tools used to help manipulate binary software images for a variety of purposes. All tools are designed to be run on the host machine, and not on ORPSoC.
The @code{utils} path contains tools used to help manipulate binary software images for a variety of purposes. All tools are designed to be run on the host machine, and not on ORPSoC.
 
 
 
 
@node Software For Board Ports
@node Software For Board Ports
@section Software For Board Ports
@section Software For Board Ports
 
 
Each board port will have its own software directory, if only to keep its @code{board.h} header file, specifying system parameters specific to the board.
Each board port will have its own software directory, if only to keep its @code{board.h} header file, specifying system parameters specific to the board.
 
 
It may also contain drivers and tests specific to peripherals for that board.
It may also contain drivers and tests specific to peripherals for that board.
 
 
@emph{Note:} For any tests or drivers named the same found in both a board's software path and the root software path, the @emph{board's} software will be used instead.
@emph{Note:} For any tests or drivers named the same found in both a board's software path and the root software path, the @emph{board's} software will be used instead.
 
 
@emph{Note:} When compiling any software in the @emph{root} software path (such as in the applications folder) intended to run on a particular board, make use of the @code{BOARD} variable to indicate which board's configuration (@code{board.h} file, and any board-specific drivers) to use. For example:
@emph{Note:} When compiling any software in the @emph{root} software path (such as in the applications folder) intended to run on a particular board, make use of the @code{BOARD} variable to indicate which board's configuration (@code{board.h} file, and any board-specific drivers) to use. For example:
 
 
@example
@example
@kbd{orpsoc/sw/apps/app1$ make app1.elf BOARD=xilinx/ml501}
@kbd{orpsoc/sw/apps/app1$ make app1.elf BOARD=xilinx/ml501}
@end example
@end example
 
 
It's also advisable to do a @code{make distclean} prior to clear out any preexisting libraries that may not contain software appropriate for the targeted board port (it may have been built with the reference design's @code{board.h}, for example.)
It's also advisable to do a @code{make distclean} prior to clear out any preexisting libraries that may not contain software appropriate for the targeted board port (it may have been built with the reference design's @code{board.h}, for example.)
 
 
 
 
@c ****************************************************************************
@c ****************************************************************************
@c EDA tool setup section
@c EDA tool setup section
@c ****************************************************************************
@c ****************************************************************************
 
 
@node EDA tool notes
@node EDA tool notes
@chapter EDA tool notes
@chapter EDA tool notes
@cindex eda tool setup notes
@cindex eda tool setup notes
 
 
EDA tool installation, setup and use notes.
EDA tool installation, setup and use notes.
 
 
@node Xilinx Environment Setup
@node Xilinx Environment Setup
@section Xilinx Environment Setup
@section Xilinx Environment Setup
 
 
Be sure to execute the Xilinx setup scripts prior to running the ORPSoC scripts of boards using that technology.
Be sure to execute the Xilinx setup scripts prior to running the ORPSoC scripts of boards using that technology.
 
 
Find the script in your Xilinx tool suite install path (the installer tells you where this is at the end of installation) but it should be under the ISE_DS path in recent Xilinx ISE releases.
Find the script in your Xilinx tool suite install path (the installer tells you where this is at the end of installation) but it should be under the ISE_DS path in recent Xilinx ISE releases.
 
 
@example
@example
@kbd{source /opt/Xilinx/13.2/ISE_DS/settings32.sh}
@kbd{source /opt/Xilinx/13.2/ISE_DS/settings32.sh}
@end example
@end example
 
 
Note that this affects the @kbd{LD_LIBRARY_PATH} environment variable and other programs may have issues caused by running this script.
Note that this affects the @kbd{LD_LIBRARY_PATH} environment variable and other programs may have issues caused by running this script.
 
 
 
 
@c ****************************************************************************
@c ****************************************************************************
@c End bits
@c End bits
@c ****************************************************************************
@c ****************************************************************************
 
 
@node  GNU Free Documentation License
@node  GNU Free Documentation License
@chapter GNU Free Documentation License
@chapter GNU Free Documentation License
@cindex license for @value{ORPSOC}
@cindex license for @value{ORPSOC}
 
 
@include fdl-1.2.texi
@include fdl-1.2.texi
 
 
@node Index
@node Index
 
 
@unnumbered Index
@unnumbered Index
 
 
@printindex cp
@printindex cp
 
 
@bye
@bye
 
 
 
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.