Complex SoC project teams typically use a divide and conquer approach where specialized engineers work in separate domains, like front-end or back-end. The five major engineering tasks for IC design can be described as: RTL design, synthesis, floor planning, place and route, then finally design analysis.
What if you could detect physical implementation bottlenecks earlier in the design process, like during RTL design? That ability would save you not only design time, but also reduce the number of iterations in trying to reach design closure and sign-off. Here’s what the design iteration cycle looks like if you wait until physical implementation and then analyze for design closure:
Related: A Complete Timing Constraints Solution – Creation to Signoff
The steps in red show that engineering has to review the results of Static Timing Analysis (STA), identify the critical paths that are limiting the clock rate, rework the floor plan, try various design optimizations, re-run STA, then maybe go all the way back to RTL and try refactoring code to eliminate the logic creating the bottleneck for closure. One EDA vendor that has studied this issue is Atrenta, and their approach to reduce design closure iterations is called Physical Lint – a step used during RTL coding that predicts the physical implementation effects of logic at an early stage:
There are logic structures identified during RTL analysis known to cause physical implementation issues, like:
- Large logic cones
- Large muxes
- Registers or memories
- Excessive register count
- Unintended black boxes for physical implementation
Related: Assertion Synthesis – From Startup to Mainstream
During physical lint the SpyGlass tool applies rules based on your actual technology mapped design to improve accuracy. For the rule about large logic cones their tool can automatically identify flip-flops with high fan-in cones, then show you how to split them up. Likewise, for flip-flops with high fan-out, the fix is to add a pipeline:
For muxes the SpyGlass Physical tool identifies both wide and deep muxes and can show you where to refactor the RTL by mux spreading, thereby reducing physical congestion.
All of the rule violations identified by SpyGlass Physical are presented in a spreadsheet viewer, and ranked based upon their physical impact so that engineers can quickly identify the RTL source code. Modifications are suggested for each rule violation, keeping the designer in control of all changes.
Related – Automatic RTL Restructuring: A Need Rather than Convenience
Mark Baker of Atrenta presented the approach of SpyGlass Physical in a 29 minute webinar, now archived and available online. The basic premise is that an ounce of prevention is worth a pound of cure, so why not use the physical lint approach in your next IC project.
Q&A
Q: Will SpyGlass Physical attempt to update my RTL?
A: Today we identify the RTL code, then suggest how to change your RTL.
Q: What physical data is required to run Physical Lint?
A: We’re using the standard Liberty format for your cell library along with the RTL source code.
Q: How does SpyGlass compare to actual logic synthesis results?
A: In physical lint we’re doing a fast synthesis process, and there’s not a need for heavy timing optimizations.
Q: How does the actual implementation compare to what SpyGlass predicts?
A: We see excellent correlation in identifying physical congestion.
Share this post via:
Next Generation of Systems Design at Siemens