License?

[caryan]

We're potentially interested in adding support for the Ultrascale GTH transceivers for use in a superconducting qubit control system but we can't work with a GPL license

[sbourdeauducq]

What is the problem with GPL?

[jordens]

@caryan We would very much welcome GTH support. We were planning to go LGPLv3+. Is that compatible with your codebase?

[caryan]

The problems with GPL are twofold:

1. It's incompatible with our contractual obligations to release code under Apache v2 or compatible.
2. It infects the entire design so we couldn't use it in a mixed open/closed design.

LGPLv3+ should be fine though. We're developing on the KCU105 and the AD9164 eval board so I'll start poking around.

[jordens]

Sounds great. Feel free to join the IRC channel. We found having an ADI guy (@larsclausen) around is very helpful. A few technicalities though:

• You are releasing your code under MPL which is more restrictive than Apache v2. MPL and Apache v2 are incompatible in that direction. Doesn't that contradict your claim?
• You can always release your changes under Apache v2 (or MPL). We would still be able to include them and distribute everything under GPL (or LGPL). There is a compatibility in that direction.
• I presume the contractual obligations are not exclusive: you can release your contributions under two licenses.

[caryan]

Different programs and/or funding sources some with different license requirements hopefully we haven't gotten ourselves too tangled.

[caryan]

Are more knowledgeable colleague (@blakejohnson can chime in if I goof up) pointed out that LGPL is tricky with firmware because it's not clear how to satisfy the "library upgrade" requirement. If we use the mlabs JESD core and a new version is released how to do we let the user "recombine or relink" to the rest of our project.

[blakejohnson]

@jordens as you noted, we have used MPL in the past when looking for a copyleft license without the "library upgrade" requirement, which seemed unacceptably onerous to satisfy with firmware.

[jordens]

@caryan @blakejohnson I assume that with "firmware" you mean "gateware". For the firmware, i.e. the code we run on the CPUs on the FPGA, LGPL 4 (d) is handled as usual. For gateware to satisfy that clause, you'd package your proprietary design as "user IP" and then "link" with the LGPL core using the standard xilinx build process. It would amount to distributing that "user IP" block, a wrapper that instantiates both and some makefiles.

[blakejohnson]

Yes, @caryan and I mean "gateware". I guess I'd point out that the Xilinx tools place a number of restrictions on proprietary IP files. For example, they do not function directly with Xilinx's block design workflow. So, in order to go down your suggested route, we'd have to accept a number of restrictions not compatible with our current gateware source code structure.

The other question is, is LGPL 4(d) important to you?

[jordens]

For your code that's under MPL/ASL this doesn't matter at all. You would easily over-comply by supplying the source. It is an inconvenience to those who can't or don't want to be at the giving end. Yes. You can't choose your tools and workflow completely freely anymore. But that's also true for firmware. LGPL 4(d) is important insofar as it is part of the "lesser" clause. As a user of your proprietary code, being able to modify jesd204b and then relink is not crucially important, but it is the only way to enable fast and independent bugfixing and exercising the freedoms that open source gives you w.r.t. jesd204b. Looking at ARTIQ being (or becoming) LGPL, clause 4(d) is crucial (at least to me) for exactly that reason. For example, I want to be able to develop ARTIQ even on products that have added a proprietary RTIO PHY (and therefore ship it as "user IP").

[jordens]

Do you consider jesd204b being LGPL a blocker for your projects?

[blakejohnson]

I am more concerned with the gateware for our next generation APS, which is proprietary, except for the parts we have already released, such as:

https://github.com/BBN-Q/VHDL-Components https://github.com/BBN-Q/APS2-Comms https://github.com/BBN-Q/APS2-TDM-Interconnect

LGPL is not a blocker, but it is a negative. Right now we are using a trial license of Xilinx's JESD204b IP core. I'm not particularly keen to give Xilinx >$5k for a full license, but in weighing the costs of using your core vs sending Xilinx some money, adding an LGPL component to our gateware may end up being the more expensive option.

[sbourdeauducq]

We can also sell you a custom license, perhaps including GTH support as well.

[sbourdeauducq]

@caryan @blakejohnson So what is your decision?

[blakejohnson]

@sbourdeauducq I'd be happy to consider that. Unfortunately, I think there would be major logistical hurdles for me to get a purchase through the Raytheon system for a Hong Kong vendor. I'll inquire, but I am not hopeful.

[caryan]

We also aren't ready to commit to JESD. There are significant latency and clock rate penalties vs. a wide LVDS DAC.

[sbourdeauducq]

Out of curiosity, what LVDS DACs are you looking at? We also considered those initially, but decided for JESD as the GSPS LVDS ones have fewer manufacturers and potentially broken proprietary inter-chip synchronization mechanisms. What clock rate penalties are you talking about?

[blakejohnson]

The e2V EV12DS400. Latency is ~1ns, which is pretty amazing. The synchronization for that part seemed pretty simple. Euvis also has a part we are interested in, but I can't remember the part number off the top of my head.

[blakejohnson]

Just to close the discussion, we ended up creating our own JESD204b module in VHDL:

https://github.com/BBN-Q/VHDL-JESD204b

It is available under the Apache v2 license.

[jbqubit]

@blakejohnson Thank you for closing the loop on this.

[sbourdeauducq]

@blakejohnson Is the transceiver code available somewhere? Also, I'm curious why you made that decision.

[caryan]

It was a couple days work to get the transmitter up and running and we would have spent more time trying to get a contract going with you folks and interfacing our sequencer with the migen/misoc stuff.

We haven't yet flipped the public switch on the KCU105 example with the wrapping the JESD module and transceivers. However, given the comments elsewhere on "discouraging the use of transceiver wizards" you may not want to look at it :grin:. We'll eventually get it working with the GTx primitives but we're still evaluating the latency. On the AD9164 we can squeeze it down to 160ns at a 12.5Gbps lane rate but that's still a big chunk of our total latency budget.

[sbourdeauducq]

However, given the comments elsewhere on "discouraging the use of transceiver wizards" you may not want to look at it .

Since parts of the transceiver are not documented, looking at what the wizard generates is sometimes the only way to get it to work.