You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It isn't possible to articulate a single .sdc file that exactly captures the
94
-
constraints of an Element as each element is used in unique circumstances.
95
-
Instead, a choice has to made and each choice has its pros and cons.
96
-
97
-
It is relatively easy to set up a maximum input/output delay for paths
98
-
that start or end in a register, so this case is not discussed here.
99
-
100
-
It is the combinational(unregistered) in -> out
101
-
paths that are tricky to create constraints for.
102
-
103
-
- Strategy used as of writing: mark non-registered/combinational paths through
104
-
the Element as false paths. This will not steer the tools to optimize the
105
-
through element path, such as discussed above and there's no timing information
106
-
available at the Element level for these combinational paths.
107
-
However, at the `MockArray` level when the Elements are used, timing will
108
-
be checked, because the .lib file generated for the Element contains timing
109
-
information, even for false paths.
110
-
- Use `set_max_delay` for combinational paths. This will make the tool try
111
-
to optimize the combinational path and there will be timing information available.
112
-
However, path segmentation could occur with OpenSTA. Refer [here](https://docs.xilinx.com/r/2020.2-English/ug906-vivado-design-analysis/TIMING-13-Timing-Paths-Ignored-Due-to-Path-Segmentation).
113
-
- Overconstrain: set up a maximum input/output path for the element and ignore
114
-
timing violations at the Element level for combinational paths.
115
-
The timing violations for the combinational paths are not real violations,
116
-
because the maximum input and output paths can not occur at the same time
117
-
in the array. The leftmost Element has the shortest maximum input path and
118
-
and the rightmost the longest maximum input path for
119
-
`assign io_lsbOuts_0 = io_lsbIns_1;`. The OpenROAD tool could put too much
120
-
emphasis on optimising the combinational path in this case, which could
121
-
lead to less than optimal results and/or inflated run times.
39
+
CTS
40
+
---
41
+
42
+
mock-array and mock-array Element are intended
43
+
to be fitted into a higher level module where CTS creates a balanced clock tree
44
+
that takes the mock-array and mock-array Element clock insertion
45
+
latency into account. This means that the optimization target
46
+
for mock-array and mock-array Element have zero skew.
47
+
48
+
constraint.sdc shared between mock-array and mock-array/Element
From the following observations, all else follows: the only thing
52
+
that can fail timing closure, is a register to register path. All
53
+
other constraints give the flow an optimization target. Failure
54
+
to meet the timing constraint of an optimization target constraint
55
+
is not a timing closure failure.
56
+
57
+
Note that ORFS regression checks does not have the ability to distinguish
58
+
between timing closure failures(register to register paths) and
59
+
optimization constraints violations. Timing violations for optimization constraints
60
+
in mock-array Element, such as maximum transit time for a combinational path
61
+
through mock-array Element, may or may not cause timing
62
+
violations later on higher up in mock-array on register to register paths.
63
+
64
+
For the Element constraint.sdc, the only register to register path
65
+
are within the Element and no lower level macros are
66
+
involved. Register to register paths within Element have to be checked
67
+
at the Element level as they are invisible higher up in mock-array.
68
+
69
+
As for the remaining optimization constraints for Element, they
70
+
should be for combinational through paths and from input pins to register and
71
+
from register to output pins.
72
+
73
+
The constraints.sdc file is designed such that the clock latency & tree
74
+
can be ignored as far constraints go;
75
+
it is not part of the optimization constraints. The clock tree latency
76
+
is accounted for in register to register paths within.
77
+
78
+
The timing closure for the register to register paths between
79
+
Element macros is checked at the mock-array level.
80
+
81
+
With this in mind, the constraints.sdc file for the Element becomes
82
+
quite general and simple. set_max_delay is used exclusively for
83
+
optimization constraints and the clock period is used to check timing
84
+
closure for register to register paths.
85
+
86
+
set_input/output_delay are not used and can't really be used
87
+
with the requirement that the constraint.sdc file should be articulated
88
+
without making assumptions on the clock tree insertion latency. The time specified
89
+
for set_input/output_delay is relative to the clock insertion point, i.e.
90
+
the time at the clock pin for the macro, which makes it impossible to articulate
91
+
the number that is passed in to set_input/output_delay without taking
92
+
clock network insertion latency into account.
93
+
94
+
Since set_input_delay is not used and set_max_delay is used instead, then
95
+
no hold cells are inserted, which is what is desired here.
96
+
97
+
Beware of [path segmentation](https://docs.xilinx.com/r/2020.2-English/ug906-vivado-design-analysis/TIMING-13-Timing-Paths-Ignored-Due-to-Path-Segmentation), which
0 commit comments