High performance and high reliability maintenance bus

Abstract

The invention relates to a high performance and high reliability maintenance bus. Main device request information initiated by any main device in the main device unit group is sent to a target object through the maintenance bus, target object response information generated by the target object is returned to the target main device, request data xx2yyreqdata is at least configured in the main device request information, and the request data xx2yyreqdata is sent to the target main device through the maintenance bus. Response data yy2xxackdata are at least configured in the target object response information, and the data bit width of the request data xx2yyreqdata in the main device request information and the data bit width of the response data yy2xxackdata in the target object response information are both not smaller than 32 bits. According to the invention, high-performance interaction between the master device and the slave device can be realized, and the reliability of access interaction between the master device and the slave device is improved.

Description

Technical Field

[0001] The invention relates to a maintenance bus, in particular to a maintenance bus with high performance and high reliability. Background Art

[0002] In chip design, the common bus structure is the AMBA (Advanced Microcontroller Bus Architecture) bus; when it is oriented towards low-bandwidth peripherals while taking into account the maintenance and debugging purposes of the entire chip, an APB (Advanced Peripheral Bus) bus is usually mounted under the AXI (Advanced eXtensible Interface) bus, and some peripherals of the entire chip are mounted under the APB bus, such as UART (Universal Asynchronous Receiver / Transmitter) and I2C (Inter-Integrated Circuit). When working, the master device sends a request to the AXI bus, the AXI bus routes the request to the APB bus, and the APB bus then routes and forwards the request, and finally accesses the slave device.

[0003] As chips in the fields of high-performance server chips and AI chips become more and more complex, more and more slave devices need to be accessed. Therefore, the design of the maintenance bus needs to take into account scalability, high reliability, and high performance. It should be noted that the maintenance bus is a bus that can access the entire chip IO (input / output) space, and is used for debug maintenance and other purposes.

[0004] In the patent application with publication number CN106326172A, an APB bus slave interface expansion circuit and its use method are disclosed, and a method for expanding the APB bus under the slave device interface is provided. Specifically, the address space of the slave device to be expanded needs to be divided into N non-overlapping sub-address spaces. A slave device interface of the APB bus is used as an expansion point, an interface expansion implementation circuit is connected below, and an APB slave device expansion interface is connected below the interface expansion circuit, and some slave devices that need to be accessed are connected below.

[0005] When the patent application with publication number CN106326172A implements the bus, based on the original master device accessing the slave device through the AXI bus and the APB bus, more slave devices can be accessed through expansion circuits and interfaces under the APB bus; specifically, it can be seen from the characteristics of the APB protocol that at least two clock cycles are required to send read and write requests to the slave device, which loses one cycle in performance. The APB protocol determines that the data bit width of the slave device mounted below cannot exceed 32 bits, which has limitations for the slave device.

[0006] In addition, there is no reliability guarantee in the bus transmission link. For example, if the request information or response information is changed in the link due to some factors, an erroneous transmission will occur, and there is no way to find out what specific abnormality has occurred. When a slave device fails and cannot return a response, the APB bus will be stuck, making all slave devices mounted under the APB inaccessible. Summary of the invention

[0007] The purpose of the present invention is to overcome the deficiencies in the prior art and provide a high-performance and high-reliability maintenance bus that can achieve high-performance interaction between a master device and a slave device and improve the reliability of access interaction between the master device and the slave device.

[0008] According to the technical solution provided by the present invention, a high-performance and high-reliability maintenance bus is used to connect a master device group and a slave device group, wherein the master device group includes a plurality of master devices, and the slave device group includes a plurality of slave devices.

[0009] For a master device request information initiated by any master device in the master device unit group, the master device request information is sent to the target object via the maintenance bus, and the target object response information generated by the target object is returned to the target master device, wherein:

[0010] The target object includes a slave device in a slave device group or an address space unit in the maintenance bus, wherein when the target object is a slave device in a slave device group, a master device request is sent from the maintenance bus to the target object via one clock cycle of the maintenance bus, and a target object response information is returned from the target object to the maintenance bus via one clock cycle;

[0011] The master device request information and the target object response information are generated based on the maintenance bus protocol, where:

[0012] At least request data xx2yy_req_data is configured in the master device request information, and at least response data yy2xx_ack_data is configured in the target object response information. The data bit width of the request data xx2yy_req_data in the master device request information and the data bit width of the response data yy2xx_ack_data in the target object response information are both not less than 32 bits, so that the master device can access the slave device with a data bit width of not less than 32 bits via the maintenance bus.

[0013] When the master device request information is generated based on the maintenance bus protocol, the master device request information also includes a request valid identification signal xx2yy_req_valid, a request address xx2yy_req_addr, a request write granularity status signal xx2yy_req_strb, a request type signal xx2yy_req_type, and a request read granularity status signal xx2yy_req_rsize;

[0014] The target object response information also includes a response valid identification signal yy2xx_ack_valid and a response abnormal identification signal yy2xx_ack_excp;

[0015] The maintenance bus protocol is a serial protocol, in which

[0016] For any master device request information, when the request valid identification signal xx2yy_req_valid in the master device request information is in a valid state, the request address xx2yy_req_addr, request data xx2yy_req_data, request write granularity status signal xx2yy_req_strb and request read granularity status signal xx2yy_req_rsize in the master device request information are maintained until the response valid identification signal yy2xx_ack_valid corresponding to the current master device request information is valid;

[0017] For any target object response information, when the response valid identification signal yy2xx_ack_valid in the target object response information is in a valid state, the response data yy2xx_ack_data and the response exception identification signal yy2xx_ack_excp are maintained until the request valid identification signal xx2yy_req_valid in the next master device request information is in a valid state.

[0018] The maintenance bus comprises:

[0019] A preprocessing module group, including several preprocessing modules, uses a preprocessing module to adapt and connect with a master device, at least preprocesses the master device request information initiated by the connected master device, and forwards the master device preprocessed request information generated by the preprocessing to the arbitration module, and returns the target object response information to the connected master device;

[0020] An arbitration module, adapted and connected to the preprocessing module group and the primary routing module, for arbitrating the preprocessed request information of the master device forwarded by the preprocessing module group, and forwarding the arbitrated preprocessed request information of the master device to the primary routing module;

[0021] The primary routing module is connected to one or more secondary routing modules, and at least forwards the request information pre-processed by the main device to the corresponding secondary routing module, wherein:

[0022] One or more leaf nodes are mounted on each secondary routing module, and the leaf nodes are used to connect the slave devices. The secondary routing module at least routes and forwards the pre-processed request information received from the master device to one leaf node, so that the pre-processed request information of the master device can be forwarded to the corresponding connected slave device via the leaf node;

[0023] A first-level routing register group for recording abnormal status is set in the first-level routing module.

[0024] When the target object is an address space unit in the maintenance bus, a leaf node, a secondary routing module or a primary routing module is configured as the address space unit.

[0025] The preprocessing module preprocesses the request information of the main device, including request content inspection processing and request verification code generation processing, where:

[0026] First, the received master device request information is checked for content.

[0027] When the request content check process is passed, the preprocessing module performs request verification code generation processing on the master device request information, and generates the master device preprocessed request information after the request verification code generation processing;

[0028] The first-level routing module, the second-level routing module and the leaf node all perform address space check and verification processing on the pre-processed request information received from the main device, where:

[0029] When the target object is a slave device, the first-level routing module, the second-level routing module and the leaf node are configured to perform address space check and verification processing on the request information pre-processed by the master device in turn, and when all address space check and verification processes are passed, the request information pre-processed by the master device is sent to the slave device as the target object through the corresponding leaf node.

[0030] When performing a request content check on the master device request information, the preprocessing module at least performs a request granularity legalization check and / or a request address granularity boundary check on the master device request information, wherein:

[0031] When performing a request granularity legalization check on the master device request information, check the write request granularity corresponding to the request write granularity status signal xx2yy_req_strb to determine whether the write request granularity of the master device request information is a legal request granularity or an illegal request granularity;

[0032] When performing a request address granularity boundary check on the master device request information, the address granularity boundary state of the request address xx2yy_req_addr is checked based on the request granularity corresponding to the master device request information to determine whether the address granularity boundary state of the master device request information is an illegal boundary state or a legal boundary state;

[0033] When the write request granularity is a legal request granularity and the address granularity boundary state is a legal boundary state, the preprocessing module preprocesses the master device request information, wherein the request verification code generation processing of the master device request information at least includes generating a request verification code based on the master device request information;

[0034] Based on the master device request information and the request verification code, the master device pre-processed request information is generated.

[0035] When performing the address space check and verification process, it includes sequentially performing the check code verification process and the address space check process, wherein:

[0036] When performing the check code verification process, at least the request check code in the request information pre-processed by the master device is verified, and when the verification passes, the address space check process is performed on the request information pre-processed by the master device;

[0037] When performing address space check processing, at least the request address xx2yy_req_addr in the request information preprocessed by the master device is judged as a hole address. When the request address xx2yy_req_addr is a non-hole address, the request information preprocessed by the master device is sent to the target object based on the request address xx2yy_req_addr.

[0038] When configuring the primary routing module, secondary routing module, and leaf node to perform address space check and verification processing on the request information after preprocessing by the main device in turn, there are:

[0039] When the primary routing module performs the address space check and verification process and passes it, the secondary routing module will perform the address space check and verification process;

[0040] When the secondary routing module passes the address space check and verification process, the leaf node will perform the address space check and verification process;

[0041] When any address space check and verification process fails, the corresponding address space check and verification exception information is written into the first-level routing module, and the exception response information is returned to the target master device.

[0042] The leaf nodes mounted on the secondary routing module are independent of each other, or multiple leaf nodes are configured as broadcast links, where:

[0043] Configure a slave device to connect to a leaf node;

[0044] For all leaf nodes in the broadcast link, the request information pre-processed by the master device is sent to each leaf node in a broadcast manner, and the request information pre-processed by the master device is sent to the connected slave device via the leaf node.

[0045] When the target object is a slave device, the slave device loads the target object response information to the corresponding connected leaf node, and forwards the target object response information to the corresponding preprocessing module via the leaf node, the secondary routing module, the primary routing module and the arbitration module, wherein:

[0046] The preprocessing module verifies the response verification code of the received target object response information. When the verification passes, the target object response information is sent to the connected main device. Otherwise, the response uncorrectable information is written into the first-level routing module, and the abnormal response information is returned to the target main device.

[0047] For any leaf node, after the leaf node forwards the request information pre-processed by the master device to the connected slave device, the leaf node starts timing. When the timing exceeds the preset timeout period and the target object response information of the slave device is not received, the leaf node generates a slave device timeout exception response and writes the response uncorrectable error information into the primary routing module;

[0048] The slave device timeout exception response is sent to the corresponding pre-processing module via the secondary routing module, the primary routing module and the arbitration module, and then sent to the corresponding master device via the pre-processing module.

[0049] The advantages of the present invention are as follows: the request information of the master device can be sent from the maintenance bus to the target object via one clock cycle of the maintenance bus, and the data bit width of the request data xx2yy_req_data in the request information of the master device and the data bit width of the response data yy2xx_ack_data in the response information of the target object are both not less than 32 bits, so that the master device can access the slave device with a data bit width of not less than 32 bits via the maintenance bus, and high-performance interaction between the master device and the slave device can be achieved;

[0050] In the process of sending the master device request to the target object, the request content is checked and processed first, and then the master device pre-processed request information is generated after pre-processing. The first-level routing module, the second-level routing module and the leaf node all perform address space check and verification processing to improve the reliability of the request information; in addition, by setting the timeout setting register in the leaf node, the timeout mechanism can be implemented to avoid the maintenance bus being stuck due to the timeout of the slave device. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 One embodiment of the present invention maintains the state of the bus.

[0052] Figure 2 A timing diagram of an embodiment of the present invention in which a master device requests information and a target object responds to information.

[0053] Figure 3 The flowchart of an embodiment of the pre-processing module of the present invention processing the request information of the main device.

[0054] Figure 4 This is a flow chart of an embodiment of the preprocessing module of the present invention processing the target object response information.

[0055] Figure 5 The flowchart of an embodiment of the arbitration module of the present invention arbitrates the request information pre-processed by the master device.

[0056] Figure 6 The flowchart of an embodiment of the present invention is that the primary routing module processes the request information after preprocessing by the main device.

[0057] Figure 7 The flowchart of an embodiment of the present invention is that the secondary routing module processes the request information after pre-processing by the main device.

[0058] Figure 8 The present invention is a flow chart of an embodiment of the leaf node processing request information after pre-processing by the main device.

[0059] Fig. 9 A schematic diagram of an embodiment of the connection between the secondary routing module and the broadcast link formed in the present invention.

[0060] Fig.10 The figure is a working diagram of a broadcast link according to an embodiment of the present invention.

[0061] Fig.11 The figure is a flow chart of an embodiment of the timeout mechanism of a single leaf node of the present invention.

[0062] Fig.12 The figure is a flow chart of an embodiment of the timeout mechanism of the broadcast link of the present invention. DETAILED DESCRIPTION

[0063] The present invention will be further described below in conjunction with specific drawings and embodiments.

[0064] In order to realize high-performance interaction between a master device and a slave device, the present invention provides a high-performance and high-reliability maintenance bus for connecting a master device group and a slave device group, wherein the master device group includes a plurality of master devices, and the slave device group includes a plurality of slave devices.

[0065] For a master device request information initiated by any master device in the master device unit group, the master device request information is sent to the target object via the maintenance bus, and the target object response information generated by the target object is returned to the target master device, wherein:

[0066] The target object includes a slave device in a slave device group or an address space unit in the maintenance bus, wherein when the target object is a slave device in a slave device group, a master device request is sent from the maintenance bus to the target object via one clock cycle of the maintenance bus, and a target object response information is returned from the target object to the maintenance bus via one clock cycle;

[0067] The master device request information and the target object response information are generated based on the maintenance bus protocol, where:

[0068] At least request data xx2yy_req_data is configured in the master device request information, and at least response data yy2xx_ack_data is configured in the target object response information. The data bit width of the request data xx2yy_req_data in the master device request information and the data bit width of the response data yy2xx_ack_data in the target object response information are both not less than 32 bits, so that the master device can access the slave device with a data bit width of not less than 32 bits via the maintenance bus.

[0069] As can be seen from the above description, the maintenance bus of the present invention is a bus that can access the entire chip IO space and is used for debugging, maintenance, and debugging. Therefore, during operation, the maintenance bus can be used to achieve the connection between the master device group and the slave device group. Figure 1 FIG. 1 shows a schematic diagram of an embodiment of using a maintenance bus to realize the connection between a master device group and a slave device group. Figure 1 It can be seen that the master device group can generally include several master devices, and the slave device group can include several slave devices. The corresponding number and type of master devices and slave devices can be selected and determined according to actual needs, and the specific amount shall be based on what can meet the actual application requirements.

[0070] It should be understood that the master device is generally a device that can initiate a request, and the request initiated can be a read request or a write request, and the slave device can respond to the request initiated by the master device. From the above description, it can be seen that in the prior art, such as the APB bus, the request initiated by the master device needs to go through two clock cycles before it can be sent to the corresponding slave device, which affects the performance of the entire interaction between the master device and the slave device.

[0071] The request initiated by the master device is the master device request information. For any master device request information, in one embodiment of the present invention, when the target object is a slave device, the master device request is sent from the maintenance bus to the target object via one clock cycle of the maintenance bus, and the target object response information is returned from the target object to the maintenance bus via one clock cycle. It can be seen that compared with the data interaction of the APB bus in the prior art, the performance of the interaction between the master device and the slave device can be improved. Consistent with the prior art, after receiving the master device request information, the target object can respond to the master device request information, generate target object response information, and return the target object response information to the target master device, wherein the target master device specifically refers to the master device that sends the master device request information to the target object.

[0072] In specific implementation, for a certain maintenance bus, the clock cycle of the maintenance bus can be determined. The clock cycle of the maintenance bus is generally related to the type of the maintenance bus and the working scenario. The specific method and process of determining the clock cycle of the maintenance bus are consistent with the prior art and will not be repeated here. When the target object is a slave device, the time for the master device request to be sent from the maintenance bus to the target object is one clock cycle. Similarly, the target object response information of the target object can be returned to the maintenance bus after one clock cycle, and can finally be returned to the target master device.

[0073] In specific implementation, the target object may be one or more slave devices in a slave device group, or an address space unit in a maintenance bus. It can be understood that when the target objects are different, the process of sending the master device request information in the maintenance bus will be different, but the master device request information can be sent from the maintenance bus to the target object within one clock cycle of the maintenance bus. The following will provide specific examples of the target object with reference to the diagram.

[0074] As can be seen from the background technology description, in the prior art, a master device based on the APB bus cannot access a slave device whose data width exceeds 32 bits. In order to further improve the performance between the master device and the slave device, the maintenance bus protocol is pre-configured. At this time, the master device request information and the target object response information should be generated based on the maintenance bus protocol. Specifically, the data width of the request data xx2yy_req_data in the master device request information and the data width of the response data yy2xx_ack_data in the target object response information are configured to be greater than 32 bits, so that the master device can access the slave device whose data width is not only 32 bits through the maintenance bus, that is, the master device can access the slave device whose data width is 32 bits or 64 bits.

[0075] From the above description, it can be seen that the above-mentioned master device can access a slave device with a data bit width of not less than 32 bits via the maintenance bus. Specifically, when the master device accesses the slave device via the maintenance bus, the data bit width of the slave device can be 32 bits or 64 bits, which can be determined according to the type of the slave device, etc., thereby achieving high-performance interaction between the master device and the slave device.

[0076] In one embodiment of the present invention, when the master device request information is generated based on the maintenance bus protocol, the master device request information also includes a request valid identification signal xx2yy_req_valid, a request address xx2yy_req_addr, a request write granularity status signal xx2yy_req_strb, a request type signal xx2yy_req_type, and a request read granularity status signal xx2yy_req_rsize;

[0077] The target object response information also includes a response valid identification signal yy2xx_ack_valid and a response abnormal identification signal yy2xx_ack_excp;

[0078] The maintenance bus protocol is a serial protocol, in which

[0079] For any master device request information, when the request valid identification signal xx2yy_req_valid in the master device request information is in a valid state, the request address xx2yy_req_addr, request data xx2yy_req_data, request write granularity status signal xx2yy_req_strb and request read granularity status signal xx2yy_req_rsize in the master device request information are maintained until the response valid identification signal yy2xx_ack_valid corresponding to the current master device request information is valid;

[0080] For any target object response information, when the response valid identification signal yy2xx_ack_valid in the target object response information is in a valid state, the response data yy2xx_ack_data and the response exception identification signal yy2xx_ack_excp are maintained until the request valid identification signal xx2yy_req_valid in the next master device request information is in a valid state.

[0081] Specifically, the request valid identification signal xx2yy_req_valid mainly reports the valid status of the master device request information. Figure 2 An embodiment in which the request valid identification signal xx2yy_req_valid is high level valid is shown. Specifically, when the request valid identification signal xx2yy_req_valid is in a valid state, the maintenance bus will confirm that there is valid master device request information, and then the master device request information can be sent to the target object.

[0082] From the above description, it can be seen that in order to improve the performance, the data bit width of the request data xx2yy_req_data is at least 32 bits. Of course, the data bit width of the request data xx2yy_req_data can also be 64 bits. The address width of the request address xx2yy_req_addr and the data bit width of the request data xx2yy_req_data can generally be selected according to actual needs, so as to meet the interaction requirements between the master device and the slave device. For example, the address width of the request address xx2yy_req_addr can be 32 bits. Figure 2 FIG. 2 shows an embodiment in which the address width of the request address xx2yy_req_addr and the data bit width of the request data xx2yy_req_data are both 32 bits.

[0083] The request type signal xx2yy_req_type is used to identify the request type of the master device request information, such as identifying the master device request information as a write request or a read request. Figure 2 FIG. 2 shows an embodiment in which when the request type signal xx2yy_req_type is at a high level, it indicates that the request information of the master device is a write request, and when the request type signal xx2yy_req_type is at a low level, it indicates that the request information of the master device is a read request. Figure 2 In the example, when the request type signal xx2yy_req_type is high and the request valid identification signal xx2yy_req_valid is valid, it can be determined that the master device request information is a valid write request. For other situations, refer to Figure 2 This is explained here and no further examples are given.

[0084] When the request type of the master device request information is a write request, the write request granularity of the write request is set by requesting the write granularity status signal xx2yy_req_strb. In addition, the request write granularity status signal xx2yy_req_strb can also be omitted in the master device request information. For example, for the maintenance bus and the slave device, the slave device only supports a single write granularity of 4B (32 bits) or 8B (64 bits), and the xx2yy_req_strb signal can be omitted between the maintenance bus and the slave device. At this time, the bit width of the write data can be configured by requesting the data xx2yy_req_data, and the request write granularity status signal xx2yy_req_strb can be omitted. When the master device request information includes the request write granularity status signal xx2yy_req_strb, the data bit width of the request write granularity status signal xx2yy_req_strb can be one eighth of the data bit width of xx2yy_req_data. For example, when the data bit width of the request data xx2yy_req_data is 32 bits, the bit width of the request write granularity status signal xx2yy_req_strb is 4. Figure 2 shown.

[0085] When the request type of the request information is a read request, the read request granularity can be set by requesting the read granularity status signal xx2yy_req_rsize. In addition, the request read granularity status signal xx2yy_req_rsize can be omitted in the master device request information. For example, for the maintenance bus and the slave device, if the slave device only supports 4B (32bit) or only supports 8B (64bit) corresponding to a single read granularity, the xx2yy_req_rsize signal can be omitted between the maintenance bus and the slave device. At this time, the request read granularity status signal xx2yy_req_rsize can be omitted by reading the response data yy2xx_ack_data. When the master device request information includes the request read granularity status signal xx2yy_req_rsize, the size of the request read granularity status signal xx2yy_req_rsize is 2 bits. At this time, when the request read granularity status signal xx2yy_req_rsize is 00, it indicates 1-byte read; when the request read granularity status signal xx2yy_req_rsize is 01, 10, and 11, it indicates 2-byte read, 4-byte read, and 8-byte read, respectively.

[0086] In specific implementation, the corresponding master device request information can be generated according to the request requirements of the master device. The corresponding content of the master device request information can be set with reference to the above method. For example, the target object connected via the maintenance bus can be determined according to the request address xx2yy_req_addr.

[0087] Figure 2 An embodiment of the target object response information is also shown in FIG. Figure 2 In the figure, yy2xx_ack_valid is a response valid identification signal, and the response valid identification signal yy2xx_ack_valid can be used to identify the validity of the current target object response information. In the figure, when the response valid identification signal yy2xx_ack_valid is at a high level, it indicates that the target object response information is valid response information, otherwise it is invalid response information.

[0088] Figure 2 In the example, yy2xx_ack_excp is a response exception identification signal. When a response exception occurs, the response exception identification signal yy2xx_ack_excp is in a valid state. Figure 2 In the example, the response abnormality identification signal yy2xx_ack_excp is effective at a high level, that is, when a response abnormality occurs, the response abnormality identification signal yy2xx_ack_excp is at a high level. Figure 2 In the example, clk is the clock signal and rst_n is the reset signal.

[0089] In specific implementation, the maintenance bus protocol is a serial protocol, that is, for the maintenance bus, the next request processing can only be carried out after the current master device request information and target object response information are processed. For example, a master device request information is used as the current master device request. When the master device request is sent to the target object and the target object response information of the target object is returned to the target master device, it is deemed that the processing of the current master device request information and the target object response information is completed. Only then can the sending processing of the next master device request and the returning processing of the target object response information be carried out.

[0090] In one embodiment of the present invention, the maintenance bus includes:

[0091] A preprocessing module group, including several preprocessing modules, uses a preprocessing module to adapt and connect with a master device, at least preprocesses the master device request information initiated by the connected master device, and forwards the master device preprocessed request information generated by the preprocessing to the arbitration module, and returns the target object response information to the connected master device;

[0092] An arbitration module, adapted and connected to the preprocessing module group and the primary routing module, for arbitrating the preprocessed request information of the master device forwarded by the preprocessing module group, and forwarding the arbitrated preprocessed request information of the master device to the primary routing module;

[0093] The primary routing module is connected to one or more secondary routing modules, and at least forwards the request information pre-processed by the main device to the corresponding secondary routing module, wherein:

[0094] One or more leaf nodes are mounted on each secondary routing module, and the leaf nodes are used to connect the slave devices. The secondary routing module at least routes and forwards the pre-processed request information received from the master device to one leaf node, so that the pre-processed request information of the master device can be forwarded to the corresponding connected slave device via the leaf node;

[0095] A first-level routing register group for recording abnormal status is set in the first-level routing module.

[0096] When the target object is an address space unit in the maintenance bus, a leaf node, a secondary routing module or a primary routing module is configured as the address space unit.

[0097] Figure 1 An embodiment of the maintenance bus is shown in FIG. Figure 1 In the example, the master device requests information to be sent to the target object, that is, Figure 1 The arrow in the figure only shows the direction in which the master device sends the request information. The direction in which the target object responds to the master device should be opposite to the direction in which the master device sends the request information. Figure 1 The target object responds to the information sent.

[0098] right Figure 1 The maintenance bus includes a preprocessing module group, an arbitration module, a primary routing module, a secondary routing module group and a leaf node group, wherein the preprocessing module group generally includes a plurality of preprocessing modules, and the number of preprocessing modules in the preprocessing module group can be selected according to actual needs. Generally, the preprocessing modules are independent of each other, one preprocessing module can be connected to a corresponding main device, and all preprocessing modules are connected to the arbitration module. Figure 1 In the figure, the secondary routing module group includes multiple secondary routing modules, all of which are connected to the primary routing module, and the leaf node group includes several leaf nodes. The secondary routing module group and the leaf node group will be described in detail below.

[0099] During specific implementation, each preprocessing module can adopt the same form and can at least realize the preprocessing of the master device request information. Specifically, at least the master device request information initiated by the connected master device is preprocessed, and the master device preprocessed request information generated by the preprocessing is forwarded to the arbitration module, and the target object response information is returned to the connected master device, that is, the preprocessing module can realize the reception of the master device request information and the target object response information. Thereafter, the received target object response information should be sent to the target master device, and the received master device request information should be forwarded to the arbitration module after preprocessing.

[0100] In specific implementation, after the master device initiates the master device request, the corresponding connected preprocessing module can immediately receive the master device request. At this time, the master device request also enters the maintenance bus. After one clock cycle, the preprocessing module completes the preprocessing of the master device request, and forwards the generated master device preprocessed request information to the arbitration module after the second clock cycle. The arbitration module performs arbitration processing after one clock cycle, and forwards the arbitrated master device preprocessed request information to the first-level routing module in the next clock cycle. The situation of forwarding the master device preprocessed request information in the maintenance bus through the clock cycle can be referred to here, and no more examples are given.

[0101] In one embodiment of the present invention, the preprocessing module preprocesses the master device request information, including request content inspection processing and request verification code generation processing, wherein:

[0102] First, the received master device request information is checked for content.

[0103] When the request content check process is passed, the preprocessing module performs request verification code generation processing on the master device request information, and generates the master device preprocessed request information after the request verification code generation processing;

[0104] The first-level routing module, the second-level routing module and the leaf node all perform address space check and verification processing on the pre-processed request information received from the main device, where:

[0105] When the target object is a slave device, the first-level routing module, the second-level routing module and the leaf node are configured to perform address space check and verification processing on the request information pre-processed by the master device in turn, and when all address space check and verification processes are passed, the request information pre-processed by the master device is sent to the slave device as the target object through the corresponding leaf node.

[0106] Since the master device request information is initiated by the master device, but the master device request information initiated by the master device may have setting errors, in order to improve the validity and reliability of the master device request information, the master device request information should first be checked and processed to ensure the correctness of the master device request information. Figure 3 An embodiment of the preprocessing module processing the received main device request information is shown in the figure. In the figure, the preprocessing module receives the request, which means the main device request information received by the preprocessing module. It can be seen from the figure that the received main device request information should be checked and processed for the request content. The method of checking and processing the request content is specifically described below.

[0107] In one embodiment of the present invention, when performing request content inspection on the master device request information, the preprocessing module at least performs a request granularity legalization check and / or a request address granularity boundary check on the master device request information, wherein:

[0108] When performing a request granularity legalization check on the master device request information, check the write request granularity corresponding to the request write granularity status signal xx2yy_req_strb to determine whether the write request granularity of the master device request information is a legal request granularity or an illegal request granularity;

[0109] When performing a request address granularity boundary check on the master device request information, the address granularity boundary state of the request address xx2yy_req_addr is checked based on the request granularity corresponding to the master device request information to determine whether the address granularity boundary state of the master device request information is an illegal boundary state or a legal boundary state;

[0110] When the write request granularity is a legal request granularity and the address granularity boundary state is a legal boundary state, the preprocessing module performs request verification code generation processing on the master device request information, wherein the request verification code generation processing on the master device request information at least includes generating a request verification code based on the master device request information;

[0111] Based on the master device request information and the request verification code, the master device pre-processed request information is generated.

[0112] It can be seen from the above description that the request type of the master device request information can be a read request or a write request. In specific implementation, when the request granularity legality check is performed on the master device request information, it mainly refers to checking the request write granularity status signal xx2yy_req_strb in the master device request information. If it is determined that the request type of the current master device request information is a write request based on the request type signal xx2yy_req_type, the request write granularity status signal xx2yy_req_strb is checked to determine the write request granularity of the request write granularity status signal xx2yy_req_strb. For example, it can be stipulated in the maintenance bus protocol that the write request granularity should be 1 byte, 2 bytes, 4 bytes or other similar granularities for write operations. When it is detected that the write request granularity corresponding to the request write granularity status signal xx2yy_req_strb is 3 bytes, or 5 bytes, etc., the current write request granularity can be determined as an illegal request granularity. Otherwise, it should be a legal request granularity.

[0113] When the request address granularity is checked for the master device request information, the request address xx2yy_req_addr is mainly checked. Specifically, when checking the request address xx2yy_req_addr, the write request granularity of the master device request information should be determined based on the above. For example, if the request type of the current master device request information is a write request, and the write request granularity determined based on the request write granularity status signal xx2yy_req_strb is 2 bytes, then the lower 1 bit of the request address xx2yy_req_addr should be 0. If the lower 1 bit of the request address xx2yy_req_addr is 0 based on the request write granularity status signal xx2yy_req_strb, then the lower 1 bit of the request address xx2yy_req_addr should be 0. When the write request granularity determined by xx2yy_req_strb is 4 bytes, the lower 2 bits of the request address xx2yy_req_addr should be 0, and the same applies to other cases. That is, when performing a request address granularity bound check, the write request granularity corresponding to the master device request information should be determined. After that, it can be determined whether the low-order data of the request address xx2yy_req_addr matches the request granularity. When the two match, it can be determined that the address granularity bound state is a legal bound state, otherwise, it should be an illegal bound state.

[0114] When the request type of the current master device request information is determined to be a read request based on the request type signal xx2yy_req_type, the write request granularity of the master device can be assumed to be a legal request granularity. At the same time, the address granularity boundary state of the master device request information should be regarded as a legal boundary state.

[0115] Figure 3 In the above, when the judgment of "write granularity is legal && address granularity is bounded" is "yes", it specifically means that the write request granularity is a legal request granularity and the address granularity is bounded. After that, the pre-processing module generates a request verification code for the master device request information. Specifically, the request granularity is a legal request granularity and the address granularity is bounded. The state is in a legal state. At this time, it means that the master device request information has passed the request content check process, which means that the master device request information should be regarded as having no configuration errors. After that, the request verification code generation process should be performed on the master device request information. Figure 3 In the process, when the write granularity is legal and the address granularity is bounded, the judgment is "no", an exception should be registered and an error response should be returned to the main device, wherein the exception should be registered in the first-level routing module.

[0116] It should be noted that the error response generated by the preprocessing module should be generated according to the provisions of the above-mentioned target object response information, that is, the error response generated by the preprocessing module includes a response valid identification signal yy2xx_ack_valid, a response abnormal identification signal yy2xx_ack_excp, and a response data yy2xx_ack_data. At this time, the specific type of the current response error can be recorded by the response abnormal identification signal yy2xx_ack_excp. In order to register the abnormality in the primary routing module, the error response should also be sent to the primary routing module via the arbitration module, and the primary routing module performs abnormal registration according to the response abnormal identification signal yy2xx_ack_excp of the error response.

[0117] In one embodiment of the present invention, after the request verification code generation processing is performed on the master device request information, a corresponding request verification code can be generated, and the request verification code and the master device request information can be used to generate the master device pre-processed request information. In specific implementation, the request verification code can be an even check code, such as Figure 3 As shown, when the request check code is an even check code, the existing commonly used technical means can be used to generate the corresponding request check code. A feasible way may be: when the address bit width of the request address xx2yy_req_addr is 48 bits, and the data bit width of the request data xx2yy_req_data is 64 bits, then a 1-bit address even check code is generated for every 8 bits of address data in the request address xx2yy_req_addr. At the same time, a 1-bit data even check code is generated based on every 8 bits of data in the request data xx2yy_req_data. Specifically, when generating a 1-bit address even check code, the 8-bit address data is subjected to bitwise XOR logic, and the 1-bit result is inverted to generate the corresponding 1-bit address even check code. The generation method of the 1-bit data check code can refer to the generation description of the 1-bit address even check code here, which will not be repeated here.

[0118] In specific implementation, the request check code may include an address even check code group and a data even check code group. In the above embodiment, the address even check code group should include a 6-bit address even check code, and the data even check code group should include an 8-bit data even check code group.

[0119] It should be noted that after the master device pre-processing request information is generated, the master device pre-processing request information should be sent to the arbitration module for arbitration processing by the arbitration module. During operation, the arbitration module may receive multiple different master device pre-processing request information at the same time. Since it is necessary to maintain the serial execution state specified by the serial protocol, it is necessary to use the arbitration module to arbitrate the master device pre-processing request information. After the arbitration module arbitrates all the master device pre-processing request information, it can select a master device pre-processing request information and send the selected master device pre-processing request information to the first-level routing module, while the master device pre-processing request information that is not selected by the arbitration will be temporarily stored in the arbitration module until the arbitration module receives a target object response information.

[0120] When the arbitration module receives the target object response information sent by the primary routing module, it will forward the target object response information to the corresponding preprocessing module. After that, the next round of arbitration processing can be started in the arbitration module to send the preprocessed request information of the newly selected master device to the primary routing module and receive the target object response information sent by the primary routing module. Figure 5 FIG. 2 shows an embodiment of arbitration processing of request information pre-processed by the arbitration module on the master device. The requests in the figure all refer to request information pre-processed by the master device. For example, the request received by the arbitration module is request information pre-processed by the master device.

[0121] During specific implementation, the arbitration module may adopt existing commonly used arbitration forms, such as the round-robin arbitration method for pre-processing request information of the main device. Of course, the arbitration module may also adopt other arbitration methods, specifically based on the ability to achieve arbitration of pre-processing request information of the main device and send the received target object response information to the corresponding pre-processing module.

[0122] In order to improve the reliability of the maintenance bus, in one embodiment of the present invention, the first-level routing module, all the second-level routing modules and all the leaf nodes can be configured to perform address space check and verification processing on the received pre-processed request information of the main device, so as to utilize the address space check and verification processing to ensure the reliability of the received pre-processed request information of the main device. It can be seen from the above description that the first-level routing module, the second-level routing module and the leaf node can all be configured as target objects. For example, when the first-level routing module is used as the target object, the first-level routing module performs address space check and verification processing on the received pre-processed request information of the main device, and generates corresponding target object response information. At this time, the pre-processed request information of the main device will not be forwarded to the second-level routing and the corresponding leaf node; similarly, when the second-level routing module is used as the target object, the first-level routing module performs address space check and verification processing on the received pre-processed request information of the main device, and generates corresponding target object response information.

[0123] It can be seen from the above description that when the first-level routing module, the second-level routing module and the leaf node receive the pre-processed request information of the main device, they should perform address space check and verification processing on the pre-processed request information of the main device. Specifically, the pre-processed request information of the main device received by the first-level routing module should be forwarded by the arbitration module, the pre-processed request information of the main device received by the second-level routing module should be forwarded by the first-level routing module, and the pre-processed request information of the main device received by the leaf node should be forwarded by the connected second-level routing module.

[0124] It can be understood that when a slave device is used as a target object, the request information after preprocessing by the master device should be forwarded to the slave device as the target object after passing through the primary routing module, the secondary routing module and the leaf node. At this time, the primary routing module, the secondary routing module and the leaf node should be configured to perform address space check and verification processing on the request information after preprocessing by the master device in turn, and when all address space check and verification processing are passed, the request information after preprocessing by the master device is sent to the slave device as the target object through the corresponding leaf node. Specifically, all address space check and verification processing are passed, which specifically means that the primary routing module, the secondary routing module and the leaf node perform address space check and verification processing on the request information after preprocessing by the master device in turn, and all pass.

[0125] In one embodiment of the present invention, when performing the address space check and verification process, it includes sequentially performing the verification code check process and the address space check process, wherein:

[0126] When performing the check code verification process, at least the request check code in the request information pre-processed by the master device is verified, and when the verification passes, the address space check process is performed on the request information pre-processed by the master device;

[0127] When performing address space check processing, at least the request address xx2yy_req_addr in the request information preprocessed by the master device is judged as a hole address. When the request address xx2yy_req_addr is a non-hole address, the request information preprocessed by the master device is sent to the target object based on the request address xx2yy_req_addr.

[0128] It can be seen from the above description that the request information after preprocessing by the master device should include a request verification code. After receiving the request information after preprocessing by the master device, the request verification code should be verified first. When the verification passes, the address space check processing should be performed on the request information after preprocessing by the master device. Specifically, based on the above-mentioned request verification code generation method, in the first-level routing module, the second-level routing module and the leaf node, the verification code is generated in the same way as the request verification code is generated by the preprocessing module. At this time, a corresponding comparison verification code can be generated. Thereafter, the comparison verification code is compared with the request verification code. When the comparison verification code is consistent with the request verification code, the verification passes, otherwise, the verification fails.

[0129] The request address xx2yy_req_addr is judged as a hole address, specifically, whether the request address xx2yy_req_addr is addressed in the IO address space. When the request address xx2yy_req_addr is addressed in the IO address space, the request address xx2yy_req_addr is considered to be a non-hole address, otherwise, the request address xx2yy_req_addr is a hole address.

[0130] In specific implementation, when the request address xx2yy_req_addr is a non-hole address, the request information after pre-processing of the main device is sent to the target object based on the request address xx2yy_req_addr, so as to realize the forwarding processing of the request information after pre-processing of the main device. For example, the first-level routing module performs address space check and verification processing on the request information after pre-processing of the main device, and determines that the target object is itself (that is, the first-level routing module) based on the request address xx2yy_req_addr. At this time, the request information after pre-processing of the main device is sent to the target object. Thereafter, the first-level routing module responds to the received request information of the main device pre-processing.

[0131] It should be noted that when the primary routing module, the secondary routing module and the leaf node determine that the request address xx2yy_req_addr is a hole address, the address anomaly registration should be performed in the primary routing module. In addition, when the primary routing module, the secondary routing module and the leaf node fail to verify the request verification code, the anomaly registration should also be performed in the primary routing module.

[0132] In one embodiment of the present invention, when the primary routing module, the secondary routing module and the leaf node are configured to perform address space check and verification processing on the request information after preprocessing by the main device in sequence, there are:

[0133] When the primary routing module performs the address space check and verification process and passes it, the secondary routing module will perform the address space check and verification process;

[0134] When the secondary routing module passes the address space check and verification process, the leaf node will perform the address space check and verification process;

[0135] When any address space check and verification process fails, the corresponding address space check and verification exception information is written into the first-level routing module, and the exception response information is returned to the target master device.

[0136] It can be seen from the above description that when performing address space check and verification processing, it specifically refers to the address space check and verification processing performed by the first-level routing module, the second-level routing module and the leaf node that receive the request information after pre-processing by the main device, wherein whether the second-level routing module and the leaf node perform address space check and verification processing should be based on the target object. The following is a specific description of the process of address space check and verification processing performed by the first-level routing module, the second-level routing module and the leaf node.

[0137] Figure 6 The flowchart of an embodiment of the processing of the request information after the primary routing module pre-processes the main device is shown. The request received by the primary routing module in the figure is the request information after the primary routing module pre-processes the main device. Figure 6 As can be seen from the above description, when receiving the request information after pre-processing by the main device, the verification code verification process should be performed first. When the verification passes, the address space check process should be performed. If the verification fails, an exception registration should be performed in the first-level routing module. Specifically, the specific process of the verification code verification process and the address space check process can be referred to the above description, which will not be repeated here.

[0138] It can be seen from the above description that the first-level routing module can be used as a target object. When the first-level routing module is used as a target object and the request address xx2yy_req_addr should be a non-empty address, the request address xx2yy_req_addr points to the address space within the first-level routing module. Since the first-level routing module includes a first-level routing register group, and the first-level routing register group includes several first-level routing registers, the address space within the first-level routing module specifically refers to the address space corresponding to a first-level routing register in the first-level routing module.

[0139] In one embodiment of the present invention, the first-level routing registers in the first-level routing register group may include: an exception record register, an uncorrectable error record register, a hole exception address record register, a read access granularity exception address record register, a write access granularity exception address record register, a timeout exception address record register, and a write granularity illegal and address non-bound exception address record register, wherein:

[0140] Specifically, the exception record register mainly records the exception types that occur on the maintenance bus. For each exception that occurs, the corresponding bit is registered as 1. After querying, the corresponding bit can be cleared by writing 1. Specifically, the data bit width of the exception record register can be 5 bits. In this case, there are: exception record register [4:0], where exception record register [0] is a hole exception, exception record register [1] is a read access granularity exception, exception record register [2] is a write access granularity exception, exception record register [3] is a timeout exception, and exception record register [4] is an illegal write granularity and an out-of-bounds address granularity exception.

[0141] It can be seen from the above description that when the pre-processing module performs a request granularity legalization check and a request address granularity boundary check on the master device request information, when the write request granularity is an illegal request granularity, the pre-processing module should register the exception to the first-level routing module. At this time, the first-level routing module should set [4] in the exception record register. In addition, when the request address xx2yy_req_addr is a hole address, [0] in the exception record register should be set. Other situations are similar and will not be explained one by one here.

[0142] The uncorrectable error record register mainly records whether the request check error occurs on the maintenance bus in the request path or the response path. The data bit width of the uncorrectable error record register can be 2 bits, wherein the uncorrectable error record register [0] indicates that a request check error occurs in the request path of the maintenance bus, and the uncorrectable error record register [1] indicates that a request check error occurs in the response path of the maintenance bus. Specifically, the request channel refers to the path for sending the master device request to the target object, and the response path refers to the path for returning the target object response information to the target master device.

[0143] The hole exception address record register mainly records the address when a hole exception occurs in the maintenance bus. The data bit width of the hole address record register is n bits, specifically: hole address record register [n-1:0], wherein only when [0] of the exception record register is 0, can it be recorded in the hole address record register, that is, if the bit is not cleared between multiple hole exceptions, only the address when the exception occurs for the first time can be recorded. The first exception is the first time that the request address xx2yy_req_addr is judged to be a hole address. The size of n is consistent with the address bit width of the request address xx2yy_req_addr. The following n are the same, and you can refer to the description here.

[0144] The read access granularity exception address recording register is used to record the address when a read access granularity exception occurs in the maintenance bus, wherein the data bit width of the read access granularity exception address recording register is n bits, and then there is: read access granularity exception address recording register [n-1:0]; generally, only when [1] in the exception recording register is 0 can it be recorded, that is, if the bit is not cleared between multiple occurrences of read access granularity exceptions, only the address when the exception occurs for the first time can be recorded. The first occurrence of the exception here specifically refers to the occurrence of a read access granularity exception.

[0145] The write access granularity exception address recording register is used to record the address when a write access granularity exception occurs in the maintenance bus, wherein the data bit width of the write access granularity exception address recording register is n bits, and then: write access granularity exception address recording register [n-1:0]; specifically, only when [2] in the exception recording register is 0, can the write access granularity exception address recording register be used to record the address when the write access granularity exception occurs, that is, if this bit is not cleared between multiple occurrences of write access granularity exceptions, only the address when the exception occurs for the first time can be recorded. The first occurrence of the exception here specifically refers to the occurrence of a write access granularity exception, and the write access granularity exception means that the above-mentioned write request granularity is an illegal request granularity.

[0146] The timeout exception address record register is used to record the address when a timeout exception occurs in the maintenance bus, wherein the data bit width of the timeout exception address record register is n bits, and then there is: timeout exception address record register [n-1:0]; specifically, only when [3] of the exception record register is 0, can the timeout exception address record register be configured to record, that is, if the bit is not cleared between multiple timeout exceptions, only the address when the exception occurs for the first time can be recorded. Here, the first exception specifically refers to the occurrence of a timeout exception.

[0147] The write granularity illegal and address out-of-bounds exception address recording register is used to record the address when the write granularity illegal and address out-of-bounds exception occurs in the maintenance bus. The data bit width of the write granularity illegal and address out-of-bounds exception address recording register is n bits, then: write granularity illegal and address out-of-bounds exception address recording register [n-1:0]. Specifically, only when [4] of the exception recording register is 0 can it be recorded, that is, if the bit is not cleared between multiple occurrences of write granularity illegal and address out-of-bounds exceptions, only the address when the exception occurs for the first time can be recorded. The first occurrence of the exception here specifically refers to the occurrence of write granularity illegal and address granularity out-of-bounds exceptions.

[0148] From the above description, it can be seen that the preprocessing module performs a request granularity legalization check and a request address granularity bounds check on the master device request information. When the write request granularity of the master device request information is an illegal request granularity and the address granularity bounds status is an illegal bounds status, the write granularity illegal and address non-bounds exception address recording register is used to record the corresponding exception address. The recorded address is the address of the preprocessing module corresponding to the exception.

[0149] In the above description, when the target object is a primary routing module and the master device request information points to the address space in the primary routing module, it means that the master device request information points to one of the above primary routing registers. After the primary routing register is determined, the operation of the selected primary routing register can be implemented according to the request type signal xx2yy_req_type in the master device request information. For example, when it is determined as a read request by the request type signal xx2yy_req_type, the value of the selected primary routing register is read. For example, when it is determined as a write request by the request type signal xx2yy_req_type, the request data xx2yy_req_data is written into the corresponding primary routing register.

[0150] Depend on Figure 6 As can be seen from the above description, the first-level routing register is the internal space of the first-level routing module. After performing corresponding operations on the first-level router according to the master device request information, the first-level routing module will generate target object response information and send the target object response information to the arbitration module, so as to be sent to the target master device through the arbitration module and the corresponding pre-processing module. When the target object is a leaf node or a slave device, the first-level routing module shall forward the received request information after pre-processing by the master device to the corresponding second-level routing module. It can be understood that the forwarded second-level routing module shall be related to the request address xx2yy_req_addr in the request information after pre-processing by the master device. The situation of the target object response information generated by the first-level routing module can refer to the description of the above-mentioned target object response information, which will not be repeated here.

[0151] Figure 7 The workflow of the secondary routing module is shown in FIG. 1 . The workflow of each secondary routing module is the same. Figure 7 In the process, the secondary routing module receives the request, specifically, the primary routing module forwards the request information pre-processed by the main device to the secondary routing module. Thereafter, the secondary routing module performs verification code verification and address space check on the received request information pre-processed by the main device. The method and process of performing verification code verification and address space check can be referred to the above description and will not be repeated here.

[0152] Depend on Figure 7It can be seen that when the check code verification process and the address space check process fail, the secondary routing module registers an exception to the primary routing module. If the check code verification process fails, the uncorrectable exception is registered in the uncorrectable error record register in the primary routing module. After that, the secondary routing module generates a check error response, wherein the generated check error response can refer to the description of the error response generated by the above-mentioned preprocessing module. Different from the preprocessing module, the check error response generated by the secondary routing module needs to be forwarded to the corresponding target master device through the primary routing module, the arbitration module and the preprocessing module. When the address space check process fails, the exception record register and the void exception address record register in the primary routing module are used to register the void address exception.

[0153] It can be seen from the above description that each secondary routing module can be used as a target object. Therefore, after receiving the request information pre-processed by the main device and passing the verification code verification process and the address space check process, the current secondary routing module can confirm whether the secondary routing module is used as the target object according to the request address xx2yy_req_addr. When it is used as the target object, the current secondary routing module responds to the request information pre-processed by the main device, and sends the target object response information generated in response to the primary routing module. The way in which the secondary routing module responds to the request information pre-processed by the main device is generally related to the request type of the request information pre-processed by the main device, etc. For details, please refer to the description of the above-mentioned primary routing module, which will not be repeated here.

[0154] If the current secondary routing module confirms that the target object is a leaf node or a slave device according to the request address xx2yy_req_addr, it shall check the granularity of accessing the leaf node and the slave device to determine whether the access granularity is legal. When the access granularity is determined to be legal, the request information pre-processed by the master device is forwarded to the corresponding connected leaf node according to the request address xx2yy_req_addr. When the access granularity is determined to be illegal, the access granularity exception is registered in the primary routing module. When the access granularity exception is registered, it shall be related to the request type of the request information pre-processed by the master device. For details, please refer to the above description.

[0155] The following example illustrates the determination of legal access granularity. For example, if the target object is a slave device, and if the slave device as the target object adopts 4-byte addressing and the internal register is 32 bits, the access granularity only allows 4-byte access. If 8-byte access is used, the access granularity is illegal. The determination method of legal access granularity in other cases can be referred to the description here, and examples will not be given one by one.

[0156] When accessing a leaf node, the same method can be used to judge the legality of the access granularity. Please refer to the above instructions for details. In addition, when accessing the corresponding address space in the first-level routing module and the second-level routing module, the steps of judging the legality of the access granularity should generally be performed. The specific judgment method can also adopt the same judgment form, which will not be repeated here.

[0157] In one embodiment of the present invention, the leaf nodes mounted on the secondary routing module are independent of each other, or multiple leaf nodes are configured as broadcast links, wherein:

[0158] Configure a slave device to connect to a leaf node;

[0159] For all leaf nodes in the broadcast link, the request information pre-processed by the master device is sent to each leaf node in a broadcast manner, and the request information pre-processed by the master device is sent to the connected slave device via the leaf node.

[0160] Figure 1 An embodiment of the leaf node group is shown in FIG. As can be seen from the figure, the leaf node can be directly hung on the secondary module. At this time, each leaf node is independent of each other. The leaf node at this time forms a unicast leaf, and the slave device connected to the unicast leaf forms a unicast slave device. In addition, multiple leaf nodes can also be configured with a broadcast link. At this time, each leaf node on the broadcast link forms a broadcast leaf, and the corresponding slave device forms a broadcast slave device. Figure 1 and Fig. 9 An embodiment of configuring multiple leaf nodes to form a broadcast link is shown. It can be understood that the leaf nodes can be configured to form a broadcast link using existing commonly used technical means. The method of configuring to form a broadcast link can be consistent with the existing technology and will not be repeated here.

[0161] It can be understood that when the leaf node is a unicast leaf, the secondary routing module can only send the request information pre-processed by the main device to the designated unicast leaf; when the leaf node is a broadcast leaf, the secondary routing module can send the request information pre-processed by the main device to each leaf node in the broadcast link in the form of broadcast.

[0162] In specific implementation, whether it is a unicast leaf or a broadcast leaf, after receiving the request information pre-processed by the master device, the address space check and verification process should be performed. Only after the address space check and verification process is passed, the request information pre-processed by the master device can be forwarded to the corresponding slave device. The way and process of unicast leaves and broadcast leaves performing address space check and verification can refer to the corresponding description above.

[0163] Figure 8 A processing flow chart of a leaf node requesting information after receiving pre-processing from a master device is shown in FIG. Figure 8In the process, the leaf node receives the request, specifically, it receives the request information after preprocessing by the main device. Figure 8 In the figure, verification pass specifically refers to the verification code verification processing performed by the leaf node. When the verification code verification processing fails, the leaf node should register the exception to the non-error-correctable register in the first-level routing module and generate a verification error response. Thereafter, the generated verification error response is returned to the target main device via the second-level routing module, the first-level routing module, the arbitration module, and the pre-processing module. The situation of generating a verification error response can be referred to the above description and will not be repeated here.

[0164] Since both the primary and secondary routing modules perform address space check processing, the leaf node can omit the address space check processing after receiving the request information pre-processed by the main device. Figure 8 An embodiment in which the address space check processing is not performed in the leaf node is shown. At this time, when the verification is passed, the access to the internal space of the current leaf node is confirmed according to the request address xx2yy_req_addr, that is, whether the current leaf node is selected as the target object. If the current leaf node is selected as the target object, the leaf node responds to the request information pre-processed by the current master device and generates the corresponding target object response information; if the current leaf node is not selected as the target object, the leaf node should send the received request information pre-processed by the master device to the corresponding slave device.

[0165] When forwarding the request information pre-processed by the master device, it is necessary to determine whether the current leaf node is a unicast leaf or a broadcast leaf. If the current leaf node is a unicast leaf, the request information pre-processed by the master device is directly forwarded to the connected slave device; if the current leaf node is a broadcast leaf, the request information pre-processed by the master device is forwarded to the corresponding broadcast slave device in a broadcast form.

[0166] In a specific implementation, when a broadcast link is formed, at least one broadcast leaf is directly connected to the corresponding secondary routing module, wherein the broadcast leaf connected to the secondary routing module can be used as the main broadcast leaf. After receiving the request information pre-processed by the master device, the main broadcast leaf can send the request information pre-processed by the master device to each broadcast leaf in the broadcast link in the form of broadcast, so that the request information pre-processed by the master device is sent to the connected slave device via the broadcast leaf, such as Fig.10 shown.

[0167] Below Fig. 9 and Fig.10 Take the broadcast process as an example. Fig. 9In the figure, leaf node 0 is connected to the secondary routing module, and leaf node 0 is the main broadcast leaf. Specifically, during broadcasting, the secondary routing module will first send the request information after the master device preprocesses to leaf node 0, and then leaf node 0 will forward the request after the master device preprocesses to slave device 0 and leaf node 1 at the same time. Leaf node 1 will send the request information after the master device preprocesses to slave device 1 and leaf node 2 at the same time, and leaf node 2 will forward the request to slave device 2 after receiving the request information after the master device preprocesses. Since leaf node 2 is the last leaf node in the current broadcast chain, after receiving the request information after the master device preprocesses, it only needs to collect the target object response information from slave device 2.

[0168] In one embodiment of the present invention, when the target object is a slave device, the slave device loads the target object response information to the corresponding connected leaf node, and forwards the target object response information to the corresponding preprocessing module via the leaf node, the secondary routing module, the primary routing module and the arbitration module, wherein:

[0169] The preprocessing module verifies the response verification code of the received target object response information. When the verification passes, the target object response information is sent to the connected main device. Otherwise, the response uncorrectable information is written into the first-level routing module, and the abnormal response information is returned to the target main device.

[0170] In specific implementation, when the target object is a slave device, a master device request information initiated by a master device can be forwarded to the slave device serving as the target object via the above-mentioned method. After receiving the request information pre-processed by the master device, the slave device responds and generates target object response information. The response method of the slave device to the request information pre-processed by the master device and the generated target object response information can all be referred to the above-mentioned corresponding instructions and will not be repeated here.

[0171] It can be seen from the above description that the target object response information should be returned to the target main device. Specifically, the target object response information should be forwarded to the corresponding pre-processing module via the leaf node, the secondary routing module, the primary routing module and the arbitration module, wherein the leaf node, the secondary routing module, the primary routing module and the arbitration module only forward the target object response information and do not process the target object response information.

[0172] In order to improve reliability, the present invention uses a preprocessing module to verify the target object response information. Figure 4An embodiment of verification processing performed by the preprocessing module is shown in the figure. In the figure, the response received by the preprocessing module refers to the target object response information. Thereafter, the response type of the target object response information is judged, such as judging whether the response type of the target object response information is a read response or a write response. When the response type of the target object response information is a write response, the target object response information can be directly returned to the target master device.

[0173] In specific implementation, when the arbitration module receives the pre-processed request information of the main device, it will record the pre-processing module that forwards the pre-processing request information of the main device. Thereafter, when the target object response information or the error message response is received, the target object response information or the error message response will be forwarded to the corresponding pre-processing module so as to be returned to the target main device through the pre-processing module.

[0174] When the response type of the target object response information is a read response, the preprocessing module verifies the response data yy2xx_ack_data in the target object response information. When the verification passes, the target object response information is directly returned to the target master device. Otherwise, an error response is sent to the target master device, and an uncorrectable exception is registered in the first-level routing module. It should be noted that after receiving the master device request information, the preprocessing module will record the received master device request information, that is, the preprocessing module can determine the request type of the received master device request information. When the request type of the master device request information is a read request, after receiving the target object response information, the corresponding response data yy2xx_ack_data is verified.

[0175] In one embodiment of the present invention, for any leaf node, after the leaf node forwards the request information pre-processed by the master device to the connected slave device, the leaf node performs timing. When the timing exceeds the preset timeout period and the target object response information of the slave device is not received, the leaf node generates a slave device timeout exception response and writes the response uncorrectable error information into the primary routing module;

[0176] The slave device timeout exception response is sent to the corresponding pre-processing module via the secondary routing module, the primary routing module and the arbitration module, and then sent to the corresponding master device via the pre-processing module.

[0177] In order to avoid the phenomenon that the maintenance bus is stuck due to the failure of the slave device, the timeout mechanism can be configured through the leaf node. Specifically, a timeout setting register can be set in each leaf node. The timeout setting register can be used to set the timeout threshold. When the leaf node receives a valid request message after preprocessing by the master device, the counting starts. When the leaf node receives the target object response message from the slave device, the counting will end immediately. During the counting process, the counting time corresponding to the count value is compared with the timeout threshold. When the counting time corresponding to the count value reaches the timeout threshold, it is a timeout. Generally, when the counting time corresponding to the count value reaches the timeout threshold, the count value will be cleared.

[0178] When the counting time corresponding to the counting value reaches the timeout threshold, and the target object response information of the slave device is not received, it is considered that the slave device is damaged and can no longer receive the target object response information. After that, the leaf node will generate a slave device timeout exception response. The generated slave device timeout exception response should be consistent with the above-mentioned target object response information. Specifically, the type of the current target master device response information returned is identified by the response exception identification signal ack_excp, which is a timeout exception response; at the same time, the timeout exception will be registered in the first-level routing module, and the slave device timeout exception response will be gradually transmitted to the target master device. After receiving the slave device timeout exception response, the target master device can determine the specific situation of the slave device timeout exception response by tracing the slave device timeout exception response.

[0179] Fig.11 A schematic diagram of the coordination between the secondary routing module, the unicast leaf and the corresponding slave device for the timeout situation is shown in the figure. In the figure, when the target object response information of the slave device is not received within the time of the timeout threshold, the leaf node will generate a slave device exception response information, and the type of the slave device exception response information is a timeout exception.

[0180] Fig.12 A schematic diagram of an embodiment of the cooperation between the secondary routing module and the broadcast link is shown in the figure. At this time, each broadcast leaf has a timeout setting register and a corresponding timeout threshold is set. Each broadcast leaf counts independently to determine whether the target object response information returned by the connected slave device is in a timeout state. Fig.12 In the example, when slave device 2 does not return the target object response information within the timeout threshold, the timing of leaf node 2 reaches the timeout threshold. At this time, leaf node 2 can directly return a timeout exception response to leaf node 1. Leaf node 1 needs to collect the timeout exception response of leaf node 2 and the target object response information returned from device 1, and then forward the collected timeout exception response and the corresponding target object response information to leaf node 0, and leaf node 0 will also receive the target object response information from device 0.

[0181] It should be noted that, since slave device 2 did not return the target object response information within the timeout threshold, the response information received by leaf node 0 has at least one slave device timeout exception response. At this time, leaf node 0 sends a slave device timeout exception response to the secondary routing module. Leaf node 0 sends the target object response information to the secondary routing module only when and only when all slave devices have no timeout response.

[0182] Specifically, for the broadcast link, the master device request information initiated by the master device should generally be a write request. At this time, if the target object response information returned from the slave device does not time out, the target object response information in the broadcast link should be the same. At this time, leaf node 0 can send any target object response information to the secondary routing module.

[0183] It can be seen from the above description that when a leaf device generates a slave device timeout exception response, the slave device timeout exception response can be consistent with the target object response information. For details, please refer to the description of the above target object response information. It should be noted that for the error responses generated by the preprocessing module, the first-level routing module, the second-level routing module and the leaf node, the error response can be returned to the target master device via the preprocessing module.

Claims

1. A high-performance and high-reliability maintenance bus, characterized in that: Used to connect a master device group and a slave device group, wherein the master device group includes a number of master devices, and the slave device group includes a number of slave devices, For a master device request information initiated by any master device in the master device unit group, the master device request information is sent to the target object via the maintenance bus, and the target object response information generated by the target object is returned to the target master device, wherein: The target object includes a slave device in a slave device group or an address space unit in the maintenance bus, wherein when the target object is a slave device in a slave device group, a master device request is sent from the maintenance bus to the target object via one clock cycle of the maintenance bus, and a target object response information is returned from the target object to the maintenance bus via one clock cycle; The master device request information and the target object response information are generated based on the maintenance bus protocol, where: At least request data xx2yy_req_data is configured in the master device request information, and at least response data yy2xx_ack_data is configured in the target object response information. The data bit width of the request data xx2yy_req_data in the master device request information and the data bit width of the response data yy2xx_ack_data in the target object response information are both not less than 32 bits, so that the master device can access the slave device with a data bit width of not less than 32 bits via the maintenance bus.

2. The high performance and high reliability maintenance bus according to claim 1 is characterized in that: When the master device request information is generated based on the maintenance bus protocol, the master device request information also includes a request valid identification signal xx2yy_req_valid, a request address xx2yy_req_addr, a request write granularity status signal xx2yy_req_strb, a request type signal xx2yy_req_type, and a request read granularity status signal xx2yy_req_rsize; The target object response information also includes a response valid identification signal yy2xx_ack_valid and a response abnormal identification signal yy2xx_ack_excp; The maintenance bus protocol is a serial protocol, in which For any master device request information, when the request valid identification signal xx2yy_req_valid in the master device request information is in a valid state, the request address xx2yy_req_addr, request data xx2yy_req_data, request write granularity status signal xx2yy_req_strb and request read granularity status signal xx2yy_req_rsize in the master device request information are maintained until the response valid identification signal yy2xx_ack_valid corresponding to the current master device request information is valid; For any target object response information, when the response valid identification signal yy2xx_ack_valid in the target object response information is in a valid state, the response data yy2xx_ack_data and the response exception identification signal yy2xx_ack_excp are maintained until the request valid identification signal xx2yy_req_valid in the next master device request information is in a valid state.

3. The high performance and high reliability maintenance bus according to claim 2 is characterized in that: The maintenance bus comprises: A preprocessing module group, including several preprocessing modules, uses a preprocessing module to adapt and connect with a master device, at least preprocesses the master device request information initiated by the connected master device, and forwards the master device preprocessed request information generated by the preprocessing to the arbitration module, and returns the target object response information to the connected master device; An arbitration module, adapted and connected to the preprocessing module group and the primary routing module, for arbitrating the preprocessed request information of the master device forwarded by the preprocessing module group, and forwarding the arbitrated preprocessed request information of the master device to the primary routing module; The primary routing module is connected to one or more secondary routing modules, and at least forwards the request information pre-processed by the main device to the corresponding secondary routing module, wherein: One or more leaf nodes are mounted on each secondary routing module, and the leaf nodes are used to connect the slave devices. The secondary routing module at least routes and forwards the pre-processed request information received from the master device to one leaf node, so that the pre-processed request information of the master device can be forwarded to the corresponding connected slave device via the leaf node; A first-level routing register group for recording abnormal status is set in the first-level routing module. When the target object is an address space unit in the maintenance bus, a leaf node, a secondary routing module or a primary routing module is configured as the address space unit.

4. The high performance and high reliability maintenance bus according to claim 3 is characterized in that: The preprocessing module preprocesses the request information of the main device, including request content inspection processing and request verification code generation processing, where: First, the received master device request information is checked for content. When the request content check process is passed, the preprocessing module performs request verification code generation processing on the master device request information, and generates the master device preprocessed request information after the request verification code generation processing; The first-level routing module, the second-level routing module and the leaf node all perform address space check and verification processing on the pre-processed request information received from the main device, where: When the target object is a slave device, the first-level routing module, the second-level routing module and the leaf node are configured to perform address space check and verification processing on the request information pre-processed by the master device in turn, and when all address space check and verification processes are passed, the request information pre-processed by the master device is sent to the slave device as the target object through the corresponding leaf node.

5. The high performance and high reliability maintenance bus according to claim 3 is characterized in that: When performing a request content check on the master device request information, the preprocessing module at least performs a request granularity legalization check and / or a request address granularity boundary check on the master device request information, wherein: When performing a request granularity legalization check on the master device request information, check the write request granularity corresponding to the request write granularity status signal xx2yy_req_strb to determine whether the write request granularity of the master device request information is a legal request granularity or an illegal request granularity; When performing a request address granularity boundary check on the master device request information, the address granularity boundary state of the request address xx2yy_req_addr is checked based on the request granularity corresponding to the master device request information to determine whether the address granularity boundary state of the master device request information is an illegal boundary state or a legal boundary state; When the write request granularity is a legal request granularity and the address granularity boundary state is a legal boundary state, the preprocessing module preprocesses the master device request information, wherein the request verification code generation processing of the master device request information at least includes generating a request verification code based on the master device request information; Based on the master device request information and the request verification code, the master device pre-processed request information is generated.

6. The high performance and high reliability maintenance bus according to claim 5 is characterized in that: When performing the address space check and verification process, it includes sequentially performing the check code verification process and the address space check process, wherein: When performing the check code verification process, at least the request check code in the request information pre-processed by the master device is verified, and when the verification passes, the address space check process is performed on the request information pre-processed by the master device; When performing address space check processing, at least the request address xx2yy_req_addr in the request information preprocessed by the master device is judged as a hole address. When the request address xx2yy_req_addr is a non-hole address, the request information preprocessed by the master device is sent to the target object based on the request address xx2yy_req_addr.

7. The high performance and high reliability maintenance bus according to claim 4 is characterized in that: When configuring the primary routing module, secondary routing module, and leaf node to perform address space check and verification processing on the request information after preprocessing by the main device in turn, there are: When the primary routing module performs the address space check and verification process and passes it, the secondary routing module will perform the address space check and verification process; When the secondary routing module passes the address space check and verification process, the leaf node will perform the address space check and verification process; When any address space check and verification process fails, the corresponding address space check and verification exception information is written into the first-level routing module, and the exception response information is returned to the target master device.

8. The high performance and high reliability maintenance bus according to claim 5 is characterized in that: The leaf nodes mounted on the secondary routing module are independent of each other, or multiple leaf nodes are configured as broadcast links, where: Configure a slave device to connect to a leaf node; For all leaf nodes in the broadcast link, the request information pre-processed by the master device is sent to each leaf node in a broadcast manner, and the request information pre-processed by the master device is sent to the connected slave device via the leaf node.

9. The high performance and high reliability maintenance bus according to any one of claims 5 to 8, characterized in that: When the target object is a slave device, the slave device loads the target object response information to the corresponding connected leaf node, and forwards the target object response information to the corresponding preprocessing module via the leaf node, the secondary routing module, the primary routing module and the arbitration module, wherein: The preprocessing module verifies the response verification code of the received target object response information. When the verification passes, the target object response information is sent to the connected main device. Otherwise, the response uncorrectable information is written into the first-level routing module, and the abnormal response information is returned to the target main device.

10. The high performance and high reliability maintenance bus according to any one of claims 3 to 8, characterized in that: For any leaf node, after the leaf node forwards the request information pre-processed by the master device to the connected slave device, the leaf node starts timing. When the timing exceeds the preset timeout period and the target object response information of the slave device is not received, the leaf node generates a slave device timeout exception response and writes the response uncorrectable error information into the primary routing module; The slave device timeout exception response is sent to the corresponding pre-processing module via the secondary routing module, the primary routing module and the arbitration module, and then sent to the corresponding master device via the pre-processing module.

Images