A reset verification method and system of an SoC chip and an electronic device

Abstract

The application provides a reset verification method and system of an SoC chip and electronic equipment, comprising: generating a reset verification table according to each module of the SoC chip and the corresponding reset source, and the subsystem of the SoC chip and the corresponding reset source; generating a corresponding detector for each subsystem according to the reset verification table; and checking each reset source through the detector. The reset verification table is used as input data, and a detector corresponding to each subsystem is generated by using a script. The detector corresponds to the subsystem one by one, each reset source is checked separately through the detector, so that the reset of a certain module or subsystem can be detected when it has an effect on other modules or subsystems, and the generation of interwoven errors during reset verification is avoided. Moreover, the reset signal is managed through the reset verification table, and the large workload and low efficiency of environmental iteration caused by reset signal modification in the project iteration process are avoided.

Description

Technical Field

[0001] This application relates to the field of integrated circuit technology, and more specifically, to a reset verification method, system, and electronic device for a SoC chip. Background Technology

[0002] System-on-Chip (SoC) design technology originated in the mid-1990s. With the development of semiconductor process technology, IC (Integrated Circuit) designers have been able to integrate increasingly complex functions onto a single silicon chip. An SoC is a micro-sized system, generally defined as integrating a microprocessor, analog IP cores, digital IP cores, and memory (or off-chip memory control interfaces) onto a single chip. It is usually customer-customized or a standard product for a specific purpose. A complex SoC system integrates multiple functional IP modules, each IP or subsystem having one or more reset control signals. Furthermore, due to different reasons for resetting, there can be multiple reset sources.

[0003] Currently, reset verification is limited to the person in charge of each module or subsystem configuring their own related reset and release settings to see if the reset works. This reset verification method cannot check whether the reset of a certain module or subsystem will work in other modules or subsystems. Summary of the Invention

[0004] The purpose of this application is to provide a reset verification method, system, and electronic device for SoC chips, in order to solve the problem that current reset verification is limited to the person in charge of each module or subsystem configuring their own related reset and release reset to see if the reset works. This reset verification method cannot check whether the reset of a certain module or subsystem will work in other modules or subsystems.

[0005] This application provides a method for resetting and verifying a SoC chip, comprising:

[0006] A reset verification table is generated based on the various modules of the SoC chip and their corresponding reset sources, and the subsystems of the SoC chip and their corresponding reset sources.

[0007] Based on the reset verification table, generate a corresponding detector for each subsystem;

[0008] Each reset source is checked using a detector.

[0009] In the above technical solution, the reset verification table can be paginated according to subsystems. Each page has one column for reset signals sent to various modules or subsystems, one column for the type of reset (module reset, full chip reset, or subsystem reset), a separate column for different reset sources, and a column for the synchronization clock of the reset synchronizer. Using the reset verification table as input data, a script generates a detector corresponding to each subsystem. Each detector corresponds one-to-one with a subsystem, and each reset source is checked individually by the detector. This ensures that a reset in one module or subsystem that affects other modules or subsystems can be detected, avoiding interleaving errors during reset verification. Furthermore, the reset verification table enables management of reset signals, preventing the large workload and low efficiency of environment iteration caused by reset signal modifications during project iterations.

[0010] In some alternative implementations, each reset source is checked by a detector, including:

[0011] Instantiate the detector into the reset detection monitor module;

[0012] By using a reset detection monitor module, the reset source and its corresponding module or subsystem are connected to the detector, and the detector is connected to the synchronous clock or virtual clock of the synchronous reset unit to enable the inspection of each reset source.

[0013] In the above technical solution, a script is used to instantiate the detector into the reset detection monitor module (i.e., the reset_test_monitor module), enabling the detector to connect to the signals to be checked. These signals include the signals from the reset destination and the reset source, and, if a synchronous clock is available, the synchronous clock itself. If no synchronous clock is available, the detector connects to a virtual clock generated by the environment. Here, the reset source signal is the reset signal sent by the reset source; the reset destination signal is the signal generated by the module or subsystem to which the reset signal acts. Specifically, the reset signals of the module or subsystem are extracted from the full chip-level waveform and assigned to the detector's ports. Similarly, the reset signals and synchronous clocks from the reset source can also be extracted from the waveform and assigned to the detector's ports, thus completing the setup of the reset inspection environment. This environment allows for the inspection of each reset source. Furthermore, this embodiment uses a script to capture these signals, avoiding the excessive workload caused by manually capturing thousands of reset signals within the chip.

[0014] In some optional implementations, a corresponding detector is generated for each subsystem based on the reset verification table, including:

[0015] Based on the reset verification table, generate a corresponding monitor for each subsystem;

[0016] Instantiate a detection unit in the monitor to check the effectiveness of the reset, and obtain a detector; the detector is used to check the reset and release of the reset source. When the corresponding module or subsystem is reset or released, if it is detected that the action is not the same as that of the reset source, it is determined that an interleaving error has occurred.

[0017] In the above technical solution, a script is used to generate a corresponding monitor for each subsystem based on the reset verification table. Then, a detection unit is instantiated in the monitor to check whether the reset is effective, thus obtaining a detector. When using the detector to perform the check, it includes the reset and release check of the reset source. Specifically, when the corresponding module or subsystem is reset or released, if it is detected that it is not the function of the reset source, it is determined that an interleaving error has occurred.

[0018] In some alternative implementations, it also includes:

[0019] The monitor is instantiated to a case module with a reset driver. The case module is used to enable and release the reset of each reset source after the SoC chip has completed initialization and released the reset of all modules and subsystems.

[0020] In the above technical solution, by instantiating the monitor to a case module with a reset driver, it is possible to release the reset of all modules and subsystems after the chip completes initialization. The case module automatically performs each process of independent enable reset and release reset in sequence, thus building an automated reset verification environment.

[0021] In some alternative implementations, the detection unit is implemented through assertions, and the detection unit is also used for burr inspection.

[0022] In the above technical solution, since glitches will inevitably be generated after the internal wiring combination logic changes as long as the input signal changes simultaneously, if there are glitches in the reset signal, it will lead to erroneous reset of the module or subsystem. Therefore, the detection unit in this embodiment also includes glitch inspection to ensure that the reset signal does not contain any glitches before inspection.

[0023] In some alternative implementations, the reset source of the module or system includes at least one of soft reset, power-on reset, power-off reset, pad output reset, and pad input reset.

[0024] In the above technical solutions, the reset sources for modules or systems include soft reset, power-on reset, power-off reset, pad output reset, and pad input reset. Soft reset is achieved by sending a reset signal (e.g., low or high level, depending on system settings) to the module or subsystem via software. Power-on reset refers to the subsystem or module performing a reset operation the instant it is powered on, including both hardware and soft reset operations. Hardware and soft resets are initiation operations starting from a certain point within the power-on reset process. The reset verification scheme in this embodiment, when used for power-on reset verification, can verify the timing of the power-on reset release using detectors corresponding to multiple subsystems, avoiding serious system problems. Power-off reset refers to the subsystem or module performing a reset operation when it is powered off. Pad output reset and pad input reset refer to the reset operation performed when a pad (pin) inputs or outputs a signal.

[0025] In some optional implementations, when the reset source is a pad input reset, each reset source is checked by a detector, including:

[0026] Perform glitches filtering on the output signal of the module or subsystem corresponding to the reset source of the pad input reset, and then check the filtered signal.

[0027] In the above technical solution, there is a type of reset that cannot be synchronized by adding a reset synchronizer in the pad input, which may produce glitches. These glitches are known and have no abnormal function. The script will automatically filter out the glitches at the reset destination before checking to avoid false alarms.

[0028] In some alternative implementations, it also includes:

[0029] For each reset source in the entire chip, a corresponding detector is generated;

[0030] The reset source of the entire chip is checked using a detector;

[0031] The full-chip reset source includes at least one of the following: watchdog reset, overheat reset, and full-chip soft reset.

[0032] The above technical solution verifies not only the reset of modules or subsystems of the SoC chip, but also the reset of the entire chip. The reset sources for the entire chip include watchdog reset, thermal reset, and full-chip soft reset. Watchdog technology is an effective system monitoring method. When the system processor is working normally, it outputs a feed signal (clear signal) to the feed input (WDI) of the watchdog timer within a set time, causing the watchdog timer to be periodically cleared. This set time is the watchdog timer's count overflow time. If the watchdog is not fed before the count overflow time (e.g., when the program crashes or freezes), meaning the watchdog timer reaches its count threshold, a reset signal is generated to the system processor, resetting the system processor and preventing system crashes.

[0033] This application provides a reset verification system for a SoC chip. The SoC chip includes multiple subsystems, and each subsystem includes at least one module.

[0034] The system includes:

[0035] The verification information storage and retrieval module is used to generate a reset verification table based on each module and its corresponding reset source, and each subsystem and its corresponding reset source.

[0036] The detection module is used to generate a corresponding detector for each subsystem based on the reset verification table;

[0037] A detector is used to check each reset source.

[0038] In some alternative implementations, the detector is connected to the reset destination terminal and the reset source terminal of the corresponding reset source, and the detector is also connected to the synchronization clock or virtual clock of the synchronous resetter.

[0039] An electronic device provided in this application includes a processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and the machine-readable instructions, when executed by the processor, perform any of the methods described above.

[0040] This application provides a computer-readable storage medium storing a computer program, which is executed by a processor as described above. Attached Figure Description

[0041] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0042] Figure 1 A flowchart illustrating the steps of a reset verification method for a SoC chip provided in this application embodiment;

[0043] Figure 2 A flowchart of the method steps for checking each reset source provided in an embodiment of this application;

[0044] Figure 3 A flowchart illustrating the method steps for generating a detector provided in this application embodiment;

[0045] Figure 4 This application illustrates one possible structure of an electronic device provided in an embodiment of the present application.

[0046] Icons: 1-Processor, 2-Memory, 3-Communication interface, 4-Communication bus. Detailed Implementation

[0047] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0048] Please refer to Figure 1 , Figure 1 A flowchart illustrating the steps of a reset verification method for a SoC chip provided in this application embodiment includes:

[0049] Step 100: Generate a reset verification table based on the various modules of the SoC chip and their corresponding reset sources, and the subsystems of the SoC chip and their corresponding reset sources;

[0050] Step 200: Generate a corresponding detector for each subsystem based on the reset verification table;

[0051] Step 300: Check each reset source using a detector.

[0052] In this embodiment, the reset verification table can be paginated according to subsystems. Each page has one column for reset signals sent to various modules or subsystems, one column for the type of reset (module reset, full chip reset, or subsystem reset), a separate column for different reset sources, and a column for the synchronization clock of the reset synchronizer. Using the reset verification table as input data, a script generates a detector corresponding to each subsystem. Each detector corresponds one-to-one with a subsystem, and each reset source is checked individually by the detector. This ensures that a reset of one module or subsystem can be detected when it affects other modules or subsystems, avoiding interleaving errors during reset verification. Furthermore, the reset verification table enables management of reset signals, preventing the large workload and low efficiency of environment iteration caused by reset signal modifications during project iterations.

[0053] Please refer to Figure 2 , Figure 2 The flowchart of the method for checking each reset source provided in the embodiments of this application shows that, in some optional embodiments, step 300, checking each reset source by a detector, specifically includes:

[0054] Step 310: Instantiate the detector into the reset detection monitor module;

[0055] Step 320: Using the reset detection monitor module, connect the reset source and the corresponding module or subsystem to the detector, and connect the detector to the synchronous clock or virtual clock of the synchronous reset device to check each reset source.

[0056] In this embodiment, a script instantiates the detector into the reset detection monitor module (i.e., the reset_test_monitor module), enabling the detector to connect to the signals to be checked. These signals include the signals from the reset destination and the reset source, and, if a synchronous clock is available, the synchronous clock itself. If no synchronous clock is available, the detector connects to a virtual clock generated by the environment. Here, the reset source signal is the reset signal sent by the reset source; the reset destination signal is the signal generated by the module or subsystem to which the reset signal acts. Specifically, the reset signals of the module or subsystem are extracted from the full chip-level waveform and assigned to the detector's ports. Similarly, the reset signals and synchronous clocks from the reset source can also be extracted from the waveform and assigned to the detector's ports, thus completing the setup of the reset checking environment. This environment allows for the checking of each reset source. Furthermore, this embodiment uses a script to capture these signals, avoiding the excessive workload caused by manually capturing thousands of reset signals within the chip.

[0057] Please refer to Figure 3 , Figure 3 The flowchart of the method steps for generating detectors provided in the embodiments of this application shows that, in some optional implementations, step 200, generating a corresponding detector for each subsystem according to the reset verification table, specifically includes:

[0058] Step 210: Generate a corresponding monitor for each subsystem based on the reset verification table;

[0059] Step 220: Instantiate a detection unit in the monitor to check the effectiveness of the reset, and obtain the detector; the detector is used to check the reset and release of the reset source. When the corresponding module or subsystem is reset or released, if it is detected that the action is not the reset source, it is determined that an interleaving error has occurred.

[0060] In this embodiment of the application, a script is used to generate a corresponding monitor for each subsystem based on the reset verification table. Then, a detection unit for checking whether the reset is effective is instantiated in the monitor to obtain a detector. When using the detector for inspection, it includes the reset and release checks of the reset source. Specifically, when the corresponding module or subsystem is reset or released, if it is detected that it is not the function of the reset source, it is determined that an interleaving error has occurred.

[0061] In some optional implementations, the reset verification method further includes: instantiating a monitor to a case module with a reset driver, the case module being used to enable and release the reset of each reset source after the SoC chip has completed initialization and released the reset of all modules and subsystems.

[0062] In this embodiment, by instantiating the monitor to a case module with a reset driver, it is possible to release the reset of all modules and subsystems after the chip completes initialization. The case module automatically performs each process of independent enable reset and release reset in sequence, thus building an automated reset verification environment.

[0063] In some optional implementations, the detection unit is implemented through assertions and is also used for glitch detection. In this embodiment, since glitch will inevitably be generated after the internal wiring combination logic changes simultaneously, if there are glitch in the reset signal, it will lead to erroneous reset of the module or subsystem. Therefore, the detection unit in this embodiment also includes glitch detection to ensure that the reset signal does not contain any glitch before performing the check.

[0064] In some optional implementations, the reset source of the module or system includes at least one of soft reset, power-on reset, power-off reset, pad output reset, and pad input reset. In this embodiment, the reset source of the module or system includes soft reset, power-on reset, power-off reset, pad output reset, and pad input reset. Soft reset is achieved by sending a reset signal (e.g., low or high level, depending on system settings) to the module or subsystem via software. Power-on reset refers to the subsystem or module performing a reset operation the instant it is powered on, including both hardware and soft reset operations. Hardware and soft resets are initiation operations starting from a certain point within the power-on reset process. The reset verification scheme in this embodiment, when used for power-on reset verification, can verify the timing of the power-on reset release using detectors corresponding to multiple subsystems, avoiding serious system problems. Power-off reset refers to the subsystem or module performing a reset operation when it is powered off. Pad output reset and pad input reset refer to the reset operation performed when a pad (pin) inputs or outputs a signal.

[0065] In some optional implementations, when the reset source is a pad input reset, each reset source is checked by a detector. Specifically, this includes: performing glitches on the output signal of the module or subsystem corresponding to the pad input reset source, and checking the filtered signal.

[0066] In this embodiment of the application, there is a type of reset that cannot be synchronized by adding a reset synchronizer in the pad input, which may produce glitches. These glitches are known and have no abnormal function. The script will automatically filter out the glitches at the reset destination and then check them to avoid false alarms.

[0067] In some optional implementations, the reset verification method further includes:

[0068] Step 400: Generate corresponding detectors for the reset sources of the entire chip;

[0069] Step 500: Inspect the reset source of the entire chip using a detector;

[0070] The full-chip reset source includes at least one of the following: watchdog reset, overheat reset, and full-chip soft reset.

[0071] In this embodiment, in addition to verifying the reset of modules or subsystems of the SoC chip, the reset of the entire chip is also verified. The reset sources for the entire chip include watchdog reset, thermal reset, and full-chip soft reset. Watchdog technology is an effective system monitoring method. When the system processor is working normally, it outputs a feed signal (clear signal) to the feed input terminal WDI of the watchdog timer within a set time, causing the watchdog timer to be periodically cleared. This set time is the watchdog timer's count overflow time. If the watchdog is not fed before the count overflow time (e.g., when the program crashes or freezes), meaning the watchdog timer reaches its count threshold, a reset signal is generated to the system processor, resetting the system processor and preventing system crashes.

[0072] This application provides a reset verification system for a SoC chip. The SoC chip includes multiple subsystems, and each subsystem includes at least one module.

[0073] The reset verification system includes a verification information storage and retrieval module, a detection module, and multiple detectors. The verification information storage and retrieval module generates a reset verification table based on each module and its corresponding reset source, and each subsystem and its corresponding reset source. The detection module generates a corresponding detector for each subsystem based on the reset verification table. The detectors are used to check each reset source.

[0074] In some alternative implementations, the detector is connected to the reset destination terminal and the reset source terminal of the corresponding reset source, and the detector is also connected to the synchronization clock or virtual clock of the synchronous resetter.

[0075] Figure 4 This illustration shows a possible structure of an electronic device provided in an embodiment of this application. (Refer to...) Figure 4 The electronic device includes a processor 1, a memory 2, and a communication interface 3. These components are interconnected and communicate with each other via a communication bus 4 and / or other forms of connection mechanism (not shown).

[0076] The memory 2 includes one or more (only one is shown in the figure), which may be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The processor 1 and other possible components can access the memory 2 to read and / or write data therein.

[0077] Processor 1 includes one or more (only one is shown in the figure), which can be an integrated circuit chip with signal processing capabilities. The aforementioned processor 1 can be a general-purpose processor, including a Central Processing Unit (CPU), a Microcontroller Unit (MCU), a Network Processor (NP), or other conventional processors; it can also be a special-purpose processor, including a Neural-network Processing Unit (NPU), a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. Furthermore, when there are multiple processors 1, some can be general-purpose processors, and others can be special-purpose processors.

[0078] Communication interface 3 includes one or more (only one is shown in the figure) that can be used to communicate directly or indirectly with other devices for data exchange. Communication interface 3 may include interfaces for wired and / or wireless communication.

[0079] One or more computer program instructions can be stored in the memory 2. The processor 1 can read and run these computer program instructions to implement the automatic outbound calling method provided in the embodiments of this application.

[0080] Understandable. Figure 4 The structure shown is for illustrative purposes only; the electronic device may also include structures that are more complex than those shown. Figure 4 The more or fewer components shown, or having the same Figure 4 The different structures shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof. Electronic devices may be physical devices, such as PCs, laptops, tablets, mobile phones, servers, embedded devices, etc., or they may be virtual devices, such as virtual machines, virtualized containers, etc. Furthermore, electronic devices are not limited to a single device; they can also be a combination of multiple devices or a cluster of a large number of devices.

[0081] This application also provides a computer-readable storage medium storing computer program instructions. These computer program instructions are read and executed by a computer's processor to perform the automatic outbound calling method provided in this application. For example, the computer-readable storage medium can be implemented as follows: Figure 4 2. Memory in electronic devices.

[0082] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0083] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0084] Furthermore, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0085] In this document, relational terms such as first and second are used only to distinguish one entity or operation from another entity or operation, without necessarily requiring or implying any such actual relationship or order between these entities or operations.

[0086] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A reset verification method for a SoC chip, characterized in that, include: A reset verification table is generated based on the various modules of the SoC chip and their corresponding reset sources, and the subsystems of the SoC chip and their corresponding reset sources. Based on the reset verification table, generate a corresponding detector for each subsystem; Each reset source is inspected using a detector; The step of generating a corresponding detector for each subsystem based on the reset verification table includes: Based on the reset verification table, generate a corresponding monitor for each subsystem; A detection unit for checking the effectiveness of a reset is instantiated in the monitor to obtain a detector; the detector is used for the reset and release checks of the reset source. When the corresponding module or subsystem is reset or released, if it is detected that the action is not the function of the reset source, it is determined that an interleaving error has occurred.

2. The method as described in claim 1, characterized in that, The step of checking each reset source using a detector includes: Instantiate the detector into the reset detection monitor module; By using a reset detection monitor module, the reset source and its corresponding module or subsystem are connected to the detector, and the detector is connected to the synchronous clock or virtual clock of the synchronous reset unit to enable the inspection of each reset source.

3. The method as described in claim 1, characterized in that, Also includes: The monitor is instantiated to a case module with a reset driver, which is used to enable and release the reset of each reset source after the SoC chip has completed initialization and released the reset of all modules and subsystems.

4. The method as described in claim 1, characterized in that, The detection unit is implemented through assertions and is also used for burr inspection.

5. The method as described in claim 1, characterized in that, The reset source of the module or system includes at least one of soft reset, power-on reset, power-off reset, pad output reset, and pad input reset; wherein, the pad output reset refers to performing a reset operation when a pin outputs a signal; PADS input reset refers to performing a reset operation when a pin input signal is received.

6. The method as described in claim 5, characterized in that, When the reset source is a pad input reset, the step of checking each reset source through the detector includes: Perform glitches filtering on the signal output by the module or subsystem corresponding to the reset source of the pad input reset, and then inspect the filtered signal.

7. The method as described in claim 1, characterized in that, Also includes: For each reset source in the entire chip, a corresponding detector is generated; The reset source of the entire chip is checked using a detector; The reset source for the entire chip includes at least one of the following: watchdog reset, overheat reset, and full-chip soft reset.

8. A reset verification system for a SoC chip, characterized in that, The SoC chip includes multiple subsystems, and each subsystem includes at least one module; The reset verification system for the SoC chip includes: The verification information storage and retrieval module is used to generate a reset verification table based on each module and its corresponding reset source, and each subsystem and its corresponding reset source. The detection module is used to generate a corresponding detector for each subsystem based on the reset verification table; A detector is used to check each reset source; The step of generating a corresponding detector for each subsystem based on the reset verification table includes: Based on the reset verification table, generate a corresponding monitor for each subsystem; A detection unit for checking the effectiveness of a reset is instantiated in the monitor to obtain a detector; the detector is used for the reset and release checks of the reset source. When the corresponding module or subsystem is reset or released, if it is detected that the action is not the function of the reset source, it is determined that an interleaving error has occurred.

9. The reset verification system for a SoC chip as described in claim 8, characterized in that, The detector is connected to the reset destination terminal and the reset source terminal of the corresponding reset source, and the detector is also connected to the synchronization clock or virtual clock of the synchronous reset device.

10. An electronic device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when executed by the processor, perform the method as described in any one of claims 1-7.

11. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, performs the method as described in any one of claims 1-7.

Images