Kasli clocking

[jordens]

• [x] Is the LTC6957 needed? IMHO we can skip it.
• [x] The SMA assignment is not the way we'd want it. I'd like to be able to get the recovered DRTIO clock out of Kasli, then feed it through some external PLL/cleaner, and then input it into Kasli for distribution to the EEM fanout again. For SMA1, there would be two use cases:
  • [x] (master mode): SMA1: DRTIO ref clock input
  • [x] (slave mode): SMA1: recovered DRTIO clock
• [x] SMA2 should always be the input to the fan-out to the EEMs.
• [x] Only if it is really easy, provide a way to feed DRTIO clock (same as the one going to the FPGA logic and transcievers) to the EEM-fanout.
• [x] Also feel free to use a bulkhead SMA connector and then a cable (or pigtail) for SMA2 if that helps with front panel space.
• [x] IC3 IN_SEL needs a jumper to select the input.
• [x] Remove R30 and R33 as IC3 (ADCLK948BCPZ) has internal termination.
• [x] No need for TR1 and TR2. Drive IC2 (Si5324C-C-GM) and IC3 (ADCLK948BCPZ) single ended. Reduce the number of MMCX connectors to 7. Drive the backplane (TR3) directly from the freed-up diff output. Saves one BOM line. @hartytp OK? @marmeladapk We should probably actually remove these components rather than just marking them as DNP to save board space.
• [ ] Please double check CK_FPGAIO_P and _N bias. Really OK to just bias _P?
• [x] Make all biasing resistors for negative outputs on IC3 DNP by default (apart from the diff pair going to the BP). CLK_CDR_SMA_OUT_N biasing resistor (R11) should also be DNP.

[jordens]

@dhslichter Ack. You can add space for free and fill the front with a vanity panel. The rail placement granularity is 1HP. This will likely be very useful generally as the wiring is be dense near Kasli.

[dhslichter]

@jordens @hartytp sounds good. Let's see if @WeiDaZhang can send a decent signal down the coax and if so, we'll stick with that. The wiring around Kasli is going to get really hairy if we have a full rack....

[WeiDaZhang]

I don't mind at all. I'll perform the above tests tomorrow and let you guys know the results ASAP then.

[jordens]

One thing to clean up the wiring would be to put a mezzanine with 4 IDC and one 96-pin DIN onto Kasli and run all 8 EEMs over the backplane.

[gkasprow]

@jordens We can also use two such mezzanines to run 12EEMs. This we will decide after we gain some experience operating EEM environment. With backplane we are tied to particular Euro cassette due to fixing.

[jordens]

@gkasprow Sure. I had already included that in the wiki page. I fully agree that we should not do that right now but just keep it in mind.

[hartytp]

One thing to clean up the wiring would be to put a mezzanine with 4 IDC and one 96-pin DIN onto Kasli and run all 8 EEMs over the backplane.

@jordens Excellent idea. The main reason I was against the BP was that with only a single 96-pin DIN there doesn't seem to be enough IO to justify the effort/expense of designing/manufacturing/installing a BP. If we can get 12EEMs + clocks using 2 additional tongues/mezzanines then I think the BP could be really nice.

• [ ] We should arrange the IDC headers on Kasli to make installing these mezzanine boards as easy as possible (e.g. place the IDCs directly behind the 96 pin DIN on Kasli).
• [ ] We should also add some mounting holes, which can be used to secure the mezzanines.

[hartytp]

@gkasprow Should we design the IDC->96-pin DIN mezzanines now? My thinking is that:

• they should be pretty quick to design and test.
• once we have them, it's easy to check for mechanical issues on Kasli, such as having the wrong stack-up height for the mezzanines. These issues could easily be missed if we don't have the mezzanines during testing, making it hard/impossible to retrofit the mezzanines later on.

[gkasprow]

@hartytp We can design 3D mock-up to solve mechanical issues and see how it fits. I don't see particular reason to produce them right now.

[hartytp]

@gkasprow I tend to like producing these things rather than just doing the modelling, as the boards are fairly cheap to make, and occasionally mistakes can slip into CAD models.

However, if you're happy with CAD alone, then it's absolutely fine by me.

[gkasprow]

@hartytp Sure, we can produce them but someone must design them first:) And we have plenty of other things to do.

[hartytp]

Fair enough.

[dhslichter]

AFAICT there don't exist commercial backplane solutions with the desired connectivity for 12 EEM run over LVDS, so there would be some very substantial design work there as well to get this all working, particularly if we will be shipping nice 1 GHz analog clocks and tons of digital logic over the same backplane (and in the digital servo use case, the digital will be going all the time).

This backplane is a nontrivial beast, to say the least. Is the 96-DIN the right connector to use in such an instance? Will we be able to fit all of the LVDS pairs for the required point-to-point wiring in with through-hole connectors, threading between the pins? Will we still be able to fit it in a standard Eurocard height? How will the clocks connect to the backplane in/out? I think the 96-DIN is certainly the wrong connector for high-performance analog clocks at 1 GHz, in terms of signal integrity.

My general feeling is this: the backplane idea is nice and is obviously where things should go in the long run, but a major part of the reason we decided to do the ribbon cable ratsnest for now is that it's really hard to do the backplane correctly for this application. It seems to me that we should focus on delivering a functional initial set of hardware using ribbon cables and coax, and just not worry about the backplane for right now. All the boards will need some redesign to use the backplane, and so if Kasli would also need that (e.g. to add in some additional mezzanines for the desired backplane connectivity), so be it. But I fear we're letting the perfect be the enemy of the good here.

[dhslichter]

Another question along these lines -- might it be better in the long haul to have Kasli's functionality actually just integrated on the backplane? You would have a slim "dumb" card that brings SFP and coax connections to the front panel, and connects them to the backplane via some high-performance but lower-pin-count connector, suitable for gigabit signals. Then the Artix FPGA, clock distribution, etc all live on the backplane, and you don't need crazy fat connectors just to route all the EEM signals and clocks off the Kasli and on to the backplane. This would also free more front panel space, because if you are adding 96-DIN mezzanines to Kasli then this obviously will make it wider, which @hartytp and @jordens have indicated is undesirable for them.

The only downside I can see is that if your FPGA on the backplane goes bad for some reason, it's more work to change it out....but this seems like it should not be a very common occurrence.

[dhslichter]

One more thought -- the Urukul has the option to be run with either one or two IDC cables, depending on use case. This limits the flexibility of the system if you are using a backplane unless you have a massive number of additional IO such that you can ensure each backplane connector can support the equivalent of two IDCs.

[gkasprow]

Yet another issue with backplane is that when you use 8HP boards, one slot is wasted.

[dhslichter]

I'll just close by saying that the point of the Kasli system was explicitly NOT to be as complex as the uTCA system, so we should be careful of mission creep here.

[hartytp]

@dhslichter ACK. I'd be happy to freeze Kasli here and move on to the layout.

[jordens]

The backplane is something that I don't want to make big changes to kasli for. Also per layer on the backplane it seems to me that you can route one full (or slightly less than one full) din connector with a star configuration. That sounds just fine for us. And speed wise 500 MHz lvds are not an issue. Clock over the backplane is another question.

[jordens]

And on the wiki I have sketched a way to allow both the two IDC urukul do the single IDC urukul. That might be a possible approach.

[dhslichter]

@jordens ack that there is nothing fundamentally impossible about the backplane, but it will be rather complex board and agreed that we should proceed with Kasli as is and worry about the backplane in a future generation.

[WeiDaZhang]

I'm afraid there is not an ADCLK948 eval board in my hand, but an ADCLK925 eval board instead. However, there is an ADCLK948 chip on the CLK mezzanine prototype board which I have been working on recently. It was designed to accept coax input pair and fanout to coax output pairs. So I measured on that with small modifications.

It has been noticed that the amplitude modulation noise is not significantly smaller than the phase noise, therefore it is plotted as well.

Both ADCLK925 and ADCLK948 are measured with one of its inputs AC coupled to an SMA connector and the other input AC coupled to ground. The output is measured on one line of an LVPECL pair through SMA connector and the other line is floating with the 200Ohm bias removed.

In total, I've done the following measurement:

• The phase noise of Wenzel 501-26228
• The phase noise and amplitude modulation of Wenzel 501-26228
• The phase noise of ADCLK925 on its eval board
• The phase noise and amplitude modulation of ADCLK925 on its eval board
• The phase noise of ADCLK948 on the CLK mezzanine prototype board
• The phase noise and amplitude modulation of ADCLK948 on the CLK mezzanine prototype board.

All the measurement are taken at the frequency of 100MHz w/ R&S FSWP8.

[hartytp]

Great, thank you for doing that @WeiDaZhang! That's really helpful.

Interesting that the ADCLK925 performed worse than the ADCLK948, even though IIRC it's nominally a lower noise IC. One thought about this: since we're not using this IC with differential inputs/outputs, it's possible that we're more sensitive to power supply noise than normal.

My though here is that the ADCLK948 is on a mezzanine with a very good LDO, while the ADCLK925 eval board doesn't have a LDO on it, so the PSU noise is limited by whatever bench top supply you're using. Maybe if you used a better supply (e.g. the same regulator you're using on the clock mezzanine -- can you run air wires between the eval boards to do this?) you'd measure lower noise on the ADCLK925?

Anyway, we should watch out for this on Kasli. Clock buffers are analogue chips and so need very clean supplies -- particularly if not used differentially. If we really want to achieve the lowest noise for Kasli's clock buffers, then we may need to consider adding an LDO.

Edit: Having said all that, the phase noise you measure there is much better than the AD9910 PLL on noise. So, I'd argue that these tests show that LVPECL over coax works with no baluns and leaving off the biasing from the negative output pin to save power. Let's not worry about using a particularly low noise voltage rail here, unless we really want to push the clock noise floor.

[hartytp]

Re Kasli backplane:

AFAICT, the only change that needs to be made to Kasli to enable Robert's proposal (IDC->mezzanines) is adding a few mounting holes and ensuring that the IDCs are placed sensibly. That seems like a worthwhile thing to to anyway, as it could also come in handy for using Kasli as an ARTIQ real-time carrier PCB. The idea here would be to put Kasli in a box with a daughter PCB that mounts directly on top of Kasli and uses the IDCs as board-to-board connectors for IO and power (you'd need an internal coax for clocks).

So, let's all agree that we should do that and then freeze Kasli here!

Another question along these lines -- might it be better in the long haul to have Kasli's functionality actually just integrated on the backplane? You would have a slim "dumb" card that brings SFP and coax connections to the front panel, and connects them to the backplane via some high-performance but lower-pin-count connector, suitable for gigabit signals. Then the Artix FPGA, clock distribution, etc all live on the backplane, and you don't need crazy fat connectors just to route all the EEM signals and clocks off the Kasli and on to the backplane. This would also free more front panel space, because if you are adding 96-DIN mezzanines to Kasli then this obviously will make it wider,

As this doesn't affect Kasli directly, it's a bit off topic here. But, nonetheless, it's a good though, and could be the way to go...

[hartytp]

If you put a larger FPGA like a XC7A200T-2FFG1156C (which is still only something like $150 in quantity) directly on the BP, you'd have enough IO to route 8 independent LVDS lines to each connector in a full-sized chassis with a 4HP pitch.

[sbourdeauducq]

The backplane is something that I don't want to make big changes to kasli for.

Agreed, remember that Kasli is also a Pipistrello replacement (since we dropped Pipistrello support). We really should keep it simple.

[gkasprow]

Additional mounting holes are already on Kasli, I use them on all 3U boards. With 2 mounting holes at the connectors it is more than sufficient.

[jordens]

I updated the post at the top summarizing what I could. @hartytp could you double check?

[hartytp]

@gkasprow Would it be better from a signal-integrity/EMI point of view to put EXT_CLK_P and EXT_CLK_N on the same 96-pin DIN connector (rather than splitting the pair across two connectors)? (e.g. remove a 12V power pin from one connector and add it to another one)?

[hartytp]

@gkasprow Is there a newer version of the Kasli schematic? It looks like some of the issues above have already been fixed (judging by the items that have been ticked off) but the schematic hasn't been updated...

[jordens]

@hartytp That's a single connector. Just different rows. I ticked off the items that looked fixed to me in the current version. Did I overdo it?

[hartytp]

@hartytp That's a single connector. Just different rows.

Oops, yes, my mistake. Thanks.

I ticked off the items that looked fixed to me in the current version. Did I overdo it?

No, the things you ticked off are correct.

But there is a post from mine about mid-way up this issue, where I catalogued things that need doing. @marmeladapk has ticked things off that list, which aren't done in the current schematic, so I suspect that the schematic is old. AFAICT, most outstanding points on your list are already fixed.

@gkasprow Can you push the latest design, please?

[marmeladapk]

@hartytp I was travelling to Boulder, I'll upload newest version today or tommorow.

[hartytp]

@marmeladapk Thanks!

[jordens]

@marmeladapk thanks. Enjoy Boulder! See you Sunday.

[hartytp]

@marmeladapk Thanks for the commit. Can you update the PDF as well (I don't have access to allium atm).

[marmeladapk]

@hartyp It should be updated as well, that's strange. I'll check that in the evening.

pt., 11.08.2017, 10:40 użytkownik hartytp notifications@github.com napisał:

@marmeladapk https://github.com/marmeladapk Thanks for the commit. Can you update the PDF as well (I don't have access to allium atm).

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/m-labs/sinara/issues/204#issuecomment-321861352, or mute the thread https://github.com/notifications/unsubscribe-auth/AXYIXBtnMhYsVcDtUN0M3OebSdrICSnBks5sXIPvgaJpZM4NlM34 .

[marmeladapk]

@hartytp It's updated now.

[hartytp]

Thanks!

Note to self about Kasli clock distribution:

• Strategy is to provide something simple/low-cost that will work for the majority of use cases. However, it's not ultra low-noise (only using one arm of diff pair, not using baluns, not attempting to break ground loops, clock buffer run from a SMPs rather than a fancy low-noise LDO, etc...).
• If Kasli is run as DRTIO master, there is no clock output SMA on the FP to allow daisy chaining (e.g. to a stand-alone Sayma).
• In the future, we should make a simple EuroCard board with an ADCLK948 to provide an ultra-low noise clock buffer, with isolated grounds for each channel.

[jordens]

Allo done. The last open item from the top post is also in #250 .