Maybe we should come back to the roots:) What if we use standard FMCs (LPC) with DAC/ADC channels and RF stuff _on_ them. JESD204B and some pins would go to the FPGA while DAC and RF clock would be fed externally. In this way we leave general purpose AMC board and define its functionality by FMC boards If we make 3 flavours of FMCs: ADC+ADC, ADC+DAC,DAC+DAC, we would cover several use cases: Quad ADC, quad DAC, 1xADC 3xDAC, 3xADC 1xDAC. FMCs with only DAC and RF stuff on it can be simple, 4 layer boards with external sield. Look at this shield (my project) http://www.ohwr.org/projects/fmc-adc-130m-16b-4cha/wiki In this way we could use existing AFCK for quick tests
-----Original Message----- From: Slichter, Daniel H. (Fed) [mailto:daniel.slich...@nist.gov] Sent: Wednesday, March 30, 2016 5:46 PM To: Leibrandt, David R. (Fed) <david.leibra...@nist.gov>; Sébastien Bourdeauducq <s...@m-labs.hk>; Grzegorz Kasprowicz <kaspr...@gmail.com> Cc: 'Grzegorz Kasprowicz' <gkasp...@elka.pw.edu.pl>; artiq@lists.m-labs.hk Subject: RE: [ARTIQ] FW: initial specification of the project > I like this plan. I think 4 + 4 channels will also make the front > panel connector density more reasonable. What are you thinking for > number of daughter cards? I suppose that more would give us more > flexibility, but less would be more economical in terms of cost and > layout area. Perhaps two daughter cards would be reasonable: one for > all of the inputs and one for all of the outputs? Agreed that ~ 8 front panel SMA connections, plus one clock SMA connection, is about what one can tolerate in a reasonable way in terms of physical footprint. If we split this as 4 DAC + 4 ADC, it makes a nice symmetry although my suspicion is that most applications would prefer something more asymmetric with a few more DAC channels than ADC channels (6 DAC/2 ADC or 6 DAC/4 ADC, for example). One could go a simple as 4 DAC/2 ADC and make the space requirements even simpler to fulfill on the cards. All of these modifications will increase the price per channel, even though we may be able to save on FPGA costs. For example, if we do 4 DAC/2 ADC on a card with 1x AD9154 and 1x ADC16DX370 (our currently planned parts), we only need 10 GTX transceivers on the FPGA. With 4 DAC/4 ADC, this would be 12 GTX transceivers. With these numbers we could look at the ZU5EV Zynq Ultrascale, instead of the ZU9EG, which we had been discussing. To Greg's question on the RTM, we have had a number of extensive internal discussions about pros and cons of RTM and it seems that we don't want to pursue this avenue for a number of carefully considered reasons. Let's just take it as a given that we will need to put everything on the AMC card or its analog daughtercards. As stated, the DAC and ADC chips themselves will be on the AMC card, not the analog daughtercards. I am in favor of separate analog daughtercards for the inputs and the outputs, this seems sensible. > On Tuesday, 29 March 2016 11:55:19 PM HKT Grzegorz Kasprowicz wrote: > > - they can be used immediately with existing OSHW carriers like AFC/AFCK. > > AFCK may be overkill. We are still working on evaluating the FPGA > resource requirements. > > > - it could be hard to fit FPGA, supply, DACs and several RF modules, > > all on single dual width AMC, especially when shielding is required. > > RTM relaxes these constraints > > - on AMC+RTM you can place 8 ADC channels + 8 DAC channels + 8 RF > > modules. In case of single AMC board it would be hard to achieve > > such channels density. > > How about this: > * we reduce the number of channels per AMC to 4 DACs + 4 ADCs > * we can therefore use a smaller FPGA. Communication lanes to the > master board are relatively cheap if we put them on IOSERDES. > * the power density and cooling requirements are also reduced. > * for the RF daughter cards, we use a custom form factor that can use > at least > 2/3 of the AMC front panel > * connectors between the DSP card and the RF daughter card are 2mm > header and 8x SMP > * the rest of the AMC front panel used for (optional, runtime > selectable) clock input and some TTLs. _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
