v1.0 rc2 design review

[hartytp]

https://github.com/sinara-hw/Stabilizer/releases/tag/v0.9rc2

[hartytp]

@cjbe

[hartytp]

@gkasprow I've completed my review. Looks great! Thanks.

My comments are below... Looking forward to getting these made.

• let's DNP the 50R terminators on the MMCX inputs. I always feel that 50R terminating a LVCMOS input is a bit aggressive and source termination is more effective. Good to have the pads there in case one really needs them
• am I right in thinking that the GPIO header is mechanically computable with EEM connectors, but uses different logic levels? That sounds like a recipe for disaster. Please can we make sure that it is not possible to insert an EEM connector into the GPIO header. Also, NB, since the GPIO header is not compatible with IDC<->BNC there is currently no easy way of exposing those signals via BNCs (not sure this a problem, just pointing it out cc @dtcallcock).
• can we do the connection between the microprocessor DAC outputs on page 1 by using net naming instead of nets that run over the microprocessor block
• pease can we have at least a crude power budget?
• the annotations on p2 make it look like the barrel connector is on the FP and an AXI connector is on the rear. Is that correct? I thought there is no FP power connector?
• Do we need 10uF on the DAC Vlogic supply, or is the current too low to need this?
• Did you optimise the capacitance on the reference buffer output? Currently it has an output capacitance of 40uF which is ten times the data sheet recommendation and could lead to reduced reference BW (higher output impedance at higher frequencies) or even instability. This should be checked in your simulation
• why are there 100nF capacitors on the DAC reference pins but not on the ADC ref pins?
• on the CPU ADC DAC schematic page, why aren't there any filter capacitors on ADC2_IN2_{P,N}?
• on the CPU ADC DAC schematic page, there are stray ADC2_IN2_{P,N} symbols
• on the reference page, please add a note giving the feedback bandwidth for IC27A
• why are the ADC reference pins driven directly from the LTC6655? They have roughly the same requirements as the DAC reference and should also be driven from the LTC3042.
• annotation "Current drain to make the reference source happier - LT3042 sources 100uA curent via SET pin" is misplaced. What does this refer to?
• on the reference page, there are some 13V symbols that don't connect to anything
• on the uC ADC page, please can you add an annotation saying "ADCs: 6xsingle-ended (0-2V) or 3 x differential (0-4V)"

[gkasprow]

let's DNP the 50R terminators on the MMCX inputs. I always feel that 50R terminating a LVCMOS input is a bit aggressive and source termination is more effective. Good to have the pads there in case one really needs them

OK, that's why I added RC termination so it works only for fast edges and do not consume energy in steady state

am I right in thinking that the GPIO header is mechanically computable with EEM connectors, but uses different logic levels? That sounds like a recipe for disaster. Please can we make sure that it is not possible to insert an EEM connector into the GPIO header. Also, NB, since the GPIO header is not compatible with IDC<->BNC there is currently no easy way of exposing those signals via BNCs (not sure this a problem, just pointing it out cc @dtcallcock).

I did it in such way to not break the Kasli when inserted by chance. But in some circumstances it may trigger latchup, so let's not tempt the user.

can we do the connection between the microprocessor DAC outputs on page 1 by using net naming instead of nets that run over the microprocessor block

sure

pease can we have at least a crude power budget?

I did detailed one

the annotations on p2 make it look like the barrel connector is on the FP and an AXI connector is on the rear. Is that correct? I thought there is no FP power connector?

true, fixed
By default DC jack will be installed, but Molex connector can be populated for EEM operation.
If you want the opposite, let me know.

Do we need 10uF on the DAC Vlogic supply, or is the current too low to need this?

It is roughly 1mA, but let's add one.

Did you optimise the capacitance on the reference buffer output? Currently it has an output capacitance of 40uF which is ten times the data sheet recommendation and could lead to reduced reference BW (higher output impedance at higher frequencies) or even instability. This should be checked in your simulation

LTC and other LDOs do not like big low ESR capacitors. So we will use tantalium 10uF ones close to the DAC. Such ones are shown in DAC datasheet.

why are there 100nF capacitors on the DAC reference pins but not on the ADC ref pins?

OK, added

on the CPU ADC DAC schematic page, why aren't there any filter capacitors on ADC2_IN2_{P,N}?

we do not use it. I routed it to digital IO connector because they are also digital pins

on the CPU ADC DAC schematic page, there are stray ADC2_IN2_{P,N} symbols

fixed

on the reference page, please add a note giving the feedback bandwidth for IC27A

done

why are the ADC reference pins driven directly from the LTC6655? They have roughly the same requirements as the DAC reference and should also be driven from the LTC3042.

true, fixed

annotation "Current drain to make the reference source happier - LT3042 sources 100uA curent via SET pin" is misplaced. What does this refer to?

not valid anymore, removed

on the reference page, there are some 13V symbols that don't connect to anything

fixed

on the uC ADC page, please can you add an annotation saying "ADCs: 6xsingle-ended (0-2V) or 3 x differential (0-4V)"

done

[gkasprow]

I did simulation of whole reference circuit.

green - REF output
blue - opamp output

After power on

Offset compensation

and ripples

[hartytp]

OK, that's why I added RC termination so it works only for fast edges and do not consume energy in steady state

Makes sense. However, 10nF is quite a large capacitance. It gives a 300kHz pole with 50R, which is a much lower frequency pole than we require to filter our fast rising edges. I'd either DNP the resistor or use a smaller capacitor.

I did detailed one

Thanks! Particularly with PoE devices, it's really useful to have power budgets to allow one to ensure that one won't overload a switch with multiple devices drawing power.

true, fixed
By default DC jack will be installed, but Molex connector can be populated for EEM operation.
If you want the opposite, let me know.

That sounds good.

---

I did simulation of whole reference circuit.
After power on

These curves look like there is quite a lot of ringing in the step response. Would it be better to decrease the OpAmp feedback bandwidth a bit to improve the stability?

and ripples

Remind me, what is this simulation? Is this all 4 data converters (2xDAC and 2XADC) drawing 550uA at 10kHz 100kHz and 1MHz? If so, that looks great since the pk-pk ripple is only 20uV, which is much less than 1LSB (65uV).

[hartytp]

Anyway, I'm really happy with the design now and don't have any further feedback on the schematic. Let's leave a few days for any other interested parties to comment on the schematic before closing this and beginning the layout.

[gkasprow]

well, the layout is nearly done :)
The simulation was with 5 sources drawing 200uA each
I played with various component values. Take into account that this oscillation is initial value after power up. So there was large step response. When I lower the RC values, the number of oscillations is more or less the same, but they decay faster

[hartytp]

well, the layout is nearly done :)

Nice! :)

The simulation was with 5 sources drawing 200uA each

Okay, good. 200uA makes sense, since this is about the size of the change in the reference current (550uA is the peak reference current, but it should not change by 100%). And, in any case, the 20uV pk-pk from you simulation is comfortably below a LSB, so there doesn't seem to be any issue here.

What frequencies did you include in your simulation?

[gkasprow]

2MHz, 200k, 20k, 2k, 200Hz,

[hartytp]

2MHz, 200k, 20k, 2k, 200Hz,

Okay, good, that's very thorough. I'm amazed the pk-pk noise is so low with so many converters drawing current at that many frequencies. The LT3042 is a magic chip!

No further comments/questions from me on the schematic then.

Just one thing about the layout (reiterating something I've said before): let's try to route the converter references from the LT3042 using short thick traces in a star topology (separate reference trace for each converter rather than a single trace) to avoid cross-talk due to common-impedance couplings on the terence line.

[hartytp]

Actually, one final comment :)

The LT3042 data sheet has this comment about the output capacitor:

This pin supplies power to the load. For stability, use a minimum 4.7μF output capacitor with an ESR below 50mΩ and an ESL below 2nH

I suspect that putting 10uF tantalum capacitors near the data converters will not be sufficient to ensure stability. Probably best would be to have an additional 4.7uF ceramic capacitor right by the LDO. But, again, we'd need to double check this in the simulation.

Also, FWIW, if I understand the spice schematic you posted correctly, you didn't include capacitor ESR/ESL or trace impedance. That's fine, but does mean that the over all reference transients could be a little larger than simulated. I don't think this will be a problem in practice.

[hartytp]

Okay, good. 200uA makes sense, since this is about the size of the change in the reference current (550uA is the peak reference current, but it should not change by 100%).

FWIW, I think this is not true. AFAICT the reference current does change by 100% as one sweeps the data converter codes through their full range. However, from the simulations, it's clear that the RMS noise will still be well below 1LSB, even if you simulated with 550uA.

[gkasprow]

LT3042 is so magic only when properly loaded, if you run it without load, performance would be poor :)
That's why I run 18mA of current through it. It has bipolar stage, and the higher the current, the lower is output resistance.

[gkasprow]

I included capacitors ESR. I assumed 1Ohm for 10u tantalium caps and 10mOhm for ceramic ones.

[gkasprow]

[hartytp]

LT3042 is so magic only when properly loaded, if you run it without load, performance would be poor :)
That's why I run 18mA of current through it. It has bipolar stage, and the higher the current, the lower is output resistance.

Good catch. I hadn't appreciated that.

I included capacitors ESR. I assumed 1Ohm for 10u tantalium caps and 10mOhm for ceramic ones.

Okay, good. I guess the 100nF capacitors have low enough ESR to ensure stability.

However, I'd still be inclined to put some capacitance right by the LT3042 to aid with stability (e.g. you model doesn't include trace ESL/ESR which can degrade stability).

[hartytp]

I assumed 1Ohm for 10u

the photo you posted shows 10u with 10mOhm ESR...

[gkasprow]

it was for ceramic ones. But for tantalium in A case I use 1Ohm.

[hartytp]

it was for ceramic ones. But for tantalium in A case I use 1Ohm.

Ok, sounds good then. Maybe add 1uF ceramic right at the LT3042 output if only to make me happy?

[gkasprow]

at the moment we have 10u ceramic at the output of LT3042 + 10uF tantalium and 100nF ceramic at every ADC and DAC. I changed the one at the LT3042 output to 1uF ceramic one.

[hartytp]

at the moment we have 10u ceramic at the output of LT3042 + 10uF tantalium and 100nF ceramic at every ADC and DAC.

Aah, ok! I hand't realised that you had the 10u ceramic at the output of the LT3042. In that case what you had was already fine. Sorry for the confusion!

I changed the one at the LT3042 output to 1uF ceramic one.

AFAICT 10uF is ok but probably a little bigger than optimal. 4.7uF would be optimal (according to the data sheet) if you didn't have the DAC/ADC capacitors. With them, we can use a little less. 1uF-4.7uF is fine, pick whichever you think is best.

[gkasprow]

@hartytp @jordens I finished layout.
Please have a look. Let's leave it for a while and then send for production with other boards.

[hartytp]

cool, thanks Greg!

So long as you're happy with the layout it's fine by me. I would only have the usual questions like:

• are the reference traces thick enough to avoid cross-talk
• PI okay?
• are we happy that the layout is good to minimise analog channel-channel cross-talk as well as digital-analog cross-talk

[gkasprow]

I used 20mils tracks for references.
I didn't do full PI analysis. This takes time. I simply specified minimal via and trace size for all critical power rails. You can see rule symbols on schematics. This is sufficient for circuits with such low power density. Only 3.3V rail takes more current, it has dedicated higher power rule.
I paid attention to geographically isolate AFE from digital signals. Also analog signals are routed away from digital ones. I used local keepout traces to make sure they are isolated.
This is example

[gkasprow]

These are not traces, but graphical rules that separate traces from each other.

[jordens]

From a quick look:

• The SPI*R_SCK should probably be on the CPLD GCK inputs to make meaningful use of the CPLD. But there are only three which will make this pretty difficult. I would put the two DAC and the first ADC clock onto the GCL pins.
• It would be useful to be able to control Urukuls from Stabilizer (for several of the use cases I mentioned above). But currently this won't work because the EEM connector is a slave.

[hartytp]

I used 20mils tracks for references.
I didn't do full PI analysis. This takes time. I simply specified minimal via and trace size for all critical power rails. You can see rule symbols on schematics. This is sufficient for circuits with such low power density. Only 3.3V rail takes more current, it has dedicated higher power rule.
I paid attention to geographically isolate AFE from digital signals. Also analog signals are routed away from digital ones. I used local keepout traces to make sure they are isolated.
This is example

Nice. Thanks Greg.

[gkasprow]

@jordens I connected CPLD clock to programmable RCC clock source that drives all SPI peripherals. So this can be used for all SPI related activities.
We can add assembly option and place additional LVDS drivers below existing ones ( on bottom side).

[hartytp]

It would be useful to be able to control Urukuls from Stabilizer (for several of the use cases I mentioned above). But currently this won't work because the EEM connector is a slave.

We discussed this before, but decided against it as it adds a fair bit of complexity/cost (bi-dir LVDS drivers etc) and the use case seemed a bit marginal (is anyone really going to write a Stabilizer driver for Urukul and include it in the firmware?).

However, if you really feel that this is an important feature then I don't object to including it. One option might be to replace the CPLD with a cheap FPGA that supports LVDS signals, and then route all EEM signals via the FPGA for direction control etc.

[gkasprow]

For rare use cases one can use Humpback + Urukul + Stabilizer. If we use FPGA right now, one would need to support HDL code for every Stabilizer version. I hope we won' have to use CPLD and it will be removed or DNP in next revision.

[gkasprow]

v1.0rc1

[cjbe]

@gkasprow 5mm would be perfect.

[cjbe]

@gkasprow it would be useful if the P12V0A and N12V0A rails are brought out to the "ADC and DAC header" (instead of P/N13V0S).

This means that a minimal piggyback board with a couple of op-amps on would not need to have any additional regulators on.

[dtcallcock]

• Can DI0/DI1 use a 5V-tolerant buffer to offer more flexibility on what random lab boxes can be plugged into them?
• Is there room for MCX instead of MMCX for DI0/DI1? If MMCX is going to become Sinara's de-facto connector for places where SMA/BNC is too big then we should consider whether it's robust enough for use on a crate front panel. See also here.

[gkasprow]

this should fit

[cjbe]

@gkasprow according to ST's RM0433 section 59.4.1 the JTCK line has an internal ~40k pull-down that will fight with the 10k pull-up. If we are going to have a resistor it should be a pull-down.

[gkasprow]

switched input buffers to 5V-tolerant SN74LVC1G125DCKT
fixed TCK pulldown resistor.

[hartytp]

🎆

[cjbe]

@gkasprow could you make the following two changes:

• it would be useful if the P12V0A and N12V0A rails are brought out to the "ADC and DAC header" (instead of P/N13V0S).
• move the MMCX digital inputs to pads with timer capture-compare inputs. E.g. move DI1 and DI2 to PA3 and PA8.

[dtcallcock]

On the 'Stabilizer AUX connector' schematic page I don't see filter capacitors on ADC1_IN1_{P,N}. Also, the capacitor on ADC2_IN2_N (C164) looks like it has the wrong value.

This still seems wrong on v1.0 Production.

Also, I don't see the bidirectional buffers required for CPCIS & downstream EEM support. Is that still planned?

[gkasprow]

We finally decided not to implement downstream buffers due to limited use cases. But if you insist, I can add them.

[gkasprow]

@cjbe DI0 and DI1 are connected to ADC trigger lines.
I can connect them in parallel to PA3 and PA8

[dtcallcock]

We finally decided not to implement downstream buffers due to limited use cases.

That's fine I just didn't see a consensus against it in the above thread so I wanted to check.

As @jordens mentioned, the killer app here is being able to do drive an Urukul and do phase/frequency servoing. However if an RF mezzanine for Stabilizer is thought to be a better way of doing it (as @hartytp suggests) then I'd be ok with leaving them off. I just don't want to be in a situation where one has to resort to adding a Kasli or Humpback just for want of a few LVDS buffers.

[gkasprow]

would assembly option be fine for you or you prefer a firmware-configurable direction control?

[gkasprow]

I could simply put additional buffers with reversed direction on the other side of PCB nad keep them DNP

[dtcallcock]

If that's easy for you to do, it sounds like a reasonable plan. These are easily hand-solderable SOIC-8 packages by the look of it.

[gkasprow]

OK, done

[gkasprow]

and drivers

[gkasprow]

they have nearly mirrored pin assignment so that was easy

[dtcallcock]

Looks good. Won't the receivers need some DNPed pads for 100Ohm termination though?

[gkasprow]

true, just added them:)

[cjbe]

@gkasprow
Could you reconnect the P/N13VS to the "CPU ADC DAC header" (J13).

This way the piggyback board has access to the noisy but higher current P/N13VS from J13, the lower current nice supply P/N12VA from J4, and P12V0 and P3V3 from J3.

[cjbe]

@cjbe DI0 and DI1 are connected to ADC trigger lines.
I can connect them in parallel to PA3 and PA8

This is fine. If we need more IO, we could remove the connection to the ADC trigger lines, as PA3 / PA8 give us the timer inputs - we can use this to timestamp the edges and trigger the ADC at a fixed time off-set from this.

[gkasprow]

I’m afraid it already was sent for production…

[cjbe]

No problem - this is a minor user-friendliness improvement we can add to the next revision