test all drivers #270

New Issue

sb10q · 2022-04-20T20:37:55+08:00

sb10q commented

2022-04-20 20:37:55 +08:00

I2C, KasliEEPROM
DIO output
DIO input (various modes)
DIO edge counter
DIO clkgen
Urukul 9910 1-EEM
Urukul 9910 2-EEM
Urukul 9910 2-EEM + sync
Urukul 9912 1-EEM
Urukul 9912 2-EEM
Sampler
Zotino
Fastino
Grabber
Phaser
Mirny
Almazny
SU-Servo
AD9914 NIST DDS

Can use artiq_sinara_tester.

- [x] I2C, KasliEEPROM - [x] DIO output - [x] DIO input (various modes) - [x] DIO edge counter - [x] DIO clkgen - [x] Urukul 9910 1-EEM - [x] Urukul 9910 2-EEM - [x] Urukul 9910 2-EEM + sync - [x] Urukul 9912 1-EEM - [x] Urukul 9912 2-EEM - [x] Sampler - [x] Zotino - [x] Fastino - [ ] Grabber - [x] Phaser - [x] Mirny - [x] Almazny - [x] SU-Servo - [ ] AD9914 NIST DDS Can use ``artiq_sinara_tester``.

mwojcik commented

2022-04-27 12:15:39 +08:00

As of 2022-04-27, I tested the devices with artiq_sinara_tester and usually they worked maybe with small fixes or workarounds.

for the untested drivers:

DIO Input/edge counter: RPC issue #101 (nothing returned making testing more difficult)

DIO clkgen: part of Urukul Sync

Urukul 9910 sync: EEPROM saves/reads OK, but cannot calibrate because of #101 and testing phase coherency is not feasible yet.

Urukul 9912 1-EEM: no hardware

Sampler: KeyError #272

Grabber: no camera to test with

Phaser: #276

SU-Servo: Need working Sampler first

AD9914: do we have the hardware, actually? That's for KC705, right?

As of 2022-04-27, I tested the devices with ``artiq_sinara_tester`` and usually they worked maybe with small fixes or workarounds. for the untested drivers: DIO Input/edge counter: RPC issue #101 (nothing returned making testing more difficult) DIO clkgen: part of Urukul Sync Urukul 9910 sync: EEPROM saves/reads OK, but cannot calibrate because of #101 and testing phase coherency is not feasible yet. Urukul 9912 1-EEM: no hardware Sampler: KeyError #272 Grabber: no camera to test with Phaser: #276 SU-Servo: Need working Sampler first AD9914: do we have the hardware, actually? That's for KC705, right?

sb10q commented

2022-04-27 13:17:52 +08:00

but cannot calibrate because of #101

Is this kind workaround feasible?

@@ -270,7 +270,7 @@ class SinaraTester(EnvExperiment):
         sync_delay_seed, _ = channel.tune_sync_delay()
         self.core.break_realtime()
         io_update_delay = channel.tune_io_update_delay()
-        return sync_delay_seed, io_update_delay
+        self.urukul_sync_cb(sync_delay_seed, io_update_delay)
 
     @kernel
     def setup_urukul(self, channel: AD9910, frequency: float):
@@ -297,6 +297,11 @@ class SinaraTester(EnvExperiment):
                 channel.pulse(100.*ms)
                 self.core.delay(100.*ms)
 
+    @rpc
+    def urukul_sync_cb(self, sync_delay_seed, io_update_delay):
+        self.sync_delay_seed = sync_delay_seed
+        self.io_update_delay = io_update_delay
+
     # We assume that RTIO channels for switches are grouped by card.
     def test_urukuls(self):
         print("*** Testing Urukul DDSes.")
@@ -316,7 +321,8 @@ class SinaraTester(EnvExperiment):
             else:
                 eeprom = channel_dev.sync_data.eeprom_device
                 offset = channel_dev.sync_data.eeprom_offset
-                sync_delay_seed, io_update_delay = self.calibrate_urukul(channel_dev)
+                self.calibrate_urukul(channel_dev)
+                sync_delay_seed, io_update_delay = self.sync_delay_seed, self.io_update_delay
                 print("{}\t{} {}".format(channel_name, sync_delay_seed, io_update_delay))
                 eeprom_word = (sync_delay_seed << 24) | (io_update_delay << 16)
                 eeprom.write_i32(offset, eeprom_word)

> but cannot calibrate because of #101 Is this kind workaround feasible? ```patch @@ -270,7 +270,7 @@ class SinaraTester(EnvExperiment): sync_delay_seed, _ = channel.tune_sync_delay() self.core.break_realtime() io_update_delay = channel.tune_io_update_delay() - return sync_delay_seed, io_update_delay + self.urukul_sync_cb(sync_delay_seed, io_update_delay) @kernel def setup_urukul(self, channel: AD9910, frequency: float): @@ -297,6 +297,11 @@ class SinaraTester(EnvExperiment): channel.pulse(100.*ms) self.core.delay(100.*ms) + @rpc + def urukul_sync_cb(self, sync_delay_seed, io_update_delay): + self.sync_delay_seed = sync_delay_seed + self.io_update_delay = io_update_delay + # We assume that RTIO channels for switches are grouped by card. def test_urukuls(self): print("*** Testing Urukul DDSes.") @@ -316,7 +321,8 @@ class SinaraTester(EnvExperiment): else: eeprom = channel_dev.sync_data.eeprom_device offset = channel_dev.sync_data.eeprom_offset - sync_delay_seed, io_update_delay = self.calibrate_urukul(channel_dev) + self.calibrate_urukul(channel_dev) + sync_delay_seed, io_update_delay = self.sync_delay_seed, self.io_update_delay print("{}\t{} {}".format(channel_name, sync_delay_seed, io_update_delay)) eeprom_word = (sync_delay_seed << 24) | (io_update_delay << 16) eeprom.write_i32(offset, eeprom_word) ```

mwojcik commented

2022-04-27 13:19:17 +08:00

Is this kind workaround feasible?

Sorry, should've mentioned it before - I tried that and that causes the RPC/KeyError (#272)

> Is this kind workaround feasible? Sorry, should've mentioned it before - I tried that and that causes the RPC/KeyError (#272)

mwojcik commented

2022-04-28 15:45:22 +08:00

Urukul 9910 w/ sync works with the aforementioned workaround, after KeyError fix.

mwojcik commented

2022-04-28 16:26:10 +08:00

SUServo after minor modifications to the code seems to suffer from the same issue as Phaser (#276).

Looks like there's DIO Clkgen left to test from the hardware that we do have.

SUServo after minor modifications to the code seems to suffer from the same issue as Phaser (#276). Looks like there's DIO Clkgen left to test from the hardware that we do have.

sb10q commented

2022-04-28 21:36:19 +08:00

Try with only one thread as suggested. Change 4 to 1 here:
3f327113b2/nac3artiq/src/lib.rs (L768)

and replace nac3artiq-pgo with nac3artiq in your local ARTIQ flake.nix so recompilation takes a more reasonable time.

What about DIO input tests using a similar workaround for the lack of kernel return value passing to the host? Should be also just a small change to sinara_tester AFAICT?

And the other DIO input modes need custom kernels (since sinara_tester is meant to test hardware).

Try with only one thread as suggested. Change 4 to 1 here: https://git.m-labs.hk/M-Labs/nac3/src/commit/3f327113b25ce34519fe686bd5531ef0efa31e27/nac3artiq/src/lib.rs#L768 and replace ``nac3artiq-pgo`` with ``nac3artiq`` in your local ARTIQ ``flake.nix`` so recompilation takes a more reasonable time. What about DIO input tests using a similar workaround for the lack of kernel return value passing to the host? Should be also just a small change to sinara_tester AFAICT? And the other DIO input modes need custom kernels (since sinara_tester is meant to test hardware).

mwojcik commented

2022-04-29 12:25:04 +08:00

With these fixes, SU-Servo runs and does initialize the channels, but there's no output from Urukuls. I ran ARTIQ-7's tester without reflashing and I got the intended result.

But Phaser works fine w/ the workaround.

With these fixes, SU-Servo runs and does initialize the channels, but there's no output from Urukuls. I ran ARTIQ-7's tester without reflashing and I got the intended result. But Phaser works fine w/ the workaround.

mwojcik commented

2022-04-29 16:30:11 +08:00

DIO ClockGen and Edge Counter work fine. DIO Input requires the workaround in artiq_sinara_tester but otherwise works fine.

SUServo is the only problematic driver that requires more investigation.

DIO ClockGen and Edge Counter work fine. DIO Input requires the workaround in ``artiq_sinara_tester`` but otherwise works fine. SUServo is the only problematic driver that requires more investigation.

👍 1

mwojcik commented

2022-05-04 17:34:54 +08:00

After meddling with SUServo I could not pinpoint the exact issue. From artiq_sinara_tester looks like the code is running proper up to the point where the channel is actually enabled (LED is green on Urukul, but no output).

Asserts with checking status are commented out, but uncommenting them and checking manually (ie. getting the status and using print_rpc to indicate if status is ok) got me to the point that I know that the driver hangs on any kind of read - and more precisely, at the call to rtio_input_data. I tried inserting some logging into the firmware part, however that gave me no logs at all through UART (maybe I forgot to set something there, wouldn't be surprised). The hang there does not explain why things are not really enabled still - as these calls are indeed commented out in normal code. Surely there will be more investigation required.

(sorry for the close, misclick!)

After meddling with SUServo I could not pinpoint the exact issue. From ``artiq_sinara_tester`` looks like the code is running proper up to the point where the channel is actually enabled (LED is green on Urukul, but no output). Asserts with checking status are commented out, but uncommenting them and checking manually (ie. getting the status and using ``print_rpc`` to indicate if status is ok) got me to the point that I know that the driver hangs on any kind of read - and more precisely, at the call to ``rtio_input_data``. I tried inserting some logging into the firmware part, however that gave me no logs at all through UART (maybe I forgot to set something there, wouldn't be surprised). The hang there does not explain why things are not really enabled still - as these calls are indeed commented out in normal code. Surely there will be more investigation required. (sorry for the close, misclick!)

mwojcik closed this issue

2022-05-04 17:34:55 +08:00

mwojcik reopened this issue

2022-05-04 17:34:58 +08:00

sb10q commented

2022-05-04 17:37:33 +08:00

Asserts with checking status are commented out, but uncommenting them and checking manually (ie. getting the status and using print_rpc to indicate if status is ok) got me to the point that I know that the driver hangs on any kind of read - and more precisely, at the call to rtio_input_data.

In that case I suggest writing a MWE that reads something from SU-Servo using the legacy compiler, then port that to NAC3 and check what is going on.

Hanging on rtio_input_data looks like the SU-Servo PHY should have put something into the input FIFO (due to commands having been sent to it) but has not. Probably a wrong command is being sent.

> Asserts with checking status are commented out, but uncommenting them and checking manually (ie. getting the status and using print_rpc to indicate if status is ok) got me to the point that I know that the driver hangs on any kind of read - and more precisely, at the call to rtio_input_data. In that case I suggest writing a MWE that reads something from SU-Servo using the legacy compiler, then port that to NAC3 and check what is going on. Hanging on ``rtio_input_data`` looks like the SU-Servo PHY should have put something into the input FIFO (due to commands having been sent to it) but has not. Probably a wrong command is being sent.

mwojcik commented

2022-05-19 12:23:00 +08:00

SU-Servo now works (tested w/ one Urukul, but that shouldn't change much) - albeit again with the change to make the compiler singlethreaded.

And so does Urukul 9912 1-EEM.

SU-Servo now works (tested w/ one Urukul, but that shouldn't change much) - albeit again with the change to make the compiler singlethreaded. And so does Urukul 9912 1-EEM.

sb10q referenced this issue

2022-05-28 12:56:34 +08:00

SUServo: Variable with the same name doesn't get overwritten in some cases? #285

Sign in to join this conversation.