A faster network interface does not, by itself, make data safe to use. For an ASIC or FPGA that consumes packets directly, the instant that matters is when received bytes become safe to act on—not when they first appear on a streaming port.

September 14 coverage of CAST’s TCPIP-100G puts that distinction in the foreground. The useful engineering question is narrower than hardware offload versus a software stack: where should a design commit application state when a cut-through interface can deliver bytes before their integrity is known? The coverage follows CAST’s September 8 announcement. These are separate dates, not a September 14 product launch. SemiWiki, September 14, 2026, CAST announcement.

What CAST’s TCPIP-100G actually offers

CAST describes an autonomous TCP/IP implementation for ASICs and FPGAs, rated for up to 100 Gbps. It manages connections, retransmissions, and flow and congestion control without a host processor. Session capacity is chosen at synthesis, with a stated maximum of 32,768. Those are vendor capabilities, not independently measured results for every configuration. CAST announcement

The two receive modes expose different contracts. CAST’s product documentation says cut-through delivery starts before integrity validation, may later mark delivered data invalid, and does not support out-of-order reassembly in that mode. Store-and-forward instead supplies verified, ordered packets, with extra buffering and latency. TCPIP-100G documentation

That is an integration choice. It is not evidence that the core is defective.

Why cut-through bytes are still provisional

TCP’s application service is a reliable, ordered byte stream. RFC 9293 explains sequence numbers, checksums, and retransmission, and requires receivers to check the TCP checksum. A low-level hardware streaming interface should not be mistaken for a conventional socket that already hands over accepted application bytes. RFC 9293, Sections 2.2 and 3.1

Engineering inference: an integrator can separate three events—receiving bytes, doing provisional work, and committing a result. A parser might identify a message type while data is still arriving, then wait to publish a command descriptor until acceptance is established. A DMA engine might park incoming bytes in a private staging region rather than exposing them immediately to another consumer.

The hard question is whether every early side effect is discardable. Updating a private scratch buffer is different from releasing a queue entry, overwriting shared application state, or triggering an external action. If the design cannot undo or withhold those effects, a first-byte latency advantage may have little application value.

This is a proposed design-review framework, not a claim about an undocumented CAST signal. Exact invalidation timing, packet identifiers, handshake behavior, and reset semantics have to be checked against the licensed integration documentation.

Measure committed-data latency, not first-byte latency

A useful evaluation should report at least two numbers: time to the first visible byte, and time to an accepted application result. Comparing only the first rewards speculative delivery and ignores the circuitry needed to contain it.

Teams should exercise the chosen configuration with:

  • A late integrity failure after the consumer has already seen payload bytes.
  • Backpressure while provisional work is still outstanding.
  • A retransmission or reordered arrival near an application-message boundary.
  • A connection reset while a staged message is incomplete.

The acceptance criterion is not merely that traffic keeps flowing. Invalid or incomplete work must never become an externally visible application result, and valid retries must not create duplicate actions. These are recommended integration tests, not reported failures of TCPIP-100G.

Compare the whole endpoint, not one IP block

CAST’s public product page includes sample ASIC and Altera resource tables, but it ties them to particular configurations and target technologies. Those tables are starting points, not a universal area or memory requirement. Product characterization

The practical comparison should include the surrounding staging memory, commit logic, reset handling, and verification effort. A smaller receive buffer inside one IP block is not automatically a smaller endpoint if equivalent buffering simply moves downstream.

Choose cut-through when useful provisional work can stay isolated until acceptance. Choose store-and-forward when the consumer benefits more from an already-validated interface. The better architecture minimizes latency to a correct result—not latency to the first byte alone.

The takeaway

Hardware TCP/IP at 100G can move the stack off a host processor. It does not remove the commit problem. Cut-through is valuable when early bytes stay provisional. It is a liability when first-byte latency is treated as application-ready data. Measure both clocks, and design the boundary that sits between them.

Sources