 |
SatCat5
|
|
SatCat5
|
A major goal of the SatCat5 project is to support a variety of endpoints, from simple microcontrollers to a full-fledged PC, all connected to the same Ethernet network.
To accomplish this, it supports a variety of media and physical-layer options that aren't used in IEEE 802.3 Ethernet. These options are typically lower speed (1-20 Mbps), but use physical layer protocols that are more amenable to use with simple microcontrollers. All interfaces transmit and receive standard Ethernet Frames.
The following is a complete listing of supported interfaces, the generic VHDL interface for integrating custom port types, plus further information on how to use each option.
The nontraditional interfaces are IEEE 802.3 compliant, except:
Runt frames may have a payload as short as zero bytes; all other fields are required as normal. This minimizes unnecessary per-packet overhead, which would otherwise be costly at these relatively low bit-rates.
The switch will preserve runt frames as-is when relayed to supported interfaces. It also zero-pads the payload field before transmission to traditional media without runt packet support. As such, runt packets should never use the EtherType field as a length, since the length may change. In addition, higher-layer software must be prepared for the length to change, since packets switched over mixed networks may be zero-padded.
To provide framing information, these interfaces are SLIP encoded (IETF RFC 1055). This provides indication of frame boundaries, and may also be used to indicate idle periods. When transmitting, Ethernet frames should be calculated normally, including the FCS. The entire frame is then SLIP-encoded just before transmission to the switch.
When external connectors are used, we recommend compatibility with Digilent's 6-pin PMOD standard, which is widely supported by many embedded development platforms. This makes it easy to buy compatible equipment, such as USB-UART adapters, from a variety of vendors. When smaller connectors are required, we recommend any 6-pin wire-to-board connector, such as the Molex Pico-Lock series. In such cases, the connector should be keyed and pin-order should match the PMOD specification where practical.
The Inter-Integrated Circuit (I2C) bus uses two wires for bidirectional communication:
Both are bidirectional open-drain signals that require an external pullup resistor, typically 1 to 4 kOhm depending on application. For more details, refer to NXP UM10204. All SatCat5 I2C interfaces support clock-stretching, but do not include collision-detection or multi-controller support.
Note that I2C has limited speed and cannot support full-duplex transfers. It is included in SatCat5 for completeness, but SPI and UART interfaces are generally preferred.
In most cases, the SatCat5 Ethernet switch should act as the peripheral. (i.e., The remote endpoint, typically a microcontroller, is the I2C controller and sets the baud rate.) However, support for the opposite configuration is also provided. In either case, the address of the peripheral can be set at build-time or through ConfigBus commands.
To transmit, the controller must execute an I2C write to the designated address, followed by any number of data bytes. After the address, written bytes are treated as a contiguous SLIP-encoded byte stream. I2C transactions are not used to indicate frame boundaries.
To receive, the controller must execute an I2C read to the designated address, followed by any number of data bytes. As above, read bytes are treated as a contiguous SLIP-encoded byte stream. Peripherals with no outgoing data should repeatedly send the SLIP inter-frame token (0xC0).
For more information on this signal naming convention, refer to this OSHWA resolution.
The Serial Peripheral Interface uses four wires for bidirectional communication. By convention, the "controller" is the clock-source:
The Ethernet switch should usually act as the SPI clock sink and drives CIPO. In this case, the remote endpoint (microcontroller, payload, etc.) should generate the clock and drive CSb and COPI. However, support for the opposite configuration is also provided.
All clock-phasing modes are supported, but SPI Mode 3 is preferred. Other modes can be set with ConfigBus commands, if the design includes this feature. The maximum supported bit-rate depends on the internal reference clock; refer to io_spi_clkin for details.
In SPI, transmitting and receiving data occurs simultaneously. All exchanges are byte-aligned, and transmitted MSB-first per SPI convention.
The COPI and CIPO signals are each treated as a contiguous, SLIP-encoded byte stream. Chip-select is not used to indicate frame boundaries.
To transmit, the endpoint should lower CSb, and strobe SCK eight times to send each byte on COPI. Note, however, that the send/receive transactions are inseparable. As such, the endpoint must also inspect the received bytes for SLIP-encoded frames. If there is no data to send, the CIPO stream will simply be a repeating SLIP inter-frame token (0xC0). Note that packets from the switch may start at any point in the CIPO stream; they are not constrained to CSb or COPI frame boundaries.
To receive, the endpoint should simply send repeating SLIP inter-frame tokens (0xC0) on COPI until the received stream emits two consecutive inter-frame tokens, indicating idle. This action should be performed periodically, since there is no explicit "data-ready" indicator.
For more information on this signal naming convention, refer to this OSHWA resolution.
As the name implies, this UART interface uses four wires for bidirectional communication:
Please note that naming conventions for Tx/Rx signals in this document are made with respect to the network endpoint. In the VHDL source code, the opposite convention is used.
UART format is 1 start bit, 8 data bits, 1 stop bit, no parity. By convention, data is always sent LSB first. Preferred baud rate is 921,600, but other rates are supported up to ~4 Mbps. The baud rate can be changed through ConfigBus commands.
The CTSb and RTSb lines are used for flow control. RTSb is driven by the endpoint, and indicates that the switch is permitted to send new data. (If the endpoint is always ready to receive new data, this signal may simply be tied to ground.) This essentially matches the RS-232 standard when the network endpoint is the DTE and the switch is the DCE. CTSb is driven by the switch. It indicates that there is new data ready to be sent. This usage does NOT match RS232 convention, but this pin is used so that most off-the-shelf USB-UART devices can read the signal. If this signal is not required, it may simply be ignored.
The TxD and RxD streams are SLIP-encoded to indicate frame boundaries. Idle tokens are not required.
If flow control is not required, then this connection type can be used for switch-to-switch connections or device-to-device connections. Simply tie flow-control inputs to ground and cross-wire the TxD and RxD pins.
This variant of the UART interfaces uses only two wires for bidirectional communication:
Please note that naming conventions for Tx/Rx signals in this document are made with respect to the network endpoint. In the VHDL source code, the opposite convention is used.
UART format is 1 start bit, 8 data bits, 1 stop bit, no parity. By convention, data is always sent LSB first. Preferred baud rate is 921,600, but other rates are supported up to ~4 Mbps. The baud rate can be changed through ConfigBus commands.
Instead of RTSb/CTSb, this variant uses a query/response model for flow control. A "query" occurs any time the endpoint sends an SLIP inter-frame character (0xC0). Whenever this token is received, the switch will respond the next complete frame (if one is queued), or a simple 0xC0 token to indicate that no data is available.
As with SPI, it is important to issue queries periodically to ensure data from the switch is received promptly.
The auto-sensing port type can automatically switch between the following modes:
This software provides support for a number of "traditional" Media Independent Interfaces (xMII) that are intended to be fully IEEE 802.3-2018 compliant.
In COTS devices, xMII are typically used to connect a switch or endpoint (MAC) to a physical-layer transceiver (PHY). Various transceiver ASICs, such as the AR8031, are available to send and receive signals over twisted-pair copper, fiber, etc. over longer distances. However, over short distances the xMII interface can be used directly, in the so-called "MAC to MAC" mode.
For legacy compatibility, these interfaces include preambles, start-of-frame tokens before each frame, and an inter-frame gap of at least 12 bytes after each frame.
Support for jumbo frames is optional, specified at build time. If enabled, buffer sizes must be increased accordingly.
MAC-to-MAC interfaces are typically provided over a backplane; we do not currently recommend any specific connectors or pinouts. We may revisit this decision in the future.
The Reduced Media Independent Interface (RMII) uses 7-9 pins:
The interface can operate at 10 or 100 Mbps and will auto-sense the appropriate rate.
In MAC-to-MAC mode, TX* are cross-coupled to the corresponding RX* signals. RXER is not required in this mode; tie those inputs to ground as needed.
The provided VHDL allows the clock to be sourced by an external clock, by the endpoint, or by the switch, configurable with an FPGA rebuild.
The Reduced Gigabit Media Independent Interface (RGMII) uses 12 pins:
The interface can operate at 10, 100, or 1000 Mbps and will auto-sense the appropriate rate.
In MAC-to-MAC mode, TX* are cross-coupled to the corresponding RX* signals.
The RGMII standard requires a 2.0 nsec delay of the clock signal, relative to the Tx and Rx data. Historically this has been provided by a serpentine trace on the PCB; however this is burdensome to the hardware designer. As such, many implementations include options to delay the clock internally, for either transmit, receive, or both. (This includes the SatCat5 switch FPGA.) It is important to ensure that this delay be applied exactly once in both directions.
The Serial Gigabit Media Indendent Interface (SGMII) uses 4 pins. (i.e., One differential LVDS pair in each direction.)
Each LVDS pair must be impedance-controlled (100-ohm differential) and terminated at the receiving end. (Preferably inside the receiving device; most FPGAs provide this capability.) Clock recovery must be performed by each LVDS receiver. To facilitate this, allow optional AC-coupling, provide framing, and exchange link-status metadata, the signal is 8b/10b encoded. As such, the LVDS line-rate of 1250 Mbaud supports user transfer rates up to 1000 Mbps.
The SGMII standard operates at a fixed line rate of 1250 Mbaud. The interface can operate at 10, 100, or 1000 Mbps by repeating data tokens. The SatCat5 switch will auto-sense the appropriate rate.
The Gigabit Media Independent Interface (GMII) uses 24 signals, although COL and CS are not supported by the SatCat5 port. The 22 requried signals are:
GMII is not widely used for MAC to PHY interfaces due to its high pin count, but it is common between cores within FPGAs. The SatCat5 GMII port is intended to connect third-party Ethernet IPs, such as the Xilinx Zynq-7000 PS Ethernet MAC, to a SatCat5 switch or network. Support for use with external GMII interfaces may be added in a future release.
If none of these interfaces matches your needs, you can define custom ports that interface with the SatCat5 switch.
The SatCat5 port interface requires three VHDL records defined in "src/vhdl/common/switch_types.vhd". The "port" variant is used for ports from 0-1 Gbps. The "portx" variant is used for ports from 2-10 Gbps.
port_rx_m2s or port_rx_m2sx = Received data (Ethernet MAC to switch)port_tx_s2m or port_tx_s2mx = Transmit data (Ethernet switch to MAC)port_tx_m2s or port_tx_m2sx = Received data (Ethernet MAC to switch)In all cases, the data stream must contain the entire Ethernet frame with header, data, and FCS. However, it must not contain additional data from the physical coding sublayer (PCS), such as preambles or the start-of-frame delimiter (SFD).
The "port" signals are defined as follows:
port_rx_m2s/clk is the clock for all signals in the "rx_m2s" record.port_rx_m2s/data contains each incoming received byte.port_rx_m2s/last indicates the last byte in each Ethernet frame.port_rx_m2s/write is the write-enable strobe for data and last.port_rx_m2s/rxerr should be asserted for serious PHY or MAC errors.port_rx_m2s/rate is the estimated line-rate. Use the get_rate_word function.port_rx_m2s/status is a set of user-defined status flags.port_rx_m2s/tsof is the optional PTP start-of-frame timestamp.port_rx_m2s/tfreq is the optional Doppler-PTP frequency offset.port_rx_m2s/reset_p indicates this port is held in reset.port_tx_m2s/clk is the clock for all signals in the "tx_s2m" and "tx_m2s" records.port_tx_s2m/data contains each outgoing transmit byte.port_tx_s2m/last indicates the last byte in each Ethernet frame.port_tx_s2m/valid is the AXI-stream "TVALID" flow-control strobe.port_tx_m2s/ready is the AXI-stream "TREADY" flow-control strobe.port_tx_m2s/pstart is the optional PTP safe-to-start strobe (usually '1').port_tx_m2s/tnow is the current PTP timestamp. (Use TSTAMP_DISABLED if unused.)port_tx_m2s/tfreq is the optional Doppler-PTP frequency offset.port_tx_m2s/txerr should be asserted for serious PHY or MAC errors.port_tx_m2s/reset_p indicates this port is held in reset.The Rx and Tx streams denote incoming and outgoing data, with respect to the switch_core block. The Rx stream uses a simple write-enable strobe with no back-pressure or flow-control. The Tx stream uses AXI-stream flow-control semantics (TVALID/TREADY). However, the SatCat5 switch also guarantees continuity within each frame. i.e., Once TVALID is asserted for the first byte in a frame, TVALID will not be deasserted until the end of that frame.
The PSTART, TSOF, and TNOW fields are used for IEEE1588 Precision Time Protocol (PTP). They are used to timestamp packets as they enter and leave the switch. If this feature is not required, drive PSTART to '1' and TSOF/TNOW to TSTAMP_DISABLED. Otherwise, use the "ptp_counter_sync" block to generate the timestamps. If the transmit and receive clock domains are separate, instantiate one synchronizer for each. For more information regarding the PSTART strobe, refer to "ptp_egress.vhd". (If in doubt, tie this signal to '1'.)
The Rx and Tx TFREQ fields are used for Doppler-PTP, an experimental extention that adds frequency-offset metadata to PTP messages. This allows measurement of motion-induced Doppler effects for mobile PTP support. Ports that do not support PTP or Doppler-PTP should tie this field to TFREQ_DISABLED.
The "portx" signals are the same, except that "data" is 64 bits wide and "last" is replaced by "nlast". The data word is always big-endian (most significant byte first) and partial words are left-packed. If "nlast" is zero, the data word is not the end of the frame. Otherwise, "nlast" indicates the number of remaining bytes (1-8). Leftover bytes are discarded, and the next frame starts with the MSB of the next data word.
Copyright 2019, 2021, 2024 The Aerospace Corporation
This file is a part of SatCat5, licensed under CERN-OHL-W v2 or later.
You may redistribute and modify SatCat5 and make products using it under the weakly reciprocal variant of the CERN Open Hardware License, version 2 or (at your option) any later weakly reciprocal version.
SatCat5 is distributed WITHOUT ANY EXPRESS OR IMPLIED WARRANTY, INCLUDING OF MERCHANTABILITY, SATISFACTORY QUALITY, AND FITNESS FOR A PARTICULAR PURPOSE. Please see (https:/cern.ch/cern-ohl) for applicable conditions.
1.9.1