In the trend of semiconductor transistor size becoming smaller and chip functionality becoming increasingly complex, system level testing (SLT) has become crucial. What is SLT?
System level testing (SLT) refers to testing a device under test (DUT) in a simulated terminal usage scenario, purely through operation and use, without the need to create test vectors like traditional automated test equipment (ATE), but still requiring the writing of tests, albeit in a different way. The testing process is as follows:
• Perform specific operations. This operation may be inherent in the system usage process, such as starting the operating system; It may also be a specific program written to run certain functional modules, such as performance evaluation programs.
The determination of whether the operation is successful is based on the measurement results or the success/failure of the operation. For example, when verifying whether an internal process has successfully executed, the basis for judgment can be whether the operating system has successfully started; Or check a certain measurement value (comparison between performance test results and threshold)
In most cases, the system in SLT will be equipped with some onboard processors to execute the testing process. Due to the fact that System on Chip (SoC) and System in Package (SIP) chips are the main test objects of SLT, the testing processor is usually a part of the chip under test. If this is not the case, the peripheral testing system of the chip under test is usually equipped with a suitable processor.
The testing time of SLT is much longer than that of traditional ATE because SLT simulates functional testing in real terminal usage scenarios, rather than structural testing in ATE. The testing time for SLT generally exceeds one minute, and may even last for tens of minutes, with a typical testing time of around 10 minutes. Due to the longer testing time, compared to traditional ATE testing, SLT testing equipment must have higher workstation density and lower workstation costs.
There are various methods for creating SLT tests, and the selected SLT testing equipment should be able to flexibly adapt to different methods. A testing program is a collection or sequence of multiple individual tests, typically run on a testing PC that is part of the testing equipment. Each individual test is typically implemented as code and run in the following locations:
• Testing PC
Testing processors, which may be part of testing equipment or test boards
• Processor, a part of the chip under test
In all three cases, testing can be performed on the test board and the chip under test through the API of the testing device or the interface implemented on the test board. In the last scenario, the test can be run on the chip under test.
1) The process of executing tests on a testing PC or testing processor is as follows. In this example, the test aims to verify whether the embedded processor is started. Assuming that the chip under test has a UART port connected to the UART console of the testing device, the simplest form of this test is:

2) Another type of testing is to deploy from the testing PC to the testing processor of the test chip itself in a test chip with a testing processor. In this case, assuming that the chip under test has some kind of high-speed interface, the test program can be downloaded and executed through this interface. The general form of this test is:

3) Another way to perform tests directly stored on the test board is to store the test sequence in non-volatile memory on the test board, thereby saving download time. When downloading tests to the test board, it is easier to modify the tests.
Of course, in real environments, testing will be more complex and require verifying many events. With the flexibility of SLT testing equipment and the real hardware around the tested chip on the test board, it is easier to create very complex scenarios, which is difficult or impossible for traditional ATE to achieve. When using SLT, test engineers can use the chip under test as if it were in a real environment, thereby discovering faults that were previously undetected.

This article is reprinted from the internet. If there is any infringement, please contact us to delete it. Thank you!