This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TDA4VM: PCIe ATU region size

Part Number: TDA4VM

Hi all

we had some problems accessing a connected PCIe device with a memory space of 4MB. It turned out, that the Address Translation Unit ATU is unable to translate the whole 4MB in one piece. We solved the issue by splitting up the memory space into multiple ATU regions, which works for now. However, we’d like to have some clarification on the maximum translatable region size, as we couldn’t find it in the TRM.

In the TRM it says that unspecified behavior may occur, if a transaction goes past one translated region. Are there any provided features to mitigate this problem?

 

Regards

Leonhard

  • Hi all

    is there any news on this topic?

    Regards

    Leonhard

  • Leonhard, 

    Sorry for the delayed response. 4MB seems small as another TI device can support up to 4GB iATU region, it is different controller.

    Can you confirm what is the PCIE_CORE_ATU_WRAPPER_OB_i_AXI_ADDR0[REGION_SIZE]? This field is defined as:

    "The programmed value in this field + 1 gives the region size. Minimum value to be programmed into this field is 7 as the lower 8 bits of the AXI region base address are replaced by zeros by the region select logic. Minimum region size supported is 256 bytes." 

    The description in the TRM is a little brief, so want to check if this field is programmed correctly.

    Jian

  • Jian,

    We just configured the ATU0 to have a region size of 4MB. After configuration the value of PCIE_CORE_ATU_WRAPPER_OB_0_AXI_ADDR0 is 0x18020012, its REGION_SIZE is 18. We use the 32bit base address 0x18020000.

    We’re not quite sure how to interpret the value in this field, as 2^(18+1) = 512kB.

    Regards

    Leonhard

  • Leonhard, 

    sorry for the slow response. can you program the PCIE_CORE_ATU_WRAPPER_OB_0_AXI_ADDR0 register to 0x18020016, this will set the max region size to 8MBtye and be safe for your desired region size. 

    Your understanding of the field is correct - where the new value of 0x16 defines the max region size of 2^(22+1)=8Mbytes. 

    Sorry this information was missing from the TRM. 

    Let me know if you can verify the 4MB size will work with this new register setting.

    Jian

  • Jian,

    thanks for your response and clarification on the maximum region size. We reconfigured PCIE_CORE_ATU_WRAPPER_OB_0_AXI_ADDR0  to 0x18020016, but still could not access the whole 4MB address space. Interestingly, with this configuration every read or write to the endpoint fails.

    Our endpoint's address space (0x000000 - 0x3FFFFF) has larger unused gaps, e.g. 0x2000 - 0xFFFF is undefined. Could this cause problems for the ATU?

    In our working solution with multiple ATU regions we only define regions for accessible memory.

    Regards,

    Leonhard

  • Jian,

    I was wondering if there is news on this topic?

    Regards,

    Leonhard

  • Unlocking thread.

    Regards,

    Takuma

  • Hi Leonhard,

    Apologies for the long delay. As it has been quite a while, would like to ask if this is still an open issue, and if so, if there has been progress since the last update.

    Regards,

    Takuma 

  • Hi Takuma,

    Thanks for your response. We still use the workaround with multiple ATU regions, however we'd prefer to replicate the whole endpoint's address space in a single ATU region.

    Our endpoint's address space (0x000000 - 0x3FFFFF) has larger unused gaps, e.g. 0x2000 - 0xFFFF is undefined. Could this cause problems for the ATU? In our working solution with multiple ATU regions we only define regions for accessible memory.

    Also, in the TRM it says that unspecified behavior may occur, if a transaction goes past one translated region. Are there any provided features to mitigate this problem?

    Regards,

    Leonhard

  • Hi Leonhard,

    Understood, I will keep this issue open. I apologize for troubling you with internal matters, but I will need some time to gather information from some of my colleagues to get up to speed on this issue. As they have moved to a different role, this may take some time - please expect 2 weeks at the latest for a response, but please feel free to ask on this thread for updates and I will be happy to oblige.

    Thank you for your continued patience.

    Regards,

    Takuma

  • Hi Leonhard,

    Apologies again for the long delay. For this issue, I would recommend reading this documentation's section 3 PCIe Address Translation: https://www.ti.com/lit/an/sprabk8/sprabk8.pdf?ts=1686848714329&ref_url=https%253A%252F%252Fwww.google.com%252F

    PCIe address range is slightly different than the examples in the documentation, but TDA4VM is part of the Keystone family of devices so the information here is applicable. TDA4VM also has a 256MB address range of PCIe space named PCIE0_DAT0 and PCIE1_DAT0, so theoretically you can configure translation region for outbound transaction as 4MB (and even 8MB).

    However, I am also concerned with the EP's unused space where the first few bytes are undefined. My theory is that when we define the region as 4MB on the TDA4VM RC-side, we are trying to access the entire 4MB of the EP device. And similar to TDA4VM device behavior defined in section 3.2 PCIe Inbound Address Translation of the same documentation, the EP device is rejecting packets since we are trying to access areas that are undefined. Except, unlike the diagram in our documentation, the EP device is not the TDA4VM, but your custom EP device.

    My recommendation is to check the EP device's datasheet to see if there is not a similar rule for rejecting addresses that are trying to access certain regions. And based on the EP device, it might not be possible to define a single 4MB region for translation.

    Regards,

    Takuma