Hello Safety Experts,  Device: S32G398 TTTech auto has observed NCF[87] in their Safety Application. As part of Analysis, safety architect from TTTech has given below justification about disabling NCF[87] and requires clarification if the justification is acceptable as per NXP safety standards. Please provide your inputs for Q1 and Q2 below. Here is the overview and analysis from TTTech safety team:  NCF[87]: This is related to topic Network-on-Chip (NoC). Following is the description of NCF[87] Following is the high level diagram of NoC: From the above block diagram, it is clear that,  Accelerator Interconnect NoC is interfaced with System Interconnect NoC. Q1: As per our knowledge , Accelerator Interconnect NoC is only used for the communication over PCIE, PFE and USB and it’s not used for any other communication. We would like to understand from NXP whether the above statement highlighted in bold is correct. Justification for disabling this NCF in FCCU config: From the below table we can see that Accelerator Interconnect NoC is having diagnostic coverage as Medium. And with reference to the NXP assumption(snippet added below), we should have E2E protected communication to claim the functionality as safety relevant. This means , if Accelerator Interconnect NoC is only used for communication over PFE then we can claim the communication as safety relevant based on E2E protection. Question related to safety impact: Q2: When considering the below mentioned safety mechanism(Refer snippet below) with respect to NOC, we would like to understand the safety impact of disabling NCF[87] on the coverage of SM1.NOC.PKT_PROT. Also we would like to understand whether the below mentioned mechanism is only for  “Accelerator NOC” or its for the entire NoC which includes “System Interconnect, Memory Interconnect, Peripheral Interconnect, Debug Interconnect, Accelerator Interconnect”   S32G3  Regards Krishna ...查看更多

Hi Safety team, We have a major mm customer using the S32K341/311, and have asked additional Safety Manual questions.  They are developing both ASIL B and ASIL D applications: Q1:  For AOU_GEN_FOLLOW_ARM_M7_DOC, can you confirm the text "this chip's Safety Manual" is referring to the Arm Cortex-M7 Safety Manual or the safety manual of the S32K3xx? Q2:  What is comm safe prot (like in SM4.COMM_SAFEPROT)?  Customer cannot find information about this. Q3: Is it possible to clarify which SMs and AoU are exclusive to ASIL D, and which are also necessary for ASIL B? Q4:  The  documentation for SM2 shows that SAF mechanisms are relevant for variant S32K311, which is ASIL B. Why is SAF needed for this chip if SAF is targeting ASIL D only? Q5:  The documentation for SM2 shows that SAF mechanisms bring DC of associated failure modes to 90%. What happens if these SAF mechanisms, DC goes down to 60% (acceptable for ASIL B) or 0% (which would be a gap for ASIL B)?   Thanks! ...查看更多

s32g2.   In the S32G2 Reference Manual, Rev. 8, February 2024, there are two notes regarding speculative access:   36.1.5 Speculative access to DDR memory Before you initialize DDR, speculative access to DDR memory can generate a fault or lead to unexpected behavior. Therefore, you must program the core to disable speculative access to this region.See https://www.developer.arm.com/documentation/ ddi0489/f/memory-system/speculative-accesses for details.   38.1.4 QuadSPI limitations Any speculative access of the QuadSPI memory mapped region 00000000h-20000000h before you configure QuadSPI might result in unexpected chip behavior. Therefore, in this situation, you must use core programming to disable speculative access of that region.    Per the Cortex M7 TRM r1p2, 5.2 Speculative Accesses, the MPU is used to implement these restrictions. The MPU can be enabled early after a core is turned on, but there will always be some number of instructions that run before this happens.    It appears there would still be a gap before the MPU is enabled in which these problematic speculative accesses could occur. Is that true, and if so, what is the safety implication of these potential speculative accesses?   -Randy Krakora   ...查看更多

We have a large mass market customer using S32K341 and have the following questions regarding SM1.FLASH.AI_SELFCHECK: What are the differences between SM1.FLASH.AI_SELFCHECK and the other SM1 FLASH self-test mechanisms> For AOU_SW_ARRAY_INTEGRITY_CHECK, is flash array integrity selfcheck referring only to SM1.FLASH.AI_SELFCHECK, or are there other mechanisms this refers to? Thanks in advance. ...查看更多

Hi Safety team, One of my client using S32K322, They want to meet the ASIL-B Addendum_S32K3xx.xlsx excel sheet attached in the SM. I did not found any specific section for SM related to ASIL-B & ASIL-D   Client asking which SM needed to implemented for ASIL-B ..? https://community.nxp.com/t5/SafeAssure-Community/S32K3xx-SM4-SAF-and-ASIL-B-vs-ASIL-D-mechanisms/m-p/2162283#M1678 As per this ticket :-- Our SM is designed as per --> Highest ASIL-D But K3 we have parts for --> both ASIL-B & ASIL-D Client saying they will implement those SM which --> will help to meet ---> ASIL-B Please suggest which SM from Addendum_S32K3xx.xlsx excel sheet, is specific for ASIL-B for S32K322 ? Regards, Dinesh ...查看更多