A signal bridge and electronic device

Abstract

The application provides a signal bridge and an electronic device. The signal bridge comprises a PIPE4.0 signal detection module configured to detect whether a signal in a PIPE4.0 interface device changes; and a PIPE4.0 signal encoding module configured to, when the PIPE4.0 signal detection module detects that any signal in the PIPE4.0 interface device changes, determine the number of encoding instructions required by the changed signal, encode the changed signal according to the number of encoding instructions, obtain a PIPE5.0 signal meeting a PIPE5.0 specification, and transmit the PIPE5.0 signal to a PIPE5.0 interface device. In this way, the conversion of the signal from the PIPE4.0 signal to the PIPE5.0 signal is realized, and the normal signal interaction between the PIPE4.0 interface device and the PIPE5.0 interface device is realized to a certain extent.

Description

Technical Field

[0001] This application relates to the field of PCIE (PCI-Express, high-speed interface) technology, and more specifically, to a signal bridge and electronic device. Background Technology

[0002] With the continuous development of PCIe, its data transfer speed has increased from 16GT / s to 32GT / s. At such high speeds, the large number of signal lines inevitably leads to crosstalk.

[0003] To address crosstalk issues and reduce the number of pins, the PIPE 5.0 (PHY Interface for the PCI Express 5.0) interface protocol was introduced. The PIPE 5.0 protocol converts signals with less stringent timing requirements from the original PIPE 4.0 into registers for the MAC (Media Access Layer) and PCS (Physical Coding Sublayer), significantly reducing the number of PIPE interface signal lines.

[0004] However, in practical applications, the NVMe PCS device used by the EMU (Emulator) department for simulation often only supports the PIPE5.0 interface, while the MAC layer of the chip under test only supports PIPE4.0 signal lines. This results in a mismatch between the protocol versions supported by the PCS and MAC ends, making it impossible to train to L0 and thus impossible to verify the chip. Summary of the Invention

[0005] The purpose of this application is to provide a signal bridge and electronic device to enable normal signal interaction between PIPE4.0 interface devices and PIPE5.0 interface devices.

[0006] This application provides a signal bridge, including:

[0007] The PIPE4.0 signal detection module is used to detect whether the signal in the PIPE4.0 interface device has changed.

[0008] The PIPE4.0 signal encoding module is used to determine the number of encoding instructions required for the changed PIPE4.0 signal when the PIPE4.0 signal detection module detects a change in any signal in the PIPE4.0 interface device, and to encode the changed PIPE4.0 signal according to the number of encoding instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification, and to transmit the PIPE5.0 signal to the PIPE5.0 interface device.

[0009] In the above implementation, when the PIPE4.0 signal detection module detects a change in the signal of the PIPE4.0 interface device, the PIPE4.0 signal encoding module encodes the changed PIPE4.0 signal according to the number of encoding instructions required for the changed PIPE4.0 signal, obtaining a PIPE5.0 signal that meets the PIPE5.0 specification. This PIPE5.0 signal is then transmitted to the PIPE5.0 interface device. This achieves the conversion of signals from PIPE4.0 to PIPE5.0, enabling the PIPE5.0 interface device to effectively recognize signals emitted by the PIPE4.0 interface device, thus realizing normal signal interaction between the PIPE4.0 and PIPE5.0 interface devices to a certain extent.

[0010] Furthermore, the PIPE4.0 signal encoding module is specifically used to: determine the number of encoding instructions required for the changed PIPE4.0 signal based on the type of the changed PIPE4.0 signal; if the changed PIPE4.0 signal requires two encoding instructions, then the changed PIPE4.0 signal is encoded into two consecutive instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification; if the changed PIPE4.0 signal requires three encoding instructions, then the changed PIPE4.0 signal is encoded into three consecutive instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification; wherein each instruction contains three parts: instruction type, address, and data content.

[0011] In the above implementation, by determining the type of the changed PIPE4.0 signal, the number of encoding instructions required for the changed PIPE4.0 signal can be quickly determined, and then encoding can be performed accordingly. This allows the signal to be quickly converted into a PIPE5.0 signal that conforms to the PIPE5.0 specification, thus improving the reliability of the solution.

[0012] Furthermore, the PIPE4.0 signal detection module is also configured to generate a first flag bit information and send the first flag bit information to the PIPE4.0 signal encoding module when a change in any signal in the PIPE4.0 interface device is detected; the PIPE4.0 signal encoding module is specifically configured to, after receiving the first flag bit information, determine the number of encoding instructions required for the changed PIPE4.0 signal, encode the changed PIPE4.0 signal according to the number of encoding instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification, transmit the PIPE5.0 signal to the PIPE5.0 interface device, and clear the first flag bit information.

[0013] In the above implementation process, the PIPE4.0 signal detection module generates the first flag information, which triggers the PIPE4.0 signal encoding module to work. This means that the PIPE4.0 signal encoding module will only perform encoding work after being triggered, thus eliminating the need for it to remain in a working state continuously, which can effectively reduce the power consumption of the PIPE4.0 signal encoding module.

[0014] Furthermore, the signal bridge also includes: a PIPE5.0 signal detection module, used to detect whether the PIPE5.0 interface device is sending a signal; and a PIPE5.0 signal decoding module, used to, when the PIPE5.0 signal detection module detects that the PIPE5.0 interface device is sending a signal, if the signal sent by the PIPE5.0 interface device is a PIPE5.0 signal to be transmitted to the PIPE4.0 interface device, obtain the address and data of the PIPE5.0 signal, and map the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address.

[0015] In the above implementation, the PIPE5.0 signal detection module detects whether the PIPE5.0 interface device is sending a signal. When the detection module detects that there is a PIPE5.0 signal that needs to be transmitted to the PIPE4.0 interface device, the PIPE5.0 signal decoding module obtains the address and data of the PIPE5.0 signal, performs decoding, and then maps the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address.

[0016] Furthermore, the PIPE5.0 signal decoding module is also used to determine the validity of the address before mapping the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address after obtaining the address and data of the PIPE5.0 signal.

[0017] In the above implementation, by first determining whether the address is valid, and only performing mapping after it is valid, the security of data transmission can be guaranteed, and erroneous data can be avoided from being transmitted, thus affecting the verification reliability of the chip.

[0018] Furthermore, the PIPE5.0 signal decoding module is specifically used to: obtain whether the current instruction of the PIPE5.0 signal is a terminating instruction that indicates the end of the instruction string; if not, store the address and data in the current instruction, and continue to obtain the next instruction of the PIPE5.0 signal; if yes, store the address and data in the current instruction, and map all the addresses and data corresponding to the stored PIPE5.0 signal to the PIPE4.0 signal line.

[0019] The above implementation method can decode a complete signal and map it to the corresponding PIPE4.0 signal line, thereby ensuring that the PIPE4.0 interface device can receive the complete signal content at one time, which facilitates data processing.

[0020] Furthermore, the PIPE5.0 signal decoding module is also configured to send the completion signal to the PIPE4.0 signal encoding module if the signal sent by the PIPE5.0 interface device is a completion signal; the PIPE4.0 signal encoding module is also configured to end the current encoding when it receives the completion signal sent by the PIPE5.0 signal decoding module.

[0021] In the above implementation process, the PIPE5.0 interface device sending a completion signal indicates that the PIPE5.0 interface device has successfully received the PIPE5.0 signal from the signal bridge. The PIPE4.0 signal encoding module then ends the current encoding based on this completion signal, thus ensuring that subsequent signals from the PIPE4.0 interface device can be encoded continuously, ensuring that signal encoding and processing can continue.

[0022] Furthermore, the PIPE5.0 signal detection module is also used to generate second flag information and send the second flag information to the PIPE5.0 signal decoding module when detecting the PIPE5.0 signal sent by the PIPE5.0 interface device to be transmitted to the PIPE4.0 interface device;

[0023] The PIPE5.0 signal decoding module is specifically used to obtain the address and data of the PIPE5.0 signal after receiving the second flag information, map the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address, and clear the second flag information.

[0024] In the above implementation process, the PIPE5.0 signal detection module generates the second flag information, which in turn triggers the PIPE5.0 signal decoding module to work. This ensures that the PIPE5.0 signal decoding module only starts working after being triggered, without having to maintain a working state continuously, which can effectively reduce the power consumption of the PIPE5.0 signal decoding module.

[0025] Furthermore, the PIPE4.0 signal detection module, the PIPE4.0 signal encoding module, the PIPE5.0 signal detection module, and the PIPE5.0 signal decoding module are all written in a synthesizable hardware language.

[0026] In the above implementation process, each module is written in a synthesizable hardware language, which enables each module to synthesize real logic gate circuits and be programmed into the Emulator (hardware acceleration device), thereby ensuring the normal progress of chip verification.

[0027] This application also provides an electronic device, which has each module of any of the aforementioned signal bridges programmed into it to realize the function of the signal bridge. Attached Figure Description

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

[0029] Figure 1 This is a schematic diagram of the basic structure of a signal bridge provided in an embodiment of this application;

[0030] Figure 2 A more specific structural diagram of a signal bridge is provided for an embodiment of this application;

[0031] Figure 3 A schematic diagram of the connection structure between a signal bridge and the MAC layer and the PCS layer provided in this application embodiment;

[0032] Figure 4 A schematic diagram of an encoding process provided in an embodiment of this application;

[0033] Figure 5 This is a schematic diagram of a decoding process provided for an embodiment of this application. Detailed Implementation

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

[0035] Example 1:

[0036] To enable normal signal interaction between PIPE4.0 interface devices and PIPE5.0 interface devices, this application provides a signal bridge in its embodiments. See also... Figure 1 As shown, Figure 1 This is a basic schematic diagram of the signal bridge provided in the embodiments of this application, including: a PIPE4.0 signal detection module and a PIPE4.0 signal encoding module.

[0037] It should be understood that, in this embodiment, the signal bridge is used between the PIPE4.0 interface device and the PIPE5.0 interface device. Wherein:

[0038] The PIPE4.0 signal detection module is connected to each PIPE4.0 signal line in the PIPE4.0 interface device and is used to detect whether the signal in the PIPE4.0 interface device has changed.

[0039] The PIPE4.0 signal encoding module is used to determine the number of encoding instructions required for the changed PIPE4.0 signal when the PIPE4.0 signal detection module detects a change in any signal in the PIPE4.0 interface device. Then, it encodes the changed PIPE4.0 signal according to the number of encoding instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification, and transmits the PIPE5.0 signal to the PIPE5.0 interface device.

[0040] It should be understood that, in the embodiments of this application, the PIPE4.0 signal encoding module can determine the number of encoding instructions required for the changed PIPE4.0 signal based on the type of the changed PIPE4.0 signal.

[0041] It should be understood that in practical applications, the type of PIPE4.0 signal is fixed, and the number of encoding instructions required to convert different types into PIPE5.0 signals is also fixed. Therefore, in this embodiment, the number of encoding instructions corresponding to each PIPE4.0 signal type can be pre-configured in the PIPE4.0 signal encoding module, so as to determine the number of encoding instructions required for the changed PIPE4.0 signal according to the type of the changed PIPE4.0 signal.

[0042] The PIPE4.0 signal detection module connects to each PIPE4.0 signal line of the PIPE4.0 interface device. Different PIPE4.0 signal lines are used to emit different types of PIPE4.0 signals. Therefore, the PIPE4.0 signal detection module can know the type of the signal that has changed based on the PIPE4.0 signal line where the detected signal has changed.

[0043] In practical applications, the number of encoding instructions required for a PIPE4.0 signal can be either two or three. During encoding, if the modified PIPE4.0 signal requires two encoding instructions, the PIPE4.0 signal encoding module can encode the modified PIPE4.0 signal into two consecutive instructions, resulting in a PIPE5.0 signal that meets the PIPE5.0 specification. If the modified PIPE4.0 signal requires three encoding instructions, the PIPE4.0 signal encoding module can encode the modified PIPE4.0 signal into three consecutive instructions, resulting in a PIPE5.0 signal that meets the PIPE5.0 specification.

[0044] It should be understood that each instruction can have three parts: instruction type, address, and data content. Among them, the instruction type includes continuation instructions that indicate that the instruction string (i.e., a continuous instruction consisting of multiple instructions representing a signal) has not ended, and terminating instructions that indicate the end of the instruction string.

[0045] For example, a continuation instruction can be represented as a "write_uncomitted" instruction, and a termination instruction can be represented as a "write_committed" instruction. Therefore, a PIPE4.0 signal requiring two encoding instructions can be encoded as write_uncommitted+write_committed; a PIPE4.0 signal requiring three encoding instructions can be encoded as write_uncommitted+write_uncommitted+write_committed.

[0046] In this embodiment of the application, the PIPE4.0 signal detection module can also be used to generate first flag information and send the first flag information to the PIPE4.0 signal encoding module when it detects a change in any signal in the PIPE4.0 interface device.

[0047] The PIPE4.0 signal encoding module, upon receiving the first flag information, determines the number of encoding instructions required for the changed PIPE4.0 signal and encodes the changed PIPE4.0 signal according to that number of instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification. After transmitting the PIPE5.0 signal to the PIPE5.0 interface device, the first flag information is cleared to ensure that the PIPE4.0 signal detection module can trigger a new round of encoding for the next detected changed PIPE4.0 signal.

[0048] In the embodiments of this application, see Figure 2 As shown, the signal bridge may also include a PIPE5.0 signal detection module and a PIPE5.0 signal decoding module. Wherein:

[0049] The PIPE5.0 signal detection module is connected to the PIPE5.0 interface device and is used to detect whether the PIPE5.0 interface device is sending a signal.

[0050] The PIPE5.0 signal decoding module is used to, when the PIPE5.0 signal detection module detects that a PIPE5.0 interface device is sending a signal, if the signal sent by the PIPE5.0 interface device is a PIPE5.0 signal that needs to be transmitted to a PIPE4.0 interface device, obtain the address and data of the PIPE5.0 signal, and map the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address.

[0051] It should be noted that in this embodiment, the PIPE5.0 signal detection module and the PIPE5.0 interface device can be connected via Message_bus. The PIPE5.0 interface device transmits the PIPE5.0 signal to be transmitted to the PIPE4.0 interface device to the PIPE5.0 signal detection module via Message_bus.

[0052] To ensure the security of transmitted data, in one feasible embodiment of this application, the PIPE5.0 signal decoding module can determine whether the address is valid after obtaining the address and data of the PIPE5.0 signal. If valid, the data is then mapped to the corresponding PIPE4.0 signal line of the PIPE4.0 interface device. If invalid, the data of the PIPE5.0 signal can be directly discarded, thereby ensuring the security of transmitted data.

[0053] It should be understood that since the PIPE4.0 signal lines of the PIPE4.0 interface device can be predetermined, in this embodiment, the addresses of the PIPE4.0 signal lines of the PIPE4.0 interface device can be pre-written into the PIPE5.0 signal decoding module to determine whether the address of the PIPE5.0 signal is among the addresses of the PIPE4.0 signal lines. If it is, it can be determined to be valid; otherwise, it can be determined to be invalid.

[0054] It is important to note that in practical applications, a PIPE5.0 interface device may need to send multiple instructions (typically two or three instructions) for a single PIPE5.0 signal. To ensure the integrity of the data transmitted to the PIPE4.0 interface device, in one feasible embodiment of this application, the PIPE5.0 signal decoding module can determine whether the current instruction of the PIPE5.0 signal is a terminating instruction indicating the end of an instruction string. If not, the address and data in the current instruction are stored, and the next instruction for the PIPE5.0 signal is then obtained. If so, it indicates that this is the last instruction of the PIPE5.0 signal, so the address and data in the current instruction can be stored, and all the stored addresses and data corresponding to the PIPE5.0 signal can be mapped to the PIPE4.0 signal line. This ensures that the data sent to the PIPE4.0 interface device is complete.

[0055] It should be noted that in the above implementation, when storing the address and data in the current instruction, it can be stored sequentially with the address and data of the previous instruction of the PIPE5.0 signal, so that a complete PIPE4.0 signal can be easily spliced ​​together.

[0056] It is important to note that in this embodiment, to ensure that the PIPE4.0 signal encoding module can continue encoding the next PIPE4.0 signal after the previous one has been encoded, thus avoiding signal encoding errors, in one feasible implementation, the PIPE5.0 interface device can return a completion signal, such as a write_ack instruction, after receiving the PIPE5.0 signal from the signal bridge. The PIPE5.0 signal detection module then transmits this completion signal to the PIPE5.0 signal decoding module. The PIPE5.0 signal decoding module recognizes this as a completion signal and, without decoding, transmits it to the PIPE4.0 signal encoding module. Upon receiving the completion signal from the PIPE5.0 signal decoding module, the PIPE4.0 signal encoding module ends the current encoding. Afterward, a new round of encoding can be performed for any new or changed PIPE4.0 signals detected by the PIPE4.0 signal detection module.

[0057] It should be understood that, in the embodiments of this application, the PIPE5.0 signal detection module can also generate second flag information and send the second flag information to the PIPE5.0 signal decoding module when it detects a PIPE5.0 signal sent by the PIPE5.0 interface device that needs to be transmitted to the PIPE4.0 interface device.

[0058] The PIPE5.0 signal decoding module only obtains the address and data of the PIPE5.0 signal after receiving the second flag information. Then, according to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to that address, it maps the data to the PIPE4.0 signal line and clears the second flag information. In this way, triggering the PIPE5.0 signal decoding module through the second flag information ensures that the module only operates after being triggered, eliminating the need for continuous operation and effectively reducing its power consumption.

[0059] It should be noted that, in the embodiments of this application, the aforementioned PIPE4.0 signal detection module, PIPE4.0 signal encoding module, PIPE5.0 signal detection module, and PIPE5.0 signal decoding module are all written in a synthesizable hardware language. For example, they can be written in languages ​​such as Verilog and HDVL.

[0060] It should be noted that "synthesizable" as mentioned above means that the code written in the hardware language can correspond to a specific circuit, such as a real logic gate circuit, and can be programmed into the Emulator. Conversely, if the code written in the hardware language cannot correspond to a circuit structure, then it is not synthesizable.

[0061] It should be understood that, in this application embodiment, an electronic device is also provided, which can be programmed with the modules of the signal bridge described above, thereby realizing the function of the signal bridge described above.

[0062] In the embodiments of this application, the electronic device may be a host, server, or other device that can be used as an Emulator, but this is not a limitation.

[0063] In this embodiment, the signal bridge can be used for chip verification. For example, the PIPE4.0 interface device can be a MAC layer device required in the chip verification process, and the PIPE5.0 interface device can be a PCS layer device required in the chip verification process, but this is not a limitation.

[0064] The signal bridge and electronic device provided in this application embodiment can realize the conversion between PIPE4.0 signals and PIPE5.0 signals, realize signal bridging between PIPE4.0 interface devices and PIPE5.0 interface devices, and enable PIPE4.0 interface devices and PIPE5.0 interface devices to perform signal interaction.

[0065] Furthermore, the signal bridge provided in this application embodiment is written in a synthesizable hardware language, which can synthesize real logic gate circuits, can be programmed into an Emulator, has strong portability, and can be applied to the conversion between any standard PIPE4.0 and PIPE5.0.

[0066] Furthermore, the embodiments of this application can solve the problem that chip verification cannot be achieved when the MAC layer and PCS layer devices support PIPE4.0 signal lines and PIPE5.0 interfaces respectively during the current chip verification process. This ensures normal chip testing, shortens the chip verification cycle, and accelerates tape-out time.

[0067] Furthermore, in the signal bridge provided in this application embodiment, the value generated by each decoding or encoding can be saved, thereby facilitating later DEBUG (debugging).

[0068] Example 2:

[0069] Based on Embodiment 1, this embodiment takes a case where, during chip verification, the MAC layer only supports PIPE4.0 signal lines and the PCS layer device only supports PIPE5.0 interfaces as an example to further illustrate this application.

[0070] See Figure 3 As shown, Figure 3 The connection structure between the signal bridge and PIPE4.0 interface devices and PIPE5.0 interface devices is shown.

[0071] The meanings of the English labels in the image are as follows:

[0072] M2P: MAC to PCS, indicating that the data flow direction is from MAC to PCS.

[0073] P2M: PCS to MAC, indicating that the data flow direction is from PCS to MAC.

[0074] PCS_MAC_maxpclk: The input clock provided by PCS to MAC.

[0075] P2M_message_bus: The message bus signal that the PCS provides to the MAC that needs to be converted.

[0076] M2P_message_bus: The message bus signal that the MAC sends to the PCS that needs to be converted.

[0077] PhyStatus: A sign that PCS is complete.

[0078] MAC_PCS_pipe_reset: The reset signal from MAC to PCS.

[0079] Elasticbuffermode: The MAC controls the signals of the PCS elastic buffer layer.

[0080] Rxrxpolarity: Indicates whether the polarity of the current data stream has been reversed.

[0081] RxblockAligincontrol: Controls whether to detect EIEOS (Electrical Idle Exit Command Set) alignment block.

[0082] Txtxswing: Controls the voltage at the transmitting end.

[0083] TxtxMargin: Select the voltage range of the transmitter.

[0084] TxtxDeemph: Select the weighting on the transmitter.

[0085] TxGetlocalPresetcoeff: A signal flag indicating that the MAC requests presetcoeff (presetcoeffient, a pre-set coefficient, a parameter used for equilibration) from the PCS.

[0086] TxGetlocalPresetIndex: MAC requests the presetcoeff number from PCS.

[0087] TxlocalTxpresetCoeff: PCS returns the presetcoeff of the MAC request.

[0088] TxlocalTxCoeffValid: PCS returns a valid presetcoeff.

[0089] RxrxEqeval: MAC requests PCS to evaluate the quality of this equlization.

[0090] RxEqInprogress: MAC notifies PCS to perform equlization.

[0091] RxlinkEvalFOM: PCS provides feedback on the quality of this equlization.

[0092] RxlinkEvalFBDirChng: PCS feedback on changes in the equlization parameters.

[0093] TxlocalFS: PCS notifies the value of MAC FS (MAC full swing).

[0094] TxlocalLF: The value of MAC LF (MAC low frequency) notified by PCS.

[0095] RxLF: The MAC notifies the PCS of the value of LF.

[0096] RxFS:MAC notifies PCS of the value of FS.

[0097] Phystatus_for_MAC: Phystatus generated by the bridge.

[0098] The working process of each module in the diagram:

[0099] 1) PIPE4.0 signal detection module:

[0100] The system detects whether the signal from the PIPE4.0 interface device on the MAC side has changed. If a change is detected, the system immediately raises its own flag bit (i.e., generates the first flag bit information) and sends this flag bit signal to the PIPE4.0 signal encoding module.

[0101] 2) PIPE4.0 signal encoding module:

[0102] Upon receiving the flag signal from the PIPE4.0 signal detection module, the encoding circuit is immediately activated, and the changed signal is encoded and sent to the PCS side via the M2P_messageBus signal. The encoding process is as follows: Figure 4 As shown.

[0103] During the encoding process, if a flag signal of 1 is detected, the encoding circuit is started. If this flag signal comes from the PIPE5.0 signal decoding module, the PIPE4.0 signal encoding module returns a write_ack instruction to the PIPE5.0 signal decoding module, and the encoding ends.

[0104] If this flag signal comes from the PIPE4.0 signal detection module, the number of instructions required for this encoding is determined based on the type of signal detected as a change in transmission.

[0105] If two instructions are required, they are encoded as write_uncommitted + write_committed, consuming a total of 6 clock cycles. This drives the M2P_MessageBus to send the message to the PCS layer. The encoding ends when the PCS layer returns the write_ack instruction.

[0106] If three instructions are required, they are encoded in the form of write_uncomitted+write_uncommitted+write_committed, consuming a total of 9 clock cycles. This drives the M2P_MessageBus to send the message to the PCS layer. The encoding ends when the PCS layer returns the write_ack instruction.

[0107] 3) PIPE5.0 signal detection module:

[0108] Check if the P2M_messagebus value of the PIPE5 interface on the PCS layer side is non-zero. If it is non-zero, pull the flag signal of the PIPE5.0 signal detection module high (i.e. generate the second flag information) and send this flag signal to the PIPE5.0 signal decoding module.

[0109] 3) PIPE5.0 signal decoding module

[0110] Upon receiving the flag signal from the PIPE5.0 signal detection module, the PIPE5.0 signal decoding circuit is immediately activated. This circuit extracts the address and data from the PIPE5.0 signal transmitted via P2M_messagebus and converts it into a PIPE4.0 signal. The decoding process is shown in the attached diagram. Figure 5 As shown.

[0111] During the decoding process, the PIPE5.0 signal decoding module begins decoding after receiving the flag signal from the PIPE5.0 signal detection module.

[0112] Save the address and data of the PIPE5.0 signal sent by P2M_messageBus, and check if the instruction type is write_committed. Also check if the address is valid.

[0113] If the address is invalid, the instruction will be discarded.

[0114] If the instruction type is not `write_committed` and the address is valid, continue fetching and storing instructions. If the instruction type is `write_committed` and the address is valid, this decoding operation ends. The data of the PIPE5.0 signal stored in this round is mapped to the PIPE4.0 signal line on the corresponding MAC side at that address, and the PIPE4.0 signal encoding module is driven to send a `write_ack` instruction to clear the flag signal of the PIPE5.0 signal detection module.

[0115] The following examples illustrate several specific types of signal conversion processes:

[0116] Example 1: getlocalcoeff signal

[0117] Once the PIPE4.0 signal detection module detects the rising edge of the getlocalpresetcoeff signal on the PIPE4.0 side of the MAC layer, it acquires the getlocalpresetindex signal and drives the M2P_MessageBus to send it to the PIPE5.0 side of the PCS layer via the PIPE4.0 signal encoding module. The PCS side receives this request and sends a write_ack command to indicate receipt. Then, the PIPE5.0 side of the PCS layer drives the P2M_MessageBus to reply with a response in the form of write_uncommitted+write_uncommitted+write_committed. The PIPE5.0 signal decoding module receives this response, parses it, and routes it to the PIPE4.0 txlocalpresetcoeff signal interface, simultaneously generating a txlocalvoeffvaild signal with a validity period of 1, and then drives the PIPE4.0 signal encoding module to send a write_ack command. This process repeats 33 times until getlocalpresetindex reaches 32.

[0118] Example 2: Eqeval signal

[0119] When the LTSSM (Link Training and Status State Machine) enters the equilibration state, the RC (Root Complex) will adjust the equality parameter of the EP (endpoint, PCIe device), raising the Rxeqinprogress signal and the Eqeval signal. When a rising edge of the rxeqinprogress signal is detected on the MAC layer PIPE4.0 side, the PIPE4.0 signal encoding module drives the M2P_MessageBus to send this signal to the PCS PIPE5.0 side. The PCS side receives this request, replies with a write_ack instruction, and then drives the P2M_MessageBus to reply with a response in the form of write_uncommitted + write_committed. The PIPE5.0 signal decoding module receives this response, parses it, and routes it to the RxlinkFOM and RxlinkEvalFbDirChg signal interfaces of the MAC PIPE4.0. Simultaneously, it generates a Phystatus_For_mac signal with a valid period of 1, and then drives the PIPE4.0 signal encoding module to send back a write_ack instruction. The MAC side detects the Phystatus_For_mac signal and pulls the RXeqeval signal low, completing this eqeval. This entire process repeats 11 times until the Rxeqinprogress signal goes low.

[0120] Example 3: Txdeemph signal

[0121] The conversion of the TXdeemph signal is only a one-way interaction. The PIPE4.0 signal detection module detects a change in the TXdeemph signal of the MAC layer PIPE4.0, and encodes the TXdeemph signal into a request in the form of write_uncommitted+write_uncommitted+write_committed through the PIPE4.0 signal encoding module, and drives the M2P_messageBus to send it. After receiving these three instructions, the PCS side sends back a write_ack response.

[0122] Example 4: Txlocal FS signal or Txlocal LF signal

[0123] The conversion between Txlocal FS and Txlocal LF signals is only a one-way interaction. When the PIPE5.0 signal detection module detects a write_uncommitted+write_committed request sent from the PCS side via P2M_MessageBus, if the address in each instruction of the request matches the address of the Txlocal FS or Txlocal LF signal, the PIPE5.0 signal decoding module parses the data in this request to the Txlocal FS or Txlocal LF signal interface on the MAC side, and then drives the PIPE4.0 signal encoding module to send back a write_ack instruction.

[0124] Example 5: RXFS signal or RXLF signal

[0125] The conversion between RXFS and RXLF signals is a one-way interaction. When the PIPE4.0 signal detection module detects a change in the RXFS or RXLF signal at the MAC layer, the PIPE4.0 signal encoding module encodes the RXFS or RXLF signal into a write_uncommitted + write_committed request and drives the M2P_messageBus to send this request. After receiving the request, the PCS side responds with a write_ack instruction.

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

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

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

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

[0130] In this article, "multiple" refers to two or more.

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

Claims

1. A signal bridge, characterized in that, include: The PIPE4.0 signal detection module is used to detect whether the signal in the PIPE4.0 interface device has changed. The PIPE4.0 signal encoding module is used to determine the number of encoding instructions required for the changed PIPE4.0 signal when the PIPE4.0 signal detection module detects a change in any signal in the PIPE4.0 interface device, and to encode the changed PIPE4.0 signal according to the number of encoding instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification, and to transmit the PIPE5.0 signal to the PIPE5.0 interface device. The PIPE4.0 signal encoding module is specifically used for: Based on the type of the changed PIPE4.0 signal, determine the number of encoding instructions required for the changed PIPE4.0 signal; If the number of encoding instructions required for the changed PIPE4.0 signal is 2, then the changed PIPE4.0 signal is encoded into the form of 2 consecutive instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification. If the number of encoding instructions required for the changed PIPE4.0 signal is 3, then the changed PIPE4.0 signal is encoded into the form of 3 consecutive instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification. Each instruction contains three parts: instruction type, address, and data content.

2. The signal bridge as described in claim 1, characterized in that, The PIPE4.0 signal detection module is further configured to generate first flag information and send the first flag information to the PIPE4.0 signal encoding module when it detects a change in any signal in the PIPE4.0 interface device. The PIPE4.0 signal encoding module is specifically used to, after receiving the first flag information, determine the number of encoding instructions required for the changed PIPE4.0 signal, encode the changed PIPE4.0 signal according to the number of encoding instructions to obtain a PIPE5.0 signal that meets the PIPE5.0 specification, transmit the PIPE5.0 signal to the PIPE5.0 interface device, and clear the first flag information.

3. The signal bridge as described in claim 1 or 2, characterized in that, The signal bridge also includes: The PIPE5.0 signal detection module is used to detect whether the PIPE5.0 interface device is sending a signal. The PIPE5.0 signal decoding module is used to, when the PIPE5.0 signal detection module detects that the PIPE5.0 interface device is sending a signal, if the signal sent by the PIPE5.0 interface device is a PIPE5.0 signal to be transmitted to the PIPE4.0 interface device, obtain the address and data of the PIPE5.0 signal, and map the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address.

4. The signal bridge as described in claim 3, characterized in that, The PIPE5.0 signal decoding module is further configured to determine the validity of the address before mapping the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address after obtaining the address and data of the PIPE5.0 signal.

5. The signal bridge as described in claim 4, characterized in that, The PIPE5.0 signal decoding module is specifically used for: Determine whether the current instruction of the PIPE5.0 signal is a termination instruction that indicates the end of the instruction string; If not, store the address and data in the current instruction and continue to fetch the next instruction for the PIPE5.0 signal; If so, store the address and data in the current instruction, and map all the addresses and data corresponding to the stored PIPE5.0 signal to the PIPE4.0 signal line.

6. The signal bridge as described in claim 3, characterized in that, The PIPE5.0 signal decoding module is further configured to send the completion signal to the PIPE4.0 signal encoding module if the signal sent by the PIPE5.0 interface device is a completion signal. The PIPE4.0 signal encoding module is also used to end the current encoding when it receives the completion signal from the PIPE5.0 signal decoding module.

7. The signal bridge as described in claim 3, characterized in that, The PIPE5.0 signal detection module is further configured to generate a second flag bit information and send the second flag bit information to the PIPE5.0 signal decoding module when detecting the PIPE5.0 signal sent by the PIPE5.0 interface device to be transmitted to the PIPE4.0 interface device; The PIPE5.0 signal decoding module is specifically used to obtain the address and data of the PIPE5.0 signal after receiving the second flag information, map the data to the PIPE4.0 signal line of the PIPE4.0 interface device corresponding to the address, and clear the second flag information.

8. The signal bridge as described in claim 3, characterized in that, The PIPE4.0 signal detection module, the PIPE4.0 signal encoding module, the PIPE5.0 signal detection module, and the PIPE5.0 signal decoding module are all written in a synthesizable hardware language.

9. An electronic device, characterized in that, The electronic device is programmed with each module of the signal bridge as described in any one of claims 1-8 to realize the function of the signal bridge.

Images