Q1:直播课经常讲到一致性，这个一致性的话一般是指place，CTS和PT的derating time，uncertainty和transition吗，我大概知道innovus的uncertainty设置要比PT里面高一点，但具体设计时这几部分的大小应该是一个什么样的关系或者需要大多少，这个有没有一些经验值？
我们一般讲的Correlation有Timing Correlation和Physical Correlation。
下面这张图是我之前分享的一个后端实现全流程思维导图，其中就把correlation按照Timing和Physical两个大方向进行划分（添加微信ic-backend2018免费领取这份思维导图）。
数字IC后端实现之Setup Violation修复案例(Data&Clock Tree ECO修复手段）
Timing Correlation又分PR实现不同阶段之间的时序一致性。
比如Placement做完setup wns是-0.1ns，长clock tree优化时序后setup wns是-0.25ns，这种就是典型的两个阶段之间的timing不一致！
那为何要追求一致性呢？因为长clock tree后的timing比较差，而这个情况在placement阶段工具压根没看到，那自然就不会做优化，即placement优化不到位。
我们最理解的结果是placement做完，CTS做完clock tree后timing情况就应根据接近于placement后的结果。
这两个步骤的差别是placement阶段clock还是ideal的（时钟从root到sink的时间为0），而CTS做完各个sink的到达时间是不一致的，所以它们差一个clock skew！
手把手教你如何分析debug Clock Skew高达上ns的案例
那我们是否可以在placement阶段提前把后续CTS阶段的clock skew考虑进来呢？答案是可以的。
我们在placement阶段可以设置一个更大点的clock uncertainty。
这个也就是咱们经常看到的placement clock uncertainty = Clock Jitter +预估clock skew +Timing Margin。
我们应该尽量让工具在placement阶段就把标准单元摆放到最佳的位置上，并把时序一步优化到位。后续其他阶段仅仅是针对实际clock skew和实际走线带来的一些时序变化进行的时序优化。这个优化过程可以比较轻松实现。
这样实现出来的结果我们可以把PR每个阶段的density控制在一个数量级！
PR是基于逻辑连接的物理实现的过程，它里面用的delay计算engine和RC抽取engine肯定和Starrc，PT是不一样的。所以PR和PT之间的一致性也是我们需要关注的。
而我们知道delay就分两种，分别是cell delay和net delay。
所以这两个阶段的timing一致性可以在PR阶段通过以下几个方法来调整（PT中对应值是不能改的）。
1）调整clock uncertainty
2）调整考虑OCV设置的set_timing_derate值
3）调整RC Scale Factor系数
而physical一致性主要指两边的routing drc结果是否比较接近。
IC后端项目案例 | Innovus DRC Violation分析及Floorplan合理性分析
Q2: Place阶段有时候出现critical path不在dpu里面需要设置region，想请问这个region是针对什么设置的，我不知道里面应该放什么。因为我想直接在place阶段就设置好region，如果这样可以的话在core的不同部位这个region里面应该摆什么？比如说给一个dpu设一个region它应该放在core的哪一个部位？
Region一般是针对某个module来设置的。以咱们T28 a7core直播课讲的这个案例为例，u_ca7pfu这个module工具自动摆放后被拆成两部分。这时候我们可以把这个module做成一个region，规划在中间那个位置。 DPU模块一般是位于远离io port那个对角位置，靠近DDATA SRAM。
添加region的的脚本命令如下所示。
set cells [dbGet top.insts.name u_cortexa7noram/u_ca7pfu* -p]
set cells_name [dbGet $cells.name]
createInstGroup PFU
addInstToInstGroup PFU $cells_name
createRegion PFU {300 300 500 600}
我们还可以根据设计的data flow和官方推荐的module分布来精细化规划每个module的摆放位置。
