Changes to PHY Layer

Comparing version 2.1 to 2.0
+60 additions -18 deletions
@@ -1,5 +1,5 @@
11 <div style="font-size: 0.85em; color: #656d76; margin-bottom: 1em; padding: 0.5em; background: #f6f8fa; border-radius: 4px;">
2-đź“„ Source: <a href="https://github.com/chipsalliance/i3c-core/blob/aae3424a8ecbd4edb7a60e23f76421de2d891712/doc/source/phy.md" target="_blank">chipsalliance/i3c-core/doc/source/phy.md</a> @ <code>aae3424</code>
2+đź“„ Source: <a href="https://github.com/chipsalliance/i3c-core/blob/bb79ebd9b487c61cd1bea1aec2574ae4740f104d/doc/source/phy.md" target="_blank">chipsalliance/i3c-core/doc/source/phy.md</a> @ <code>bb79ebd</code>
33 </div>
44
55 # Physical Layer
@@ -74,27 +74,69 @@
7474 T_SU_DAT_REG = reg_val > 0 ? reg_val : 0
7575 ```
7676
77-For system clock frequencies below 320MHz, the core should be configured with the `DisableInputFF` parameter set to `True` (see [example configuration](https://github.com/chipsalliance/i3c-core/blob/main/i3c_core_configs.yaml#L49))
78-This parameter removes one flipflop on the input lines, shortening the response latency.
77+The core supports system clock frequencies above 333MHz, and SCL frequencies up to 12.5MHz. Below 333MHz Tsco I3C timing requirement of 12ns is not met. I3C specification defines Tsco as “Clock to Data Turnaround Time: The time duration between reception of an SCL edge and the start of driving an SDA change”. With 333MHz clock the maximum response time from the core is 12ns. This timing is not affected by the chip pads delays as per MIPI CSI I3C 1.1.1 specification.
7978
80-The core provides 2 configurations with the `DisableInputFF` parameter set to `True`.
81-In order to generate a configuration with the parameter set, run the following command from the top level of the I3C repository:
79+The I3C core needs 3 system clock cycles between an event on a SCL line and driving the SDA. Since SCL and core clock are asynchronous, SCL can drop just after rising edge of the system clock. Such situation adds an additional clock cycle latency resulting in 4 cycles in total.
80+
81+Maximal I3C core Tsco can be calculated with the Tsco = 4 * Tsys_clk formula , where Tsys_clk is a system clock period.
82+
83+```{warning}
84+The minimum frequency calculation (333MHz) accounts only for the
85+I3C core internal logic delay. It does **not** include timing delays
86+introduced to and from the PADs. Integrators must account for these additional
87+delays when selecting the system clock frequency.
88+```
89+
90+Future core releases will enable the GETMXDS CCC support allowing the core to advertise longer Tsco times for lower system clock frequencies.
91+
92+
93+### SDA Output Path and Output Enable
94+
95+The SDA output path uses a dedicated output enable (`sda_oe`) signal in addition to the
96+data value (`sda_o`). The `bus_tx_flow` module computes both based on the drive mode
97+(Open Drain or Push-Pull) and the data value being transmitted:
8298
8399 ```
84- make generate CFG_NAME=ahb CFG_FILE=i3c_core_configs.yaml
100+sda_oe = drive_mode_is_pushpull OR (NOT data_msb)
85101 ```
86102
87-or
103+The resulting truth table for the SDA pad:
88104
105+| sel_od_pp | sda_o | sda_oe | IO State |
106+| ----------- | ------- | -------- | ---------- |
107+| 0 (OD) | 0 | 1 | Drive Low |
108+| 0 (OD) | 1 | 0 | High-Z (released) |
109+| 1 (PP) | 0 | 1 | Drive Low |
110+| 1 (PP) | 1 | 1 | Drive High |
111+
112+
113+In Open Drain mode, the pad is released (High-Z) when driving a logical 1, allowing
114+the external pull-up to assert the line. In Push-Pull mode, the pad actively drives
115+both high and low.
116+
117+The PHY module (`i3c_phy.sv`) passes these signals through to the pad interface:
118+
119+- `ctrl_sda_oe_i` -> `ctrl_sda_oe_o` (output enable passthrough)
120+- `sel_od_pp_i` -> `sel_od_pp_o` (drive mode passthrough)
121+
122+### I/O Signal Routing Constraints
123+
124+All six I3C bus I/O signals (`scl_i`, `sda_i`, `scl_o`, `sda_o`, `scl_oe`, `sda_oe`)
125+must be routed together in physical design. The two-flop synchronizers
126+(`scl_synchronizer`, `sda_synchronizer`) and the output-path flops should be placed
127+close to the I/O pads to minimize routing skew between input and output paths.
128+
129+Keeping the synchronizing flops and output flops near each other and near the pads
130+ensures that:
131+
132+1. Input sampling latency is minimized and consistent across SCL and SDA.
133+2. Output drive timing (t{sub}`SCO`) is not degraded by long internal routing.
134+3. Skew between `sda_o` / `sda_oe` and the corresponding `sda_i` sample point
135+ remains within the timing budget described in the
136+ [I3C timing configuration](#i3c-timing-configuration) section above.
137+
138+```{note}
139+The `sel_od_pp_o` (Open Drain / Push-Pull select) signal should also be routed
140+alongside `sda_o` and `sda_oe` since it directly controls the pad driver mode
141+and must be stable before the pad switches drive state.
89142 ```
90- make generate CFG_NAME=axi CFG_FILE=i3c_core_configs.yaml
91-```
92-
93-Depending on the chosen bus interface.
94-More Information about the configuration tool can be found in the relevant [README](https://github.com/chipsalliance/i3c-core/blob/main/tools/i3c_config/README.md)
95-
96-Example configurations:
97-
98-* 160MHz system clock (minimal operting clock) - `DisableInputFF=True`, `T_SU_DAT_REG=0`
99-* 400MHz system clock - `DisableInputFF=False`, `T_SU_DAT_REG=0`
100-* 1GHz system clock - `DisableInputFF=False`, `T_SU_DAT_REG=2`