Sayma: drop support for LLRFBP in v2.0

[hartytp]

I've been thinking a bit more about what Sayma v2.0 should look like, and I want to raise the possibility of dropping support for the low-level RF backplane.

My proposal is that we drop support for the LLRFBP and instead only support two options for supplying the reference clock:

1. Front panel SMA on Sayma RTM
2. DRTIO clock from the Si5324

As discussed elsewhere, providing the HMC830 ends up working well and the noise matches our simulations (and hence is essentially as good as the DAC's noise floor), we would only support one source of DAC clock: the HMC830.

My reasons for dropping the LLRFBP are:

• There is currently only 1 LLRFB available, and only for one rack, with no more likely to exist in the near future. This makes it quite inflexible (can't be used with half-sized racks)
• It's very expensive and has a long lead time.
• The LLRFBP also requires Baikal to work. This board hasn't been tested or documented yet. Relying on Baikal means one more board that users have to buy, understand and configure correctly and generally increases the complexity/hassle/cost of Sinara/Sayma.
• The only real planned use for the LLRFBP in Sinara is distributing the 100MHz reference (assuming we all agree that the HMC830 is fine for generating the DAC clock), but:
  • We are already using DRTIO to distribute a reference clock to the RTM. After jitter filtering by the Si5324, followed by the HMC830, the performance of the DRTIO/CDR clock is very good, and pretty close to the DAC's noise floor (cf the phase noise plots on the Si5324 datasheet and the plots that Weida posted).
  • Thus, the DRTIO clock distributed via fibres/the AMC backplane will be good enough for boards like Shuttler, and will be good enough for the majority of Sayma uses -- the improvement from using an ultra-low oscillator is pretty marginal given that the DAC itself isn't ultra-low noise (DACs never are!).
  • For all standalone Sayma applications the LLRFBP obviously can't be used
  • So, the only use case for the LLRFPB is: people who really want that last bit of improvement in noise for Sayma; are prepared to buy the fancy rack + Baikal/etc; and who really want the extra convenience of not having to route the clock to Sayma via an external SMA (although even then, I'm not sure this is more convenient given the extra hassle of having to get the special rack + Baikal, etc).But, that's a pretty niche use case.
  • Whenever Sayma is used in a rack there will generally be a Eurorack nearby for VHDCI breakout etc. It's cheaper and arguably easier to add a clocker or two to that rack and use that for low-noise clock distribution via the SMA on Sayma RTM's front panel. The only downside of that is a minor inconvenience of having to have one more SMA per Sayma. But that's pretty negligible compared to the 16 coax cables already going into each Sayma.

So, given the above, I really don't see a strong case for supporting the LLRFBP. By fully removing this, we get to:

• Remove some expensive connectors from Sayma RTM
• Not have to worry about finishing, documenting and testing Baikal
• Remove a bunch of muxes (and associated LDOs), reducing complexity, power consumption and cost.
• generally simplify the clock distribution network quite a bit

[hartytp]

FWIW, we actually did buy some racks with LLRFBP. However, given hindsight, I'd argue that this was a mistake and I wouldn't do it again; the convenience of distributing the reference clock over them is nowhere near worth the cost and hassle. So, I'd rather use the CDR/DRTIO clock or clocker and some SMAs.

I'd be interested to hear from other users: does anyone think that, given the above, the LLRFBP is actually worth it? Does anyone really plan to use it?

[hartytp]

The way I'd ideally like to see clock distribution done in Sayma RTM (which is, I believe, essentially the minimal complexity solution) is:

1. reference sources: SMA on front panel of Sayma RTM, DRTIO clock from Si5324
2. Reference sources feed a single ADCLK948 mux (no LTC chip). Outputs of this:
   • 1 to HMC830
   • 1 to a test connector (I'd prefer MMCX to UFL)
   • 1 to input of LO mux (see below)
3. HMC830 feeds HMC7043, which feeds DAC, FPGA and another test connector (again, an MMCX please). If we still have doubts about the reliability of the HMC830 then we should put a solder jumper between the HMC830 and the HMC7043, which allows the LO (see below) to be used as an external DAC clock input (I only expect this to be needed for debugging, so not worth an extra mux for this, but let's make the jumpers 0402 or larger).
4. LO inputs: SMA on Sayma RTM front panel and the reference clock (this is useful for AFE mezzanines including a synth to generate the LO).
5. LO inputs feed a second mux (there are only 2 on Sayma RTM instead of the current multitude). Outputs of this mux:
   • AFE mezzanines
   • Test connector
   • Maybe a solder jumper to the HMC7043 input for debugging?

Add putdowns on the mux select lines so that sensible defaults are selected without needed to be explicit programmed. I'd suggest that the reference source defaults to the CDR input and the LO defaults to the 100MHz reference as well.

[dhslichter]

@hartytp thanks for the thoughts. My two cents:

I agree that the RF backplane is certainly a major additional headache/complexity item without providing meaningful performance benefits. One of the initial motivations was to try to avoid having a ratsnest of external reference cables coming in to the RTM cards, and to aid in high-performance synchronization between neighboring cards, if necessary feeding a shared DAC clock down the backplane to keep all DACs on separate cards locked to each other (i.e. not relying on multiple PLLs for this task). However, I at this point it does feel like this is letting the perfect be the enemy of the good. We need Sayma to be lab-ready soon, and this will mean making some compromises.

Specific thoughts:

• Let's do this with DNP instead of ripping things out, to the extent possible -- it would be nice to be able to avoid having to do major rerouting if we want to go back to a backplane for some future application. That said, if it's too crazy to do it this way, I think we are pretty safe in ripping out some RF-backplane-related items.

• I would keep the LTC6957 for the SMA input. It's cheap, simple, already on the BOM elsewhere, and does a nice clean level conversion for us so that the ADCLK948 inputs are happy -- it gives us a lot more leeway in the amplitude of the external clock, for example.

• I am not convinced that the current number of ADCLK948 chips is really a problem; unless @gkasprow thinks there is a win from removing them, I am inclined to leave them in because they allow us to mess with clock selection without soldering in the clock path itself. If you desperately want to get rid of one, I would vote for IC46, it does the least.

• I agree with the pullups/pulldowns for mux select (I think the sensible thing is to have the default be to run off the external SMA reference - in other words, CLK1 for IC45, IC46, IC54, CLK1 for IC52). I would include pads for both pullup and pulldown for each ADCLK948 so that people can reconfigure their defaults easily if needed. 0603 if at all possible, otherwise I can live with 0402.

• Is there enough physical space to put an additional front panel SMA for an LO? I am not sure that there is, even if we are changing up the AFE connectors as previously discussed for Sayma 2.0, @gkasprow correct me if I am wrong.

• I think we should run a front panel SMA LO into IC52, then we can use one of the unused outputs for an MMCX monitor (via balun?), with another of the unused outputs connected to CLK0 of IC54. This is a cleaner way to bypass the HMC830 if needed, I think -- no soldering/messing around in the signal path, just pullup/pulldown resistors. Take one of the spare outputs of IC54 for another MMCX monitor.

[hartytp]

@dhslichter first, a general point here, based on my experience working both with Sayma and the EEMs, both at the design stage and physically working with the hardware.

The attitude for Sayma has been to put as many features on as possible to try and make it all things to all users. The LLRFBP is a good example of this, where it's at best a minor convenience feature (removes the need for an external clocker + a few SMAs) that leads to a significant level of extra cost and complexity.

In contrast, the attitude with the EEMs has been to keep things simple, low cost and modular by ensuring that each design has a well-specified use case, which we can optimize around. Rather than cramming tonnes of features to try to allow a single single board to do everything, we provide an ecosystem of boards that, in combination, can do everything we want together.

It's not a coincidence that even though the EEMs/Kasli were started after Sayma's initial design was completed, they are now all nearly up and running. It's also not a surprise that the current cost of Sayma is so crazy high -- this is the biggest thing which turns of potential users of it that I've spoken to.

The attitude you're adopting -- which I've definitely been guilty of myself -- is to say "I acknowledge that this feature isn't very useful, and I certainly don't expect to need it or know of anyone who does. But, it doesn't bloat the cost/complexity/power budget too much and I can imagine potential (albeit unlikely) users in the future who might want it at some point in the future." However, the result of the result of that kind of thinking is a board crammed to bursting with kruft, the sum of which does cause a major complexity explosion.

It's easy for us to sit down with PDFs and say "the complexity here isn't too bad", but as someone who's actually been working on the hardware a lot recently, I thoroughly regret doing that. The clock tree has inputs from nearly every part of the PCB (clock mezzanine in the centre, RF BP connectors on one corner, CDR/Si5324 on another corner, SMA on another corner, various test connectors). It's just a mess, and the routing to go between them is crazy. Trying to track down issues amongst that mess has taken me an age, when it would have been trivial if we'd stuck to just having the features we need.

[hartytp]

Let's just focus on giving Sayma a simple, well-defined job of being an RF generating board and focus on doing that really well and cheaply.

Having all these options in the clocking made sense for the prototypes as it allowed us to test out ideas. Now that we have the prototypes, we should test these ideas out thoroughly and decide on a very reduced set of them to keep for the final version.

Another example of this is the JSED ADC. Having an ADC on Sayma does contribute to Sayma's core functionality of RF generation by providing the option of closed-loop power leveling (which is a major feature for many users). But, for that one wants the cheapest, simplest ADC that can saturate the JSED bandwidth, which is best done with an LVDS ADC on the AFE mezzanine. An ADC as fast as the JESD one contributes nothing to Sayma's core functionality apart from cost, power consumption and complexity. It also takes up significant board real estate and valuable lines on the AMC<->RTM connector. The only use anyone has suggested for it is off-line (open loop) digitization. But, that can equally well be done by an FMC or a separate RTM. It would be much better to focus on getting Sayma so cheap and simple that users are happy to use a separate special-purpose digitizer than cramming one onto Sayma where it doesn't belong (and, in the process, causing a major headache for those of us who don't want it and consider it an anti-feature!).

[hartytp]

More specific points:

Firstly, check out Weida's simulations here. Note that the Si5324/DRTIO clock is expected to be very close to the noise floor of the DAC -- it's within 6dB at most frequencies, with a servo bump that takes it to within 15dB at the worst case. This is the nice thing about the 2 loop PLL we have using the Si5324 and HMC830. Again, note that these DACs aren't ultra-low noise themselves, so there isn't much point trying to feed them with a crazy-low noise source.

For the vast majority of users, that noise level is absolutely fine. As a result, the major use-case for Sinara should be using the DRTIO clock to generate the DAC clock. In other words, the LLRFBP is generally not needed because we can use the AMC BP to distribute the clock via CDR and then apply a very narrow-bandwidth cleanup loop. As a result, the LLRFBP is a non-issue unless you really want those last few dB of phase noise and are prepared to splash out some serious cash for them. That's a pretty niche use-case and not one we need to bend over backwards to make convenient.

Having said that, of course before we make a final decision on this we need to characterize the Si5324/DRTIO clock phase noise carefully and check its performance. If that doesn't match our simulations we can reconsider this.

[hartytp]

One of the initial motivations was to try to avoid having a ratsnest of external reference cables coming in to the RTM cards

Yes, that was the initial motivation, and it made sense at the time (I certainly argued for it). But, we know a lot more now than we did then, and I really don't think it made sense.

• As explained above, the Si5324/HMC830 should be fine for the vast majority of users
• If we had a high-density connector on Sayma, so that there were only 2 cables coming out of each Sayma, that might make sense. But, generally there will be 16 cables (8 RF out and 8 ADC in). There's your rats' nest. Adding a single extra cable per Sayma doesn't make this much worse.
• Knowing what we know now, do you seriously expect anyone to choose to buy a silly-expensive rack with a LLRFBP + Baikal etc just to save on having a clocker near the rack and 1 extra coax cable per Sayma? Who would do that?
• We still haven't debugged the LLRFBP connections and checked the performance. And, we can't do that without Baikal. Getting all that up and running is a lot of effort that I don't see any time soon. So, the LLRFBP is going to be a completely untested, unused feature. Why clutter up the design supporting it?

and to aid in high-performance synchronization between neighboring cards, if necessary feeding a shared DAC clock down the backplane to keep all DACs on separate cards locked to each other

This was a contingency plan, in case m-labs clock synchronization techniques don't work out. However, they are working on that right now and we will have results before Sayma v2.0 is finalized. Assuming that all works out, synchronization isn't an argument for keeping the LLRFBP.

[hartytp]

Let's do this with DNP instead of ripping things out, to the extent possible -- it would be nice to be able to avoid having to do major rerouting if we want to go back to a backplane for some future application. That said, if it's too crazy to do it this way, I think we are pretty safe in ripping out some RF-backplane-related items.

The major part of the win here isn't the cost of the RFBP connectors, it's all the other stuff we rip out (lots of muxes etc.). Once we acknowledge that these connectors aren't going to be used it's better just to bite the bullet and properly simplify the clock network.

Note that another motivation to rip out the clock network is phase stability; the more muxes the ref clk goes through the worse its temperature coefficient. For lowest noise and best stability, one always wants to keep things as simple as possible and to take pains to avoid unnecessary components in critical clock paths.

[hartytp]

I would keep the LTC6957 for the SMA input. It's cheap, simple, already on the BOM elsewhere, and does a nice clean level conversion for us so that the ADCLK948 inputs are happy -- it gives us a lot more leeway in the amplitude of the external clock, for example.

Daniel, please don't do this! We had a discussion about this in December in #119 and agreed to remove them. We can't make progress on this design if people keep reopening these discussions.

Is your comment here based on any actual data? I've used both the LTC6957-1 and ADCLK948 extensively and made very careful phase noise measurements. They both work really well over a wide range of input amplitudes and both far outperform the DAC in terms of phase noise.

AFAICT from the measurements I've taken, the only real context where the LTC6957 buys one something is very low amplitude, low frequency clocks, and then only when one uses the filter pins (which Sayma does not by default). But, again, that's a pretty niche use case: anyone who doesn't mind loosing a few dB of phase noise can use either chip safely with a wide range of input amplitudes. And, for those users who really want those last dB of phase noise, it's not unreasonable to expect them to supply a sensible clock signal (e.g. use clocker and provide a nice square wave, providing excellent noise immunity).

Again, you're adding components to the design that just don't provide any notifiable value to the vast majority of users. That one user doing something odd, who really wants this feature can just use an eval board.

[hartytp]

I am not convinced that the current number of ADCLK948 chips is really a problem; unless @gkasprow thinks there is a win from removing them, I am inclined to leave them in because they allow us to mess with clock selection without soldering in the clock path itself. If you desperately want to get rid of one, I would vote for IC46, it does the least.

It's caused me problems. There are so many of them and so many LDOs, with clocks criss-crossing the board from all directions. It makes debugging a real PITA.

Far better to have a nice simple clock network, which we can make compact. e.g. make this compact enough that all clock components can fit under a single screening can if needed (atm they're so scattered that there's no hope to screen them all).

[hartytp]

I think we should run a front panel SMA LO into IC52, then we can use one of the unused outputs for an MMCX monitor (via balun?), with another of the unused outputs connected to CLK0 of IC54. This is a cleaner way to bypass the HMC830 if needed, I think -- no soldering/messing around in the signal path, just pullup/pulldown resistors. Take one of the spare outputs of IC54 for another MMCX monitor.

No, let's not do that! We've already agreed to scrap the clock mezzanine, so IC54 should be scrapped as well -- just route the HMC830 directly to the HMC7043 (but do add a test point on the HMC7043's output).

Having a mux here shouldn't be necessary for the next revision. That kind of thing is fine for prototype hardware, but shouldn't be included in production hardware. We should just test Sayma v1.0 enough that we're happy that the HMC830 works reliably.

Instead of a mux to do that job, it's probably worth adding a solder jumper to allow the HMC830 to be bypassed as a last resort. But, that doesn't warrant a mux.

[hartytp]

Is there enough physical space to put an additional front panel SMA for an LO? I am not sure that there is, even if we are changing up the AFE connectors as previously discussed for Sayma 2.0, @gkasprow correct me if I am wrong.

That's a good question, and not something I've checked carefully yet. I think this is okay, since we can use right-angle SMAs for the 100MHz reference clock. If this doesn't work out then we'll need to think of something else to do.

[hartytp]

Anyway, that's all a bit of an essay, so sorry about that!

tl;dr I've done a lot of playing around with this hardware and found that all the small niceties we added to solve marginal use cases actually make this board a complete PITA to use and debug, so I want to get rid of them for the next round. Actually, a lot of this was pointed out by @jordens a while back, in hindsight he was right!

[jbqubit]

retrospective

@hartytp said

It's not a coincidence that even though the EEMs/Kasli were started after Sayma's initial design was completed, they are now all nearly up and running.

In 2016 when the Sayma/Metlino design was locked-in we didn't have the distributed functionality enabled by Kasli+EEM nor was there a community-wide appreciation for minimalist design. Sayma v1 included complexity beyond its core goal of agile RF output. In contemporary Sinara a lot of the complexity is off loaded to Kasli+EEM. For example, feedback on RF tones is implemented by nu-servo (Kasli+Novo+Urukul). We've collectively learned a lot from wrangling over the specification, design, testing and redesign of now 15-odd post-Sayma components. With that history I'm confident the production version of Sayma will be much smoother sailing.

Anyway, on with the present Issue.

HMC830 bypass

@dslichter said

I think we should run a front panel SMA LO into IC52, then we can use one of the unused outputs for an MMCX monitor (via balun?), with another of the unused outputs connected to CLK0 of IC54. This is a cleaner way to bypass the HMC830 if needed,

@hartytp replied

Having a mux here shouldn't be necessary for the next revision. That kind of thing is fine for prototype hardware, but shouldn't be included in production hardware. We should just test Sayma v1 enough that we're happy that the HMC830 works reliably.

Sayma v2 is meant to be a production run of Sayma which fixes v1 bugs and is low risk. We ought not progress to v2 if problems persist with HMC830. We should avoiding adding components to the v2 BOM that second guess this path.

phase noise

What's the message from the right side of Weida's phase noise plot? It looks like the Ref dominates the Total phase noise; why not use better Ref? What is Ref anyway? And what is Chip?

@hartytp said

As a result, the LLRFBP is a non-issue unless you really want those last few dB of phase noise and are prepared to splash out some serious cash for them. 

From left side of Weida's phase noise plot the HMC830 on-chip VCO 2.4GHz is lower phase noise than the AD9154 performance by a margin > 4 dB from 10 Hz to 100 kHz. That suggests no win for using LLRFBP over HMC830, right? I'm trying to understand your comment about "last few dB" phase noise.

ditching LLRFB (and Baikal)

@hartytp said

There is currently only 1 LLRFB available, and only for one rack, with no more likely to exist in the near future. This makes it quite inflexible (can't be used with half-sized racks)

In 2016 there was an expectation that use of the RF backplane included in the uTCA.4.1 would be a net positive for Sayma. As @hartytp points out it's availability as of 2/2018 remains poor, its cost is high and it saves us one SMA per Sayma. Baikal is the intended clock distribution board for LLRFBP. Its layout is complete (thanks @sbouhabib!) but its not yet been tested. Relative to the complexity of LLRFBP+Baikal, use of Clocker EEM or an RF power splitter is a much simpler approach for clock fanout. So far WUT, Oxford and UMD have LLRFBP hardware.

I support scrapping LLRFB support and removing dependencies on the RTM (not just DNPing).

fewer clock source options

@hartytp said

The clock tree has inputs from nearly every part of the PCB (clock mezzanine in the centre, RF BP connectors on one corner, CDR/Si5324 on another corner, SMA on another corner, various test connectors). It's just a mess, and the routing to go between them is crazy.

@hartytp said

Far better to have a nice simple clock network, which we can make compact. e.g. make this compact enough that all clock components can fit under a single screening can if needed (atm they're so scattered that there's no hope to screen them all).

The many clock distribution options for Sayma v1 also made @sbourdeauducq and @jordens unhappy.

@hartytp proposed

support two options for supplying the reference clock:

• Front panel SMA on Sayma RTM
• DRTIO clock from the Si5324

Clock distribution is among the most critical elements of phase synchronization of Sayma. AFACT @hartytp's argument is sound that reduced complexity will improve temperature dependence, phase noise, permit increased shielding (single RF shield) and ease debugging. If @gkasprow agrees that rerouting (and simulation) of clocks is low risk I'd support this simplification.

default clock source

@dhslichter suggested

I would include pads for both pullup and pulldown for each ADCLK948 so that people can reconfigure their defaults easily if needed.

Agreed. Since DRTIO-derived clock is an advanced use case I support the physicist-friendly default dependence on an external SMA clock.

DRTIO-derived clock

Need to show phase synchronization of clock recovery from DRTIO

• board to board upon power cycling of crate

[sbourdeauducq]

I support scrapping LLRFB support and removing dependencies on the RTM (not just DNPing).

Interesting. The clock backplane was one of your arguments for having RTMs at all. So we are moving towards the single-board, DAC-only solution that Robert and I were advocating at the very beginning of the project, that you fought using various techniques, and that would have been much simpler to develop?

[sbourdeauducq]

It's not a coincidence that even though the EEMs/Kasli were started after Sayma's initial design was completed, they are now all nearly up and running.

http://hintjens.com/blog:19

[sbourdeauducq]

Here's an idea: a EEM with a medium-size Kintex-7 FPGA (likely needs a fan, maybe a dedicated one mounted on the heatsink like the KC705), one AD9154, maybe one HMC830, no SDRAM or other features, maybe talking to a DRTIO master (TBD) over SATA cables in the same crate, which incidentally are faster (6Gbps) than the AMC backplane... or plain old IDC and Kasli, but with reduced bandwidth.

[hartytp]

Here's an idea: a EEM with a medium-size Kintex-7 FPGA (likely needs a fan, maybe a dedicated one mounted on the heatsink like the KC705), one AD9154, maybe one HMC830, no SDRAM or other features, maybe talking to a DRTIO master (TBD) over SATA cables in the same crate, which incidentally are faster (6Gbps) than the AMC backplane... or plain old IDC and Kasli, but with reduced bandwidth.

@sbourdeauducq I still think that uTCA is the way to go for high-speed designs like Sayma and Shuttler.

• Even a 4-channel version of Sayma that's been quite heavily stripped back isn't going to fit on a Eurocard. You need the large FPGA + heatsink, RAM for DMA, DAC + AFE (even if we don't make the AFE pluggable we'd want something like Urukul at min), Si5324 + HMC830, SMPSs + LDOs, LVDS ADCs + AFE (these are important and need to be hooked up to the same FPGA, although maybe one could just add a couple of IDCs to plug Sampler into this Eurocard I guess).
• Thermal management in Euroracks isn't really good enough for a design that burns off this much power
• You couldn't get enough power over the IDC to power a sensible number of channels for this kind of board (same with sampler). Power consumption is a major issue with EEMs. For example, we couldn't have used AD9914s for Urukul without running out of power pretty fast. Having an AMC rack with a nice PSU is a big plus for this kind of thing IMHO.
• Once we scrap the LLRFBP so we can use much cheaper racks and get the cost of Sayma AMC + RTM down by a factor of two or more, I don't see any disadvantage of uTCA.

In general, I don't really have any objection to using AMCs + RTMs for Sayma, so long as we get the complexity and cost down to a minimum. Note also that my suggestion actually involves only a relatively minor amount of work (remove some muxes and reroute a couple of clock lines), while you're suggesting that we scrap a more or less working product and start again. It should be pretty clear that there isn't any appetite for that.

[hartytp]

Interesting. The clock backplane was one of your arguments for having RTMs at all. So we are moving towards the single-board, DAC-only solution that Robert and I were advocating at the very beginning of the project, that you fought using various techniques, and that would have been much simpler to develop?

The RTM is still fine IMHO. Even with only 4 channels per Sayma it's not clear that we could have got that all on an AMC alone. The RTM is also a nicer thermal environment.

@sbourdeauducq Edit: done right, uTCA is a really nice form factor. The Enterpoint DDS boards we used to use cost about the same as Urukul for 4 channels on an AMC (and also had a VGA hooked to the FPGA for pulse shaping). LLRFBP aside, the racks are pretty standard and don't cost that much (compared to e.g. a Eurorack with the level of cooling and power supply that you'd need for this). The RTMs aren't a major issue either for us, and creating a reusable AMC with can act as the digital side of future designs is nice IMHO.

[hartytp]

@jbqubit breaking your comments out into the relevant issues...

What's the message from the right side of Weida's phase noise plot? It looks like the Ref dominates the Total phase noise; why not use better Ref? What is Ref anyway? And what is Chip?

Ignore the plots on the right, that's just Weida optimising the loop and the labels are confusing. The plot on the left shows that this is limited by the Si5324.

From left side of Weida's phase noise plot the HMC830 on-chip VCO 2.4GHz is lower phase noise than the AD9154 performance by a margin > 4 dB from 10 Hz to 100 kHz. That suggests no win for using LLRFBP over HMC830, right? I'm trying to understand your comment about "last few dB" phase noise.

Yes, the HMC830 outperforms the DAC at almost all offset frequencies, which is why I don't see the need to have an external DAC clock input (cf #407). That comment about noise refers to using the Si5324 to generate the 100MHz reference for the HMC830. The Si5324 is note quite as good as the DAC, but it's close enough for almost all use cases.

[hartytp]

Clock distribution is among the most critical elements of phase synchronization of Sayma. AFACT @hartytp's argument is sound that reduced complexity will improve temperature dependence, phase noise, permit increased shielding (single RF shield) and ease debugging. If @gkasprow agrees that rerouting (and simulation) of clocks is low risk I'd support this simplification.

This is more broadly discussed in #405.

[hartytp]

Oh, and, @sbourdeauducq to be absolutely clear: I'm still 100% in favour of Sayma in more or less its current form; I think Sayma is a really excellent product, which is going to be an amazing asset in our lab. All the hard parts of Sayma worked essentially perfectly on the first attempt, which is extremely impressive of @gkasprow and his colleagues.

If you look at the changes I've suggested, they're all actually pretty minor, and just boil down to removing features which we now know won't be that useful, or to fixing mechanical issues. I'm not in any way advocating a major rework of this (e.g. not suggesting touching the DAC JESD links, which were one of the hardest things to route IIRC). Just simplify a bit and fix the bugs and it'll be great!

[sbourdeauducq]

I'm not sure if it's as difficult as you think to have a single DAC chip + FPGA in a Eurocard - remember, it worked on the KC705 with the ADI FMC, and it didn't heat that much. Power distribution can perhaps be solved. The JESD links are more easily routed if they only have to go to a DAC right next to the FPGA. But yes, it's just an idea that I'm putting out there, I agree that throwing away most of the current design is problematic, and that µTCA solves the power and cooling problems, and helps with higher channel densities and distributed DMA.

[hartytp]

@sbourdeauducq agreed with all that. But, note that unlike the FMC, we'd really want the AFE on the same PCB. That AFE consumes quite a bit of space...

[dhslichter]

OK, OK @hartytp! :) I apologize for having missed out on #119, didn't remember that this had been beaten to death. Your arguments are convincing for the other items as well. I guess I had been thinking more about the simplicity of board redesign more than the simplicity of final product. I agree that the Si5324 plus HMC830 should be sufficient for just about everyone based on the noise floor of the DACs. Do we feel comfortable that the HMC830 actually works as desired now?

@sbourdeauducq I understand why you are thinking about Eurocards but I think we should stick with uTCA, and AMC + RTM. Several reasons:

• the rack mounting/physical form factor is well-engineered already, no need to make our own fiddles for cooling, power distribution, DRTIO distribution, etc. It can just be bought as is.
• the RTM gives us a lot more room to spread out for the DACs and AFE cards -- if we try to put it all on an AMC it will be way too cramped. It also spreads the power dissipation out physically, so that things can be cooled better.
• We already have the boards engineered for uTCA -- no need for additional work on physical form factor.
• The JESD links are easier to route on a single board perhaps, but they have already been routed and tested and they work, so this isn't really relevant here.

[hartytp]

Do we feel comfortable that the HMC830 actually works as desired now?

Not yet, but we need to get to that point before finalizing decisions for Sayma v2.0

[gkasprow]

@hartytp so what is the conclusion? Do we definitely get rid of RF backplane support? Since I will move to RFSOCs + WR-like sync in my applications, I don't care at all about Sayma ADCs or RF backplane. I'd favor for simplicity. I got funding for RFSOC version of Sayma so we have straight upgrade path up to 10GHz DAC.

[dhslichter]

I think we should go ahead and get rid of the rf backplane. AFAICT we will use WR with cleanup oscillator to generate synchronous distributed clocks with good phase noise, and the rf backplane has always been an expensive and complex feature to have to deal with.

[hartytp]

@gkasprow let's just get rid of the LLRFBP. The only DAC clock options should be: RTM SMA; WR. The LLRFBP is a nice idea but has too many problems with it and is not worth it in our case.

[jbqubit]

Agreed. No RF backplane. #601 "Reduce complexity of Sayma v2"

[hartytp]

@jbqubit Let's keep this open until the change has been made to the design files.

[gkasprow]

done