| Line 30... |
Line 30... |
@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 2 for @value{ORPSOC}
|
@author Issue 3 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
|
| Line 57... |
Line 57... |
@menu
|
@menu
|
* Introduction::
|
* Introduction::
|
* Project Organisation::
|
* Project Organisation::
|
* Getting Started::
|
* Getting Started::
|
* Reference Design::
|
* Reference Design::
|
* Board Designs::
|
|
* ORDB1A3PE1500::
|
* ORDB1A3PE1500::
|
* ML501::
|
* ML501::
|
* S3ADSP1800::
|
* S3ADSP1800::
|
|
* Atlys::
|
* Generic Designs::
|
* Generic Designs::
|
* Software::
|
* Software::
|
|
* 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
|
| Line 125... |
Line 126... |
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
|
|
|
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. 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 (...);}.
|
|
|
| Line 266... |
Line 268... |
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
|
|
|
@menu
|
|
* Overview::
|
|
* RTL::
|
|
* Software::
|
|
* Simulation::
|
|
@end menu
|
|
|
|
@node Reference Design Overview
|
|
@subsection Overview
|
|
|
|
The reference design's paths are all based in the root directory of @value{ORPSOC}. This is different from the board-targeted builds, which are based in their specific board paths.
|
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
|
| Line 348... |
Line 340... |
@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
|
|
@section Simulation
|
@section Simulation
|
|
|
@menu
|
@menu
|
* RTL::
|
* RTL::
|
* Cycle Accurate::
|
* Cycle Accurate::
|
* Results::
|
* Results::
|
@end menu
|
@end menu
|
|
|
@node Reference Design RTL
|
@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.
|
|
|
| Line 983... |
Line 974... |
@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:
|
|
|
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.
|
|
|
| Line 1008... |
Line 999... |
|
|
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 ML501 XILINX_PATH
|
@node ML501 Xilinx Environment Setup
|
@subsection ML501 XILINX_PATH
|
@subsection ML501 Xilinx Environment Setup
|
|
|
Be sure to set the environment variable @code{XILINX_PATH} to the path of the Xilinx tools' install path on the host machine. This path is usually the base install path for the Xilinx tool suite and contains subdirectories such as @code{ISE/}, @code{common/}, @code{PlanAhead/}, etc.
|
|
|
|
Most bash-like shells can use the following line to set this environment variable.
|
|
|
|
@example @kbd{export XILINX_PATH=/software/xilinx_12.3} @end example
|
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
|
|
|
Note that it helps to add the @code{XILINX_PATH} variable to the user's @code{.bashrc} script or similar to save setting it each time a new shell is opened.
|
|
|
|
If the @code{XILINX_PATH} variable is not set correctly, the makefiles will not run.
|
|
|
|
This build has been tested with ISE versions 11.1 and 12.3.
|
|
|
|
@node ML501 Tools
|
@node ML501 Tools
|
@section Tools
|
@section Tools
|
|
|
@menu
|
@menu
|
| Line 1067... |
Line 1049... |
|
|
@node ML501 Simulating
|
@node ML501 Simulating
|
@section Simulating
|
@section Simulating
|
@cindex simulating ML501
|
@cindex simulating ML501
|
|
|
Ensure the @code{XILINX_PATH} environment variable is set correctly. @xref{ML501 XILINX_PATH} for information.
|
Ensure the Xilinx environment has been setup before running all simulations for this board build. @xref{Xilinx Environment Setup}.
|
|
|
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.
|
|
|
| Line 1248... |
Line 1229... |
@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, 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, 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- 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: 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. 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.
|
|
|
| Line 1359... |
Line 1340... |
@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} (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
|
| Line 1380... |
Line 1361... |
|
|
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 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.
|
| Line 1404... |
Line 1385... |
|
|
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 (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
|
| Line 1434... |
Line 1415... |
|
|
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:
|
|
|
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.
|
|
|
| Line 1453... |
Line 1434... |
|
|
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_PATH
|
@node S3ADSP1800 Xilinx Environment Setup
|
@subsection S3ADSP1800 XILINX_PATH
|
@subsection S3ADSP1800 Xilinx Environment Setup
|
|
|
Be sure to set the environment variable @code{XILINX_PATH} to the path of the Xilinx tools' install path on the host machine. This path is usually the base install path for the Xilinx tool suite and contains subdirectories such as @code{ISE/}, @code{common/}, @code{PlanAhead/}, etc.
|
|
|
|
Most bash-like shells can use the following line to set this environment variable.
|
|
|
|
@example @kbd{export XILINX_PATH=/software/xilinx_13.1} @end example
|
|
|
|
Note that it helps to add the @code{XILINX_PATH} variable to the user's @code{.bashrc} script or similar to save setting it each time a new shell is opened.
|
|
|
|
If the @code{XILINX_PATH} variable is not set correctly, the makefiles will not run.
|
Ensure the Xilinx environment has been setup before running all scripts for this board build. @xref{Xilinx Environment Setup}.
|
|
|
This build has been tested with ISE version 13.1
|
|
|
|
Note: At present a variable named @code{XILINX_SETTINGS_SCRIPT} is hardcoded in the board's @code{Makefile.inc} file. This may need to be changed by hand to point to the correct settings32.sh script provided by Xilinx. This should be fixed at some point in the future.
|
|
|
|
@node S3ADSP1800 Tools
|
@node S3ADSP1800 Tools
|
@section Tools
|
@section Tools
|
|
|
@menu
|
@menu
|
| Line 1514... |
Line 1483... |
|
|
@node S3ADSP1800 Simulating
|
@node S3ADSP1800 Simulating
|
@section Simulating
|
@section Simulating
|
@cindex simulating S3ADSP1800
|
@cindex simulating S3ADSP1800
|
|
|
Ensure the @code{XILINX_PATH} environment variable is set correctly. @xref{S3ADSP1800 XILINX_PATH} for information.
|
|
|
|
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.
|
| Line 1662... |
Line 1629... |
|
|
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. 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: 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.
|
|
|
| Line 1743... |
Line 1710... |
@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 (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: 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: 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.
|
| Line 1770... |
Line 1737... |
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 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.
|
| Line 1792... |
Line 1759... |
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 Atlys board build chapter
|
|
@c ****************************************************************************
|
|
|
|
@node Atlys
|
|
@chapter Atlys
|
|
@cindex Atlys board build information
|
|
|
|
@menu
|
|
* Overview::
|
|
* Structure::
|
|
* Tools::
|
|
* Simulating::
|
|
* Synthesis and Backend::
|
|
* Programming File Generation::
|
|
@end menu
|
|
|
|
@node Atlys Overview
|
|
@section Overview
|
|
|
|
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/}
|
|
|
|
Note that this board port is based on the ML501 and structure and use are very similar.
|
|
|
|
@node Atlys 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}.
|
|
|
|
The board port's structure is similar to that of a standalone project which accords with the OpenCores coding guidelines. However, all software and RTL that is available in the reference design is also available to the board port, with any local (ie. in the board's @code{rtl} or @code{sw} paths) versions taking precedence over the versions available in the reference design.
|
|
|
|
The Verilog RTL specific to this board is under @code{rtl/verilog} in the board path. The @code{include} path in there is the place where all required definitions files, configuring the RTL, are found.
|
|
|
|
Backend files, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
|
|
|
|
@node 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}.
|
|
|
|
|
|
@node Atlys Tools
|
|
@section Tools
|
|
|
|
@menu
|
|
* Host Tools::
|
|
* Target System Tools::
|
|
* EDA Tools::
|
|
* Debug Tools::
|
|
@end menu
|
|
|
|
@node Atlys Host Tools
|
|
@subsection Host Tools
|
|
@cindex host tools required Atlys
|
|
|
|
Standard development suite of tools: gcc, make, etc.
|
|
|
|
@node Atlys Target System Tools
|
|
@subsection Target System Tools
|
|
@cindex target system tools required Atlys
|
|
|
|
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
|
|
|
|
@node Atlys EDA Tools
|
|
@subsection EDA Tools
|
|
@cindex EDA tools required Atlys
|
|
|
|
RTL, gatelevel simulation: Mentor Graphics' Modelsim
|
|
Synthesis: XST (from Xilinx ISE)
|
|
Backend: ngdbuild/map/par/bitgen/promgen, etc. (from Xilinx ISE)
|
|
Programming: iMPACT (from Xilinx ISE)
|
|
|
|
This has been tested with Xilinx ISE 11.1 under Ubuntu Linux.
|
|
|
|
|
|
@node Atlys Debug Tools
|
|
@subsection Debug Tools
|
|
@cindex Debug tools required Atlys
|
|
|
|
or_debug_proxy, ORPmon/u-boot
|
|
|
|
@node Atlys Simulating
|
|
@section Simulating
|
|
@cindex simulating Atlys
|
|
|
|
Ensure the Xilinx environment has been setup before running all simulations for this board build. @xref{Xilinx Environment Setup}.
|
|
|
|
|
|
@subheading Run RTL Regression Test
|
|
|
|
To run the default set of regression tests for the build, run the following command in the board's @code{sw/run} path.
|
|
|
|
@example
|
|
@kbd{make rtl-tests}
|
|
@end example
|
|
|
|
The same set of options for RTL tests available in the reference design should be available in this build. @xref{Running A Set Of Specific Reference Design RTL Tests}.
|
|
|
|
Options specific to the Atlys build.
|
|
|
|
@table @code
|
|
|
|
@item PRELOAD_RAM
|
|
Set to '1' to enable loading of the software image into RAM at the beginning of simulation.
|
|
|
|
If the chosen bootROM program (set via a define in software header file in the board's @code{sw/board/include} path) will jump straight to RAM to begin execution, then the software image will need to be in RAM for the simulation to work. This define @emph{must} be used in that case for the simulation to do anything.
|
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
@node Atlys 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.
|
|
|
|
@example
|
|
@kbd{make all}
|
|
@end example
|
|
|
|
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.
|
|
|
|
@node Atlys Synthesis 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}.
|
|
|
|
@example
|
|
@kbd{make print-config}
|
|
@end example
|
|
|
|
|
|
@node Atlys Synthesis Warnings
|
|
@subsection Checks
|
|
|
|
The following is a list of some considerations before synthesis.
|
|
|
|
@itemize @bullet
|
|
@item bootrom.v
|
|
|
|
If the bootROM module is being used to provide the processor with a program at startup (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.
|
|
|
|
|
|
@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.
|
|
|
|
|
|
|
|
@end itemize
|
|
|
|
@node Atlys Synthesised Netlist
|
|
@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.
|
|
|
|
@example
|
|
@kbd{make orpsoc.v}
|
|
@end example
|
|
|
|
@node Atlys 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.
|
|
|
|
@example
|
|
@kbd{make orpsoc.ncd}
|
|
@end example
|
|
|
|
@node Atlys Timing 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.
|
|
|
|
@example
|
|
@kbd{make timingreport}
|
|
@end example
|
|
|
|
@node Atlys Back-annotated Netlist
|
|
@section Back-annotated Netlist
|
|
|
|
A post-PAR back-annotated netlist can be generated with the following command.
|
|
|
|
@example
|
|
@kbd{make netlist}
|
|
@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.
|
|
|
|
|
|
@node Atlys Place and route 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.
|
|
|
|
@example
|
|
@kbd{make print-config}
|
|
@end example
|
|
|
|
@node Atlys 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.
|
|
|
|
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
|
|
@section Programming File Generation
|
|
|
|
Programming file generation is run from the board's @code{backend/par/run} path with the following command.
|
|
|
|
@example
|
|
@kbd{make orpsoc.bit}
|
|
@end example
|
|
|
|
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 ****************************************************************************
|
|
|
| Line 1848... |
Line 2040... |
|
|
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} for an example.
|
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.
|
| Line 1917... |
Line 2109... |
@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 EDA tool setup section
|
|
@c ****************************************************************************
|
|
|
|
@node EDA tool notes
|
|
@chapter EDA tool notes
|
|
@cindex eda tool setup notes
|
|
|
|
EDA tool installation, setup and use notes.
|
|
|
|
@node 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.
|
|
|
|
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
|
|
@kbd{source /opt/Xilinx/13.2/ISE_DS/settings32.sh}
|
|
@end example
|
|
|
|
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 ****************************************************************************
|
|
|
