Etherdecode ethernet protocol decoder

Realtime 100Mbit ethernet triggering and decoding, for use with a mixed-signal oscilloscope or logic analyser.
Home FAQs Contact and ordering info Background & future developments



The Etherdecode unit receives and decodes 100Mbit ethernet packets, and converts them to 8-bit parallel byte data at 12.5Mhz for display and analysis using a mixed-signal oscilloscope or logic analyser. It is intended for debugging of systems where the timing and content of ethernet packets needs to be seen in the same context as, or triggered by other signals in the system.
The board comprises a Microchip/Micrel KSZ8061RND PHY plus a small FPGA to provide data formatting. Power is via a USB micro connector, and the board can typically be powered from a scope's front-panel USB connector.


Development and debugging of embedded ethernet interfaces.
Protocol reverse-engineering and development.
Side-channel analysis / timing attacks on ethernet systems.
Characterising ethernet hardware (e.g. switch delays, throughput etc.)

Note this is currently a trial product produced in a limited initial batch to establish whether this is a sufficiently useful device.
Feedback on functionality/usefulness and applications is welcome! 


Output functions 

Outputs are provided on a 20 pin 0.1" pin header, alternate pins being grounds for good signal integrity.

TRIG  : High during the active part of the ethernet packet, from the first byte of the source address to the last byte of the FCS (Frame Check Sequence / CRC).
This can be used both for triggering at the start of a packet, and also measuring (and/or triggering on) the length of packets.

MARK : This triple-function output provides various markers to help identify sections of the packet of interest. See the description of the SW1 and SW2 settings below for details.

D0-7 : These form an 8-bit bus, which when connected to a mixed-signal scope or logic analyser provides realtime ethernet protocol decoding.
In addition, D0 and D1 may be used for triggering to reduce the number of channels required on the MSO or logic analyser, allowing some useful funtionality on 8-bit instruments.
D0 goes high when the PHY's Carrier sense/RX Data Valid (CRS_DV) signal is asserted, indicating the start of the preamble.
D1 goes high when the Start Frame Delimiter (SFD) is detected, indicating the start of the packet payload.

Although D1 or D0 may be used as triggers, note that as these lines will also transition during the packet, appropriate trigger holdoff must be set up to avoid false triggering. Even with holdoff, it may not be practical to eliminate false triggering, for example where there are widely varying packet lengths and/or very short gaps between packets, in which case the TRIG signal will need to be used. 


LED indications

Power : Board has power, obviously.
Link : Lights when PHY has established a link and can receive data
Active : This is the PHY's "Active" indication, which lights when the link is active, and blinks off when a packet is received. It is however of limited use as the activity indication is somewhat decoupled from actual packet timing. You may find it too distracting and want to remove it or cover it up with a marker pen.
Packet : Flashes briefly every time a packet is received. Flash time is 1.2mS (regardless of packet length) and gives realtime indication of activity.
Error : Flashes if the PHY's RXER line is asserted,indicating some sort of problem with the received data. This will flash when connecting/disconnecting and changing the TAP or UNTERM switches

Switch functions

TAP switch  Selects which of the two pairs (Tx or Rx) are monitored. This selects the direction of traffic monitored.
Note that due to auto-MDIX functionality on most devices, the data direction on a particular pair can be hard to ascertain, so trial and error should be used by switching the TAP switch and looking at the content of the packets to establish which way is which.
Set to the Rx position if the TxRx/Rx switch is in the TxRx position. 

TxRx/Rx switch
In the Rx position, only the PHY receiver is connected to the pair selected by the TAP switch and the Tx pair is unused.
In the TxRx position, the PHY's Tx pair is also connected. This is necessary when connecting to a single device, such as a switch port ( as opposed to connecting inline between two devices as aa passive tap). This is necessary for the switch to detect the presence of the PHY and establish the link.
(In TxRx mode, transmit functionalit could potentially be used via the TXE,TX0,TX1 and CLK pins on the PHY signal header.)

SW1 : Count
When SW1 is OFF, D0-D7 output the content of the ethernet packet for normal decode functionality.

When SW1 is ON, D0-D7 output the index of bytes in the packet, 0 representing the first byte of the source address, and MARK outputs bit 8 of the index.
This allows specific byte offsets to easily be found, e.g. for cursor positioning, setting timebase/trigger delays or annotation.
This mode also allows a quick way to verify that the D0-D7 outputs are connected to the correct scope or logic analyser input channels


When SW2 is OFF, the MARK output goes high once per byte in the packet. This can be used for triggering on specific bytes using Nth-edge type trigger modes, clocking a logic state analyser, or to help setting cursors or annotations at specific locations.

When SW2 is ON, the MARK output goes high to coincide with specific fields in the ethernet packet and ipv4 header. See the screenshots page for more details

When SW3 is ON, this disables the PHY's internal receiver termination, to reduce loading in passive tap applications. This should be OFF when using TxRx mode.

This is only used when programming the FPGA via the JTAG header. It must be OFF for normal operation.


Usage examples

1) Passive tap - Traffic in one (switch-selectable) direction is monitored

2) Managed switch with port mirroring. Traffic in either direction on the mirrored port(s) will be displayed ( Some switches may allow selection of traffic direction.)

3) Traffic in each direction is indicated seperately, using two Etherdecode units and 16 scope/analyser channels.


4) Broadcast or transmit-only monitoring.  One-way traffic broadcast or transmitted from a device will be monitored.

Video overview