search

sinara-hw / sinara

Sayma AMC/RTM issue tracker
Other
42 stars 7 forks source link

Number/type of analog mezzanine designs #32

Closed dhslichter closed 7 years ago

dhslichter commented 7 years ago

The current spec for analog mezzanines in https://github.com/m-labs/artiq-hardware is outdated; the new design calls for both input and output on the same mezzanine, mezzanines are no longer castellated, and we may desire multi-width designs.

We need to develop a list of which mezzanines are desired for implementation (combinations of input/output styles). I have made a straw man proposal below, feedback/suggestions/contributions needed: @sbourdeauducq @jordens @gkasprow @sbouhabib @hartytp @jmizrahi @jbqubit @dtcallcock

My recollection of previous discussions with some others is that we should not worry for now about "PDQ"-like applications for current Sayma RTM ("Ulvidy" in the current spec) -- generation of "fast" (~1 MHz bandwidth) trap voltage splines (+/- 10V) may be more efficient to do with different DACs, able to put out many more channels per RTM card on e.g. SCSI-type cable for routing to trap.

If desired, we can rename these after obscure tiny Russian towns again, I have put in placeholder names so we don't get confused with the existing definitions.

Proposed mezzanines

hartytp commented 7 years ago

IMHO, it would be much better not to name these boards after obscure Russian towns. I've had too many conversations about "the board that does ..., and has some obscure name that I can't remember". Things that make a name memorable for me include

dhslichter commented 7 years ago

I know that some may rain fire and hell down about how you're not supposed to name things after what they are intended to do, and I understand that. However, it might be nice to use names that aren't just plucked from thin air, where one doesn't have to strain to remember the names. How about cities people know? "Tokyo", "London", "Paris"?

dhslichter commented 7 years ago

Or: how about names that start with a letter indicating frequency range? This is well-defined: "L" for baseband (boards which operate below 500 MHz), "M" for boards which can use the higher Nyquist images or the digital upconversion in the DAC (between 500 MHz and 3.6 GHz), "H" for up/down conversion boards. Then the name provides some useful information about what frequency ranges it's good for, as a quick guide, but you don't have to worry about name collisions or calling boards "microwave" when they are not.

hartytp commented 7 years ago

For fear of hell-fire/ridicule: why not go for names that reflect function? I can see the desire for avoiding naming collisions, but I don't think that the best solution is to go for the most obscure names we can think of. It's a bit like taking advice from the guide to writing unmaintainable code.

Still, so long as it all works, I guess we can all call it what we like...

jordens commented 7 years ago

Please do not try to encode metadata like function or frequency band in the name. That is bound to fail. It is about as naive as calling computers by their room, division, function, owner, cpu speed, peripherals connected. All those are ephemeral. Refer to the relevant RFCs. Claiming that "Paris" "has an obvious English-language pronunciation" is ironic at best. Claiming that "Allaki" is harder to work with or remember makes me suspicious...

dhslichter commented 7 years ago

For example one could have baseband designs London and Lodz, microwave design Mexico and Milan, up/downconverting designs Houston and Hamburg. Simple names with not too many letters, not rhyming (to avoid confusion over the phone with poor connection, for example), common international words. We don't all have to pronounce them the same way if we don't want to.

I personally disagree with @jordens assessment of what necessarily constitutes "naive" naming, or what is "bound to fail". It is true that names that include some metadata may not "scale" ad infinitum, but they can be useful under certain circumstances when it is not required to scale ad infinitum, exactly because the name conveys some information without the need for additional lookup. Also -- computers can move and change owners and divisions (simple solution -- rename the computer at that time). Baseband mezzanine cards will never be upconverting mezzanine cards. If you modify an existing design to work differently, give it a different name and keep both designs.

That said, I don't want this to be an argument about names. If everything ends up being "Allaki" and "Argayash" it's not the end of the world. The point of this thread is to discuss what types of analog mezzanines are required, now that the old specification is defunct and we have combined both analog output and input onto the same physical cards.

jordens commented 7 years ago

And you made my day with "widely-known, phonetically spelled names" like "Mow", "Larrie", "Curlie", "Shamb", and "Basser"...

dhslichter commented 7 years ago

These names are explicitly placeholders (see my actual words in opening the issue), never intended to last. I just needed something quick to use that was different from current names to avoid confusion for the time being. They are the names of The Three Stooges (and two more guys who played Stooges). I chose them intentionally because I figured we would never want to keep such names, so they were safely placeholder names.

I have made my suggestion for a different way of naming the mezzanines, and have explicitly stated in multiple places that it is a suggestion, not a demand, and that I am OK with keeping the current names if that is what the majority wants.

Now, can we PLEASE actually talk about the desired card functionalities?

jmizrahi commented 7 years ago

For the first mezzanine card listed, I do not think it needs a DC coupling option. I think DC coupling should be handled with a different, dedicated mezzanine.

@dhslichter Developing schematics, layouts, etc for all five of the listed mezzanines seems like quite a bit of work, and as far as I know only the development of the first one (i.e. the simple baseband) is funded. Is there funding available from some other source for these other mezzanines?

dhslichter commented 7 years ago

@jmizrahi thank you. Development for other mezzanines is not funded yet, to my knowledge, but the design intent should be stated so it can be discussed/modified as appropriate. In addition, important considerations are raised by the desired mezzanine functionalities in terms of what voltage rails need to be supplied to the mezzanines, and what (if any) signal conditioning needs to be performed on the Sayma card (see #22, #23 for example).

Many of the cards are simple enough that groups could develop them independently as desired (and then share designs if they so choose). My main point is that the current spec is totally outdated, we need a new spec, and when thinking about this new spec should consider what cards we would intend to have developed (whether or not funding is currently in place), as this impacts design choices for the Sayma right now.

jordens commented 7 years ago
gkasprow commented 7 years ago

Why not simply follow naming convention from OHWR, there are i.e. FMC boards names: FMC_ADC_100M_16B_4CHA, FMC_DAC_250M_DDS, FMC_LVDS_32... I don't have to check their names because they are self-explainable. Maybe they are not so nice to pronounce but in engineering world it just works.

dhslichter commented 7 years ago

This needs to be written and decided by those who will most likely fund the boards.

The final version, sure. But we should think about what the needs would likely be so we can make sure the Sayma supplies the appropriate plumbing for what is most likely necessary.

Claiming that the current specification is outdated does not invalidate it. In what way is it outdated?

The DACs and ADCs are now connected to the same mezzanine card, not separate mezzanine cards. Thus the mezzanines are now linear combinations of the existing designs, perhaps with some additional modifications required (e.g. integrated LO for up/downconverting cards).

Since actual thought went into it, references to the current spec and a rationale why things were changed/moved/altered would be most welcome.

The current spec assumes separate mezzanines for DAC and ADC. This was changed for a combined DAC/ADC mezzanine architecture for mechanical/physical footprint reasons -- it was too difficult to fit separate DAC and ADC mezzanines in with all necessary connectors, clearances, etc. Specifically, the best design I came up with required the ADC signals to come single-ended from mezzanine onto Sayma, and greatly reduced the available real estate on the ADC card. See attached for my draft design. We can still discuss if it makes more sense to try to go back to this, but @gkasprow will probably have plenty to say on this front. RTM_DAC_w_daughtercards_mockup.pdf RTM_DAC_w_daughtercards_mockup.zip

I am one of the people who put substantial "actual thought" into the original spec, and I am not suggesting that we fully disregard it. It just needs to be modified to account for combined DAC/ADC mezzanines, and that entails making decisions about what combinations make sense to support, etc.

The problem with the input-output mezzanines is that pretty much every input configuration is useful with every output configuration. I have a hard time coming up with reasons to cull that matrix. And saying "then use channels from the adjacent mezzanine" is not really helping either.

Agreed. I would much rather be able to do the mezzanines separately, and this is in fact the reason we designed it the other way in the first place -- you don't have to make these ugly kinds of choices. You may recall that for a time we were discussing the idea of being able to alter the number of DACs and ADCs on each Sayma, for even greater flexibility (this idea did not pan out for a variety of well-considered reasons). But here we are. If we decide that the pain is so great from choosing among the matrix of combinations that we prefer the pain of board real-estate madness, that's where we go.

We do need identifiers. That's not something for later or something optional. Using names that are not intended to last, names that are explicitly chosen to be discarded, or placeholder names for other names seems weird.

Agreed, we need identifiers. By "placeholder", I meant "for the next day or two until we sort things out and assign names", not "these will slowly become accepted until they are the actual names". I thought that naming cards Curly, Larry, and Moe would provide additional impetus to change the names to something permanent on a more rapid timescale. My main point was that right now, there exists a specification (which I have called outdated), and that specification contains identifiers tied to specific board designs. If I start reusing those identifiers to refer to new board designs, a shit show will ensue. Therefore, I need a second set of temporary identifiers for the "new" board designs until those can be settled, at which point we can either a) deprecate the old designs and migrate their identifiers to refer to new designs or b) come up with entirely new identifiers for the new designs. I didn't want to impose some set of permanent identifiers by fiat, because I knew that there might be strong feelings on the subject (as, indeed, there appear to be).

dtcallcock commented 7 years ago

The problem with the input-output mezzanines is that pretty much every input configuration is useful with every output configuration. I have a hard time coming up with reasons to cull that matrix.

I agree. For the configurations that don't involve an LO (Curly, Larry & Besser) is there any reason we can't have all the input/output options compatible with each other? Then you get to choose your combination by just sending the desired front and back files to the boardhouse.

As for names, me, Shaun, and Raghu all agree that we should name them after obscure cricket terminology. Mine's a 'Googly'.

dhslichter commented 7 years ago

Not quite this simple because of the multitude of ground vias that will need to be placed on these boards, but yes, probably we will just end up with a few more designs than we had originally thought would be needed, and if we can reuse layouts between designs to some degree that would help control cost.

dhslichter commented 7 years ago

Claiming that the current specification is outdated does not invalidate it. In what way is it outdated?

@jordens if you read the entire first paragraph of the first post of this issue, you will see my reasons for claiming the spec was outdated. Not invalid, outdated.

dtcallcock commented 7 years ago

Not quite this simple because of the multitude of ground vias that will need to be placed on these boards.

If the central copper of the 4-layer stack was solid ground (in the area of the board to be changed between designs) with blind vias from either side then that would work. It would add to cost and add design constraints though so it may well be preferable to just tweak the combinations manually to work together as needed like @dhslichter proposes.

dtcallcock commented 7 years ago

"Moe"... upconverting/downconverting card for driving microwave transitions above ~3.6 GHz (Yb+, superconducting qubits) and reading back modulated microwave readout signals (e.g. for superconducting qubit readout)

I think with ions there is not usually much call for downconversion so an upconverting card with one of the other input options (as desired) might be preferable. Probably the Yb+ people should weigh in here.

Alternatively could we add the option of an x2 or x4 multiplier to "Larry" so he can cover all ion qubit frequencies (except Hg+, but that's only for the hardcore anyway)?

"Curly" baseband ... output frequency 100 kHz - 500 MHz

Is there any reason to not have this card go to 2GHz? I would still expect <500MHz to be the normal operating regime for the obvious reasons, but it doesn't seem there's a need to limit it to that with our component choices (other than user-replaceable band-defining filters).

See #30 for more info but I think 100kHz might be annoyingly low, especially with regards to the differential-single-ended balun and DC-blocking caps. Would 1MHz be a problem if "Besser" is available with a 10MHz output?

jordens commented 7 years ago

@dhslichter I read that. Your approach seems to be to paint it and then to hijack and discard it. I think it is preferable to be able to track and retrace the changes made and would like to ask for more willingness to amend and evolve the specification.

dhslichter commented 7 years ago

@jordens it was not my intention to hijack and discard, I'm sorry if it came off that way. It would be nice to track and retrace changes made (thus trying to post as an issue to get us started), and my intent was to modify/regroup rather than destroy the existing specification. I decided to post the issue here rather than to the artiq-hardware repository because it's relevant to the Sayma design now. I should have perhaps been more explicit in saying that the mezzanines I proposed as a "straw man" are really just based on linear combinations of the existing input and output designs, with some modifications added in based on discussions that have been ongoing in other Github issues and post-date the last time the specification document was touched (have not been included in that document yet).

hartytp commented 7 years ago

I have two output stages in mind to cover our use-cases:

  1. Direct output

    • ~10MHz to ~3.6GHz (with suitable population options), no upconversion/multiplication

    • uses: driving AOMs up to 200MHz; generating microwaves to 3.2GHz for cases that don't require ultra-low phase noise (using the AD9154 in mixer mode)
    • This is covered by the NIST "Curly" design
  2. Upconverting output
    • Ultra-low phase noise microwaves at ~3GHz, with ~150MHz IF bandwidth
    • Uses TBD IQ mixer (LO generated by PLL on clock mezzanine??)
    • 1 microwave output per DAC channel, I & Q provided using SMT baseband quadrature hybrid
    • Otherwise the same as (1).

Ideally, these can both be the same PCB with different population options/0R jumpers to bypass the mixers.

The only input stage I anticipate needing is the DC coupled <10MHz InAmp stage.

jmizrahi commented 7 years ago

The direct output card is called out as having a 3rd order Butterworth 300 MHz low pass filter, intended for driving ~200 MHz AOMs. If the board is to accommodate higher frequencies, the filter will have to be laid out in such a way that other corner frequencies, or no filter at all, can be created with other component choices, without affecting the impedance. This seems like it could be tricky.

dhslichter commented 7 years ago

Actually it's very simple -- discrete component filter synthesis is incredibly straightforward at these frequencies. Also, what is the reason for specifying a 300 MHz cutoff? Presumably your AOM bandwidth is <100 MHz, so that effectively filters all the electrical inputs outside that bandwidth around your AOM center frequency. You could probably get away with using a higher cutoff (e.g. 500 MHz, to eliminate Nyquist images -- which you could also already do by running the DACs at 2x interpolation mode) and then the boards would be useful to all those folks with 330 MHz AOMs without repopulating filters.

The more I think about it, the more it seems to make sense for NIST applications to use external filters that are easily reconfigurable for band-defining applications for most applications. If we provide footprints for discrete component filters on the board and then enable the user to choose how they are stuffed, including no filter, then this option is available. This is less doable with the FV1206-type mini-circuits surface mount filters.

jmizrahi commented 7 years ago

@dhslichter at 300 MHz, yes, but if you want it to also work at 3 GHz with the same pads, I was under the impression this was trickier, in terms of getting the impedance correct. But, perhaps I'm wrong.

While it's true that a 200 MHz AOM rejects signals outside its bandwidth, the higher frequency signals are still passed to the amplifier, which is not ideal, and moreover are reflected back to the amplifier. Because our application for these boards is aimed specifically at 200 MHz AOMs, it makes sense to filter out frequencies above its bandwidth, hence the specification for a 300 MHz corner.

By "external filters," do you mean external to the mezzanine? I think of the mezzanine board as already being the external filter.

dhslichter commented 7 years ago

By "external filter" I mean external to the RTM -- a minicircuits SMA filter on the output line.

In terms of the frequency capability, it depends on the pad layout and component size/performance selection. It is possible to design a filter in such a way that the copper layout just looks like CPWG with interruptions in the center conductor; a judicious choice of components (including high-frequency-capable shorts) can allow it to work up to 3 GHz frequencies.

dhslichter commented 7 years ago

I think we should put in a discrete component band defining filter as planned, populate with components for the specified 300 MHz cutoff, design it so that components can be chosen to make that cutoff higher as desired, and then if it doesn't work all the way to 3.6 GHz we make a slightly modified version of the mezzanine board that uses e.g. minicircuits surface mount filters capable of going to high enough frequency.

hartytp commented 7 years ago

AFAICT, this issue is now outdated and stale. Closing.