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.

TMS570LC4357 "error trapping" in L2 memory interconnect subsystem (Safety Manual)

Other Parts Discussed in Thread: TMS570LC4357

Hello forum team,

I have a few questions regarding section 5.11.1 of the TMS570LC4357 safety manual (SPNU540):

"5.11.1 Error Trapping

The L2 memory interconnect subsystem includes a number of mechanisms to detect and trap errors.

Address decoders in the diagnostic respond with a bus error to the initiator if a bus transaction does not

decode to a valid target. Logic is also present that can detect the timeout of certain transactions and

respond with a bus error to the transaction initiator.

The interconnect error trapping functionality is enabled by default and cannot be disabled by the software.

Use of this safety mechanism is mandatory. These features can be tested via software through the

insertion of invalid bus transactions.

"

We consider if we should implement the test mentioned above ("These features can be tested via software through the insertion of invalid bus transactions".)

Question 1:

What is "error trapping"? My understanding is that it includes two features: 1. Address decoder monitoring (which can detect invalid target address). 2. Transaction timeout monitoring. Is my understanding correct? If yes, then we should test the two features separately.

Question 2:

What are "invalid bus transactions"? My understanding is that they can be an access to an unimplemented address, or a not word aligned access (eg. access to the address 0x0000_0002). Any other invalid transactions?

Question 3:

Does the "address decoder" mentioned in 5.11.1 mean the "redundant address decoder" in the L2RAMW? If yes, this would mean that this feature is also tested if we test the redundant address decoder.

Question 4:

How to test the "Timeout" monitoring feature? Any special diagnostic register (like RAMTES in L2RAM") available?

Question 5:

Section 5.12.1 mentions the error trapping test too. Is it the same as that mentioned in section 5.11.1?

Question 6:

Section 5.11.7 and 5.11.8,  5.12.4, 5.12.5 all mentioned the read back of configuration registers. Which registers are meant here?

Thank you and best regards,

Libo

 

  • Hi LIbo,

      Please find my answers inline.

    Question 1:

    What is "error trapping"? My understanding is that it includes two features: 1. Address decoder monitoring (which can detect invalid target address). 2. Transaction timeout monitoring. Is my understanding correct? If yes, then we should test the two features separately.

    Charles>> Error trapping can be means of a bus error or an error to to the ESM module. The L2 interconnect has the responsibility of decoding the address initiated by a bus master. If the address falls into a undefined space in the memory map then the L2 interconnect will reply to the bus master with a bus error as part of the response. In the case of the CPU, it can lead to an abort. Inside the L2 memory interconnect there are also timeout circuits that measures the amount of time a request initiated by each bus master until the the request is accepted by the slave and also the amount of time from a request is accepted until the response is replied by the slaves. If the counter times out before the request is accepted or the response is replied then an error is assertred to the ESM GP1.91.

    Question 2:

    What are "invalid bus transactions"? My understanding is that they can be an access to an unimplemented address, or a not word aligned access (eg. access to the address 0x0000_0002). Any other invalid transactions?

    Charles>> Illegal address can be one of them. I don't consider an unaligned access an invalid transaction. An unaligned access can be handled by the CPU by breaking it into more than one aligned accesses. So there could be multiple aligned bus transactions initiated on the AXI bus onto the L2 memory interconnect.

    Question 3:

    Does the "address decoder" mentioned in 5.11.1 mean the "redundant address decoder" in the L2RAMW? If yes, this would mean that this feature is also tested if we test the redundant address decoder.

    Charles>> The "address decoder" mentioned in 5.11.1 is about the address decoding mechanism for each initiator in the L2 memory interconnect. As you know in LC4357 there are 5 bus masters attached to the L2 memory interconnect. These 5 bus masters are R5F CPU, DMA PortA, POM, ACP-M and PS_SCR_M. For each bus master, there is an address decoder. Once the address is routed to the slave, i.e. L2RAMW, there is additional safety diagnostic logic such as the redundant address decoder. Note that the redundant address decode is part of the L2RAMW. 

    Question 4:

    How to test the "Timeout" monitoring feature? Any special diagnostic register (like RAMTES in L2RAM") available?

    Charles>> For each type of the timeout counter there is a compare threshold counter register. Please look at the SCMTHRESHOLD register in the SCM module. You can try to program with a very small value so that timeout can happen.

    uestion 5:

    Section 5.12.1 mentions the error trapping test too. Is it the same as that mentioned in section 5.11.1?

    Charles>> There are two interconnects in the LC4357 architecture. One is the L2 Memory Interconnect which glues the various bus masters to the L2 memories such as L2 flash, L2 RAM, and EMIF. The Peripheral Interconnect glues the various bus masters to the peripherals such as CRC, PCR1, PCR2, PCR3. As far as the address decoder is concerned it functions the same as the Memory Interconnect in which an illegal address will be signaled to the bus master as a bus error as part of the transaction response.

    Question 6:

    Section 5.11.7 and 5.11.8,  5.12.4, 5.12.5 all mentioned the read back of configuration registers. Which registers are meant here?

    Charles>> All configuration register accesses will happen through the peripheral interconnect, not memory interconnect.  It is possible that the intention in 5.11.7 and 5.11.8 is to ensure the configuration of the memory interconnect itself. The memory interconnect itself also has some control/status registers. the registers to control the timeout compare threshold is in the SCM module. The SCM module then drives these compare values to the memory interconnect. However, the SCM module is a peripheral under the PCR. Some of the control/status registers for the memory interconnect can be access via Interconnect SDC MMR starting at 0xFA00_0000. Please see the TRM Table 2-2. In 5.12.4 and 5.12.5 it is recommending that writing to any peripheral configuration registers be read back periodically as a diagnostic for inadvertent writes or disturb of these registers.

  • Hi Charles,

    thanks for the quick response.

    We currently evaluate if we shall implement the tests mentioned both in 5.11.1 and 5.12.1:

    "These features can be tested via software through the insertion of invalid bus transactions".

    Therefore we would like to clarify what is exactly required in this statement and what we should do.

    Below is the summary based on your answer.

    1. We can meet the requirement in 5.11.1 by doing the following tests:

    We need to test two features: address decoder, and timeout monitoring.

    The address decoder can be tested through accessing an unimplemented address (in RAM region, for example 0x08080000). A data abort shall be triggered.

    The timeout can be tested by setting the SCMTHRESHOLD register.

    2. For 5.12.1, we only need test address decoder (with an  access to an unimplemented address in peripheral region).

    My summary regarding the read back of configuration registers:

    1. For 5.11.7, 5.11.8, we can read back the SCM and SDC MMR registers.

    2. For 5.12.4 and 5.12.5, there is no such register. It is actually covered in the section 5.13.6/7, 5.14.6/7 and 5.15.7/8. There we can test the PCR1, PCR2 and PCR4 registers.

    Could you please check if I have missed anything?

    Thank you and regards,

    Libo

  • Hi Libo,

      Two more things I'd also bring up are the 5.11.6 Transaction Parity Diagnostic and 5.11.10 Interconnect Self Test. These are additional safety diagnostic built inside the L2 memory interconnect. If you are interested to test these diagnostic please refer to the SCM module section 3.3 for more details.

  • Hi Charles,

    thanks for the hints to the extra tests.

    According to TRM Section 3.2.3.3, it seems that the self test covers Timeout. Dose the self test also cover address decoder? If yes, then I don't need to implement the tests for 5.11.1 which I described above if I run the self test.

    SPNU540: Section 5.22.6:

    "This parity mechanism can detect a single bit error. The use of the feature is highly recommended."

    This statement sounds that the parity mechanism can be disabled. SCMCNTRL register can only put the MCU to parity test mode. Which register can disable this feature?

    Thank you!

    Libo

  • Hi Libo,  

      During L2 memory interconnect selftest, the selftest logic will inject small amount of test vectors to stimulate the interconnect. It will cover not only  the address decoder logic but also various other components inside the interconnect.  It is similar to CPU LBIST in concept but the implementation is different with lesser coverage. Any selftest errors will be logged in the Interconnect SDC MMR registers and generates error to the ESM.

      The parity check built inside the L2 memory interconnect can not be disabled. However, you can change the polarity of the parity checking and hence create some intentional faults. For example, the CPU may generate ODD parity for the address and control signals. You can force the interconnect to decode the parity using EVEN parity and hence will create faults. The fault will cause the error to go to ESM.

  • Hi Charles,

    thanks for the answer.

    Then I think it makes more sense to implement the self test. This way I can cover the requirements of section 5.11.1, 5.11.10 (or even 5.11.6 too?). For 5.11.6, we can use the test described in section 3.3.1 of the TRM.

    Usually in the safety manual, if the  use of feature is "highly recommended", then it should be enabled. Since the feature "parity check" can't be disabled, it is actually a "mandatory" feature.

    Thanks and regards,

    Libo

  • Hi LIbo,

      I'd like to give a bit more implementation detail on the L2 memory interconnect but not too much to confuse you.There are two layers to the L2 memory interconnect. The self-test is applicable to the inner layer where the majority of the interconnect logic belongs to such as the decoder, arbitration logic, FIFO and etc. This inner layer is wrapped by a small outer layer. The main purpose of this outer layer is to translate bus protocol from one bus interface to another interface. In this layer there is also the parity checking. 

    The self test is a more comprehensive test where it provides both positive test vectors and negative test vectors from each masters to the connected slaves. Various different types of faults can be detected including parity errors and others. Since the self-test does not apply to the outer layer I will suggest that you also do the parity checking diagnostic for the outer layer by inverting the polarity. Yes, you are right that the parity checking can not be disabled.

  • Hi Charles,

    thanks for the further explanation of the parity checking mechanism.

    I will mark this question as answered to close this thread.

    Thanks and regards,

    Libo