check power consumption

[hartytp]

seems a bit high on some rails indicating a potential problem: https://github.com/sinara-hw/Phaser/issues/101#issuecomment-682044877

[gkasprow]

I measured power consumption, but since there is some issue with DAC, they may not be representative for all rails. P12V0A 3.2mV 0.24R I= 13mA N12V0A 4.8mV 0.24R I=20mA P5V5 6.4mV 0.045R I= 142mA P3V6A 13.7mV 0.045R I=304mA P1V5A 6mV 0.045R I=133mA P3V3 30mV 0.045R I= 666mA P1V0 14mV 0.045R I= 311mA

[gkasprow]

Not symmetrical current consumption of the N12V0A is caused mainly by the LED, which has 1.2k resistor.

[gkasprow]

I used inductor resistance to estimate the currents, so there is something like a 10% error.

[gkasprow]

I see one issue with 3V3 rail consumption. I assumed max value of 384mA, but I measure more than 660mA

[gkasprow]

P1V8A consumes I= 4.8mV/0.05R = 96mA which is fine

[hartytp]

@gkasprow was this for the baseband or upconverting module?

P5V5 6.4mV 0.045R I= 142mA

I don't understand the power budget. What are "from dep." and "with dep."? How does this current compare to expectations?

[hartytp]

@gkasprow any idea why @jordens measured the TRN 3-1222 getting to 65C when it's not dissipating much power at all?

[gkasprow]

P3V3 without FPGA config is just 9.3mV/0.034=206mA. With FPGA configured, it consumes 666mA. This rail supplies 2V5 and 3V3 FPGA rails.

[gkasprow]

@hartytp "from dep" means it is supply from dependent rails, i.e. LDOs. "with dep" is a sum of LDOs and main rails.

[gkasprow]

the TRN 3-1222 consumes 40mA of idle current. Which is already half of watt. It is well isolated thermally from the PCB so it's not suprising that it heats itself to such temperature. The load is 165mW which adds roughly 30..40mW to the bill.

[gkasprow]

we have 37 LVDS signals. If we assume each of them is 2x4mA, we get 296mA of just static power, just for LVDS links

[gkasprow]

that I didn't take into account making the power budget

[gkasprow]

but it does not change the power budget so much

[hartytp]

@gkasprow with the caveat that the DAC isn't fully configured, what's your conclusion? Does the measured total/rail power match the budget?

[gkasprow]

For the moment I have 4.7W - Kasli 9.2W Kasli + Phaser 12.5W Kasli + Phaser with FPGA configured 12.8W after running Phaser_playground.py I would be able to check more when I have the DAC running.

[jordens]

125 mhz clock from kasli connected? And is that face alarm happening always or just the first time you run the script?

[gkasprow]

Yes, it is. I see it on the scope. The alarm error appears each time I run the script. However, this is the board that didn't want to work with testbench @kaolpr wrote. I suspect it has some HW issue with FPGA-DAC.

[jordens]

Maybe. But you are also the first one to test it afaik. So there are likely issues to be found. Could you print out the dac alarm register in check_dac_alarns() before the error is raised?

[gkasprow]

sure. How exactly should I do it? I'm a newbie to ARTIQ

[jordens]

I added a commit to make this a bit easier (no need to make new bitstreams but double check that artiq phaser tree is the latest and that you are using the phaser v0.3 bitstream):

• make the call to Phaser .init() in your script a .init(debug=True) and it will just print the alarm register and continue regardless
• Run your script twice and post the number it prints here.
• Ignore the PLL error in the alarm register. According to the datasheet it isn't reliable and shouldn't be used.
• If the remaining alarm flags are some of the three fifo collision errors, play with the fifo_offset in your device database device_db.py (values 0-7), like:

...
device_db["phaser0"] = {
    "type": "local",
    "module": "artiq.coredevice.phaser",
    "class": "Phaser",
    "arguments": {
        "channel_base": ...,
        "dac": {"fifo_offset": 2},
        "clk_sel": 0
    }
}

• There should be two or three values of fifo_offset that don't lead to fifo errors.

[gkasprow]

[nix-shell:/workspace]$ artiq_run ./experiments/phaser_playground.py
2112
Core Device Traceback (most recent call last):
  File "./experiments/phaser_playground.py", line 12, in __modinit__ (RA=+0x8c8)
    self.phaser0.init(debug=True)
  File "<artiq>/coredevice/phaser.py", line -1, in ... artiq.coredevice.phaser.Phaser.init<artiq.coredevice.phaser.Phaser>(...) (RA=+0x256c)
    <unknown>
  File "<artiq>/coredevice/phaser.py", line 283, column 17, in ... artiq.coredevice.phaser.Phaser.init<artiq.coredevice.phaser.Phaser>(...)
    raise ValueError("DUC+oscillator phase/amplitude test failed")
    ^
ValueError(0): DUC+oscillator phase/amplitude test failed
Traceback (most recent call last):
  File "/nix/store/ks8m3p0isn9l87795ap258l4abc5p9g9-python3.7-artiq-6.7267.4340a5cf.beta/bin/.artiq_run-wrapped", line 9, in <module>
    sys.exit(main())
  File "/modules/artiq/artiq/frontend/artiq_run.py", line 225, in main
    return run(with_file=True)
  File "/modules/artiq/artiq/frontend/artiq_run.py", line 211, in run
    raise exn
  File "/modules/artiq/artiq/frontend/artiq_run.py", line 204, in run
    exp_inst.run()
  File "/modules/artiq/artiq/language/core.py", line 54, in run_on_core
    return getattr(self, arg).run(run_on_core, ((self,) + k_args), k_kwargs)
  File "/modules/artiq/artiq/coredevice/core.py", line 137, in run
    self.comm.serve(embedding_map, symbolizer, demangler)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 629, in serve
    self._serve_exception(embedding_map, symbolizer, demangler)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 621, in _serve_exception
    raise python_exn
ValueError: DUC+oscillator phase/amplitude test failed

[gkasprow]

each time I get the same error

[gkasprow]

when I comment this part:

        # allow ripple
       # if (data_i < sqrt2 - 30 or data_i > sqrt2 or
        #        abs(data_i - data_q) > 2):
         #   print(ch)
         #   raise ValueError("DUC+oscillator phase/amplitude test failed")

it starts blinking LEDs and power consumption is 15W with Kasli

[gkasprow]

It prints channel 0

[gkasprow]

How to get something at the DAC output? I tried this sequence; self.core.reset() self.phaser0.init(debug=True) self.phaser0.set_cfg() self.phaser0.channel[0].set_nco_frequency(10000000)

[jordens]

Use the phaser example.py script (linked above) or the artiq_sinara_tester.py tool (in artiq/frontend)

[jordens]

That phase amplitude test should not fail if you use recent bitstreams. And apparently now your dac alarms are gone.

[jordens]

The phase amplitude test also fails if you hit https://github.com/quartiq/phaser/issues/5. The current work around is to reload the Phaser bitstream (or power cycle kasli+phaser if both are flashed with the desired bistreams).

[gkasprow]

This time I downloaded the bitstream directly from https://github.com/quartiq/phaser/releases/tag/v0.3

[jordens]

The DAC alarm you are seeing is alarm_fifo_2away. Try "fifo_offset": 0, 1, 3 or 4 (instead of the default 2) in device_db.py (see above).

[gkasprow]

OK, I'm playing with example.py When I set fifo_offset to 3, the DAC error disppears. I get

./phaser/example.py:30:9-30:15: error: this function of type method(fn=(self:<instance artiq.coredevice.phaser.Phaser>, ?debug:'a)->'b delay('c), self=<instance artiq.coredevice.phaser.Phaser>) does not accept argument 'clk_sel'
        f.init(clk_sel=1)
        ^^^^^^           
./phaser/example.py:30:16-30:25: note: extraneous argument
        f.init(clk_sel=1)
               ^^^^^^^^^ 

[jordens]

That's an old code version.

[gkasprow]

OK, true. This time I get:

[nix-shell:/workspace]$ artiq_run ./phaser/example.py 
['0x350068']
['0xffffffa9']
['0xffffff8a']
['0xb']
['0x4b00300c']
['0xffffff8d']
['0xff90100e']
['0xd041100f']
['0x340068']
['0xffffffa9']
['0xffffff8a']
['0xb']
['0x4b00300c']
['0xffffff8d']
['0xff90100e']
['0xd041100f']
['0x40']
Traceback (most recent call last):
  File "/nix/store/ks8m3p0isn9l87795ap258l4abc5p9g9-python3.7-artiq-6.7267.4340a5cf.beta/bin/.artiq_run-wrapped", line 9, in <module>
    sys.exit(main())
  File "/modules/artiq/artiq/frontend/artiq_run.py", line 225, in main
    return run(with_file=True)
  File "/modules/artiq/artiq/frontend/artiq_run.py", line 211, in run
    raise exn
  File "/modules/artiq/artiq/frontend/artiq_run.py", line 204, in run
    exp_inst.run()
  File "./phaser/example.py", line 16, in run
    self.do()
  File "/modules/artiq/artiq/language/core.py", line 54, in run_on_core
    return getattr(self, arg).run(run_on_core, ((self,) + k_args), k_kwargs)
  File "/modules/artiq/artiq/coredevice/core.py", line 137, in run
    self.comm.serve(embedding_map, symbolizer, demangler)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 627, in serve
    self._serve_rpc(embedding_map)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 527, in _serve_rpc
    args, kwargs = self._receive_rpc_args(embedding_map)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 385, in _receive_rpc_args
    value = self._receive_rpc_value(embedding_map)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 378, in _receive_rpc_value
    return receivers.get(tag)(self, embedding_map)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 86, in _receive_list
    item = fn(kernel, embedding_map)
  File "/modules/artiq/artiq/coredevice/comm_kernel.py", line 148, in <lambda>
    embedding_map.retrieve_object(kernel._read_int32()),
  File "/modules/artiq/artiq/compiler/embedding.py", line 118, in retrieve_object
    return self.object_forward_map[obj_key]
KeyError: 2895

[jordens]

That's an old ARTIQ version (mismatch between bitstream and host code). But the error is late enough that you should have output from the DAC and the TRFs.

[gkasprow]

I don't see any output. Which commits of artiq and phasern shoul I use? For the moment I'm using: artiq:

  2fba3cfc78252d2b87d4e005099deee4d08c60dc
  d517d5d4421ae9f31ae556f458fdb2f63e4d1abd
  f0959fb8
  master
* phaser

phaser:

  2fba3cfc78252d2b87d4e005099deee4d08c60dc
  cd2a893
  d517d5d
* d517d5d4421ae9f31ae556f458fdb2f63e4d1abd
  master

[jordens]

If the asterisk marks your HEAD, then the Phaser commit is ok (use the bitstream and example from that). It doesn't tell me what ARTIQ commit you are using. In any case you need to make sure that the bitstreams on the devices also match those commits, not just the code on your computer. I've pushed v0.4 with explicit ARTIQ and misoc commits that I tested.

[jordens]

Also why does the host-gateware-firmware mismatch detection seem to be broken? @sbourdeauducq ?

[jordens]

If you run the script to completion, comment out this line to not put the DAC and the TRFs to sleep.

[sbourdeauducq]

Works for me...

sb@vulcan ~/a/a/e/kc705_nist_clock (master)> nix-shell "<artiq-fast/shell-dev.nix>"
sb@vulcan ~/a/a/e/kc705_nist_clock (master)> artiq_run repository/mandelbrot.py
WARNING:artiq.coredevice.comm_kernel:Mismatch between gateware (6.7372.a6523995.beta) and software (6.7370.29c940f4.beta) versions
               ...............................................................
             .....................,,,,,,,,,,,.................................
            .............,,,,,,,,,,,,,,,,,,,,,,,,,,,,,........................
          ..........,,,,,,,,,,,,,,,,,,,,,,,----------,,,,,,...................
         ........,,,,,,,,,,,,,,,,,,,,,------::;h+;::-----,,,,,................
       .......,,,,,,,,,,,,,,,,,,,,,--------:::;+MMhM :------,,,,,.............
[...]

Do you have a repro?

[kaolpr]

@gkasprow asked me to help him with this. We've managed to get rid of this KeyError: 2895 error (wrong MiSoC version). Now example script from phaser gw repo finishes with no errors. However, Greg reports no output on DAC.

I tried to use test mode by doing:

f.channel[0].set_duc_cfg(select=1)
f.channel[1].set_duc_cfg(select=1)
while True:
    f.channel[0].set_dac_test(0x0)
    f.channel[1].set_dac_test(0x0)
    delay(500*us)
    f.channel[0].set_dac_test(0xFFFFFFFF)
    f.channel[1].set_dac_test(0xFFFFFFFF)
    delay(500*us)

Unfortunately, it did not give any output on DAC. @jordens are we missing something?

[gkasprow]

Actually, I observe 475...478mV DC on all DAC output pins.

[jordens]

https://github.com/sinara-hw/Phaser/issues/116#issuecomment-699875812 ?

[kaolpr]

Yes, I did comment out L63.

[kaolpr]

And when I tried to use test mode the code never reached L63 either.

[jordens]

What's "test mode"? You said you can run the script to the end. If you can run the example.py script (artiq/phaser commits and bitstreams as in v0.4) to the end with that line commented out there should be dac output everywhere.

[kaolpr]

What's "test mode"?

I believe the mode that corresponds to set_duc_cfg(select=1)? Then set_dac_test() sets value that is output to DAC, am I right? At least that's what I tried when Greg reported that after example.py was finished with line 63 commented out (artiq/phaser commits as in v0.4 note) there was no output on DAC.

[jordens]

It sets the value that's sent to the dac.

[gkasprow]

Is there any kind of HW failure that can lead to such an issue? Is the data integrity checked by the DAC somehow? There is a PARITY line, I assume DAC would set an alarm if something was wrong. @kaolpr had issues with DAC initialization on this particular board, but the current code seems to work. The DAC does something, at least it sets the DC value correctly.

[jordens]

I don't know. init() runs lots of different tests, including several iotest. Parity check is enabled. So is every alarm that the datasheet describes. Some will turn of the DAC outputs if they trigger. If the example script runs to the end (dac_sleep and trf_ps disabled) and does not indicate a relevant alarm by then, there should be output. Maybe check on a scope for transient output until the alarm triggers after the script is long done. As mentioned above the sinara_tester script will also create outputs.

[hartytp]

@jordens Digging through the issues, I've lost track of what data you took. I see that you measured a higher than expected current draw with the upconverters. Did you measure anything / anything unexpected with the baseband version?