Does AHB Specification prohibit a combo path from HTRANS to HREADYOUT?

It wouldn't make sense to have such a path.

HTRANS is an address phase signal, and HREADYOUT is a data phase signal, so you would use HCLK rising to sample the HTRANS value to see what the AHB manager required before the subordinate would know what it wanted to signal on HREADYOUT.

To turn the question back to you, why would you ever want to have a combinatorial path from HTRANS to HREADYOUT ?

It wouldn't make sense to have such a path.

HTRANS is an address phase signal, and HREADYOUT is a data phase signal, so you would use HCLK rising to sample the HTRANS value to see what the AHB manager required before the subordinate would know what it wanted to signal on HREADYOUT.

To turn the question back to you, why would you ever want to have a combinatorial path from HTRANS to HREADYOUT ?

Hi Colin Campbell. Thank you for your response. Yes, that makes sense. So, it looks like it is inferred from the AHB spec that there shouldn't be a path from HTRANS to HREADYOUT. In my case, HTRANS never really combinatorially changes the HREADYOUT in the same cycle - it is a synthesis path which exists from HTRANS to HREADYOUT (gated by another signal in the path which prevents a direct relationship in the same cycle). However, since the initiator also has a combo path from HREADYOUT to HTRANS, it creates a combo loop. 

 If I may ask, can an initiator have a combo path from HREADYOUT to HTRANS?

Looking at the AHB Specification, it seems to be that the HTRANS driven out should be registered (depending on the HREADYOUT in the current cycle) - is that correct? Is there a special case where the initiator would want to change HTRANS combinatorially based on HREADYOUT input from the subordinate - is it allowed to do so as per the spec?

Other than HADDR being combinatorially decoded in the AHB decoder block, there shouldn't be any combinatorial use of any signal in an AHB system (although I suppose the paths through the combinatorial subordinate to manager response MUXes are the other examples).

The HTRANS input (and all other address phase inputs) on a subordinate should only be sampled when HREADY is high to determine what the next required transfer is, and then based on that sampled address phase request the subordinate will drive the HREADYOUT signal as required.

So there shouldn't be any synthesis path from HTRANS to HREADYOUT in the subordinate, regardless of what other signal is gating this, and equally there should never be any combinatorial path from the HREADY input on the manager to HTRANS output. Again both of these paths should be registering the input signal before using it.

Also looking at the AHB protocol document you should see that all diagrams show HTRANS only changing once HREADY has been registered, and never used combinatorially. Similarly HREADYOUT not changing until HTRANS has been registered.

Neither of these scenarios is explicitly stated in the protocol document, but they are implied due to how the protocol functions. Any combinatorial use of any signal risks adding a critical timing path, or in your system where you appear to have combinatorial paths at both manager and subordinate, you risk infinite loops.