polynomials at the speed of silicon

The first answer comes out on cycle 4. The next comes out on cycle 5. Each has gone through four dependent multiply-add steps. That is the distinction I wanted to follow through accounts of FPGA trading systems: how long one evaluation takes, and how soon the circuit can start another.

Those cycle numbers come from a Python model, with one clock assigned to each arithmetic stage. I haven't built trading hardware. I can check the schedule, then use the DSP48E2 documentation to ask what mapping it to an FPGA would involve. The financial examples raise a separate question: what must the arithmetic preserve for its answer to be useful?

following one input through four steps

Take a degree-four polynomial:

p(x) = a₀ + a₁x + a₂x² + a₃x³ + a₄x⁴

Regrouping it with Horner's method gets rid of the separate powers of x:

p(x) = a₀ + x·(a₁ + x·(a₂ + x·(a₃ + x·a₄)))

Begin at a₄, inside the innermost brackets. Getting to a₃ costs one multiply and one add. Reaching a₂ costs another pair, and so on until a₀. That makes four of each operation here, or n multiplications and n additions for degree n. The bracket on the right has to finish before we can work on the next one to its left.

I used 1, 2, 3, 4, 5 as the coefficients in the clocked check. Working through x=2 gives this trail: 5 → 14 → 31 → 64 → 129. Each arrow means double the previous answer and add the next coefficient. In the pipeline run, that input enters on cycle 2 and returns 129 on cycle 6. With x=0 through x=4 arriving in order, the outputs are 1, 15, 129, 547, and 1593, on cycles 4 through 8. I check every one against a separate Horner calculation with an assertion.

By cycle 3 the model has four evaluations in flight. They are at different steps: x=0 is about to finish, while x=3 has only just arrived. On the next clock, the completed answer leaves and x=4 takes the vacant first stage. The four-clock journey for an input has not become shorter. We have arranged for the next input to be only one clock behind it.

Calling the clock period T gives latency 4T and, once the pipeline fills, throughput 1/T. Every evaluation still obeys its dependencies. The overlap is between different inputs. Multivariate Horner evaluation can nest variables too, though choosing their order changes how much arithmetic is left to do.

The partial result alone is not enough to pass between stages. It needs its original x alongside it. Otherwise, when the second stage is working on x=2, it might multiply by the 3 that has just arrived at the first stage. That would quietly change the polynomial being evaluated. The script carries the pair together.

what the DSP block actually offers

What clock could those four stages sustain? Python leaves that question open. AMD's UG579 guide gives something concrete to map onto: the UltraScale+ DSP48E2 has a 27×18-bit multiplier, an arithmetic unit, and optional pipeline registers. With suitable register settings, a slice can accept an operation every clock while an earlier result is still inside it.

Degree eight requires eight Horner arithmetic steps. Their widths, register settings, and routing determine how those steps map to a device. The delayed copies of x need to follow that schedule as well. Changing coefficients adds another question: which set does an evaluation use if the update happens while it is halfway through? All its stages need one coherent set.

The script uses Python integers. It has therefore left overflow and rounding out of the exercise. Fixed point can save resources when the ranges are known, but I would need room for every intermediate, including that growing partial result, and an error budget for rounding. Floating point also costs hardware, with support that varies across FPGA families. Choosing it would still leave accuracy to check.

For an accepted input, this arithmetic path has a useful property: its work does not depend on a branch or a variable loop count. I can count the steps. Getting the input accepted is a separate matter if shared memory, backpressure, or a variable-length parser can hold it up.

what is known before the tick arrives?

Fitting the coefficients could happen well before any live input arrives. The evaluator would then reuse them as the inputs change. Our example has only x; a multivariate version could be p(x₁,…,xₙ) = Σ cᵢ · x₁^a · x₂^b … xₙ^z. I can supply those inputs and work forward through the arithmetic, without searching for a root.

"Polynomial computation" also covers a much harder job. Solving a system means finding inputs that satisfy its equations. That can be expensive: Buchberger, F4, and F5 are Gröbner-basis methods for versions of this problem; resultants and homotopy methods are other approaches. Our Horner chain is doing the simpler job of evaluating at a supplied input. Its remaining design choices concern how to arrange the arithmetic and represent the numbers.

For a volatility surface, take strike K and maturity T. I could write a basis expansion σ(K,T) = Σ cᵢⱼ · fᵢ(K) · gⱼ(T) and choose polynomial basis functions to make the arithmetic regular. That choice would say nothing about whether the fitted prices make sense together. Gatheral and Jacquier's arbitrage-free SVI work addresses that consistency problem for SVI. SVI itself is nonpolynomial; a polynomial fit would need constraints of its own.

Even choosing a curve model changes what belongs before the first multiply. For fixed-income cubic splines and B-splines, an input selects an interval and its coefficients before the polynomial can be evaluated. Nelson-Siegel uses exponential terms. Choosing that model would mean mapping those terms too; calling all of these "curve evaluation" hides the difference.

Delta is where I would be especially wary of accepting a fit on price error alone. Differentiating a polynomial price approximation in S gives another polynomial, so the arithmetic remains convenient. The approximation error has a derivative too. How large can that be if the price error is small?

Here is an error that makes the problem visible: ε Tₙ(x), where Tₙ is a Chebyshev polynomial and ε=10⁻⁶. From its cosine form, I know its magnitude stays within ε everywhere on [-1, 1]. For the slope I used x=1, where each Tₙ is 1. Differentiating Tₙ₊₁ = 2xTₙ − Tₙ₋₁ at that point leaves Dₙ₊₁ = 2 + 2Dₙ − Dₙ₋₁. Starting at D₀=0 and D₁=1, the script gets a slope error of 0.000064 at degree 8, 0.001024 at degree 32, and 0.004096 at degree 64. That last value is 4,096 times ε. The bound on the values never changed.

This gives a specific reason to check the derivative separately. The small value-error bound by itself does not carry over to the slope. These are constructed errors, rather than errors measured on a fitted price surface; they show what the value bound leaves open. A delta calculation would need its own accuracy check, including rounding at the chosen arithmetic width.

For a cross-venue pricing relationship written as algebraic inequalities, I would ask the same question about preparation: can fitting or region analysis leave only a few conditions to evaluate online? That reduction needs to be worked out for the particular model. Polynomials make a small example I can inspect. Neural networks can map to FPGAs too, with their own graph sizes and precision costs. These public sources give me no basis for saying how often proprietary strategies choose either.

from a packet to the polynomial

The script can simply supply x=2. Where would that input come from in a trading system? Following Nasdaq's protocol specifications, one possible path starts with an FPGA network interface receiving packets without waiting for the OS networking stack. A hardware decoder extracts the relevant ITCH messages. An order-book block applies their updates to selected price levels, with some state held in on-chip RAM as the feed and strategy allow. Missing or out-of-order packets need explicit handling, or those book values may no longer describe the intended market state.

Selected book values can now enter the Horner chain. What comes out still needs a decision and risk checks before anything goes on the wire. An encoder could then build an OUCH order-entry message for the Nasdaq connection in question. A CPU can configure and supervise the circuit without seeing each tick. Counting the four arithmetic stages alone leaves all of that other work unaccounted for.

Before using a number from that diagram, I would want to know where timing begins and ends. At the first received bit, or after the last required field arrives? At the first outbound bit, or after the complete order message? Moving those boundaries changes how much serialization and processing the number includes.

At 10 Gbps, eight bits take 8 / 10¹⁰ = 0.8 ns to send. That much follows from the line rate, before encoding or protocol overhead. A rough 100 ns estimate for main-memory access needs more context. Which CPU and memory subsystem? Was the access sequential, random, or contended? I have no such details for that number. Moving this path into FPGA fabric gets rid of the CPU's cache misses and branch mispredictions, but I still owe measurements for the parser, memory, and I/O.

the milliseconds outside the circuit

The cross-country link in the diagram needs its own explanation. For a colocated system, I would measure from market-data arrival to order emission at that venue. Connecting Nasdaq's Carteret site in New Jersey with CME's Aurora site in Illinois adds the travel between the two regions. That delay is already measured in milliseconds.

I can compare propagation alone by giving both routes an illustrative length of 1,100 km. With silica fiber's refractive index roughly 1.5, v = c/n gives about 0.67c: a travel time near 5.5 ms. Radio through air travels close to c, giving a lower bound near 3.7 ms over that distance. The gap is about 1.8 ms before equipment overhead. A real route adds distance, and radio also has to satisfy line-of-sight constraints.

Against the diagram's illustrative 10–40 ns arithmetic budget, that 1.8 ms gap is 45,000–180,000 times as long. I am comparing scales here; neither number measures a trading advantage. A straighter fiber route or a microwave link can reduce the travel delay. The Spread Networks account in Flash Boys and the microwave reporting below describe that competition. Their reported construction costs are background; the propagation calculation depends on distance and speed.

I would not use that ratio to dismiss the local arithmetic. A cross-region strategy pays for both travel and processing. A strategy confined to one colocated venue has a different path to measure, and the 1.8 ms comparison says little about where it should spend engineering effort. The useful budget follows the strategy's actual path.

what speed says about the trade

Following the input also helps keep two trading descriptions separate. In latency arbitrage, the input may be a price change at one venue, while a quote at another has yet to adjust. Front-running involves knowledge of a pending transaction, often a customer's, and trading ahead of it. The same kind of fast circuit could act on either input; its speed tells me little about how the information was obtained.

FINRA Rule 5270 supplies a more specific test in the US: its restrictions concern trading with material nonpublic information about an imminent block transaction, under the rule's provisions. I would need the facts of the trade and the applicable rule before calling an activity front-running. Nor does describing it as "latency arbitrage" settle its legality for a venue arrangement.

I would take this schedule into synthesis only after choosing the arithmetic widths, registers, and target device. Then the timing report could answer the question Python left open: what clock period works, and how many stages does it need? That is also the appeal for radar processing, packet inspection, or a control loop with a deadline. It is a reason to compare hardware, though. A CPU, microcontroller, DSP, or ASIC could meet the input rate and error budget more cheaply. For this polynomial I could also try spending more arithmetic resources on parallel evaluation. I have a schedule to compare those choices against.