Implementation method for periodical online self-test of network chip digital component and chip architecture

Abstract

The invention discloses a method for realizing periodic online self-test of a network chip digital component and a chip architecture. 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 functional architecture; s2, a TestPattern sequence is generated through a TestPattern generator, each TestPattern in the TestPattern sequence comprises a message, configuration and expected checksum information, for each TestPattern, the corresponding configuration is updated to a configuration and state storage sandbox, meanwhile, the TestPattern is notified to respond to the expected checksum information of a processor, and then the corresponding message is sent to a first functional unit of the chip; s3, the messages of the TestPattern sequentially pass through the corresponding functional units according to the processing sequence, when memory access operation is encountered, the memory access operation is mapped to the configuration and state storage sandbox through sandbox mapping logic, read-write operation is executed on the configuration and state storage sandbox, output check sums of the corresponding functional units are obtained through output check value logic, and the output check sums of the corresponding functional units are obtained; the output check sum of the last functional unit is sent to the TestPattern response processor; s4, the TestPattern response processor judges whether a random hardware fault exists or not based on the expected checksum information and the obtained checksum, namely 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 circulating manner.

Description

Technical Field

[0001] The present invention relates to the technical field of network chip functional safety, and in particular to a method for implementing periodic online self-testing of digital components of a network chip and a chip architecture. Background Art

[0002] During the use of chip integrated circuit components, there will be inevitable random hardware failures due to cosmic rays, alpha particles, electromagnetic interference or voltage faults. These faults include permanent faults such as fixed 0 / 1 faults, open circuit faults, bridge faults, single event hard errors (Single Event Hard Error) and transient faults. These faults will cause abnormal chip functions, which will cause life-related or critical application hazards when the chip is used in the automotive, industrial and other fields. Non-storage type digital components in integrated circuits also have these faults.

[0003] Functional safety standards such as ISO26262 and IEC61580 recommend the use of safety mechanisms such as software- and hardware-based self-testing or redundancy to improve the diagnostic coverage of random hardware failures in order to avoid or reduce the occurrence of hazards.

[0004] For the chip non-storage type digital component safety mechanism, due to the large scale of network chips such as switching and routing, the current software-based self-test in such network chips takes a long time and cannot meet the requirements of the fault tolerance time FTTI (Fault Tolerance Time Interval) (FTTI requires that if a fault occurs, the fault must be detected within a specified time, and the fault must be processed and then enter a safe state). At the same time, the architecture of the switching and routing chip is generally based on the pipeline of the message. Several messages processed in parallel have both context information based on a single message, and the processing logic is controlled by the user service configuration register or memory. Unlike the processor that can perform task switching, the software-based self-test is difficult to implement on such network chips. The hardware-based self-test is generally completed by LBIST (Logic Build In Self Test) implemented at the chip gate level. However, LBIST is destructive and generally only runs during power-on and power-off to check potential faults. It cannot be used during the normal operation of the chip, so it cannot check the permanent faults and transient faults of the logic components that appear during the normal operation. Redundant safety mechanisms such as the MCU's dual-core lock-step technology can run protection while the chip is working normally, but the cost is relatively high. Summary of the invention

[0005] In response to the above technical problems, the present invention proposes a method for implementing periodic online self-test of digital components of a network chip. Random hardware failures of non-storage type digital components of the chip can be checked by periodically running hardware-based self-tests during normal working hours of the chip, while meeting the requirements of the fault tolerance time FTTI.

[0006] In order to achieve the above-mentioned purpose, the technical solution of the present invention provides a method for implementing periodic online self-test of digital components of a network chip, which includes the following steps: S1: adding a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, a sandbox mapping logic, and an output check value logic on the basis of the chip functional architecture; S2: generating a TestPattern sequence through a TestPattern generator, each TestPattern in the TestPattern sequence includes a message, a configuration, and expected checksum information, wherein, for each TestPattern, the corresponding configuration is updated to 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 The first functional unit of the chip; S3: The message of TestPattern passes through the corresponding functional units in the processing order. When encountering a memory access operation, the memory access operation is mapped to the configuration and status memory sandbox through the sandbox mapping logic, and read and write operations are performed on the configuration and status memory sandbox. 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 determines whether there is a random hardware fault based on the expected checksum information and the obtained checksum, that is, the output checksum of the last functional unit; S5: Complete all patterns of the TestPattern sequence in FDTI, and execute the TestPattern sequence in a loop.

[0007] Furthermore, in step S3, all user service-related configuration / status memory access operations are mapped to the configuration and status memory sandbox through the sandbox mapping logic, and read and write operations are performed on the configuration and status memory sandbox; for non-user service-related memory access operations, no sandbox mapping is performed, and the same message memory space is used as the service message.

[0008] Further, in step S3, obtaining the output checksum of the corresponding functional unit through the output check value logic includes: after the message passes through the corresponding functional unit, all output information of the functional unit is captured, and the captured information is checked and calculated together with the output checksum of the previous functional unit, so as to obtain 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 checked and calculated together, so as to obtain the output checksum of the last functional unit.

[0009] Furthermore, 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 transmitted.

[0010] Further, 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.

[0011] Further, in step S4, the TestPattern response processor determines whether there is a random hardware failure by comparing the obtained checksum with the expected checksum to see if they are consistent.

[0012] Furthermore, in step S3, the CRC32 algorithm is used when performing the checksum calculation.

[0013] Furthermore, the output information of the corresponding functional unit includes output information generated for the next functional unit and output information generated for the configuration and state memory sandbox.

[0014] The technical solution of the present invention also provides a network chip architecture, which is used to execute the method as described above, and the network chip architecture includes: a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, a sandbox mapping logic, and an output check value logic. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0016] Figure 1 It is a schematic diagram of an implementation model of the periodic online self-test of a network chip digital component of the present invention. DETAILED DESCRIPTION

[0017] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0018] The present invention provides a method for implementing periodic online self-test of digital components of a network chip, and its design key points include:

[0019] (1) Based on the chip functional 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 configuration and expected checksum information. For each TestPattern, the TestPattern configuration is updated to the configuration / state memory sandbox, and the TestPattern response processor is notified of the expected checksum information, and then the message is sent to the first functional unit of the chip.

[0021] (3) When the message of TestPattern passes through the functional unit, if it encounters a memory access operation (including user configuration registers), the memory access operation is mapped to the configuration / status memory sandbox through the sandbox mapping logic, and the read and write operations are performed on the memory sandbox.

[0022] (4) After the message passes through the functional unit logic, the output information generated by the functional unit to the next functional unit and the output information generated to the configuration / status memory is captured, and the captured information and the output checksum of the previous functional unit (if any) are checked and calculated together to obtain the module output checksum.

[0023] (5) The corresponding functional units are passed in sequence according to the message processing order. In the last functional unit module, all the output information generated by the module, the output checksum of the previous module, and the CRC value of the message are used to calculate the checksum, 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 see if they are consistent, and then determines whether there is a random hardware failure in the non-storage digital component.

[0025] (7) Complete all patterns in the TestPattern sequence within the Fault Detection Time Interval (FDTI) and execute the TestPattern sequence in a loop.

[0026] In a specific embodiment, Figure 1 As shown in the figure, the white box is the architecture of a general network chip. The network processing pipeline includes several functional units, which may be message receiving units, message parsing units, message protocol processing units, message security processing units, message QoS (quality of service) processing units, message sending units, etc. The processing flow is generally that the message is received into the message memory, and the context information of the message is generated. Combined with the user configuration / status register, the message is processed by the logic circuit of the functional unit, and finally the message is discarded or sent out.

[0027] In order to improve the diagnostic coverage of random hardware failures of logic circuits, the present invention adds functional safety mechanism modules on the basis of the functional architecture: TestPatten generator, TestPattern response processor, configuration / state memory sandbox, sandbox mapping logic module, and output check value logic module.

[0028] The TestPattern generator is responsible for generating a TestPattern sequence containing messages, configurations, and expected checksum information. The TestPattern sequence supports deterministic preset sequences that can cover most circuit logic including critical processing paths. 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 is 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 result of the addition is Ob10101011+0b01010101=0b0000000 (actual output checksum). Due to the inconsistency, it indicates that there is a problem with the logic circuit.

[0029] For each generated TestPattern, the configuration of the TestPattern is updated to the configuration / state memory sandbox, and the TestPattern response processor is notified of the expected checksum of the current TestPattern, and then the message is sent to the first functional unit of the chip. The configuration / state memory sandbox is to divide or increase a part of the user business status and configurable functional memory or register as a dedicated storage space for the TestPattern message, in order to prevent the TestPattern message processing from affecting the user business function.

[0030] When the TestPattern message passes through the functional unit, all user service-related configuration / status memory access operations (including user configuration / status registers and memory) are mapped to the configuration / status memory sandbox through the sandbox mapping logic, and read and write operations are performed on the memory sandbox to avoid affecting user services. No sandbox mapping is performed for non-user service-related memory access operations (such as message memory, etc.), that is, the message memory does not divide the sandbox space, and the TestPattern message and the business message use the same message memory space.

[0031] After the TestPattern message is processed by the functional unit, all the output information of the functional unit is captured and recorded, and the checksum of the functional unit is generated based on the recorded output information and the output checksum of the previous level (for the first functional unit, there is no output checksum of the previous level), and it is used as the input of the next level. If the current functional unit finds that the TestPattern message is a message discarded by the previous functional unit, the checksum remains unchanged and the message and checksum are transparently transmitted.

[0032] The corresponding functional units that the message passes through in sequence, in the last functional unit module, calculate the checksum of the output information generated by the module, the output checksum of the previous module, and the CRC value of the modified message, and send the final checksum to the TestPattern response processor module. For messages discarded by the intermediate functional units, set the message CRC to a fixed value.

[0033] The TestPattern response processor compares the obtained checksum with the expected checksum to see if they are consistent, and determines whether there is a random hardware failure in the non-storage digital component, and then notifies other controllers or directly enters a safe state.

[0034] Complete all patterns in the TestPattern sequence within the Fault Detection Time Interval (FDTI) and execute the TestPattern sequence cyclically to meet the requirements of functional safety FTTI.

[0035] Take TestPattern as an example. If the current message parsing unit supports Ethernet parsing and network layer IP parsing, then for the TestPattern of this functional unit, the corresponding message should be constructed, such as {destination_mac, Source_mac, ethernet_type, ip_version, ip_header_len, ip_tos, ip_total_length, ...}, and the corresponding configuration, such as the port type is Ethernet, the function of this module is to correctly parse Ethernet and IP messages, then the module output is each field of the message, such as destination_mac, source_mac, etc., and the expected output of the module is checked and calculated to obtain the output checksum of the module, and it is used as the input of the next functional unit. Similarly, the expected output is made for each functional unit in turn, and the expected output is checked and calculated. In the last unit, the checksum including the message CRC is calculated as the expected checksum of the TestPattern. That is, TestPattern contains three elements, {input message, configuration, expected checksum}. The checksum generation algorithm can be, for example, the CRC32 algorithm.

[0036] In an embodiment of the present invention, a method for implementing periodic online self-test of digital components of a network chip is provided, which includes the following steps: S1: adding a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, a sandbox mapping logic, and an output check value logic on the basis of the chip functional architecture; S2: generating a TestPattern sequence through a TestPattern generator, each TestPattern in the TestPattern sequence includes a message, a configuration, and expected checksum information, wherein, for each TestPattern, the corresponding configuration is updated to 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 chip. The first functional unit; S3: The TestPattern message passes through the corresponding functional units in the processing order. When encountering a memory access operation, the memory access operation is mapped to the configuration and status memory sandbox through the sandbox mapping logic, and read and write operations are performed on the configuration and status memory sandbox. 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 determines whether there is a random hardware fault based on the expected checksum information and the obtained checksum, that is, the output checksum of the last functional unit; S5: Complete all patterns of the TestPattern sequence in FDTI, and execute the TestPattern sequence in a loop.

[0037] Furthermore, in step S3, all user service-related configuration / status memory access operations are mapped to the configuration and status memory sandbox through the sandbox mapping logic, and read and write operations are performed on the configuration and status memory sandbox; for non-user service-related memory access operations, no sandbox mapping is performed, and the same message memory space is used as the service message.

[0038] Further, in step S3, obtaining the output checksum of the corresponding functional unit through the output check value logic includes: after the message passes through the corresponding functional unit, all output information of the functional unit is captured, and the captured information is checked and calculated together with the output checksum of the previous functional unit, so as to obtain 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 checked and calculated together, so as to obtain the output checksum of the last functional unit.

[0039] Furthermore, 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 transmitted.

[0040] Further, 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.

[0041] Further, in step S4, the TestPattern response processor determines whether there is a random hardware failure by comparing the obtained checksum with the expected checksum to see if they are consistent.

[0042] Furthermore, in step S3, the CRC32 algorithm is used when performing the checksum calculation.

[0043] Furthermore, the output information of the corresponding functional unit includes output information generated for the next functional unit and output information generated for the configuration and state memory sandbox.

[0044] In another embodiment of the present invention, a network chip architecture is provided for executing the method described above, wherein the network chip architecture includes: a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, a sandbox mapping logic, and an output check value logic.

[0045] The present invention solves the problem of online real-time detection of random hardware failures of non-storage digital components of network chips, and can realize functional safety FTTI requirements at a low cost.

[0046] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A method for implementing periodic online self-test of digital components of a network chip, characterized in that: The steps include: S1: Add TestPattern generator, TestPattern response processor, configuration and state memory sandbox, sandbox mapping logic, and output check value logic based on the chip functional architecture; S2: Generate a TestPattern sequence through the TestPattern generator, each TestPattern in the TestPattern sequence includes a message, a configuration, and expected checksum information, wherein for each TestPattern, update the corresponding configuration to the configuration and state memory sandbox, and notify the TestPattern response processor of the expected checksum information, and then send the corresponding message to the first functional unit of the chip; S3: The message of TestPattern passes through the corresponding functional units in the processing order. When encountering a memory access operation, the memory access operation is mapped to the configuration and status memory sandbox through the sandbox mapping logic, and the read and write operations are performed on the configuration and status memory sandbox. 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 determines whether there is a random hardware fault based on the expected checksum information and the obtained checksum, that is, the output checksum of the last functional unit; S5: Complete all patterns of the TestPattern sequence in FDTI and execute the TestPattern sequence in a loop.

2. The method according to claim 1, characterized in that In step S3, all user service-related configuration / status memory access operations are mapped to the configuration and status memory sandbox through the sandbox mapping logic, and read and write operations are performed on the configuration and status memory sandbox; for non-user service-related memory access operations, no sandbox mapping is performed, and the same message memory space is used 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 includes: After the message passes through the corresponding functional unit, all output information of the functional unit is captured, and the captured information is checked and calculated together with the output checksum of the previous functional unit to obtain 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 checked and calculated together to obtain the output checksum of the last functional unit.

4. The method according to claim 3, characterized in that: 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 transmitted.

5. The method according to claim 4, characterized in that 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 according to claim 5, characterized in that In step S4, the TestPattern response processor determines whether there is a random hardware failure by comparing the obtained checksum with the expected checksum.

7. The method according to claim 3, characterized in that In step S3, the CRC32 algorithm is used when performing checksum calculation.

8. The method according to claim 3, characterized in that 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.

9. A network chip architecture, characterized in that: Used to execute the method as described in any one of claims 1-8, the network chip architecture includes: a TestPattern generator, a TestPattern response processor, a configuration and state memory sandbox, a sandbox mapping logic, and an output check value logic.

Images