• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 87 subscribers
  • Views 14935 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

AHB Bufferable/Non-bufferable write

Hariprem Arora
Note: This was originally posted on 12th September 2008 at http://forums.arm.com

Hi,

Please clarify the following issue related to AHB write:

If HPROT[2] = 1, AHB write is bufferable and we need to provide OKAY response as soon as the AHB slave interface receives data without caring that the data is actually written into the memory or not.

if HPROT[2] = 0, AHB write is non-bufferable, AHB slave interface needs to provide response to the master only when the data is actually written into the memory.

The issue is that if we see this non-bufferable transaction, the state of HRESP will by default be OKAY (HREADY is HIGH to accept the next data) and it means that we are providing the response in advance for non-bufferable write.

Please clarify how to distinguish between the two transactions.
If possible, please provide waveforms for INCR undefined length & non-bufferable write
  • 0
    Note: This was originally posted on 16th September 2008 at http://forums.arm.com

    Hi JD,

    Thanks for your prompt responses. I find it really useful.

    Hari
  • 0
    Note: This was originally posted on 15th September 2008 at http://forums.arm.com

    Hi JD,

    Thanks for clarification regarding response from AHB slave for non-bufferable write.

    so from the explanation, I understood that AHB slave has to pull HREADY LOW to insert wait state.

    Does it mean AHB slave can insert wait state for each data transacted in a burst to give actual destination slave response. Is this feasible with regards to the throughput.

    Hari
  • 0
    Note: This was originally posted on 16th September 2008 at http://forums.arm.com

    Hi JD,

    Its clear that we need to insert wait states if we want to have destination slave response.

    From here we have following approaches for non-bufferable writes:

    Approach 1 :
    i) Do specified length transfers with last data transfer done by inserting wait state so that real response can be taken for whole burst.
    ii) Do unspecified length transfers with each data transfer done by inserting wait state because slave doesn't know when the last data transfer will occur.

    Approach 2 :
    Remove the unspecified length transfer feature so that it doesn't effect throughput (as wait state is inserted for each data transfer in a burst to get real response).

    Please suggest if the above approaches feasible.

    Hari
  • 0
    Note: This was originally posted on 15th September 2008 at http://forums.arm.com

    Hi JD,

    Thanks for the detailed information.

    For non-bufferable write, you have mentioned :

    >Yes, that is the risk with providing the early response, if the destination slave    >decides on a different response you cannot change anything.

    I need to know what kind of strategy needs to be employed if destination slave has different response than the early response provided by AHB slave interface.

    How AHB master takes action in this case.

    Hari
  • 0
    Note: This was originally posted on 12th September 2008 at http://forums.arm.com

    Hi Hari,

    > If HPROT[2] = 1, AHB write is bufferable and we need to
    > provide OKAY response as soon as the AHB slave interface
    > receives data without caring that the data is actually written
    > into the memory or not.

    First thing is that you do not need to provide a response from any intermediate module (rather than the destination slave), this is only an option for you to consider to speed up the transfers for bufferable writes.

    Next thing is that you do not need to provide an OKAY response. If your intermediate component decides that a transfer is not allowed, it could give an ERROR response.

    > if HPROT[2] = 0, AHB write is non-bufferable, AHB slave
    > interface needs to provide response to the master only when
    > the data is actually written into the memory.
    >
    > The issue is that if we see this non-bufferable transaction, the
    > state of HRESP will by default be OKAY (HREADY is HIGH to
    > accept the next data) and it means that we are providing the
    > response in advance for non-bufferable write.

    Yes, that is the risk with providing the early response, if the destination slave decides on a different response you cannot change anything.

    > Please clarify how to distinguish between the two transactions.

    Well you already know how to distinguish between them, that is what the HPROT[2] signal is for.

    > If possible, please provide waveforms for INCR undefined length &
    > non-bufferable write

    There is nothing special here that I would think needs extra waveforms. If the burst sequence is non-bufferable, and you are going via some interim buffering module, you will just see additional wait states for each access while it completes through to the destination device and a real response is returned to the originating master.

    JD
  • 0
    Note: This was originally posted on 15th September 2008 at http://forums.arm.com

    Hi Hari,

    > I need to know what kind of strategy needs to be employed
    > if destination slave has different response than the early
    > response provided by AHB slave interface.
    >
    > How AHB master takes action in this case.

    You almost certainly cannot do anything.

    The response for the transfer has already been received by the master, so any "new" response you subsequently tried to return would be treated as applying to a later transfer, so would not affect the earlier "completed" transfer.

    You can only give an early response for bufferable write transfers if you 100% know that the response you give is what the slave will actually eventually return, so a typical example being the end destination slave is a RAM that will accept any transfer.

    If you are not sure what the end slave will do, do not give an early response and just add wait states until you do see the real slave response.

    You do not have to give an early response to bufferable writes, this is only an option for you to consider.

    JD
  • 0
    Note: This was originally posted on 15th September 2008 at http://forums.arm.com

    Hi Hari,

    If you have a module that registers a transfer between the master and slave, and you do want the real transfer response from the destination slave, yes, you will need to add at least one wait state per data transfer to allow this registering component time to sample the real response and then drive it back to the master.

    This will affect throughput, so you need to look at why you are putting in this registering component - is it to another bus protocol, or is it to break a long timing path.

    Can you restructure the architecture to avoid this registering component, or design the destination slave so that it will always give back an OKAY response that can be safely handled as a buffered write ?

    Sorry but if you want to buffer writes AND get the real slave response, you will need wait states that will reduce throughput.

    JD
  • 0
    Note: This was originally posted on 16th September 2008 at http://forums.arm.com

    Hi Hari,

    I would think there are problems with both approaches.

    For approach 1, where you only provide a real response for the last transfer in a burst, this will improve efficiency, but it relies on the master being designed to interpret this final response as applying to the complete burst. Just something your software needs to be aware of when handling the ERROR.

    Also, you would need to make sure that this final real response you return is a summation of all the real responses for the burst, so if only the 3rd transfer in an INCR8 burst received an ERROR, you would need to return ERROR for transfer 8, even if it actually was an OKAY from the slave.

    I am only looking at ERROR responses because for SPLIT and RETRY you would need to locally handle them in your buffering logic, while adding wait states to the master to stall it.

    For approach 2, what will you do if a master attempts an INCR burst ?

    If you do not support them, would you signal ERROR (which would be a problem for most masters) ?

    Sorry, I know I am only raising problems here and not solutions, but if you want to fully support bufferable writes, you should only do so if you know absolutely that the transfers will complete with OKAY responses, or if you don't care what the response is from the slave.

    Your approach 1 is probably the best compromise between efficiency and complexity, assuming the master knows how to interpret the final response, as it does allow buffered writes while still returning a real response.

    Approach 2 I would think is too restrictive.

    I guess it really depends on your application, you know what types of bursts your master(s) will attempt, what responses are possible from your slave(s), and what sort of performance you need, so it looks like you are considering all the right sorts of things.

    Good luck.

    JD