• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 348 subscribers
  • Views 903 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

question about arbitration scheme of AHB bus matrix

JJ HUA

generate an AHB bus matrix ,using the perl script of CMSDK.

Below are the properties of the bus matrix:

  • protocol:AHB2;
  • arbitration scheme:fixed
  • 2 masters:CPU,DMA(CPU is prior to DMA)
  • 3 slaves:ROM(for instruction),SRAM(for data),sdram(other usage)
  • conectivity:full

When using Modelsim to verify,I found that if i let DMA access ROM while CPU accessing ROM to fetch instruction,there will appear a phenomenon that  CPU work normmally,but the timing of DMA AHB interface make mistakes.

I suppose that because of higher priority ,CPU works without disturbing.In contrast,DMA AHB interface goes wrong.

What above is just my thought.I want to know why.

Parents
  • +1

    The CMSDK BusMatrix "FIXED" arbitration scheme implements a priority based scheme where the master connected to the lowest port number has highest priority, and arbitration can change at any point in a burst.

    If you have two masters both trying to access the same ROM target, one master will be stalled (the lowest priority one) by the BusMatrix driving HREADY low while the other is given access to the ROM. The "stalled" master will see wait states added.

    When the "stalled" master is later allowed access to the ROM the BusMatrix logic will create a new burst for the ROM (starting with a NONSEQ access and HBURST driven according to the number of transfers remaining if this was previously a defined length burst), HREADY will go high, and the previously "stalled" master can then continue with its transfers.

    If you are seeing your DMA interface make "mistakes", this won't be a result of anything the CMSDK BusMatrix is doing wrongly, so instead I would suspect that you have not correctly connected the HREADY signals in the system so that somewhere a transfer has been missed.

    If your company has license CMSDK directly from Arm you should submit a support request on the licensee support website, where you can include waveforms showing the "mistake" you are seeing. See the "Support" dropdown menu on https://developer.arm.com/ for details on how to open a support case.

    Or if you have not obtained the CMSDK deliverables direct from Arm, either ask your CMSDK IP supplier for help, or try describing here in more detail what the "mistake" is.

Reply
  • +1

    The CMSDK BusMatrix "FIXED" arbitration scheme implements a priority based scheme where the master connected to the lowest port number has highest priority, and arbitration can change at any point in a burst.

    If you have two masters both trying to access the same ROM target, one master will be stalled (the lowest priority one) by the BusMatrix driving HREADY low while the other is given access to the ROM. The "stalled" master will see wait states added.

    When the "stalled" master is later allowed access to the ROM the BusMatrix logic will create a new burst for the ROM (starting with a NONSEQ access and HBURST driven according to the number of transfers remaining if this was previously a defined length burst), HREADY will go high, and the previously "stalled" master can then continue with its transfers.

    If you are seeing your DMA interface make "mistakes", this won't be a result of anything the CMSDK BusMatrix is doing wrongly, so instead I would suspect that you have not correctly connected the HREADY signals in the system so that somewhere a transfer has been missed.

    If your company has license CMSDK directly from Arm you should submit a support request on the licensee support website, where you can include waveforms showing the "mistake" you are seeing. See the "Support" dropdown menu on https://developer.arm.com/ for details on how to open a support case.

    Or if you have not obtained the CMSDK deliverables direct from Arm, either ask your CMSDK IP supplier for help, or try describing here in more detail what the "mistake" is.

Children