Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

Help using ACP Port with EMAC on Cyclone V

Altera_Forum
Honored Contributor II
1,242 Views

I am trying to configure and use the Accelerator Coherency Port with EMAC1 on a Cyclone V. My understanding is that I should be able to place the descriptors and packet buffers in cachable, shared memory and never need to invalidate or flush the caches from the HPS. Requests from the EMAC DMA engine should be intercepted at the ACP and directed to the SCU which will either read data from the L1/L2 cache or cause a write to invalidate L1/L2 cache. 

 

I have a working EMAC driver that uses uncached descriptors and cached packets buffers. On the receive side, the packet buffers are invalidated in cache before they are given to the EMAC DMA and after the EMAC DMA returns them filled. When filling a TX buffer, the packet buffer is flushed before it is assigned to the EMAC DMA. 

 

From this starting point I have: 

- Changed the uncached descriptors to shared cachable memory. The mmu settings for the descriptors is: Page1: 0x027A3C01, Page2:0x0606645E, and the mmu settings for the packets buffers is: Page1: 0x037A3C01, Page2:0x0606B45E 

- Updated the EMAC’s l3master register in the system manger region to 0xf0f0. This is done while EMAC1 is in reset. 

- Updated the ACP IP Mapper registers for channels 5 and 6 to be assigned to EMAC1. This is done while EMAC1 is in reset. 

vid5rd is set to 0x880201f0 

vid5wr is set to 0x880201f0 

vid6rd is set to 0x88a01f0 

vid6wr is set to 0x880a01f0 

A read of the sync versions of these read back these settings, so they should be in effect. 

- The physical addresses used in the descriptors are all between 0x80000000 – 0xC0000000 

 

This does appear to transmit packets, but the reception is not working. My assumption is that now that the descriptors are cached, they are not getting flushed and the ACP is not reading into caches. 

 

If I walk through the list of items that must be met to use the ACP (“Configuration for ACP Use” in the HPS TRM), 

- The master module must target the ACP in physical memory, addresses 0x80000000 – 0xC0000000). I think this is met since the physical address of the packet buffers in the descriptors, the base address of the descriptor chain in the EMAC DMA registers, and the links to the next packet in the DMA descriptors, all target this range. 

- For ACP read accesses, ARCACHE must be set to the MMU Page table attributes. In l3master register, ARCACHE is set to 0xF which is cacheable write-back, allocate on both reads and writes. Given the PAGE2 settings above, this is write back, write allocate, so I think this is correct. 

- ARCACHE[1] must be 1. Given the setting of 0xF, I think this is met. 

- ARUSER[0] must be 1. This is set in vid5rd/vid6rd. 

- For ACP write accesses, AWCACHE must be set to the MMU Page table attributes. In l3master register, ARCACHE is set to 0xF which is cacheable write-back, allocate on both reads and writes. 

- AWCACHE[1] must be 1. Given the setting of 0xF, I think this is met. 

- AWUSER[0] must be 1. This is set in vid5wr/vid6wr. 

- If an HPS peripheral uses the ACP for coherent master accesses, the AxCACHE and AxUSER properties must be correctly configured. I think this is done per the description here. 

- The SCU must be enabled. This is done. 

- Coherent memory must be cacheable and sharable. Per the Page2 settings, this is done. 

- The SMP bit of the ACTRL register must be set in the ARM cores. This is done. 

 

What am I not understanding, or what suggestions are there for debugging this ? My hw support engineer says he does not have visibility into the AXI transactions between the EMAC and the CPU/ACP/L2 from the quartus tools.
0 Kudos
0 Replies
Reply