• Locked Locked
  • Replies 6 replies
  • Subscribers 120 subscribers
  • Views 7751 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

Accelerator Coherency Port

Shakith Fernando
Note: This was originally posted on 25th January 2013 at http://forums.arm.com

Hi all,

I'm trying to use the AcceleratorCoherency Port of the ARM A9MPCORE in the Xilinx Zynq platform (http://www.xilinx.co...vices/index.htm).

1.[size="2"]  [/size]I have a functionaldesign where DMA in the FPGA region is able read and write data through the ACP.But is there direct way to verify that the data is coming from the cacheitself. Only option is to measure cache hits using the PL310 cache controllerevent registers againist a known data set size. But it's a not exact solution,as there may be cache hits in the L1 cache hits instead of L2.

2. As mentioned here (http://forums.arm.co...pcore-acp-port/),I downloaded the Ds5 tools to get access to the reference design, but there is nospecific target design for the ACP. The startup code that enables MMU, L1 cachesand SCU should be enough to make sure the ACP is getting the data from cache?

3.  Cacheable region setting can be set in the MMU table. Butdoes it guarantee exclusive access to a fixed memory region. Maybe if a linux osis running, then it can cause cache thrashing. Is there way to set priority forthe region?

4. Is there support for linux for this. As I understand the ACP istechnically a hardware thing and should be transparent to software. Only thing isto do would be to expose the memory region from kernel space to user space togive it to the DMA engine.

Thanks in advance.
Parents
  • Note: This was originally posted on 27th January 2013 at http://forums.arm.com

    [color=#222222][font=Arial, sans-serif][size=2]> But is there direct way to verify that the data is coming from the cacheitself[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]No.[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]> The startup code that enables MMU, L1 caches and SCU should be enough to make sure the ACP is getting the data from cache?[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]The request into the ACP determines coherency properties. See [/size][/font][/color][color=#222222][font=Arial, sans-serif][size=2]http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/CACGGBCF.html[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]> Maybe if a linux osis running, then it can cause cache thrashing. Is there way to set priority for the region?[/size][/font][/color]


    If you have multiple masters hammering the cache then yes you will get thrashing. There is no concept of region priority.


    [color=#222222][font=Arial, sans-serif][size=2]> Is there support for linux for this. As I understand the ACP is technically a hardware thing and should be transparent to software. Only thing is to do would be to expose the memory region from kernel space to user space to give it to the DMA engine.[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]
    [/size][/font][/color]
    The ACP itself is transparent, but you are going to need some kernel-side device driver to handle the DMA engine and the memory it uses. ACP makes it easier (and avoid cache maintenance), but there is still a lot of other "driver things" you will need (like VA to PA translation, the ability to share one hardware block over multiple user-space processes, ensuring memory cannot move while being accesses by the DMA, etc).


    HTH,
    Iso
Reply
  • Note: This was originally posted on 27th January 2013 at http://forums.arm.com

    [color=#222222][font=Arial, sans-serif][size=2]> But is there direct way to verify that the data is coming from the cacheitself[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]No.[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]> The startup code that enables MMU, L1 caches and SCU should be enough to make sure the ACP is getting the data from cache?[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]The request into the ACP determines coherency properties. See [/size][/font][/color][color=#222222][font=Arial, sans-serif][size=2]http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407e/CACGGBCF.html[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]
    [/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]> Maybe if a linux osis running, then it can cause cache thrashing. Is there way to set priority for the region?[/size][/font][/color]


    If you have multiple masters hammering the cache then yes you will get thrashing. There is no concept of region priority.


    [color=#222222][font=Arial, sans-serif][size=2]> Is there support for linux for this. As I understand the ACP is technically a hardware thing and should be transparent to software. Only thing is to do would be to expose the memory region from kernel space to user space to give it to the DMA engine.[/size][/font][/color]
    [color=#222222][font=Arial, sans-serif][size=2]
    [/size][/font][/color]
    The ACP itself is transparent, but you are going to need some kernel-side device driver to handle the DMA engine and the memory it uses. ACP makes it easier (and avoid cache maintenance), but there is still a lot of other "driver things" you will need (like VA to PA translation, the ability to share one hardware block over multiple user-space processes, ensuring memory cannot move while being accesses by the DMA, etc).


    HTH,
    Iso
Children
No data