Re: [ARTIQ] installing ARTIQ

Hi, On Tuesday, 15 March 2016 6:32:19 PM HKT Jonathan Mizrahi wrote: > I am trying to get ARTIQ installed on a Windows system using the KC705 > board, following the instructions > here. This has proven > difficult and frustrating (and not yet

[ARTIQ] GUI working with conda packages

Hi, we have fixed all major problems with conda and Qt5. If you want to try out the new GUI, it should work with a regular ARTIQ installation as per the manual. Let me know of any problems. Sebastien ___ ARTIQ mailing list

[ARTIQ] TTLInOut directions

Hi, On Friday, February 19, 2016 01:45 AM, Slichter, Daniel H. wrote: I haven't been able to test the clock generator (to look for phase slippage) because I can't get a signal from either the ClockGen pin AFAICT you are using the ClockGen correctly. Have you double-checked the gateware

Re: [ARTIQ] ARTIQ-1.0 feature freeze

On Thursday, February 18, 2016 10:42 AM, Robert Jördens wrote: I am working on the PDQ2 related items. Yes, the PDQ2 is for 1.0 (and tagged accordingly in the issue tracker); AFAIK most labs need the PDQ? ___ ARTIQ mailing list

[ARTIQ] ARTIQ-1.0 feature freeze

Hi, I think we are close to a point where we should make a stable branch of ARTIQ. The idea is to get a series of stable versions that contain a good set of features that at lab could use on a regular basis for a substantial period (>= 6 months), and that we would maintain (fix bugs) without

Re: [ARTIQ] turning experiment docks into MDI windows

On Monday, February 15, 2016 11:09 PM, Slichter, Daniel H. wrote: My main question: how long would it take to change the GUI implementation over to this proposed model? Not long I believe, the code in ARTIQ is rather modular and so far my experience with those parts of Qt has been relatively

[ARTIQ] turning experiment docks into MDI windows

Hi Ting Rei, what would you think about making the ARTIQ GUI look like this, with the experiment argument editors replacing the *.ui files: http://web.univ-pau.fr/~puiseux/enseignement/python/tutoQt-zero/images/10/fenetre-03.png The main differences with the pyqtgraph-based UI are: -

Re: [ARTIQ] ARTIQ shortcuts

On 11/26/2015 11:34 AM, Robert Jördens wrote: > In many cases one just fires a calibration > or verification experiment without wanting a window to pop up then > having to close it again. What about using the shortcuts (which can have buttons in addition to the F-key mappings) instead of the

Re: [ARTIQ] ARTIQ hotkeys

On 10/24/2015 01:30 AM, Robert Jördens wrote: > Ting Rei could bind a single high-prio panic-experiment and have that > experiment clear the queue in whichever way it wants and do whatever > cleanup it desires. The scheduler now exposes the relevant APIs:

Re: [ARTIQ] ARTIQ shortcuts

Hi, On 10/24/2015 01:16 AM, Robert Jördens wrote: > On Fri, Oct 23, 2015 at 6:56 PM, Sébastien Bourdeauducq <s...@m-labs.hk> > wrote: >> What exactly should the hotkeys do in ARTIQ, and what are their use cases? >> >> As I understand, the idea is to

[ARTIQ] automated cancellations

On 10/25/2015 02:48 AM, Robert Jördens wrote: > "dequeue all instances" would do it. Then you can fire two shortcuts. Ok. I guess that would be "request graceful termination of all instances". Are there other "automated cancellation" features that would be nice to have? As you point out,

Re: [ARTIQ] ARTIQ hotkeys

On 10/24/2015 05:38 AM, Britton, Joe wrote: > * Submit Experiment :: Submit to scheduler new instance of whatever program > is selected in Explorer. > * use case is obvious > * Say, CTRL-S Done. > * Re-submit Experiment :: P is whichever program has focus in > Explorer. Request graceful

Re: [ARTIQ] ARTIQ hotkeys

On 10/24/2015 01:17 AM, Tan, Ting Rei wrote: > 2. Can be programmed as a 'panic button'. Where this experiment will > stop whatever that is running and put the system back to a 'safe' > state. How exactly should that work? Request graceful termination of all experiments in a pipeline associated

Re: [ARTIQ] API change: merger of results and parameters into "datasets"

On 10/21/2015 03:35 AM, Joe Britton wrote: > $ artiq_client does not have an option for specifying persistence flag It does: $ artiq_client.py set-dataset -h [...] -p, --persist make the dataset persistent ___ ARTIQ mailing list

Re: [ARTIQ] logging and log levels within an experiemtn

On 10/21/2015 03:05 AM, Joe Britton wrote: > As it stands I gather that it's all logged but only the subset that > matches the Minimum level choice in the Log GUI is displayed. This > is good but insufficient for monitoring log messages of importance to > a particular debugging session.

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

On 10/16/2015 12:05 PM, Joe Britton wrote: > Due to changes in conda deployment use the main build channel instead of > the dev channel. Actually you should have both right now. The main channel is for stable/released software that is manually built, while the dev channel is for automatically

Re: [ARTIQ] AD9914 support status and questions

Hi Raghu, thanks for your helpful information. The DDS is working now :) Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ClockGen TTL

On 08/27/2015 09:18 AM, Neal Pisenti wrote: What is the purpose of splitting out the `build` function (instead of setting acc_width, etc. in the `__init__` method) It's an oversight. A previous device management mechanism used build() and I missed that one when refactoring. Thanks for

[ARTIQ] AD9914 support status and questions

Hi, I've been doing some hardware tests on the QC2 AD9914 DDS system. Many things are working (tested using the runtime test mode): * basic read/write of the registers, reset values match the datasheet * 10 cycles of ddstest * selection of different slots on the backplane * reset - a modified

Re: [ARTIQ] some comments about artiq_gui

On 08/23/2015 12:48 AM, Tan, Ting Rei wrote: 2. Master Menu bar so user containing a list of the tabs, e.g. DDS, explorer, log…. - This is so that user can open these tabs from these menu bar after closing them. Currently there is no way for the user to do this. The fact that

[ARTIQ] TTL direction on I2C IO expander

On 08/14/2015 12:22 AM, Slichter, Daniel H. wrote: But then we won't be able to use the TTLs properly until I2C is implemented. What kind of time scale would you see for having the I2C running correctly? We can give you a demo board for the I2C chip (TCA6424A) to help with the I2C debugging,

Re: [ARTIQ] KC705 DDS/TTL card status

Hi, On 08/12/2015 10:00 AM, Benjamin K. Stuhl wrote: I'm writing to inquire about the status of the DDS/TTL (really just the TTL) breakout cards that were described on this list back in Jan/Feb [1]: have the designs been finished? Have any been built, or tested? The hardware we ended up

Re: [ARTIQ] Building Artiq from source

Hi, On 08/04/2015 05:05 PM, Chris Ballance wrote: When I try to make the runtime I get unknown argument errors: $ cd ~/artiq-dev/artiq/soc/runtime make runtime.fbi CC isr.o clang: error: unknown argument: '-mhard-mul' clang: error: unknown argument: '-mhard-div' Those two arguments

Re: [ARTIQ] fire-and-forget RPC / inter-CPU communication

On 06/12/2015 11:17 PM, Robert Jördens wrote: it may make sense to make choices that optimize the inter-CPU communication speed in the SoC. (Florent and I are debating whether we should have a shared L2 cache for both CPUs, which would e.g. make the transfer of small messages between the

[ARTIQ] remote imports

On 06/03/2015 02:59 AM, Robert Jördens wrote: And as I have pointed out before, proper remote imports with asyncio are difficult (though not impossible) as they require modifying the AST of remotely imported modules to turn their own import statements into something asyncio-friendly. I

Re: [ARTIQ] ARTIQ future details

Hi Joe, On 03/12/2015 01:43 AM, Joe Britton wrote: Goals by beginning of May === Aim is to run penning trap experiment on ARTIQ 1) run ARTIQ on KC705 with legacy TTL/DDS system (16 TTL, 8 DDS) Ethernet is working fine on the KC705 now - I have fixed the low throughput bug.

[ARTIQ] result management

On 04/21/2015 02:12 AM, Tan, Ting Rei wrote: On a similar note, is there any documentation on the workflow/communication between the GUI and the master? There are several things I'm curious about: 1. When the master receive data from the core devices, how does the data get to the GUI

Re: [ARTIQ] Pipistrello build process

On 04/21/2015 05:46 AM, Zach Smith wrote: I'll poke though the stack trace to see if I can find a problem somewhere in the morning, but in case this is a familiar error to anyone I thought I'd reach out. Did you build the runtime yourself? If you used a runtime binary in conjunction with ARTIQ

Re: [ARTIQ] Logger UI

On 04/14/2015 11:29 PM, Tan, Ting Rei wrote: List the logged values with time stamps. What kind of logged values? I thought the log was like a console where you output debug strings. Did you mean results? Sébastien ___ ARTIQ mailing list

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

On 03/31/2015 07:13 AM, Joe Britton wrote: If the latency were deterministic and less than 1 us the scenarios I described would work fine When you receive a trigger, the RTIO core timestamps it and the CPU uses that timestamp as now value. Then you delay() it by a sufficient amount to account

Re: [ARTIQ] KC705 support

Hi, Thanks Florent, I didn't find the Vivado command to generate raw binaries in the manual. Direct load with xc3sprog still does not work, but the bitgen options solve another problem: booting the FPGA from flash was also broken. Sébastien On 03/29/2015 06:21 PM, Florent Kermarrec wrote:

Re: [ARTIQ] KC705 support

Hi, Seems to work here, thanks for fixing! I found two other bugs while testing: * Vivado fails to generate the .bin raw binary bitstream file: https://github.com/m-labs/migen/issues/9 This breaks loading the bitstream into flash wish xc3sprog. Building with ISE works around the problem. *

Re: [ARTIQ] artiq complicated experiments

Hi, On 02/10/2015 07:04 AM, Gaebler, John wrote: I would like to describe a compound device from a combination of dds and rtioout devices that would do everything needed to set the frequency for a gate pulse and also switch on and off. The dds device is too simple since sometimes multiple

Re: [ARTIQ] GUI: controls

On 02/06/2015 03:36 PM, Robert Jördens wrote: Hmm. I fear that with this design the prevalent use case of a) taking an arbitrary experiment b) choosing an arbitrary parameter from the parameter db c) scanning the experiment over that parameter is more complicated than it should be. AFAICT

Re: [ARTIQ] GUI: controls

Hi, Are you able to run the GUI - do you see the parameters, scheduler and explorer windows? You need to run artiq_master (in the examples directory, so that it finds pdb.pyon, ddb.pyon and explist.pyon) and then artiq_gui. I made several changes since Jan 20, so you may want to upgrade from

Re: [ARTIQ] logging in controllers

On 01/28/2015 09:56 PM, Yann Sionneau wrote: +from artiq.frontend.loglevel import verbosity_args, init_logger Looks good to me, but I'd rather put those two small functions in artiq.tools instead of creating another file. Sébastien ___ ARTIQ mailing

Re: [ARTIQ] artiq dependencies

On 01/29/2015 04:25 AM, Slichter, Daniel H. wrote: I think it would make sense to fork external dependencies into m-labs/artiq so that dependencies don't break over time. I second the motion. What about pointing out to known good version numbers of dependencies in the ARTIQ documentation?

Re: [ARTIQ] driver integration

On 01/27/2015 10:03 AM, Joe Britton wrote: class LED(AutoDB): class DBKeys: led = Device() penning_rotating_wall = Device() penning_rotating_wall.set_freq_all_phase_continuous(0.05) DBKeys is only a description of what object attributes needs to be linked to the

Re: [ARTIQ] PXI6733 controller

On 01/27/2015 03:48 AM, Yann Sionneau wrote: Actually I was thinking about using the PyDAQmx project ( http://pythonhosted.org/PyDAQmx/ ) and provide a direct access to the PyDAQmx API through the ARTIQ RPC mechanism. The PyDAQmx API being itself a direct wrapping/binding of the NI DAQ mx

Re: [ARTIQ] PXI6733 controller

On 01/22/2015 02:08 AM, Joe Britton wrote: * The waveform advance pulse to the 6733 is what causes its output to transition from one ADC channel (voltage) to another. We usually generate this pulse from the FPGA not from a periodic clock (eg crystal oscillator). This makes it possible to a)

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/09/2015 01:12 AM, Slichter, Daniel H. wrote: You mean to use essentially as a thresholding phase detector? In other words, directly measuring the phase of the output signal instead of the phase of the SYNC_CLK? Yes. We could potentially implement this, but I would do it in addition

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/07/2015 02:02 AM, Slichter, Daniel H. wrote: All SYNC_CLKs need to be matched (ideally to less than a SYSCLK cycle) so that the FPGA can properly detect when they are aligned, and a shared bus will not achieve that. This is not necessarily required, I had thought. What we need is to

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/06/2015 03:26 PM, Sébastien Bourdeauducq wrote: Or sample SYNC_CLK with a discrete flip-flop or latch near each DDS chip and trigger them with a skew-matched on-board clocking network pulsed by the FPGA through a scanned ODELAY. Then low-performance multiplexers, shared buses and skew

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

Hi, On 01/06/2015 04:43 AM, Slichter, Daniel H. wrote: Is there an on-die 100-ohm differential termination for LVDS signals at VCCO = 2.5V? Yes. Either way, it's actually a physically shorter distance from the SMA connector to the FPGA (~5 cm) than from the FMC connector to the FPGA, so

Re: [ARTIQ] controller management

Hello, On 01/03/2015 10:51 AM, Robert Jördens wrote: I would just point the managers to the master where they can get their (current, versioned) subset of the devicedb. They can cache that if really needed. Then the master depends on the controllers to be able to run experiments, and the

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

On 01/03/2015 06:47 AM, Slichter, Daniel H. wrote: I'm not very confident about this technique (and high speed LVDS signals on two separate SMA connectors in general). The differential impedance will not match the LVDS requirements on long sections of the transmission line. Another option

Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system

Hi, Happy new year to all! On 01/01/2015 01:21 AM, Slichter, Daniel H. wrote: For the RTIO clocking, I'm currently planning to put a 2.5V LVDS clock on the USER_CLK_P/USER_CLK_N SMA connectors directly on the KC705 board (goes to an MRCC pair in I/O Bank 15, pins L25 and K25). I'm not very

[ARTIQ] Fwd: Re: controller management

Forwarded Message Subject: Re: [ARTIQ] controller management Date: Fri, 19 Dec 2014 15:11:08 -0700 From: Robert Jördens jord...@gmail.com To: Sébastien Bourdeauducq s...@m-labs.hk Hello, On Sat, Dec 13, 2014 at 2:33 AM, Sébastien Bourdeauducq s...@m-labs.hk wrote

Re: [ARTIQ] controller management

Hi, On 12/13/2014 01:36 PM, Robert Jördens wrote: Will the manager never restart or crash? The manager shouldn't have to be restarted unless its code is modified. Crashes may still happen, but it is a relatively simple and contained piece of software, so they should be rare. How does the

[ARTIQ] controller management

Hi, I'd like to take to the mailing list a discussion that started in Github comments a while ago: https://github.com/m-labs/artiq/commit/57e25c7af1cd6a2839d491a772447bb8a2359a55#commitcomment-8728507 I propose to keep each controller simple and have one controller process connected to a single

Re: [ARTIQ] November 2014 status report

Hello, On 11/25/2014 11:58 AM, Robert Jördens wrote: * JSON/PYON: As mentioned on IRC, you could still have used JSON with a bit of type annotation. The other arguments against JSON appear to only count if you want to build a fully bijective python data (de)serializer wich may not be needed.

Re: [ARTIQ] Phase Control

On 11/03/2014 10:31 AM, Gaebler, John wrote: For the dds phase control I think there are three behaviors that we might want to easily be able to implement and switch between when describing experiments. What is the purpose of setting the DDS to sine output in absolute and track mode, and to

Re: [ARTIQ] TTL/DDS breakout meeting report

On 10/30/2014 03:29 AM, Slichter, Daniel H. wrote: 1. If a DDS frequency needs to be changed, how long would it take to load the required data for reprogramming into the output queue of the RTIO core? Let’s assume we need to change freq, phase, and amplitude – thus 64 bits sent over

[ARTIQ] TAACCS slides

I've put online a PDF version of Robert's slides: http://m-labs.hk/artiq/slides_taaccs.pdf Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Mojo board compatibility

Hi, As far as I know, there are no plans to stop the Papilio Pro production, but Jack can probably tell us about this. Porting ARTIQ to the Mojo board would mainly involve: 1. creating a new platform file in Mibuild with the pin assignments

Re: [ARTIQ] master architecture and Windows support

On 10/17/2014 01:44 AM, Joe Britton wrote: For IPC on a single machine I've successfully used a shared memory map mmap between two well-behaved processes. This is fast, simple but doesn't scale well. https://docs.python.org/3/library/mmap.html How do you tell the receiving process that a new

[ARTIQ] PDQ2 driver - API refinements and questions

Hi, I have started implementing the PDQ2 driver and made some changes to the transport example. Please have a look. I have some points I'd like to clarify: * since we are accessing the segments/frames via the frame objects (self.transport.begin(), self.transport.xxx.advance(), ...), then those

Re: [ARTIQ] Sustained RTIO output switching speed

On 10/16/2014 11:12 PM, Slichter, Daniel H. wrote: For inputs, what is the deepest FIFO one could make given the resources on the Kintex7? Could one do a 65k FIFO? Yes, with 64-bit timestamps (a pessimistic estimate) that would make a ~4Mbit memory. The FPGA on KC705 has ~16Mbit of block RAM

Re: [ARTIQ] Proposition for a units system

On 10/14/2014 05:47 AM, Robert Jordens wrote: The obvious performance optimization here is to have the constant folding transform work across statements. The llvm optimizer passes should be able to do that, right? As far as I can tell right now, not so much. In particular it does not work

Re: [ARTIQ] DDS/TTL breakout boards

On 09/19/2014 10:55 PM, Slichter, Daniel H. wrote: This will mean running the I/O single-ended from FPGA onto the daughterboard and then translating to LVDS, as is done with the current system. Why not drive the LVDS signals directly from the FPGA? If doing that I suggest adding some

Re: [ARTIQ] DDS/TTL breakout boards

On 09/20/2014 06:38 AM, Robert Jordens wrote: A jitter of one parallel UI is unlikely. For transmission, yes. For reception, the SERDES needs to align the received data words with the parallel clock, which can cause a latency variation in that vicinity depending on the parallel clock/serial word

Re: [ARTIQ] first experiments

On 09/10/2014 01:17 AM, Slichter, Daniel H. wrote: What is the notion behind removing the explicitly stated parallel and sequential blocks? In this particular case, after the replacement of pulse() with on() to avoid zero-length turn-off times, those blocks are not needed anymore. Generally,

Re: [ARTIQ] DDR3 status on KC705

On 09/05/2014 01:39 PM, Robert Jordens wrote: Works fine here. The windows look good with vivado as well as ise. Great! Temperature and/or vivado-ise differences change it by at most one bit time. I guess you meant a IODELAY tap? Sébastien ___

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,

Re: [ARTIQ] August 2014 progress report

Hi, On 08/26/2014 07:31 AM, Britton, Joe wrote: * What is the resolution for the time stamps? That depends on the PHY (the logic part of the core makes abstraction of it). I'm aiming for 1ns on the KC705. * How many bits are used to represent the time stamp for each event? It's configurable

Re: [ARTIQ] first experiments

On 08/20/2014 11:35 PM, Slichter, Daniel H. wrote: the core device will support these data types, as well as arrays of these data types: - booleans - chars - short ints (16 bit) - long ints (32 bit) - long long ints (64 bit) - doubles - rational numbers Is this correct? We can do

Re: [ARTIQ] first experiments

On 08/20/2014 04:42 AM, Robert Jordens wrote: By the way, will we ever need multi-dimensional array support on the core device? I don't see a need for that. In case it ever comes up, I would just emulate it explicitly. Ok. And should we support anything else than 32-bit integers for the

Re: [ARTIQ] Proposition for a units system

On 08/14/2014 09:16 AM, Robert Jordens wrote: Also that excerpt misses the point of the underlying question, which is when to best convert floating point physical quantities to integer device units. What about having soft floating point (and rational with e.g. 64-bit numerator and denominator)

<    1   2