AM6421: memory access priority handling

Hi Anil,

Swargam Anil said:

Can you please confirm what the use case is here?

The customer simply prioritize some software(thread).
Suppose the software is running on R5_0 core, R5_0 core access to resources should be higher priority.
If the software uses DMA ch-0(for example), the ch-0 should be higher priority.

Thanks and regards,
Koichiro Tashiro

Hello Koichiro ,

As per our internal discussion, I should get more details on the below topics.

1. Should we configure priority, or which core has more priority access to MSRAM shared memory among the 4 R5F cores?

2. Similarly for DDR memory

3. Similarly for DMA access.

Regards,

S.Anil.

Hi Anil,

Swargam Anil said:

1. Should we configure priority, or which core has more priority access to MSRAM shared memory among the 4 R5F cores?

The initiator is not limited to R5F cores. All other initiators (A53, DMA, etc.) are considered.
Suppose R5F_0, R5F_1, DMA ch0, ch1 and A53_0 are sharing MSRAM, is it possible to configure access priority among them?
This is what the customer is asking.

Same for DDR.

Thanks and regards,
Koichiro Tashiro

Hello Koichiro,

Thanks for clarifying the above query. We will get more details from the Design Team since we can't get this information from TRM.

Regards,

S.Anil.

Tashiro-san,

Please share the attached PowerPoint slide with customer, as discussed last night. They can configure on-chip SRAM banks for the required memory size per core and have a dedicated path from the core to the OCM bank w/o having a contention with other initiators. This implementation is a unique and differentiated feature with AM64x and could be an advantage for applications like PLC that require deterministic and low-latency data processing. I'm following up on the DDR feature with the team and getting back to you.

 AM64x Low Latency Memory architecture.pptx

Regards,

Kazunobu Shin

Regarding DDR the tool available is class of service (CoS). It can be used to give relative priority to an initiator in case of congestion. But it is not a guaranteebut one variable in the DDR acccess management. See this in the TRM https://www.ti.com/lit/pdf/spruim2 :

8.1.4.9.2.1 Placement Logic

The placement logic is a 2-stage queue which determines the order of commands that run in the DDR controller.

The placement logic follows rules for determining placement of new commands into the queue, relative to the

contents of the command queue at that time. Placement is determined by considering coherency, address

collisions, source collisions, data collisions, user assigned priority, latency, age, and command type to offer low

latency for critical controllers while optimizing bandwidth for all controllers. A second reordering stage allows

ready-to-run commands to start even if the head-of-queue command is not yet ready to run. In addition, the

queue can be disabled completely, resulting in an in-line queue that services requests in the order that they

arrive.

The DDR controller also has a full look-ahead facility that reduces the effect of page misses by pre-conditioning

rows for upcoming requests by using “spare” cycles in preceding transactions.

Hi Shin-san, Pekka,

Thanks for your inputs. Regarding DDR, I understood DDR controller uses CoS for priority handling.
According to TRM section 8.1.4.1, CoS is based on "VBUSM priority".
I checked what is VBUSM priority and how to set it, but there seems no description about it.


Could you point me where I can find the information?

Thanks and regards,
Koichiro Tashiro

Koichiro Tashiro said:

TRM section 8.1.4.1, CoS is based on "VBUSM priority".
I checked what is VBUSM priority and how to set it, but there seems no description about it.

Sorry about that I agree the terminology is not clear in the TRM. VBUS priority is the EPRIORITY field you can find in section 3.4 System Interconnect Registers of the TRM. Note this priority is only relevant at the interconnect endpoint, when two commands from two different initiators are available at the same time. This will usually mean at most couple clock cycles at the interconnect speed, so maybe 10ns or so.

DDR CoS is a hint type QoS value used by the DDR controller to reorder or pick the next command to use on the DDR bus. CoS is not a hard guarantee, for example DDR refresh that must be served can create jitter in the range of 1 microsecond.

The customer has a few more questions for priority.
Q1) User can set priority for each initiators listed in TRM Table 3-7 "CBASS0 Initiator Module Attriutes", correct?
Q2) Table 3-7 does not seem to include Cortex-A cores. How priority between A cores and R cores are handled by EPRIORITY?

Thanks and regards,
Koichiro Tashiro