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

[Thomas Harty via ARTIQ]

> I have spelled out in previous emails why I think there is a very compelling
> physics case for us to be able to run at 800 MSPS/1 GSPS (8x f_rtio at
> 100 MHz or 125 MHz RTIO freq, respectively),

> At intermediate field (119 G), relevant 9Be+ transitions are between 1 GHz
> and 1.4 GHz, so using 800 MSPS with 2x digital upconversion and mix-mode
> would probably work better.

Daniel,

to check I understand you here:
- by "digital upconversion" do you mean "interpolation" (i.e. only the DAC clock
  changes, not the output RF frequency)?
- in other words, your "800MSPS" use-case would be: f_rtio=100MHz, 
f_data=800MHz,
  f_dac=1.6GHz. With mix-mode you then have access to the 2nd nyquist zone from
  800MHz-1.2GHz and the 3rd nyquist zone from 1.2GHz to 1.6GHz

Some comments about this (if only as notes to myself):
- this could also be done with 1GSPs data rate by using MixMod to perform analog
  up-conversion. The only downside I can see with that is that it takes two DAC
  channels per microwave output due to IQ mixing, so more expensive if you need
  > 4 channels (although, if Sayma v2.0 delivers the promised cost savings,
  the cost of a channel of Sayma is actually relatively small compared with 
other costs
  like AOMs etc)
- with the digital mixing, there will be a bit of a dead-zone around 1.2GHz due
  to the various digital anti-aliasing filters, which may or may not be an
  issue depending on where the atomic transitions are
- you will get a slightly cluttered spectrum due to the presence of tones in
  both nyquist zones, which can't be filtered out (may also get some nasty
  third-order products when using a PA). again, this may or may not be a
  problem
- phase stability/noise will be worse with mix mode than with an analog IQ
  mixer
- due to the 100MHz RTIO, this can't be used in the same experiment as the
  1GSPS data rate. So, you can't use mix mode for state prep and IQ mixing for
  gates. You also have to accept the slightly coarser (1.25ns) time stamp
  resolution and ensure that everything else works at 100MHz f_rtio etc

For the time being, my top priority is to get Sayma into labs and RF applied to
ions. Given our limited resources, it would make sense to agree on a single
configuration (f_rtio, f_dac, f_data) to support in the first instance, on the
understanding that users are welcome to add support for other configurations
as and when they need them.

Does anyone object to making the 1GSPS configuration our main initial target,
assuming we can solve the resource/complexity issues satisfactorily?

Also, does anyone object to the DUC frequency resolution being f_rtio/2 in the
first instance? If that causes problems, we can always improve the resolution
to, say, f_rtio/4 down the line as and when needed. But, it would be good to
begin with something that's not over specified.


Finally, Daniel, are you happy to drop the request for modulation of the RF

envelope at 1GSPS for now? That can either be done using AWG instead

of SAWG, or could be a future extension of Sayma. But, again, for the first

version, can we focus on getting a minimal SAWG working at 1GSPS?


Best,

Tom


Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: Robert Jördens 
Sent: 11 August 2018 18:47:04
To: Thomas Harty
Cc: artiq@lists.m-labs.hk
Subject: Re: ARTIQ Digest, Vol 50, Issue 9

On Sat, Aug 11, 2018 at 12:12 PM Thomas Harty
 wrote:
> - Moninj: Chris B/David N will be able to give a better-informed view on this 
> than me, but my feeling is that moninj isn't actually that useful for the 
> SAWG. What would SAWG moninj include? Leaving aside the work/funding required 
> to implement sawg moninj, is it likely to be a problem in terms of resource 
> consumption/timing closure?

I would expect it to include monitoring and injection of all
parameters (9 + 1 cfg currently) of each SAWG channel.
In any reasonable implementation it is likely going to be
resource-hungry and routing-intensive without scalable moninj (#676).

> - External modulation (#801): I'm not sure I fully understand what this 
> proposal is. Can you give some details about what this would do and why it 
> would be needed, please?

You'll have to ask Joe et al. for the proposal and plan. But it could
well be that it has become completely irrelevant.

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

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

[Thomas Harty via ARTIQ]

> All correct, except the last bit: the digital equivalent of DC/LO

> leakage is less than one LSB. There will be a spur but it's well controlled.


Remind me, for the current design, what's a 1 LSB spur in dBc? How does that 
scale with the width parameters?


> How low do the other spurs have to be? They can also be controlled somewhat.


Generally, I'd argue that it's probably okay to think of this in terms of 
off-resonant excitation amplitude for a narrow-linewidth transition. So, the 
tolerable spur amplitude scales with the distance from the nearest atomic 
transition, which depends on the experiment. We're more sensitive if the spur 
offset is in the 100kHz - 10MHz range that motional modes lie in, due to 
Lamb-Dicke parameters.


> And regarding the benefit I don't see a reason why the spurs would 
> necessarily move or be guaranteed to change a lot by choosing the "band".


Am I wrong in thinking that the frequency separation between the spurs and the 
RF tones depends on things like the frequency of the base-band oscillator? So, 
for the same RF output frequency, the spur offset frequency can be moved by 
changing the DUC frequency. At the very least, I'd expect a spur at the DUC 
frequency, which will shift as that frequency changes. What am I missing here?


> Maybe f_rtio/4 is going to be quite a bit costlier than f_rtio/2


I can't see any reason to go finer than f_rtio/4. f_rtio/2 is probably okay, 
but we'd need to give it more thought. Would be interesting to see how much 
worse f_rtio/4 actually is in terms of FPGA resources etc.


> The logic resources are a bit worse than O(n*log(n)) in each of the
> bit width parameters. And the noise goes roughly as the well known 6dB
> per bit.


Thanks. Can you remind me what the noise situation is with the current 
parametrize? Am I right in thinking this just contributes white PM/AM? At what 
level in dBc/Hz?


I'm a bit reluctant to let the SAWG degrade the DAC's noise floor by too much. 
So, I'd prefer to try to concentrate on other ways of simplifying the design. 
If we can achieve something satisfactory without degrading the noise, let's do 
that. If we can't then we can come back to this.


T




Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: Robert Jördens 
Sent: 10 August 2018 18:11:33
To: Thomas Harty
Cc: artiq@lists.m-labs.hk
Subject: Re: ARTIQ Digest, Vol 50, Issue 9

On Thu, Aug 9, 2018 at 11:56 AM Thomas Harty
 wrote:
> Where are we in terms of resource usage with the current design? What's a 
> rough upper bound on how high we can push the resource utilization on an FPGA 
> for this kind of design before timing closure/compile times/etc becomes a 
> nightmare (50%? 75%?)?

IIRC resource usage is around 50%-60% now. But have a look at any Vivado run.
It gets increasingly hard anywhere between 70 and 90% depending on the routing.

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

The users who asked for that need to engage and answer that question.
I can only point to the issues on our radar. There is a more like
servoing in the plans and proposals.
https://github.com/m-labs/artiq/issues/675
https://github.com/m-labs/artiq/issues/801
https://github.com/m-labs/artiq/issues/651
https://github.com/m-labs/artiq/issues/688

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

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

[Thomas Harty via ARTIQ]

> IIRC resource usage is around 50%-60% now. But have a look at any Vivado run.

> It gets increasingly hard anywhere between 70 and 90% depending on the 
> routing.


Thanks for clarifying that.


Okay, so it really is the case that with the current design getting the 1GSPS 
data rate, 8-channel SAWG to fit on the FPGA is going to be marginal at best. 
It's not even just an issue that multi-hour compile times make debugging 
anything a nightmare. In that case, there clearly is a need to simplify the 
design.


> The users who asked for that need to engage and answer that question. I can 
> only point to the issues on our radar.


Thanks. So, we have:


- Moninj: Chris B/David N will be able to give a better-informed view on this 
than me, but my feeling is that moninj isn't actually that useful for the SAWG. 
What would SAWG moninj include? Leaving aside the work/funding required to 
implement sawg moninj, is it likely to be a problem in terms of resource 
consumption/timing closure?

- Analyzer: again, Chris B/David N are probably the people to answer this, but 
it seems useful to have this

- External modulation (#801): I'm not sure I fully understand what this 
proposal is. Can you give some details about what this would do and why it 
would be needed, please?


As mentioned before, the one bell/whistle that I am keen on is an AM input to 
the SAWG for a noise eater along the lines of SU-servo. Comments:

- no need for more than 1MSPS modulation bandwidth, since IIRC the DAC/JESD 
latency alone limits us to something like 300kHz loop bandwidth

- I'd be happy with only being able to modulate the common-mode amplitude for 
the two SAWG tones if that's easier, don't need to be able to modulate the 
amplitude of the individual tones

- FM/PM might also be useful to some users, I guess, but I can't think of a 
concrete use-case in our lab. Unless anyone specifically want's that, I'd argue 
we can leave it out. In most cases, it will be easier to do things like fibre 
phase noise cancellation with a separate AOM that runs CW using a FM version of 
the Urukul-Sampler servo.


> However, among the features  is one thing that I think is very important for 
> us (but all can be  debated at this stage),
> namely having the envelope for the upconverted  sine waves update at the full 
> 1 GSPS update rate. This is relevant for
> both the Oxford fast laser gate and the magtrap, where we want to be  able to 
> do pulse shaping on rise/fall times in the ~5-15 ns range.

If this is okay from a resource/complexity point of view then obviously I don't 
object to it, but I'd put that pretty low down my priorities list. For now, I'm 
keen to find the easiest way of getting the SAWG working at the full 1GSPS data 
rate, which is an obvious prerequisite to this anyway.

Beyond that though, it's not totally clear to me that this is a good use-case 
for SAWG as opposed to good old fashioned AWG. Maybe I'm wrong here, but I 
think of SAWG as a means of data compression when the modulation bandwidth is 
low compared with the sample rate. Once you start modulating close to the 
sample rate, it's not so clear to me that one wins by using a SAWG instead of 
playing pulses back from ram via DMA (maybe through a multiplier to enable 
noise eating). For such short pulses, the event rate you have will be large 
compared with the sustained RTIO event rate, so you'll probably be using DMA 
even if you do use SAWG.

Maybe you feel differently, but I'm not sure that the win from doing this via 
SAWG instead of DMA/AWG is worth the increased complexity (unless it really is 
small) from making the SAWG modulation bandwidth so high.


Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: Robert Jördens 
Sent: 10 August 2018 18:11:33
To: Thomas Harty
Cc: artiq@lists.m-labs.hk
Subject: Re: ARTIQ Digest, Vol 50, Issue 9

On Thu, Aug 9, 2018 at 11:56 AM Thomas Harty
 wrote:
> Where are we in terms of resource usage with the current design? What's a 
> rough upper bound on how high we can push the resource utilization on an FPGA 
> for this kind of design before timing closure/compile times/etc becomes a 
> nightmare (50%? 75%?)?

IIRC resource usage is around 50%-60% now. But have a look at any Vivado run.
It gets increasingly hard anywhere between 70 and 90% depending on the routing.

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

The users who asked for that need to engage and answer that question.
I can only point to the issues on our radar. There is a more like
servoing in the plans and proposals.
https://github.com/m-labs/artiq/issues/675
https://github.com/m-labs/artiq/issues/801

Re: [ARTIQ] SAWG

[Thomas Harty via ARTIQ]

Yes, the simplest design that does the job is the best.


Unfortunately, the issue with building hardware for physics experiments is that 
there is never a clear-cut and exact specification for what's needed for a 
number of reasons:

- it wouldn't be research if we understood everything completely

- often, we can tolerate a decrease in HW performance by adding additional 
complexity elsewhere in our experiment

- if we're going to spend large sums of money on HW, we want to make sure that 
we have some performance overhead in case our requirements change in the future 
-- at something like 10k a Sayma, we don't want to find that it doesn't meet 
our long-term needs because we skimped on the specification

- we want to try to leave the door open for new use cases/experiments we 
haven't yet thought of


So, the only way to arrive at a good design is to understand the trade-offs 
between performance and its impact on users and complexity, so we can try to 
make an informed decision about where to aim for. If you want to argue for a 
decrease in design complexity, that's fine, but we need details. Various 
changes are being discussed. How much difference would each of them actually 
make to you? If you just keep repeating that "simpler designs are better" 
without giving any more details, I don't see how we're supposed to make any 
progress on this.


T


Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572



From: Thomas Harty
Sent: 09 August 2018 08:12
To: Sébastien Bourdeauducq; artiq@lists.m-labs.hk; Robert Jördens
Subject: Re: SAWG


Sébastien,


Understood. But, that's quite a vague answer. We don't want to throw away 
performance/flexibility unnecessarily. 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? If we need a short exploratory project to answer those questions then so 
be it.


Tom



Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: Sébastien Bourdeauducq 
Sent: 09 August 2018 02:53:43
To: Thomas Harty; artiq@lists.m-labs.hk; Robert Jördens
Subject: SAWG

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

Re: [ARTIQ] SAWG

[Thomas Harty via ARTIQ]

Sébastien,


Understood. But, that's quite a vague answer. We don't want to throw away 
performance/flexibility unnecessarily. 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? If we need a short exploratory project to answer those questions then so 
be it.


Tom



Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: Sébastien Bourdeauducq 
Sent: 09 August 2018 02:53:43
To: Thomas Harty; artiq@lists.m-labs.hk; Robert Jördens
Subject: SAWG

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

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

[Thomas Harty via ARTIQ]

"significantly" (6dB?) seems like a good starting point however. 
Again, we can probably relax this specification if there is a really good 
reason to. But, I think we would need to see a clear argument for what we would 
gain by doing so, and how much we would need to degrade the noise floor by.


Best,


Tom


Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: ARTIQ  on behalf of 
artiq-requ...@lists.m-labs.hk 
Sent: 19 July 2018 11:00:05
To: artiq@lists.m-labs.hk
Subject: ARTIQ Digest, Vol 50, Issue 9

Send ARTIQ mailing list submissions to
artiq@lists.m-labs.hk

To subscribe or unsubscribe via the World Wide Web, visit
https://ssl.serverraum.org/lists/listinfo/artiq
or, via email, send a message with subject or body 'help' to
artiq-requ...@lists.m-labs.hk

You can reach the person managing the list at
artiq-ow...@lists.m-labs.hk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARTIQ digest..."


Today's Topics:

   1. Re: ARTIQ Digest, Vol 50, Issue 7 (Robert Jördens)


--

Message: 1
Date: Wed, 18 Jul 2018 19:24:11 +0200
From: Robert Jördens 
To: artiq@lists.m-labs.hk
Subject: Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 7
Message-ID:

Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 18, 2018 at 5:48 PM Thomas Harty via ARTIQ
 wrote:
> > * Is (f0+f1, f0+f2) better than (f0+f1-f2, f0+f1+f2)? (with f0 coarse,
> > and f1/f2 fine) etc. Or other parametrizations.
> > * What is the maximum step size of f0 in terms of the f1/f2 rate?
>
> By `(f0 + f1)` do you mean the current parametrization? 
> http://m-labs.hk/artiq/manual-master/core_drivers_reference.html?highlight=sawg#artiq.coredevice.sawg.SAWG

Yes.

> My minimal requirements are to be able to pick an arbitrary (within the SAWG 
> BW) centre frequency, fc, and to be able to produce either a single tone or a 
> pare of tones anywhere within, say, +-10MHz of that centre frequency without 
> changing the DUC frequency f0. So long as the DUC size steps are small enough 
> to allow this then I'm happy.

The proposal is to have the f0 DUC at 125 MHz or 62.5 MHz granularity
and do move the remaining center frequency offset into f1/f2

> Having said that, more flexibility is always useful, so I'd be keen to keep 
> the f0 size steps as small as reasonably (without excessive complexity) 
> possible. I don't understand the flexibility v complexity trade-offs well 
> enough here to know what level of flexibility would be best to shoot for.

The coarse f0 DUC (as per the proposal) would be tens of multipliers
instead of eight CORDICs+accumulators. We'd need an exploratory
project to get hard numbers for the resource trade of.

> > * What width is really needed for the FTW on f1/f2?
>
> Less than 32-bits (0.2Hz for 1GSPS) is problematic. A few more bits would be 
> nice, but can be traded off against gateware complexity.

One eighth of that. f1/f2 would run at 125 MHz.

> > * What width do we need for the CORDICs (IQ)? Are we just beating the
> > spurs? Then we certainly don't need 16 bits. Or is 16 bit amplitude
> > resolution needed?
> > And saying "one LSB", "16 bit" or equivalent might sound convenient
> > but it's also potentially very expensive. If the requirement can't be
> > derived from physics, then something like the DAC SFDR would be a
> > reasonable target.
>
> Remind me, does the CORDIC width affect broad-band noise, or just spur level? 
> If it's just spurs then I'm probably not too concerned so long as it doesn't 
> degrade the SFDR -- although, I'd need to look at where the spurs are to be 
> confident in that.

Both in different ways through different "width" paramters. What broad
band phase noise is required?

Robert.


--

Subject: Digest Footer

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

--

End of ARTIQ Digest, Vol 50, Issue 9

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

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

[Thomas Harty via ARTIQ]

> Fine adjustment of SAWG f0 by RTIO and local DSP is the planned path

> for dynamically compensating for time-variation of the Coherent

> Paladin laser repetition rate. Could the resolution of the the f0 NCO

> be defined parametrically? This could enable relatively

> straightforward switching between faster compile times and finer

> resolution.


Can't you do that equally well by adjusting the frequencies of the baseband 
oscillators while holding the DUC frequency fixed (assuming the drifts are 
small compared with the RTIO frequency)?


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.


(*) this was certainly the case in the early days of Sayma where the board 
behaved differently when replacing the SAWG with a dummy ramp generator. 
Thankfully now the PI issues that caused that have been fixed, it seems that 
all non-SAWG related issues can be debugged without compiling the SAWG, so this 
may be less of an issue...


Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: Joe Britton 
Sent: 10 July 2018 21:37:31
To: Thomas Harty
Cc: artiq@lists.m-labs.hk
Subject: Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2

> It would be good to get the interpolation running, both to improve spectral
> purity and to put the hardware through its paces before we move on to the
> next design revision (I'd love to see synchronisation at max DAC clock
> rate).

I agree with @hartytp on this. Pushing digitization artifacts to
higher frequencies is really helpful.

>> drastically reduce the SAWG digital upconverter resolution to a few
>> frequencies (use the other NCOs to for fine tuning).

Fine adjustment of SAWG f0 by RTIO and local DSP is the planned path
for dynamically compensating for time-variation of the Coherent
Paladin laser repetition rate. Could the resolution of the the f0 NCO
be defined parametrically? This could enable relatively
straightforward switching between faster compile times and finer
resolution.

> - f_RTIO = 125MHz
> - f_DAC = 2GHz
> - f_data = 1GSPS (2 x interpolation)

These parameters are fine for the UMD-Duke-ARL application set. -Joe
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

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

[Thomas Harty via ARTIQ]

> use the DAC interpolation modes (2X, 4X, 8X) if the goal is simply to improve 
> spectral purity.


It would be good to get the interpolation running, both to improve spectral 
purity and to put the hardware through its paces before we move on to the next 
design revision (I'd love to see synchronisation at max DAC clock rate).


> drastically reduce the SAWG digital upconverter resolution to a few 
> frequencies (use the other NCOs to for fine tuning).



You mean something like 
https://github.com/sinara-hw/sinara/issues/515#issuecomment-371481089 ?


I can't see that being a problem for us, so if it makes a big difference to the 
ease of development/maintenance then I'd be happy with it.


Long term, the configuration I'd like to use is:

- f_RTIO = 125MHz

- f_DAC = 2GHz

- f_data = 1GSPS (2 x interpolation)


T



Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: ARTIQ  on behalf of 
artiq-requ...@lists.m-labs.hk 
Sent: 09 July 2018 11:00:04
To: artiq@lists.m-labs.hk
Subject: ARTIQ Digest, Vol 50, Issue 2

Send ARTIQ mailing list submissions to
artiq@lists.m-labs.hk

To subscribe or unsubscribe via the World Wide Web, visit
https://ssl.serverraum.org/lists/listinfo/artiq
or, via email, send a message with subject or body 'help' to
artiq-requ...@lists.m-labs.hk

You can reach the person managing the list at
artiq-ow...@lists.m-labs.hk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARTIQ digest..."


Today's Topics:

   1. Sayma DAC frequencies (Sébastien Bourdeauducq)


--

Message: 1
Date: Mon, 9 Jul 2018 12:08:50 +0800
From: Sébastien Bourdeauducq 
To: "artiq@lists.m-labs.hk" 
Subject: [ARTIQ] Sayma DAC frequencies
Message-ID: <26b2caca-db15-edc3-b2e3-e045064d6...@m-labs.hk>
Content-Type: text/plain; charset=utf-8; format=flowed

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


--

Subject: Digest Footer

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

--

End of ARTIQ Digest, Vol 50, Issue 2

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

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

[Thomas Harty via ARTIQ]

> any objections to supporting only the RTIO clock frequency (currently 150MHz) 
> at the Sayma input, instead of 100MHz?


Assuming you mean "supporting" in the sense of which bitstreams M-Labs will 
build and test, I'm fine with that.


IIRC, changing reference frequency is pretty easy and only requires changing 
HMC830 divider values 
(https://github.com/m-labs/artiq/blob/574892a4e549e5882a46dcfa51016f5051404869/artiq/firmware/libboard_artiq/hmc830_7043.rs#L336)
 and potentially the FPGA SYSREF phase to meet S/H 
(https://github.com/m-labs/artiq/blob/574892a4e549e5882a46dcfa51016f5051404869/artiq/firmware/libboard_artiq/hmc830_7043.rs#L175)
 -- and that latter requirement could probably be removed by adding a proper 
CDC on that input. So it's easy for users to change this later on to whatever 
they want (within reason).


>  I think it is more easy way to leave an 10MHz clock input, through I don't 
> understand why almost all of the frequency standard output 10MHz.


I don't think that's supported in HW atm (baluns etc). You'd have to check. In 
any case, the design is optimized for working with a higher frequency reference 
than 10MHz. You'll take a bit of a phase noise hit if you try to use the HMC830 
to get from 10MHz to 2GHz.


T


Dr Thomas Harty
Junior Research Fellow, St John's College
University of Oxford, Department of Physics
The Clarendon Laboratory
Parks Road, Oxford, OX1 3PU
Mob: +44 (0)7986 375 052
Lab: +44 (0)1865 272 572

From: ARTIQ  on behalf of 
artiq-requ...@lists.m-labs.hk 
Sent: 19 June 2018 11:00:07
To: artiq@lists.m-labs.hk
Subject: ARTIQ Digest, Vol 49, Issue 2

Send ARTIQ mailing list submissions to
artiq@lists.m-labs.hk

To subscribe or unsubscribe via the World Wide Web, visit
https://ssl.serverraum.org/lists/listinfo/artiq
or, via email, send a message with subject or body 'help' to
artiq-requ...@lists.m-labs.hk

You can reach the person managing the list at
artiq-ow...@lists.m-labs.hk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARTIQ digest..."


Today's Topics:

   1. Sayma input frequency (Sébastien Bourdeauducq)
   2. Re: Sayma input frequency (Slichter, Daniel H. (Fed))
   3. Re: Sayma input frequency (joe wong)


--

Message: 1
Date: Mon, 18 Jun 2018 21:28:55 +0800
From: Sébastien Bourdeauducq 
To: "artiq@lists.m-labs.hk" 
Cc: Ken Brown , Jungsang Kim

Subject: [ARTIQ] Sayma input frequency
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

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


--

Message: 2
Date: Mon, 18 Jun 2018 21:27:19 +
From: "Slichter, Daniel H. (Fed)" 
To: Sébastien Bourdeauducq , "artiq@lists.m-labs.hk"

Cc: Ken Brown , Jungsang Kim

Subject: Re: [ARTIQ] Sayma input frequency
Message-ID:



Content-Type: text/plain; charset="utf-8"

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 board to 
generate 150 MHz from another reference frequency and feed that to the Sayma 
input connector.  However, over the longer term I think it would be good to 
have Sayma able to operate from a more standard reference frequency such as 100 
MHz.

> -Original Message-
> From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sébastien
> Bourdeauducq via ARTIQ
> Sent: Monday, June 18, 2018 7:29 AM
> To: artiq@lists.m-labs.hk
> Cc: Ken Brown ; Jungsang Kim
> 
> Subject: [ARTIQ] Sayma input frequency
>
> 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fssl.serverr
> aum.org%2Flists%2Flistinfo%2Fartiq=02%7C01%7Cdaniel.slichter%40nist.
> gov%7C05f9ee8fb8ec4fc6878308d5d51f7c2f%7C2ab5d82fd8fa4797a93e054655
> c61dec%7C1%7C0%7C636649253558496201=tfd6NTpKq73oYUwH3t7J9
> w%2FUOnfF0IhOAa8ksKkYzB8%3D=0

--

Message: 3
Date: Tue, 19 Jun 2018 10:35:29 +0800
From: joe wong 
To: "Slichter, Daniel H. (Fed)" 
Cc: Sébastien Bourdeauducq , "artiq@lists.m-labs.hk"
, Ken Brown ,
Jungsang Kim 
Subject: Re: [ARTIQ] Sayma input frequency
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi All,

the frequency standard output generally 10MHz, many choices like SRS FS725
or FS740. Usually, they need the GPS to 

[ARTIQ] Purchasing artiq hardware

[Thomas Harty via ARTIQ]

Dear all,

The first artiq hardware is now available to buy!

You can now buy the following boards (fully populated and tested, complete with 
aluminium front panels):

VHDCI_carrier
BNC_DIO
SMA_DIO
RJ45_DIO

See https://github.com/m-labs/sinara/wiki for more info about these boards.

Note that all hardware is currently in the v2 prototype stage, so (hopefully 
minor) changes are expected for the final revision. Changes are tracked on the 
Sinara GitHub project.

Currently, the supplier is TechnoSystem, who accept PayPal or purchase orders. 
Email Wojciech Niedźwiedź 
>, 
copying in Grzegorz Kasprowicz > 
to get a quote. In future, there will be an online webshop to make purchasing 
easier. Lead time is currently around 3 weeks, but should get quicker when 
everyone’s back from their August holidays.

Thanks again to Greg and his team for all the work they’ve put into this.

Best,

Tom

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

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

[Thomas Harty via ARTIQ]

ers 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
> 
> 
> --
> 
> Subject: Digest Footer
> 
> ___
> ARTIQ mailing list
> https://ssl.serverraum.org/lists/listinfo/artiq
> 
> --
> 
> End of ARTIQ Digest, Vol 37, Issue 6
> 
> 
> 
> --
> 
> Message: 2
> Date: Thu, 29 Jun 2017 12:27:17 +
> From: "Slichter, Daniel H. (Fed)" <daniel.slich...@nist.gov>
> To: "'artiq@lists.m-labs.hk'" <artiq@lists.m-labs.hk>
> Subject: Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6
> Message-ID:
>   
> <by1pr09mb05994c1bc69d7602f88fb88191...@by1pr09mb0599.namprd09.prod.outlook.com>
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I second Tom's thoughts here -- I would go for the largest Artix-7 we can 
> reasonably accommodate, just for flexibility.  Going with the -2 speed grade 
> sounds like it makes a lot of sense.
> 
> 
> Best,
> 
> Daniel
> 
> 
> From: ARTIQ <artiq-boun...@lists.m-labs.hk> on behalf of Thomas Harty via 
> ARTIQ <artiq@lists.m-labs.hk>
> Sent: Thursday, June 29, 2017 4:16:32 AM
> To: artiq@lists.m-labs.hk
> Subject: Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6
> 
> Sébastien,
> 
> Given the relatively low cost of the Artix-7 FPGAs, my preference is 
> generally to go as big and as fast as reasonably possible. I don't want to 
> find that, for example, we can't fit a hard FPU/fancy servo on Kasli because 
> we saved $50 on the FPGA. Also, since gateware development is usually much 
> more expensive than hardware, I'd rather go for dumb/inefficient gateware on 
> big FPGAs than have to optimise the gateware to fit on a smaller FPGA.
> 
> 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.
> 
> Having said all that, if you think the 50T in the -2 speed grade won't be a 
> limitation then I'm happy to go along with your recommendation...
> 
> T
> 
> 
> From: ARTIQ [artiq-boun...@lists.m-labs.hk] on behalf of 
> artiq-requ...@lists.m-labs.hk [artiq-requ...@lists.m-labs.hk]
> Sent: 29 June 2017 11:00
> To: artiq@lists.m-labs.hk
> Subject: ARTIQ Digest, Vol 37, Issue 6
> 
> Send ARTIQ mailing list submissions to
>artiq@lists.m-labs.hk
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://ssl.serverraum.org/lists/listinfo/artiq
> or, via email, send a message with subject or body 'help' to
>artiq-requ...@lists.m-labs.hk
> 
> You can reach the person managing the list at
>artiq-ow...@lists.m-labs.hk
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARTIQ digest..."
> 
> 
> Today's Topics:
> 
>   1. Kasli FPGA selection (Sébastien Bourdeauducq)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 29 Jun 2017 12:23:04 +0800
> From: Sébastien Bourdeauducq <s...@m-labs.hk>
> To: Thomas Harty <thomas.peter.ha...@gmail.com>
> Cc: "artiq@lists.m-labs.hk" <artiq@lists.m-labs.hk>, Grzegorz
>Kasprowicz <kaspr...@gmail.com>
> Subject: [ARTIQ] Kasli FPGA selection
> Message-ID: <25ce5ee0-1bbb-3b7c-851d-3e1bc9e29...@m-labs.hk>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> 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
&

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

[Thomas Harty via ARTIQ]

Sébastien,

Given the relatively low cost of the Artix-7 FPGAs, my preference is generally 
to go as big and as fast as reasonably possible. I don't want to find that, for 
example, we can't fit a hard FPU/fancy servo on Kasli because we saved $50 on 
the FPGA. Also, since gateware development is usually much more expensive than 
hardware, I'd rather go for dumb/inefficient gateware on big FPGAs than have to 
optimise the gateware to fit on a smaller FPGA. 

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.

Having said all that, if you think the 50T in the -2 speed grade won't be a 
limitation then I'm happy to go along with your recommendation...

T


From: ARTIQ [artiq-boun...@lists.m-labs.hk] on behalf of 
artiq-requ...@lists.m-labs.hk [artiq-requ...@lists.m-labs.hk]
Sent: 29 June 2017 11:00
To: artiq@lists.m-labs.hk
Subject: ARTIQ Digest, Vol 37, Issue 6

Send ARTIQ mailing list submissions to
artiq@lists.m-labs.hk

To subscribe or unsubscribe via the World Wide Web, visit
https://ssl.serverraum.org/lists/listinfo/artiq
or, via email, send a message with subject or body 'help' to
artiq-requ...@lists.m-labs.hk

You can reach the person managing the list at
artiq-ow...@lists.m-labs.hk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARTIQ digest..."


Today's Topics:

   1. Kasli FPGA selection (Sébastien Bourdeauducq)


--

Message: 1
Date: Thu, 29 Jun 2017 12:23:04 +0800
From: Sébastien Bourdeauducq 
To: Thomas Harty 
Cc: "artiq@lists.m-labs.hk" , Grzegorz
Kasprowicz 
Subject: [ARTIQ] Kasli FPGA selection
Message-ID: <25ce5ee0-1bbb-3b7c-851d-3e1bc9e29...@m-labs.hk>
Content-Type: text/plain; charset=utf-8; format=flowed

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


--

Subject: Digest Footer

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

--

End of ARTIQ Digest, Vol 37, Issue 6

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

Re: [ARTIQ] ARTIQ Digest, Vol 34, Issue 3

[Thomas Harty via ARTIQ]

Neal,

If we can bulk the order, that should bring the price down a little. Talking to 
the accounts people here, it sounds like it is "nearly impossible" to bill 
groups outside UMD (ie, to put 10x boards on a single PO through UMD, then 
re-arrange monies afterwards), but hopefully either of those companies will 
quote us with the assumption/promise that each group will pay for their 
quantity separately…?

Thanks for the offer, but I’ve already ordered a batch of the PCBs from Itead 
Studio, with the intention of populating them ourselves. We have a decent oven 
here, which we’ve used for FMCs before without problems. Given how simple this 
board is compared to the average university finance system, my bet is that 
assembling a couple of them will take less time than arranging a joint 
purchasing agreement…

T


On 15 Mar 2017, at 20:36, Neal Pisenti 
<npise...@gmail.com<mailto:npise...@gmail.com>> wrote:

I was about to email out for quotes from Creotech and Technosystem for the FMC 
-> VHCDI boards. It sounds like Joe wants ~2x, we want 2x, and @Tom, I'm 
guessing you guys want at least 2x as well... that puts us in the qty 6-10 
range.

If we can bulk the order, that should bring the price down a little. Talking to 
the accounts people here, it sounds like it is "nearly impossible" to bill 
groups outside UMD (ie, to put 10x boards on a single PO through UMD, then 
re-arrange monies afterwards), but hopefully either of those companies will 
quote us with the assumption/promise that each group will pay for their 
quantity separately...?

If you guys have any other ideas, let me know.

Neal

On Fri, Mar 10, 2017 at 8:58 AM Grzegorz Kasprowicz via ARTIQ 
<artiq@lists.m-labs.hk<mailto:artiq@lists.m-labs.hk>> wrote:
I already received assembled 3U boards including VHDCI carrier and BNC IO.
So we can test whole setup in the lab quickly.
You can help us with simple HDL design for KC705 that i.e. toggles IOs or makes 
loopback: ttl->lvds->VHDCI-> FPGA-> VHDCI->lvds->TTL.
At the moment we are so occupied with other tasks that every help is very 
valuable.
Greg

On 10 March 2017 at 14:33, Thomas Harty 
<thomas.ha...@physics.ox.ac.uk<mailto:thomas.ha...@physics.ox.ac.uk>> wrote:
> It is compatible with VHDCI carrier - I used the same pinout.

Thanks for confirming that. In that case, we'll have a few of these made up, 
and plan to use them with the KC705 + VHDCI carrier as a short-term solution.


-Original Message-
From: ARTIQ 
[mailto:artiq-boun...@lists.m-labs.hk<mailto:artiq-boun...@lists.m-labs.hk>] On 
Behalf Of Thomas Harty via ARTIQ
Sent: Friday, March 10, 2017 12:56 PM
To: artiq@lists.m-labs.hk<mailto:artiq@lists.m-labs.hk>
Subject: Re: [ARTIQ] ARTIQ Digest, Vol 34, Issue 3

> ..., and we might spin up some in-house boards for multichannel DAC over SPI.

FYI, the Zotino and Novogorny DAC/ADC EEMs are now funded (Oxford/Freiburg) and 
being designed by WUT. They should be ready in ~12weeks. We're planning to 
contract M-Labs to provide full support for them.

The draft specifications are on the Wiki at 
https://github.com/m-labs/sinara/wiki feel free to comment on them if you have 
requests/questions.

> What adapters in particular? http://www.ohwr.org/projects/fmc-vhdci?

@Greg, can you confirm whether this is compatible with the VHDCI carrier?
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq


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

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

Re: [ARTIQ] ARTIQ Digest, Vol 34, Issue 3

[Thomas Harty via ARTIQ]

> It is compatible with VHDCI carrier - I used the same pinout.

Thanks for confirming that. In that case, we'll have a few of these made up, 
and plan to use them with the KC705 + VHDCI carrier as a short-term solution.


-Original Message-
From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Thomas Harty 
via ARTIQ
Sent: Friday, March 10, 2017 12:56 PM
To: artiq@lists.m-labs.hk
Subject: Re: [ARTIQ] ARTIQ Digest, Vol 34, Issue 3

> ..., and we might spin up some in-house boards for multichannel DAC over SPI.

FYI, the Zotino and Novogorny DAC/ADC EEMs are now funded (Oxford/Freiburg) and 
being designed by WUT. They should be ready in ~12weeks. We're planning to 
contract M-Labs to provide full support for them.

The draft specifications are on the Wiki at 
https://github.com/m-labs/sinara/wiki feel free to comment on them if you have 
requests/questions.

> What adapters in particular? http://www.ohwr.org/projects/fmc-vhdci?

@Greg, can you confirm whether this is compatible with the VHDCI carrier?
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

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

Re: [ARTIQ] ARTIQ Digest, Vol 34, Issue 3

[Thomas Harty via ARTIQ]

> ..., and we might spin up some in-house boards for multichannel DAC over SPI.

FYI, the Zotino and Novogorny DAC/ADC EEMs are now funded (Oxford/Freiburg) and 
being designed by WUT. They should be ready in ~12weeks. We're planning to 
contract M-Labs to provide full support for them.

The draft specifications are on the Wiki at 
https://github.com/m-labs/sinara/wiki feel free to comment on them if you have 
requests/questions.

> What adapters in particular? http://www.ohwr.org/projects/fmc-vhdci?

@Greg, can you confirm whether this is compatible with the VHDCI carrier?
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq

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

[Thomas Harty via ARTIQ]

Hi,

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

FWIW, we are currently planning to use the KC705 + FMC_VHDCI apater + VHDCI 
carrier to run one of our experiments from until the Metlino/Kasli system is 
more developed.

This would be something we develop and maintain in house as a short-term fix. 
But, we should be able to give you some help getting your system up and running.

Tom

From: ARTIQ [artiq-boun...@lists.m-labs.hk] on behalf of 
artiq-requ...@lists.m-labs.hk [artiq-requ...@lists.m-labs.hk]
Sent: 09 March 2017 11:00
To: artiq@lists.m-labs.hk
Subject: ARTIQ Digest, Vol 34, Issue 2

Send ARTIQ mailing list submissions to
artiq@lists.m-labs.hk

To subscribe or unsubscribe via the World Wide Web, visit
https://ssl.serverraum.org/lists/listinfo/artiq
or, via email, send a message with subject or body 'help' to
artiq-requ...@lists.m-labs.hk

You can reach the person managing the list at
artiq-ow...@lists.m-labs.hk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARTIQ digest..."


Today's Topics:

   1. Re: starter ARTIQ hardware for neutral atoms
  (Sébastien Bourdeauducq)


--

Message: 1
Date: Thu, 9 Mar 2017 12:24:39 +0800
From: Sébastien Bourdeauducq 
To: Neal Pisenti , "artiq@lists.m-labs.hk"

Subject: Re: [ARTIQ] starter ARTIQ hardware for neutral atoms
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

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



--

Subject: Digest Footer

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

--

End of ARTIQ Digest, Vol 34, Issue 2

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