Re: [ARTIQ] plans for clock chip, JESD and DAC initialization/configuration

2016-12-16 Thread Sébastien Bourdeauducq via ARTIQ
On Saturday, December 17, 2016 12:02 PM, Sébastien Bourdeauducq via 
ARTIQ wrote:

Before DRTIO can operate, the clock chip (HMC* on Sayma and AD9516 on
KC705) needs to be running.


Strictly speaking: this is needed only for the two-KC705 system. But we 
might as well use the same scheme everywhere, and it avoids the corner 
case of operating the kernel CPU with no RTIO clock running.


The generic chip configuration code should go in firmware/libbsp.

With the RTM FPGA, SPI will have to go over the SERDES link. I'm still 
thinking about a generic "I/O expander" similar to mini-DRTIO; we can 
have half-rate, quarter-rate, etc. updates for some pins in order to 
save bandwidth.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq


[ARTIQ] plans for clock chip, JESD and DAC initialization/configuration

2016-12-16 Thread Sébastien Bourdeauducq via ARTIQ

Hi,

Before DRTIO can operate, the clock chip (HMC* on Sayma and AD9516 on 
KC705) needs to be running.


This setup should be done by the comms CPU on the DRTIO master, and the 
management CPU on a DRTIO satellite.


For initialization, the comms or management CPU would configure the 
clock chips and bring up the JESD links. The clock chip and JESD code 
currently in 
https://github.com/m-labs/artiq/blob/master/artiq/examples/phaser/startup_kernel.py 
should be moved to the Rust runtime and the Rust DRTIO satellite manager.


The SPI core would be connected to the comms CPU.

It seems desirable to alter DAC settings in the experiment. Perhaps this 
feature can be deferred. When we need it, it can be done as follows:
* the kernel CPU sends a request to the comms CPU via the mailbox. Since 
the comms CPU already knows about the DAC as it needs to initialize it, 
the request should be on a similar level of abstraction, i.e. it should 
be something like "enable mix mode" and not "write X to SPI register Y".
* if the DAC is on the local board, the comms CPU performs the SPI 
transaction.
* if the DAC is on a remote board, the comms CPU sends an auxiliary 
DRTIO packet to the relevant board, and its management CPU performs the 
SPI transaction, then sends an acknowledgement auxiliary packet back.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq


[ARTIQ] ARTIQ users meeting

2016-12-16 Thread Sébastien Bourdeauducq via ARTIQ

Hi,

The idea of organizing an in-person meeting for current and prospective 
ARTIQ users has been floating for a while. We'd like to get a 
conversation started on this topic. Some of this email is taken from 
Joe's GitHub issue #582.


* Venue? some ideas: NIST, JQI, DESY, Oxford, CERN, Warsaw University of 
Technology, Chinese University of Hong Kong.
* It would be convenient to have it before or after an existing physics 
conference (e.g. APS DAMOP 2017 is June 5-9 in Sacramento, CA)


* We need organizers taking care of logistics, publicity, conference 
program, social activities, catering.

* M-Labs can hold several tutorials/workshops.

* What would you like to see at such a conference?
* Would you present something?
* Would you attend a conference if it were on your continent? Another 
continent?


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq