SJA1110 Qbv AdminBaseTime Configuration

[GuilhermeS32G]

Dear NXP members,

I have been working on the configuration of the SJA1110 switch on the S32G-VNP-RDB3 board for enabling the TSN features such as PTP and Qbv.

I am using the SJA1110 SDK for S32 Design Studio to configure the switch, generate an updated sja1110_uc.bin file, and deploying it on the S32G board.

Although I have been able to understand and test the configuration of most Qbv parameters, I was not able to grasp the correct configuration of the ADMINBASETIME[31:0] and ADMINBASETIME[63:32] on the QBV Administrative Parameters table.

According to the documentation in the document um549820-UM11107 Software User Manual for SJA1110(2.0), ADMINBASETIME is explained as:

Defines the administrative value used for the base time, expressed in PTP/free
running timescale, used for reference when calculating the moment in time when
the reconfigured gate cycle begins (CycleStartTime) .

But it does not provide any clue about how to calculate this value in a real project. Besides, the SJA1110 Qbv example on the SJA1110 Extended Configuration presentation uses 0 (start directly for this parameter).

Let's imagine one example.

Qbv is configured for the port 3 of the SJA1110 switch, which has a speed of 1000Mbps, and a granularity of 200 ns.

One cycle has 500 μs and three segments:

• In the first segment, all Traffic Classes are open, except TC7. It lasts for 100 μs (TRIGGER_TIME = 500);
• In the second segment, only Traffic Class 7 is open, the other TCs are closed. It lasts for 300 μs (TRIGGER_TIME = 1500);
• In the third segment, all Traffic Classes are open, except TC7. It lasts for 100 μs (TRIGGER_TIME = 500).

But in the same network there are another TSN switches configured with a Qbv cycle of 500 μs, but different segment intervals.

How do I calculate ADMINBASETIME in order to synchronize between TSN switches and make sure it aligns with the gPTP time epoch?

Thank you very much for your support!

[PavelL]

Hello @GuilhermeS32G ,

ADMINBASETIME should be understood as the absolute time reference/phase reference for the Qbv schedule. It is used to align the start of the repeating Qbv cycle to the synchronized time domain. It is not calculated from the port speed and it is not based on the TRIGGER_TIME granularity.

In a multi-switch TSN system, gPTP / IEEE 802.1AS provides the common synchronized time base, but it does not automatically configure the Qbv schedule. The Qbv configuration, including ADMINBASETIME, must be programmed by a TSN management stack/CNC or by application-specific/custom software running on the host processor. IEEE 802.1Qcc describes centralized TSN configuration models where a CNC computes and distributes TSN configuration to the network devices. 

https://www.ieee802.org/1/files/public/docs2017/cc-Kehrer-StartOfCycleReference-0117-v01.pdf

A typical procedure might look like:

1. Start gPTP / 802.1AS and wait until all relevant TSN devices are synchronized.

2. Read the current synchronized time from the device/PTP time domain.

3. Choose a future base time: ADMINBASETIME = current_gPTP_time + safety_margin

The safety margin should be large enough to allow the configuration to be written to all switches/ports before the selected base time is reached.

4. Program the same ADMINBASETIME and the same cycle time on all switches/ports that must share the same Qbv cycle phase.

5. Program the per-port GCL entries according to the required schedule.

If alignment to the gPTP time epoch is required, the selected base time can also be aligned to the cycle boundary, e.g.:

ADMINBASETIME = ceil((current_gPTP_time + safety_margin) / cycle_time) * cycle_time

This is the same general idea used by Linux taprio: base-time defines when the schedule starts; if the base time is already in the past, the active start time is derived by adding an integer number of cycle times until the resulting start time is in the future.

https://www.cisco.com/c/en/us/td/docs/switches/lan/cisco_ie4000/tsn/b_tsn_ios_support/b_tsn_ios_supp...

https://deepwiki.com/nxp-qoriq/tsntool/5.2-device-configuration

For SJA1110, the final ADMINBASETIME value must be encoded according to the time format expected by the SJA1110 Qbv configuration, and then split into:

ADMINBASETIME[31:0] = lower 32 bits

ADMINBASETIME[63:32] = upper 32 bits

So, in summary: gPTP provides the common time; another software/configuration layer must choose and program the Qbv ADMINBASETIME relative to that time. This may be done by a TSN management stack/CNC or by custom application code in a simpler embedded system.

Best regards,

Pavel

[GuilhermeS32G]

Hello @PavelL ,

Thanks for your support once again.

So, from my understanding, this ADMINBASETIME configuration ideally should be set programmatically during runtime so to ensure that the Qbv schedule is in the future.

In my case, as the SJA1110 switch is booting in SDL Boot, I am using the SJA1110 SDK for S32DS for programming its firmware. In this case, I would have to set the ADMINBASETIME in the QBV Administrative Parameters table; then build the new firmware file; deploy it into the S32G-VNP-RDB3 board; reboot the board so that the new configuration takes effect.

The first time the ADMINBASETIME would be in the future, but then if I don't update the firmware in the subsequent runs, it would always have to adjust the active start time, as you have mentioned.

In this case, wouldn't be better to simply set the ADMINBASETIME to 0? Otherwise, it would be better to reset the gPTP time during every start-up.

Best regards,

Guilherme

[PavelL]

Hello @GuilhermeS32G ,

Yes, ADMINBASETIME configuration ideally should be set programmatically during runtime to ensure that the Qbv on all switches is synchronized. 

I would suggest to build the SJA1110 static configuration with ADMINBASETIME = 0.

ADMINBASETIME should be programmed dynamically at runtime after gPTP synchronization is established. In that case, a host application, TSN management stack, CNC or other custom configuration software would read the current synchronized time, select a future base time with sufficient margin, write the Qbv administrative parameters (via dynamic reconfiguration) and trigger the configuration change.

I would not recommend resetting the gPTP time at each startup only to make a fixed ADMINBASETIME valid.

Best regards,

Pavel