Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| asic:timing:forks [2024/02/02 12:02] – [Related concepts] rajit | asic:timing:forks [2024/09/03 14:06] (current) – [Relative timing] rajit |
|---|
| there is an implicit assumption that ''a+'' and ''b-'' occur, and the methodology is most commonly used to reason about control logic where this is a common scenario. | there is an implicit assumption that ''a+'' and ''b-'' occur, and the methodology is most commonly used to reason about control logic where this is a common scenario. |
| |
| Timing fork theory states that if the two transitions are guaranteed to be ordered, then a timing fork/zig-zag that is the basis for the ordering must exist. In this sense, timing forks can be used to describe a relative | Timing fork theory states that if the two transitions are guaranteed to be ordered, then a timing fork/zig-zag that is the basis for the ordering must exist. In other words, a design that uses relative timing constraints can only be correct if a timing fork/zig-zag exists that ensures that the constraint is satisfied. |
| timing constraint. However, a timing fork doesn't require that all the transitions occur. It can also refer to only a specific instance of a signal transition if that is all that is required; for example, we could say that the ''i''th occurence of ''a+'' occurs before the ''(i+1)''th occurrence of ''b-'' rather than the ''i''th occurrence of ''b-'' (or some other such relation). | |
| |
| | It is worth noting that a timing fork doesn't //require// that all the transitions occur. This is useful when we have data-dependent timing constraints, i.e., where a signal change occurs only in certain cases based data values being computed by the circuit. |