HLMC_55 IP数字后端设计

来源:互联网 发布:php商城哪个好 编辑:程序博客网 时间:2024/06/16 02:38

        前段时间完成了一个IP在HLMC_55工艺下的后端设计,在此记录如下。

        关于工艺

        本次设计选用工艺库为IH55LP_HS_RVT_V2p3_1P4M_1TM2X,设计中不包含IO及Memory,因此物理库只引用standard_cell。关于时序库,target_library选择ih55lp_hs_rvt_ss_1p08_125c_basic.db,link_library选择ih55lp_hs_rvt_ss_1p08_125c_basic.db和ih55lp_hs_rvt_ff_1p32_-40c_basic.db。tech_file选择tf/HLMC_cl055lp_1p4m_1tm2x_mw.tf。因为此工艺只有4层金属,相比其他工艺,绕线问题将成为本设计的设计瓶颈。

        拿到的初始文件

        从前端拿到的东西只有一个网表和一个sdc,因此本次设计不包含扫描链。从sdc可看出,本次设计包含8个主时钟,其中最高频时钟周期为1.25ns(为了减轻后面修正时序的工作量,在apr时把周期调整为1.2),另有17个衍生时钟,用于产生分频。

        从版图拿到的floorplan size为{{0 0}, {0 482},{2550 482},{2550 0},{2005 0},{2005 382},{545 382},{545 0}},这是一个不规则图形,一开始跑流程的时候仅仅意识到这个不规则形状可能对时序有恶劣的影响,没有考虑到其对绕线的影响,这一点后面再详细讲述。

        开始后端流程

        建立设计库和加载网表没有什么特别之处,和其他大多数项目的流程相同。

create_mw_lib  {自己指定的设计库路径(文件夹)}     -technology  {tech_file}   -bus_naming_style {[%d]}   -mw_reference_library  {物理库路径}   -open

set_tlu_plus_files   -max_tluplus  {max_tluplus}    -min_tluplus  {min_tluplus}    -tech2itf   {mapfile}

import_designs   -format verilog  -top {design}   -cell {design}    {网表}

current_design

link

change_names -rules verilog  -hierarchy

uniquify

        在创建floorplan时,从原则上讲,对于不规则形状应该使用initialize_rectilinear_block命令,对于规则形状才能用create_floorplan命令,然而此次设计为不规则形状,使用create_floorplan命令居然也成功了,有点不明白~~

        在preplace阶段,出于优化时序的考虑,把最高频时钟输入后经过的两个MUX和第一个分频点拉到该时钟的输入端口附近,并fix住。

        在place阶段,有一个设置值得一提,set_app_var placer_max_cell_density_threshold -1,此设置使得工具在布局时充分利用core的全部面积对cell进行均匀布局,此设置可能导致时序不够理想,但有利于解决绕线困难的问题。在place阶段向设计中加入spare cell时,对所有加入的spare都加上keepout_margin,这也是出于优化绕线考虑。

        做时钟树阶段,设置target_skew为0.1,max_transition为0.2。时钟树做完之后报告显示,最长时钟树的longest path为2.4,max_skew为0.18,时钟情况整体看来可以接受。

       后面的流程时钟优化和绕线其实没什么特别的,按照正常流程进行即可。在绕线阶段,因为绕线资源的限制,在解决短路问题上花费了一点时间。总体而言,短路多出现在内拐角附近,以后再做类似floorplan的IP时应该在布局之前在内拐角区域打上blockage,通过降低局部cell密度来解决局部拥塞。

      APR流程跑完后cell数为38734,利用率为16.5%。

        关于signoff

        APR之后跑出来的结果,时序果然非常差,原因可能是两方面的:1. floorplan的形状比较畸形,2. 金属层较少,绕线资源紧张。

        STA在21个corner下进行,OCV设定为early:0.9,late:1.15。uncertainty设定为:setup:0.15,hold:0.06。max transition设定为:data:0.4,clock:0.2。修正时序的具体过程在此不再详细描述。值得一提的是,在修正noise时,考虑当前绕线资源已经比较紧张,采用的是在有noise的线中间位置插buffer的方法来修正,而不是采用更常用的加倍线宽和线距的方法,而这种方法又会对时序产生影响(或许出现noise的线刚好处于关键路径上?),因此在修正时序和noise的过程经历了较多次eco迭代,并且迭代过程中也多次出现新产生的短路,总而言之,eco迭代过程相当不顺利。

      LVS比较顺利,短路解决后,LVS一次通过。DRC存在少量的间距问题,删掉个别线重绕即可解决。

原创粉丝点击