An early misconception I had about ASICs was that they are fast because they are one-trick ponies. A computing chip that can perform only one specific operation is fast and cheap to make. Traditional data-center switches were filled with these ASICs. In my head, a packet entered one rigid pipeline on one side, ran along the only lane available, and came out the other side at line rate.

Cisco Silicon One is Cisco’s new approach to designing networking ASICs. While reading through training materials on S1 architecture, these lines caught my eye.

Most networks have fixed rules for how they process traffic. That approach works fine until the requirements change. In artificial intelligence and machine learning (AI/ML) data centers, cloud networks, or 5G environments, traffic patterns shift fast, and rigid hardware can slow you down.

Cisco Silicon One fixes this situation by supporting Programming Protocol-independent Packet Processors (P4). This language lets you customize how to process data packets, all in software, without replacing the processor.

For example, engineers can program Silicon One (like the G200 or P100) to prioritize traffic for AI workloads like LLM training or to manage different types of services more efficiently.

CiscoU training material on Cisco Silicon One

Okay, sweet. But that raised two questions:

  1. For a use case that is famously sensitive to speed, why are we making the chips less ‘rigid’? Are we teaching our fast pony new tricks?
  2. How far can this programmability be stretched? Is Cisco selling us blank Play-Doh hardware that I, the network engineer, can mold into whatever I want?

Turns out my preconception of what an ASIC is was wrong. An ASIC isn’t necessarily hardwired to perform exactly one algorithm. Instead, it’s designed for a specific application domain. One such domain is extremely fast packet forwarding.

Cisco Silicon One is essentially a specialized packet-processing machine:

  • The physical machinery is fixed: Ethernet interfaces, packet buffers, lookup engines, arithmetic units, queues, schedulers, memory widths, and processing capacity.
  • The forwarding recipe executed by that machinery is programmable.
  • P4 describes that recipe: which headers to recognize, which fields to use as lookup keys, what tables to consult, and what actions to perform.

For example, a P4 program might say:

parse Ethernet → IPv6 → SRv6
look up destination and policy
decrement hop limit
attach telemetry metadata
select output port and queue
rewrite headers

Cisco’s compiler converts that program into bytecode or microcode that runs on Silicon One’s packet-processing engines. Cisco describes this as combining P4 programmability with a “run-to-completion” processing model. See Cisco’s Silicon One architecture paper.

So the correct intuition is: “The chip is programmable within a fixed hardware boundary.”

So, it’s programmable AND fast?

My mistake was treating specialized and rigid as the same thing.

The chip is fast because it has purpose-built packet machinery working in parallel. Lookups happen in dedicated hardware. Buffers and forwarding engines are designed around the single purpose of moving packets as fast as possible. It is not asking a general-purpose CPU to interpret some arbitrary Python program for every frame.

P4 does not remove those constraints. A program still has to fit into the processing budget offered by that ASIC. If it asks for something the hardware cannot do at line rate, the compiler cannot wish the problem away.

The ASIC is flexible ‘before’ it actually has to start forwarding packets. Once the program is compiled and installed, the same specialized hardware executes it at speed.

But who gets to program it?

The word programmable can mean different things depending on what part of the lifecycle we are talking about:

Four stages of control in a programmable switch ASIC: runtime and day-2, boot and day-1, compile time, and ASIC design time. Compile time is where most P4 programmability lives.
  1. Physical ASIC RTL/design time - Chip design done by the HW vendor. Things like buffer architecture, SerDes count, VOQ, TCAM/SRAM sizing, etc. This can’t be changed once set. There is no customization offered here.
  2. Compile time - Things that go in the NOS image, controlled by the software vendor. The parser, header definitions, and match-action pipeline are expressed in a P4-ish language, compiled to pipeline microcode, and shipped as part of the software release. This is how SRv6 uSID feature or a new encap can be added without a silicon respin. It’s “software” but it’s Cisco’s software, not ours.
  3. Boot / day-1 - Network architect controlled. Hardware forwarding profiles: TCAM carving, table-scale profiles that trade LPM against ACL space (forwarding profile in Cisco switches), port breakout etc. We’re picking from a menu of vendor-precompiled configurations. The network architect controls it, but in most cases a reload is required, not typically a day-2 operations activity.
  4. Runtime / day-2 - Network engineer controlled. This consists of populating table entries. The pipeline behavior is already fixed.

So the P4 programmability is mostly at layer 2, and I am not the one doing the customizing. Cisco doesn’t expose the P4 toolchain on IOS-XR or NX-OS. Hyperscalers with direct Silicon One SDK access may get more rope.

Intel’s Tofino is the counterexample. It handed P4 to end users, but it turns out customers didn’t really want it. Tofino-2 was at 12.8T while Tomahawk 4 shipped 25.6T and Tomahawk 5 hit 51.2T. Customers chose bandwidth-per-watt over the ability to write their own ASIC pipeline.

Where AI fits

AI networks need very fast hardware, but the way they use that hardware is still changing. Congestion control, multipath forwarding, packet trimming, telemetry, and load balancing are all moving faster than a silicon replacement cycle.

This is where P4 helps. Cisco says it has added things like Multipath Reliable Connection support and packet trimming to existing Silicon One hardware through P4 software updates.

That gives AI networks both things I originally thought were incompatible: specialized hardware for speed, plus enough flexibility to support new forwarding behavior before the next ASIC architecture change.

So, what did I get wrong?

The speed of an ASIC does not come only from freezing one algorithm into a rigid chip. It comes from specialized hardware, parallel processing, and a limited set of operations engineered to run at line rate.

P4 makes the forwarding pipeline flexible, but it does not make different ASICs interchangeable. It can change packet parsing and match-action behavior within the chip’s limits. It cannot add buffer capacity, bandwidth, SerDes, or new physical machinery.

A P4-programmable microwave cannot be converted to a refrigerator.

References