Bridging the gap between IP development and qualification for P&R
Mentor, a Siemens business, is looking to bridge the long-standing gap between IP development and IP qualification with a targeted flow for its Oasys-RTL floorplanning and physical synthesis tool. The methodology is explained a new white paper.
Both internal and third-party IP blocks tend to be developed in isolation. Separate teams have separate competences and the blocks are frequently intended for re-use and integration across multiple SoC projects.
This ‘sandbox’ approach is therefore unlikely to change soon but means that IP is created with little, if any reference to the specific chips on which it is to be used. If a floorplan shows timing and congestion issues, it follows that ultimately tracing these back to an uncontextualized IP block can be extremely difficult and time-consuming.
At the same time, IP typically comes with an associated and pre-qualified set of specifications that must be maintained the final design. The wrong kind of ‘tinkering’ could easily invalidate the entire SoC.
Moving IP qualification up the flow
The Mentor response is to pull upon the ‘PlaceFirst’ technology within Oasys RTL. As its name suggests, this raises placement and floorplanning up the design flow so that it takes place during RTL development and ahead of synthesis.
Oasys-RTL does this by synthesizing RTL into virtual physical partitions. Each partition is optimized and implemented as placed gates. If necessary, the RTL is repartitioned until design specifications are met, both those dedicated to the design and those inherent in an IP block. The outputs from Oasys-RTL comprise a netlist and a DEF file to pass on for place-and-route.
As Figure 1 shows, this effectively combines two steps within the flow to shorten time and reduce iterations.
Figure 1. Toward an integrated RTL level sign-off flow enabling early IP qualification (Mentor)
The white paper explains the process in more detail:
“Oasys-RTL can perform RTL-level floorplanning and analyze timing, power and congestion along with physical synthesis to qualify the IP. This enables quick iterations at the RTL level to analyze and improve the floorplan and utilization of the IP.
“With Oasys-RTL, designers can perform timing and congestion analysis during RTL synthesis and make changes to the RTL if need be to improve the quality of results. The ability to validate the timing and congestion metrics for the IP before physical implementation significantly minimizes the number of frontend-to-backend iterations.”
Breaking down IP qualification
The paper’s authors specifically describe the use of the tool in the context of four IP qualification processes:
- Analyzing timing bottlenecks
- Analyzing congestion hot-spots in the RTL design
- Validating RTL with different floorplan configurations
- Timing and congestion analysis correlation to place and route
They also set out a checklist of eight questions IP qualification must resolve before RTL is handed off for physical implementation.
- Will the IP have physical and timing related challenges during implementation?
- Would the same RTL code be implementable across different floorplan cut outs?
- How close will the PPA predictions early in the design cycle follow implementation?
- How will we provide the data flow diagram to synthesis tools?
- How can we avoid costly P&R iterations to converge on timing/congestion?
- How can we avoid making last minute RTL changes to fix timing/congestion?
- Can we get a good power estimation early in the design cycle?
- Can we accurately identify power hot-spots and fix them in RTL?
‘IP qualification with Oasys-RTL‘ is available now and you can also learn more about Oasys-RTL here.
