isolation jumpers

[hartytp]

The desire to have the IO isolated came from older systems where all control hardware shares a common ground. Now Kasli + DRTIO works well, this seems to be less important; it's generally easy to have sub-sections of the experiment that require different grounds running from different Kaslis, with DRTIO fibres providing isolation. Cases where 1-2 IOs need a completely separate ground do still exist, but seem much less common.

Isolating grounds like this has some gotchas, and is probably not a good default option. I can see two paths forward:

1. Make new versions of the IO boards without the ioslation
2. Add populated-by-default jumpers to the next revision of these boards, which tie the grounds together.

My preference would be 2 because

Pros:

• Trivial change to existing design, much less work/risk of breakage than ripping out the isolators and creating a new design. In the current design, we already have R19 and R25 that can be used to break the isolation (replace with 0R). However, having a jumper seems nicer (no soldering required, and visually easier to see what's happening) and shorting the grounds together by default seems like a good idea.
• Easy to switch between isolation and non-isolation to investigate ground loops

Cons:

• Marginally more expensive (need extra isolators etc). Doesn't really concern me since the cost increase is small and probably swamped by batch size etc (i.e. producing more each of fewer designs probably cheaper)
• More complicated. Again, fewer designs means each is likely to be more widely used, better tested/documented etc, which for me outweighs a small increase in complexity
• More latency/jitter. IIRC the jitter we measured was a few hundred ps, which should be fine for most applications (applications needing much less jitter should probably consider using stamper etc). Also, the jitter was a few times larger than the specified jitter from the isolator, so not clear how much removing it will win us.
• hidden state: one thing I like about Sinara is that almost all state (switches open/closed, terminators, etc) can be seen either from FP LEDs or from diagnostics (SCPI etc). This makes fault-finding etc much nicer. Having state (isolation/no isolation) that cannot be checked without removing PCBs from the rack concerns me. Not sure what the best solution to this is.

Thoughts?

[jordens]

Yes. We need a low-jitter, non-isolated, cheap, high-density, low-EEM-count DIO solution.

IIRC the jitter was pretty much the isolator value which was ~500ps RMS and thus very much comparable to the 1ns resolution. It would be great if we could resolve the jitter issue of the isolators at the same time. The non-isolated driver does not have to have that issue but merely jumpering ground would transplant it.

We already have a good non-isolated IO solution: Banker. Already for the usual number of DIOs (>= 24) Banker does not significantly differ in price and saves lots of EEM connectors and -- if desired -- front panel space.

[hartytp]

IIRC the jitter was pretty much the isolator value which was ~500ps RMS

The isolator is 350ps pk-pk, RMS is <100ps I believe

[hartytp]

What jitter do you expect from the FPGA -> ribbon cable -> LVDS buffer -> LVDS-LVCMOS driver? I don't have a well-calibrated expectation for that (particularly the FPGA), but no point optimizing the isolator below the other jitter sources. There are also lower jitter isolators (by at least a factor of a few) if we really want, but good to be clear on our goals before altering designs.

The non-isolated driver does not have to have that issue but merely jumpering ground would transplant it.

To be clear, you mean that jumpering across the isolator to tie the grounds together does not decrease the jitter?

We already have a good non-isolated IO solution: Banker. Already for the usual number of DIOs (>= 24) Banker does not significantly differ in price and saves lots of EEM connectors and -- if desired -- front panel space.

Is your point here that we should just not bother with the {BNC, SMA}_DIO boards here and everyone should use banker?

[jordens]

I stand corrected on the isolator datasheet value. But you measured 750ps pk-pk in practice and given the design of the isolator I would expect the distribution to be mostly uniform and thus the RMS value to be not much less than 500ps.

Currently, the jitter between a pair of TTLs is about 1.5ns pk-pk, so something like 750ps pk-pk jitter per TTL. AFAICT, this is dominated by the isolators.

sinara-hw/sinara#222 (comment) etc

[jordens]

The FPGA is in the 90ps range "bad" case output jitter IIRC (from the Urukul SYNC issue).
If we make a non-isolated option we should not make that non-isolated option as jittery as the isolated one.
IMO for applications from 24 non-isolated channels upwards Banker looks to be a better solution than three or more DIO modules. I'm not saying that everyone should use Banker or that the DIO modules should die. I'm fine with adding jumpers to the DIO modules. But I think a new non-isolated DIO version aims for a use case that could be better filled by Banker.

[hartytp]

Thanks for digging that out.

So, we measured 1.5ns pk-pk jitter between a pair of TTLs. Assuming each TTL contributed half the pk-pk jitter, that's 750ps per TTL, which is still a factor of 2 greater than the specified max jitter. So, it's still not obvious to me that we can blame this on the isolator.

[hartytp]

IMO for applications from 24 non-isolated channels upwards Banker looks to be a better solution than three or more DIO modules. I'm not saying that everyone should use Banker or that the DIO modules should die. I'm fine with adding jumpers to the DIO modules. But I think a new non-isolated DIO version aims for a use case that could be better filled by Banker.

Okay.

I haven't really thought too much about Banker (or trade-offs in terms of update rates/latency for that design), so it may be that some of our use-cases would be better served by it. Did you measure jitter with Banker?

It seems like adding a jumper is a good idea anyway. Having some way of detecting the isolation state (FP LED/something on an I2C extender) would be nice if we do it.

[hartytp]

RMS value to be not much less than 500ps.

Assume that's a typo and you mean "not much less than 350ps"

[jordens]

I didn't measure jitter with Banker.
Yes. The RMS of a 750ps wide uniform (underlying the triangular convolution of the two TTLs) distribution is 750ps/2/sqrt(3)=217ps.

[hartytp]

Yes. The RMS of a 750ps wide uniform (underlying the triangular convolution of the two TTLs) distribution is 750ps/2/sqrt(3)=217ps.

So, the 350ps pk of jitter specified by the isolator is ~100ps RMS. So, not too far off what one might expect from the FPGA and other jitter sources. i.e. on the basis of current evidence it looks like: (a) we're not currently limited by the isolator's jitter (b) the isolator's jitter is probably not that much worse than the FPGA etc (and IIRC there are a few other isolators with a factor ~2 less jitter).

tl;dr without further data, I don't think jitter is a strong reason to remove the isolator.

[jordens]

IIRC the fpga jitter was also peak, I don't know about the speculation w.r.t not being limited by the isolator. But sure. Somebody should measure it.

[gkasprow]

The isolators are supplied by DC/DC converters. I added LC filter but some ripples are still there and may impact the jitter.

[gkasprow]

What about making a high density, 16-channel MCX board with low jitter, high-speed IOs?
Something like this:

[gkasprow]

Banker is very limited because does not support DRTIO. Such a solution would enable 1ns timing resolution occupying only 4HP. This is essential when used in the CPCIS crate.

[hartytp]

Sounds like a good idea

[jordens]

That is not much of a limitation in practice. Banker doesn't need to support drtio. It can still give you full timing resolution by routing the eem signals to the desired ios dynamically.

[gkasprow]

True, but it's unnecessary complexity and adds a jitter and delays that it's hard to control.
Anyway, if there is such a need, I can release such a board.

[gkasprow]

Let's close it. I designed a 16channel IO MCX board without isolators. It should reduce jitter significantly.