DESC:TECHNICAL FIELD
[001] The invention pertains in general to the field of Ethernet communications and in particular to the technology of Ethernet physical devices

BACKGROUND
[002] Background description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
[003] Traditionally internet protocol (IP) communication between processor and field-programmable gate array (FPGA) modules involved physical Ethernet Phy IC. An example is recited in a US patent US 8,200,473 B1, entitled “Emulation of Multiple MDIO Manageable Devices”. The patent describes a method and system for processing a management operation command received from a management entity is provided. The management operation command is received by an emulation module for a switch element operationally coupled to the management entity. The switch element includes a plurality of ports, each port having a plurality of components designated as managements devices. The emulation module determines if identification information for a management device in the command matches with identification information stored by the switch element to emulate the management device. If the information matches, then the management operation identified in the management operation command is performed by the emulation module interfacing with a Switch element processor.
[004] Although multiple systems and mechanisms exist today, these systems and mechanisms suffer from significant drawbacks. Therefore, it is desired to develop a custom logic to emulate a management data input/output (MDIO) slave device in FPGA to make the IP communication possible between processor and FPGA modules without a physical Ethernet Phy IC.

OBJECTS OF THE PRESENT DISCLOSURE
[005] An object of the present disclosure is to provide a system that creates virtual Ethernet PHY in FPGA to communicate with the processor over IP without any additional device drivers.
[006] Another object of the present disclosure is to provide a system that requires minimum features of PHY for implementation so that it leads to low logic area consumption in FPGA.
[007] Another object of the present disclosure is to provide a system that does not involve any physical cable for connection.
[008] Another object of the present disclosure is to provide a system that does not require additional hardware.
[009] Another object of the present disclosure is to provide a system that provides a custom MDIO component in FPGA to emulate the management port of Ethernet PHY for the host CPU.
[0010] Another object of the present disclosure is to provide a system that expands the custom MDIO logic as many as Ethernet ports available in the processor.
[0011] Another object of the present disclosure is to provide a system that provides resource utilization.
[0012] Yet another object of the present disclosure is to provide a system that does not require auto-negotiation, fault signalling, and loopback functionality in the implementation.

SUMMARY
[0013] The present disclosure pertains in general to the field of Ethernet communications and in particular to the technology of Ethernet physical devices. The main objective of the present disclosure is to solve the technical problem as recited above by enabling IP communication possible between processor and FPGA modules without a physical Ethernet PHY IC. The required minimal Ethernet PHY MDIO features are implemented in FPGA to interact with the Ethernet ports of the processor. Receive interface (RIF) and transmit interface (TIF) memory is used to send and receive data between custom Ethernet modules and other modules in FPGA.
[0014] The present disclosure includes methods and system to create virtual Ethernet PHY in FPGA to communicate with the processor over IP. Virtual PHY MDIO module may be given commands from host processor to perform minimal Ethernet PHY functionality without any additional device drivers to support. The present disclosure consists of host CPU connected to FPGA having custom logic to emulate MDIO slave using hardcoded register lookup tables without any additional device drivers to support various PHY available.
[0015] The present disclosure provides resource utilization 36.5 adaptive logic modules (ALMs), 66 adaptive lookup tables (ALUTs) and 42 logical registers in programmable devices. The system does not involve any physical cable to connect between emulated PHY devices. The system enables the creation of hardcoded register maps as per IEEE 802.3 standards. The system processes command received from the host CPU and response generation to emulate the PHY device.
[0016] The present disclosure provides methods and system that enables a connection to be established that comprises of host CPU and FPGA can be on-chip System on Chip (SoC), Buses such as Advance eXtensible Interface (AXI), Avalon, and the likes or off-chip physical pin to pin connections. The system utilizes a fixed look up table (LUT) to be used to respond to the register status requested from host CPU.
[0017] The present disclosure provides methods and system that has provision for First in First Out (FIFO), RIF and TIF memory interface on receive and transmit side for the data path. The system enables host CPU Ethernet interface to be of any kind but compiling to IEEE 802.3 standards. The system can include a plurality host CPU connecting to a plurality of virtual Ethernet Phy devices emulated in FPGA.
[0018] The present disclosure has the following advantages, the present disclosure aims at providing the custom MDIO component in FPGA to emulate the management port of Ethernet PHY for the host CPU. Using Reduced Gigabit Media Independent Interface (RGMII), Gigabit Media Independent Interface (GMII)/Media Independent Interface (MII) ports of the host CPU to connect to the custom Ethernet component in FPGA without the use of any driver support. Additional hardware such as external processor, memory devices and the likes are not required. The custom MDIO logic can be expanded as many as Ethernet ports available in the processor. Minimum features of PHY are required for implementation so that it leads to low logic area consumption in FPGA. The auto-negotiation, fault signalling, and loopback functionality are not required in the implementation.

BRIEF DESCRIPTION OF THE DRAWINGS
[0019] The accompanying drawings are included to provide a further understanding of the present disclosure, and are incorporated in and constitute a part of this specification. The drawings illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.
[0020] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
[0021] FIG. 1 illustrates an exemplary interaction between custom MIDO and ethernet components to set the properties of ethernet interface, in accordance with an exemplary embodiment of the present disclosure.
[0022] FIG. 2 illustrates an exemplary state machine for MDIO slave implemented on FPGA, in accordance with an exemplary embodiment of the present disclosure.
[0023] FIG. 3 illustrates an exemplary MDIO packet frame, in accordance with an exemplary embodiment of the present disclosure.
[0024] FIG. 4 illustrates an exemplary receiving interface (RIF) memory block diagram, in accordance with an exemplary embodiment of the present disclosure.
[0025] FIG. 5 illustrates an exemplary transmit interface (TIF) memory block diagram, in accordance with an exemplary embodiment of the present disclosure

DETAILED DESCRIPTION
[0026] The following is a detailed description of embodiments of the disclosure depicted in the accompanying drawings. The embodiments are in such detail as to clearly communicate the disclosure. If the specification states a component or feature “may”, “can”, “could”, or “might” be included or have a characteristic, that particular component or feature is not required to be included or have the characteristic.
[0027] As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
[0028] The evolution of digital communication has led to the penetration of more devices working on IP as backbone of modern-day communication systems. PHY device is required to handle physical layer of transmission control protocol (TCP)/IP model and also to manage the Ethernet physical interface properties.
[0029] The present disclosure pertains in general to the field of Ethernet communications and in particular to the technology of ethernet physical devices (also interchangeable referred to as "Ethernet Phy" or "PHY", hereinafter). The present disclosure includes methods and system to create virtual Ethernet phy in FPGA to communicate with processor over IP. Virtual phy MDIO module may be given commands from host processor to perform minimal Ethernet phy functionality without any additional device drivers to support. The description of terms and features related to the present disclosure shall be clear from the embodiments that are illustrated and described; however, the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions, and equivalents of the embodiments are possible within the scope of the present disclosure. Additionally, the invention can include other embodiments that are within the scope of the claims but are not described in detail with respect to the following description.
[0030] FIG. 1 illustrates an exemplary interaction between custom MIDO and ethernet components to set the properties of ethernet interface, in accordance with an exemplary embodiment of the present disclosure.
[0031] Referring to FIG. 1, the system 100 adapted to create virtual Ethernet PHY in FPGA to communicate with processor over IP. The virtual physical MDIO module may be given commands from host processor to perform minimal Ethernet PHY functionality without any additional device drivers to support. The system 100 can include system on chip (SoC) (102-1, 102-2), processor (104-1, 104-2), central processing unit (CPU) (106-1, 106-2), field programmable gate array (FPGA) (108-1, 108-2), virtual ethernet physical device (110-1, 110-2), and custom ethernet components (112-1, 112-2).
[0032] In an embodiment, the system on chip (SoC) (102-1, 102-2) is disclosed. The SoC includes the processor (104-1, 104-2), and the field programmable gate array (FPGA) (108-1, 108-2). The FPGA (108-1, 108-2) has a virtual ethernet physical device (110-1, 110-2) coupled with the processor (104-1, 104-2) through an emulated management data input/output (MDIO). The FPGA (108-1, 108-2) includes one or more emulated ethernet ports to communicate with one or more associated ethernet ports of the processor (104-1, 104-2).
[0033] In an exemplary embodiment, the processor (104-1, 104-2) communicated with the FPGAs (108-1, 108-2) without an ethernet physical device. In another exemplary embodiment, the FPGAs (108-1, 108-2) includes one or more custom ethernet components (112-1, 112-2) adapted to connect with one or more ports of the central processing unit (CPU) (106-1, 106-2) of the processor (104-1, 104-2) using at least one reduced gigabit media independent interface (RGMII), gigabit media independent interface (GMII), and media independent interface (MII) without use of any driver support.
[0034] In an exemplary embodiment, the emulated MDIO is a MDIO slave component of the processor (104-1, 104-2). The emulated MDIO includes a MDIO interface clock (MDC) driven by a media access control (MAC) device to the virtual ethernet physical device (110-1, 110-2). The MDIO includes MDIO data to provide register data at end of a read operation.
[0035] In an embodiment, MDIO is a 2-wire serial bus that is used to manage PHYs or physical layer devices in media access controllers (MACs) in Gigabit Ethernet equipment. The management of these PHYs is based on the access and modification of their various registers.
[0036] MDIO was originally defined in Clause 22 of IEEE RFC802.3. In the original specification, a single MDIO interface is able to access up to 32 registers in 32 different PHY devices. These registers provide status and control information such as link status, speed ability and selection, power down for low power consumption, duplex mode (full or half), auto-negotiation, fault signalling, and loopback.
[0037] The host CPU Ethernet interface such as RGMII/GMII/MII may be connected to FPGA (108-1, 108-2). The custom MDIO logic which is running in FPGA (108-1, 108-2) may act as MDIO slave for processor. The commands for the PHY from processor may be sent to FPGA emulated PHY for configuring the properties of Ethernet port.
[0038] The custom MIDO may interact with custom Ethernet components (112-1, 112-2) to set the properties of Ethernet interface such as RGMII/GMII/MII as shown FIG. 1
[0039] The MDIO interface is implemented by two signals:
a) MDIO interface clock (MDC): clock driven by the MAC device to the PHY.
b) MDIO data: bidirectional, the PHY drives it to provide register data at the end of a read operation
[0040] Before a register access, PHY devices generally require a preamble of 32 ones to be sent by the MAC on the MDIO line. The access consists of 16 control bits, followed by 16 data bits. The control bits consist of 2 start bits, 2 access type bits (read or write), the PHY address (5 bits), the register address (5 bits), and 2 "turnaround" bits. MDIO Packet frame is as shown in FIG. 3 and described in detail below.
[0041] The processor (104-1, 104-2) is configured to transmit one or more commands to the virtual ethernet physical device (110-1, 110-2) configuring the properties of the one or more ethernet ports. The virtual ethernet physical device (110-1, 110-2) includes hardcoded register lookup tables (LUT) to respond to register status requested from the CPU (106-1, 106-2). The virtual ethernet physical device (110-1, 110-2) is configured to communicate with one or more processors over IP. The virtual ethernet physical device (110-1, 110-2) is used in a programmable device.
[0042] The one or more custom ethernet components (112-1, 112-2) comprises receive interface (RIF) memory and transmit interface (TIF) memory, where the RIF memory used to store data from receiving interface of one or more custom ethernet components and other data interface modules and the TIF memory is used to store data from transmitting interface of one or more custom ethernet components and other data interface modules.
[0043] FIG. 2 illustrates an exemplary the state machine for MDIO slave implemented on FPGA, in accordance with an exemplary embodiment of the present disclosure.
[0044] Referring to FIG. 2, Idle state may be the state for initialization of registers after a reset event or transitioned after reaching an unknown state
[0045] Idle state may transition to Read_Phyaddr on receiving '01' bits at start of MDIO command from host CPU MDIO.
[0046] Read_OpCode state is used to read OpCode from the host CPU MDIO.
[0047] Wait count is incremented in every state.
[0048] Read_Phyaddr state is used to send predefined PHY address to host CPU MDIO.
[0049] Read_Regaddr state is used to identify Reg address sent over host CPU MDIO.
[0050] WaitTurn Sate is used to wait for MDIO operation.
[0051] Read_Reg State is used to send predefined PHY data as per Register address (refer table-1) to host CPU MDIO.
[0052] EndTXN State is used to reach back to idle to repeat the operations.
[0053] LUT for the register is as shown in Table-1
[0054] For Register address 10001b (17d - Status Register) data field is as shown below:
Data [15:14] 01 - Speed 100Mbps
Data [13] 1 - Full-duplex
Data [12] 0 - page not received
Data [11] 1 - Speed and Duplex Resolved
Data [10] 1 - Link up
Data [9:7] 000 - cable length <50m
Data [6] 1 - MDI (Media Dependent Interface) Crossover
Data [5] 0 - no downshift
Data [4] 0 - Copper Energy Detect status active
Data [3] 0 - Transmit pause disable
Data [2] 0 - Receive Pause disable
Data [1] 0 - Polarity Normal
Data [0] 0 - No Jabber
[0055] For Register address 00000b (0d - Control Register) data field is as shown below:
Data [15] 0 - Normal operation (Reset Status)
Data [14] 1 - Enable Loopback
Data [13] 0 - speed select always 0
Data [12] 0 - Disable Auto-Negotiation
Data [11] 0 - Power Down Normal operation
Data [10] 0 - Isolate normal operation
Data [9] 0 - Restart copper Auto-Negotiation (Normal Operation)
Data [8] 1 - Copper Duplex Mode (Full-duplex)
Data [7] 0 - Disable Collision Test
Data [6] 1 - speed selection
Data [0:5] 101101 - Reserved
[0056] For Register address 00001b (1d - Status Register) data field is as shown below:
Data [15] 0 - PHY is not able to perform 100base-T4
Data [14] 0 - PHY is not able to perform full-duplex 100base-x
Data [13] 0 - PHY is not able to perform half-duplex 100base-x
Data [12] 0 - PHY is not able to perform full-duplex 10base-T
Data [11] 0 - PHY is not able to perform half-duplex 10base-T
Data [10] 0 - PHY is not able to perform Full-duplex 100base-T2
Data [9] 0 - PHY is not able to perform Half-duplex 100base-T2
Data [8] 1 - don't extend status information to register 15
Data [7] 0 - Reserved
Data [6] 1 - PHY don't accept management frames with preamble suppressed
Data [5] 0 - Copper Auto Negotiation complete
Data [4] 0 - Remote fault condition not detected
Data [3] 0 - PHY able to perform auto negotiation (always 1)
Data [2] 0 - Copper link down
Data [1] 0 - Jabber condition not detected
Data [0] 1 - extend register capability (always 1)
[0057] For Register address 00010b (2d - PHY Identifier Register) data field is as shown below:
Data [15:0] 0000110011000101 - Organizationally Unique Identifier Bits
[0058] For Register address 00011b (3d-PHY Identifier Register) data field is as shown below:
Data [15:10] 000000 - OUI LSB
Data [9:4] 010000 - Model Number
Data [3:0] 0001 - Revision Number
[0059] For Register address 00100b (4d-Auto-Negotiation Register) data field is as shown below:
Data [15] 0 - Next Page
Data [14] 0 - Acknowledge
Data [13] 0 - Remote Fault
Data [12] 1 - Reserved
Data [11] 0 - Asymmetric Pause
Data [10] 0 - Pause
Data [9] 0 - 100BASE-T4
Data [8] 1 - 100BASE-TX Full-Duplex
Data [7] 0 - 100BASE-TX Half-Duplex
Data [6] 0 - 10BASE-TX Full-Duplex
Data [5] 0 - 10BASE-TX Half-Duplex
Data [4:0] 00000 - selector field
[0060] For Register address 01111 (15d-Extended status register) data field is as shown below:
Data [15] 0 - 1000BASE-X Full-Duplex
Data [14] 0 - 1000BASE-X Half-Duplex
Data [13] 0 - 1000BASE-T Full-Duplex
Data [12] 0 - 1000BASE-T Half-Duplex
Data [11:0] 000000000000 - Reserved
[0061] For Register address 01001 (9d - 1000BASE-T Control Register) data field is as shown below:
Data [15:13] 000 - Test Mode
Data [12] 0 - Automatic MASTER/SLAVE Configuration
Data [11] 0 - Manual configure as SLAVE
Data [10] 0 - Prefer single port device (SLAVE)
Data [9] 0 - 1000BASE-T Full-Duplex Not advertised
Data [8] 0 - 1000BASE-T Half-Duplex Not advertised
Data [7:0] 00000000 - Reserved
[0062] For Register address 01010 (10d - 1000BASE-T Status Register) data field is as shown below:
Data [15] 0 - No MASTER/SLAVE configuration fault detected
Data [14] 0 - Local PHY configuration resolved to SLAVE
Data [13] 0 - Local Receiver is not OK
Data [12] 0 - Remote receiver not OK
Data [11] 1 - Link Partner is capable of 1000BASE-T full-duplex
Data [10] 0 - Link Partner is not capable of 1000BASE-T Half-duplex
Data [9:8] 00 - reserved
Data [7:0] 00000000 - idle Error Counter
Register Address Register Data
"10001" (17d) "0110110001000000"
"00000" (0d) "0100000101101101"
"00001" (1d) "0000000101000001"
"00010" (2d) "0000110011000101"
"00011" (3d) "0000000100000001"
"00100" (4d) "0001000100000000"
"00101" (5d) "0000000000000100"
"01111" (15d) "0000000000000000"
"01001" (9d) "0000000000000000"
"01010" (10d) "0000100000000000"
Table 1: LUT for the register
[0063] FIG. 3 illustrates an exemplary MDIO packet frame, in accordance with an exemplary embodiment of the present disclosure.
[0064] Referring to FIG. 3, the PHY devices (110-1, 110-2) generally require a preamble of 32 ones to be sent by the MAC on the MDIO line. The access consists of 16 control bits, followed by 16 data bits. The control bits consist of 2 start bits, 2 access type bits (read or write), the PHY address (5 bits), the register address (5 bits), and 2 "turnaround" bits.
[0065] PRE_32: The first field in the MDIO header is the Preamble. During the preamble, the MAC sends 32 bits, all '1', on the MDIO line.
[0066] ST: The Start field consists of 2 bits and always contains the combination '01'.
[0067] OP: The Opcode consists of 2 bits. There are two possible opcodes, read '10' or write '01'.
[0068] PA5: 5 bits, PHY address.
[0069] RA5: The Register Address field indicates the register to be written to or read from. It is 5 bits long.
[0070] TA: The turn-around field is 2 bits long. When data is being written to the PHY, the MAC writes '10' to the MDIO line. When data is being read, the MAC releases the MDIO line.
[0071] D16: 16 bits, data. This can be sent by either the SME or the PHY, depending on the value of the OP field.
[0072] FIG. 4 and FIG. 5 shows receiving interface (RIF) and transmit interface (TIF) memory block diagram. RIF memory is used to store data from receiving interface of custom Ethernet interface and other data interface modules. TIF memory is used to store data from transmitting interface of custom Ethernet interface and other data interface modules.
[0073] TIF_ input_Addr[8:0] and TIF_input_Addr_MSB are together 10 bit address line used for storing 32 bit data on TIF_Data_Input[31:0] into TIF memory. TIF_Write/Read_Enable line is used to Enable Write or Read operation on TIF memory. TIF_output_Addr[8:0] and TIF_output_Addr_MSB are together 10 bit address line used for outputing 32 bit data on TIF_Data_output[31:0] from TIF memory.RIF_ input_Addr[8:0] and RIF_input_Addr_MSB are together 10 bit address line used for storing 32 bit data on RIF_Data_Input[31:0] into RIF memory.RIF_Write/Read_Enable line is used to Enable Write or Read operation on RIF memory.RIF_ output_Addr[8:0] and RIF_output_Addr_MSB are together 10 bit address line used for outputting 32 bit data on RIF_Data_output[31:0] from RIF memory. RIF_output_Addr_MSB and RIF_input_Addr_MSB will always be not equal and always toggle according to the input data count threshold.
[0074] Dual port memory uses one of its port to write data into the memory and other port to read data from memory. Whenever an Ethernet packet received by custom Ethernet component it may be written into RIF memory and RIF_input_Addr_MSB may be toggled and packet count is incremented. Whenever a packet count is incremented the RIF_output_Addr_MSB may be logical not of RIF_input_Addr_MSB and RIF_output_Addr may be incremented to read data on RIF_Data_output[31:0], the same may be applicable for TIF memory interface when Ethernet packet need to be transmitted from custom Ethernet component.
[0075] Although the system has been elaborated as above to include all the main modules, it is completely possible that actual implementations may include only a part of the modules or a combination of those or a division of those into sub-modules in various combinations across multiple devices that can be operatively coupled with each other, including in the cloud. Further the modules can be configured in any sequence to achieve objectives elaborated. Also, it can be appreciated that system can be configured in a computing device or across a plurality of computing devices operatively connected with each other, wherein the computing devices can be any of a computer, a laptop, a smartphone, an Internet enabled mobile device and the like. All such modifications and embodiments are completely within the scope of the present disclosure.
[0076] As used herein, and unless the context dictates otherwise, the term “coupled to” is intended to include both direct coupling (in which two elements that are coupled to each other or in contact each other) and indirect coupling (in which at least one additional element is located between the two elements). Therefore, the terms “coupled to” and “coupled with” are used synonymously. Within the context of this document terms “coupled to” and “coupled with” are also used euphemistically to mean “communicatively coupled with” over a network, where two or more devices are able to exchange data with each other over the network, possibly via one or more intermediary device.
[0077] Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms “comprise” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refer to at least one of something selected from the group consisting of A, B, C ….and N, the text should be interpreted as requiring only one element from the group, not A plus N, or B plus N, etc.
[0078] While some embodiments of the present disclosure have been illustrated and described, those are completely exemplary in nature. The disclosure is not limited to the embodiments as elaborated herein only and it would be apparent to those skilled in the art that numerous modifications besides those already described are possible without departing from the inventive concepts herein. All such modifications, changes, variations, substitutions, and equivalents are completely within the scope of the present disclosure. The inventive subject matter, therefore, is not to be restricted except in the protection scope of the appended claims.

ADVANTAGES OF THE PRESENT DISCLOSURE
[0079] The present disclosure provides a system that creates virtual Ethernet PHY in FPGA to communicate with the processor over IP without any additional device drivers.
[0080] The present disclosure provides a system that requires minimum features of PHY for implementation so that it leads to low logic area consumption in FPGA.
[0081] The present disclosure provides a system that does not involve any physical cable for connection.
[0082] The present disclosure provides a system that does not require additional hardware.
[0083] The present disclosure provides a system that provides a custom MDIO component in FPGA to emulate the management port of Ethernet Phy for the host CPU.
[0084] The present disclosure provides a system that expands the custom MDIO logic as many as Ethernet ports available in the processor.
[0085] The present disclosure provides a system that provides resource utilization.
[0086] The present disclosure provides a system that does not require auto-negotiation, fault signalling, and loopback functionality in the implementation.

,CLAIMS:1. A system on chip (SoC) (102-1, 102-2) comprising:
a processor (104-1, 104-2); and
a field programmable gate array (FPGA) (108-1, 108-2) having a virtual ethernet physical device (110-1, 110-2) coupled with the processor (104-1, 104-2) through an emulated management data input/output (MDIO), wherein the FPGA includes one or more emulated ethernet ports to communicate with one or more associated ethernet ports of the processor.
2. The system on chip (SoC) as claimed in claim 1, wherein the processor communicated with the field programmable gate arrays (FPGAs) without an ethernet physical device.
3. The system on chip (SoC) as claimed in claim 1, wherein the field programmable gate array (FPGA) (108-1, 108-2) comprises one or more custom ethernet components (112-1, 112-2) adapted to connect with one or more ports of a central processing unit (CPU) (106-1, 106-2) of the processor using at least one of reduced gigabit media independent interface (RGMII), gigabit media independent interface (GMII), and media independent interface (MII).
4. The system on chip (SoC) as claimed in claim 1, wherein the emulated management data input/output (MDIO) is a MDIO slave component of the processor.
5. The system on chip (SoC) as claimed in claim 1, wherein the processor is configured to transmit one or more commands to the virtual ethernet physical device configuring the properties of the one or more ethernet ports.
6. The system on chip (SoC) as claimed in claim 1, wherein the emulated management data input/output (MDIO) comprises a MDIO interface clock (MDC) driven by a media access control (MAC) device to the virtual ethernet physical device (110-1, 110-2).
7. The system on chip (SoC) as claimed in claim 1, wherein the emulated management data input/output (MDIO) comprises MDIO data to provide register data at end of a read operation.
8. The system on chip (SoC) as claimed in claim 1, wherein the virtual ethernet physical device comprises hardcoded register lookup tables to respond to register status requested from the CPU (106-1, 106-2).
9. The system on chip (SoC) as claimed in claim 1, wherein the virtual ethernet physical device is configured to communicate with one or more processors over internet protocol (IP), wherein the virtual ethernet physical device is used in a programmable device.
10. The system on chip (SoC) as claimed in claim 1, wherein one or more custom ethernet components (112-1, 112-2) comprises receive interface (RIF) memory and transmit interface (TIF) memory, wherein RIF memory used to store data from receiving interface of one or more custom ethernet components and other data interface modules and TIF memory is used to store data from transmitting interface of one or more custom ethernet components and other data interface modules.