@@ -165,21 +165,21 @@ fn recurse_down_expression(
165165 }
166166}
167167
168- /// The basic way latency count inference works is as follows:
169- /// On the module interface, ports may be marked with latency annotations.
168+ /// The basic way latency count inference works is as follows:
169+ /// On the module interface, ports may be marked with latency annotations.
170170/// These annotations can be simple constants (portA'0, portB'-3, etc),
171171/// or larger expressions involving some template parameter, such as portC'L, portD'L+3-2
172172///
173173/// Whereever there is a difference in the latency annitation between two ports of exactly
174174/// 1x a variable + some constant offset, the port pair becomes eligible for latency inference
175- ///
176- /// When the module is flattened, we can immediately construct for every template parameter,
177- /// a list of all port pairs that may be used to infer the value of this parameter.
178- ///
175+ ///
176+ /// When the module is flattened, we can immediately construct for every template parameter,
177+ /// a list of all port pairs that may be used to infer the value of this parameter.
178+ ///
179179/// Once we come to actually performing said inference [Self::try_infer_var], we take the list
180- /// of absolute latencies we know for these ports, and take the minimum latency we could find.
180+ /// of absolute latencies we know for these ports, and take the minimum latency we could find.
181181/// This ensures that instantiating the module cannot ever expand beyond the context in which
182- /// it is inferred. Finally, all
182+ /// it is inferred. Finally, all
183183#[ derive( Default , Debug ) ]
184184pub struct PortLatencyInferenceInfo {
185185 //port_latency_groups: Vec<Vec<PortGroup>>,
0 commit comments