Method for implementing periodic online self-test of network chip digital components and chip architecture
By introducing a TestPattern generator and TestPattern extraction technology into network chips, a periodic generator, a TestPattern response processor, a configuration and state memory sandbox, a tester, a configuration and state memory, a state memory sandbox, a state memory sandbox, an output verification logic and output logic, an output memory sandbox, an output verification logic and output verification logic, and an output verification logic and output verification logic, the problem of random hardware fault detection in non-storage type digital components in network chips is solved, achieving real-time detection and low-cost functional safety.
Patent Information
- Application Number
- CN202411775398.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-04
- Publication Date
- 2025-11-07
- Estimated Expiration
- 2044-12-04
AI Technical Summary
Existing technologies struggle to efficiently detect and handle random hardware failures in non-storage type digital components during normal network chip operation, leading to functional abnormalities and failing to meet the Fault Tolerance Time (FTTI) requirements. Furthermore, software-based self-testing is time-consuming, while hardware-based LBIST can only operate during power-on and power-off cycles, resulting in high costs for redundant safety mechanisms.
The functional architecture of the network chip is enhanced by adding a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, sandbox mapping logic, and output verification value logic. By generating and executing TestPattern sequences, random hardware faults of digital components are periodically checked, and the existence of faults is determined by using the CRC32 algorithm for verification and calculation.
It enables real-time detection of random hardware faults in non-memory type digital components during normal chip operation, meets FTTI requirements, reduces costs, and avoids the harm of functional abnormalities.
Smart Images

Figure CN119603196B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of network chip functional safety technology, and in particular to a method for implementing periodic online self-test of a network chip digital component and a chip architecture. BACKGROUND
[0002] During use of the components of a chip integrated circuit, unavoidable random hardware failure conditions may occur due to cosmic rays, alpha particles, electromagnetic interference or voltage faults, etc. These faults include permanent faults such as fixed 0 / 1 faults, open circuit faults, bridging faults, single event hard errors (Single Event Hard Error), and transient faults, etc. These faults may cause abnormal chip functions, and may further cause harm to life-related or critical applications when the chip is used in the fields of vehicle-mounted, industry, etc. Non-storage type digital components in integrated circuits also have these faults.
[0003] Functional safety standards such as ISO26262, IEC61580, etc. suggest using safety mechanisms such as software-based, hardware-based self-test or redundancy to improve the diagnostic coverage of random hardware faults to avoid or reduce the occurrence of harm.
[0004] For safety mechanisms of non-storage type digital components of a chip, due to the large scale of network chips such as switches and routers, current software-based self-test requires a long time in such network chips, and cannot meet the requirements of fault tolerance time interval (FTTI) (FTTI requires that if a fault occurs, the fault must be detected within a specified time, and the fault is handled and then enters a safe state). At the same time, the architecture of a switch / router chip is generally based on a message Pipeline, and a plurality of messages processed in parallel have context information based on a single message, and the processing logic is controlled by user business configuration registers or memories, which is different from a processor that can perform task switching. It is difficult to implement software-based self-test on such network chips. Hardware-based self-test is generally completed by LBIST (Logic Build In Self Test) implemented at the gate level of the chip, but LBIST is destructive, and is generally only run during power-on and power-off to check potential faults, and cannot be used during normal operation of the chip, and thus cannot check permanent faults and transient faults of logic components that occur during normal operation. Although the dual-core lockstep technology of an MCU can run protection while the chip is operating normally, the cost is high. SUMMARY
[0005] In order to solve the above technical problems, the present application provides a method for implementing periodic online self-test of network chip digital components, which can check the random hardware failure of non-memory type digital components of the chip by periodically running hardware-based self-test during normal working time of the chip, while meeting the requirement of fault tolerance time interval (FTTI).
[0006] In order to achieve the above object, the technical scheme of the present application provides a method for implementing periodic online self-test of network chip digital components, which comprises the following steps: S1: adding a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, sandbox mapping logic and output check value logic on the basis of chip function architecture; S2: generating a TestPattern sequence by the TestPattern generator, each TestPattern in the TestPattern sequence comprising a message, a configuration and expected checksum information, wherein for each TestPattern, the corresponding configuration is updated into the configuration and state memory sandbox, and the TestPattern response processor is informed of the expected checksum information, and then the corresponding message is sent to the first functional unit of the chip; S3: the message of the TestPattern passes through the corresponding functional unit in turn according to the processing order, when encountering a memory access operation, the memory access operation is mapped to the configuration and state memory sandbox through the sandbox mapping logic, read / write operation is performed on the configuration and state memory sandbox, and the output checksum of the corresponding functional unit is obtained through the output check value logic, and the output checksum of the last functional unit is sent to the TestPattern response processor; S4: the TestPattern response processor judges whether there is a random hardware failure based on the expected checksum information and the obtained checksum, i.e. the output checksum of the last functional unit; and S5: all Patterns of the TestPattern sequence are completed within the FDTI, and the TestPattern sequence is executed cyclically.
[0007] Further, in step S3, all memory access operations of user service related configurations / states are mapped to the configuration and state memory sandbox through the sandbox mapping logic, and read / write operation is performed on the configuration and state memory sandbox; and the memory access operations not related to user service are not sandbox mapped, and use the same message memory space as the service message.
[0008] Further, in step S3, the output check value logic obtaining the output check sum of the corresponding functional unit comprises: after the packet passes through the corresponding functional unit, all output information of the functional unit is captured, and the captured information is calculated with the output check sum of the previous functional unit to obtain the output check sum of the functional unit; when the packet reaches the last functional unit, the output information generated by the last functional unit, the output check sum of the previous functional unit and the CRC value of the packet are calculated to obtain the output check sum of the last functional unit.
[0009] Further, in step S3, if the current functional unit finds that the packet is the packet discarded by the previous functional unit, the check sum remains unchanged and the packet and the check sum are transparently processed.
[0010] Further, in step S3, in the last functional unit, for the packet discarded by the intermediate functional unit, the packet CRC is set to a fixed value.
[0011] Further, in step S4, the TestPattern response processor compares whether the obtained check sum is consistent with the expected check sum to determine whether there is a random hardware failure.
[0012] Further, in step S3, when the check sum is calculated, the CRC32 algorithm is used.
[0013] Further, the output information of the corresponding functional unit comprises the output information generated by the next functional unit and the output information generated by the configuration and state memory sandbox.
[0014] The technical scheme of the present application also provides a network chip architecture for executing the method as described above, and the network chip architecture comprises a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, sandbox mapping logic and output check value logic. BRIEF DESCRIPTION OF DRAWINGS
[0015] In order to more clearly illustrate the technical scheme of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments, and it should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope, and for those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.
[0016] Figure 1 is a schematic diagram of the implementation model of the periodic online self-test of the digital component of the network chip of the present application. DETAILED DESCRIPTION
[0017] The technical solutions in the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.
[0018] The present application provides an implementation method of periodic online self-test of a network chip digital component, and the design points include:
[0019] (1) On the basis of the chip function architecture, a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, a functional module sandbox mapping logic, and a functional module output check value logic are added.
[0020] (2) The TestPattern generator is responsible for generating a TestPattern sequence containing a message and a configuration and expected checksum information. For each TestPattern, the configuration of the TestPattern is updated to the configuration / state memory sandbox, and the expected checksum information is notified to the TestPattern response processor, and then the message is sent to the first functional unit of the chip.
[0021] (3) When the message of the TestPattern passes through the functional unit, a memory access operation (containing a user configuration register) is mapped to the configuration / state memory sandbox through the sandbox mapping logic, and a read / write operation is performed on the memory sandbox.
[0022] (4) After the message passes through the functional unit logic, the output information generated by the next functional unit and the output information generated by the configuration / state memory are captured, and a checksum calculation is performed on the captured information and the output checksum of the previous functional unit (if any) to obtain a module output checksum.
[0023] (5) The corresponding functional units are sequentially passed through in the order of message processing, and at the last functional unit module, a checksum is calculated on all the output information generated by the module, the output checksum of the previous module, and the CRC value of the message, and the final checksum is sent to the TestPattern response processor module.
[0024] (6) The TestPattern response processor compares the obtained checksum with the expected checksum to determine whether there is a random hardware failure in the non-storage digital component.
[0025] (7) In FDTI (Fault Detection Time Interval), all Patterns of TestPattern sequence are completed and TestPattern sequence is executed in a loop.
[0026] In specific embodiments, as shown in FIG. 1, the white box is the architecture of a general network chip, and the network processing pipeline includes a plurality of functional units, which can be a message receiving unit, a message parsing unit, a message protocol processing unit, a message security processing unit, a message Qos (Quality of Service) processing unit, a message sending unit, and the like. The processing flow is generally that a message is received into a message memory, and context information of the message is generated, the message is processed by a logic circuit of a functional unit in combination with a user configuration / state register, and finally the message is discarded or sent out. Figure 1
[0027] To improve the diagnostic coverage of random hardware faults of the logic circuit, the present application adds functional safety mechanism modules to the functional architecture: a TestPatten generator, a TestPattern response processor, a configuration / state memory sandbox, a sandbox mapping logic module, and an output checksum logic module.
[0028] The TestPattern generator is responsible for generating a TestPattern sequence containing messages, configurations, and expected checksum information. The TestPattern sequence supports a deterministic preset sequence that can cover most of the circuit logic including the critical processing path. The TestPattern preset sequence is obtained through circuit logic analysis. For example, taking an adder as an example, if the 0th bit of the first addend of the adder is broken and always 1 (short circuit state), in order to detect this error, a TestPattern can be added, 0b10101010+Ob01010101=Ob11111111, and the expected value is 0b11111111 (equivalent to the expected checksum). Because the first addend becomes 0b10101011, the actual addition result is Ob10101011+0b01010101=0b0000000 (actual output checksum). Since they are inconsistent, it indicates that the logic circuit has a problem.
[0029] For each generated TestPattern, the configuration of the TestPattern is updated into the configuration / status memory sandbox, while informing the TestPattern response processor of the expected checksum of the current TestPattern, and then sending the packet to the first functional unit of the chip. The configuration / status memory sandbox is a part of the user service state and configurable function memory or register that is carved out or added as a storage space dedicated to the TestPattern packet, with the purpose of avoiding the impact of TestPattern packet processing on user service functions.
[0030] When the packet of the TestPattern passes through the functional unit, all user service related configuration / status access operations (including user configuration / status registers and memories) are mapped to the configuration / status memory sandbox through sandbox mapping logic, and read / write operations are performed on the memory sandbox to avoid affecting the user service. Non-user service related access operations (such as packet memory, etc.) are not sandbox mapped, i.e., the packet memory is not divided into sandbox space, and the TestPattern packet and the service packet use the same packet memory space.
[0031] After the packet of the TestPattern is processed by the functional unit, all output information of the functional unit is captured and recorded, and a checksum of the functional unit is generated based on the recorded output information and the output checksum of the previous stage (for the first functional unit, there is no output checksum of the previous stage), and is used as the input of the next stage. If the current functional unit finds that the TestPattern packet is the packet discarded by the previous functional unit, the checksum remains unchanged and the packet and the checksum are transparently processed.
[0032] The corresponding functional units that pass through in the order of packet processing are sequentially passed through the last functional unit module, and the output information generated by the module and the output checksum of the previous module and the CRC value of the modified packet are used to calculate the checksum, and the final checksum is sent to the TestPattern response processor module. For the packet discarded by the intermediate functional unit, the packet CRC is set to a fixed value.
[0033] The TestPattern response processor compares the obtained checksum with the expected checksum to determine whether there is a random hardware failure in the non-storage digital component, and then notifies other controllers or directly accesses the safe state.
[0034] All patterns of the TestPattern sequence are completed within the FDTI (Fault Detection Time Interval), and the TestPattern sequence is executed in a loop to meet the requirements of functional safety FTTI.
[0035] For example, if the current packet analysis function supports Ethernet analysis and network layer IP analysis, the TestPattern for this function unit is constructed as {destination_mac, Source_mac, ethernet_type, ip_version, ip_header_len, ip_tos, ip_total_length,...}, and the corresponding configuration is that the port type is Ethernet, and the function of this module is to correctly analyze Ethernet and IP packets. The output of the module is each field of the packet, such as destination_mac, source_mac, etc. The expected output of the module is checked and calculated to obtain the output checksum of the module, which is used as the input of the next function unit. Similarly, the expected output of each function unit is checked and calculated, and the checksum including the packet CRC is calculated at the last unit as the expected checksum of the TestPattern. That is, the TestPattern includes three elements: input packet, configuration, and expected checksum. The checksum generation algorithm can be, for example, the CRC32 algorithm.
[0036] In an embodiment of the present application, a method for implementing periodic online self-test of a network chip digital component is provided, comprising the following steps: S1: adding a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, sandbox mapping logic, and output check value logic to a chip function architecture; S2: generating a TestPattern sequence by the TestPattern generator, each TestPattern in the TestPattern sequence comprising a message, a configuration, and expected checksum information, wherein for each TestPattern, the corresponding configuration is updated into the configuration and state memory sandbox, and the TestPattern response processor is notified of the expected checksum information, and then the corresponding message is sent to a first functional unit of the chip; S3: the message of the TestPattern passes through the corresponding functional unit in turn according to a processing order, when a memory access operation is encountered, the memory access operation is mapped to the configuration and state memory sandbox by the sandbox mapping logic, read and write operations are performed on the configuration and state memory sandbox, and an output checksum of the corresponding functional unit is obtained by the output check value logic, and the output checksum of the last functional unit is sent to the TestPattern response processor; S4: the TestPattern response processor judges whether there is a random hardware fault based on the expected checksum information and the obtained checksum, i.e., the output checksum of the last functional unit; and S5: all Patterns of the TestPattern sequence are completed in the FDTI, and the TestPattern sequence is executed in a loop.
[0037] Further, in step S3, all memory access operations of user service related configurations and states are mapped to the configuration and state memory sandbox by the sandbox mapping logic, and read and write operations are performed on the configuration and state memory sandbox; and memory access operations that are not related to user services are not sandbox mapped, and use the same message memory space as service messages.
[0038] Further, in step S3, obtaining the output checksum of the corresponding functional unit by the output check value logic comprises: after the message passes through the corresponding functional unit, all output information of the functional unit is captured, and checksum calculation is performed on the captured information and the output checksum of the previous functional unit, thereby obtaining the output checksum of the functional unit; when the message reaches the last functional unit, the output information generated by the last functional unit, the output checksum of the previous functional unit, and the CRC value of the message are subjected to checksum calculation, thereby obtaining the output checksum of the last functional unit.
[0039] Further, in step S3, if the current functional unit finds that the packet is the packet discarded by the previous functional unit, the checksum remains unchanged and the packet and the checksum are transparently processed.
[0040] Further, in step S3, in the last functional unit, for the packet discarded by the intermediate functional unit, the packet CRC is set as a fixed value.
[0041] Further, in step S4, the TestPattern response processor judges whether there is a random hardware failure by comparing whether the obtained checksum is consistent with the expected checksum.
[0042] Further, in step S3, when the checksum is calculated, the CRC32 algorithm is adopted.
[0043] Further, the output information of the corresponding functional unit includes the output information generated for the next functional unit and the output information generated for the configuration and state memory sandbox.
[0044] In another embodiment of the present application, a network chip architecture is also provided for executing the method as described above, and the network chip architecture comprises a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, sandbox mapping logic and output checksum logic.
[0045] The present application solves the online real-time detection problem of random hardware failure of the non-storage digital components of the network chip, and can realize the functional safety FTTI requirement at low cost.
[0046] The above description is only the preferred embodiment of the present application, but the protection scope of the present application is not limited to this, and any person skilled in the art can make equivalent replacement or change according to the technical solution and the inventive concept of the present application within the technical range disclosed by the present application, which should be covered in the protection scope of the present application.
Claims
1. A method for implementing periodic online self-testing of digital components in a network chip, characterized in that, The method comprises the following steps: S1: adding a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, sandbox mapping logic, and output check value logic on the basis of a chip function architecture; S2: generating a TestPattern sequence by the TestPattern generator, each TestPattern in the TestPattern sequence comprising a message, a configuration, and expected checksum information, wherein, for each TestPattern, the corresponding configuration is updated into the configuration and state memory sandbox, and the TestPattern response processor is notified of the expected checksum information, and then the corresponding message is sent to the first functional unit of the chip; S3: the message of the TestPattern passes through the corresponding functional unit in turn according to a processing order, when a memory access operation is encountered, the memory access operation is mapped to the configuration and state memory sandbox through the sandbox mapping logic, read / write operations are performed on the configuration and state memory sandbox, and the output checksum of the corresponding functional unit is obtained through the output check value logic, and the output checksum of the last functional unit is sent to the TestPattern response processor; S4: the TestPattern response processor judges whether there is a random hardware fault based on the expected checksum information and the obtained checksum, i.e., the output checksum of the last functional unit; S5: all the patterns of the TestPattern sequence are completed in the FDTI, and the TestPattern sequence is executed in a loop.
2. The method of claim 1, wherein, In step S3, all the memory access operations of the configurations / states related to user services are mapped to the configuration and state memory sandbox through the sandbox mapping logic, and read / write operations are performed on the configuration and state memory sandbox; the memory access operations not related to user services are not sandboxed, and use the same message memory space as the service message.
3. The method according to claim 1 or 2, characterized in that, In step S3, obtaining the output checksum of the corresponding functional unit through the output check value logic comprises: After the message passes through the corresponding functional unit, all the output information of the functional unit is captured, and the captured information is subjected to checksum calculation together with the output checksum of the previous functional unit, thereby obtaining the output checksum of the functional unit; When the message reaches the last functional unit, the output information generated by the last functional unit, the output checksum of the previous functional unit, and the CRC value of the message are subjected to checksum calculation, thereby obtaining the output checksum of the last functional unit.
4. The method of claim 3, wherein, In step S3, if the current functional unit finds that the message is a message discarded by the previous functional unit, the checksum remains unchanged and the message and the checksum are transparently processed.
5. The method of claim 4, wherein, In step S3, in the last functional unit, for the message discarded by the intermediate functional unit, the message CRC is set to a fixed value.
6. The method of claim 5, wherein, In step S4, the TestPattern response processor judges whether there is a random hardware fault by comparing whether the obtained checksum and the expected checksum are consistent.
7. The method of claim 3, wherein, In step S3, the CRC32 algorithm is used when performing the check sum calculation.
8. The method of claim 3, wherein, The output information of the respective functional units comprises output information to the next functional unit and output information to the configuration and status memory sandbox.
9. A network chip architecture, comprising: The network chip architecture for performing the method of any of claims 1-8 comprises a TestPattern generator, a TestPattern response handler, a configuration and status memory sandbox, sandbox mapping logic, and output check value logic.
Citation Information
Patent Citations
Test pattern automatic generation system
JP1994186298A
Test pattern generating method
JP1995085129A