Urukul v1.0 detailed testing

[hartytp]

• [x] Channel-to-channel cross-talk: adjacent channels, with agressor, victim switches opened and switches closed and with attenuators at max/min
• [x] Output phase noise/amplitude noise (0.1 Hz - 10 MHz)
• [x] OIP3, OIP2 vs frequency for min attenuator setting and medium/large amplitude (ASF)
• [x] RF switch settling behavior for on edge at max power (worst case)
• [x] Attenuator glitches
• [x] Nyquist attenuation, clock leakage
• [ ] RF switch settling behavior for off edge at max power (worst case)
• [ ] RF switch phase chirp
• [ ] Temperature coefficient of power and phase
• [ ] Are we happy running the IC11 and running the LVDS interface directly from the 3V6 rail? (Try this and check performance)
• [ ] Check performance of clock buffers when running in LVDS mode from the 1V8A rail
• [x] Optimize PLL loop filters (@weidazhang can you do this for the AD9910 boards, please?)
• [ ] Board-to-board crosstalk (in proximity to Kasli, DIO pulsing 5 V into 50 R, Urukul)

Use some fixed reference frequency for all tests, such as 80MHz.

[hartytp]

@gkasprow Can you ship us all but 1 of the AD9910 Urukul prototypes you've ordered as soon as basic functionality/"no smoke" testing is complete (i.e. don't complete the above detailed testing first!).

Thanks!

[hartytp]

@gkasprow @jordens Feel free to add more tests to the above list.

[hartytp]

@gkasprow When you ship the AD9910 DDSs that we paid for, please can you ship one to @jordens?

[jordens]

Updated it a bit. Please ship right after smoke test:

• [ ] power supplies good
• [ ] clock fanout fans out
• [ ] dds pll locks
• [ ] dds outputs frequency
• [ ] attenuators can be set
• [ ] rf switches work

We'll be happy to help with characterization afterwards.

[hartytp]

@gkasprow Is Urukul due to arrive this week? When it arrives, please can we prioritise no smoke/basic functionality testing (see reobert's list) above finishing Zotino -- I'd like to get Urukul prototypes shipped asap. No need to do the detailed testing for now.

Thanks!

[gkasprow]

@hartytp OK, 2 Zotinos + BNC adapters were shipped on Friday. Once I receive DDS, I will test them ASAP.

[hartytp]

Thanks!

[gkasprow]

@hartytp There are no panels for DAC BNC adapters attached - I forgotten about them. Will ship them next time with some other stuff.

[hartytp]

@gkasprow No problem. That can wait.

If there is any time before Urukul arrives, it'd be great to get a few of the analog test for Zotino done.

[gkasprow]

@hartytp Sure, once I repair my bard, will continue with measurements.

[hartytp]

Great, thanks @gkasprow!

[jordens]

@hartytp could you remember to do a bit of triage on the issues you file (i.e. assignee, labels, milestone)?

[hartytp]

sure

[hartytp]

@gkasprow For the current source biasing, my inclination is to go for Daniel's suggestion of the LT3092. They're pretty cheap ($2 in quantity) and seem like a better/easier solution than building our own current source.

@jordens @gkasprow if you're oaky with this approach, then we should buy an eval board at some point and test this out with the v1.0 boards we have. I'm happy to do this testing if that helps -- I probably won't do this until after Christmas, but I don't think we're in a rush for it.

[jordens]

@a-shafir and I will take care of the first round of noise, power, RF switch testing.

[hartytp]

Cool.

Out of curiosity, do you have a proper phase noise/amplitude noise meter? Or, will you just stick this on a spectrum analyser?

[jordens]

We have proper tools.

@gkasprow how are the AD9912 variant boards?

[gkasprow]

@jordens I have them all in my lab but was busy with Sayma Ethernet debugging. You can follow my fight here

[gkasprow]

So the next thing is 9912 testing.

[jordens]

I am following that and involved. Thanks for the AD9912 update. Once you have smoke-tested them like the AD9910 stuff, you can send two of them to me.

[a-shafir]

@gkasprow what was actually flashed into the CPLD on the 9910 board we have in Berlin?

I see 2 options https://github.com/m-labs/sinara/tree/master/ARTIQ_ALTIUM/EEMs/Urukul/CPLD_code or https://github.com/quartiq/urukul

I am testing h/w but can't generate any output on the IO_SESET (P129) and some pins around.

[a-shafir]

@gkasprow how you tested 3U DDS 9910? Have you got DDS ic working? Do you have the code that sent the spi commands, what actually sent to DDS/atten etc?

[gkasprow]

@a-shafir I burned Roberts Verilog code. The only change I did was assignment of test points. Now we have:

assign tp = (cfg_data_rst | ((~en_9910) & tstriple7_i));
assign tp_1 = dds_cs_n;
assign tp_2 = dds_sck;
assign tp_3 = dds_sdi;
assign tp_4 = dds_io_update;

[gkasprow]

I connected 9910 devkit via DIO-Tester module to make sure that Robert's code works. In this way I could communicate with it using LVTTL signals

[gkasprow]

I also modified the verilog code so all 4 channels were active simultaneously. In this way I tested if PLLs are locked. Here is the code: Urukul_CPLD_all_ch.zip

[gkasprow]

To do general purpose communication over SPI I use little Artix 7 devkit with USB and FORTH processor that translates UART commands to bit-bang protocol, i.e. SPI. It works really fast but it's written in FORTH, so probably not really useful for you :)

[a-shafir]

@gkasprow i see io_reset commented in the code. probably some other changes. Please also attach the pin assignment for the code. So what was generating the DDS SPI command? 9910 devkit? I have no devkit. Can you generate a dump (sequence) of the commands? Also what about the reading from DDS when all in parallel?

[a-shafir]

@gkasprow i see why in_sel not working to - it commented out Good that i got this data from you )

[gkasprow]

The original DDS was working in parallel. So I didn't read the status from externally connected ones. You can compare this code with one @jordens posted. I did not touch the pins assignment. My CPLD project is here

[gkasprow]

This is how typical setup with devkit looks like. I this case I connected Sampler module, but the idea is same.

[gkasprow]

this is the FORTH code I use to talk to LV595 registers. The FORTH ascii is executed in FPGA and is toggling IOs routed to an IO register with a few MHz rate. CPU runs with 50MHz clock. The function below writes 16 bits via SPI to the register and reads them back.

: spi_LV595 ( a ) 

    1 OUT0_SET_REG io! \ SCK hi
    1 16 lshift OUT0_SET_REG io! \ OE buff active
    1 2 lshift OUT0_CLR_REG io! \ RCLK low

    16 0 do
        dup
        1 15 lshift and
        if
           1 1 lshift OUT0_SET_REG io!
        else
           1 1 lshift OUT0_CLR_REG io!
        then
        1 OUT0_CLR_REG io! \ SCK low
        2*
        INP0_REG io@ 4 rshift 1 and +
        1 OUT0_SET_REG io! \ SCK hi 
    loop

     1 2 lshift OUT0_SET_REG io! \ RCLK high
     1 2 lshift OUT0_CLR_REG io! \ RCLK low
     1 16 lshift OUT0_CLR_REG io! \ OE buff inactive
     $ffffff and  \ return only valid bits
;

[gkasprow]

@a-shafir you are right - I had to modify the reset pin state to make it working.

[gkasprow]

And the code you have burned in your CPLD is in Urukul_CPLD_1ch.v file

[gkasprow]

@jordens here is your 9912 :)

[jordens]

@gkasprow Nice! Other than the missing amplifier, are there any other issues? Is the solder on the underside bad as well?

[hartytp]

Nice!

[gkasprow]

I got this amp separately. The PN is wrong so they got ones with straight leads and had to replace them. It seems that the ICs they got had problems with wetting because other chips are fine. Anyway, it's their responsibility to solder it right

[jordens]

Are you returning the AD9912 boards to Technosystem to be fixed as well?

[gkasprow]

I will fix one piece myself to test it. Rest of the boards will be returned. I talked with the company and they say that it is quite standard thing that some chips have poor wetting and side contacts are not always covered by the tin. The flux that is part of the soldering paste is only roughly 10..15% of it and is not always able to clean the contact side. The joint still maintains the contact because it is low side of it which does the job. Side area does not need to be covered, but if we want, they can fix it.

[jordens]

IMHO it is likely that the joints are bad on the underside as well if they fail to wet that dramatically on the edge. And since they probably didn't inspect those joints there is no telling. I'd like to see them fix it.

[gkasprow]

I just desoldered the chip and the bottom pads are correctly soldered. Anyway it just looks non professional and should be fixed.

[a-shafir]

This is a long known for the technologists that too much solder is not helping and even can cover some problem. But in this case it is not about the professionalism but about Optical inspection standards. All the packages designed that way that there is possibility to ensure by inspection the proper electrically and mechanically soldering. For this package there must be wetting on the side edges of the pads. This indicates that there is wetting under the pads and also improves mechanical properties.

For some of the packages we have (BGA and some of the qfn with signal pads under) the OIS will not enough. I think need to check if the factory can do x-ray inspection, they must have it in or out house at least for BGA but also for some regulator chips etc. Visual inspection of the QFN etc is the must. It shall not increase the cost of the samples production more than few %

Any way investing our time to solving the technological issues is the worst case scenario.

[a-shafir]

Urukul 9910, 4th channel, 10.000MHz, variable attenuation test, no termination:

[gkasprow]

@a-shafir look here

[a-shafir]

@gkasprow ok, this is a news for me too. There are 3 similar looking "QFN-style" packages:

• one have sides plated to be good for wetting (some crystals for instance and old stile QFN)
• some have a etch/step around to have the wetting visible for OIS
• the newest are basicly BGA-like i.e. all wetting is under the package but just no balls.

That minds for us:

• Even we don't have a BGA on a board we need to inspect the packages to ensure they are good for optical inspection (OIS) and if any one of them is needed we must add X-ray inspection into the production list.
• Need to chose the parts for the boards more careful. If the board normally (most of the parts) does not needs X-ray try to avoid any packages that have no OIS compatible pads (like LTM4622 etc)
• It is good to put this as a part of the h/w and production specs checklist.

[a-shafir]

Gateware, core drivers and experiment for Urukul AD9910 rev 1.0 board.

The current setup is for KC705, see the details here: https://github.com/m-labs/artiq/commit/dd3c8a336dc12cda33cadebdf3bafc77c0bc1565

The experiment initializes FMC DIO, the Urukul board and configures the single tone for all 4 channels. Attenuator and SW are supported.

There are 2 "interference generator loops" (for DDS3 SPI and for ATT SPI). Each can be activated in the experiment. Note: with the current RTIO gateware it is not possible to generate the NU-mode intensive SPI communication so if any interference from the SPI clock will be seen on the output it will be not the worst case scenario.

The 4-channels DDS output:

The setup:

[jordens]

• RF Switch rise time is roughly 100ns to 95%
• Spectrum looks ok. A few weird close in Spurs (+- 1.2 kHz and 11kHz at -70dBc) potentially related to grounding to be debugged. They are big when the board is on the antistatic bag on an optical table and otherwise disappear.

More data and screenshots to follow.

[dhslichter]

@a-shafir why are you using scope probes to look at the DDS outputs instead of SMA cables?

[gkasprow]

@jordens in such setup you easily receive and induce current from every short wave radio station including CB :)

[jordens]

@gkasprow in general yes, but not if you are in a room that is as insanely shielded as the one we are doing the tests in ;)