L9

[hartytp]

@gkasprow is L9 populated by default. IIRC, it's not, but that's not marked on the schematic.

[gkasprow]

in older version where T1 was not added, L9 was removed to disable oscillator. Now it should be mounted by default.

[hartytp]

Hmm..What am I missing? If the mmcx is used the XO is enabled isn't it? doesn't the XO still couple to the output via the removed capacitor. I thought that when the mmcx is used the XO must be powered down by removing the inductor.

[dnadlinger]

Yep, L9 shouldn't be populated if the MMCX coupling caps are. T1 only helps for switching to the external SMA in.

[hartytp]

@gkasprow we definitely want the default population option to be mmcx not XO so no L9. I much prefer the mmcx to the sma for connecting to Kasli clocks

[gkasprow]

OK, right.

[hartytp]

@gkasprow Thinking about this a bit more, I think it would be much nicer if the XO were disabled by removing a 0R resistor on the power line instead of an inductor. My thinking is that the inductor is something that most people won't have lying around, so repopulating it requires ordering components. A 0R resistor can just be a solder blob.

Better yet, we could just add a jumper since it's only DC.

[hartytp]

Having said that, the more I think about it, the more I want to avoid users having to get out a soldering iron. Too much chance of a student damaging the board during rework. Too much chance of people forgetting to document the changes before they put the EEM back in a cupboard for someone to find later once the rework has been forgotten about.

So, my feeling is that if this XO is likely to be used often, we should have a way of using it that doesn't require populating capacitors (if it's not likely to be used often, we should consider DNPing it to save money).

Ideally, I'd like to stick an extra 2-input MUX here to allow the XO to be used, but I know that @jordens was keen to keep this board as cheap as possible.

So, what about doing this the cheap way? Since we are only driving the MMCX input to the buffer/divider single-ended at the moment, we can connect the XO to one half of the input and the MMCX to the other half. We then add an extra CPLD control line that allows the unused input to be shorted to ground via a capacitor + FET.

In other words, we have two CDPL control lines. The first one switches the mux between SMA and XO/MMCX. The second one shunts the unused half of the MMCX/XO mux input to ground through a capacitor. Additionally, we ensure that the XO is only powered if both control lines are set to use the XO.

That seems like very minimal extra complexity: one more CPLD output or one of the unused DIP switches if there are no more CPLD outputs, and a couple of FETs. And, it means that all options are supported without board modifications.

Thoughts?

[gkasprow]

I'm not sure if such MOSFET switch will provide good isolation. Small signal MOSFET have >10Ohm resistance. Power MOSFETs has huge capacitance at 100MHz and non-negligible inductance.

What about simple mechanical jumper? It will work at 100MHz without issues.

We already measured that isolation of digital mux is not enough so that's why MSOFET in series with L9 was added.

We can also do the switch in old-fashioned way using PIN diodes. We can get 60dB isolation at 100MHz with such circuit. Cost of PIN diode is a few cents.

Relay is also an option but RF-grade relays are not cheap.

[hartytp]

I'm not worried about isolation, as we will also cut XO power when MMCX is active and warn users not to apply signal to MMCX when XO is powered. The idea of the FETs is that we need to make sure that the un-driven half of the mux input is connected to AC ground via a low impedance.

I think it's nice to have both the XO and MMCX as "first class" options, meaning they can be accessed with no population changes required. MMCX is our clock input of choice for connecting Urukul to the clock outputs of Kasli, since it keeps the wiring inside the rack. We haven't used the XO yet, but I can imagine it being really useful e.g. for Humpback where there isn't a Kasli to supply a clock.

I don't want to put these clocks through a THT jumper (as we discussed a while back) if we can avoid it. Don't forget they can have harmonic content up to several GHz, which needs to be preserved for a clean rising edge.

My preference would definitely be to add a cheap, low-power LVDS mux before the divider to allow users to switch between the MMCX and XO (the input select line should also control the XO power supply to improve isolation). @jordens would you object to us doing this?

[hartytp]

previous post edited for clarity...

[gkasprow]

What about this mux? It is low cost (1.5$) and has very low jitter (60fs).

[hartytp]

Looks fine by me. It doesn't go up to 1GHz, but I'd argue that's not a problem for the MMCX input. So, put the MMCX and XO into that and then the output into the divider, with the SMA going into the other divider input. Route both clk select lines to the CPLD, and also ensure that the XO is only powered when it's selected.

That all works for me. @jordens any objections?

[gkasprow]

XO power needs to be controlled separately - I'd like to keep it off when SMA is enabled. Otherwise we would have to remember to switch the first mux to MMCX input when other is set to SMA mode.

[hartytp]

Yes, I would and the two cs lines to enable to XO.

[gkasprow]

Please have a look:

[hartytp]

@gkasprow thanks for doing that.

What about Si53340-B-GM instead? That is a bit cheaper and goes up to >1GHz, so it can be used to supply the max DDS clock frequency via the MMCX. Partly, my motivation here is that if we use a slower buffer for the MMCX input then we will need to document it. If all buffers go to 1GHz then there is less to document.

Edit: am I right in thinking that floating LVDS outputs don't consume any current? I ask because the 53340 has 4 outputs, but we only need 1. It would be a shame to waste the extra supply current!

[hartytp]

Other comments:

• Is R22 marked as DNP? Shouldn't it be, as the balun is not populated?
• Should we also add a DNP 100R resistor for the MMCX input?
• For the CPLD, the configuration SR currently uses 21 bits. So, we assuming we keep it to 3 bytes, we still have 3 bits spare. So, we do have enough bits to make the clk in control line 2 bits wide. Don't need a separate control register bit for OSC EN, can determine its state in the CPLD from the two CLK select lines. https://github.com/quartiq/urukul/blob/2d1c145aabc1fc1cbdc6e492c26f827f503926eb/urukul.py#L65-L88

Otherwise, all looks good to me. @jordens any objections to going ahead with this?

[gkasprow]

OK, I have it in my libs.

[gkasprow]

the schematic above was without assembly variants enabled. Below is correct one.

[gkasprow]

R52 is mounted instead of R22 and gives 50Ohm impedance instead of 100Ohm which is needed for symmetrical output from balun.

[gkasprow]

Here is version with improved readability

[hartytp]

@gkasprow that all looks good to me. Just need to hear from @jordens now.

[hartytp]

@gkasprow actually, one more thing: am I right in thinking that the XO maximum output current is +-24mA, which means that it needs a min load of 137.5 Ohms. Yet, we're loading it with 100Ohms.

Also, presumably we could use a passive network to convert HVCMOS to LVDS and get a differential signal out. I assume that the reason you haven't done this is simplicity (the XO puts out a square-wave AFAICT with a nice sharp rising edge, so signal level shouldn't be an issue). Is that correct? (I'm not asking for a change, just curious)...

[gkasprow]

Yes, but passive network means balun. I don't think we need it, XO amplitude is high enough. We can also add low cost differential CMC to convert it to diff signal. There is 9cm distance between XO and SIlabs chip.

[gkasprow]

I mean this CMC

[jordens]

Removing population options in favor of configurability is great as long as the side effects are OK. A couple questions.

• What's the plan for implementing the code changes?
• What's the impact on power consumption? If the Si has significantly more consumption, I'd consider going back to the cheaper lvds buffer.
• What's the impact on cost? Some are going to say that it's just one BOM line but that doesn't really compute when looking at past changes.

[hartytp]

What's the plan for implementing the code changes?

I'm happy to implement, test and document CPLD + core device changes.

What's the impact on power consumption? If the Si has significantly more consumption, I'd consider going back to the cheaper lvds buffer.

Si53307 would be 85mA typical (65mA core + 20mA for a single LVDS output).

Si53340 is specified as being 140mA "core current". However, I believe that's a bit misleading, since it doesn't have a separate "VDDO" pin, so I think this actually includes the output current draw as well at 20mA/output. In which case, the actual current draw with a single output would be 80mA, so the same.

[hartytp]

Note also that the supply current is the same for the 53340/53341 (which is 200MHz LVDS) so doesn't seem to depend on the speed.

[gkasprow]

We have to finish this revision today and start production. I finished layout with Si53340.

[hartytp]

the cheaper lvds buffer

which cheaper buffer do you mean? The slower one was actually a bit more expensive. Maybe because it has a flexible "any output" interface. The Si53340 is a cheaper LVDS-only buffer.

[hartytp]

Yes, but passive network means balun. I don't think we need it, XO amplitude is high enough. We can also add low cost differential CMC to convert it to diff signal. There is 9cm distance between XO and SIlabs chip.

ACK. Not worth it. As I said, I was just curious.

But, we really should increase the value of the load resistance to make sure we keep the load current within the specified limits.

[hartytp]

Sounds good to me. Thanks!

[jordens]

OK. Sounds good to me. It looks like this can be implemented transparently w.r.t. the v1.0, v1.1, v1.2 versions in ARTIQ 4.0. I'm also ok with putting OSC_EN on a dedicated CPLD pin. Maybe the same power switching for the MMCX/XO mux.

[gkasprow]

Power consumption will change from 9.95 to 10.26W for AD9912

[gkasprow]

I increased the load resistance to 100Ohm

[hartytp]

You mean 100R + 50R=150R total?

[gkasprow]

yes

[jordens]

To answer my question: the impact on cost is 40-50€. That's much more than I expected and suggests that reducing complexity and the BOM (drop amplifiers+chokes+bias+LDO, pad, filters, MMCX, MUX, clips, DIP switch) might really make Urukul quite a bit cheaper.

[hartytp]

To answer my question: the impact on cost is 40-50€.

Wow! Where did you get that number from? That's much higher than I'd expected. @gkasprow can that really be right?

[hartytp]

@jordens even if that's true, my guess is that this cost will still be dwarfed by costs associated with production size. So, even if some of these components make the board more expensive, if they allow more users to use the exact same board they may still lead to lower overall costs.

[jordens]

Technosystem. I asked because I suspected that Urukul would become more expensive.

[jordens]

@hartytp where do you get you numbers on production cost scaling from? From what I have seen it's steps of ~5%/10pcs. If somebody buys 40 RF channels, that's roughly the cost of these changes eating up the savings due to scaling.

[hartytp]

Technosystem. I asked because I suspected that Urukul would become more expensive.

@gkasprow any idea why this cost is so high?

@ where do you get you numbers on production cost scaling from? From what I have seen it's steps of ~5%/10pcs.

From previous conversations with TechnoSystems the scaling factors for going from 1-2 boards to 10-20 have been significantly more than 5%. Notice that there are two different kinds of discount: (1) they are building a large batch already and one is negotiating what fraction of that to buy (but, still a fraction that's small compared with the overall batch size) (2) one is buying the entire batch. Obviously the price scaling is way more for the second case than the first.

Anyway, obviously you should order whatever variants you want to. But, FWIW, there are several things on the list you posted above that I do feel add significant value and would want to keep (filter, amplifier, MMCX, mux) for any boards we buy. At this point I also have no appetite for further rounds of design revisions + testing.

[jordens]

That doesn't agree with what I have seen in practice and with what I have been told. I haven't seen more than 5% up to qtys of 16. Yes, I know how these things are priced and manufactured. I'd definitely recommend that those buying a bunch of Urukuls take a good look at the options and the cost. Unused components have exactly zero value. IIRC you mentioned lowering the output power to match the gain from Booster and to get rid of attenuator banks. The AA filter is useless if you are driving AOMs and are not bothered by harmonics or Nyquist images. The mux is useless where there will be no clock reference clock switching. And the MMCX is useless in two of three use cases.

[hartytp]

@jordens Personally, I place a high premium on having all boards the same; much easier to perform debugging/provide support if I know exactly what I'm dealing with without having to check population options; avoids issues over someone changing a population option and then putting a board in the cupboard with the wrong label; lowers the learning curve for new users; means that students don't have to get out a soldering iron (and risk damaging a board) if their use cases change slightly. From my experience, the cost of postdoc time wasted in fussing with populations generally far outweighs the savings from having them.

I'm not saying I'm willing to pay a factor of two for that convenience, but I'm certainly not going to worry about 10% here or there (which, AFAICT, is all we're talking about here).

I also do not want to make any unnecessarily changes to Urukul. It's a design that we have used a lot in our lab and are now very happy with. I don't want to introduce new bugs for the sake of small cost savings.

IIRC you mentioned lowering the output power to match the gain from Booster and to get rid of attenuator banks.

Yes, for the AOM driver use-case the amplifiers are at best useless and at worst dangerous. However, there are a few use cases in our lab where they do come in handy. At which point, keeping everything the same/avoiding unnecessary changes makes me want to keep them.

The mux is useless where there will be no clock reference clock switching.

The mux is there to avoid users having to much about with population options, rather than for dynamic switching.

And the MMCX is useless in two of three use cases.

We use the MMCX connector in about 90% of our Urukuls. It makes wiring within the rack much clearer and interfaces well with the fanouts on Kasli (an external fanout would cost more than those muxes combined).

The AA filter is useless if you are driving AOMs and are not bothered by harmonics or Nyquist images.

Clean RF is useful for a few of our use-cases.

[hartytp]

Anyway, if you want different population options then go for it.

My point is just that I think the current design is pretty close to optimal and I wouldn't want to buy a different version with those features removed.

[gkasprow]

It looks like Technosystem has batch of v1.2 produced and patially assembled (one PCB side). If you order v1.3, they will do it in low quantity so that's why such batch will be more expensive. Nothing to do with board revision.

[hartytp]

@jordens Remind me, why do you dislike the MMCX connectors so much?

• Almost all of our Kaslis connect to at least one EEM that requires a clock. Currently, this is just Urukul, but should soon extend to Mirny and Stamper
• The MMCXs seem to be the cheapest and cleanest way of doing this clock distribution. There are plenty of EU suppliers who will make up MMCX cables to custom lengths cheaply, so we just bought a stack of them. They are mechanically quite nice to use and work into the GHz range, so can transmit nice clean clock edges without SI issues.
• I've never found it particularly difficult to route the MMCX connectors inside the rack alongside the ribbon cables. And, I definitely prefer this to external cabling
• The fanout on Kasli seems much cheaper and more convenient than any other solution. If you're not using that then what are you doing to distribute your clocks? Use an external board like clocker and SMAs? That costs more, takes up more space, consumes more power and leads to more external wiring
• The Kasli recovered clock is pretty good (and good enough for all our current EEM applications); the short-term stability/phase noise is excellent, and even the long-term stability of 100ps is fine for many uses.

[sbourdeauducq]

In addition to what Tom said, the internal clocking is nice for first-time users who just received a new crate from us - the DDS just works by default, without taking special care of anything. Then they can move to external clocking if they need a bigger boat.

[jordens]

@hartytp You just expressed your aversion towards discussing design changes, your disinterest in variants, preempted any further discussion by declaring Urukul "pretty close to optimal", and shrugged your shoulders saying that we should do whatever we want. And now you are implying that I "dislike the MMCX connectors so much" as if I had some irrational hate against a specific connector type and you wanted to analyze that bias. What gives? Haven't we discussed the pros and cons of the various clock inputs already? What do you want here?

I have no bias against "the MMCX connectors". They are fine connectors.

Urukul already has a good ppm-stable ultra low noise clock on board. There is zero need to go through the hassle of designing, procuring, buying, installing a cable from Kasli if that XO is good enough. Especially for "first-time users" and especially for the applications where ppm stability is absolutely fine. There is differential stability between Urukul channels is unaffected which further reduces the need for absolute external references. I have a hard time coming up with reasons to use the Kasli fanout if that's not externally stabilized. If the XO is good enough it doesn't matter how easy you think the MMCX cable idea is. It'll always be more complicated.

On top of it being unnecessary, I do find it tedious to install MMCX cables. They are much less flexible than the ribbon cables and the COTS ones IME of are all with a U connector arrangement and not the N arrangement we need. That puts maximal twist strain on the boards/cables/connectors. And custom ones are certainly not cheap (i.e. more expensive than the XO, which is already free on board). Having a bunch of MMCX cables in there makes an already challenging cable routing job significantly more difficult, more so if you ever want to disassemble/rearrange or swap cards. A dozen IDC30 ribbon cables and maybe another 8 short IDC26 jumper cables in a crate is a tradeoff I am happy to make when comparing that with the backplane. But another 4 or more MMCX cables does not help.

The Kasli recovered clock only has that 100ps long-term stability (which is only good for some cases) when operated as a DRTIO satellite. Otherwise (i.e. in all non-DRTIO and in all DRTIO-master setups) it has a non-deterministic phase offset w.r.t. external.

External fanouts tend to be just there in the lab. And usually there is a port available. The cable from the fan-out to Urukul is as cheap as the internal one. And typically you only need one cable at most since the other Urukuls are fine on their internal clock. If you want to always use the MMCX, you need a cable per Urukul.

Using an external reference also opens up the door to bypass the DDS PLLs. And it give you the opportunity to use Urukul to derive frequencies from others, i.e. use it as a microstepper or generally as a highly capable PLL or modular divider.

I guess beyond your mutual thumbs-up you are both aware of the spurs you are adding when you connect Kasli on MMCX (unstabilized because usually and especially for first-time users Kasli frequency lock is not needed) and ever want to connect an external reference to the Urukul SMA.

And finally, using Kasli's clock has another crucial problem (in the way it is currently implemented): it drops out and re-locks each time Kasli reboots. That's not the case for the XO or an external clock which makes them the only answer if you need reliable RF output for long times (locks or trap RF) and want to be able to survive Kasli crashes or new firmware/gateware. Maybe you don't need that, but others do.