Hi,
In FCCU of MPC5744P，four RCCU errors has been listed, including NCF[11]RCCU_0a, NCF[12]RCCU_0b, NCF[13]RCCU_1 and NCF[69]RCCU_2. I have some questions:
1. How to distinguish the differences among them? Especially the RCCU_0b and RCCU_2, they are both related to D-MEM.
2. in the description of NCF[69] , Redundancy mismatch: DSMC D-MEM out of lockstep ,as shown in following figure, the checker core has access to D-MEM memory array? While in Safety Manual of MPS5744P, it said "The Checker Core does not have a direct connection to the XBAR. All of the outputs of Checker Core_0 that target the XBAR (as well as any other non-duplicated resource, like local memories) ."
Hi Alice,
1. How to distinguish the differences among them? Especially the RCCU_0b and RCCU_2, they are both related to D-MEM.
This is quite obvious from the description in my AN5259
RCCU2 - DSMC (Decorated Storage Memory Controller) D-MEM out of lockstep
RCCU_0b - D-MEM array interface out of lockstep
2. in the description of NCF[69] , Redundancy mismatch: DSMC D-MEM out of lockstep ,as shown in following figure, the checker core has access to D-MEM memory array?
As you can see there is only one DMEM array. In order to save place on chip layout. But the access path must be replicated (higher ASIL classes requirements) , therefore there are 2 separate DMEM controllers. Each for one core.
While in Safety Manual of MPS5744P, it said "The Checker Core does not have a direct connection to the XBAR. All of the outputs of Checker Core_0 that target the XBAR (as well as any other non-duplicated resource, like local memories) ."
Yes, checker core has no direct connection to XBAR.
As you can see from block diagram there is no master assigned for checker core:
There is no need for it as checker core execute its operation in delayed lockstep separately and if any inconsistency is found system is notified via RCCUs.
Hope this clarify your doubts.
Cheers,
Peter
Hi Peter,
Thanks for your reply. But I still have some puzzles.
As you said, there are 2 separate DMEM controllers and replicated access path.
Does you mean the Checker Core has write/read access to D-MEM?
While in the description of Safety Manual:
“The Checker Core does not have a direct connection to the XBAR. All of the outputs of Checker Core_0 that target the XBAR (as well as any other non-duplicated resource, like local memories) will end in an RCCU for verification, and all the inputs to Checker Core_0 from the XBAR will be split off from the Main Core_0 XBAR inputs.”
It seems like that the outputs of Checker Core will not connect to any non-duplicated resource (e.g. D-MEM, Cache，XBAR). The outputs from Checker Core are connected to RCCU only and be compared with outputs from Master Core.
Similarly, any input signals from non-duplicated resource, like instruction or data from XBAR or D-MEM, Cache, will not be connected to Checker Core directly. In contrary, input signals are connected to Master core only and these signals are registered. After delaying 2 clocks, these input signals are fed to the Checker Core.
In summary, I am guessing that the Checker Core has no write/read access to any non-duplicated resource.
Please correct me if I was wrong. I need your help.
Furthermore, I didn’t find any RCCU registers. There is no RCCU register to flag the mismatch errors?
Waiting for your reply.
Sincerely,
Alice
