OpenTitan Big Number Accelerator (OTBN) Technical Specification

Overview

This document specifies functionality of the OpenTitan Big Number Accelerator, or OTBN. OTBN is a coprocessor for asymmetric cryptographic operations like RSA or Elliptic Curve Cryptography (ECC).

This module conforms to the Comportable guideline for peripheral functionality. See that document for integration overview within the broader top level system.

Features

  • Processor optimized for wide integer arithmetic
  • 32b wide control path with 32 32b wide registers
  • 256b wide data path with 32 256b wide registers
  • Full control-flow support with conditional branch and unconditional jump instructions, hardware loops, and hardware-managed call/return stacks.
  • Reduced, security-focused instruction set architecture for easier verification and the prevention of data leaks.
  • Built-in access to random numbers.

Description

OTBN is a processor, specialized for the execution of security-sensitive asymmetric (public-key) cryptography code, such as RSA or ECC. Such algorithms are dominated by wide integer arithmetic, which are supported by OTBN’s 256b wide data path, registers, and instructions which operate these wide data words. On the other hand, the control flow is clearly separated from the data, and reduced to a minimum to avoid data leakage.

The data OTBN processes is security-sensitive, and the processor design centers around that. The design is kept as simple as possible to reduce the attack surface and aid verification and testing. For example, no interrupts or exceptions are included in the design, and all instructions are designed to be executable within a single cycle.

OTBN is designed as a self-contained co-processor with its own instruction and data memory, which is accessible as a bus device.

Compatibility

OTBN is not designed to be compatible with other cryptographic accelerators. It received some inspiration from assembly code available from the Chromium EC project, which has been formally verified within the Fiat Crypto project.

Instruction Set

OTBN is a processor with a custom instruction set. The full ISA description can be found in our ISA manual. The instruction set is split into two groups:

  • The base instruction subset operates on the 32b General Purpose Registers (GPRs). Its instructions are used for the control flow of a OTBN application. The base instructions are inspired by RISC-V’s RV32I instruction set, but not compatible with it.
  • The big number instruction subset operates on 256b Wide Data Registers (WDRs). Its instructions are used for data processing.

Processor State

General Purpose Registers (GPRs)

OTBN has 32 General Purpose Registers (GPRs), each of which is 32b wide. The GPRs are defined in line with RV32I and are mainly used for control flow. They are accessed through the base instruction subset. GPRs aren’t used by the main data path; this operates on the Wide Data Registers, a separate register file, controlled by the big number instructions.

x0 Zero register. Reads as 0; writes are ignored.
x1

Access to the call stack

x2 ... x31 General purpose registers

Note: Currently, OTBN has no “standard calling convention,” and GPRs other than x0 and x1 can be used for any purpose. If a calling convention is needed at some point, it is expected to be aligned with the RISC-V standard calling conventions, and the roles assigned to registers in that convention. Even without a agreed-on calling convention, software authors are encouraged to follow the RISC-V calling convention where it makes sense. For example, good choices for temporary registers are x6, x7, x28, x29, x30, and x31.

Call Stack

OTBN has an in-built call stack which is accessed through the x1 GPR. This is intended to be used as a return address stack, containing return addresses for the current stack of function calls. See the documentation for JAL and JALR for a description of how to use it for this purpose.

The call stack has a maximum depth of 8 elements. Each instruction that reads from x1 pops a single element from the stack. Each instruction that writes to x1 pushes a single element onto the stack. An instruction that reads from an empty stack or writes to a full stack causes OTBN to stop, raising an alert and setting the ErrBitCallStack bit in the ERR_BITS register.

A single instruction can both read and write to the stack. In this case, the read is ordered before the write. Providing the stack has at least one element, this is allowed, even if the stack is full.

Control and Status Registers (CSRs)

Control and Status Registers (CSRs) are 32b wide registers used for “special” purposes, as detailed in their description; they are not related to the GPRs. CSRs can be accessed through dedicated instructions, CSRRS and CSRRW . Writes to read-only (RO) registers are ignored; they do not signal an error. All read-write (RW) CSRs are set to 0 when OTBN starts an operation (when 1 is written to CMD.start).

Number Access Name Description
0x7C0 RW FG0 Wide arithmetic flag group 0. This CSR provides access to flag group 0 used by wide integer arithmetic. FLAGS, FG0 and FG1 provide different views on the same underlying bits.
BitDescription
0Carry of Flag Group 0
1MSb of Flag Group 0
2LSb of Flag Group 0
3Zero of Flag Group 0
0x7C1 RW FG1 Wide arithmetic flag group 1. This CSR provides access to flag group 1 used by wide integer arithmetic. FLAGS, FG0 and FG1 provide different views on the same underlying bits.
BitDescription
0Carry of Flag Group 1
1MSb of Flag Group 1
2LSb of Flag Group 1
3Zero of Flag Group 1
0x7C8 RW FLAGS Wide arithmetic flag groups. This CSR provides access to both flags groups used by wide integer arithmetic. FLAGS, FG0 and FG1 provide different views on the same underlying bits.
BitDescription
0Carry of Flag Group 0
1MSb of Flag Group 0
2LSb of Flag Group 0
3Zero of Flag Group 0
4Carry of Flag Group 1
5MSb of Flag Group 1
6LSb of Flag Group 1
7Zero of Flag Group 1
0x7D0 RW MOD0 Bits [31:0] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D1 RW MOD1 Bits [63:32] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D2 RW MOD2 Bits [95:64] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D3 RW MOD3 Bits [127:96] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D4 RW MOD4 Bits [159:128] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D5 RW MOD5 Bits [191:160] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D6 RW MOD6 Bits [223:192] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D7 RW MOD7 Bits [255:224] of the modulus operand, used in the BN.ADDM / BN.SUBM instructions. This CSR is mapped to the MOD WSR.
0x7D8 RW RND_PREFETCH Write to this CSR to begin a request to fill the RND cache. Always reads as 0.
0xFC0 RO RND An AIS31-compliant class PTG.3 random number with guaranteed entropy and forward and backward secrecy. Primarily intended to be used for key generation.

The number is sourced from the EDN via a single-entry cache. Reads when the cache is empty will cause OTBN to be stalled until a new random number is fetched from the EDN.

0xFC1 RO URND A random number without guaranteed secrecy properties or specific statistical properties. Intended for use in masking and blinding schemes. Use RND for high-quality randomness.

The number is sourced from an LFSR. Reads never stall.

Wide Data Registers (WDRs)

In addition to the 32b wide GPRs, OTBN has a second “wide” register file, which is used by the big number instruction subset. This register file consists of NWDR = 32 Wide Data Registers (WDRs). Each WDR is WLEN = 256b wide.

Wide Data Registers (WDRs) and the 32b General Purpose Registers (GPRs) are separate register files. They are only accessible through their respective instruction subset: GPRs are accessible from the base instruction subset, and WDRs are accessible from the big number instruction subset (BN instructions).

Register
w0
w1
w31

Wide Special Purpose Registers (WSRs)

OTBN has 256b Wide Special purpose Registers (WSRs). These are analogous to the 32b CSRs, but are used by big number instructions. They can be accessed with the BN.WSRR and BN.WSRW instructions. Writes to read-only (RO) registers are ignored; they do not signal an error. All read-write (RW) WSRs are set to 0 when OTBN starts an operation (when 1 is written to CMD.start).

Number Access Name Description
0x0 RW MOD

The modulus used by the BN.ADDM and BN.SUBM instructions. This WSR is also visible as CSRs MOD0 through to MOD7.

0x1 RO RND An AIS31-compliant class PTG.3 random number with guaranteed entropy and forward and backward secrecy. Primarily intended to be used for key generation.

The number is sourced from the EDN via a single-entry cache. Reads when the cache is empty will cause OTBN to be stalled until a new random number is fetched from the EDN.

0x2 RO URND A random number without guaranteed secrecy properties or specific statistical properties. Intended for use in masking and blinding schemes. Use RND for high-quality randomness.

The number is sourced from an LFSR. Reads never stall.

0x3 RW ACC The accumulator register used by the BN.MULQACC instruction.

Flags

In addition to the wide register file, OTBN maintains global state in two groups of flags for the use by wide integer operations. Flag groups are named Flag Group 0 (FG0), and Flag Group 1 (FG1). Each group consists of four flags. Each flag is a single bit.

  • C (Carry flag). Set to 1 an overflow occurred in the last arithmetic instruction.

  • M (MSb flag) The most significant bit of the result of the last arithmetic or shift instruction.

  • L (LSb flag). The least significant bit of the result of the last arithmetic or shift instruction.

  • Z (Zero Flag) Set to 1 if the result of the last operation was zero; otherwise 0.

The M, L, and Z flags are determined based on the result of the operation as it is written back into the result register, without considering the overflow bit.

Loop Stack

OTBN has two instructions for hardware-assisted loops: LOOP and LOOPI . Both use the same state for tracking control flow. This is a stack of tuples containing a loop count, start address and end address. The stack has a maximum depth of eight and the top of the stack is the current loop.

Security Features

Work in progress

Work on OTBN is ongoing, including work on the specification and implementation of its security features. Do not treat the following description (or anything in this documentation) as final, fully implemented, or verified.

OTBN is a security co-processor. It contains various security features and is hardened against side-channel analysis and fault injection attacks. The following sections describe the high-level security features of OTBN. Refer to the Design Details section for a more in-depth description.

Data Integrity Protection

OTBN’s data integrity protection is designed to protect the data stored and processed within OTBN from modifications through physical attacks.

Data in OTBN travels along a data path which includes the data memory (DMEM), the load-store-unit (LSU), the register files (GPR and WDR), and the execution units. Whenever possible, data transmitted or stored within OTBN is protected with an integrity protection code which guarantees the detection of at least three modified bits per 32 bit word. Additionally, instructions and data stored in the instruction and data memory, respectively, are scrambled with a lightweight, non-cryptographically-secure cipher.

Refer to the Data Integrity Protection section for details of how the data integrity protections are implemented.

Secure Wipe

OTBN provides a mechanism to securely wipe all state it stores, including the instruction memory.

The full secure wipe mechanism is split into three parts:

A secure wipe is performed automatically in certain situations, or can be requested manually by the host software. The full secure wipe is automatically initiated as a local reaction to a fatal error. A secure wipe of only the internal state is performed whenever an OTBN operation is completed and after a recoverable error. Finally, host software can manually trigger the full or partial secure wipe operations by writing to the SEC_WIPE register.

Refer to the Secure Wipe section for implementation details.

Instruction Counter

In order to detect and mitigate fault injection attacks on the OTBN, the host CPU can read the number of executed instructions from INSN_CNT and verify whether it matches the expectation.

Theory of Operations

Block Diagram

OTBN architecture block diagram

Hardware Interfaces

Referring to the Comportable guideline for peripheral device functionality, the module otbn has the following hardware interfaces defined.

Primary Clock: clk_i

Other Clocks: clk_edn_i, clk_otp_i

Bus Device Interfaces (TL-UL): tl

Bus Host Interfaces (TL-UL): none

Peripheral Pins for Chip IO: none

Interrupts:

Interrupt NameDescription
done

OTBN has completed the operation

Security Alerts:

Alert NameDescription
fatal

A fatal error. Fatal alerts are non-recoverable and will be asserted until a hard reset.

recov

A recoverable error. Just sent once (as the processor stops).

Hardware Interface Requirements

OTBN connects to other components in an OpenTitan system. This section lists requirements on those interfaces that go beyond the physical connectivity.

Entropy Distribution Network (EDN)

OTBN has two EDN connections: edn_urnd and edn_rnd. What kind of randomness is provided on the EDN connections is configurable at runtime, but unknown to OTBN. To maintain its security properties, OTBN requires the following configuration for the two EDN connections:

  • OTBN has no specific requirements on the randomness drawn from edn_urnd. For performance reasons, requests on this EDN connection should be answered quickly.
  • edn_rnd must provide AIS31-compliant class PTG.3 random numbers. The randomness from this interface is made available through the RND WSR and intended to be used for key generation.

Design Details

Memories

The OTBN processor core has access to two dedicated memories: an instruction memory (IMEM), and a data memory (DMEM). Each memory is 4 kiB in size.

The memory layout follows the Harvard architecture. Both memories are byte-addressed, with addresses starting at 0.

The instruction memory (IMEM) is 32b wide and provides the instruction stream to the OTBN processor. It cannot be read from or written to by user code through load or store instructions.

The data memory (DMEM) is 256b wide and read-write accessible from the base and big number instruction subsets of the OTBN processor core. There are four instructions that can access data memory. In the base instruction subset, there are LW (load word) and SW (store word). These access 32b-aligned 32b words. In the big number instruction subset, there are BN.LID (load indirect) and BN.SID (store indirect). These access 256b-aligned 256b words.

Both memories can be accessed through OTBN’s register interface (DMEM and IMEM). These accesses are ignored if OTBN is busy. A host processor can check whether OTBN is busy by reading the STATUS.busy flag. All memory accesses through the register interface must be word-aligned 32b word accesses.

Random Numbers

OTBN is connected to the Entropy Distribution Network (EDN) which can provide random numbers via the RND and URND CSRs and WSRs.

RND provides bits taken directly from the EDN connected via edn_rnd. As an EDN request can take time, RND is backed by a single-entry cache containing the result of the most recent EDN request. A read from RND empties this cache. A prefetch into the cache, which can be used to hide the EDN latency, is triggered on any write to the RND_PREFETCH CSR. Writes to RND_PREFETCH will be ignored whilst a prefetch is in progress or when the cache is already full. OTBN will stall until the request provides bits. Both the RND CSR and WSR take their bits from the same cache. RND CSR reads simply discard the other 192 bits on a read. When stalling on an RND read, OTBN will unstall on the cycle after it receives WLEN RND data from the EDN.

URND provides bits from an LFSR within OTBN; reads from it never stall. The URND LFSR is seeded once from the EDN connected via edn_urnd when OTBN starts execution. Each new execution of OTBN will reseed the URND LFSR. The LFSR state is advanced every cycle when OTBN is running.

Error Handling and Reporting

By design, OTBN is a simple processor and provides no error handling support to code that runs on it.

Whenever OTBN observes an error, it will generate an alert. This gets sent to the alert manager. The alert will either be fatal or recoverable, depending on the class of error: see Alerts and ERR_BITS below for details.

If OTBN was running when the alert occurred (this is true whenever STATUS.busy is high), it will also:

  • Immediately stop fetching and executing instructions.
  • Set INTR_STATE.done and clear STATUS.busy, marking the operation as completed.
  • Set the ERR_BITS register to a non-zero value describing the error.

Note that OTBN can detect some errors even when it isn’t running. One example of this is an error caused by an integrity error when reading or writing OTBN’s memories over the bus. In this case, the ERR_BITS register will not change. This avoids race conditions with the host processor’s error handling software. However, every error that OTBN detects when it isn’t running causes a fatal alert. This means that the cause will be reflected in FATAL_ALERT_CAUSE, as described below in Alerts. This way, no alert is generated without setting an error code somewhere.

TODO

When the implementation is finished, document more precisely how OTBN stops on error. Can we claim to cancel all register and memory writes in that cycle? Is there a way for that to make sense for errors that aren’t related to a particular instruction (e.g. shadow register mis-matches; FSM glitches)?

Also, once it is decided, document behaviour on a bus access when OTBN is running.

Alerts

OTBN has two alerts, one recoverable and one fatal. The ERR_BITS register documentation has a detailed list of error conditions, those with ‘fatal’ in the name raise a fatal alert, otherwise they raise a recoverable alert.

A recoverable alert is a one-time triggered alert for recoverable error conditions. Recoverable alerts are only triggered when OTBN is running, so will always imply a write to ERR_BITS. The error that caused the alert can be determined by reading the ERR_BITS register.

A fatal alert is a continuously triggered alert after unrecoverable error conditions. The error that caused the alert can be determined by reading the FATAL_ALERT_CAUSE register. If OTBN was running, this value will also be reflected in the ERR_BITS register. A fatal alert can only be cleared by resetting OTBN through the rst_ni line.

Reaction to Life Cycle Escalation Requests

OTBN receives and reacts to escalation signals from the life cycle controller.

An escalation request signaled through the lc_escalate_en_i signal results in the same action as a fatal error but does not raise a fatal alert.

Idle

OTBN exposes a single-bit idle_o signal, intended to be used by the clock manager to clock-gate the block when it is not in use. This signal is high when OTBN is not running. The cycle after a write to CMD.start, the signal goes low. This remains low until the end of the operation (either from an ECALL ) or an error, at which point it goes high again.

Data Integrity Protection

OTBN stores and operates on data (state) in its dedicated memories, register files, and internal registers. OTBN’s data integrity protection is designed to protect all data stored and transmitted within OTBN from modifications through physical attacks.

During transmission, the integrity of data is protected with an integrity protection code. Data at rest in the instruction and data memories is additionally scrambled.

In the following, the Integrity Protection Code and the scrambling algorithm are discussed, followed by their application to individual storage elements.

Integrity Protection Code

OTBN uses the same integrity protection code everywhere to provide overarching data protection without regular re-encoding. The code is applied to 32b data words, and produces 39b of encoded data.

The code used is an (39,32) Hsiao “single error correction, double error detection” (SECDED) error correction code (ECC) [CHEN08]. It has a minimum Hamming distance of four, resulting in the ability to detect at least three errors in a 32 bit word. The code is used for error detection only; no error correction is performed.

Memory Scrambling

Contents of OTBN’s instruction and data memories are scrambled while at rest. The data is bound to the address and scrambled before being stored in memory. The addresses are randomly remapped.

Note that data stored in other temporary memories within OTBN, including the register files, is not scrambled.

Scrambling is used to obfuscate the memory contents and to diffuse the data. Obfuscation makes passive probing more difficult, while diffusion makes active fault injection attacks more difficult.

The scrambling mechanism is described in detail in the section “Scrambling Primitive” of the SRAM Controller Technical Specification.

The scrambling keys are rotated regularly, refer to the sections below for more details.

Actions on Integrity Errors

A fatal error is raised whenever a data integrity violation is detected, which results in an immediate stop of all processing and the issuing of a fatal alert. The section Error Handling and Reporting describes the error handling in more detail.

Register File Integrity Protection

OTBN contains two register files: the 32b GPRs and the 256b WDRs. The data stored in both register files is protected with the Integrity Protection Code. Neither the register file contents nor register addresses are scrambled.

The GPRs x2 to x31 store a 32b data word together with the Integrity Protection Code, resulting in 39b of stored data. (x0, the zero register, and x1, the call stack, require special treatment.)

Each 256b Wide Data Register (WDR) stores a 256b data word together with the Integrity Protection Code, resulting in 312b of stored data. The integrity protection is done separately for each of the eight 32b sub-words within a 256b word.

The register files can consume data protected with the Integrity Protection Code, or add it on demand. Whenever possible the Integrity Protection Code is preserved from its source and written directly to the register files without recalculation, in particular in the following cases:

  • Data coming from the data memory (DMEM) through the load-store unit to a GPR or WDR.
  • Data copied between WDRs using the BN.MOV or BN.MOVR instructions.
  • Data conditionally copied between WDRs using the BN.SEL instruction.
  • Data copied between the ACC and MOD WSRs and a WDR. (TODO: Not yet implemented.)
  • Data copied between any of the MOD0 to MOD7 CSRs and a GPR. (TODO: Not yet implemented.)

In all other cases the register files add the Integrity Protection Code to the incoming data before storing the data word.

The integrity protection bits are checked on every read from the register files, even if the integrity protection is not removed from the data.

Detected integrity violations in a register file raise a fatal reg_error.

Data Memory (DMEM) Integrity Protection

OTBN’s data memory is 256b wide, but allows for 32b word accesses. To facilitate such accesses, all integrity protection in the data memory is done on a 32b word granularity.

All data entering or leaving the data memory block is protected with the Integrity Protection Code; this code is not re-computed within the memory block.

Before being stored in SRAM, the data word with the attached Integrity Protection Code, as well as the address are scrambled according to the memory scrambling algorithm. The scrambling is reversed on a read.

The ephemeral memory scrambling key and the nonce are provided by the OTP block. They are set once when OTBN block is reset, and changed whenever a secure wipe of the data memory is performed.

The Integrity Protection Code is checked on every memory read, even though the code remains attached to the data. A further check must be performed when the data is consumed. Detected integrity violations in the data memory raise a fatal dmem_error.

Instruction Memory (IMEM) Integrity Protection

All data entering or leaving the instruction memory block is protected with the Integrity Protection Code; this code is not re-computed within the memory block.

Before being stored in SRAM, the instruction word with the attached Integrity Protection Code, as well as the address are scrambled according to the memory scrambling algorithm. The scrambling is reversed on a read.

The ephemeral memory scrambling key and the nonce are provided by the OTP block. They are set once when OTBN block is reset, and changed whenever a secure wipe of the instruction memory is performed.

The Integrity Protection Code is checked on every memory read, even though the code remains attached to the data. A further check must be performed when the data is consumed. Detected integrity violations in the data memory raise a fatal imem_error.

Secure Wipe

The entire OTBN state, including the contents of instruction and data memories, can be securely deleted on demand from a host software. In addition, full or partial secure wipe is triggered automatically by the OTBN in certain situations.

Triggering Secure Wipe

In the following situations OTBN itself initiates a full secure wipe:

  • The lifecycle controller asks for it through its escalation signal.
  • A fatal alert is issued. In this case, a full secure wipe is performed as a local action.

The internal state secure wipe is automatically triggered when an OTBN operation completes, either successfully, or unsuccessfully due to a recoverable error.

Host software can trigger a full state wipe by writing 3'b111 to SEC_WIPE (i.e. set all individual state wipe bits).

Completion of Secure Wipe

During the secure wipe operation the STATUS.busy flag is set to 1, indicating that the OTBN is busy. Once the operation is completed, a INTR_STATE.done interrupt is raised and STATUS.busy is cleared. This effectively means that the host software will get a single done interrupt for a secure wipe operation, independent of how many SEC_WIPE bits the software wrote.

Data Memory (DMEM) Secure Wipe

The wiping is performed by securely replacing the memory scrambling key, making all data stored in the memory unusable. The key replacement is a two-step process:

  • Overwrite the 128b key of the memory scrambling primitive with randomness from URND. This action takes a single cycle.
  • Request new scrambling parameters from OTP. The request takes multiple cycles to complete.

Host software can initiate a data memory secure wipe by writing 1 to the SEC_WIPE.dmem register field. The completion is signalled by raising an INTR_STATE.done interrupt.

Instruction Memory (IMEM) Secure Wipe

The wiping is performed by securely replacing the memory scrambling key, making all instructions stored in the memory unusable. The key replacement is a two-step process:

  • Overwrite the 128b key of the memory scrambling primitive with randomness from URND. This action takes a single cycle.
  • Request new scrambling parameters from OTP. The request takes multiple cycles to complete.

Host software can initiate an instruction memory secure wipe by writing 1 to the SEC_WIPE.imem register field. The completion is signalled by raising an INTR_STATE.done interrupt.

Internal State Secure Wipe

OTBN provides a mechanism to securely wipe all internal state, excluding the instruction and data memories.

The following state is wiped:

  • Register files: GPRs and WDRs
  • The accumulator register (also accessible through the ACC WSR)
  • Flags (accessible through the FG0, FG1, and FLAGS CSRs)
  • The modulus (accessible through the MOD0 to MOD7 CSRs and the MOD WSR)

The wiping procedure is a two-step process:

  • Overwrite the state with randomness from URND.
  • Overwrite the state with zeros.

Loop and call stack pointers are reset.

Host software can initiate an internal state secure wipe by writing 1 to the SEC_WIPE.internal register field. The completion is signalled by raising an INTR_STATE.done interrupt.

Running applications on OTBN

OTBN is a specialized coprocessor which is used from the host CPU. This section describes how to interact with OTBN from the host CPU to execute an existing OTBN application. The section Writing OTBN applications describes how to write such applications.

High-level operation sequence

The high-level sequence by which the host processor should use OTBN is as follows.

  1. Write the OTBN application binary to IMEM, starting at address 0.
  2. Optional: Write constants and input arguments, as mandated by the calling convention of the loaded application, to DMEM.
  3. Start the operation on OTBN by writing 1 to CMD.start. Now neither data nor instruction memory may be accessed from the host CPU. After it has been started the OTBN application runs to completion without further interaction with the host.
  4. Wait for the operation to complete (see below). As soon as the OTBN operation has completed the data and instruction memories can be accessed again from the host CPU.
  5. Check if the operation was successful by reading the ERR_BITS register.
  6. Optional: Retrieve results by reading DMEM, as mandated by the calling convention of the loaded application.

OTBN applications are run to completion. The host CPU can determine if an application has completed by either polling STATUS.busy or listening for an interrupt.

  • To poll for a completed operation, software should repeatedly read the STATUS.busy register. While the operation is in progress, STATUS.busy reads as 1. The operation is completed if STATUS.busy is 0.
  • Alternatively, software can listen for the done interrupt to determine if the operation has completed. The standard sequence of working with interrupts has to be followed, i.e. the interrupt has to be enabled, an interrupt service routine has to be registered, etc. The DIF contains helpers to do so conveniently.

Note: This operation sequence only covers functional aspects. Depending on the application additional steps might be necessary, such as deleting secrets from the memories.

Device Interface Functions (DIFs)

To use this DIF, include the following C header:

#include "sw/device/lib/dif/dif_otbn.h"

This header provides the following device interface functions:

Driver

A higher-level driver for the OTBN block is available at sw/device/lib/runtime/otbn.h (API documentation).

Register Table

otbn.INTR_STATE @ 0x0

Interrupt State Register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  done
BitsTypeResetNameDescription
0rw1c0x0done

OTBN has completed the operation


otbn.INTR_ENABLE @ 0x4

Interrupt Enable Register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  done
BitsTypeResetNameDescription
0rw0x0done

Enable interrupt when INTR_STATE.done is set.


otbn.INTR_TEST @ 0x8

Interrupt Test Register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  done
BitsTypeResetNameDescription
0wo0x0done

Write 1 to force INTR_STATE.done to 1.


otbn.ALERT_TEST @ 0xc

Alert Test Register

Reset default = 0x0, mask 0x3
31302928272625242322212019181716
 
1514131211109876543210
  recov fatal
BitsTypeResetNameDescription
0wo0x0fatal

Write 1 to trigger one alert event of this kind.

1wo0x0recov

Write 1 to trigger one alert event of this kind.


otbn.CMD @ 0x10

command register

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  start
BitsTypeResetNameDescription
0r0w1cxstart

Start the operation

The completion is signalled by the done interrupt.


otbn.STATUS @ 0x14

Status

Reset default = 0x0, mask 0x1
31302928272625242322212019181716
 
1514131211109876543210
  busy
BitsTypeResetNameDescription
0roxbusy

OTBN is performing an operation.


otbn.ERR_BITS @ 0x18

Error bitfield. Reads as non-zero if an error was seen during OTBN operation

Reset default = 0x0, mask 0xff
31302928272625242322212019181716
 
1514131211109876543210
  fatal_reg fatal_dmem fatal_imem loop illegal_insn call_stack bad_insn_addr bad_data_addr
BitsTypeResetNameDescription
0roxbad_data_addr

A DMEM read or write occurred with an out of bounds or unaligned address.

1roxbad_insn_addr

An IMEM read occurred with an out of bounds or unaligned address.

2roxcall_stack

A instruction tried to pop from an empty call stack or push to a full call stack.

3roxillegal_insn

One of the following happened:

  • An instruction being excuted had an invalid encoding.
  • An access occurred for an invalid CSR or WSR.

4roxloop

One of the following happened:

  • A loop was started with an iteration count of zero.
  • The final instruction of a loop was a branch or another loop.
  • A new loop tried to push to a full loop stack (loop nesting level too deep).

5roxfatal_imem

A fatal failure was seen on an instruction fetch.

6roxfatal_dmem

A fatal failure was seen on a DMEM read.

7roxfatal_reg

A fatal failure was seen on a GPR or WDR read.


otbn.START_ADDR @ 0x1c

Start byte address in the instruction memory

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
start_addr...
1514131211109876543210
...start_addr
BitsTypeResetNameDescription
31:0wo0x0start_addr

Byte address in the instruction memory OTBN starts to execute from when instructed to do so with the CMD.start .


otbn.FATAL_ALERT_CAUSE @ 0x20

The cause of a fatal alert.

Reset default = 0x0, mask 0xf

The bits of this register correspond to errors that can cause a fatal alert. Software can read these bits to see what went wrong. Once set, these bits cannot be cleared.

31302928272625242322212019181716
 
1514131211109876543210
  reg_error dmem_error imem_error bus_integrity_error
BitsTypeResetNameDescription
0ro0x0bus_integrity_error

Set by a failed integrity check on a bus access. Note that this can happen even when OTBN is not running.

1ro0x0imem_error

Set on any ECC error in IMEM

2ro0x0dmem_error

Set on any ECC error in DMEM

3ro0x0reg_error

Set on any ECC error in a register file


otbn.SEC_WIPE @ 0x24

Trigger a secure wipe operation.

Reset default = 0x0, mask 0x7

This register should only be accesed while OTBN is not busy, as indicated by the STATUS.busy flag. Access attempts while OTBN is busy are ignored.

31302928272625242322212019181716
 
1514131211109876543210
  internal imem dmem
BitsTypeResetNameDescription
0wo0x0dmem

Write 1 to securely wipe data memory.

1wo0x0imem

Write 1 to securely wipe instruction memory.

2wo0x0internal

Write 1 to securely wipe internal state.


otbn.INSN_CNT @ 0x28

Instruction Counter

Reset default = 0x0, mask 0xffffffff
31302928272625242322212019181716
insn_cnt...
1514131211109876543210
...insn_cnt
BitsTypeResetNameDescription
31:0roxinsn_cnt

The number of instructions executed in the current or last OTBN run. Saturates at 2^32-1. The counter is reset to zero when a new operation is started. Instructions triggering an error do not count as being executed.


otbn.IMEM @ + 0x4000
1024 item rw window
Byte writes are not supported
310
+0x4000 
+0x4004 
 ...
+0x4ff8 
+0x4ffc 

Instruction Memory.

This register should only be accesed while OTBN is not busy, as indicated by the STATUS.busy flag. Accesses while OTBN is busy are blocking.

TODO: The exact behavior is yet to be determined, see https://github.com/lowRISC/opentitan/issues/2696 for details.


otbn.DMEM @ + 0x8000
1024 item rw window
Byte writes are not supported
310
+0x8000 
+0x8004 
 ...
+0x8ff8 
+0x8ffc 

Data Memory.

This register should only be accesed while OTBN is not busy, as indicated by the STATUS.busy flag. Accesses while OTBN is busy are blocking.

TODO: The exact behavior is yet to be determined, see https://github.com/lowRISC/opentitan/issues/2696 for details.


Writing OTBN applications

OTBN applications are (small) pieces of software written in OTBN assembly. The full instruction set is described in the ISA manual, and example software is available in the sw/otbn directory of the OpenTitan source tree.

A hands-on user guide to develop OTBN software can be found in the section Writing and building software for OTBN.

Toolchain support

OTBN comes with a toolchain consisting of an assembler, a linker, and helper tools such as objdump. The toolchain wraps a RV32 GCC toolchain and supports many of its features.

The following tools are available:

  • otbn-as: The OTBN assembler.
  • otbn-ld: The OTBN linker.
  • otbn-objdump: objdump for OTBN.

Other tools from the RV32 toolchain can be used directly, such as objcopy.

Passing of data between the host CPU and OTBN

Passing data between the host CPU and OTBN is done through the data memory (DMEM). No standard or required calling convention exists, every application is free to pass data in and out of OTBN in whatever format it finds convenient. All data passing must be done when OTBN is not running, as indicated by the STATUS.busy bit; during the OTBN operation both the instruction and the data memory are inaccessible from the host CPU.

Returning from an application

The software running on OTBN signals completion by executing the ECALL instruction.

When it executes this instruction, OTBN:

The DMEM can be used to pass data back to the host processor, e.g. a “return value” or an “exit code”. Refer to the section Passing of data between the host CPU and OTBN for more information.

Using hardware loops

OTBN provides two hardware loop instructions: LOOP and LOOPI .

Loop nesting

OTBN permits loop nesting and branches and jumps inside loops. However, it doesn’t have support for early termination of loops: there’s no way to pop an entry from the loop stack without executing the last instruction of the loop the correct number of times. It can also only pop one level of the loop stack per instruction.

To avoid polluting the loop stack and avoid surprising behaviour, the programmer must ensure that:

  • Even if there are branches and jumps within a loop body, the final instruction of the loop body gets executed exactly once per iteration.
  • Nested loops have distinct end addresses.
  • The end instruction of an outer loop is not executed before an inner loop finishes.

OTBN does not detect these conditions being violated, so no error will be signalled should they occur.

(Note indentation in the code examples is for clarity and has no functional impact.)

The following loops are well nested:

LOOP x2, 3
  LOOP x3, 1
    ADDI x4, x4, 1
  # The NOP ensures that the outer and inner loops end on different instructions
  NOP

# Both inner and outer loops call some_fn, which returns to
# the body of the loop
LOOP x2, 5
  JAL x1, some_fn
  LOOP x3, 2
    JAL x1, some_fn
    ADDI x4, x4, 1
  NOP

# Control flow leaves the immediate body of the outer loop but eventually
# returns to it
LOOP x2, 4
  BEQ x4, x5, some_label
branch_back:
  LOOP x3, 1
    ADDI x6, x6, 1
  NOP

some_label:
  ...
  JAL x0, branch_back

The following loops are not well nested:

# Both loops end on the same instruction
LOOP x2, 2
  LOOP x3, 1
    ADDI x4, x4, 1

# Inner loop jumps into outer loop body (executing the outer loop end
# instruction before the inner loop has finished)
LOOP x2, 5
  LOOP x3, 3
    ADDI x4, x4 ,1
    BEQ  x4, x5, outer_body
    ADD  x6, x7, x8
outer_body:
  SUBI  x9, x9, 1

Algorithic Examples: Multiplication with BN.MULQACC

The big number instruction subset of OTBN generally operates on WLEN bit numbers. BN.MULQACC operates with WLEN/4 bit operands (with a full WLEN accumulator). This section outlines two techniques to perform larger multiplies by composing multiple BN.MULQACC instructions.

Multiplying two WLEN/2 numbers with BN.MULQACC

This instruction sequence multiplies the lower half of w0 by the upper half of w0 placing the result in w1.

BN.MULQACC.Z      w0.0, w0.2, 0
BN.MULQACC        w0.0, w0.3, 64
BN.MULQACC        w0.1, w0.2, 64
BN.MULQACC.WO w1, w0.1, w0.3, 128

Multiplying two WLEN numbers with BN.MULQACC

The shift out functionality can be used to perform larger multiplications without extra adds. The table below shows how two registers w0 and w1 can be multiplied together to give a result in w2 and w3. The cells on the right show how the result is built up a0:a3 = w0.0:w0.3 and b0:b3 = w1.0:w1.3. The sum of a column represents WLEN/4 bits of a destination register, where c0:c3 = w2.0:w2.3 and d0:d3 = w3.0:w3.3. Each cell with a multiply in takes up two WLEN/4-bit columns to represent the WLEN/2-bit multiply result. The current accumulator in each instruction is represented by highlighted cells where the accumulator value will be the sum of the highlighted cell and all cells above it.

The outlined technique can be extended to arbitrary bit widths but requires unrolled code with all operands in registers.

d3 d2 d1 d0 c3 c2 c1 c0
BN.MULQACC.Z w0.0, w1.0, 0 a0 * b0
BN.MULQACC w0.1, w1.0, 64 a1 * b0
BN.MULQACC.SO w2.l, w0.0, w1.1, 64 a0 * b1
BN.MULQACC w0.2, w1.0, 0 a2 * b0
BN.MULQACC w0.1, w1.1, 0 a1 * b1
BN.MULQACC w0.0, w1.2, 0 a0 * b2
BN.MULQACC w0.3, w1.0, 64 a3 * b0
BN.MULQACC w0.2, w1.1, 64 a2 * b1
BN.MULQACC w0.1, w1.2, 64 a1 * b2
BN.MULQACC.SO w2.u, w0.0, w1.3, 64 a0 * b3
BN.MULQACC w0.3, w1.1, 0 a3 * b1
BN.MULQACC w0.2, w1.2, 0 a2 * b2
BN.MULQACC w0.1, w1.3, 0 a1 * b3
BN.MULQACC w0.3, w1.2, 64 a3 * b2
BN.MULQACC.SO w3.l, w0.2, w1.3, 64 a2 * b3
BN.MULQACC.SO w3.u, w0.3, w1.3, 0 a3 * b3

Code snippets giving examples of 256x256 and 384x384 multiplies can be found in sw/otbn/code-snippets/mul256.s and sw/otbn/code-snippets/mul384.s.

References

[CHEN08] L. Chen, “Hsiao-Code Check Matrices and Recursively Balanced Matrices,” arXiv:0803.1217 [cs], Mar. 2008 [Online]. Available: http://arxiv.org/abs/0803.1217