Francisco E. Alderete

Ethernet Datapath Bring-Up — 10–100G and MLDs (200G–800G)

Impact

These tests ensure that required datapaths are brought up automatically for subsystem engineers to expand testcases for design robustness, as well as SoC teams being able to use these datarates with minimal to no sub system configuration knowledge.

Brought up an end-to-end Ethernet datapath subsystem across multiple data rates including 10–100G single-lane configurations and multi-lane designs (MLDs) ranging from 200G to 800G. The goal was to achieve stable link-up and verified packet transfer across the subsystem.

Subsystem Components

• MAC
• PCS
• SerDes
• BFMs (Vendor/Internal)
• Glue logic interconnect

Challenges Encountered

• Glue logic configuration issues (incorrect mux selections and interconnectivity bugs)
• Programming IP components (MAC and PCS) while interpreting incomplete or ambiguous databook documentation
• BFM configuration mismatches and incorrect DUT/BFM connectivity
• Alignment marker mismatches between PCS and BFM configurations
• SerDes programming dependencies on firmware availability

Bring-Up Process

• Program glue logic controlling datapath routing
• Configure MAC and PCS IP blocks
• Configure BFMs on both ends of the subsystem
• Program SerDes via firmware or UVM sequences when firmware was unavailable

Key Indicators for Successful Bringup

• PCS link-up between SerDes and PCS
• Link-up signals observed in BFMs
• MAC link status signals indicating operational datapath

Validation

• Once link-up was achieved, packets were transmitted across the subsystem
• Scoreboards and monitors verified packet integrity
• Loopbacks at the PCS boundary enabled rapid iteration during early bring-up

Automation Impact

• After successful bring-up, subsystem configuration was encapsulated into reusable scripts and sequences
• This reduced complex setup procedures into a single command-line invocation
• Enabled other engineers on the team to rapidly run tests at specific data rates without needing deep configuration knowledge
• Also enables teams in SoC at higher levels of the design to run this component as a black box with minimal input for them, since the entire bringup is automated and validated to send packets.
• Accelerated validation of additional subsystem features by automating the bring-up configuration
• SerDes bring-up is typically the longest simulation phase, so early PCS boundary loopbacks were used to accelerate debug cycles before full SerDes validation.

PCS Error Injection and Error Counter Validation

Impact

These verification tests ensure that the same hardware error reporting mechanisms used during simulation can be trusted by post-silicon validation teams during hardware bring-up and lab debugging.

Developed verification stimulus to validate PCS error detection, correction, and reporting mechanisms. This testing ensured that hardware error counters, interrupts, and recovery behavior function correctly and can be relied upon by post-silicon validation teams during lab bring-up.

Verification Goal

• Verify PCS error detection and classification mechanisms
• Validate correctable and non-correctable error counters
• Ensure subsystem and SerDes interrupts trigger correctly
• Confirm link stability and recovery after error conditions

Error Injection Techniques

• Used vendor BFM capabilities to inject PCS-level errors
• Injected symbol errors
• Injected invalid alignment markers
• Injected sync header errors

Custom Stimulus

• Generated additional stimulus to flip bits at the SerDes input interface
• Induced PCS errors to validate error counters
• Validated both correctable and non-correctable error classifications
• Triggered PCS link drops and verified correct link recovery behavior

Interrupt Validation

• Verified subsystem interrupts were triggered when error conditions occurred
• Validated interrupt masking behavior
• Confirmed SerDes interrupt generation when enabled

Vendor Collaboration

• Worked directly with vendor engineers to debug and configure BFM error injection features
• Coordinated across multiple time zones (US and India)
• Resolved BFM configuration issues and clarified vendor documentation

SerDes Latency Verification

Impact

• Discovered a critical bug in the SerDes latency reporting logic
• The issue caused incorrect latency values to be generated by the SerDes RTL
• Fix prevented incorrect latency reporting to downstream validation teams and customers

Verified the SerDes contribution to end-to-end Ethernet packet latency by validating internal latency measurement registers used by the subsystem. These latency values are exported to post-silicon validation teams and ultimately used by customers as part of the total datapath latency equation.

Problem Context

• Total subsystem packet latency includes contributions from PCS, and SerDes
• SerDes latency is captured internally in RTL and exported through subsystem registers
• These values must be accurate and within defined tolerance ranges

Verification Methodology

• Captured internal SerDes latency values directly from RTL signals
• Used UVM assigns to monitor two key internal signals representing latency timing points
• Computed expected latency using signal sampling and arithmetic in the testbench
• Configured subsystem registers controlling latency measurement sample rate
• Sample rate varies depending on datapath data rate
• Issued subsystem register resets to ensure a clean measurement window
• Used AI generated scripts to export results to a management readable format in the case of a bug found this was extremely useful for communicating the issue and accelerating resulotion.

Validation Process

• Compared internally observed RTL latency against the latency value reported by subsystem registers
• Verified both values remained within the defined tolerance window
• Test executed across all supported datapath data rates

Key Technical Challenges

• Routing the correct clocks into the testbench so sampling occurred at the same rate as RTL
• Coordinating between verification, subsystem RTL, and SerDes RTL teams
• Ensuring latency sampling logic behaved correctly across multiple data rates

Gate-Level JTAG and DFT Verification

Impact

Identified a critical issue in a third-party DFT-inserted gate-level netlist during JTAG verification, preventing incorrect silicon behavior from propagating into tapeout.

Problem Context

• Received a DFT-inserted gate-level netlist from an external vendor responsible for scan and test insertion
• Verification required validating JTAG functionality and DFT infrastructure before silicon tapeout
• Testing involved exercising scan chains, flash programming interfaces, and memory test infrastructure

Verification Work

• Developed UVM stimulus to drive JTAG operations through external pins
• Validated scan chain integrity and proper scan shifting behavior
• Verified internal flash programming sequences through JTAG interfaces
• Executed MBIST operations across embedded memories
• Triggered fuse execution sequences through JTAG-controlled flows

Power Domain Validation

• Brought up power islands in the design to enable MBIST and fuse execution
• Verified proper power-up sequencing across the subsystem
• Ensured correct behavior when transitioning between powered and unpowered regions

Debugging Approach

• Traced gate-level netlist connectivity to isolate incorrect behavior
• Analyzed scan chain behavior and JTAG state transitions
• Worked through the DFT-inserted logic to identify discrepancies between expected and implemented behavior

This work validated critical DFT infrastructure prior to tapeout and ensured the design could be reliably tested through JTAG and memory test mechanisms in post-silicon environments.