Re: [ARTIQ] Applets and Datasets

[Sébastien Bourdeauducq]

Hi,

On Tuesday, August 02, 2016 02:07 AM, Stevens, Kelly E. M. wrote:

I ran the example run() function and tried to get a plot generated
but wasn’t able to figure it out.  The manual says I need to edit the
applet command line so that it retrieves the parabola dataset.  How
do I do that?


For the XY plot applet, the Y dataset name is a positional argument. The 
full command would be something like:


{python} -m artiq.applets.plot_xy --embed {ipc_address} 
name_of_my_parabola_dataset



Also, the default XY applet has this in the text:
“{ipc_address}” what is that?


Before running the applet command, the GUI replaces {ipc_address} that 
by a string that tells the applet how to connect to it, for the applet 
to embed itself and get dataset access. Same with {python} that gets 
replaced with the path to the Python interpreter that runs the GUI.



Also, in general, where can I find
documentation on what environment variables


Environment variables are not involved here, it's just a command line.


are available on the applet command line?


The applets are independent Python programs and you get their command 
line options by running them in a shell with the usual -h:


$ python -m artiq.applets.plot_xy -h
usage: plot_xy.py [-h] [--update-delay UPDATE_DELAY] [--server SERVER]
  [--port PORT] [--embed IPC_ADDRESS] [--title TITLE] 
[--x X]

  [--error ERROR] [--fit FIT]
  y
...
datasets:
  y Y values
  --x X X values
  --error ERROR Error bars for each X value
  --fit FIT Fit values for each X value

Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] clock recovery on Metlino and Kasli

[Sébastien Bourdeauducq]

On Thursday, June 30, 2016 04:49 PM, Grzegorz Kasprowicz wrote:

In case of WR it already worked quite well 6 years ago but later on this
circuit was modified several times:)
All the time little things.
So since we have more important things to do I'd leave it as it is.


Since we are not going to use White Rabbit, I propose removing them. I 
do not have a strong opinion about this since the complexity/part count 
should be small.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] clock recovery on Metlino and Kasli

[Sébastien Bourdeauducq]

Hi,

my question was whether one can get rid of all those 6 parts and replace 
them with a Si5324 circuit (instead of #1 and supporting parts) and 
internal FPGA PLL(s) (instead of #2 and supporting parts). Why did you 
design it that way - what do all those additional parts bring exactly?


Sébastien


On Thursday, June 30, 2016 12:06 AM, Grzegorz Kasprowicz wrote:

Hi
The idea is to use SPEC board design: http://www.ohwr.org/projects/spec/wiki
It's well debugged. I designed it a few years ago and it's already 4-th
revision.
The WR components are:
1. 25MHz VCXO VM53S3-25.000-2.5/-30+75 + CDCM61004RHBT PLL chip. The two
can be replaced by 125MHz VCXO.
2. 20MHz helper VCXO for DDMTD : LF VCXO026156
3. 2x DAC AD5662BRMZ-1
4. 3V LDO : LP5951MF-3.0/NOPB
5. 2.5V reference: LM336M-2.5/NOPB
6. some LRC passives
Greg




On 29 June 2016 at 15:56, j arl > wrote:

As the topic shifted from backplane logic, I've moved to this
conversation to a new thread.

On Tuesday, June 28, 2016 04:02 PM, Grzegorz Kasprowicz wrote:
> For synchronisation over fibre we can use existing White Rabbit core.
> The card requires only 2 VCXO oscillators and FPGA logic. The WR core
> consumes 50% of small Spartan 45T. It ensures 1ns timing accuracy.

>We probably won't use White Rabbit as-is, but the basic principle will
>be the same. It can be a good idea to include those VCXOs on boards
that
>may be synchronized over fiber (Kasli/Metlino), though can't we use
>instead a Si5324 for jitter cleanup and FPGA PLLs for DDMTD?

Heads up that the clock synchronization for Metlino resides on
Metlino_clk (Tongue 2) not Metlino_motherboard (Tongue 3-4). So
headers need to provide whatever io is required. Greg already has a
layout for a Metlino_clk board that has White Rabbit components on it.

Greg, do you have a short list of components required for
WhiteRabbit-type clock recovery?  -Joe



___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Sinara clocking

[Sébastien Bourdeauducq]

On Friday, September 30, 2016 07:18 PM, Sébastien Bourdeauducq wrote:

AD9516-1 has more coarse delay range.


Scratch this. I just noticed the HMC has another "slip" mechanism that 
essentially gives it infinite range. So there is no reason to use the 
AD9516-1, other than compatibility with the FMC card.

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] Sinara clocking

[Sébastien Bourdeauducq]

Hi,

Here is a plan for clocking the Sinara system. Please comment.

Crate clock distribution


The crate distributes a 100MHz clock on a RTM RF backplane. This clock 
is typically externally supplied from a high quality source, but it is 
desirable to include a 100MHz oscillator on the clock module for 
turnkey/standalone operation (with limited timing performance).


In a multi-crate system, all crates should receive the same 100MHz clock.

RTIO clock on Metlino
-

In root mode, the Metlino receives the 100MHz clock and turns it into a 
200MHz RTIO clock that it uses as reference clock for its DRTIO 
transmitters.


In satellite mode, the Metlino recovers the RTIO clock from the fiber.

The following clock resources should be available on Metlino to support 
this operation:
* Si5324 for 100->200MHz in root mode, and CDR jitter filtering in 
satellite mode.
* 200MHz XO to transceiver clock pin for providing a CDR reference in 
satellite mode.


The Si5324 shall have its two clock outputs connected to a transceiver 
clock input (so that we can transmit back synchronously and at fixed 
latency) and to a general purpose clock input on the FPGA. 
Transceiver<->fabric clock routing inside the FPGA is of poor quality, 
so we want to be able to mitigate that.


There are three options for connecting the 100MHz RTM clock to the 
Metlino (required in root mode):
1) make the Metlino double-width and connect it to RTM (preferred option 
IMO)
2) add one clock cable inside the crate - could be mechanically 
difficult or impossible
3) require two 100MHz inputs in root mode - this makes using the 
built-in oscillator unwieldy, and will affect single-crate systems


RTIO clock on Sayma
---

Sayma cards recover their RTIO clock from the backplane's transceiver 
links. This requires the same hardware as the Metlino in root mode: XO + 
Si5324, connected in the same way.


RTIO clock frequency flexibility


The FPGA's built-in transceiver PLLs are not very flexible, so if easy 
changing of the RTIO clock frequency is desired, we should consider 
replacing the XOs with PLL synthesizer chips.


General purpose oscillator
--

Sayma and Metlino shall include a general purpose XO of e.g. 125MHz, 
connected to a general purpose FPGA clock input pin. Transceiver clock 
inputs can be routed to the fabric (with degraded timing), so this is 
not absolutely necessary, but this is a simple addition that make the 
boards a bit friendlier to developers. This XO becomes necessary if we 
use a transceiver PLL chip that needs to be configured before it outputs 
a clock.


JESD204 synchronization procedure
-

The FPGA shall align SYSREF with designated RTIO clock edges. The 
alignment should be better than a DAC clock cycle and reproducible 
across reboots.


The FPGA first roughly aligns SYSREF within one cycle before a desired 
RTIO clock edge by asserting the synchronization signal of the clock 
chip, which resets its dividers. This alignment has an uncertainty of 
one DAC clock cycle. The FPGA then analyzes SYSREF by repeatedly 
sampling it with a known clock while scanning a calibrated I/O input 
delay (IDELAYE3) element to measure its phase with a high precision. It 
then derives a phase correction value that it programs into the relevant 
registers of the clock chip to delay SYSREF by the duration that aligns 
it with the RTIO clock.


This mechanism is limited by the resolution of the IDELAY scanning 
technique and of the clock chip's fine delay block. For this to work, 
those resolutions should be good enough, i.e. significantly smaller than 
a DAC clock period.


The clock chip we should use to generate SYSREF and the DAC clock is 
AD9516-1 or HMC7044. HMC7044 looks like a better choice.


AD9516-1 has more coarse delay range. HMC7044 has more outputs, less 
noise, and a higher resolution fine delay block.


Other clock chips that were considered but not selected were:
* AD9528 - maximum output frequency too low.
* HMC7043 - no PLL, cannot multiply the input clock.

This technique can be implemented on the AD9154 FMC cards, which also 
use a AD9516-1 (assuming its fine delay block has enough resolution).


Alternate synchronization procedure #1
--

In case we encounter problems with the fine delay, we may be able to get 
away by using the coarse delay only (which has a resolution of one DAC 
clock period). This will require storing some information about the 
choice of clock edge made from one boot to the next in order to ensure 
constant latency across reboots. This technique was proposed by Robert 
on IRC yesterday.


Alternate synchronization procedure #2
--

If the above techniques fail, we can distribute SYSREF at the source and 
use it to sync HMC7044 clock chips (which contain a SYSREF retimer that 
makes 

Re: [ARTIQ] ARTIQ implementation

[Sébastien Bourdeauducq]

Hi,

On Wednesday, October 05, 2016 12:17 PM, Cornelius Hempel wrote:

At this stage, we are just trying to get an understanding of the size and 
functional requirements (FPGA space and features) at the verilog level - which 
both Trung, our FPGA engineer, and Moglabs speak.


you can simply look at the synthesis logs on our buildserver, e.g.
http://buildbot.m-labs.hk/builders/artiq-board/builds/66/steps/conda_build/logs/stdio
http://buildbot.m-labs.hk/waterfall?show=artiq-board

Note that most of our builds are for the KC705, which uses significantly 
more resources than the Pipistrello target.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ implementation

[Sébastien Bourdeauducq]

Hi,

On Wednesday, October 05, 2016 09:49 AM, Trung Nguyen wrote:

My goal is to extract the Verilog comprising that gets compiled into the
FPGA bitstream in order to establish how and if we can deploy it on
another SPARTAN 6 board (= the pipistrello FPGA) made commercially by
moglabs here in Australia.

It appears that I need to intercept the output of both Migen and MiSoC
as they build the gateway bitstream, BIOS and runtime.


Better port Migen/MiSoC to your board, otherwise you will have to take 
apart/reinvent the ARTIQ build system.



I have tried two ways to install ARTIQ, (1) via Anaconda and (2) from
source.
(1) fails as Migen and MiSoC are not part of the distribution and I
presume this branch is just to compile user control commands to send to
the FPGA, correct?


Migen and MiSoC are packaged for conda and it is possible to build a 
bitstream using only the conda packages. But since you are intending to 
develop I recommend you use (and learn) git.



Trying Artiq 2.0, as pointed out in your previous email,
I tried to build gateware bitstream but I got this error:


AttributeError: type object 'BaseSoC' has no attribute 'csr_map'


https://github.com/m-labs/artiq/issues/565
If you use MiSoC from Git (not conda), "git checkout 0.3" also gives you 
the correct version.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Sinara clocking

[Sébastien Bourdeauducq]

On Sunday, October 09, 2016 10:20 PM, Grzegorz Kasprowicz wrote:

I mean connection of HMC7043 RFSYNCIN pins.


And it's HMC7044, not HMC7043.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] 3.3 V I/O on kc705

[Sébastien Bourdeauducq]

Hi,

On Tuesday, September 20, 2016 09:35 AM, Jonathan Mizrahi wrote:

Thanks! I assume this is the part I need to buy?
http://www.ti.com/tool/usb-to-gpio


Yes.


The ARTIQ manual doesn't say anything about removing and replacing the
J65 jumper, which the kc705 manual talks about (p. 74). Is this unnecessary?


No. The technique described in the manual is for when the FPGA 
reprograms dynamically the power chip. Since we didn't want to bother 
with the details of programming proprietary TI power chips, we used a 
different technique that requires only existing software and hardware. 
The proposed technique will permanently program the TI chip to output 
3.3V, without FPGA intervention.



Also, are all of the I/O pins on the FMC connectors in HR banks (and
thus able to go to 3.3 V)?


IIRC yes, all HP banks go to on-board peripherals (mostly the SDRAM), 
and it would not be smart if reprogramming the FMC voltage only changed 
it for some of the pins. You can check using the schematics.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] ARTIQ implementation

[Sébastien Bourdeauducq]

Hi,

the mailing list I was referring to is the ARTIQ list 
(https://ssl.serverraum.org/lists/listinfo/artiq).


You need to use a modified Rust:
https://github.com/m-labs/rust

Full compilation instructions for the upcoming ARTIQ 3.0 are here:
https://m-labs.hk/artiq/manual-master/installing_from_source.html#preparing-the-build-environment-for-the-core-device

Alternatively you can use the already released ARTIQ 2.0 which does not 
require Rust.


Sébastien


On Thursday, September 29, 2016 10:28 AM, Trung Nguyen wrote:

Hi Developers,

I'm trying to run the Artiq environment to compile the gateware file.
My OS is Linux. Distribution version is Ubuntu 14.04LTS

I have done step-by-step installation of the following manual but
excepts the openOCD because we don't have FPGA board yet:
https://m-labs.hk/artiq/manual-release-2/installing_from_source.html#install-from-source

The installation process is almost ok but I have some problems with
libraries and packages that I had to install when I installed Artiq.
I installed the following libraries and packages:

hdf5-1.8.17
pygit2==0.19.1
numpy-1.11.2rc1
h5py-2.6.0
libffi6 Version: 3.1~rc1+r3.0.13-12ubuntu0.1
Package: libhdf5-dev Version: 1.8.11-5ubuntu7
cargo 0.13.0-nightly (7964e94 2016-09-27)
rustc 1.11.0 (9b21dcd6a 2016-08-15)


I'm struggling with an error when I run this code:

python3.5 -m artiq.gateware.targets.pipistrello

And here is the error message:

make: Entering directory

`/home/trungnguyen/artiq-dev/misoc_nist_qc1_pipistrello/software/runtime'

CARGO_TARGET_DIR="./cargo" \

cargo rustc --verbose \

--manifest-path
/home/trungnguyen/artiq-dev/artiq/artiq/runtime/../runtime.rs/Cargo.toml
 \

--target=or1k-linux -- \

-C target-feature=+mul,+div,+ffl1,+cmov,+addc -C opt-level=s \

-L../libcompiler-rt

error: failed to run `rustc` to learn about target-specific
information


Caused by:

  process didn't exit successfully: `rustc - --crate-name _
--print=file-names --crate-type bin --crate-type rlib
--crate-type staticlib --target or1k-linux` (exit code: 101)

--- stderr

error: Error loading target specification: Could not find
specification for target "or1k-linux"


make: *** [libartiq_rust.a] Error 101


The target is incorrect. It was "or1k-unknown" but I read the note in
released manual as below:

We’re using an |or1k-linux| target because it is necessary to enable
shared library support in |ld|, not because Linux is involved.

from this link:
https://m-labs.hk/artiq/manual-release-2/installing_from_source.html#install-from-source
So I tried to change the target to "or1k-linux" but it does work.

Could you please have a look? Any comments are appreciated.
Thank you.

Best Regards,
Trung Vu Nguyen

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] HMC7044 stability

[Sébastien Bourdeauducq]

Dear Thomas,

On Monday, October 03, 2016 11:18 PM, Thomas Harty wrote:

I guess you mean propagation delay temp. co. + long-term stability,
right?


Yes. Your document mentions a <0.1deg error at 3GHz which corresponds to 
100fs, but it doesn't say over what period of time that error is 
accumulated.



I haven't tested this for the HMC7044 yet, but I'm happy to
add it to the list of ICs to test.

I have a couple questions/comments for you, but first let me check I
understand your plan at a high level:

- We have a rack with both AMC (digital) and RTM (RF) backplanes -
The MCH (Metlino) receives a 100MHz clock from one of various
sources


There are only two sources possible for the Metlino:
1) 100MHz received directly when in root mode, and converted to 200MHz 
RTIO clock
2) 200MHz recovered from DRTIO fiber when in satellite mode (with more 
than one crate). Using the recovered clock here avoids a CDC in gateware 
and associated non-deterministic-latency issues.



- The MCH communicates with the AMCs via the AMC backplane
using Gigabit transceivers clocked at n*100MHz (say, 1GHz-10GHz)


Correct, or fiber to another crate or to a Kasli, which hopefully will 
get built.



-
Each AMC recovers its RTIO clock by integer division of the recovered
gigabit transceiver clock (e.g. to 125MHz)



Yes, and the satellite Metlinos (if any) also do.


- The RTIO clock shall be
the same for all devices, but is globally tunable over some specified
range


Yes. If we want tunability, we may have to use PLL synthesizer chips 
instead of XOs; as I mentioned in my email the Xilinx transceivers are 
not very flexible when it comes to synthesizing frequencies.



- The DAC data rates/TTL phy clocks are power-of-two multiples
of the RTIO clock


Multiple yes, power-of-two helps but is not strictly necessary, Robert 
already wrote on this topic.



- The DAC is clocked from one of various sources,
such as an integer-N PLL locked to the 100MHz RTM clock
- The ADC is
clocked from an integer division of the DAC clock


Both would be synthesized from 100MHz by one HMC7044, so yes.


For the synchronisation:

- SYS_REF is generated by integer division of the DAC clock, and is
routed from the divider (HMC704x) to the DAC using length-matched
traces, such that it's phase relationship to the DAC clock is
well-known
- SYS_REF is operated at an integer division of the RTIO
clock
- SYS_REF is also routed to the FPGA using a length-matched
trace
- As a result, SYS_REF has the same phase at the FPGA as at the
DAC
- The FPGA measures the phase of SYS_REF w.r.t. the RTIO clock by
scanning its IDELAY
- The FPGA then programs the phase of the SYS_REF
output of the HMC704x to align the DAC/ADC clocks + SYS_REF signals
with the RTIO clock. This alignment needs to be good to better than 1
DAC clock cycle (i.e. <<400ps)


Not necessarily length-matched, but with a known length.

Robert also pointed out that with the HMC7044 we can scan its fine 
delays (which are potentially better calibrated than the Ultrascale's 
IDELAY) instead of using the IDELAY. My email was assuming the AD9516-1 
there, which has a limited number of fine delay blocks.



Also, - Why do you require a 125MHz XO on the Sayma? Is this just
used for startup until the RTIO clock can be recovered from the
gigabit link?


Simple convenience and the 125MHz frequency is not critical. This 
oscillator is not meant to be used as transceiver clock.


The transceivers do however always need an external clock even when 
receiving, to provide a reference to the CDR. In the scheme I proposed 
it is the same frequency as the RTIO clock, typically 200MHz.


Regards,
Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] shared SPI clock

[Sébastien Bourdeauducq]

On Friday, October 28, 2016 11:55 PM, Jonathan Mizrahi wrote:

How do you recommend I do that?


Something like:
self.comb += [
  mosi_dev1.eq(mosi_spi_core),
  mosi_dev2.eq(mosi_spi_core),
  miso_spi_core.eq(miso_dev_1 | miso_dev_2)
]

The last line assumes that a non-transmitting device (weakly) pulls down 
MISO. If this is not the case, you need to mux using CS instead.


There will also be some subtleties with the tristate.

Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] shared SPI clock

[Sébastien Bourdeauducq]

On Saturday, October 29, 2016 12:00 AM, Sébastien Bourdeauducq wrote:

The last line assumes that a non-transmitting device (weakly) pulls down
MISO.


You can enable a pull-down resistor inside the FPGA.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Sinara multi-crate / DRTIO switches

[Sébastien Bourdeauducq]

Joe,

I think some clarification is badly required about what DRTIO does and 
does not.


DRTIO gives you:
1) time transfer
2) low-latency low-level control of remote RTIO channels
3) an auxiliary low-bandwidth low-priority general-purpose data channel 
(which can be used for moninj, flashing boards, monitoring temperature, 
etc.)


It is *not* a general-purpose networking or distributed computing protocol.

On Tuesday, November 08, 2016 11:13 PM, Joe Britton wrote:

Crossing each switch will incur 100ns-200ns of latency


This has implications for some experiments. 10 m (10 km) fiber
propagation is 48 ns (48 us). Demonstration experiments involving
heralded entanglement of a pair of nodes (2 crates) have a low
probability of success (~1e-6) and are repeated continuously (~1 MHz).


Why does it have to be 2 crates? Are the hundreds of channels of a 
single crate not enough to drive a few ion traps? You'll have slow 
entanglement in your system at some point anyway as you plan to go long 
distances.



1) slower response times.
2) blocking the kernel CPU by twice the latency (round-trip) when it needs to 
enquire about the space available in a remote RTIO FIFO.


Any implementation that requires round-trip communication to complete
DRTIO is very bad due to fiber/free-space propagation delays. To first
order all DRTIO should assume receiving devices are ready to receive
and handle errors by a) reporting to master crate b) logging for
post-processing. To second order it's fine for low-traffic advisory
signaling like "FIFO 80% full." Plan for future deployments where
communication propagation delays are 100's us.


I advise against running DRTIO over such high-latency links. Even if we 
find all sorts of clever tricks to hide the latency in the "write to a 
remote FIFO" case, any branching would unavoidably require a roundtrip. 
Even toggling an output TTL in response to an input TTL edge would take 
2x 100's us.


Instead the nodes should have more autonomy (e.g. contain their own 
CPUs) and the links should be just time transfer + general purpose 
networking, i.e. White Rabbit. (The reasons we don't do DRTIO over White 
Rabbit are latency, Ethernet overhead for small packets, and 
difficulties in prioritizing traffic)


> A current implementation using soft-core switching seems an adequate
> compromise provided the system is designed in such a way that a future
> gateware implementation is straight forward.


In anticipation of a future all-gateware implementation of DRTIO
routing is use of a dedicated soft-core CPU helpful?


Not at all.

Sébastien

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Sinara multi-crate / DRTIO switches

[Sébastien Bourdeauducq]

On Saturday, November 05, 2016 09:57 PM, Grzegorz Kasprowicz wrote:

We can use multiple 10Gbit links in parallel between Metlinos


That's doable, but we'd have to write the gateware for inter-lane 
synchronization while keeping deterministic latency, which is a bit tricky.

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] Sinara multi-crate / DRTIO switches

[Sébastien Bourdeauducq]

Hi,

does anyone have serious plans to use more than one Sinara crate?

A crate already contains one Metlino and up to 12 Sayma cards, which 
means 96 DAC and 96 ADC channels. A Metlino could also be connected to 
several Kaslis (if the Kasli ends up being made).


Multi-crate configurations require slightly complicated gateware support 
for DRTIO switches. The bandwidth between crates will also be limited to 
10Gbps. Crossing each switch will incur 100ns-200ns of latency which 
will manifest itself in two significant ways:

1) slower response times.
2) blocking the kernel CPU by twice the latency (round-trip) when it 
needs to enquire about the space available in a remote RTIO FIFO.


There is currently a plan to support multi-crate in the hardware (this 
future-proofing simply means adding some SFPs, essentially) but no plan 
to support it in the gateware.


DRTIO switch support is also beneficial to the serial protocol between 
the Sayma AMC and Sayma RTM FPGAs - the current plan is to use a dumb 
protocol that doesn't have good timing resolution and is inefficient for 
things like SPI transfers, essentially a more open version of Channel 
Link II.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] [RFC] remove output event replacement feature

[Sébastien Bourdeauducq]

On Thursday, November 24, 2016 04:54 AM, Srinivas, Raghavendra
(IntlAssoc) wrote:

Replacing is very channel dependent. It can only happen on certain
data and certain state of the channel. Not generally. It needs to be
fine tuned for each channel. And it needs to happen at the input side
of the RTIO FIFO. In DRTIO we can't have such channel dependent
gateware close to the kernel CPU. Whether a channel supports
replacing is done by adding to the RTIO CSR API a logical "address"
that discriminates replaceable "register data". That additional
address field directly impacts and increases the amount of data that
is written on each RTIO event submission. We expect a significant
speed up in event rate by removing it. It also bloats DRTIO packets.


Well there is nothing unmanageable there.
* If we keep your "reset address CSR on timestamp modification" feature, 
those writes that always have address zero (e.g. set TTL level) can use 
a different syscall that ignores the address and saves the associated 
CPU overhead.
* In DRTIO packets, the address field can be transmitted in a handful of 
nanoseconds.
* For replacements in DRTIO, we can just do it on the remote side. The 
inefficiency of sending multiple packets is fine as the throughput will 
be limited by the CPU anyway. For DMA, we can optimize the sequences in 
advance to remove internal replacements.
* The remote side also has a synchronous FIFO which is easier to handle 
than the asynchronous FIFO of local RTIO.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] [RFC] remove output event replacement feature

[Sébastien Bourdeauducq]

On Thursday, November 24, 2016 06:24 PM, Robert Jördens wrote:

How do you want to do the replacement?
Optimizing the sequence in advance in CPU/runtime would be
channel-dependent and mode-dependent special casing.
Doing so in gateware before it enters the DMA buffer would require
gateware there that depends on channel features on remote DRTIO
devices.


All software, and yes there would be some channel-based special cases. I 
don't see advantages to writing DMA buffers in gateware, only inconvenience.

___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] shared SPI clock

[Sébastien Bourdeauducq]

On Friday, October 28, 2016 08:49 PM, Jonathan Mizrahi wrote:

In the platform extension file, when I specify the SPI buses, there is a
clock subsignal "clk." If I want to have multiple SPI buses that share
the same clock, I'm going to need to reference the same clock subsignal
in each bus, which means that that specific pin will appear multiple
times in the file. Will this cause any problems?


Yes. There will be multiple drivers for the same FPGA pin, and the FPGA 
tools cannot do anything reasonable with that.



Do I need to do something else to have a shared SPI clock?


The code assumes one clock per bus. There would be a bit of work to do. 
If you are using the SPI devices one by one, I suggest putting them all 
on a single RTIO channel and mux/demux MISO/MOSI.


Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Pipistrello TTL Output

[Sébastien Bourdeauducq]

Hi,

See here:
https://github.com/m-labs/artiq/blob/master/artiq/gateware/nist_qc1.py#L4

The A/B/C connectors and numbers match the silkscreen of the board.

Sébastien
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] ARTIQ 2.2 released

[Sébastien Bourdeauducq via ARTIQ]

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] ARTIQ 2.1 released

[Sébastien Bourdeauducq via ARTIQ]

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] test

[Sébastien Bourdeauducq via ARTIQ]

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

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] ARTIQ users meeting

[Sébastien Bourdeauducq via ARTIQ]

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] plans for clock chip, JESD and DAC initialization/configuration

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] ARTIQ users meeting

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] plans for clock chip, JESD and DAC initialization/configuration

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] [RFC] remove RTIOCollision

[Sébastien Bourdeauducq via ARTIQ]

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!

[Sébastien Bourdeauducq via ARTIQ]

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

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] starter ARTIQ hardware for neutral atoms

[Sébastien Bourdeauducq via ARTIQ]

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] August 2017 status report

[Sébastien Bourdeauducq via ARTIQ]

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?

[Sébastien Bourdeauducq via ARTIQ]

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] Kasli FPGA selection

[Sébastien Bourdeauducq via ARTIQ]

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] Kasli FPGA selection

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] Fwd: North American Conference on Trapped Ions

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] Instantiating tri-state buffer in migen

[Sébastien Bourdeauducq via ARTIQ]

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] September status report

[Sébastien Bourdeauducq via ARTIQ]

Please see the attached PDF.


2017-September.pdf
Description: Adobe PDF document
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] ARTIQ 2.5 released

[Sébastien Bourdeauducq via ARTIQ]

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] ARTIQ 3.0 released

[Sébastien Bourdeauducq via ARTIQ]

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] October status report

[Sébastien Bourdeauducq via ARTIQ]

Please see the attached PDF.


2017-October.pdf
Description: Adobe PDF document
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] scans and generators on core device?

[Sébastien Bourdeauducq via ARTIQ]

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?

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] SFP/SATA cables for connecting Ethernet on Sayma

[Sébastien Bourdeauducq via ARTIQ]

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] test

[Sébastien Bourdeauducq via ARTIQ]

Please disregard this message.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

[ARTIQ] November status report

[Sébastien Bourdeauducq via ARTIQ]

Please see the attached PDF.


2017-November.pdf
Description: Adobe PDF document
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] scans and generators on core device?

[Sébastien Bourdeauducq via ARTIQ]

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] monthly status report

[Sébastien Bourdeauducq via ARTIQ]

Please see the attached PDF.


2018-May.pdf
Description: Adobe PDF document
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] We have ARTIQ RF out of Sayma!

[Sébastien Bourdeauducq via ARTIQ]

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] Sayma input frequency

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] Single-board ARTIQ/Kasli system now operational

[Sébastien Bourdeauducq via ARTIQ]

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] ARTIQ 3.4 released

[Sébastien Bourdeauducq via ARTIQ]

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] January 2018 report

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] SAWG

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] monthly report

[Sébastien Bourdeauducq via ARTIQ]

Please see the attached PDF.


2018-August.pdf
Description: Adobe PDF document
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] SAWG

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2

[Sébastien Bourdeauducq via ARTIQ]

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] Sayma DAC frequencies

[Sébastien Bourdeauducq via ARTIQ]

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

[ARTIQ] March 2018 report

[Sébastien Bourdeauducq via ARTIQ]

Please see the attached PDF.


2018-March.pdf
Description: Adobe PDF document
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

Re: [ARTIQ] Elementary problems with Kasli

[Sébastien Bourdeauducq via ARTIQ]

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] status report

[Sébastien Bourdeauducq via ARTIQ]

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

Re: [ARTIQ] Frame grabber

[Sébastien Bourdeauducq via ARTIQ]

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] web forum

[Sébastien Bourdeauducq via ARTIQ]

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?

[Sébastien Bourdeauducq via ARTIQ]

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

[Sébastien Bourdeauducq via ARTIQ]

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

[Sébastien Bourdeauducq via ARTIQ]

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