Skip to content

Latest commit

 

History

History
182 lines (139 loc) · 7.41 KB

AHB.md

File metadata and controls

182 lines (139 loc) · 7.41 KB

Advanced High-performance Bus

As stated in the ReadMe, the AHB is the backbone of the SoC, so it is important that you gain an inherent understanding of the AHB.

AHB Components

The AHB requires a many components to work efficiently and high-performancey.

Manager

  • Initiates read and write operations

  • Provides address and control information

Subordinate

  • Responds to the transfers initiated by the manager within the system

  • Uses a selX select signal, where X is just some identifier, for example:

    • Memory controller will have signal sel0
    • AHB-APB bridge will be sel1

  • A subordinate will use the selX signal from the decoder to determine whether it should respond to the bus transfer

  • All other signals for the transfer will be generated by the manger

Data Buses

  • AHB has two data buses:

    • wdata[31:0]: The write data bus is used to move data from the manager to the subordinate, and is driven by the manager
    • rdata[31:0]: The read data bus is used to move data from subordinate to manager, and is driven by the subordinate

  • AHB uses two buses instead of one to avoid the use of tri-state drivers

  • The minimum data bus width is 32 bits, which is also what we implement

  • For transfers lower than the minimum width, the component has to drive the appropriate byte lanes

  • Burst transfers with a transfer size less than the bus width will have
    different active byte lanes for each beat of the burst

  • The active byte lane is dependent on the endianness of the system

    • Since RISC-V is little endian, we use that

  • In the case of read transfers (using rdata[31:0]), the subordinate has to provide valid data when a transfer completes with an okay response; other responses don't require valid data

MUX

  • Routes the read data and response signals to and from the subordinates to the manager

  • Each subordinate will have a unique input

Decoder

  • Used to perform centralised address decoding, which improves portability of peripherals by making them independent of the system memory map

Bus Privilege

Since we are developing a single-manager system for now, we can assume that the manager always has bus access.

In the case of a multi-manager system, the manager would have to assert a request signal to the arbiter, which will then indicate whether the manager has bus access.

The Bus is Pipelined

The bus is pipelined, to allow high-performance operations. The bus overlaps address and data phases.

The address phase of the next transfer occurs during the data phase of the previous transfer.

However, in case the previous transfer is extended, it will have the side-effect of extending the address phase of the next transfer, since they are part of the same "phase" of the bus (think of this as adding nop's in pipelined E20; nop's between instructions 2 and 4 will affect instruction 5 and beyond).

Address Decoding

  • The central decoder is used to provide the select signal selX, for each of the subordinates on the bus

  • A subordinate must only sample the address and control signals and selX when ready is high (current transfer is completing)

  • The minimum address space that can be allocated to a single subordinate is 1kB

  • The manager will be designed such that they will not perform incrementing transfers over 1kb

  • In case an SoC does not contain a completely filled memory map (which is very likely early on with us), a default subordinate must be implemented to provide a response when any of the non-existent address locations are accessed

    • Non-sequential or sequential transfers: error response
    • Idle or busy transfers: Zero-wait-state okay response
    • This functionality will be implemented as part of the decoder

Transfer Commencement

  • A manager commences an AHB transfer by driving address and control signals:

    • Provide information on the address direction (read/write) and width
    • Indicate if the transfer is part of a burst

  • Every Transfer consists of:

    • Address phase: One cycle for address and control signals
    • Data phase: At least one cycle for the data

  • The address phase cannot be extended, so it is important for the subordinate to sample the address

  • The data phase can be extended using the ready signal:

    • Low: Wait states in the transfer and allow extra time for the subordinate
    • High: Transfer completed successfully

Transfer Responses

  • A subordinate shows the status using the response signals resp[1:0] after the manager has started the transfer

    • Think of this as a real-time status monitor

  • Signals:

    • okay: If the transfer is progressing normally
    • error: An error has occurred and the transfer was unsuccessful
    • retry and split: Transfer cannot complete immediately but keep trying (it's in the name)
      • The difference has to do with how the arbiter allocates the bus after either response, we don't need to worry about this for now.

Two-cycle Response

  • The okay response can be given in a single cycle

  • The error, retry, and split responses require at least two cycles

    • To complete with any of these, the subordinate has to drive resp[1:0] appropriately whilst driving ready low to extend the transfer for an extra cycle
    • In the final cycle, ready is driven high to end the transfer, whilst resp remains from the previous cycle
    • If additional cycles are required, additional wait states may be inserted by driving ready low and respond okay

  • For split and retry, the following transfer must be cancelled because it must not take place before the current transfer has completed

  • For the error response, where the current transfer is not repeated, the cancellation of the following transfer is optional

  • Two-cycle responses are required for a pipelined bus

    • By the time the subordinate starts to issue a two-cycle response, the address of the following transfer has already been broadcast to the bus

    • This response allows sufficient time for the manager to cancel this address and drive trans[1:0] to idle before the start of the next transfer.

Transfer Completion

A manager can complete the transfer many ways:

  • Complete the transfer immediately
  • Insert one or more wait states to allow time to complete the transfer
  • Signal an error to indicate failure
  • Delay the completion of the transfer, but back off the bus for other subordinates

The ready signal identifies the completeness of the transfer

  • Low: Wait states in the transfer and allow extra time for the subordinate
  • High: Transfer completed successfully

Note: Transfer responses and transfer completion blend together, so these two sections should really be comprehended as one. We have them separated to draw a firm difference between what is considered "complete", and, because responses also happen regardless of completeness.