search

m-labs / artiq

A leading-edge control system for quantum information experiments
https://m-labs.hk/artiq
GNU Lesser General Public License v3.0
422 stars 193 forks source link

ARTIQ interface for KC705 to EEM TTL breakout boards #780

Closed jbqubit closed 7 years ago

jbqubit commented 7 years ago

I'd like to begin using the 3U BNC, SMA and RJ45 EEM boards with ARTIQ. Initially this will be using a KC705. Here's the specific path I want to use.

KC705-> FMC-VHDCI adapter -> VHDCI cable -> VHDCI carrier -> IDC cable-> 3U BNC

This Issue externalized a discussion thread that was being conducted by email so everybody can participate.

@sbourdeauducq provided advice on how to get going by email:

To use those boards with ARTIQ and a KC705 I'd recommend the following:

@gkasprow provided information about how he validated the hardware using WUT tools:

I did simple test bench that takes signals from half of VHDCI connector and forwards to second half. Then I took VHDCI breakout + 4x DIO BNC boards and connected it with BNC cables. In this way I could test all features of VHDCI carrier, FMC-VHDCI, DIO BNC, DIO SMA, DIO RJ45 boards at once. The KC705 code also controls I2C tree and direction of LVDS buffers on FMC VHDCI in such way that you only specify 32bit vector and the state machine does the job.

The I2C tree is controlled using simple, open source J1B FORTH processor that takes commands from UART and executes them immediately. In this way I can either load all init commands to block RAM or play with it using console. It has more features, i.e. can measure frequency of other clocks and control IOs.

In this way I managed to quickly test all LVDS connectivity, I2c path, I2C registers, unique IDs on the PCBs.

And the question is: how to integrate such code with ARTIQ.

One can of course write functions that do SPI configuration of 3state buffers under ARTIQ, or simply reuse my code together with buffers, state machnine since it works.

On the WUT side, @marmeladapk was working on this but now it's assigned to @michallgaska and Tomasz. Please work with the M-Labs guys to develop this interface.

jbqubit commented 7 years ago

This gist contains the test code by @gkasprow. https://gist.github.com/jbqubit/2d99dac5ed61c4a924b398da6f2c9fbb

gkasprow commented 7 years ago

@jbqubit I have much more complete code for KC705. It is here; https://www.dropbox.com/sh/8ax6ew8xyx9p7y3/AAAoJOV5Gda7PSPyF4UWOKqIa?dl=0

hartytp commented 7 years ago

On the WUT side, @marmeladapk was working on this but now it's assigned to @michallgaska and Tomasz. Please work with the M-Labs guys to develop this interface.

@jboulder Out of curiosity, what's the WUT involvement in this? I thought that now these boards have been thoroughly tested by WUT, this would be handed over to M-Labs to write the interface. Do M-Labs need more than the schematics for this?

jbqubit commented 7 years ago

In parallel with the EEM hardware testing, a WUT student (@marmeladapk ) was working on writing ARTIQ drivers back in June. But there wasn't much progress. I posted the discussion in this Issue to externalize the discussion. Agreed the most efficient approach at this point is for M-Labs to write the interface.

hartytp commented 7 years ago

@jbqubit Okay, that makes sense.

Back in June, before these EEMs had been tested by WUT, it made sense for WUT to consider writing ARTIQ drivers to use for their testing. But, now that these boards have been tested, I don't think that makes sense any more.

Given how much work needs to be done to finish designing and testing the boards that have been funded, it might make sense for WUT to focus on hardware and leave the drivers to M-Labs.

jbqubit commented 7 years ago

I agree with @hartytp. Division of labor is the fastest way forward.

jbqubit commented 7 years ago

These are simple board but there's more to it than wire mapping. Also needs configuration via rust.

hartytp commented 7 years ago

@jbqubit IIRC, the I2C on the BNC board is only for direction readout, not for direction control.

AFAICT, I2C isn't required for the basic functionality of any of these boards -- although it is nice to have if implemented properly (e.g. auto-detection of IO direction would be great!). What I'm not clear on is whether the current M-Labs contract covers getting that up and running...

sbourdeauducq commented 7 years ago

Via rust?

gkasprow commented 7 years ago

These I2C chips are used to either read switch positions or set directions when switches are off. They are very simple to read - have just one register. EEPROMs have unique ID and of course array that can be written with some content, at least name. We can follow FMC convention - here is tool I use to build FMC EEPROM contents https://www.opalkelly.com/tools/fmceepromgenerator/

gkasprow commented 7 years ago

@hartytp These extenders have open drain output ('8051 style) so can be used for both purposes

jbqubit commented 7 years ago

ICs are now configured using runtime, right? Won't that be true for 3U boards too? For example, artiq/firmware/libboard/ad9154.rs

jbqubit commented 7 years ago

Here's a stab at this. @sbourdeauducq Please critique the following outline of a commit. @gkasprow Please supply the pin mappings for KC705 LPC.

https://gist.github.com/jbqubit/c37574ed2b4daf4f7d05eba7a171d355

sbourdeauducq commented 7 years ago

We'd rather not merge it because we don't want to maintain KC705+EEM support and especially not mix it with the phaser target, but it looks fine for your local tests.

sbourdeauducq commented 7 years ago

And you can reference FMC pins in Migen, see how it's done in nist_qc2.py.

sbourdeauducq commented 7 years ago

Only some ICs are configured by the runtime; for those on the EEM boards, kernels are perfectly fine.

gkasprow commented 7 years ago

@jbqubit the pin mapping is here

jbqubit commented 7 years ago

Can you give me a hand? See attached for the patch of what I've got. I'm modifying the phaser build for kc705 as a starting point. Several observations.

https://gist.github.com/jbqubit/a8826061c7593b53bf291c33d5d3a137

sbourdeauducq commented 7 years ago

Am I correct in assuming ttl_serdes_7series.Output_8X(pads.p, pads.n) combines pads.p and pads.n into a single RTIO channel with differential signaling?

Yes.

What's the right structure for the the platform extension file fmc_lpc_to_vhdci_breakout_io.py? I'd like to indicate differential signaling.

See I/O entries elsewhere that also use differential signaling.

jbqubit commented 7 years ago

See I/O entries elsewhere that also use differential signaling. I'm following ```gateware/ad9154_fmc_ebz.py ````

As a simple test I setup sma_ttl to be differential on KC705. When I compile, load the bit file and toggle the ttl I only see transitions on USER_GPIO_N. Here are the modifications I'm making -- see also gist above. 

    ("sma_ttl_diff", 0,
     Subsignal("p", Pins("Y23")),
     Subsignal("n", Pins("Y24")),
     IOStandard("LVDS_25"), Misc("DIFF_TERM=TRUE")
     ),
        pads = platform.request("sma_ttl_diff", 0)
        phy = ttl_serdes_7series.Output_8X(pads.p, pads.n)
        self.submodules += phy
        rtio_channels.append(rtio.Channel.from_phy(phy, ififo_depth=128))

What am I doing wrong?

sbourdeauducq commented 7 years ago

Are you writing to the correct RTIO channel number?

jbqubit commented 7 years ago

PHYs "lpc_vhdci_ext0" 0 to 7 don't register properly as RTIO channels. That is "sma_ttl_diff" and "user_led" are RTIO 0 and 1.

The RTIO channel numbers do not increment as I would expect. I have to write to a different RTIO channel number than I'd expect.

jbqubit commented 7 years ago

I pushed to a jbqubit fork of ARTIQ. It makes for easier-to-read source. This is what I'm using. Also, I don't see differential pulsing of sma_ttl_diff.

https://github.com/m-labs/artiq/compare/master...jbqubit:vhdci

jbqubit commented 7 years ago

@sbourdeauducq Please comment on the fork. I'd like to get this working in the lab.

sbourdeauducq commented 7 years ago

Do the usual debugging. Check your cables and measure the signals at different points. Connect something else than that RTIO PHY (e.g. the MSB of a counter that increments at every cycle, plus OBUFDS) to check that the FPGA itself can toggle logic levels where you want. Double-check RTIO channel numbers.

jbqubit commented 7 years ago

OK. I can now differential toggle sma_gpio_p and sma_gpio_n. https://github.com/jbqubit/artiq/commits/vhdci_play

@gkasprow It looks like the I/O direction choosing IC on fmc-vhdci adapter has an ill defined power-on state. This is SN74LV595APWT. Is that right? Working now on figuring out how to initialize it for all-output.

hartytp commented 7 years ago

@gkasprow It looks like the I/O direction choosing IC on fmc-vhdci adapter has an ill defined power-on state. This is SN74LV595APWT. Is that right? Working now on figuring out how to initialize it for all-output.

Related question:

jbqubit commented 7 years ago

I can now successfully drive output on 3U BNC. Thanks to @npisenti for help playing with the SN74LV595APWT. It's not a full driver but enough to get basic stuff working the lab. See the following commit.

https://github.com/jbqubit/artiq/commit/58f0b9bd3f25d991748396926ebd520823c91fdc

gkasprow commented 7 years ago

@jbqubit The PCF8574 has open drain outputs with weak pullup so it does not interfere with DIP switches. It means that when DIP switch is open, you can always change the line low. You can always read DIP switch position by reading the PCF8574. Switches and PCF chip realize wired and function. So to summarize, you don't have to touch PCF chip if you don't use it. You can use it to change direction, in this mode all DIP switches must be in off position to not interfere with I2C control.

hartytp commented 7 years ago

@gkasprow Understood.

My question was more: do ARTIQ users (e.g. @jbqubit) plan to use the PCF8574 instead of the DIP switch to set the direction control? Or, will they just use it for direction read-out? If they plan to use it for direction control, how do they intend to initialise it to avoid sequencing issues?

jbqubit commented 7 years ago

SN74LV595APWT on FMC-VHDCI adapter requires bit-setting for input/output configuration.

PCF8574ADW direction-setting via I2C is desired but not required. It doesn't take long before the snarl of cables in a typical lab makes it inconvenient to add/remove cards to set dip switches.

npisenti commented 7 years ago

An additional caveat here too that @jbqubit and I realized today is if you're using KC705 + fmc adapters, you'll also have to synchronize the lvds buffer directionality on the fmc -> vhdci boards. This is potentially more problematic (unless I've misread the data sheet), since they are set via shift register with a global latch which might mean undesirable directionality on other i/o lines during the reprogramming.

Only speaking for myself, we're fine keeping ttl directionality fixed at boot (i.e., use the DIP switches + startup kernel to configure fmc -> vhdci rx/tx).

gkasprow commented 7 years ago

I managed to make design for KC705 where direction can be changed at any time. Don't worry about direction - LVDS standard don't care if you connect outputs together since it is current source.