[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  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  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
>  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  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