-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mock array element simpler constraints sdc #1969
Mock array element simpler constraints sdc #1969
Conversation
mock-array/Element has no timing closure failures when looking at register to register paths. There are timing violations for the optimization targets, but no hold cells are added:
|
82e8e26
to
7dc3009
Compare
use bitwise or instead of 64 bit addition to close timing in Element Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
7dc3009
to
51cb48d
Compare
Looks good for mock-array:
|
Looks good for mock-array/Element:
|
@rovinski What do you think about this approach for architectural exploration? Architectural exploration, the goal of mock-array, is a completely separate concern to an actual tape-out. For an actual tape-out I would expect sharper(more accurate and precise) more macro and context specific constraints.sdc files would be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SDC is a rich language and I think its great that you are able to have a simple SDC like this to cover both cases and constrain the design to work the way you want it.
|
Sounds good. I want to leave that as a future improvement as I'm a little bit unsure that it is true. What I'm trying to do is to ask the optimizer to do it's best for a macro where the inputs/outputs are registered. I'm wondering if these numbers are in fact constants that relate to how long it takes for the PDK to go through the input/output buffers. I'm loath to add comments about this to the constraints.sdc, because it is a bit early days in my understanding. ChatGPT would probably write something more comprehensible than the drivel that I could currently come up with with my current understanding... :-) |
This is an attempt to simplify mock-array/Element/constraints.sdc
From the following observations, all else follows: the only thing that can fail timing closure, is a register to register path. All other constraints gives the flow an optimization target. Failure to meet the timing constraint of an optimization target constraint is not a timing closure failure.
Note that ORFS regression checks does not have the ability to distinguish between timing closure failures(register to register paths) and optimization constraints violations(which may or may not cause timing violations later on higher up in mock-array).
For the Element constraint.sdc, the only register to register path are within the Element(recently added) and no lowe level macros are involved. These have to be checked at the Element level as they are invisible higher up in mock-array.
As for the remaining optimization constraints for Element, they should be for through paths and from input pins to register and from register to output pins.
The clock latency & tree should be ignored as far constraints go; it is not part of the optimization constraints and is accounted for in register to register paths timing closure paths within the Element. Also the clock tree higher up will take the clock tree insertion latency of the Element into account when balancing the clock tree.
The timing closure for the register to register paths between Elements is checked at the mock-array level.
With this in mind, the constraints.sdc file for the Element becomes quite general and simple. set_max_delay is used exclusively for optimization constraints and the clock period is used to check timing closure for register to register paths. set_input/output_delay are not used.