TDA4VH-Q1: PCIe Traffic Class setting

Hi Takuma

Thanks for your answer.

I tried to understand the QoS mechanism.

PCIE ingress:

A PCIe transaction with TCis transformed in a CBass PCIe master transaction with channel id selected according to the PCIe TC and the “TC to channid” register

The QoS characteristics of a channel are programmed in the CBASS_HC2_QOS_Ipcie_g3x4_128_main_0_pcie_mst_rd_map register.

Is this correct ?

PCIE egress:

It is written: “The VC mapping is done using the AXI outbound descriptor registers in the PCIe controller.”

I don’t understand what is meant.  I didn’t find the corresponding register.

There are no TC indication ?

Thanks for your explanations

JPH

Hi JPH,

To quote the TRM:

"""

The Virtual Channel/Transfer Class (VC/TC) feature in the PCIe core, in conjunction with the device system
CBASS Quality-of-Service (QOS) capabilities, provide a mechanism for supporting differentiated QOS within
the PCIe subsystem. The policy for traffic differentiation is determined by the Transfer Class (TC) and Virtual
Channel (VC) mapping and VC-based arbitration mechanism.

A Virtual Channel is established when one or more TCs are associated with a physical resource designated
by a VC ID. Every Traffic Class that is supported on a given path within the subsystem must be mapped to
one of the enabled Virtual Channels. Every Port must support the default TC0/VC0 pair – this is “hardwired.”
Any additional TC mapping or additional VC resource enablement is optional. The number of VC resources
provisioned within a component or enabled within a given subsystem may vary due to implementation and usage
model requirements.

The PCIe core in the PCIe subsystem is configured to support four virtual channels (4VC/4TC). For both ingress
and egress traffic, VC3, the highest numbered virtual channel, has the highest priority.
For ingress traffic, the TC information from each transaction on the AXI master information is mapped to the
CCHANID signal of the VBUSM master interface. The system level interconnect can use the CCHANID along
with the ORDERID for QoS purposes. Table 12-187 shows the TC mapping to the 12-bit CCHANID of each
VBUSM master interface.

"""

PCIe registers are in the J784S4_Registers_Public_20250116.xlsx excel sheet zipped with the TRM in the PCIe section.

Regards,

takuma

Hi Takuma,

Thanks for the answer.

As you said, your answer is a quotation from the document.

I had already thoroughly read the TRM as well as the Excel file containing the details of the registers: the information I found allowed me to guess how the inbound QoS works (which is what I was asking for confirmation on).

But regarding the outbound QoS, I need further explanations to understand how it works. In particular: which parameters do I have to tune to get a virtual channel associated to a PCIe outbound message? Which registers are impacted?There are only 2 general sentences about outbound QoS in the TRM.

Thank you in advance for any explanations you can provide.

JPH

Hi JPH,

Virtual channel configuration is part of the standard but optional PCIe configuration space registers. In general, the 0x029xxxxx registers are the PCIe controller device's register while the 0x0Dxxxxxx registers are the PCIe configuration space registers. 

So in register excel sheet, they will be the registers with "VC"

Within Linux, this translates into the Virtual Channel capabilities register that can be obtained with "lspci -vvv"

        Capabilities: [4c0 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
                VC1:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=1 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
                VC2:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=2 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-
                VC3:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable- ID=3 ArbSelect=Fixed TC/VC=00
                        Status: NegoPending- InProgress-

Regards,

Takuma

Hi JPH,

So far, I have only seen VC0/TC0 be used. I do not have any examples for Jacinto SoC acting as RC and accessing an endpoint via different VC/TC pairs.

Is there a particular endpoint device you have in mind for enabling more VC/TC?

Regards,

Takuma

Hi Takuma,

Our use case is a PCIe network with several TDA4VH, where each endpoints can access to the other, with transactions of different priorities (i.e. different TC/VC). 

"Even if you don't have a code example, could you point out which registers need to be programmed? I am in the design phase and would like to make sure that this functionality is possible."

Thanks for your help,

JPH

Hi JPH,

JPH-FR said:

It is written: “The VC mapping is done using the AXI outbound descriptor registers in the PCIe controller.”

I don’t understand what is meant.  I didn’t find the corresponding register.

Most likely the Ext_desc register.

Regards,

Takuma

Hi Takuma,

Thank you for your response, which helps me advance in my understanding.

In paragraph "12.2.3.3.7.2 PCIe Outbound Address Translation bypass" of the TDA4VH TRM, there is a mechanism that allows to override the TC value.

I have the impression that generating a transaction with a particular TC is only possible from a DMA and not from the CPU (casel must be not null). Is this correct?

Moreover, this mechanism is in the case the outbound translation is bypassed. I understand that bypassing the outbound address translation is a condition to be able to set the TC. Is it true ?

Thanks in advance for the response.

JPH

Hi JPH,

JPH-FR said:

I have the impression that generating a transaction with a particular TC is only possible from a DMA and not from the CPU (casel must be not null). Is this correct?

That is my understanding as well. Only UDMA can generate transactions with non-zero ASEL value.

For the ASEL question, I would recommend reading this thread about cache coherency. Although the main focus is coherency, it talks about how ASEL is set:  RE: AM67: bus snooping for cache coherency 

To quote some portions: 

"

From a low level point of view it looks like there the PCI has a VBUSM-R and VBUSM-W port and each has 8 channels.  Each channel will have an ASEL[...]

Here are the QOS register blocks and per-channel addresses which allow setting of the ASEL.

"

As for bypassing address translation, historically, this feature has been unsupported in our SDK:  SK-AM68: VMAP in bypass mode 

Regards,

Takuma

Hi Takuma,

Thanks for your last response.

I now need time to examine the registers and perfect my understanding.

My last question of this thread is relative to your answer concerning VC configuration, in which you gave a lspci -vvv screenshot.

There are several VC registers to configure during the network discovery done by the root complex.

Is there an example of Linux configuration parameters taking in charge the VC ?

Thanks again

JPH