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.

• [x] 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
• [x] 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).
• [x] 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
• [x] pease can we have at least a crude power budget?
• [x] 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?
• [x] Do we need 10uF on the DAC Vlogic supply, or is the current too low to need this?
• [x] 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
• [x] why are there 100nF capacitors on the DAC reference pins but not on the ADC ref pins?
• [x] on the CPU ADC DAC schematic page, why aren't there any filter capacitors on ADC2IN2{P,N}?
• [x] on the CPU ADC DAC schematic page, there are stray ADC2IN2{P,N} symbols
• [x] on the reference page, please add a note giving the feedback bandwidth for IC27A
• [x] 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.
• [x] annotation "Current drain to make the reference source happier - LT3042 sources 100uA curent via SET pin" is misplaced. What does this refer to?
• [x] on the reference page, there are some 13V symbols that don't connect to anything
• [x] 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 ADC2IN2{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 ADC2IN2{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.

[dtcallcock]

Awesome.

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

[jordens]

@hartytp A lot of use cases of a PID steer an analog or digital oscillator. Doing that with Stabilizer+Urukul is cheaper, smaller, more convenient, and arguably simpler than with Humpback+Sampler+Urukul. If the feedback path needs a DDS, sure someone will write a Urukul (i.e. AD9910) driver for the µC. I don't see the problem with that or how else it would be done. @gkasprow ACK the MCO programmable clock. But having just one clock for the entire CPLD fabric will mean a lot of functional interference and interdependencies between the four SPI buses if there are registers to be used in the CPLD.

[gkasprow]

OK, so I will route two ADC SPI clocks to CPLD clock input. And also will add alternative set of LVDS drivers that can be mounted on request in these rare use cases. I have free CPU pins so can also use bidir LVDS transceivers (DS92LV040A) which can be configured run-time.

[gkasprow]

I have enough CPU pins to make all LVDS drivers bidir.

[hartytp]

@hartytp A lot of use cases of a PID steer an analog or digital oscillator.

@jordens Okay, I see what you mean. I imagined that Stabilizer would only be used for Voltage in -> voltage out servos, and hadn't considered this use case (not to imply that this isn't valid, I just hadn't thought about it).

Am I correct in thinking that what you want is essentially a lower cost (only 2 channels, not requiring Kasli) version of SU servo? AFAICT, the cost savings will only be something like 25% compared with the Kasli servo, so nothing huge.

I guess that doing it on a microprocessor also makes it more flexible (easy to make it a stand-alone box with an ethernet interface)/easier to implement fancier feedback loops. Is there another advantage of doing this on Stabilizer that I'm missing?

If you want to go down that route then I can see why you need the "master"/"downstream" EEM connector. Would you want/need two EEM connectors, one upstream (to allow real-time control from Kasli) and one downstream (to control Urukul)? Or, is a single connector enough?

[hartytp]

I have enough CPU pins to make all LVDS drivers bidir.

If people think this is likely to be a common use case then maybe we should aim to support it by adding the bidir drivers?

[gkasprow]

We don't have enough space nor CPU pins for second EEM. I would have to redesign it from scratch and use big ICE40 FPGA. Adding of bidir drivers is simple, 1 hour of work.

[hartytp]

@gkasprow okay, that settles that then: no second EEM connector!

I'm indifferent to the bidir LVDS interface: if it's likely to be useful to people then let's add it. But, just bear in mind the cost/power consumption/complexity increase required to do that.

[jordens]

Steering Urukul is not exclusive to amplitude. This would in fact be more interesting for phase and frequency locks and especially more complicated locks (fiber length and power stabilization where that needs to be done in a single AOM). SUServo is currently limited to amplitude feedback with a simple PI.
Or use two Urukul outputs to downconvert two optical beats in analog, sample them with Stabilizer, steer two AOMs fast-ish using the other two Urukul outputs (with infinite tracking of phase wraps in software) and feedback slow using the DAC outputs onto two lasers. Throw in the ADCs to stabilize a beam power somewhere. Cost savings would be one reason, the other is that it is faster and easier to develop a complicated servo architecture in software on the µC than in gateware on Kasli. Integration is also easier. It would be much cheaper to develop the feature set, the ideas, and the user interface on and for Stabilizer+Urukul and then later port it to another set of hardware involving Kasli.

A single EEM connector is fine for now. Could even be restricted to only support either side of a Urukul-EEM0 link (clk, mosi, miso, 3 cs, io_update). Please not another FPGA/CPLD now.

In a second iteration we can then look at properly clocking Stabilizer from Urukul (via the EEM connector) or from its upstream EEM connector.

[hartytp]

Steering Urukul is not exclusive to amplitude. SUServo is currently limited to amplitude feedback with a simple PI.

Yes, although it can be extended to cover those other use cases.

Cost savings would be one reason, the other is that it is faster and easier to develop a complicated servo architecture in software on the µC than in gateware on Kasli. Integration is also easier. It would be much cheaper to develop the feature set, the ideas, and the user interface on and for Stabilizer+Urukul and then later port it to another set of hardware involving Kasli.

Fair enough.

A single EEM connector is fine for now. Could even be restricted to only support either side of a Urukul-EEM0 link (clk, mosi, miso, 3 cs, io_update). Please not another FPGA/CPLD now.

In a second iteration we can then look at properly clocking Stabilizer from Urukul (via the EEM connector) or from its upstream EEM connector.

:+1:

[gkasprow]

How would you like to clock Stabilizer from EEM? I can add DNP resistor to the clock input. The question is which clock.

[jordens]

It would be LVDS0 (the generic clock pin on EEMs from Kasli) or LVDS7 (when using automatic IO_UPDATE on urukul, dividing its DDS_SYNC_CLK0 by ~16 and routing it to LVDS7) and feeding to PH0, OSC_IN (HSE). This would need to be instead of the 8 MHz XTAL and the µC would fall back to its 8 MHz HSI RC oscillator during booting and/or when that clock signal is interrupted.

[cjbe]

@hartytp @gkasprow what is the current plan for mounting a custom AFE board? In general this board would require its own front panel, so will probably be spaced by 4HP = 20.32mm from the stabiliser board. I have not found any 0.1" pitch pin header with this spacing, so the boards cannot stack directly. This leaves us with ribbon cables, but these would have to route around the back of the AFE card to reach the top surface of the AFE card, meaning that the analog and digital signal cables run close together for quite a long distance - have we decided this is OK, or am I missing something?

[hartytp]

@cjbe I'd need to double check that distance. IIRC the plan was female pin header on the top of Stabilizer and on the underside of the AFE mezzanine.

[cjbe]

The distance is 18.72mm PCB surface to PCB surface, assuming 4HP board spacing and 1.6mm board thickness. I have not found any connectors on Digikey that come anywhere near this stackup, but this may be me not looking in the right places.

[hartytp]

https://www.toby.co.uk/uploads/publications/2012.pdf

[hartytp]

Something like this might also work https://www.toby.co.uk/board-to-board-pcb-connectors/254mm-sockets/esq-samtec-254mm-elevated-socket-strip-457mm-contact-1867mm-profile/

[hartytp]

(samtec has quite a few products for this kind of thing)

[hartytp]

@cjbe as you say, assuming stabiliser is 4HP wide, the separation between cards is 4*5.08mm=20.32mm. Thus, the distance from the top of Stabilizer to the bottom of the AFE is 18.72mm assuming 1.6mm PCBs.

@gkasprow what part number will you use for the shrouded headers on Stabilizer? Assuming the distance from the surface of the PCB to the bottom of the mating surface is 2.54mm, which seems somewhat standard, that leaves a gap of 16.2mm.

16.13mm seems to be a common height for elevated shrouded headers. For example, we can use the Samtec ESW series. Availability depends on the numbers of contacts used, but generally isn't great e.g. for the 2x17 GPIO header: https://octopart.com/search?q=esw-117-33&start=0&avg_avail=(1__*)

What do you think about this @gkasprow? What's your suggestion for board-board connectors to go between Stabilizer and its AFE?

[hartytp]

Having said that, some parts in the ESW series do have good availability like the 2x5 one: https://www.digikey.co.uk/product-detail/en/ESW-105-33-G-D/SAM12535-ND/2651068?utm_campaign=buynow&WT.z_cid=ref_octopart_dkc_buynow&utm_medium=aggregator&curr=gbp&site=us&utm_source=octopart

Since they can be stacked, this could work if, for example, all the board-board connectors have a multiple of 10 pins. Anyway, maybe @gkasprow has a better idea, but that is one possible solution...

Edit: see https://www.digikey.co.uk/products/en/connectors-interconnects/rectangular-connectors-headers-receptacles-female-sockets/315?k=&pkeyword=&sv=0&pv2018=468&sf=0&FV=ffec224c%2Cffe0013b&quantity=&ColumnSort=0&page=1&stock=1&pageSize=25