SFFS757 February   2024 DLP4620S-Q1 , DLPC231S-Q1

 

  1.   1
  2. 1Introduction
    1.     Trademarks
  3. 2 DLP4620S-Q1 Chipset Functional Safety Capability
  4. 3Development Process for Management of Systematic Faults
    1. 3.1 TI New-Product Development Process
    2. 3.2 TI Functional Safety Development Process
  5. 4 DLP4620S-Q1 Chipset Overview
    1. 4.1 Targeted Applications
    2. 4.2 DLP4620S-Q1 Chipset Functional Safety Concept
      1. 4.2.1 Typical Hazards
      2. 4.2.2 Chipset Architecture
      3. 4.2.3 Built-In Self Tests
    3. 4.3 Functional Safety Constraints and Assumptions
  6. 5Description of Hardware Component Parts
    1. 5.1 Description of System Level Built In Self Test (BISTs)
  7. 6Management of Random Faults
    1. 6.1 Fault Reporting
      1. 6.1.1 HOST_IRQ
      2. 6.1.2 Error History
      3. 6.1.3 Fault Handling
    2. 6.2 Functional Safety Mechanism Categories
    3. 6.3 Description of Functional Safety Mechanisms
      1. 6.3.1 Video Path Protection
        1. 6.3.1.1 Video Input BISTs
        2. 6.3.1.2 Video Processing BISTs
        3. 6.3.1.3 Video Output BISTs
      2. 6.3.2 Illumination Control Protection
        1. 6.3.2.1 Communication Interface and Register Protection
        2. 6.3.2.2 LED Control Feedback Loop Protection
        3. 6.3.2.3 Data Load and Transfer Protection
        4. 6.3.2.4 Watchdogs and Clock Monitors
        5. 6.3.2.5 Voltage Monitors
  8.   A Summary of Recommended Functional Safety Mechanism Usage
  9.   B Distributed Developments
    1.     B.1 How the Functional Safety Lifecycle Applies to TI Functional Safety Products
    2.     B.2 Activities Performed by Texas Instruments
    3.     B.3 Information Provided
  10.   C Revision History

Video Processing BISTs

Figure 6-4 gives an overview of the BISTs used to monitor and diagnose the video processing blocks in the DLPC231S-Q1.

GUID-20240130-SS0I-WM6J-GF1C-51PD2SJZMBSV-low.svg Figure 6-4 Video Processing BIST
  • [SM_5] Front-End Functional Test (FEFT): Checks the video processing blocks in the DLPC231S-Q1 by inserting a test pattern data and performing a CRC check on the output of processing blocks. The test pattern is a 1920x608 horizontal ramp pattern with an overlaid random noise pattern. The size of the image is chosen in order to provide full coverage of the memory control. Two frames of ~120Hz data are tested. This provides a high source pixel clock frequency, in order to stress internal logic. A subset of the image is used for a CRC check. If the CRC after processing does not match the expected CRC, the test fails. This test can be configured to run at start-up, and it can be executed by command after the software is changed to Stand-by mode via host command. In case of test failure, software will not transition Display Mode even if it is commanded by the host. An error will also be logged.
  • [SM_6] Back-End Functional Test (BEFT): Checks the DLPC231S-Q1 blocks responsible for outputting data from the frame buffers to the DMD driver. This checks functionality such as image flips, smooth image transition functions, and frame buffer swaps. Additionally, functionality related to the synchronization of the video with LEDs is tested. This will be discussed in more detail in Section 6.3.2. This test checks a 160x60 image with four configurations—no flip, East/West flip only, North/South flip only, and East/West plus North/South flip. The image size is small in order to increase test speed. The goal of this test is not to provide full coverage of the frame buffers, because that coverage is already provided by other tests. A CRC check is performed on the image after formatting. If the resulting CRC does not match the expected value, the test fails. This test can be configured to run at start-up, and it can be executed by command after the software is changed to Stand-by mode via host command. In case of test failure, software will not transition to Display Mode even if it is commanded by the host. An error will also be logged.
  • [SM_7] DLPC231S-Q1 Memory BIST: Checks functionality of internal memories such as the frame buffers, internal RAM, and sequence look up tables using a series of writes, delays, and reads. The frame buffer memory check is critical for diagnosing a corrupt video path. The SRAM frame buffers are tested using a series of instructions provided by the manufacturer of the SRAM cell. The instructions for executing the test are stored in external flash, but the test data is generated locally in the frame buffer. If the data read from the memory does not match the data written to the memory the test fails. This test can be configured to run at start-up, and it can be executed by command after the software is changed to Stand-by mode via host command. In case of test failure, software will not transition to Display Mode even if it is commanded by the host. An error will also be logged.