1. In the NETC driver, the “MCAL_INSTRUCTION_SYNC_BARRIER()” should NOT be a must. It will decrease the performance and can be removed. Per my understanding, if we do not dynamically change instruction sequence, we do not need to flush the instruction FIFO (isync). Might I'm wrong, please help to double check it.
For example, in Netc_Eth_Ip_SendFrame(), about the code below, speculative will not execute for store instructions, why do we need this barrier?
/* When the development error is enabled we need to add a barrier first in order to avoid speculative exection before the previous else if condition is completed. */
MCAL_INSTRUCTION_SYNC_BARRIER();
MCAL_DATA_SYNC_BARRIER();
2. Some of the “MCAL_DATA_SYNC_BARRIER()” needs to be reviewed. Parts of them seem to be not necessarily (above), parts of them need to be adjust. For example, in Netc_Eth_Ip_SendFrame(), about the code below, the “MCAL_DATA_SYNC_BARRIER()” should be moved to follow-up the cache operation and before the TBPIR register.
/* Writes in memory for BD are optimized and syncronization before starting transmission need to be done to assure that transmission BD is write correctly in memory. */
MCAL_DATA_SYNC_BARRIER();
Hi,
I understand that barrier commands were added before changing global variable to not impact to other. For example: in the function SendFrame with this code:
Without barrier commands, speculative execution will be done before "if" condition fully resolves. If case NextProducerIndex = LastTxdata happened that indicates that queue empty or full but CPU predict wrongly and set the variable LockTxBufferDes = TRUE. After, "if" condition finished, CPU recognized that it wrong so come back but the variable LockTxBufferDes changed. The sequence for this variable is: before transmit LockTxBufferDes = LOCKED, after handling in ReportTransmission, LockTxBufferDes = UNLOCKED. This led to one buffer was ignored to use.
For this command:
This relates to the note in RM:
barrier was added to ensure that TxBD synced to memory before the following command started:
Best regards,
Nhi
Regarding to "variable LockTxBufferDes changed", As I stated in the question, any speculative execution will NOT cause corrupt memory store action, which is not revoked. Please double check about the speculative concept.
Hi,
My answer based on that found as below:
I have no more idea about this, so I created the ticket ARTDCC1-640, you can follow it to get the explanation from SW team.
Best regards,
Nhi
Yes, I found this by a AI tool. It is Cody.
Hi,
I just found it, not official documentation but I think it can be the reason when SW adding this command. I have no idea, maybe my thinking is wrong they have other reasons . SW team will answer in the ticket mentioned above.
Best regards,
Nhi