528 lines
18 KiB
Plaintext
528 lines
18 KiB
Plaintext
mor1kx IP core specification
|
|
============================
|
|
:doctype: book
|
|
|
|
Introduction
|
|
------------
|
|
|
|
This document describes the mor1kx processor block and its various configurable
|
|
components. The core is an implementation of an OpenRISC 1000 compliant
|
|
processor which is highly configurable and contains multiple pipeline
|
|
implementations along with a configurable set of peripherals such as caches,
|
|
timers, debug and bus interfaces. This documentation will contain a section
|
|
detailing each optional block such as pipeline, caches, bus interface etc. It
|
|
can outline as much implementation detail as it wants but should ultimately
|
|
provide information to users on how to program and use the peripheral, or what
|
|
to expect during execution of software on a particular configuration.
|
|
|
|
.Document Status
|
|
******************************************************************************
|
|
This documentation is far from complete. It is expected that the documentation
|
|
will become more extensive over time.
|
|
******************************************************************************
|
|
|
|
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.
|
|
|
|
mor1kx CPU
|
|
~~~~~~~~~~
|
|
|
|
The mor1kx implementation was developed in order to provide a better platform
|
|
for processor component development than previous implementations. The goal of
|
|
the implementation is to provide a greater level of flexibility in terms of
|
|
implementation trade-offs such as area and performance.
|
|
|
|
The blocks within the core have been designed for maximum re-use within
|
|
different configurations. Based on this, different pipeline implementations are
|
|
a major focus of the core. With this, the core should be very useful for
|
|
developers and users alike. For developers as a base for either
|
|
high-performance or low-overhead pipeline implementations based on re-usable
|
|
components eg. decode and ALU block. For users as a wider variety of
|
|
capabilities should be available to suit the processor's use case.
|
|
|
|
Implementation Overview
|
|
-----------------------
|
|
|
|
The implementation is heavily modular, with each particular functional block
|
|
of the design being contained within its own Verilog module or modules.
|
|
|
|
The implementation configuration makes use of Verilog parameters. There should
|
|
be no configuration performed with the use of Verilog defines.
|
|
|
|
Hierarchy
|
|
~~~~~~~~~
|
|
|
|
The top few levels of hierarchy are as follows
|
|
|
|
mor1kx:: Top-level, instantiatng bus interfaces and CPU top-level
|
|
* mor1kx_bus_if_xx - Bus interface, depending on desired bus standard
|
|
* mor1kx_cpu - Pipeline implementation wrapper
|
|
** mor1kx_cpu_xx - Pipeline implementation, depending on configuration
|
|
*** mor1kx_fetch_xx - Pipeline-implementation-dependent fetch stage
|
|
**** mor1kx_icache - Instruction cache implementation
|
|
**** mor1kx_immu - Instruction memory management unit implementation
|
|
*** mor1kx_decode - Generic decode stage
|
|
*** mor1kx_execute_alu - Generic ALU for execute stage
|
|
*** mor1kx_lsu_xx - Pipeline-implementation-dependent load/store unit
|
|
**** mor1kx_dcache - Data cache implementation
|
|
**** mor1kx_dmmu - Data memory management unit implementation
|
|
*** mor1kx_wb_mux_xx - Pipeline-implementation-dependent writeback stage mux
|
|
*** mor1kx_rf_xx - Pipeline-implementation-dependent register file
|
|
*** mor1kx_ctrl_xx - Pipeline-implementation-dependent control stage, usually containing features such as tick timer, interrupts etc.
|
|
|
|
|
|
The above hierarchy is not always the same for each pipeline implementation
|
|
(from _mor1kx_cpu_xx_ level down) but as a good indicator as to how the
|
|
existing pipeline implementations have been structured.
|
|
|
|
Coding Style
|
|
~~~~~~~~~~~~
|
|
|
|
The coding style is a relatively simple Verilog style and should be adhered to
|
|
for any future development. All of the following detail how the existing code
|
|
base has been implemented, and it should be realtively easy to continue in that
|
|
style, but if in doubt, the following details some of the rules:
|
|
|
|
* module names should be prefixed with _mor1kx_ and be in lowercase and stored in a source file of the same name plus the standard verilog suffix, _.v_.
|
|
* port names should have their direction abbreviation appended to the name
|
|
** E.g the instruction bus address output should be ibus_adr_o
|
|
** The only exceptions are the clock and reset ports, commonly referred to as _clk_ and _rst_ in the Verilog, and don't really require direction suffixes. The only exception is if a clock or reset generation module is outputting one of these, in which case it should have _o appended, otherwise for clock and reset inputs it can be inferred that they are inputs from the absence of _o.
|
|
* Parameter names should be in UPPERCASE, with parameter values, if strings, also in uppercase.
|
|
* Verilog reg and wire names should be named usefully, in lowercase, and make use of underscores in the name.
|
|
* There should be no reason to alter the mor1kx-defines.v or mor1kx-sprs.v files unless it is expanding upon or fixing what is already there. _No new class of defines controlling implementation should be added_ (use parameters instead!) Those files are only for storing architectural information in Verilog format, which can then be used in the design.
|
|
|
|
There has been heavy use of the Emacs Verilog mode auto-implement and wire
|
|
features throughout the code. This is a useful tool and it would be useful to
|
|
stick to using this for future pipeline implementations, to speed up the
|
|
tedious task of wiring up new blocks.
|
|
|
|
|
|
Architecture compliance
|
|
~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The mor1kx aims to be fully OpenRISC 1000 compliant. It implements the VR2,
|
|
AVR and ISRs (still largely unused). The current OR1K architecture version
|
|
supported is 1.0.
|
|
|
|
Version Register 2 definition
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Bits 23:0 of the VR2 are implementation-specific. They are defined, for mor1kx,
|
|
to be 3 bytes, interpreted as 3 unsigned 8-bit integers, as the following:
|
|
|
|
* 23:16 - Major version number
|
|
* 15:8 - Minor version number
|
|
* 7:0 - Pipeline identifier
|
|
** Where this pipeline identifier means
|
|
*** 1 - Cappuccino
|
|
*** 2 - Espresso
|
|
*** 3 - Pronto Espresso
|
|
|
|
However, the mor1kx does not implement the following at present:
|
|
|
|
* arithmetic exception control/status registers (AECR, AESR)
|
|
* l.muld[u] and thus access to full 64-bit result as there is no MAC unit
|
|
|
|
CPU Components
|
|
==============
|
|
|
|
This section will outline each of the CPU component modules.
|
|
|
|
CPU Pipeline Implementations
|
|
----------------------------
|
|
|
|
Available Implementations
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
At present the following pipeline implementations are available. These
|
|
combine various of the components, outlined in a following section, to
|
|
implement the bulk of the processor.
|
|
|
|
- cappuccino - 6 stage, single issue, delay slot, debug unit, timers, PIC,
|
|
tightly coupled cache, MMU, ORBIS32 support
|
|
- espresso - 2 stage, single issue, delay slot, debug unit, timers, PIC, ORBIS32 support
|
|
- pronto espresso - 2 stage, single issue, no delay slot, debug unit, timers, PIC, ORBIS32 support
|
|
|
|
Cappuccino pipeline
|
|
~~~~~~~~~~~~~~~~~~~
|
|
|
|
A 6 stage pipeline. (address, fetch, decode, execute, control/memory and writeback)
|
|
|
|
Caches supported (optional).
|
|
|
|
MMUs supported (optional).
|
|
|
|
It has a delay slot on jump and branch instructions.
|
|
|
|
It features the EVBAR.
|
|
|
|
Pipeline consists of the following modules:
|
|
|
|
* Fetch:
|
|
** <<mor1kx_icache,mor1kx_icache>>
|
|
** <<mor1kx_immu,mor1kx_immu>>
|
|
** <<mor1kx_fetch_cappuccino,mor1kx_fetch_cappuccino>>
|
|
* Decode
|
|
** <<mor1kx_decode,mor1kx_decode>>
|
|
* Execute stage
|
|
** <<mor1kx_execute_alu,mor1kx_execute_alu>>
|
|
** <<mor1kx_wb_mux_cappuccino,mor1kx_wb_mux_cappuccino>>
|
|
** <<mor1kx_rf_cappuccino,mor1kx_rf_cappuccino>>
|
|
** <<mor1kx_execute_ctrl_cappuccino,mor1kx_execute_ctrl_cappuccino>>
|
|
* Control/memory stage
|
|
** <<mor1kx_dcache,mor1kx_dcache>>
|
|
** <<mor1kx_dmmu,mor1kx_dmmu>>
|
|
** <<mor1kx_lsu_cappuccino,mor1kx_lsu_cappuccino>>
|
|
** <<mor1kx_ctrl_cappuccino,mor1kx_ctrl_cappuccino>>
|
|
** <<mor1kx_ctrl_branch_cappuccino,mor1kx_ctrl_branch_cappuccino>>
|
|
|
|
The following sections outline the pipeline-specific modules
|
|
|
|
[[mor1kx_ctrl_branch_cappuccino]]
|
|
mor1kx_ctrl_branch_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is the pipelines branch control unit, selecting the jump/branch address
|
|
and opcode input from execute stage, with flag input from control stage.
|
|
Indication of whether a branch needs to be evaluated (based on flag) comes
|
|
from the control stage.
|
|
|
|
The block then outputs the appropriate indication of whether a branch is going
|
|
to occur and the target address to the fetch stage.
|
|
|
|
It is wholly combinatorial.
|
|
|
|
[[mor1kx_ctrl_cappuccino]]
|
|
mor1kx_ctrl_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This module contains a lot of the core functionality of the pipeline, such as:
|
|
|
|
* SPRs (NPC, PPC, etc.) and accesses to them
|
|
* PIC
|
|
* Debug unit
|
|
* Tick timer
|
|
* Pipeline control signals
|
|
** Advance/stall signaling to each pipeline stage
|
|
** Exception handling
|
|
|
|
It's in a big monolithic file but perhaps things like the PIC and tick timer
|
|
could be split out and made genering among pipeline implementations.
|
|
|
|
[[mor1kx_execute_ctrl_cappuccino]]
|
|
mor1kx_execute_ctrl_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Determine the status of execute-stage units in play (ALU or LSU) and:
|
|
|
|
* Determine when they're done
|
|
* Control the write-enable to the register file for any result
|
|
* Correctly propagate exception signals from either execute or earlier stages
|
|
|
|
[[mor1kx_fetch_cappuccino]]
|
|
mor1kx_fetch_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Fetch stage, tightly coupled with instruction cache.
|
|
|
|
[[mor1kx_lsu_cappuccino]]
|
|
mor1kx_lsu_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Load/store unit.
|
|
|
|
Performs accesses of the generic bus which may or may not be then going to
|
|
a data cache, and finally out onto the bus via the selected bus interface.
|
|
|
|
Is 32-bit specific.
|
|
|
|
Combinatorial outputs to pipeline control logic to reduce latency, may
|
|
introduce long paths effecting timing, though.
|
|
|
|
Handles sign extension if load/store requires it.
|
|
Generates alignment exception, and handles bus error exception back to
|
|
the mor1kx_execute_ctrl_cappuccino module.
|
|
|
|
[[mor1kx_rf_cappuccino]]
|
|
mor1kx_rf_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Register file for the pipeline. 2 lots of 32 general purpose registers (GPRs.)
|
|
|
|
Handles forwarding from control/memory and writeback to execute stage.
|
|
|
|
Instantiates a RAM for each of the two register files (_mor1kx_rf_ram_ module.)
|
|
|
|
[[mor1kx_wb_mux_cappuccino]]
|
|
mor1kx_wb_mux_cappuccino
|
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Writeback stage mux. Inputs are ALU result, LSU result, SPR value for l.mfspr
|
|
instruction. Generates link address for jump-and-link instructions.
|
|
|
|
|
|
Espresso pipeline
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
The espresso pipeline essentially contains two stages: a fetch and "the-rest"
|
|
stages. There is no registering in the decode stage, so the register outputting
|
|
the fetched instruction from the fetch stage is what is used for the remainder
|
|
of that instruction's processing.
|
|
|
|
No support for caches.
|
|
|
|
It has a delay slot.
|
|
|
|
Supports DSX bit in SR.
|
|
|
|
Pipeline consists of the following modules:
|
|
|
|
* Fetch:
|
|
** <<mor1kx_fetch_espresso,mor1kx_fetch_espresso>>
|
|
* Decode
|
|
** <<mor1kx_decode,mor1kx_decode>>
|
|
* Execute/memory stage
|
|
** <<mor1kx_execute_alu,mor1kx_execute_alu>>
|
|
** <<mor1kx_lsu_espresso,mor1kx_lsu_espresso>>
|
|
** <<mor1kx_wb_mux_espresso,mor1kx_wb_mux_espresso>>
|
|
** <<mor1kx_rf_espresso,mor1kx_rf_espresso>>
|
|
* Control stage
|
|
** <<mor1kx_ctrl_espresso,mor1kx_ctrl_espresso>>
|
|
|
|
The following sections outline the pipeline-specific modules
|
|
|
|
[[mor1kx_fetch_espresso]]
|
|
mor1kx_fetch_espresso
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is the fetch stage for the espresso pipeline.
|
|
|
|
It is tightly coupled with the control stage.
|
|
|
|
The block attempts to stream in bursts from the bus interface.
|
|
|
|
The block outputs register addresses for the next read from the RF.
|
|
|
|
[[mor1kx_lsu_espresso]]
|
|
mor1kx_lsu_espresso
|
|
^^^^^^^^^^^^^^^^^^^
|
|
|
|
A LSU specific to the espresso pipeline. Its features are similar to the
|
|
<<mor1kx_lsu_cappuccino,mor1kx_lsu_cappuccino>> block.
|
|
|
|
[[mor1kx_wb_mux_espresso]]
|
|
mor1kx_wb_mux_espresso
|
|
^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
Writeback stage mux for the espresso pipeline. Similar to the
|
|
<<mor1kx_wb_mux_cappuccino,mor1kx_wb_mux_cappuccino>> block.
|
|
|
|
[[mor1kx_rf_espresso]]
|
|
mor1kx_rf_espresso
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
Register file for the espresso pipeline. Simlar to the
|
|
<<mor1kx_rf_cappuccino,mor1kx_rf_cappuccino>> block.
|
|
|
|
[[mor1kx_ctrl_espresso]]
|
|
mor1kx_ctrl_espresso
|
|
^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This module contains a lot of the core functionality of the pipeline, such as:
|
|
|
|
* SPRs (NPC, PPC, etc.) and accesses to them
|
|
* PIC
|
|
* Debug unit
|
|
* Tick timer
|
|
* Pipeline control signals
|
|
** Advance/stall signaling to each pipeline stage
|
|
** Exception handling
|
|
** Branch indication to fetch stage
|
|
** Register file write enable
|
|
|
|
|
|
Pronto Espresso pipeline
|
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
The pronto espresso pipeline essentially contains two stages: a fetch and "the-rest"
|
|
stages. It is based on the Espresso pipeline, but does not have a delay slot on jumps
|
|
and branches. As such, it reuses a lot of Espresso's pipeline.
|
|
|
|
No support for caches.
|
|
|
|
It has _no_ delay slot.
|
|
|
|
Pipeline consists of the following modules:
|
|
|
|
* Fetch:
|
|
** <<mor1kx_fetch_prontoespresso,mor1kx_fetch_prontoespresso>>
|
|
* Decode
|
|
** <<mor1kx_decode,mor1kx_decode>>
|
|
* Execute/memory stage
|
|
** <<mor1kx_execute_alu,mor1kx_execute_alu>>
|
|
** <<mor1kx_lsu_espresso,mor1kx_lsu_espresso>>
|
|
** <<mor1kx_wb_mux_espresso,mor1kx_wb_mux_espresso>>
|
|
** <<mor1kx_rf_espresso,mor1kx_rf_espresso>>
|
|
* Control stage
|
|
** <<mor1kx_ctrl_prontoespresso,mor1kx_ctrl_prontoespresso>>
|
|
|
|
The following sections outline the pipeline-specific modules
|
|
|
|
[[mor1kx_fetch_prontoespresso]]
|
|
mor1kx_fetch_prontoespresso
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This is the fetch stage for the pronto espresso pipeline
|
|
|
|
It is tightly coupled with the control stage.
|
|
|
|
The block attempts to stream in bursts from the bus interface.
|
|
|
|
The block outputs register addresses for the next read from the RF.
|
|
|
|
It takes into account that the pipeline does not support a delay slot on jumps/branches.
|
|
|
|
[[mor1kx_ctrl_prontoespresso]]
|
|
mor1kx_ctrl_prontoespresso
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
|
|
This module contains a lot of the core functionality of the pipeline, such as:
|
|
|
|
* SPRs (NPC, PPC, etc.) and accesses to them
|
|
* PIC
|
|
* Debug unit
|
|
* Tick timer
|
|
* Pipeline control signals
|
|
** Advance/stall signaling to each pipeline stage
|
|
** Exception handling
|
|
** Branch indication to fetch stage
|
|
** Register file write enable
|
|
|
|
It is based on the espresso pipeline, however is modified in such a way as to make sure it doesn't have a delay slot on branches.
|
|
|
|
Components
|
|
----------
|
|
|
|
[[mor1kx_bus_if_wb32]]
|
|
mor1kx_bus_if_wb32
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
This module is a Wishbone bus interface block and sits between the pipeline's
|
|
fetch and load/store units and the Wishbone bus.
|
|
|
|
It is Wishbone version B3 compliant and can perform burst reads.
|
|
|
|
At present there are two configurations of the block, one is "classic"
|
|
configuration and the other is "B3 read bursting".
|
|
|
|
The "classic" configuration performs all access as single cycle reads or
|
|
writes to the bus.
|
|
|
|
The "B3 read bursting" mode will perform burst reads over the bus, but writes
|
|
are still single cycle accesses.
|
|
|
|
[[mor1kx_cpu]]
|
|
mor1kx_cpu
|
|
~~~~~~~~~~
|
|
|
|
The CPU pipeline wrapper layer. This selects the appropriate pipeline CPU
|
|
implementation toplevel.
|
|
|
|
Additionally, some signals intended to be used as hooks for monitor modules are
|
|
provided.
|
|
|
|
[[mor1kx_decode]]
|
|
mor1kx_decode
|
|
~~~~~~~~~~~~~
|
|
|
|
This is a generic OR1K decode stage module, which can ideally be reused by each
|
|
CPU implementation.
|
|
|
|
The module can either register the its decode output or be wholly combinatorial.
|
|
|
|
It generates ALU, LSU and control operation signals for the remainder of the pipeline
|
|
units. Exceptions caused in this stage (ie, illegal instruction, system call etc.) or
|
|
earlier (fetch stage exceptions like bus error) are also generated or passed through.
|
|
|
|
[[mor1kx_execute_alu]]
|
|
mor1kx_execute_alu
|
|
~~~~~~~~~~~~~~~~~~
|
|
|
|
This is a generic ALU implementation. It contains all of the integer arithmetic and
|
|
logical operations which are supported in the ORBIS32 instruction set.
|
|
|
|
The following features are optional. All can be disabled, or enabled with the
|
|
implementation options listed, if any:
|
|
|
|
* Multiplier
|
|
** Three stage, three cycle, full 32-bit parallel multiplier
|
|
** Serial, 32-cycle serial multiplication implementation
|
|
** Simulation, single cycle multiplication, not advisable for synthesis
|
|
* Divider
|
|
** Serial, 32-cycle serial division implementation
|
|
** Simulation, single cycle division, not synthesisable
|
|
* Shift-right-arithmetic
|
|
* Rotate right
|
|
* Shift instructions, logical shift left and right, and shift right arithmetic and rotate right can be chosen to be implemented in a single-cycle barrel shifter implementation or done serially to save implementation area.
|
|
* Conditional move
|
|
* Find first and last '1'
|
|
|
|
The following is not yet supported:
|
|
|
|
* Add with carry
|
|
* Sign extension instructions
|
|
|
|
The module also implements comparison logic for the set flag instructions.
|
|
|
|
|
|
[[mor1kx_icache]]
|
|
mor1kx_icache
|
|
~~~~~~~~~~~~~
|
|
|
|
Instruction cache module.
|
|
|
|
[[mor1kx_dcache]]
|
|
mor1kx_dcache
|
|
~~~~~~~~~~~~~
|
|
|
|
Data cache module.
|
|
|
|
|
|
[[mor1kx_immu]]
|
|
mor1kx_immu
|
|
~~~~~~~~~~~
|
|
|
|
Instruction memory management module.
|
|
|
|
[[mor1kx_dmmu]]
|
|
mor1kx_dmmu
|
|
~~~~~~~~~~~
|
|
|
|
Data memory management module.
|
|
|
|
[[mor1kx_rf_ram]]
|
|
mor1kx_rf_ram
|
|
~~~~~~~~~~~~~
|
|
|
|
[[mor1kx_spram]]
|
|
mor1kx_spram
|
|
~~~~~~~~~~~~
|
|
|
|
Generic single port ram with seperate read and write addresses. +
|
|
Has explicit bypass logic to correctly present write-first behaviour on
|
|
different platforms.
|
|
|
|
[[mor1kx_dpram_sclk]]
|
|
mor1kx_dpram_sclk
|
|
~~~~~~~~~~~~~~~~~
|
|
|
|
Generic single clocked dual port ram.
|