Add comment about asynchronous inputs

urukul.py

@@ -470,7 +470,22 @@ class Urukul(Module):
 
         self.comb += [
                 cfg.en_9910.eq(en_9910),
+                # Important note regarding the chip-select (CS) signals (`eem[3].i`, `eem[4].i`, `eem[5].i`):
+                # These CS signals are generated by the Kasli SPI controller and used to select specific Urukul SPI targets.
+                # Some of these SPI targets rely on the CS signals to drive asynchronous inputs, meaning improper handling
+                # could introduce glitches.
+                #
+                # We are reasonably confident that the following combinatorial equation does not introduce glitches because:
+                #
+                # * The Kasli SPI controller drives the CS signals from DFFs on the same clock, ensuring synchronization.
+                # * The `en_nu` signal, controlled by a DIP switch, is a constant. As a result, `~en_nu & eem[5].i`
+                #   should not create differences in gate propagation delays.
+                #
+                # NOTE: As long as the combinatorial logic below remains well-formed and does not introduce unintended
+                # asynchronous behavior, the signals should remain glitch-free. However, modifications to this logic
+                # should be made with caution to avoid potential hazards or race conditions that could lead to glitches.
                 cs.eq(Cat(eem[3].i, eem[4].i, ~en_nu & eem[5].i)),
+
                 Array(sel)[cs].eq(1),  # one-hot
                 eem[2].o.eq(Array(miso)[cs]),
                 miso[3].eq(miso[4]),  # for all-DDS take DDS0:MISO