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
