Urukul placement/coarse layout issues

[jordens]

With coordinates in mm from the bottom left.

• Clock input circuitry (OSC1, the baluns, SMA, MMCX) is fine. Since the module handle makes the lowest SMA less accessible, this is where I would put the clock input. Let's change Clocker in the next round to have the same layout.
• Clock distribution and SYNC distribution IC9 and IC19 location and overall layout is fine as well. Routing needs tweaking.
• Length matching (!} Urukul synchronization trace langth matching #278
• DC/DC switching and linear regulators look very tight but fine in location and general layout.
• Please route the OSC1 output nicely and away from the dirty stuff: on the bottom layer (not on the digital layers), do it like (or maybe even "with") CK_MMCX_IN_[PN].
• Let's place OSC1 and C103 by default in both variants, and DNP whatever is needed to disconnect CK_MMCX_IN_[PN] . IMHO it is the right choice to make using Urukul easy and it was the original design to default to not relying on the internal clock distribution. Those needing the internal MMCX wiring can just move a capacitor.
• Let's kill the RF amp bypass R33. As @hartytp mentions, the pads might do more bad than good.
• Connector placement is good (SMA, MMCX, IDC, JTAG).
• You can use smaller DIP switches if you want to.
• You are really cutting into and thinning you power polygons with some vias. I'd fatten them to the limit.
• Do I see that correctly that you want to use some of the clips for multiple adjacent shielding boxes?
• Be careful with the mounting hole clearance for the angle pieces at the front, especially near the bottom LEDs. On the digital EEMs, those washers are too close to live signals. They are loose around the screws and end up going beyond the mounting hole.
• The heat sink idea won't work without more mounting holes, especially in middle near 30,50 and 60,50 and 90,50. And it would need the bottom layer to be significantly exposed GND. Right now there is neither. But let's not spend time on the heatsink right now. Leave it like it is.
• LED placement is good.
• But make the double LEDs all one green/one red. And connect the over temperature to the red one and the power_good one to the green one on LD7A/B.
• More testpoints for supply voltages. To check noise, stability etc.
• Add one LED for 3.3V MP.
• Place R57 and R58 to complete that Jumper. but leave R49 to R51 DNP.
• If at all possible put another clip for shielding the clock distribution IC19.
• I am OK with going to 6 layers if that's what it takes. But then make good use of the area and the free copper.
• You can do a much cleaner job by swapping some of the DAC_CLK pairs on the IC19.
• IC9: OE4 should be high. Please place two DDS on bank A and the other two plus FB_SYNC on the other bank.
• Roughly half of your vias is covered with soldermask, the other half is not. What gives?
• Really make the clip grounding and several of the decoupling caps beefier. On some you just have one or two long but only 150µm wide wires to ground.
• The 9dB pad footprint looks weird. Sure there is paste and a soldermask opening on the ground connection?
• Grounding and power supply decoupling/filtering around the DDS looks good.
• Except for a few caps that want beefier via connections to their planes.

Details:

• There are a bunch of non-ideal things that (at the very least) hurt the eye. Jagged lines, stubs everywhere, things going in circles...
• Clean up the routing of ATT_*, especially ATT_S_OUT. Move it to the others.
• While I understand the benefits of a layer for horizontal wires and another for vertical, it doesn't make much sense for the wires at the edges, i.e. RFSW_CTRL[3:0] and ATT_* going over and under again for no reason.
• 115, 62: stray +12 v annotation
• 111, 39: stray stub via
• I don't see how you connected the AD9910 DAC outputs to the balun. Vias missing near R57/R78/R79/R91?
• 11, 18: clock input not connected

[gkasprow]

@jordens this is initial layout without cosmetics. Just general feedback is needed. It will change after PI and SI analysis anyway. So at the moment I dont care about stubs, missing vias and other details. Pls check routing of critical signals, component placement including connectors. Silk screen will be in the next step.

[jordens]

@gkasprow OK. Updated. Looks mostly fine! I checked the critical clocking and analog signal chains, overall component arrangement. I wouldn't bother with silk screen until after SI/PI and copper cosmetics.

[hartytp]

Let's place OSC1 and C103 by default in both variants, and DNP whatever is needed to disconnect CK_MMCX_IN_[PN] . IMHO it is the right choice to make using Urukul easy and it was the original design to default to not relying on the internal clock distribution. Those needing the internal MMCX wiring can just move a capacitor.

My preference would be to populate OSC1 by default, but to not connect it to the clock mux (connect the SMA and MMCX inputs instead). If you really want the XO connected to the mux by default, I'd prefer to leave the SMA NC than the MMCX. However, I'll leave the final call to you if you feel strongly about this.

My motivation for this preference is that I expect that the most common use case (and hence the one to support with default population options) will be clocking Urukul from the RTIO clock produced by Kasli. This ensures that the DAC clock is phase locked to the RTIO clock, allowing deterministic latency, which is a common feature to want.

The most convenient means of doing this is to use the MMCX for internal distribution within the rack (rather than using clocker and a bunch of external SMAs). This certainly what we'd always want to do.

[hartytp]

Do I see that correctly that you want to use some of the clips for multiple adjacent shielding boxes?

I suspect that this is done to reduce cross-talk. But, IMHO, it's probably overkill (what dBc cross-talk are we aiming for anyway?). No harm in leaving it like that for the prototyping round though, so that we can test whether this level of screening is actually needed.

[hartytp]

Be careful with the mounting hole clearance for the angle pieces at the front, especially near the bottom LEDs. On the digital EEMs, those washers are too close to live signals. They are loose around the screws and end up going beyond the mounting hole.

Does this warrant an issue for the DIO EEMs?

[jordens]

@hartytp

• I would like to be able to use OSC1 without having to do any soldering. We can meet in the middle and have the internal MMCX and SMA on a jumper both going into CLK2 and OSC1 always on CLK1.
• Yes. I get the intention. My question was about whether there would be two walls in one clip in some places. The problem is that the outer shape is not recangular. I.e. making one box to fit everything (if the corsstalk is not an issue) will be tricky.
• Yes. There is an issue about that on the DIO EEMs. SMA DIO rev2 Errata #240

[hartytp]

I would like to be able to use OSC1 without having to do any soldering. We can meet in the middle and have the internal MMCX and SMA on a jumper both going into CLK2 and OSC1 always on CLK1.

So long as we can find a jumper that has good S-parameters up to a few GHz, this sounds like a good solution. However, I'm not sure that a standard 100-mil jumper would be a good idea.

[hartytp]

Yes. I get the intention. My question was about whether there would be two walls in one clip in some places. The problem is that the outer shape is not recangular. I.e. making one box to fit everything (if the corsstalk is not an issue) will be tricky.

ACK

[jordens]

I had the same resistor/capacitor solder mux in mind we have in other places as well.

[hartytp]

Can we make the MMCX default population option then?

[hartytp]

Yes. There is an issue about that on the DIO EEMs. #240

Is it? Which point on that issue are you referring to?

[gkasprow]

The oscillator has enable input.
So one can use it to control its activity. The question i if this particular oscillator disables only output and leaks some RF or EN input switches its oscillations off entirely.
We can also use jumper to power it on and off which is safer solution.
In this way isolation of ordinary jumper would not be such issue.

[gkasprow]

We can also use MMCX connector at the oscillator output and use piece of MMCX jumper to connect it with clock input.

[gkasprow]

@jordens there is no place to put double shield clips. Of course sharing the clips by two boxes walls makes the isolation slightly worse. I will connect them with solid piece of copper to GND. Anyway, I treat them as experiment to verify if we really need them. I think we won't mount them.

[hartytp]

We can also use MMCX connector at the oscillator output and use piece of MMCX jumper to connect it with clock input.

That would work well for me! How much would it cost to supply a short MMCX cable for this with Urukul?

The oscillator has enable input.
So one can use it to control its activity. The question i if this particular oscillator disables only output and leaks some RF or EN input switches its oscillations off entirely.
We can also use jumper to power it on and off which is safer solution.
In this way isolation of ordinary jumper would not be such issue.

What's the oscillator's output impedance when disabled/powered down?

[hartytp]

For the CVHD-950-100.000 (which I thought we were using) i didn't see an enable input on the data sheet.

Edit: oops, wrong PN. Ignore this!

[gkasprow]

@hartytp you are right, VC is tuning voltage:)
I will order MMCX-MMCX cables anyway. 15cm ones from Mouser are roughly 10EUR, but we will get them much cheaper, for half that price.

[jordens]

#240 (comment)

[gkasprow]

@jordens you probably mean LED distance to the mounting bracket, not SMA. Or do you mean the most upper SMA?

[jordens]

On urukul the led. And on sma dio the SMD sma.

[jordens]

I don't like the mmcx jumper idea. Let's go with the jumpers. Wenn use the same on allaki and there people want to go to several ghz. And for this revision I would like to use the external sma and have the jumper placed that way.

[hartytp]

@jordens I get the motivation for wanting the SMA connected to the mux by default -- this gives the user the option of bypassing the AD9910 PLL by using a 1GHz clock that's phase locked to the RTIO clock, which is a useful thing to do. However, the more I think about this, the less I understand prioritising the XO over the MMCX.

1. The XO isn't cheaper/simpler than the MMCX: Urukul will almost always be used from Kasli. Kasli always (master/slave) provides multiple 125MHz clock outputs from the fanout, with no special configuration required. Urukul plans to ship with a MMCX cable for clocking (cf Urukul MMCX cables #267), and requires a ribbon cable connection to Kasli, so it's not really any worse (in terms of effort/cost/complexity/risk) to run a MMCX cable in parallel to the ribbon cable.
2. The MMCX is much more convenient than the SMA for supplying a 100MHz clock to Urukul: since Kasli only has 1 SMA clock output (max), to supply more than 1 Urukul, one needs to buy a clocker and a bunch of SMAs. This is more expensive and creates a nastier cabling mess outside the rack.
3. The XO cannot be phase locked to the RTIO clock: so it cannot be used for deterministic latency, which is a high value feature for most users. The XO also cannot be phase locked to an atomic reference, so output frequencies will always be slightly off. e.g. with the XO, Urukul can't be used with the NU-servo, and the 48-bit FTW is completely pointless, so that knocks out the two main proposed uses for Urukul atm.
4. The SMA/XO will not provide better performance than the CDR clock: look at the data sheets for the CDR clock phase noise and the AD9910 PLL. We will be limited by the PLL, so the XO and CDR will give the same performance. The same applies to the SMA: passing the CDR clock through an external PLL (e.g. a Wenzel oscillator) won't improve the DDS performance, since the AD9910 PLL isn't better than the CDR clock.

So, what's the motivation for connecting the XO by default? And, if the MMCX clock is likely to be the most widely used choice, why require users to get out a soldering iron to activate it? What am I missing here?

Wenn use the same on allaki and there people want to go to several ghz.

?

[hartytp]

@gkasprow Is there an equivalent clock buffer to the one we're using that has >=3 inputs? That would be the ideal solution to this issue!

[hartytp]

Also, @jordens are you sure that the XO is the right part to use for this design, and that it's corrected properly? I never put too much thought into it, since I can't see us ever using it. But, AFAICT:

• current part is a VCXO, not an XO.
• tuning pin is currently floating (needs 1.65V with very good decoupling/low noise)?

If we're going to prioritise the XO, we should at the very least make sure it works! But, given the late stage of the design, I'd prefer to just DNP it and worry about it in the next revision.

[jordens]

@hartytp

• I can't check the XO. It wasn't in the BOM, the PDF fails to state the type, and I don't have Altium. It should be non-tunable XO with correct output impedance/matching.
• The comment about the discrete jumper/mux with resistors/capacitors at GHz is a response to you asking for such a thing
• The simplicity of the XO is high value. We don't depend on the intricacies of getting the clocking tree to work and it enables use of Kasli with for testing with Greg's LVDS-to-TTL boards. Being able to test, verify, debug and characterize a board without Kasli or Sayma/Metlino or some way to set the PGIAs would have accelerated Novogorny testing. I don't want to repeat that mistake and won't make the Urukul clocking dependent on Kasli.
• The SMA is more convenient to supply 100 MHz. You just connect it. No messing with the internals of the rack, no MMCX-to-SMA adapters with angled MMCX or pigtails in tight spaces, not tricky mechanics with non-locking and rotatable connectors or strain-relieving and wiring thin cables, no Clocker needed at all.
• If Kasli is run as master (in most cases it will be) there is no clock output on the Kasli front panel at all. And since we don't have linear regulators for the clock fanout on Kasli, I expect quite a few spurs from the switching power supplies. I don't want to risk that.

[jordens]

@gkasprow
That's 2.7 mm from the center of the hole. Loose washers go over that distance on PCB_3U_SMA.

[hartytp]

The comment about the discrete jumper/mux with resistors/capacitors at GHz is a response to you asking for such a thing

Okay. I was hoping for something that doesn't require soldering. Are you open to putting another mux on the board to allow all three options without soldering? BOM cost increase is pretty minimal for this!

The simplicity of the XO is high value. We don't depend on the intricacies of getting the clocking tree to work and it enables use of Kasli with for testing with Greg's LVDS-to-TTL boards. Being able to test, verify, debug and characterize a board without Kasli or Sayma/Metlino or some way to set the PGIAs would have accelerated Novogorny testing. I don't want to repeat that mistake and won't make the Urukul clocking dependent on Kasli.

ACK, but if the XO is primarily there for testing:

• My preference is to set the default population options they way they will be for users, not for testing; testers will generally only work on 1 or two boards, and will have soldering irons to hand, making minor modifications/swapping components easy. This is more of an ask for a user who buys a larger batch of these boards, and may be a graduate student with limited soldering abilities. Obviously, we can change population options after testing, but I find it's better to start as you mean to continue with these things. And, in any case, we will want to test Urukul using the MMCX at some point to verify its performance.
• Anyone testing this will have a 100MHz source they can connect to the SMA/MMCX anyway, so the XO isn't that important for testing.

The SMA is more convenient to supply 100 MHz. You just connect it. No messing with the internals of the rack, no MMCX-to-SMA adapters with angled MMCX or pigtails in tight spaces, not tricky mechanics with non-locking and rotatable connectors or strain-relieving and wiring thin cables, no Clocker needed at all.

Well, if you have more than one of these, you'll need some kind of very low noise fanout and clocker is about the cheapest option for that.

If Kasli is run as master (in most cases it will be) there is no clock output on the Kasli front panel at all. And since we don't have linear regulators for the clock fanout on Kasli, I expect quite a few spurs from the switching power supplies. I don't want to risk that.

I don't think this will be too much of an issue, but we'll see!

If Kasli is run as master (in most cases it will be)

FWIW, in our group at least, I anticipate having quite a few Kasli DRTIO slaves scattered around the lab. I think this will be quite common in the long run..

[jordens]

@hartytp Keep in mind that this run is a prototype run aiming for testability. I am happy to choose options so that we can test and characterize them and explicitly unhappy choosing options that make initial testing harder. Clock distribution inside the rack, three-way muxes are all late to the party. Kasli DRTIO slave usage, mass soldering is not something the prototypes are looking at.
The XO is not there primarily for testing. It is there for testing and for usage.

[hartytp]

Well, there isn't much more I can add to this conversation.

FWIW, I'm pretty sure that we need to change the VXCO, or at least change how the tuning pin is connected. If we're going to do that then changing to a three-way mux (e.g. by adding a second identical mux IC) at the same time doesn't seem to be unreasonable. IMHO, adding the three-way mux is justifiable at this stage if only because it makes testing easier since it allows us to swap between options without having to muck around with a soldering iron. How about that as a compromise solution?

[jordens]

We loose time due to new component choice, a few rounds of debugging the schematics again, component placement, layout. I don't know if there are mux/fanouts that meet all the criteria we had for the current mux and are not excessively large or expensive.
Sure. The XO needs to be verified. @gkasprow Which one is it?

[hartytp]

I can't check the XO. It wasn't in the BOM, the PDF fails to state the type, and I don't have Altium. It should be non-tunable XO with correct output impedance/matching.

AFAICT, the XO is a CVHD-950-100.000 (cf #201), same as on Baikal. This may have originally been my suggestion. But, I just did a really quick parametric search, and assumed someone else would check the details. As I said, it's not something I plan to use, so I didn't ever think too carefully about it...

[hartytp]

We loose time due to new component choice, a few rounds of debugging the schematics again, component placement, layout. I don't know if there are mux/fanouts that meet all the criteria we had for the current mux and are not excessively large or expensive.

I was more thinking of just putting two of the current mux in series to give 3 inputs. Cost/power consumption/space taken up by this are pretty minimal.

[jordens]

I don't think we want a VCXO here. I can't find an accuracy spec on that datasheet. Maybe there is a smaller standard 10-20 ppm 100 MHz XO that suits the fanout input, @gkasprow
And let's stick with the solder-mux (the same topology as for Allaki where you only need BOM changes or hand soldering) and the between the MMCX and the oscillator (and the current fanout) for our prototypes and revisit this later for production.

[gkasprow]

We can use U.FL connectors and jumpers. They are cheap and small and very popular.

[hartytp]

We can use U.FL connectors and jumpers. They are cheap and small and very popular.

Do you mean using U.FL<->U.FL cable?

[gkasprow]

yes. you can get them for 1$

[jordens]

1$, plus connectors, plus layout, board space, BOM line etc. Is the Allaki jumper not good enough? I am happy to change this after the prototypes.

[hartytp]

Is the Allaki jumper not good enough? I am happy to change this after the prototypes.

That's fine by me: let's stick with it as is for now and we can revisit it if needs be after prototyping.