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

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.

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.