Sayam: DNF HMC7043 LVDS bias resistors

[hartytp]

• [ ] FPGA SYSREF inputs need LVDS, not LVPECL. So, it doesn't make sense to have the 200R bias resistors, as they just decrease the LVDS signal amplitude, which could cause SI problems. Let's scrap (either DNF or, better yet, remove) them.

For the transceiver clock inputs, LVDS might well be a better choice than LVPECL (it's also less aggressive if it's driven into an input that's not properly biassed). AFAICT, there is no need for the FPGA clock to be ultra-low noise, so the marginal noise improvement in using LVPECL is not needed -- and, even if it were, by the time that signal has passed through some buffers in the FPGA, I doubt one can still see the difference.

AFAICT, the only reason we're not using LVDS for the FPGA MGT REFCLK inputs at the moment is that @gkasprow measured the signal amplitude to be a bit on the low side. My guess is that DNFing the bias resistors will fix this.

• [ ] @gkasprow can you remove these resistors, change the HMC7043 logic standard to LVDS and measure the signal level at the AMC FPGA, please? Once we have that measurement, we can decide what to do.

[sbourdeauducq]

FPGA SYSREF inputs need LVDS, not LVPECL. So, it doesn't make sense to have the 200R bias resistors, as they just decrease the LVDS signal amplitude, which could cause SI problems.

Would that explain why SYSREF/RTIO alignment sometimes breaks on some boards?

and, even if it were, by the time that signal has passed through some buffers in the FPGA, I doubt one can still see the difference.

The two paths inside the IBUFDS_GTE3 that I mentioned in another issue are there for this reason; the path to the transceiver is lower-noise. Someone should check if we can run the transceiver at the required data rate for the expected level of clock noise.

[hartytp]

Would that explain why SYSREF/RTIO alignment sometimes breaks on some boards?

I very much doubt it. Removing those resistors is more "good pratice" than because I'm genuinely worried about SI.

However, having said that, there is no reason to have them on any FPGA input that can't tolerate LVPECL levels, so it would probably be a good idea to remove them. They're nice big resistors, so it's really quite easy to do.

Removing these resistors is also probably a good idea because:

1. Having LVPECL bias resistors makes it look like LVPECL is a valid choice when someone unfamiliar with Sayma looks at the design. So, it sends out kind of misleading signals
2. If we remove them then it ensures that if one accidentally misconfigures the HMC7043 to LVPECL outputs on those channels then one gets no signal, which is better than a signal that exceeds the FPGA's input buffers max range

[hartytp]

The two paths inside the IBUFDS_GTE3 that I mentioned in another issue are there for this reason; the path to the transceiver is lower-noise. Someone should check if we can run the transceiver at the required data rate for the expected level of clock noise.

It is probably worth checking what the transceivers require in terms of jitter for full BW operation. However, in practice, I'm not worried about that; the HMC7043 is exceptionally low noise (whatever we think of the digital interface, HMC7043 do phase noise well!) in all output standards. Also, note that the HMC7043 output buffer would just contribute a low-level white noise floor, so it only affects relatively high frequencies (for low frequencies we're limited by the reference). But, the PLLs inside the FPGA will filter most of that out anyway.

Related, but why aren't we using CML for the transceivers? Isn't that what they're designed for? If we did that we'd also want to remove the output resistors...

[gkasprow]

CML output is 1.3Vpp (low power) or 1.8Vpp (high power) while LVPECL is 1.8V and LVDS is 0.75V (high power) and 0.39V (low power) So we can use low power CML with internal termination or high power LVDS. But resistors must be removed anyway. Using LVPECL or high power CML can stress the FPGA input buffers too much.

[hartytp]

:+1: but, we should still make sure to check the signal at the FPGA pins at some point to ensure we're happy with SI.

[marmeladapk]

@gkasprow @hartytp This should be now obsolete, since we're removing HMC7043, right?

[hartytp]

Yes.

[hartytp]

But, there does need to be a general issue about verifying signal levels generally. e.g. in the old design we were overdriving several inputs with LVPECL levels.

[marmeladapk]

Ping @gkasprow

[gkasprow]

We can simply add 50R series resistors to not override LVDS levels with LVPECL outputs...

[gkasprow]

@sbourdeauducq do we still need SYSREF from HMC7043 to the AMC FPGA? What about HMC7043 REFSYNCIN? Connect it to the AMC FPGA or RTM FPGA?

[sbourdeauducq]

@sbourdeauducq do we still need SYSREF from HMC7043 to the AMC FPGA?

Yes. We don't strictly need it but it makes things easier and allows for more experimentation.

What about HMC7043 REFSYNCIN? Connect it to the AMC FPGA or RTM FPGA?

RFSYNCIN (not spelled REFSYNCIN) is not used and not planned to be used.

[sbourdeauducq]

You can put RFSYNCIN on uFL, if that's easy, just in case.

[sbourdeauducq]

Workable SYSREF routing options, from best to worst: 1) Two SYSREF to AMC, two SYSREF to RTM 2) Two SYSREF to AMC, one SYSREF to RTM 3) One SYSREF to AMC, two SYSREF to RTM 4) One SYSREF to AMC, one SYSREF to RTM 5) One SYSREF to RTM

Option 5 requires significant gateware changes and should be avoided.

[sbourdeauducq]

Also try to use the HMC7043 dedicated "SYSREF" channels (odd channels) for SYSREFs, though that's not strictly a requirement.

[gkasprow]

OK, so I connected HMC7043 outputs to: AMC LVDS21, same bank as SYNCOUT and LVDS link between FPGAs I also changed names on RTM sheet so LVDS and GT lines from AMC are called AMC_GT.xx and AMC_LVDS.xx Another 2 SYSREF lines are routed to the RTM FPGA, the same bank as clocks. One of them is routed to MRCC

[sbourdeauducq]

AMC LVDS21, same bank as SYNCOUT and LVDS link between FPGAs

what is SYNCOUT? The CDR output? OK.

[sbourdeauducq]

So we get option 3.

[gkasprow]

I mean the SYNCOUT of DAC is in the same FPGA bank as HMC7043 SYSREF.

[gkasprow]

but it is in a different bank as AMC CDR output.

[sbourdeauducq]

but it is in a different bank as AMC CDR output.

OK that shouldn't matter, on the AMC the normal plan is to sample that signal with a clock derived from the GTH. On the RTM it should be the same bank though.

[gkasprow]

Let's summarize. Which of the signals below need to be in same AMC FPGA bank: CDR REC clock SYSREF IN from HMC7043 WR clocks DAC SYNCOUT 10/10

[sbourdeauducq]

SYSREF (on the AMC) and SYNCOUT are only sampled at 125/150MHz and have no particular bank requirements. CDR clock to the fabric is a debug signal - normal plan is to use the clock through the GTH. It probably makes sense to put it and the WR clocks in the same bank though. In general I didn't find pin assignment issues, other than what I reported, with the assignments that are in the Dec 13, 2018 release.