Doubt about the code in ahb_lite_address_decoder.sv

[DerekWangScaleflux]

Hi Caliptra team, In the module "ahb_lite_address_docder.sv":

   What is the purpose of the red marked part here ?
    In one AHB transfer, the "hesl_o_int[rr]" is on the AHB address phase, the "hreadyout_i[rr]" is on the AHB data phase.
    How come they are used in combinational ?

Best Regards Derek Wang

[calebofearth]

Thanks for your detailed code review.

The hreadyout signal from the targeted responder is used in both address and data phases. In the address phase, the requester must stall until the responder is ready. In this code, hsel_o_int indicates that the responder is selected for an access due to address decode, and the hreadyout signal is propagated back to the original requester (as hready) to indicate that address phase is complete and data phase can begin. Note that pending_hsel (which persists through data phase) takes precedence in driving hinitiator_ready_int_q over the hsel_o_int signal.

[DerekWangScaleflux]

Hi @calebofearth , Thanks for the reply.

     But normally hready to master will take hready_out from all slaves AND together, not by selection of hready_out by hsel.
     This lead to a combinational path from the input haddr from the master, to the output hready to the master.

     This doesn't seem to be an issue in Caliptra design now, but maybe not be compatible with another master design.

Best Regards Derek Wang

[calebofearth]

I agree with your reading of the AHB spec, hready could be implemented as the AND of hreadyout from all subordinates. This might be a timing improvement. However, this is not explicitly required based on the below text; the spec describes the behavioral relationship as:

2.5 Multiplexor signals When HIGH, the HREADY signal indicates to the Manager and all Subordinates, that the previous transfer is complete.

and

3.1 Basic Transfers Each Subordinate has an HREADYOUT signal that it drives during the data phase of a transfer. The interconnect is responsible for combining the HREADYOUT signals from all Subordinates to generate a single HREADY signal that is used to control the overall progress.

This functional behavior is facilitated in our logic by giving priority to the pending_hsel signal over hsel_o_int.

Please let us know if this path becomes a critical timing problem in your design. If this solution answers your question, please mark this issue as closed. Thanks!

[DerekWangScaleflux]

Hi, @calebofearth , Our synthesis result is not showing timing issue on the path. Thanks for the reply. We could close this one.

Best Regards Derek Wang