• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 88 subscribers
  • Views 10355 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 Multilayer

Jesuraj vinoth Joseph
Note: This was originally posted on 30th April 2008 at http://forums.arm.com

In the multilayer environment,  i found a interconnect matrix with interface signals on the Master side having a hsel signal. Can anyone specify the significance of it. A basic doubt is that apart from the interconnect matrix do we hav any slave mux and decoder.
Parents
  • 0
    Note: This was originally posted on 8th May 2008 at http://forums.arm.com

    Hi Ark,

    I don't know anything about the Cadence UVC, but assuming they haven't done anything strange with their signals, the HSELS0 input should be driven by your local AHB Decoder. This means the interconnect slave port is just one of the slaves appearing on your master's bus.

    However if the interconnect is the only slave connected directly to your AHB master, you won't have a local AHB decoder (because all transfers are routed to the interconnect), and so the HSELS0 input would be tied to 1'b1.

    As far as the HREADYS0 and HREADYOUTS0 pins on the interconnect are concerned, this is what you will always see on any AHB slave.

    For the scenario where you have lots of local slaves, the HREADYOUTS0 signal is MUXed together with all the other local slave HREADYOUT signals, so that the data phase active HREADYOUT signal is routed to the AHB master HREADY input, and this MUX output is also routed back to ALL the local slaves as the HREADY input (the HREADYSo input on the interconnect).

    For the single slave scenario (where HSELS0 is tied to 1'b1), the MUX is not needed. As the interconnect will always be the data phase active slave, its HREADYOUTS0 signal drives the master's HREADY input, and is also directly driven back into the interconnect HREADYS0 input.

    Or at least that's how I've seen ARM's AHB interconnect used :rolleyes:

    JD..
Reply
  • 0
    Note: This was originally posted on 8th May 2008 at http://forums.arm.com

    Hi Ark,

    I don't know anything about the Cadence UVC, but assuming they haven't done anything strange with their signals, the HSELS0 input should be driven by your local AHB Decoder. This means the interconnect slave port is just one of the slaves appearing on your master's bus.

    However if the interconnect is the only slave connected directly to your AHB master, you won't have a local AHB decoder (because all transfers are routed to the interconnect), and so the HSELS0 input would be tied to 1'b1.

    As far as the HREADYS0 and HREADYOUTS0 pins on the interconnect are concerned, this is what you will always see on any AHB slave.

    For the scenario where you have lots of local slaves, the HREADYOUTS0 signal is MUXed together with all the other local slave HREADYOUT signals, so that the data phase active HREADYOUT signal is routed to the AHB master HREADY input, and this MUX output is also routed back to ALL the local slaves as the HREADY input (the HREADYSo input on the interconnect).

    For the single slave scenario (where HSELS0 is tied to 1'b1), the MUX is not needed. As the interconnect will always be the data phase active slave, its HREADYOUTS0 signal drives the master's HREADY input, and is also directly driven back into the interconnect HREADYS0 input.

    Or at least that's how I've seen ARM's AHB interconnect used :rolleyes:

    JD..
Children
No data