Re: [ARTIQ] FW: initial specification of the project

[Sébastien Bourdeauducq]

On Friday, 1 April 2016 5:25:19 PM HKT Thomas Harty wrote:
> d) Something else I'm missing?

Low-frequency jitter of the PLL?

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] FW: initial specification of the project

[Thomas Harty]

Agreed, clock phase noise is _very_ important, and backplane crosstalk will be 
a killer if clocks are distributed without due care. Having said that, I'm not 
convinced that clock distribution via the backplane isn't the right way to go 
if done properly -- even for the most demanding applications.

The plan would be to derive the backplane clock from a source with extremely 
good close-in phase noise/long term stability, such as an atomic reference. 
Transmission over the backplane will degrade the short-term stability (the 
phase noise far from the carrier) to an unacceptable level. To fix this, we 
would use an on-AMC (or FMC board) PLL based on a low-noise VCO. The PLL loop 
filter would be designed with narrow bandwidth in order to reduce the VCO phase 
noise to the reference level at low frequencies, while still rejecting noise 
further from the carrier.

Take the 2.4GHz DAC clock as an example. A decent (relatively small and 
inexpensive) choice of VCO for the PLL might be a UMX-630-D16-G 
(http://www.rfmd.com/store/products/all-products/oscillators/ultra-low-noise-cro-vcos/umx-630-d16-g-1.html).
 To get an idea of the lock bandwidth required, we can compare the phase noise 
of this VCO with a typical high-quality lab 10MHz source, such as a SRS FS725 
Rubidium Standard (http://www.thinksrs.com/products/FS725.htm) scaled from 
10MHz to 2.4GHz by adding 20*log10(240)=48dB. By 10kHz offset frequency, the 
typical VCO noise is -108dBc/Hz, compared with a (scaled) noise for the FS725 
of ~-105dBc/Hz. Beyond that, the VCO is significantly better*.

So, the lock bandwidth we need should only be a few kHz. With proper design of 
the loop filter, one should be able to heavily suppress any noise much outside 
this range (it might also be worth putting a low-Q low-pass/band-pass filter on 
the 10MHz clock to remove any noise far outside the loop bandwidth). So, as 
long as we don't put any signals down the backplane which have significant 
spectral content within, say, a few hundred kHz of the clock frequency, I 
wouldn't expect cross-talk to be an issue.

Presumably, your concern is some combination of:

a) We won't be able to build a PLL on the AMC/FMC board which has good enough 
phase noise @2.4GHz, regardless of the quality of the 10MHz reference we feed it
b) The PLL won't do a good enough job of removing noise on the reference clock 
far outside the loop bandwidth (say, outside the range 9MHz - 11MHz if one 
wants to be pessimistic)
c) Even with a narrow-bandwidth (~1kHz) PLL with carefully chosen loop filter, 
and taking care over what other signals we send down the backplane, there will 
be too much pickup on the clock line close to 10MHz that can't be filtered off
d) Something else I'm missing?

If you have any measurements relevant to this, I'd be interested to see them. 
We're currently building hardware, one purpose of which will be to test how 
well we can generate a low phase noise 1GHz DDS clock from a 10MHz signal 
distributed down a uTCA backplane.

Best,

Tom

* Of course, actually achieving this noise level will require some work in 
terms of simulation/testing the PLL design, and may need a multi-loop PLL to 
prevent the high divider ratio from causing problems with the PFD...

From: Slichter, Daniel H. (Fed) [daniel.slich...@nist.gov]
Sent: 31 March 2016 17:21
To: Thomas Harty; artiq@lists.m-labs.hk
Subject: RE: FW: initial specification of the project


Re DAC clock: presumably, the plan is to distribute a 10MHz (or 100MHz, or 
whatever) clock with really low close-in phase noise to each MCH, and then from 
each MCH to the AMCs via the backplane. Why not send this from the AMC to the 
FMC boards via the FMC connectors? Then, have the FMC board generate the DAC 
clock using an integer-N PLL. If done properly, an int-N PLL at a couple of GHz 
is cheap, has a small footprint and will give as good phase noise/phase 
stability as using an external synth plus coax. The loop filter bandwidth can 
be low enough to take out any cross-talk from the FMC/backplane. Plus, this way 
the DAC clock has a well-defined phase relationship to the main system clock 
(the 10MHz or whatever), which may come in handy for keeping everything 
synchronised...
Basically, it is not possible to generate a sufficiently high performance DAC 
clock for many applications from something that comes over the backplane, due 
to crosstalk/signal integrity issues.  Joe Britton has some data on clock noise 
over uTCA backplanes, I believe.  The idea would be to have a clock selection 
crossbar switch on the FMC card, which allows the user either to use an 
external clock brought in on an SMA connector, or to use a clock generated by a 
PLL on the AMC card referenced to a backplane clock (and there will be 
backplane clocks for digital timing purposes).  This way people who really care 
about phase noise can have it as good as they want, while people who don’t care 
as much can dispense with 

Re: [ARTIQ] NIST IT security requirement - reimplement ARTIQ in C/C++

[Hankin, Aaron M. (Assoc)]

From: ARTIQ  on behalf of Slichter, Daniel H. 
(Fed) 
Sent: Friday, April 1, 2016 9:19 AM
To: artiq@lists.m-labs.hk
Subject: [ARTIQ] NIST IT security requirement - reimplement ARTIQ in C/C++


Hi,



NIST IT security has just pushed a new policy that any and all software 
developed by outside contractors must be in C or C++ only.  Apparently they are 
going to run some sort of scanning software on the source to look for malicious 
code and this will only work on code written in C or C++.  All other 
programming languages are banned.  So we will need to reimplement the entirety 
of ARTIQ in C or C++.



Sorry for the hassle!

Daniel


___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] NIST IT security requirement - reimplement ARTIQ in C/C++

[Slichter, Daniel H. (Fed)]

Hi,

NIST IT security has just pushed a new policy that any and all software 
developed by outside contractors must be in C or C++ only.  Apparently they are 
going to run some sort of scanning software on the source to look for malicious 
code and this will only work on code written in C or C++.  All other 
programming languages are banned.  So we will need to reimplement the entirety 
of ARTIQ in C or C++.

Sorry for the hassle!
Daniel

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] DSP gateware

[Robert Jördens]

On Fri, Apr 1, 2016 at 1:09 AM, Slichter, Daniel H. (Fed)
 wrote:
>> And a 16 ns pulse would be just about 20 samples. Why would you want to
>> describe that using ~4 spline knots each being maybe 16 times 16 bits in 
>> data.
>> If you need the full bandwidth, the idea of compression using splines is not
>> very helpful. In that case you would need to design in a little "real" AWG
>> player that plays snippets from a wide BRAM.
>
> Sure, that is a better solution for these kinds of things.  I am just saying 
> that unless we have some suitable feature like this, no superconducting 
> people will be interested in the system.  So we should design things in such 
> a way that this is a possibility, to maximize the target audience.

Sure. If people want "real" sample-based AWG, it should be into the
specification. I was just pointing out that trying to do it with
spline interpolators is not particularly bright.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq