Re: [ARTIQ] precisions on GUI features
ecially if > writing the controller in another language than Python, for which a > ARTIQ logging library may not be available). That protocol should also > be human-readable so that controllers can be run stand-alone. Something like (173b) looks human-readable to me. > >> 5) Support changes of inputs while an experiment is running: I'm > >> not sure how that would be used. One thing that we discussed with > >> Joe is to support resetting each argument widget individually from > >> its default value recomputed by running again the build() function > >> of the experiment. Are there use cases that are not well-covered by this? > > > > The most common use case is a periodically scheduled scan whose > > range depends on a time-varying dataset value. Example: scan range > > should be symmetric about a data-set value, re-compute range each > > each build(), update GUI ranges, run experiment. > This is supported by the reset approach above, correct? I proposed an implementation of this in #93 on github. Not sure how you were planning on implementing this. > > 7) display-only GUI element in Explorer tab Context: Experiments may > > produce information that can be productively presented to user in an > > organized way. One way of presenting this information to the user is > > in an output to the Log. However, this quickly scrolls out of sight > > in the case of a single Log view. Implementation: It would be > > convenient if the user-defined section of the Explorer GUI supported > > "display-only" widgets. HTML and PNG seem like reasonable formats. > > The display widgets could be updated by the same > > set_dataset(broadcast=True) mechanism that causes Plots and > > Histograms to update real-time. > > Why not replace plots and histograms with a more general mechanism > that allows defining your own display code with a Python plug-in? Then > images, complex plots, etc. become possible. Agreed that replacing plots and histograms with user-defined code is superior. >Why integrate the output into the > explorer, instead of it having its own dock like the current plots and >histograms? I think we agree. To be explicit, an experiment selected in the Explorer determines the contents of two tabbed panes "Experiment Configuration" and "Experiment Results" which show a list of e.g. Scan widgets and a list of user-defined plots, respectively. The contents of these two windows are automatically re-drawn dependent on which experiment is selected in the Explorer. To my view, the use case of several experiments displaying output to a single pop-out window is important but secondary to clearly linking Experiment choice with Configuration and plotted Results. Experiment Results widgets include display widgets for matplotlib output (e.g. png) and html. > -Original Message- > From: Sébastien Bourdeauducq [mailto:s...@m-labs.hk] > Sent: Friday, November 20, 2015 10:18 AM > To: Britton, Joe <joe.brit...@nist.gov>; artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] precisions on GUI features > > On 11/20/2015 11:00 AM, Britton, Joe wrote: > > The use scenario is juggling a long-running experiment (over, say, > > hours). From a data analysis perspective it's annoying to try to glue > > together several datasets that were generated due to restarting (eg to > > reschedule or change priority). > > This is an argument for supporting priority changes, but not due dates: > before the due date is reached, no dataset is created. > > >> d) experiment submitted/completed: I guess the master should log > >> those. It does not right now but it should be easy to add. We can > >> have a keyword on those messages that the text filter can use. > > > > Not sure what level of nuisance is appropriate but submitted and > > completed timestamps miss a lot of details about what the scheduler is > > actually doing. A more complete log might also include timestamps for > > scheduler events. > > All log entries already include a timestamp. > > > I'd advocate for the DEBUG level. * experiment submitted/resubmitted > > to scheduler * "preparing" finished * "running" started * "paused" > > started * "paused" finished * "running" ended * "analysis" finished > > If this sort of message is at the DEBUG level (I would suggest INFO as DEBUG > already prints a lot of other messages, but same problem): should we also > support a way to change the log message production level of the master > without restarting it? Right now this requires stopping it and restarting it > with > the -v/-q options. >
Re: [ARTIQ] ARTIQ hotkeys
It would be helpful to have the following keyboard shortcuts.
* Submit Experiment :: Submit to scheduler new instance of whatever program is
selected in Explorer.
* use case is obvious
* Say, CTRL-S
* Re-submit Experiment :: P is whichever program has focus in Explorer. Request
graceful termination of any Scheduler instances of P. Submit to Scheduler new
instance of P.
* use case is tweaking an experiment parameter then re-running repeatedly
* Experiment Hot Keys :: New hotkey entry in device_db.pyon.
{ "hotkey":
{
"key": "F1",
"modifier": "SHIFT",
"program_class": "SaveIon",
"scheduler": {"priority": 0, "pipeline": "main", "debug": "INFO",
"flush": False}
}
}
Joe Britton
NIST - Div 688
325 Broadway
Boulder, CO 80305
303.497.7295
brit...@nist.gov
-Original Message-
From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert Jördens
Sent: Friday, October 23, 2015 11:17 AM
To: Sébastien Bourdeauducq
Cc: artiq@lists.m-labs.hk; Tan, Ting Rei
Subject: Re: [ARTIQ] ARTIQ hotkeys
On Fri, Oct 23, 2015 at 6:56 PM, Sébastien Bourdeauducq wrote:
> What exactly should the hotkeys do in ARTIQ, and what are their use cases?
>
> As I understand, the idea is to assign hotkeys to experiments in the
> explorer, and pressing one will run the associated experiment with the
> arguments currently set for it in the right panel of the explorer.
Yes. If it is a useful simplification, a limitation to the function keys would
be fine.
Maybe this can be done programmatically: just another persistent dataset? Then
the editing and updating interfaces are already implemented...
> Are there other hotkey feature requests/use cases?
IMHO the UI should also have a sensible adaptation the usual desktop
keybindings:
When the explorer is in focus:
enter: enqueue
When the scheduler pane is active:
delete: (graceful) termination
enter: open in explorer?
When an experiment is in focus:
ctrl-enter: enqueue
On top of what I suspect is already exposed by the various widgets already as
key bindings.
--
Robert Jordens.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Distributed Real-Time I/O (DRTIO) upgrade to ARTIQ, clock stability
# Addendum I gather that some additional words would help explain what this DRTIO architecture will look like. See attached Architecture figure (from m-labs.hk) or [image](https://ssl.serverraum.org/lists-archive/artiq/attachments/20150724/e0243576/attachment-0016.png) from [pervious post](https://ssl.serverraum.org/lists-archive/artiq/2015-July/000489.html). ## Core Device * Contains all the brains * Large-ish FPGA (e.g. KC705, XC7K325T) * Network-on-chip architecture with multiple softcore (e.g. OR1K) CPUs * NB: All the above is already implemented in ARTIQ. * Sends commands and clock to Satellite Devices over fiber optics (32 per Master, 1 per Satellite) * uses built-in Xilinx clock and data recovery unit (CDR) in FPGA GTX/GPX * at least 1 Gb per second bandwidth * telecom standard small form-factor pluggable (SFP) * single-mode optical fiber to 10-km * SFP Rx/Tx transceivers (inc. detectors lasers) : $70/ea * 1310nm FP laser, 1490 PIN/TIA receiver * 1490nm DFB laser, 1310 PIN/TIA receiver * Note: If more than 32 links are desired, use normal IO pins on FPGA (limits to ~1Gbps per link and no clock recovery) ## Satellite Devices * Minimal resources required to interface with target ICs and circuits * simple devices: no CPU, no DRAM, Small FPGA (eg XC7A50T) * more complex devices: resources as needed * Takes low level commands from the fiber optics * Identified by serial number - no need to label fibers * Recovers clock from fiber optics using FPGA transceiver * uses built-in Xilinx clock and data recovery unit (CDR) * low phase noise crystal oscillator (VCX) and clean-up PLL * CDR modeled on White Rabbit * Recovered clock is used for devices external to FPGA as well as (DDS, DAC, etc.) possibly after multiplication/division * to economize on bandwidth local FPGA will do data processing and storage * e.g. PDQ-style interpolation * e.g. buffering of ksamples-sized ADC burst Note: DRTIO is for devices requiring precision-timing with respect to the Core Devices. A different interface already implemented in ARTIQ is used for slow laboratory peripherals (e.g. waveplates, fixed-frequency DDSs, stand-alone PID servos) or perhiperals that requires a Windows/Linux host computer (e.g. National Instruments PCI/PXI boards). See more on Controller PCs and Slow Peripherals in this [slide](https://ssl.serverraum.org/lists-archive/artiq/attachments/20150724/e0243576/attachment-0011.png) and read about already supported [NDSP](http://m-labs.hk/artiq/manual/ndsp_reference.html) devices. Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.gov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] GUI Contract Specification
Some comments on Ting Rei's writeup of the GUI specification. Thank you for the detailed writeup Ting Rei. See below for some comments. -Joe $$$ FIRST CONTRACT $$$ ### Experiment Explorer Panel ### It would be good to have some hierarchy to the organization of experiments. A list folding/unfolding GUI widget could be used for this. Or folders. We have 100 experiments in Penning lab. ### Scheduler panel ### Hilight an experiment in the list then click a EEP button. This would open the Experiment Explorer Panel for that experiment. Hilight an experiment in the list then click a Edit button. This would open the experiment defintion file for editing. For each experiment in list need a way to view git commit ID for the corresponding source files. ### Parameter database panel ### Hierarchical organization of elements... I prefer splitting using python-like dot . And, list folding/unfolding widget. Easy access to Parameter database history (via python API or click to generate a time-series plot). ### General structure of GUI elements ### ### UI for results reporting and alert notification ### + a. A window storing the text of the latest event, e.g. fit values of a scan result, hardware failure, etc. A scrolling list showing recent events would be better. There may be a steady stream of alerts. + Does anybody think it would be helpful to have a class of alerts that are sticky in that they stay at the top of the scrolling list until dismissed? I'm thinking a laser unlocked alert might fall into this class. + As an alternative to popup of multiple windows, one log reader tool I use (baretail.exe) has an option to specify text, background color for log entries that match a certain search string (regular expression). This makes certain log entries stand out in an easily identifiable way. Configuration via a text file would be fine. In general, it would be nice to avoid the huge proliferation of free-floating windows that plague the current HFgui. ### General structure of GUI widgets ### + In general, we assume that changing values on the GUI will not interrupt or affect a currently running kernel, but may cause kernel recompilation. Better to wait to recompile the kernel until just before the next run. Else it will recompile after each edit of a GUI element. i.The precedent of setting a scan range in the scanning widget is the following: It's is often the case that the scan range needs to be updated automatically by a script. For example, consider a program designed to automatically calibrate a slowly drifting experiment parameter (e.g. mode frequency). The script should be able to update the scan range to keep the scan centered on the spectral feature as it drifts. Therefore the following might make more sense. All GUI parameters are derivable from values in the Parameter Database or hard coded into python script. This would reduce the number of distinct databases that need to be juggled. As a convenience, addition of a new experiment to the Artiq experiment list could auto-generate the required Parameter Database entries. This is a simplification since many the GUI-editable variables that modify experiment execution need to be part of the permanent experiment record anyway. Examples include, * number of experiment reps per scan point * number of scan points * number of scans * which parameter is being scanned * over what range is the parameter being scanned In this model, editing a GUI variable would automatically update the corresponding Parameter Database entry. ### Results Database ### b. GUI widgets can also store things in the results database so that other GUI widgets can then access the database and retrieve them. (for example, a fitting widget that stores the fit, so that the plotting widget can display it). By Results Database we mean the disk file system on the master machine that holds HDF5 files, right? My expectation of the Results Database is that it will be more or less write-only from the perspective of a running experiment. Reading from the Results Database would be for offline data analysis or experiment replay. And, as a matter of clarity, are we in agreement that the Parameter Database is the only mechanism for passing data between different experiments? And, between one schedule run of an experiment and the next scheduled run. Easy way to retrieve name/path to HDF5 file corresponding to displayed experiment. ### Fitting Widget ### iii. G. Default value of fit parameter. Could be numerical value or Ion Property. iii. H. If fit is successful save a fit parameter to an Ion Property. Need to choose goodness-of-fit metric (e.g. Chi-squared) ### Plotting Widget ### * option to automatically fit at end of data acquisition or refit after each point is acquired * plot fit on top of data * widget is provided with x,y data by a) real-time RPC or sync_struct sent by master b) reading a HDF5 file * support for
[ARTIQ] external triggering; optical dipole force beatnote
Trying to setup an experiment in the Penning lab this week using the old FPGA system clarified several aspects of external triggering that would be desirable in Artiq. It would be good to know if there are other triggering scenarios that Ion Storage envisions not covered by the following. (0) By external trigger I mean the following. RTIO outputs and the core device are held until a trigger condition is satisfied. The trigger condition could be the falling edge of a RTIO input (or an interval trigger defined below). (1a) A trigger event is a rising or falling edge of a signal applied to a RTIO input. (1b) Logic lines in our labs are often TTL carried over BNC. On some occasions there is cross coupling between cables when they are tightly bundled. On our oscilloscope we handle this problem by using the interval trigger mode that only triggers on pulses of length tau or greater. Here's a pulse sequence. _ | | -- t0t1 If t1-t0 = tau then the pulse is valid. If t1-t0 tau, don't trigger. Choose between triggering on: rising-tau-falling or falling-tau-rising. (2) Some experiments may involve more than one trigger event. For example, we may want to block the start of an experiment sequence until the falling edge of a discriminated 60 Hz AC line presented on RTIO channel 1. The experiment sequence then commences with several RTIO pulses (e.g. laser cooling). Then the sequence blocks, waiting for the falling edge of the input to RTIO channel 2 (e.g. discriminated beat note from optical dipole force ODF beams). The experiment sequence then resumes. In general it would be helpful if any of the RTIO channels could be used for triggering. (3) Very low latency is desired between satisfaction of a trigger condition and resumption of RTIO events. In general, the objective is to align the Artiq pulse sequence with some external stochastic event. The ODF beat note could be a 10 MHz signal when an ion has a 10 MHz secular frequency. We'd like to be able to synchronize subsequent events with the ion's motion (following application of an ODF laser pulse) with at most 1% error. That is, to 1 ns. Example experiments: (a) In the clock lab, one scheme for detecting the Al+ resonance is applying an ODF to Al+ in an Al+Mg+ ion crystal. Laser light blue-detuned from the Mg+ cycling transition is applied and a time-stamp for each scattered photon is recorded. Driving of the Al+ resonance is indicated by observation that the photon scatter rate is synchronous with the ODF. 10 ns time stamp resolution is required. (b) In a Penning lab, one scheme for calibrating the Jz^2 strength is a loop in phase space using the pulse sequence: ODF (0 deg), classical force (90 deg), ODF (180 deg), classical force (270 deg). Achieving the requisite angle between the ODF (ODF phase is stochastic, but stable for milliseconds) and the classical force (from a DDS) requires 5 ns timing resolution of RIO pulses after initial triggering Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.govmailto:brit...@nist.gov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] duty cycle management
If the duty cycle information is specified in ddb.pyon and there are no conditional routines in the default experiment, the default experiment pulse sequence could be precomputed and loaded onto the FPGA. In general, any experiment that includes conditional routines would need the dutycycle management preformed on the core device. I don't think this would pose a computational problem since the dutycycle pulse sequence could be computed at the end of each experiment (OK if it takes many micro-seconds). -Joe Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.gov -Original Message- From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sebastien Bourdeauducq Sent: Saturday, March 14, 2015 5:46 AM To: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] duty cycle management Hi, An important question is whether the default experiment (that runs on the core device alone, without any computer intervention) will need duty cycle management. If it does, it means that the duty cycle tracking should happen on the device. Sebastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ future details
c) which file and line of code was responsible for underflow This is non-trivial to implement as it requires unwinding the stack, getting a machine instruction address/LLVM instruction mapping from LLVM, and adding a LLVM instruction mapping/Python AST node mapping to the compiler. We can do it but it is currently a next contract item (not so well- named py2llvm debugging symbols). Shall we make it a higher priority one? If getting this to work is nontrivial I'd say put it on the next contract. 4) functional parameter database What do you mean? It would be helpful to have a history for the parameter database. We use this in the Penning experiment to feed forward on some aspects of the experiment that drift over time (e.g. accumulation of dark ions shifts our COM mode). If this is somewhat involved to implement in Artiq and you'd prefer to defer to the next contract that's OK. I'm sure I can come up with an ad hoc solution. 5) debug methods to find DDS bus errors a) systematic read and write to all available pins on bus I have merged most of the nist-dds-ttl-tester functions into the ARTIQ runtime. Press 't' while the runtime starts to enter the test mode (reset the board to leave it). https://github.com/nist-ionstorage/nist-dds-ttl-tester#result Great! I'll give this a try as soon as I can get Artiq running on the KC705. -Joe ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
[ARTIQ] minutes for today's demo discussion
12:30pm 2/23 - notes by JWB Today SB led a tour of user interface and controller features of Artiq. Most members of Ion Storage were present. Demo of glade and GUI. Interprocess Communication and Networking (IPChttps://docs.python.org/3.4/library/ipc.html) is used by Artiq for communication between architecture elements: master-GUI, master-controllers. * artiq_rpctool.py can be used to list the targets for any RPC-aware element * TRID is time run ID * Demo of LDA controller o artiq_ctlmgr.py o artiq_run.py o artiq_rpctool.py Experiment results are recorded using HDF5 file format. * use h5dump to inspect a HDF5 file contents * status of Artiq code including .py file responsible for the experiment are linked via github commit IDhttp://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History (e.g. ca82a6dff817ec66f44342007202690a93763949) * copy of latest Parameters from Parameter Database is included in HDF5 file. * Kyle requests a facility for quickly navigating Experiment Results on disk and plotting experiment output just as it would have looked when collected in the lab. Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.govmailto:brit...@nist.gov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] GUI: controls
It might be possible to auto-generate a GUI client for a device with an ARTIQ driver based on the existing command line clients we are writing using argparse. This would entail processing the parser object constructed in a command line client and auto-generating corresponding GUI client interface. This could have a couple benefits. 1. Any device with a useful command line client interface would automatically get an equivalent GUI client interface. 2. This would prevent code duplication. 3. It would ensure that we develop strong support for command line clients. -Joe Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.gov -Original Message- From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sébastien Bourdeauducq Sent: Friday, January 30, 2015 12:27 AM To: artiq@lists.m-labs.hk Subject: [ARTIQ] GUI: controls Hi, I'd like to start more discussions about the GUI before coming. I've been prototyping some of those ideas (the Glade controls loading and argument passing should work already), and I invite you to have a look at the code and try it out so that we have a solid base of discussion. Please let me know your thoughts and questions. Sébastien Experiment registry === The experiment registry is a small database hosted by the master that contains the list of the experiments to show in the GUI. Each entry contains essentially its name, the top-level experiment file, and the optional GUI file. The master does not use the registry in any way other than providing access to the GUI clients. GUI controls The explorer window in the GUI has a two-column layout. The left column shows the list of the experiments from the registry and the right column shows the controls associated with the selected experiment in the list. Most options (scan parameters, fit selection, etc.) are part of those controls. All the values of those options are passed as Arguments (http://m- labs.hk/artiq/manual/core_language_reference.html#artiq.language.db.Arg ument) to the experiment. This means that the data analysis is part of each experiment, though some generic library code can be provided for the experiments to use. When the user selects an experiment in the explorer, the client retrieves the GUI file from the master and executes it to define the controls by creating the appropriate widgets. When the experiment is scheduled, the client executes another part of the GUI file code to retrieve the information from the widgets and turn it into a set of Arguments. The Arguments are then sent to the scheduler along with the rest of the information about the run (filename, timeout, etc.). Glade = Glade (https://glade.gnome.org/) may be used to build the layout of the controls. Glade saves the GUI description as a separate XML file, and since the ARTIQ GUI file is running on the client, it needs to contact the master (where the experiment code is stored) to retrieve that XML file. This is done by using the get_data coroutine that is passed to the code in the GUI file. The following example shows the use of Glade: https://github.com/m- labs/artiq/blob/master/examples/flopping_f_simulation_gui.py (we can probably factor the build and get_top_widget methods into a GladeControls abstract class and make it part of the ARTIQ APIs) ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] artiq dependencies
What about pointing out to known good version numbers of dependencies in the ARTIQ documentation? [:: ] Agreed that that's a better solution. I propose we build into setup.py a pull of specific version numbers for external dependencies. This makes it straightforward for end users. And, provides a straightforward deployment path for upgrades. That is, pull a new copy of setup.py from m-labs's github and run install. Duplicating and maintaining all the code from the dependencies will be painful, and will conflict with the package managers of Linux or Python distributions. Having a version number associated with each dependency is necessary anyway to report bugs, update them, etc. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ development system
tutorialhttps://github.com/m-labs/artiq/blob/master/doc/manual/getting_started.rst ojoin the mailing list artiq@lists.m-labs.hk oask questions on IRC · on the virtual machine a nice IRC client is xchat · choose a nickname; please don't use rabi · choose Debian Servers as the Network · click Connect · join the channel #m-labs Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.govmailto:brit...@nist.gov From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Joe Britton Sent: Wednesday, November 05, 2014 10:19 AM To: Sherman, Jeffrey A. Cc: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] ARTIQ development system Thank you for trying out the VM Jeff. And a big thanks for pointing out to the list that building the development toolchain is nontrivial. It took me about 20 hours to build the Linux-based VM over the past couple days with Robert's help. This is on top of a partly successful but abandoned foray into a docker-distributed VM setup two weeks ago; another 20+ hours. My expectation is that by the end of our contract with Sebastein an Artiq development environment will be relatively easy to install on a new Linux box. At this juncture however there is not an automated build process. I'm learning that while the necessary packaging may be straightforward it's a nontrivial undertaking. In light of my efforts of the last two weeks I'd like to reiterate my recommendation that everybody who is not an m-labs employee not invest any time trying to port Artiq to any other OS or FPGA platform. This is an astonishingly deep rabbit hole...Let's focus our joint efforts on Ubuntu 14.04 Linux, Papilio Pro and the KC705. Recall the discussion in this thread. https://ssl.serverraum.org/lists-archive/artiq/2014-October/000121.html Also note that a focus on Linux as a host OS for Master and MIGEN development does not preclude use of hardware with Windows-native device drivers. In this case the hardware would installed in a separate Windows PC and integrated with the Artiq ecosystem using the Controller infrastructure and ethernet. This note is in followup to Daniel's comment on the same thread. https://ssl.serverraum.org/lists-archive/artiq/2014-October/000128.html -Joe On Wed, Nov 5, 2014 at 9:04 AM, Sherman, Jeffrey A. jeff.sher...@nist.govmailto:jeff.sher...@nist.gov wrote: Awesome, thanks! I've spent the last two fails utterly failing to build the toolchain using native OS X ports/packages. The year is 2014 and there are, like, six distinct C compilers presently installed on my system. I've obtained a Papilio Pro now and will try your VM on the Mac today. Jeff Sherman National Institute of Standards and Technology Time Frequency Division 325 Broadway (Div 688) Boulder, CO 80305 // Office: 303-497-3511tel:303-497-3511 From: Britton, Joe joe.brit...@nist.govmailto:joe.brit...@nist.gov Date: Tuesday, November 4, 2014 11:41 PM To: artiq@lists.m-labs.hkmailto:artiq@lists.m-labs.hk artiq@lists.m-labs.hkmailto:artiq@lists.m-labs.hk Subject: [ARTIQ] ARTIQ development system I've setup a Linux virtual machine that's configured with everything that's needed to develop for Artiq. It's stand-alone and should work fine on Windows 7 or OS X. It would be good to get a NIST volunteer to give it a spin. With feedback I'll improve the instructions and fix up any missing elements. -Joe · VirtualBox · Install Oracle VirtualBoxhttps://www.virtualbox.org/ on your computer (OS X or Windows 7) · Download and install the VirtualBox Extension Pack · Copy the xubuntu_artiq virtual machine disk image to your local hard disk. · \\jake\68_PML\688\Public\penning_britton\shared\artiq\20141104_xubuntu_artiq · 64-bit Xubuntu is used as the base image (xubuntu-14.04.1-desktop-amd64.iso). · Xubuntu's window manager is xfce. xfce is more light weight than Gnome. I find the xfce user interface is much snappier on Windows and OS X hosts than Gnome. · The virtual machine is setup to use 2 GB of host memory and 4 CPU cores. Change this if appopriate for your host. · Updates to the Artiq development platform will be released in the form of a new disk image. Don't save user data on the virtual machine's disk. Instead use a folder shared between the Virtual Machine and the host PC. · The VM's username is rabi. The password is the identity from last week. · Directory structure · The source code files needed for writing artiq scripts, compiling .bit files and programming FPGA boards are located at · /home/rabi/artiq-dev · artiq-related python modules are installed at /home/rabi/.local/lib/python3.4. This is the prefered location for python packages that are under development
Re: [ARTIQ] DDS/TTL breakout boards
Sounds like a great idea Daniel. I took an inventory yesterday of the Papilio FPGA boards [1] and SCSI 68-pin TTL-bus/DDS-bus boards [2] designed by Robert Sebastien. We have two copies of [1] and three copies of [2] (one of the latter needs stuffing). I will order a third copy of [1]. Robert, do we have the parts needed to stuff [2]? -Joe Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.gov -Original Message- From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Slichter, Daniel H. Sent: Friday, September 26, 2014 9:24 AM To: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] DDS/TTL breakout boards FYI, Till has designed a breakout board from FMC directly to the DDSs (i.e., no cable in between, so the DDSs are collocated with the FPGA). We're using it in our zynq system, and it may be an easy way to get an artiq test system up and running. I checked out these boards yesterday and I think they would work quite well as a solution for most people, without requiring recourse to a distributed RTIO system. Each breakout board fits on an LPC FMC and holds 11 DDS daughterboards and provides 28 galvanically-isolated TTLs, 21 outputs and 7 inputs (it is possible to trade inputs for more outputs when building by choosing a different, pin-compatible isolator/level shifter chip). With the KC705 and its two FMC connectors, this would mean 22 DDS channels, 42 TTL outputs, and 14 TTL inputs. The pinout of the FMC is identical between the Zynq board and the KC705 (since it complies with FMC spec), so it's plug and play in that respect (although obviously the pinout needs to be coded appropriately in the FPGA). And since Till has already done the design work, very little effort is needed to implement. The only requirement is that we would need to build a box to hold the FPGA, DDSs, and TTLs and break them out to connectors on the f ront panel, which is not very onerous. For those interested, in principle more DDS slots or TTLs could be added to each board with some minor tweaking, and I will work on this once I get the files from Till. The boards are designed to use either the new AD9914 DDS daughterboards Till has designed for the clock folks or the old AD9858 DDS daughterboards that Quantum I/Quantum II/Penning have been using. All of this is not to say that we cannot/should not pursue the distributed RTIO idea, which in the end gives more scalability, but I think at least for the immediate needs of just about everyone in the group, one or two of these FMC breakout boards would suffice, and they have the advantage of already existing and having been tested. I will try to get some made in time for Sebastien's visit, but we can plan on using the Papilio Pro if they aren't ready yet. Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] August 2014 progress report
Typically, 0.5-1.5 MHz. -Joe Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.gov -Original Message- From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sébastien Bourdeauducq Sent: Tuesday, August 26, 2014 7:38 PM To: artiq@lists.m-labs.hk Subject: Re: [ARTIQ] August 2014 progress report On 08/27/2014 12:44 AM, Britton, Joe wrote: With the Penning trap we are work with many more ions than the other labs. Often N=300 or more ions. In this case we collect many more photons to beat the projection noise limit (std_proj = 1/sqrt(N)). Often, N*10 so 30,000 events. In how much time, one second? A 30kHz event rate is not too high for the CPU to transfer them to a SDRAM buffer, which can easily be made very large. Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] cost estimates : master, chassis, custom bus
this information and the figure of merit we calculated on Friday of wanting a minimum of 200 user I/O, I think we will probably have to go with a BGA FPGA and not be able to do the QFP design like what the PDQ uses, which was the idea for the simple board option. Once we're talking BGA, then we need to send out to get boards stuffed for us. Price-wise, an Artix-7 or Kintex-7 FGPA in the 50k-160k logic cells size range (approx. 5-16x the size of the PDQ FPGA, and sufficient even at the smallest size to hold an OpenRISC mor1kx processor in addition to other gateware if desired) will be between $80 (smallest Artix, lowest speed grade) and $500 (largest Kintext, highest speed grade), with basically all prices in between represented by choosing the speed grade, number of user I/O, and number of logic cells. The Kintex-7 can be clocked ~1.5-2 times as fast as the Artix-7 for the internal logic, but the I/O rates are less than a factor of 1.5 faster. Xilinx FPGA overview: http://www.xilinx.com/support/documentation/data_sheets/ds180_7Series_Overview.pdf Artix-7 specs: http://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf Kintex-7 specs: http://www.xilinx.com/support/documentation/data_sheets/ds182_Kintex_7_Data_Sheet.pdf It seems to me that a good compromise between performance, size, and price would be the smallest Kintex-7 processor in a medium Kintex speed grade (-2). It would be fast enough (200 MHz+ clock) and large enough (65,000 logic cells) to efficiently run OpenRISC if desired with some space left over. A package with 285 user I/O would cost $145 each at the 10-unit price break. One could also get the next size up Kintex-7 (162,000 logic cells) that would be more than enough to run a whole experiment as the master, costing $250 apiece at the 10-unit price break for 285 user I/O, or $286 apiece for a package with 400 user I/O. To compare, an Artix-7 with 100,000 logic cells in the highest Artix speed grade (-3) would need to be clocked ~1.5-2 times slower than the Kintex-7, but would cost $208 apiece (285 user I/0) or $256 apiece (400 user I/O) at the 10-unit price break. For reference, the speed grade numbers cannot be directly compared between Artix and Kintex (e.g. fastest Artix speed grade is generally worse than slowest Kintex speed grade), but they have meaning within each of these families. Ball pitch on all these packages is 1.0 mm so layout should be doable per the response from the Digicom designer. Best, Daniel From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Britton, Joe Sent: Monday, July 28, 2014 2:32 PM To: artiq@lists.m-labs.hkmailto:artiq@lists.m-labs.hk Subject: [ARTIQ] cost estimates : master, chassis, custom bus See attached market research on cost of the following components: * Motherboard layout with FMC connector * 3U Euro chassis * Custom backplane Joe Britton NIST - Div 688 325 Broadway Boulder, CO 80305 303.497.7295 brit...@nist.govmailto:brit...@nist.gov ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq Migen/MiSoC: please use de...@lists.m-labs.hk instead.
