• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 1158 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS3137: Lockstep verification and intended behavior of the CPUs

_MM_
Expert 1995 points
Part Number: TMS570LS3137

Hello,

I have a couple of questions about the behavior of the described dual core architecture:

1) According to the TRM by the CCM self test, the match test, the mismatch test and the error forcing mode check the correct comparison of the signal from the 2 CPUs by pre-defined sequences. Can I verify by my own the correct working of the CCM by introducing (by code or by debugging) different output values to both the CPUs and looking at the status of the CCM? If yes, could you explain me please how ?

2) When the debug is executed, only the registers (e.g. R0-R15) are displayed like only a CPU is there. Is there some mechanism to avoid the user to "hack" the MCU respect to the safety intended behavior (e.g. for parallel calculation or clustering) ?

Thanks ahead for any reply.

Regards,

-Marco

  • 0
    TI__Mastermind 49120 points
    Hi Marco,

    I have added my comments after >>.

    1) According to the TRM by the CCM self test, the match test, the mismatch test and the error forcing mode check the correct comparison of the signal from the 2 CPUs by pre-defined sequences. Can I verify by my own the correct working of the CCM by introducing (by code or by debugging) different output values to both the CPUs and looking at the status of the CCM? If yes, could you explain me please how ?

    >> It is sufficient to test the following aspects in the defined sequence:
    a) Check that a diagnostic feature's failure indication mechanism is working correctly. This is done via the CCM Self-Test Error Forcing mode.
    b) Run a self-test on the diagnostic feature's logic. This is done via the CCM Self-Test mode.
    c) Check that a mis-compare is actually signaled by the CCM. This is done via the CCM Error Forcing mode.

    Once all the above checks are passed, only then you can actually use the CCM to compare CPU outputs correctly. There is no other way to intentionally disturb / corrupt the CPU outputs to the CCM. It is possible that the two CPU's registers do not power up to the same value, in which case any operation that would cause the CPU to output a register value to memory could cause a real CCM compare error. However, this may not always work as the CPU registers could indeed power up to the same values.

    2) When the debug is executed, only the registers (e.g. R0-R15) are displayed like only a CPU is there. Is there some mechanism to avoid the user to "hack" the MCU respect to the safety intended behavior (e.g. for parallel calculation or clustering) ?

    >> I do not understand the question. Can you please clarify?

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Expert 1995 points

    Hello Sunil,

    Thanks for your reply.

    About 1) : 

    Is there a way to get some evidence from that sequence you defined a)-b)-c)? My goal would be showing what is going on the self-tests described in the TRM. For example: how can I monitor during the CCM Self-Test Error Forcing Mode that actually 0x5 is applied to the CCM input coming from CPU1 while 0xA is applied to the CCM input related to CPU2 ? how can I monitor the patterns provided during both the tests of self-test mode (mismatch and match) ?

    About 2):

    Sure! The MCU has 2 CPUs. This rises up some doubt:

    - During debug, I can watch just one single set of core registers; properly R0-R14, PC, SP, LR and CPSR. Where are the respective core registers of the second core?

    - In spite of the dual-core architecture, it is well known the two CPUs are periodically compared by the CCM in order to check they are performing the same processing (as safety feature). So, at the end it is like having one single core since the other one plays the role of checker. But, how to ensure this dual core architecture cannot be used for different purposes (e.g. the state-of-the-art multi-processing techniques to increase the processing performance such as parallel computing) ? I am asking because in the certification context having a multi-core architecture impacts strongly with the needed assessments; so maybe arguing there is not possibility to use the dual-core in another way can mitigate.

    I hope this time I have been clearer, otherwise please let me know. Looking forward your reply and thanks ahead.

    -Marco

     

  • 0 in reply to _MM_
    TI__Mastermind 49120 points
    Hi Marco,

    Thanks for the clarifications. I have added my answers embedded below, after >>:

    About 1) :

    Is there a way to get some evidence from that sequence you defined a)-b)-c)? My goal would be showing what is going on the self-tests described in the TRM. For example: how can I monitor during the CCM Self-Test Error Forcing Mode that actually 0x5 is applied to the CCM input coming from CPU1 while 0xA is applied to the CCM input related to CPU2 ? how can I monitor the patterns provided during both the tests of self-test mode (mismatch and match) ?

    >> There is no deeper granularity to "observe" the inputs to the compare logic. Also, the patterns for the "compare match" and "compare mismatch" tests are internally generated, so there is no way to observe these patterns either.

    About 2):

    Sure! The MCU has 2 CPUs. This rises up some doubt:

    - During debug, I can watch just one single set of core registers; properly R0-R14, PC, SP, LR and CPSR. Where are the respective core registers of the second core?

    >> Only one CPU's outputs are visible on the interconnect, so you can read registers from only one CPU.

    - In spite of the dual-core architecture, it is well known the two CPUs are periodically compared by the CCM in order to check they are performing the same processing (as safety feature). So, at the end it is like having one single core since the other one plays the role of checker. But, how to ensure this dual core architecture cannot be used for different purposes (e.g. the state-of-the-art multi-processing techniques to increase the processing performance such as parallel computing) ? I am asking because in the certification context having a multi-core architecture impacts strongly with the needed assessments; so maybe arguing there is not possibility to use the dual-core in another way can mitigate.

    >> The ability to split the two cores so that each can operate independently is not supported on the Cortex-R4 CPU. This ability is supported on the Cortex-R5 CPU, but is not supported on Hercules MCUs with the Cortex-R5 CPU (TMS570LC/RM57).

    Regards,
    Sunil
  • 0 in reply to Sunil Oak
    Expert 1995 points

    Hi Marco,

    Thanks for the answers.

    Sunil Oak said:

    >> The ability to split the two cores so that each can operate independently is not supported on the Cortex-R4 CPU. This ability is supported on the Cortex-R5 CPU, but is not supported on Hercules MCUs with the Cortex-R5 CPU (TMS570LC/RM57).

    Regards,
    Sunil

    I am trying to catch it through the Architecture reference manual and the TRM of the ARM Cortex-R4, but unsuccessfully. Do you know where this feature is described ? Thanks.

    Regards,

    -Marco

  • 0 in reply to _MM_
    TI__Mastermind 49120 points
    Marco,

    This feature is not supported on the Cortex-R4 CPU, so you will not find information about it in the R4 TRM. You can search for something like "split/lock" on the Cortex-R5 TRM.

    Regards,
    Sunil