Path: EDN Asia >> Design Centre >> IC/Board/Systems Design >> Grasp timing closure in multi-level partitioned SoCs
IC/Board/Systems Design Share print

Grasp timing closure in multi-level partitioned SoCs

20 Oct 2015  | Syed Shakir Iqbal, Mitul Soni,Gourav Kapoor

Share this page with your friends

Hence, multi-level partitioning may often turn out to be gamble in terms of improving timing and implementation closure. The returns from such a strategy depend upon the quality of interface modeling techniques and the maturity curve of the logic involved in the physical partitions itself. In the next section, we shall discuss some of the unique challenges and their possible resolutions (if any) concerning multi-level partitioning schemes.

Table: Hierarchy level of various partitions in the design shown in figure 1.

Challenges in Multi-level hierarchical timing closure and implementation
Hierarchical timing closure inherently has its short comings primarily driven by the interface uncertainties and ripple effects across physical boundaries. Apart from timing, physical restrictions further create bottlenecks in other aspects of the implementation cycle like floor-plan closure, pin placement, leakage reduction, etc. The primary factors responsible for these can be categorized as follows:

a) Physical Uncertainties:

Physical uncertainties reflect the closure uncertainties arising due to physical isolation of the hierarchical partitions during implementation. Physical uncertainties generally arise due to three factors:

i. Unpredictable data path distribution across the interface:

Data path distribution across the boundaries of partitions is highly dependent on both the partition's physical as well as logical maturity. One of the most common challenges seen as a result of this unpredictability is the complex and iterative budgeting of input/output delays across the interface boundary. To add upon this the added stage based uncertainty for placement, CTS and routing jump further makes this simple task much more iterative and implementation dependent. Let us consider the example of the multi-level partition APP_SUB_SYSTEM as shown in figure 1. We can clearly observe that at the TOP_SOG interface, there are two categories of interactions: APP_SUB_SYSTEM vs. TOP_SOG & APP_CORE vs. TOP_SOG which can be modeled as follows:



+ Stage_Margin_APP_SUB_SYSTEM
+ Stage_Margin_TOP_SOG


+ Stage_Margin_APP_CORE
+ Stage_Margin_APP_SUB_SYSTEM
+ Logic_Distribution_Inside_APP_SUB_SYSTEM
+ Stage_Margin_TOP_SOG

The above equation simply suggests that while modeling the budgets for sub-blocks in multi-level partitioned designs, the stage margin and logic distribution for all the intermediate partitions (i.e. except for the path start & end partition) has to be considered. If the budget is being driven from top, then also this budget has to be segmented into similar parts reasonably for proper implementation and timing closure. For example, let us say the top has given a margin of 10ns (50% of clock period) to an IN2REG path of APP_CORE being timed with a clock of 20ns. Now, assuming that 80% of logic is located inside APP_CORE while the remaining 20% is inside APP_SUB_SYSTEM as a through path, this implies at any stage the budget inside APP_SUB_SYSTEM should never exceed 2ns and for APP_CORE it should be limited to 8ns. To add upon this, the individual block stage margin also has to be modeled within this limit.

The designer will thus have to model this path as:

I/P max delay for APP_CORE = 20 – (0.8*10) = 12ns

I/P_port_budget + APP_CORE_stage_margin = 12ns

I/P to O/P max delay for APP_SUB_SYSTEM = 0.2*10 = 2ns
I/P_to_O/P_port_budget + APP_SUB_SYSTEM_margin = 2ns

While the above calculation seems fairly easy, the issue starts as the design matures and the logic distribution as well as stage margins change. Hence in multi-partition schemes the number variables for each subsequent partition will increase by at least 2 and this often forces the designer to go for multiple iterations to mature each of these budgets for proper convergent timing closure.

ii. Uncommon path within and outside the partition boundary:

Apart for logic distribution, uncommon clock path is another nightmare that haunts the designers in case of hierarchical closure. While the modeling of uncommon path uncertainty is a challenge of similar caliber as budget distribution, a more noxious aspect comes in the form of mismatches associated with the uncommon path. Some of the common consequences of uncommon path are:

 • Variation in CPPR or CPPR degradation.
 • Change in input latencies and hence I/O modeling
 • Substantial increase in interface hold violations
 • Noise variation due to changes in timing window

 First Page Previous Page 1 • 2 • 3 • 4 Next Page Last Page

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact