v1.0 tests

[gkasprow]

• after correction of v1.0 errata #100 the power supply values are OK
• the power rail ripples are below 10mV on digital rails and at the scope noise level on analog rails.
• the power consumption for baseband version without FPGA bitstream is 2.4W
• the power consumption for the upconverting version without the FPGA bitstream is 3.8W

[gkasprow]

the FPGA is correctly detected over JTAG
INFO: [Labtools 27-1435] Device xc7a100t (JTAG device index = 0) is not programmed (DONE status = 0).

[hartytp]

Awesome! Will you be able to get rf out of the dac using Xilinx ip?

[gkasprow]

That's a bit tricky. DDS is trivial with Xilinx IP tools, but DAC initialization seems to be much more complex (48 16-bit registers)

[hartytp]

Ok. @jordens anything else you want done before shipping?

[gkasprow]

however, I can test the upconverter because I have a devkit and can connect the SPI lines directly to the mixer chip. But I need to get something on the DAC outputs first

[hartytp]

That's a bit tricky. DDS is trivial with Xilinx IP tools, but DAC initialization seems to be much more complex (48 16-bit registers)

I wonder how many actually need to be configured beyond their reset values to get basic functionality.

[gkasprow]

the eval software seems to do the config job

[gkasprow]

the eval SW works only with the connected devkit. I did not find a way how to generate the register map.

[gkasprow]

ok, that's not that bad. TI delivers several default config files. This is example one
DAC34H84_FDAC_1228p8MHz_4xint_NCO_30MHz_QMCon.txt

[hartytp]

Nice!

[gkasprow]

I plan to play with them. The idea is to use Xilinx DDS Compiler that outputs sin/cos 16-bit value, then use DDR primitive to realize the output interface. 100MHz would be sufficient to do some tests without waiting too long for compilation.
Then use FORTH embedded CPU that does all DAC SPI configuration. To config the upconverters, I will route their SPI lines to EEM and then use tester EEM to connect to the TI devkit where I get nice GUI to access to all registers
I can build such a setup quickly.

[hartytp]

Perfect!

[jordens]

Checking that the LVDS interface works at full required speed would be helpful (using the pattern checker). Debugging that is not something I'm set up for.
AFAICT there is no need to generate signals on FPGA for testing the RF chain. You can just output constant and use the DAC NCO to upconvert that.

[gkasprow]

True, I'll have a look at it.

[gkasprow]

We need the production PTS anyway, so It's good to make the pattern checker running anyway.

[jordens]

It'll likely also be part of the standard init sequence in ARTIQ and our test suite as well. Probably worth doing it in such a way that there is maximal code reuse.

[gkasprow]

Yes, we do it with ARTIQ. The LEDs are blinking :)

[jordens]

As you know, we have also had a test suite for a long time and every bit of possible self-testing functionality that can be moved from private one-shot production and integration tests into ARTIQ proper is extremely useful for everybody including manufacturing. It increases coverage of the tests, of the hardware, and allows the test suite to be maintained together with ARTIQ preventing divergence.

[gkasprow]

We are developing it at the WUT right now and all we do is or will be public.

[gkasprow]

@hartytp @jordens we are working on basic firmware support that will let us characterize the design.
TS wants to send all 6 boards to you immediately. What is the decision then? I'd need 2 boards to do initial tests. I don't want you to do HW debugging.

[jordens]

No point in shipping them to me right now. I can't do much with the boards yet anyway. First need to make progress on the gateware development for it. That will be another few weeks. Since shipping is fast, I'd prefer you keep the boards for the next two weeks. Then we revisit.

[hartytp]

I'm happy for TS to send me an invoice now if easier? I agree with @jordens though, no point shipping before basic testing is complete.

[hartytp]

@gkasprow any progress with this or is it blocked by the uni being closed?

[gkasprow]

Mikolaj is working on it all the time. We have access to the WUT but we go there only when necessary.

[hartytp]

Wonderful! Let me know when you have results

[kaolpr]

Hi, indeed I work on testing of the Phaser. Some remote-working and epidemic related difficulties stopped me for a while, but I can confirm that basic gw for Phaser FPGA is ready and is being tested. Hoping to have it tested at the end of the next week at the latest.

[hartytp]

Awesome!

[kaolpr]

Well, referring to my previous post, regrettably I have to report that tests are not yet finished. Currently all chip communication works and I'm experimenting with DAC LVDS interface checker. Hope to have some results in the days to come.

[hartytp]

Glad to hear things are progressing!

[hartytp]

@kaolpr how's the testing going? We're really looking forward to getting our hands on Phaser!

[gkasprow]

This is the configuration that simply works

[hartytp]

Cool!

@jordens were there any other acceptance tests you wanted to see before we ship the remaining boards?

[jordens]

With the DACs running at 1 GS/s and the upconverters on it pulls about 10.5 W and gets into the uncomfortable temperature range (without forced cooling) where the DAC on-die sensor is around 90 C after a minute and the package at 86 C. The upconverters are also around that temperature. Even the DCDC converter gets into the 65 C range. This board needs force air cooling.

[hartytp]

Thanks for the photos. That doesn't overly surprise me. I assume that in a rack with a fan tray this will be fine, but would be good to see some data.

Do you think it's worth adding heat sinks on to the DAC + up converters for good measure?

[gkasprow]

This is the reason I install LM75 which will shut down the main SMPS when 80C is exceeded. It does not need initialisation.

[jordens]

@hartytp The overall high power shouldn't surprise anyone. We said that it would be hungry.

But that it exceeds the power budget (10.3 W) is a bit surprising. I don't remember seeing that before.
Also, as pointed out, the DCDC converts shouldn't get that warm. According to budget it burns only 75 mW.

@gkasprow With the DAC die at 85 C, the LM75s are at 50.5 and 36.0 C respectively. I suspect that before either gets to 80, the DAC is at 115, more than I'd want to run it at. A related question: is there x-ray data on how well that approach with the exposed pads and the unplugged vias works in terms of wetting the pad while not wicking? It seems to be decidedly non-standard.

[jordens]

There is more testing data correlated to the gateware development over at quartiq/phaser#3
Let's close this and fork where issues arrise.

[gkasprow]

we can move the sensors closer to the DACs :)
The power budget shows 10.28W so it looks like the perfect fit.

[jordens]

Just that we are usually significantly below the budget (e.g. Urukul).

[hartytp]

I agree; the numbers in the budget are generally "worst-cases" so I expect to come quite a bit under. I suspect one of the numbers may be wrong (e.g. for a different clock frequency or something).

[hartytp]

Also, as pointed out, the DCDC converts shouldn't get that warm. According to budget it burns only 75 mW.

Do you mean the TRN 3-1222 (+-12V?)

[jordens]

Yes

[hartytp]

@jordens any idea what the FPGA current is for the configuration you're running?

[hartytp]

I checked the DAC, clock chip and upconverter currents. They all look correct.

The numbers are generally (where available) "worst-cases" which are generally around ~20% worse than "typical". On top of that, we're e.g. not using the DRAM/transceivers, which is a few hundred mW saved. So, I am a little surprised that the power consumption isn't lower

[jordens]

No idea. The design is calculated to draw around 2 W. The FPGA isn't really getting hot.

[hartytp]

Okay, that's around what is budgeted in the table. But it's one of the biggest items in the budget so it could eat up some of the margin included in the other components if it's a bit on the high side.

[hartytp]

The TRN 3-1222 getting hot surprises me more however. Looking at the things it drives

• the AD8253 only draws 5mA max quiescent (we budget 8mA but I assume it's actually putting out ~0V in Robert's configuration. either way though, it's not much current). That's ~10mA total for the two channels
• The OPA2197 are only 1.5mA worst case (the ADC should be high-Z for a static load), so 6mA for the two channels plus a small amount for the feedback resistors (but they are ~10k so not a big amount)
• the N11V5 LED is 10mA if it hasn't burnt out already...

assuming the LED is dead (which seems likely) that's a bit above 16mA for each of the P/N11V5 rails (we budget 24mA giving a comfortable margin). Call it 400mW rail power, so 75mW at 20% SMPS efficiency.

Assuming 20C ambient and 60C case, that suggests a thermal impedance of order 40C/75e-3W = 500C/W. Which doesn't sound very plausible!

My guess is that there is indeed an issue with something on the P/N rails. Maybe a short or something oscillating?

[hartytp]

@jordens @gkasprow is it worth putting heat sinks on the DACs/upconverters to keep them happy?

[gkasprow]

@jordens can you post me binaries so I can configure the FPGA and see how it behaves with my board?

[jordens]

I can do that but without a kasli driving it it won't do anything.

[jordens]

The bitstream is at https://github.com/quartiq/phaser/releases/download/v0.1/phaser.bit
You need the duc branch of misoc and the phaser branch of artiq to build a kasli bitstream to interface with it. Then execute the example.py artiq experiment with the penultimate line commected out.

[gkasprow]

In my setup the power consumption is as follows:

• Kasli idle 2.17W
• Kasli idle + Phaser idle: 5.57W
• Kasli idle + Phaser with FPGA configured: 8.42W
  Do you have similar readings with your board?

Tomorrow I plan to build the Kasli bitstream and see how much it takes.

[jordens]

For me:

• Kasli 2.0 with bitstream containing one Fastino PHY on EEM0 and one Phaser PHY on EEM1: 8.3 W
• plus one Phaser (upconverter) with Phaser bitstream: 15.3 W
• plus running the example script which enables everything (DAC, NCO, interpolation, TRF etc, penultimate line commented out): 18.9 W
• example again but putting the DAC and the TRFs into sleep (penultimate line active): 14.8 W

[hartytp]

@jordens I've gone over the issues and broken everything I spotted into its own issue. If there is anything else I've missed/other tests you think we should perform could you open issues at some point?