search

sinara-hw / FMC_Shuttler

16-channel 125MS/s 16bit DAC in FMC form factor.
15 stars 4 forks source link

[RFC] New AMC: Shuttler (high-speed multi-channel DAC) #2

Closed marmeladapk closed 3 years ago

marmeladapk commented 5 years ago

From @hartytp on 2017-08-16 05:24

I've started sketching out requirements for a fast DAC to be used for ion shuttling/splitting. It's on the Wiki.

All comments welcome...

marmeladapk commented 5 years ago

From @dhslichter on 2017-08-18 17:27

Brief summary of discussion with @gkasprow @hartytp offline:

TPH additions:

marmeladapk commented 5 years ago

From @dhslichter on 2017-08-18 17:32

More people to comment: @dtcallcock @r-srinivas @dkienzler @erickson-nist @yw-nist. This is basically a uTCA-form-factor replacement for the PDQ (although more general purpose than that).

marmeladapk commented 5 years ago

From @vnegnev on 2017-08-18 18:37

Some thoughts from the ETH side.

Currently our cost per channel is very roughly $300, for 32 channels (8 PCBs) including racks, power supplies etc, so if this design will be comparable then we'd be very interested in collaborating.

I can estimate any specific specs that would be of interest when I'm back in Zurich (31st August).

marmeladapk commented 5 years ago

From @hartytp on 2017-08-18 19:08

Currently our cost per channel is very roughly $300

LTC-2000-16 is roughly $80 in quantity, so that sets a bit of a limit. The rest depends on how expensive your racks etc are. I'd expect $300 per channel to be absolutely fine (I certainly don't want it much more than this!).

Ideally it would be nice to have a version of the "Gaevo/Shuttler" PCB where we could mount several (4-8) commercial Zynq-based FPGA boards with Ethernet and enough I/O to drive multiple DACs each. Does this seem feasible? I'm open to alternatives, as long as there's a way for us to port most of our current software and firmware to the new system

If you want to do this, one option is to use the RTM FPGAs as deserialisers, controlled via gigabit links (you may want a trigger line for synchronisation) via the ERNI (AMC<=>RTM) connector. You then have a few options for how you connect your uZed eval boards to those connectors. e.g. see Greg's RTM <=> SATA adapter. You could either modify this to be a uZed carrier, or use it "as is" and connect your uZeds via SATA cables.

marmeladapk commented 5 years ago

From @hartytp on 2017-08-19 00:47

While this is fresh in my mind, I've updated the Wiki.

AFE/receiver components still need choosing.

@vnegnev We don't have much space to mount active filters near our trap, but we could make it work.

How about this: let's start by designing the differential receiver board, as described on the Wiki. Once that's done, we can estimate the power dissipation and space it will need. Based on that, we can make a decision about whether to keep it separate, or combine it with the AFE mezzanine (mezzanine option 2 on the wiki). Obviously, if we put the gain on the AFE mezzanine, we'll have to be careful about cabling, so the DACs will have to be relatively (<1m) close to the traps, which could be a problem since the power consumption of this board is quite high!

marmeladapk commented 5 years ago

From @gkasprow on 2017-08-28 17:32

@hartytp what is spec for such diff receiver board?

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 07:48

@gkasprow I'd be really interested to get input from other groups on this. Provisionally, I'd suggest:

marmeladapk commented 5 years ago

From @gkasprow on 2017-08-29 07:55

@hartytp more specs:

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 08:04

Previous comment updated.

If we fix the filter transfer function + slew rate, we fix the settling time as well. (I'm just more use to thinking about this in the frequency domain than the time domain).

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 08:07

Re bandwidth, my thinking is:

marmeladapk commented 5 years ago

From @gkasprow on 2017-08-29 12:52

@hartytp what about noise density above filter cutout?

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 12:56

marmeladapk commented 5 years ago

From @dhslichter on 2017-08-29 15:11

This attenuation at the motional frequency needs to be done with passive (not active) filtering I would imagine, for better noise performance. Also, we should be careful since the output waveforms that one wants to use will have frequency components out to the motional frequency and beyond, so we need the filter transfer functions to be voltage/temperature stable (channel-to-channel variation would be nice to control as well, but this can be calibrated if needed). Filters should be Bessel or dissipative Gaussian filters, since we care about nice time-domain properties (not just frequency-domain).

If all of this is on detachable AFE cards, we have enormous risk mitigation benefits and enable different groups to be flexible in terms of their implementation.

@gkasprow can you find a suitable AFE connector with low crosstalk (better than 80 dB at 100 MHz, ideally has good transmission out to ~1-2 GHz) for the analog signals, which can also host digital signals, so we can get away from the SMPs?

marmeladapk commented 5 years ago

From @jordens on 2017-08-29 15:22

I thought this is "detached" and not just "detachable", i.e. "the AFE is at the trap".

marmeladapk commented 5 years ago

From @dhslichter on 2017-08-29 15:44

Ah, I think there is some confusion. We have discussed both an AFE on the RTM card, as a mezzanine, and also the other option of "AFE at the trap". We should perhaps use nomenclature such as "mezzanine AFE" and "remote AFE" to distinguish? I think @hartytp is currently looking to see if we need to implement a remote AFE at all, or if a mezzanine AFE will be workable. In any event, a mezzanine AFE needs to be implemented (perhaps just low-gain ultra-low-noise diff-diff buffering stages, such as ADA4927) to allow a remote AFE -- we probably don't want to expose unprotected DAC outputs on the front panel.

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 16:39

Also, we should be careful since the output waveforms that one wants to use will have frequency components out to the motional frequency and beyond, so we need the filter transfer functions to be voltage/temperature stable (channel-to-channel variation would be nice to control as well, but this can be calibrated if needed)

If your waveforms extend to the motional frequency then noise on this DAC is going to be a real problem. Unless you intend to heavily pre-emphasise the signal to overcome attenuation in the filters? (But, with a high-order filter you'll be limited in how far you can push this due to the limited DAC output range).

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 16:41

If all of this is on detachable AFE cards, we have enormous risk mitigation benefits and enable different groups to be flexible in terms of their implementation.

Agreed. Most likely, many users will need/want their own RC populations to tailor the filter response to their motional frequencies. So, it's nice to be able to keep the RTMs people use the same, and just customise the plug-in filter boards.

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 16:46

I think @hartytp is currently looking to see if we need to implement a remote AFE at all, or if a mezzanine AFE will be workable.

My initial plan is to have both a mezzanine AFE (just a differential driver + basic passive anti-aliasing filter) and remote/receiver AFE (differential ended to single ended conversion, gain, filtering) (see Wiki for details). IMO, driving +-20V at >=1MHz into a couple of meters of unterminated cable capacitance is a recipe for disaster (in the form of drifts and other thermal issues), which motivates the decision to have the remote mezzanine. The remote/receiver AFE isn't strictly necessary in my case, but it seems nice to keep the output amps +connectors on a mezzanine to give users more flexibility.

marmeladapk commented 5 years ago

From @gkasprow on 2017-08-29 19:01

@dhslichter look at these connectors: datasheet and characterisation report

marmeladapk commented 5 years ago

From @gkasprow on 2017-08-29 19:05

another advantage of using mezzanine is freedom of front panel connector choice. Some users may be happy with SCSI as in 3U DAC, some would want fancy SAMTEC one with custom high isolation cables.

marmeladapk commented 5 years ago

From @dhslichter on 2017-08-29 19:10

If your waveforms extend to the motional frequency then noise on this DAC is going to be a real problem.

But that's what you need for diabatic transport applications. Basically you have to accept heavy filter attenuations to be able to still drive at these frequencies while suppressing the DAC noise. I am not saying that we can't have filter + pre-emphasis (that is what we need to do), my point was that if the filter transfer functions are drifting around then it screws up your pre-emphasis and everything is a disaster, thus the need for stable filter components (vs temp and voltage).

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 22:04

thus the need for stable filter components (vs temp and voltage).

ACK.

NB assuming drifts/errors come from the passives, rather than the OpAms. As each user will generally want a different filter, it's up to them to choose the passives they want, including an appropriate temp co. etc.

For the "reference design" we should probably go for something like:

How does that sound?

marmeladapk commented 5 years ago

From @dhslichter on 2017-08-29 22:10

I would assume only passive filters for those freqs and thus only passive drifts. Reference design components sound good. Probably want to put a fairly tight spec on the capacitance tolerances too, 1% maybe? This helps reduce the amount of calibration required.

marmeladapk commented 5 years ago

From @hartytp on 2017-08-29 22:15

@dhslichter I would assume only passive filters for those freqs and thus only passive drifts

Let's agree on filter performance, and then we can pick the optimum implementation. My suggestion:

marmeladapk commented 5 years ago

From @hartytp on 2017-12-20 22:32

@dhslichter and others: before we finalise our plans for Sayma AMC v2.0 is it worth thinking a bit more about our plans for shuttler?

Will Shuttler work by having a powerful FPGA on the AMC and then some cheap Artixs on the RTM? In this case, the GTX lines from the AMC would go directly to the RTM FPGAs, which would then drive the DAC LVDS lines. The RTM FPGAs are then just basically fancy SERDESs.

If that's our model, the AMC needs a beefy FPGA with lots of transceivers (due to limited number of lines between the AMC and RTM), RAM, SFPs, etc. If we go down this route, it would probably make sense to have Shuttler use Sayma AMC rather than designing a new AMC from scratch. (Edit: yes, this is effectively rolling our own JSED interface to the DACs, but there are no JSED DACs which have the channel density, DNL, sample rate, etc that we need).

If we do that, it's worth asking whether there are any changes we'd like to make to Sayma AMC to make it work well for Shuttler. e.g. is the current AMC to RTM connectivity well suited to this? (Although, the answer to that question may well be "dunno, no time to think about that right now").

Or, maybe we take a different approach to Shuttler and put the DACs on the same board as the RAM and powerful FPGAs. In which case, we don't need to worry about Sayma AMC.

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 01:43

A few thoughts on this:

  1. I'm assuming that, while the DACs can run at something like 1GSPS, we'll probably run them at a data rate equal to RTIO coarse frequency of 150MHz or so.
  2. I'm assuming that the gateware on the AMC will be a simplified version of the Sayma SAWG: only 1 tone per DAC; no DUC; no parallelized CORDICs since everything runs at the RTIO clock frequency.
  3. If it's possible given practicalities (FPGA resources/timing) we may wish to add x2/x4 interpolation on the RTM FPGA to allow the DACs to run at a multiple of the RTIO coarse frequency (data rate). This allows higher clock rate without increasing the required AMC<->RTM bandwidth.
  4. I'm assuming that Shuttler will have either 16 or 24 DACs. 32 will most likely be impractical given the amount of space on the RTM FPGA.
  5. While I'd like to hear from @jordens on this, AFAICT, it shouldn't be a problem putting 24 channels of the gateware on the AMC FPGA; this was chosen to support 8 channels of dual-tone SAWG with parallelized DUC, which is much more complex AFAICT, as well as the ADCs.
  6. Say we run the AMC to RTM links at 6GBPs (roughly the max for Artix-7 IIRC) and we want to clock the DACs at 0.15GHz. Assume (pessimistically?) 25% overhead on the communication. We can then run 2 16-bit DACs per transceiver. (I'm assuming we can use all the "Rx" lines for "Tx", since we don't need any transceivers as RX, is this correct?). We currently have 28 gigabit lines between the AMC and RTM which can be used for this. That's enough for 56 DACs.
  7. We then have plenty of extra LVDS lines between the AMC and RTM, which can be used for DRTIO, synchronisation, etc.

Anyone spot any obvious mistakes in any of that? Anything important I'm missing? If not, I can't see any obvious changes we'd need to make to Sayma AMC to use it for Shuttler...

marmeladapk commented 5 years ago

From @dhslichter on 2017-12-21 03:05

tl;dr - I think that we can probably leave Sayma AMC alone, as long as it is technically feasible to use some of the resources on its FPGA to act as a bus fanout for the DRTIO signals coming over the AMC backplane, with the notion that you then use the current AMC/RTM connectivity to pass the bus to the RTM card as well (for all intents and purposes, I want any FPGAs on the RTM card to be able to act like they are plugged in to the bus in one of the AMC backplane slots).

I prefer to think about the RTM FPGAs being themselves DRTIO devices -- in other words, do all the math on the RTM card, have the FPGAs talking to the DRTIO bus, and not have them end up as glorified SERDES for roll-your-own JESD.

For comparison to PDQ, the largest Artix 7 model (~$250-300 each at retail) has 40x the block RAM, ~20x the logic gates, and can do 240 differential I/O pairs. One could run 8-12 DACs per FPGA and there should be enough resources to duplicate the current PDQ, but have longer memory depths enabled just using block RAM (for simple start-up/porting from current PDQ code), and have enough I/O to add an external SDRAM to greatly increase waveform depth and/or to enable direct streaming from memory. Probably there would be enough to enable 2x interpolation blocks for all the channels, if desired. There is a tradeoff in power dissipation with clock rate for the DACs, and I think keeping them below ~250 MSPS is eminently reasonable. No digital upconversion needed, and frankly, 125 or 150 MSPS should be more than ample to move Nyquist images out to where they are easily filtered. We can still make all the various traces from FPGA to DACs capable of running at ~GSPS rates if people would want to repurpose things. Because the DAC chips are $80-100 each, the FPGA is not an overwhelming part of the silicon cost (at most 1/3). By contrast, the FPGA on the current Sayma AMC has only about ~1.5-2x the resources of one of these largest-size Artix 7 FPGAs. Thus one would be probably a bit more squeezed on the AMC FPGA, and then the resources have all been spoken for so there's not much room left on the FPGA to put anything useful on the FMC card if you want to.

I would rather have the AMC card be a Sayma AMC which contains a buffer or simple repeater for the DRTIO to the RTM card via the connector, but all the number crunching is then done on the RTM card in these simple FPGAs. It seems to me that instead of having an IC for this, it should be possible to implement a DRTIO bus fanout in the AMC FPGA, such that all the connectivity available for the AMC to the outside world is also passed to the RTM card as though it too were plugged in to the AMC backplane, while still allowing the AMC FPGA its usual access.

This all keeps the Sayma AMC card free for use if someone wants to put a module in the FMC and use it e.g. for fast ADCs or whatever.

In the end, I think I might want to develop essentially a "dummy" AMC card that just routes the backplane signals over the AMC/RTM connector to the RTM. One could use either this or Sayma AMC to connect up the Shuttler RTM to the rest of the world.

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 03:57

I would rather have the AMC card be a Sayma AMC which contains a buffer or simple repeater for the DRTIO to the RTM card via the connector, but all the number crunching is then done on the RTM card in these simple FPGAs

Why even have an RTM then? If you don't need a separate board with the big FPGA, RAM, etc then why not just put the whole thing, DACs and all, on the AMC and save some money?

marmeladapk commented 5 years ago

From @gkasprow on 2017-12-21 11:20

There is not much space on Sayma AMC - definitely we won't fit DACs there. What we can do is to design simple AMC without FPGA - just power supply, management, SMAs, SFPs and redirect all DRTIO links to the RTM. But this can wait because we already have Sayma AMC We could theoretically fit DACs on AMC side, but would have to get rid of SMAs, FMCs, DDR chips and leave only FPGA. But this approach requires lots of engineering. If we leave Sayma AMC as it is and modify the Sayma RTM leaving most of supply, clocking and replace FPGA with bigger one this would save us a lot of work. We would also reuse the mezzanine mechanical format.

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 14:31

@gkasprow Okay.

Well, in any case, it looks like there is nothing that we need to change on Sayma AMC, so we can shelve the rest of this discussion for a later date.

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 16:43

In the end, I think I might want to develop essentially a "dummy" AMC card that just routes the backplane signals over the AMC/RTM connector to the RTM. One could use either this or Sayma AMC to connect up the Shuttler RTM to the rest of the world.

Thoughts about this:

At that point, this new AMC is basically just Sayma AMC, but with a cheaper FPGA. So, a couple of questions arise:

  1. Would it make more sense to just use a cost-optimised version of Sayma AMC rather than designing a new AMC? AFAICT, the only real place we can save money on Sayma AMC is the FPGA (again, I'd like to hear from @gkasprow on that point). So, the main change would probably be to use a the cheapest pin-compatible FPGA. The main question then (which would need to be answered before Sayma AMC v2.0) is whether it's feasible to switch the AMC FPGA for a cheaper one. What breaks if we do that? e.g. which transceivers do we loose, and are they crucial ones?
  2. Before we do that, we should ask how much we actually stand to save by switching to a cheaper FPGA. Is it really enough money to be worth maintaining two population variants etc? The usual arguments apply here (reduced bulk-buy discounts with multiple designs, cost/hassle of stocking two products, cost of supporting/bug-fixing/designing hardware/gateware/software/documentation for two boards). So, do we just bite the bullet and accept that we should use Sayma AMC?

At the moment, Sayma AMC costs about the Same as Sayma RTM (probably more once we implement the RTM cost-saving measures we've been discussing). So, it would be good to know where this cost comes from before we make any decisions! IIRC, at least half of the cost we paid for Sayma v1.0 was NRE like getting masks printed, so the cost may be lower if we do future runs with the same design?

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 16:48

Anyway, @dhslichter while I don't particularly object to your proposal, I'm also not sure I see the benefit of making the RTM FPGAs "first-class" DRTIO devices, rather than just $10 FPGA-based SERDESs. IMHO, it seems nice to put all the RAM, clock recovery etc on the AMC FPGA and keep the RTM as close to "purely analog" as reasonably possible.

I'd be interested to hear from @sbourdeauducq / @jordens on all of this, since they will probably be the ones who actually write all the required gateware and will have a better feeling for the pros/cons of the various approaches.

marmeladapk commented 5 years ago

From @dhslichter on 2017-12-21 16:58

I think that @hartytp has arrived at the conclusion I was coming to last night with my comments, namely that Sayma AMC in its current form is probably going to be a good option, perhaps the best option, for the front of Shuttler, which should live as an RTM. We can use the AMC FPGA as a DRTIO buffer/mux for the FPGAs on the RTM card. The various LVDS and gigabit lines are already in place through the AMC/RTM connector and can be repurposed accordingly. If we don't try to worry about having the AMC FPGA calculate the data, the resources can be left available for other desired tasks potentially involving FMC cards, for example.

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 17:01

@dhslichter Right.

The various LVDS and gigabit lines are already in place through the AMC/RTM connector and can be repurposed accordingly.

Yes, so the main question for now is whether there are any changes we want to make to Sayma AMC to work for Shuttler (apart from driving its cost down!). AFAICT, the answer is "no", but I haven't really thought too much about that side of things.

marmeladapk commented 5 years ago

From @dhslichter on 2017-12-21 17:07

Anyway, @dhslichter while I don't particularly object to your proposal, I'm also not sure I see the benefit of making the RTM FPGAs "first-class" DRTIO devices, rather than just $10 FPGA-based SERDESs. IMHO, it seems nice to put all the RAM, clock recover etc on the AMC FPGA and keep the RTM as close to "purely analog" as reasonably possible.

I don't want to have to stream massive amounts of data over the RTM connector, filling up the AMC FPGA with the calculation overhead, etc. The FPGAs on the RTM should be perfectly capable of doing all of this and then we don't have to write a whole bunch of new gigabit SERDES crap for packing and unpacking data. We can use the DRTIO designs, which will be made for other devices, for the RTM FPGAs as well.

I don't know what part of your proposal makes the RTM more "purely analog" -- either way involves a massive amount of digital heavy lifting by the RTM FPGAs. It seems to me that generating a bunch of digital signals, packing them up into gigabit format, streaming them over, unpacking them, and farming them out again seems to be unnecessary if one has the resources to just do the signal generation and massively parallel output right there where it's needed.

In any event, for now the resources on Sayma AMC seem to be sufficient AFAICT for any proposed Shuttler work.

On another note, Shuttler as conceived is going to be an expensive board, and there's really no way around that. We are talking ~$3000 just in silicon cost alone. I don't see much value in trying to save a few hundred bucks on AMC FPGA cost if it means having to maintain an entire new variant.

marmeladapk commented 5 years ago

From @hartytp on 2017-12-21 17:13

I don't know what part of your proposal makes the RTM more "purely analog" -- either way involves a massive amount of digital heavy lifting by the RTM FPGAs.

I was just thinking of things like whether the RTM FPGA needs RAM (for direct sample-streaming to the DAC if we want to support that), clock recovery chips, etc. Seems we can keep the digital side of things on the RTM simpler with the SERDES approach. But, maybe I'm wrong about that.

In any case, as I said, I haven't thought too much about the digital side of things. So, my preference would be to go with whatever @jordens and @sbourdeauducq think will be easiest.

I don't see much value in trying to save a few hundred bucks on AMC FPGA cost if it means having to maintain an entire new variant.

IIRC, the current AMC FPGA costs something like $1k, so we might be able to save a bit more than that. But, I agree, probably not enough to justify having multiple population variants.

Anyway, we should have a proper cost review of Sayma AMC before v2.0 and then these things will be clearer.

marmeladapk commented 5 years ago

From @sbourdeauducq on 2017-12-22 01:24

I'd rather think about this after Sayma is thoroughly tested and works well. @hartytp if you have that much bandwidth, you can help with some of the testing and bug-fixing :)

marmeladapk commented 5 years ago

From @sbourdeauducq on 2017-12-22 01:29

https://github.com/m-labs/artiq/issues/860 for example

marmeladapk commented 5 years ago

From @hartytp on 2017-12-22 03:42

I'd rather think about this after Sayma is thoroughly tested and works well.

Sounds like a good idea.

This isn't intended as a high-priority discussion, just something we should give a little thought to before finalising plans for Sayma AMC v2.0.

m-labs/artiq#860 for example

If it's still an issue in a few weeks when I'm back in my lab then I may have time to have a look.

marmeladapk commented 5 years ago

From @jbqubit on 2018-01-12 16:53

Would it make more sense to just use a cost-optimised version of Sayma AMC rather than designing a new AMC?

We should avoid proliferation of FPGA "carrier boards" similar to Kasli and Sayma_AMC.

AFAICT, the only real place we can save money on Sayma AMC is the FPGA

Cost of these boards will drop with volume. As soon as we hit qty 50 of the same Xilinx chip open source project pricing kicks in and cost drops by 50% from $1650.

I'd rather think about this after Sayma is thoroughly tested and works well.

Agreed.

marmeladapk commented 5 years ago

From @jbqubit on 2018-01-18 20:10

Deleted name-related content and moved verbatim to #482.

marmeladapk commented 5 years ago

From @hartytp on 2018-02-01 09:21

Thinking about Sayma made me realise that I still don't fully understand the idea behind having Sampler on an RTM. @dhslichter @gkasprow maybe you can help me understand your reasoning? As far as I see it:

marmeladapk commented 5 years ago

From @dhslichter on 2018-02-01 17:10

@hartytp you mean Shuttler, not Sampler?

marmeladapk commented 5 years ago

From @dhslichter on 2018-02-01 17:11

These points are well taken and I think if it fits on an AMC card, that would probably be a good idea -- I think the RTM idea was historically based.

marmeladapk commented 5 years ago

From @hartytp on 2018-02-01 17:12

@hartytp you mean Shuttler, not Sampler?

Yes.

marmeladapk commented 5 years ago

From @hartytp on 2018-02-01 17:15

These points are well taken and I think if it fits on an AMC card, that would probably be a good idea -- I think the RTM idea was historically based.

Well, I guess my feeling is this:

Anyway, this is a decision for the future, it just crossed my mind.

marmeladapk commented 5 years ago

From @dhslichter on 2018-02-01 17:18

Let me have a think about the available area on the AMC card, etc. IIRC we can run about 10 DACs maximum per FPGA. If we do an AMC card only, and we just get 10 channels per board, that's probably fine -- certainly makes the density problem easier and gives lower power dissipation.

I think the EMC advantages of the RTM are certainly one of the points I like, but if we have two FPGAs running 20 DACs with parallel LVDS data streams I am not convinced that that won't be the dominant EMC issue anyway, no matter where the card is mounted. This is especially true with Shuttler where the signals go down to DC and are not narrowband.

marmeladapk commented 5 years ago

From @hartytp on 2018-02-01 17:30

The only other potentially nice thing about an AMC + RTM combo is that we can reuse Sayma AMC. That means we get of lot of stuff for free without having to do a redesign. All we need to do is implement the roll-your-own JESD link between the two.

Anyway, I don't have a strong preference here, just jotting things down while it's on my mind.

marmeladapk commented 5 years ago

From @gkasprow on 2018-02-01 17:32

we can try to fit 16 16 DAC channels to AMC. I have AMC FMC board design with biggest ARTIX chip that can be used as a template. So we replace FMCs with DACs, get rid of SDRAM. There are 6 HR banks that can be used for DACs. My student did simulations with Hyperlynx to check the feasibility of connecting 3 LVDS, 100R terminated DAC chips to single FPGA diff IO pin. With LVDS output this has no chance to work. With diff SSTL18 it works, we can distribute the signal in such way that 600Mbit/s looks great. This gives us 600/3 MHz sampling rate and 18 channels If we want to connect 4 DAC channels, then only BLVDS does the job. In fact these are ordinary LVCMOS channels toggled in differential way + resistive network. But still, it is possible to have correct signalling at each DAC input at 600mbps with 150MHz DAC clock. So essentially we are able to pack 24 DAC channels to such board providing that we have enough space.

marmeladapk commented 5 years ago

From @gkasprow on 2018-02-01 18:32

Anyway the board will be quite expensive. The RTM will let us pack 24 channels easily, in case of AMC we could fit 16 channels hardly but might be very difficult. Such DACs are rougly 100$/channel . So from price/channel point of view it could be similar in case of 16 channel AMC or 24 channel RTM+AMC. AMC itself gives lower latency, but we loose SDRAM or its width would have to be seriously limited to 16 bits. And of course we would have 16 or 18 DAC channels, providing that we fit them and AFE boards. If we go AMC+RTM then we leave existing SDRAM on AMC + gain FMC but serial transceiver latency will be added. And we would go for 24 channels.