Phaser support status - Githubissues

jordens commented 4 years ago

This is a running list of the implementation milestones

Phaser baseline

[x] Phaser migen/misoc platform definition, verified against schematics and existing test gateware
[x] Build scripts, load and flash scripts
[x] Kasli I2C implementation for LM75, I2C-to-SPI converter, SPI flash, flashing scripts
[x] Clocking tree: 125 MHz ref, data clock from Kasli fastlink, 250 MHz fabric clock generation, 500 MHz DDR serdes clock, iodelay calibration, reset generation
[x] Fastlink PHY, adapted from Fastino, 500 MHz oversampling, automatic bitslip alignment to middle of eye
[x] Fastlink link layer: clock alignment, marker discovery, frame alignment, checksum verification
[x] Bit error measurement passed (<1e-13)
[x] Frame decoder, configuration-status-registers and and CSR bus, sample payload unpacking
[x] Status and configuration registers hooked up, fan, leds, gain switches, hw_rev, gw_rev, board id, crc error counter, termination indication, dac/att/trf/adc control, resets, power save, lock detects
[x] DAC, Attenuator, TRF spi interfaces, controlled via CSRs
[x] Zero order hold interpolator
[x] Uneven, variable input size, 5/6-to-7 (to-14-to-28) gearbox for streaming interpolator
[ ] Buffered streaming sample gearbox (saves latency and a few FFs, at the cost of data CRC validation, low-prio)
[x] Proper interpolation path DSP design and analysis
[x] DSP Interpolation path implementation (#1)
[x] New CosSinGen implemented and integrated
[x] CosSinGen scaling tested (>256 250 MHz DDS on xc7a100t)
[x] Complex multiplier with rounding and proper scaling
[x] Multi-sample Phased accumulator
[x] Multisample phased digital upconverter
[x] Upstream DSP components to MiSoC (https://github.com/m-labs/misoc/compare/duc)
[x] DAC data interface (500 MS/s on 4 channels, 1 Gb/s per pin, passes timing with 250 MHz fabric)
[x] ARTIQ RTIO phy for CSRs (https://github.com/m-labs/artiq/compare/phaser)
[x] ARTIQ coredevice layer
[x] MultiDDS: time domain multiplexed DDS for baseband on coredevice
[x] MultiDDS saturating summation
[x] ARTIQ RTIO phy for sample payload
[x] Coredevice MultiDDS layer
[x] Complex-real multiplier with two DSP (saves a DSP, low-prio)
[x] DAC setup sequence: pll, interpolation, mixing, qmc, nco
[x] DAC iotest passes at 1 Gb/s
[x] DAC 32 bit parity alarms passes
[x] DAC dual source synchronization with PLL passes
[x] DAC alarms unmasked and enabled
[x] Coredevice Phaser register abstraction
[x] Coredevice attenuator abstraction
[x] Coredevice DAC register abstraction #6
[x] TRF setup sequence
[x] Coredevice TRF register abstraction #6
[x] SI-to-mu unit conversions
[x] Maybe rework the tone RTIO channel partitioning
[x] Useful self-testing initialization sequence (move large parts of example.py into phaser.init())
[x] HITL tests, kasli_tester #8
[x] Expose CMIX and basic VCO frequency settings. #6
[ ] Debug spectral inversion between DAC and TRF #9

jordens commented 4 years ago

Feature preview: five tones around 125 MHz, different amplitudes. Still several things to implement.

jordens commented 4 years ago

And with the upconverters (5 tones at -1.67 MHz multiples on coredevice, duc to -164 MHz on phaser, 2x interpolation and cmix -125 MHz on dac, upconverter carrier at 1.25 GHz), showing good IMD, phase spur, carrier suppression, IQ balance.

hartytp commented 4 years ago

Nice!

@jordens out of curiosity, there looks to be quite a bit of close in noise. Any idea where that's from? On the baseband plot, the multi-tone SFDR looked to be about 40dB. Is that what you'd expect?

jordens commented 4 years ago

There is no interpolation (only zero order hold from 25 MS/s to 500 MS/s) yet so there are copious amounts of aliases flying around. The first shot is also with the Phaser DUC at zero frequency so they have a good chance of appearing close in. In the second shot they are (conveniently) outside the 40 MHz bandwidth of the scan. The pedestal noise in the first shot is either a bug that I fixed on the way or an analyzer limitation (settings were different). In the second shot it's likely analyzer. Neither test is meant to measure or characterize anything. I wouldn't worry.

hartytp commented 4 years ago

cool, that's what I wanted to hear

jordens commented 4 years ago

With the complete interpolation chain, settings as before. The obviously required PLL tuning, LF debugging, IQ balancing, carrier nulling, delay matching, and phase noise measurement will need to be done by someone else. I don't see anything that looks like it's introduced in the digital domain. Note that there is no common reference, no locking and the devices are strewn across a table in the breeze.

PNG4 PNG3 PNG1 PNG2

The analyzer's own 10 MHz reference for comparison. PNG1

hartytp commented 4 years ago

cool! What are peaks 2/3 in the top plot?

hartytp commented 4 years ago

LF debugging, IQ balancing, carrier nulling, delay matching, and phase noise measurement will need to be done by someone else

What do you mean by "LF debuggin" and "delay matching"?

jordens commented 4 years ago

2/3 looks like a upconverter PLL instability (as I said, no attempt at verifying the parameters, these were those from Greg's screenshot elsewhere).
Debugging PLL loop filters
Analog I-Q delay matching from the DAC to the upconverter. The digital delays are matched already.

jordens commented 4 years ago

Also note that the complete design uses about 10% of the resources (DSP, LUT/FF) of the xc7a100t on Phaser. A 15t would still have plenty of space and there is room for resource optimization.

hartytp commented 4 years ago

Analog I-Q delay matching from the DAC to the upconverter. The digital delays are matched already.

That's nominally done in the design, right? You just mean that it may need tuning in practice to get good sideband suppression at multiple frequencies due to component tolerances etc.

hartytp commented 4 years ago

2/3 looks like a upconverter PLL instability (as I said, no attempt at verifying the parameters, these were those from Greg's screenshot elsewhere).

ack. Looking at the phase noise/loop filters is on my testing list once the gateware/driver is finished.

Am I right in thinking that modulo issues like sub-optimal PLL tuning, this is now basically ready for use in experiments? Or are the register abstractions required to do much with it?

jordens commented 4 years ago

Analog I-Q delay matching from the DAC to the upconverter. The digital delays are matched already. That's nominally done in the design, right?

There are multiple knobs for I-Q group delays, qmc scalings and offsets and phases, upconverter offsets. They are all nominally good but there may well be a couple dozen dB of improvement in there. Group delays might be a bit more interesting to optimize properly but might also not bring that much gain for typical experiments.

Am I right in thinking that modulo issues like sub-optimal PLL tuning, this is now basically ready for use in experiments? Or are the register abstractions required to do much with it?

The coredevice layer needs some SI-to-mu conversion methods. And there may be a bit of register abstraction coming but I'm not sure it'll go very far since there can't really be a meaningful abstraction beyond those registers. There will be some default settings and going beyond them will require reading the datasheets. The only user-facing adjustables required now are means to set the upconversion frequencies (on Phaser, FMIX/CMIX in the DAC and the TRF VCO).

This is definitely ready to be characterized in depth and used in early experiments to get some more experience with it and find the most prominent bugs.

hartytp commented 4 years ago

This is definitely ready to be characterized in depth and used in early experiments to get some more experience with it and find the most prominent bugs.

Perfect!

There are multiple knobs for I-Q group delays, qmc scalings and offsets and phases, upconverter offsets. They are all nominally good but there may well be a couple dozen dB of improvement in there. Group delays might be a bit more interesting to optimize properly but might also not bring that much gain for typical experiments.

ack

The coredevice layer needs some SI-to-mu conversion methods. And there may be a bit of register abstraction coming but I'm not sure it'll go very far since there can't really be a meaningful abstraction beyond those registers. There will be some default settings and going beyond them will require reading the datasheets. The only user-facing adjustables required now are means to set the upconversion frequencies (on Phaser, FMIX/CMIX in the DAC and the TRF VCO).

ack, so long as there is some way of playing with CP gain etc I'm happy (it's fine if this needs some familiarity with the data sheet, as ultimately it will be a matter of doing some playing to pick sensible defaults which most users will likely not touch).

jordens commented 4 years ago

Without further investigation, I suspect that there need to be some changes to the baseband version analog AA filter and/or load as there is lots of IMD with the nominal DAC current of 20 mA FS. If I dial it down to 9 mA, the output looks good and SFDR is still limited by IMD and no concerning clearly digital spurs in sight.

PNG2