     [file config.texi not included]

This file documents the OpenRISC Reference Platform SoC, ORPSOC.

Copyright © 2010 OpenCores

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.  A copy of the license is included in the section entitled ``GNU Free Documentation License''.

Scope of this Document
**********************

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

Introduction
************

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.

The reference design will contain a minimal set of resources to create an OpenRISC-based SoC. It is expected the board builds will contain their own set of peripheral modules and software, and still draw upon the resources available in the reference implementation. It is hoped that, with this structure, the project can serve dual roles; to be a development platform for OpenRISC family processors, and to provide a platform for development of complex OpenRISC-based systems on chip.

This document, the user guide, focuses on getting the various designs in ORPSOC up and running. For matters relating to development of a board port, see the development guide included with this documentation.

Project Organisation
********************

Organisation Overview
=====================

The 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.

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

Software
========

The 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 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 sw/lib path. Both drivers and support library are compiled together to create a library called liborpsoc which is placed in sw/lib.

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

Under each test directory are two directories, board and 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 testdirname-testname.extension, eg. uart-simple.c or or1200-fp.S.

RTL
===

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 uart16550) should also be the name of the top level file, eg. uart16550.v, and the top level module should also be simply this name, eg. module uart16550 (....

Testbench
=========

For each design in 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.

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.

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 (rtl/verilog/) as well as those in their ``local'' RTL path (something like 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.

Getting Started
***************

Supported Platforms
===================

At present the majority of  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.

Obtaining Project Source
========================

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

     svn export http://opencores.org/ocsvn/openrisc/openrisc/trunk/orpsocv2

Required Tools
==============

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

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

The required tools can be divided into four groups.

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

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

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

  * Debug tools - tools providing control over the system on target

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

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

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

Reference Design
****************

Overview
--------

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

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

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

Structure
---------

Overview
........

The reference design's paths are all based in the root directory of 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 syn or backend paths in the root directory of ORPSOC.

RTL
...

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

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

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

Software
........

The software run on the reference design is found in the ORPSOC root directory, under the sw path.

The test software for the or1200 processor is found under sw/tests/or1200/sim.

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

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

Simulation
..........

The simulation of the reference design is run from the sim/run path.

The script controlling simulation is the file sim/bin/Makefile.

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

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

Tools
-----

Host Tools
..........

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

Target System Tools
...................

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

EDA Tools
.........

RTL simulation: Icarus Verilog (also compatible with Mentor Graphics' Modelsim) Cycle Accurate Simulation: Verilator, Verilog-Perl, System-Perl, SystemC

Debug Tools
...........

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

Simulation
----------

RTL
...

All simulations of the reference design are run from the sim/run path.

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:

     make rtl-tests

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

Running An Individual Test
..........................

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

     make rtl-test TEST=or1200-basic

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 TESTS environment variable.

     make rtl-tests TESTS="sdram-rows uart-simple or1200-mmu or1200-fp"

Options For RTL Tests
.....................

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

VCD
     Set to '1' to enable value change dump (VCD) creation in sim/out/testname.vcd

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

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

END_TIME
     Force simulation end ($finish) at this time.

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

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

Cycle Accurate
..............

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:

     make vlt-tests

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

Running An Individual Test
..........................

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

     make vlt-test TEST=or1200-basic

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 sim/run path.

     make prepare-vlt

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

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.

     make prepare-vlt-profiled

Cycle Accurate Model Executable Usage
.....................................

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

     Vorpsoc_top --help

A short list of options is given here.

-f FILE
--program FILE
     Load software from OR32 ELF image FILE

     If unspecified, model attempts to load VMEM file sram.vmem

-v
--vcd
     Dump VCD file

-e VALUE
--endtime VALUE
     End simulation after VALUE simulated ns

-l FILE
--log FILE
     Log processor execution trace to FILE

Results
.......

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.

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 sim/out and will be named test-name-executed.log.

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 sim/out named test-name-sprs.log.

Processor Instruction Excecution Time Log
.........................................

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

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

These values are logged to a file in sim/out named test-name-lookup.log.

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 sim/out named test-name-general.log. This is not optional.

Value Change Dump (VCD)
.......................

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

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.

ORDB1A3PE1500
*************

Overview
--------

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

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

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

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

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

Structure
---------

Note that in this chapter the term board path refers to the path in the project for this board port; 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 rtl or sw paths) versions taking precedence over the versions available in the reference design.

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

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

Tools
-----

Host Tools
..........

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

Target System Tools
...................

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

EDA Tools
.........

RTL, gatelevel simulation: Mentor Graphics' Modelsim Synthesis: Synopsys Synplify (included in Actel Libero Suite) Backend: Actel Designer (included in Actel Libero Suite) Programming: Actel FlashPRO (included in Actel Libero Suite)

This has been developed with Libero v8.6 for Linux.

Debug Tools
...........

or_debug_proxy, ORPmon

Simulating
----------

Run RTL Regression Test
.......................

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

     make rtl-tests

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

Options specific to the ORDB1A3PE1500 build.

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 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 must be used in that case for the simulation to do anything.

Synthesis
---------

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

     make all

This will create a EDIF netlist in 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.

Options
.......

The following can be passed as environment variables when running make all.

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

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

FPGA_FAMILY
     Defaults to the A3PE1500's ProASIC3E but if targeting any other set it with this.

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

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

FREQ
     Target frequency for synthesis.

MAXFAN
     Maximum net fanout.

MAXFAN_HARD
     Hard limit on maximum net fanout.

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

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

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

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

Checks
......

The following is a list of some considerations before synthesis.

  * 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 sw/board/include path, is selecting the correct bootROM program.

     Do a 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.

  * 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 make clean from the synthesis run directory.

  * Check Command Line Options

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

Place and Route
---------------

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

     make all

This will create a .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 do not allow programming file generation - they do, however, under Windows.)

Options
.......

Most of the design's parameters are deteremined by processing the 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 make all.

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

FPGA_FAMILY
     Defaults to the A3PE1500's ProASIC3E but if targeting any other set it with this.

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

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

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

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

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

PLACE_INCREMENTAL
     Defaults to off.

ROUTE_INCREMENTAL
     Defaults to off.

PLACER_HIGH_EFFORT
     Defaults to off.

BOARD_CONFIG
     Defaults to orsoccpuexpio.mkpinassigns

Constraints
...........

A synposys design constraints (SDC) file, and 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 BOARD_CONFIG environment variable to indicate which pin assignment file to pull into the Makefile (they live in backend/par/bin). The PDC also depends on the actual contents of the main place and route Makefile, 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.

     make pdc-file sdc-file

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

Programming File Generation
---------------------------

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

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

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.

Enabling Existing RTL Modules
.............................

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

There are only a few modules included by deafult.

  * Processor - or1200

  * Clock and reset generation - clkgen

  * Bus arbiters - arbiter_ibus, arbiter_dbus, arbiter_bytebus

The rest are optional, depending on what is defined in the board's 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 orspco-defines.v file.)

Adding RTL Modules
..................

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

  * RTL Files

     Create a directory under the board's 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 all the same.

     Place any include files into the board's rtl/verilog/include path.

  * Instantiate in ORPSoC Top Level File

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

       * Create appropriate `define in orpsoc-defines.v and surround module instantiation with it.

       * Add required I/Os (surrounded by appropriate `ifdef )

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

       * Update appropriate bus arbiter (in board's rtl/verilog/arbiters path) adding (uncommenting) additional ports as needed.

       * Update board's rtl/verilog/include/orpsoc-params.v file with appropriate set of parameters for new module, as well as arbiter memory mapping assignment.

       * Attach appropriate clocks and resets, modify the board's rtl/verilog/clkgen/clkgen.v file generating appropriate clocks if required.

       * Attach any interrupts to the processor's PIC vector in, assigned as the last thing in the file.

  * Update ORPSoC Testbench

     Update the board's bench/verilog/orpsoc_testbench.v file with appropriate ports (surrounded by appropriate `ifdef.)

     Add any desired models to help test the module to the board's bench/verilog path and instantiate it correctly in the testbench.

  * Add Software Drivers and Tests

     In a similar fashion to what is already in the board's sw/drivers and sw/tests path, create desired driver and test software to be used during simulation (and potentially on target.)

  * Update Backend Scripts

     If any I/O is added, or special timing specified, the board's backend main Makefile, backend/par/bin/Makefile and pinout files (in backend/par/bin wll need to be updated.

     The section in 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 $(PDC_FILE): and is actually a set of long bash lines.

     Continuing the format already there should be easy enough. Rememeber that the 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 foo, and in orpsoc-defines.v a value FOO1 is defined, we can add I/Os foo1_srx_i and foo1_tx_o[3:0] with the following.

          	$(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

     (ensure there is no whitespace after the trailing backslashes.)

     It's a little hard to follow, but it's essentially one 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 orpsoc-defines.v.

     Note that what is defined can be checked by running make print-defines in the board's 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 .mkpinassigns which is included intot he Makefile (according to the BOARD_CONFIG variable set when running the 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 make pdc-file command.

GNU Free Documentation License
******************************

     [file fdl-1.2.texi not included]