> 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
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.
> 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
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
> > 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
to modify my hardware.
Jonathan Mizrahi
Research Scientist
Joint Quantum Institute
University of Maryland
301-314-1903
On Fri, Oct 28, 2016 at 11:10 AM, Slichter, Daniel H. (Fed)
<daniel.slich...@nist.gov<mailto:daniel.slich...@nist.gov>> wrote:
I have a two channel DDS board in which t
> > 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
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
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
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
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
> 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,
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++.
> 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
> 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
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
> 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
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>
...@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
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
> 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
> 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
> > 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?
> 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.
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
> > 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.
> 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
> 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
35 matches
Mail list logo
