CN112083977A

CN112083977A - Error processing method of transmission interface and related error processing architecture

Info

Publication number: CN112083977A
Application number: CN201910505253.7A
Authority: CN
Inventors: 萧丞渊; 刘松高; 简怡婷; 庄威宏; 许志宇
Original assignee: Realtek Semiconductor Corp
Current assignee: Realtek Semiconductor Corp
Priority date: 2019-06-12
Filing date: 2019-06-12
Publication date: 2020-12-15

Abstract

An error handling method for a transport interface and related error handling architecture, wherein a connection type between the transport interface and a first device is a direct interface, and a connection type between the transport interface and a second device is an indirect interface, the error handling method comprising: when detecting that an error occurs in the direct interface, reporting an error event to a main control end of the first device; when detecting that an error occurs in the indirect interface connection, attempting to directly process the error without letting the master control end know the error; and if the error cannot be processed, reporting another error event to the master control end.

Description

Error processing method of transmission interface and related error processing architecture

Technical Field

The present invention relates to transmission among multiple devices, and more particularly, to an error handling method for a transmission interface.

Background

Based on convenience and practicability, more and more products have been produced to integrate two or more high-speed interfaces, such as Universal Serial Bus (USB) to Peripheral Component Interconnect Express (PCIE), USB to Serial Advanced Technology Attachment (SATA), and PCIE device to PCIE host, and the transmission between these high-speed interfaces is implemented by a control circuit capable of being compatible with and converting two different interfaces. When an Error occurs, although these different interfaces have respective Error Recovery mechanisms (Error Recovery mechanisms), there is no clear way to integrate the different Error Recovery mechanisms, so that the master (instruction master) (or upper layer, host) can understand it. Therefore, the user is often inconvenienced by program jamming or overtime due to lack of a proper debugging mechanism or reporting mechanism.

In summary, the interface transmission products of the present invention lack a good error recovery mechanism to integrate two or more high-speed interfaces in a single product, and therefore, there is a need for a novel error recovery mechanism to properly solve the above-mentioned problems.

Disclosure of Invention

It is an object of the present invention to provide a recovery mechanism at high speed interfaces to solve the problems encountered in the prior art without causing side effects.

One of the objectives of the present invention is to provide a recovery mechanism for high-speed interface, which can recover the high-speed interface to a normal state when an error occurs during transmission, and thus, a dead lock (dead lock) situation will not occur.

An embodiment of the present invention provides an error handling method for a transmission interface, where the transmission interface is used to connect a first device and a second device for data transmission between the first device and the second device, where a connection type between the first device and the transmission interface is a Direct Interface (DI), and a connection type between the second device and the transmission interface is an Indirect Interface (II), the error handling method comprising: when detecting that an error occurs in the direct interface, reporting an error event to a main control end of the first device; when detecting that an error occurs in the indirect interface, attempting to directly process the error without letting the master control end know the error; and if the error cannot be processed, reporting another error event to the master control end.

An embodiment of the invention provides an error handling architecture, which includes a first device, a second device and a transmission interface. The first device includes a first command interface and the second device includes a second command interface. The transmission interface is used for connecting the first device and the second device to perform data transmission between the first device and the second device, and comprises a controller, a third instruction interface and a fourth instruction interface. The transmission interface is used for connecting the first device and the second device to perform data transmission between the first device and the second device, wherein the third command interface is used for connecting the first command interface to form a Direct Interface (DI), and the fourth command interface is used for connecting the second command interface to form an Indirect Interface (II). When the controller detects that an error occurs in the direct interface, an error event is reported to a main control end of the first device; when the controller detects that an error occurs in the indirect interface, the controller tries to directly process the error under the condition that the main control end does not know the error; if the controller determines that the error cannot be handled, another error event is reported to the host.

Drawings

Fig. 1 is a schematic diagram of a high-speed interface adapter according to an embodiment of the invention.

Fig. 2 is a schematic diagram of an architecture for performing transmission between USB and PCIE according to an embodiment of the present invention.

FIG. 3 is a flowchart illustrating an error handling method for a transport interface according to an embodiment of the invention.

Description of the symbols

100 high-speed interface switching structure

10. 20, 10 ', 20' device

30. 30' instruction conversion unit

12. 22, 32, 33 instruction interface

14. 24, 34 controller

300 error handling method

301 to 314 steps

Detailed Description

Certain terms are used throughout the description and following claims to refer to particular components. As one skilled in the art will appreciate, manufacturers may refer to a component by different names. The present specification and claims do not intend to distinguish between components that differ in name but not function. In the following description and in the claims, the terms "include" and "comprise" are used in an open-ended fashion, and thus should be interpreted to mean "include, but not limited to. Additionally, the term "coupled" is used herein to encompass any direct or indirect electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections.

Referring to fig. 1, fig. 1 is a schematic diagram of a high-speed interface switching architecture 100 according to an embodiment of the present invention, as shown in fig. 1, a device 10 and a device 20 are connected through a Command Conversion Unit (CCU) 30, where the command conversion unit 30 is used as a direct interface for directly receiving a command. The transmission between the instruction Interface 12 of the device 10 and the instruction Interface 32 of the instruction converting unit 30 is called Direct Interface (DI), and the transmission between the instruction Interface 22 of the device 20 and the instruction Interface 33 of the instruction converting unit 30 is called Indirect Interface (II). In addition, the

devices

10, 20 contain

controllers

14, 24, respectively, to perform basic processing.

For better understanding, the device 10 may be a USB device, and the device 20 may be a PCIE device, such as a hard drive (hard drive), a Solid State Drive (SSD), etc. In the prior art, when the transmission between the command conversion unit 30 and the PCIE port is abnormal, since a master (command master) (not shown) of the USB can only detect the state of the USB port, it is impossible to know that the PCIE port is abnormal, and under the condition that the master simply determines that the USB port has no error, it is also unknown how to eliminate the abnormality, so that the program is blocked or overtime due to lack of a proper debug mechanism or a proper report mechanism, which causes great inconvenience to the user. Note that the host can also be understood as an upper layer device or a host (host).

The error recovery mechanism of the present invention can be distinguished into the following two cases:

A. when the abnormality is sent to the direct interface, the abnormality is immediately reported to the main control end of the USB, and the main control end processes the error.

B. When an error occurs in the indirect interface, the instruction conversion unit 30 is responsible for handling the error, and the problem is solved by the instruction conversion unit 30 as much as possible without letting the master find the error. If the command conversion unit 30 cannot handle the problem, the indirect interface generates error information and provides the error information to the direct interface, and the direct interface is responsible for reporting the error information to the main control end, and the main control end handles the error.

For example, in fig. 1, it is assumed that the host on the device 10 sends an instruction to the instruction converting unit 30 through the direct interface, and the direct interface directly reports an error after receiving the instruction, and the host processes the error.

In another example, assuming that the master on the device 10 can send the command to the command conversion unit 30 through the direct interface, the direct interface does not find any error after receiving the command, and then when the command conversion unit 30 sends the command to the indirect interface, and the master (not shown) on the device 20 finds an error and reports back to the indirect interface, the command conversion unit controls the direct interface to not cause the master on the device 10 to feel any problem (for example, report a normal status back to the master), and the indirect interface also repairs the error according to the specification of the command interface 22 on the device 20. Assuming that the indirect interface problem can be solved by the command conversion unit and the command interface 22 on the device 20, the direct interface is responsible for reporting a normal status to the master on the device 10. If the problem of the indirect interface cannot be solved by the command conversion unit and the command interface 22 on the device 20, the indirect interface generates an error state and is transmitted to the master on the device 10 by the direct interface.

Referring to fig. 2, fig. 2 is a schematic diagram of an architecture 200 for USB and PCIE transmission according to an embodiment of the present invention, in which the command conversion unit 30 ' serves as a bridge between the USB device 10 ' and the PCIE device 20 ', and the PCIE device 20 ' may be an SSD (hereinafter, the PCIE device 20 ' is directly referred to as the SSD). The host (hereinafter referred to as USB host) of the USB device 10 ' communicates with the command conversion unit 30 ' (hereinafter referred to as bridge) via the BOT/UASP, and the command conversion unit 30 ' communicates with the SSD via the NVMe/AHCI.

When the USB main control end sends a SCSI instruction to the SSD, the SCSI instruction is packaged into a USB instruction through UASP/BOT and then is transmitted to a USB end (namely a direct interface) of the bridge, the USB end firstly confirms whether the instruction accords with UASP/BOT specification after receiving the instruction, and if an error is found, an error state is sent to the USB main control end according to the UASP/BOT specification; if the command conforms to the UASP/BOT specification, the command is packaged into a PCIE command by an indirect interface on the bridge according to the NVMe/AHCI specification and is transmitted to the SSD, if the SSD has an error, an error state is sent to the indirect interface, and the error recovery is carried out by the indirect interface according to the NVMe/AHCI specification after the indirect interface receives the error. At this time, the bridge needs to let the direct interface continuously make the USB host consider that no error occurs, after the indirect interface can process the error according to the NVMe/AHCI specification, the direct interface returns a correct status to the USB host, if the indirect interface cannot process the error, the indirect interface provides an error status to the bridge, and the bridge returns the error status to the USB host through the direct interface and makes the USB host process the error.

In the embodiments of fig. 1 and fig. 2, the possible errors and the corresponding processing methods are as follows (but not limited thereto):

first, Device not ready (Device not ready): this condition indicates that the device is busy and unable to process instructions as follows:

1. if the error occurs in the direct interface, the device must directly report the error status to the host, so that the host knows that the device is in an unprepared state.

2. If the action occurs in the indirect interface, the action can maintain the normal operation of the main control end by waiting for a period of time under the condition that the indirect interface does not influence the direct interface until the action can be normally operated.

3. If the error occurs in the indirect interface and the indirect interface cannot be solved even if the indirect interface waits, an error state is reported to the master control end, so that the master control end knows that the device is in a state that the device is not ready at present.

Secondly, the instruction content received by the device has errors (format has errors), and the processing mode is as follows:

1. if the error occurs in the direct interface, the direct interface should inform the main control end of the device which command part has an error.

2. If the command is generated in the indirect interface, the indirect interface should inform the main control end of the device which command part has an error.

Thirdly, the unsupported instruction is processed in the following way:

1. if the command occurs on the direct interface, the direct interface should inform the host of the device that the command is not supported.

2. If the command occurs in the indirect interface, the indirect interface should inform the main control end of the device that the command is not supported.

3. As long as any interface (i.e. either direct interface or indirect interface) does not support the command, the device must inform the host that the command is not supported.

Fourth, instruction interrupted (Aborted): the device interrupts the instruction due to the reason that the instruction is processed on the Power end (Power), and the processing mode is as follows:

1. if the command occurs in the direct interface, the direct interface must inform the master of the device that the command is interrupted.

2. If the indirect interface occurs, the indirect interface must perform corresponding processing, such as Retry (Retry), without affecting the direct interface.

3. If the command is interrupted, the main control end of the device is informed through the direct interface.

Fifthly, the device fails to respond, for example, the device is stuck (dead), and the processing method is as follows:

1. if it happens on the direct interface, it must rely on the driver of the master to recover because it cannot respond.

2. If the interface occurs in the indirect interface, the indirect interface must perform corresponding processing, such as restarting (Reset), without affecting the direct interface.

3. If the situation occurs in the indirect interface and the indirect interface cannot handle the state, the direct interface must inform the master of the device that the device cannot respond.

Referring to fig. 3, fig. 3 is a flowchart illustrating an error handling method 300 for a transport interface according to an embodiment of the invention. It should be noted that the steps are not necessarily performed in the order shown in fig. 3, for example, new steps may be inserted and some steps may be removed from the current flow if substantially the same result is obtained. The method shown in FIG. 3 can be adopted by the high-speed interface adapter architecture 100 shown in FIG. 1, and can be briefly summarized as follows:

step 301: starting;

step 302: detecting whether an error occurs in the direct interface and the indirect interface, and jumping to step 304 if the error occurs in the direct interface; if the indirect interface is faulty, go to step 306: if no error exists, go to step 314;

step 304: directly reporting the error occurrence of the master control end by the direct interface, and jumping to step 312;

step 306: processing the error under the condition that the direct interface assists and the main control end does not find the error, judging whether the indirect interface can solve the error, and if so, jumping to the step 308; if not, jumping to step 310;

step 308: after the error processing is completed, returning the normal status to the master control end, and jumping to step 314;

step 310: the indirect interface provides an error state to the direct interface, and the direct interface reports the error state back to the main control end;

step 312: the main control end provides a corresponding repair scheme aiming at the error state so as to eliminate the problem;

step 314: and (6) ending.

Since the details of each step in fig. 3 should be easily understood by those skilled in the art after reading the above paragraphs, further description will be omitted here for the sake of brevity.

In summary, the present invention aims to improve the error recovery mechanism of the high-speed switching interface and enable the indirect interface to deal with the problem by itself without being discovered by the master. However, in the case that the capability of the indirect interface is not enough to handle the problem, the indirect interface still reports the status back to the direct interface, and the direct interface further reports the status back to the master, so as to prevent the master from recognizing that the indirect interface is in the normal transmission stage, but actually the indirect interface cannot receive the data.

The above-mentioned embodiments are only preferred embodiments of the present invention, and all equivalent changes and modifications made by the claims of the present invention should be covered by the scope of the present invention.

Claims

1. An error handling method for a transmission interface, the transmission interface being used to connect a first device and a second device for data transmission between the first device and the second device, wherein the connection between the first device and the transmission interface is a direct interface, and the connection between the second device and the transmission interface is an indirect interface, the error handling method comprising:

when detecting that an error occurs in the direct interface, reporting an error event to a main control end of the first device;

when detecting that an error occurs in the indirect interface connection, attempting to directly process the error without letting the master control end know the error; and

if it is determined that the error cannot be handled, another error event is reported to the host.

2. The error handling method of claim 1, wherein the direct interface assists the indirect interface in handling errors without being discovered by the master.

3. The error handling method of claim 2, wherein the direct interface keeps the host considering that no error has occurred, and the direct interface reports a correct status to the host after the indirect interface has handled the error.

4. The error handling method of claim 3, wherein if the indirect interface cannot handle an error while the direct interface is assisting the indirect interface, the direct interface reports the another error event to the host.

5. The error handling method of claim 1, wherein the first device is a USB device and the second device is a hard disk device.

6. The error handling method of claim 5, wherein the direct interface is transmitted via BOT/UASP and the indirect interface is transmitted via NVMe/AHCI.

7. The method of claim 1, wherein the error event and the another error event comprise at least one of:

device not ready, wrong command content, unsupported command, command interrupted, device not responding.

8. An error handling architecture, comprising:

a first device including a first command interface (12);

a second device including a second instruction interface (22); and

a transmission interface for connecting the first device and the second device to perform data transmission between the first device and the second device, comprising a controller, a third command interface (32) and a fourth command interface (33), wherein the third command interface is used for connecting the first command interface to form a direct interface, and the fourth command interface is used for connecting the second command interface to form an indirect interface; when the controller detects that an error occurs in the direct interface, an error event is reported to a main control end of the first device; when the controller detects that an error occurs in the indirect interface connection, the controller tries to directly process the error under the condition that the main control end does not know the error; if the controller determines that the error cannot be handled, another error event is reported to the host.

9. The error handling architecture of claim 8, wherein the controller controls the direct interface to assist the indirect interface in handling errors without being discovered by the master.

10. The error handling architecture of claim 9, wherein the controller controls the direct interface to let the host consider no error occurred, and the direct interface returns a correct status to the host after the indirect interface has processed the error, and the direct interface returns the other error event to the host if the indirect interface cannot process the error.