OpenRisc-54-play with OpenRISC based atlys board

1.OpenRISC 1200 soft processor

Introduction

The  OpenRISC 1200  (OR1200) is a synthesizable CPU core maintained by developers at  OpenCores.org . The OR1200 design is an  open source  implementation of the OpenRISC 1000 RISC architecture. The Verilog RTL description is released under the GNU Lesser General Public License ( LGPL ). For more information see OpenRisc 1200 Specification document  or go to the  OpenRISC 1200 IP Core Specification  page.

Since  the 1st of November 2007 OpenCores is maintained by  ORSoC . For a long period of time ORSoC has worked closely to OpenCores, both with the community and with development of the technology.

Reading instructions

This is the first part of the OpenRISC tutorial. The chapters should be read in date order, starting with the oldest. At the end of every chapter there are four links called TOP,  NEXT,  PREVIOUS and TOC. The TOP link takes you the top of the current chapter. The NEXT link takes you to the next chapter, the PREVIOUS link takes you to the previous chapter and the TOC link takes you to the table of contents page. You can also click the Modesty-CoreX label and then click Index to get to TOC page.
 
 

A review of the OpenRISC architecture and implementation

Julius Baxter has written a great review of open source development and especially the OpenRISC project in his master's thesis. It starts like this:

This document is a look at both the technical aspects of a microprocessor project and open source development. The technology involved in microprocessors and the philosophy and practices of open source development are first explained, before the OpenRISC project, a project combining the two, is presented. This project is then evaluated and the results of the development effort and the role open source has played are discussed. Read ithere.

OpenRISC community portal
 

This wiki is the main entrance to information about the OpenRISC project. It has a lot of useful information about the development process. It took me a long time to find this page. Please add a link on the opencores.org site.

 

Architecture

The IP core of the OR1200 is implemented in the  Verilog HDL . As an open source core, the design is fully public and may be downloaded and modified by any individual. The official implementation is maintained by developers at OpenCores.org. The implementation specifies a power management unit, debug unit, tick timer, programmable interrupt controller (PIC), central processing unit (CPU), and memory management hardware. Peripheral systems and a memory subsystem may be added using the processor's implementation of a standardized 32-bit Wishbone bus  interface.

CPU/DSP

The OR1200 CPU is an implementation of the 32-bit ORBIS32 instruction set architecture (ISA) and (optionally) ORFP32X ISA implementing IEEE-754 compliant single precision floating point support. The ISA has five instruction formats and supports two addressing modes: register indirect with displacement, and PC-relative. The implementation has a single-issue 5-stage pipeline and is capable of single cycle execution on most instructions. The CPU also contains a  MAC unit  in order to better support digital signal processing ( DSP ) applications.

 

Default caches are 1-way direct-mapped 8KB data cache and 1-way direct-mapped 8KB instruction cache, each with 16-byte line size. Both caches are physically tagged. By default  MMUs are implemented and they are constructed of 64-entry hash based 1-way direct-mapped data TLB and 64-entry hash based 1-way direct-mapped instruction TLB. Supplemental facilities include debug unit for real-time debugging, high resolution tick timer, programmable interrupt controller and power management support. For more information see: http://opencores.org/openrisc,or1200
 

General Microarchitecture

 

• Central CPU/DSP block
• IEEE 754 compliant single precision FPU
• Direct mapped data cache
• Direct mapped instruction cache
• Data MMU based on hash-based DTLB
• Instruction MMU based on hash-based ITLB
• Power management unit and power management interface
• Tick timer
• Debug unit and development interface
• Interrupt controller and interrupt interface
• Instruction and Data WISHBONE B3 compliant interfaces

ORPSoC - OpenRISC Reference Platform SoC

ORPSoC is the OpenRISC Reference Platform System-on-Chip. This project implements a platform for OpenRISC development. It provides a reference SoC, primarily for the testing and development of OpenRISC processors, and a set of pre-built SoCs for various FPGA boards.
 

Downloading ORPSoC

The RTL source, test software and scripts can be downloaded from the OpenRISC project subversion (svn) repository. The sources can be checked out with the following command:

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

 After unpacking the ORPSoC installation looks like this.

 

 

GNU toolchain

The GNU Toolchainis a blanket term for a collection of programming tools produced by the GNU Project.These tools form a toolchain (suite of tools used in a serial manner) used for developing applications and operating systems. The GNU toolchain plays a vital role in development of Linux kernel, BSD, and software for embedded systems.

Before we can start using ORPSoC platform we have to download and install the OpenRISC GNU newlib toolchain. The link on the GNU tooolchain web page doesn't work for some reason, but the GNU toolchain can be downloaded from this OpenCores FTP site:  ftp://ocuser:ocuser@openrisc.opencores.org/toolchain/or32-elf-1.0rc1-x86.tar.bz2

Here is a link to download the latest version of the toolchain. Observe, not exactly the same installation as described here below.

Newlib library

The OpenRISC 1000 port of the  newlib  library aims to provide a library to provide support for running on bare-metal hardware without an operating system. It is also used when running the GNU toolchain regression suite. The library is linked when using the newlib version of the GCC compiler (or32-elf-gcc) and adding the -mnewlib option. The target board is specified by -mboardname. If not board is specified, the default (-mor1ksim) is suitable for use with Or1ksim simulator.

GNU toolchain installation

The programs must be installed in the /opt directory. Use the following commands to unzip and unpack the downloaded file:

cd /opt
sudo tar xjf ...../or32-elf-1.0rc1-x86.tar.bz2 

Add the following symbolic links which helps when switching to new updated version later on :

sudo ln -s or32-elf-1.0rc1 or32-elf
sudo ln -s or1ksim-0.5.1rc1 or1ksim

Add the following path to the PATH varable in your .profile file:

PATH=/opt/or32-elf/bin:/opt/or1ksim/bin:$PATH

 

 

Installing in a Linux 64 bits system

When installing the GNU toolchain (32 bits Linux) in Debian Squeeze (64bits) the following i386 (32bits) libraries were missing:

• libmpfr.so.1
• libmpc.so.2
• libgmp.so.3

Finding and installing these i386 libraries in an amd64 system is not that simple. Can anyone explain for me how to do it. One problem is that there are 64 bits versions of some of these libraries installed already.

Building the toolchain yourself
 

There is now a script environment called orbuild that can be downloaded and used to build the toolchain from source. For more information see Using orbuild.

Choosing a development board

From the installation we can see that there are support for a number of development boards. We look for a board with a SPARTAN-6 FPGA and find the Digilent Atlys board. Let's give it a try. I will order the board at once.
 

The MinSoC project

The Minimal OpenRISC System on Chip (minsoc) is a system on chip (SoC) implementation with standard IP cores available at OpenCores. This implementation consists of a standard project comprehending the standard IP cores necessary for a SoC embedding the OpenRISC implementation OR1200.

This project idea is to offer a synthesizable SoC which can be uploaded to every FPGA and be compatible with every FPGA board without the requirement of changing its code. In order to deliver such a project, the project has been based on a standard memory implementation and the Advanced Debug System, which allows system debug and software upload with the same cables used for FPGA configuration.

 

Getting help

If we need help with the development we can post to the OpenRISC forum or send an email toopenrisc_team@opencores.org. There are also four mailing list you can subscribe to. It seems most of the discussion about OpenRISC takes place in these mailing lists. A pattern of usage seems to be emerging, where general users ask their questions on the OpenRISC forum, while developers discuss new design ideas and post patches on the four mailing lists. Click the first link to subscribe to the list and click the second link to send an email to the list.
 

• OpenRISC mailing list on openrisc.net
• Linux mailing list  on  openrisc.net
• OpenRISC mailing list on opencores.org
• Wishbone mailing list on  opencores.org

IRC

Most of the regular contributors can be found on channel #opencores at freenode.net. They are a friendly bunch, and a good source of advice.
 

Links

Here are links to companies using the OpenRISC processor and to other interesting information about the OpenRISC processor. 

AntMicro
ÅAC Microtec Wiki
EMBECOSM
ORSoC
Beginners' Guide to OpenRISC

2.Digilent Atlys SPARTAN-6 development board

Introduction

It didn't take more than one day for the board to arrive. Here it is

 

 
and it looks like this:

 

The size of the board is 13.5 x 12 cm and it contains the following:

• Xilinx Spartan-6 LX45 FPGA, 324-pin BGA package
• 128Mbyte DDR2 16-bit wide data
• 10/100/1000 Ethernet PHY
• On-board USB2 ports for programming & data transfer
• USB-UART and USB-HID port (for mouse/keyboard)
• Two HDMI video input ports & two HDMI output ports
• AC-97 Codec with line-in, line-out, mic, & headphone
• Real time power monitors on all power rails
• 16Mbyte x4 SPI Flash for configuration & data storage
• 100MHz CMOS oscillator
• 48 I/O’s routed to expansion connectors
• GPIO includes 8 LEDs, 6 buttons, & 8 slide switches
• Ships with a 20W power supply and USB cable

For more information see  Diligent webpage .

Documentation

The board comes without any documentation. All documents about the Atlys board can be downloaded from the Digilent support page .

 

Built-in self test

A demonstration configuration is loaded into the SPI Flash ROM on the Atlys board during manufacturing. This demo, also available on the Digilent website, can serve as a board verification test since it interacts with all devices and ports on the board. When the Atlys board powers up, if the demonstration image is present in the SPI Flash, the DDR is tested, and then a bitmap image file will be transferred from the SPI Flash into DDR2. This image will be driven out the HDMI J2 port for display on a DVI/HDMI-compatible monitor. The slide switches are connected to the user LEDs. The user buttons BTNU, BTND, BTNR, BTNL, BTNC, and RESET cause varying sine-wave frequencies to be driven on the LINE OUT and HP OUT audio ports. Here is the test setup.

 

 

 

 

Configuring the board

After power-on, the FPGA on the Atlys board must be configured (or programmed) before it can perform any functions. The FPGA can be configured in three ways: a USB-connected PC can configure the board using the JTAG port any time power is on, a configuration file stored in the SPI Flash ROM can be automatically transferred to the FPGA at power-on, or a programming file can be transferred from a USB memory stick attached to the USB HID port.
 

Design environment

We will use the Xilinx ISE Design Suite as our design environment for synthesizing designs and configuring the FPGA. For more information on how to download and install the Design Suite see this page.
 

Connecting the Atlys board to the computer

It seems that one big hurdle when starting a new FPGA project is to setup the connection between the development board and the computer. I will take you through this process and hopefully we will get the board connected and be able to configure the FPGA. In this example I have Ubuntu 12.04 installed in VirtualBox running on my MacBook Pro, but the same setup will work for other Linux flavors and computers.

There are two ways to connect the computer to the Atlys board:

1. Using the Xilinx Platform Cable USB
 

2. Using a standard USB cable and the Digilent Adept system.

The Digilent Adept system

The Adept port is compatible with Xilinx's iMPACT programming software if the Digilent Plug-In for Xilinx Tools is installed on the host PC. The plug-in automatically translates iMPACT-generated JTAG commands into formats compatible with the Digilent USB port, providing a seamless programming experience without leaving the Xilinx tool environment. Once the plug-in is installed, the "third party" programming option can be selected from the iMPACT tools menu, and iMPACT will work as if a Xilinx programming cable were being used. All Xilinx tools (iMPACT, ChipScope, EDK, etc.) can work with the plug-in, and they can be used in conjunction with Adept tools (like the power supply monitor). We will use this method of connecting to the board because we don't need any extra hardware. Let's start by installing some software.

Installing the Digilent cable drivers

First we add these two sofware packages:

• sudo apt-get install libusb-dev
• sudo apt-get install fxload

Next we have to install the Digilent plugins. Xilinx provide these plugins in their installation directory but they are not activated. Here is what we have to do in Design Suite 14.2:

Goto to directory /opt/Xilinx/14.2/ISE_DS/common/bin/lin/digilent

Execute the following command:

sudo ./install_digilent.sh /opt/Xilinx/14.2/ISE_DS/ISE

The Digilent plugins are installed here.
 

l
 

The USB rules file 52-digilent-usb.rules is installed here:
 

 

The rules file

The problem with this rules file is that in can only be run when we are logged in as root. To fix this problem we have to edit the file and change all SYSFS to ATTR (three locations).
 

After editing the file we have to reboot the system and we are ready to ride. If we are using VirtualBox we have to make sure the USB device is enabled in the Device menu. For older versions of Linux we have to change the first MODE=666" to MODE="666", GROUP="plugdev"
 

Using iMPACT

Let's find out if we can identify the board using iMPACT. First we connect the USB cable from a USB port on our computer to the mini-USB prog port on the Atlys board. We power up the board and start iMPACT. Here is the iMPACT main window telling us that the board has been identified.

 

l l

3.Using ORPSoC

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. It also provides systems intended to be synthesized and programmed on physical hardware. The reference system is the least complex implementation and consists of just enough to test the processor’s functionality. The board-targeted builds typically include many additional peripherals. For more information read the  ORPSoC User Guide  found in the doc directory of the ORPSoC installation.

Project organization

The ORPSoC project is intended to serve dual purposes. One is to act as a development platform for OpenRISC processors, and as a development platform of OpenRISC-based SoCs targeted at specific hardware. Organising a single project to satisfy these requirements can lead to some overlap and redundancy. The reference implementation based in the root (base directory) of the project contains enough components to create a simple OpenRISC-based SoC. Each board build is intended to implement as fully-featured a system as possible, depending on the targeted hardware. The project is organised in such a way that each board build can use both the reference implementation’s RTL modules and software, as well as its own set of RTL and software. The reference implementation is limited to what is available in the RTL and software directories in the root of the project, and is not technology dependent.

The Atlys board

We will start by finding the Atlys board setup.

 

Before we start

Before we start the design phase we have to make sure the Xilinx  Design Suite is installed and that the environment variable XILINX is set.

 

 

Design

The design is made up of a number of Verilog HDL files. They reside in two different directory. One directory that holds all the code that is common to all board designs found here:
 

 

And one board specific design directory as shown in the screenplot of the atlys board directory structure. The syntesis script will pick up all the Verilog design files to build the complete system.

Synthesis 

Synthesis of the board port for the Xilinx technology with the XST synthesis tool can be run in the board’s <syn/xst/run> path with the following command: <make all>
This will create an NGC file in <syn/xst/run> named <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.

 

 

User constraints file
 

A Xilinx User Constraints File (UCF) is in the board’s <backend/par/bin> path. It is named <atlys.ucf>. It should be edited if any extra I/O or constraints are required.

 

Mappping and place & route

Mapping and place & route of the design can be run from the board’s <backend/par/run> path with the following command: <make orpsoc.ncd>. The makefile used can be found in the <......./boards/xilinx/atlys/backend/par/bin> directory. Here is an excerpt from the makefile showing the backend design flow:

 

 

 

Place & route results

The results from the place & route tool can be found in the logfile <orpsoc.par>:

 

 

Options

To get a list of options that can be set when running the backend flow, run the following command:

make print-config
 

Generate timing report

The trace tool can be used to generate a timing report of the post-place and route design:

make timingreport

 

 

Here is the result:

 

 

We have 1338 timing errors. Before we continue we have to investigate these errors. The timing report result file is called <orpsoc.twr>. Analyzing the this we find the following timing errors.
 

 

Without knowing to much about the design it is hard to figure out what is wrong. Let's setup a simulation environment and analyze what's going on (see next chapter).
 

Generating the bitstream file

The bitstream file is used to configure the FPGA device. The configuration file generation is run from the .../atlys/backend/par/run directory using the command:  make orpsoc.bit

 

 

Downloading the bitstream
 

We are going to use the Xilinx configuration tool called iMPACT to configure the SPARTAN-6 FPGA on the Atlys board. The first thing we have to do is connecting our board to the computer we use for our development work using a USB cable.