The SoC design teams are usually divided between front-end and back-end specialties. It is neither practical nor advisable to combine the two teams in order to better tackle the back-end issues upfront during the front-end design. However, a common problem is that the issues at the layout stage have very little scope for resolution unless the design team is ready to overhaul the design again from front-to-back. The net result is – either live with unworthy work-arounds in the layout or extend the design window which may be risky from the perspective of losing business. What if we had an automated way to let the front-end engineers know about the physical quality of a design, issues to be addressed, and tools to fix and debug at the RTL stage? Without needing intensive back-end design expertise, they should be able to fix the physical issues in the RTL. Better quality RTL will flow smoothly through the back-end tools such as physical synthesis and place & route without any severe issues to be addressed at the layout stage. The created layout can be much better quality the first time. Naturally, the end result will be a faster design closure with better quality of the design. Let’s look at an example:
Multiplexers (Mux) are very common in designs. A wide mux can contain a large number of inputs and a single output whereas a deep mux can contain a large number of select lines. The complexity created by a wide and deep mux can have severe implications in routability down the stream which in-turn can cause several issues including layout congestion, signal integrity and timing. A back-end designer will run through several P&R iterations and still will not be able to fix such issues satisfactorily at the layout stage. This needs to be better handled architecturally at the RTL stage, provided such implications downstream can be provided at the RTL stage.
I was impressed with Atrenta’s“Physical Lint” methodology where they have a large number of expert physical rules that can be applied to the RTL code of a design to understand its quality from the physical perspective. The checks against these rules can flag complexity issues beyond particular thresholds for complex structures such as a large mux as discussed above and others like large logic cones, cell pin densities, and so on. Having awareness about such physical implications at the RTL stage, the front-end engineers can easily fix such issues in the RTL code and do light-weight trials at the RTL stage.
To assist the front-end engineers, SpyGlass Physical has an excellent GUI for physical rule analysis and debug. The complex structures can be automatically inferred and their complexity scores listed in an ordered list, along with their references in the source code. The RTL source code can be cross probed with the schematic. The front-end engineers can take corrective actions to simplify complex structures and re-run physical rule analysis to lower the complexity scores. For example, in case of the mux as depicted in the picture above, the mux traffic can be distributed or spread more efficiently across the design. By using this method, the front-end engineers can easily comprehend the impact of complex structures on downstream tools and improve quality of the RTL to be handed over to the back-end team.
It has been observed that the design utilization can be improved significantly by resolving logic structure violations in the RTL. In the above design examples, priority was given to resolve the highest scored items, leaving remaining violations unresolved. The methodology and effort to be put on resolving the structural issues before signing off the RTL is left to the discretion of the design teams.
The RTL improvement through resolution of complex logic structures leads to faster and predictable design convergence with better quality metrics of the design. More information about the SpyGlass Physical Lint methodology can be obtained from the customer support team at Atrenta.
Pawan Kumar Fangaria
Founder & President at www.fangarias.com