Re: [ARTIQ] sayma gateware updates
On Sunday, July 24, 2016 11:27 AM, Sébastien Bourdeauducq wrote: It is reasonable to use the same approach to (a) and (c) on metlino_motherboard? I suggest (a) and (b) on all boards. (c) involves gadgetry. And by "all boards" I also mean Kasli, which (c) would not support. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Fwd: proposed uTCA hardware for ARTIQ; Sayma, Metlino, Kasli and friends
Based on feedback from m-labs, Greg at Warsaw Technical University (WUT) and ARTIQ users I've updated the microTCA hardware plan. Here's a recap of the changes. ## ### Changes to sayma_motherboard 1) An UltraScale Kintex FPGA will be used in lieu of Kintex7. The change is motivated by the need for 2 serial transceivers per DAC channel on the sayma_motherboard -- I had neglected to account for 8b/10b encoding. Thanks to AOSense for pointing this out! * XCKU040-1FFVA1156C * 485k CLB FF, 242k CLB LUT * 20 GTH, 12.5 Gb/s * 520 user IO (excluding GTH) + -1C speed grade is sufficient to max out the AD9154 transceiver rate (10.96 Gb/s) + provides transceiver resources to drive 8 DAC channels sampled at 1096 MSPS + is a 20% increase in available FPGA resources (relative to Kintex-7 325T) + adds 30% to FPGA cost at single unit quantities (relative to Kintex-7 325T) + VA1156C package has a long upgrade path list including UltraScale + chips which are pin compatible. It is the minimal package which supports 20 transceivers. + Xilinx KCU105 will be used for prototyping the gateware which has 8 GTH transceivers on the HPC FMC. 2) DRAM switch from DDR3 to DDR4 to match KCU105 protoboard. 3) Increased FPGA IO count enables RTM connectors to be fully populated with 54 differential pairs. This permits future RTM applications. 4) Replace Atxmega128A1U-AU with ARM Cortex M3. + This is the microTCA IPMI CPU that implements IPMB-L. + Open source microTCA MMC works on M3. 5) It is desirable to have an on-board mechanism for generating the 2.4 GHz DAC clock. It is anticipated that doing this with very low phase noise and small temperature coefficient is challenging. To mitigate this risk the DAC clock electronics will appear on a daughter board named sayma_clk. Two variants of sayma_clk will be produced (with same form factor). + sayma_clk_approach_2 :: A low risk clock generator. It accepts a physicist-generated 2.4 GHz sinusoid from a front-panel SMA and provides a suitable driver for the differential DAC CLK+ and CLK-. + sayma_clk_approach_1 :: A is higher risk clock generator led by Oxford. As reference it uses the uTCA backplane CLK3 at 100 MHz to generate phase-locked 2.4 GHz DAC and 100 MHz ADC clocks. ## ### Changes to metlino_motherboard 1) An UltraScale Kintex FPGA will be used in lieu of Kintex7. This change is made to match the FPGA family and transceiver type (GTH) used for the sayma_motherboard. * XCKU040-1FFVA1156C + Xilinx KCU105 will be used for prototyping the gateware which has 8 GTH transceivers on the HPC FMC. + XCKU040 has 20 GTH transceivers (relative to 24 GTX on Kintex-7 325T). Since 16 GTH are needed for DRTIO with AMC modules (eg sayma_motherboard), only 8 GTH remain for SFP connectors. 4 GTH will be front-facing, 4 GTH will be exposed on the RTM. + VA1156C package has a long upgrade path list including UltraScale + chips which are pin compatible. It is the minimal package which supports 20 transceivers. + Xilinx KCU105 will be used for prototyping the gateware. 2) DRAM switch from DDR3 to DDR4 to match KCU105 protoboard. 3) Increased FPGA IO count enables RTM connectors to be fully populated with 54 differential pairs. This permits future RTM applications. 4) Replace Atxmega128A1U-AU with ARM Cortex M3. + This is the microTCA IPMI CPU that implements IPMB-L. + Open source microTCA MMC works on M3. ## ### Changes to kasli Kasli is an integral part of the ARTIQ hardware plan but hardware development won't start until Q4 2016. > Below is a link to the google docs spreadsheet discussing the hardware > details. Please use the mailing list for comments, questions and > suggestions on how to improve things. Refer to spreadsheet tabs by > name so we all are on the same page about which subsystem is being > discussed. > > https://docs.google.com/spreadsheets/d/1mkg7u-MaYnXeptUxOmuWZalwc4X5r3Jy-z8v8w91Q00/edit?usp=sharing -Joe ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] sayma gateware updates
Hi, On Sunday, July 24, 2016 07:59 AM, j arl wrote: The bitfiles for the sayma_motherboard FPGA will be stored in flash. We've discussed several ways of updating the bitfiles. a) serial JTAG b) DRTIO over microTCA Port4 c) Ethernet microTCA Port0. Update method (a) is implemented by a directly connecting a serial cable to the board. This is well suited to factory debug and loading the initial bitfiles. However, it's not convenient for in-field upgrades. For this technique, one could also build the JTAG adapter into the board - use a FT2232H chip and have a small USB connector on the front panel. (b) and (c) permit in-field upgrades without external connectors. What implementation of (b) does m-labs have in mind for sayma? Since it's DRTIO it involves the Port4 GTH from metlino_motherboard. The PC sends bitfiles to the root Metlino over the Metlino's front panel Ethernet connector (the same used in regular operation of the system). The Metlino receives its own bitfile from there, and distributes the other bitfiles to the whole DRTIO system using the existing communications links (fiber/backplane). When receiving a bitfile, a board (Metlino/Sayma) writes it to its flash memory (via a SPI master core inside the FPGA) and then reboots (using ICAP) to load the new bitfile. Greg advocates for use of ARM Cortex M3 (LPC1700 family from NXP) to implement the microTCA MMC functionality (IPMI). This is gadgetry that solves no real problem. And how do you program the microcontroller? It's not easier than loading a FPGA bitfile. If you want temperature sensors (the only arguably useful monitoring feature IMO) I suggest connecting them to the FPGA and reading them out over DRTIO. The FPGA already contains one built-in temperature sensor, and an ADC with additional external channels. Greg points out that the M3 has a built-in MAC. If this were connected to Port0 the MMC could be reconfigured over Ethernet. The M3 could also be connected to the FGPA to permit loading of bitfiles. I would not bother with this and also with Ethernet inside the crate. The built-in FPGA configuration mechanisms are good enough and do not require additional hardware. This would enable (c). Xilinx's recommended implementation is discussed in "Figure 3-2: Slave Serial Mode Configuration Interface Example" of the UltraScale Architecture Configuration guide. It seems (b) and (c) are not mutually exclusive. The microcontroller would have to be connected and programmed to drive the Mx pins of the FPGA to switch between the two modes - serial flash for (b) and slave serial for (c). It is reasonable to use the same approach to (a) and (c) on metlino_motherboard? I suggest (a) and (b) on all boards. (c) involves gadgetry. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] request for testers
Hello, we expect to publish the first release candidate for the ARTIQ 2.0 release soon. There are a few issues scheduled to be resolved (https://github.com/m-labs/artiq/milestone/2) before 2.0rc1 but there is currently nothing on the radar that implies a critical bug or involves a major change to resolve. We consider the current state of the master branch usable in the laboratory and would like to invite testers to give it a run and report issues. Changes relative to previous versions (1.X) that require user attention are described in the release notes: https://github.com/m-labs/artiq/blob/master/RELEASE_NOTES.rst The master brach is regularly published as packages in the `dev` Anaconda label. The current installation instructions for the master branch are at: https://m-labs.hk/artiq/manual-master/installing.html Check your device database and experiments against the examples in the manual or the unittests. For example, the introduction of seamless hand-over between experiments requires the use of `core.reset()` to recover from previous experiments having saturated the FIFOs or having advanced the timeline far into the future. As a reminder, when switching between ARTIQ versions or when upgrading, you should generally follow the installation instructions again (unless you know better). You will generally also have to recompile and reflash the idle kernel if you are using one. Regards, Robert for the ARTIQ team ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
