Why Does 10BASE-T1S Use PLCA?

Traditional point-to-point Automotive Ethernet connects two endpoints across a dedicated link. 10BASE-T1S introduces a different topology by allowing multiple nodes to communicate across one shared multidrop segment.

This is particularly useful for lower-bandwidth automotive devices such as sensors, mirrors, lighting, and door modules, where requiring a dedicated Ethernet link and switch port for every endpoint can add wiring, connectors, and infrastructure.

Sharing the network creates another challenge, however: multiple nodes need a coordinated way to determine when they can transmit without interfering with one another. For multidrop operation, 10BASE-T1S can use Physical Layer Collision Avoidance (PLCA) to provide that structured access to the shared medium.

How Does PLCA Work?

PLCA organizes access to the shared 10BASE-T1S segment around a repeating sequence of transmit opportunities.

Each participating node is configured with a PLCA Node ID. Node ID 0 has a distinct role because it generates the BEACON that marks the beginning of each PLCA cycle.

After the BEACON, the network progresses through transmit opportunities associated with the configured Node IDs:

BEACON → TO0 → TO1 → TO2 → … → next BEACON

Each station knows its own Node ID and locally follows the transmit-opportunity sequence so it can determine when it is permitted to access the shared medium.

An important distinction is that Node ID 0 does not individually grant permission to each node. Its BEACON establishes the synchronization point for the cycle. The participating stations then use their own configured Node IDs to determine where their transmit opportunities occur within that sequence.

The IEEE 802.3cg 10 Mb/s Single Pair Ethernet Task Force developed the 10BASE-T1S standard and its PLCA access mechanism.

What Is a PLCA Transmit Opportunity?

A transmit opportunity is the point in the PLCA sequence associated with a particular Node ID. When that opportunity arrives, the corresponding node can transmit if it has data waiting.

This scheduled access is what allows multiple devices to share the same network segment without relying solely on competing for access whenever they have traffic to send.

From an implementation perspective, supporting PLCA therefore involves more than normal Ethernet frame handling. The implementation needs to track information such as:

• BEACON detection
• Configured Node ID
• Current position within the transmit-opportunity sequence
• Whether PLCA synchronization remains valid
• Node ID 0 versus non-zero Node ID behavior, where supported
• Transitions when PLCA synchronization is lost

These states and transitions are also important verification targets because incorrect timing can result in a node transmitting when the shared network state does not permit it.

What Is Special About Node ID 0?

Node ID 0 has a distinct role in PLCA: it generates the BEACON used to establish the beginning of the transmit-opportunity cycle.

This role should not be confused with continuously assigning transmission slots to other nodes. Once the BEACON establishes the cycle, each participating station tracks its own position based on its Node ID.

This distinction also matters when discussing failure behavior. Standard PLCA ties BEACON generation to Node ID 0. If Node ID 0 becomes unavailable, another node should not automatically be assumed to take over that role.

Some implementations may include additional host-controlled or vendor-specific recovery mechanisms, but those should be verified according to the specific implementation rather than treated as a standard automatic re-election of the BEACON-generating role.

What Happens If PLCA Synchronization Is Lost?

Nodes rely on PLCA synchronization to determine where they are within the transmit-opportunity sequence. If that synchronization is lost, a node can no longer safely continue relying on its previously tracked PLCA timing.

The implementation needs to recognize the loss of synchronization and transition according to its supported behavior. The 10BASE-T1S controller case study developed by SmartDV includes an implementation-specific fallback to CSMA/CD when PLCA synchronization is lost, followed by verification of recovery and resynchronization behavior.

This transition is an important corner case because the controller must avoid continuing to transmit based on stale assumptions about the PLCA cycle.

For a deeper discussion of this condition, see What Happens When PLCA Synchronization Is Lost in a 10BASE-T1S Network?

Why Is PLCA Important for 10BASE-T1S Verification?

PLCA changes the verification problem because correct behavior depends on the state of the entire shared segment, not simply whether the DUT can generate and receive valid Ethernet frames.

A frame might be completely valid from a protocol-format perspective but still represent incorrect behavior if the DUT transmitted it outside the appropriate PLCA transmit opportunity.

Verification therefore needs visibility into several conditions at the same time:

• Which Node ID the DUT is using
• Whether the DUT is operating as Node ID 0 or a non-zero Node ID
• Where the network is within the PLCA cycle
• Whether BEACON synchronization is valid
• Which nodes currently have traffic queued
• Whether nodes are becoming active or being removed from the segment
• Whether a failure or transition condition is active

These combinations are why 10BASE-T1S verification is more complex than point-to-point Ethernet verification.

How Can Verification Teams Test PLCA Behavior?

A representative verification environment can place the DUT on a shared multidrop segment alongside several configurable peer agents.

A protocol monitor observes the shared bus and provides information to verification components such as a PLCA-aware scoreboard and protocol assertions. The scoreboard can compare expected transmit behavior against what actually occurs across the network, while assertions continuously check critical PLCA requirements.

Functional coverage can then measure combinations involving Node ID, DUT role, transmit-opportunity position, synchronization state, and injected fault conditions rather than simply tracking individual node states.

Verification teams should also deliberately exercise corner cases such as:

• BEACON loss
• PLCA synchronization loss
• Node activation, removal, and resynchronization events
• Transmit-opportunity edge timing
• Invalid configurations such as duplicate Node IDs
• Recovery and resynchronization sequences

For more detail on the verification methodology, see How Do Verification Teams Test 10BASE-T1S Multidrop Arbitration?

How Does PLCA Support the Automotive Ethernet Last Mile?

10BASE-T1S allows Ethernet to extend into portions of the vehicle where a dedicated high-speed point-to-point connection may not be necessary for every endpoint.

A zonal controller, for example, can support a higher-bandwidth 100BASE-T1 connection for a device such as a camera while a shared 10BASE-T1S segment connects lower-bandwidth sensors, mirrors, lighting, and door modules.

PLCA is important to this model because it provides the coordinated access needed for those devices to share the multidrop segment while maintaining structured transmission behavior.

For the broader implementation and verification discussion, read 10BASE-T1S Verification for Automotive Ethernet.

How SmartDV Supports 10BASE-T1S Verification

SmartDV provides Design IP and Verification IP for Ethernet and other advanced interface protocols used in SoC, ASIC, and FPGA development.

SmartDV’s Ethernet portfolio includes Ethernet 10BASE-T1S PCS Design IP as well as Ethernet BASE-T Verification IP, supporting engineering teams working with Ethernet implementations across design and verification environments.

For teams validating multidrop Ethernet behavior, SmartDV’s Ethernet BASE-T VIP provides reusable protocol-aware verification capabilities for BASE-T verification environments.

Verify PLCA and 10BASE-T1S with SmartDV

PLCA makes shared-medium 10BASE-T1S operation possible by coordinating transmit opportunities across participating nodes, but that coordination also introduces synchronization, timing, role, and cross-node behaviors that need to be verified carefully.

» Contact SmartDV to discuss 10BASE-T1S, PLCA, Automotive Ethernet, Design IP, or Verification IP requirements for your next SoC, ASIC, or FPGA project.