Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 9
> 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 what to trim. My two cents is that shifts in increments of f_rtio/4 would definitely be fine enough for DUC. 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), so I am willing to sacrifice a lot of other "features" in order to achieve this higher sample rate. 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. I would also point out that if for some reason this SAWG gateware does not meet people's needs down the line, one can pay to have a different version developed which chooses a different set of tradeoffs. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> 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 (with a couple of minor clarifications), which gives our use cases and
the motivation for wanting to run at 1 GSPS as well as 600 MSPS.
===
> What sample rate(s) would you like to see and why?
The primary application here would be the driving of AOMs centered at 220 MHz
(which could be done at 600 MSPS in theory) or 330 MHz (much harder to avoid
Nyquist images at 600 MSPS). We would most likely want 1 GSPS, with an RTIO
clock of 125 MHz, which also aids compatibility with our other hardware and its
RTIO clock frequencies (although some of our setups run with 100 MHz RTIO
clock, and thus we'd aim for 8x multiplexing still but which would yield 800
MSPS -- still suitable for the 220 MHz and 330 MHz AOMs though). For a 1 GSPS
data rate, the DAC clock could be run at 1 GSPS, or with the 2x interpolation
enabled at 2 GSPS. We also have AOMs at ~600 MHz that we would like to drive.
For this application, we would take the second Nyquist image running at 1 GSPS
with no DAC interpolation, probably in mix mode and define our band with
filters afterwards (200 MHz would then separate first and second Nyquist images
so easy to filter). For obvious reasons 600 MSPS would be a very poor data
rate choice for this application.
The second application for this would be microwave hyperfine transitions
accessed using single-sideband mixing with the Sayma outputs as the I and Q
inputs to an external mixer. Having 1 GSPS data rates would give us sufficient
bandwidth to span the hyperfine manifold of 25Mg+ qubits at intermediate field
(212 G); running at 600 GSPS (for example) would not allow this, as spanning
all relevant hyperfine transitions for shelving requires ~700 MHz of bandwidth
(350 MHz on each side of a carrier would work). For this application, we would
likely want to use 2x DAC interpolation to improve spectral purity and clean up
undesired Nyquist images.
Because of the way the internals of the DAC work, using the NCO in the DAC to
shift signals to higher Nyquist bands forces the outputs to be paired as I/Q
channels, so for direct synthesis of microwaves for 9Be+ or 25Mg+ qubits, one
would have to discard half the output channels. For this task we would
probably perform updates of the internal NCO to shift frequencies coarsely, but
data rates of 1 GSPS would allow 2x digital upconversion plus internal NCO
shifting to higher Nyquist zones, at the cost of half the output channels, to
enable direct output using mix-mode of signals up to 2 GHz, placing undesired
images out of harm's way for 9Be+ at low field. 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. Using 600
MSPS data rates with 4x upconversion would enable signals out to 2.4 GHz, which
would be more suitable for 25Mg+ direct generation at 212 G (~1.3 GHz to ~2.1
GHz).
> 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.
I think we definitely would like to see these implemented to improve spectral
purity. Implementation of the Nyquist band shifting with the DAC onboard NCO
would be good but can happen later as long as 1 GSPS data rates are supported.
> * drastically reduce the SAWG digital upconverter resolution to a few
> frequencies (use the other NCOs to for fine tuning).
Referencing the Github comment that Tom referred to in his email:
https://github.com/sinara-hw/sinara/issues/515#issuecomment-371481089
"Even up-conversion to n*k/m*f_RTIO (k=8=f_sample/f_RTIO here) with m=16 and n
\in {0,...,m-1} could turn out to be as simple as m=8."
This kind of selection of available DUC frequencies on SAWG would be more than
enough from my perspective. For finer compensation you could just put the
frequency shift in the sine waves generated at baseband, as pointed out by Tom.
Best,
Daniel
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 50, Issue 2
> 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. I think we will really need the 8x interleaving at the RTIO clock rate, because 1 GSPS is pretty critical (600 MSPS is marginal or a non-starter for most of our use cases). This to me seems much more important than maintaining some kind of more arbitrary flexibility for DUC. I am a little unclear on others' use cases regarding DUC on the FPGA itself, but it seems to me that simply being able to shift the output by integer multiples of fs/8 (or fs/16, perhaps) should be more than satisfactory. It would appear to me that any tuning with finer frequency resolution can/should be done with the baseband signals coming out of the 8 interleaved generation blocks. Sebastien, are you saying that even this level of DUC presents substantial challenge? Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Sayma input frequency
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&data=02%7C01%7Cdaniel.slichter%40nist. > gov%7C05f9ee8fb8ec4fc6878308d5d51f7c2f%7C2ab5d82fd8fa4797a93e054655 > c61dec%7C1%7C0%7C636649253558496201&sdata=tfd6NTpKq73oYUwH3t7J9 > w%2FUOnfF0IhOAa8ksKkYzB8%3D&reserved=0 ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] scans and generators on core device?
> 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. processor slack) than the current way of just passing a list to the kernel which it can step through to scan something? I'd say this feature would enable kernel code to be written a little more "Pythonically", but if that comes at a serious performance cost that's not what we want to do. My personal feeling for our experiments is that code executing on the core device should be limited to fairly low-level stuff, and so lists etc are fine, especially if the computation of list values on the fly with generators is computationally slow/inefficient on the core device. Similarly with the MultiScanManager, just having the scan unrolled and flattened to 1D at compile time is currently suitable for our purposes. It may make sense to revisit these topics more in the future, as needs/applications change. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Example Ion Trap Code
> What about publishing Raghu's code? It seemed pretty clean from the quick > look I had at it during NACTI. For use as a general tutorial, the magtrap code that Raghu/NIST has written is too complex and contains too many behaviors/design features that are specific to our particular experiment. It would require substantial work to retool it for use as a proper introduction for people who are new to ARTIQ, and this sort of work has lower priority than our scientific projects at the current time. This tutorial needs to stand on its own, without requiring the authors of the tutorial to be available to answer questions; if we just post existing code, there will be a million different questions about minor/irrelevant details (we have had this experience a great deal already when people have looked at our code), making it a huge time sink for us and not very useful to new users. The reason we suggested a collaboration with a new group starting up with ARTIQ is that they are best equipped to provide an accurate representation of the sorts of questions/confusions/pitfalls that typical new users might have, and so they will be able to comment their code and/or structure the tutorial to address these most efficiently. We are willing to collaborate with such a group to provide some general guidance on how we have solved relevant problems, and offer advice on efficient code structure, which would provide a benefit for the group getting started with ARTIQ, and then for other new users as the tutorial takes shape. I suggest that any tutorial(s)/example code be hosted in a separate repository from ARTIQ itself. > I could also publish some code or even a detailed tutorial to scan an unknown > RGA (the quadrupole mass spectrometer thing) using programmable power > supplies, RF generator, and ionpak as low-current ammeter (see: > https://twitter.com/M_Labs_Ltd/status/889435735429754881). It won't get > much more basic than that, a core device isn't even involved - but it shows > what the master, controllers, and dashboard are about. This would definitely be helpful to have as part of a tutorial, since many groups will want to know how to incorporate various sorts of existing hardware (especially USB/GPIB/serial-controlled hardware) into an ARTIQ setup. However, I think it's also crucial to have core device code in the tutorial. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ Digest, Vol 37, Issue 6
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 on behalf of Thomas Harty via ARTIQ 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 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 ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove RTIOCollision
> 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 used and is convenient for zero-length pulses etc.), if it's not you throw an RTIOBusy error which is reported asynchronously. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ users meeting
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 arrange travel and bring a larger group). It seems that JQI would be a good potential location because: - relatively easy to get to DC area from Europe, Colorado, east coast -- close to "center of mass" for likely attendees (sorry Sebastien!) - likely we would want to invite funding agencies to observe/participate, so holding meeting in the DC area makes their participation more likely - ARL and JQI are two major funding/development drivers at present so it is a natural location > * 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) This might increase attendance (although is relatively immaterial for Creotech/WUT + M-Labs), but I think people tend to be pretty wiped out after a major conference so I don't think it's necessarily a big plus. One possibility, especially if we are interested in involving funding agents, would be to hold it immediately before/after an IARPA LogiQ Technical Exchange meeting, for example. This would probably gather more of the relevant players than DAMOP as well. It would also make travel to/from the conference more cost-effective for ARTIQ users which are LogiQ performers/support teams (e.g. NIST, JQI, Duke, Georgia Tech, etc). > * What would you like to see at such a conference? I can identify several areas in which such a conference could be useful, which I list roughly in order of priority: - discussing and refining plans for future ARTIQ development -- along the lines of the discussions at the quarterly site visits during the past NIST contracts - tutorials/workshops (ideally also webcast/recorded) -- to help give structural and practical information and introduction to main features of ARTIQ, including new features such as DRTIO - securing additional funding -- demonstrating to funding agents that the ARTIQ user community is broad-based and that ARTIQ enables important work could unlock additional funding for developing next-generation capabilities - building user community -- bringing new users onboard, creating links and collaborations between groups, finding areas of interest for joint funding of specific developments, etc. - sharing results -- reports on experiments/techniques performed with ARTIQ (especially if ARTIQ is an enabling technology) > * Would you present something? Depending on the structure and goals of the conference, the NIST group would likely be interested in presenting as appropriate. > * Would you attend a conference if it were on your continent? Another > continent? NIST in-person attendance would probably be very continent-dependent, with a strong preference for North America. The cost and red tape for international travel would make it prohibitive to bring a sizeable NIST contingent to a non-US location. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] test
This is a test sent from a NIST email address. > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sébastien > Bourdeauducq via ARTIQ > Sent: Wednesday, November 30, 2016 10:24 PM > To: artiq@lists.m-labs.hk > Subject: [ARTIQ] test > > 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 ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
> > 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 onwards. > > ttl.on() > delay(t_pi/2) > ttl.pulse_off(t) > delay(t_pi/2) > ttl.off() > > would be a natural extension of the API. If we're going to talk about "unaesthetic" code, I'd say this version is much worse than the three-line original code. From a logical standpoint, a Ramsey sequence consists of two rotations with a variable delay between them. While this 5-line code manages to create the desired sequence, it loses the logical flow that one has from reading code like the 3-line version -- much harder to tell from inspection that this is a Ramsey sequence. Is there another way to maintain or wrap the two back-to-back pulses so that you can accomplish your goals for DRTIO/DMA while not hurting the lexical clarity of the code on the physics level? Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] remove output event replacement feature
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 flopping, or no delay between Ramsey pulses). The proposed modification would break all of these experiments, and require the experiment code to have internal conditional/branching to check for zero-duration pulses everywhere that we're scanning pulse times and have a different branch to deal with these instances. The behavior of automatically collapsing zero-duration pulses simplifies the experimental code substantially. One potentially acceptable compromise might be to delegate the task of finding and eliminating zero-duration pulses to the compiler. This could then address the situation above (where zero-duration pulses are known at compile time), but would leave people to fend for themselves if pulse durations are calculated at runtime (or are otherwise unknowable at compile time). Peter should probably comment on the feasibility of such a scheme, and in any event I am not sure that everyone would be satisfied with that. What is the DRTIO/DMA requirement that makes this functionality problematic? Can you explain the rationale a bit? Best, Daniel > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > Jördens > Sent: Wednesday, November 23, 2016 10:20 AM > To: artiq@lists.m-labs.hk > Subject: [ARTIQ] [RFC] remove output event replacement feature > > Hello ARTIQ users, > > in preparation for DRTIO and DMA we are considering dropping a small > feature that -- while being potentially "convenient" to the user -- leads to > overhead and is unergonomic/unaesthetic. > > Currently, we support submitting multiple output events scheduled for the > same timestamp under certain conditions. That means you can turn a TTL > channel on() and off() in the same cycle. The prior on() is be replaced by the > off(). This happens transparently in gateware. It allows e.g. zero-length > pulses or back-to-back pulses to behave properly. They would otherwise > result in RTIOCollision exceptions. > > We are uncertain to what extent this feature is actually know and > used/relied upon in practice. > > Any comments on removing this feature and making it *always* an > RTIOCollision exception when two events are scheduled for the same > timestamp on the same channel? > > -- > Robert Jördens. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] shared SPI clock
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. (Fed) Cc: Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] shared SPI clock Yes, I know how SPI and chip select lines work. The fact remains that I have sitting in front of me a board with two chips on it, which have separate data lines and a common clock line. This was done because the board designer wanted to preserve the ability to write to both chips at the same time. He used a common clock line because he wanted to save a pin, and the SPI clock is on all the time and has the same frequency so why not. My point was that I was willing to give up the ability to do simultaneous writes if it meant that I could easily control both channels via ARTIQ. I could, I suppose, just short the two data lines and use SPI "correctly." I would prefer, though, a software solution, as I really don't want 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) mailto:daniel.slich...@nist.gov>> wrote: 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 need the mosi/miso subsignals to not be specific pins, but rather be determined by a mux internal to the FPGA. How do I do that? This is the purpose of the chip select line(s). Most chips that have SPI communications have a chip select line (sometimes named something different) that controls whether they listen to or ignore data on the MOSI, and whether they write to MISO. The ARTIQ SPI system allows you specify any number of chip select lines along with an SPI bus at bitstream compile time. You can also just use regular RTIO channels to do chip select manually if you prefer. So your SPI bus on ARTIQ has one clock, one MISO, one MOSI, and multiple chip select lines. You route the same CLK/MOSI/MISO to all of your DDS chips, and then each chip gets its own chip select line. If the chips don’t have actual chip select lines on them, you can use an analog switch or mux/demux chip. There are essentially infinite options for how to do this; check out http://www.ti.com/lsds/ti/analog/switches-multiplexers/overview.page for example to see a bunch of options. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Fwd: shared SPI clock
> > 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 need the mosi/miso subsignals to not be specific > > pins, but rather be determined by a mux internal to the FPGA. How do I do > that? > > A few things: > * This is a bad idea. SPI is not designed to work like that. You either share > clk/miso/mosi and address by cs_n or you have separate busses. > * You can have clk driven by only one SPI channel and run dummy commands > on that channel (without asserting cs_n) whenever you want to do > something on the other channels. > * You can mux clk using cs_n. To learn how to do that you'll need to learn > migen/misoc. It would look something like self.comb += > clk.eq(Mux(spi0.cs_n, spi1.clk, spi0.clk)) but it depends on a bunch of other > things as well and there is absolutely no safety net or access control. 100% agree. See my email as well; mux/demux should be done external to the FPGA, not internally. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] shared SPI clock
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 need the mosi/miso subsignals to not be specific pins, but rather be determined by a mux internal to the FPGA. How do I do that? This is the purpose of the chip select line(s). Most chips that have SPI communications have a chip select line (sometimes named something different) that controls whether they listen to or ignore data on the MOSI, and whether they write to MISO. The ARTIQ SPI system allows you specify any number of chip select lines along with an SPI bus at bitstream compile time. You can also just use regular RTIO channels to do chip select manually if you prefer. So your SPI bus on ARTIQ has one clock, one MISO, one MOSI, and multiple chip select lines. You route the same CLK/MOSI/MISO to all of your DDS chips, and then each chip gets its own chip select line. If the chips don’t have actual chip select lines on them, you can use an analog switch or mux/demux chip. There are essentially infinite options for how to do this; check out http://www.ti.com/lsds/ti/analog/switches-multiplexers/overview.page for example to see a bunch of options. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Sinara clocking
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 limited timing performance). Is the distributed clock on the RTM RF backplane a sine wave or a differential square wave? If the latter (better phase noise performance), will there be a chip (e.g. LTC6957) on the RTM RF backplane to perform sine-to-LVDS or sine-to-LVPECL conversion? It seems that it would be easiest to distribute 100 MHz to the crate(s) as a relatively high power sine wave over coax, but better for phase noise performance if the distributed clock on the RTM RF backplane has the fastest possible edges (thus differential square wave). LVPECL would be better for this than LVDS. > 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. Given the constraints that the DAC and ADC clocks be related in an integer way to the RTIO clock (for the purposes of the CORDIC/interpolator system, for example), some tuning range for the RTIO clock is necessary if we are planning to have tunability for the DAC/ADC clocks generated by the RTM clock daughterboards. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ implementation
For the Pipistrello and QC1 gateware (from the logs Sebastien sent): Device utilization summary: --- Selected Device : 6slx45csg324-3 Slice Logic Utilization: Number of Slice Registers: 12049 out of 5457622% Number of Slice LUTs:16853 out of 2728861% Number used as Logic: 15670 out of 2728857% Number used as Memory: 1183 out of 640818% Number used as RAM: 1178 Number used as SRL:5 Slice Logic Distribution: Number of LUT Flip Flop pairs used: 23803 Number with an unused Flip Flop: 11754 out of 2380349% Number with an unused LUT: 6950 out of 2380329% Number of fully used LUT-FF pairs: 5099 out of 2380321% Number of unique control sets: 270 IO Utilization: Number of IOs: 113 Number of bonded IOBs: 107 out of21849% Specific Feature Utilization: Number of Block RAM/FIFO: 83 out of11671% Number using Block RAM only: 83 Number of BUFG/BUFGCTRLs:5 out of 1631% Number of DSP48A1s: 6 out of 5810% Number of PLL_ADVs: 2 out of 450% Or with some more detail: == Design Summary: Number of errors: 0 Number of warnings:2 Slice Logic Utilization: Number of Slice Registers:12,047 out of 54,576 22% Number used as Flip Flops: 12,043 Number used as Latches: 0 Number used as Latch-thrus: 0 Number used as AND/OR logics:4 Number of Slice LUTs: 14,611 out of 27,288 53% Number used as logic: 12,806 out of 27,288 46% Number using O6 output only: 9,057 Number using O5 output only: 472 Number using O5 and O6:3,277 Number used as ROM:0 Number used as Memory: 611 out of 6,4089% Number used as Dual Port RAM:606 Number using O6 output only:26 Number using O5 output only: 8 Number using O5 and O6:572 Number used as Single Port RAM:0 Number used as Shift Register: 5 Number using O6 output only: 5 Number using O5 output only: 0 Number using O5 and O6: 0 Number used exclusively as route-thrus: 1,194 Number with same-slice register load: 1,148 Number with same-slice carry load:46 Number with other load:0 Slice Logic Distribution: Number of occupied Slices: 5,180 out of 6,822 75% Number of MUXCYs used: 4,380 out of 13,644 32% Number of LUT Flip Flop pairs used: 17,555 Number with an unused Flip Flop: 7,205 out of 17,555 41% Number with an unused LUT: 2,944 out of 17,555 16% Number of fully used LUT-FF pairs: 7,406 out of 17,555 42% Number of unique control sets: 281 Number of slice register sites lost to control set restrictions: 606 out of 54,5761% A LUT Flip Flop pair for this architecture represents one LUT paired with one Flip Flop within a slice. A control set is a unique combination of clock, reset, set, and enable signals for a registered element. The Slice Logic Distribution report is not meaningful if the design is over-mapped for a non-slice resource or if Placement fails. IO Utilization: Number of bonded IOBs: 113 out of 218 51% Number of LOCed IOBs: 113 out of 113 100% IOB Flip Flops: 6 Specific Feature Utilization: Number of RAMB16BWERs:51 out of 116 43% Number of RAMB8BWERs: 63 out of 232 27% Number of BUFIO2/BUFIO2_2CLKs: 1 out of 323% Number used as BUFIO2s: 1 Number used as BUFIO2_2CLKs: 0 Number of BUFIO2FB/BUFIO2FB_2CLKs: 0 out of 320% Number of BUFG/BUFGMUXs: 5 out of 16 31% Number used as BUFGs:4 Number used as BUFGMUX: 1 Number of DCM/DCM_CLKGENs: 1 out of 8 12% Number used as DCMs: 0 Number used as DCM_CLKGENs: 1 Number of ILOGIC2/ISERDES2s: 18 out of 3764% Number used as ILOGIC2s: 0 Number used as ISERDES2s: 18 Number of IODELAY2/IODRP2/IODRP2_MCBs: 0 out of
Re: [ARTIQ] 3.3 V I/O on kc705
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 the ARTIQ manual site below. > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > Jördens > Sent: Monday, September 19, 2016 4:57 PM > To: Jonathan Mizrahi > Cc: artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] 3.3 V I/O on kc705 > > On Mon, Sep 19, 2016 at 9:36 PM, Jonathan Mizrahi > wrote: > > see LVTTL IOStandards, which means they're already operating at 3.3 V. > > This is why I'm confused about what I need to do to work at 3.3 V off > > the FMC connector. > > https://m-labs.hk/artiq/manual-release-2/core_device.html#vadj > > -- > Robert Jördens. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] DSP gateware
Hi Robert, This is very nice work, thanks for the detailed write-up. It seems that this gateware design would cover just about any use case for high-bandwidth two-tone designs. To Dave L's question, there are already interpolation filters with sharp cutoffs in the AD9154 to eliminate Nyquist images if desired; I have done some measurements on the AD9154 hardware and they work quite well, up to what the datasheet says (~85 dB image rejection in the stopband, which would take us effectively to the noise floor of the outputs generated by the gateware Robert demonstrates). TI gives the filter coefficients for their FIR filters in the datasheets; you might be able to email Analog Devices and ask them for the filter coefficients for the AD9154, and this would allow you to evaluate the phase and amplitude response vs your needs. It does highlight the need for the DAC clock to be programmable over a wide range, from ~800 MHz up to 2.4 GHz (this is most important for Greg and Tom to be thinking about). If we are feeding the DAC with samples at the max rate of 1.096 GHz, for any signal above ~500 MHz (depending on what spur performance you demand) you can't use the interpolation modes unless you are willing to sacrifice half your channels and use the IQ modulator for digital upconversion. However, operating the DAC in "mix mode" with no interpolation at 1.096 GHz DAC clock (and 1.096 GHz data clock) would allow the generation of tones of reasonable amplitude between ~600 MHz and ~1.5 GHz, provided one uses analog filters on the output of the DACs to eliminate the undesired Nyquist images. For signals higher than ~1.5 GHz (basically for hyperfine qubit microwave drive for species other than 9Be+), we can either use analog frequency multipliers after the reconstruction filters, or sacrifice half of the output channels. Using only half of the output channels, we can use the internal IQ modulation for coarse frequency shifting (allowing for output signals up to ~3.5 GHz) or use them to generate IQ pairs for an analog IQ modulator on the DAC analog daughtercard. Best, Daniel > -Original Message- > From: Robert Jördens [mailto:r...@m-labs.hk] > Sent: Sunday, July 31, 2016 5:32 AM > To: artiq@lists.m-labs.hk; Jonathan Mizrahi ; Sébastien > Bourdeauducq ; Joe Britton ; > Slichter, Daniel H. (Fed) ; Leibrandt, David R. > (Fed) > ; Allcock, David T. (IntlAssoc) > ; Ken Brown > Subject: Re: DSP gateware > > Hello, > > to fuel the discussion and planning of the smart arbitrary waveform > generator requirements for the different applications, I did another > extended design study for the proposed ARTIQ/Sayma DSP gateware and > signal flow, looking at actual signal quality, resource usage and possible > parametrizations. > > This time, take the following parametrization of a channel's output o: > > z = (a1*exp(i*(f1*t+p1)) + a2*exp(i*(f2*t+p2))) * exp(i*(f0*t+p0)) o = u + > b*Re(z) + c*Im(z_buddy) > > * u and a are 16 bit cubic spline inteprolators > * p are 16 bit constant (non-) interpolators > * f are 48 bit linear interpolators > * z_buddy refers to the (complex, IQ) z data coming from each channel's > "buddy" channel, ignore it for now > * b, c are switches (with values 0 or 1) that allow a bunch of different > configurations, ignore them for now > * all spline interpolators (u, a, f, p) sample at 200 MHz > * the f1/p1 and f2/p2 oscillators sample at 200 MHz and their data is fed to > the f0/p0 oscillator without interpolation > * the f0/p0 oscillator samples at 8*200 MHz = 1.6 GHz > * data width is at least 16 bit everywhere > > This setup can -- for example -- generate a two-tone signal at 162 MHz and > 238 MHz by setting f0=157 MHz, f1=5 MHz, f2=81 MHz. The attached plot has > the data and the spectrum from a bit-accurate simulation of the full FPGA > gateware. Units are "natural" (sample rate=1, full > scale=1): the relevant tones are close to 0.1 and 0.15 sample rate. > Output amplitude is below clipping. > > This is a bit-accurate representation of the data that would be sent to the > DAC. Actual analog output would only differ by the DAC's interpolation and > it's analog output transfer function and DAC noise. > Don't be confused by the way the samples look: this is only due to the un- > interpolated data from the f1/f2 oscillators. Same goes for the Nyquist > images all around. A very rough and conservative estimate for wideband SNR > is > 85 dB not counting the images. There are a lot of things that can be > tweaked still, this demo is not supposed to be show the optimum. > > * 200 MHz is a bit under maximum achievable speed for this logic on a > -2 speed grade kintex 7. > * 1.6 GHz * 4 channels is more than we can push to a DA
Re: [ARTIQ] proposed DAC gateware
Two comments and a clarification: - DAC is AD9154, not AD9145 - at the bottom of page 2, it specifies f_max = 300 MHz, but I assume this is not correct? What I think should be happening is a 48-bit phase accumulator with frequency tuning word specified by f (which is a linear interpolator, allowing for frequency chirps) and the constant offset p, the value of which is then run into CORDIC (or equivalent) to calculate sine or cosine. Is this right? - a clarification: is it correct that u, a, and f are constant between updates at f_DAC/16? i.e., they maintain their values for 16 time points, then their values update to the next calculated value from the interpolator? In other words, the interpolators generate new values for u, a, f only every 16 time points? Best, Daniel > -Original Message- > From: j arl [mailto:joe.britton@gmail.com] > Sent: Thursday, July 28, 2016 3:14 PM > To: artiq@lists.m-labs.hk; Sébastien Bourdeauducq > ; Robert Jördens ; > Slichter, Daniel H. (Fed) ; jase...@gmail.com; > camaca...@gmail.com > Subject: proposed DAC gateware > > Dear prospective Sayma users, please comment on the attached gateware > and ARTIQ-integration specification. It is intended to be stand-alone and > make minimal reference to the microTCA hardware. The aim is to provide > isolation of the gateware development from broader Sayma/Metlino > system. Detailed specification of the other components are forthcoming. > > Many thanks to long conversations with Robert Jordens and Sebastien > Bourdeauducq (m-labs), Jonathan Mizrahi (JQI) and Daniel Slichter (NIST > Boulder). Huge props to developers of the NIST PDQ system Ryan Bowler (U. > Washington) and Jason Heidecker. And to Robert Jordens > (m-labs.hk) who developed its successor PDQ2. > > -Joe > > --- > Joe Britton > Sensors and Electron Devices > Army Research Lab > 2800 Powder Mill Rd > Adelphi, MD 20783 > 301-394-3130 > joseph.w.britton5@mail.mil ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] clock recovery on Metlino and Kasli
> Since we are not going to use White Rabbit, I propose removing them. Do we have an alternate time/synchronization protocol planned for DRTIO? Does it make sense to leave WR components as a fallback for risk mitigation, in case we change our minds subsequently? ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] uTCA backplane driver choices
> On Thursday, June 23, 2016 11:09 PM, Slichter, Daniel H. (Fed) wrote: > > One question raised by David Allcock is whether the Sayma cards can be > > run standalone (e.g. in a smaller crate on table with no Metlino). > > It would definitely be useful for the Sayma cards to have the > > necessary connectivity (e.g. SFP cage) to allow for this option. > > That's a sensible option too; the advantages compared to SPI are higher > bandwidth, possibility of synchronization over the fiber, and galvanic > isolation. > > [Joe: Note that those SFPs are connected to FPGA transceivers directly and > do not involve a Ethernet PHY chip on the Sayma PCB] Ethernet per se is not a requirement -- just being able to interface with the card when it is not in a rack (over fiber from a core device is OK), and to have the possibility for synchronization over fiber (so the Sayma card can output pulses at the correct time) would be sufficient. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] uTCA backplane driver choices
One question raised by David Allcock is whether the Sayma cards can be run standalone (e.g. in a smaller crate on table with no Metlino). It would definitely be useful for the Sayma cards to have the necessary connectivity (e.g. SFP cage) to allow for this option. I understand that the connectivity would necessarily be slower than if you are plugged in to a backplane, but running it standalone as a DRTIO peripheral would be a very compelling use case for us. For example, the Magtrap experiment would probably want to have 1-2 cards down on the table directly, as close to the trap as possible (for best stability). A single Sayma card could replace the full DDS+PDQ+IQ modulator setup we have built, at a greatly reduced footprint. Best, Daniel > -Original Message- > From: Sébastien Bourdeauducq [mailto:s...@m-labs.hk] > Sent: Wednesday, June 22, 2016 10:28 PM > To: j arl ; artiq@lists.m-labs.hk; Greg Kasprowicz > ; Slichter, Daniel H. (Fed) > Subject: Re: [ARTIQ] uTCA backplane driver choices > > On Wednesday, June 22, 2016 04:47 AM, j arl wrote: > > Use standard RGMII to SERDES chip for Port 0 and Port 1 which works > > with open source Ethernet MAC. For example Micrel KSZ9021. > > Ethernet is not required on the Sayma cards. It would add a relatively small > amount of cruft, except that you now need additional backplane traces and a > hub, which are all useless and redundant. > > If one does need Ethernet networking on the AMC cards (but I can't see > why), we have a plan to dedicate some bandwidth to non-realtime traffic on > the DRTIO links (for e.g. the monitoring/injection features), and Ethernet > could be piped through that. > > Otherwise, the trajectory of the hardware generally looks great! > > Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] uTCA backplane driver choices
I tend to go with Greg here; I think the edges on LVDS are just not as sharp as you would like for clock distribution, and for the GTX transceiver you will want whatever is most compatible (I don't have experience here). CML or LVPECL would be the way to go for the others. > -Original Message- > From: j arl [mailto:joe.britton@gmail.com] > Sent: Tuesday, June 21, 2016 2:48 PM > To: artiq@lists.m-labs.hk; Greg Kasprowicz ; Slichter, > Daniel H. (Fed) > Subject: uTCA backplane driver choices > > What differential logic is best for for the uTCA backplane? This impacts the > Ports that connect the MCH to AMC boards. The relevant uTCA Ports are the > following. > > Port 0 and Port 1 for Gbit Ethernet > Port 4 for 10.3125 Gb/s GTX transceiver > Ports 5-7 for general purpose I/O > TCLKA, TCLKB and TCLKC for 125 MHz, 5 MHz and 100 MHz clocks > > Options seem to be LVPECL, HCSL, CML, and LVDS. The following EETimes > discusses the choices. > > http://www.eetimes.com/document.asp?doc_id=1225744 > > Use standard RGMII to SERDES chip for Port 0 and Port 1 which works with > open source Ethernet MAC. For example Micrel KSZ9021. > > HCSL or CML are the only options for >> 1 Gb/s transceivers. GTX supports up > to 10.3125 Gb/s. Greg K. recommends HCSL. > > For clocks < 1 GHz Greg K. recommends using LVPECL. It is widely used for > this application as it is lower jitter (sharper edges) than other logic > families. > > For Ports 5-7 connect directly to FPGA pins. > > -Joe > > --- > Joe Britton > Sensors and Electron Devices > Army Research Lab > 2800 Powder Mill Rd > Adelphi, MD 20783 > 301-394-3130 > joseph.w.britton5@mail.mil ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Question about AD9XXX
Hi Ken, The architecture for the AD9858 and AD9914 currently in ARTIQ is for programming DDS chips over a wide parallel bus, but the AD9959 is only programmable over a serial link (albeit a parallelizable one). I think the fastest solution for you would be to just use an instance of the existing ARTIQ SPI core and write a driver based on that. This will allow you to program the DDS with an SPI clock frequency up to half the frequency of your RTIO clock (62.5 Mbps for a 125 MHz RTIO clock). You can use ARTIQ TTLInOut() lines to control the profile pins, send IO_UPDATE signals, etc. There is an SPI driver for the AD5360 DAC chip located in artiq/coredevice/ad5360.py, which is a good template. The SPI core is in artiq/coredevice/spi.py, and the docstrings are very detailed and the code is straightforward. I also suggest reading the docstrings in artiq/gateware/spi.py . If you look in artiq/gateware/nist_qc2.py or artiq/gateware/nist_clock.py, as well as artiq/gateware/targets/kc705.py , you can see how to instantiate an spi core in the Migen code such that it gets built in to your gateware. I am currently writing an SPI driver for the AD9914 DDS, which can be used to program an AD9914 eval board over SPI. Once it is complete I will post it on Github as well, since this may help others get going using DDS chips with ARTIQ. Best, Daniel > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Ken Brown > Sent: Tuesday, June 21, 2016 9:34 AM > To: artiq@lists.m-labs.hk > Subject: [ARTIQ] Question about AD9XXX > > As a test, I would like to build gateware to support one channel of an AD9959. > > I am using the pippistrello board and I see where to change the connections > from an AD9858 to an AD9959. I see also where to change the number of > pads, define the connection, etc. > > What I have not found is where the address control is. For example, if I send > a phase word versus a frequency word, I need to put these in different > addresses. > I am currently overlooking the command that sets this address. > > Any pointers in the right direction would be appreciated. > > Thanks, > Ken > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] connecting to KC705
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 ttl_pins[]. All of these give you the FMC signal names. If those names are not available silkscreened on your breakout, you can relate them to the pin numbers on the FMC connector by looking in the appendix of the KC705 datasheet. Best, Daniel > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Jonathan > Mizrahi > Sent: Friday, May 27, 2016 2:53 PM > To: Robert Jördens > Cc: artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] connecting to KC705 > > Robert, > > Thanks for the recommendations, I solved the problem. It turned out that > the problem was that I needed to have SW13 set to 1. It had been set to > 00101. In that configuration, I could not connect to the board over ethernet > or serial. As a side point, I had it set to 00101 based on this information > from > Xilinx: http://www.xilinx.com/support/answers/50079.html, after originally > being unable to connect to the board over JTAG at all. > > I would like to be able to connect pins of the KC705 to a scope so that I can > write and test programs. I have an FMC debug card from Xilinx (HW-FMC- > XM105-G), but I need to know how to map a TTL from the device database to > a physical FPGA pin. How do I do that (and how do I see the current > mapping)? I see the RTIO channel mappings in the manual, but that doesn't > tell me what the physical pin is. > > Thanks, > Jonathan > > From: Robert Jördens [r...@m-labs.hk] > Sent: Wednesday, May 25, 2016 4:48 PM > To: Jonathan Mizrahi > Cc: artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] connecting to KC705 > > Hey Jonathan, > > On Wed, May 25, 2016 at 10:34 PM, Jonathan Mizrahi > wrote: > > I get "socket.timeout: timed out" (together with a long traceback). What > am I doing wrong? > > A couple things you can check: > > Are you supplying _that_ device_db.pyon to artiq_run? > Does it blink its LED three times after booting? > Does it respond to pings (at that IP address)? > If you connect the serial console (next to the jtag-over-usb > connector) and look at it during boot (using flterm, minicom, miniterm.py, > hyperterm... settings are 115200 baud, 8 bits, no parity, > 1 stop bit) what does it say? > > -- > Robert Jördens. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
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 backplane clock distribution is the best way to go, so long as we can overcome the phase noise/drift concerns that we've discussed -- which isn't a given. We've probably taken this discussion about as far as we can without having test data to see how well we can get the backplane clock to work practice. We (Oxford) are happy to have a go at getting this data and, as I mentioned, are currently designing hardware to that end. Once we've got designs ready for the test hardware, we'll post them here along with a rough description of the tests we plan to perform. Great, I look forward to the results of your measurements. If you have a couple of test boards up and running, would it be easy to take some data on the propagation delay stability of these DACs at the same time? This would be a really useful reference point for thinking about how stable the clock distribution network needs to be -- there isn't much point worrying about the temp. co. of clock buffers/PLLs if they are small compared with the DAC... I have one test board right now, but can measure the channel-to-channel noise within a single card pretty easily. If we get another board we can compare two chips to each other as well. I'll share the data once I have it, lots of items on the plate though so it may not be instant. Out of curiosity, what is the plan for thermal management (e.g. the DACs put out a fair amount of heat)? Is this something you've thought about much yet? The plan here is forced air cooling at crate level, which is part of the uTCA crate design. We are only trying to send a relatively small volume of data, and have the option of using a multi GBPS link. This gives us a lot of options in terms of spreading the noise power out/minimising the power at our reference frequency. If we do this properly, the numbers actually don't look so bad and I think we may be able to get the cross-talk noise below the DAC's noise floor. We'll have a proper think about this once we've got our test hardware designed... It's not clear to me that we will only be sending a relatively small volume of data. We may want to send waveform data to and from DACs, or potentially stream raw or minimally processed ADC data out to the MCH. I think it is a mistake to rely on the notion that we will only be sending small amounts of data. Likewise, with Greg's proposed solution of silencing the high speed digital transmissions during experiments, I think we may need to pipeline things such that data is being fed in and/or out of the cards while an experiment is running. Any design which doesn't allow for this seems like a bad idea to me. I'm not so sure about that... It's been my experience that if one wants a source that can be programmed to go from 100kHz to 20GHz and -130dBm to +20dBm with crazy resolution and accuracy then the Agilent synth is the way to go. However, for a fixed-frequency, stable oscillator they're actually not that great. e.g. it's not that hard to outperform an Agilent synth at a few GHz with a cheap PLL phase noise wise. When it comes to phase stability, bigger is generally worse. I suspect that a small, if needs be ovenized, PLL is actually a pretty good solution. But, maybe I'll take that back when our test boards arrive. Sounds like waiting for the test boards to "recalibrate our BS detectors" is the thing to do here :) ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> 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 can to a > reasonable extent, but then it does complicate the board. On the DSP/"Sayma" boards, a hard SoC could have use for reducing the time it takes to perform feedback calculations (e.g. shifts of output signal frequency based on ADC readings). My comment in the previous email about "users" wanting this also pertains to the idea that people not using ARTIQ might want to buy these boards and use them for their own purposes. For many of them, having a hard SoC on board may make it faster/easier for them to get the boards doing what they want. Again, it's not totally necessary to have this but would enable more applications and a broader group of potentially interested customers. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
I also think that, however "disgusting" the Zynq is, there are a number of people who might want the additional processing power available in a hard processor. Greg also points out a number of advantages in terms of management of bitstreams in a large-scale experimental setting. On our previous phone conversations with Sebastien, Joe, and Dave Leibrandt, it seemed that using the hard processor on the Zynq would be necessary to be able to talk to a connected SDRAM chip, so there is a little more to it than just treating it as a regular Kintex in terms of connections. However, Sebastien seemed to think that it would not be that difficult to implement things on a Zynq. Sebastien, has this opinion changed? Is the "disgusting" part of Zynq a philosophical objection, or an objection based on the amount of additional work required to implement gateware? Many potential users might prefer having a Zynq. We also discussed the advantages of having 24 gigabit transceivers, instead of 16, in that then we are not reduced to hacks to have gigabit connectivity (e.g. GbE, potentially PCIe, etc) while keeping the possibility of using 8 DAC outputs at their full bandwidth. If this is not a priority, the AD9154 can be run at a reduced instantaneous bandwidth (e.g. higher interpolation rate) or reduced channel count, both of which would be satisfactory for some applications, with only 4 lanes connected. Thus one could connect one FMC with 8 lanes and the other with 4 lanes (4 lanes is all that is needed for 4 channels of ADC at max data rates), and have 4 left over. I proposed this idea back some months ago when we were doing initial discussions. Best, Daniel > -Original Message- > From: Grzegorz Kasprowicz [mailto:gkasp...@elka.pw.edu.pl] > Sent: Friday, April 08, 2016 6:00 AM > To: 'Sébastien Bourdeauducq' > Cc: 'Grzegorz Kasprowicz' ; Slichter, Daniel H. (Fed) > ; artiq@lists.m-labs.hk > Subject: RE: [ARTIQ] FW: initial specification of the project > > Well, I compared highest speed grades (-3) in large packages :) XC7K325T- > 3FFG900E costs more than ZU11 in similar speed grade. > Personally, I like this disgusting ZynQ stuff. I didn't have any special > troubles > to make it running. And it gives very handy feature of FPGA upgrade over > Ethernet :) In this way you can keep all FPGA bit streams on single nfs server > and load them at the startup. > THE CPU and FPGA are independent, so you can boot CPU without the > bitstream, connect to nfs, grab the bitteam and load it. So you can treat it > as > CPU which simply loads the FPGA and from programmable logic you treat it > as ordinary Kintex device. > And you get bunch of IOs for free which can be controlled over Ethernet. > In case of complex system it is very desirable because you keep all the > settings in single location and to upgrade it don't have to walk with > programmer from board to board. > We have a system which consists of 22 FPGAs in single box and all FPGA files > are kept on single USB drive. The system is installed in UK and upgraded once > a month and it is real pleasure to work in such manner. > Another system is CMS muon trigger which consists of thousands of FPGAs > and they all are loaded at the startup. It's much easier to keep control on > bitstream versions of individual chips. > The only alternative update channel in MTCA is either JTAG or I2C. > With I2C you need about 30hours to programm the config FLASH. In case of > JTAG, not every MTCA crate has JSM. > Greg > > > -Original Message----- > From: Sébastien Bourdeauducq [mailto:s...@m-labs.hk] > Sent: Friday, April 08, 2016 12:13 PM > To: Grzegorz Kasprowicz > Cc: 'Grzegorz Kasprowicz' ; 'Slichter, Daniel H. (Fed)' > ; artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] FW: initial specification of the project > > On Friday, 8 April 2016 11:53:25 AM HKT Grzegorz Kasprowicz wrote: > > Btw, > > ZU11 FPGA costs more or less the same as 7K325 and offers almost twice > > more logic resources. The price of ZU11 is $1,376.00 at 100pcs. > > Since we will buy such quantity for our CBM project (Fair facility in > > GSI), we can use that step pricing in this case as well. > > Even on Digikey in single quantities, 7K325T starts at $898.75 (and the > cheapest one in FF which seems to be recommended for the full transceiver > bandwidth is $1122.50) and we don't have to deal with any of this disgusting > Zynq stuff. > > Sébastien > ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
These are good thoughts, Tom, thanks for sending this detailed message. I imagine Greg will have some insights and measurements as well from Creotech's experience in building the RF distribution backplane for the RTMs. A few comments inline below: Take the 2.4GHz DAC clock as an example. A decent (relatively small and inexpensive) choice of VCO for the PLL might be a UMX-630-D16-G (http://www.rfmd.com/store/products/all-products/oscillators/ultra-low-noise-cro-vcos/umx-630-d16-g-1.html). To get an idea of the lock bandwidth required, we can compare the phase noise of this VCO with a typical high-quality lab 10MHz source, such as a SRS FS725 Rubidium Standard (http://www.thinksrs.com/products/FS725.htm) scaled from 10MHz to 2.4GHz by adding 20*log10(240)=48dB. By 10kHz offset frequency, the typical VCO noise is -108dBc/Hz, compared with a (scaled) noise for the FS725 of ~-105dBc/Hz. Beyond that, the VCO is significantly better*. For good phase noise performance, one is better off distributing a higher frequency clock. For example, use an external 1 GHz crystal or oscillator disciplined to a 10 MHz atomic reference with low loop bandwidth. The phase noise at 1 GHz at 10 kHz offset for these sorts of things can be -160 dBc/Hz (e.g. Wenzel GMXO-PLD), which is substantially better than the scaled (multiplied) phase noise from an FS725 rubidium standard (-115 dBc/Hz @ 1 GHz, 10 kHz offset). Now you are way below the phase noise from the VCO, which would be -116 dBc/Hz scaled at 1 GHz. And the VCO you quote is a particularly fancy one because it is disciplined to an onboard CRO already, so one is not likely to find a substantially better VCO. How much will this level of phase noise affect things? If we go with -96 dBc/Hz at 10 GHz (scaled), assuming a VCO, we can compare with Fig 2 in http://arxiv.org/abs/1602.04551. This would put us about a third of the way from the "lab-grade" at -75 dbc/Hz to the "precision" at -130 dBc/Hz. This frequency offset corresponds to ~100 us operation times, so the phase noise would give an infidelity of about 10^-4 per gate there. Taking the 100 kHz offset, we have -118 dBc/Hz at 10 GHz with VCO, which is about 2/3 of the way from "lab grade" to "precision" and would limit gate fidelity to a few times 10^-6 per gate at ~10 us gate times. This is obviously a very coarse way of ballparking things, because one has to look at the entire spectrum, especially the integrated power in the white noise floor, but it gives a rough figure of merit. Given this admittedly very coarse analysis, I would prefer to at least have the option to pipe in a nice low-noise external clock directly, although it seems a backplane clock (especially if one distributes a higher frequency on the backplane) could work for many applications. Presumably, your concern is some combination of: a) We won't be able to build a PLL on the AMC/FMC board which has good enough phase noise @2.4GHz, regardless of the quality of the 10MHz reference we feed it This is one concern, but it appears the chip you suggest could get us decent phase noise for many applications. b) The PLL won't do a good enough job of removing noise on the reference clock far outside the loop bandwidth (say, outside the range 9MHz - 11MHz if one wants to be pessimistic) If you have a really good onboard oscillator that you are only disciplining with the backplane reference, this is not so much of an issue. But this then requires substantially more engineering. c) Even with a narrow-bandwidth (~1kHz) PLL with carefully chosen loop filter, and taking care over what other signals we send down the backplane, there will be too much pickup on the clock line close to 10MHz that can't be filtered off This is potentially an issue. d) Something else I'm missing? If each board in a crate has its own PLL, you will have more phase drift between the outputs of separate cards than if you distribute the DAC clock directly to all boards from a single source. Obviously the direct clock distribution doesn't scale to many crates, but you would at least know that an entire crate's worth of DACs are fully synchronized, as opposed to just one AMC card's worth. If you have any measurements relevant to this, I'd be interested to see them. We're currently building hardware, one purpose of which will be to test how well we can generate a low phase noise 1GHz DDS clock from a 10MHz signal distributed down a uTCA backplane. Creotech probably have some measurements of this from when they built their RF backplane for the RTMs; I don't have any data of my own. Glad you are doing some testing of your own. I would see if you can't distribute the 1 GHz clock directly and use the PLL for cleanup only? * Of course, actually achieving this noise level will require some work in terms of simulation/testing the PLL design, and may need a multi-loop PLL to prevent the high divider ratio from causing problems
[ARTIQ] NIST IT security requirement - reimplement ARTIQ in C/C++
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++. All other programming languages are banned. So we will need to reimplement the entirety of ARTIQ in C or C++. Sorry for the hassle! Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] DSP gateware
> And a 16 ns pulse would be just about 20 samples. Why would you want to > describe that using ~4 spline knots each being maybe 16 times 16 bits in data. > If you need the full bandwidth, the idea of compression using splines is not > very helpful. In that case you would need to design in a little "real" AWG > player that plays snippets from a wide BRAM. Sure, that is a better solution for these kinds of things. I am just saying that unless we have some suitable feature like this, no superconducting people will be interested in the system. So we should design things in such a way that this is a possibility, to maximize the target audience. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] TTL + slow DACs
> 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 well controlled labs -- exceed the common mode tolerances of > lvds if the devices are a few tens of meters apart. > > This is why we would like to consider a very low barrier, non-rack form factor > that is connected by fiber plus a simple power supply and provides a good > number of analog voltages and a good number of ttls. > That obsoletes the LVDS breakout board which also doesn't help with the > galvanic isolation for the high density low speed DAC that we would like to > bundle with that box. OK, fiber is superior for galvanic isolation, but at the end of the day this would be a solution with just a few TTL lines per board, and you would then sprinkle these around the lab, correct? And clock/timing transfer can be done over the fiber in a suitable way? ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] DSP gateware
> 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 * sin(f0 * t + p0) + i1 * a1 * cos(f1 * t + p1) > > * u and a are 16 bit cubic spline inteprolators > * p are 16 bit constant (non-) interpolators > * f are 48 bit linear interpolators > * i and q are switches (0 or 1) that allow many different configurations, > among them single tone independent, two-tone, single tone iq, and two- > tone iq all with independent dc offsets > * the inteprolators interpolate at 1/8 output rate, the DUCs output at full > rate > (effectively). > * all designed for 16 bit spline knot duration resolution and scalable spline > interpolation clock This looks like a good general purpose method for defining signals, which accommodates most possible use cases in a clean and concise way. A few potential comments: - For sc qubit applications, it would be necessary to update the u and a interpolators at the full output rate (~1.25 GSPS), since pulses are often only 10-20 ns long and require nontrivial shaping over those periods of time (sometimes 2 envelope oscillations up and down, see e.g. http://arxiv.org/pdf/1405.0450v2.pdf on "wah-wah" pulses, which are commonly used). In general, having u and a only updated at 1/8 clock rate will give rise to spurs at 1/4 of the Nyquist frequency and harmonics, which is undesirable for any application. Perhaps I am misunderstanding what you mean by the interpolators running at 1/8 output date. > This uses about 28 kLUT, 14% of a xc7k325t. The timing, parsing, serial link, > rtlink, drtio, jdes phy, gearbox, monitoring, digital servo, adc logic will > probably add another 10-20 kLUT per channel pair but this is the dominant > chunk. > > This looks good for the xc7a200t or a xc7k325t as the building block and 4 > channels (two smart channel pairs). Will changing the update rate for the spline interpolators make things much larger? I assume they would have to be physically parallelized. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
Re DAC clock: presumably, the plan is to distribute a 10MHz (or 100MHz, or whatever) clock with really low close-in phase noise to each MCH, and then from each MCH to the AMCs via the backplane. Why not send this from the AMC to the FMC boards via the FMC connectors? Then, have the FMC board generate the DAC clock using an integer-N PLL. If done properly, an int-N PLL at a couple of GHz is cheap, has a small footprint and will give as good phase noise/phase stability as using an external synth plus coax. The loop filter bandwidth can be low enough to take out any cross-talk from the FMC/backplane. Plus, this way the DAC clock has a well-defined phase relationship to the main system clock (the 10MHz or whatever), which may come in handy for keeping everything synchronised... Basically, it is not possible to generate a sufficiently high performance DAC clock for many applications from something that comes over the backplane, due to crosstalk/signal integrity issues. Joe Britton has some data on clock noise over uTCA backplanes, I believe. The idea would be to have a clock selection crossbar switch on the FMC card, which allows the user either to use an external clock brought in on an SMA connector, or to use a clock generated by a PLL on the AMC card referenced to a backplane clock (and there will be backplane clocks for digital timing purposes). This way people who really care about phase noise can have it as good as they want, while people who don't care as much can dispense with the extra wiring and clutter involved in feeding external clocks to each FMC module. The issue is just that for the most demanding signal generation, using backplane clocks and an on-chip PLL is considerably worse than a dedicated clock that would come in on the front panel from a dedicated low-noise clock source. Mike Biercuk, his student, and Will Oliver have made a nice writeup looking at the importance of low phase noise master clocks for gate fidelity, that describes a number of the important issues: http://arxiv.org/abs/1602.04551 Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] TTL + slow DACs
> 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 recommend that the TTL be broken out to LVDS over cat5/cat6 using RJ45 connectors, as is currently done in the ARTIQ hardware. It would be possible to send 64 TTL lines out of a single AMC card of 6 HP width in this manner, much more than you could ever do with SMA, and with vastly cheaper cabling and excellent signal integrity for long cabling runs (tested to work fine with 30 m cable, for example). We have existing breakout boards that convert between 4 TTL signals on SMA and 4 LVDS signals on Ethernet cables. This card would not have an FMC mezzanine, but would rather just break things out directly from the FPGA. I would recommend using a similar architecture on the AMC board to our existing TTL riser card that interfaces between TTL at the FPGA and LVDS. I know we could directly drive LVDS to/from the FPGA, but then we don't have any isolation between the FPGA user IO and the end user application, which makes me nervous that users could more easily fry the FPGA. One could use a very inexpensive FPGA for this particular task, although it might be nice to have a hard processor if it is driving so many TTL lines. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
One further question: is there a plan to make a “TTL” card or a multichannel “slow” DAC card (e.g. for trap voltages), using a Centronics or d-sub type connector? These could both be more readily accomplished with their own FMC modules if we go with this architecture. From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com] Sent: Wednesday, March 30, 2016 3:36 PM To: Slichter, Daniel H. (Fed) Cc: Robert Jördens ; Grzegorz Kasprowicz ; Leibrandt, David R. (Fed) ; Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] FW: initial specification of the project Here is example of CERN carrier with analogue voltages: http://www.ohwr.org/projects/fmc-pci-carrier/wiki "+5V, -2V, -5V2 and -12V optionally wired on HPC pins" look here https://edms.cern.ch/ui/file/1098639/1/EDA-02118-V1-1_sch.pdf page 3 On 30 March 2016 at 23:17, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: We definitely need +/- 15V for the low frequency (e.g. trap electrode) amplifiers. Many low noise amplifiers and RF components run off +5V or +/- 5V and have substantial current draws, so if you pull everything from +/- 15V rails you are tripling your power dissipation and you end up with very hot regulators. The DACs and ADCs will be dissipating a fair amount of power already so we want to try to keep the power budget under control. Other than that, I don’t see major reasons why one couldn’t run fewer analog rails. I think we are better off with DC/DC converters on the AMC card making a number of rails, which then have some filtering/regulation on the AMC card and then a final stage of LDO regulation on the FMC daughtercard itself, as close to the amplifiers etc as possible. Using the alternating grounds a la CERN seems like a suitable solution to me for sending in these additional analog rails. From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com<mailto:kaspr...@gmail.com>] Sent: Wednesday, March 30, 2016 3:13 PM To: Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> Cc: Robert Jördens mailto:r...@m-labs.hk>>; Grzegorz Kasprowicz mailto:gkasp...@elka.pw.edu.pl>>; Leibrandt, David R. (Fed) mailto:david.leibra...@nist.gov>>; Sébastien Bourdeauducq mailto:s...@m-labs.hk>>; artiq@lists.m-labs.hk<mailto:artiq@lists.m-labs.hk> Subject: Re: [ARTIQ] FW: initial specification of the project Well, CERN does it in their FMC carriers. They use HPC routed like LPC and then some of grounds are used as symmetrical analog supplies. In this way if you plug wrong board, it will short the supply but no damage will occur. I assume that low nosie DC/DC converters + LDOs will be installed on the AMC board. Do we need all these voltages, especially +/-5 and +/- 15? Won't single +/- 8 or +/- 15V be sufficient? Greg On 30 March 2016 at 23:08, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: 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 as well as +3.3V, +1.8V, +12V. Can we put these through on the FMC without breaking back compatibility? For example, one rail on each of the 4 VADJ pins? I am sure this would not be VITA 57 compliant….and we don’t want switching converters on the FMC daughtercard for space and noise reasons both. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
Looks like one could get a pretty good start on things by just copying the designs used by marki microwave: http://www.markimicrowave.com/assets/packages/CTG.pdf http://www.markimicrowave.com/assets/appnotes/an-ct-pcb.pdf On another note, I would recommend the MM1-0320HSM mixer as a good option for the upconversion board if we decide not to go with an IQ modulator (there the ADL5375 would be best but I haven’t tested it to 12 GHz). http://www.markimicrowave.com/MM1-0320HSM-MMIC-Double-Balanced-Mixer-P782.aspx From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com] Sent: Wednesday, March 30, 2016 3:09 PM To: Slichter, Daniel H. (Fed) Cc: Grzegorz Kasprowicz ; Leibrandt, David R. (Fed) ; Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] FW: initial specification of the project Well, it depends on trace width matching. We can simulate and characterize it even at much higher frequencies. If we place them really close to the DAC and match widths, remove grounds under pads, we can match it not worse than SMA connectors. We can even do even more crazy thing - try to make them mountable. The only signals that would need to be transmitted is DAC output / ADC input. We can use low profile board to board connectors for rest of the signals - I know ones that have 1mm stacking hight. For RF we could use PCB mounted UFL connectors. This is just crazy idea that need to be verified. On 30 March 2016 at 23:02, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: This is an interesting potential solution although I am not sure how the signal integrity is at ~3 GHz, for example. From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com<mailto:kaspr...@gmail.com>] Sent: Wednesday, March 30, 2016 2:44 PM To: Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> Cc: Grzegorz Kasprowicz mailto:gkasp...@elka.pw.edu.pl>>; Leibrandt, David R. (Fed) mailto:david.leibra...@nist.gov>>; Sébastien Bourdeauducq mailto:s...@m-labs.hk>>; artiq@lists.m-labs.hk<mailto:artiq@lists.m-labs.hk> Subject: Re: [ARTIQ] FW: initial specification of the project Such assembly technique is called: castellated PCB module https://www.google.pl/search?q=castellated+RF+modules&biw=1920&bih=917&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjRvuqko-nLAhWnnXIKHe_IARsQ_AUIBygB<https://www.google.pl/search?q=castellated+PCB+down+converter+modules&biw=1920&bih=917&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj19L7younLAhUKvXIKHQVBCg8Q_AUIBigB#tbm=isch&q=castellated+RF+modules> On 30 March 2016 at 22:40, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: One more thing - we can fit 5 SMA connectors on FMC panel, in case of 6 ones, we won't be able to screw them. But we can install MMCX ones for clocks and fit in total of 7 RF connectors, Look here http://www.ohwr.org/attachments/3390/fmc_top.jpg Greg On 30 March 2016 at 22:38, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: Well, we can do another crazy thing - solder small module with RF stuff on the FMC board, under same shield. In this way we keep 3 simple FMCs with expensive ADCs/DACs and define the functionality by soldering (automatic or manual) of just RF modules. WE can even design such modules to hold the front-end connectors of leave them on the FMC. Such approach has also some attractive feature - we can make them using small pieces of Rogers material which is hell expensive and it's hard to make small vias and thin traces needed for JESD signals. these modules could look like that http://www.emcfastpass.com/wp-content/uploads/2014/09/rf_module_holes.gif You can mount them by pick and place or manually. IT is also possible to manually disassemble them. This is a form factor of popular RF modules, i.e. wifi, GPS and LTE modems. http://www.emcfastpass.com/rf-modules/ And is simply works Greg On 30 March 2016 at 22:25, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: > 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 functionality > by FMC boards If we make 3 flavours of FMCs: ADC+ADC, > ADC+DAC,DAC+DAC, we would cover several use cases: > Quad ADC, quad DAC, 1xADC 3xDAC, 3xADC 1xDAC. > FMCs with only DAC and RF stuff on it can be simple, 4 layer boards with > external sield. > Look at this shield (my project) > http://www.ohwr.org/projects/fmc-adc-130m-16b-4cha/wiki > In this way we could use existing AFCK for quick tests We have been working with the notion that should be many possible front ends for each of the DACs or ADCs, depending on what the particular application is, and so we want to separate the analog daughte
Re: [ARTIQ] Fwd: FW: initial specification of the project
> 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 channels of IQ upconversion would also probably be good, but most likely the upconverting mixer would need to have larger RF bandwidth than is typically available in surface mount IQ modules (which typically go to ~ 6 GHz spec'ed max, might be rough making it out to 12 GHz for Yb). Since we have full IQ control in the digital regime, we could do everything we want with just a regular mixer as long as filters are put in place to get rid of the second sideband on the output (these could be placed off-card as well, for example). The bandwidth of the DACs is sufficiently high that this method for removing the second sideband is viable, as long as appropriate filters are placed in the IF signal path. Just another potential way of generating things. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
We could also use a fuzz button interposer, which would do the same kind of task (low stacking height connection w/ high frequency compatibility), but I think once we start heading too far down this road the cost and complexity of making a robust solution starts to outweigh the cost of just making more types of boards. We should consider carefully before we make too fancy a solution. The notion of the SMP connectors is that they are robust, high performance, suited for the task, and cheap. It does seem that microwave-frequency castellated solutions are used by serious industry 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) Cc: Grzegorz Kasprowicz ; Leibrandt, David R. (Fed) ; Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] FW: initial specification of the project Well, it depends on trace width matching. We can simulate and characterize it even at much higher frequencies. If we place them really close to the DAC and match widths, remove grounds under pads, we can match it not worse than SMA connectors. We can even do even more crazy thing - try to make them mountable. The only signals that would need to be transmitted is DAC output / ADC input. We can use low profile board to board connectors for rest of the signals - I know ones that have 1mm stacking hight. For RF we could use PCB mounted UFL connectors. This is just crazy idea that need to be verified. On 30 March 2016 at 23:02, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: This is an interesting potential solution although I am not sure how the signal integrity is at ~3 GHz, for example. From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com<mailto:kaspr...@gmail.com>] Sent: Wednesday, March 30, 2016 2:44 PM To: Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> Cc: Grzegorz Kasprowicz mailto:gkasp...@elka.pw.edu.pl>>; Leibrandt, David R. (Fed) mailto:david.leibra...@nist.gov>>; Sébastien Bourdeauducq mailto:s...@m-labs.hk>>; artiq@lists.m-labs.hk<mailto:artiq@lists.m-labs.hk> Subject: Re: [ARTIQ] FW: initial specification of the project Such assembly technique is called: castellated PCB module https://www.google.pl/search?q=castellated+RF+modules&biw=1920&bih=917&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjRvuqko-nLAhWnnXIKHe_IARsQ_AUIBygB<https://www.google.pl/search?q=castellated+PCB+down+converter+modules&biw=1920&bih=917&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj19L7younLAhUKvXIKHQVBCg8Q_AUIBigB#tbm=isch&q=castellated+RF+modules> On 30 March 2016 at 22:40, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: One more thing - we can fit 5 SMA connectors on FMC panel, in case of 6 ones, we won't be able to screw them. But we can install MMCX ones for clocks and fit in total of 7 RF connectors, Look here http://www.ohwr.org/attachments/3390/fmc_top.jpg Greg On 30 March 2016 at 22:38, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: Well, we can do another crazy thing - solder small module with RF stuff on the FMC board, under same shield. In this way we keep 3 simple FMCs with expensive ADCs/DACs and define the functionality by soldering (automatic or manual) of just RF modules. WE can even design such modules to hold the front-end connectors of leave them on the FMC. Such approach has also some attractive feature - we can make them using small pieces of Rogers material which is hell expensive and it's hard to make small vias and thin traces needed for JESD signals. these modules could look like that http://www.emcfastpass.com/wp-content/uploads/2014/09/rf_module_holes.gif You can mount them by pick and place or manually. IT is also possible to manually disassemble them. This is a form factor of popular RF modules, i.e. wifi, GPS and LTE modems. http://www.emcfastpass.com/rf-modules/ And is simply works Greg On 30 March 2016 at 22:25, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: > 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 functionality > by FMC boards If we make 3 flavours of FMCs: ADC+ADC, > ADC+DAC,DAC+DAC, we would cover several use cases: > Quad ADC, quad DAC, 1xADC 3xDAC, 3xADC 1xDAC. > FMCs with only DAC and RF stuff on it can be simple, 4 layer boards with > external sield. > Look at this shield (my project) > http://www.ohwr.org/projects/fmc-adc-130m-16b-4cha/wiki > In this way we could use existing AFCK for quick tests We have been working with the notion that shoul
Re: [ARTIQ] FW: initial specification of the project
We definitely need +/- 15V for the low frequency (e.g. trap electrode) amplifiers. Many low noise amplifiers and RF components run off +5V or +/- 5V and have substantial current draws, so if you pull everything from +/- 15V rails you are tripling your power dissipation and you end up with very hot regulators. The DACs and ADCs will be dissipating a fair amount of power already so we want to try to keep the power budget under control. Other than that, I don’t see major reasons why one couldn’t run fewer analog rails. I think we are better off with DC/DC converters on the AMC card making a number of rails, which then have some filtering/regulation on the AMC card and then a final stage of LDO regulation on the FMC daughtercard itself, as close to the amplifiers etc as possible. Using the alternating grounds a la CERN seems like a suitable solution to me for sending in these additional analog rails. From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com] Sent: Wednesday, March 30, 2016 3:13 PM To: Slichter, Daniel H. (Fed) Cc: Robert Jördens ; Grzegorz Kasprowicz ; Leibrandt, David R. (Fed) ; Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] FW: initial specification of the project Well, CERN does it in their FMC carriers. They use HPC routed like LPC and then some of grounds are used as symmetrical analog supplies. In this way if you plug wrong board, it will short the supply but no damage will occur. I assume that low nosie DC/DC converters + LDOs will be installed on the AMC board. Do we need all these voltages, especially +/-5 and +/- 15? Won't single +/- 8 or +/- 15V be sufficient? Greg On 30 March 2016 at 23:08, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: 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 as well as +3.3V, +1.8V, +12V. Can we put these through on the FMC without breaking back compatibility? For example, one rail on each of the 4 VADJ pins? I am sure this would not be VITA 57 compliant….and we don’t want switching converters on the FMC daughtercard for space and noise reasons both. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
So now we are moving towards complying with the AMC FMC physical standard. Is this something we want to do? There are pluses (able to use existing AMC FMC cards) and minuses (squeezing things in more tightly than we otherwise might have to). From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com] Sent: Wednesday, March 30, 2016 2:41 PM To: Slichter, Daniel H. (Fed) Cc: Grzegorz Kasprowicz ; Leibrandt, David R. (Fed) ; Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] FW: initial specification of the project One more thing - we can fit 5 SMA connectors on FMC panel, in case of 6 ones, we won't be able to screw them. But we can install MMCX ones for clocks and fit in total of 7 RF connectors, Look here http://www.ohwr.org/attachments/3390/fmc_top.jpg Greg On 30 March 2016 at 22:38, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: Well, we can do another crazy thing - solder small module with RF stuff on the FMC board, under same shield. In this way we keep 3 simple FMCs with expensive ADCs/DACs and define the functionality by soldering (automatic or manual) of just RF modules. WE can even design such modules to hold the front-end connectors of leave them on the FMC. Such approach has also some attractive feature - we can make them using small pieces of Rogers material which is hell expensive and it's hard to make small vias and thin traces needed for JESD signals. these modules could look like that http://www.emcfastpass.com/wp-content/uploads/2014/09/rf_module_holes.gif You can mount them by pick and place or manually. IT is also possible to manually disassemble them. This is a form factor of popular RF modules, i.e. wifi, GPS and LTE modems. http://www.emcfastpass.com/rf-modules/ And is simply works Greg On 30 March 2016 at 22:25, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: > 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 functionality > by FMC boards If we make 3 flavours of FMCs: ADC+ADC, > ADC+DAC,DAC+DAC, we would cover several use cases: > Quad ADC, quad DAC, 1xADC 3xDAC, 3xADC 1xDAC. > FMCs with only DAC and RF stuff on it can be simple, 4 layer boards with > external sield. > Look at this shield (my project) > http://www.ohwr.org/projects/fmc-adc-130m-16b-4cha/wiki > In this way we could use existing AFCK for quick tests We have been working with the notion that should be many possible front ends for each of the DACs or ADCs, depending on what the particular application is, and so we want to separate the analog daughtercards from whatever board has the DACs and ADCs on it. This way, you can reconfigure the hardware for high-frequency or low-frequency applications, for example, by changing daughtercards and not having to build entire new AMC cards. The modularity principle lets one have a single design for the AMC card (aka DSP card) that can be used for many different applications, by shifting the analog signal processing circuitry onto a separate card. 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, and use FMC to communicate with the whole thing. This makes it a bit more expensive/difficult to reconfigure the analog front end, but the DAC and ADC costs are not so high that it is impossible to do. I had envisioned the notion of making the daughtercards simple enough that end users could redesign/respin easily to accommodate their own applications, or we could ship unstuffed or partially stuffed boards that they could complete with the particular filters etc they desire. However, I agree that there are compelling arguments for using the architecture you propose. We would need to pick just a few board styles (I suggest quad DAC, 2 DAC/2 ADC, and quad ADC), and for each of these board styles we would need to make several different variants with different analog front ends (3 types for DAC - low frequency, baseband RF, upconverted RF - and 2 types for ADC - baseband RF and downconverted RF, both likely including switchable gain). So now we are looking at making 3 types of quad DAC boards, 2 types of ADC board, and probably 3 types of DAC/ADC board (upconvert DAC/downconvert ADC, baseband RF DAC/baseband RF ADC, and low frequency DAC/baseband RF ADC). So now there are 8 different daughterboard designs. If we restrict ourselves to just quad DAC or quad ADC on a given daughtercard, then there are 5 designs, same as in the current proposal for analog-only daughtercards. I would still want to have boards be partially stuffed (or stuffed in different configurations on demand) to allow users to choos
Re: [ARTIQ] FW: initial specification of the project
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 as well as +3.3V, +1.8V, +12V. Can we put these through on the FMC without breaking back compatibility? For example, one rail on each of the 4 VADJ pins? I am sure this would not be VITA 57 compliant….and we don’t want switching converters on the FMC daughtercard for space and noise reasons both. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
This is an interesting potential solution although I am not sure how the signal integrity is at ~3 GHz, for example. From: Grzegorz Kasprowicz [mailto:kaspr...@gmail.com] Sent: Wednesday, March 30, 2016 2:44 PM To: Slichter, Daniel H. (Fed) Cc: Grzegorz Kasprowicz ; Leibrandt, David R. (Fed) ; Sébastien Bourdeauducq ; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] FW: initial specification of the project Such assembly technique is called: castellated PCB module https://www.google.pl/search?q=castellated+RF+modules&biw=1920&bih=917&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjRvuqko-nLAhWnnXIKHe_IARsQ_AUIBygB<https://www.google.pl/search?q=castellated+PCB+down+converter+modules&biw=1920&bih=917&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj19L7younLAhUKvXIKHQVBCg8Q_AUIBigB#tbm=isch&q=castellated+RF+modules> On 30 March 2016 at 22:40, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: One more thing - we can fit 5 SMA connectors on FMC panel, in case of 6 ones, we won't be able to screw them. But we can install MMCX ones for clocks and fit in total of 7 RF connectors, Look here http://www.ohwr.org/attachments/3390/fmc_top.jpg Greg On 30 March 2016 at 22:38, Grzegorz Kasprowicz mailto:kaspr...@gmail.com>> wrote: Well, we can do another crazy thing - solder small module with RF stuff on the FMC board, under same shield. In this way we keep 3 simple FMCs with expensive ADCs/DACs and define the functionality by soldering (automatic or manual) of just RF modules. WE can even design such modules to hold the front-end connectors of leave them on the FMC. Such approach has also some attractive feature - we can make them using small pieces of Rogers material which is hell expensive and it's hard to make small vias and thin traces needed for JESD signals. these modules could look like that http://www.emcfastpass.com/wp-content/uploads/2014/09/rf_module_holes.gif You can mount them by pick and place or manually. IT is also possible to manually disassemble them. This is a form factor of popular RF modules, i.e. wifi, GPS and LTE modems. http://www.emcfastpass.com/rf-modules/ And is simply works Greg On 30 March 2016 at 22:25, Slichter, Daniel H. (Fed) mailto:daniel.slich...@nist.gov>> wrote: > 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 functionality > by FMC boards If we make 3 flavours of FMCs: ADC+ADC, > ADC+DAC,DAC+DAC, we would cover several use cases: > Quad ADC, quad DAC, 1xADC 3xDAC, 3xADC 1xDAC. > FMCs with only DAC and RF stuff on it can be simple, 4 layer boards with > external sield. > Look at this shield (my project) > http://www.ohwr.org/projects/fmc-adc-130m-16b-4cha/wiki > In this way we could use existing AFCK for quick tests We have been working with the notion that should be many possible front ends for each of the DACs or ADCs, depending on what the particular application is, and so we want to separate the analog daughtercards from whatever board has the DACs and ADCs on it. This way, you can reconfigure the hardware for high-frequency or low-frequency applications, for example, by changing daughtercards and not having to build entire new AMC cards. The modularity principle lets one have a single design for the AMC card (aka DSP card) that can be used for many different applications, by shifting the analog signal processing circuitry onto a separate card. 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, and use FMC to communicate with the whole thing. This makes it a bit more expensive/difficult to reconfigure the analog front end, but the DAC and ADC costs are not so high that it is impossible to do. I had envisioned the notion of making the daughtercards simple enough that end users could redesign/respin easily to accommodate their own applications, or we could ship unstuffed or partially stuffed boards that they could complete with the particular filters etc they desire. However, I agree that there are compelling arguments for using the architecture you propose. We would need to pick just a few board styles (I suggest quad DAC, 2 DAC/2 ADC, and quad ADC), and for each of these board styles we would need to make several different variants with different analog front ends (3 types for DAC - low frequency, baseband RF, upconverted RF - and 2 types for ADC - baseband RF and downconverted RF, both likely including switchable gain). So now we are looking at making 3 types of quad DAC boards, 2 types of ADC board, and probably 3 types of DAC/ADC board (upconvert DAC/downconvert ADC, baseband RF DAC/b
Re: [ARTIQ] FW: initial specification of the project
> On Wed, Mar 30, 2016 at 10:25 PM, Slichter, Daniel H. (Fed) > 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, and use FMC to communicate with the whole thing. This makes it a bit > more expensive/difficult to reconfigure the analog front end, but the DAC > and ADC costs are not so high that it is impossible to do. I had envisioned > the > notion of making the daughtercards simple enough that end users could > redesign/respin easily to accommodate their own applications, or we could > ship unstuffed or partially stuffed boards that they could complete with the > particular filters etc they desire. > > It makes letting unused mezzanines collect dust on the shelf more > expensive. The point is you buy X number of daughtercards for Y AMC cards, where X>Y (perhaps X=2*Y or X=3*Y), and the daughtercards either do or don't have ADC/DAC on them. If they do, it costs you more than if the ADC/DAC were on the AMC modules. > > However, I agree that there are compelling arguments for using the > architecture you propose. We would need to pick just a few board styles (I > suggest quad DAC, 2 DAC/2 ADC, and quad ADC), and for each of these board > styles we would need to make several different variants with different > analog front ends (3 types for DAC - low frequency, baseband RF, > upconverted RF - and 2 types for ADC - baseband RF and downconverted RF, > both likely including switchable gain). So now we are looking at making 3 > types of quad DAC boards, 2 types of ADC board, and probably 3 types of > DAC/ADC board (upconvert DAC/downconvert ADC, baseband RF > DAC/baseband RF ADC, and low frequency DAC/baseband RF ADC). So now > there are 8 different daughterboard designs. If we restrict ourselves to just > quad DAC or quad ADC on a given daughtercard, then there are 5 designs, > same as in the current proposal for analog-only daughtercards. I would still > want to have boards be partially stuffed (or stuffed in different > configurations on demand) to allow users to choose the frequencies of > interest for analog filters etc. > > > > If we proceed this way, we will need an external clock SMA for each FMC > module, because we don't want the high-quality external clock going down > one FMC connector, across the AMC, and up the other FMC connector for > signal integrity/crosstalk reasons. > > For a digital clock with fast edges 60 dB of crosstalk is _much_ less of a > problem. No! The clock coming in will be a sine wave from a low phase noise oscillator somewhere. The DACs and ADCs will threshold this clock to determine their sample times. Any amount of crosstalk will distort the clock signal (adding or subtracting to the voltage at a given time), thus skewing the time at which the threshold is reached and thus inducing jitter into the sampling times. This would also hold true even if you have an LVPECL clock signal, because at frequencies like 2.4 GHz the rise and fall times (~100-200 ps) are similar to that of a sine wave. Unlike for digital data signals, any amount of crosstalk will degrade the jitter and/or edge time performance for a clock signal. > > Are we thinking we would try to implement the actual VITA 57 standard on > these connectors? Or just use them as convenient high-speed-capable > connectors? I agree with the second idea, but I don't like the first one. > > What from the VITA 57 pin assignmend do you not like? If you comply with VITA 57, we will need to use an HPC connector to get enough gigabit transceivers into the connector, and we will have to populate all the other digital lines. We could use an HPC connector with the VITA 57 LPC connections, plus adding on the gigabit transceivers in the locations where they would go for an HPC connector, and thus have an LPC compliant connector with "extra features" for the needed gigabit transceivers. I am just trying to reduce unnecessary complexity in routing the AMC board to the FMC connectors, since HPC is much more of a pain than LPC in this regard. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> 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 functionality > by FMC boards If we make 3 flavours of FMCs: ADC+ADC, > ADC+DAC,DAC+DAC, we would cover several use cases: > Quad ADC, quad DAC, 1xADC 3xDAC, 3xADC 1xDAC. > FMCs with only DAC and RF stuff on it can be simple, 4 layer boards with > external sield. > Look at this shield (my project) > http://www.ohwr.org/projects/fmc-adc-130m-16b-4cha/wiki > In this way we could use existing AFCK for quick tests We have been working with the notion that should be many possible front ends for each of the DACs or ADCs, depending on what the particular application is, and so we want to separate the analog daughtercards from whatever board has the DACs and ADCs on it. This way, you can reconfigure the hardware for high-frequency or low-frequency applications, for example, by changing daughtercards and not having to build entire new AMC cards. The modularity principle lets one have a single design for the AMC card (aka DSP card) that can be used for many different applications, by shifting the analog signal processing circuitry onto a separate card. 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, and use FMC to communicate with the whole thing. This makes it a bit more expensive/difficult to reconfigure the analog front end, but the DAC and ADC costs are not so high that it is impossible to do. I had envisioned the notion of making the daughtercards simple enough that end users could redesign/respin easily to accommodate their own applications, or we could ship unstuffed or partially stuffed boards that they could complete with the particular filters etc they desire. However, I agree that there are compelling arguments for using the architecture you propose. We would need to pick just a few board styles (I suggest quad DAC, 2 DAC/2 ADC, and quad ADC), and for each of these board styles we would need to make several different variants with different analog front ends (3 types for DAC - low frequency, baseband RF, upconverted RF - and 2 types for ADC - baseband RF and downconverted RF, both likely including switchable gain). So now we are looking at making 3 types of quad DAC boards, 2 types of ADC board, and probably 3 types of DAC/ADC board (upconvert DAC/downconvert ADC, baseband RF DAC/baseband RF ADC, and low frequency DAC/baseband RF ADC). So now there are 8 different daughterboard designs. If we restrict ourselves to just quad DAC or quad ADC on a given daughtercard, then there are 5 designs, same as in the current proposal for analog-only daughtercards. I would still want to have boards be partially stuffed (or stuffed in different configurations on demand) to allow users to choose the frequencies of interest for analog filters etc. If we proceed this way, we will need an external clock SMA for each FMC module, because we don't want the high-quality external clock going down one FMC connector, across the AMC, and up the other FMC connector for signal integrity/crosstalk reasons. Are we thinking we would try to implement the actual VITA 57 standard on these connectors? Or just use them as convenient high-speed-capable connectors? I agree with the second idea, but I don't like the first one. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> > 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? > > Just one, the space on the AMC is rather limited. We should be able to do two side by side. I think it would be nice to be able to select the input daughtercard separately from the output daughtercard. This would require having two sets of pin headers for sending power and digital signals, but I think the input daughtercards would likely have much less in terms of digital control signal requirements; there would be two basic designs, one for baseband digitization and one for downconversion before digitization. Both designs would just have analog components, no digital attenuators/switches/etc would be necessary or desired. This would especially hold true if we go to a 4 DAC / 2 ADC design, but a 4/4 design should work fine too. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> 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. Perhaps two daughter > cards would be reasonable: one for all of the inputs and one for all of the > outputs? Agreed that ~ 8 front panel SMA connections, plus one clock SMA connection, is about what one can tolerate in a reasonable way in terms of physical footprint. If we split this as 4 DAC + 4 ADC, it makes a nice symmetry although my suspicion is that most applications would prefer something more asymmetric with a few more DAC channels than ADC channels (6 DAC/2 ADC or 6 DAC/4 ADC, for example). One could go a simple as 4 DAC/2 ADC and make the space requirements even simpler to fulfill on the cards. All of these modifications will increase the price per channel, even though we may be able to save on FPGA costs. For example, if we do 4 DAC/2 ADC on a card with 1x AD9154 and 1x ADC16DX370 (our currently planned parts), we only need 10 GTX transceivers on the FPGA. With 4 DAC/4 ADC, this would be 12 GTX transceivers. With these numbers we could look at the ZU5EV Zynq Ultrascale, instead of the ZU9EG, which we had been discussing. To Greg's question on the RTM, we have had a number of extensive internal discussions about pros and cons of RTM and it seems that we don't want to pursue this avenue for a number of carefully considered reasons. Let's just take it as a given that we will need to put everything on the AMC card or its analog daughtercards. As stated, the DAC and ADC chips themselves will be on the AMC card, not the analog daughtercards. I am in favor of separate analog daughtercards for the inputs and the outputs, this seems sensible. > On Tuesday, 29 March 2016 11:55:19 PM HKT Grzegorz Kasprowicz wrote: > > - they can be used immediately with existing OSHW carriers like AFC/AFCK. > > AFCK may be overkill. We are still working on evaluating the FPGA resource > requirements. > > > - it could be hard to fit FPGA, supply, DACs and several RF modules, > > all on single dual width AMC, especially when shielding is required. > > RTM relaxes these constraints > > - on AMC+RTM you can place 8 ADC channels + 8 DAC channels + 8 RF > > modules. In case of single AMC board it would be hard to achieve such > > channels density. > > How about this: > * we reduce the number of channels per AMC to 4 DACs + 4 ADCs > * we can therefore use a smaller FPGA. Communication lanes to the master > board are relatively cheap if we put them on IOSERDES. > * the power density and cooling requirements are also reduced. > * for the RF daughter cards, we use a custom form factor that can use at least > 2/3 of the AMC front panel > * connectors between the DSP card and the RF daughter card are 2mm > header and 8x SMP > * the rest of the AMC front panel used for (optional, runtime selectable) > clock input and some TTLs. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> FMC has mounting height of 8 or 10mm. > Other heights are also possible in case of SEARAY series, but one must order > large number of them Greg FMC per VITA 57.1 standard is 8.5 mm stacking height or 10 mm stacking height (see section 3.4). You can get the SEARAY connectors (of which FMC compliant connectors are a subset) in a variety of other stacking heights too. At the end of the day, I really think that something simple and straightforward like pin headers is going to work well and will save us a lot of hassle in finding specialized connectors/worrying about 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 > Cc: Grzegorz Kasprowicz ; artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] FW: initial specification of the project > > Let me make clear that I don't have any specific opposition to FMC for the > power/digital signals. The only reason for considering other types of > connectors would be either if the desired stackup height is not doable (this > is > unlikely -- one .224" bullet e.g. corning A1A1-0001-02, plus two male > connetors with .051" reference plane distance, e.g. Molex 74315-3312, gives > a total SMP height of 8.28 mm, which works perfectly with the standard FMC > stackup height of 8.5 mm board to board), or if there is not enough real > estate on the board to meet the physical footprint requirements (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) > > Cc: Sébastien Bourdeauducq ; Grzegorz Kasprowicz > > ; artiq@lists.m-labs.hk > > Subject: Re: [ARTIQ] FW: initial specification of the project > > > > On Tue, Mar 29, 2016 at 5:16 PM, Slichter, Daniel H. (Fed) > > wrote: > > > Yes, FMC could work but it's overkill in terms of pin count; one > > > might be > > able to find a smaller footprint connector with fewer pins, which > > would be advantageous. Frankly something as dumb and cheap as 2 mm > > pin headers would do the job. > > > > Yes. A pin header would be dumb if there are better suggestions. > > LPC FMC with 64 single ended signals is definitely not overkill if 40 > > signals is the estimated need. The grounding is unlikely to hurt. > > There are certainly many other offers. But if there is such a strong > > opposition to FMC, I would look for something where we can at least > > expect a long term availability that is similar to the FMC usage lifespan. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> There are FMC-type connectors with much smaller number of pins (SEARAY > series) Greg Sure. I think Robert wants to use the particular ones that are in the VITA FMC standard, for longevity purposes. I happen think that pin headers are the cockroaches of board-to-board connectors; they will still be around after the nuclear holocaust wipes everything else out. > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > Jördens > Sent: Tuesday, March 29, 2016 1:01 PM > To: Sébastien Bourdeauducq > Cc: Grzegorz Kasprowicz ; artiq@lists.m-labs.hk; > Slichter, Daniel H. (Fed) > Subject: Re: [ARTIQ] FW: initial specification of the project > > On Tue, Mar 29, 2016 at 11:56 AM, Sébastien Bourdeauducq > wrote: > > On Monday, 28 March 2016 6:30:52 PM HKT Slichter, Daniel H. (Fed) wrote: > >> Thus for the two examples above, using digital connectors with a 9 mm > >> or 11 mm total stackup height would give 250 um axial misalignment > >> (.010"), which is a typical tolerance one would want to use anyway with > SMP. > >> > >> More information is available in this application note: > >> > https://www.corning.com/media/worldwide/coc/documents/applications/ > mi > >> crowave > >> ApplicationNotes.pdf > > > > 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. > Also since reliably reflowing SMP connectors manually to three hair widths is > rather tricky, manual assembly is of the table now anyway. And FMC give us > at least a form factor that has been tested very well. No need to reinvent the > mezzanine here. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
Let me make clear that I don't have any specific opposition to FMC for the power/digital signals. The only reason for considering other types of connectors would be either if the desired stackup height is not doable (this is unlikely -- one .224" bullet e.g. corning A1A1-0001-02, plus two male connetors with .051" reference plane distance, e.g. Molex 74315-3312, gives a total SMP height of 8.28 mm, which works perfectly with the standard FMC stackup height of 8.5 mm board to board), or if there is not enough real estate on the board to meet the physical footprint requirements (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) > Cc: Sébastien Bourdeauducq ; Grzegorz Kasprowicz > ; artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] FW: initial specification of the project > > On Tue, Mar 29, 2016 at 5:16 PM, Slichter, Daniel H. (Fed) > wrote: > > Yes, FMC could work but it's overkill in terms of pin count; one might be > able to find a smaller footprint connector with fewer pins, which would be > advantageous. Frankly something as dumb and cheap as 2 mm pin headers > would do the job. > > Yes. A pin header would be dumb if there are better suggestions. > LPC FMC with 64 single ended signals is definitely not overkill if 40 signals > is > the estimated need. The grounding is unlikely to hurt. > There are certainly many other offers. But if there is such a strong > opposition > to FMC, I would look for something where we can at least expect a long term > availability that is similar to the FMC usage lifespan. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
How about something like this for board-to-board connector for power/digital? Allows 11 mm stackup, can do 40 pins in relatively small footprint, well-engineered mezzanine connector: https://www.samtec.com/products/qse There are of course many more options than just this, but just to show the alternatives to FMC. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> > 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. > Also since reliably reflowing SMP connectors manually to three hair widths is > rather tricky, manual assembly is of the table now anyway. And FMC give us > at least a form factor that has been tested very well. No need to reinvent the > mezzanine here. Yes, FMC could work but it's overkill in terms of pin count; one might be able to find a smaller footprint connector with fewer pins, which would be advantageous. Frankly something as dumb and cheap as 2 mm pin headers would do the job. Manual assembly was never really one of the major concerns with these daughtercards, as many of the desired components are leadless or QFN packages with center ground pads, which are tricky for manual assembly anyway, especially if one cares about microwave performance. However, many SMP connectors have a through hole design (see below for an example from Corning Gilbert, or from Molex at http://www.molex.com/pdm_docs/sd/734153320_sd.pdf ), so it's entirely possible to achieve the kind of lateral alignment tolerances required with manual assembly. Cost-wise, the molex part quoted is less than $3 apiece on digikey at qty 750 (and $5 at qty 1), so it’s not like these connectors will be a major cost driver on the cards either. [cid:image001.png@01D1899A.9C6CA5F0] ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> 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
Re: [ARTIQ] FW: initial specification of the project
> Is there a digital/power board-to-board connector that is known to be > compatible with SMP? Connectors of different types are often not meant to > be used together and their heights can be significantly different - certainly > by > more than 2.54mm. One can purchase bullets of varying lengths to give the desired full stackup depth for SMP connectors. Bullet lengths of .243", .254", .286", .395", .517" are standard, for example, and custom bullet lengths are available. The mating board connectors add further length to these bullets, typically .051" or .090" each. Just to give two examples, two .051" connectors plus a .243" bullet is 8.75 mm, and two .091" connectors plus a .243 bullet is 10.75 mm. You typically run the SMP connectors with the bullets not inserted fully flush - this is called "axial misalignment". The measured specification on this at frequencies below ~3.5 GHz (where we are concerned) is such that we should be able to tolerate .025" or even a bit more of axial misalignment and still have this not limit the overall signal performance. Thus for the two examples above, using digital connectors with a 9 mm or 11 mm total stackup height would give 250 um axial misalignment (.010"), which is a typical tolerance one would want to use anyway with SMP. More information is available in this application note: https://www.corning.com/media/worldwide/coc/documents/applications/microwaveApplicationNotes.pdf There are many multipin connector types available suitable for power or digital signal transmission (remember, these digital signals will not be extremely high speed, definitely <100 MHz and probably <20 MHz given typical hardware they would be addressing) with stackups of 9 mm or 11 mm. For comparison with FMC, the spec value on RF leakage for SMP is -80 dB to 3 GHz (this should be measured to verify as well). I will work on a test board that compares FMC with SMP using otherwise identical traces on the two PC boards. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
The beauty of SMP connectors is that they are explicitly designed for board-to-board applications with substantial tolerance for misalignment. Each board has a male SMP connector, with a female-female "bullet" in between. These connectors, with the bullet in between, can tolerate substantial axial and radial misalignment (in excess of .010" - basically considerably larger than the fabrication tolerances of typical PCBs and PCB assembly) without degrading RF performance. Then one would have one multipin connector for power and digital signals that fixes the board-to-board alignment, and the SMP connectors can absorb the slack as necessary based on fabrication/assembly tolerances for their placement. I agree that if we can get suitable performance out of an FMC or other single-connector solution, that would be better from a physical simplicity standpoint. We need to test this. I may try putting together a board to do so in the near term. > -Original Message- > From: Sébastien Bourdeauducq [mailto:s...@m-labs.hk] > Sent: Saturday, March 26, 2016 10:19 AM > To: Slichter, Daniel H. (Fed) > Cc: Grzegorz Kasprowicz ; artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] FW: initial specification of the project > > On Saturday, 26 March 2016 4:06:17 PM HKT Slichter, Daniel H. (Fed) wrote: > > The cost savings from using FMC, which might amount to $50 per AMC, > > are not worth if the crosstalk will make the cards not useful for > > researchers. > > It's not only about cost of the connector - the RF daughter cards will often > need some digital signals (e.g. SPI) for control. FMC provides plenty of pins > for that. Mixing two different types of board-to-board connectors will cause > mechanical problems and I think we should not do that. If two types of > connectors are needed, one of them should use cables. > > Sébastien ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] FW: initial specification of the project
> > * we want to avoid RTMs and instead put the DAC/ADCs on the AMC card > > and have analog plug-ins using the FMC form factor (see my document). > > **Are you sure you would get noise performance from such setup that > > satisfies you? > > Unless the FMC connector is particularly bad with analog signals, I think it > should not be worse than the current hardware. I want to repeat what Sebastien has said, that we want the signals to come out the front, and to avoid the use of RTMs as the standard output. There may be some special use cases (e.g. many channels of slow ADC) that *might* work with the RTM architecture, but for the DSP AMC cards we want all the DACs on the AMC card and their outputs routed immediately to the small RF/analog daughter cards. I want to stress again that the levels of channel crosstalk relevant to quantum information/optical clock experiments are vastly more stringent than for typical signals propagating through large "high-speed" connectors. I think it will be necessary to use minimal length unshielded traces and have multi-cavity shielding on the daughtercards to ensure low crosstalk. The use of a connector like an FMC, even with grounding wires between differential pairs, is inevitably going to be worse than using dedicated board-to-board RF connectors like SMP/GPO or their smaller cousins GPPO/G3PO. These connectors are explicitly designed for these types of applications, and allow for board misalignments etc. The cost savings from using FMC, which might amount to $50 per AMC, are not worth if the crosstalk will make the cards not useful for researchers. For reference, Samtec offers an intermediate solution called Isorate, which is designed to have higher isolation than typical high speed connectors while being cheaper than SMP. They spec 80 dB isolation at 1.3 GHz and 70 dB at 7.6 GHz, so probably we are talking between 90 and 75 dB isolation in our frequency range of interest for RF/microwave signals. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] analog extension cards
To clarify nomenclature, we have been referring to these as "RF daughter cards" previously. These cards could potentially contain components such as RF amplifiers, operational/instrumentation amplifiers, filters, mixers/modulators/demodulators, splitters/combiners/hybrids, baluns, digital or analog attenuators, RF switches, frequency multipliers. There are three types of basic card designs that I think should be available from the beginning: 1. "Low frequency" - Signal bandwidth of a few MHz, swinging between +/- 10 V or so, suitable for ion trap transport waveforms or various DC or quasi-DC bias signals in general applications. This would involve op amps/instrumentation amps running off +/- 15V supplies in a similar configuration to the current PDQ output stages. Footprints for discrete component filters both before and after the amplifiers should be included. 2. "RF" - For synthesis of tones from a few MHz out to ~3.3 GHz, suitable for AOM drive or Be+/Mg+/Ca+/NV center microwave transitions. This would involve a set of filters (common footprint, stuff boards with different cutoff parts to define band of interest -- these can be left open for users, or we can choose one or two basic frequency sets and they can run their own custom assembly order from the fab/layout docs if they want something different) followed by an RF amplifier stage (ERA-4SM is a good broadband low-phase-noise selection), a digital step attenuator, and a fast high-isolation RF switch. 3. "Upconverting" - For synthesis of tones beyond ~3.3 GHz, suitable for Yb+ or superconducting qubit microwave transitions. The board would have an input connector for an externally generated microwave carrier, split and sent to the LO ports of a set of mixers/modulators. We should decide if these needs to be IQ mixers or if regular mixers are sufficient. There will be filters (again, common footprint for a choice of frequencies) between the DAC outputs and mixer IF ports. Each mixer RF port will be followed by an amplifier, a digital step attenuator, and a fast high-isolation RF switch. Again, I stress strongly that I am *not* satisfied using FMC connectors for these cards until someone has tested and verified properties like crosstalk. This issue has the potential the render the entire hardware project useless (e.g. if crosstalk levels are too high), and therefore we need to be very careful about design here. For the "RF" and "upconverting" boards, it will most likely be important to have board-level shielding cavities to reduce crosstalk between channels on the daughtercards. It is possible to have these custom designed and produced inexpensively at scale (~$15-$20/board). Best, Daniel > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sébastien > Bourdeauducq > Sent: Saturday, March 26, 2016 2:57 AM > To: artiq@lists.m-labs.hk > Subject: [ARTIQ] analog extension cards > > Hi, > > any ideas of what analog extensions in FMC form factor for the DSP card > should be available first? Mixers I guess, but what are the specs? Amplifiers? > > Sébastien > > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [RFC] timeline behavior of coredevice API kernels
> > I think SPI writes should occur in the "past" and SPI reads should occur in
> the "future". This is based on the notion that the time you care about (and
> the one which is simplest to think about) really has to do with whether or not
> the slave device is "ready" in the appropriate sense. For writes, the slave
> is
> "ready" once it has received the information you wanted to write to it, i.e.
> the end of the write. For reads, the slave must be "ready" at the start of
> the
> read transaction.
>
> This doesn't really work. An SPI transaction can be mixed reading and writing.
> And for many devices they need to be mixed transactions. Also most devices
> need to be ready when you start _writing_ the address you want to _read_
> from. "Device readiness" is not a good point in time for generic SPI
> transactions. Bus idle is.
I don't buy this. I think the SPI implementation should be as device-agnostic
as possible, with all device-based specifics built in at a higher, device
driver level. For SPI, device "readiness" is only an indication of whether
bits are ready to be clocked out (for reads), or whether bits have completed
being clocked in (for writes). If you want to talk about a device being
"ready" in the sense of "I have completed conversion of an analog signal to
digital", or "I have updated my DAC outputs", these things are for device
drivers to determine, not the lowest-level SPI implementation.
> Having spi.write() be zero delay is not how you can conveniently use it. If
> you
> ever do more than two transactions (writes to different
> registers) back to back, you need to figure out the delay required and apply
> it. That is why spi.write() should apply the delay itself and additionally
> offer a
> way to determine the delay so it can be used to build zero-delay methods.
If you split SPI into atomic units of write only and read only (understanding
that this is slightly different from your current proposal), and you allow a
programmable delay for the "now" time on the end of write or start of read (as
you suggest here), this is a totally generic way of implementing SPI without
needing to combing reading and writing in a single transaction. Then the
definitions of "now" as being at the end of a write or the beginning of a read
(including delays before last/first clock edge respectively) plus the optional
delay allows one to build up multiple transactions back to back in a clean way
as you suggest.
> > The performance of a FUD or LDAC should be separate from the SPI
> transaction itself. Some transactions do not want/need a FUD-like signal --
> for example each atomic SPI call writes up to 32 bits in the current scheme.
> For programming a DDS, for example, one may wish to have several SPI calls
> (to write amplitude, FTW, POW) without issuing a FUD until all writes are
> completed, or one might wish to update registers on several DDS chips
> sharing one SPI bus and then perform a simultaneous FUD on all at once.
> Also, different devices will have different allowed latencies between the
> completion of an SPI transaction and updating internal registers with FUD or
> LDAC, and this should be handled either manually by the user, or preferably
> by their writing higher-level methods specific to the individual hardware
> ("device drivers"). SPI doesn't know about FUD or LDAC, nor should it. This
> simplifies the SPI and puts the complications of individual devices onto
> higher-level code, which is desirable.
>
> Are suggesting something different from what I said about the distinction
> between spi.write() and spi_dac.set()?
My point was that spi.write() should not have any knowledge of FUD or LDAC; it
wasn't clear to me that you were saying this explicitly in your email, but if
you were, then I agree. If you have a driver for an spi_dac or spi_dds, then
it is the responsibility of the respective set() methods to figure out the
appropriate times for FUD/LDAC. For example, LDAC updates the DAC outputs
immediately upon going low (as long as BUSY is not low) for the AD5370, but for
an AD9914, the time that matters is when the SYNC_CLK of the DDS has a rising
edge when FUD is high. So you have different drivers for these two types of
hardware. For spi_dds.set(), the "now" can be at the deassertion of FUD.
The core device will know the rising edge of SYNC_CLK because we plan to use a
loopback TTL line in the same TTL breakout as feeding back SYNC_CLK from the
SPI DDS chip into another TTL input, so one can establish a phase relationship
between a TTL pulse at the location of the SPI DDS generated synchronously with
the RTIO clock and the DDS SYNC_CLK (which is at the same frequency). This
will allow us to do a deterministic FUD on the SPI DDS chips by choosing the
phase (fine timestamp) of the FUD pulse with respect to the RTIO clock
appropriately. Thus the deassertion of FUD can have a deterministic
relationship with the time at which the DD
Re: [ARTIQ] [RFC] timeline behavior of coredevice API kernels
> 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 located at the
> current point on the timeline. And they should apply net zero net delay on
> the timeline. That means that DDS and SPI DAC do all bus writing in the past
> before asserting FUD and LDAC in the present. But the deassertion of FUD
> and LDAC happens in the future. An spi_adc.get() would sample at `now` but
> would do the readout in the future.
I think SPI writes should occur in the "past" and SPI reads should occur in the
"future". This is based on the notion that the time you care about (and the
one which is simplest to think about) really has to do with whether or not the
slave device is "ready" in the appropriate sense. For writes, the slave is
"ready" once it has received the information you wanted to write to it, i.e.
the end of the write. For reads, the slave must be "ready" at the start of the
read transaction.
I would then argue that the SPI functionality should be such that an SPI write
transaction is completed, by which I mean that the SPI clock at the output of
the master has returned to its default level exactly at "now". For an SPI read
transaction, the SPI clock should depart from its default level exactly at
"now". It may be acceptable if one simply guarantees that for writes, the SPI
clock has returned to default level at some time before "now", and for reads
that the SPI clock will depart from its default level sometime after "now", as
long as the time duration between either of these actions and "now" is
explicitly bounded and is "small" in the sense of not being comparable to the
duration of a full atomic SPI transaction as implemented.
The performance of a FUD or LDAC should be separate from the SPI transaction
itself. Some transactions do not want/need a FUD-like signal -- for example
each atomic SPI call writes up to 32 bits in the current scheme. For
programming a DDS, for example, one may wish to have several SPI calls (to
write amplitude, FTW, POW) without issuing a FUD until all writes are
completed, or one might wish to update registers on several DDS chips sharing
one SPI bus and then perform a simultaneous FUD on all at once. Also,
different devices will have different allowed latencies between the completion
of an SPI transaction and updating internal registers with FUD or LDAC, and
this should be handled either manually by the user, or preferably by their
writing higher-level methods specific to the individual hardware ("device
drivers"). SPI doesn't know about FUD or LDAC, nor should it. This simplifies
the SPI and puts the complications of individual devices onto higher-level
code, which is desirable.
For some devices, a read transaction necessarily involves a prior write
transaction announcing what is desired to be read (e.g. DDS register readback).
In this instance, the functionality should be split into two SPI calls, one
for a write (issuing the command), and one for a read (reading back the
result), allowing for a delay to be inserted (manually or at a "device driver"
level) between these two transactions as required by the particular device.
This delay will then give the exact time required between the last edge of the
"write" clock and the first edge of the "read" clock, which is generally what
is specified on datasheets.
> Kernels that dominantly refer to a time interval (ttl.pulse(),
> ramsey_pulse_sequence()) or those where a unique point in time can not be
> assigned (spi.write(): some devices use the last bit clocked in, others the
> deassertion of cs_n)
One solution here might be to add an input parameter to spi.write() and
spi.read() which indicates whether or not the chip select should be left
asserted at the end of the transaction or not. If so, the point in time for
read and write methods is the last clock edge as described above; if not, then
the deassertion time is used. Another wrinkle here is that different chips
have different requirements on the delay between assertion of cs/first clock
edge and last clock edge/deassertion of cs, so probably these methods should
also include delays relative to first/last clock edges for
assertion/deassertion of cs, respectively. This would allow for situations
like the AD9914, where cs must remain asserted after writing a read instruction
through the end of the subsequent readback, being handled with two separate
calls to write() and read(), with a delay in between, as outlined above.
> should schedule their actions between now (at kernel
> entry) and when they are done (kernel return). They should apply the
> appropriate delay to the timeline to ensure the same kernel can immediately
> be called again with an equivalent result. And
Re: [ARTIQ] ARTIQ-1.0 feature freeze
> Yes, the PDQ2 is for 1.0 (and tagged accordingly in the issue tracker); AFAIK > most labs need the PDQ? Yes, PDQ is used by everyone except the clock labs currently. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ-1.0 feature freeze
> One thing we should do as part of the release process is to designate a > release candidate that would need to see some actual testing before we call > it a release. Otherwise chaos ensues usually. Anybody willing to test such a > release candidate to make sure we didn't overlook something? The Magtrap aims to be using ARTIQ in a serious way very soon, so we would be willing to test a release candidate. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] ARTIQ-1.0 feature freeze
> 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 in the clock lab for most of the > experiments we run, so we probably won't be able to use ARTIQ to run our > main experiments until there is a stable release including SPI. The magtrap also has a number of uses for SPI, so we agree that this would be very helpful to have implemented in ARTIQ 1.0. What is the current timescale for implementation of SPI? Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] turning experiment docks into MDI windows
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. ; Robert Jördens > > Cc: artiq@lists.m-labs.hk; Tan, Ting Rei > Subject: Re: [ARTIQ] turning experiment docks into MDI windows > > On Monday, February 15, 2016 11:09 PM, Slichter, Daniel H. wrote: > > My main question: how long would it take to change the GUI > > implementation over to this proposed model? > > Not long I believe, the code in ARTIQ is rather modular and so far my > experience with those parts of Qt has been relatively hassle-free. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] turning experiment docks into MDI windows
> On Mon, Feb 15, 2016 at 1:43 PM, Sébastien Bourdeauducq > wrote: > > what would you think about making the ARTIQ GUI look like this, with > > the experiment argument editors replacing the *.ui files: > > http://web.univ-pau.fr/~puiseux/enseignement/python/tutoQt- > zero/images > > /10/fenetre-03.png From our standpoint in Quantum I, this seems like a nice way to bring some organization to the GUI. As long as things can be spread over multiple monitors as suggested by Robert, I think it should work. My main question: how long would it take to change the GUI implementation over to this proposed model? Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] flash-backed persistent storage from experiments
> Assuming there is also SDRAM-backed key-value data that persists (uploaded > with and written by one experiment, used by others), flash-backed data > would only help for the idle_kernel (especially given the constraints). IMHO > we can survive without it. I tend to agree that while handy, it doesn't seem essential right now, and if the issue is one that is peculiar to the KC705, as Peter says, then I say don't worry about it for the time being. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] flash-backed persistent storage from experiments
> What is the use case for flash-backed persistent storage accessed from > experiments? One case is to store various hardware calibration parameters (e.g. desired phase of IO_UPDATE with respect to RTIO clock) which may be specific to the particular core device, so that one can change the computer which talks to the core device without having to transfer to the new computer all such hardware calibration values. It seems appropriate to store such parameters tied to specific hardware on the hardware itself, if possible. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] changing "experiment" terminology
I am in full agreement with Robert; I think "experiment" is much better terminology than "application" for all of these things, including "small housekeeping tasks", as they have been described. What is the motivation behind wanting to change the terminology? My feeling is that any changes in terminology should happen only if they provide a big improvement in clarity, which this proposed change doesn't seem to do as far as I am concerned. If you start trying to delineate between "small" and "large" experiments that produce or don't produce "science", everyone is going to have a different opinion about each thing and it will be very confusing. One person's "application" would be another person's "experiment" and so on. One name to just describe all of them should be the way to go, and I don't see why "experiment" is a bad name to use. Best, Daniel > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Robert > Jördens > Sent: Friday, December 11, 2015 1:53 AM > To: Sebastien Bourdeauducq > Cc: artiq@lists.m-labs.hk > Subject: Re: [ARTIQ] changing "experiment" terminology > > On Fri, Dec 11, 2015 at 1:37 AM, Sebastien Bourdeauducq > wrote: > > On Friday, December 11, 2015 04:36 PM, Sebastien Bourdeauducq wrote: > >> My thinking is that the word "experiment" evokes something more > >> advanced > > Or more precisely: something that produces science results directly. > > That is not a very useful requirement. > What about an experiment that is aborted and thus does not produce any > results, science or not? > > -- > Robert Jordens. > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] DDS vs DAC for RF; parallel LVDS vs GTX
> > - would need to synchronize the two chips with SYSREF system, feed > matched data clocks > > Shouldn't the ADCs be synchronized with the DACs anyway? We don't actually need these to be synchronized together unless you care about have a deterministic phase relationship between DAC outputs and ADC inputs. My feeling is that this is not one of the use cases of this hardware; if that is needed one can make a more complex board. You also have to consider that if the ADC and DAC clock frequencies will be different (which they must be), and are not related as a ratio of integers (which is potentially the case as well), the synchronization doesn't really have meaning anyway. If you care about the time lag between output from a DAC and input to an ADC (less stringent than phase relationship), you can use two FPGA outputs to send a SYSREF signal to the DACs and a different SYSREF signal to the ADC(s). That will give you the timing definition for relative delays based on when the FPGA outputs those signals, if you want to reference an acquisition to the start of the DAC output for example. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] DDS vs DAC for RF; parallel LVDS vs GTX
> There is no particular issue with Artix besides the already mentioned fabric > size and transceiver limitations. Note that JESD204B synchronization does not > require additional transceiver resources, so we have 4 spare ones, not 2. SFP > (for crate-to-crate fiber) and/or the backplane will typically need some - If we decide to dedicate two transceivers to SFP and backplane, that leaves two potentially open. One nice way to use these would be to add a JESD204B ADC to the same card, as proposed by Dave Leibrandt and others. This would enable the tightest loops for feedback to the DAC outputs. Candidate chips (in my rough order of preference): http://www.ti.com/product/adc16dx370 - use 2 JESD204B lanes @ 6.6 Gbps - get 2 channels of 16-bit DAC at up to 330 MSPS (using Artix-7) - latency 18.5 ADC clock cycles (56 ns at max speed) http://www.ti.com/product/ads42jb69 - use 2 JESD204B lanes @ 3.125 Gbps (limited by chip) - get 2 channels of 16-bit DAC at up to 156 MSPS - this chip has slightly better distortion/spur properties than the previous one - latency 23 ADC clock cycles (147 ns at max speed) http://www.analog.com/en/products/analog-to-digital-converters/ad-converters/ad9683.html - use 2 chips, each with one JESD204B lane @ 5 Gbps (limited by chip) - each chip: one channel of 14-bit DAC at up to 250 MSPS - chip distortion properties are almost the same as the previous 2 ADCs - would need to synchronize the two chips with SYSREF system, feed matched data clocks - latency 36 ADC clock cycles (144 ns at max speed) - this chip features a CMOS output that determines whether the signal magnitude is above or below a programmable threshold value (with a hysteretic threshold to give some noise immunity). Latency for this output is only 7 ADC clock cycles, or 28 ns at max clock speed. This would be a nice feature for people trying to perform ultra-fast feedback on a qubit measurement (e.g. sc qubit folks?). Another option would of course be to use a parallel LVDS ADC instead of a JESD204B model, and there appear to be quite a number of high performance candidates suitable for the task. Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] DDS vs DAC for RF; parallel LVDS vs GTX
> 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 roughly > balanced. Artix FPGA also has gigabit transceiver lines and so could be used for JESD204B as well. The difference is that even the highest speed grade in the Artix is limited to 6.6 Gbps transmission. It would still be possible to run 8 channels of output with 312 MHz instantaneous bandwidth using two DAC38J84 chips using 12 lanes (you send 8 lanes to one DAC and 4 lanes to the other, use 2 lanes for synchronization ). There are 16 available GTX (giving you 4 spares) on the largest Artix-7, an XC7A200T-2FFG1156C, which costs $280 apiece (as opposed to $1000 for the XC7K325T Kintex in the -1 speed grade, or $1700 for the -3 speed grade needed for the full 12.5 Gbps data rate). . The hardware could be reprogrammed to run with 6 channels of 660 MHz instantaneous bandwidth or 4 channels of 1.23 GHz instantaneous bandwidth, depending on the desires of the user. This would enable us to satisfy both the desires for ~ 1 GHz instantaneous bandwidth for SC qubit or other fast applications on the same card, and using a much less expensive FPGA. Now your card has a $500 hardware cost for FPGA and DACs instead of $2000. Sebastien, are there other issues with the Artix-7 series that would be problematic for what we want to do? The cost savings are definitely substantial. FPGA size is listed below, we would use the largest one, which is about 2/3 the size of the Kintex 7 on the KC705 board. Best, Daniel [cid:image001.png@01D12E93.2683B110] ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] <1 ns output resolution
This sort of timing performance, while potentially achievable from the FPGA itself, is definitely not achievable with the current design of the TTL output circuitry in the 0th-generation ARTIQ hardware because of the jitter of the various stages involved. If you truly have a need for this kind of exquisite timing resolution (and thus jitter performance), you would need to pay substantial attention to the design of the electronics for interfacing the FPGA with your desired signal. You would need to go full differential (using a multi-gigabit-capable LVDS buffer chip if you want to isolate the FPGA from the rest of the circuit) all the way to your peripheral of choice in order to not substantially degrade the jitter performance. The current circuitry will add several hundred ps of peak-to-peak jitter at a minimum. This is more reasonable if you are talking about a signal that stays on just one board, but again you will need to do some careful engineering. Best, Daniel From: ARTIQ on behalf of Joe Britton Sent: Saturday, November 21, 2015 11:05 PM To: artiq@lists.m-labs.hk Subject: [ARTIQ] <1 ns output resolution SB, You mentioned in the past that the Kintex7 can give higher resolution in output timing than 1 ns. Is this a difficult modification of the RTIO cores? As a reference point, SRS DG645 delay generators have 5 ps resolution and "for short delays the jitter is typically 20 ps." How well do you think a Kintex7 could do running ARTIQ assuming it's not limited by reference clock phase noise? -Joe < SB 39ps output resolution is straightforward using the ODELAY. Less than that requires a custom delay line (similar to the S6 TDC design), with which 5ps might be attainable. Jitter depends on many factors such as power supply noise and undocumented characteristics of the Xilinx silicon. > It looks to me like ODELAY can be independently configured for each HP I/O bank. How many such banks does a Kintex 7 have (eg. on the KC705)? http://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf << SB Depends on the chip. On the 325T/KC705 the HP banks are 32, 33 and 34 and they are all routed to internal board signals (mostly SDRAM). Note that each bank contains 50 independent ODELAYs. >> Does using the ODELAY resource for precision physics timing reduce the number of GTX transceivers available for data links? << SB No >> ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Fwd: multiple explorer docks vs. memos
> At the moment, the list of experiments is flat. Do you confirm that > directories > should be supported? Yes, definitely. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] fire-and-forget RPC / inter-CPU communication
> 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 efficient use of > the wide DRAM word), connect those directly to the memory controller, > have the two CPUs communicate over DRAM. This is a simple architecture, > but it requires digging into mor1kx and all the inter-CPU data has to go > through the DRAM. Also, all on-chip data caching is flushed at each inter-CPU > message. > 2) keep the current writethrough caches and wire them to a large shared > L2 cache which is then connected to the memory controller. Slightly more > complicated architecture, uses more BRAM, but no mor1kx modification > necessary (which definitely outweights the architectural complexity in terms > of initial development time), and small inter-CPU messages will fit in L2. I would vote for option 2, since I think that using a customized mor1kx sounds like both a lot of development time and makes us more vulnerable to future breakage. Do others agree? How small is a "small" inter-CPU message? I would imagine that individual fire-and-forget RPCs are not going to require the passing of much information, but it's not totally easy to quantify. One might in theory want to send back as much as an entire deep FIFO input buffer's worth of timestamps, which would be a few hundred kB, but I can't imagine something larger than that. More typical would be something like ~10 timestamps for a detection event. Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] AD9914 programming details
> 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 compatible with the current hardware architecture (many DDS cards on a backplane), because it requires a 32-bit-wide bus and this would cost us too many TTL lines on the LPC connector. If we want DDS chips with this direct modulation mode, they should be driven directly from a dedicated FPGA a few at a time. Is there anyone who needs this mode in the near term? Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] AD9914 programming details
> >> 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. > > It's still misleading. Take it up with AD. > >> Agreeing on 0.2 nHz (!) is seemingly easy. But either we abandon > >> profile mode, data modulation and phase/amplitude and frequency > ramps > >> or you need to specify at what level and how you want to switch > >> between these mutually exclusive modes. > > > > These modes do not need to be abandoned; you just can't use the ramp > > generator or the frequency changing function of profile mode if > > programmable modulus is enabled. We should be able to > > They are mutually exclusive. If you want to support both, you have to specify > how to resolve conflicts, inconsistencies, and what should happen if you > switch modes, e.g. with phase tracking. My proposal had been *not* to support the profile mode and digital ramp right now, just programmable modulus, since these other two modes will require considerable work on the compiler which programmable modulus does not. If others in addition to Joe feel that we should support these features right now, then yes we will need to figure out a protocol for resolving conflicts/inconsistencies, and this is something that would need to be thought out carefully, agreed. > > How long does it take to write 64 bits (8 write cycles) to the DDS chips? > > Is > this limited by the FPGA? The DDS itself takes minimum ~ 10 ns per write > cycle, so changing frequency would require ~ 100 ns in programmable > modulus mode from DDS limits alone. > > That is a simplistic. You are assuming that frequency writes are optimized. > Currently it would be closer to 0.5 µs. My sentence states "from DDS limits alone", implying a lower bound assuming the FPGA is infinitely fast (which is obviously not a good assumption, thus my question). My question was in fact "how long does it take to write 8 write cycles to the DDS chips? Is this limited by the FPGA?". It appears your answers are "approx. 500 ns" and "yes". > https://github.com/m-labs/artiq/blob/master/soc/runtime/dds.c > The rationale is in the IRC logs. Ack. > > From a hardware perspective, the DDS registers can be programmed ahead > of time and then the actual change of output freq/phase/amplitude occurs > when the IO_UPDATE (aka FUD) command is sent. So if multiple DDS chips > need to be updated to new output parameters at the same time, one would > program them one at a time over the DDS parallel bus, then send them all a > common IO_UPDATE signal at the appropriate time for the update to > happen. The system would thus need a way of recognizing this condition (or > similar conditions) and allowing enough lead time for DDS programming so > that they can all be programmed before the IO_UPDATE needs to go out. > > Dito This can just be refactoring the FUD into dds_fud() from dds_set_one() so it can be called independently. It would then either need an array of ints to specify which channels to update, or perhaps better use a long long int as a bitmask for channels to be updated (as long as there are fewer than 64; I doubt we'd ever have more than 64 DDS chips hanging off a single FPGA from simple wire count considerations). Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] AD9914 programming details
> > On the QC1 hardware, there is no possibility to send a common FUD. > > When programming several DDSes in a batch, the core device will issue > > tight > > programming+FUD sequences and compensate each POW for the > dispersion > > programming+in FUD > > times. > > As I mentioned in an older email that can be improved by moving all the FUDs > to the end of the batch. Agreed. With the hardware we are putting together for the KC705 (FMC backplanes etc), it will be possible to send simultaneous IO_UPDATE to multiple DDS chips, so we should plan for this. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] AD9914 programming details
> 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 and phase/amplitude and frequency ramps or you > need to specify at what level and how you want to switch between these > mutually exclusive modes. These modes do not need to be abandoned; you just can't use the ramp generator or the frequency changing function of profile mode if programmable modulus is enabled. We should be able to > Also people have to determine whether the programming pattern that we > implemented is fast enough (and will be with the additional 4 writes of the > numerator) or in need of optimization. How long does it take to write 64 bits (8 write cycles) to the DDS chips? Is this limited by the FPGA? The DDS itself takes minimum ~ 10 ns per write cycle, so changing frequency would require ~ 100 ns in programmable modulus mode from DDS limits alone. Some questions for Sebastien: How does the current DDS programming firmware work? Does the SoC need to do any processing, or is it just fetching precomputed register values (done at compile time) and pushing them to an output FIFO? If a DDS is programmed to change frequency, say, at a particular time, how is it determined when the register programming commands are output to the DDS bus? How does the system handle it if more than one DDS chip is supposed to change frequency/phase/amplitude at the same time? >From a hardware perspective, the DDS registers can be programmed ahead of time >and then the actual change of output freq/phase/amplitude occurs when the >IO_UPDATE (aka FUD) command is sent. So if multiple DDS chips need to be >updated to new output parameters at the same time, one would program them one >at a time over the DDS parallel bus, then send them all a common IO_UPDATE >signal at the appropriate time for the update to happen. The system would >thus need a way of recognizing this condition (or similar conditions) and >allowing enough lead time for DDS programming so that they can all be >programmed before the IO_UPDATE needs to go out. Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] AD9914 programming details
The brief summary: The new DDS chips (AD9914) normally operate with a 32-bit FTW, which gives them 0.8 Hz resolution in frequency with a 3.5 GHz clock. The chip is capable of operating in a special mode called "programmable modulus mode", which allows considerably finer resolution and also allows for the possibility of exact frequency synthesis (see pp.17-18 of the datasheet for details). What I am proposing below is that: 1) people in the group do want frequency resolution finer than 0.8 Hz for some applications, so we should enable the programmable modulus mode. 2) we can have ARTIQ use this mode in a very simple way that doesn't allow for exact frequency synthesis but just increases the effective FTW to 63 bits, which gives ~400 pHz (picohertz) frequency resolution. I am imagining that this level of frequency error is acceptable to everyone, right? > -Original Message- > From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Sebastien > Bourdeauducq > Sent: Monday, May 18, 2015 10:28 PM > To: artiq@lists.m-labs.hk > Subject: [ARTIQ] AD9914 programming details > > Taking this to the list. > > > Forwarded Message > Subject: RE: [ARTIQ] Today's slides > Date: Mon, 18 May 2015 20:53:39 + > From: Slichter, Daniel H. > To: Jordens, Robert , Sébastien Bourdeauducq > , Britton, Joe > > > >> 1. Programmable modulus mode. The appropriate modulus should be > > >> calculated by the master in the compilation stage, as it may be > > >> computationally expensive to do so on the SoC. For most > > >> applications, exact frequency synthesis may not be necessary and > > >> simply using programmable modulus simplistically to add effective > > >> bits to the FTW (e.g. setting B=2^31 and varying A for fine > > >> frequency tuning, see AD9914 data sheet) may be sufficient and > > >> simpler to implement. > > I think this simplistic mode of operation, which gives additional effective > bits > in the FTW but does not try for exact frequency synthesis, should meet 99% > of the needs of typical users. I would advocate going ahead and > implementing this simple B=2^31 solution for now. We would need to > determine how exactly to expose the functionality to the user. One option > would be to have a mode for the DDS, like the phase mode, which might be > called "resolution". So then we would have a method set_resolution(self, > resolution), with two options, STANDARD_RESOLUTION and > FINE_RESOLUTION. The first option would just use the usual 32-bit FTW > (profile mode with profile 0), and the second would use programmable > modulus mode, setting B=2^31 to give you an effective 63-bit FTW. If you > leave profile mode enabled, then the amplitude and phase settings for the > current profile determine amplitude and phase of the output, while the > programmable modulus determines frequency. > > If we are not implementing profile mode or digital ramps right now, this > should be a very straightforward addition to make. I think that most users in > our group are interested in the AD9914 at least in part because of the option > of an increased-resolution FTW, so I think we really should have at least this > basic capability enabled. > > > > ___ > ARTIQ mailing list > https://ssl.serverraum.org/lists/listinfo/artiq ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] handling device disconnections and controller freezes
> >>> * 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 calibration/license > > stuff loaded over the network where repeated attempts will just make > > things worse. Several of the device controllers might be racing for > > the same resource. You can also fill up your process table over a > > weekend if each attempt ends up leaving a zombie process. > > As far as I can tell, none of the currently planned controllers would > misbehave in such ways. One fairly easy-to-imagine possibility is people wanting to call Matlab from ARTIQ for some of their data processing, using the Matlab Engine for Python. In this instance, one would have to wait for Matlab network licenses to be available, and pinging the license server at too high a rate may elicit unhappy responses from the people who manage the licenses. There some sort of backoff would probably be nice. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] [ionstorage] hardware design proposal for ARTIQ DDS/TTL system
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 will be around for many years. If that is the case, then it would > be disappointing if it ends up (again) being an ad-hoc mechanical design with > boards mounted in random places in a box, lots of flying wires, rf-splitters, > and flimsily mounted daughterboards that can not be accessed when > mounted and not exchanged without opening the custom box. I don't think > that should be considered "good enough". You are correct that this falls a bit in a no-man's-land between "do nothing" and "make it really robust and nice". The "do nothing" approach, essentially just using the clock team's backplane, would work fine for everything except the DDS syncing using the FPGA. The motivation for this design was to try to enable the FPGA-based DDS syncing, since this appears to be a feature that people want to have. Since this requires a high-bandwidth-capable connector to the DDS boards (or in any event something better than a pin header) because of rise time/jitter issues, the thought was to go to a new connector, and once you are there changing up the buses is not a great deal of additional work. However, I don't have the time to design a nice solution, something like a rack-mounted chassis with slots for DDS cards, and there is also then the issue of getting signals from the FPGA card to the chassis. We had a lot of discussions about this several months ago, and it was decided that having a DDS/TTL backplane directly on the FMC connector in the same crate as the KC705 was the best solution for now -- people didn't like the idea of giant SCSI cables as we currently have, and the high-speed serial interconnection option was deemed to have too many questions about latency, signal integrity, etc for a first-generation design (although likely this is where we want to head in the future). This leaves us with an FMC backplane solution, with DDS cards plugging directly in, ugly though that may be in some ways. We need to add in some solution for DDS syncing, so engineering of some sort will have to be done. One option would be to use the existing clock backplane and just add an external board with SMA cables for the syncing stuff. Another would be to include the DDS syncing stuff on the backplane and then use an additional high-speed connector (e.g. SATA with short cables, or SMP coax) to carry the sync signals to and from the DDS cards. Another alternative is to just make an FMC-SCSI adapter card (similar in functionality to the daughtercard on the current HFGUI FPGAs) and use ribbon cables to connect to our existing DDS/TTL boxes. This was proposed initially, and it was voted down. Joe is now suggesting we do this so we have the ability to use our existing hardware while people migrate; I think it can be made to happen in time for Sebastien's visit > > - The interface between the FPGA and the TTL riser card is > > designed in such a way that one can very easily replace the current > > TTL riser card with a card that accepts up to 14 differential pairs > > for high-speed serial signaling from the FPGA, with no modifications > > to the FMC backplane. A replacement card could be designed to allow > > these lines to talk to remote DDS/TTL outputs, or to other boards in a > > rack employing a distributed RTIO system, both of which are proposed > > next-generation hardware ideas for ARTIQ. This “future-proofs” the > > design to some extent. > > To what extent? I would probably use the GTX transciever(s) for that even if > they are a bit of a grey box. I was planning to route the GTX transmitter and receiver to this connector as well. In any event, if you don't think this is worthwhile I don't have to bother, but it's basically for free to have the lines run as differential pairs. Probably not much crosstalk effect since they already run this way for a much longer distance on the KC705 board. > > All the signals save two are sent through the FMC connector as > > single-ended LVCMOS, which allows us to get more signals through. > > Hmm. I don't have a good feeling for how much the coupling of the pairs on > the board and in the connectors will cause problems here. I don't either, except to say that the clock team are using this method on their backplane and so far I haven't heard complaints? The outputs of the FPGA can be configured for fast or slow rise times, and if crosstalk is an issue we can go to the slower rise time to reduce crosstalk. Otherwise there doesn't appear to be much one can do about this other than a) using LVDS and accepting many fewer signal lines or b) using LVDS with the OSERDES and then deserializing on the backplane, which sounds
Re: [ARTIQ] artiq dependencies
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 mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] hardware design proposal for ARTIQ DDS/TTL system
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 > syncing. Again, we do not care about the relative phase of the signals at the output of the DDS chips when things are synced up; we ONLY care that this relative phase is the same every time we do the syncing. If there is a part-to-part skew in the time between the internal SYNC_CLK and the SYNC_CLK signal at the pin, this will just show up as a repeatable, constant phase offset between channels, which is the same after each syncing routine. This is not a problem. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] hardware design proposal for ARTIQ DDS/TTL system
> I suggest: > * using 3.3V everywhere so that the FMC card is compatible with other FPGA > boards that use a different distribution of the FPGA banks to the FMC > connector. Having two different IO voltages on LAxx violates rule > 6.1 of the FMC standard and may work only on the KC705. Switching > everything to 2.5V does not seem to be an option as the MLVDS transceivers > are 3.3V (and I assume you put some effort already into trying to find 2.5V > ones). This is a good point, thanks for pointing this out. The question remains as to whether we are better off going to 2.5V everywhere, and using 2.5V-3.3V LVCMOS level translators on all the DDS control/readback lines as well. These will add jitter and skew between the parallel signals, but with the part I've proposed I think the added jitter should be sufficiently small that it doesn't affect our parallel bus too badly. The tradeoff here would be that we can maintain the option of using high-speed differential signaling to the TTL riser card connector in case we want to try something new there. At this point, if we want to be FMC-compliant we are probably better off just sticking with 3.3 V and saying that if we want to add a high-speed serial capability, we'll use the HB bank on the HPC connector and just expand the current board design a bit. In addition, if we are going to be FMC-compliant we cannot use the CLK0_M2C and CLK1_M2C pins for I/O (which I had been planning on for now) - and they cannot be used as clocks either because the clocks are all required by the standard to use LVDS, which is not compatible with 3.3V banks - so we have lost 4 pins that way, we gain 2 back by going single-ended instead of LVDS, and then we cut 2 digital I/O "TTL" channels. > * not using LVDS at the FPGA for LATCH_CLK and SYNC_IN. This will increase > jitter, but we'll have to deal with it anyway since LATCH_CLK triggers > sampling > of a single-ended signal and SYNC_IN is converted to single-ended. This > solves the IO voltage compatibility problem and frees an FMC pin for... This one obviously flows from the previous point - if we go with 3.3V LVCMOS then LVDS is not an option anyway. > * ...adding a flip-flop that samples the analog output of the DDS, for > automated self-test purposes and possibly synchronization in case SYNC_CLK > is not good enough. With this design, the amount of analog jitter is going to be pretty nasty, and we'll need to have it pegged to less than one SYSCLK period (~300 ps) if we want to use this for syncing. If we really care about this kind of diagnostic being automated in the FPGA (I am not totally convinced), I would propose using a low-phase-noise sine-to-square-wave converter like the LTC-6957 that we are already using to generate the reference clock for the RTIO core (http://www.linear.com/product/LTC6957-1). These devices have ultra-low-phase-noise limiting preamplifiers on the input stage to increase the slew rate of the sine wave signal and reduce the jitter that would be associated with thresholding a regular sine wave signal. Then the output of this could be sampled with a fast latch clocked by SYNC_CLK_LATCH_CLK (mux'ed through an LVPECL crosspoint switch like http://www.ti.com/product/sn65lvcp23) and returned with a slow bus in the same way that the SYNC_CLK sampling currently happens. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> > If we are OK with losing the back-compatibility with previous designs, we > can think about using high-speed connectors e.g. SAMTEC QRM8, which are > designed for this sort of thing. How about this solution: we use an inexpensive high-speed board-edge connector (Samtec HSEC8-DV: http://www.samtec.com/technical-specifications/default.aspx?SeriesMaster=HSEC8-DV). The new DDS boards would then have gold fingers on the edges and just plug in, much in the same way one plugs in a RAM DIMM module in a computer, potentially with board locks as is used for DIMMs. This connector should have plenty of bandwidth for the rise times we are discussing (spec'ed to 10.5 GHz for differential signals). We get a connector with 74 or 80 pins, which is enough to send in all the signals we would want plus some to spare. Then, we can make a simple, very short adapter board with a 2mm pin header on one side and fingers on the other side, wired such that we could plug any legacy DDS cards with 2mm connectors into the new FMC backplane via the adapter board. This board would be very inexpensive to build dozens or hundreds of, and the 2mm pin header could be stuffed by hand as needed. Obviously any legacy DDS cards would not be able to take advantage of the new features, e.g. syncing, that we are planning, but this adapter board would enable them to be used if desired for some reason. Thus we solve the back-compatibility problem as well as the connector speed/edge time problem. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> Well, synchronizing them to one SYSCLK provides an elegant solution to this > problem and that of meeting setup times on all chips, at the cost of having > another skew-matched layout for the distribution buffer to flip-flop lines. As > I believe you can add more layers to the backplane in the worst case, the > difficulty sounds reasonable. If the SYSCLK-perfect approach fails for some > reason (such as part-to-part skew on SYNCLK within the DDS chips), we can > fall back on the "fixed phase difference" solution. Agreed. > Other advantages of the SYSCLK-perfect synchronization is that the DDS > hardware becomes fully interchangeable without phase differences from > one box to the next, and testing that the sychronization actually works can > be done with a straightforward observation of the SYNCLKs or the outputs on > a multi-channel fast scope. I would argue that the phase differences should be interchangeable box to box anyway, but agree it's cleaner to look at if everything is just synchronized. > Actually, it might be better to connect the analog output of the DDS to a > flip- > flop instead of or in addition to SYNCLK. This way, the above-mentioned part- > to-part skew on SYNCLK within the DDS chips is out of the equation (and it > should be negligible for the setup times), and we can re-use the flip-flop for > unit tests of driver functionality such as different phase modes. The main > problem is that the system will need to output waveforms during > synchronization. You mean to use essentially as a thresholding phase detector? In other words, directly measuring the phase of the output signal instead of the phase of the SYNC_CLK? The issue here is that getting the phase by thresholding an analog signal is going to introduce uncertainty/jitter that is not present if you are just looking at a digital phase with >=300 ps increments. We could potentially implement this, but I would do it in addition to, and not instead of, the SYNC_CLK flip-flop. > On 01/08/2015 08:07 AM, Slichter, Daniel H. wrote: > > Originally the motivation for using this FMC backplane/DDS riser > > scheme was that it required minimal modification of an existing > > design. Now that we are trying to do the DDS synchronization using > > the FPGA and traces on the backplane as well, it's getting a bit more > > involved. However, I don't think the level of complexity approaches > > what might be necessary if we move to a COTS crate architecture like > > MicroTCA for the DDS's, where it would probably be necessary to have a > > distributed RTIO core and an FPGA on each card to handle > > communications, which run over gigabit Ethernet or PCIe in those > > standards. > > Yes, connecting a rack to the KC705 would be complicated, mechanically and > electrically. It seems to me that the task of interfacing the FMC to an existing commercial backplane is at least as hard as the task of making a reliable backplane ourselves, where by "ourselves" I mean "with the help of a high-speed circuit board engineer". Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> > 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 really on the signalling standard). LVCMOS does not help with signal integrity; what I had meant to express with my statement is that if you are just using LVCMOS (and its correspondingly slow-ish rise times relative to fast differential standards like LVPECL/LVDS) then the question of the connector to the DDS cards is not as crucial, and you can perhaps get away with the existing 2mm pin header. > > the current design calls for the use of 2mm pin headers, back compatible > with the existing DDS boards, which are not going to give us the best > performance. > > > > If we are OK with losing the back-compatibility with previous designs, we > can think about using high-speed connectors e.g. SAMTEC QRM8, which are > designed for this sort of thing. > > If plain pin headers can not do the required < 300 ps edges (for the > AD9915 SYNC_IN/OUT scheme or for reliable SYNC_CLK detection) the > question has a simple answer. And if new bus connectors are required, this is > the time to choose a COTS rack/bus system and not invent another. So are you suggesting we should move to something like XMC or MicroTCA for the DDS cards? We should perhaps have a group discussion about these various topics. I know that Joe has also been pushing to put our hardware in some sort of nice commercial rack-able format too. Originally the motivation for using this FMC backplane/DDS riser scheme was that it required minimal modification of an existing design. Now that we are trying to do the DDS synchronization using the FPGA and traces on the backplane as well, it's getting a bit more involved. However, I don't think the level of complexity approaches what might be necessary if we move to a COTS crate architecture like MicroTCA for the DDS's, where it would probably be necessary to have a distributed RTIO core and an FPGA on each card to handle communications, which run over gigabit Ethernet or PCIe in those standards. For my money, this would be an entirely new project at yet another level of complexity. It's great for scaling up, and I agree it is better if one is thinking in a truly "big picture" way, but the up-front cost is substantial and I think the value for our 5-year experimental horizon relative to a one-off solution like changing connectors on the existing FMC backplane design is not par ticularly high. Given the level of complexity for re-routing the board at this point, and the amount of time it would take for me to do all the work, I have been thinking I would send the backplane (and potentially the DDS cards as well) out to an external PCB design/layout guy to do the grunt work. This would also make it go faster, I think, once we have settled on a design we like. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> 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 phase relationship
between the DDS chips must be set to the same value every time we run the sync
algorithm. The signals coming out of the DDS chips are going to be propagating
down cables of various lengths, driving AOMs where the propagation time of the
acoustic wave is different, etc. All of these effects after the DDS chip will
need to be calibrated when the experiment is set up, and will need to be
recalibrated each time the cabling is changed. What we require from the DDS
syncing process is only that the relative phase of each DDS SYNC_CLK be set to
the same value each time, so we only have to do all the
line/propagation/experiment/etc calibrations once. Then, if you for example
command all DDS chips to start from zero phase with a shared IO_UPDATE at the
beginning of your experiment, you will always have the same phase relationship
between your signals at the point where they matter in the experiment (even
though they
will most likely NOT be exactly phase aligned at the AOM/ion trap
chip/wherever they are going, they will have a precisely defined relative phase
always).
> The phase of that distant DDS will also be off by roughly the propagation
> delay.
See above; this is not an issue because we don't really care about the absolute
phase difference between DDS chips at the plane of the DDS outputs, just that
this phase difference is fixed and returned to the same value by the SYNC
process.
> With FPGA-based syncing, the SYNC_INs do not need to be matched. If the
> signal integrity is good, even a shared bus ("fly-by" like DDR3) would work.
> The only lines that need to be tightly matched are those from the clock
> buffer to the flip-flops.
Agreed, this is the advantage of the FPGA-based syncing method, and with the
latches only the latch clock needs to be well matched. However, given the
discussion above about absolute phase, even *that* does not need to be
perfectly matched, since we are not requiring in-phase SYNC_CLK over all chips,
merely deterministic/repeatable SYNC_CLK meeting the IO_UPDATE setup times.
> > For the readback, one multiplexer is here
> > (http://www.idt.com/products/clocks-timing/clock-distribution-ics/fano
> > ut-buffers-clock-dividers-and-multiplexers/853s012i-121-differential-3
> > 3v25v-lvpecl-clockdata-multiplexer),
> > although there would need to be an LVPECL-to-LVCMOS translator stage
> > afterwards as well.
>
> Timing at the flip flop outputs is not critical. A single LVPECL-to-LVCMOS
> translator on each DDS board driving a shared bus through a tri-state buffer
> would work.
Yes.
> > So now the system would have the following components on the FMC
> > backplane and DDS cards:
> >
> > * SYNC_IN 1:12 clock distribution with lines to each DDS, driven by
> > FPGA with variable ODELAY
>
> Can be replaced with the FPGA directly a shared bus, though this obviously
> removes the possibility of falling back to the ADI-recommended
> synchronization circuit without a backplane respin.
I would rather leave the ability to do hardware-based synchronization if
possible.
Daniel
___
ARTIQ mailing list
https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> What connector do you want to use to get these fast-edge signals from the > backplane to the dds cards and back? This is part of why I have been proposing LVCMOS signals instead of trying for crazy bandwidths with differential signaling - the current design calls for the use of 2mm pin headers, back compatible with the existing DDS boards, which are not going to give us the best performance. By opting for surface mount instead of through-hole, we reduce the pin capacitance somewhat, but it's still not ideal. If we are OK with losing the back-compatibility with previous designs, we can think about using high-speed connectors e.g. SAMTEC QRM8, which are designed for this sort of thing. The price and footprint of these connectors is similar to the current 2 mm pin headers, but we would lose the interoperability of old-style DDS cards. This is something we might discuss at group meeting. In general, we are probably better off going to real high-speed connectors, but it should be debated. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> On 01/06/2015 03:26 PM, Sébastien Bourdeauducq wrote: > > Or sample SYNC_CLK with a discrete flip-flop or latch near each DDS > > chip and trigger them with a skew-matched on-board clocking network > > pulsed by the FPGA through a scanned ODELAY. Then low-performance > > multiplexers, shared buses and skew are acceptable at the flip-flop > outputs. > > http://www.onsemi.com/pub/Collateral/NB4L52-D.PDF has 150ps of setup + > hold time, so the part-to-part variation in input characteristics should not > be > significant. And it takes LVCMOS and even contains a comparator. This would work, but then one has the task of distributing a skew-matched on-board clock in addition to the SYNC_IN which is already being distributed. There is the advantage that this would make the SYNC_CLKs aligned at the DDS chips automatically (to within the skew matching of the clocking network). Something like http://www.ti.com/product/cdclvp1216 would provide a suitable clock distribution solution. For the readback, one multiplexer is here (http://www.idt.com/products/clocks-timing/clock-distribution-ics/fanout-buffers-clock-dividers-and-multiplexers/853s012i-121-differential-33v25v-lvpecl-clockdata-multiplexer), although there would need to be an LVPECL-to-LVCMOS translator stage afterwards as well. So now the system would have the following components on the FMC backplane and DDS cards: * SYNC_IN 1:12 clock distribution with lines to each DDS, driven by FPGA with variable ODELAY * SYNC_CLK LVCMOS-to-LVPECL latch on each DDS card * SYNC_CLK latch clock 1:12 distribution, with matched skew lines to each DDS, driven by FPGA with variable ODELAY * SYNC_CLK 12:1 multiplexer with LVPECL-to-LVCMOS translation to FPGA input (these do no need to be fast because of the fast latch on the DDS cards) It might be a challenge to get all this on the circuit board! ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> 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 that the > LTC6957 PCB will be very small (so it can be reasonably designed not to bump > into parts of the KC705 or the FMC cards) and has no other connectors on the > back. Sounds good, although for mechanical compatibility it might be better to use two extremely short (<1") SMA cables, since the axial misalignment tolerances on SMA are not very forgiving. We can test it out and see how it goes. > > The 3.3V LVCMOS DDS sync signal would be sent to a TI CDCLVC1112 1:12 > > LVCMOS clock fanout (http://www.ti.com/product/cdclvc1112) located > > very close to the FMC connector, which would then fan out the sync > > signal with one output channel dedicated to each DDS's SYNC_IN pin via > > an analog switch. This way the sync signal is always point-to-point > > (nothing shared on a bus), so loading (and corresponding slow > > rise/fall times) should not be an issue for the FPGA output. The > > additive jitter of this part is extremely low (~100 > > fs) so we will be limited by jitter due to the rise times from the > > FPGA. > > That CDCLVC1112 also has slow rise times, but it seems that it's unavoidable > with LVCMOS. An AND gate instead of the analog switch would also work. > Skew does not matter for SYNC_IN, as the FPGA will scan its timing until it > receives an aligned SYNC_CLK. Skew does matter, however, for SYNC_CLK. 3.3V LVCMOS just always has a slower rise time -- this is a consequence of the much higher voltages involved. So for a given slew rate that a driver can produce, you'll get a faster rise time for something like LVDS (where the swing is hundreds of mV) than for something that needs to swing by several volts. And this is (one of) the reasons people don't use 3.3 LVCMOS for high-speed signaling :) > > As to the question of returning the SYNC_CLK signal to the FPGA, I had > > been talking about using an analog switch to pass the SYNC_CLK to the > > FPGA using a shared bus (with a chip-select pin to determine the state > > of the switch). > > All SYNC_CLKs need to be matched (ideally to less than a SYSCLK cycle) so > that the FPGA can properly detect when they are aligned, and a shared bus > will not achieve that. This is not necessarily required, I had thought. What we need is to repeatably set the phase relationships of all the different SYNC_CLKs to within less than a SYSCLK cycle, and we need the SYNC_CLK phases to be such that we can meet the IO_UPDATE setup and hold time criteria for all DDS boards at the same time, but this does not necessarily imply that the SYNC_CLKs are aligned either at the FPGA or at the DDS cards themselves. In fact, one might consider the situation were you want the SYNC_CLK of a more distant DDS to lag behind that of a nearer DDS, which would give more headroom for the IO_UPDATE setup time by accounting for the propagation delay of the IO_UPDATE pulse down the shared bus. Are there limitations on the IDELAY/ODELAY range that make this problematic? My vision for a synchronization had been as follows: 1) Enable the sync feature on one DDS and turn on the analog switch on SYNC_IN. 2) Send a SYNC_IN pulse from the FPGA to the clock fanout, which is then received by the DDS with the enabled syncing (others do not receive it due to analog switch on their cards being off). 3) Sweep the ODELAY from the FPGA while monitoring the phase of the returned SYNC_CLK from that DDS, stopping when the SYNC_CLK is stable with the correct phase. 4) Disable the sync feature on the DDS. 5) Repeat for all other DDS chips. The "correct phase" in 3) can be established in one of several ways: a) use a readback loop in hardware to connect the FPGA to the DDS board and back again, measure round-trip time, divide by two to estimate propagation delay, and use this to figure out the desired phase relationship. b) set up a system where you can look at the SYNC_CLK pulses over matched-length coax cables using a fast oscilloscope. Run the FPGA ODELAY syncing sequence until these are aligned as desired, then figure out the phase relationship of the SYNC_CLK signals at the FPGA and have it remember this phase relationship for all future syncing. The board-to-board variations in propagation times should be low enough that this would work if we measured it once and then used those values for all FMC daughter cards. Once the SYNC_CLK is fixed, we just would need to check periodically (before and after each experiment, for example) to make sure that the phases of each SYNC_CLK are where we want them to be. > What about using a multiplexer with matched trace lengths to each DDS? > It seems a bit difficult however to find a multiplexer that has at the
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> >> 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 the > > USER_CLK_P SMA connector, this can be accomplished with a different > > variant of the same LTC6957 chip, again with very low jitter. > > That would be unterminated (on-die 50 ohm termination is only supported > for VCCO <= 1.8V) so there can be signal integrity issues at long cable > lengths. > > What about adding to the FMC backplane a connector that is properly > designed for high speed differential signaling, e.g. SATA? The impedance is > the same as LVDS so standard SATA cables can be used. Then add a > LVCMOS33 translator; the only unmatched length becomes the traces > between the translator and the FPGA which are shorter than typical cables > and do not depend on a particular lab setup. Is there an on-die 100-ohm differential termination for LVDS signals at VCCO = 2.5V? Either way, it's actually a physically shorter distance from the SMA connector to the FPGA (~5 cm) than from the FMC connector to the FPGA, so if we have to use LVCMOS to drive the clock we're still better using the SMA connector, if we ensure that the LTC6957 chip is attached directly to the board (no long cables). In addition, at these frequencies I would imagine we could get away with an LVDS signal that is differential on the clock driver board, goes to two extremely short SMA cables to the SMA connectors on the KC705, and then comes back (the traces on the KC705 are 100 ohm differential from the FPGA until right next to the SMA connectors). > > However, even if we send the DDS sync signals over LVDS they will > > still need to be converted to 3.3V LVCMOS at some point, and then I > > think we are right back where we started in terms of rise times and > > resulting jitter. > > My experience with Spartan-6 is that it doesn't like signals lingering between > the logic high and logic low thresholds, What do you mean by signals "lingering" in this particular instance? Slow rise/fall times? The 3.3V LVCMOS DDS sync signal would be sent to a TI CDCLVC1112 1:12 LVCMOS clock fanout (http://www.ti.com/product/cdclvc1112) located very close to the FMC connector, which would then fan out the sync signal with one output channel dedicated to each DDS's SYNC_IN pin via an analog switch. This way the sync signal is always point-to-point (nothing shared on a bus), so loading (and corresponding slow rise/fall times) should not be an issue for the FPGA output. The additive jitter of this part is extremely low (~100 fs) so we will be limited by jitter due to the rise times from the FPGA. I could change over to point-to-point LVDS for the SYNC_IN signal (using e.g. a TI CDCLVD1212 http://www.ti.com/product/cdclvd1212), but then the SYNC_IN signal ends up with the additive jitter from an LVDS-LVCMOS translator required on the DDS boards. One can use an LVDS-LVCMOS clock distribution chip like the TI LMK00804B (http://www.ti.com/product/lmk00804b), which has very low jitter, but the part-to-part skew is ~700 ps so now you are just adding that much more overall variation between the SYNC_CLK phases of different DDS chips, which makes it harder to meet the IO_UPDATE setup times for all chips. As to the question of returning the SYNC_CLK signal to the FPGA, I had been talking about using an analog switch to pass the SYNC_CLK to the FPGA using a shared bus (with a chip-select pin to determine the state of the switch). The drivers on the AD9914 are not very high-current, though, so the bus capacitance might be too much of a load. If that is the case, a more robust solution would be to have a multipoint LVDS bus, with LVDS drivers on each DDS board and an LVDS-LVCMOS receiver chip right near the FMC connector with appropriate series output resistance. Here one encounters the issue of part-to-part skew, as you discuss (see below). > What's the plan for acceptable signal integrity on the long traces that go > across the backplane? Traces on the backplane from the LVCMOS clock fanout buffer will be 50 ohm microstrip, and there will be series resistors at the fanout buffer to match the output impedance. I am leaving the exact termination circuit at the DDS SYNC_IN pins unspecified, putting in unstuffed pads so we can play with different resistors -- based on my tests here we may need to terminate with something a bit more than 50 ohms to ensure we meet the input voltage requirements. We might also try terminating to VDD/2, so I'll make pads for that as well. If we go for LVDS for the SYNC_IN and SYNC_CLK, these will be 100 ohm differential pairs terminated at both ends. For the DDS data buses, read/write pins, etc, no special trace impedance control is planned (wire
Re: [ARTIQ] technical details for clocking and syncing with FMC/DDS system
> On 01/01/2015 01:21 AM, Slichter, Daniel H. wrote: > > For the RTIO clocking, I'm currently planning to put a 2.5V LVDS clock > > on the USER_CLK_P/USER_CLK_N SMA connectors directly on the > > KC705 board (goes to an MRCC pair in I/O Bank 15, pins L25 and K25). > > I'm not very 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 the USER_CLK_P SMA connector, this can be accomplished with a different variant of the same LTC6957 chip, again with very low jitter. Our only constraint is that we need to use VCCO=2.5 V because Bank 15 is used to interface with other chips on the KC705 which constrain us. > What about those: > http://www.digikey.com/product-detail/en/HMC363S8GE/1127-1028-1- > ND/3452169 > > I haven't checked the jitter performance (including long-term skew > drift) and the datasheet I found is lacking, but at first glance this > $21 chip can divide by 8 from DC to 12GHz. Then the FPGA can divide by > another 3 to reach 24. There are evaluation boards available for ~$300. I looked at these Hittite chips previously and they are definitely a possibility if people would like to use them. The phase noise performance may not be quite as good as the Wenzel parts we are planning to use but it may not matter in the end at that level for our purposes. In any event, with the current plan each experiment is free to choose the method by which they generate the RTIO clock and the DDS SYSCLK (and the frequencies used for each), and all they need to do is provide a sine wave at each frequency with sufficient power. I don't think it makes sense to try to integrate this into the FMC backplane since then it locks people in more. > > The edge timing at the SYNC_IN pin is probably the main limitation > > there. > > Edge timing with the ODELAY is very precise, but it can be drowned in jitter. > Gaussian jitter would "just" make the process more random. I think this should hopefully not present too much of an issue, again we just resync until it works. Above 3 GHz all bets are off for deterministic syncing anyway... > > For the DDS clocking, Raghu has done some experiments to see how long > > the DDS SYNC_CLKs maintain synchronization if they are not constantly > > receiving synchronization pulses (both at 2.5 GHz and 3 GHz SYSCLK), > > and it seems they have a tendency to lose lock with each other at > > around 1, 2, or 3 hours after synchronization. > > That's suspicious. I would expect the DDS divider to operate synchronously to > SYSCLK, and so SYNCLK should not significantly drift once locked unless the > DDS chips miss clock transitions or register spurious ones. If that's the > case, > the problem would adversely affect phase coherence as well. > > What does ADI tech support say about this? How large/fast was the drift? > Was it continuous, or did it happen in discrete steps of e.g. one SYSCLK > period? Was the chip operating well within specs - good power supply > voltages, no ground bounce, good SYSCLK signal integrity? There is no drift to speak of (at least, not that is meaningful given our measurement setup); the loss of lock occurs as a discrete jump, usually of 2 SYSCLK cycles (in either direction). I haven't talked to Analog Devices about this, but they might be able to shed some light on it. As far as I know, everything is operating well within spec, and we are using two demo boards from AD so there shouldn't be issues with our board design at fault here. Agreed that this affects phase coherence, thus my suggestion of a feature to check the SYNC_CLK phase before and after an experiment and raise a flag if it has shifted by more than half a SYSCLK period (to allow for some inevitable jitter in the SYNC_CLK signal to the FPGA). > A 300ps rise time is large when syncing at 3.5GHz, and differential signaling > does sound like a better option. (Unfortunately, HP banks are not available > on the FMC...) Correct, but this is the rise time that is available from the DDS chips themselves on their SYNC_OUT for example. In general it's going to be hard to get a rise time that is much faster out of 3.3V LVCMOS, which is what we need to interface with the SYNC_IN pin of the DDS chips. > I think that level translators on the data bus should be fine, especially as > the > register readback performance does not matter. In regular operation (as > opposed to debugging DDS communication issues), we are only writing to the > DDS chips and data lines are driven by the FPGA all the time. > > TMDS (which is supported at
[ARTIQ] technical details for clocking and syncing with FMC/DDS system
Hi Sebastien (cc'ing ARTIQ list for commentary/archival purposes), For the RTIO clocking, I'm currently planning to put a 2.5V LVDS clock on the USER_CLK_P/USER_CLK_N SMA connectors directly on the KC705 board (goes to an MRCC pair in I/O Bank 15, pins L25 and K25). This will come from an LTC6957-2 clock generation chip on a separate small board, which takes a reference sine wave and converts it to LVDS with very low added phase noise. We will use a phase-locked oscillator (PLO) referenced to the 10 MHz maser signal to generate the RTIO clock, and then an ultra-low-phase-noise multiplier will multiply this frequency by 24 to generate the DDS SYSCLK. In this way we can ensure that the DDS SYSCLK/SYNC_CLK and the RTIO clock are always reliably phase-locked to each other. Another option would be to use a PLO at the DDS SYSCLK frequency and then employ a 24x divider, which would give better phase noise performance at the RTIO clock frequency, but a) I don't think the PLO is the limit on the RTIO clock phase noise, and b) the divider system is more e xpensive and would require purchase orders. For the Magtrap experiment, we will clock the RTIO core at 100 MHz and the DDS chips at 2.4 GHz -- this is optimal in terms of where the DDS spurs are located with respect to the Mg+ transition frequencies. For other experiments, people may use higher frequencies. Above 3 GHz we haven't been able to get the DDS clocks to sync reliably, though. This may work better with the FPGA-based syncing because even if the process is a bit random, you can just send individual SYNC pulses until the SYNC_CLK phase is as desired and then stop. The edge timing at the SYNC_IN pin is probably the main limitation there. For the DDS clocking, Raghu has done some experiments to see how long the DDS SYNC_CLKs maintain synchronization if they are not constantly receiving synchronization pulses (both at 2.5 GHz and 3 GHz SYSCLK), and it seems they have a tendency to lose lock with each other at around 1, 2, or 3 hours after synchronization. This is not a big deal necessarily, but it does mean that if we use the FPGA-based synchronization it will have to be a calibration experiment that gets repeated on a regular basis (or at least, the FPGA should be able to check for DDS synchronization before and after a given kernel runs and flag an error if the DDS lost sync during the experiment, and then run a resynchronization routine). The current DDS sync design I envision involves using one 3.3V LVCMOS line from the FPGA to send a synchronization signal, which will go to a 1:12 LVCMOS clock distribution chip on the FMC backplane. Unfortunately we cannot use LVDS because all the available I/O banks need to run at a 3.3V VCCO in order to talk to the interface logic of the DDS chips (e.g. the parallel bus etc). Using 2.5V LVCMOS to drive 3.3V inputs degrades our noise margin to basically zero, which given our desire for >100 MHz bus speeds doesn't seem like a sensible tradeoff. Putting level translators in will be a nightmare in terms of introducing skew and latency, especially for bidirectional signals. I don't think that using LVCMOS instead of LVDS will make a big difference, though, as the 3.3V LVCMOS rise times (based on IBIS) are ~300-400 ps, and I don't think we can do much better since we have to convert to 3.3 V LVCMOS in the end to talk to the DDS SYNC_IN pin. The clock distribution chip has a similar rise time spec. Each output from the clock distribution chip will be dedicated to one DDS. On the DDS cards themselves, there will be an analog switch which allows the clocking signal to be either passed through to the DDS SYNC_IN or blocked (SYNC_IN pulled low after the switch), depending on a DDS chip select signal. The same analog switch will use another channel to pass the DDS SYNC_CLK back to the FPGA for monitoring. It will also have two more channels that are connected together right next to the DDS, so that the FPGA can send pulses and measure a round-trip time from FPGA inputs to DDS and back for deskewing if needed. I would imagine that the board-to-board variations would be sufficiently small, though, that one could manually perform a calibration of the propagation delays for the setup with DDS clocks synced and then just give those numbers to the FPGA to use as offsetsthen one wouldn't need to use a round-trip signal every time. I am making provision on the DDS cards themselves to do the hardware-only syncing using the SYNC_OUT/SYNC_IN method if preferred for some reason, so that can be a backup option. Let me know your thoughts! Best, Daniel ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] return types of kernel RPCs
> when a kernel calls an interpreted function via RPC, it is generally not > possible to determine the type of the value that the function returns, until > it > has actually been executed (and the type can vary dynamically between > calls). This is a problem with static compilation. > > How should we deal with it? > > 1) Assume that all RPCd functions return an integer, or None. None is > converted to 0 at runtime. This is what is done right now. > 2) Add manual type annotations to RPCd functions. This can be done using > Python function annotations (http://legacy.python.org/dev/peps/pep- > 3107/), e.g.: > def foo() -> float: >... > > #2 is a superset of #1: we can default to #1 when no annotations are present. > So the actual question is: do we need #2, and what do you think of the > proposed syntax for annotating return types? I could imagine an RPC whose results might be used to set a DDS, e.g., in which case it would be nice to be able to return frequency and phase, or one where several different pulse times need to be set, so it seems that option #2 would be good to have available. The alternative (issuing multiple RPCs for each desired pulse time, or one for freq and one for phase, for example) would end up costing us a lot of GigE communication time overhead. For most cases, a single integer would probably suffice (and if you are clever and the information returned is of appropriate form one could manage multiple return values in a single returned 64-bit long by masking bits, e.g.), so it seems that defaulting to #1 and allowing the option to specify return type manually is sensible. The proposed syntax seems straightforward and simple to me. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] controller management
> > 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 those who need or want Windows or are uncomfortable with Linux > seem to be either bored or shy to speak up. Honestly, the chances of > deployment of Linux in these labs are small. And yes: that bothers me. I think we will want the ability to have controllers on Windows. For better or for worse, there will likely be majority Windows 7 computers in the lab, and there may well be various hardware devices we would like to use where the Linux support is absent or not good enough. Granted, nothing springs to mind immediately, but that doesn't mean it's not a real consideration. I think that having the master running on Linux, and having the bitstream compilation take place on Linux (inside a virtual machine, or on a real Linux box) seems reasonable, and gets rid of many issues trying to have cross-platform compatibility. But I think it's important that we keep the ability to have controllers running on Windows if we can. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] PXI-6733 and other drivers
I agree with all that Joe has written in detail here. Basically, the motivation of the “generic driver” idea is to make it so that when someone wants to make a controller for a new type of hardware, they can do so by just tinkering with/expanding an existing controller template, rather than having to create the whole thing from scratch. This should hopefully reduce the chances of having broken/poorly written/poorly formatted drivers being written by scientists with widely varying Python experience trying to get something running in a hurry. Along these lines, commenting/documentation for the template (explaining why certain steps might be needed, for example) is important. These drivers will need to be a bit more complex (see Joe’s comments) than just the simple tutorial controller that has been written so far – something to get us to a point where you might just copy a template “set” or “get” method, change the commands (e.g. SCPI) inside, rename the method as appropriate, etc. From: ARTIQ [mailto:artiq-boun...@lists.m-labs.hk] On Behalf Of Joe Britton Sent: Wednesday, December 17, 2014 10:42 AM To: Sébastien Bourdeauducq; artiq@lists.m-labs.hk Subject: Re: [ARTIQ] PXI-6733 and other drivers Here's my take on this. > "Generic Devices with manufacturer-supplied DLL or C/C++ driver" This could be satisfied using ctypes and python. An example showing proper end-to-end coding is what I have in mind. Assume the PC hosting the hardware is running Windows 7 and a scientific python distribution, say, Enthought Canopy Express [0]. (1a) some generic code in C with functions passing a representative sample of types (char[10], int[10], double[10], my_struct[10]) (1b) instructions on how to compile to a suitable .dll (1c) example Controller using ctypes and Artiq methods (1d) error handling using exceptions or whatever method Artiq uses (1e) shell documentation using sphinx (or whatever we agree upon). > "Generic GPIB, USB, or RS232/485 Devices using VISA"? Similar to previous we'd like code templates. (2a) A properly implemented, robust interface to a generic serial device written in python 3. Assume the device manufacturer includes whatever HID driver is required to present the interface as a Windows serial port (eg port 3). (2b) Example of how to send/receive text commands and test that device responds properly (eg it echos back "OK\n"). (2c) Example of how to send/receive continuous stream of binary data. (2d) Example Controller using Artiq methods. (2e) Error handling using exceptions or whatever method Artiq uses. (2f) Documentation example using in-line sphinx annotation of the python (or whatever we agree upon). (2g) Windows has an unpleasant reality that there's not a static mapping between a particular USB-serial device and an assigned serial port. The mapping seems to depend on which physical port the device is plugged into and what other devices are in use on the system. So, upon launch it would be good if all serial ports registered on the host were polled to figure out which port is right for a particular Controller. Most devices have some sort of device-specific query and response strings (eg "ID?"). (3a) A light-weight, generic GPIB interface. I advocate we consolidate our lab setups to the Prologix USB-GPIB interface http://prologix.biz/ since this requires installing no drivers; the NI alternative works is $500 and requires installing about 1 GB of crud. The Prologix device presents to the host OS as a serial device and commands are sent/received GPIB text strings (e.g. GPIB formatted). While this is basically an application of (1a) it is helpful if it's a distinct example since configuring a prologix device requires a couple properly formatted text strings. (3b-f) as (2b-f) (3g) Most devices have some sort of device-specific query and response strings (eg "*IDN?"). Confirm upon startup the target device is responding as expected at the specified GPIB address. This prevents an accident where a hazardous device (eg high voltage or current) gets reprogrammed via random text strings intended for another piece of GPIB hardware. (4a) I think listing "USB" here was a bit sloppy on our part. If the device presents to the host OS as a serial port (eg USB-serial interface) I think (2a-g) fits the bill. If it presents to the host OS as some other sort of HID it's safe to assume that the vendor has supplied a DLL or C/C++ driver and (1a-e) applies. [0] https://store.enthought.com/downloads/ Note to ions... For convenience of documentation it would be helpful if we make a choice for a scientific python distribution for Windows. The two main contenders seem to be Enthought Canopy and Anaconda. -Joe On Wed Dec 17 2014 at 7:59:21 AM Sébastien Bourdeauducq mailto:s...@m-labs.hk>> wrote: Hi, are you still using the PXI-6733 DAC cards? If you do not need it, we can replace the driver with another one of similar complexity for another device. Also, what
Re: [ARTIQ] PXI-6733 and other drivers
> are you still using the PXI-6733 DAC cards? If you do not need it, we can > replace the driver with another one of similar complexity for another device. As far as I know there are still people using the PXI-6733 DAC cards, so I think it makes sense to have them be supported as per the Statement of Work. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] GUI development update
> On 12/16/2014 12:16 AM, Tan, Ting Rei wrote: > > Any update about finding someone for GUI development? > > Nothing concrete yet, and I've been busy with other topics (RTIO, controllers, > master, etc.). Is that a priority? My impression is that a number of things > could be developed and deployed via scripting and command line already. Having a good GUI is definitely a crucial aspect of the success of ARTIQ for our group, so I think it pays not to wait until the last minute to find someone. Obviously the other things you have been working on are also essential for success, and you should continue working on them, but it probably would make sense to see if we can find a GUI developer in the near term. ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
Re: [ARTIQ] Today's slides
> 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 one of the FPGA clock inputs to serve as the clock for the RTIO core. As an update on the DDS syncing, it is looking like it should be possible to sync the DDS chips using pulses from the FPGA with variable delays, but this is preliminary and not fully shown yet. It is essential that the edge time for the synchronization pulses be very fast, <400 ps is best for reliable performance. This should be achievable using a OSERDES, correct? Can the OSERDES be used in conjunction with the ODELAY blocks for fine delay adjustment? ___ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
