Industrial Ethernet Slave SoC for Real-Time Field Devices
← Back to: Industrial Ethernet & TSN
H2-1. Definition & Scope Guard (What this page covers)
Intent
Lock the page boundary so the content stays centered on device/slave SoC architecture: hardware offload, dual-port switching behavior, determinism evidence, and debug hooks. Topics that belong to sibling pages are referenced only as “go-to links”, not expanded into new knowledge domains.
In-scope (deep dive depth)
- Slave SoC data plane: Port A/B ingress, classification, buffering/queues, forwarding vs local delivery, and where tail latency forms.
- HW protocol offload points (PROFINET / EtherCAT / EtherNet/IP(CIP) / SERCOS III): what is accelerated in silicon vs what remains firmware/software responsibility.
- Dual-port switching inside a device: cut-through vs store-and-forward, queue separation, and worst-case delay bounding (not just averages).
- Determinism evidence: timestamp tap locations, in-chip time path, queue jitter contributors, and budget-style verification.
- Debug hooks: counters, event logs, black-box buffers, loopback/self-test, and field-forensics design hooks.
Out-of-scope (link out only; no expansion)
- PHY / magnetics / SI / EMC / surge/ESD layout — handled in the PHY + protection pages; this page references only integration hooks and measurable symptoms.
- TSN switch deep mechanisms (Qbv/Qci/Qav, GCL, admission control) — belongs to TSN switch/bridge; this page covers only device internal dual-port forwarding bounds.
- PTP/SyncE/WR theory and topology calibration — belongs to timing & sync; this page focuses on timestamp tap placement and in-chip error terms.
- PoE/PoDL power, classification, thermal design — belongs to PoE/PoDL; this page references only logging/telemetry hooks relevant to forensics.
- Protocol spec clause-by-clause explanations — belongs to Industrial Ethernet stacks; this page abstracts to “offload points + evidence”.
- Ring redundancy protocol deep dive (MRP/HSR/PRP) — belongs to redundancy pages; this page keeps scope to dual-port switching impact and measurables.
Deliverable: Page boundary map (Topic → owner page)
Use this map as a scope brake: if content starts to drift into a sibling domain, stop and link out.
| Topic | This page depth | Output here | Sibling page |
|---|---|---|---|
| HW protocol offload | Offload points, HW/SW split, evidence hooks | Protocol×offload matrix | Industrial Ethernet stacks |
| Dual-port switching | Device internal forwarding bounds | Per-hop latency/jitter budget skeleton | TSN switch / bridge (deep) |
| Timing & timestamps | Tap point selection + in-chip error terms | Timestamp path map + error budget template | Timing & sync (deep) |
| PHY & EMC robustness | Symptoms + integration hooks only | Bring-up checklist pointers | Ethernet PHY / protection |
| PoE/PoDL power | Telemetry hooks only | Black-box fields for power events | PoE / PoDL |
Diagram: Page boundary map
Cross-page pointers (link out only)
- PHY/EMC/Protection: go to the PHY and co-design protection pages.
- TSN windows/filters/admission: go to TSN switch/bridge pages.
- PTP/SyncE/WR deep timing: go to timing & sync pages.
H2-2. Where a Slave SoC sits in an industrial device (Roles & use cases)
What this section delivers
- A system position model: controller → line/ring → field devices (device-side only).
- A decision rationale: why real-time networking requires hardware data-plane guarantees, not just “more CPU”.
- A constraints view: use-cases expressed as measurable inputs (cycle time, jitter bound, port role, observability).
Why a Slave SoC instead of a plain MCU
- Worst-case bound matters: cyclic control needs bounded delay/jitter, not best-effort averages. Queueing, DMA contention, and ISR latency must be engineered into a budget.
- Through-forwarding exists in the device: in line/ring deployments the device can become an internal forwarding hop; dual-port switching behavior becomes a determinism term.
- Field forensics requires silicon hooks: intermittent faults are closed by counters, timestamped event logs, and black-box capture—designed in upfront, not added after failures.
Minimal need-check (fast triage)
- A bounded cycle/jitter requirement exists (not just “works most of the time”).
- The device must forward traffic in line/ring (dual-port is active, not decorative).
- Troubleshooting needs timestamped evidence (counters/logs) to avoid “cannot reproduce”.
Device-side use cases expressed as constraints (inputs for selection)
Each use-case is described by the smallest set of measurable inputs that drive architecture and verification. Values are shown as placeholders (X) and should be replaced by project targets.
Remote I/O node
- Traffic pattern: cyclic I/O + bursts of diagnostics.
- Determinism: cycle time X ms; allowed jitter X µs (worst-case bound).
- Port role: end-node or line device (forwarding may be required).
- Observability must-haves: per-port CRC/drop counters + timestamped power/link events.
Servo drive / motion node
- Traffic pattern: tight cyclic control; strict sync; limited tolerance to tail latency.
- Determinism: bounded hop delay; timestamp tap point selection is a first-order error term.
- Port role: commonly line/ring pass-through in multi-axis chains.
- Observability must-haves: queue overflow counters + cycle-miss event capture (black-box).
Robot end-effector / tool node
- Traffic pattern: mixed cyclic + event-driven; sensor bursts can coincide with control windows.
- Determinism: isolation between cyclic and acyclic channels via queue separation.
- Port role: often end-node; dual-port used for daisy-chain wiring flexibility.
- Observability must-haves: event logs correlated with temp/power to explain “only happens in the field”.
Vision trigger / time-aligned sensor node
- Traffic pattern: time-aligned triggers + payload bursts; timestamps must stay meaningful under load.
- Determinism: timestamp tap point and queue jitter dominate alignment error budgets.
- Port role: end-node or line node depending on cabling; forwarding behavior must be bounded.
- Observability must-haves: timestamp statistics + packet delay variation counters (derived from taps).
Diagram: Factory cell (controller → line/ring → devices)
Engineering output (used later for selection and verification)
- Use-case constraints become inputs for a deterministic budget (latency/jitter) and a measurable evidence plan (counters/logs).
- Dual-port role (end vs line/ring) determines whether internal forwarding is a first-order latency term.
- Observability must be specified upfront as a requirement, not treated as a debugging afterthought.
H2-3. Architecture: Control plane vs Data plane (Why HW acceleration matters)
Intent
Establish a strict responsibility split: the data plane is built for bounded, per-packet work (worst-case), while the control plane owns configuration, object models, diagnostics, and lifecycle. This split is the reason hardware acceleration improves determinism, not just throughput.
Data path (bounded pipeline)
The data plane is a fixed pipeline where each stage must have measurable behavior. The goal is to prevent “average good, worst-case bad” outcomes by isolating cyclic traffic from bursts and by keeping queueing effects observable.
Pipeline stages
- RX parse → extract header fields into compact metadata.
- Classification → map frames into traffic classes (cyclic / acyclic / diagnostics / update).
- Queue / buffer → isolate and bound contention; track occupancy and drop reasons.
- Schedule → select TX order (priority/time-aware policy configured by control plane).
- TX → transmit through Port A / Port B or deliver locally.
Why HW matters here
- Worst-case containment: fixed pipelines and dedicated queues prevent ISR/DMA contention from turning into tail-latency spikes.
- Traffic separation: cyclic flows stay protected even when diagnostics or firmware updates burst.
- Evidence-first design: per-stage counters and timestamp taps make determinism verifiable and debuggable.
Control path (policy + lifecycle)
The control plane owns the “what and why”: configuration, object models, diagnostics semantics, and safe update workflows. It programs the data plane via versioned rules and consumes data-plane evidence via snapshots and event logs.
- Stack configuration: traffic classes, queue maps, time policies, forwarding rules.
- Object model: device identity, parameters, I/O mapping, status surfaces.
- Diagnostics: consistent fault codes, counter snapshots, correlation fields.
- Firmware update: versioning, rollback points, and traceable update events.
Scope brake
This page focuses on in-chip control/data split and evidence hooks. PHY SI/EMC, TSN/PTP topology rules, and spec clauses are linked out to sibling pages.
Deliverable: Responsibility split (HW vs firmware vs host MCU)
The table below defines a “contract” and the measurable evidence expected from each owner.
| Function | HW (SoC) | Firmware (SoC) | Host MCU | Evidence |
|---|---|---|---|---|
| RX parse + metadata | Fixed pipeline stage | Rules programming | N/A | Parse error counters |
| Classification | Fast match + tagging | Policy mapping | N/A | Per-class counters |
| Queues + buffering | Dedicated queues | Threshold config | N/A | Watermarks + drop reasons |
| Scheduling / shaping | Deterministic selector | Policy apply + versioning | N/A | Schedule miss counters |
| Timestamp taps | Tap + capture unit | Timebase control | Use timestamps | Tap offset/jitter stats |
| Diagnostics + black-box | Counters + ring buffer | Fault codes + snapshots | System correlation | Event logs + counters |
Diagram: SoC internals (control plane vs data plane)
H2-4. Protocol offload blocks (PROFINET / EtherCAT / EtherNet-IP / SERCOS III)
Intent
Explain what is accelerated in hardware without expanding into protocol clauses. Each stack is mapped to the same offload primitives (parse, classify, queues, scheduling, timestamp taps, event/timer), plus the software-owned parts (object model, diagnostics semantics, security hooks, update).
Unified template (applied to all four protocols)
- Real-time driver: cyclic / sync style (directional, not clause-level).
- HW offload points: parse, cut-through, event/timer, sync capture, cyclic/acyclic split.
- SW still owns: object model, diagnostics, security/update workflows.
- Pitfalls + evidence: each pitfall is paired with “must-measure counters”.
Scope brake
The section stays at the “offload points + evidence counters” level. Certification procedures and spec clause details are linked out to the stack pages.
Deliverable: Protocol × offload matrix (engineering view)
This matrix is designed for bring-up and selection: each row provides the minimum set of offload primitives and evidence counters required to close the loop.
| Protocol | Real-time driver | Offload primitives | Typical pitfalls | Must-measure counters |
|---|---|---|---|---|
| PROFINET | Cyclic channel + tight scheduling | Parse, classify, queue split, event/timer, timestamp taps | Acyclic burst pollutes cyclic; schedule drift; hidden queue buildup | Per-class drops, queue watermark, schedule-miss, tap jitter stats |
| EtherCAT | Through-forwarding + sync capture | Cut-through, parse, sync capture, mailbox split, counters | Forwarding adds tail delay; mailbox bursts; tap point misplacement | Forwarded frames, cut-through hits, mailbox queue depth, event log |
| EtherNet/IP (CIP) | Mixed cyclic + messaging | Parse, classification, queue isolation, rate control, diagnostics taps | Messaging bursts starve cyclic; buffer contention; noisy retries | Per-traffic counters, retry/drop reasons, queue watermark, CPU load tags |
| SERCOS III | Motion sync + bounded cycle | Event/timer, sync capture, queue split, timestamp taps, fast forwarding | Cycle miss due to hidden contention; misaligned time path; logging gaps | Cycle-miss events, tap offset stats, per-queue drops, black-box snapshots |
Diagram: Four engines, one pipeline (offload points only)
Software still owns (common across protocols)
- Object model: parameters, identity, I/O mapping, state surfaces.
- Diagnostics semantics: fault codes, snapshot rules, correlation fields.
- Security & update hooks: key storage integration, version control, rollback points (details belong to security pages).
- Lifecycle robustness: safe config apply, compatibility checks, and field upgrade resilience.
H2-5. Dual-port switching inside a device (Line topology behavior)
Intent
Explain how a device-local 2-port switch forwards traffic, where latency accumulates, and how queueing creates a measurable worst-case bound. The scope stays strictly inside a device, not a full-featured enterprise switch.
Forwarding model (inside the device only)
Frames arriving on Port A or Port B follow a fixed ingress pipeline, get classified into traffic classes, then either (1) are delivered locally to the protocol engine / application domain, or (2) are forwarded to the other port. Determinism depends on keeping cyclic traffic isolated from bursts and making queue behavior observable.
Store-and-forward vs cut-through (per-hop latency shape)
- Store-and-forward: waits for a complete frame before forwarding; per-hop latency includes serialization and buffer dwell. Predictability is tied to queue depth and scheduling bounds.
- Cut-through: forwards after early header parse; improves typical latency but becomes sensitive to downstream blocking. Worst-case still needs queue/egress evidence to be bounded.
QoS / VLAN pass-through (device view)
- Classification maps traffic into cyclic / acyclic / diagnostics / update classes.
- Priority queues decide who leaves first; burst traffic must not starve cyclic classes.
- Evidence must include per-class counters, per-queue watermarks, and drop reasons.
Scope brake
Ring mechanisms (MRP/HSR/PRP) are out of scope and are linked to the Ring Redundancy page. Full TSN shaping mechanisms are linked to TSN Switch / Bridge pages.
Deliverable: Port latency budget (per-hop bound skeleton)
This table is a measurement contract: it separates fixed pipeline latency from queue dwell and provides placeholders for worst-case bounds (X).
| Path | Mode | Base latency | Queue dwell (typ) | Queue dwell (worst) | Per-hop bound | Evidence / counters |
|---|---|---|---|---|---|---|
| Port A → Port B | Store / Cut | Pipeline fixed (X) | X | X (depth-bound) | X | Queue watermark, egress-busy, drop-reason |
| Port B → Port A | Store / Cut | Pipeline fixed (X) | X | X (depth-bound) | X | Per-class counters, schedule-miss, event-log |
| Port ingress → local deliver | Local | Parse/classify (X) | X | X | X | Local queue depth, DMA latency stats |
Diagram: 2-port switch pipeline (where latency accumulates)
H2-6. Determinism & local time path (DC/IRT/CIP Sync “inside the chip”)
Intent
Present determinism as a verifiable on-chip path: where timestamps are tapped, how local time is disciplined, and how cyclic scheduling uses the timebase. The goal is to build an error budget that can be measured, not to teach network timing theory.
Timestamp tap points (position changes the error terms)
Tap placement determines which parts of the pipeline are included in the observed time. The closer a tap is to the physical egress, the less it includes queue dwell; the closer it is to software observation, the more it includes bus arbitration and DMA variability.
- MAC RX/TX tap: defines line-adjacent timing; requires accounting for internal queue/schedule offsets.
- Switch egress tap: aligns best with scheduled transmit; captures real egress behavior.
- DMA completion tap: best for logging correlation; includes bus/DMA variability and is not suitable as a precision reference.
Cross-page pointer
Full PTP/SyncE/WR theory, topology calibration, and network asymmetry belong to the Timing & Sync over Ethernet page.
Deliverable: Local timing error budget (skeleton with X thresholds)
The budget below separates tap noise, queue-induced jitter, and local clock wander. Use it as a bring-up checklist and a selection contract.
| Term | Represents | Primary cause | How to measure | Pass criteria |
|---|---|---|---|---|
| Timestamp noise | Tap quantization + capture jitter | Tap location + capture path | Tap jitter stats, offset histograms | ≤ X |
| Queue jitter | Egress time variation | Queue dwell under contention | Watermarks, dwell estimates, schedule-miss | ≤ X |
| Clock wander | Local timebase drift over time | Osc/PLL noise, temperature drift | Timebase stats, drift/wander counters | ≤ X |
| Observation delay | Host-visible timestamp lag | Bus arbitration, DMA variability | DMA completion stats, log correlation fields | ≤ X |
Diagram: Timestamp path map (RX pin → timestamp unit → scheduler)
H2-7. Bandwidth/latency/jitter budgeting (Make it measurable)
Intent
Convert “good or not” into budget tables that can be calculated and measured. End-to-end behavior is decomposed into ingress → processing → queue → egress → host, and the dominant term is identified by evidence instead of averages.
Define the measurable path (E2E)
A stable budget starts with a stable path definition. Each segment must have at least one counter, one tap, or one log field so the tail can be verified in production.
- Ingress: port/MAC receive, header parse, classification metadata.
- Processing: protocol engine fast path, timer/event handling.
- Queue: per-class queue dwell under contention (dominant tail candidate).
- Egress: scheduling, time window, egress MAC/PHY handoff.
- Host: DMA, ISR/worker, application consumption and logging.
Typical traps
- Using only average latency and ignoring p99.9/max tail.
- Using throughput as a proxy for determinism and ignoring cyclic windows.
- Aggregating counters across traffic classes and losing root-cause visibility.
Deliverable: Latency budget table (E2E)
This table treats tail as a first-class requirement. Every segment must specify measurement evidence and a pass threshold (X).
| Segment | Includes | Metric | Primary knob | How to measure | Pass criteria |
|---|---|---|---|---|---|
| Ingress | RX parse + classify metadata | avg / p99.9 | Pipeline depth | RX tap hist + parse counters | ≤ X |
| Processing | Fast path engines + events | avg / max | Timer/event config | Engine busy + event miss | ≤ X |
| Queue | Per-class dwell under contention | p99.9 / max | Queue depth + priority | Watermark + dwell stats | ≤ X |
| Egress | Schedule + egress MAC | avg / p99.9 | Window / shaping | Egress tap + schedule-miss | ≤ X |
| Host | DMA + ISR/worker + app | p99.9 / max | DMA policy + IRQ binding | DMA completion stats + logs | ≤ X |
Deliverable: Jitter budget table (cycle window)
Jitter is defined as cycle-to-cycle variation inside a deterministic window. This table allocates error terms and required evidence.
| Term | Definition | Dominant when | Evidence | Pass criteria |
|---|---|---|---|---|
| Queue jitter | Egress time variation from dwell | Burst contention / mixed classes | Watermark + dwell distribution | ≤ X |
| Scheduler jitter | Window execution variation | Misconfigured windows / overload | Schedule miss + window counters | ≤ X |
| Timestamp noise | Tap quantization + capture jitter | Tap far from egress / weak stats | Tap histogram + offset stats | ≤ X |
| Clock wander | Timebase drift over time | Temp drift / insufficient discipline | Drift stats + holdover counters | ≤ X |
| Host ISR jitter | Host handling variation | Shared IRQ / competing workloads | IRQ latency stats + logs | ≤ X |
Diagram: Budget waterfall (dominant term visualization)
H2-8. Host integration (MCU/CPU interfaces, boot, firmware partitioning)
Intent
Show how to integrate a Slave SoC into a product without breaking determinism: selecting host interfaces, defining boot/update hooks, partitioning firmware, and controlling DMA/interrupt jitter.
Host interface choices (system impact)
- SPI / QSPI: simple integration; host-side DMA/IRQ policy must be tuned to avoid tail jitter under competing workloads.
- Parallel: higher bandwidth potential; requires clear reset/strap timing and stable host sampling assumptions.
- PCIe: high throughput and low CPU copy potential; increases bring-up and driver complexity, but can reduce host-segment tail if configured correctly.
Scope brake
Physical-layer routing, magnetics, and ESD/surge components are out of scope here and belong to PHY co-design & protection pages.
Boot & update hooks (mechanism-level)
- Secure boot: immutable root-of-trust checks the active image and configuration profile.
- Dual-image: A/B images with a controlled activation switch and rollback criteria.
- Rollback: explicit failure reasons and a persisted “last-known-good” marker.
DMA / interrupt strategy (tail control)
- Keep cyclic traffic handling isolated from diagnostics and update workloads.
- Make logging non-blocking and rate-limited to protect data-plane windows.
- Bind IRQ/DMA policies to measurable outcomes: reduced p99.9 and stable window occupancy.
Deliverable: Integration checklist (mini)
A minimal set of hooks that prevents bring-up dead ends and enables field forensics.
| Area | Bring-up must-have | Production must-have | Evidence fields |
|---|---|---|---|
| Clock / Reset / Strap | Stable sequence, read-back strap | Locked profile, audit trail | Boot stage + reset reason |
| Firmware partition | A/B images, activation switch | Rollback criteria + LKG | Image ver + config ver |
| Host IF / DMA | DMA bursts sized, backpressure | Host tail bounded (p99.9) | DMA completion stats |
| IRQ handling | Dedicated priority for cyclic | No starvation under load | IRQ latency hist |
| Forensics logs | Event ring buffer enabled | Persisted history + rate limit | Link state + watermark snapshots |
Diagram: Integration map (SoC ↔ Host ↔ I/O + two ports)
H2-9. Diagnostics & observability (Counters, black-box, field forensics)
Intent
Make field failures reproducible and localizable using SoC-visible telemetry: per-port and per-class counters, time-correlated event logs, and a low-overhead black-box schema. The focus stays within MAC / 2-port switch / engines / DMA / host observability.
Scope brake
PHY waveform analysis and standards text are out of scope here. Use this chapter to define evidence fields and triage signals, then link to PHY or cable diagnostics pages only when deeper physical-layer work is required.
Per-port counters (MAC / switch visible)
Counters must be per-port and directional so the failing side can be isolated quickly. Avoid single “total errors” counters that hide the root cause.
- CRC/FCS errors: receive integrity signal for each port.
- Drops: split into rx buffer drop, queue drop, and parse/descriptor drop where possible.
- Link transitions: link up/down counts plus timestamped events.
- Queue watermark: per-class queue peak usage per port (dominant tail indicator).
- Schedule miss: window overrun / late egress flags when available.
Quick triage heuristics
- CRC increases without drops: suspect receive-side integrity or timing margin, keep evidence scoped to MAC-visible signals.
- Drops rise before link flaps: suspect resource exhaustion causing cascading recovery events.
- Only one traffic class shows drops: isolate cyclic vs acyclic/diagnostics before expanding scope.
Time-correlated event logging (field forensics)
Field forensics requires a time-aligned event chain. Each event is stamped with local time (and optional synced time) so link flaps, queue overflow, temperature drift, and resets can be correlated.
| Event | Typical precursor | Evidence fields | Pass criteria |
|---|---|---|---|
| Link flap | CRC/drops rising | port state + timestamp + deltas | ≤ X/day |
| Queue overflow | Watermark saturating | per-class watermark + drop reason | ≤ X/min |
| Brownout/reset | Voltage/rail event | reset reason + supply flag + uptime | ≤ X/year |
| Thermal drift | Temp rising trend | temperature + error deltas + time | ≤ X |
Deliverable: Black-box log schema (fields + sampling + thresholds)
A product-grade schema captures identity, timebase, link state, data-path health, and system events. Sampling is split into high-rate deltas, low-rate snapshots, and event-triggered records.
| Group | Fields (examples) | Sampling | Trigger / threshold |
|---|---|---|---|
| Identity | device_id, build_id, config_id, protocol_profile_id | On boot + on change | Always |
| Timebase | local_ticks, uptime_ms, optional_synced_time | Every record | Always |
| Link / ports | portA_state, portB_state, flap_count, speed_mode | Low-rate snapshot (X s) | Flap event |
| Data-path health | crc_err_delta, drop_delta(reasoned), per-class watermark, schedule_miss | High-rate delta (X ms) | Watermark ≥ X% |
| System events | temperature, brownout_flag, reset_reason, update_attempt, rollback_reason | Event-triggered + snapshot | Any event |
| Triage tags | suspect_layer_tag, port_id, traffic_class, severity | On anomaly | Rule-based |
Diagram: Observability plane (telemetry sideband → ring buffer)
H2-10. Verification & certification readiness (prove before the lab)
Intent
Turn “certification-ready” into an executable plan: a three-layer model (conformance / performance / robustness), a scenario-driven test matrix, and a four-stage verification flow with clear exit criteria (X).
Three-layer model: conformance vs performance vs robustness
- Conformance: required behaviors covered with traceable evidence (no standards text here).
- Performance: bandwidth, latency tail, and host overhead meet budget tables.
- Robustness: storm, burst, reboot, and brownout recovery remains observable and bounded.
Deliverable: Test matrix (scenario × metrics × tools × pass criteria)
Each row binds a scenario to measurable metrics and required artifacts. Evidence sources should reuse the black-box schema from H2-9.
| Scenario | Metrics | Tools | Evidence source | Pass criteria |
|---|---|---|---|---|
| Cyclic load | Latency p99.9, window occupancy | Traffic gen + counters | per-class stats + taps | ≤ X |
| Burst traffic | Queue watermark, drop reasons | Traffic gen + logging | watermark + drop split | ≤ X |
| Storm / overload | Recovery time, flap rate | Traffic gen + black-box | events + link transitions | ≤ X |
| Reboot loop | Bring-up stability, time to ready | Power cycle + logs | boot stage + reset reason | ≤ X |
| Brownout | Recovery bounded, no silent corruption | Supply event + black-box | brownout flag + counters | ≤ X |
A/B tester correlation (production consistency)
Correlation prevents “passes in A, fails in B” escapes. Station-to-station variance must be bounded using the same metric definitions, sampling windows, and profiles.
- Lock metric definitions: tail percentiles, window occupancy, and counter deltas must match across stations.
- Tie correlation to artifacts: black-box snapshots and version/config IDs must accompany every outlier.
- When variance exceeds X: first check profile drift (filters, windows, sampling cadence), then expand scope.
Diagram: Verification flow (simulation → bench → system → field gates)
H2-11. Engineering Checklist (Design → Bring-up → Production)
- In-scope: slave/device SoC offload, dual-port forwarding behavior, determinism hooks, host integration, counters/logging, verification readiness.
- Link-out only: PHY SI/ESD/magnetics layout, full TSN/PTP theory, PoE/PoDL power design, protocol standard clauses.
| Item | How to test | Evidence artifact | Pass criteria (X) |
|---|---|---|---|
| Latency budget (E2E + tail) | Decompose ingress→process→queue→egress→host; define worst-case terms. | Budget table v1 + assumptions list. | P99/P999 ≤ X µs; worst-case bound documented. |
| Jitter budget (cycle window) | Allocate timestamp noise, queue jitter, DMA jitter, ISR jitter. | Jitter budget table + dominant-term rationale. | Cycle jitter ≤ X; margin ≥ X% of window. |
| Host interface bandwidth | Compute peak/cyclic traffic + diagnostics overhead; confirm headroom. | Interface throughput sheet + burst assumptions. | Headroom ≥ X%; no sustained backpressure. |
| Black-box log schema | Define fields (time base, per-port counters, events, thermal/power). | Schema doc + sample log record. | Field completeness ≥ X%; drop rate ≤ X. |
| Version & config governance | Freeze build_id/config_id; specify change control and rollback rules. | Governance checklist + rollback plan. | Rollback success ≥ X%; traceability 100%. |
| Item | How to test | Evidence artifact | Pass criteria (X) |
|---|---|---|---|
| Dual-port forwarding matrix | Inject known traffic on Port A/B; verify egress behavior and ordering. | Forwarding test log + packet capture summary. | No unexpected drops; order rules match mode; latency ≤ X. |
| Queue/watermark sanity | Force congestion; confirm watermark events and counter increments. | Counter delta snapshot + event trace. | Counters monotonic; event timestamps aligned; no silent overflow. |
| Determinism taps readable | Read timestamps at defined tap points; validate time base consistency. | Tap-point map + timestamp samples. | Tap jitter ≤ X; drift ≤ X over Y min. |
| Offload hooks active | Run cyclic + acyclic mix; confirm HW/firmware split via counters/CPU load. | CPU load trace + protocol-engine counters. | Cyclic deadlines met; CPU headroom ≥ X%. |
| Black-box ring buffer | Stress events (flap/overflow/reboot); confirm persistence and retrieval. | Ring buffer dump + index continuity check. | Retention ≥ X records; no gaps beyond X. |
| Item | How to test | Evidence artifact | Pass criteria (X) |
|---|---|---|---|
| A/B tester correlation | Run identical profile on stations; compare tail latency/jitter and counters. | Station report + diff summary. | Delta ≤ X%; sign-off checklist complete. |
| Soak / endurance | Cyclic + burst + reboot/brownout sequence; track drift and event rate. | Soak log + event histogram. | Event rate ≤ X; tail drift ≤ X over Y hours. |
| Field log harvest | Dump black-box securely; confirm compression, paging, and integrity. | Dump package + checksum + metadata. | Integrity 100%; time base consistent; size ≤ X. |
| Rollback & governance | Update/rollback loop; verify config_id/build_id tracking in logs. | Upgrade report + rollback proof. | Rollback success ≥ X; traceability 100%. |
| Category | Example PN | Why it fits this page | Bring-up focus |
|---|---|---|---|
| Multi-protocol slave SoC | Hilscher netX 90 | Device-side multiprotocol node with dual-port Ethernet and protocol options. | Forwarding matrix + counters + log schema. |
| Multi-protocol comms IC | Renesas R-IN32M3-EC | Industrial Ethernet communication controller with integrated dual-port switching focus. | Cyclic load + event/timestamp correlation. |
| Ready-to-use comms module | Renesas RY9012A0 | Dual-port industrial Ethernet module option for faster integration trials. | Host integration checklist + station correlation. |
| EtherCAT slave controller | Microchip LAN9252TI/ML | 2/3-port EtherCAT subdevice controller with integrated Ethernet PHYs. | DPRAM/Sync/forwarding sanity + counters. |
| EtherCAT slave controller | Microchip LAN9252/PT | Packaging variant for design flexibility (same controller family). | Bring-up profile reuse + A/B correlation. |
| Industrial comms MCU/SoC | TI AM2434 | Industrial comms-capable device family used in multi-protocol device implementations. | IRQ/DMA binding + jitter control + logging. |
H2-12. Applications & IC selection logic (device-side)
- Primary constraints: cycle time, bounded latency, robust counters/logging.
- Example device ICs: Hilscher netX 90, Renesas R-IN32M3-EC, TI AM2434.
- Primary constraints: tight jitter budget, deterministic tap points, fast fault forensics.
- Example comms ICs: Hilscher netX 90 (Sercos slave class) or higher-tier family options (e.g., netX 500).
- Primary constraints: small form factor, dual-port line wiring, observability for field service.
- Example device ICs: Hilscher netX 90; Microchip LAN9252TI/ML (EtherCAT-only class).
- Primary constraints: predictable failure modes, log depth, rollback discipline.
- Example device ICs: TI AM2434 (integration-heavy), Renesas RY9012A0 module (faster pathfinding).
- Protocol profile: single-stack (e.g., EtherCAT-only) vs multi-stack (PROFINET/EtherNet-IP/EtherCAT/SERCOS class).
- Cycle time & jitter budget (X): pick the class that can prove bounded tail latency and stable tap-point timing.
- Dual-port forwarding mode: store-and-forward vs cut-through class; confirm queue depth and worst-case accumulation.
- Diagnostics & black-box depth: counters, event timestamps, retention; decide log schema and extraction method.
- Ecosystem & certification: toolchain/SDK, lab readiness, station correlation plan (gate-based evidence).
| Feature | Risk if wrong | Evidence needed | Example PNs |
|---|---|---|---|
| Multi-protocol device support | Toolchain/cert path mismatch; schedule misses under mixed load. | Protocol profile + cyclic/acyclic stress + CPU headroom logs. | netX 90, R-IN32M3-EC, AM2434 |
| Dual-port forwarding behavior | Unbounded queue tail; hidden jitter spikes in line topology. | Per-hop latency bound + watermark events + tail histograms. | netX 90, R-IN32M3-EC, RY9012A0 |
| Determinism hooks (tap points) | Timestamp ambiguity; “works on bench” but fails in real cycles. | Tap map + drift/jitter measurements + event correlation. | AM2434, netX 90 |
| EtherCAT-only fast path | Overbuying multi-protocol; integration complexity increases. | Cyclic deadline proof + DPM/host bus saturation checks. | LAN9252TI/ML, LAN9252/PT |
| Black-box depth | Field failures become non-reproducible; slow RMA loop. | Log schema, retention, dump integrity, station correlation. | netX 90, AM2434, RY9012A0 |
