EM Module Guide

Ethernet NIC (EM) Family Guide

Overview

NAI’s EM-series modules are Ethernet Network Interface Cards (NICs) — smart function modules that give a host single-board computer (SBC) additional Ethernet ports over a direct-connect PCIe interface. The family’s current member, the EM1, is a dual-port Gigabit NIC: an Intel® 82580 GbE controller plus NAI’s magnetics and supporting circuitry, providing two independent 10/100/1000Base-T Ethernet ports in a Gen5 package.

Unlike NAI’s measurement, simulation, and I/O modules, an EM NIC is not driven by the NAI Software Support Kit (SSK). It is a standard NIC: the host SBC’s operating system enumerates the ports through its normal network driver and you configure them with the same tools you’d use for any Ethernet interface. There is no naibrd_* API, no Open/Init/Free lifecycle, and nothing module-specific to call — the “getting started” story for the EM family is about bringing up network ports under your OS, which is what this page walks through.

Note

An EM NIC needs no NAI SSK. The SSK (the naibrd library and its sample apps) is for NAI’s smart function modules — A/D, 1553, serial, encoder, and so on. An EM module is a PCIe Ethernet controller that your operating system owns directly through its standard NIC driver, so there is no NAI API to call for it. If you’ve configured a Linux or Windows network interface before, you already know how to use it.

Typical reasons to add an EM NIC to a system:

• Add or expand network ports on an SBC — give a processor card more Gigabit ports without an external adapter.
• Segregate traffic — keep, say, a mission/data network and a maintenance/control network on physically separate ports.
• Redundant paths — run two links to different switches so a single cable or switch failure doesn’t isolate the box.
• Bridge to an external switch or LAN — connect the chassis to the wider network.

EM modules at a glance

The EM family currently has one member, the EM1. It is a fixed-function NIC — there are no model variants to choose between; what you configure is the two ports.

Attribute	EM1
Function	Dual-port Ethernet Network Interface Card
Ports	2, independent
Speed	10/100/1000Base-T, auto-negotiating
Controller	Intel® 82580 GbE
Host interface	Direct-connect PCIe
Magnetics	On-module (NAI)
Generation / form factor	Gen5, 3U or 6U VPX

There is no combination module that bundles an EM Ethernet function with another NAI I/O function.

Using the two ports

The EM1’s two ports are independent network interfaces — they appear to the OS as two separate NICs and are configured separately. That independence is the whole point of the module, and it maps directly to the use cases above:

• Two networks, one module. Put each port on a different subnet to keep two networks physically and logically separate — for example mission data on one port, maintenance/console on the other.
• Redundancy. Cable the two ports to two different switches and let your OS or application fail over between them.
• More of the same network. Bridge or team the two ports under the OS if you simply want more bandwidth or more physical connections to one network.

Whichever you choose, the setup is the same standard per-interface configuration described in Software and Try it below — there is no module-level mode to set first.

Physical setup

Each EM1 port is a standard 10/100/1000Base-T twisted-pair interface. Because the Ethernet magnetics are on the module, the signals that leave the EM1 are the four transformer-coupled differential pairs of each port, ready to route straight to an RJ45 connector. In the EM1 Manual pinout they appear as:

• Port 1 (ETH1): pairs EM1-ETH1-TP0± … EM1-ETH1-TP3±
• Port 2 (ETH2): pairs EM1-ETH2-TP0± … EM1-ETH2-TP3±

Four differential pairs per port is what 1000Base-T uses — all four pairs carry data in both directions. A 10/100Base-T link uses only two of them. So a port that negotiates down to 100 Mb/s on a two-pair cable is normal; you only need all four pairs wired for Gigabit.

Those pairs come out of the module on its I/O connector and route through the motherboard or system’s I/O connector to the chassis Ethernet jacks. The exact pins are per-board, so get them from the manuals; the pattern is the same:

1. Identify the EM1’s slot number on your NAI motherboard or system.
2. The slot brings the module’s pairs out as generic IO# pins on the breakout/connector.
3. Map those IO# pins to the eight pairs — ETH1-TP0±…TP3± and ETH2-TP0±…TP3± — using the pinout in the EM1 Manual (Appendix: Pinout Details) together with your motherboard’s I/O connector tables.
4. Land each port’s four pairs (plus the cable shield) on its RJ45 jack, and run Cat5e/Cat6 to the switch or host.

A couple of things hold for the EM1:

• The two ports are fully independent. ETH1 and ETH2 have their own pairs, their own link, and their own MAC — route and cable them separately. One can be a Gigabit uplink to a switch while the other is a 100 Mb/s point-to-point link to a laptop.
• Auto MDI/MDI-X. The Intel 82580 controller detects and corrects cable crossover automatically, so an ordinary straight-through cable works whether the port connects to a switch or directly to another host — you don’t need a crossover cable for a back-to-back link.

Software

There’s nothing about which software you run that’s specific to the EM1, and there’s no NAI library involved at all. The two ports are owned by your operating system’s standard NIC driver, and which OS you’re on is determined by your motherboard/SBC, not by the EM1.

On Linux, the Intel 82580 is handled by the in-kernel igb driver, which is part of mainline Linux and present in NAI’s PetaLinux SBC images. When the driver binds, the EM1’s two ports show up as two ordinary network interfaces — named by your distro’s conventions (for example eth0/eth1, or predictable names like enp1s0f0/enp1s0f1). From there they behave exactly like any other Ethernet interface:

# See that the controller and its two ports are present
lspci | grep -i 82580            # two Intel 82580 functions, one per port
ip link                          # the two interfaces the driver created

Bringing a port up and giving it an address is the same as for any NIC — assign a static address for a point-to-point or fixed-subnet link, or use your platform’s DHCP/network-config service. The concrete command sequence is in Try it below.

Note

Other operating systems work the same way conceptually: VxWorks, DEOS, and Windows each load their own driver for the 82580 and present the two ports through their normal networking interfaces. Only the configuration commands differ — the EM1 itself is just a standard NIC to all of them.

Where to find what you need:

• Pinout and electrical detail — the EM1 Manual (pinout details, data sheet link).
• Which IO# pins the ports land on — your motherboard or system manual’s I/O connector tables (the EM1 pinout is given with respect to those connectors).
• Powering and networking the SBC itself — Connecting to Boards covers bringing the host board up and reaching it over the network and console.
• Configuring an interface — your OS’s standard networking documentation; the EM1 needs nothing beyond it.

Confirm communication

The EM1 has no NAI built-in test to read — it’s a standard NIC, so “confirm communication” means the same thing it does for any Ethernet port: the driver sees the controller, a port links up, and you can pass traffic. Prove it in three increasing steps, no extra hardware beyond one cable and a peer.

1. The driver bound (no cable needed). If the two interfaces exist, the igb driver attached to the controller:

ip link            # two EM1 interfaces listed => driver bound, ports enumerated

2. A port links (one cable). Connect one EM1 port to any powered switch or to a laptop, and check the link:

ethtool eth0       # "Link detected: yes" plus the negotiated "Speed:" / "Duplex:"

ethtool reports Link detected: yes only when there’s a live partner on the other end, so a single cable to a powered device confirms the PHY, the magnetics, and the cabling at once. The port’s link LED lighting is the same signal in hardware.

3. You can pass traffic (the real test). Give the port an address in the peer’s subnet, bring it up, and ping the peer:

• Wire it: one Cat5e/Cat6 cable from an EM1 port to a host whose IP you know (say 192.168.1.50).
• Set it up:

sudo ip addr add 192.168.1.10/24 dev eth0
sudo ip link set dev eth0 up

• Result: ping 192.168.1.50 returns replies. That round trip exercises the full path — host PCIe, the 82580, the port’s magnetics and pairs, the cable, and the peer — and is the definitive “it works” check.

Repeat on the second port to confirm both. From here, the Try it section turns this into a couple of complete, repeatable setups.

Features

Everything you do with an EM1 happens at the operating-system network layer, not through an NAI API. The capabilities below are what the module’s hardware gives your OS to work with; “how you use it” points at the standard tools (ip, ethtool, your network-config service) rather than at module calls.

Two independent Gigabit ports

What it does / when: the EM1 presents two separate Ethernet interfaces, each with its own MAC address, link, and configuration. Use the pair to put two networks on one module, to run redundant links, or simply to add two ports to an SBC.

Applies to: both ports (ETH1 and ETH2).

How you use it: configure each interface on its own in your OS — different IP/subnet per port for separate networks, or combine them with OS bonding/teaming or a bridge if you want one logical link. Nothing about one port’s configuration affects the other.

Auto-negotiating 10/100/1000Base-T

What it does / when: each port auto-negotiates speed (1000/100/10 Mb/s) and duplex with its link partner, and falls back gracefully — a Gigabit port still links at 100 Mb/s to a 100 Mb/s switch or over a two-pair cable.

Applies to: both ports.

How you use it: normally nothing — negotiation is automatic. If you need to pin a rate (for a finicky partner or a fixed-speed link), force it with ethtool (ethtool -s eth0 speed 100 duplex full autoneg off) and confirm the result with ethtool eth0.

Direct-connect PCIe, optimized for NAI SBCs

What it does / when: the controller connects to the host over a direct-connect PCIe interface — no external adapter or cabling between the NIC and the processor. NAI’s SBCs are designed with dual-port NICs in mind, so the EM1 drops in to extend an SBC’s Ethernet without extra glue.

Applies to: the module’s host interface.

How you use it: there’s nothing to configure — it’s architectural. The host simply sees two more PCIe network functions and loads its driver for them, exactly as it would for an on-board NIC.

Standard driver and OS integration

What it does / when: because the EM1 is built on a standard Intel controller, it is driven by the standard in-tree driver (Linux igb, equivalents elsewhere). Everything your OS and that driver normally offer for a NIC is available — interface statistics, link control, driver tuning, and OS-level networking features like VLAN sub-interfaces, bridging, and bonding.

Applies to: both ports, via the host OS.

How you use it: the usual toolchain — ip/ifconfig for addressing and state, ethtool for link, statistics, and driver settings, and your distro’s network manager or config files to make settings persist. Whatever the driver exposes on your platform, the EM1 inherits by being a standard NIC.

Try it

These are complete, repeatable setups using standard Linux commands (adapt the syntax for VxWorks/Windows). They assume the two ports enumerated as eth0 and eth1 — substitute your actual interface names from ip link.

Try it — a static point-to-point link

Bring one port up on a fixed address and reach a peer — the quickest way to a working link.

sudo ip addr add 192.168.1.10/24 dev eth0    # address in the peer's subnet
sudo ip link set dev eth0 up                  # bring the port up
ethtool eth0                                  # confirm "Link detected: yes" and Speed
ping 192.168.1.50                             # the peer answers

Try it — two ports on two networks

The segregation use case: one port on a mission/data subnet, the other on a separate maintenance network served by DHCP.

# Port 1: static, mission/data network
sudo ip addr add 10.0.0.1/24 dev eth0
sudo ip link set dev eth0 up
 
# Port 2: maintenance network, address from DHCP
sudo ip link set dev eth1 up
sudo dhclient eth1                            # or your platform's DHCP client
 
ip addr show eth0; ip addr show eth1          # each port on its own subnet

The two interfaces route independently, so traffic on one network never crosses to the other unless you explicitly bridge or route between them.

Try it — measure the link

Confirm a port really is running at Gigabit with a throughput test against a peer running iperf3 -s.

iperf3 -c 192.168.1.50                        # expect roughly 940 Mb/s on a clean 1000Base-T link

A result near line rate confirms all four pairs are wired and negotiated correctly; a result capped near ~94 Mb/s is the classic sign the port fell back to 100Base-T (two-pair or marginal cabling) — check ethtool eth0 for the negotiated speed.

Note

Make it persistent. The ip commands above configure the interface until the next reboot. To make a setup survive a restart, write it into your platform’s network configuration (for example /etc/network/interfaces, systemd-networkd, or netplan on Linux) rather than running the commands by hand each time. See your OS’s networking documentation and Connecting to Boards.

Hardware capabilities and status monitoring

This section covers what the hardware provides and what you can monitor. Because the EM1 is a standard NIC, monitoring is done with ordinary OS tools rather than an NAI status API.

What the hardware provides:

• Two 10/100/1000Base-T PHYs with on-module magnetics, each with its own link and activity indication.
• Two MACs on the Intel 82580 controller, presented to the host as two PCIe network functions.
• Auto-negotiation and auto MDI/MDI-X on each port (see Physical setup).
• Standard NIC telemetry — link state, negotiated speed/duplex, and per-interface traffic and error counters, exposed through the OS driver.

Statuses you can monitor:

Status	What it tells you	How to read it
Link state	Whether the port has a live partner	ethtool eth0 (“Link detected”), ip link
Speed & duplex	The negotiated rate (1000/100/10, full/half)	ethtool eth0
Traffic & error counters	Packets, drops, errors, collisions per port	ip -s link, ethtool -S eth0
Driver & controller info	Driver name/version, PCI bus address	ethtool -i eth0, lspci
Physical port identity	Which jack is which interface	ethtool -p eth0 blinks that port’s LED

That last row is worth knowing: ethtool -p eth0 flashes the port’s LED so you can tell which physical jack a logical interface maps to before you commit your cabling.

Common pitfalls

• Link LED on, but no ping. A lit link is layer 1 only. If traffic won’t pass, the addresses are almost always not in the same subnet/mask, or routing/firewall on one side is blocking — check ip addr on both ends first.
• No interface appears. If ip link doesn’t list the ports, the driver didn’t bind — confirm the controller is present with lspci | grep -i 82580 and that the igb module is loaded.
• Wrong port assumption. eth0/eth1 (or predictable names) don’t necessarily match the jack labels in the order you expect. Identify each physical port with ethtool -p before relying on the mapping.
• Stuck at ~100 Mb/s. Gigabit needs all four pairs and Cat5e or better. A two-pair, damaged, or too-long cable silently negotiates down to 100Base-T — confirm with ethtool.
• Duplex mismatch from one-sided forcing. If you force speed/duplex on one end, force it on both (or auto-negotiate on both). A forced/auto mismatch links but produces errors and terrible throughput.
• Settings vanish on reboot. ip addr/ip link changes are runtime-only. Persist them in your OS network configuration or they’re gone after a restart.

Related resources

• EM1 Manual — pinout details, electrical reference, and the data sheet link
• EM1 Data Sheet — full controller and port specifications
• Your motherboard or system manual — the I/O connector tables the EM1 pinout maps onto
• Connecting to Boards — power, network, console, and file transfer to the host SBC