> On Wed, Mar 30, 2016 at 10:25 PM, Slichter, Daniel H. (Fed) > <daniel.slich...@nist.gov> wrote: > > Now, as you suggest we could just change the level at which we make this > break from the AMC card, shift the DACs and ADCs onto the daughter card as > well, and use FMC to communicate with the whole thing. This makes it a bit > more expensive/difficult to reconfigure the analog front end, but the DAC > and ADC costs are not so high that it is impossible to do. I had envisioned > the > notion of making the daughtercards simple enough that end users could > redesign/respin easily to accommodate their own applications, or we could > ship unstuffed or partially stuffed boards that they could complete with the > particular filters etc they desire. > > It makes letting unused mezzanines collect dust on the shelf more > expensive.
The point is you buy X number of daughtercards for Y AMC cards, where X>Y (perhaps X=2*Y or X=3*Y), and the daughtercards either do or don't have ADC/DAC on them. If they do, it costs you more than if the ADC/DAC were on the AMC modules. > > However, I agree that there are compelling arguments for using the > architecture you propose. We would need to pick just a few board styles (I > suggest quad DAC, 2 DAC/2 ADC, and quad ADC), and for each of these board > styles we would need to make several different variants with different > analog front ends (3 types for DAC - low frequency, baseband RF, > upconverted RF - and 2 types for ADC - baseband RF and downconverted RF, > both likely including switchable gain). So now we are looking at making 3 > types of quad DAC boards, 2 types of ADC board, and probably 3 types of > DAC/ADC board (upconvert DAC/downconvert ADC, baseband RF > DAC/baseband RF ADC, and low frequency DAC/baseband RF ADC). So now > there are 8 different daughterboard designs. If we restrict ourselves to just > quad DAC or quad ADC on a given daughtercard, then there are 5 designs, > same as in the current proposal for analog-only daughtercards. I would still > want to have boards be partially stuffed (or stuffed in different > configurations on demand) to allow users to choose the frequencies of > interest for analog filters etc. > > > > If we proceed this way, we will need an external clock SMA for each FMC > module, because we don't want the high-quality external clock going down > one FMC connector, across the AMC, and up the other FMC connector for > signal integrity/crosstalk reasons. > > For a digital clock with fast edges 60 dB of crosstalk is _much_ less of a > problem. No! The clock coming in will be a sine wave from a low phase noise oscillator somewhere. The DACs and ADCs will threshold this clock to determine their sample times. Any amount of crosstalk will distort the clock signal (adding or subtracting to the voltage at a given time), thus skewing the time at which the threshold is reached and thus inducing jitter into the sampling times. This would also hold true even if you have an LVPECL clock signal, because at frequencies like 2.4 GHz the rise and fall times (~100-200 ps) are similar to that of a sine wave. Unlike for digital data signals, any amount of crosstalk will degrade the jitter and/or edge time performance for a clock signal. > > Are we thinking we would try to implement the actual VITA 57 standard on > these connectors? Or just use them as convenient high-speed-capable > connectors? I agree with the second idea, but I don't like the first one. > > What from the VITA 57 pin assignmend do you not like? If you comply with VITA 57, we will need to use an HPC connector to get enough gigabit transceivers into the connector, and we will have to populate all the other digital lines. We could use an HPC connector with the VITA 57 LPC connections, plus adding on the gigabit transceivers in the locations where they would go for an HPC connector, and thus have an LPC compliant connector with "extra features" for the needed gigabit transceivers. I am just trying to reduce unnecessary complexity in routing the AMC board to the FMC connectors, since HPC is much more of a pain than LPC in this regard. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
