[ARTIQ] Sinara design & layout review
We're in the final stretch of Sinara schematic review (0.1rc) and ready to tackle Sinara layout review (0.1). On the current timeline, testing of v0.1 prototype hardware will commence in Jan 2017. For those on the mailing list please note that most of the discussion is taking place in the form of github Issues. Design files are in the repository. https://github.com/m-labs/sinara/issues https://github.com/m-labs/sinara/ Here's my view on Issues outstanding. https://github.com/m-labs/sinara/projects/6 Prospective users of the Sinara system may like to weigh in on design of the Kasli PCB (led by M-Labs) and on IO breakout from Metlino/Kasli (led by Warsaw Technical University). https://github.com/m-labs/sinara/issues/129 https://github.com/m-labs/sinara/issues/99 Ping @jordens to join the Sinara project on github. https://github.com/jordens -Joe --- Joe Britton Sensors and Electron Devices Army Research Lab 2800 Powder Mill Rd Adelphi, MD 20783 301-394-3130 joseph.w.britton5@mail.mil ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Survey of ARTIQ User Community (April 2017)
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] ARTIQ Digest, Vol 37, Issue 6
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
Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 7
>>> and what speed grade? >> >> I would advocate for the 50T in -2 speed grade for two main reasons: >> a) I don't think we need that much FPGA resources for the 100T to be needed. >> b) -2 speed grade transceivers go to 6.25Gbps whereas -1 speed grade >> ones go to 3.75Gbps. In addition to a significant increase in bandwidth, >> the -2 transceivers can use the same configuration on the Metlino/Sayma >> side which is used for the backplane (5Gbps). Otherwise we would have to >> generate another set of Ultrascale transceiver settings (and shave a >> yak) and potentially deal with weird RTIO frequency ratios in a hybrid >> MTCA/Eurocard Sinara system. >> >> Sébastien >> >> >> -- >> >> Subject: Digest Footer >> >> ___ >> ARTIQ mailing list >> https://ssl.serverraum.org/lists/listinfo/artiq >> >> -- >> >> End of ARTIQ Digest, Vol 37, Issue 6 >> >> ___ >> ARTIQ mailing list >> https://ssl.serverraum.org/lists/listinfo/artiq >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <http://ssl.serverraum.org/lists-archive/artiq/attachments/20170629/dbb942dc/attachment-0001.html> >> >> -- >> >> Message: 3 >> Date: Thu, 29 Jun 2017 21:37:27 +0800 >> From: Sébastien Bourdeauducq >> To: Thomas Harty , >> "artiq@lists.m-labs.hk" >> Subject: Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6 >> Message-ID: <3a746c22-f1d0-a33a-58a9-8bcd30fce...@m-labs.hk> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> On Thursday, June 29, 2017 06:16 PM, Thomas Harty via ARTIQ wrote: >>> The fact that going for a 75T/100T gives us access to 12EEMs/Kasli (4 >>> on the BP) rather than 10EEMs/Kasli (only 2 on the BP) for the 50T is >>> an added benefit. >> Kasli was meant to be a simple and low-cost board without a backplane, >> and you are now using the backplane as an argument... >> >> >> -- >> >> Message: 4 >> Date: Thu, 29 Jun 2017 15:43:00 -0400 >> From: Joe Britton >> To: Sébastien Bourdeauducq >> Cc: "artiq@lists.m-labs.hk" , Thomas Harty >> >> Subject: Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6 >> Message-ID: >> >> Content-Type: text/plain; charset="UTF-8" >> >> 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 >> >> >> -- >> >> Message: 5 >> Date: Thu, 29 Jun 2017 21:55:16 +0200 >> From: Grzegorz Kasprowicz >> To: Joe Britton >> Cc: "artiq@lists.m-labs.hk" , Thomas Harty >> >> Subject: Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6 >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Usually one can expect half of octopart prices. >> So the difference would be about 30$ >> >> On 29 June 2017 at 21:43, Joe Britton via ARTIQ >> wrote: >> >>> 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 >>> >> -- next part -- >> An HTML attachment was scrubbed... >> URL: >> <http://ssl.serverraum.org/lists-archive/artiq/attachments/20170629/ab4bb70a/attachment.html> >> >> -- >> >> Subject: Digest Footer >> >> ___ >> ARTIQ mailing list >> https://ssl.serverraum.org/lists/listinfo/artiq >> >> -- >> >> End of ARTIQ Digest, Vol 37, Issue 7 >> > > ___ > 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
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] July status report
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
Re: [ARTIQ] Pipistrello Install Issue
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] Pipistrello Install Issue
> I've followed Chris' suggestion and artiq 2.4 is listed in my environment's packages. >I can find artiq_flash.py files in my file manager but these are not able to be called. >Would this be something to do with paths? Will Just now I followed Ballance's instructions. And confirm I can run artiq_browser from the command line. I'm using Ubuntu 14.04 and Conda 4.3.22. On Fri, Jul 28, 2017 at 10:06 AM, Joe Britton wrote: > Also be sure you're using ARITQ 2.x. See Release Notes. > > https://github.com/m-labs/artiq/blob/471605ec1ed951f9033472a19c0428 > 7494978d49/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
[ARTIQ] Should we use StackExchange?
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&A. 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&A 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
[ARTIQ] ARTIQ SPI PHY, differential driving
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
Re: [ARTIQ] ARTIQ SPI PHY, differential driving
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
Re: [ARTIQ] Example Ion Trap Code
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&A. Ideally the Q&A 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 representation >> of the sorts of questions/co
Re: [ARTIQ] Example Ion Trap Code
Hi Aaron. Great to hear there's interest in making baseline code for NV's using ARTIQ. Not sure how much overlap there is between the base ion and NV system but agreed that it's good to try to minimize duplication. -Joe On Wed, Sep 20, 2017 at 10:58 AM, Aaron R Vontell wrote: > Hello ARTIQ Team, > > I’d be interested in learning more and connecting regarding the development > of this ion trap library. I am beginning to design a generic “operating > system” using ARTIQ for my undergraduate research, but for Nitrogen vacancy > centers in diamond. My background is in computer science and software > development (not physics or math) so I may be of some use in the context of > making the library as easy to use as possible. Most of all, it would be nice > to have a collective repository to minimize overlap of the code for these > two systems. I am imagining that this might spawn a generic quantum > information operating system which connects to modules which use ion-trap > vs. NV vs. other qubit mediums. > > Aaron Vontell > MIT Class of 2018 > MIT Quantum Photonics Lab | MIT Decentralized Information Group > > On Sep 14, 2017, 7:10 PM -0400, Joe Britton via ARTIQ > , wrote: > > 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&A. Ideally the Q&A > 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
Re: [ARTIQ] ARTIQ SPI PHY, differential driving
This was discussed on IRC too... https://irclog.whitequark.org/m-labs/2017-09-13 https://irclog.whitequark.org/m-labs/2017-09-15 https://irclog.whitequark.org/m-labs/2017-09-16 https://irclog.whitequark.org/m-labs/2017-09-17 The Q&A is much appreciated but we still don't have a solution that works. It looks like rather greater knowledge of MIGEN is required. M-Labs, please provide code so Arpit can contribute at the ARTIQ Python level and steer clear of not-yet fully documented aspects of Migen. AFACT this is needed for integration of any of the EEM modules with VHDCI_carrier. Arpit can't contribute to testing and driver writing for Zotino if he remains stuck on this bump. -Joe On Wed, Sep 13, 2017 at 1:35 PM, Joe Britton wrote: > 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
Re: [ARTIQ] Error Installing Rust
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] Error Installing Rust
> We were following the instructions from the link you attached; conda worked > for installing rust. Your email to the list started out with a question related to compiling rust. Now you say you were installing rust from conda. Don't try to mix the two approaches. The conda-dev path should be squeaky clean with no errors since it's used by the build bot for automated builds. I just did a spot test installing ARTIQ 3 from the conda dev channels on a Windows 10 machine on top of a fresh install of 64-bit Anaconda. Following these instructions and got no errors. http://www.m-labs.hk/artiq/manual-master/developing.html#artiq-anaconda-development-environment To test the phaser gateware on kc705 there's also a precompiled bitfile. Then you don't have to build using Vivado. This conda .bit is discussed here: http://www.m-labs.hk/artiq/manual-master/core_device.html?highlight=phaser#phaser I triggered a build of the latest version of this .bit file artiq-kc705-phaser. (a3t2) c:\shared\github\m-labs\artiq> conda search artiq-kc705-phaser 3.0.dev py_1295+gitc00b3fe8 m-labs/label/dev But when I install it there are unsatisfied dependencies. Do you see this too? (a3t2) c:\shared\github\m-labs\artiq>conda install artiq-kc705-phaser Fetching package metadata ... Solving package specifications: PackageNotFoundError: Dependencies missing in current win-64 channels: - artiq-kc705-phaser -> artiq 3.0.dev py_1183+gitf4624e08 -> llvmlite-artiq 0.12.0.dev py35_30 - artiq-kc705-phaser -> artiq 3.0.dev py_1183+gitf4624e08 -> python-dateutil - artiq-kc705-phaser -> artiq 3.0.dev py_1183+gitf4624e08 -> pythonparser >=1.1 (and similarly for the other packages) On Sun, Sep 24, 2017 at 8:03 PM, Joe Britton wrote: > 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
[ARTIQ] Sayma bootstrapping
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] Sinara (Kasli, Urukul, Novo, Zotino...) batch sizing
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
Re: [ARTIQ] monthly status report
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] We have ARTIQ RF out of Sayma!
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!
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!
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] Sayma input frequency
My comment echos Daniel's. Getting 150 MHz reference oscillators is a special order. What's the motivation to switch to 150 MHz? On Tue, Jun 19, 2018 at 12:06 PM, Kristin Beck via ARTIQ < artiq@lists.m-labs.hk> wrote: > I already have a 100MHz (non-programmable) clock in the lab, so I prefer > to continue supporting that in all levels (firmware, hardware, etc.) in the > long term. That said, the workarounds are not too onerous for getting up > and running initially--either Dan's suggestion of a non-standard 150MHz > clock or Tom's suggestion of modifying the dividers in our lab-specific > bitstream build would allow us to see full performance in the lab for > device testing. > > Best, > Kristi Beck > > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq > > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> 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
[ARTIQ] ARTIQ/Sinara, fedtech.io
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
[ARTIQ] 2018 ARTIQ/Sinara User Survey
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