Reference ABX hardware design and implementation

[mcdn]

@Cascode and @KSTR, thanks for the input on the gain stage. It prompted me to recheck a few things.

The feedback impedance near unity gain was indeed too low and not supported. I've increased Rf to 680ohms, at the cost of a small increase in noise. This allows for source impedances down to 75ohms while staying within the datasheet measurement low end of 600ohms. here's a table of the A-weighted noise contribution with a 75ohm source impedance and 2Vrms input:

Gain
Output
Effective Rg
Output noise
Noise relative to output
0 dB
2.000 Vrms
Open
0.434 µVrms(A)
−133.3 dB(A)
1 dB
2.244 Vrms
5.57 kΩ
0.459 µVrms(A)
−133.8 dB(A)
2 dB
2.518 Vrms
2.63 kΩ
0.486 µVrms(A)
−134.3 dB(A)
3 dB
2.825 Vrms
1.65 kΩ
0.516 µVrms(A)
−134.8 dB(A)
4 dB
3.170 Vrms
1.16 kΩ
0.550 µVrms(A)
−135.2 dB(A)
5 dB
3.557 Vrms
874 Ω
0.587 µVrms(A)
−135.7 dB(A)
6 dB
3.991 Vrms
683 Ω
0.627 µVrms(A)
−136.1 dB(A)
7 dB
4.477 Vrms
549 Ω
0.672 µVrms(A)
−136.5 dB(A)
8 dB
5.024 Vrms
450 Ω
0.722 µVrms(A)
−136.9 dB(A)
9 dB
5.637 Vrms
374 Ω
0.777 µVrms(A)
−137.2 dB(A)
10 dB
6.325 Vrms
314 Ω
0.838 µVrms(A)
−137.6 dB(A)
11 dB
7.096 Vrms
267 Ω
0.906 µVrms(A)
−137.9 dB(A)
12 dB
7.962 Vrms
228 Ω
0.982 µVrms(A)
−138.2 dB(A)

THD is more complex. At 1kHz, 2V input, 0dB gain and 150ohm or lower source impedance, the datasheet says -134dB. It does rise at higher frequencies and with increasing source impedances, to -123dB at 10kHz and 600ohms, but A weighting brings this back down to about -130dB as the second harmonic at 20kHz is weighted by -7dB relative to the fundamental.

Overall I think I'd like to stick with the OPA1612 solution for its simplicity, low implementation risk, low voltage offset, low noise and broad availability. I may need to rethink the claimed specs to avoid having to surround them with too many qualifications, but measurement is the gold standard.

 

[mcdn]

I've done some more research and I think we can get better performance while retaining the single opamp architecture by using the OPA2211:

• Max DC offset drops from 500uV to 150uV
• Datasheet specs better match our expected loads (-136dBTHD+N at 3Vrms into 600ohms)
• Temperature drift much more controlled - effectively negligible in any reasonable operating range

Thoughts?

 

[KSTR]

Do you have any thoughts on stackup for this design?

I'm a dynamic stackup guy so to say. It starts from all layers being GND and stitched together with tons of stitching vias, a solid block of copper basically. Then I "carve out" what is required, after spending a lot of effort on placement . I use larger supply polygons as required and make sure they are basically still a GND plane just with DC offset, adding companion stitching caps to the stitching vias. I don't use classical output caps on regulators as there is only one large and distributed "composite" cap per rail, formed by the plane capacitance and the tons of stitching caps (all with the same value). All the the stitching any any local bypass caps of course follow the "combine then return" strategy so that rectified load currents are combine before they enter GND at one single place.

And yes it's KiCad 10, but the schematics are in Zener language (https://docs.pcb.new/pages/spec), and I haven't yet found a sensible way to turn those into accurate and human-readable versions.

Now this is totally weird ;-) Never heard of this and it makes zero sense to me. How is one supposed to even work without a proper schematic? How is one supposed to document and think about stuff? A cleanly drawn schematic with lots of remarks and annotations is THE foundation of everything (and notably for placement/routing), together with well-maintained libraries (IMHO, Kicad's stock stuff sucks big time in this regard and hence we compile our own stuff to comply to our standards).
I see no way I could place and route a board professionally, flying blind basically, without having schematic with real-time cross-probing and all. Also, I iteratively update the schematic with required net classes, rearrange details to be more clear, etc.
Hhmm.....

 

[mcdn]

Now this is totally weird ;-) Never heard of this and it makes zero sense to me. How is one supposed to even work without a proper schematic? How is one supposed to document and think about stuff? A cleanly drawn schematic with lots of remarks and annotations is THE foundation of everything (and notably for placement/routing), together with well-maintained libraries (IMHO, Kicad's stock stuff sucks big time in this regard and hence we compile our own stuff to comply to our standards).
I see no way I could place and route a board professionally, flying blind basically, without having schematic with real-time cross-probing and all. Also, I iteratively update the schematic with required net classes, rearrange details to be more clear, etc.
Hhmm.....

As a software engineer I've always thought the opposite - "how on earth are these EEs relying on diagrams with visually specified net ties, difficult to interpret crossings, and complex cross-sheet naming conventions?!". Like seriously, your nets are joined based on whether your schematic editor visually showed a connection or not? In KiCad that's how it works, just geographical nearness.

But of course doing it in code means a lack of visual awareness, and that's a huge gap. The computer doesn't understand that "these things go together" in the same way you do. So the mapping from visual hierarchy to electrical hierarchy gets lost.

On the other hand a lot of this work can be datasheet driven at the local layout level. We have an IC and its supporting passives, and a reference layout. It's easy to get the computer to put the passives close to where they should sit and let the human work out the detail. Given that, global layout becomes much more of a human judgement thing.

 

[mcdn]

Here's an example bit of Zener code - it defines the SPDIF interfaces on the digital module:

"""One optical input, two optical outputs and one isolated coaxial output."""

OpticalReceiver = Module("../../components/everlight_plr237_t10bk/Plr237T10bk.zen")
OpticalTransmitter = Module("../../components/everlight_plt237_t10wh/Plt237T10wh.zen")
Transformer = Module("../../components/murata_da101c/MurataDa101c.zen")
Rca = Module("../../components/cax_av_104a_r/CaxAv104aR.zen")
CoaxBuffer = Module("../../components/nexperia_74hc14d_653/Nexperia74hc14d653.zen")
Resistor = Module("@stdlib/generics/Resistor.zen")
Capacitor = Module("@stdlib/generics/Capacitor.zen")

PICO_3V3 = io(Power)
PICO_VSYS = io(Power)
DIGITAL_GND = io(Ground)
SPDIF_RX = io(Net)
SPDIF_TX_OPTICAL_A = io(Net)
SPDIF_TX_OPTICAL_B = io(Net)
SPDIF_TX_COAX = io(Net)

OPTICAL_RX_RAW = Net()
OPTICAL_TX_A_IN = Net()
OPTICAL_TX_B_IN = Net()
COAX_PRIMARY = Net()
COAX_DRIVER_OUT_1 = Net()
COAX_DRIVER_OUT_2 = Net()
COAX_DRIVER_OUT_3 = Net()
COAX_SECONDARY = Net()
COAX_CENTRE = Net()
COAX_RETURN = Net()


def decoupling(name, supply):
    Capacitor(
        name=name,
        P1=supply,
        P2=DIGITAL_GND,
        value="100nF",
        package="0603",
        voltage="50V",
        dielectric="X7R",
        mpn="CC0603KRX7R9BB104",
        manufacturer="Yageo",
        properties={
            "LCSC": "C14663",
            "assembly": "JLCPCB Basic SMT; Economic PCBA",
            "submodule": "SpdifInterfaces",
        },
    )


def series_100(name, source, sink):
    Resistor(
        name=name,
        P1=source,
        P2=sink,
        value="100Ohm",
        package="0603",
        mpn="0603WAF1000T5E",
        manufacturer="UNI-ROYAL",
        properties={
            "LCSC": "C22775",
            "assembly": "JLCPCB Basic SMT; Economic PCBA",
            "submodule": "SpdifInterfaces",
        },
    )


OpticalReceiver(
    name="U_OPTICAL_RX",
    VCC=PICO_3V3,
    GND=DIGITAL_GND,
    VOUT=OPTICAL_RX_RAW,
    properties={"submodule": "SpdifInterfaces"},
)
decoupling("C_OPTICAL_RX", PICO_3V3)
series_100("R_OPTICAL_RX", OPTICAL_RX_RAW, SPDIF_RX)

series_100("R_OPTICAL_TX_A", SPDIF_TX_OPTICAL_A, OPTICAL_TX_A_IN)
OpticalTransmitter(
    name="U_OPTICAL_TX_A",
    VIN=OPTICAL_TX_A_IN,
    VCC=PICO_VSYS,
    GND=DIGITAL_GND,
    properties={"submodule": "SpdifInterfaces"},
)
decoupling("C_OPTICAL_TX_A", PICO_VSYS)

series_100("R_OPTICAL_TX_B", SPDIF_TX_OPTICAL_B, OPTICAL_TX_B_IN)
OpticalTransmitter(
    name="U_OPTICAL_TX_B",
    VIN=OPTICAL_TX_B_IN,
    VCC=PICO_VSYS,
    GND=DIGITAL_GND,
    properties={"submodule": "SpdifInterfaces"},
)
decoupling("C_OPTICAL_TX_B", PICO_VSYS)

CoaxBuffer(
    name="U_COAX_BUFFER",
    A1=SPDIF_TX_COAX,
    Y1=COAX_DRIVER_OUT_1,
    A2=SPDIF_TX_COAX,
    Y2=COAX_DRIVER_OUT_2,
    A3=SPDIF_TX_COAX,
    Y3=COAX_DRIVER_OUT_3,
    GND=DIGITAL_GND,
    Y4=NotConnected(),
    A4=DIGITAL_GND,
    Y5=NotConnected(),
    A5=DIGITAL_GND,
    Y6=NotConnected(),
    A6=DIGITAL_GND,
    VCC=PICO_3V3,
    properties={"submodule": "SpdifInterfaces"},
)
decoupling("C_COAX_BUFFER", PICO_3V3)


def coax_series(name, source):
    Resistor(
        name=name,
        P1=source,
        P2=COAX_PRIMARY,
        value="750Ohm",
        package="0603",
        mpn="0603WAF7500T5E",
        manufacturer="UNI-ROYAL",
        properties={
            "LCSC": "C23241",
            "assembly": "JLCPCB Extended SMT; Economic eligibility requires quote",
            "catalog_stock_observed": "553660 on 2026-08-10; not JLC assembly stock",
            "submodule": "SpdifInterfaces",
        },
    )


coax_series("R_COAX_SERIES_1", COAX_DRIVER_OUT_1)
coax_series("R_COAX_SERIES_2", COAX_DRIVER_OUT_2)
coax_series("R_COAX_SERIES_3", COAX_DRIVER_OUT_3)
Resistor(
    name="R_COAX_SHUNT",
    P1=COAX_PRIMARY,
    P2=DIGITAL_GND,
    value="110Ohm",
    package="0603",
    mpn="0603WAF1100T5E",
    manufacturer="UNI-ROYAL",
    properties={
        "LCSC": "C22781",
        "assembly": "JLCPCB Extended SMT; Economic eligibility requires quote",
        "catalog_stock_observed": "41159 on 2026-08-09; not JLC assembly stock",
        "submodule": "SpdifInterfaces",
    },
)
Transformer(
    name="T_COAX",
    PRIMARY_DOT=COAX_PRIMARY,
    PRIMARY_RETURN=DIGITAL_GND,
    SECONDARY_RETURN=COAX_RETURN,
    SECONDARY_DOT=COAX_SECONDARY,
    properties={"submodule": "SpdifInterfaces"},
)
Capacitor(
    name="C_COAX_COUPLING",
    P1=COAX_SECONDARY,
    P2=COAX_CENTRE,
    value="100nF",
    package="0603",
    voltage="50V",
    dielectric="X7R",
    mpn="CC0603KRX7R9BB104",
    manufacturer="Yageo",
    properties={
        "LCSC": "C14663",
        "assembly": "JLCPCB Basic SMT; Economic PCBA",
        "submodule": "SpdifInterfaces",
    },
)
Rca(
    name="J_COAX_OUT",
    CENTRE=COAX_CENTRE,
    SHELL=COAX_RETURN,
    properties={"submodule": "SpdifInterfaces"},
)

 

[KSTR]

I've done some more research and I think we can get better performance while retaining the single opamp architecture by using the OPA2211:

• Max DC offset drops from 500uV to 150uV
• Datasheet specs better match our expected loads (-136dBTHD+N at 3Vrms into 600ohms)
• Temperature drift much more controlled - effectively negligible in any reasonable operating range

Thoughts?

You still have the offset contribution from unequal node DC impedances times bias current. The 211 is only slightly better than 1611 wrt to bias and offset current. The low voltage offset comes into effect only with low and equal node impedances, which we don't have here, though not as bad as with AD797 and the like.
I'd add provisions for manual offset trim, just in case. Or use OPA828, all problems solved.

And putting a BUF634/LME49600 driver in the loop is a low complexity effort and would help quite a bit to keep distortion low.

 

[KSTR]

Here's an example bit of Zener code - it defines the SPDIF interfaces on the digital module:

To me (I'm a software guy with computer science degree, too), that's like inspecting code with a disassembler rather than looking at, and working with, nice C++ (or whatever) high-level code in a modern IDE. You really type/edit/debug/maintain this stuff manually?

Anyway, I fear that your truly unusual approach blocks collaboration quite a bit.

 

[mcdn]

You still have the offset contribution from unequal node DC impedances times bias current. The 211 is only slightly better than 1611 wrt to bias and offset current. The low voltage offset comes into effect only with low and equal node impedances, which we don't have here, though not as bad as with AD797 and the like.
I'd add provisions for manual offset trim, just in case. Or use OPA828, all problems solved.

And putting a BUF634/LME49600 driver in the loop is a low complexity effort and would help quite a bit to keep distortion low.

Good point about the actual DC offset sources vs the datasheet, that does narrow the gap. With the OPA828 we do still pay a price in 6dB worse THD+N and 4 times the absolute noise. We're already at very low DC offset levels regardless of the single opamp choice, and with fading before switching I think it's never going to provide a cue.

 

[mcdn]

To me (I'm a software guy with computer science degree, too), that's like inspecting code with a disassembler rather than looking at, and working with, nice C++ (or whatever) high-level code in a modern IDE. You really type/edit/debug/maintain this stuff manually?

Anyway, I fear that your truly unusual approach blocks collaboration quite a bit.

I hear you on the collaboration point, but verifiable code is a much sounder foundation than pictures.

In terms of maintenance, I can and do make edits manually where needed - it's nicely structured code and easy to navigate - but the Zener code is mostly maintained by an LLM - Codex Pro for now. Just like the DSPi project couldn't exist without Claude, this wouldn't exist without Codex.

 

[KSTR]

Distortion of the OPA828 under real world conditions is on par, if not better than OPA1612. Noise also often is.

I hear you on the collaboration point, but verifiable code is a much sounder foundation than pictures.

It's not just drawing pictures and I'm sure you know that. Working with Altium or Kicad means you have a complete IDE with all bells and whistles.

In terms of maintenance, I can and do make edits manually where needed - it's nicely structured code and easy to navigate - but the Zener code is mostly maintained by an LLM - Codex Pro for now. Just like the DSPi project couldn't exist without Claude, this wouldn't exist without Codex.

I sort of was expecting that. I'm using AI a lot as well of course, but not in a way that is a closed one-way road.

 

[mcdn]

Distortion of the OPA828 under real world conditions is on par, if not better than OPA1612. Noise also often is.

I could order one board with each and measure, but we'd need to be sure what we were testing for.

It's not just drawing pictures and I'm sure you know that. Working with Altium or Kicad means you have a complete IDE with all bells and whistles.

Of course, and thank you for not taking that too literally. I've certainly been burned in KiCad before by nets that appear to merge, pass ERC, but due to a minor naming issue aren't actually electrically connected.

I sort of was expecting that. I'm using AI a lot as well of course, but not in a way that is a closed one-way road.

I know how you feel, but being able to say "you know what, let's move this function to a different board" or "Dammit, KSTR has a point, let's simulate a different opamp", and know the whole project is in sync is _amazing_

 

[pma]

I could order one board with each and measure, but we'd need to be sure what we were testing for

It has been tested many times. Complex contribution of opamp input voltage and current noise vs. source impedance and source impedance nonlinearity.

 

[mcdn]

Please don't shoot me for all the obvious issues with this schematic, I hope it is enough to help with getting to grips with the overall analog board:

 

[KSTR]

Please don't shoot me for all the obvious issues with this schematic, I hope it is enough to help with getting to grips with the overall analog board:

It's really a bit rough on the eyes but contains all info needed. Thanks for sharing.

At first glance I note missing protection on inputs and outputs wrt ESD, Overvoltage/Backpower, RF

 

[mcdn]

It's really a bit rough on the eyes but contains all info needed. Thanks for sharing.

At first glance I note missing protection on inputs and outputs wrt ESD, Overvoltage/Backpower, RF

Yes I’ve got those in the todo list. I don’t want to go overboard but something in that space is probably needed. The inputs can handle a pretty wide voltage range +-13V, and are not connected to PE or the case (supply is isolated). Thoughts on economic options?

 

[mcdn]

Some more thoughts on protection. I'll split this into DC offset, RF, ESD and phantom power.

On the inputs we are moderately well covered by the input coupling cap and load resistor for ordinary DC offset or a broken source outputting DC up to ~12V. And when powered off the relays are open. Even hot plug transients should be OK. Just my opinion here, so please challenge if that's not adequate.

RF filtering is definitely not there. I was thinking a 100pF cap from signal to return across each connector for both inputs and outputs. I considered ferrite beads but am worried about distortion at our tough target. There are "audio" ones available (Murata NFZ series for example: https://article.murata.com/en-global/article/audio-line-noise-suppression-for-home-audio-1) but I can't find any line level THD measurements.

For ESD, the inputs and outputs all use AUDIO_GND which is the centre tap of the +-15V isolated DC/DC converter. There are no connections from that to the input POWER_GND or to the case, so handling the case can't cause ESD to reach the audio circuit unless it blows through the converter first, in which case we have bigger problems. A surge could come through a connected input or output, but again we will likely have bigger problems in that case. On this basis I'm inclined not to add TVS to each socket by default.

There is a surprisingly realistic issue with phantom power being accidentally connected to either an input or output if someone is using RCA-XLR cables and messes up. See this hilariously named THAT paper: 48V - The Phantom Menace. This could be more common than it sounds, because

1. a lot of audio interfaces have multi-purpose inputs, so if someone was using e.g. a Scarlett 2i2 to monitor the output via an RCA to XLR adapter, and accidentally engaged phantom power, boom.
2. this product is much more likely to be used in a rapidly changing test environment with multiple devices connected though adapters, and mistakes can happen

Making it completely immune to 48V applied across signal-return is hard, expensive, and comes with THD compromises, as discussed in the THAT paper. If you look at Focusrite's documentation they explicitly warn that engaging phantom power could damage attached devices. (as an aside, I wish they would make the phantom power button require a really long press to engage).

What I'm thinking is that this risk is minimal on the inputs - it would require someone using an RCA-XLR adapter, accidentally connecting our input to an external input with phantom power capability, and turning phantom power on.

On the outputs it's more plausible that an issue could occur. Schottky protection diodes from each signal output to the +13V rail can work. We have defined-load 2k resistors for the audio LDOs, so we can sink the 48V through those at ~5mA, and while there is back power it's going to be proportionate to the resistance of the phantom power output (presumed 5k or higher), and our 2k minimum load resistors, so 18V worst case. That's well within the rated ranges of all the components on the board.

So in summary my current proposal is:

• 100pf caps across all signal-return pairs
• No ferrite beads until data on THD is available
• No TVS on inputs or outputs. Rely on return isolation from case and external power ground.
• 30V schottkys from each output signal to +13V

 

[KSTR]

My standard scheme for a rugged input protection goes like this:

• One or more 200V spark gaps to GND or return path (and from return path to GND in that case). Basically exposed copper "half-moons" (no solder mask) with 0.1mm distance. http://www.carousel-design.com/SparkGap.html
• 47R 1206/MiniMELF Antisurge series resistor. Lesser resistors tend to degrade when zapped.
• 32V low capacitance TVS // 47pF 1kV NPO, to GND. Something like a PESD32VF1BLS-Q. We don't want capacitance modulation, thus low capacitance is required. TVS alone has limited surge capacity, therefore the spark gap in front of it.
• AC coupling when present.
• Bias resistor to GND for the opamp input. After that there is no input current other than whats needed to drive the opamp input itself.
• Back-to-back depletion high voltage MOSFET like BSS139 with a ~30R degeneration resistor, limits current to a few tens of mA, and has very low pass resistance.
• 47pF NP0 to GND.
• BAV199 catch diodes to the rails. Those diodes must be low leakage and very low capacitance, or they need bootstrapping to avoid capacitance modulation. Rails must be protected from being lifted. One can omit those diodes when using current limiting to less than 10mA (LND150, note the high pass resistance, or 2SK880GR JFETs , but note the limited voltage range and still high pass resistance)
• Another 47R series resistor and another 47pF shunt cap right at the opamp input, to shunt RF and to limit input fault current.

Ferrite beads are a two-sided sword, but not for potential distortion (no current == no distortion) but for building unwanted high-Q tank circuits with downstream shunt caps, also sometimes for unwanted H-field pickup Check in sim, and later in real circuit with a network analyzer. With the above scheme I've found not needing them, there is enough series resistance and distributed shunt capacitance.

For the MOSFETs and catch diodes see https://img.electronicdesign.com/fi...n/document/2020/05/Blencowe.5ec3eb2314f63.pdf

For output protection:

• Schottky catch diodes directly from opmap outputs to the rails, and rails protected from being lifted (I use 1.5W Zeners, like 15V for your 13V rails). Select a type that presents a managable capacitive load for the opamp but can handle a fault current of ~0.5A and much higher peak current (for example CUS05S40). Otherwise a L//R series cell for isolation in between.
• 32V TVS to GND
• 47R 1206/MiniMELF Antisurge series resistor. As that one may pass signal current, a thin film type should be used.
• 200V spark gap

In closing, I can only recommend to read, digest and follow all the advice given in Henry W. Ott's landmark book, "Electromagnetic Compatibility Engineering". If you don't already own a copy, get one. This is THE survival guide for successful and robust electronic device design.

 

[mcdn]

My standard scheme for a rugged input protection goes like this: ...

Wow! Tell me you've designed for hostile environments without telling me you've designed for hostile environments!

A lot to digest there, but some obvious things jump out:

• Spark gaps - if someone's putting 200V down an RCA cable they're making an insurance claim, not getting a warranty repair, but it's free copper, so why not I suppose, unless it causes layout issues. To avoid corrosion might need ENIG?
• Series film resistors - yes, total facepalm, those are mandatory. The Vishay 0204 MELFs we're using elsewhere on the board are well qualified
• Distributed RC filtering - adding another cap after the series resistor is a good cheap win and as you say largely removes the need for ferrites

I'll need to think further about the TVS situation, and the zener/schottky setup. RME for example don't as far as I know use either on e.g. the ADI-2, which has DC coupled outputs like ours and can sink the ~7ma of current phantom power would present, as can the OPA2211. Not clear what the powered-off/backpower situation would be for them or for us, and especially for us with the output switch open.

 

[KSTR]

Spark gaps - if someone's putting 200V down an RCA cable they're making an insurance claim, not getting a warranty repair, but it's free copper, so why not I suppose, unless it causes layout issues. To avoid corrosion might need ENIG?

PCB spark gaps are for catching the bulk of a strong ESD event or other short high voltage glitch with limited energy. They cost nothing but have limited precision and limited life-time, worst-case you get semi-shorts (or leakage) when there is too much deposit of carbonized material. There are integrated spark gaps available with true "air" gaps (often filled with some inert gas) which solve the issue. Parts like Panasonic EZAEG3W11AV or the rugged Littlefuse SH75.

HASL does work for PCB gaps but needs inspection for accidental solder bridges. In the early days of lead-free HASL there were incidents of tin whiskers growing bridges, shorting out the gaps.

Output protection is far less critical and easier to implement than input protection.

The problem with ESD that repeated incidents often slowly degrade parts rather than breaking them right away, they may still work for a long time, sort of, but go out of spec sooner or later or produce weird error symptoms. I learned that the hard way when I was involved in the design of automated test equipment (in-circuit testing rigs).

 

[Cascode]

Hi @mcdn, going through the numbers, I think you will have to make a concession some way or the other. Focussing on options with a mimum number of parts, we have:

OPAMP	BUFFER	DC 12 dB (typ.)	Rfb	THD	INPUT LINEARITY	NOISE -130 dBA / 0.63 µVrms
OPA1611	-	2.4 mV	680R	???	Rdut < 680R	Rdut < 600R / fail
OPA1611	BUF634-WB	2.4 mV	100R (max 150R)	pass	Rdut < 680R	Rdut < 800R / 200R
OPA828	BUF634-WB	0.2 mV	100R	pass	Rdut < 2k2	fails above 9 dB gain
OPA1611	AD797*	2.4 mV	200R	pass	Rdut < 680R	Rdut < 680R / fail

* OPA1611 as unity gain input buffer and AD797 as gain stage

As you see, the only minimum parts option that fullfills all requirements is the OPA1611 + Buffer. However, there is an argument for the OPA2828 (2 OPA828 in parallel) OPA828 + Buffer as well. Its distortion and noise are largely independent of DUT and frequency, it has basically no DC offset, and you could minimizing loading the DUT by raising the input resistor to e.g. 100k. Essentially, this would be a very neutral ABX box at the cost of slighty more noise. I see why @KSTR added this option.
Whether an OPA1611 alone would meet the THD requirements depends on how the different distortions add up. It may require a perfect implementation of the surroundings tough, while the original noise target would be violated anyway. An additional buffer therefore seems like an easy fix at the cost of 1 chip + 1 bypass capacitor in the signal path. If you would prefer to avoid buffers alltogether, you could switch to a 2 stage structure with the OPA1611 acting as input buffer and AD797 as gain stage (also 1 chip + bypass capacitor, see Fig. 34 AD797; EDIT: bypass capacitor was already specified).

Background numbers below. Please, double check this before deciding on anything ^^'

Global EDIT: paralleling OPA(2)828 does not work of course. Thank you @KSTR and sorry!!

Note on the Buffer
From a coarsery look, a SOIC BUF634 in wide bandwidth mode (BW pin to V-) should pass all targets. Expected output THD would be around -140 dB (~60 dB THD with 80 dB loop gain) and constant over the frequency range. A bypass capacitor of 220 pF (crossover at 7 MHz) would support at least a 1 nF load. This configuariont also matches the recommendations for the predecessor of OPA828, the OPA627 (Fig. 8-6). Peak power dissipation would be ~0.41 W, equaling a reasonable 50 K temperature raise.

Maximum Source Impedance
Assuming input linearity to be dominated by HD2, distortion should scale linearily with input voltage and source impedance. It is limited by the A-weighted THD at 10 kHz (-123 dB non-weighted), resulting in:

Rsource < THDtarget * Rmeasured * Vmeasured / (THDmeasured * Vtarget)

OPA1611 R < 680R
AD797 R < 680R
OPA828 R < 2k2
OPA2828 R < 1k (2 OPA828 in parallel)

Note, this is again an upper boundary, since the target power supply is slightly lower than that of the measurements (+-13 V vs 15V), resulting in slightly higher expected HD.

Maximum Feedback Resistor Noise
I forgot the noise gain in my original post The target specifies 0.63 µVrms. However, it might be worthwhile to omit this and focus on only -130 dBA THD+N at 4 Vrms instead, resulting in a target of 1.26 µVrms, see below.

The total input refered noise is limited by the 12 dB gain setting, giving an A-weighted input refered noise (Nin) of 1.4/2.8 nV/√Hz. With Rfb, Rg, and Rin as feedback, gain and input impedance, as well as Nv / Ni as voltage / current noise of the opamp, the target becomes:

Rfb||Rg < 59 * (Nin² - Nv² - (Rin * Ni)² - (Rfb||Rg * Ncurrent)²), from 0.13 √(R) = N with N in nV/√Hz
or
Rfb < 236 * (Nin² - Nv² - (Rin * Ni)² - (Rfb * Ncurrent / 4)²), for gain of 12 dB

Let's assume a minimal input impedance of 100R (DUT output + antisurge resistors). The maximum feedback resistance for 0.63 µVrms / -130 dBA Noise then becomes:

OPA1611 + Buffer Rfb < 150R / 1k2
OPA1611 + AD797 Rfb < fail / 1k2

OPA828 unfortunately fails, but OPA2828 in parallel with nonetheless the option with e.g. Rfb of 100R is noteworthy. Input refered noise is very close to the THD+N target (3.2 nV/√Hz, 1.4 µVrms, -129 dBA) 4.2 nV/√Hz, thus staying below -130 dBA until 9 dB gain, and constant irrespective of DUT output impedance. For comparison, the OPA1611 with 100R Rfb exceeds targets at 200R/800R input impedance.

References
https://www.nanovolt.ch/resources/ic_opamps/pdf/opamp_distortion.pdf (OPA211, AD797 input linearity, p. 24, 329)
https://www.diyaudio.com/community/...impedance-in-jfet-input-op-amps.264797/page-3 (OPA828 input linearity, Post 52)
https://www.ti.com/lit/ds/symlink/buf634.pdf (BUF634 datasheet)
https://www.ti.com/lit/ds/symlink/opa828.pdf (OPA828 datasheet)
https://www.ti.com/lit/ds/symlink/opa1612.pdf (OPA1612 datasheet)
https://www.analog.com/media/en/technical-documentation/data-sheets/AD797.pdf (AD797 datasheet)