[ARTIQ] test
Testing new Mailman options that hopefully will stop triggerring the NIST/Microsoft email spoofing detector. Can someome from NIST reply to this message and confirm that they don't get "This sender failed our fraud detection checks" messages anymore? ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] test
--- Begin Message --- Another test On Thursday, December 01, 2016 01:24 PM, Sébastien Bourdeauducq via ARTIQ wrote: Testing new Mailman options that hopefully will stop triggerring the NIST/Microsoft email spoofing detector. Can someome from NIST reply to this message and confirm that they don't get "This sender failed our fraud detection checks" messages anymore? ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq --- End Message --- ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 2.1 released
Hi, ARTIQ 2.1 is out and is a simple bugfix release. We recommend that all 2.0 users upgrade. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ users meeting
Hi, The idea of organizing an in-person meeting for current and prospective ARTIQ users has been floating for a while. We'd like to get a conversation started on this topic. Some of this email is taken from Joe's GitHub issue #582. * Venue? some ideas: NIST, JQI, DESY, Oxford, CERN, Warsaw University of Technology, Chinese University of Hong Kong. * It would be convenient to have it before or after an existing physics conference (e.g. APS DAMOP 2017 is June 5-9 in Sacramento, CA) * We need organizers taking care of logistics, publicity, conference program, social activities, catering. * M-Labs can hold several tutorials/workshops. * What would you like to see at such a conference? * Would you present something? * Would you attend a conference if it were on your continent? Another continent? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] plans for clock chip, JESD and DAC initialization/configuration
Hi, Before DRTIO can operate, the clock chip (HMC* on Sayma and AD9516 on KC705) needs to be running. This setup should be done by the comms CPU on the DRTIO master, and the management CPU on a DRTIO satellite. For initialization, the comms or management CPU would configure the clock chips and bring up the JESD links. The clock chip and JESD code currently in https://github.com/m-labs/artiq/blob/master/artiq/examples/phaser/startup_kernel.py should be moved to the Rust runtime and the Rust DRTIO satellite manager. The SPI core would be connected to the comms CPU. It seems desirable to alter DAC settings in the experiment. Perhaps this feature can be deferred. When we need it, it can be done as follows: * the kernel CPU sends a request to the comms CPU via the mailbox. Since the comms CPU already knows about the DAC as it needs to initialize it, the request should be on a similar level of abstraction, i.e. it should be something like "enable mix mode" and not "write X to SPI register Y". * if the DAC is on the local board, the comms CPU performs the SPI transaction. * if the DAC is on a remote board, the comms CPU sends an auxiliary DRTIO packet to the relevant board, and its management CPU performs the SPI transaction, then sends an acknowledgement auxiliary packet back. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] plans for clock chip, JESD and DAC initialization/configuration
On Saturday, December 17, 2016 12:02 PM, Sébastien Bourdeauducq via ARTIQ wrote: Before DRTIO can operate, the clock chip (HMC* on Sayma and AD9516 on KC705) needs to be running. Strictly speaking: this is needed only for the two-KC705 system. But we might as well use the same scheme everywhere, and it avoids the corner case of operating the kernel CPU with no RTIO clock running. The generic chip configuration code should go in firmware/libbsp. With the RTM FPGA, SPI will have to go over the SERDES link. I'm still thinking about a generic "I/O expander" similar to mini-DRTIO; we can have half-rate, quarter-rate, etc. updates for some pins in order to save bandwidth. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ users meeting
On Monday, December 19, 2016 10:08 PM, Slichter, Daniel H. (Fed) via ARTIQ wrote: It seems that JQI would be a good potential location because: Sounds good. Jonathan, Joe, Jason - what do you think about hosting such a meeting? * Would you present something? Depending on the structure and goals of the conference, the NIST group would likely be interested in presenting as appropriate. Noted, thanks for your support. Any other groups? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 2.2 released
Hi, ARTIQ 2.2 is available, and contains bugfixes (SPI and some compiler corner cases) and a relicensing under LGPL. The new license resolves concerns about experiments being potentially considered derived works under the GPL. We encourage all users to update to 2.2. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Sinara progress report
Hi, here is a status report on some key gateware tasks relevant to the support of the Sinara hardware. Sébastien sinara-2017-02.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] starter ARTIQ hardware for neutral atoms
Hi, On Wednesday, March 08, 2017 06:11 AM, Neal Pisenti via ARTIQ wrote: * For ARTIQ core device, we would ideally jump straight to using a Kasli, but as that isn't likely to be done in the next few months, I was planning to use a KC705 as the core. The "EEM" DDS/synth Kasli extensions may not necessarily be ready before Kasli. So I don't see how the KC705 helps - is it because you want more extensions that one Kasli would support? Supporting this KC705 scheme is more gateware development and one more configuration that needs to be documented, packaged and maintained. Maintainance means that we need to check regularly (preferably automatically) that it keeps working when we modify ARTIQ and fix any bugs that pop up. It takes work. * KC705 has 2x FMC headers, which would drive 1x VHDCI carrier card, providing 8x IDC for EEMs. We would buy FMC -> VHDCI adapters for this interconnect. What adapters in particular? http://www.ohwr.org/projects/fmc-vhdci? We didn't check compatibility of any of those. **Specific questions**: * what limitations are there (latency/bandwidth/etc) on daisy-chaining additional Kasili DRTIO modules off of the single KC705 SFP? While the hardware could do it, daisy-chaining Kaslis is not supported by the current gateware plans. The plan is to use a Metlino, which has many available transceiver links (mostly to the microTCA backplane, but there are also 3 SFPs), as a central device with a direct link to every satellite device. If daisy-chains are implemented, there would be virtually no impact on bandwidth, and the latency would increase by roughly ~100-200ns per hop. Instead of the daisy chain, it is also possible to have one Kasli as central device driving directly other Kaslis with its SFPs (note that one SFP will be used for Ethernet). There are no current gateware plans for this either (so this would need funding), but it is less difficult to develop and has less latency. * Is there an estimate on the timescale for finished Kasli? It is not funded yet, but I think this should happen in a few months. Then there will be another few months before it begins to become usable. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] [RFC] remove RTIOCollision
Hi, RTIOCollision is a bit tedious to implement with DRTIO, since the master does not know if a given channel should do replace or collision. The satellite would need to report this information for each of its channels (and this also needs to be passed from the gateware scripts to the satellite manager firmware), then the master should program it into its gateware. Do we strongly need it, or can we simply have the replace behavior at all times? According to this mailing list discussion, the replace behavior is actually wanted: https://ssl.serverraum.org/lists-archive/artiq/2016-November/001052.html Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [SINARA] hardware arrived!
On Friday, March 17, 2017 07:34 AM, Grzegorz Kasprowicz via ARTIQ wrote: look here https://cloud.githubusercontent.com/assets/4325054/24015076/98f7653a-0a87-11e7-93d2-7df1831b2422.jpg Looks nice! Thanks for all your work! ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 2.3 released
Hi, ARTIQ 2.3 is available and fixes various bugs that were present in 2.2. We encourage all users to update to 2.3. When using conda, make sure to add the conda-forge channel before updating, as ARTIQ now depends on the new pyqtgraph 0.10 package available there. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Fwd: North American Conference on Trapped Ions
Hi, I would like to relay the information about this upcoming conference on trapped ions organized at NIST Boulder. M-Labs will be participating with an exhibit (including some Sinara boards) and the hosting of a networking event and panel discussion at Sanitas Brewery one evening. The panel will be on the future of control systems for quantum information experiments. Conference registration has recently opened and costs US$431 catered, US$250 non-catered. Abstract deadline: July 1 Registration deadline: August 1 Conference dates: August 14-18 The conference would be a great opportunity for the ARTIQ community to get together. We are looking forward to seeing you there! Sébastien Forwarded Message Subject:North American Conference on Trapped Ions Date: Sun, 19 Feb 2017 17:40:35 + From: Allcock, David T. (IntlAssoc) To: Wilson, Andrew C. (Fed) Dear Members of the International Ion Trap Community, The Ion Storage group at NIST Boulder will be holding a new Ion Trap Conference at our laboratory. The conference will be similar in scope and aims to the European Conference on Trapped Ions (ECTI) but with a corresponding emphasis on North American research. We hope for this to become a regular series, running on alternate years to ECTI. If you are interested in attending, please add the following dates to your diary: 1st North American Conference on Trapped Ions NIST Boulder Campus, Colorado USA August 14-18 2017 https://www.nist.gov/news-events/events/2017/08/1st-north-american-conference-trapped-ions More details and a registration link will be posted on the website in about a month and we will email you again at that time. Until then please feel free to make suggestions and pass this email on to colleagues and team members who may be interested. Sincerely, David Allcock & Andrew Wilson (For the NIST Ions) ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 2.4 released
Hi, ARTIQ 2.4 is now available and fixes problems related to the packaging system, in particular the "Failed to create process" message that appeared on Windows when trying to run the front-end programs. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Kasli FPGA selection
On Wednesday, June 28, 2017 04:52 PM, Thomas Harty wrote: Have we settled on the 50T as the FPGA for the first version of Kasli, 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 ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6
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... ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Kasli FPGA selection
On Friday, June 30, 2017 07:54 PM, Grzegorz Kasprowicz via ARTIQ wrote: additional 30$ does not make any difference. OK, fine. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] August 2017 status report
Please see the attached PDF. 2017-August.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Should we use StackExchange?
Joe, Why is this better than the mailing list? And why add another place to get support? On Sunday, August 13, 2017 05:10 PM, Joe Britton via ARTIQ wrote: - news and topics of community-wide interest (https://ssl.serverraum.org/lists/listinfo/artiq) The mailing list was never intended for news only, otherwise not every subscriber could post. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Example Ion Trap Code
David Allcock wrote (on github): To get from a bare ARTIQ installation to a working ion trap experiment requires writing a lot of code and making a lot of low level decisions about how to handle things like data and scanning variables. This seems to be having two effects: Smaller groups are put off using ARTIQ as they don't have the resources to do this. A group leader at NACTI said they were setting up a new trap and asked me how much work it would be to get it up and running assuming they had turnkey hardware (ie Kasli and a bunch of EEMs). Based on our experience I said it would be 3-6 months depending on how much previous programming the student had done. This was clearly too long and they said they'd probably just replicate the kludgy pile of odds and ends they’re running their current trap off. Groups that are planning to use ARTIQ are starting to request code examples from our lab to get an idea of what they need to do. 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. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] September status report
Please see the attached PDF. 2017-September.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.0 released
Hello, After a year since the last major release, we are pleased to announce ARTIQ 3.0. There were ~1300 commits since 2.0, for many different features such as RTIO DMA that can dramatically improve the throughput of long pulse sequences, and asynchronous RPCs to speed up the reporting results from the core device, and dashboard applet control from experiments. ARTIQ-3 contains demonstrations on the KC705 board for two new major features that will be fully developed in ARTIQ-4 on the Sinara hardware: distributed RTIO, that enables multi-FPGA many-channel RTIO systems, and the SAWG, a "DDS on steroids" using multi-GSPS DACs connected directly to the FPGA. We made major improvements to the PDQ waveform generator, which requires ARTIQ-3 but now lives in its own repository: https://github.com/m-labs/pdq The core device runtime saw a complete rewrite in Rust, and it now uses a new TCP/IP stack that we developed that should fix stability and performance issues encountered with lwIP. The complete commit history is at https://github.com/m-labs/artiq/commits/release-3 Functional changes that merit attention and may require user action are described in the release notes: https://m-labs.hk/artiq/manual-release-3/release_notes.html We recommend that users of ARTIQ 2.Y upgrade to 3.0. We plan to release ARTIQ 2.5 soon, after which we will cease maintainance on the 2.Y releases. The pre-built packages are available under the "main" conda label. Instructions on how to get started with ARTIQ are at https://m-labs.hk/artiq/manual-release-3/installing.html Due to conda problems, 32-bit Windows packages are no longer available, and may come back after Python 3.6 support lands (#652). We do not plan to add features to the release-3 branch and subsequent 3.Y release that change behavior or APIs: the focus will be on bugs. We will continue to track those at: https://github.com/m-labs/artiq/issues As always, please report issues and bugs through the usual channels. Meanwhile work is continuing towards ARTIQ 4.0 and several new features are already implemented. ARTIQ-4 will contain support for the new Sinara hardware (Sayma, Metlino, Kasli and their peripherals) plus a new, more scalable RTIO architecture (#778). Please feel free to forward this message to other interested users. The ARTIQ team. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 2.5 released
Hello, We have just released ARTIQ 2.5 and new conda packages are available. This is a bugfix release that you can use if you do not wish to move to ARTIQ-3 yet. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] October status report
Please see the attached PDF. 2017-October.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Instantiating tri-state buffer in migen
On Saturday, October 07, 2017 09:13 AM, Arpit Agrawal via ARTIQ wrote:
return Instance("IOBUFDS",
i_I=self.i, o_O=self.o, i_T=self.oe,
OE means "output enable". T means "tristate", i.e. not driving. You need
to invert that signal.
Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] scans and generators on core device?
Hi, to implement scans on the core device (https://github.com/m-labs/artiq/issues/118) in the best way possible, we need some information about how ARTIQ is used and will be used: * are Python generators (i.e. using "yield") something that you know about, use, and would like to see supported inside kernels? * are you using MultiScanManager? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] scans and generators on core device?
Hi, Judging from the absence of replies to this email, we will not support generators on the core device nor MultiScanManager. Sébastien On Tuesday, October 10, 2017 02:34 PM, Sébastien Bourdeauducq wrote: Hi, to implement scans on the core device (https://github.com/m-labs/artiq/issues/118) in the best way possible, we need some information about how ARTIQ is used and will be used: * are Python generators (i.e. using "yield") something that you know about, use, and would like to see supported inside kernels? * are you using MultiScanManager? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] scans and generators on core device?
On Friday, October 20, 2017 12:36 AM, Slichter, Daniel H. (Fed) wrote: Judging from the absence of replies to this email, we will not support generators on the core device nor MultiScanManager. My main question with this is about time efficiency -- if you were to go to the effort to support this on the core device Note that scans can be supported on the device with just iterators and not generators (as explained in the issue). Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] November status report
Please see the attached PDF. 2017-November.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] test
Please disregard this message. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] SFP/SATA cables for connecting Ethernet on Sayma
Hi Greg, just a quick note about the SFP/SATA cable that is necessary to connect Ethernet on a Sayma directly. I suggest building them from a passive SFP copper cable (e.g. http://www.fs.com/products/36649.html) cut in half, with a male (motherboard or disk) connector soldered at the end. Some switches or media converters require a EEPROM or the LOS signal that the copper cable provides, and the male connector is more solid mechanically than soldering a SATA cable inside a SFP. The cable I got from you had its transceiver line connections damaged, plus it cannot work on my media converter due to the missing EEPROM or LOS (not sure which - LOS would be relatively easy to fix, just connect to ground). The FS.com cable above is properly detected. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] December status report
Please see the attached PDF. 2017-December.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.1 released
Hi, ARTIQ 3.1 is released and contains mostly fixes for networking bugs (ARP storm under some conditions, and packet losses with switches sending truncated Ethernet preambles). We recommend that all users upgrade to 3.1. Networking issues #845 and #848 will be addressed in a future release. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] January 2018 report
Here is the current report. Happy new year everyone! Sébastien 2018-January.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] January 2018 report
Clarification: the sentence "After reflashing the MMC firmware to make the Ethernet PHY operate correctly in MII mode (which WUT managed to do, but could not be reproduced)" is not criticism of WUT's work regarding the Ethernet issue. I am simply describing what the Ethernet situation is, and why we have still not managed to obtain a working Ethernet connection to Sayma. WUT have been very helpful and supportive of the effort to make Ethernet work on Sayma. They also have started making SATA/SFP adapters on PCB to replace the fragile cable-based hacks, which I forgot to mention in the report but I'm happy about. Sébastien On Thursday, January 04, 2018 02:41 PM, Sébastien Bourdeauducq via ARTIQ wrote: Here is the current report. Happy new year everyone! Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.2 released
Hello, We have released ARTIQ 3.2 today, which contains further Ethernet bugfixes, and now display backtrace information on runtime panics to make tracking down problems easier and faster. To accommodate the larger runtime, the flash layout as changed. As a result, the contents of the flash storage will be lost when upgrading. Set the values back (IP, MAC address, startup kernel, etc.) after the upgrade. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Single-board ARTIQ/Kasli system now operational
Hi everyone, We have completed the ARTIQ core development for Kasli in single-board configurations (i.e. without DRTIO). This includes DDR3 support, and 1000BASE-X Ethernet PHY using Artix-7 GTP transceivers. The full ARTIQ runtime works properly on the board and is ready to execute kernels over Ethernet. Development of the Urukul driver (both AD9910 and AD9912) is under way and progressing rapidly; a sizable part of it can already be found in the repository. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] We have ARTIQ RF out of Sayma!
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.
diff --git a/artiq/firmware/libboard_artiq/hmc830_7043.rs b/artiq/firmware/libboard_artiq/hmc830_7043.rs
index ee456beb9..ca0a296b7 100644
--- a/artiq/firmware/libboard_artiq/hmc830_7043.rs
+++ b/artiq/firmware/libboard_artiq/hmc830_7043.rs
@@ -22,7 +22,7 @@ mod clock_mux {
csr::clock_mux::out_write(
1*CLK_SRC_EXT_SEL | // use ext clk from sma
1*REF_CLK_SRC_SEL |
-1*DAC_CLK_SRC_SEL);
+0*DAC_CLK_SRC_SEL);
}
}
}
@@ -191,6 +191,6 @@ mod hmc7043 {
pub fn init() -> Result<(), &'static str> {
clock_mux::init();
-hmc830::init()?;
+//hmc830::init()?;
hmc7043::init()
}
# openocd -f sayma_new.cfg -c "pld load 0 rtm.bit; exit"
# openocd -f sayma_new.cfg -c "pld load 1 amc.bit; exit"
interface ftdi
ftdi_device_desc "Quad RS232-HS"
ftdi_vid_pid 0x0403 0x6011
# if there are multiple Sayma:
#ftdi_location 5:2
ftdi_channel 0
# EN_USB_JTAG on ADBUS7: out, high
# nTRST on ADBUS4: out, high, but R46 is DNP
ftdi_layout_init 0x0098 0x008b
reset_config none
adapter_khz 5000
transport select jtag
source [find cpld/xilinx-xc7.cfg]
set CHIP XCKU040
source [find cpld/xilinx-xcu.cfg]
init
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.3 released
Hello, We have released ARTIQ 3.3 today. It contains fixes for a few bugs found in 3.2, in particular binaries not being found when flashing boards using Windows. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.4 released
Hi, We have released ARTIQ 3.4 to fix an intermittent core device crash (#902). Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] March 2018 report
Please see the attached PDF. 2018-March.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.5 released
Hi, we have released ARTIQ 3.5 today, which contains a few bugfixes and most importantly corrects an intermittent core device crash (#902). Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.6 released
Hi, ARTIQ 3.6 is released and addresses a few Windows-specific problems. Please update. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] April status report
Please see the attached PDF. 2018-April.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] monthly status report
Please see the attached PDF. 2018-May.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] monthly status report
On Tuesday, May 08, 2018 06:30 AM, Joe Britton wrote: It was really cool to see how quickly RISC-V was added. Awesome! Just to clarify, it was added to MiSoC only, and it is not supported in ARTIQ. When do you expect to look for phase synchronization of SAWG in the analog signal? Tom was proposing to test it: https://github.com/m-labs/artiq/issues/794#issuecomment-385687656 Otherwise I'll have a look within a few weeks. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] We have ARTIQ RF out of Sayma!
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
[ARTIQ] monthly report
Please see the attached PDF. 2018-June.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Sayma input frequency
Hi, any objections to supporting only the RTIO clock frequency (currently 150MHz) at the Sayma input, instead of 100MHz? Are you using non-programmable 100MHz references? Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Sayma input frequency
On Tuesday, June 26, 2018 01:53 AM, Joe Britton via ARTIQ wrote: My comment echos Daniel's. Getting 150 MHz reference oscillators is a special order. What's the motivation to switch to 150 MHz? Ditch a few lines of code. But it's fine, we support both 150MHz (used on the DRTIO satellite, clocking the 830 from the 5324) and 100MHz now. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Sayma DAC frequencies
Hi, I'm trying to determine what is the best way forward to support sample rates better than the current 600MHz with the Sayma DAC and SAWG. What sample rate(s) would you like to see and why? With high sample rates, there are two ways to ease the FPGA resource burden: * use the DAC interpolation modes (2X, 4X, 8X) if the goal is simply to improve spectral purity. * drastically reduce the SAWG digital upconverter resolution to a few frequencies (use the other NCOs to for fine tuning). Are those acceptable? We have a large FPGA, but high resource utilization means long compilation times and potential difficulties to meet timing, so it is still a good idea to make the design as light as possible. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
On Wednesday, July 11, 2018 04:59 AM, Thomas Harty via ARTIQ wrote: My view is that we shouldn't give up the flexibility of being able to fine-tune the DUC frequency unless there is a good reason to do so. For example: if the complexity/compile times of the current code make development/maintenance problematic(*), or if the current code is going to have issues achieving the full 1GSPS data rate. It would be good to hear a bit more from SB/RJ on the advantages of moving to a simpler DUC parametrization. Right now we are producing 4 DAC samples per cycle (150MHz RTIO, 600MHz DAC). Moving to 1GSPS will need 8 samples per cycle (125MHz RTIO), i.e. requiring twice the FPGA resources plus adding interconnection paths between the parallel units. This can only exacerbate issues of compilation time, routing congestion, and timing closure. The last two can probably be addressed but there is no free lunch - it'll take significant work. And the compilation time would always remain problematic. Having the fixed DUC frequencies would simplify the sample generation logic and reduce the problems. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] SAWG
On Thursday, August 09, 2018 03:15 AM, Thomas Harty via ARTIQ wrote: it's a big FPGA and IIRC we're not really pushing the resources limits yet (but maybe I'm wrong about that?), so it's not clear that's actually a problem. I get that multi-hour compile times are death, but at least we haven't seen any Sayma bugs that depend on whether the Sawg is enabled or not for quite a while (since we fixed the power supplies). So, maybe it's not actually such an issue if the majority of Sawg testing can be done in simulation, and any non-SAWG issues on Sayma can be debugging in non-SAWG builds? Let's not get too optimistic. There can be difficult problems with timing closure and routing congestion, which are already a bit sensitive with the current design. Those cannot be solved with a partial design only. Also, even if there are no more Sayma-bugs, simulation/hardware mismatches might still happen (due to Vivado miscompilations, Verilog simulation issues, or Migen bugs). Having a smaller, faster to compile design is valuable. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] SAWG
On Thursday, August 09, 2018 03:12 PM, Thomas Harty wrote: So, the questions are: how much do we need to simplify the SAWG to make it okay to debug and maintain at the 1GSPS data rate? and, what's the way of doing that, which has the least impact on users? "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away". - Antoine de Saint Exupéry ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] monthly report
Please see the attached PDF. 2018-August.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] monthly report
Hi, please see the attached PDF for the latest monthly report. Sebastien 2018-September.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Elementary problems with Kasli
On 10/01/2018 10:30 PM, Hanhijärvi Kalle via ARTIQ wrote: On Kasli, I'm using SFP0 port for the fiber. Is the LED next to SFP0 turned on? That's the Ethernet connection status indicator. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 3.7 released
Hi, A new version of ARTIQ-3 is now available. From to the previous version 3.6, a number of bugs have been fixed, and there are also some performance considerations: * the Ethernet transfer rates with the core device have been increased by >60%. * in some cases, floating point operations in kernels have become slower (https://github.com/m-labs/artiq/issues/1007). Sebastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ 4.0 released
Hi, We are happy to announce ARTIQ 4.0, a major release that brings several exciting features, such as: * Support for the Kasli FPGA core device, and its Eurocard Extension Modules: TTL cards, Urukul DDS cards, Zotino DACs, Sampler and Novogorny ADCs, Grabber EMCCD camera interfaces. * Distributed RTIO (DRTIO), which allows multiple FPGA boards to be interconnected and synchronized using fiber optics links, to reach large number of channels. DRTIO switching support, which allows DRTIO devices to act as repeaters and thus increase the maximum number of nodes, will be part of the 5.0 release. * SU Servo, a gateware peripheral controlling Sampler and Urukul with a DSP engine connecting the ADC data and the DDS output amplitudes to enable feedback. SU Servo can for example be used to implement intensity stabilization of laser beams with an amplifier and AOM driven by Urukul and a photodetector connected to Sampler. * Experimental support for the Sayma multi-GSPS SAWG prototype. There is also a number of internal changes such as SED, a new RTIO architecture that enables larger number of channels on a single device, and facilitates DRTIO switching. Some of these changes result in different ARTIQ behavior and user code needs to be adapted. The list of relevant changes is documented in the RELEASE_NOTES.rst file. How to update: If you have purchased a Kasli crate from M-Labs or QUARTIQ, we have pre-built firmware and gateware binaries for your device. Simply install them via conda and reflash: conda install artiq-kasli-YOUR_VARIANT=4.0 artiq_flash -V YOUR_VARIANT The micro-USB cable needs to be connected, and the OpenOCD configuration instructions apply: https://m-labs.hk/artiq/manual-release-4/installing.html#configuring-openocd Note that the commands above will replace any existing ARTIQ installation; you may want to create a new conda environment instead. For the KC705 (NIST hardware variants), there are also binaries available. Other users need to patch and compile the ARTIQ source. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] status report
Hi, The attached PDF covers the work since the last report sent on October 9th. Sébastien 2018-November-December.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Dec 11 - Jan 19 status report
Please see the attached PDF. 2019-January.pdf Description: Adobe PDF document ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Frame grabber
Hi, The Grabber card is not compatible with CoaXpress. Using CoaXpress with Kasli should be possible via its SATA connector, but requires nontrivial development in hardware and gateware. Sébastien On 2/1/19 12:02 AM, Harry Parke via ARTIQ wrote: Dear ARTIQ list members, Does anybody know if the Frame Grabber Interface is only compatible with Camera Link or whether anything can be done so that it works with other fast data transfer interfaces such as CoaXpress? Many thanks, Harry Parke ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] Mattermost chat
Hi all, For quite some time, the IRC channel #m-labs on Freenode has been where a lot of the activity happened. But good old IRC appears not to be to the taste of everyone, so we now also have a more modern option at https://chat.m-labs.hk/ This is based on Mattermost (an open source solution installed on our own server) and it offers many features that IRC does not have, such as: * message history is kept while you are offline * a nicer web-based interface * smartphone apps * pictures * email notifications The Mattermost chat room is bridged to the IRC channel, i.e. messages posted to IRC appear on Mattermost and vice versa. The IRC chat room is not becoming obsolete - Mattermost is just another option. Choose what you prefer. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] web forum
Hi, I have set up a web-based forum as another place (that some may find friendlier and easier to use) to discuss all things ARTIQ, (n)Migen, MiSoC and HeavyX with the community. Visit it here: https://forum.m-labs.hk/ Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ 5 release timeline?
On 9/12/19 11:05 PM, Andrew Risinger via ARTIQ wrote: > Is there a timeline for the release of ARTIQ 5? https://github.com/m-labs/artiq/milestone/14 The main item is Sayma v2 support. > Also, is there any reason that the conda builds only still support > python >=3.5.3 <3.6, when Nix supports python 3.7? Yes, the poor quality of conda, which makes it frustratingly difficult to upgrade Python. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] ARTIQ-5 released
Hi, ARTIQ-5 is released today. To update, follow the stable branch manual at https://m-labs.hk/artiq/manual/installing.html. Highlights of this new release (compared to 4.0): * Performance improvements: - Faster RTIO event submission (1.5x improvement in pulse rate test) See: https://github.com/m-labs/artiq/issues/636 - Faster compilation times (3 seconds saved on kernel compilation time on a typical medium-size experiment) See: https://github.com/m-labs/artiq/commit/611bcc4db4ed604a32d9678623617cd50e968cbf * Improved packaging and build system: - new continuous integration/delivery infrastructure based on Nix and Hydra, providing reproducibility, speed and independence. - rolling release process (https://github.com/m-labs/artiq/issues/1326). - firmware, gateware and device database templates are automatically built for all supported Kasli variants. - new JSON description format for generic Kasli systems. - Nix packages are now supported. - many Conda problems worked around. - controllers are now out-of-tree. - split packages that enable lightweight applications that communicate with ARTIQ, e.g. controllers running on non-x86 single-board computers. * Improved Urukul support: - AD9910 RAM mode. - Configurable refclk divider and PLL bypass. - More reliable phase synchronization at high sample rates. - Synchronization calibration data can be read from EEPROM. * A gateware-level input edge counter has been added, which offers higher throughput and increased flexibility over the usual TTL input PHYs where edge timestamps are not required. See `artiq.coredevice.edge_counter` for the core device driver and `artiq.gateware.rtio.phy.edge_counter`/`artiq.gateware.eem.DIO.add_std` for the gateware components. * With DRTIO, Siphaser uses a better calibration mechanism. See: https://github.com/m-labs/artiq/commit/cc58318500ecfa537abf24127f2c22e8fe66e0f8 * Schedule updates can be sent to influxdb (artiq_influxdb_schedule). * Experiments can now programatically set their default pipeline, priority, and flush flag. * List datasets can now be efficiently appended to from experiments using `artiq.language.environment.HasEnvironment.append_to_dataset`. * The core device now supports IPv6. * To make development easier, the bootloader can receive firmware and secondary FPGA gateware from the network. * Python 3.7 compatibility (Nix and source builds only, no Conda). * Various other bugs from 4.0 fixed. * Preliminary Sayma v2 and Metlino hardware support. Breaking changes: * The `artiq.coredevice.ad9910.AD9910` and `artiq.coredevice.ad9914.AD9914` phase reference timestamp parameters have been renamed to ``ref_time_mu`` for consistency, as they are in machine units. * The controller manager now ignores device database entries without the ``"command"`` key set to facilitate sharing of devices between multiple masters. * The meaning of the ``-d/--dir`` and ``--srcbuild`` options of ``artiq_flash`` has changed. * Controllers for third-party devices are now out-of-tree. * ``aqctl_corelog`` now filters log messages below the ``WARNING`` level by default. * On Kasli the firmware now starts with a unique default MAC address from EEPROM if `mac` is absent from the flash config. * The ``-e/--experiment`` switch of ``artiq_run`` and ``artiq_compile`` has been renamed ``-c/--class-name``. * ``artiq_devtool`` has been removed. * Much of ``artiq.protocols`` has been moved to a separate package ``sipyco``.``artiq_rpctool`` has been renamed to ``sipyco_rpctool``. * ``artiq_ctlmgr`` and the influxdb tools have moved to a separate package ``artiq-comtools`` (normally installed by default). (Also posted on: https://forum.m-labs.hk/d/51-artiq-5-released) Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] closing mailing lists on Dec. 24
Hi, since nobody is using these mailing lists anymore (these days the preferred channels seem to be GitHub/Gitea issues, IRC/mattermost, and the forum), I will close them next week, Dec 24th - unless someone objects. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
