Subversion Repositories openrisc_2011-10-31

OpenRISC 1200 IP Core Specification (Preliminary Draft)

=======================================================

:doctype: book

////

Revision history

Note: When adding new entries, strictly follow the format of the existing ones.

Rev.    | Date          | Author        | Description

__vstart__

v0.1    | 28/3/01       | Damjan Lampret        | First Draft

v0.2    | 16/4/01       | Damjan Lampret        | First time published

v0.3    | 29/4/01       | Damjan Lampret        | All chapters almost

finished. Some bugs hidden waiting for an update. Awaiting feedback.

v0.4    | 16/5/01       | Damjan Lampret        | Synchronization with

OR1K Arch Manual

v0.5    | 24/5/01       | Damjan Lampret        | Fixed bugs

v0.6    | 28/5/01       | Damjan Lampret        | Changed some SPR addresses.

v0.7    | 06/9/01       | Damjan Lampret        | Simplified debug unit.

v0.8    | 30/08/10      | Julius Baxter         | Adding information about FPU

implementation, data cache write-back capability. PIC behavior update.

Instruction list update. Update of bits in config registers, bringing into

line with latest OR1200 - not entirely complete.

v0.9    | 12/9/10       | Julius Baxter         | Clarified supported parts of

OR1K instruction set. Updated core clock input information.

Fixed up reference to instruction execute stage cycle table.

Added divide cycles to execute stage cycle table.

0.10    | 1/11/10       | Julius Baxter         | Added FF1/FL1 instructions to

supported instructions table.

v0.11   | 19/1/11       | Julius Baxter | Cache information update.

Wishbone behavior clarification. Serial integer multiply/divide update.

Reset address clarification

v0.12   | 13/9/11       | Julius Baxter | Addition of extension instructions

l.extbs, l.extbz, l.exths, l.exthz, l.extws and l.extwz. Range exception

support, overflow bit in supervision register.

__vend__

////

Introduction

------------

Purpose of this document is to define specifications of the OpenRISC 1200

implementation. This specification defines all implementation specific

variables that are not part of the general architecture specification. This

includes type and size of data and instruction caches, type and size of data

and instruction MMUs, details of all execution pipelines, implementation

of exception unit, interrupt controller and other supplemental units.

This document does not cover general architecture topics like instruction set,

memory addressing modes and other architectural definitions. See

<> for more information about architecture.

OpenRISC Family

~~~~~~~~~~~~~~~

(((OpenRISC,Family)))

OpenRISC 1000 is architecture for a family of free, open source RISC processor

cores. As architecture, OpenRISC 1000 allows for a spectrum of chip and

system implementations at a variety of price/performance points for a range of

applications. It is a 32/64-bit load and store RISC architecture designed with

emphasis on performance, simplicity, low power requirements, scalability and

versatility. OpenRISC 1000 architecture targets medium and high performance

networking, embedded, automotive and portable computer environments.

image::img/or_family.gif[scaledwidth="50%",align="center"]

All OpenRISC implementations, whose first digit in identification number

is  1 , belong to OpenRISC 1000 family. Second digit defines which features

of OpenRISC 1000 architecture are implemented and in which way they are

implemented. Last two digits define how an implementation is configured

before it is used in a real application.

However, at present the OR1200 is the only major RTL implementation of the

OR1K architecture spec, and the OR1200 name has stuck, despite the high level

of reconfigurability possible that would, strictly speaking, mean the core

is either a OR1000, OR1300, etc. So, despite the various features that may

or may not be implemented, the core is still only referred to as the OR1200.

OpenRISC 1200

~~~~~~~~~~~~~

(((OpenRISC,1200)))

The OR1200 is a 32-bit scalar RISC with Harvard microarchitecture, 5 stage

integer pipeline, virtual memory support (MMU) and basic DSP capabilities.

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-mpped 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.  When implemented in a typical 0.18u 6LM process it should provide

over 300 dhrystone 2.1 MIPS at 300MHz and 300 DSP MAC 32x32 operations, at

least 20% more than any other competitor in this class. OR1200 in default

configuration has about 1M transistors.

OR1200 is intended for embedded, portable and networking applications. It can

successfully compete with latest scalar 32-bit RISC processors in his class

and can efficiently run any modern operating system.  Competitors include

ARM10, ARC and Tensilica RISC processors.

Features

^^^^^^^^

The following lists the main features of OR1200 IP core:

- All major characteristics of the core can be set by the user

- High performance of 300 Dhrystone 2.1 MIPS at 300 MHz using 0.18u process

- High performance cache and MMU subsystems

- WISHBONE SoC Interconnection Rev. B3 compliant interface

Architecture

------------

<> below shows general architecture of OR1200 IP core. It

consists of several building blocks:

- CPU/FPU/DSP central block

- 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 host interfaces

[[core_arch_fig]]

.Core's Architecture

image::img/core_arch.gif[scaledwidth="50%",align="center"]

CPU/FPU/DSP

~~~~~~~~~~~

((CPU))/((FPU))/((DSP)) is a central part of the OR1200 RISC processor.

<> shows basic block diagram of the CPU/DSP. Not pictured

are the FPU components.  OR1200 CPU/FPU/DSP ony implements sections of

the ORBIS32 and ORFPX32 instruction set. No ((ORBIS64)), ((ORFBX64)) or

((ORVDX64)) instructions are implemented in OR1200.

[[cpu_fpu_dsp_fig]]

.CPU/FPU/DSP Block Diagram

image::img/cpu_fpu_dsp.gif[scaledwidth="50%",align="center"]

Instruction unit

^^^^^^^^^^^^^^^^

The instruction unit implements the basic instruction pipeline, fetches

instructions from the memory subsystem, dispatches them to available execution

units, and maintains a state history to ensure a precise exception model

and that operations finish in order. It also executes conditional branch

and unconditional jump instructions.

The sequencer can dispatch a sequential instruction on each clock if the

appropriate execution unit is available. The execution unit must discern

whether source data is available and to ensure that no other instruction is

targeting the same destination register.

Instruction unit handles only ((ORBIS32)) and, optionally, a subset of the

((ORFPX32)) instruction class. Some ((ORFPX32)) and all ((ORFPX3264)) and

((ORVDX64)) instruction classes are not supported by the OR1200 at present.

General-Purpose Registers

^^^^^^^^^^^^^^^^^^^^^^^^^

OpenRISC 1200 implements 32 general-purpose 32-bit ((registers)). OpenRISC 1000

architecture also support shadow copies of register file to implement fast

switching between working contexts, however this feature is not implemented

in current OR1200 implementation.

OR1200 implements general-purpose register file as two synchronous dual-port

memories with capacity of 32 words by 32 bits per word.

Load/Store Unit

^^^^^^^^^^^^^^^

The ((load/store unit (LSU))) transfers all data between the GPRs and the CPU's

internal bus. It is implemented as an independent execution unit so that stalls

in memory subsystem only affect master pipeline if there is a data dependency.

The following are LSU's main features:

- all load/store instruction implemented in hardware (atomic instructions

  included)

- address entry buffer

- pipelined operation

- aligned accesses for fast memory access

When load and store instructions are issued, the LSU determines if all

operands are available. These operands include the following:

- address register operand

- source data register operand (for store instructions)

- destination data register operand (for load instructions)

Integer Execution Pipeline

^^^^^^^^^^^^^^^^^^^^^^^^^^

(((Pipeline, Integer Execution)))

The core implements the following types of 32-bit integer instructions:

- Arithmetic instructions

- Compare instructions

- Logical instructions

- Rotate and shift instructions

Most integer instructions can execute in one cycle. For details about timing

see <>.

MAC Unit

^^^^^^^^

The ((MAC)) unit executes DSP MAC operations. MAC operations are 32x32 with

48-bit accumulator. MAC unit is fully pipelined and can accept new MAC

operation in each new clock cycle.

Floating Point Unit

^^^^^^^^^^^^^^^^^^^

(((Floating Point Unit)))

The ((FPU)) implementation is based on two other FPUs available from

OpenCores.org. For the comparison and conversion functions, parts were taken

from the FPU project by Rudolf Usselmann, and for the arithmetic operations,

the fpu100 project by Jidan Al-Eryani was converted to Verilog HDL.

All ((ORFPX32)) instructions except for ((lf.madd.s)) and ((lf.rem.s)) are

supported when the FPU is enabled in the OR1200 configuration.

System Unit

^^^^^^^^^^^

The ((system unit)) connects all other signals of the CPU/FPU/DSP that are not

connected through instruction and data interfaces. It also implements all

system special-purpose registers (e.g. supervisor register).

Exceptions

^^^^^^^^^^

Core exceptions can be generated when an exception condition occurs.

((Exception sources)) in OR1200 include the following:

- External interrupt request

- Certain memory access condition

- Internal errors, such as an attempt to execute unimplemented opcode

- System call

- Internal exception, such as breakpoint exceptions

- Arithmetic overflow

((Exception handling)) is transparent to user software and uses the same

mechanism to handle all types of exceptions. When an exception is taken,

control is transferred to an exception handler at an offset defined by for

the type of exception encountered. Exceptions are handled in supervisor mode.

Data Cache

~~~~~~~~~~

The default configuration of OR1200 data ((cache)) is 8-Kbyte, 1-way

direct-mapped data cache, which allows rapid core access to data. However

data cache can be configured according to <>.

[[data_confs_or1200_table]]

.Possible Data Cache Configurations of OR1200

[width="60%",options="header"]

|======================================================

|                                       | Direct mapped

| 16B/line, 256 lines, 1 way            | 4KB

| 16B/line, 512 lines, 1 way            | *8KB (default)*

| 16B/line, 1024 lines, 1 way           | 16KB

| 32B/line, 1024 lines, 1 way           | 32KB

|======================================================

It is possible to operate the data cache with write-through or write-back

strategies, however write-back is currently experimental.

Features:

- data cache is separate from instruction cache (Harvard architecture)

- data cache implements a least-recently used (LRU) replacement algorithm

  within each set

- the cache directory is physically addressed. The physical address tag is

  stored in the cache directory

- write-through or write-back operation

- entire cache can be disabled, lines invalidated, flushed or forced to be

  written back, by writing to cache special purpose registers

On a miss, and appropriate conditions, the cache line is filled or emptied

(written back) with 16-byte bursts. The burst fill is performed as a

critical-word-first operation; the critical word is simultaneously written

to the cache and forwarded to the requesting unit, thus minimizing stalls

due to cache fill latency. Data cache provides storage for cache tags and

performs cache line replacement function.

Data cache is tightly coupled to external interface to allow efficient

access to the system memory controller.

The data cache supplies data to the GPRs by means of a 32-bit interface

to the load/store unit. The LSU provides all logic required to calculate

effective addresses, handles data alignment to and from the data cache,

and provides sequencing for load and store operations. Write operations to

the data cache can be performed on a byte, half-word or word basis.

image::img/data_cache_diag.gif[scaledwidth="50%",align="center"]

Each line contains four contiguous words from memory that are loaded from

a cache line aligned boundary. As a result, cache lines are aligned with

page boundaries.

Instruction Cache

~~~~~~~~~~~~~~~~~

The default configuration of OR1200 instruction ((cache)) is 8-Kbyte, 1-way

direct mapped instruction cache, which allows rapid core access to

instructions. However instruction cache can be configured according to

<>.

[[inst_confs_or1200_table]]

.Possible Instruction Cache Configurations of OR1200

[width="60%",options="header"]

|==============================================

|                               | Direct mapped

| 16B/line, 32 lines, 1 way     | 512B

| 16B/line, 256 lines, 1 way    | 4KB

| 16B/line, 512 lines, 1 way    | *8KB (Default)*

| 16B/line, 1024 lines, 1 way   | 16KB

| 32B/line, 1024 lines, 1 way   | 32KB

|==============================================

Features:

- instruction cache is separate from data cache (Harvard architecture)

  (((Architecture,Harvard)))

- instruction cache implements a least-recently used (LRU) replacement

  algorithm within each set

  ((LRU))

- the ((cache directory)) is physically addressed. The physical address tag is

  stored in the cache directory

- it can be disabled or invalidated by writing to cache special purpose

  registers

On a miss, the cache is filled in with 16-byte bursts. The burst fill

is performed as a critical-word-first operation; the critical word is

simultaneously written to the cache and forwarded to the requesting unit,

thus minimizing stalls due to cache fill latency. Instruction cache provides

storage for cache tags and performs cache line replacement function.

Instruction cache is tightly coupled to external interface to allow efficient

access to the system memory controller.

The instruction cache supplies instructions to the instruction sequencer by

means of a 32-bit interface to the instruction fetch subunit. The instruction

fetch subunit provides all logic required to calculate effective addresses.

image::img/inst_cache_diag.gif[scaledwidth="50%",align="center"]

Each line contains four contiguous words from memory that are loaded from

a line-size  aligned boundary. As a result, cache lines are aligned with

page boundaries.

Data MMU

~~~~~~~~

(((MMU, Data)))

The OR1200 implements a ((virtual memory management)) scheme that

provides memory access protection and effective-to-physical address

translation. ((Protection)) granularity is as defined by OpenRISC 1000

architecture - 8-Kbyte and 16-Mbyte pages.

[[data_tlb_confs_or1200_table]]

.Possible Data TLB Configurations of OR1200

[width="60%",options="header"]

|======================================

|                       | Direct mapped

| 16 entries per way    | 16 DTLB entries

| 32 entries per way    | 32 DTLB entries

| 64 entries per way    | *64 DTLB entries (default)*

| 128 entries per way   | 128 DTLB entries

|======================================

Features:

* data MMU is separate from instruction MMU

* page size 8-Kbyte

* comprehensive page protection scheme

* direct mapped hash based translation lookaside buffer (DTLB) with the

  default of 1 way and the following features:

** miss and fault exceptions

** software tablewalk

** high performance because of hashed based design

** variable number DTLB entries with default of 64 per each way

image::img/tlb_diag.gif[scaledwidth="50%",align="center"]

The MMU hardware supports two-level software tablewalk.

Instruction MMU

~~~~~~~~~~~~~~~

(((MMU, Instruction)))

The OR1200 implements a virtual memory management scheme that provides memory

access protection and effective-to-physical address translation. Protection

granularity is as defined by OpenRISC 1000 architecture - 8-Kbyte and

16-Mbyte pages.

[[inst_tlb_confs_or1200_table]]

.Possible Instruction TLB Configurations of OR1200

[width="60%",options="header"]

|======================================

|                       | Direct mapped

| 16 entries per way    | 16 DTLB entries

| 32 entries per way    | 32 DTLB entries

| 64 entries per way    | *64 DTLB entries (default)*

| 128 entries per way   | 128 DTLB entries

|======================================

Features:

* instruction MMU is separate from data MMU

* pages size 8-Kbyte

* comprehensive page protection scheme

* 1 way direct-mapped hash based translation lookaside buffer (ITLB) with the

  following features:

** miss and fault exceptions

** software tablewalk

** high performance because of hashed based design

** Variable number of ITLB entries with default of 64 entries per way

image::img/inst_mmu_diag.gif[scaledwidth="50%",align="center"]

The MMU hardware supports two-level software tablewalk.

Programmable Interrupt Controller

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The ((interrupt)) controller receives interrupts from external sources and

forwards them as low or high priority interrupt exception to the CPU core.

[[interrupt_controller_fig]]

.Block Diagram of the Interrupt Controller

image::img/interrupt_controller.gif[scaledwidth="50%",align="center"]

Programmable interrupt controller has three special-purpose registers and 32

interrupt inputs. Interrupt input 0 and 1 are always enabled and connected

to high and low priority interrupt input, respectively.

30 other interrupt inputs can be masked and assigned low or high priority

through programming special-purpose registers.

Tick Timer

~~~~~~~~~~

OR1200 implements tick ((timer)) facility. Basically this is a timer that is

clocked by RISC clock and is used by the operating system to precisely

measure time and schedule system tasks.

OR1200 precisely follow architectural definition of the tick timer facility:

* Maximum timer count of 2^32 clock cycles

* Maximum time period of 2^28 clock cycles between interrupts

* Maskable tick timer interrupt

* Single run, restartable or continues timer

Tick timer operates from independent clock source so that doze power management

mode can be implemented.

Power Management Support

~~~~~~~~~~~~~~~~~~~~~~~~

To optimize ((power consumption)), the OR1200 provides ((low-power)) modes that

can be used to dynamically activate and deactivate certain internal modules.

OR1200 has three major features to minimize power consumption:

* Slow and Idle Modes (SW controlled clock freq reduction)

* Doze and Sleep Modes (interrupt wake-up)

[[power_consumption_table]]

.Power Consumption

[width="60%",options="header"]

|===================================================================

| Power Minimization Feature    | Approx Power Consumption Reduction

| Slow and Idle mode            | 2x - 10x

| Doze mode                     | 100x

| Sleep mode                    | 200x

| Dynamic clock gating          | N/A

|===================================================================

Slow down mode takes advantage of the low-power dividers in external clock

generation circuitry to enable full functionality, but at a lower frequency

so that a power consumption is reduced.  PMR[SDF] 4 bits are broadcasted on

pm_clksd and external clock generation for the RISC should adapt RISC clock

frequency according to the value on pm_clksd.

When software initiates the doze mode, software processing on the core

suspends. The clocks to the RISC internal modules are disabled except to

the tick timer. However any other on-chip blocks can continue to function

as normal.  The OR1200 will leave doze mode and enter normal mode when a

pending interrupt occurs.

In sleep mode, all OR1200 internal units are disabled and clocks

gated. Optionally implementation may choose to lower the operating voltage

of the OR1200 core.  The OR1200 should leave sleep mode and enter normal

mode when a pending interrupt occurs.

Dynamic ((Clock gating)) (unit clock gating on clock by clock basis) is not

supported by OR1200.

Debug unit

~~~~~~~~~~

((Debug unit)) assists software developers to debug their systems. It provides

support only for basic debugging and does not have support for more advanced

debug features of OpenRISC 1000 architecture such as watchpoints, breakpoints

and program-flow control registers.

[[debug_unit_fig]]

.Block Diagram of Debug Unit

image::img/debug_unit_diag.gif[scaledwidth="50%",align="center"]

Watchpoints and breakpoints are events triggered by program- or data-flow

matching the conditions programmed in the debug registers. Breakpoints

unlike watchpoints also suspend execution of the current program-flow and

start breakpoint exception.

Clocks & Reset

~~~~~~~~~~~~~~

The OR1200 core has a ((clock)) input each for the instruction and data Wishbone

interface logic, and for the CPU core. Clock input clk_cpu clocks everything

inside the Wishbone interfaces. Data Wishbone interface is clocked by

dwb_clk_i, instruction Wishbone interface is clocked by iwb_clk_i.

OR1200 has asynchronous ((reset)) signal. Reset signal rst, when asserted high,

immediately resets all flip-flops inside OR1200. When deasserted, OR1200

will start reset exception.

WISHBONE Interfaces

~~~~~~~~~~~~~~~~~~~

Two ((WISHBONE)) interfaces connect OR1200 core to external peripherals and

external memory subsystem. They are WISHBONE SoC Interconnection specification

Rev. B3 compliant. The implementation implements a 32-bit bus width and does

not support other bus widths.

Wishbone registered-feedback incrementing burst accesses occur when not

disabled, and cache lines are filled. The burst size (beats) is determined

by the cache line size.

image::img/wb_compatible.png[scaledwidth="30%",align="center"]

Operation

---------

This section describes the operation of the OR1200 core. For operations

that pertain to the architectural definitions, see <>.

Reset

~~~~~

OR1200 has one asynchronous ((reset)) signal that can be used by a soft and hard

reset on a higher system hierarchy levels.

[[powerup_sequence_fig]]

.Power-Up and Reset Sequence

image::img/powerup_seq.gif[scaledwidth="70%",align="center"]

<> shows how asynchronous reset is applied after

powering up the OR1200 core. Reset is connected to asynchronous reset of

almost all flip-flops inside RISC core. Special care must be taken to ensure

hold and setup times of all flip-flops compared to main RISC clock.

If system implements gated clocks, then clock gating can be used to ensure

proper reset timing.

[[powerup_sequence_gatedclk_fig]]

.Power-Up and Reset Sequence w/ Gated Clock

image::img/powerup_seq_gatedclk.gif[scaledwidth="70%",align="center"]

The address the PC assumes at hard reset (assertion of external reset signal)

is definable at synthesis time, via the OR1200_BOOT_ADR define. This is not

to be confused with the ability to set the exception prefix address with

the EPH bit.

CPU/FPU/DSP

~~~~~~~~~~~

((CPU))/((FPU))/((DSP)) is implementation of the 32-bit part of the OpenRISC

1000 architecture and only a subset of all features is implemented.

Instructions

^^^^^^^^^^^^

(((OpenRISC 1200, Instruction List)))

The following table lists the instructions implemented in the OR1200. Those

optionally implemented are indicated as such.

// The table below is split into several columns for readability by the

// preprocessing script. It is better to have this automated because

// given the pseudo-lexicographical ordering, adding a new instruction

// would require manual changes in all subsequent columns, which is

// tedious and error-prone.

//

// When changing the column headers, remember to change the script accordingly.

[[instructions_table]]

.Instructions implemented in OR1200

[width="95%",options="header"]

|=================================

| Instruction mnemonic  | Optional

| ((l.add))             |

| ((l.addc))            | Yes

| ((l.addi))            |

| ((l.and))             |

| ((l.andi))            |

| ((l.bf))              |

| ((l.bnf))             |

| ((l.div))             | Yes

| ((l.extbs))           | Yes

| ((l.extbz))           | Yes

| ((l.exths))           | Yes

| ((l.exthz))           | Yes

| ((l.extws))           | Yes

| ((l.extwz))           | Yes

| ((l.ff1))             | Yes

| ((l.fl1))             | Yes

| ((l.j))               |

| ((l.jal))             |

| ((l.jalr))            |

| ((l.jr))              |

| ((l.lbs))             |

| ((l.lbz))             |

| ((l.lhs))             |

| ((l.lhz))             |

| ((l.lws))             |

| ((l.lwz))             |

| ((l.mac))             | Yes

| ((l.maci))            | Yes

| ((l.macrc))           | Yes

| ((l.mfspr))           |

| ((l.movhi))           |

| ((l.msb))             | Yes

| ((l.mtspr))           |

| ((l.mul))             | Yes

| ((l.muli))            | Yes

| ((l.nop))             |

| ((l.or))              |

| ((l.ori))             |

| ((l.rfe))             |

| ((l.rori))            |

| ((l.sb))              |

| ((l.sfeq))            |

| ((l.sfges))           |

| ((l.sfgeu))           |

| ((l.sfgts))           |

| ((l.sfgtu))           |

| ((l.sfleu))           |

| ((l.sflts))           |

| ((l.sfltu))           |

| ((l.sfne))            |

| ((l.sh))              |

| ((l.sll))             |

| ((l.slli))            |

| ((l.sra))             |

| ((l.srai))            |

| ((l.srl))             |

| ((l.srli))            |

| ((l.sub))             | Yes

| ((l.sw))              |

| ((l.sys))             |

| ((l.trap))            |

| ((l.xor))             |

| ((l.xori))            |

| ((lf.add.s))          | Yes

| ((lf.div.s))          | Yes

| ((lf.ftoi.s))         | Yes

| ((lf.itof.s))         | Yes

| ((lf.mul.s))          | Yes

| ((lf.sfeq.s))         | Yes

| ((lf.sfge.s))         | Yes

| ((lf.sfgt.s))         | Yes

| ((lf.sfle.s))         | Yes

| ((lf.sflt.s))         | Yes

| ((lf.sfne.s))         | Yes

| ((lf.sub.s))          | Yes

|=================================

For a complete description of each instruction's format refer to

<>.

Instruction Unit

^^^^^^^^^^^^^^^^

((Instruction unit)) generates instruction fetch effective address and fetches

instructions from instruction cache. Each clock cycle one instruction can

be fetched. Instruction fetch EA is further translated into physical address

by IMMU.

General-Purpose Registers

^^^^^^^^^^^^^^^^^^^^^^^^^

((General-purpose register)) file can supply two read operands each clock cycle

and store one result in a destination register.

GPRs can be also read and written through development interface.

Load/Store Unit

^^^^^^^^^^^^^^^

((LSU)) can execute one load instruction every two clock cycles assuming load

instruction have a hit in the data cache. Execution of store instructions

takes one clock cycle assuming they have a hit in the data cache.

LSU performs calculation of the load/store effective address. EA is further

translated into physical address by DMMU.

Load/store effective address and load and store data can be also accessed

through development interface.

Integer Execution Pipeline

^^^^^^^^^^^^^^^^^^^^^^^^^^

(((Pipeline, Integer Execution)))

The core implements the following types of 32-bit integer instructions:

* Arithmetic instructions

* Compare instructions

* Logical instructions

* Rotate and shift instructions

[[exec_time_int_table]]

.Execution Time of Integer Instructions

[width="70%",options="header"]

|================================================

| Instruction Group     | Clock Cycles to Execute

| Arithmetic except Multiply/Divide     | 1

| Multiply                              | 3

| Divide                                | 32

| Compare                               | 1

| Logical                               | 1

| Rotate and Shift                      | 1

| Others                                | 1

|================================================

<> lists execution times for instructions executed by

integer execution pipeline. Most instructions are executed in one clock cycle.

Integer multiply can be either serial or parallel implementations. Serial

operations require one clock cycle per bit of operand, which is 32-cycles

on the OR1200. At present no synthesis tools support division operators,

and so the serial option must be used.

MAC Unit

^^^^^^^^

((MAC)) unit executes l.mac instructions. MAC unit implements 32x32 fully

pipelined multiplier and 48-bit accumulator. MAC unit can accept one new

l.mac instruction each clock cycle.

Care should be taken when executing l.macrc (MAC read and clear) too soon

after the final l.mac instruction as the operation may still be underway

and the result will not be valid in time. It is recommended at least 3 other

instructions (or just l.nops) are inserted between the final l.mac and l.macrc.

Floating Point Unit

^^^^^^^^^^^^^^^^^^^

The ((floating point unit)) has a mechanism to stall the processor pipeline

until processing has completed.

The following table indicates the number of cycles per operation

[[exec_time_fp_table]]

.Execution time of floating point instructions

[width="60%",options="header"]

|=======================

| Operation     | Cycles

| Add/subtract  | 10

| Multiply      | 38

| Divide        | 37

| Compare       | 2

| Convert       | 7

|=======================

System Unit

^^^^^^^^^^^

((System unit)) implements system control and status special-purpose registers

and executes all l.mtspr/l.mfspr instructions.

Exceptions

^^^^^^^^^^

The core implements a precise ((exception model)). This means that when an

exception is taken, the following conditions are met:

* Subsequent instructions in program flow are discarded

* Previous instructions finish and write back their results

* The address of faulting instruction is saved in EPCR registers and the

  machine state is saved to ESR registers

[[exceptions_table]]

.List of Implemented ((Exceptions))

[width="95%",options="header"]

|===========================================================

| Exception Type        | Vector Offset | Causing Conditions

| Reset                 | 0x100 | Caused by reset.

| Bus Error             | 0x200 | Caused by an attempt to access invalid

  physical address.

| Data Page Fault       | 0x300 | Generated artificially by DTLB miss exception

  handler when no matching PTE found in page tables or page protection

  violation for load/store operations.

| Instruction Page Fault| 0x400 | Generated artificially by ITLB miss exception

  handler when no matching PTE found in page tables or page protection violation

  for instruction fetch.

| Low Priority External Interrupt       | 0x500 | Low priority external

  interrupt asserted.

| Alignment     | 0x600 | Load/store access to naturally not aligned location.

| Illegal Instruction   | 0x700 | Illegal instruction in the instruction stream.

| High Priority External Interrupt      | 0x800 | High priority external

  interrupt asserted.

| D-TLB Miss    | 0x900 | No matching entry in DTLB (DTLB miss).

| I-TLB Miss    | 0xA00 | No matching entry in ITLB (ITLB miss).

| Range         | 0xB00 | If programmed in the SR, the setting of  SR[OV],

  usually by an arithmetic instruction, causes a range exception.

| System Call   | 0xC00 | System call initiated by software.

| Floating point exception      | 0xD00 | FP operation caused flags in FPCSR to

  become set.

| Trap  | 0xE00 | Trap instruction was decoded

|===========================================================

The OR1200 exception support does not include support for range exceptions

or fast context switching.

Data Cache Operation

~~~~~~~~~~~~~~~~~~~~

Data Cache Load/Store Access

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Load/store unit requests data from the data ((cache)) and stores them into

the general-purpose register file and forwards them to integer execution

units. Therefore LSU is tightly coupled with the data cache.

If there is no data cache line miss nor ((DTLB)) miss, load operations take

two clock cycles to execute and store operations take one clock cycle to

execute. LSU does all the data alignment work.

Data can be written to the data cache on a word, half-word or byte basis. Since

data cache only operates in write-through mode, all writes are immediately

written back to main memory or to the next level of caches.

[[wb_write_fig]]

.WISHBONE Write Cycle

image::img/wb_write.gif[scaledwidth="70%",align="center"]

<> shows how a ((write-through)) cycle on data WISHBONE interface

is performed when a store instruction hits in the data cache.  If +dwb_ERR_I+

or +dwb_RTY_I+ is asserted instead of usual +dwb_ACK_I+, bus error exception

is invoked.

Data Cache Line Fill Operation

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When executing load instruction and a cache miss occurs, depending on whether

the cache uses ((write-through)) or ((write-back)) strategy and the line

is clean or invalid, a 4 beat sequential read burst with critical word

first is performed. If the strategy is write-back and the line is dirty,

the line is first written back to memory. The critical word is forwarded to

the load/store unit to minimize performance loss because of the cache miss.

[[wb_read_fig]]

.WISHBONE Block Read Cycle

image::img/wb_read.gif[scaledwidth="70%",align="center"]

<> shows how a cache line is read in WISHBONE read block cycle

composed out of four read transfers.  If +dwb_ERR_I+ or +dwb_RTY_I+ is asserted

instead of usual +dwb_ACK_I+, bus error exception is invoked.

When executing a store instruction with the cache in write-through strategy,

and a cache miss occurs, the write is simply put on the bus and no caching

occurs. If it is a miss and the cache is in write back strategy and the line

is valid and clean or invalid,  a 4 beat sequential read burst to fill the

line is performed, and the the write to cache occurs. If storing and a cache

miss occurs, and the desired line is valid and dirty, it is first written

back to memory before the desired line is read.

[[wb_rw_fig]]

.WISHBONE Block Read/Write Cycle

image::img/wb_rw.gif[scaledwidth="70%",align="center"]

<> shows how a cache line is read in WISHBONE read block cycle

followed by a write transfer.  If +dwb_ERR_I+ or +dwb_RTY_I+ is asserted instead

of usual +dwb_ACK_I+, bus error exception is invoked.

Cache/Memory Coherency

^^^^^^^^^^^^^^^^^^^^^^

Data cache in OR1200 operates in either write-through or write-back mode,

definable at synthesis time, for default use, and runtime when DMMU is

used. There is currently no ((coherency)) support between local data cache and

caches of other processors.

Data Cache Enabling/Disabling

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Data cache is disabled at power up. Entire data cache can be enabled by setting

bit SR[DCE] to one. Before data cache is enabled, it must be invalidated.

Data Cache Invalidation

^^^^^^^^^^^^^^^^^^^^^^^

Data cache in OR1200 does not support ((invalidation)) of entire data

cache. Normal procedure to invalidate entire data cache is to cycle through

all data cache lines and invalidate each line separately.

Data Cache Locking

^^^^^^^^^^^^^^^^^^

Data cache implements way ((locking)) bits in data cache control register

DCCR. Bits LWx lock individual ways when they are set to one.

Data Cache Line Prefetch

^^^^^^^^^^^^^^^^^^^^^^^^

Data cache line ((prefetch)) is optional in the OpenRISC 1000 architecture and

is not implemented in OR1200.

Data Cache Line ((Flush))

^^^^^^^^^^^^^^^^^^^^^^^^^

Operation is performed by writing effective address to the DCBFR register.

When a cache line is valid and clean, or the cache is in write-through

strategy, the line is invalidated and no write-back occurs.

Data Cache Line Invalidate

^^^^^^^^^^^^^^^^^^^^^^^^^^

Data cache line ((invalidate)) invalidates a single data cache line. Operation

is performed by writing effective address to the DCBIR register.  If cache

is in write-back strategy, it is best to use the line flush function.

Data Cache Line ((Write-back))

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Operation is performed by writing effective address to the DCBWR register.

If cache is in ((write-through)) strategy, this operation is ignored as no

lines will be cached and dirty, capable of being written back.

Data Cache Line ((Lock))

^^^^^^^^^^^^^^^^^^^^^^^^

Locking of individual data cache lines is not implemented in OR1200.

Data Cache ((inhibit)) with address bit 31 set

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If DMMU is disabled, by default all addresses with bit 31 of the address

asserted high will cause the data cache to be inhibited, meaning no reads

or writes are cached.

If the ((DMMU)) is enabled, it is possible for any address to be inhibited

or not, and in these modes the cache behaves accordingly.

Instruction ((Cache)) Operation

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Instruction Cache Instruction ((Fetch)) Access

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Instruction unit requests instruction from the instruction cache and forwards

them to the instruction queue inside instruction unit. Therefore instruction

unit is tightly coupled with the instruction cache.

If there is no instruction cache line ((miss)) nor ITLB miss, instruction fetch

operation takes one clock cycle to execute.