KU7 alternatives for Metlino >v1.0

[jbqubit]

In followup to meeting on 2/18 there was discussion about FPGA for a future roll of Metlino.

8. Discuss Metlino FPGA. Can we avoid Ultrascale? Or, too late in the design process? Assuming ARTIQ Zynq ports go ahead, in the long run we may wish to switch metlino to a Zynq FPGA anyway, so there is room to rethink things when we do that.

@sbourdeauducq provided analysis offline. Reproduced here with his permission.

Advantages of A7 (by decreasing importance):
* lower power supply demands and lower PI risk
* Kasli Ethernet code can be reused (NB: I have Ultrascale GTH Ethernet 
code but I'm not sure if it works; according to Florent it works on 
KCU105, but I can't get it to work on Sayma - it could be broken 
hardware since it turns out DRTIO is also flaky on that board's SFP; I 
could try another Sayma board tomorrow. My KCU105 doesn't power up anymore.)
* Kasli Grabber code can be reused (implementing CameraLink on 
Ultrascale will be a PITA)
* we get another chance at whether this bug appears or not: 
https://github.com/m-labs/artiq/issues/1230 anymore (NB: Xilinx should 
fix in the next Vivado release a related bug that I reported, this may 
or may not get it to work).
* lower power consumption
* lower cost per board

The only problem I can see from the firmware perspective is FPGA timing. 
I could check if timing is met with a 12-port DRTIO master on A7-200; 
this should be rather quick, but time/funding is very limited.

[jbqubit]

Further comment by @sbourdeauducq

Yes. But IMO that re-roll of Metlino won't happen. I get that Greg 
doesn't want to throw away most of the existing Metlino design at this 
point and use A7, and that's a respectable decision. So it will have to 
work correctly with Ultrascale. After this, the only important thing 
we'd get with A7 is Grabber support, and it's probably less work to get 
the Ultrascale I/Os to behave than redo the whole PCB (or we can just 
ignore Grabber support). Then the next version will probably be Zynq-based.