Arm Community
Site
Search
User
Site
Search
User
Groups
Education Hub
Distinguished Ambassadors
Open Source Software and Platforms
Research Collaboration and Enablement
Forums
AI and ML forum
Architectures and Processors forum
Arm Development Platforms forum
Arm Development Studio forum
Arm Virtual Hardware forum
Automotive forum
Compilers and Libraries forum
Graphics, Gaming, and VR forum
High Performance Computing (HPC) forum
Infrastructure Solutions forum
Internet of Things (IoT) forum
Keil forum
Morello forum
Operating Systems forum
SoC Design and Simulation forum
SystemReady Forum
Blogs
AI and ML blog
Announcements
Architectures and Processors blog
Automotive blog
Graphics, Gaming, and VR blog
High Performance Computing (HPC) blog
Infrastructure Solutions blog
Internet of Things (IoT) blog
Operating Systems blog
SoC Design and Simulation blog
Tools, Software and IDEs blog
Support
Arm Support Services
Documentation
Downloads
Training
Arm Approved program
Arm Design Reviews
Community Help
More
Cancel
Support forums
Arm Development Studio forum
Accelerator Coherency Port
Jump...
Cancel
Locked
Locked
Replies
6 replies
Subscribers
120 subscribers
Views
7836 views
Users
0 members are here
Options
Share
More actions
Cancel
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
over 10 years ago
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
Shakith Fernando
over 10 years ago
Note: This was originally posted on 14th February 2013 at
http://forums.arm.com
I got the PMU registers working using inline assembly code for the cp15 registers method.
I have also enabled ACP coherent read and write requests using[font=Verdana, Tahoma, Arial, Helvetica, sans-serif] this[/font][font=Verdana, Tahoma, Arial, Helvetica, sans-serif]
[/font]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/index.html
I am able to monitor and verify the exact number of cache read hits for ACP read (externel DMS reads from the l1 cache) using the ARM PMU event monitors. I get 72 data cache hits. That is 64 + 8. 8 (4*2) is I guess is for X_mWriteReg function calls.
start_perfmon();
X_mWriteReg(0x60000000,0x0,0x00005000); //Start DMA
X_mWriteReg(0x60000000,0x18,0xFFFF8000); //Src Address
X_mWriteReg(0x60000000,0x20,0x80000000); //Dst Address
X_mWriteReg(0x60000000,0x28,0x00000040); //Number of bytes - 64 bytes
stop_perfmon();
But for the otherway around is tricky to verify. (ACP writes- Externel DMA writes to the cache). As it looks like a write through policy from above link, it should be writing to the L2 cache all the ACP writes. Therefore P310 L2 Event counters for data writes should be around 64 or something similar. Strangely it shows zero or one. Is it really write through?
Cancel
Up
0
Down
Cancel
Reply
Shakith Fernando
over 10 years ago
Note: This was originally posted on 14th February 2013 at
http://forums.arm.com
I got the PMU registers working using inline assembly code for the cp15 registers method.
I have also enabled ACP coherent read and write requests using[font=Verdana, Tahoma, Arial, Helvetica, sans-serif] this[/font][font=Verdana, Tahoma, Arial, Helvetica, sans-serif]
[/font]
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388e/index.html
I am able to monitor and verify the exact number of cache read hits for ACP read (externel DMS reads from the l1 cache) using the ARM PMU event monitors. I get 72 data cache hits. That is 64 + 8. 8 (4*2) is I guess is for X_mWriteReg function calls.
start_perfmon();
X_mWriteReg(0x60000000,0x0,0x00005000); //Start DMA
X_mWriteReg(0x60000000,0x18,0xFFFF8000); //Src Address
X_mWriteReg(0x60000000,0x20,0x80000000); //Dst Address
X_mWriteReg(0x60000000,0x28,0x00000040); //Number of bytes - 64 bytes
stop_perfmon();
But for the otherway around is tricky to verify. (ACP writes- Externel DMA writes to the cache). As it looks like a write through policy from above link, it should be writing to the L2 cache all the ACP writes. Therefore P310 L2 Event counters for data writes should be around 64 or something similar. Strangely it shows zero or one. Is it really write through?
Cancel
Up
0
Down
Cancel
Children
No data