retiming: add some more docs#3417
Conversation
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
|
|
||
| Architectural or manual retiming, as opposed to automatic retiming, is | ||
| usually preferred, because LEC(Logic Equivalence Check) will not work | ||
| together with automatic retiming. |
There was a problem hiding this comment.
There's no reason LEC cannot be done with automatic retiming, it's just more challenging.
There was a problem hiding this comment.
Good point. I think these docs should stick strictly to what to expect from the current retiming implementation and not try to give any context about what retiming is.
|
|
||
| The main use-case for automatic retiming is to quickly identify if | ||
| performance is left on the table and can be gained with architectural | ||
| retiming. Architectural retiming also has the advantage that it can change |
There was a problem hiding this comment.
Architectural retiming also has the advantage that it can change the semantics of the RTL code limited only by not breaking the application, hence retiming can't estimate this performance potential.
It took me a second to understand this sentence. I think it's better left out.
Architectural retiming can also consider placement and routing, whereas automatic retiming only considers information available at synthesis time.
Fwiw one could implement retiming more aware of physical effects.
There was a problem hiding this comment.
Yes: delete any drivel that I may have added :-)
At first I thought I had an example of physical effects being important for retiming, but when I removed the synchronous reset from the pipelining registers in the multiplier, the correlation between synthesis and global route was much stronger, so I don't have an example use-case where taking physical effects into account would be important.
|
@maliberty @povik Closing for now. @povik Can you add some well chosen words after investigations and conclusions? |
2 participants
No description provided.