Urukul schematic review

[hartytp]

Thanks for posting the updated Urukul schematic @gkasprow! Starting a review of it...

• [x] DDS_CLK1_P/DDS_CLK1_N and similar for other DDSs should be zero-indexed

• [x] RFSW_CTRL_1 etc should be zero-indexed

• [x] Annotation on page 7: "P12V0 current is up to 500mA", shouldn't that be 1A for our current EEM spec?

• [x] On the top page, can you label the LVDS interfaces "IDC 0" and "IDC 1" or similar, so it's easier to figure out which connector is associated with which block?

• [x] It looks like the clock baluns are currently not used (jumpered over), so should they be labeled DNP?

• [x] R79/R79 not needed since ADCLK has an internal termination

• [x] Can you clarify the default population option for the XO. By default, it should be DNP, right?

• [x] Power budget: ADCLK power consumption is overestimated, since only half of the outputs are used

• [x] Can we have a DIP switch for clock input selection, rather than using the PLD? (The PLD is going to be a pain for users to reprogram, so shouldn't be used for this kind of thing).

• [x] For the AD9912 comment "not mounted by default", an you add a box or something to make it clear which components this comment applies to?

• ~Can we connect the PLD up so reprogramming over I2C is possible (might be useful for distributing firmware upgrades to users)?~

• [x] RF amp should be ERA-3+, amplifier should be after RF attenuator, but before the RF switch (cf #199)

• ~Should we use the same low-noise LTC regulators we've used elsewhere for the sensitive analogue supply rails for the DDS + clock buffer?~

• [x] Fix a couple of misplaced tabs in the power budget table

• ~(Maybe) feel free to drop the discrete reconstruction filter (C164 etc) to save space.~

[hartytp]

@jordens Can you remind me what the plan for synchronising DDSs is for the "wide bandwidth" case?

[gkasprow]

@hartytp Thanks for quick review. There is 4 position DIP switch. So can be used for clock selectrion, IDC utlisation, LED assignment, etc. Instead of "DNP" I use variants, check PDF file now. The LTC regulators go up to 500mA. We need much more than that. We can use dedicated LDOs per DDS chip but we would need plenty of them. For CPLD update we would need to write bit-bang driver over I2C. I treat this CPLD as hardwired logic which used don;t need to touch. If there is some volunteer who will write such update software, I can add I2C extender that controls JTAG lines.

[hartytp]

@gkasprow Likewise -- thanks for the quick fixes!

There is 4 position DIP switch. So can be used for clock selectrion, IDC utlisation, LED assignment, etc.

Thanks.

The LTC regulators go up to 500mA. We need much more than that. We can use dedicated LDOs per DDS chip but we would need plenty of them.

Okay, so long as the LDOs you've chosen are reasonably low noise, let's stick with them.

If we have issues with noise or supply-line-related cross-talk, we can consider moving to 1 LDO per DDS in the next revision.

For CPLD update we would need to write bit-bang driver over I2C. I treat this CPLD as hardwired logic which used don;t need to touch. If there is some volunteer who will write such update software, I can add I2C extender that controls JTAG lines.

@jordens may feel differently, but I think it's worth adding the I2C extended, even if it's DNP by default. That way, at least we have the option of programming over I2C if we decide to write the loader later on.

[jordens]

Wide bandwidth case?

[jordens]

Awesome!

• I like the cpld idea.
• We should agree to work hard to keep the cpld logic purely combinatorial. And it should be written, agreed upon, and unittested before the prototypes arrive. In that case I am ok with JTAG only.
• Did you go for the Si fanout just because it is lower power and cheaper than another adclk? Is it worth the additional bom line?
• PS design looks ok to me but needs a thermal sim.
• Also the (or at least two of the) first prototypes need to be with ad9912. ... More coming.

[gkasprow]

@jordens I used this LVDS fanout because it has individual output enables and I need LVDS not LVPECL. However I cannot use it as clock fanout because it runs up to 700MHz.

[hartytp]

Wide bandwidth case?

The mode used in the NU servo (that's what it's called on the Wiki atm).

[jordens]

@hartytp use the ad9910 sync mechanism and either drive that sync from the servo or sync the servo to it. AFAICT either should work.

[hartytp]

@gkasprow On the new version of the schematic, all the repeated blocks are now included multiple times (e.g. 4 identical pages of DDSs). In the past, there was just one copy of each, which was better IMO. Can we go back to just one copy of each identical block, please?

Also, obvious point, but have you double checked the termination/matching required for all the DDS inputs/outputs? (IIRC, there are a few quirks about how the various pins are terminated/need to be terminated/matched).

[hartytp]

@hartytp use the ad9910 sync mechanism and either drive that sync from the servo or sync the servo to it. AFAICT either should work.

@jordens My memory of the AD9910 is a little rust now, but IIRC:

• To sync the AD9910 with the servo, one needs to supply it with a SYNC_IN signal generated by the servo
• To sync the servo with the AD9910, one needs to feed the SYNC_OUT signal to the FPGA.

However, as currently described on the Wiki, neither of those signals are connected to the IDCs in the "wide bandwidth" case. Or, am I missing something?

[gkasprow]

@hartytp notice that pages differ by component designators. Altium prints each channel separately when assembly variants are used because each channel can differ. Another option is to use DNP marking for not mounted components. But then we cannot have variants for 9912 and 9910. SYNC_OUT from DDS0 can be routed via IC9 to LVDS1 directly to avoid TTL->LVDS buffer delay

[hartytp]

Altium prints each channel separately when assembly variants are used because each channel can differ. Another option is to use DNP marking for not mounted components. But then we cannot have variants for 9912 and 9910.

Okay, that makes sense. If the variants option is useful for maintaining multiple population options then I don't object to using it...

SYNC_OUT from DDS0 can be routed via IC9 to LVDS1 directly to avoid TTL->LVDS buffer delay

My question was more about pin usage on the IDC connector; for the "wide bandwidth" case, where we have lines for each MOSI and for each switch, there aren't any lines spare for SYNC_IN/SYNC_OUT (although, these could be multiplexed with the attenuator control lines using a CS and the PLD).

[jordens]

(items moved to OP)

@hartytp re synchronization. we would use the CPLD to enable driving SYNC_IN from the FPGA during the startup phase.

[hartytp]

@hartytp re synchronization. we would use the CPLD to enable driving SYNC_IN from the FPGA during the startup phase.

Thanks for clarifying, that sounds good. Do you think that, once synchronised, synchronisation will be maintained for months? Do we need a way of checking for sync errors?

Edit: otherwise, since the attenuators won't be reprogrammed often, we could mux the SYNC_IN and attenuators, so that SYNC_IN is applied to the DDSs whenever the attenuators aren't being reprogrammed (will need a little care to avoid glitches)...

• [x] To do: add this to the Wiki.

[hartytp]

@jordens Re isolated GNDs on Urukul SMAs: I think it's nice to have the pads on the PCB so that floating the grounds is easy (just means altering the FP) if required. However, I'm not sure it's worth the hassle of actually fitting isolated washers by default (depends a little on how much it adds to the cost, and how good it is mechanically). Isolating the grounds is certainly not actually required for anything I'm planning to do with these boards...

[hartytp]

TR1 should be a 1:sqrt(2) transformer. Does minicircuits have anything closer to that (e.g. 1:1.5)? Or is 1:2 already optimized for some reason I don't see? I know it is on the eval board...

@sbouhabib Can you remind me why we didn't do this for Allaki? Shouldn't that also have been a 1:sqrt(2) rather than 1:2?

[jordens]

I agree on the shield AC coupling. But it should be done consistently for the SMA clock input and the SMA DDS outputs. I.e. also make the clock input AC-couplable.

[hartytp]

I have a vague memory (but didn't see anything in a quick skim through the data sheet) of the SYNC_CLK output of the AD9910 only having a really weak current drive. Needing something like 1k min termination. Does that ring any bells @cjbe?

[hartytp]

@jordens does it matter that IO_UPDATE and SYNC_IN/IO_UPDATE_RED will be on different IDCs, while Kasli/VHDCI_CARRIER currently only do length matching between lines on the same IDC? (i.e. IO_UPDATE and SYNC_IN paths will not be length matched)?

[gkasprow]

@hartytp It says only that CMOS outputs deliver 0.4 or 2.8V at 1mA load. Which means that the output resistance is roughly 400...500OHms.

[hartytp]

Thanks @gkasprow!

So, given that SNC_CLK is a low current CMOS output:

• we need to be careful with capacitive loading on this pin
• We should probably not 100Ohm terminate it at the input to the buffer (as in the current schematic)
• If we do buffer this signal, but not the other synchronisation-related signals, will the propagation delay of the buffer be an issue?

[jordens]

The fanout (andf the CPLD) are there to do the buffering. SYNC_OUT only needs to be matched on the branches to the DDS (SYNC_IN, as I described above). The rest doesn't matter.

[hartytp]

The fanout (andf the CPLD) are there to do the buffering.

ACK, but let's increase the termination resistance a bit.

[gkasprow]

@hartytp the SYNC_CLK is delivered to the IC4 via level conversion resistive network. One can increase R31 to even 1kOhm. We need only to make sure that LVDS buffer see signal amplitude at least 200mV.

[hartytp]

@gkasprow Okay, if you're happy this will work reliably, that's fine then.

[jordens]

I split the pending open items from this issue into #270 #271 #272 #273 #274 #275 #276 #277 #278 #279 #280 #281 #282