M-Labs
/
nac3
8
0
Fork 5
Code Issues 87 Pull Requests 3 Releases Wiki Activity

test all drivers #270

New Issue
Open
opened 2022-04-20 20:37:55 +08:00 by sb10q · 11 comments
sb10q commented 2022-04-20 20:37:55 +08:00
Owner
  • 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
Owner

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
Poster
Owner

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
Owner

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
Owner

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

Urukul 9910 w/ sync works with the aforementioned workaround, after KeyError fix.
mwojcik commented 2022-04-28 16:26:10 +08:00
Owner

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
Poster
Owner

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
Owner

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
Owner

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
Owner

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 reopened this issue 2022-05-04 17:34:58 +08:00
sb10q commented 2022-05-04 17:37:33 +08:00
Poster
Owner

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
Owner

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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
enhance/issue-149-ndarray/numpy-func-take-ndarray
master
enhance/cargo-test-standalone-demos
issue-136
rpc-obj-as-param
no_init
iterators
escape-analysis
refactor_anto
Labels
Clear labels   
UROP0622
   
future-extension
   
high-priority
   
low-priority
No Label
UROP0622
future-extension
high-priority
low-priority
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nac3#270
There is no content yet.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?