The RTL design community tends to be verification centric, with the majority of the engineers having front-end RTL and verification expertise and a minority with back-end synthesis and place-and-route expertise. RTL engineers tend to focus on building functional RTL, simulating it to ensure that the code does what it is intended to do. They have traditionally seen full synthesis as a back-end issue. PPA and coding issues are typically afterthoughts, considered late in the design cycle. Until now, RTL engineers also haven’t had a tool or methodology that could absorb PPA feedback within their RTL design toolkit.
Without a means to explore and understand the impact of the block-level RTL at the higher level (partition, sub-chip, or chip), there hasn’t been an easy way to perform fast, incremental RTL synthesis. As a result, issues aren’t detected until weeks or months later, after the RTL has been handed over to the physical chip design team for implementation. By this time, it’s often too difficult to change the design to improve PPA. Changes could break test, timing, and power constraints. Instead, it is left to the backend team to improve PPA. However, waiting until the place-and-route stage to improve PPA leads to smaller PPA gains and longer runtimes. Improving PPA during implementation is even more challenging at advanced nodes since moving cells and wires is more difficult due to the plethora of foundry rules that must be obeyed.
Another common scenario that occurs is synthesis of the RTL with wide margins. The RTL design is then taken into placement and routing, where back-end engineers must contend with over-margining and apply optimization techniques to hit their PPA requirements. However, the further down the chip design flow, the less impact any changes will make. So, this approach is not geared toward making a meaningful impact on the design, nor does it allow engineers the flexibility of positioning their products in an opportune way.