Ethernet physical layer multi-mode driving method, system, medium and driver

By providing a multi-mode driving method, the problems of high driver development and maintenance costs and cumbersome application in the prior art are solved, unified management and flexible application of drivers are achieved, costs are reduced and verification efficiency is improved.

CN119743386BActive Publication Date: 2025-09-16NANJING JINZHEN MICROELECTRONICS TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202411810809.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-10
Publication Date
2025-09-16
Estimated Expiration
2044-12-10

AI Technical Summary

Technical Problem

In the existing technology, driver development and maintenance costs are high and the application is cumbersome, which cannot effectively solve the needs of multiple MAC interfaces, resulting in increased costs and complexity in the verification process.

Method used

This paper provides an Ethernet physical layer multi-mode driving method, which updates transmission configuration parameters by acquiring transmission data, responds to driving main processes and parallel processes, supports switching of multiple interface modes and error injection of data transactions, and realizes unified management and flexible application of drivers.

Benefits of technology

It reduces the development and maintenance costs of the driver, improves verification efficiency, simplifies the driver usage process, and enhances the scalability and flexibility of the driver.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119743386B_ABST
    Figure CN119743386B_ABST
Patent Text Reader

Abstract

The present invention provides an Ethernet physical layer multi-mode driving method, system, medium, and driver. The method includes the following steps: obtaining transmission data to update transmission configuration parameters; responding to task processes based on the transmission configuration parameters, wherein the task processes include a driving main process and a parallel process; when the responding process is the driving main process, exiting the transmission loop and transmitting transaction data based on the current interface occupancy; when the responding process is a parallel process, distinguishing responses based on the event type of the parallel process, wherein the event type of the parallel process includes at least a low-power frame process and an idle period signal process. The Ethernet physical layer multi-mode driving method, system, medium, and driver of the present invention integrate driving tasks from low-speed 10M / 100M MII and RMII interfaces to high-speed Gigabit GMII and RGMII interfaces, and can support interface / rate mode switching, error injection of data transactions, carrier extension transmission, and low-power frame transmission functions.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of drivers and data processing, and in particular relates to an Ethernet physical layer multi-mode driving method, system, medium and driver. Background Art

[0002] Ethernet physical layer chips are specialized chips designed under the IEEE 802.3 protocol framework and are essential components for wired communications. Currently, the industry typically uses UVM (Universal Verification Method) for digital verification of physical layer chips. UVM (Universal Verification Method) is the mainstream methodology in the chip verification industry. With its universal and scientific architecture, as well as its advantages of reusability and interpretability, UVM plays a crucial role in chip verification in various fields. In the verification work guided by this methodology, the design of the stimulus generator (or driver) is a very important step. Most of the stimuli in the verification process are generated by drivers carefully designed by the verifier. Building a fully functional, accurately behaved driver often requires considerable time and effort on the part of the verifier.

[0003] Furthermore, during the PHY chip verification process, verification engineers also need to develop various drivers to implement different stimuli. The MAC interface driver is crucial, as it generates MAC data message stimuli that comply with protocol specifications to drive the PHY chip data path, thereby verifying the PHY chip's digital circuit logic. However, during PHY chip verification, verification engineers often face the need for multiple MAC interfaces. The current mainstream approach is to develop a separate driver for each MAC interface, then select one or more drivers based on the functionality of the specific PHY chip being verified. This results in high development and maintenance costs for multiple independent drivers, and also creates inconvenience in application. Summary of the Invention

[0004] In view of the above-mentioned shortcomings of the prior art, the purpose of the present invention is to provide an Ethernet physical layer multi-mode driving method, system, medium and driver to solve the problems of high driver development and maintenance costs and cumbersome application in the prior art.

[0005] In a first aspect, the present invention provides an Ethernet physical layer multi-mode driving method, the method comprising the following steps:

[0006] Get transmission data to update transmission configuration parameters;

[0007] Based on the transmission configuration parameters, the task process is responded to, and the task process includes a driving main process and a parallel process, wherein:

[0008] When the responding process is the driving main process, the transmission loop is exited, and transaction data is transmitted based on the current interface occupancy right;

[0009] When the responded process is the parallel process, differentiated responses are performed based on the event type of the parallel process, wherein the event type of the parallel process includes at least a low power consumption frame process and an idle period signal process.

[0010] In a possible implementation of the present application, obtaining transmission data to update transmission configuration parameters specifically includes:

[0011] Acquire configuration parameters in the transmission data, wherein the configuration parameters include at least interface type, interface timing parameters, interface rate mode, interface support functions and other parameters;

[0012] The transmission timing of the corresponding interface is updated based on the interface timing parameters in the configuration parameters, and the transmission configuration parameters are updated based on the remaining parameters in the configuration parameters.

[0013] In a possible implementation of the present application, the interface type supports any interface among MII / RMII / GMII / RGMII, and the interface rate mode supports driving at a rate mode of 10M / 100M / 1000M supported by any interface.

[0014] In one possible implementation of the present application, the method further includes initializing the interface before obtaining transmission data to update transmission configuration parameters, which specifically includes initializing the delay of the data signal relative to the clock signal within the specified range and / or custom setting protocol of any interface.

[0015] In a possible implementation of the present application, when the responding process is the driving main process, the exited transmission loop includes a waiting transmission transaction loop, wherein the transmission loop specifically includes:

[0016] Extracting a transmission period, obtaining data to be transmitted at the beginning of the transmission period, wherein,

[0017] If the acquisition fails, idle transmission is performed and the interface occupancy right is released at the end of the current transmission cycle;

[0018] If the acquisition is successful, the current transmission loop is exited, the interface occupancy right is obtained and the corresponding data is waited for to be transmitted.

[0019] In a possible implementation of the present application, the transmitting of transaction data based on the current interface occupancy right specifically includes:

[0020] Acquiring the transaction data, wherein the transaction data includes the interface occupancy right corresponding to the transmission configuration parameter;

[0021] Analyze the incorrect instructions in the transaction data, wherein:

[0022] If there is no error, driving the transaction data payload within the transmission cycle based on the interface occupancy right, specifically including driving the valid bit and the data bit respectively to transmit the payload;

[0023] If there is an error, the abnormal transaction transmission mechanism is entered, and the error indication bit is driven to transmit the payload.

[0024] In a possible implementation of the present application, performing differentiated responses based on the event types of the parallel processes specifically includes:

[0025] When responding to the low-power frame process, the current low-power frame transmission interface, the low-power duration, and the time to exit the low-power silent state are obtained based on the transmission configuration parameters, wherein low-power frame data transmission is performed based on the current low-power frame transmission interface, and the silent state is entered after the low-power duration ends, and after entering the silent state, when the time to exit the low-power silent state is reached, the low-power frame process is exited;

[0026] When responding to the idle period signal process, the current idle period transmission interface, idle state mode and idle state maintenance time are obtained based on the transmission configuration parameters, wherein the idle state transmission is performed based on the current idle period transmission interface and the idle state maintenance time is reached before exiting the idle period signal process, wherein the idle state mode includes four modes.

[0027] In a second aspect, the present invention provides an Ethernet physical layer multi-mode driving system, the system comprising:

[0028] An acquisition module, used to acquire transmission data to update transmission configuration parameters;

[0029] A response module, configured to respond to a task process based on the transmission configuration parameters, wherein the task process includes a driving main process and a parallel process;

[0030] A transmission module, configured to exit the transmission loop when the responding process is the driving main process, and transmit transaction data based on the current interface occupancy right;

[0031] The distinguishing module is used to perform a distinguishing response based on the event type of the parallel process when the responded process is the parallel process, wherein the event type of the parallel process at least includes a low power frame process and an idle period signal process.

[0032] In a third aspect, an Ethernet physical layer multi-mode driver is provided, comprising: a processor and a memory; wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the Ethernet physical layer multi-mode driver executes any one of the Ethernet physical layer multi-mode driving methods.

[0033] In a fourth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned Ethernet physical layer multi-mode driving method when executed by an electronic device.

[0034] As described above, the Ethernet physical layer multi-mode driving method, system, medium, and driver of the present invention have the following beneficial effects: integrating driving tasks from low-speed 10M / 100M MII and RMII interfaces to high-speed Gigabit GMII and RGMII interfaces, and can support interface / rate mode switching, error injection of data transactions, carrier extension transmission, and low-power frame transmission functions. Specific applications include the following beneficial effects:

[0035] (1) It can adapt to multiple interfaces of the Ethernet device to be verified, instead of the traditional verification environment, which requires different drivers to be applied to each different interface. This can reduce the development and maintenance costs of the verification personnel, greatly improve the verification efficiency, and also improve the reusability of the overall environment. In particular, since there is only one configuration object during use, there is no need to control different driver objects separately, which can also reduce the control difficulty and the probability of errors caused by repeated configurations. In addition, mode switching in a multi-mode driver is much simpler and safer than switching in multiple drivers. It can be switched with one click, which greatly improves the efficiency of the verification personnel in developing mode switching scenario use cases.

[0036] (2) The driver has a clear management logic when driving tasks. By using universal tasks to execute the common parts when driving different interfaces, the maintenance cost of the driver itself can be reduced. In addition, the modularization of different transmission tasks also improves the scalability of the driver. In actual applications, more driving tasks can be added according to further requirements such as Ethernet protocol updates and complex application scenarios.

[0037] (3) It can make good use of the randomness in the verification methodology. Under the constraints of the established timing range, it can generate random timing parameters, or accept directly given timing parameters, and set the timing parameters directly to the interface file when the task updates the configuration parameters. It has strong flexibility and is very convenient to use. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Figure 1 Shown is a schematic diagram of a scene of an electronic device in an embodiment of the present invention;

[0039] Figure 2 Shown is a schematic diagram of the steps of an Ethernet physical layer multi-mode driving method in one embodiment of the present invention;

[0040] Figure 3 Shown is a schematic structural diagram of a driver in one embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0041] Figure 4 Shown is a flow chart of transmission configuration parameters in an embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0042] Figure 5 Shown is a flowchart of a task of transmitting transaction data in an embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0043] Figure 6 Shown is a schematic diagram of the annotated sequence contents in one embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0044] Figure 7 Shown is a flow chart of transmitting a low-power frame in an embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0045] Figure 8 It is a flow chart showing the transmission idle period signal in an embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0046] Figure 9 Shown is a schematic diagram of an idle state mode in an embodiment of the Ethernet physical layer multi-mode driving method of the present invention;

[0047] Figure 10 Shown is a schematic structural diagram of an Ethernet physical layer multi-mode driving system in one embodiment of the present invention;

[0048] Figure 11 FIG. 1 is a schematic structural diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0049] The following describes the embodiments of the present invention through specific examples. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments. The details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0050] It should be noted that the illustrations provided in the following embodiments are merely schematic illustrations of the basic concept of the present invention. Therefore, the illustrations only show components related to the present invention and are not drawn according to the number, shape, and size of components in actual implementation. In actual implementation, the type, quantity, and proportion of each component may be changed arbitrarily, and the component layout may also be more complex.

[0051] The following embodiments of the present invention provide an Ethernet physical layer multi-mode driving method, which can be applied to Figure 1 The electronic device shown. The electronic device described in the present invention may include a mobile phone 11 with a wireless charging function, a tablet computer 12, a laptop computer 13, a wearable device, an in-vehicle device, an augmented reality (AR) / virtual reality (VR) device, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA), etc. The embodiment of the present invention does not impose any restrictions on the specific type of electronic device.

[0052] It's important to note that the primary function of a PHY chip is to convert messages (or simply, data) from the Media Access Control (MAC) sublayer into electrical or optical signals on the Media Dependent Interface (MDI), as well as receive MDI signals and convert them into messages (or data) for the MAC interface. Obviously, the MAC interface is a crucial component of the PHY chip. To support different data rates and address the need to reduce interface pin counts in different package sizes, multiple MAC interface protocols have been developed, each of which is specified in the IEEE 802.3 standard. For example, the 100M / 10M MAC interface (MII) corresponds to the RMII, a MAC interface with reduced interface pin count. For example, the GMII, a MAC interface for 1G and below, corresponds to the RGMII, a MAC interface with reduced interface pin count. It's important to note that while the signal names and numbers associated with different interface protocols vary, the Ethernet message format sent across these interfaces is the same, and the representation of valid bit indication, error indication, and low-power frame (LPI) is also essentially the same.

[0053] Currently, the following problems exist in the application process of drivers. First, during the development phase, due to the independence of each interface driver, it may be developed by multiple developers at different time points. This poses a great challenge to the uniformity of the driver structure and code style. In addition, some code will be rewritten due to the common characteristics of the interface, resulting in unnecessary redundancy.

[0054] Secondly, during later maintenance, for example, if a code error is discovered when applying a certain interface driver, and it is determined that the error lies in a common feature of all interfaces, then other related drivers need to be modified. As the number of interfaces increases, this maintenance cost is multiplied. Similarly, when interface functionality evolves and a certain function needs to be added to all interface drivers, such as error injection or verification, the effort required to modify the code of each driver will also be multiplied.

[0055] In terms of applications, for example, some PHY chips support two or even multiple MAC interfaces. Verification of such chips requires the simultaneous integration of multiple corresponding drivers, which places significant overhead on verification personnel. Furthermore, when verifying interface switching scenarios for such PHY chips, such as switching from the GMII interface to the RGMII interface, the corresponding drivers must be switched, placing higher demands on driver design and the overall verification environment architecture.

[0056] Therefore, in order to improve the integration, reduce the maintenance cost and usage overhead of the verification personnel, and improve the overall verification efficiency, this application proposes an Ethernet physical layer multi-mode driving method, system, medium and driver based on the UVM methodology, wherein the driver can integrate the multi-interface multi-mode of the common MAC interface, thereby supporting Ethernet standard message transmission, supporting mode switching, and is simple to use and has low maintenance cost.

[0057] The technical solutions in the embodiments of the present invention will be described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0058] Specifically, see Figure 2 In one embodiment of the invention, the Ethernet physical layer multi-mode driving method of the present invention includes the following steps:

[0059] Step S202: acquiring transmission data to update transmission configuration parameters;

[0060] Step S204, responding to a task process based on the transmission configuration parameters, wherein the task process includes a driving main process and a parallel process;

[0061] Step S206: when the responding process is the driving main process, exit the transmission loop and transmit transaction data based on the current interface occupancy right;

[0062] Step S208 : When the responded process is the parallel process, differentiated responses are performed based on the event type of the parallel process, wherein the event type of the parallel process at least includes a low power frame process and an idle period signal process.

[0063] It should be noted that, in this embodiment, the Ethernet physical layer is between the MAC layer and the medium in the Ethernet hierarchy, which is also the working domain of the Ethernet physical layer (PHY) chip. The object driven by the driver is the interface between the MAC and the PHY. Among them, the 10M and 100M interfaces are called MII, and there is also a simplified interface version RMII with half the signal harness. The gigabit interface is called GMII, and its simplified harness version is the RGMII interface. The protocol of each interface will specify the normal delay and maximum delay of its data signal and clock signal to constrain the design of different Ethernet physical layer chips and ensure that different designs can be compatible with each other. Therefore, the interface type supports any interface among MII / RMII / GMII / RGMII, and the interface rate mode corresponds to the rate mode supported by any interface, 10M / 100M / 1000M, for driving.

[0064] Furthermore, taking the low power frame process as a parallel process as an example, Figure 3 As shown in the figure, it is a schematic diagram of the structure of the driver, where the interface is the signal defined by different MAC interface protocols described by System-Verilog. For example, the signals of the GMII interface are txclk, txen, txd, txer, rxclk, rxdv, rxd, and rxer. Since the interface description itself fully complies with the protocol, this article will not go into details. However, it should be noted that the interface signal delay mentioned above is applied in the interface description file. This parameter will be passed to the input and output delays in the System-Verilog clocking block used in the interface description and will take effect under the syntax defined by System-Verilog.

[0065] Specifically, transmission data is obtained to update transmission configuration parameters. For example, after specifying the basic parameters of the driver, such as the interface type and rate mode, the driver will initialize the interface when starting the driver, and obtain the initial parameters to initialize the driver, which specifically includes initializing the delay of the data signal relative to the clock signal within the specified range and setting the protocol of any interface, thereby responding to the task process based on the transmission configuration parameters. The task process includes a driving main process and a parallel process, and the interface is set at the same time. The type of the currently used interface, the timing parameters of the interface, the currently used rate mode, the currently required support / use of the driving function (such as whether error annotation is required, whether carrier extension technology needs to be supported, etc.) are set. When the responding process is the driving main process, the transmission loop is exited, and transaction data is transmitted based on the current interface occupancy right. When the responding process is the parallel process, the response is differentiated based on the event type of the parallel process, wherein the event type of the parallel process includes at least a low power frame process and an idle period signal process.

[0066] It should be noted that the main process specifically waits for and obtains the transaction given by the UVM sequencer and drives it based on Figure 3 It can be seen that the main process is an infinite loop, which specifically includes a transmission transaction loop, which will be described in detail in the subsequent instructions. The parallel process is to solve multiple different events (such as data transactions, low-power control frames, and idle period signals, etc.) that can autonomously occupy and control the same interface to avoid mutual competition and facilitate later functional expansion. Among them, driving the low-power frame may occur at any time when driving the main process (message data and idle period). The design of the parallel process has greatly improved the degree of freedom and is closer to the real scene. Each parallel process will try to obtain the occupancy right of the current interface before performing the actual driving behavior. The system-verilog semaphore is used here to implement the management of occupancy rights. It can be driven safely only when there is no process occupying the current interface. When the process completes the driving of the interface, the interface occupancy right will be released for other processes or the next drive to apply.

[0067] Furthermore, in one embodiment of the invention, obtaining transmission data to update transmission configuration parameters specifically includes:

[0068] Acquire configuration parameters in the transmission data, wherein the configuration parameters include at least interface type, interface timing parameters, interface rate mode, interface support functions and other parameters;

[0069] The transmission timing of the corresponding interface is updated based on the interface timing parameters in the configuration parameters, and the transmission configuration parameters are updated based on the remaining parameters in the configuration parameters.

[0070] It should be noted that, in this embodiment, Figure 4 As shown, it is shown that the transmission configuration parameters are obtained for updating, the purpose of which is to support dynamic switching / changing of the transmission interface, such as switching the interface between two transmissions, etc., wherein the configuration parameters include at least interface type, interface timing parameters, interface rate mode, interface support functions and other parameters, thereby updating the transmission timing of the corresponding interface based on the interface timing parameters in the configuration parameters, and updating the transmission configuration parameters based on the remaining parameters in the configuration parameters.

[0071] Furthermore, in one embodiment of the invention, when the responding process is the driving main process, the exited transmission loop includes a waiting transmission transaction loop, wherein the transmission loop specifically includes:

[0072] Extracting a transmission period, obtaining data to be transmitted at the beginning of the transmission period, wherein,

[0073] If the acquisition fails, idle transmission is performed and the interface occupancy right is released at the end of the current transmission cycle;

[0074] If the acquisition is successful, the current transmission loop is exited, the interface occupancy right is obtained and the corresponding data is waited for to be transmitted.

[0075] It should be noted that, in this embodiment, at the beginning of each transmission cycle, the loop first attempts to obtain the data transaction that needs to be transmitted. If the acquisition fails, the current cycle is considered to be an idle period, and an attempt is made to obtain the interface occupancy right, and an idle signal of one cycle is transmitted. In addition to the default mode specified by the protocol, the idle signal can also be configured as user-defined patterned data, and then the interface occupancy right is released, and the next cycle is carried out; if the transmission transaction is successfully obtained, the current cycle is immediately exited, and an attempt is made to obtain the interface occupancy right, and the data transaction is transmitted, and the transmission cycle is completed in this way.

[0076] Furthermore, if Figure 5 as well as Figure 6 As shown, when transmitting transaction data, the following steps are included:

[0077] The first step is to re-acquire the current transmission configuration parameters, which corresponds to the annotation number 1. That is, the transmission configuration parameters need to be updated before each transmission transaction to support the switching / changing of the transmission interface;

[0078] The second step is to adjust the transaction data according to the error annotation instruction in the transmission transaction, which corresponds to the annotation signal 2, that is, the error indication in the transmission transaction data is randomly pulled high during the transmission process. Specifically, the error annotation instruction in the transmission transaction is analyzed, and the transmission transaction data is adjusted accordingly to support error injection, so as to be applied to the scenario of testing abnormal transaction transmission. The specific supported error injection types cover the error types specified by the interface protocol. For example, when the data valid bit is pulled high, the data error bit is pulled high, indicating that there is an error in the data of the current clock cycle.

[0079] The third step is to drive the valid bit, data bit, error indicator and other signals according to the interface protocol to receive the termination instruction and dynamically and immediately exit the transmission. This corresponds to annotation signal three. That is, according to the high-speed GMI / RGMI protocol, when transmitting transactions less than "512" bytes, special format extension data can be immediately followed by the transaction data to widen the transmission carrier. This is called carrier extension technology. Specifically, on the selected interface, the corresponding transaction data payload content is driven on a clock cycle basis, and the valid bit, data bit, error indicator bit and other signals are driven respectively until the payload is transmitted. During this period, the transaction data transmission task can also receive the termination instruction issued by the user and dynamically and immediately exit the current transmission behavior. In actual application, this can help construct scenarios such as sudden data termination and sudden interface switching. If the error annotation instruction in the transaction data is analyzed and there is no error, the transaction data payload is driven within the transmission cycle based on the interface occupancy right, specifically including driving the valid bit and data bit to transmit the payload. If there is an error, the abnormal transaction transmission mechanism is entered, specifically driving the error indicator bit to transmit the payload.

[0080] The fourth step is to drive the idle time specified by the interface protocol for the transmission transaction. This corresponds to note number 4, which states that the MAC protocol requires a minimum intra-frame interval between transactions to maintain the idle state. Specifically, the fourth step involves the transmission of the carrier extension portion. This is effective only if the configuration parameters support carrier extension technology; otherwise, this step is skipped. Carrier extension technology is described here. This technology is a backward-compatible feature of the Ethernet high-speed interface specified in the IEEE protocol. According to the GMII / RGMII protocol, when transmitting transaction data smaller than 512 bytes, to ensure that the peer device can accurately detect the carrier on the transmission medium, specially formatted extension data can be immediately followed by the transaction data to widen the carrier, allowing less sensitive older devices to detect the carrier in a timely manner. This also allows the user to terminate the transmission and dynamically and immediately exit the current transmission. Furthermore, it should be noted that after all data in the current transaction is transmitted, the aforementioned transmission idle state task is invoked to transmit an idle time. According to the protocol, this idle time is required between adjacent transactions, but its length can be specified by the transmission configuration parameters.

[0081] Furthermore, in one embodiment of the invention, the differentiated response based on the event type of the parallel process specifically includes:

[0082] When responding to the low-power frame process, the current low-power frame transmission interface, the low-power duration, and the time to exit the low-power silent state are obtained based on the transmission configuration parameters, wherein low-power frame data transmission is performed based on the current low-power frame transmission interface, and the silent state is entered after the low-power duration ends, and after entering the silent state, when the time to exit the low-power silent state is reached, the low-power frame process is exited;

[0083] When responding to the idle period signal process, the current idle period transmission interface, idle state mode and idle state maintenance time are obtained based on the transmission configuration parameters, wherein the idle state transmission is performed based on the current idle period transmission interface and the idle state maintenance time is reached before exiting the idle period signal process, wherein the idle state mode includes four modes.

[0084] It should be noted that, in this embodiment, two parallel processes are specifically described, one is the low-power frame process, and the other is the idle period signal process, wherein, when responding to the low-power frame process, the current low-power frame transmission interface, low-power duration and exit low-power silent state time are obtained based on the transmission configuration parameters, wherein low-power frame data transmission is performed based on the current low-power frame transmission interface, and the silent state is entered after the low-power duration ends, and after entering the silent state, when the exit low-power silent state time is reached, the low-power frame process is exited; and when responding to the idle period signal process, the current idle period transmission interface, idle state mode and idle state maintenance time are obtained based on the transmission configuration parameters, wherein idle state transmission is performed based on the current idle period transmission interface and the idle state maintenance time is reached and then the idle period signal process is exited, wherein the idle state mode includes four modes.

[0085] Specifically, if Figure 7 As shown, it shows a flowchart of the task of transmitting low power frames, wherein the low power frame (LPI) is a part of the Energy Efficient Ethernet (EEE) specified in the IEEE 802.3 protocol. Taking the GMII interface as an example, its typical format on the MAC interface is that the data bit is an eight-bit hexadecimal number 0x01, and the error indication bit is pulled high. It is initiated by the MAC and transmitted to the PHY through the MAC interface to instruct the PHY device to enter the low power mode. The LPI of the low-speed MAC interface such as the MII interface is different only in the format, that is, the data bit is a four-bit hexadecimal number 0x1, or equivalently represented as an eight-bit hexadecimal number 0x11. Specifically, as Figure 7 As shown, when the user initiates the LPI transmission instruction, the low-power frame driving process will start waiting and obtaining the interface occupancy right. When the acquisition is successful, it will enter the low-power frame transmission task. After entering, it will first obtain a series of parameters required for LPI transmission from the current configuration parameters, such as the selected transmission interface, the duration of the low-power frame, and the silent time after exiting the low-power state (that is, the time from the next start of transaction data transmission). Then, it will use the selected interface to drive according to the above-mentioned low-power frame format. After continuously driving for the specified time, it will start the silent state. Finally, after waiting for the silent duration, it will exit the low-power frame transmission task.

[0086] Furthermore, if Figure 8 As shown in FIG, a flowchart of transmitting idle period signals is shown. In the driver, this task is encapsulated as a more general method that can be called by other tasks and can specify the idle state signal mode. The idle state signal mode mentioned includes four modes, as shown in FIG. Figure 9As shown, for example, when mode 1 is set, the interface data signal can be driven to all 0 values ​​in the idle state, which is also the default mode; for example, when mode 2 is set, the interface data signal can be driven to all 1 values ​​in the idle state, which can be used in special scenarios and function verification activities. In addition, mode 3 and mode 4 are also included, among which mode 3 is that the idle state transmission data is in an indeterminate state, and mode 4 is that the idle state transmission data is a random value. At the same time, the idle state transmission task can also specify the idle state maintenance time when calling, in units of transmission cycles. When transmitting the idle period in the above-mentioned driving main process, only one transmission cycle is maintained each time, because its cycle is one round per cycle.

[0087] An embodiment of the present application also provides an Ethernet physical layer multi-mode driving system, which can implement the Ethernet physical layer multi-mode driving method described in the present application. However, the implementation device of the Ethernet physical layer multi-mode driving method described in the present application includes but is not limited to the structure of the Ethernet physical layer multi-mode driving system listed in this embodiment. All structural deformations and replacements of the existing technology made according to the principles of the present application are included in the protection scope of the present application.

[0088] See also Figure 10 In one embodiment, this embodiment provides an Ethernet physical layer multi-mode driving system 100, the system comprising:

[0089] An acquisition module 101 is configured to acquire transmission data to update transmission configuration parameters;

[0090] A response module 102, configured to respond to a task process based on the transmission configuration parameters, wherein the task process includes a driving main process and a parallel process;

[0091] The transmission module 103 is configured to exit the transmission loop when the responding process is the driving main process, and transmit the transaction data based on the current interface occupancy right;

[0092] The distinguishing module 104 is configured to, when the responding process is the parallel process, perform a differentiated response based on the event type of the parallel process, wherein the event type of the parallel process includes at least a low power frame process and an idle period signal process.

[0093] Since the specific implementation of this embodiment corresponds to the aforementioned method embodiment, the same details will not be repeated here, and those skilled in the art should also understand that Figure 10The division of the various modules in the embodiment is merely a division of logical functions. In actual implementation, all or part of the modules can be integrated into one or more physical entities, and all of these modules can be implemented in the form of software called by processing elements, or all of them can be implemented in the form of hardware. Some modules can also be implemented in the form of software called by processing elements, and some modules can be implemented in the form of hardware.

[0094] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices or methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules / units is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules or units can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules or units, which can be electrical, mechanical or other forms.

[0095] Modules / units described as separate components may or may not be physically separate, and components displayed as modules / units may or may not be physical modules, that is, they may be located in one place or distributed across multiple network elements. Some or all of the modules / units may be selected based on actual needs to achieve the objectives of the embodiments of the present invention. For example, the functional modules / units in various embodiments of the present invention may be integrated into a single processing module, each module / unit may exist physically separately, or two or more modules / units may be integrated into a single module / unit.

[0096] Those skilled in the art should further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0097] The embodiment of the present invention also provides a computer-readable storage medium. A person skilled in the art will understand that all or part of the steps in the method for implementing the above embodiment can be completed by instructing a processor through a program, and the program can be stored in a computer-readable storage medium, and the storage medium is a non-transitory medium, such as a random access memory, a read-only memory, a flash memory, a hard disk, a solid-state drive, a magnetic tape, a floppy disk, an optical disc, and any combination thereof. The above storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more available media. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a tape), an optical medium (for example, a digital video disc (DVD)), or a semiconductor medium (for example, a solid-state drive (SSD)), etc.

[0098] An embodiment of the present invention further provides an electronic device comprising a processor and a memory.

[0099] The memory is used to store computer programs.

[0100] The memory includes various media that can store program codes, such as ROM, RAM, magnetic disk, USB flash drive, memory card or optical disk.

[0101] The processor is connected to the memory and is used to execute the computer program stored in the memory, so as to enable the electronic device to execute the above-mentioned Ethernet physical layer multi-mode driving method.

[0102] Preferably, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0103] like Figure 11As shown, the electronic device of the present invention is in the form of a general-purpose computing device. Components of the electronic device may include, but are not limited to: one or more processors or processing units 111, memory 112, and a bus 113 connecting different system components (including memory 112 and processing unit 111).

[0104] Bus 113 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus architectures. Examples of these architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MAC) bus, an Enhanced ISA bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0105] Electronic devices typically include a variety of computer system readable media. These media can be any available media that can be accessed by the electronic device, including volatile and non-volatile media, removable and non-removable media.

[0106] The memory 112 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1121 and / or cache memory 1122. The electronic device may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 1123 may be used to read and write non-removable, non-volatile magnetic media ( Figure 11 Not shown, often called a "hard drive"). Although Figure 11 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 113 via one or more data medium interfaces. Memory 112 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments of the present invention.

[0107] A program / utility 1124 having a set (at least one) of program modules 11241 may be stored, for example, in memory 112. Such program modules 11241 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which, or some combination thereof, may include an implementation of a network environment. Program modules 11241 generally implement the functions and / or methods of the embodiments described herein.

[0108] The electronic device may also communicate with one or more external devices (e.g., keyboards, pointing devices, displays, etc.), one or more devices that enable a user to interact with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication may be performed through input / output (I / O) interface 114. Furthermore, the electronic device may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) through network adapter 115. Figure 11 As shown, the network adapter 115 communicates with other modules of the electronic device via the bus 113. It should be understood that, although not shown in the figures, other hardware and / or software modules may be used in conjunction with the electronic device, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0109] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the present invention. Anyone skilled in the art may modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by one of ordinary skill in the art without departing from the spirit and technical principles disclosed herein are intended to be covered by the claims of the present invention.

Claims

1. An Ethernet physical layer multi-mode driving method, characterized in that: include: Acquire transmission data to update transmission configuration parameters, wherein the configuration parameters include at least an interface type and an interface rate mode, the interface type supports any interface in MII / RMII / GMII / RGMII, and the interface rate mode corresponds to driving at a rate mode of 10M / 100M / 1000M supported by any interface; Based on the transmission configuration parameters, the task process is responded to, and the task process includes a driving main process and a parallel process, wherein: When the responding process is the driving main process, the transmission loop is exited, and transaction data is transmitted based on the current interface occupancy right; When the responded process is the parallel process, a differentiated response is performed based on the event type of the parallel process, wherein the event type of the parallel process includes at least a low-power frame process and an idle period signal process, specifically including: when responding to the low-power frame process, obtaining the current low-power frame transmission interface, low-power duration and exit low-power silent state time based on the transmission configuration parameters, wherein low-power frame data transmission is performed based on the current low-power frame transmission interface, and the silent state is entered after the low-power duration ends, and after entering the silent state, when the exit low-power silent state time is reached, the low-power frame process is exited; when responding to the idle period signal process, obtaining the current idle period transmission interface, idle state mode and idle state maintenance time based on the transmission configuration parameters, wherein idle state transmission is performed based on the current idle period transmission interface and the idle state maintenance time is reached and then the idle period signal process is exited, wherein the idle state mode includes four modes.

2. The Ethernet physical layer multi-mode driving method according to claim 1, characterized in that: The acquiring of transmission data to update transmission configuration parameters specifically includes: Acquire configuration parameters in the transmission data, wherein the configuration parameters at least include interface timing parameters, interface support functions and other parameters; The transmission timing of the corresponding interface is updated based on the interface timing parameters in the configuration parameters, and the transmission configuration parameters are updated based on the remaining parameters in the configuration parameters.

3. The Ethernet physical layer multi-mode driving method according to claim 1, wherein: The method further includes initializing the interface before acquiring transmission data to update transmission configuration parameters, which specifically includes initializing the delay of the data signal relative to the clock signal within the protocol setting and / or custom specified range of any interface.

4. The Ethernet physical layer multi-mode driving method according to claim 3, characterized in that: When the responding process is the driving main process, the exited transmission cycle includes a waiting transmission transaction cycle, wherein the transmission cycle specifically includes: Extracting a transmission period, obtaining data to be transmitted at the beginning of the transmission period, wherein, If the acquisition fails, idle transmission is performed and the interface occupancy right is released at the end of the current transmission cycle; If the acquisition is successful, the current transmission loop is exited, the interface occupancy right is obtained and the corresponding data is waited for to be transmitted.

5. The Ethernet physical layer multi-mode driving method according to claim 4, characterized in that: The transmitting of transaction data based on the current interface occupation right specifically includes: Acquire the transaction data, wherein the transaction data includes the interface occupancy right corresponding to the transmission configuration parameter; analyze the error injection instruction in the transaction data, wherein, If there is no error, driving the transaction data payload within the transmission cycle based on the interface occupancy right, specifically including driving the valid bit and the data bit respectively to transmit the payload; If there is an error, the abnormal transaction transmission mechanism is entered, and the error indication bit is driven to transmit the payload.

6. An Ethernet physical layer multi-mode driving system, characterized in that: include: An acquisition module is used to acquire transmission data to update transmission configuration parameters, wherein the configuration parameters include at least an interface type and an interface rate mode, the interface type supports any interface in MII / RMII / GMII / RGMII, and the interface rate mode corresponds to driving at a rate mode of 10M / 100M / 1000M supported by any interface; A response module, configured to respond to a task process based on the transmission configuration parameters, wherein the task process includes a driving main process and a parallel process; A transmission module, configured to exit the transmission loop when the responding process is the driving main process, and transmit transaction data based on the current interface occupancy right; A differentiation module is used to differentiate responses based on the event type of the parallel process when the responded process is the parallel process, wherein the event type of the parallel process includes at least a low-power frame process and an idle period signal process, specifically including: when responding to the low-power frame process, obtaining the current low-power frame transmission interface, low-power duration and exit low-power silent state time based on the transmission configuration parameters, wherein low-power frame data transmission is performed based on the current low-power frame transmission interface, and the silent state is entered after the low-power duration ends, and after entering the silent state, when the exit low-power silent state time is reached, the low-power frame process is exited; when responding to the idle period signal process, obtaining the current idle period transmission interface, idle state mode and idle state maintenance time based on the transmission configuration parameters, wherein idle state transmission is performed based on the current idle period transmission interface and the idle state maintenance time is reached and then the idle period signal process is exited, wherein the idle state mode includes four modes.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the Ethernet physical layer multi-mode driving method according to any one of claims 1 to 5 is implemented.

8. An Ethernet physical layer multi-mode driver, characterized in that The Ethernet physical layer multi-mode driver includes: a processor and a memory; wherein the memory is used to store a computer program, and the processor is used to execute the computer program stored in the memory, so that the Ethernet physical layer multi-mode driver performs the Ethernet physical layer multi-mode driving method according to any one of claims 1 to 5.

Citation Information

Patent Citations

  • Software definition method and gateway for intelligent manufacturing

    CN118612317A