Zynq Kasli

[dtcallcock]

A new Kasli based on the forthcoming v1.2 design, but with a Zynq-7000 series FPGA (2x ARM CPU) instead of an Artix-7 (no hard CPU).

This will allow the proposed Zynq version of Artiq to utilise the EEM hardware.

The proposed FPGA is the XC7Z030-3FFG676I. The reasons for choosing this FPGA (as laid out by @hartytp) are:

• Very similar (same Kintex-7 fabric) to the XC7Z045 FFG900 –2 used on the Xilinx ZX706 Evaluation Kit that will likely be used for gateware development.
• The CPUs on the 7Z030 go up to maximum 1GHz clock rate available on 7000 series Zynqs.
• Fastest speed grade to ensure we can clock the AXI bus as fast as possible. The thought is that cost sensitive users can stick with the Artix Kasli, and the main user base for Zynq Kasli will be people who don’t mind paying an extra $50 to get the fastest FPGA.
• The design costs + risks will be much lower if we use a Zync model that @gkasprow has used in previous designs. He's used this FPGA before.
• It has enough pins to drive all 12 EEM connectors + WR oscillators

SDRAM would be routed to the ARM subsystem only. The gateware will still have DMA access based on tests carried out by @cjbe, where he found that:

I have tested DMA from PL to PS-SDRAM via the HP ports, and indeed it works without any problems, and one gets the advertised bandwidth.

I am working on getting this board funded and would appreciate any input.

Also, is 'Zynq Kasli' a confusing name? Do we need to dust off our Russian maps and come up with something more unique?

[dhslichter]

LVDS has still the same voltage levels in 1.8, 2.5 and 3.3V systems.

Yes, but the common-mode voltage will be different, and some devices (not all) are not happy to receive a common-mode voltage other than 1.25V, for example. The point is just that it's not necessarily straightforward.

[sbourdeauducq]

the common-mode voltage will be different

Really? AFAIK a LVDS transmitter is always supposed to use 1.2V as common-mode voltage.

[dhslichter]

LVDS is (in theory, in the standard) supposed to allow for variation in the common-mode voltage. Depending what what you are transmitting to/from, different ways of implementing the common-mode voltage are used, and most of them are mid-supply basically. Looking at the Zynq US+ dc characteristics, it seems they do use a 1.25 V nominal common mode for both, so that should be manageable.

[gkasprow]

True, some devices may have other common-mode voltage, but usually on their inputs. On the outputs it must be 1.25V, otherwise, it's not LVDS. But some LVDS drivers may exhibit non-standard behavior when both inputs are held low - both outputs get tied to 3.3V. But in such case, 2.5V supply won't help either.

[gkasprow]

The specification of the controller is on the way.

[hartytp]

@gkasprow are you suggesting that we should use that board as the main Zynq Kasli for Sinara? If so, can you remind me the reasons it would be better for us to use that board than to make a new design that's tailored to our specifications?

There are a few things that seem non-ideal to me about that:

• Ultrascale FPGA will make it harder to port the (NIST-funded) ARTIQ-Zynq prototype to Kasli-Zynq
• I think we'd want roughly the same FP as Kasli v2.0 (inc 4 SPFs etc). (Do we need an extra SPF for the internal Ethernet connection? Or, does that just go via one of the SFPs?). Would you be relying on putting all of that on the FMC? Seems unnecessarily cumbersome
• Where would the EEM connectors go? Or, would this be CPICs only?
• Not sure about the clock tree. Also, note that the WR main TCXO is quite a bit worse than the SI549. Why not just scrap it and use the Si549 like Kasli v2.0?

[gkasprow]

@hartytp the board is funded and will be designed anyway for CERN. I'm doing my best to make it fully compatible with EEM modules in CPCIs chassis. Just in case you want to use it. We will use it for our other projects @creotech with other EEM boards, especially for EGSE systems for satellites. We have plans to provide ARTIQ support. I know that it will be some work to port it to ARTIQ. Additional 4 SFPs can be easily plugged as FMC-SFP board. There is already one SFP on board. It would be CPCIs only. We can make it possible to use both types of oscillators. If you like it, I can, later on, make a version with 5 SFPs. We will get the SoC at a very low price, a small fraction of Digikey price.

[dhslichter]

@gkasprow I still think we should just make a proper Zynq Kasli with the Zynq-7000 series, EEMs, our desired clocking, our desired FP configuration, etc, and not worry about trying to port this CERN board to ARTIQ. The savings, such as they might be, are really not worth the compromises IMHO.

[gkasprow]

What is the status of the ARTIQ port for ZynQ? I think we can design this board relatively quickly. I can assign one experienced engineer for 2 months. I can also assign one SW engineer who knows ARTIQ, but he would need some guidance. We will keep compatibility with Kasli in terms of connectors placement to be able to use the same CPCIS adapter. Any conclusion about the name? I'd like to move it to the dedicated repo.

[hartytp]

I'm happy with Kasli-Zynq or something like that to minimize confusion (basically, bill it as more of a design variant than a new design).

My vote would be to keep this as close to Kasli v2.0 as possible.

• add an RJ45 to the FP for ethernet and copy ethernet from the zc706
• maybe put USB under ethernet as in Stabilizer to make room for the RJ45
• RAM to PS only
• min-range Zynq FPGA

[sbourdeauducq]

What is the status of the ARTIQ port for ZynQ?

The key parts are demonstrated on ZC706 or Zedboard so it's looking quite good, just a lot of work to put all the software/gateware pieces together. Please stay as close as possible to the ZC706. Things like Zynq-Ultrascale in particular are dangerous.

[gkasprow]

Actually the only things that we connect outside the SoC are Ethernet chip, SDRAM, USB, UART and config memory. ARTIQ do not care about the power supply. So, if we connect the peripherals like on ZC706, there should be no issues.

[dhslichter]

Please stay as close as possible to the ZC706. Things like Zynq-Ultrascale in particular are dangerous.

I want to re-emphasize this -- there is NO reason from our standpoint to work with Zynq US at this stage. Some tens of dollars price differential per board is NOT worth the cost of the extra development/debugging time.

I think Kasli-Zynq or Kasli-ARM would be reasonable names. We might not want to use someone's copyrighted name as part of our board name though? Could do Kasli-HC (hard core) or Kasli-Z or Kasli-HP (high performance) to avoid this....

I agree that we should try to think of this board as a drop-in replacement, basically a design variant with some improved internals, for the standard Kasli. Assuming the port goes well, I imagine that many groups will want to switch over, based on discussions with others on the topic.

[gkasprow]

I'm talking about building a series 7 ZynQ board. UltraScale version is also under development, but it is covered by the CERN contract.

[gkasprow]

My student will take care of this board very soon. He will post new issues so don't be surprised.

[hartytp]

XC7Z030-3FFG676 sounds like a good choice for this.

As mentioned before, I'd ideally like to go for 4 SPF + 1 RJ45 on the front panel, copying ethernet from the zc706.

Ram to the PS only.

Other than that, stick as close to the current Kasli 2.0 design as possible.

[gkasprow]

The schematics are close to completion. Btw, @sbourdeauducq did you see this

[sbourdeauducq]

* no SD Card

We want a SD card if possible. From experience on ZC706, it might be the least troublesome way to get non-volatile storage on Zynq, and there's the easy "escape hatch" of extracting the SD card and putting it into a $5 USB adapter in case Zynq won't write to it. The PS NOR flash controller is messed up; the only thing that seems to work semi-reliably is a read-only mode where the flash contents are mapped into the CPU memory. We didn't manage to write to the flash at all - even with the official Xilinx flasher on one of the two boards we have. There may be some workarounds in some cases like re-routing the flash to GPIO and bit-banging, but it's extra trouble and development time.

[filipswit]

I'll try to fit it. It looks there is enough space above RAM but only for this kind of socket: https://www.molex.com/molex/products/part-detail/memory_card_socket/0473092651

The white line is the outline of microSD

[gkasprow]

I used a slightly higher version of this Molex connector and managed to fit the BGA chip under the SD card. You can use it as well and rotate the connector if that helps.

[sbourdeauducq]

How well does this connector hold the SD card? We'll want to ship systems with the SD card pre-installed, and carriers sometimes handle packages roughly - while they have teams whose job is to find excuses to deny claims. And just normal transportation vibrations tend to dislodge things. So our hardware should be pretty sturdy.

[gkasprow]

We used these connectors in the production of 8k pieces of LTE routers. There were several issues with these boards but it never happened that SD slipped off. Here are some photos

[jordens]

They have the standard spring loaded ratchet locking mechanism, right? There is no way they'd fall out. Get proper packaging and tie down cables properly and make sure fasteners designs are right and tightened properly.

[filipswit]

Version with SD card is on a repo.