Where does specialized hardware belong in a market-data path, and which jobs should stay in software a reviewer can read? This note draws that line, using the decode of a Nasdaq equities feed as the public example, without turning the line into a speed claim.
Hardware is a place, not a compliment
Specialized hardware, including a field-programmable device, is a place where a narrowly defined transformation can run under a design that is awkward to express as an ordinary process. Parsing a fixed message layout, filtering a channel, or checking a sequence number are the kinds of jobs people consider putting there. A judgment about whether a signal is economically interesting is not that kind of job. The line is about the shape of the task. It is not a ranking of the people who work on either side of it.
The cost of the placement is rigidity and review. A change to a parser in hardware is a different release from a change to a parser in a program, with a different way of inspecting the result. Putting a vague task in that place makes the vagueness harder to see. Putting a stable, specified task there can make the boundary of the task sharper. The decision should say which of those is being bought. A diagram that labels a box with a hardware word and does not say the task has not made the decision.
Hardware belongs in a market-data path on a stable, specified transformation, such as decoding a published message format, and it stays out of the hypothesis the message is later used for.
Decoding an equities feed
Nasdaq publishes specifications for equities market-data messages. A decoder's job is to turn those bytes into the fields the specification names: identifiers, prices, sizes, and the codes that say what kind of update this is. That job is a candidate for hardware because the layout is defined by someone else and the function is a parse, not a view. The output should be the same fields a software decoder would emit. If the two decoders disagree, one of them is wrong, and the disagreement is a bug rather than a style.
What does not belong in that device is the strategy. A rule about whether a quote is attractive, a join to a dataset accepted last month, or a piece of text from a filing are software problems with reviewers, logs, and frequent change. Parking them in the decode path couples a research edit to a hardware release. The Nasdaq example keeps the split visible. The feed has a specification. The specification ends at the message. Everything about what to do with the message is on the other side of the line.
Even the parse can be the wrong resident if the specification is in flux or if the team cannot test the device against a recorded packet the way it tests a program. A hardware decoder earns its place when a recorded day can be fed to it and the decoded records match a reference decoder field by field. Without that test, the device is an unreadable copy of the specification. The reference can live in ordinary software. The comparison is the point of having both.
The line, stated without a number
Hardware belongs on the market-data path where the task is a stable transformation of a specified message, checked against a software reference. It does not belong where the task is a hypothesis. The Nasdaq decode is the example of the first kind of task. A signal built on top of that decode is the second. Mixing them produces a system nobody can replay, because the interesting part is trapped in a place the logs do not describe in sentences.
This placement says nothing about how quickly either side runs. A correct slow parse is a different topic from a fast wrong one, and neither topic is settled by the word hardware. The belonging is logical. Specified, stable, checkable transformations may sit in the device. Everything that is still an argument stays where arguments are reviewed.
This piece does not claim that hardware is necessary, that a decoder confers a speed, or that any feed should be handled in a device. It draws the line between a specified parse and a judgment, using a public equities feed as the illustration.
