This section describes each of the design modules in detail.
Figure 3 shows the input stage. All of the ports on the left side of the diagram are connected to the input layer and all the ports on the right of the diagram are connected to either the decoder or output stages within the BusMatrix.
The main function of the input stage is to hold the address and control information from the input layer if the transfer cannot be passed immediately to the appropriate shared slave. This is required because in the AHB protocol the duration of the address phase is controlled by the slave. The slave was accessed by the previous transfer and therefore the BusMatrix cannot extend the address phase of the transfer if the required shared slave is not available.
The loading of the holding register is controlled by the Active signal. Each output stage generates a set of Active signals, one per input stage, which indicates that the address/control signals from a given input stage are currently being driven on to the required shared slave.
Whenever a transfer arrives at the input stage it is either passed directly to the output stage, if Active is HIGH, or it is loaded in to the holding register if Active is LOW. The multiplexor in the address/control signal path simply selects the holding register when it is loaded or the straight-through path when it is empty.
The HeldTran signal is generated within the input stage and indicates if the holding register is full or empty. To be more precise, the HeldTran signal indicates if the holding register is full or empty in the following cycle. This signal is not only used within this block, but is also routed to the output arbitration block, because it shows that the input stage has a transfer that is ready to start.
The second main function of the input stage is to generate the HREADYOUT and HRESP signals for the input layer and this is done as follows:
When a transfer has been routed to the appropriate output stage the HREADYOUT and HRESP are generated from the equivalent signals at the output stage.
When a transfer is stored in the holding register HREADYOUT is driven LOW to stall the transfer and HRESP indicates OKAY.
When the input stage is not being accessed or for an IDLE or BUSY transfer, HREADYOUT is driven HIGH and HRESP indicates OKAY, as required by the AHB protocol.
The final function provided by the input stage is shown in Figure 3 by the two logic bubbles on the HTRANS and HBURST paths as they leave the input stage. These two patches of logic are used to override the transfer type information and the burst information if a fixed length burst to a shared slave is interrupted before it reaches completion. If this happens, the burst information is changed to indicate an INCR undefined length burst. The transfer type signals are only overridden to NONSEQ, if a wrapping burst has been changed to an INCR burst and has crossed the wrap boundary.
Each input stage has a decoder associated with it, which is used to determine the output stage that is required to complete an access. Because the address map of every system can be different, the main address decode function of the decoder can be changed if required. Within the RTL this section of code, which converts from the incoming address bus to an output port number AddrOutPort, is located at the top of the file. Figure 4 shows the decoder.
By default, the decoder is supplied with each of the output ports occupying 16MB of address space, that is, HADDR[26:24] is used to determine the output port required.
Within the decoder, AddrOutPort is used to show which output port the current address and control information is destined for. DataOutPort is used to show which output port is being used for the data phase of the previous transfer.
AddrOutPort is used for two routing functions. Firstly, assuming that the input Sel signal is HIGH, AddrOutPort is used to determine which output stage select signal must be asserted. Only one output Sel signal can be asserted at a time. Each output stage has a Sel signal from each input layer and the output stage arbitration can use this to determine which input stages has to perform a transfer.
The second use of AddrOutPort is to route the appropriate Active signal back to the input stage. The Active signal indicates that the address of the input port is being actively driven to the shared slave, so the transfer does not have to be held in the input stage.
Each time an address phase completes, as indicated by HREADY being HIGH, the data phase of the transfer commences. Whenever HREADY is HIGH, the output port number in AddrOutPort is moved to DataOutPort to indicate the output port required to complete the transfer.
Within the decoder DataOutPort is then used to select the HREADYOUT, HRESP, and HRDATA from the appropriate output stage and route these back to the input stage.
If an input layer accesses one shared slave and then immediately follows this with an access to a different shared slave, the output port indicated by AddrOutPort is different from the output port indicated by DataOutPort.
Each output stage gives access to a shared slave. In reality there can be more than one shared slave connected to an output stage, but from the perspective of the BusMatrix this is not important and it can treat multiple shared slaves on the same port as just one slave (see Address decoding strategies for more information on connecting multiple shared slaves to one output stage).
Each output stage has two main functions:
it contains an output arbitration block to decide which input stage is given access to the shared slave
it contains a set of routing multiplexors.
Figure 5 shows the output stage.
The main routing multiplexors in the output stage are the address/control signals multiplexor, which is controlled directly using AddrInPort. The write data multiplexor is controlled using the data phase signal, DataInPort.
The address/control signals multiplexor is followed by another multiplexor, which drives all the address/control output signals to inactive levels when no input stages are selected, as indicated by the NoPort signal.
The two other functions contained within the output stage are the generation of the Active signals and the generation of the HREADY signal for the shared slave:
The Active signals indicate back to the various input stages which one is currently driving out to the shared slave. Only one Active signal is asserted at any time.
The HREADY signal for the shared slave is generated from the HREADYOUT signal of the slave when it is selected and at all other times it is driven HIGH.
The Request signals for the output arbitration are generated within the output stage by ANDing the HeldTran signal with the Select signal from each input stage. The HeldTran signal shows that there is a transfer ready to commence and the Select signal shows that it is destined for this particular output stage.
It is important that the arbitration process uses the HeldTran signal, rather than just using HTRANS(1), because the HeldTran signal also includes the fact that the HREADY signal on the input layer is HIGH. This is important because otherwise a transfer can be routed to the shared slave before it is has actually started on the input layer.
Within the output arbitration block all of the Request signals are combined to work out which input stage must be used for the next transfer. The arbitration process follows four steps:
If HMASTLOCK is asserted, the same input stage remains selected.
If HMASTLOCK is not asserted, all the different requests are examined and the highest priority input stage is selected. The algorithm that is used to choose between the input stages can be user-modified and two different schemes, fixed priority and round-robin, are supplied.
If no input stage is requesting access and the currently selected input stage is performing Idle transfers to the shared slave, that is, the Sel signal is still asserted, then the same input stage is selected.
If none of the above apply, the NoPort signal is asserted, which indicates that none of the input stages must be selected and the address/control signals to the shared slave must be driven to an inactive state.
Figure 6 shows the output arbitration.
The output arbitration registers the result of the arbitration process before passing this to the output stage multiplexors. This is done to avoid the critical path of attempting to:
work out which input stages requires a transfer
arbitrate between them
switch the output multiplexors and still provide the address and control signals to the shared slave with adequate setup time.
However, this registering of the arbitration result can lead to a single cycle delay when an input layer first attempts access to a shared slave. The single cycle delay becomes hidden if the shared slave is already being accessed by another input layer.
The cycle delay only occurs on the first access to a shared slave. If an input layer performs a sequence of bursts to the shared slave, all of which are in the same address decode region then the single cycle penalty is only observed for the first access in the sequence.
It is possible in low clock frequency systems to remove the register stage. This removes the cycle delay that occurs to give an input stage access to the shared slave. However, this must only be done in circumstances where it is known that the critical arbitration timing path can be satisfied.