Modeling an Ethernet device is a relatively simple task: it must be able to send and receive Ethernet frames with one of the Ethernet link models that Simics provides. This is done through the ethernet_common interface:
SIM_INTERFACE(ethernet_common) {
void (*frame)(conf_object_t *NOTNULL obj, const frags_t *frame,
eth_frame_crc_status_t crc_status);
};
#define ETHERNET_COMMON_INTERFACE "ethernet_common"
For sending frames, an Ethernet device must provide an object attribute, i.e., a DML connect, that expects an object implementing the ethernet_common interface. Sending a frame consists in calling the frame() function with the object, the frame (as a frags_t) and the CRC status for the frame.
For receiving frames, an Ethernet device must simply implement itself the ethernet_common interface. The link will call the device whenever it receives a frame, with the same information as above.
Ethernet frames sent via the ethernet_common interface should not contain any preamble nor SFD (Start Frame Delimiter), but they should contain all fields, CRC included. The frame is represented as a frags_t, which is described in section 20.
Because of the cost of computing valid CRC fields in a simulation environment, the simulated Ethernet links make it possible to optimize away the CRC and assume it is correct. Setting crc_status to Eth_Frame_CRC_Match indicates to the link that, regardless of the actual contents of the CRC field in frame, the CRC is considered matching the frame contents. In other words, whenever the frame is assumed to be correct in the simulation (on an Ethernet network without error), the CRC field of the frame can be left uncomputed, and Eth_Frame_CRC_Match passed to the link.
Setting crc_status to Eth_Frame_CRC_Mismatch indicates that, on contrary, the CRC field and the frame contents do not agree. The CRC field must then be filled with a non-matching CRC value, to make sure that any simulated hardware or software handling the problem will correctly obtain a mismatched CRC.
Finally, crc_status can be left as Eth_Frame_CRC_Unknown. This will force the link to compute the CRC and reset the status as either a match or a mismatch. This can be useful when receiving already prepared frames that have been computed by software or another device. Note that the link itself will never send to the device an Eth_Frame_CRC_Unknown status.
A complete description of the ethernet_common interface is provided in the API Reference Manual.
Ethernet devices are connected to their link via a temporary endpoint object. This endpoint object provides the device with a private object to talk to, as well as a well-defined endpoint id on the link. This is used by the link when routing or switching packets. The simplest way to connect a device to a link is to use components, which will abstract away the endpoint object creation and configuration.
To connect to a link, a component encapsulating an Ethernet device should provide a connector of type ethernet-link. The connector information to pass along is a list containing either the device object itself, as [device object], or the device object and its port as a pair, if the device provides a port connection, as [[device object, port]]. This will provide sufficient information for the endpoint to talk with the device. In return, the endpoint will provide itself as object for connection to the link, as [endpoint object].
A complete type description of the ethernet-link connector is in section 24.10.
It is also possible—even recommended—to base a new Ethernet device model on an existing transceiver. The transceiver will connect to the link and handle the ethernet_common interface. In return, it will provide standard features for a transceiver model, such as bandwidth control and MII registers, and expose the ieee_802_3_phy_v3 to the device for communication. The device itself must implement the ieee_802_3_mac_v3 interface for receiving information from the transceiver.
The DEC21140A device model is built with a separate transceiver and provides a good example of this approach. It is described in section 10.3.
In most cases, the generic_eth_phy device can be used as an Ethernet transceiver. The device is described in section 10.4.
It may in some cases be desirable not to expose the transceiver as a separate device, and instead let the Ethernet device communicate directly with a link endpoint. The generic_eth_phy device is actually a good example of how to communicate with a link endpoint, even though it is not a standalone Ethernet device.