Flash Controller HWIP Technical Specification

Overview

This document describes the flash hardware functionality. The flash hardware is broken down into 3 major components

• Open source flash controllers
• Closed source vendor flash wrapper
• Closed source vendor flash module

A breakdown of the 3 can be seen below

This open source flash controller is divided into two partitions.

• Flash protocol controller
• Flash physical controller

The remaining document focuses primarily on the function of these blocks.

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

Features

Flash Protocol Controller Features

The flash protocol controller interfaces with software and other hardware components in the system (such as life cycle and key manager). Regardless of the flash size underneath, the flash controller maintains the same data resolution as the bus and processor (default 4B). The flash physical controller (see section below) is then responsible for bridging that gap.

The protocol controller currently supports the following features:

• Controller initiated read, program and erase of flash.
  • Erase can be either of a page, or an entire bank.
• Support for differentiation between informational and data flash partitions.
• Parameterized support for burst program, up to 64B
  • Longer programs are supported, however the protocol controller will directly back-pressure the bus.
• Flash memory protection at page boundaries
• Features to be added if required
  • Program verification
    • may not be required if flash memory supports alternative mechanisms of verification.
  • Erase verification
    • may not be required if flash memory supports alternative mechanisms of verification.
  • Flash redundant pages
    • Flash may contain additional pages used to remap broken pages for yield recovery.
    • The storage, loading and security of redundant pages may also be implemented in the physical controller or flash memory.

Features to be implemented

• Enhanced memory protection
• Life cycle feature support
• Key manager feature support

Flash Physical Controller Features

The flash physical controller wraps the actual flash memory and translates both host and controller initiated requests into low level flash transactions.

The physical controller supports the following features

• Multiple banks of flash memory
• For each flash bank, parameterized support for number of flash pages (default to 256)
• For each flash page, parameterized support for number of words and word size (default to 128 words of 8-bytes each)
• Data and informational paritions within each bank of flash memory
• Arbitration between host requests and controller requests at the bank level
  • Host requests are always favored, however the controller priority can escalate if it repeatedly loses arbitration
  • Since banks are arbitrated independently, where transactions may take different amounts of times to complete, the physical controller is also responsible for ensuring in-order response to both the controller and host.
• Flash read stage
  • Each bank maintains a parameterizable number of read buffers in front of the flash memory
  • The read buffers behave as miniature read-only-caches to store flash data when flash words are greater than bus words.
• Flash program stage
  • Flash data work packing when flash word size is an integer multiple of bus word size.

Features to be implemented

• Flash scrambling
• Flash ECC

Theory of Operation

Block Diagram

Flash Protocol Controller

The Flash Protocol Controller sits between the host software interface and the flash physical controller, which contains the physical flash. Its primary function is to translate software requests into a high level protocol for the actual flash block. Importantly, the flash protocol controller is not responsible for the detailed timing and waveform control of the flash. Instead, it maintains FIFOs / interrupts for the software to process data, as well as high level abstraction of region protection controls.

Flash Physical Controller

The Flash Physical Controller is the wrapper module that contains the actual vendor flash memory instantiation. It is responsible for arbitrating high level protocol commands (such as read, program, erase) as well as any additional security and reliability features. The contained vendor wrapper module is then responsible for converting high level commands into low level signaling and timing specific to a particular flash vendor. The vendor wrapper module is also responsible for any BIST, redundancy handling, remapping features or custom configurations required for the flash.

The diagram below summarizes the high level breakdown.

Hardware Interfaces

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

Primary Clock: clk_i

Other Clocks: none

Bus Device Interface: tlul

Bus Host Interface: none

Peripheral Pins for Chip IO: none

Interrupts:

Security Alerts: none

Signals

In addition to the interrupts and bus signals, the tables below lists the flash protocol controller I/Os.

Each of flash_i and flash_o is a struct that packs together additional signals, as shown below

The physical controller IOs are listed and described below.

Design Detials

Flash Protocol Controller Description

The flash protocol controller uses a simple FIFO interface to communicate between the software and flash physical controller. There is a read fifo for read operations, and a program fifo for program operations. Note, this means flash can be read both through the controller and the main bus interface. This may prove useful if the controller wishes to allocate specific regions to HW FSMs only, but is not a necessary feature.

When software initiates a read transaction of a programmable number of flash words, the flash controller will fill up the read FIFO for software to consume. Likewise, when software initiates a program transaction, software will fill up the program FIFO for the controller to consume.

The controller is designed such that the overall number of words in a transaction can significantly exceed the FIFO depth. In the case of read, once the FIFO is full, the controller will cease writing more entries and wait for software to consume the contents (an interrupt will be triggered to the software to alert it to such an event). In the case of program, the controller will stop writing to flash once all existing data is consumed - it will likewise trigger an interrupt to software to prepare more data. See detailed steps in theory of operation. The following is a diagram of the controller construction as well as its over connectivity with the flash module.

Host Read

Unlike controller initiated reads, host reads have separate rdy / done signals to ensure transactions can be properly pipelined. As host reads are usually tied to host execution upstream, additional latency can severely harm performance and is not desired. The expected waveform from the perspective of the physical controller is shown below.

The host_req_done_o is always single cycle pulsed and upstream logic is expected to always accept and correctly handle the return. The same cycle the return data is posted a new command / address can be accepted. While the example shows flash reads completing in back to back cycles, this is typically not the case.

Controller Read

Unlike host reads, controller reads are not as performance critical and do not have command / data pipeline requirements. Instead, the protocol controller will hold the read request and address lines until the done is seen. Once the done is seen, the controller then transitions to the next read operation. The expected waveform from the perspective of the physical controller is shown below.

Controller Program

Program behavior is similar to reads. The protocol controller will hold the request, address and data lines until the programming is complete. The expected waveform from the perspective of the physical controller is shown below.

Programmers Guide

Issuing a Controller Read

To issue a flash read, the programmer must

• Specify the address of the first flash word to read
• Specify the number of total flash words to read, beginning at the supplied address
• Specify the operation to be ‘READ’ type
• Set the ‘START’ bit for the operation to begin

The above fields can be set in the CONTROL and ADDR registers. See library code for implementation.

It is acceptable for total number of flash words to be significantly greater than the depth of the read FIFO. In this situation, the read FIFO will fill up (or hit programmable fill value), pause the flash read and trigger an interrupt to software. Once there is space inside the FIFO, the controller will resume reading until the appropriate number of words have been read. Once the total count has been reached, the flash controller will post OP_DONE in the OP_STATUS register.

Issuing a Controller Program

To program flash, the same procedure as read is followed. However, instead of setting the CONTROL register for read operation, a program operation is selected instead. Software will then fill the program FIFO and wait for the controller to consume this data. Similar to the read case, the controller will automatically stall when there is insufficient data in the FIFO. When all desired words have been programmed, the controller will post OP_DONE in the OP_STATUS register.

Register Table

The flash protocol controller maintains two separate access windows for the FIFO. It is implemented this way because the access window supports transaction back-pressure should the FIFO become full (in case of write) or empty (in case of read).