In S32ZE NETC reference manual, "Document identifier: S32E27NETCRM Reference Manual Rev. 4, 2024-12-12", 3.2.5.3.1 Normal Mode with Drift and Error Adjustment, it claimed "During normal operation, any change to the 1588 timer configuration (for example TMROFF_H/L), except for TMR_ADD updates, requires that TSN related functionality such time gate scheduling, time specific departure scheduling, stream gating and rate policing, be disabled." But neither the gPTP software, nor the NETC device driver does meet this specification.
We have a gPTP software module from NXP, is it correct?
It will call the function "EthSwt_43_NETC_CorrectPtpClk" to update current time.
I'm not talking about the "provide functions about correcting timer".
My question is, while the gPTP is calling EthSwt_43_NETC_CorrectPtpClk() function to update current time, how to make the 802.1Qbv feature NOT be impacted?
Hi @shuangjunzhu ,
ETH driver RTD2.0.1 follows ASR 21-11 that just includes some api functions for timestamp such as:
For this reason, I think that they didn't provide functions about correcting timer as you said. Seems functions about correcting timer will be supported in ASR23-11 or gPTP have to make the request with changing the requirement if they need to use them in ASR21-11.
Best regards,
Nhi
Thanks for your attention. As you stated "driver just supported to get current timer from TMR registers until now, not supports to configurate them", I do not understand. How about gPTP software to change the OFFSET register? I do think the gPTP software definitely needs to change the OFFSET register. My question is, how to follow-up the RM, while the gPTP software is trying to change OFFSET register, to keep the TSN features, for example, the 802.1Qbv function working smoothly?
Hi @shuangjunzhu ,
I'll answer this topic for NETC driver.
- The latest release was launched for ZE is RTD 2.0.1 that follows RM rev 3 and as far as I know, the next release RTD 2.0.2, still follows RM Rev 3. But if there is any update about RM version, SW team has a ticket to check change between new and old RM. I think that they can detect the change.
- As far as I know, timestamp was supported in driver until now are default count TMR_CTRL[TE] = 0 and the feature EthEnableFreeRunningTimer just added to RTD 2.0.1 that works in 1588 timer TMR_CTRL[TE] = 1. Current timer will be gotten from 1588 registers TMR_FRT_L/H, but seem that there is an bug here because I didn't anywhere set TE (the ticket: ARTDCC1-593 for detail). Anyway, driver just supported to get current timer from TMR registers until now, not supports to configurate them. The claim that you said seem just happen if user want to change 1588 register configuration.
Best regards,
Nhi
Hi @shuangjunzhu ,
You means want to stop TSN functionalities before changing 1588 list of registers, right?
Current driver, I saw driver doesn't support the function to stop TSN. If you want to disable each features in TSN, seem you need to delete entries in each table. For example:
- Rate policy: Netc_EthSwt_Ip_DeleteRatePolicerTableEntry();
- Netc_EthSwt_Ip_DeleteStreamGateControlListTableEntry();
- EthSwt_43_NETC_StopTas();
Best regards,
Nhi
Hi @shuangjunzhu ,
From my point of view, the problem is not only how many TSN features are enabled, because if the customer uses ASR context, these features enabled/disabled in precompile by macros but also are in each feature. As you know, each feature Rate policing, stream gate,... controlled through table as below:
If user just configured elements in the configuration tool, then SW team can control how many entries with entry ID to delete them when disabling this feature. But in case, user adds elements by calling function, then SW has no way to know. But I think user can control this from their application. Maybe I missed something, but I understand TSN will refer to timer values, so it is make sense to stop them before changing timer configuration and start again to get new timer values. I believe that SW team can has deep insight when they analyzing that ticket.
Best regards,
Nhi
Hi @shuangjunzhu ,
If you don't have any idea about ETH driver anymore, please remove RTD from this topic so that someone is from gPTP can answer you.
Best regards,
Nhi
Hi,
Thanks for your great help.
Please have me highlight one very import thing for AUTO customers, while they are using TSN IEEE802.1Qbv feature, of course, they need to enable gPTP as well per 802.1Qbv time sync requirement.
They are concerning about whether the gPTP will impact the critical traffic which is in one 802.1 Qbv slot. We (NXP) need to clarify it and provide how to do it. This is a very dedicate and clear requirement. And it's a good example or use case for you to understand the situation.
Yes, for sure, we do not know how many TSN features customer are enabling. But for everyone of possible using, we need a solution. Customer could make right selection based on their use cases.
Thanks,
Jeff
Hi,
Yes, I still have a question. Please help to check how to dis-able/re-enable 802.1Qbv from Ethernet driver point of view. And please help analyze whether this kind of action will cause the critical traffic delay one of 802.1Qbv schedule cycle?
Thanks,
Jeff
Hi,
It's NOT me want to disable the TSN feature before gPTP changed timer offset register. It's the requirement of NETC RM.
Customer is asking for official solution to meet the RM specification from NXP: how to disable TSN features, i.e. IEEE802.1Qbv under this situation. Customer assume it should be provided by NXP, because it's hardware requirements and hardware related coding.
By the way, I'm thinking your suggestion need to be well designed. Especially for 802.1Qbv, how to make the application traffic NOT impact by the gPTP sync action. For example, is it possible that some traffic might be delay one Qbv schedule cycle?
Thanks,
Jeff
Hi @shuangjunzhu ,
From my point of view, it is difficult to meet this requirement from ETH driver with the official function that stop TSN . As you can see, to disable the Port Gate time schedule , just need to reset the bit Time Gate enable PTGSCR[TGE]. But for some TSN features, such as Rate Policy, this feature was enabled/disabled based on elements in this table. But from ETH, we can't know entries were added to this table to delete or update elements to disable them, upper layer can handle this better. For this reason, I suggested to call functions that delete entries in each table as my previous reply.
In case, user didn't enable option features: rate Policing, stream gate control list,... they can disable TSN with the function EthSwt_43_NETC_StopTas() .
Anyway, I created the ticket ARTDCC1-607, you can follows it to get the analysis from SW team in case I missed something. And RM Rev4 hasn't applied to RTD release yet. If you don't have more idea about ETH for this topic, please let me know, I'll free this case to gPTP can continue answer you from their side.
Best regards,
Nhi
Hi @shuangjunzhu ,
I saw the feature 802.1 Qbv supports both NETC and Switch. So, you can configure this feature through:
- Eth_NETC:
- Port switch:
The functions are:
For ETH_NETC:
- Eth_43_NETC_StartTas()
- Eth_43_NETC_StopTas()
For Port switch:
- EthSwt_43_NETC_StartTas()
- EthSwt_43_NETC_StopTas()
For this question: "analyze whether this kind of action will cause the critical traffic delay one of 802.1Qbv schedule cycle", from my point of view, as you can look at the function Netc/PortSwt_Ip_ConfigPortTimeGateScheduling() that enable/disable this feature, to disable this feature, just need to reset one bit but enable this feature, need to enable Gate Time and set up Gate Time table. This time can measure.
I understand that you means about "one of 802.1Qbv schedule cycle" is the execution time of the Gate control list should be repeated, right? If it is, this can be configured.
Best regards,
Nhi
Hi,
It looks like you still do not catch up my question. Please let me have a more detail description. Assume customer has a Qbv configuration and it's in running status with the parameter as below:
1. the cycle time is 10ms
2. in one 10ms time period, there are two slots, 5ms individually. In other words, there are two entries in the gate list.
3. Assume while the first time slot is open, NETC is transmitting the critical frames. At this time the gPTP start to update current time, per RM requirement, customer needs to disable/re-enable 802.1Qbv.
4. After the 802.1Qbv is re-enabled, It's possible that the NETC hardware might continue to open time slot 1, or go to gate list 2nd entry, or wait for new Qbc schedule cycle. If the hardware go to 2nd entry, it means the critical frames in NETC queue will be transmit in next 10-ms cycle. And it might cause big delay and impact applications.
5. Customer is asking how to avoid this kind of situation. In other words, how to smoothly disable/re-enable Qbv to reduce the impact to the applications.
Hope it will make thing clear.
Thanks,
Hi,
I didn't see another way to enable/disable TAS except 2 functions that I mentioned in the previous reply. From my point of view, when disable time gate control, all of features of this also disabled, time interval, cycle,... Duration between disable and enable TAS, includes time to finish updating timer from gPTP. When enable TAS, base time will be updated with current time. Except new base time = next old interval time, if not can't see your requirement.
I have no more idea about this, I also updated this question in above ticket so that SW team can have suggestion for your case.
Best regards,
Nhi