This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HSELx behavior for One master to two slave transfer (back to back) for address A (slave1) and address B (slave2)

How will HSELx behave for the following Scenario?

We have one AHB master and two AHB slaves connected.

Master initiates two transactions (one after another) as follows.

1. The First transaction is for address (slave 1).  [In 1st clock cycle Address phase of A, 2nd clock cycle Data phase A]

2. The Second transaction is for address B (Slave 2). [2nd clock cycle address phase of B, 3rd clock cycle Data phase B]

My question here is:

    1. How HSELx is going to behave? Is the following correct?

          - HSEL1 will be high on the 1st clock cycle, in the 2nd clock cycle, it will be low.

          - HSEL2 will be high on the 2nd clock cycle, in the 3rd clock cycle, it will be low.   

    2. Does the address decoder sample address from the address bus at positive clock edge? or when address will change in address bus, then only it will decode that address and generate HSELx?

Parents
  • HSEL is a combinatorially produced signal, decoded only from HADDR. No other AHB signals should form part of your address decoding function.

    Especially not HTRANS !

    And not HCLK !

    Or HREADY !

    So in your example, whenever HADDR matches an address allocated to slave 1, HSEL1 will be driven high by your address decoder, as in the 1st cycle.

    HADDR then matches an address for slave 2 in cycle 2 in your example, so HSEL2 will be high in cycle 2.

    Note that if any slave drives HREADY low, this will stall the current address phase signals (including HADDR), so HSEL could be high for a number of cycles before this address phase ends (when HREADY is driven high to end the previous transfer's data phase). HREADY is not an input to the address decode logic, it is an input to the master generating HADDR.

    And if you are performing numerous transfers to the same slave in a sequence, HSEL will be high to that slave for a number of transfer address phases.

    HSEL (and HADDR and other control signals) should only be sampled by a slave when HREADY is high, indicating the end of the current address phase transfer. This is because these control signals can change during a waited transfer in certain circumstances, for example when a slave returns a non-OKAY response.

    There must always be one slave in the system selected so that it can drive HREADY and HRESP during that transfer's data phase, so any addresses not allocated to slaves in your system need to be allocated to a "default slave" so that it can return ERROR responses to any NONSEQ or SEQ accesses.

    Try to keep the address map implemented by the system address decoder as simple as possible. Try to only use HADDR MSBs as this will make the combinatorial logic easier to synthesise to meet single cycle timing.

    Slaves must be assigned a minimum of 1K of memory, so address decoding on the bus never needs to look at HADDR[9:0].

    Hopefully that answers your two questions above, and perhaps a few more you might then have asked.

Reply
  • HSEL is a combinatorially produced signal, decoded only from HADDR. No other AHB signals should form part of your address decoding function.

    Especially not HTRANS !

    And not HCLK !

    Or HREADY !

    So in your example, whenever HADDR matches an address allocated to slave 1, HSEL1 will be driven high by your address decoder, as in the 1st cycle.

    HADDR then matches an address for slave 2 in cycle 2 in your example, so HSEL2 will be high in cycle 2.

    Note that if any slave drives HREADY low, this will stall the current address phase signals (including HADDR), so HSEL could be high for a number of cycles before this address phase ends (when HREADY is driven high to end the previous transfer's data phase). HREADY is not an input to the address decode logic, it is an input to the master generating HADDR.

    And if you are performing numerous transfers to the same slave in a sequence, HSEL will be high to that slave for a number of transfer address phases.

    HSEL (and HADDR and other control signals) should only be sampled by a slave when HREADY is high, indicating the end of the current address phase transfer. This is because these control signals can change during a waited transfer in certain circumstances, for example when a slave returns a non-OKAY response.

    There must always be one slave in the system selected so that it can drive HREADY and HRESP during that transfer's data phase, so any addresses not allocated to slaves in your system need to be allocated to a "default slave" so that it can return ERROR responses to any NONSEQ or SEQ accesses.

    Try to keep the address map implemented by the system address decoder as simple as possible. Try to only use HADDR MSBs as this will make the combinatorial logic easier to synthesise to meet single cycle timing.

    Slaves must be assigned a minimum of 1K of memory, so address decoding on the bus never needs to look at HADDR[9:0].

    Hopefully that answers your two questions above, and perhaps a few more you might then have asked.

Children