On Friday, 25 March 2016 12:24:02 PM HKT you wrote: > * whether or not we use Zynq remains to be decided. > **The price difference is not that high (a few tens of $) and we get > plenty of CPU power
Yes, but Zynq chips are annoying to program (even if we do not use the ARM cores) and more proprietary. The question is really whether the Zynq architecture has technical benefits to the end application that justify the trouble. The answer is not straightforward, e.g. CPU power doesn't translate linearly to latency reductions. [GK] If you don't use ARM, you still get hardened SDRAM controller and GBE MACs. Maybe we should do a quick experiment and map the ARTIQ RTIO core in the address space of a Zynq device, and compile (with just gcc or clang, not the ARTIQ compiler) the equivalent of the current runtime+kernel system that measures the maximum pulse rate. Then we have hard numbers to discuss. [GK]For time critical apps, one can program these CPUs bare metal. We did it in our projects. > * transceivers on the backplane are acceptable but not necessary; > since we have multiple signals we can transmit a clock and use the > regular IOSERDES to lower FPGA requirements. > **Well, IOSERDES can go up to 1.2Gbit n synchronous mode. > **GTH can go 12Gbit/s easily > **Are you sure you want to relay only on IOSERDES? Yes, I think they would be sufficient. The bulk of the data will be processed locally on-the-fly by the AMC cards, and a couple Gbps (I suppose we can route extra pairs easily) of bandwidth should be plenty for controlling the AMCs. > * what is the other large BGA chip on the MCH rendering? Is it the > Macom > M21048 48x48 crossbar? Let's not use such a device, which looks > unnecessary, complicated, and very proprietary. There isn't even a > public datasheet for it. > We do not need direct communication between the AMCs. > > **At the moment not, but remember that it's going to be research > platform If we use the IOSERDES, the FPGA has plenty of IO pins to perform such direct routing (on wider buses and/or with less bandwidth) . [GK] That' true > **I can make an option with this chip not mounted. I simply see > another potential of this board and the place on the PCB does not cost > single $ since we have to use standard module **dimensions:) OK, but what about the additional routing difficulty, and any additional PCB layers? [GK] It will need 2 extra layers What is the other application you are thinking of? [GK] The other application is not related to ARTIQ project - we will need it for another project at the WUT related with GEM detectors. [GK] Generally, it is detector processing electronics > **In case of the datasheet, I got it easily after I signed the NDA. The fewer NDAs I sign, the better. And it would make the board less accessible. [GK] I understand your point. It is not compatible with Open Hardware > * we want to avoid RTMs and instead put the DAC/ADCs on the AMC card > and have analog plug-ins using the FMC form factor (see my document). > **Are you sure you would get noise performance from such setup that > satisfies you? Unless the FMC connector is particularly bad with analog signals, I think it should not be worse than the current hardware. [GK] All depends how you deliver the clock for such DAC. This is the weakest point of such solution. [GK] Is current HW fully sufficient in terms of SFDR? Greg _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
