| Line 58... |
Line 58... |
* Introduction::
|
* Introduction::
|
* Project Organisation::
|
* Project Organisation::
|
* Getting Started::
|
* Getting Started::
|
* Reference Design::
|
* Reference Design::
|
* Board Designs::
|
* Board Designs::
|
* ordb1a3pe1500::
|
* ORDB1A3PE1500::
|
* 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 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, and systems intended to be synthesized and run on physical hardware (boards.) The simple refernce system contains just enough to test the processor's functionality, whereas the board targeted builds will include many additional peripherals.
|
@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, and systems intended to be synthesized and run on physical hardware (boards.) The simple refernce system contains just enough to test the processor's functionality, whereas the board targeted builds will include many additional peripherals.
|
| Line 90... |
Line 90... |
* RTL::
|
* RTL::
|
* Testbenches::
|
* Testbenches::
|
* Reference And Board Designs::
|
* Reference And Board Designs::
|
@end menu
|
@end menu
|
|
|
@node Overview
|
@node Organisation Overview
|
@section Overview
|
@section Organisation Overview
|
|
|
The @value{ORPSOC} project is intended for dual uses. One is to act as a development platform for OpenRISC processors, as well as development of complex OpenRISC-based SoCs. Organising a single project to satisfy these requirements can lead to some confusion. This section is intended to make the organisation of the project clear.
|
The @value{ORPSOC} project is intended for dual uses. One is to act as a development platform for OpenRISC processors, as well as development of complex OpenRISC-based SoCs. Organising a single project to satisfy these requirements can lead to some confusion. This section is intended to make the organisation of the project clear.
|
|
|
In essense, the reference implementation based in the root of the project contains enough to get a simple OpenRISC-based SoC together, the board builds are intended to implement fully-featured systems. The project is organised in such a way that the board builds can use both the reference implementation's RTL and software, as well as its own set of RTL and software. The reference implementation, however, cannot use any board's modules, software or scripts.
|
In essense, the reference implementation based in the root of the project contains enough to get a simple OpenRISC-based SoC together, the board builds are intended to implement fully-featured systems. The project is organised in such a way that the board builds can use both the reference implementation's RTL and software, as well as its own set of RTL and software. The reference implementation, however, cannot use any board's modules, software or scripts.
|
|
|
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
|
@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) and a few custom tools 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) and a few custom tools for manipulation of binary software images.
|
|
|
Driver software, implementing access functions for hardware modules, are found under @code{sw/drivers}. There is the concept of a CPU library, providing CPU-specific functions, which can be changed to support different versions of OpenRISC processors. There is also 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}.
|
Driver software, implementing access functions for hardware modules, are found under @code{sw/drivers}. There is the concept of a CPU library, providing CPU-specific functions, which can be changed to support different versions of OpenRISC processors. There is also 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}.
|
| Line 112... |
Line 112... |
|
|
Under each test directory are two directories, @code{board} and @code{sim}, containing the test software targeted at each. Code for simulation will produce less printfs and perhaps not run as long as tests intended to run at full speed on target.
|
Under each test directory are two directories, @code{board} and @code{sim}, containing the test software targeted at each. Code for simulation will produce less printfs and perhaps not run as long as tests intended to run at full speed on target.
|
|
|
There are for naming software tests, 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}.
|
There are for naming software tests, 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}.
|
|
|
@node RTL
|
@node RTL Organisation
|
@section RTL
|
@section RTL
|
|
|
The HDL code layout conforms to those outlined in the OpenCores.org coding guidelines. http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf
|
The HDL code layout conforms to those outlined in the OpenCores.org coding guidelines. http://cdn.opencores.org/downloads/opencores_coding_guidelines.pdf
|
|
|
Beyond that, there are some rules for the naming in modules. 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 (...}.
|
Beyond that, there are some rules for the naming in modules. 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 (...}.
|
|
|
@node Testbenches
|
@node Testbench Organisation
|
@section Testbenches
|
@section Testbench
|
|
|
For each design in @value{ORPSOC} there will be a testbench instantiating the top level, and any peripherals (at least, as many as there are models for.)
|
For each design in @value{ORPSOC} there will be a testbench instantiating the top level, and any peripherals (at least, as many as there are models for.)
|
|
|
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. However, this is not intended as a platform for peripheral development (although, it very well could be) the board designs are not expected to have thorough peripheral tests. They are expected to have just enough to prove that basic functionality.
|
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. However, this is not intended as a platform for peripheral development (although, it very well could be) the board designs are not expected to have thorough peripheral tests. They are expected to have just enough to prove that basic functionality.
|
|
|
@node 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.
|
|
|
Typically, a board-targeted design will wish to reuse common components (processor, debug interface, Wishbone arbiters, UART etc.) The project has been configured to allow a board build to use either modules available in the ``common'' RTL path (@code{rtl/verilog/}) as well as those in their ``local'' RTL path (something like @code{boards/vendor/boardname/rtl/verilog}). In the event that some particular modification to a module in the common RTL set is desired for a particular board build, that module can simply be copied into the board's ``local'' RTL path and the scripts will that version instead of the common one.
|
Typically, a board-targeted design will wish to reuse common components (processor, debug interface, Wishbone arbiters, UART etc.) The project has been configured to allow a board build to use either modules available in the ``common'' RTL path (@code{rtl/verilog/}) as well as those in their ``local'' RTL path (something like @code{boards/vendor/boardname/rtl/verilog}). In the event that some particular modification to a module in the common RTL set is desired for a particular board build, that module can simply be copied into the board's ``local'' RTL path and the scripts will that version instead of the common one.
|
| Line 149... |
Line 149... |
* Supported Platforms::
|
* Supported Platforms::
|
* Obtaining Project Source::
|
* Obtaining Project Source::
|
* Required Tools::
|
* Required Tools::
|
@end menu
|
@end menu
|
|
|
@node Supported Platforms
|
@node Getting Started Supported Platforms
|
@section Supported Platforms
|
@section Supported Platforms
|
@cindex platforms supported by the @value{ORPSOC} project
|
@cindex 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 is not a given.
|
Unless indicated otherwise, support for the project under Cygwin on Microsoft Windows platforms is not a given.
|
|
|
|
|
@node 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 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.
|
| Line 217... |
Line 217... |
* Tools::
|
* Tools::
|
* Simulation::
|
* Simulation::
|
* Synthesis::
|
* Synthesis::
|
@end menu
|
@end menu
|
|
|
@node Overview
|
@node Reference Design Overview
|
@subsection Overview
|
@subsection 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. In this regard, 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. In this regard, 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 instaniated 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 instaniated 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.
|
| Line 230... |
Line 230... |
|
|
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 Structure
|
@node Reference Design Structure
|
@subsection Structure
|
@subsection Structure
|
|
|
@menu
|
@menu
|
* Overview::
|
* Overview::
|
* RTL::
|
* RTL::
|
* Software::
|
* Software::
|
* Simulation::
|
* Simulation::
|
@end menu
|
@end menu
|
|
|
@node Overview
|
@node Reference Design Overview
|
@subsubsection Overview
|
@subsubsection Overview
|
|
|
The reference design's paths are all based in the root directory of @value{ORPSOC}. This is different from the board-targeted builds, which are based in their specific board paths.
|
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 RTL
|
@node Reference Design RTL
|
@subsubsection RTL
|
@subsubsection 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.
|
|
|
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 Software
|
@node Reference Design Software
|
@subsubsection Software
|
@subsubsection 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 Simulation
|
@node Reference Design Simulation
|
@subsubsection Simulation
|
@subsubsection 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 Tools
|
@node Reference Design Tools
|
@subsection Tools
|
@subsection 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 Host Tools
|
@node Reference Design Host Tools
|
@subsubsection Host Tools
|
@subsubsection 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 Target System Tools
|
@node Reference Design Target System Tools
|
@subsubsection Target System Tools
|
@subsubsection 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 EDA Tools
|
@node Reference Design EDA Tools
|
@subsubsection EDA Tools
|
@subsubsection 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 Debug Tools
|
@node Reference Design Debug Tools
|
@subsubsection Debug Tools
|
@subsubsection 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 Simulation
|
@node Reference Design Simulation
|
@subsection Simulation
|
@subsection Simulation
|
|
|
@menu
|
@menu
|
* RTL::
|
* RTL::
|
* Cycle Accurate::
|
* Cycle Accurate::
|
* Results::
|
* Results::
|
@end menu
|
@end menu
|
|
|
@node RTL
|
@node Reference Design RTL
|
@subsubsection RTL
|
@subsubsection 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.
|
|
|
| Line 337... |
Line 337... |
|
|
@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{sw/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.
|
|
|
@subsubheading Running An Individual Test
|
@subsubheading 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
|
@subsubheading Running A Set Of Specific Tests
|
@subsubheading 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 Options For Reference Design RTL Tests
|
@subsubheading Options For RTL Tests
|
@subsubheading 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{sw/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
|
| Line 384... |
Line 385... |
|
|
@end table
|
@end table
|
|
|
|
|
|
|
@node Cycle Accurate
|
@node Reference Design Cycle Accurate
|
@subsubsection Cycle Accurate
|
@subsubsection Cycle Accurate
|
@cindex cycle accurate simulation of reference design
|
@cindex cycle accurate simulation of reference design
|
|
|
@subsubheading Running Cycle Accurate Regression Test
|
@subsubheading Running Cycle Accurate Regression Test
|
|
|
| Line 464... |
Line 465... |
@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 Results
|
@node Reference Design Results
|
@subsubsection Results
|
@subsubsection Results
|
@cindex output from simulation of reference design
|
@cindex output from simulation of reference design
|
|
|
The following files are generted 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 generted from the event driven simulation. For output options of the cycle accurate model, see the section on Cycle Accurate Model Executable Usage.
|
|
|
| Line 501... |
Line 502... |
@subsubheading Value Change Dump (VCD)
|
@subsubheading 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 Synthesis
|
@node Reference Design Synthesis
|
@subsection Synthesis
|
@subsection 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::
|
* Synthesis and Backend::
|
|
* Programming File Generation::
|
|
* Customising::
|
@end menu
|
@end menu
|
|
|
@node Overview
|
@node ORDB1A3PE1500 Overview
|
@subsection Overview
|
@subsection Overview
|
|
|
@c TODO
|
The ORDB1 (ORSoC development board 1) with Actel A3PE1500 FPGA is supported by this build.
|
|
|
|
As the ORDB1 is intended to be a daughter board for a variety of I/O boards its options for configuration are extensive.
|
|
|
|
This board port of ORPSoC implements an example of a configurable system, with many cores that can be enabled or disabled as required by the expansion board's capabilities.
|
|
|
|
The port was mainly developed with the ORSoC ethernet expansion board (OREEB1), and was used with the OpenRISC port of the Linux kernel and BusyBox suite running network applications.
|
|
|
@node Structure
|
This guide will overview how to simulation, synthesize and customise the system.
|
|
|
|
@node ORDB1A3PE1500 Structure
|
@subsection Structure
|
@subsection Structure
|
|
|
@c TODO
|
Note that in this chapter the term @emph{board path} refers to the path in the project for this board port; @code{boards/actel/ordb1a3pe1500}.
|
|
|
|
The board port's structure is similar to that of a standalone project which accords with the OpenCores coding guidelines. However, all software and RTL that is available in the reference design is also available to the board port, with any local (ie. in the board's @code{rtl} or @code{sw} paths) versions taking precedence over the versions available in the reference design.
|
|
|
|
The Verilog RTL specific to this board is under @code{rtl/verilog} in the board path. The @code{include} path in there is the place where all required definitions files, configuring the RTL, are found.
|
|
|
@node Tools
|
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
|
@subsection Tools
|
@subsection 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 Host Tools
|
@node ORDB1A3PE1500 Host Tools
|
@subsubsection Host Tools
|
@subsubsection Host Tools
|
@cindex host tools required
|
@cindex host tools required ORDB1A3PE1500
|
|
|
Standard development suite of tools: gcc, make, etc.
|
Standard development suite of tools: gcc, make, etc.
|
|
|
@node Target System Tools
|
@node ORDB1A3PE1500 Target System Tools
|
@subsubsection Target System Tools
|
@subsubsection Target System Tools
|
@cindex target system tools required
|
@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 EDA Tools
|
@node ORDB1A3PE1500 EDA Tools
|
@subsubsection EDA Tools
|
@subsubsection EDA Tools
|
@cindex EDA tools required
|
@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)
|
|
|
@node Debug Tools
|
This has been developed with Libero v8.6 for Linux.
|
|
|
|
@node ORDB1A3PE1500 Debug Tools
|
@subsubsection Debug Tools
|
@subsubsection Debug Tools
|
@cindex Debug tools required
|
@cindex Debug tools required ORDB1A3PE1500
|
|
|
or_debug_proxy, ORPmon
|
or_debug_proxy, ORPmon
|
|
|
|
@node ORDB1A3PE1500 Simulating
|
|
@subsection Simulating
|
|
@cindex simulating ORDB1A3PE1500
|
|
|
|
@subsubheading Run RTL Regression Test
|
|
|
|
To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.
|
|
|
|
@example
|
|
@kbd{make rtl-tests}
|
|
@end example
|
|
|
|
The same set of options for RTL tests available in the reference design should available in this build. @xref{Running A Set Of Specific Reference Design RTL Tests}.
|
|
|
|
@node ORDB1A3PE1500 Synthesis
|
|
@subsection Synthesis
|
|
|
|
Synthesis of the board port for the Actel technology with the Synplify tool can be run in the board's @code{syn/synplify/run} path with the following command.
|
|
|
|
@example
|
|
@kbd{make all}
|
|
@end example
|
|
|
|
This will create a EDIF netlist in @code{syn/synplify/out}.
|
|
|
|
Hopefully it's all automated enough so that, as long as the design is simulating as desired, the correct set of RTL will be picked up and synthesized without any need for customising scripts for the tool.
|
|
|
|
@node ORDB1A3PE1500 Synthesis Options
|
|
@subsubsection Options
|
|
|
|
The following can be passed as environment variables when running @kbd{make all}.
|
|
|
|
@table @code
|
|
|
|
@item RTL_TOP
|
|
Default's to the designs top level module, @emph{orpsoc_top}, but if wishing to synthesize a particular module, its name (not instantiated name) should be set here.
|
|
|
|
@item FPGA_PART
|
|
Defaults to A3PE1500 but if targeting any other set it with this.
|
|
|
|
@item FPGA_FAMILY
|
|
Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.
|
|
|
|
@item FPGA_PACKAGE
|
|
Defaults to PQFP208 but if targeting any other set it with this.
|
|
|
|
@item FPGA_SPEED_GRADE
|
|
Defaults to Std but if targeting any other set it with this.
|
|
|
|
@item FREQ
|
|
Target frequency for synthesis.
|
|
|
|
@item MAXFAN
|
|
Maximum net fanout.
|
|
|
|
@item MAXFAN_HARD
|
|
Hard limit on maximum net fanout.
|
|
|
|
@item GLOBALTHRESH
|
|
Threshold of fanout before promoting signal to a global routing net.
|
|
|
|
@item RETIMING
|
|
Defaults to '1' (on) but set to '0' to disable.
|
|
|
|
@item RESOURCE_SHARING
|
|
Defaults to '1' (on) but set to '0' to disable.
|
|
|
|
@item DISABLE_IO_INSERTION
|
|
Defaults to '0' (off) but set to '1' to enable. Useful when synthesizing individual modules not intended as a top level.
|
|
|
|
@end table
|
|
|
|
@node ORDB1A3PE1500 Synthesis Warnings
|
|
@subsubsection Checks
|
|
|
|
The following is a list of some considerations before synthesis.
|
|
|
|
@itemize @bullet
|
|
@item bootrom.v
|
|
|
|
If the bootROM module is being used to provide the processor with a progrm 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 clean-all} from the synthesis run directory to be sure that the previous bootROM file is cleared away and regenerated when synthesis is run.
|
|
|
|
|
|
@item Clean away old leftovers
|
|
|
|
If the unwanted files from an old synthesis run are still there before the next run, it's best to clean them away with @kbd{make clean} from the synthesis run directory.
|
|
|
|
|
|
@item Check Command Line Options
|
|
|
|
If using any command line settings, they can be checked by passing them to the following make target: @kbd{make print-config}
|
|
|
|
|
|
@end itemize
|
|
|
|
@node ORDB1A3PE1500 Place and Route
|
|
@subsection Place and Route
|
|
|
|
Place and route is run from the board's @code{backend/par/run} path with the following command.
|
|
|
|
@example
|
|
@kbd{make all}
|
|
@end example
|
|
|
|
This will create a @code{.adb} file in the same path.
|
|
|
|
All steps, up to programming file generation are done here. This is mainly a licensing thing (free liceneses for Libero under Linux @emph{do not} allow programming file generation - they do, however, under Windows.)
|
|
|
|
@node ORDB1A3PE1500 Place and route options
|
|
@subsubsection Options
|
|
|
|
Most of the design's parameters are deteremined by processing the @code{orpsoc-defines.v} file and determining, for example, the frequency of the clocks entering the design.
|
|
|
|
The following can be passed as environment variables when running @kbd{make all}.
|
|
|
|
@table @code
|
|
|
|
@item FPGA_PART
|
|
Defaults to A3PE1500 but if targeting any other set it with this.
|
|
|
|
@item FPGA_FAMILY
|
|
Defaults to the A3PE1500's @emph{ProASIC3E} but if targeting any other set it with this.
|
|
|
|
@item FPGA_PACKAGE
|
|
Defaults to ``208 PQFP'' but if targeting any other set it with this.
|
|
|
|
|
|
@item FPGA_SPEED_GRADE
|
|
Defaults to Std but if targeting any other set it with this.
|
|
|
|
@item FPGA_VOLTAGE
|
|
Defaults to 1.5 but if targeting any other set it with this.
|
|
|
|
@item FPGA_TEMP_RANGE
|
|
Defaults to COM but if targeting any other set it with this.
|
|
|
|
@item FPGA_VOLT_RANGE
|
|
Defaults to COM but if targeting any other set it with this.
|
|
|
|
@item PLACE_INCREMENTAL
|
|
Defaults to off.
|
|
|
|
@item ROUTE_INCREMENTAL
|
|
Defaults to off.
|
|
|
|
@item PLACER_HIGH_EFFORT
|
|
Defaults to off.
|
|
|
|
@item BOARD_CONFIG
|
|
Defaults to @code{orsoccpuexpio.mkpinassigns}
|
|
|
|
@end table
|
|
|
|
@node ORDB1A3PE1500 Constraints
|
|
@subsubsection Constraints
|
|
|
|
|
|
A @emph{synposys design constraints} (SDC) file, and @emph{physical design constraints} (PDC) file are generated automatically by the scripts. The main Verilog defines file is parsed to detect which modules are included in the design, and generates the appropriate constraints which are embedded in the Makefile.
|
|
|
|
|
|
The PDC relies on the @code{BOARD_CONFIG} environment variable to indicate which pin assignment file to pull into the Makefile (they live in @code{backend/par/bin}). The PDC also depends on the actual contents of the main place and route Makefile, @code{backend/par/bin/Makefile}.
|
|
|
|
|
|
By default these should have support for the peripherals included with ORPSoC. Double check, however, that the correct constraints are set, by running the following command before starting place and route.
|
|
|
|
@example
|
|
@kbd{make pdc-file sdc-file}
|
|
@end example
|
|
|
|
These can be generated and edited and then used when running place and route, they will not get replaced.
|
|
|
|
@node ORDB1A3PE1500 Programming File Generation
|
|
@subsection Programming File Generation
|
|
|
|
The @code{.adb} file resulting from place and route can be opened in the Actel @emph{Designer} tool and a programming file generated there.
|
|
|
|
Once this programming file is created, Actel's @emph{FlashPro} can used to program the ORDB1A3PE1500 board.
|
|
|
|
@node ORDB1A3PE1500 Customising
|
|
@subsection Customising
|
|
|
|
The versatile nature of the ORDB1A3PE1500 means the design that goes on it must be equally versatile, if not more so.
|
|
|
|
The following sections have information on how to configure the design.
|
|
|
|
@node ORDB1A3PE1500 Customising Enabling Existing Modules
|
|
@subsubsection Enabling Existing RTL Modules
|
|
|
|
The design relies on the Verilog HDL @emph{define} function to indicate which modules are included.
|
|
|
|
There are only a few modules included by deafult.
|
|
|
|
@itemize @bullet
|
|
@item Processor - @emph{or1200}
|
|
@item Clock and reset generation - @emph{clkgen}
|
|
@item Bus arbiters - @emph{arbiter_ibus}, @emph{arbiter_dbus}, @emph{arbiter_bytebus}
|
|
@end itemize
|
|
|
|
The rest are optional, depending on what is defined in the board's @code{rtl/verilog/include/orpsoc-defines.v} file.
|
|
|
|
Inspect that file to see which modules are able to be included. At present the list includes USB 1.1 host controller and/or slave interface, I2C master/slave core, and SPI master cores.
|
|
|
|
These cores should be supported and ready to go by just defining them (uncommont in the @code{orspco-defines.v} file.)
|
|
|
|
@node ORDB1A3PE1500 Customising Adding Modules
|
|
@subsubsection Adding RTL Modules
|
|
|
|
There are a number of steps to take when adding a new module to the design.
|
|
|
|
@itemize @bullet
|
|
@item RTL Files
|
|
|
|
Create a directory under the board's @code{rtl/verilog} directory, and name it the same as the top level of the module.
|
|
|
|
Ensure the module's top level file and actual name of the module when it will be instantiated are @emph{all the same}.
|
|
|
|
Place any include files into the board's @code{rtl/verilog/include} path.
|
|
|
|
@item Instantiate in ORPSoC Top Level File
|
|
|
|
Instantiate the module in the ORPSoC top level file, @code{rtl/verilog/orpsoc_top/orpsoc_top.v}, and be sure to take care of the following.
|
|
@itemize @bullet
|
|
@item Create appropriate @emph{`define} in @code{orpsoc-defines.v} and surround module instantiation with it.
|
|
@item Add required I/Os (surrounded by appropriate @emph{`ifdef })
|
|
@item Attach to appropriate bus arbiter, declaring any signals required. Be sure to tie them off if modules is not included.
|
|
@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 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.
|
|
@end itemize
|
|
|
|
@item Update ORPSoC Testbench
|
|
|
|
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.
|
|
|
|
@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.)
|
|
|
|
@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} wll 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.
|
|
|
|
Continuing the format already there should be easy enough. Rememeber that the @code{orspoc-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.
|
|
|
|
@example
|
|
@kbd{ $(Q)if [ ! -z $$FOO1 ]; then \
|
|
echo "set_io foo1_srx_i " $(FOO_SRX_BUS_SETTINGS) " \
|
|
-pinname "$(FOO1_SRX_PIN) >> $@; \
|
|
echo "set_io foo1_tx_o\\[0\\] " $(FOO_TX_BUS_SETTINGS) " \
|
|
-pinname "$(FOO1_TX0_PIN) >> $@; \
|
|
echo "set_io foo1_tx_o\\[1\\] " $(FOO_TX_BUS_SETTINGS) " \
|
|
-pinname "$(FOO1_TX1_PIN) >> $@; \
|
|
echo "set_io foo1_tx_o\\[2\\] " $(FOO_TX_BUS_SETTINGS) " \
|
|
-pinname "$(FOO1_TX2_PIN) >> $@; \
|
|
echo "set_io foo1_tx_o\\[3\\] " $(FOO_TX_BUS_SETTINGS) " \
|
|
-pinname "$(FOO1_TX3_PIN) >> $@; \
|
|
fi
|
|
}
|
|
@end example
|
|
|
|
@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.
|
|
|
|
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.
|
|
|
|
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 intot he 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.
|
|
|
|
The physical constraints file can be generated manually with the @kbd{make pdc-file} command.
|
|
|
|
@end itemize
|
|
|
|
|
|
|
|
|
|
|
@c ****************************************************************************
|
@c ****************************************************************************
|
@c End bits
|
@c End bits
|
@c ****************************************************************************
|
@c ****************************************************************************
|
|
|
