Add register access time to spec

source/hw-spec/controller/channels/data_frames.rst

@@ -17,7 +17,7 @@ The frame format is:
     uint32  sample_sz
     var     sample
 
-Where
+where
 
 - ``dev_addr``: Device Address. The address of the device producing the data, as
   featured on the :ref:`device table <dev-table>`.

source/hw-spec/controller/channels/signal_channel.rst

@@ -60,18 +60,41 @@ channel is also used to asynchronously acknowledge register access via the
 :ref:`configuration channel <conf-chan>`. Following a device register read or
 write, an CONFIGWACK, CONFIGWNACK, CONFIGRACK, or CONFIGRNACK signal is pushed
 onto the signal stream by the controller to indicate the validity of the
-transaction. In the case of a successful read, the CONFIGRACK flag will be
-followed by the result of the read operation. In all other cases, the flag will
-be sent with no additional data.
+transaction. Successful transactions will include the following timing
+fields:
+
+::
+
+    uint64  reg_time
+    uint64  reg_hub_time
+
+where
+
+- ``reg_time``: Time when this register access acknowledge was
+  received by the controller. Based on the :ref:`acq_clk`.
+- ``reg_hub_time``: Register access time as reported by
+  the :ref:`device <dev-reg-time>`.
+
+In the case of a successful read, the CONFIGRACK flag will also be
+followed by the result of the read operation after the time fields.
+In all other cases, the flag will be sent with no additional data.
 
 For instance, on a successful register read:
 
 ::
 
-    ... | CONFIGRACK, uint32 read_value | ...
+    ... | CONFIGRACK, uint64 reg_time, uint64 reg_hub_time, uint32 read_value | ...
 
-While on a succesful register write:
+While on a successful register write:
 
 ::
 
-    ... | CONFIGWACK | ...
+    ... | CONFIGWACK, uint64 reg_time, uint64 reg_hub_time | ...
+
+And on a failed register read or write
+
+::
+
+    ... | CONFIGRNACK | ...
+    ... | CONFIGWNACK | ...
+

source/hw-spec/devices/datasheet.rst

@@ -52,6 +52,8 @@ this table, but it MUST contain the following columns:
 -  **Access**: Read-only, Write-only, or Read/Write.
 -  **Time of Effect**: When does a register write affect hardware state?
    Immediately or following soft reset?
+- **Access time report**: If device will report the :ref:`access time <dev-reg-time>`
+  for this register.
 -  **POR Value**: Power-on or :ref:`hard reset <hard_reset>` default value.
 -  **Reset Action**: Upon a :ref:`soft reset <soft-reset-reg>`, what happens to the register? Does it
    maintain its previous state or get reset to some value? If the latter, then

source/hw-spec/devices/registers.rst

@@ -44,16 +44,35 @@ soft reset. An example of this type of behavior is registers that operate on the
 runtime, but registers affecting it might take action after a soft reset,
 providing an updated descriptor to the controller.
 
-Register access, bit-field definitions, reset behavior, and time of effect MUST
-be specified in the hardware datasheet for raw registers or the :ref:`ONI Device
+.. _dev-reg-time:
+
+Devices SHOULD inform the :ref:`controller` of the time when a register access
+has been acknowledged. For read accesses, this is the time at which the value is
+retrieved by the device. For write accesses, its meaning depends on the register
+effect timing:
+
+- For registers with an immediate effect, the acknowledge time SHOULD be
+  as close as possible to the time the effect occurs (e.g.: when the
+  communication with the underlying hardware is finished)
+- For other register types, when the value is written to the device
+
+The time reported by the devices MUST use the same counter source and format as
+the ``hubclk_cnt`` field of their :ref:`data samples <dev-sample>`. If a device
+does not provide the time of a register access, the time MUST be of value
+0xFFFFFFFFFFFFFFFF. Access time reporting MAY be implemented in all or some of
+the registers of any device.
+
+Register access, bit-field definitions, reset behavior time of effect
+and access time reporting description MUST all be specified in the
+hardware datasheet for raw registers or the :ref:`ONI Device
 Datasheet <dev-datasheet>` for managed registers.
 
 .. _dev-reg-map:
 
 Register Map
 -------------
 
-A device can optionally implement raw registers and MUST implement at least one
+A device MAY implement raw registers and MUST implement at least one
 managed register, ``ENABLE``. This register's behavior MUST conform the
 following rules:
 

source/hw-spec/hubs.rst

@@ -11,7 +11,8 @@ They can be independent hardware aggregates connected to the controller
 Every hub MUST have access to a high-resolution monotonic counter (typically
 driven by a high-resolution crystal oscillator, resonator, PLL, etc.). All
 devices within a hub MUST use the values of this counter for the ``hubclk_cnt``
-field of their :ref:`data samples <dev-sample>`.
+field of their :ref:`data samples <dev-sample>` and the
+:ref:`register access time <dev-reg-time>`.
 
 Hubs that exist on hardware that is physically separated from the
 :ref:`controller <controller>` are referred to as remote hubs, while hubs