Hi All 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. > We plan to use it anyway.
> > (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. > We used this approach some time ago in AFC/AFCK designs. But it had no failover protection. For this reason I added second FLASH that MMC can switch and do failsave recovery of communication link. The procedure was simple: MMC boots the FPGA from second FLASH and tries to estabilish communication gateware over local SPI link. WHen this fails, it switches to first FLASH and reboots FPGA. MTCA supports remote upgrade via IPMB, but it takes ~20h to write to config FLASH. Remote upgrade is not critical in case of our system, but in primary field of MTCA.4 (accelerators) when hundreds of crates are operating around the ring it makes a lot of sense. If we want to keep the scalability to the MTCA it's worth to consider such feature. So the primary update channel is JTAG connector, but this need physical presence at the site and AMC needs to be removed from the crate. Another one could be USB which we have anyway as debug UART channel (micro USB will fit on the panel). FT2232 or Silabs chips have JTAG engine supported by i.e. UrJTAG. But in case of complex system update of several boards will be time consuming. Still another channel is IPMB and this is not useful in our case. In our case, main remote update channel is over Ethernet, where FPGA programs its own FLASH by custom gateware while keeping fail-safe FLASH intact. In case of AMC boards, we consider adding Ethernet PHY to keep compatibility of AMC standard (PORT0). Together with simple open source MAC we gain communication channel over PORT0 and MCH switch. This can be used for setup, diagnistics and update. Since the PHY chip supports RGMII and MII standards and on the other side has 1000BASE-X, we can use its MII port to connect to MMC chip and in this way gain for free additional update channel where MMC can do FLASH programming, direct FPGA ocnfig, diagnistic and fail recovery functions. So the procedure would be simple: MMC diables FPGA by PROGRAM_B line, than takes control over MII interface of PHY chip. The chip does translation between 100mbit and 1Gbit link speed and in this way we can have quick access to both FLASH and all resources of the AMC board (supply currents and voltages, thermometers, ID, etc) >From Metlino board we have Ethernet connection to the MCH Tongue 1 Ethernet switch and can use it in the same manner. > > 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. > You do CPU programming once, during production. Later on it uses its own bootloader to upgrade remotely over IPMB or Ethernet. Once you estabilish communication channel, regular FPGA updates would be easy. > > 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. > In proven AFC/AFCK designs the I2C interface of sensors is connected to both MMC and FPGA so you can read the sensors from any of them. There are more interesting resources on the board that can be monitored - we have readout of all critical currents and voltages. I use Exar XRP7725 chips for power generation. They are cheap and are programmable - you can setup power-on sequence, delays, current limits, failure behaviour and monitor all power issues. > > 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). > The idea is to upgrade FLASH only at the moment. But in final production system where several AMC boards are present, it may make sense to boot all FPGAs over Ethernet at the startup from single file location. In this way it's easier to keep control over file versions. FLASH chips won't be used at all in this scenario. In complex systems we build at WUT where tens or hundreds of FPGAs are used, it is very useful feature to have all bit files in same place and all FPGAs exactly in the same state after every power cycle. So I wouldn't close such future scenario, especially that it doesn't cost even single $. Greg > > 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
