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

Subversion Repositories openrisc_me

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /openrisc/trunk/orpsocv2
    from Rev 466 to Rev 468
    ↔ Reverse comparison
  •

Rev 466 → Rev 468

/bench/verilog/or1200_monitor.v
456,7 → 456,7
get_gpr(3, r3);
$fdisplay(fgeneral, "%t: l.nop exit (%h)", $time, r3);
`ifdef OR1200_MONITOR_VERBOSE_NOPS
$display("%t: l.nop exit (%h)", $time, r3);
$display("exit(%h)",r3);
`endif
$finish;
end
467,9 → 467,9
// simulation reports (l.nop 2)
if (`OR1200_TOP.`CPU_cpu.`CPU_ctrl.wb_insn == 32'h1500_0002) begin
get_gpr(3, r3);
$fdisplay(fgeneral, "%t: l.nop report (%h)", $time, r3);
$fdisplay(fgeneral, "%t: l.nop report (0x%h)", $time, r3);
`ifdef OR1200_MONITOR_VERBOSE_NOPS
$display("%t: l.nop report (%h)", $time, r3);
$display("report (0x%h);", r3);
`endif
end
// simulation printfs (l.nop 3)
503,7 → 503,7
input [31:0] addr;
output [31:0] insn;
begin
insn = `RAM_WB_TOP.get_mem(addr);
insn = `RAM_WB_TOP.get_mem32(addr);
end
endtask // get_insn_from_wb_ram
`endif
/doc/orpsoc.texi
8,7 → 8,7
@copying
This file documents the OpenRISC Reference Platform SoC, @value{ORPSOC}.
 
Copyright @copyright{} 2010 OpenCores
Copyright @copyright{} 2010,2011 OpenCores
 
@quotation
Permission is granted to copy, distribute and/or modify this document
62,6 → 62,7
* Board Designs::
* ORDB1A3PE1500::
* ML501::
* Software::
* GNU Free Documentation License:: The license for this documentation
* Index::
@end menu
125,6 → 126,8
 
The rules for naming software tests are important to adhere to, so the automation scripts can locate them. The test directory name must be a single word (potentially with underscores), and then the tests must be in files of the format @emph{testdirname}-@emph{testname}.extension, eg. @code{uart-simple.c} or @code{or1200-fp.S}.
 
@xref{Software} for further details.
 
@node RTL Organisation
@section RTL
 
244,7 → 247,7
@end menu
 
@node Reference Design Overview
@subsection 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.
 
257,7 → 260,7
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
@subsection Structure
@section Structure
 
@menu
* Overview::
267,7 → 270,7
@end menu
 
@node Reference Design Overview
@subsubsection 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.
 
274,7 → 277,7
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
@subsubsection 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.
 
283,7 → 286,7
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
@subsubsection Software
@subsection Software
 
The software run on the reference design is found in the @value{ORPSOC} root directory, under the @code{sw} path.
 
294,7 → 297,7
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
@subsubsection Simulation
@subsection Simulation
 
The simulation of the reference design is run from the @code{sim/run} path.
 
305,7 → 308,7
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
@subsection Tools
@section Tools
 
@menu
* Host Tools::
315,19 → 318,19
@end menu
 
@node Reference Design Host Tools
@subsubsection Host Tools
@subsection Host Tools
@cindex host tools required
 
Standard development suite of tools: gcc, make, etc.
 
@node Reference Design Target System Tools
@subsubsection Target System Tools
@subsection Target System Tools
@cindex target system tools required
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
@node Reference Design EDA Tools
@subsubsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required
 
RTL simulation: Icarus Verilog (also compatible with Mentor Graphics' Modelsim)
334,7 → 337,7
Cycle Accurate Simulation: Verilator, Verilog-Perl, System-Perl, SystemC
 
@node Reference Design Debug Tools
@subsubsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required
 
None. The target is purely simulation, no extra utilities are required to debug.
341,7 → 344,7
 
 
@node Reference Design Simulation
@subsection Simulation
@section Simulation
 
@menu
* RTL::
350,12 → 353,12
@end menu
 
@node Reference Design RTL
@subsubsection RTL
@subsection RTL
@cindex rtl simulation of reference design
 
All simulations of the reference design are run from the @code{sim/run} path.
 
@subsubheading 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:
 
365,7 → 368,7
 
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
@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.
 
374,7 → 377,7
@end example
 
@node Running A Set Of Specific Reference Design RTL Tests
@subsubheading 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.
 
382,8 → 385,31
@kbd{make rtl-tests TESTS="sdram-rows uart-simple or1200-mmu or1200-fp"}
@end example
 
@node Providing A Precompiled ELF Executable
@subheading Providing A Precompiled ELF Executable
 
It's possible to specify the path to an OR32 ELF executable to be run in simulation instead of test software. Use the @code{USER_ELF} environment variable to specify the path to the ELF to run.
 
@example
@kbd{make rtl-test USER_ELF=/path/to/myapp.elf}
@end example
 
The ELF will be converted to binary format, and then converted to a VMEM to be
loaded into the model for execution at runtime.
 
@node Providing A Custom VMEM Image
@subheading Providing A Custom VMEM Image
 
It's possible to specify the path to a pre-existing VMEM image to be run in simulation instead of test software. Use the @code{USER_VMEM} environment variable to specify the path to the VMEM image to be run.
 
@example
@kbd{make rtl-test USER_VMEM=/path/to/myapp.vmem}
@end example
 
This VMEM file will be copied into the working directory, and renamed according to what the simulated memory expects.
 
@node Options For Reference Design RTL Tests
@subsubheading 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.
 
412,10 → 438,10
 
 
@node Reference Design Cycle Accurate
@subsubsection Cycle Accurate
@subsection Cycle Accurate
@cindex cycle accurate simulation of reference design
 
@subsubheading 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:
 
425,7 → 451,7
 
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.
 
@subsubheading 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.
 
433,7 → 459,7
@kbd{make vlt-test TEST=or1200-basic}
@end example
 
@subsubheading 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.
 
443,7 → 469,7
 
The resulting executable will be @emph{Vorpsoc_top} in the @code{sim/vlt} path. Run it with the @emph{-h} option for usage instructions.
 
@subsubheading 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.
 
451,7 → 477,7
@kbd{make prepare-vlt-profiled}
@end example
 
@subsubheading 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.
 
492,24 → 518,24
@end table
 
@node Reference Design Results
@subsubsection Results
@subsection Results
@cindex output from simulation of reference design
 
The following files are generated from the event driven simulation. For output options of the cycle accurate model, see the section on Cycle Accurate Model Executable Usage.
 
@subsubheading 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.
 
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}.
 
@subsubheading 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.
 
These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-sprs.log}.
 
@subsubheading 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.
 
517,19 → 543,19
 
These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-lookup.log}.
 
@subsubheading 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.
 
These values are logged to a file in @code{sim/out} named @code{@emph{test-name}-general.log}. This is not optional.
 
@subsubheading 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}.
 
 
@node Reference Design Synthesis
@subsection 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.
 
553,7 → 579,7
@end menu
 
@node ORDB1A3PE1500 Overview
@subsection Overview
@section Overview
 
The ORDB1 (ORSoC development board 1) with Actel A3PE1500 FPGA is supported by this build.
 
566,7 → 592,7
This guide will overview how to simulation, synthesize and customise the system.
 
@node ORDB1A3PE1500 Structure
@subsection 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}.
 
577,7 → 603,7
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
@section Tools
 
@menu
* Host Tools::
587,19 → 613,19
@end menu
 
@node ORDB1A3PE1500 Host Tools
@subsubsection Host Tools
@subsection Host Tools
@cindex host tools required ORDB1A3PE1500
 
Standard development suite of tools: gcc, make, etc.
 
@node ORDB1A3PE1500 Target System Tools
@subsubsection Target System Tools
@subsection Target System Tools
@cindex target system tools required ORDB1A3PE1500
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
@node ORDB1A3PE1500 EDA Tools
@subsubsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required ORDB1A3PE1500
 
RTL, gatelevel simulation: Mentor Graphics' Modelsim
610,16 → 636,16
This has been tested with with Libero v8.6 and v9.0sp1 under Ubuntu Linux.
 
@node ORDB1A3PE1500 Debug Tools
@subsubsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required ORDB1A3PE1500
 
or_debug_proxy, ORPmon
 
@node ORDB1A3PE1500 Simulating
@subsection Simulating
@section Simulating
@cindex simulating ORDB1A3PE1500
 
@subsubheading 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.
 
644,7 → 670,7
 
 
@node ORDB1A3PE1500 Synthesis
@subsection 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.
 
657,7 → 683,7
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
@subsection Options
 
The following can be passed as environment variables when running @kbd{make all}.
 
702,7 → 728,7
@end table
 
@node ORDB1A3PE1500 Synthesis Warnings
@subsubsection Checks
@subsection Checks
 
The following is a list of some considerations before synthesis.
 
727,7 → 753,7
@end itemize
 
@node ORDB1A3PE1500 Place and Route
@subsection 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.
 
740,7 → 766,7
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
@subsubsection 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.
 
785,7 → 811,7
@end table
 
@node ORDB1A3PE1500 Constraints
@subsubsection 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.
803,7 → 829,7
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
@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.
 
810,7 → 836,7
Once this programming file is created, Actel's @emph{FlashPro} can used to program the ORDB1A3PE1500 board.
 
@node ORDB1A3PE1500 Customising
@subsection Customising
@section Customising
 
The versatile nature of the ORDB1A3PE1500 means the design that goes on it must be equally versatile, if not more so.
 
817,7 → 843,7
The following sections have information on how to configure the design.
 
@node ORDB1A3PE1500 Customising Enabling Existing Modules
@subsubsection 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.
 
836,7 → 862,7
These cores should be supported and ready to go by just defining them (uncomment in the @code{orspco-defines.v} file.)
 
@node ORDB1A3PE1500 Customising Adding Modules
@subsubsection Adding RTL Modules
@subsection Adding RTL Modules
 
There are a number of steps to take when adding a new module to the design.
 
936,7 → 962,7
@end menu
 
@node ML501 Overview
@subsection Overview
@section Overview
 
The Xilinx ML501 board contains a Virtex LX50 part, varied memories and peripherals. See Xilinx's site for specific details:
 
953,7 → 979,7
This guide is far from complete, but provides the basics on running simulations, and building the design.
 
@node ML501 Structure
@subsection 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}.
 
964,7 → 990,7
Backend files, mainly binary NGC files for mapping, are found in the board's @code{backend/bin} path.
 
@node ML501 XILINX_PATH
@subsubsection ML501 XILINX_PATH
@subsection ML501 XILINX_PATH
 
Be sure to set the environment variable @code{XILINX_PATH} to the path of the ISE path on the host machine. This can be done with something like @kbd{export XILINX_PATH=/software/xilinx_11.1/ISE} and additionally a symbolic link to the Verilog simulation library sources will be required - see the simulation section on this. 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.
 
971,7 → 997,7
If the @code{XILINX_PATH} variable is not set correctly, the makefiles will not run.
 
@node ML501 Tools
@subsection Tools
@section Tools
 
@menu
* Host Tools::
981,19 → 1007,19
@end menu
 
@node ML501 Host Tools
@subsubsection Host Tools
@subsection Host Tools
@cindex host tools required ML501
 
Standard development suite of tools: gcc, make, etc.
 
@node ML501 Target System Tools
@subsubsection Target System Tools
@subsection Target System Tools
@cindex target system tools required ML501
 
OpenRISC GNU toolchain. For installation, see OpenRISC GNU toolchain page on OpenCores.org.
 
@node ML501 EDA Tools
@subsubsection EDA Tools
@subsection EDA Tools
@cindex EDA tools required ML501
 
RTL, gatelevel simulation: Mentor Graphics' Modelsim
1005,13 → 1031,13
 
 
@node ML501 Debug Tools
@subsubsection Debug Tools
@subsection Debug Tools
@cindex Debug tools required ML501
 
or_debug_proxy, ORPmon
 
@node ML501 Simulating
@subsection Simulating
@section Simulating
@cindex simulating ML501
 
Ensure the @code{XILINX_PATH} environment variable is set correcetly. @xref{ML501 XILINX_PATH} for information.
1018,7 → 1044,7
 
Note that if this path is not set, simulations will not compile.
 
@subsubheading 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.
 
1043,7 → 1069,7
 
 
@node ML501 Synthesis
@subsection 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.
 
1056,7 → 1082,7
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
@subsubsection 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}.
 
1066,7 → 1092,7
 
 
@node ML501 Synthesis Warnings
@subsubsection Checks
@subsection Checks
 
The following is a list of some considerations before synthesis.
 
1087,7 → 1113,7
@end itemize
 
@node ML501 Synthesised Netlist
@subsubsection 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.
 
1096,7 → 1122,7
@end example
 
@node ML501 Place and Route
@subsection 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.
 
1105,7 → 1131,7
@end example
 
@node ML501 Timing Report
@subsection 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.
 
1114,7 → 1140,7
@end example
 
@node ML501 Back-annotated Netlist
@subsection Back-annotated Netlist
@section Back-annotated Netlist
 
A post-PAR back-annotated netlist can be generated with the following command.
 
1126,7 → 1152,7
 
 
@node ML501 Place and route options
@subsubsection 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.
 
1135,7 → 1161,7
@end example
 
@node ML501 Constraints
@subsubsection 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.
 
1142,7 → 1168,7
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
@subsection 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.
 
1153,7 → 1179,7
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
@subsubsection 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.
 
1162,7 → 1188,7
@end example
 
@node ML501 SPI programming file with software
@subsubsection 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.
 
1191,7 → 1217,7
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
@subsubsection SPI flash programming
@subsection SPI flash programming
 
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.
 
1205,7 → 1231,7
 
 
@node ML501 Customising
@subsection 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.
 
1212,7 → 1238,7
The following sections have information on how to configure the design.
 
@node ML501 Customising Enabling Existing Modules
@subsubsection 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.
 
1229,7 → 1255,7
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
@subsubsection Adding RTL Modules
@subsection Adding RTL Modules
 
There are a number of steps to take when adding a new module to the design.
 
1272,10 → 1298,10
@end itemize
 
@node ML501 Running And Debugging Software
@subsection Running And Debugging Software
@section Running And Debugging Software
 
@node ML501 Debug Interface
@subsubsection 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.
 
1301,7 → 1327,7
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.
 
@node ML501 UART
@subsubsection UART
@subsection UART
 
There are 2 ways of connecting to the UART in the design.
 
1324,7 → 1350,110
 
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.
 
@c ****************************************************************************
@c Software section
@c ****************************************************************************
 
 
@node Software
@chapter Software
 
@cindex software use of @value{ORPSOC}
 
This section details the structure of the software library included in @value{ORPSOC}.
 
@node Software 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 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.
 
@node Software Componenets
@section Components
 
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
@subsection Applications
 
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.
 
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.
 
@node Software Components 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 driver path should contain its source and an include path for driver headers.
 
@node Software Components 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}.
 
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.
 
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.
 
@node Software Components 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.
 
@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.
 
@emph{Note:} There is no automated testing mechnism 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
@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.
 
@node Software Components 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.
 
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
@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.
 
 
@node 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.
 
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:} 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 indicat which board's configuration (@code{board.h} file, and any board-specific drivers) to use. For example:
 
@example
@kbd{orpsoc/sw/apps/app1$ make app1.elf BOARD=xilinx/ml501}
@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.)
 
 
 
@c ****************************************************************************
@c End bits
@c ****************************************************************************
/sim/bin/Makefile
55,7 → 55,19
# Need this for individual test variables to not break
TEST ?= or1200-simple
 
TESTS ?= or1200-simple or1200-basic or1200-cbasic or1200-dctest or1200-float or1200-mmu or1200-except or1200-mac or1200-ffl1 or1200-linkregtest or1200-tick or1200-ticksyscall uart-simple
TESTS ?= or1200-simple \
or1200-basic \
or1200-cbasic \
or1200-dctest \
or1200-float \
or1200-mmu \
or1200-except \
or1200-mac \
or1200-ffl1 \
or1200-linkregtest \
or1200-tick \
or1200-ticksyscall \
uart-simple
 
# Gets turned into verilog `define
SIM_TYPE=RTL
68,7 → 80,10
 
PROJECT_VERILOG_DEFINES=$(RTL_VERILOG_INCLUDE_DIR)/$(DESIGN_NAME)-defines.v
# Detect technology to use for the simulation
DESIGN_DEFINES=$(shell cat $(PROJECT_VERILOG_DEFINES) | sed s://.*::g | sed s:\`:\#:g | sed 's:^[ ]*::' | awk '{print};/^\#define/{printf "_%s=%s\n",$$2,$$2}' | grep -v PERIOD | cpp -P | sed s:^_::g | sed s:=$$::g )
DESIGN_DEFINES=$(shell cat $(PROJECT_VERILOG_DEFINES) | \
sed s://.*::g | sed s:\`:\#:g | sed 's:^[ ]*::' | \
awk '{print};/^\#define/{printf "_%s=%s\n",$$2,$$2}' | \
grep -v PERIOD | cpp -P | sed s:^_::g | sed s:=$$::g )
 
# Rule to look at what defines are being extracted from main file
print-defines:
361,24 → 376,65
# Path for the current test
TEST_SW_DIR=$(SW_DIR)/tests/$(shell echo $(TEST) | cut -d "-" -f 1)/sim
 
# This SHOULD be a VMEM file. sram.vmem is the name of the image the ram models
# attempt to load.
SIM_SW_IMAGE ?=sram.vmem
# This file name corresponds to the VMEM file the RAM models will attempt to
# load via $readmemh().
SIM_VMEM_IMAGE ?=sram.vmem
 
.PHONY : sw-vmem sw-elf
sw-vmem: $(SIM_SW_IMAGE)
ifeq ($(USER_ELF),)
ELF_FILE=$(TEST_SW_DIR)/$(TEST).elf
else
ELF_FILE=$(USER_ELF)
ELF_FILE_NOTDIR=$(notdir $(USER_ELF))
ELF_FILE_NOTDIR_BASENAME=$(basename $(ELF_FILE_NOTDIR))
endif
 
$(SIM_SW_IMAGE): $(TEST_SW_DIR)/$(TEST).vmem
# Rules allowing user to specify a pre-existing VMEM file to load into the
# simulation, instead of compiling a test.
ifeq ($(USER_VMEM),)
VMEM_FILE=$(TEST_SW_DIR)/$(TEST).vmem
.PHONY: $(VMEM_FILE)
 
 
# If USER_ELF was specified, then we need a slightly different way of
# generating the VMEM file from it than a usual test
ifeq ($(USER_ELF),)
$(SIM_VMEM_IMAGE): $(VMEM_FILE)
$(Q)if [ -L $@ ]; then unlink $@; fi
$(Q)if [ -e $@ ]; then rm $@; fi
$(Q)ln -s $< $@
else
$(SIM_VMEM_IMAGE): $(USER_ELF)
$(Q)$(MAKE) -C $(SW_DIR)/lib \
USER_ELF_BIN=`pwd`/$(ELF_FILE_NOTDIR_BASENAME).bin \
USER_ELF_VMEM=`pwd`/$(ELF_FILE_NOTDIR_BASENAME).vmem \
gen-user-elf-vmem
$(Q)cp -v $(ELF_FILE_NOTDIR_BASENAME).vmem $@
 
.PHONY: $(TEST_SW_DIR)/$(TEST).vmem
TEST=$(ELF_FILE_NOTDIR_BASENAME)
endif
 
else
VMEM_FILE=$(USER_VMEM)
USER_VMEM_NOTDIR=$(notdir $(USER_VMEM))
TEST=$(basename $(USER_VMEM_NOTDIR))
 
$(SIM_VMEM_IMAGE): $(VMEM_FILE)
cp -v $< $@
 
endif
 
 
 
 
.PHONY : sw-vmem sw-elf
sw-vmem: $(SIM_VMEM_IMAGE)
 
$(TEST_SW_DIR)/$(TEST).vmem:
$(Q) echo; echo "\t### Compiling software ###"; echo;
$(Q)$(MAKE) -C $(TEST_SW_DIR) $(TEST).vmem
 
# Compile ELF and copy it here
sw-elf: $(TEST_SW_DIR)/$(TEST).elf
sw-elf: $(ELF_FILE)
$(Q)cp -v $< .
 
$(TEST_SW_DIR)/$(TEST).elf:
409,7 → 465,9
clean-sim:
$(Q) echo; echo "\t### Cleaning simulation run directory ###"; echo;
$(Q)rm -rf *.* lib_* work transcript check-test-log
$(Q) if [ -e $(VPI_SRC_C_DIR) ]; then $(MAKE) -C $(VPI_SRC_C_DIR) clean; fi
$(Q) if [ -e $(VPI_SRC_C_DIR) ]; then \
$(MAKE) -C $(VPI_SRC_C_DIR) clean; \
fi
 
clean-bootrom:
$(MAKE) -C $(BOOTROM_SW_DIR) clean
426,7 → 484,7
$(Q)rm -f $(TEST_DEFINES_VLG)
 
clean-sim-test-sw:
$(Q)if [ -e $(SIM_SW_IMAGE) ]; then unlink $(SIM_SW_IMAGE); fi
$(Q)if [ -L $(SIM_VMEM_IMAGE) ]; then unlink $(SIM_VMEM_IMAGE); fi
 
clean-sw:
$(Q) echo; echo "\t### Cleaning simulation sw directories ###"; echo;
/sw/Makefile.inc
48,10 → 48,16
 
# If BOARD_PATH is set, we'll first scan that path for which drivers they have
# and will override any locally named driver directories here.
ifdef BOARD_PATH
#$(info BOARD_PATH is being used: $(BOARD_PATH))
BOARD_SPECIFIC_DRIVERS=$(shell if [ -e $(BOARD_PATH)/sw/drivers ]; then ls $(BOARD_PATH)/sw/drivers; fi)
BOARD_SW_TESTS=$(shell if [ -e $(BOARD_PATH)/sw/tests ]; then ls $(BOARD_PATH)/sw/tests; fi)
ifdef BOARD
BOARD_PATH=$(SW_ROOT)/../boards/$(BOARD)
#$(info BOARD is being used: $(BOARD_PATH))
BOARD_SPECIFIC_DRIVERS=$(shell if [ -e \
$(BOARD_PATH)/sw/drivers ]; then \
ls $(BOARD_PATH)/sw/drivers; \
fi)
BOARD_SW_TESTS=$(shell if [ -e $(BOARD_PATH)/sw/tests ]; then\
ls $(BOARD_PATH)/sw/tests; \
fi)
endif
 
COMMON_SW_DRIVERS=$(shell ls $(SW_ROOT)/drivers )
/sw/lib/Makefile
14,3 → 14,11
 
clean:
$(Q)rm -f *.a *.o
 
# Special rule to help simulation Makefile compile VMEMs from ELFs passed via
# the USER_ELF variable
$(USER_ELF_BIN): $(USER_ELF)
$(Q)$(OR32_OBJCOPY) -O binary $< $@
$(USER_ELF_VMEM): $(USER_ELF_BIN) $(UTILS_BIN2VMEM)
$(Q)$(UTILS_BIN2VMEM) $< > $@
gen-user-elf-vmem: $(USER_ELF_VMEM)
/boards/actel/ordb1a3pe1500/sim/bin/Makefile
55,8 → 55,8
BOARD_DIR=$(PROJECT_ROOT)/boards/$(FPGA_VENDOR)/$(BOARD_NAME)
 
# Export BOARD_PATH for the software makefiles
BOARD_PATH=$(BOARD_DIR)
export BOARD_PATH
BOARD=$(FPGA_VENDOR)/$(BOARD_NAME)
export BOARD
 
# Paths to other important parts of this test suite
COMMON_RTL_DIR = $(PROJECT_ROOT)/rtl
/boards/actel/ordb1a3pe1500/sw/bootrom/Makefile
14,10 → 14,10
bootrom.v: $(SW_ROOT)/bootrom/bootrom.v
$(Q)cp -v $< .
 
export BOARD_PATH
# Export BOARD so the Make script in the root software path knows we're to
# use our board.h file, not theirs.
export BOARD
 
# Pass BOARD_PATH so the Make script in the root software path knows we're to
# use our board.h file, not theirs.
$(SW_ROOT)/bootrom/bootrom.v:
$(Q)$(MAKE) -C $(SW_ROOT)/bootrom bootrom.v
 
/boards/actel/ordb1a3pe1500/sw/Makefile.inc
9,10 → 9,10
SW_ROOT=$(BOARD_SW_ROOT)/$(PROJ_ROOT)/sw
 
# Set the BOARD_PATH to point to the root of this board build
BOARD_PATH=$(shell pwd)/$(BOARD_SW_ROOT)/..
BOARD=actel/ordb1a3pe1500
 
# Set RTL_VERILOG_INCLUDE_DIR so software
RTL_VERILOG_INCLUDE_DIR=$(BOARD_PATH)/rtl/verilog/include
RTL_VERILOG_INCLUDE_DIR=$(shell pwd)/$(BOARD_SW_ROOT)/../rtl/verilog/include
 
# Set the processor capability flags
# This doesn't work! :-( Need to figure out way to set these and have them
/boards/actel/ordb1a3pe1500/syn/synplify/bin/Makefile
16,9 → 16,9
BOARD_DIR ?=$(CUR_DIR)/../../..
PROJECT_ROOT=$(BOARD_DIR)/../../..
 
# Export BOARD_PATH for the software makefiles
BOARD_PATH=$(BOARD_DIR)
export BOARD_PATH
# Export BOARD for the software makefiles
BOARD=actel/ordb1a3pe1500
export BOARD
 
DESIGN_NAME=orpsoc
 
/boards/xilinx/ml501/sim/bin/Makefile
54,9 → 54,9
BOARD_NAME=ml501
BOARD_DIR=$(PROJECT_ROOT)/boards/$(FPGA_VENDOR)/$(BOARD_NAME)
 
# Export BOARD_PATH for the software makefiles
BOARD_PATH=$(BOARD_DIR)
export BOARD_PATH
# Export BOARD for the software makefiles
BOARD=$(FPGA_VENDOR)/$(BOARD_NAME)
export BOARD
 
# Paths to other important parts of this test suite
COMMON_RTL_DIR = $(PROJECT_ROOT)/rtl
/boards/xilinx/ml501/sw/bootrom/Makefile
14,10 → 14,10
bootrom.v: $(SW_ROOT)/bootrom/bootrom.v
$(Q)cp -v $< .
 
export BOARD_PATH
# Export BOARD so the Make script in the root software path knows we're to
# use our board.h file, not theirs.
export BOARD
 
# Pass BOARD_PATH so the Make script in the root software path knows we're to
# use our board.h file, not theirs.
$(SW_ROOT)/bootrom/bootrom.v:
$(Q)$(MAKE) -C $(SW_ROOT)/bootrom bootrom.v
 
/boards/xilinx/ml501/sw/Makefile.inc
9,10 → 9,10
SW_ROOT=$(BOARD_SW_ROOT)/$(PROJ_ROOT)/sw
 
# Set the BOARD_PATH to point to the root of this board build
BOARD_PATH=$(shell pwd)/$(BOARD_SW_ROOT)/..
BOARD=xilinx/ml501
 
# Set RTL_VERILOG_INCLUDE_DIR so software
RTL_VERILOG_INCLUDE_DIR=$(BOARD_PATH)/rtl/verilog/include
RTL_VERILOG_INCLUDE_DIR=$(shell pwd)/$(BOARD_SW_ROOT)/../rtl/verilog/include
 
# Set the processor capability flags
# This doesn't work! :-( Need to figure out way to set these and have them
/boards/xilinx/ml501/sw/board/include/board.h
10,8 → 10,8
// file, which is compiled and converted into Verilog for inclusion at
// synthesis time. See bootloader/bootloader.S for details on each option.
 
//#define BOOTROM_SPI_FLASH
#define BOOTROM_GOTO_RESET
#define BOOTROM_SPI_FLASH
//#define BOOTROM_GOTO_RESET
//#define BOOTROM_LOOP_AT_ZERO
//#define BOOTROM_LOOP_IN_ROM
 
/boards/xilinx/ml501/syn/xst/bin/Makefile
160,9 → 160,9
BOOTROM_FILE=bootrom.v
BOARD_BOOTROM_SW_DIR=$(BOARD_SW_DIR)/bootrom
BOOTROM_VERILOG=$(BOARD_BOOTROM_SW_DIR)/$(BOOTROM_FILE)
# Export BOARD_PATH for the software makefiles
BOARD_PATH=$(BOARD_DIR)
export BOARD_PATH
# Export BOARD for the software makefiles
BOARD=xilinx/ml501
export BOARD
bootrom: $(BOOTROM_VERILOG)
$(BOOTROM_VERILOG):
$(MAKE) -C $(BOARD_BOOTROM_SW_DIR) $(BOOTROM_FILE)

powered by: WebSVN 2.1.0

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