[ARTIQ] 2018 ARTIQ/Sinara User Survey

[Joe Britton via ARTIQ]

Please follow the link below to access a quick poll to evaluate how
ARTIQ and Sinara is being used by the research community. The results
of the survey are public. Knowing the number, location and interests
of users helps plan future technical development, meetings and enhance
the case for continued investment in the community.

https://goo.gl/forms/L1rGz9vITyWWDgEb2

-Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] ARTIQ/Sinara, fedtech.io

[Joe Britton via ARTIQ]

In the US there are several programs that aim to take ideas
originating in gov't labs and shepherd them toward commercial use. It
looks like ARTIQ/Sinara got the attention of some of these program
managers. I've been asked to gauge interest of the ARTIQ/Sinara
community to participate in this autumn's fedtech.io program. The
program assembles small teams with expertise in business and a
specific gov't funded technology for a six-week long program. One of
the activities is market analysis by the business-folks who interview
40-50 companies, venture capital firms, universities and other gov't
agencies to explore on- and off-label uses of the tech and ascertain
market potential (US and international). See fedtech.io/faq. There's
also funding opportunities for companies and startups that's tied to
the program.

I've been asked to solicit interest among experts in ARTIQ/Sinara for
participation in the Fall fedtech.io cohort. Early in the program
there is a team-formation stage that brings together experts in the
tech and business people for the six week long program. Participants
not located in the DC area are expected to participate in-person on
the kick-off Sept 22, 23. US-citizenship is not required; there's no
restriction on foreign participation as far as I can tell. The
application process is simple but must be completed by Friday Aug 10
fedtech.io/entrepreneur-app. Travel stipends may be available to
qualified experts. This is a good opportunity for a student or postdoc
who works with ARTIQ in the lab or any of the ARTIQ developers. Direct
questions about fedtech.io to ben.solo...@fedtech.io.

Please circulate to whoever might be interested.  -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2

[Joe Britton via ARTIQ]

> It would be good to get the interpolation running, both to improve spectral
> purity and to put the hardware through its paces before we move on to the
> next design revision (I'd love to see synchronisation at max DAC clock
> rate).

I agree with @hartytp on this. Pushing digitization artifacts to
higher frequencies is really helpful.

>> drastically reduce the SAWG digital upconverter resolution to a few
>> frequencies (use the other NCOs to for fine tuning).

Fine adjustment of SAWG f0 by RTIO and local DSP is the planned path
for dynamically compensating for time-variation of the Coherent
Paladin laser repetition rate. Could the resolution of the the f0 NCO
be defined parametrically? This could enable relatively
straightforward switching between faster compile times and finer
resolution.

> - f_RTIO = 125MHz
> - f_DAC = 2GHz
> - f_data = 1GSPS (2 x interpolation)

These parameters are fine for the UMD-Duke-ARL application set. -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] We have ARTIQ RF out of Sayma!

[Joe Britton via ARTIQ]

SAWG RF output wasn't working on my builds when I last had Sayma in
hand. Good to know that its now working.

On Wed, May 23, 2018 at 9:53 PM, Sébastien Bourdeauducq <s...@m-labs.hk> wrote:
> On Thursday, May 24, 2018 02:16 AM, Joe Britton wrote:
>>
>> Has M-Labs tested SAWG on Sayma since the DRAM, Ethernet, gateware bug
>> patching in recent months?
>
>
> Sure, I did it just before sending the board to Duke two weeks ago. Why?
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] We have ARTIQ RF out of Sayma!

[Joe Britton via ARTIQ]

To clarify, by "testing SAWG" I mean looking for two-tone RF using
SAWG. Now as in Jan HMC830 isn't needed for this test.

On Wed, May 23, 2018 at 2:16 PM, Joe Britton <joe.britton@gmail.com> wrote:
> Has M-Labs tested SAWG on Sayma since the DRAM, Ethernet, gateware bug
> patching in recent months?
>
> On Tue, Jan 23, 2018 at 2:43 AM, Sébastien Bourdeauducq via ARTIQ
> <artiq@lists.m-labs.hk> wrote:
>>
>> Hi,
>>
>> We are pleased to announce that the ARTIQ SAWG is now working on the Sayma
>> board. See the attached scope screenshot!
>>
>> There are still many rough edges but we are getting there.
>>
>> Steps to reproduce:
>> 0) We assume you have a Linux machine, Linux skills, and the full ARTIQ
>> development environment installed (Vivado, Rust, etc.). We will make conda
>> packages later. See:
>> https://m-labs.hk/artiq/manual-master/developing.html
>>
>> 1) Since the HMC830 usually malfunctions, bypass it by applying the
>> attached patch to the firmware.
>>
>> 2) Compile everything:
>> ./artiq/gateware/targets/sayma_rtm.py
>> ./artiq/gateware/targets/sayma_amc.py
>> Be patient: Vivado compilation time is Ultrascaled.
>>
>> 3) Since we bypassed the HMC830, feed a 1.2GHz clock directly into the
>> DAC_CLK_P SMP connector in the RTM. Put a 50R resistor across the DAC_CLK_N
>> SMP connector. Or use a balun if you have one (but the single-ended mode is
>> explicitly supported by the clock chip).
>>
>> 4) Flash the board:
>> artiq_flash.py -t sayma_amc --srcbuild misoc_standalone_sayma_amc
>> Do not put the board into a µTCA crate, as it wouldn't get correctly
>> powered due to a work-in-progress problem. Use the ATX connector instead.
>>
>> 5) Since Ethernet doesn't work yet, the kernel will be loaded as an "idle
>> kernel" through the flash. Run:
>>
>> cd artiq/examples/sayma
>> artiq_compile repository/demo.py
>> artiq_mkfs -f idle_kernel repository/demo.elf sawg.config
>> artiq_flash -t sayma_amc -f sawg.config proxy storage start
>>
>> (We've made progress on the Ethernet front, and reception of packets now
>> works; transmission appears to be a PHY configuration problem which is being
>> investigated).
>>
>> 6) Look at the boot messages on the serial console (first FTDI non-JTAG
>> channel, 115200bps, you can use flterm from MiSoC). It should block during
>> the initialization of the AMC/RTM bridge.
>>
>> 7) Since automatic RTM FPGA loading is not implemented yet, load the RTM
>> FPGA manually with the attached OpenOCD script and:
>> openocd -f sayma_new.cfg -c "pld load 0 artiq_sayma_rtm/top.bit; exit"
>>
>> 8) Look at the serial console again. Loading the RTM FPGA should have
>> unlocked the boot process and the board should initialize the HMC7043 and
>> the DACs, run PRBS tests, and finally your kernel.
>>
>> 9) Observe RF with a scope on the two outputs of a BaseMod (Allaki) in AFE
>> Channel 1.
>> By modifying the kernel and then recompiling and flashing it as in step 5,
>> you should be able to use the other channels as well, and generate other
>> waveforms.
>>
>>
>> ___
>> ARTIQ mailing list
>> https://ssl.serverraum.org/lists/listinfo/artiq
>>
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] We have ARTIQ RF out of Sayma!

[Joe Britton via ARTIQ]

Has M-Labs tested SAWG on Sayma since the DRAM, Ethernet, gateware bug
patching in recent months?

On Tue, Jan 23, 2018 at 2:43 AM, Sébastien Bourdeauducq via ARTIQ <
artiq@lists.m-labs.hk> wrote:

> Hi,
>
> We are pleased to announce that the ARTIQ SAWG is now working on the Sayma
> board. See the attached scope screenshot!
>
> There are still many rough edges but we are getting there.
>
> Steps to reproduce:
> 0) We assume you have a Linux machine, Linux skills, and the full ARTIQ
> development environment installed (Vivado, Rust, etc.). We will make conda
> packages later. See:
> https://m-labs.hk/artiq/manual-master/developing.html
>
> 1) Since the HMC830 usually malfunctions, bypass it by applying the
> attached patch to the firmware.
>
> 2) Compile everything:
> ./artiq/gateware/targets/sayma_rtm.py
> ./artiq/gateware/targets/sayma_amc.py
> Be patient: Vivado compilation time is Ultrascaled.
>
> 3) Since we bypassed the HMC830, feed a 1.2GHz clock directly into the
> DAC_CLK_P SMP connector in the RTM. Put a 50R resistor across the DAC_CLK_N
> SMP connector. Or use a balun if you have one (but the single-ended mode is
> explicitly supported by the clock chip).
>
> 4) Flash the board:
> artiq_flash.py -t sayma_amc --srcbuild misoc_standalone_sayma_amc
> Do not put the board into a µTCA crate, as it wouldn't get correctly
> powered due to a work-in-progress problem. Use the ATX connector instead.
>
> 5) Since Ethernet doesn't work yet, the kernel will be loaded as an "idle
> kernel" through the flash. Run:
>
> cd artiq/examples/sayma
> artiq_compile repository/demo.py
> artiq_mkfs -f idle_kernel repository/demo.elf sawg.config
> artiq_flash -t sayma_amc -f sawg.config proxy storage start
>
> (We've made progress on the Ethernet front, and reception of packets now
> works; transmission appears to be a PHY configuration problem which is
> being investigated).
>
> 6) Look at the boot messages on the serial console (first FTDI non-JTAG
> channel, 115200bps, you can use flterm from MiSoC). It should block during
> the initialization of the AMC/RTM bridge.
>
> 7) Since automatic RTM FPGA loading is not implemented yet, load the RTM
> FPGA manually with the attached OpenOCD script and:
> openocd -f sayma_new.cfg -c "pld load 0 artiq_sayma_rtm/top.bit; exit"
>
> 8) Look at the serial console again. Loading the RTM FPGA should have
> unlocked the boot process and the board should initialize the HMC7043 and
> the DACs, run PRBS tests, and finally your kernel.
>
> 9) Observe RF with a scope on the two outputs of a BaseMod (Allaki) in AFE
> Channel 1.
> By modifying the kernel and then recompiling and flashing it as in step 5,
> you should be able to use the other channels as well, and generate other
> waveforms.
>
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] monthly status report

[Joe Britton via ARTIQ]

Thank you SB. This looks like a huge amount of work in the last month.
It was really cool to see how quickly RISC-V was added. Awesome!

When do you expect to look for phase synchronization of SAWG in the
analog signal?

On Sun, May 6, 2018 at 12:19 AM, Sébastien Bourdeauducq via ARTIQ
 wrote:
> Please see the attached PDF.
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Sinara (Kasli, Urukul, Novo, Zotino...) batch sizing

[Joe Britton via ARTIQ]

Robert, Please post a quote from Technosystem for qty 1-10, 11-20, 21-50.
It's hard for groups to project volume without knowing price brackets.

In keeping with the open philosophy of the platform I encourage everyone to
use the wiki to communicate anticipated volume (Robert's link [2]). -Joe

On Wed, Nov 15, 2017 at 11:43 AM, Robert Jördens  wrote:

> Dear all,
>
> [This e-mail goes to the ARTIQ mailing list and to everybody who I can
> remember has indicated interest in purchasing Sinara hardware. Feel
> free to pass it along.]
>
> as you may know we are nearing the availability of several pieces of
> the Sinara [1] family and many groups want to start buying Sinara
> hardware [2] to evaluate it and even more importantly to run
> experiments with it. The prototypes of Urukul will enter smoke testing
> in the next days and Kasli will follow shortly after that.
>
> Cost is a significant factor for many and we'd like to be able to give
> numbers that are as low as possible. We need to know the batch size
> accurately and early as possible as price goes down significantly with
> batch size. We are not in a position where we can overestimate the
> production batch size and stock significant numbers of these boards.
>
> Therefore, we'd like to know the **most likely number of boards you
> will be purchasing in the next four months**. We are especially
> interested in the numbers for:
>
> * Kasli
> * Urukul
> * Novo
> * Zotino
>
> but to get a handle on the other boards as well would be helpful. See
> the wiki [3] for an overview of what's in the pipeline.
>
> With that data we can produce a low and realistic price estimate.
>
> Please feel free to send me the data. I will collect and keep it, if you
> prefer.
>
> Best regards,
> Robert.
>
> [1] https://github.com/m-labs/sinara
> [2] https://github.com/m-labs/sinara/wiki/Purchasing
> [3] https://github.com/m-labs/sinara/wiki
>
> Robert Jördens.
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] Sayma bootstrapping

[Joe Britton via ARTIQ]

UMD has received a complete set of Sayma hardware from WUT. So we're ready
to test M-Labs components. Please advise on how to get started.  -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Error Installing Rust

[Joe Britton via ARTIQ]

Lauren, Why are you trying to compile rust from scratch? Have you had
success using the pre-compiled conda-distributed version?

http://www.m-labs.hk/artiq/manual-master/developing.html#artiq-anaconda-development-environment


On Fri, Sep 22, 2017 at 7:40 PM, Lopez, Lauren M via ARTIQ
 wrote:
> We encounter the attached error when installing Rust. The specific error
> alternates amongst the source dependencies for ‘cmake,’ ‘toml,’ getopts,’
> ‘’rustc-serialize,’ num_cpus,’ ‘libc,’ and ‘gcc.’  Gcc and cmake are
> installed. We ran the following shell script from the installation
> instructions:
>
>
>
> cd ~/artiq-dev
> git clone -b artiq-1.18.0 https://github.com/m-labs/rust
> cd rust
> git submodule update --init
> mkdir build
> cd build
> ../configure --prefix=/usr/local/rust-or1k --llvm-root=/usr/local/llvm-or1k
> --disable-manage-submodules
> sudo mkdir /usr/local/rust-or1k
> sudo chown $USER.$USER /usr/local/rust-or1k
> make install
>
> libs="libcore liballoc libstd_unicode libcollections liblibc_mini libunwind"
> rustc="/usr/local/rust-or1k/bin/rustc --target or1k-unknown-none -g -C
> target-feature=+mul,+div,+ffl1,+cmov,+addc -C opt-level=s -L ."
> destdir="/usr/local/rust-or1k/lib/rustlib/or1k-unknown-none/lib/"
> mkdir ../build-or1k
> cd ../build-or1k
> for lib in ${libs}; do ${rustc} ../src/${lib}/lib.rs; done
> ${rustc} -Cpanic=abort ../src/libpanic_abort/lib.rs
> ${rustc} -Cpanic=unwind ../src/libpanic_unwind/lib.rs --cfg llvm_libunwind
> sudo mkdir -p ${destdir}
> sudo cp *.rlib ${destdir}
>
> We also attempted to install without the script running each line
> individually. We get the following error when running make install:
>
>
>
> osError: [Errno 13] Permission denied: ‘.cargo/config’
>
>
>
> ---
>
> Lauren Lopez
>
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Example Ion Trap Code

[Joe Britton via ARTIQ]

Hi All. I'd like to introduce Arpit Agrawal. He's a physics graduate
student at UMD and recently joined my group at JQI/ARL. His background
is in computer science and quantum information theory. He has a
masters degree in physics from IIT-Bombay. The plan is that Arpit's
thesis work will be focused on building a trapped-ion application
layer on top of ARTIQ. Locally he will work with my lab and the Monroe
labs. Discussions and code examples from labs currently running ARTIQ
(Oxford and NIST) would help bootstrap this process. Since it sounds
like there's interest from a couple groups in this sort of project I'd
like to discuss ways of working together on this.

> One solution to both of these problems would be to maintain a public 
> repository
> with some ‘generic ion trap’ example code, which might eventually include a 
> wide
> variety of examples submitted by different groups. It would be important that 
> the
> code be clean, well-commented, PEP 8 compliant, etc. One way of doing this 
> fairly
> painlessly would be for NIST to work with a group that is switching to ARTIQ 
> and
> help them write good, well documented code that can be published.

Getting together basic examples is a good starting point. The longer
term aim for Arpit's work is an extensible trapped ion control
framework that provides some degree of modularity. Both code and
social structures are needed that facilitate upstream contributions by
trapped ion groups. As Robert points out there's an opportunity to
avoid group-by-group fragmentation of common-use code.

> For use as a general tutorial, the magtrap code that Raghu/NIST has written is
> too complex and contains too many behaviors/design features that are specific 
> to
> our particular experiment.

Sounds like an opportunity to learn from what NIST has done and refine
where boundaries lie between what's "specific to a particular
experiment" and what's general use.

> This tutorial needs to stand on its own, without requiring the authors of the
> tutorial to be available to answer questions

Agreed that whatever is published should stand on its own. No single
group can handle the load of fielding community Q Ideally the Q
will take place in a public forum where M-Labs and the broader ARTIQ
trapped ion community can all contribute.

> We are willing to collaborate with such a group to provide some general 
> guidance
> on how we have solved relevant problems, and offer advice on efficient code 
> structure,
> which would provide a benefit for the group getting started with ARTIQ, and 
> then for
> other new users as the tutorial takes shape.

Sounds like a good opportunity. Let's talk if you have an interest in
working together on this.

> I suggest that any tutorial(s)/example code be hosted in a separate 
> repository from
> ARTIQ itself.

Agreed.

> It seems to me that
> everyone who has working code will likely claim that their code is too
> complex and too specific and that there are other priorities. We have
> to break out of that circle.

Agreed. The modularity and generic nature of the ARTIQ codebase is a
demonstration that this is possible. Involvement from M-Labs would
help shape the development of the resulting trapped ion code.

Arpit is making good progress at understanding the internals of ARTIQ.
As an under-the-hood exercise he's currently working with M-Labs to
write a driver for the Sinara Zotino DAC. He will also spend time in
an established qubit labs at UMD that is using the Sandia
PyIonControl. Maybe a visit to NIST for a couple days is in order to
see how you're using ARTIQ on the magtrap? Refactoring the magtrap
code into more polished example code could be part of his
bootstrapping process.

-Joe

On Wed, Aug 30, 2017 at 11:10 AM, Robert Jördens via ARTIQ
 wrote:
> On Mon, Aug 28, 2017 at 5:22 PM, Slichter, Daniel H. (Fed) via ARTIQ
>  wrote:
>>> What about publishing Raghu's code? It seemed pretty clean from the quick
>>> look I had at it during NACTI.
>>
>> For use as a general tutorial, the magtrap code that Raghu/NIST has written 
>> is too complex and contains too many behaviors/design features that are 
>> specific to our particular experiment.  It would require substantial work to 
>> retool it for use as a proper introduction for people who are new to ARTIQ, 
>> and this sort of work has lower priority than our scientific projects at the 
>> current time.  This tutorial needs to stand on its own, without requiring 
>> the authors of the tutorial to be available to answer questions; if we just 
>> post existing code, there will be a million different questions about 
>> minor/irrelevant details (we have had this experience a great deal already 
>> when people have looked at our code), making it a huge time sink for us and 
>> not very useful to new users.
>>
>> The reason we suggested a collaboration with a new group starting up with 
>> ARTIQ is that they are best equipped to provide an accurate 

Re: [ARTIQ] ARTIQ SPI PHY, differential driving

[Joe Britton via ARTIQ]

Thanks Arpit and Daniel for email responses. Catching up the mailing list...

The path Metlino/Sayma -> FMC -> VHDCI uses LVDS which are driven as
_p and _n pin pairs from the FPGA for each EEM IO line. Each EEM board
has an LVDS receiver that generates local single-ended IO.

> If that is the case, you need to dig into Migen to figure out how to express 
> the
> subsignals with two pins using an LVDS standard (I haven’t done this myself, 
> you might ask Robert
> or Sebastien).

We've already figure out how to do get Migen to express subsignals
using a pair of pins. For example,

("clk", 0,
Subsignal("p", Pins("Y23")),
Subsignal("n", Pins("Y24")),
IOStandard("LVDS_25"), Misc("DIFF_TERM=TRUE")
)

Does Migen supports sub-subsignals or is a change needed to SPIMaster?
This is what the NIST_clock Migen subsignal definition looks like for
spi when driven single-ended by the FPGA.

("spi", 0,
Subsignal("clk", Pins("LPC:LA13_N")),
Subsignal("cs_n", Pins("LPC:LA14_N")),
Subsignal("mosi", Pins("LPC:LA17_CC_P")),
Subsignal("miso", Pins("LPC:LA17_CC_N")),
IOStandard("LVTTL")),


On Wed, Sep 13, 2017 at 11:21 AM, Joe Britton <joe.britton@gmail.com> wrote:
> What's the right way to use ARTIQ to drive SPI devices across the VHDCI bus?
> The SPIMaster interface appears to take only a single signal for each of
> clk, cs_n, mosi and miso.
>
> Has anybody yet interfaced with an SPI device using VHCDI? -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] ARTIQ SPI PHY, differential driving

[Joe Britton via ARTIQ]

What's the right way to use ARTIQ to drive SPI devices across the VHDCI
bus? The SPIMaster interface appears to take only a single signal for each
of clk, cs_n, mosi and miso.

Has anybody yet interfaced with an SPI device using VHCDI? -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] Should we use StackExchange?

[Joe Britton via ARTIQ]

Have you ever had ARTIQ questions that weren't quite covered in the
official documentation?

- How do I get data into Mathematica for offline analysis?
- How do I get data into MATLAB/Mathematica for offline analysis?
- How do I program a 2-dim scan and plot the results?
- What configuration options are available for devices listed in device_db.py?
- What devices are available for inclusion in device_db.py?

Have you ever wondered how other research groups are deploying ARTIQ
or asked questions like?

- How do I extend ARTIQ to support a device in my lab?
- Why are some device drivers in artiq/devices and some in
artiq/firmware/libboard?
- What's the best way to reuse code common in several similar experiments?

To support discussions of this sort I propose using StackExchange as a
medium for ARTIQ Q Proposed scope is discussion of best practices
for deployment and writing ARTIQ Python programs. I've setup a pilot
StackExchange site where we can decide if this is something of
interest to ARTIQ users.

https://area51.stackexchange.com/proposals/113150/artiq?referrer=B5MvthzU--YSYKc3cy0s1g2

If you like this idea please click Follow.  From what I can tell
on-boarding of new StackExchange communities (eg
artiq.stackexchange.com) uses a social engineering algorithm of sorts.
It starts off by asking the community do discuss type and scope of
questions it site would address -- current stage. If there's
sufficient interest the algorithm permits users to answer the proposed
questions. In time the site may in time graduate to become a
full-fledged stackexchange.com community. If not enough people take
interest the site goes away.

Context: Just as github Issues have proved popular for discussing new
ARTIQ features, I'm hopeful that StackExchange can increase community
engagement. The StackExchange Q is meant to compliment but not
duplicate the following existing resources.

- authoritative ARTIQ documentation
(https://github.com/m-labs/artiq/tree/master/doc)
- bug reports (https://github.com/m-labs/artiq/issues)
- discussion of new features (https://github.com/m-labs/artiq/issues)
- news and topics of community-wide interest
(https://ssl.serverraum.org/lists/listinfo/artiq)

Thanks everyone for your consideration. Cheers. -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Pipistrello Install Issue

[Joe Britton via ARTIQ]

Also be sure you're using ARITQ 2.x. See Release Notes.

https://github.com/m-labs/artiq/blob/471605ec1ed951f9033472a19c04287494978d49/RELEASE_NOTES.rst

On Thu, Jul 27, 2017 at 6:43 PM, Chris Ballance via ARTIQ
 wrote:
> Hi,
>
> Do not try to install from source - installing the package is much easier.
>
> Following the instructions at
> https://m-labs.hk/artiq/manual-release-2/installing.html
> After running
>
> $ conda create -n artiq-main artiq-pipistrello-nist_qc1
>
> (which should finish without error)
> Then
>
> $ source activate artiq-main
>
> followed by
>
> $ conda list
>
> should show you the list of installed packages in this environment. This
> should include artiq 2.4 - does it?
>
> C
>
>
> On 26/07/2017 16:29, William Evans via ARTIQ wrote:
>
> Hello there,
>
>
>
> I have been trying to install the ARTIQ system on a pipistrello to trial it
> and demonstrate it to my group at the University of Sussex.
>
>
>
> I have tried both installing from the packages and from source. Sébastien
> has advised me to contact the mailing list to find some help.
>
>
>
> In my most recent attempt, I have followed the instructions in the manual to
> install on a Linux VM. When trying to use the artiq_flash command I receive
> the following message:
>
> ‘artiq_flash: command not found’
>
>
>
> Is anyone willing to help me to understand the installation process in more
> detail and figure out how to proceed?
>
>
>
> Kind regards,
>
> William Evans
>
>
>
>
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
>
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] July status report

[Joe Britton via ARTIQ]

Thank you for the update.

Please consider adding more explicit references to the codebase in the
monthly reports. This helps new users get oriented and experienced
users review what's new. Here's an example of what I have in mind
based on the July 1 status report.

"We have developed a mechanism for kernels to access non-realtime SPI buses."
coredevice.spi.NRTSPIMaster

"I2C restart feature"
coredevice.i2c.i2c_restart

"We have documented the DRTIO protocol and usage in the ARTIQ manual."
artiq/doc/manual/drtio.rst

On Sat, Jul 1, 2017 at 12:31 PM, Sébastien Bourdeauducq via ARTIQ
 wrote:
> Please see the attached PDF.
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] program files for testing Sinara

[Joe Britton via ARTIQ]

I've posted some of the ARTIQ program files I'm using to test the
Sinara gateware/software.

https://github.com/jbqubit/sinara-testing

-Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6

[Joe Britton via ARTIQ]

Octopart Avnet costs for 1 unit

XC7A100T-2CSG324C $131.22
XC7A50T-2CSG324C $74.98

Greg, What is the cost differential between 50T-2 and 100T-2 assuming
Xilinx open source pricing? -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] Survey of ARTIQ User Community (April 2017)

[Joe Britton via ARTIQ]

Dear ARTIQ Friends, I've made a quick google poll to gauge the
activity of the ARTIQ user community. It only takes 5 minutes to fill
out. If you are using ARTIQ or just lurking in the wings please fill
it out.

https://docs.google.com/a/umd.edu/forms/d/e/1FAIpQLSepPMMap_EstK_T5h1jA5BTbcL8s56L0qN-dk5iK7NMqhgJvw/viewform

If you have additional questions you wish I'd asked, email me or reply
to this message. Cheers!  -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Fwd: Sinara multi-crate / DRTIO switches

[Joe Britton]

> * The decision we want to taking here is whether we will support only
> the simple hierarchy of a single Metlino *directly* connected to a
> bunch of terminal child devices devices (Sayma, Kasli) or whether we
> allow support for hierarchies deeper than a single level of DRTIO
> links to be built without having to rewrite parts of the stack.

If I wanted a simple hierarchy I'd just use point-to-point BNC cables.
Support of an arbitrary graph (not just hierarchical) is desired.
Routing based on a static lookup table is fine.

> * The slower response times would only affect channels that are deeper
> in the DRTIO tree than the first level. It doesn't degrade performance
> of existing channels. I.e. it affects channels that are on a Sayma
> that's attached to a *satellite* Metlino. And the latency is
> physically given by that hierarchy already. This latency also needs to
> be viewed in comparison to the CPU latency which is µs.

The utility of ARTIQ for future quantum information experiments is
considerably hampered by reliance on CPUs with ~us latency.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Sinara multi-crate / DRTIO switches

[Joe Britton]

> does anyone have serious plans to use more than one Sinara crate?

Absolutely. One of my primary motives for supporting DRTIO is
coordination of multiple crates. Use case is ARTIQ coordinating
entanglement distribution between a pair of qubit systems (each with
its own crate) separated by an optical fiber. Future (>3 years) is
same but for >2 nodes. See the following paper for one approach using
trapped ion qubits.

http://iontrap.umd.edu/wp-content/uploads/2015/06/NphysModNet2015.pdf

> Multi-crate configurations require slightly complicated gateware support for 
> DRTIO switches.
>The bandwidth between crates will also be limited to 10Gbps.

10 Gb/s doesn't strike me as a limitation for the foreseeable future.

> Crossing each switch will incur 100ns-200ns of latency

This has implications for some experiments. 10 m (10 km) fiber
propagation is 48 ns (48 us). Demonstration experiments involving
heralded entanglement of a pair of nodes (2 crates) have a low
probability of success (~1e-6) and are repeated continuously (~1 MHz).
With each rep the success (or failure) is typically reported to nodes
so the rep rate is limited by node-node communication latency. Adding
an additional 200 ns for DRTIO routing in the case of 10 m separation
is a significant added cost and may preclude the use of ARTIQ for
early experiments (eg defect qubits where T2~ 10's us). For larger
node separation it is fractionally smaller.

>There is currently a plan to support multi-crate in the hardware (this 
>future-proofing simply
>means adding some SFPs, essentially) but no plan to support it in the gateware.

A current implementation using soft-core switching seems an adequate
compromise provided the system is designed in such a way that a future
gateware implementation is straight forward.

> 1) slower response times.
> 2) blocking the kernel CPU by twice the latency (round-trip) when it needs to 
> enquire about the space available in a remote RTIO FIFO.

Any implementation that requires round-trip communication to complete
DRTIO is very bad due to fiber/free-space propagation delays. To first
order all DRTIO should assume receiving devices are ready to receive
and handle errors by a) reporting to master crate b) logging for
post-processing. To second order it's fine for low-traffic advisory
signaling like "FIFO 80% full." Plan for future deployments where
communication propagation delays are 100's us.

In anticipation of a future all-gateware implementation of DRTIO
routing is use of a dedicated soft-core CPU helpful?

> DRTIO switch support is also beneficial to the serial protocol between the 
> Sayma AMC and
> Sayma RTM FPGAs - the current plan is to use a dumb protocol that doesn't 
> have good timing
>resolution and is inefficient for things like SPI transfers, essentially a 
>more open version of Channel
>Link II.

In this case you're relying on in-crate timing distribution. Seems fine.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Fwd: proposed uTCA hardware for ARTIQ; Sayma, Metlino, Kasli and friends

[Joe Britton]

Based on feedback from m-labs, Greg at Warsaw Technical University
(WUT) and ARTIQ users I've updated the microTCA hardware plan. Here's
a recap of the changes.

##
### Changes to sayma_motherboard

1) An UltraScale Kintex FPGA will be used in lieu of Kintex7. The
change is motivated by the need for 2 serial transceivers per DAC
channel on the sayma_motherboard -- I had neglected to account for
8b/10b encoding. Thanks to AOSense for pointing this out!
* XCKU040-1FFVA1156C
* 485k CLB FF, 242k CLB LUT
* 20 GTH, 12.5 Gb/s
* 520 user IO (excluding GTH)
+ -1C speed grade is sufficient to max out the AD9154 transceiver rate
(10.96 Gb/s)
+ provides transceiver resources to drive 8 DAC channels sampled at 1096 MSPS
+ is a 20% increase in available FPGA resources (relative to Kintex-7 325T)
+ adds 30% to FPGA cost at single unit quantities (relative to Kintex-7 325T)
+ VA1156C package has a long upgrade path list including UltraScale +
chips which are pin compatible. It is the minimal package which
supports 20 transceivers.
+ Xilinx KCU105 will be used for prototyping the gateware which has  8
GTH transceivers on the HPC FMC.

2) DRAM switch from DDR3 to DDR4 to match KCU105 protoboard.

3) Increased FPGA IO count enables RTM connectors to be fully
populated with 54 differential pairs. This permits future RTM
applications.

4) Replace Atxmega128A1U-AU with ARM Cortex M3.
+ This is the microTCA IPMI CPU that implements IPMB-L.
+ Open source microTCA MMC works on M3.

5) It is desirable to have an on-board mechanism for generating the
2.4 GHz DAC clock. It is anticipated that doing this with very low
phase noise and small temperature coefficient is challenging. To
mitigate this risk the DAC clock electronics will appear on a daughter
board named sayma_clk. Two variants of sayma_clk will be produced
(with same form factor).
+ sayma_clk_approach_2 :: A low risk clock generator. It accepts a
physicist-generated 2.4 GHz sinusoid from a front-panel SMA and
provides a suitable driver for the differential DAC CLK+ and CLK-.
+ sayma_clk_approach_1 :: A is higher risk clock generator led by
Oxford. As reference it uses the uTCA backplane CLK3 at 100 MHz to
generate phase-locked 2.4 GHz DAC and 100 MHz ADC clocks.

##
### Changes to metlino_motherboard

1) An UltraScale Kintex FPGA will be used in lieu of Kintex7. This
change is made to match the FPGA family and transceiver type (GTH)
used for the sayma_motherboard.
* XCKU040-1FFVA1156C
+ Xilinx KCU105 will be used for prototyping the gateware which has  8
GTH transceivers on the HPC FMC.
+ XCKU040 has 20 GTH transceivers (relative to 24 GTX on Kintex-7
325T). Since 16 GTH are needed for DRTIO with AMC modules (eg
sayma_motherboard), only 8 GTH remain for SFP connectors. 4 GTH will
be front-facing, 4 GTH will be exposed on the RTM.
+ VA1156C package has a long upgrade path list including UltraScale +
chips which are pin compatible. It is the minimal package which
supports 20 transceivers.
+ Xilinx KCU105 will be used for prototyping the gateware.

2) DRAM switch from DDR3 to DDR4 to match KCU105 protoboard.

3) Increased FPGA IO count enables RTM connectors to be fully
populated with 54 differential pairs. This permits future RTM
applications.

4) Replace Atxmega128A1U-AU with ARM Cortex M3.
+ This is the microTCA IPMI CPU that implements IPMB-L.
+ Open source microTCA MMC works on M3.

##
### Changes to kasli
Kasli is an integral part of the ARTIQ hardware plan but hardware
development won't start until Q4 2016.

> Below is a link to the google docs spreadsheet discussing the hardware
> details. Please use the mailing list for comments, questions and
> suggestions on how to improve things. Refer to spreadsheet tabs by
> name so we all are on the same page about which subsystem is being
> discussed.
>
> https://docs.google.com/spreadsheets/d/1mkg7u-MaYnXeptUxOmuWZalwc4X5r3Jy-z8v8w91Q00/edit?usp=sharing

-Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ-1.0 feature freeze

[Joe Britton]

On 2/19 we had a google hangout and discussed the v1.0 release. People
present were Daniel, Joe, David L. and SB. Robert reviewed minutes.
Here's a recap of the release schedule we agreed to follow.

  * April 1: testing starts on official 1.0RC  (for both Linux
and Windows 7)
  * May 1: official 1.0 release
+ compromise: possibility that Win 7 v1.0 release is
delayed beyond May 1

-Joe

On Thu, Feb 18, 2016 at 9:47 AM, Leibrandt, David R.
 wrote:
>
> We'd also be happy to do some testing in the clock lab.
>
> Best,
> Dave
>
> -Original Message-
> From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Slichter, 
> Daniel H.
> Sent: Thursday, February 18, 2016 9:04 AM
> To: Robert Jördens ; Sébastien Bourdeauducq 
> 
> Cc: artiq@lists.m-labs.hk
> Subject: Re: [ARTIQ] ARTIQ-1.0 feature freeze
>
> > One thing we should do as part of the release process is to designate
> > a release candidate that would need to see some actual testing before
> > we call it a release. Otherwise chaos ensues usually. Anybody willing
> > to test such a release candidate to make sure we didn't overlook something?
>
> The Magtrap aims to be using ARTIQ in a serious way very soon, so we would be 
> willing to test a release candidate.
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Dropping 32-bit packages

[Joe Britton]

I think it's fine to kill the 32-bit Linux version.

The 32-bit Windows version is preferred over 64-bit. Reasons...
* 32-bit binaries runs on 64-bit or 32-bit Windows OSs
* In may be the case that ARTIQ is installed on Windows machines for the
purpose of acting as a Device Manager for a bespoke physics hardware. It is
a reality of scientific equipment that some vendors still release drivers
as 32-bit .dll.

-Joe

On Tue, Jan 26, 2016 at 4:35 PM, Peter Zotov  wrote:

> Hello all,
>
> There should be little reason to use 32-bit systems.
> Thus, we would like to stop building 32-bit Linux and
> Windows conda packages.
> Is this OK?
>
> --
> Peter Zotov
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ Compatibility with VIRTEX 7 FPGA

[Joe Britton]

Hi Zach. Thanks for the question. Porting ARTIQ to the VC707 probably
isn't very hard but would likely cost more in time than buying a KC705
($1700).  If you'd like to get up and running quickly I recommend
using the KC705. Is there a feature on the VC707 that you need that's
not available on the KC705? I've cc'd this email to the ARTIQ mailing
list so that others more knowledgeable about porting can comment. -Joe

On Mon, Jan 11, 2016 at 2:54 PM, Zachary J Miller  wrote:
> Hi Joe,
>
> I am part of the Englund group at MIT. I am in the process of implementing
> ARTIQ in our lab, and have a question about compatibility of ARTIQ with
> FPGA's other than the two listed in the ARTIQ manual. I currently have a
> XILINX Virtex-7 VC707, and I am uncertain if the procedure for installation
> in the ARTIQ documentation will still work. So do I need to get a KC705, or
> will the VC707 work? Thank you.
>
> Best,
> Zach Miller
>
> Zach Miller
> Department of Physics
> Massachusetts Institute of Technology
> Class of 2018
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] November status report

[Joe Britton]

Thank you for the progress report. Some questions.

Regarding 2), can you say more about the new MiSoC. What's new about
it? What does it mean for "builds to be out-of-tree?"

Regarding 3), is the Startup Kernel in addition to the previously
implemented Default Kernel?

 -Joe

On Mon, Nov 23, 2015 at 2:57 AM, Sebastien Bourdeauducq  wrote:
> Please see the attached file.
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] <1 ns output resolution

[Joe Britton]

>The current circuitry will add several hundred ps of peak-to-peak jitter at a 
>minimum.
> This is more reasonable if you are talking about a signal that stays on just 
> one
> board, but again you will need to do some careful engineering.

It's worse than that. In June I tested the legacy (circa 2004) LVDS
bus to 50-Ohm driver we use in the Penning lab and found that it fails
to reproduce a 50% duty cycle square wave >20 MHz. Continued use of
this legacy front-end to the experiment is my lazy approach to getting
ARTIQ to work with the KC705 and is certainly not the path forward.

My point in this email thread is to establish the timing capabilities
of the FPGA itself. If a lab wants to take advantage, additional work
is needed to couple to their apparatus. COTS solutions exist for low
jitter optical links. For example, SFP+ transceivers achieve > 10
Gbps.   -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ API Changes :: python3.5, datasets, setattr_*

[Joe Britton]

Changes in experiment logging API.

See changes in examples/master/repository/arguments_demo.py

https://github.com/m-labs/artiq/commit/d13b368a6575ac7ac932b8fe5dc680d7503bcd53




On Thu, Oct 15, 2015 at 10:21 PM, Sébastien Bourdeauducq <s...@m-labs.hk>
wrote:

> On 10/16/2015 12:05 PM, Joe Britton wrote:
> > Due to changes in conda deployment use the main build channel instead of
> > the dev channel.
>
> Actually you should have both right now. The main channel is for
> stable/released software that is manually built, while the dev channel
> is for automatically built packages from repository commits. ARTIQ is
> only in the dev channel at the moment.
>
> Sébastien
>
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
>
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] conda channel change

[Joe Britton]

 Just FYI, after 31st of August binstar.org will be deprecated,
 everybody should use anaconda.org - https://anaconda.org/m-labs/.

* remove the following line from ~/.condarc
  - http://conda.binstar.org/fallen/channel/dev
* remove artiq
$ conda uninstall artiq
* follow instructions here
http://www.m-labs.hk/artiq/manual/installing.html#installing-using-conda
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] Distributed Real-Time I/O (DRTIO) upgrade to ARTIQ, clock stability

[Joe Britton]

Sometime in 2015 I'm aiming for an extension to ARTIQ for low-latency,
high-bandwidth optical interconnect for ARTIQ peripherals. This
underpins several applications. For example,

* streamlined real-time control of lab peripherals used by trapped-ion
and neutral atom AMO groups; real-time means latency much lower than
qubit coherence time

* all-digital, closed-loop PID loops spanning devices distributed
around a lab; requires deterministic ( 1ns jitter), low-latency
(100 ns), Gigabit-bandwidth  links

* break ground loops for laboratory peripherals; use commodity Gigabit
optical links

* clock and control synchronization for distributed quantum systems
(e.g. quantum networking, quantum-enabled sensors)

When planning for this so-called Distributed Real-Time I/O (DRTIO)
upgrade to ARTIQ it's necessary to answer the question What type of
clock stability is needed by trapped ion experiments? Here's my go at
it.

---

# Trapped Ion Qubit Timing  Clock Requirements
## Ramsey for qubit
Here's a physics example that illustrates the type of clock stability
that a trapped ion qubit experiment would require. Do a 1 second long
Ramsey interference experiment on a 10 GHz qubit. This involves a pair
of short microwave pulses separated in time by 1 second. The microwave
source is locked to a low phase noise reference oscillator. If the
integrated phase error on the 10 GHz between the two pulses is pi
Radians the atomic coherence is lost. To ensure that oscillator phase
noise is not the limiting factor aim for a phase error of less than
pi/10 over 1 second, a stability of 1e-11 is needed. A spin-echo
sequence will give insensitivity to slow (1 Hz) variations in
reference oscillator frequency at the 1e-11 level.

## Ramsey for clock/sensing
If the aim is to use the Ramey-type experiment to sense B-field (or
local oscillator) drift, greater stability is required to beat down
quantum projection noise. One hundred repetitions of the 1 s Ramsey
experiment would require 1e-13 reference oscillator stability. This
level of stability is straighforward when a high quality reference
oscillator is co-located with the 10 GHz microwave source.

## Adiabatic trapped ion transport
Another physics example is the timing requirements for DACs used to
define the harmonic trapping potential of trapped atomic ions. For
non-adiabatic transport of ions it's useful to have a DAC update (~100
MHz) rate that is much higher than the ions secular motion (~1 MHz).
In this case a 1 ns jitter seems adequate relative to 1/100MHz. As a
more stringent requirement, we might require that ion motional heating
following diabatic transport be delta_n  0.1 quanta. As a worst-case
limit use expression (2) in Ref [1]. Assume,
' 9Be+ ion, v = 1mm/10us, fCOM = 1 MHz and t = 10 us + epsilon.'

epsilon| delta_n
--|--
1e-9 s | 0.11
0.1e-9 s  | 0.001

Therefore, by this metric we desire  1 ns jitter. 100 ps deviation
over 10 us would be adequate. There are experiments I could imagine
that would require at or below 100 ps deviation over intervals as long
as 1 ms.

## Proposed DRTIO target
What should be target for DRTIO? Jitter below 100 ps should be
adequate for DRTIO devices responsible for ion transport. And, a wide
variety of ADC applications. If DRTIO devices are to be used for
distributed Ramsey experiments this requires much lower jitter ( 10
ps) and places additional demands on the stability of remote
oscillators. Initially, I'd say it's OK if DRTIO aims shoot for the
first criterion. Sound good?

---

# DRTIO work plan
With these performance criteria and the demonstrated performance of
White Rabbit in mind [2], here's a proposed work plan for bringing
DRTIO to ARTIQ.

**Step 1)** KC705 to KC705 loopback test over SMA cables

**Step 2)**  KC705 to KC705 loopback test with SFP (single-mode
bi-directional fiber link for Rx/Tx)

**Step 3)** Two KC705 linked by SFP, 10 m fiber

**Step 4)** Integrate DRTIO link into ARTIQ's RTIO core

**Step 5)** Demonstrate DRTIO using one KC705 as Core Device (and
master clock) and second KC705 as Satellite. Link is DRTIO over fiber.
Satellite implements 32 channel TTL PHYs. Test that Objectives 3,4,5
are met using TTL PHY on Satellite and TTL PHY on Core Device.

For each Step demonstrate that Objectives 1 to 5 can be met.

**Objective 0**... Deterministic pseudo-random data generator; e.g.
64-bit counter scrambled by something like SHA1

**Objective 1**... Recovery of 100 MHz clock from serial link; clock
recovery sufficient for sustained data transmission at 1 Gbps

**Objective 2**... Demonstration of 1 Gbps transmission with error
rate 1e-14, 1 Gbps over one day of running

**Objective 3**...  Comparison of two synchronized KC705 100 MHz
clocks: RMS jitter 5 ps over periods of 1 ms and 1s; maximum peak to
peak skew  20 ps over 1 second

**Objective 4**... Round-trip determinacy:  10 ns jitter in
round-trip, over 1 minute observation period (1 m cable length)

**Objective 5**... Round-trip 

[ARTIQ] LED example

[Joe Britton]

This should work, right? I'm using KC705 in Penning lab. No blinking.  The
core device runs mandelbrot.py fine.

from artiq import *
def input_led_state():
return int(input(Enter desired LED state: ))

class LED(EnvExperiment):
def build(self):
self.attr_device(core)
self.attr_device(led)

@kernel
def run(self):
s = input_led_state()
self.core.break_realtime()
if s:
self.led.on()
else:
self.led.off()
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Qt and pyqtgraph

[Joe Britton]

Impulse is an extension for the Eclipse IDE that supports visualization of
a wide array of time-series data. I don't have any experience with it but
found it while browsing. Its written in Java and is free to use for
non-commercial/research applications. It may be more inspirational than a
useful building block for Artiq. Quoting from their web page [0]...

impulse allows developers to view signals and other informations form
multiple sources formatted in various ways. Read logic data from an
analyzer, parse and visualize log data from serial line, show line diagrams
of analog inputs, get variables from the debug adapter and present
communication protocols grabbed from ethernet.

It allows the representation of a wide range of signals, not limited to
digital and analogue signals only. Beside these two, impulse offers
transaction, event, text,log , structured, binary, image, and
multi-dimensional signals supporting impressive visualization options.

All impulse components are fully integrated into the eclipse framework
(Windows, Linux and OsX/Mac) 

impulse supports a big bunch of signal types (digital, analog, text, logs,
transactions,..) and related diagram types. The domain does't need to be
time, instead it can be frequency, voltage, current, index,... .You can
also manage and view different domains inside of one view. Depending on the
signals you watch, impulse shows the right axis and cursors.

Streaming is realized by using Ports. There are dedicated ports for
specific devices, protocols or simulators, and there are general purpose
port available to stream from pipes, sockets, serial lines and processes.

Support for multiple data sources [1].

[0] http://toem.de/index.php/projects/impulse
[1] http://toem.de/index.php/projects/impulse/11-impuse/46-simulation



On Tue, May 19, 2015 at 9:51 PM, Sebastien Bourdeauducq s...@m-labs.hk
wrote:

 On Wednesday, May 20, 2015 08:17 AM, Robert Jördens wrote:

 * nice big number widget

 The seven-segment font does not help readability;)


 It doesn't, but I would argue it hints at the purpose of the widget.

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

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

[ARTIQ] Duke control system

[Joe Britton]

Scalable Digital Hardware for a Trapped Ion Quantum Computer


http://arxiv.org/abs/1504.00035
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] external triggering; optical dipole force beatnote

[Joe Britton]

 What about fixing the cabling and/or devices so that this does not
 happen? There may be a problem with the grounding of the coaxial cables,
 poor quality cables, or poorly designed devices (if the crosstalk is
 coming from different channels from the same source).


Of course we strive to do these things. But the reality is that crosstalk
sometimes happens and it's nice to have some tools to handle it. Besides
cross coupling from digital transitions many labs have AOMs and EOMs that
operate at 10's of MHz at several watts. There can be RF leakage even with
double shielded cables. The variable-duration trigger feature is a luxury
feature; its not a high priority at all.


  (3)
  Very low latency is desired between satisfaction of a trigger condition
  and resumption of RTIO events.

 How much latency is very low? With the current architecture, ARTIQ
 should typically give you some hundred nanoseconds. Moving to the
 RTIO-bus system will not significantly change this.


If the latency were deterministic and less than 1 us the scenarios I
described would work fine. We would just factor that delay into the
subsequent pulse sequence.

 We'd like to be able to synchronize subsequent events with
  the ion's motion (following application of an ODF laser pulse) with at
  most 1% error. That is, to 1 ns.

 The planned SERDES-based RTIO PHY on the KC705 will have 0.86ns
 resolution when clocked at 146MHz. This assumes a clock that is precise
 enough so as not to accumulate significant errors during the few hundred
 nanoseconds of latency, but as I understand this should not be a problem.


Sounds good. That resolution would be more than adequate for the two
applications I described.

Are there changes needed to the language to permit multiple subsequent
external triggers in a single experiment? Can any RTIO line be used as a
trigger?

-Joe



 Sebastien
 ___
 ARTIQ mailing list
 https://ssl.serverraum.org/lists/listinfo/artiq

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

Re: [ARTIQ] shallow parameter histories

[Joe Britton]

If you want to keep track and use the history of a parameter, you can
do much more much better using either of the following two approaches
or a combination of them:
* Do it explicitly: keep another parameter that is (n, 2) array with
.(time, value) entries and change that array each time you determine a
new value.
 That solves the problem of where and how to determine the depth of
the history and removes all kind of overhead of saving, maintaining
and restoring the history of every value in memory.

Robert's suggestion would indeed work and may economize on memory.

I guess this history feature could also replace the latest modified
parameters
feature in the GUI too. Instead of having one list with all recent
parameter
changes, you would have one list per parameter.

How much depth will be retained for the time-stamped list of modified
parameters on the master? If this list is deep it might not be much more
expensive to take the shallow-list-per-parameter approach SB suggested. In
light of Robert's comments I can see either approach has its merits.

* Use the logging database explicitly. That is fast, simple and
extends naturally to all kinds of processing, filtering and arbitrary
history depth.

Agreed that this is the most comprehensive solution. If database access
latency is low (~ 5 ms) I could see this working fine. It could be
problematic if the latency is long (100 ms) and the user is aiming for
closed-loop feedback. I suppose in that case keeping a private history on
the master as Robert suggests is the way to go.

-Joe

On Fri, Mar 20, 2015 at 5:38 PM, Robert Jördens jord...@gmail.com wrote:

 Hello,

 On Thu, Mar 19, 2015 at 11:38 AM, Sebastien Bourdeauducq s...@m-labs.hk
 wrote:
  Hi,
 
  On Wednesday, March 18, 2015 09:22 PM, Joe Britton wrote:
 
Ok. How deep should the history be, and what is the algorithm that
  takes  the history and outputs the expected mass at a given time? Does
  the algorithm really need the complete history every time?
 
  For the accumulation of heavy mass ions we typically do a linear fit
  though exponential might be more physical. Having ready access to the
  most recent 10 points would suffice for both fits.
 
 
  Ok, that's pretty small.
 
  What about keeping such a shallow history of all parameters in-memory for
  the master (and in pdb.pyon)?
 
  I would also propose to change the parameter API to use get/set
 functions,
  e.g. you would do:
 
  class DBKeys:
  foo = Parameter()
 
  def run(self):
  a = self.foo.get()
  b = munge(a)
  self.foo.set(b)
 
  This way we can have an additional function get_history that returns a
 list
  of ~10 tuples (date, value) for the parameter. (Despite the inefficiency
  this causes for large parameters e.g. arrays, I propose returning an
 actual
  list instead of using some smarter Python iterator. With next-generation
  scheduling, another experiment might update the parameter while its
 history
  is being read, and thus keeping e.g. valid indices in the history becomes
  difficult).
 
  This API also improves two unrelated smaller thing:
  * coherency of the parameter database from kernels while other
 experiments
  run concurrently under next-generation scheduling. Parameter accesses are
  now RPC'd (and you should store them in a local variable for performance
 -
  and then any coherency issues become more obvious).
  * bugs in experiments due to the use of mutable types in parameters (e.g.
  self.foo.append(x)) become more obvious.
 
  As for archiving: if the experiment has used get_history on a parameter,
 we
  can write the full shallow history (in addition to the latest value) into
  the HDF5 file for that parameter.
 
  I guess this history feature could also replace the latest modified
  parameters feature in the GUI too. Instead of having one list with all
  recent parameter changes, you would have one list per parameter.

 If you want to keep track and use the history of a parameter, you can
 do much more much better using either of the following two approaches
 or a combination of them:

 * Do it explicitly: keep another parameter that is (n, 2) array with
 (time, value) entries and change that array each time you determine a
 new value.
  That solves the problem of where and how to determine the depth of
 the history and removes all kind of overhead of saving, maintaining
 and restoring the history of every value in memory.

 * Use the logging database explicitly. That is fast, simple and
 extends naturally to all kinds of processing, filtering and arbitrary
 history depth.

 I don't see the benefit of providing even a shallow history of the pdb
 in the way you proposed. There is a history saved into the experiment
 data and there is another history tracked in the logging database.
 Regarding changing the DBKeys API, I would do something else. Keep the
 the current DBKeys as is but do not provide parameter setting through
 this api. Instead add a RPC object that _is_ the pdb. Maybe rename

Re: [ARTIQ] debug vs logic analyzer

[Joe Britton]

 On Tuesday, March 24, 2015 02:41 AM, Robert Jordens wrote:
 Hmm. What is the scope of py2llvm debugging symbols? Just code
 locations and then stack/traceback? The traceback will be pretty flat as
 long as we don't have functions, or do you want to add support for
 functions at the same time

 We will not add support for non-inlined functions at this time, but the
 traceback should handle those functions that have been inlined and show
 them in the trace, in addition to unwinding the stack (which is always
 necessary to some extent because runtime syscalls may also raise
 exceptions). In other words, the final tracebacks will contain the same
 amount of information whether or not non-inlined functions are
implemented.

Ok. I still prefer the hardware logic analyzer because I know how I can
use it to debug issues while for the elf debugging symbols I have a hard
time imagining a case where it would be useful given the debugging
features (py2llvm errors and metadata-exceptions) that we already have.

Joe, given that you want debugging symbols, do you have a use case where
they are needed/useful?

I have in mind a scenario where there is an underflow condition on the core
device. It would be helpful if the user had some feedback as to which line
of @kernel python code was responsible. It would be convenient if something
like the usual python debugger's call history were available. What I'm
after is a method for the user to quickly figure out which part of the code
generated the underflow. In the absence of a full stack/traceback it would
be helpful to know a line number and a (stack/heap?) dump that could
provide clues. An example clue might be the current value of loop indices.

The logic analyzer is indeed a useful debugging tool. Especially for
figuring out timing-related bugs for interfacing with external hardware.
However, I imagine parsing by eye a long list of RTIO-vs-time to would be
cumbersome if the user is angling to figure out which bit python code is
bogging down the core device. In the case of a physicist-induced underflow
error, a debug message that refers back to the errant python code would be
best. I imagine the logic analyzer output to be used as low-level
diagnostic for timing critical aspects of experiments or hardware
interfacing.

-Joe


On Tue, Mar 24, 2015 at 1:27 PM, Robert Jordens robert.jord...@nist.gov
wrote:

 On 03/24/2015 01:42 AM, Sebastien Bourdeauducq wrote:
  On Tuesday, March 24, 2015 02:41 AM, Robert Jordens wrote:
  Hmm. What is the scope of py2llvm debugging symbols? Just code
  locations and then stack/traceback? The traceback will be pretty flat as
  long as we don't have functions, or do you want to add support for
  functions at the same time
 
  We will not add support for non-inlined functions at this time, but the
  traceback should handle those functions that have been inlined and show
  them in the trace, in addition to unwinding the stack (which is always
  necessary to some extent because runtime syscalls may also raise
  exceptions). In other words, the final tracebacks will contain the same
  amount of information whether or not non-inlined functions are
 implemented.

 Ok. I still prefer the hardware logic analyzer because I know how I can
 use it to debug issues while for the elf debugging symbols I have a hard
 time imagining a case where it would be useful given the debugging
 features (py2llvm errors and metadata-exceptions) that we already have.

 Joe, given that you want debugging symbols, do you have a use case where
 they are needed/useful?

 Robert.

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

Re: [ARTIQ] duty cycle management

[Joe Britton]

At present Quantum II does not do duty cycle management on its AOMs because
its less cumbersome (given the existing .dc language) to transform
AOM-induced beam pointing into amplitude noise using a fiber (and then
noise eat downstream). This approach wastes laser power and is a patch on
the duty-cycle problem. The aim of writing a general purpose duty cycle
management code (and abstraction of complexity in general) is that the
non-ideality of duty-cycle-dependent devices can be managed automatically
in the background. This makes experiment control files more terse and
therefore reduces the surface area for errors.

 It seems to me that in all cases the experiments can be
 pre-computed and then loaded onto the fpga in the normal way.

The point of the Artiq core device is that RTIO pulse sequences can't in
general be pre-compute offline and loaded onto the FPGA (e.g. branching).

 As with the example that Joe gave before, you just have to add an
 else statement (or another if that captures the other possibilities)
 at the end of the experiment for every if statement where the
 extra else statement will have the same duty cycle.  Then the
 duty cycles are independent of the branches.

With this manual-fix approach, for every modification to the experimental
body there could be a corresponding manual change to the duty cycle
section. This is not a general solution and leaves ample room for errors.

Better, for each repetition of the experiment let the Artiq core integrate
the use of each device (fast integer arithmetic) then automatically add
additional RTIO pulses dynamically at the close of the experiment to
achieve the dutycycle specified in ddb.pyon.

 Maybe for very complicated experiments with many branches
 this would not be a good idea but we are not currently operating
 in that regime.

The successor program to MQCO [0] (and the natural trajectory of qubit
systems) may be a program aiming at error correction. This would be more
complicated than experiments we run at present. Artiq is aimed at reducing
the complexity in both our current stable of experiments and those we may
do in the next five years.

-Joe

[0] http://www.iarpa.gov/index.php/research-programs/mqco

On Tue, Mar 17, 2015 at 9:19 AM, Gaebler, John john.gaeb...@nist.gov
wrote:


 Hi,
 It seems to me that in all cases the experiments can be pre-computed and
 then loaded onto the fpga in the normal way.  As with the example that Joe
 gave before, you just have to add an else statement (or another if that
 captures the other possibilities) at the end of the experiment for every if
 statement where the extra else statement will have the same duty cycle.
 Then the duty cycles are independent of the branches.  The code for every
 experiment could be automatically padded with either extra pulses or extra
 wait times at the end to achieve the desired duty cycles in all cases.  It
 would be convenient if this could happen automatically using something like
 the code Joe proposed. Maybe for very complicated experiments with many
 branches this would not be a good idea but we are not currently operating
 in that regime.  As long as we can avoid long down times (a few us are
 probably fine) where the FPGA is doing nothing (not even running the
 default experiment) I think this works fine
  .  Of course, if there is a simpler solution that also works then I would
 have no problem with that either but conceptually I think this works and no
 changes to the core device behavior or language are needed.
 -John


 --



 If the duty cycle information is specified in ddb.pyon and there are no
 conditional routines in the default experiment, the default experiment
 pulse sequence could be precomputed and loaded onto the FPGA.

 In general, any experiment that includes conditional routines would need
 the dutycycle management preformed on the core device. I don't think this
 would pose a computational problem since the dutycycle pulse sequence could
 be computed at the end of each experiment (OK if it takes many
 micro-seconds).

 -Joe


 Joe Britton
 NIST - Div 688
 325 Broadway
 Boulder, CO 80305
 303.497.7295
 brit...@nist.gov

  -Original Message-
  From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of
 Sebastien
  Bourdeauducq
  Sent: Saturday, March 14, 2015 5:46 AM
  To: artiq@lists.m-labs.hk
  Subject: Re: [ARTIQ] duty cycle management
 
  Hi,
 
  An important question is whether the default experiment (that runs on the
  core device alone, without any computer intervention) will need duty
 cycle
  management. If it does, it means that the duty cycle tracking should
 happen
  on the device.
 
  Sebastien
  ___
  ARTIQ mailing list
  https://ssl.serverraum.org/lists/listinfo/artiq


 --

 Subject: Digest Footer

 ___
 ARTIQ mailing list
 https

Re: [ARTIQ] ARTIQ future details

[Joe Britton]

 Ok. Can we assume you consider it a manual operation to extract the
 duty cycle of a gpio in an experiment and how you use that number is
 all left up to you? Then this sounds just like a use case for the
 soft logic analyzer and would depend on it.

No. I don't think this approach works. Consider an experiment where a duty
cycle resource is swept. For example ttl0 here:

for t in range(0,100,1) :
   ttl0.pulse( t*ms )
   cts = detect()
   if cts  10 :
   ttl0.pulse( 1* ms )
duty_cycle_management()

The desired result of duty_cycle_management() is that the duty cycle of
ttl0 is maintained for any value of t and cts. This is something that can
be computed dynamically during an experiment.





On Wed, Mar 11, 2015 at 4:36 PM, Robert Jördens robert.jord...@nist.gov
wrote:

 On Fri, Mar 6, 2015 at 10:08 AM, Gaebler, John john.gaeb...@nist.gov
 wrote:
  I would keep the duty cycle stuff simple for now.  The first thing would
 be a program that could analyze an Artiq experiment and print out the duty
 cycles of any of the ttl lines (or combinations of the ttl lines).  It is
 ok if this only runs on experiments without any branching.  Then you need
 the ability to write a default experiment that will run whenever nothing
 else is running so things don't get too cold or hot during that time.  I
 would be happy with that.

 Ok. Can we assume you consider it a manual operation to extract the
 duty cycle of a gpio in an experiment and how you use that number is
 all left up to you? Then this sounds just like a use case for the
 soft logic analyzer and would depend on it.
 ___
 ARTIQ mailing list
 https://ssl.serverraum.org/lists/listinfo/artiq

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

[ARTIQ] Fwd: ARTIQ future details

[Joe Britton]

At last week's meeting we discussed prioritizing several items on the
ARTIQ todo list. My interest is in getting Artiq into a form where
real experiments can be done in the lab. The aim is to provide
concrete feedback based on what's happening in the lab. It is
understood that the user interface will be poorly developed.

Goals by beginning of May
===
Aim is to run penning trap experiment on ARTIQ
1) run ARTIQ on KC705  with  legacy TTL/DDS system (16 TTL, 8 DDS)
2) Default Experiment on FPGA is available
   a) automatically runs on boot -- Penning trap is OK without
cooling for a couple seconds
   b) automatically runs if e.g. (10 ms) hardware watchdog timer
times out (eg if soft-core CPU hangs)
2) PY2LLVM error reporting that is readable
3) RTIOUnderflow reporting...
a) which channel experienced underflow?
b) how large was underflow?
c) which file and line of code was responsible for underflow
4) functional parameter database
5) debug methods to find DDS bus errors
a) systematic read and write to all available pins on bus

Please correct me if I'm overlooking something, but the following
don't seem to be necessary to get a bare-bones system up and running.
It would be great if they could be done by the end of May but I'd make
them a lower priority than the list above.
* fancy scheduler
* rtio bus, dds rtio
* fire-and-forget rpcs
* benchmarks
* pdq2 is a helpful tool but Robert already has a stand-alone python
routine for programming the PDQs

Penning experiments that could be handled by ARTIQ with this basic
infrastructure:

e1) scan RTIO parameter (pulse duration, frequency, phase) :: as in
Ramsey, mode spectroscopy/thermometry, squeezing

e2) scan RTIO parameter and do automated fit, stuff result to
parameter database :: as in periodic calibrations of pi-time,
spin-freq, motional mode freq

e3) scan ARTIQ driver parameter between experiments :: as in ACSS
nulling (Thorlabs wave plate rotation angle), beam overlap (Thorlabs
motorized mount), rotating wall frequency (serial device)

e4) set ARTIQ driver waveform :: as in ODF or cooling beam pulse
shaping (PDQ-DAQs and RF Mixer for AOM)

e5) write output of experiments to disk in HDF5 format; penning
trappers will figure out how to plot

e6) change scan parameters via editing text file

 Dutycycle management: John and Joe, you were commenting on this feature
 during the meeting IIRC. Could you write down what this means for you, how
 it should behave, and how it could be implemented (based on what you
 know), and what specific tests and milestones we can write into the
 contract?

Observation: some devices have a thermal time constant (e.g. AOM)
Goal: maintain constant duty cycle for the device so the time-average
power is constant (over many experiment reps)

Sample implementation for a hypothetical device attached to RTIO ttl0.

1) When creating instances of devices in an experiment file, tag those
devices for which duty-cycle management is important (e.g. ttl0)
 a) specify ttl0.duty_cycle in range (0,1] for a device
 b) choose ttl0.duty_cycle_tc in seconds (time for device to
initially thermalize)
 c) tt0.use_t is a parameter that keeps track of device
utilization during a rep; it's reset at the outset of each experiment
rep
 d) ttl0.duty_cycle_is_thermalized == true if the device is warmed up

2) When writing the experiment, put a special function at the end
(after detection) called duty_cycle_management() defined below

3) set a timer that keeps track of the duration of a given experiment
repetition: rep_t

4) duty_cycle_management()
 if ttl0.duty_cycle_is_thermalized == false, auto-generate and run
a pulse sequence with ttl0 duty cycle ttl0.duty_cycle with total
duration = ttl0.duty_cycle_tc
 x = ttl0.duty_cycle * rep_t - ttl0.use_t
 if x0 : ttl0.pulse( x )
 else : delay(-x)

5) do some juggling to handle multiple devices

 Finally, Daniel and Joe, could you look into the administrative details on how
 we end this contract (does Sebastien visit in May? the language is a bit
 ambiguous there; can we delay milestones/payment until August?) and how
 we can label (sole source, extension, repair) the next contract?

I've not taken any action on this. Daniel?

-Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] KC705 support

[Joe Britton]

'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/rabi/artiq-dev/misoc/software/libbase'
 LD  runtime.elf
chmod -x runtime.elf
 OBJCOPY  runtime.bin
chmod -x runtime.bin

*rabi@vboxartiq:~/artiq-dev/misoc$ ./tools/flterm --port /dev/ttyUSB0
--kernel ~/artiq-dev/artiq/soc/runtime/runtime.bin*
[FLTERM] Starting...
*reset button on KC705... no response... no echo back of characters typed
at terminal*
*CTRL-C*

*rabi@vboxartiq:~/artiq-dev/misoc$ ./tools/flterm --port /dev/ttyUSB2
--kernel ~/artiq-dev/artiq/soc/runtime/runtime.bin*
[FLTERM] Starting...
*reset button on KC705... no response... no echo back of characters typed
at terminal*
*CTRL-C*


On Wed, Feb 25, 2015 at 12:57 PM, Yann Sionneau y...@m-labs.hk wrote:

 Agreed, here are patches which fix this:

 Those patches should apply after the previous ones I sent you, except that
 they contain the LPC: addition that you added manually.

 Regards,
 Yann


 On 2015-02-25 20:20, Joe Britton wrote:

 The user clock SMA definition should go to mibuild and follow the same
 pattern as other differential signals (n and p subsignals). -Sebastien

 On Wed, Feb 25, 2015 at 12:08 PM, Joe Britton joe.brit...@gmail.com
 wrote:

 OK. We're trying now using your patches. -Joe

 On Wed, Feb 25, 2015 at 12:01 PM, Yann Sionneau y...@m-labs.hk wrote:

 Ok, I think I fixed the issue, I forgot to put LPC: in front of both
 LA07_N and LA17_CC_N in artiq_kc705.py for signal dds d[] line 40

 Le 25/02/15 19:52, Yann Sionneau a écrit :

 Joe, Sebastien,

 It turns out my last modification fixed the non dedicated clock pin
 issue, it now goes all the way to write_bitstream but then fails because
 there is an issue in the .xdc file generation for the LOC constraints.
 It puts wrong LOC names for the pins coming from FMC connector.
 Here is the error I get:

 http://pastebin.com/t3Ltr7CB

 And I can see in the .xdc file : set_property LOC LA07_N [get_ports
 dds_d[6]]
 which is wrong, it should be : set_property LOC D28 [get_ports
 dds_d[6]]

 Seems like something is wrong around migen/mibuild/xilinx_vivado.py
 line 14 :
 return set_property LOC  + c.identifiers[0]

 Hope this gives hints.

 Le 25/02/15 19:06, Yann Sionneau a écrit :

 Hello Joe and Sebastien,

 Here is what I've got so far, I didn't have time to synthesize the
 last version which I'm sending you.
 It seems both xtring and user_sma_P (Y23) are not clock capable pins
 which so far makes my synthesis fail.

 I hope you will find a way to make it work

 Regards,
 Yann

 Le 25/02/15 16:40, Joe Britton a écrit :

 Any luck? The board is ready to try out.  -Joe

 On Tue, Feb 24, 2015 at 3:45 PM, Yann Sionneau y...@m-labs.hk wrote:

 Le 24/02/15 22:38, Joe Britton a écrit :

 1°) It's quite clear to me that XM105's J17 will be plugged to the
 FMC LPC of KC705 board.

 OK

  2°) it's also clear that on your kc705-fmc105-scsi-adapter board,
 J2 and J1 are the SCSI connectors

 No. The logic lines from the SCSI connectors originate from J20
 and J1
 on the XM105. J2 on the XM105 is not used.

 I meant the J2 and J1 of the scsi-adapter board, not the ones of
 XM105.

 3°) But what's less clear is to what the P1 P2 P3 P4 P5 P6 J6 (of
 your board) will be connected on the XM105 board.

 P1..P4 on my board adapt to J1 on XM105
 P5..P6 on my board adapt to J20 on XM105

 All the other headers on my board are for power or ground.

 Alright, I got it right then :)

 I'm sorry if for you those are obvious questions!

 Questions are good!

 Thanks for your help!

 I'm stuffing the boards now so will be ready to test this in about
 2 hours.

 I'm heading to bed now, I will do my best to try to have a working
 kc705-artiq target file tomorrow, sorry for the delay...

 Regards,

 --
 Yann



 --
 Yann Sionneau
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] KC705 support

[Joe Britton]

 Can you run git checkout . in every repository to revert such
 modifications (you may want to use git diff before to make
 sure you are not deleting anything important), and try again?

There were some local modification. I've reverted to the master and will
rebuild.

rabi@vboxartiq:~/artiq-dev/artiq$ git reset HEAD soc/runtime/main.c
soc/artiqlib/ad9858.py examples/master/pdb.pyon examples/master/ddb.pyon

rabi@vboxartiq:~/artiq-dev/artiq$ git remote -v
origin https://github.com/m-labs/artiq (fetch)
origin https://github.com/m-labs/artiq (push)

rabi@vboxartiq:~/artiq-dev/migen$ git checkout
Your branch is up-to-date with 'origin/master'.
rabi@vboxartiq:~/artiq-dev/migen$ cd ..
rabi@vboxartiq:~/artiq-dev$ cd misoc
rabi@vboxartiq:~/artiq-dev/misoc$ git pull
Already up-to-date.
rabi@vboxartiq:~/artiq-dev/misoc$ git checkout
Your branch is up-to-date with 'origin/master'.
rabi@vboxartiq:~/artiq-dev/misoc$ cd ..
rabi@vboxartiq:~/artiq-dev$ cd artiq
rabi@vboxartiq:~/artiq-dev/artiq$ git pull
Already up-to-date.
rabi@vboxartiq:~/artiq-dev/artiq$ git checkout
Your branch is up-to-date with 'origin/master'.

 Also, does the bitstream get properly loaded, i.e. does the
 DONE LED turn on? And which reset button are you talking
 about? Make sure you press the one that reloads the bitstream.

The DONE LED is illuminated after hitting the reset button. The other
button doesn't change the state of any of the LEDs.

-Joe



On Wed, Mar 4, 2015 at 2:45 PM, Sebastien Bourdeauducq s...@m-labs.hk wrote:

 Hi,

 On Wednesday, March 04, 2015 09:35 PM, Joe Britton wrote:

   CC  main.o
 main.c:58:12: warning: ‘load_object’ defined but not used
 [-Wunused-function]
   static int load_object(void *buffer, int length)
  ^
 main.c:68:12: warning: ‘run_kernel’ defined but not used
 [-Wunused-function]
   static int run_kernel(const char *kernel_name, int *eid)
  ^
 main.c:92:13: warning: ‘blink_led’ defined but not used
 [-Wunused-function]
   static void blink_led(void)
   ^


 That's unrelated to not having any characters printed to the serial port
 when resetting the board, but those warnings should not happen. You
 probably have some local modifications of the code. Can you run git
 checkout . in every repository to revert such modifications (you may want
 to use git diff before to make sure you are not deleting anything
 important), and try again?

 Also, does the bitstream get properly loaded, i.e. does the DONE LED turn
 on? And which reset button are you talking about? Make sure you press the
 one that reloads the bitstream.

 Florent - are you able to get the BIOS to run on your KC705 when using the
 ARTIQ SoC?

 Sebastien

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

Re: [ARTIQ] kc705 flashing woes

[Joe Britton]

Here's what I see trying to start artiq on the KC705.

rabi@vboxartiq:~/artiq-dev/misoc/tools$ ./flterm --port /dev/ttyUSB0
[FLTERM] Starting...

MiSoC BIOS   http://m-labs.hk
(c) Copyright 2007-2014 Sebastien Bourdeauducq
Revision 165a5b67 built Feb 28 2015 12:14:51

BIOS CRC passed (9eb89790)
Running on MiSoC rev. 165a5b67 (sysid:K7) at 125MHz
Initializing SDRAM...
Write leveling: 13  14* 12  11   8   7   5   6  completed
Read bitslip: 7 6 5 4 3
Read delays: 7:01-10  6:01-11  5:03-12  4:03-13  3:10-20  2:00-06
1:00-09  0:00-10  completed
Memtest OK
Automatic boot in 2 seconds...
Q/ESC: abort boot
F7:boot from serial
Booting from flash...
Error: Invalid flash boot image length 0x
Booting from serial...
sL5DdSMmkekro
Timeout
No boot medium found

On Sun, Mar 1, 2015 at 4:01 PM, Joe Britton joe.brit...@gmail.com wrote:
 What remains to be done before a test of the DDS/TTL adapter board is
 possible? -Joe

 On Sat, Feb 28, 2015 at 4:39 PM, Sebastien Bourdeauducq s...@m-labs.hk 
 wrote:
 Hi,

 we found the problem with the KC705 flashing. When the XM105 FMC card is
 plugged in, it opens a switch on the KC705 between TDI and TDO at the FMC to
 make the JTAG chain go through the mezzanine card. On the XM105, TDI/TDO are
 simply connected to a 2.54mm pin header, which meant that the JTAG chain was
 broken. Somehow, some of the JTAG data still went through that circuit -
 enough to make FPGA detection, bitstream loading and a few other things work
 (unreliably). Vivado was more tolerant than xc3sprog regarding JTAG data
 corruption. Connecting TDI and TDO on the XM105 made xc3sprog flashing work
 reliably.

 So make sure to use a jumper between TDI and TDO on the XM105 when using it.


 Sebastien
 ___
 ARTIQ mailing list
 https://ssl.serverraum.org/lists/listinfo/artiq
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] kc705 flashing woes

[Joe Britton]

What remains to be done before a test of the DDS/TTL adapter board is
possible? -Joe

On Sat, Feb 28, 2015 at 4:39 PM, Sebastien Bourdeauducq s...@m-labs.hk wrote:
 Hi,

 we found the problem with the KC705 flashing. When the XM105 FMC card is
 plugged in, it opens a switch on the KC705 between TDI and TDO at the FMC to
 make the JTAG chain go through the mezzanine card. On the XM105, TDI/TDO are
 simply connected to a 2.54mm pin header, which meant that the JTAG chain was
 broken. Somehow, some of the JTAG data still went through that circuit -
 enough to make FPGA detection, bitstream loading and a few other things work
 (unreliably). Vivado was more tolerant than xc3sprog regarding JTAG data
 corruption. Connecting TDI and TDO on the XM105 made xc3sprog flashing work
 reliably.

 So make sure to use a jumper between TDI and TDO on the XM105 when using it.


 Sebastien
 ___
 ARTIQ mailing list
 https://ssl.serverraum.org/lists/listinfo/artiq
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] feedback on ARTIQ tutorial

[Joe Britton]

In planning for Sebastein's upcoming visit I'd like to propose

a) homework in advance for physicists

b) topics to cover in a group tutorial.

Please comment on additions/subtractions to the list below. -Joe



Homework in advance of hands-on

ARTIQ has adoped several tools and standards that promote collaboration and
code legibility. Read about these in advance.



PEP8

PEP8 is guidelines for writing python code. Homework:

   1. read PEP8 https://www.python.org/dev/peps/pep-0008/ style guide [0]
   2. practice using pyflakes: python -m flake8 your_file.py
   3. enable automatic PEP8 checking in your text editor
  - Spyder :: Preferences :: Editor :: Code Introspection ::
 - check pyflakes
 - check pep8
  - PyCharm :: google it
   4. read about python string formatting using .format() [1]



Sphynx markup

Sphynx is the documentation framework used by ARTIQ. It transforms in-line
comments in python files into easy to read documentation on github.

   1. read Function Definitions and Full Code Example here: [2]
   2. compare



git and github

Read the official git tutorial at git-scm.com/doc [3]. Selected chapters:

   - Getting Started
   - Git Basics
   - Git Branching
   - Git on the Server
   - GitHub
   - print out cheat sheet
   https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf
   [4]

ARTIQ

   1. get a copy of the latest Xubuntu ARTIQ virtual machine (VM) for
   VirtualBox, currently: 20150120_xubuntu_artiq
   2. instructions are on Jake [5]
   3. get your hands on a Pipalio Pro FPGA for testing out the ARTIQ code
   examples
  1. talk to Joe or Robert if you need help with the initial flashing
  of your Pipalio Pro; instructions are on github [7]. Everything is
  pre-compiled on the virtual machine so you should be able to start at the
  step Build and flash the bitstream and BIOS by running from the MiSoC
  top-level directory.
   4. read Sebastein's Getting Started [6] and try out the example code on
   your Xubuntu machine with a Papilio Pro board
   5. Work through the following examples in ~/artiq-dev/artiq/examples on
   your VM [7]
  1. flopping_f_simulation.py
  2. transport.py
  3. if you get stuck makes notes to ask during the discussion with SB

Controllers

Read about how to build a controller to support a piece of hardware in your
lab. [8]





[0] https://www.python.org/dev/peps/pep-0008/

[1] https://docs.python.org/2/library/string.html

[2]
https://pythonhosted.org/an_example_pypi_project/sphinx.html#function-definitions

[3] git-scm.com/doc

[4] https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf

[5] O:\Public\penning_britton\shared\artiq

[6]
https://github.com/jboulder/artiq/blob/master/doc/manual/getting_started.rst

[7] https://github.com/jboulder/artiq/tree/master/examples

[8]
https://github.com/jboulder/artiq/blob/master/doc/manual/writing_a_driver.rst



Tutorial with Sebastien

Proposed topics for SB to do at a tutorial session. The hands-on in the
Penning lab during SB's last was a bit chaotic. I think it would be easier
to learn together if we're all seated in a conference room with laptops
(running Xubuntu ARTIQ). SB can lead the discussion from a projector. SB
has hardware and oscilloscope, everyone else just has laptop.

ARTIQ Tutorial

In front of the class...

   1. demo: agile phase/frequency demo of DDS
   2. demo: define new fitting function
   3. demo: query and update of Parameter database
   4. basic GUI workflow: e.g. Glade layout, what are required files?

hands-on practice by physicists

   - write a spin-echo simulation from scratch
  - plot: real-time phase-flopping on last pi/2 pulse
  - plot: real-time histogram
  - save: save data to disk
  - open data in Matlab or python
   - write calibrate pi-time simulation from scratch
  - flop, fit and update Parameter Database
  - schedule to run automatically every 90 seconds
  - interleave some other experiment



Driver Tutorial

Talk through what a driver is supposed to do. Walk through an example
driver.



Code Contribution

Give example of contributing code to github. This can be quick run though
the workflow since everybody should already have read the git
documentation. This is an opportunity to discuss questions and cultural
aspects of a collaborative codebase.

On Fri, Feb 6, 2015 at 1:06 AM, Robert Jördens jord...@gmail.com wrote:

 On Tue, Feb 3, 2015 at 9:37 AM, Bohnet, Justin G.
 justin.boh...@nist.gov wrote:
  I know that I am in need of some of the more fundamental skills.  To
 clarify, you are suggesting a tutorial in the format that John suggested,
 but explaining just things like git, python programming in general, and how
 to write basic experiments in artiq?  If so, I think that sounds useful for
 me at least.

 I suspect that for the fundamental skills a tutorial would take at
 least as much time as self-study based on existing documentation. But
 that does not 

Re: [ARTIQ] artiq dependencies

[Joe Britton]

I advocate adding options to setup.py to include these dependencies if a
user want's them.

I think it would make sense to fork external dependencies into m-labs/artiq
so that dependencies don't break over time.

-Joe

On Wed, Jan 28, 2015 at 8:39 AM, Yann Sionneau y...@m-labs.hk wrote:

 Hello,

 I'm wondering about which kind of dependencies we should enforce in ARTIQ
 installer (setup.py).
 For instance, if an ARTIQ device (PDQ2, Lda, Thorlabs TDC/TPZ, PXI6733)
 needs a Python dependency (PyDAQmx here for PXI6733), should we put it in
 setup.py thus enforcing it's installation?

 Or should we just document that dependency and let the user install only
 what he needs.

 For instance, one might just want to install ARTIQ to run the GUI/the
 master but would for instance not need to run a controller (at least not on
 this particular computer). For just running the master you don't need the
 driver dependencies.

 Regards,

 --
 Yann Sionneau
 ___
 ARTIQ mailing list
 https://ssl.serverraum.org/lists/listinfo/artiq

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

Re: [ARTIQ] driver integration

[Joe Britton]

It looks like this is still not working right. Here's the code that I'm
running.

https://github.com/jboulder/penning/tree/master/artiq/demos/zero_freq_modes

Start the controller on the local host.
$ python3 novatech409B_controller.py

On the local host, confirm that I can communicate with the controller from
the command line.
$ python3
~/artiq-dev/artiq/artiq/devices/novatech409B/novatech409B_client.py gain 1.0

On the local host, try to run the ARTIQ experiment.
$ python3 ~/artiq-dev/artiq/artiq/frontend/artiq_run.py zero_freq_modes.py

No error it just hangs.

What am I doing wrong? -Joe

On Mon, Jan 26, 2015 at 7:05 PM, Sébastien Bourdeauducq s...@m-labs.hk
wrote:

 On 01/27/2015 10:03 AM, Joe Britton wrote:
  class LED(AutoDB):
  class DBKeys:
  led = Device()
  penning_rotating_wall = Device()
  penning_rotating_wall.set_freq_all_phase_continuous(0.05)

 DBKeys is only a description of what object attributes needs to be
 linked to the databases. You cannot use the devices there; instead, do
 this:

 class DBKeys:
penning_rotating_wall = Device()

 def build(self):
self.penning_rotating_wall.set_freq_all_phase_continuous(0.05)

 Your entry in ddb.pyon will create the driver locally without going over
 the network, but this might be what you want. If you want to use the
 controller, use (for now) the artiq.protocols.pc_rpc.Client class in ddb.

 Sébastien

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

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

Re: [ARTIQ] PXI6733 controller

[Joe Britton]

Thank you for the question Yann.  I spoke with John Gabler and Dan Slichter
here at NIST and came up with the following advice.

There's no need for the 6733 controller to run on a Linux machine. I've
found the NI libraries on Windows to be reasonably straightforward
(NI-DAQmx libraries with C++). I recommend building to a binary.dll then
writing a python interface (using e.g. ctypes) for artiq.

I'll send you a copy of the code we currently use as part of our HFgui
environment. I recommend taking a look at QC-DAQ\src\6733wfm to see how
this was coded in the past; reuse as much as you can. From an interface
perspective it would be excellent if the 6733 looked identical to the PDQ
interface. Some differences:
* 6733 doesn't support waveform branching
* The waveform advance pulse to the 6733 is what causes its output to
transition from one ADC channel (voltage) to another. We usually generate
this pulse from the FPGA not from a periodic clock (eg crystal oscillator).
This makes it possible to a) conserve memory on the 6733 when a static
output is desired and b) reduce noise on the 6733 analog outputs (its more
noisy when being clocked).

-Joe



On Tue, Jan 20, 2015 at 3:55 AM, Yann Sionneau y...@m-labs.hk wrote:

 Hello,

 I'm trying to implement a controller for NI PXI 6733 even if I didn't
 receive the hardware yet.
 First task was to pick a library/driver to control it.

 So far I found 4 python libraries: PyDAQmx, pylibdaqmx, pycomedilib
 (debian package name python-comedilib) and pycomedi.
 I wasn't able to make any of them work under Linux for various reasons
 (python 3 vs python 2, or crashing while loading some shared library).
 I was able to import and call a few functions (under Windows 7) of PyDAQmx
 which makes it a potential candidate.

 Is the PXI 6733 used on Linux machines? Is there a real need for a Linux
 controller?

 Thanks!

 Regards,

 --
 Yann
 ___
 ARTIQ mailing list
 https://ssl.serverraum.org/lists/listinfo/artiq

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

Re: [ARTIQ] PXI6733 controller

[Joe Britton]

 Does the FPGA need to generate one pulse per DAC sample?
Yes, one pulse is required per sample. One way of doing this might be to
have a fixed frequency clock that is gated by a RTIO channel.

On Wed, Jan 21, 2015 at 7:46 PM, Sébastien Bourdeauducq s...@m-labs.hk
wrote:

 On 01/22/2015 02:08 AM, Joe Britton wrote:
  * The waveform advance pulse to the 6733 is what causes its output to
  transition from one ADC channel (voltage) to another. We usually
  generate this pulse from the FPGA not from a periodic clock (eg crystal
  oscillator). This makes it possible to a) conserve memory on the 6733
  when a static output is desired and b) reduce noise on the 6733 analog
  outputs (its more noisy when being clocked).

 Does the FPGA need to generate one pulse per DAC sample?

 Sébastien

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

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

Re: [ARTIQ] ARTIQ development system

[Joe Britton]

Viviado product.
- The WebPack version of ISE is 18 GB in size. Since its so big I've
installed it on a secondary virtual hard disk called
xubuntu_artiq_xilinx.vdi. This disk is mounted in the virtual machine at
/opt/Xilinx. This secondary image is required only if you aspire to
generating .bit files.


- Working with USB


- The USB 2.0 controller is enabled in the VirtualBox disk image.
- It is necessary to forward the FPGA board's USB interface to the
Xubuntu virtual machine. Just put a tick mark adjacent to the right USB
device in the Settings :: USB :: USB Device Filters menu. On my machine the
Papilio Pro shows up as FTDI Dual RS232.
- Robert and I confirmed that the development system can successfully
compile and write the Artiq .bit file to a Papilio Pro. This was tested on
a Windows 7 host OS.



 Joe Britton
 NIST - Div 688
 325 Broadway
 Boulder, CO 80305
 303.497.7295
 *brit...@nist.gov* brit...@nist.gov




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


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

Re: [ARTIQ] Phase Control

[Joe Britton]

Thank you for offering several API alternatives Sebastian.

I can't think of any scenario where the phase behavior of a DDS would need
to change in the midst of an experiment. It's also probably technically
easier to set a DDS's phase behavior at the outset of an experiment
sequence. Daniel, please correct me if I'm wrong on this. I therefore favor
the syntax which is global and less verbose.

self.dds.set_phase_mode(PHASE_CONTINUOUS)
self.dds.set_phase_mode(PHASE_ABSOLUTE)
self.dds.set_phase_mode(PHASE_TRACKING)

If anybody can think of a motivation to change the phase behavior in the
midst of an experiment please speak up.

-Joe

On Tue, Nov 4, 2014 at 8:44 AM, Gaebler, John john.gaeb...@nist.gov wrote:



 Which API do you prefer?

 I think the several-function API sounds nice because it makes it more
 transparent what will happen with each dds set.

 Turn the pulse (respectively on) function into three functions:
 pulse_continuous, pulse_absolute, pulse_tracking (respectively on_***).
 The last two would take an additional phase offset parameters.

 I think the pulse_continuous should also be able to take a phase offset
 parameter, however, here it is understood that the phase accumulator will
 not be reset.
 -John

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

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