OpenRISC 1200 IP Core Specification (Preliminary Draft)

The following lists the main features of OR1200 IP core:

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.

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.

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:

When load and store instructions are issued, the LSU determines if all operands are available. These operands include the following:

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

Most integer instructions can execute in one cycle. For details about timing see Table 3.2, “Execution Time of Integer Instructions”.

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.

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.

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

Core exceptions can be generated when an exception condition occurs. Exception sources in OR1200 include the following:

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.

The following table lists the instructions implemented in the OR1200. Those optionally implemented are indicated as such.

For a complete description of each instruction’s format refer to [or1000_manual].

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

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.

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

Table 3.2, “Execution Time of Integer Instructions” 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 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.

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

System unit implements system control and status special-purpose registers and executes all l.mtspr/l.mfspr instructions.

The core implements a precise exception model. This means that when an exception is taken, the following conditions are met:

The OR1200 exception support does not include support for range exceptions or fast context switching.

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.

Figure 3.3. WISHBONE Write Cycle

Figure 3.3, “WISHBONE Write Cycle” 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.

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.

Figure 3.4. WISHBONE Block Read Cycle

Figure 3.4, “WISHBONE Block Read Cycle” 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.

Figure 3.5. WISHBONE Block Read/Write Cycle

Figure 3.5, “WISHBONE Block Read/Write Cycle” 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.

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 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 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 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 is optional in the OpenRISC 1000 architecture and is not implemented in OR1200.

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

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.

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

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

Instruction cache cannot be explicitly modified like data cache can be with store instructions.

On a cache miss, a 4 beat sequential read burst with critical word first is performed. Critical word is forwarded to the instruction unit to minimize performance loss because of the cache miss.

Figure 3.6. WISHBONE Block Read Cycle

Figure 3.6, “WISHBONE Block Read Cycle” shows how a cache line is read in WISHBONE read block cycle composed out of four read transfers. If iwb_ERR_I or iwb_RTY_I is asserted instead of usual dwb_ACK_I, bus error exception is invoked.

OR1200 is not intended for use in multiprocessor environments. Therefore no support for coherency between local instruction cache and caches of other processors or main memory is implemented.

Instruction cache is disabled at power up. Entire instruction cache can be enabled by setting bit SR[ICE] to one. Before instruction cache is enabled, it must be invalidated.

Instruction cache in OR1200 does not support invalidation of entire instruction cache. Normal procedure to invalidate entire instruction cache is to cycle through all instruction cache lines and invalidate each line separately.

Instruction cache implements way locking bits in instruction cache control register ICCR. Bits LWx lock individual ways when they are set to one.

Instruction cache line prefetch is optional in the OpenRISC 1000 architecture and is not implemented in OR1200.

Instruction cache line invalidate invalidates a single instruction cache line. Operation is performed by writing effective address to the ICBIR register.

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

Load/store address translation can be disabled by clearing bit SR[DME]. If translation is disabled, then physical address used to access data cache and optionally provided on dwb_ADDR_O, is the same as load/store effective address.

Load/store address translation can be enabled by setting bit SR[DME]. If translation is enabled, it provides load/store effective address to physical address translation and page protection for memory accesses.

Figure 3.7. 32-bit Address Translation Mechanism using Two-Level Page Table

In OR1200 case, page tables must be managed by operating system’s virtual memory management subsystem. Figure 3.7, “32-bit Address Translation Mechanism using Two-Level Page Table” shows address translation using two-level page table. Refer to [or1000_manual] for one-level page table address translation as well as for details about address translation and page table content.

DMMUCR is not implemented in OR1200. Therefore page table base pointer (PTBP) must be stored in software variable. Flush of entire DTLB must be performed by software flush of every DTLB entry separately. Software flush is performed by manually writing bits from the TLB entries back to PTEs.

After a virtual address is determined to be within a page covered by the valid PTE, the access is validated by the memory protection mechanism. If this protection mechanism prohibits the access, a data page fault exception is generated.

The memory protection mechanism allows selectively granting read access and write access for both supervisor and user modes. The page protection mechanism provides protection at all page level granularities.

Table 3.5, “Protection Attributes for Load/Store Accesses” lists page protection attributes defined in DTLBWyTR pregister. For the individual page appropriate strategy out of seven possible strategies programmed with the PPI field of the PTE. Because OR1200 does not implement DMMUPR, translation of PTE[PPI] into suitable set of protection bits must be performed by software and written into DTLBWyTR.

OR1200 does not implement DTLB entry reloads in hardware. Instead software routine must be used to search page table for correct page table entry (PTE) and copy it into the DTLB. Software is responsible for maintaining accessed and dirty bits in the page tables.

When LSU computes load/store effective address whose physical address is not already cached by DTLB, a DTLB miss exception is invoked.

DTLB reload routine must load the correct PTE to correct DTLBWyMR and DTLBWyTR register from one of possible DTLB ways.

Special-purpose register DTLBEIR must be written with the effective address and corresponding DTLB entry will be invalidated in the local DTLB.

Since all DTLB entry reloads are performed in software, there is no hardware locking of DTLB entries. Instead it is up to the software reload routine to avoid replacing some of the entries if so desired.

Dirty (D) attribute is not implemented in OR1200 DTLB. It is up to the operating system to generate dirty attribute bit with page protection mechanism.

Accessed (A) attribute is not implemented in OR1200 DTLB. It is up to the operating system to generate accessed attribute bit with page protection mechanism.

Weakly ordered memory (WOM) attribute is not needed in OR1200 because all memory accesses are serialized and therefore this attribute is not implemented.

Write-back cache (WBC) attribute is not implemented as the data cache cannot be configured at run time to be write-back enabled if write-through strategy was selected at synthesis-time.

Caching-inhibited (CI) attribute is not implemented in OR1200 DTLB. Cached and uncached regions are divided by bit 30 of data effective address.

Uncached accesses must be performed when I/O registers are memory mapped and all reads and writes must be always performed directly to the external interface and not to the data cache.

Instruction fetch address translation can be disabled by clearing bit SR[IME]. If translation is disabled, then physical address used to access instruction cache and optionally provided on iwb_ADDR_O, is the same as instruction fetch effective address.

Instruction fetch address translation can be enabled by setting bit SR[IME]. If translation is enabled, it provides instruction fetch effective address to physical address translation and page protection for instruction fetch accesses.

Figure 3.8. 32-bit Address Translation Mechanism using Two-Level Page Table

In OR1200 case, page tables must be managed by operating system s virtual memory management subsystem. Figure 3.8, “32-bit Address Translation Mechanism using Two-Level Page Table” shows address translation using two-level page table. Refer to [or1000_manual] for one-level page table address translation as well as for details about address translation and page table content.

IMMUCR is not implemented in OR1200. Therefore page table base pointer (PTBP) must be stored in software variable. Flush of entire ITLB must be performed by software flush of every ITLB entry separately. Software flush is performed by manually writing bits from the TLB entries back to PTEs.

After a virtual address is determined to be within a page covered by the valid PTE, the access is validated by the memory protection mechanism. If this protection mechanism prohibits the access, an instruction page fault exception is generated.

The memory protection mechanism allows selectively granting execute access for both supervisor and user modes. The page protection mechanism provides protection at all page level granularities.

Table 3.7, “Protection Attributes for Instruction Fetch Accesses” lists page protection attributes defined in ITLBWyTR pregister. For the individual page appropriate strategy out of seven possible strategies programmed with PPI field of the PTE. Because OR1200 does not implement IMMUPR, translation of PTE[PPI] into suitable set of protection bits must be performed by software and written into ITLBWyTR.

OR1200 does not implement ITLB entry reloads in hardware. Instead software routine must be used to search page table for correct page table entry (PTE) and copy it into the ITLB. Software is responsible for maintaining accessed bit in the page tables.

When LSU computes instruction fetch effective address whose physical address is not already cached by ITLB, an ITLB miss exception is invoked.

ITLB reload routine must load the correct PTE to correct ITLBWyMR and ITLBWyTR register from one of possible ITLB ways.

Special-purpose register ITLBEIR must be written with the effective address and corresponding ITLB entry will be invalidated in the local ITLB.

Since all ITLB entry reloads are performed in software, there is no hardware locking of ITLB entries. Instead it is up to the software reload routine to avoid replacing some of the entries if so desired.

Dirty (D) attribute resides in the PTE but it is not used by the IMMU.

Accessed (A) attribute is not implemented in OR1200 ITLB. It is up to the operating system to generate accessed attribute bit with page protection mechanism.

Weakly ordered memory (WOM) attribute is not needed in OR1200 because all instruction fetch accesses are serialized and therefore this attribute is not implemented.

Write-back cache (WBC) attribute resides in the PTE but it is not used by the IMMU.

Caching-inhibited (CI) attribute is not implemented in OR1200 ITLB. Cached and uncached regions are divided by bit 30 of instruction effective address.

Cache coherency (CC) attribute resides in the PTE but it is not used by the IMMU.

If system doesn t support clock gating and if changing clock frequency in slow down mode is not possible, CPU can be stalled for certain number of clock cycles. This is much lower benefit on power consumption however it still reduces power consumption.

Slow down mode is software controlled with the 4-bit value in PMR[SDF]. Lower value specifies higher expected performance from the processor core. Usually PMR[SDF] is dynamically set by the operating system s idle routine, that monitors the usage of the processor core.

PMR[SDF] is broadcast on pm_clksd. External clock generator should adjust clock frequency according to the value of pm_clksd. Exact slow down factors are not defined but 0xF should go all the way down to 32.768 KHz.

With pm_clksd equal to 0xF, pm_lvolt is asserted. This is an indication for the external power supply to lower the voltage.

To switch to doze mode, software should set the PMR[DME]. Once an interrupt is received by the programmable interrupt controller (PIC), pm_wakeup is asserted and external clock generation circuitry should enable all clocks. Once clocks are running RISC is switched back again to the normal mode and PMR[DME] is cleared.

When doze mode is enabled, pm_dc_gate, pm_ic_gate, pm_dmmu_gate, pm_immu_gate and pm_cpugate are asserted. As a result all clocks except clk_tt should be gated by external clock generation circuitry.

To switch to sleep mode, software should set the PMR[SME]. Once an interrupt is received by the programmable interrupt controller (PIC), pm_wakeup is asserted and external clock generation should enable all clocks. Once clocks are running, RISC is switched back again to the normal mode and PMR[SME] is cleared.

When sleep mode is enabled, pm_dc_gate, pm_ic_gate, pm_dmmu_gate, pm_immu_gate, pm_cpu_gate and pm_tt_gate are asserted. As a result all clocks including clk_tt should be gated by external clock generation circuitry.

In sleep mode, pm_lvolt is asserted. This is an indication for the external power supply to lower the voltage.

Clock gating feature is not implemented in OR1200 power management.

Units that are disabled in special-purpose register SR, have their clock gate signals asserted. Cleared bits SR[DCE], SR[ICE], SR[DME] and SR[IME] directly force assertion of pm_dc_gate, pm_ic_gate, pm_dmmu_gate and pm_immu_gate.

OR1200 debug unit does not implement OR12000 architecture watchpoints.

Which breakpointDMR2[WGB] bits specify which watchpoints invoke breakpoint exception. By invoking breakpoint exception, target resident debugger can be built.

Breakpoint is broadcast on development interface on dbg_bp_o.

The DSR special-purpose register specifies which exceptions cause the core to stop the execution of the exception handler and turn over control to development interface. It can be programmed by the resident debug software or by the development interface.

The DRR special-purpose register is specifies which event caused the core to stop the execution of program flow and turned over control to the development interface. It should be cleared by the resident debug software or by the development interface.

The DIR special-purpose register is not implemented.

Crucial information like program counter (PC), ((load/store effective address)) (LSEA), load data, store data and current instruction in execution pipeline can be asynchronously read through the development interface.

Table 3.9, “Development Interface Operation Commands” lists operation commands that control what is read or written through development interface. All reads except reads and writes of SPRs are asynchronous.

For reads and write to SPRs dbg_op_i must be set to 0x4 and 0x5, respectively.

Figure 3.9. Development Interface Cycles

Figure 3.9, “Development Interface Cycles” shows development interface cycles. Writes must be synchronous to the main RISC clock positive edge and should take one clock cycle. Reads must take two clock cycles because access to synchronous cache lines or to TLB entries introduces one clock cycle of delay.

If required, external debugger can stop the CPU core by asserting dbg_stall_i. This way it can have enough time to read all interesting registers from the RISC or guarantee that writes into SPRs are performed without RISC writing to the same registers.

An external debugger can monitor and record data flow inside the RISC for debugging purposes and profiling analysis. This is accomplished by monitoring status of the load/store unit, load/store effective address and load/store data, all available at the development interface.

External trace buffer can capture all interesting data flow events by analyzing status of the load/store unit available on dbg_lss_o. Table 3.10, “Status of the Load/Store Unit” lists different status encoding for the load/store unit.

An external debugger can monitor and record program flow inside the RISC for debugging purposes and profiling analysis. This is accomplished by monitoring status of the instruction unit, PC and fetched instruction word, all available at the development interface.

External trace buffer can capture all interesting program flow events by analyzing status of the instruction unit available on dbg_is_o. Table 3.11, “Status of the Instruction Unit” lists different status encoding for the instruction unit.

Figure 3.10, “Assertion of External Watchpoint Trigger” shows how development interface can assert dbg_ewt_I and cause watchpoint event. If programmed, external watchpoint event will cause a breakpoint exception.

Figure 3.10. Assertion of External Watchpoint Trigger