Hi all,
Sebastien has indicated that we are basically ready for a breakout board from
the KC705 to the existing DDS/TTL system, so that we can start using the KC705
and new software to test and run our experiments. I am willing to go ahead and
design a daughterboard to attach to the LPC FMC
I think we're making this too complex at this stage. I gather we're in
agreement that the short-term goal is to get ARTIQ up and running as quickly
as possible in some labs using existing TTL and DDS hardware. I propose
postponing the task of improving upon the current parallel LVDS bus. A
In order to have a very straight forward to follow documentation, it would be
interesting to know which Linux distributions you plan on using so that I
focus
my documentation effort on those.
Another point to consider is that some users may want/need to use Windows 7
rather than Linux (I
Should I make it a priority to optimize this (the CPU/RTIO
communication via CSR looks like a good suspect), or is it going to be
enough for the near future?
Good enough IMHO. My guess would be that the sum of tweaks like CSR
data width will at most yield a factor of 3-5, probably not
Hi,
If we go the DMA route, maybe a good option is to have DRAM backing of
the RTIO FIFOs that is implemented all in gateware and is fully transparent
for
the software. Then we can have FIFOs with hundreds of megabytes of
storage (note that loading/unloading them will take some time). But
1 MHz does not sound like an unreasonable performance target for software
and RTIO/processor communication optimizations. And we can have the
large block RAM FIFO as you said, as a plan B that is easy to roll out.
If you think this is doable, then please go ahead with the further
What about using SYNCLK, which is available on J3 on the AD9858 DDS
modules? It's divided by 8 and a square wave.
Can the FPGA use a clock which is not running at a 50% duty cycle? I am
assuming yes, but wanted to check. My plan for the breakout boards is to feed
the SYNCCLK of DDS0 into
To upgrade a single controller, we could disable it in the manager,
upgrade, and re-enable. There is the detail of controlled process
stops on Windows; I'll check if signal implementations actually work
(e.g. can one catch a signal 15 on Windows and do an orderly
shutdown?)
Yes. All
* looks like there would also be a backoff algorithm for restarting.
Why? Just attempting a restart every 5 seconds is simpler and will
not use lots of CPU resources.
Since we don't know how expensive it is to attempt to start a
controller that is a bit naive. There could be
I advocate adding options to setup.py to include these dependencies if a user
want's them.
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.
___
ARTIQ
Adding an LTC6957 introduces minimal additional complexity or cost, so I vote
to do that. Helps with the jitter problem.
but I'm worried
about a possible part-to-part skew inside the DDS chips between SYNCLK and
the output, which is why the possibility of sampling the latter can help with
Thanks Robert for your thoughtful comments on the hardware, they are indeed
very much appreciated. Replies inline below:
What is the mission statement here? From the level of complexity already
required for this implementation, it looks like this hardware will require a
lot
of work and
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 is to use a single-ended 2.5V LVCMOS clock on
If they are not aligned at the DDS chips, then setting the same phase on two
different DDS channels is difficult and requires knowledge of how much the
skew is. Essentially, the phase reference would be different for each DDS
channel.
This doesn't actually matter -- all we need is that the
This is part of why I have been proposing LVCMOS signals instead of
trying for crazy bandwidths with differential signaling -
I don't see how LVCMOS helps with signal integrity over pin headers given
that the bandwidth depends on the requirement on the rise time of the
signal (and not
That sounds reasonable. What about using LVDS and two male SMA
connectors, e.g.:
http://www.digikey.com/product-
detail/en/CONSMA013.031/CONSMA013.031-ND/1577227
soldered on the back of the LTC6957 PCB? They would serve both as a short
electrical connection and mechanical mount. I suppose
] Today's slides
Date: Mon, 18 May 2015 20:53:39 +
From: Slichter, Daniel H. daniel.slich...@nist.gov
To: Jordens, Robert robert.jord...@nist.gov, Sébastien Bourdeauducq
s...@m-labs.hk, Britton, Joe joe.brit...@nist.gov
1. Programmable modulus mode. The appropriate modulus should
For the fire-and-forget RPCs, the Ethernet latency is not relevant. But for
sending data from the kernel CPU to the comms CPU, the CPUs need to
ensure cache coherency. The two architectures we are considering at the
moment are:
1) modify mor1kx to support writeback caches (which enable
This mode can represent many rational frequencies but is certainly not
exact.
I am just using the datasheet terminology of exact, referring to how rational
frequencies can be exactly represented.
Agreeing on 0.2 nHz (!) is seemingly easy. But either we abandon profile
mode, data modulation
On 05/22/2015 05:07 AM, Robert Jördens wrote:
Modulation seems to be especially hard as it will make the bus sharing
even harder.
What will modulation bring from a physics perspective? DRTIO and an army of
small FPGAs would solve the DDS bus sharing issues...
Modulation mode is not
> Note that parallel LVDS can be done with a Artix FPGA, which could be the
> lowest-cost-per-channel option. The largest device is relatively small
> compared to Kintex though, so one would have to research whether fabric or
> IO is the limiting factor for the number of channels, or if it is
Hi Jonathan,
Depending on which gateware you are using (nist_qc1, nist_qc2, nist_clock), the
pins are in the corresponding file in the folder:
https://github.com/m-labs/artiq/tree/master/artiq/gateware
They are either labeled explicitly, or in the case of qc2, are listed in order
in the list
So...two weeks? More? Less?
> -Original Message-
> From: Sébastien Bourdeauducq [mailto:s...@m-labs.hk]
> Sent: Monday, February 15, 2016 3:14 PM
> To: Slichter, Daniel H. <daniel.slich...@nist.gov>; Robert Jördens
> <jord...@gmail.com>
> Cc: artiq@
> I agree wholeheartedly that stable releases will be very helpful.
I agree as well -- this will be very helpful in allowing people to get science
done with ARTIQ.
> Regarding features that I'd like to see in release 1.0: Is there any chance
> SPI
> communication can be included? We use SPI
> > OK. Then mixing SMP with something else is fine IMO.
>
> The other connector can well be FMC. We need at least ~40 signals other
> than the analog ones going to the cards. A bunch of different power supplies,
> SPI control lines, identification buses, switching, attenuation settings etc.
Actually HPC with LPC IO assignment and 8 x GTP links is popular configuration
So you have 34 LVDS pairs and 8 GTP links.
If this works for you then I don’t have major objections. The other issue to
consider is power rails, since for the analog circuitry we will probably want
+/- 5V, +/- 15V
...@gmail.com]
Sent: Wednesday, March 30, 2016 2:41 PM
To: Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov>
Cc: Grzegorz Kasprowicz <gkasp...@elka.pw.edu.pl>; Leibrandt, David R. (Fed)
<david.leibra...@nist.gov>; Sébastien Bourdeauducq <s...@m-labs.hk>;
artiq@lists.m-labs.hk
> Maybe we should come back to the roots:) What if we use standard FMCs
> (LPC) with DAC/ADC channels and RF stuff _on_ them.
> JESD204B and some pins would go to the FPGA while DAC and RF clock would
> be fed externally.
> In this way we leave general purpose AMC board and define its
> On Wed, Mar 30, 2016 at 10:25 PM, Slichter, Daniel H. (Fed)
> <daniel.slich...@nist.gov> wrote:
> > Now, as you suggest we could just change the level at which we make this
> break from the AMC card, shift the DACs and ADCs onto the daughter card as
> well, an
folks:
https://www.markimicrowave.com/Assets/appnotes/Marki_Surface_mount_Guide_V1.pdf
From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com]
Sent: Wednesday, March 30, 2016 3:09 PM
To: Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov>
Cc: Grzegorz Kasprowicz <gkasp...@elka.pw.edu.pl>
> Impressive. Yep. Looks doable then. For us it would probably be either just
> filtering and amplification on four channels, or upconversion (on two iq
> channels then i would think).
Agreed, seems doable. Filtering plus amplification should fit in a suitable
footprint pretty easily. Two
Kasprowicz [mailto:kaspr...@gmail.com]
Sent: Wednesday, March 30, 2016 3:36 PM
To: Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov>
Cc: Robert Jördens <r...@m-labs.hk>; Grzegorz Kasprowicz
<gkasp...@elka.pw.edu.pl>; Leibrandt, David R. (Fed)
<david.leibra...@nist.gov>; Sébast
, March 30, 2016 3:09 PM
To: Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov>
Cc: Grzegorz Kasprowicz <gkasp...@elka.pw.edu.pl>; Leibrandt, David R. (Fed)
<david.leibra...@nist.gov>; Sébastien Bourdeauducq <s...@m-labs.hk>;
artiq@lists.m-labs.hk
Subject: Re: [ARTIQ] F
> On Saturday, 9 April 2016 6:10:36 PM HKT Grzegorz Kasprowicz wrote:
> > Why do you think that CPUs have negative value? You don't have to use
> > them at all.
>
> I already explained that the MPSoC has to be dealt with and cannot be
> completely ignored. If we have two SDRAM systems, maybe we
Hi Tom,
Responses inline below! Agreed that we are pretty much on the same page
regarding our end goals, and I am flexible in how they are achieved (backplane
clocks would be great!) as long as we aren't sacrificing performance in a
substantial way.
Cheers,
Daniel
It looks like we agree that
> For kernels that are dominantly referring to a single point in the timeline
> (ttl.on(), and also both spi_dac.set(), and dds.set() even though they both
> involve a long sequence of actions), their potential "preparatory" and
> "cleanup" actions should be scheduled such that the "effect" is
Hi,
NIST IT security has just pushed a new policy that any and all software
developed by outside contractors must be in C or C++ only. Apparently they are
going to run some sort of scanning software on the source to look for malicious
code and this will only work on code written in C or C++.
longevity/connector
availability/etc.
> -Original Message-
> From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Slichter,
> Daniel H. (Fed)
> Sent: Tuesday, March 29, 2016 10:39 PM
> To: Robert Jördens <r...@m-labs.hk>
> Cc: Grzegorz Kasprowicz <gkasp...@el
ments (FMC is larger than the QSE
connectors I sent along, for example).
> -Original Message-
> From: Robert Jördens [mailto:r...@m-labs.hk]
> Sent: Tuesday, March 29, 2016 11:08 AM
> To: Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov>
> Cc: Sébastien Bourdeau
> I like this plan. I think 4 + 4 channels will also make the front panel
> connector
> density more reasonable. What are you thinking for number of daughter
> cards? I suppose that more would give us more flexibility, but less would be
> more economical in terms of cost and layout area.
> > What are you thinking for number of daughter cards? I suppose that
> > more would give us more flexibility, but less would be more economical
> > in terms of cost and layout area. Perhaps two daughter cards would be
> reasonable:
> > one for all of the inputs and one for all of the outputs?
> to allow for FPGA selection and to rush the funding I have done a design
> study and implemented a basic DSP output channel for the ARTIQ DSP
> hardware. A 1.25 GS/s, 16 bit, "smart" channel pair would do
>
> o0 = u0 + i0 * a0 * cos(f0 * t + p0) + q1 * a1 * sin(f1 * t + p1)
> o1 = u1 + q0 * a0
> We'll probably want a few dozen TTLs, broken out on SMA, so the FMC panel
> is not an option there.
>
> We can remove PCIe indeed, but keeping the WR oscillators is probably a
> good idea as they can be used for clock synchronization with the master.
For the purpose of a TTL card, I would
> Since this is another piece of hardware and the processing constraints as well
> as the electrical constraints are so different, it seems prudent to account
> for
> these differences. Consider doing proper galvanic isolation with a fiber:
> ground potential differences easily
> -- and even in
> If 65 dB between neighboring channels is the requirement, then
> comprehensive board level shielding appears to be required.
Yes, this will be necessary. See my previous emails.
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
day, July 28, 2016 3:14 PM
> To: artiq@lists.m-labs.hk; Sébastien Bourdeauducq
> <sebastien.bourdeaud...@gmail.com>; Robert Jördens <r...@m-labs.hk>;
> Slichter, Daniel H. (Fed) <daniel.slich...@nist.gov>; jase...@gmail.com;
> camaca...@gmail.com
> Subject: propose
A few questions/comments inline below:
> 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
To expand, the VADJ rail supplies the output stages for the KC705 I/O banks
connected to the FMC connectors, so if you want to drive things using LVCMOS or
LVTTL 3.3V logic, you will have to program the VADJ rail to supply the
necessary voltage. It’s very straightforward; instructions are on
Are there no chip select lines on these DDS chips? If there are, use them. If
there are not, use a mux/demux chip instead of trying to hack up something
atrocious in the gateware.
From: Jonathan Mizrahi [mailto:jmizr...@umd.edu]
Sent: Friday, October 28, 2016 9:30 AM
To: Slichter, Daniel H
> > OK, thanks for confirming.
> > I have a two channel DDS board in which the DDSs have separate signal
> > lines but a common clock line. I am OK with only talking to one of them at a
> time.
> > What is the easiest way to implement the mux/demux you suggest? When
> I
> > declare the SPI bus I
> > As Daniel mentioned, for Ramsey experiments when you're scanning the
> > delay, when the delay is 0 you'd have two back to back pi/2 pulses.
> > How would that need to be coded differently? Explicitly,
> >
> > ttl.pulse(t_pi/2)
> > delay(t)
> > ttl.pulse(t_pi/2)
> >
> > and we scan t from 0
We definitely use zero-length pulses as a regular part of our experiments. The
most prominent example is scanning a pulse duration time (e.g. for Rabi
flopping, or delay between Ramsey pulses), where the first item in the list of
pulse durations to scan is a zero duration pulse (i.e. no Rabi
We had some brief discussions on this subject at the NIST group meeting today,
with responses inline below:
> * Venue? some ideas: NIST, JQI, DESY, Oxford, CERN, Warsaw University of
> Technology, Chinese University of Hong Kong.
We strongly prefer a location inside the US (much easier to
> Why not do blind submission and do the replacement at the satellite side
> plus asynchronous error reporting like RTIOBusy?
As long as the satellite is able to handle things appropriately for the type of
channel it is, I am OK with this. If it's a TTL you should do replace (as is
currently
It is certainly possible to get nice low-phase-noise sources at 150 MHz instead
of 100 MHz, but these would need to be special ordered. How much of a
challenge is using 100 MHz? Does the HMC830 not allow us leeway here?
One temporary solution would be to use an HMC830 (or equivalent) eval
> 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, will it end up taking a lot longer
(i.e.
> What "bells and whistles" do you mean? Do you mean things like fancy
> modulation/demodulation schemes for PDH locks etc? Let's have a bells and
> whistles list and see what we can agree to cull.
Agreed, I think a list of the current "bells and whistles" would help a lot in
terms of thinking
> You just need to get away from specifying sample rates and
> details of the DSP chain and start specifying the actual use cases.
My apologies; I thought I had sent an email to the entire list but it turns out
it just went to Sebastien. I reproduce the email I sent Sebastien last Friday
below
58 matches
Mail list logo
