的write方法有哪些参数_知否?知否?Block PD应该提交哪些数据?

本文介绍了Block PD工程师在芯片设计中的核心任务——如何正确提交数据给不同角色。内容涉及LEF文件、ETM模型、clock tree平均延迟、网表、DEF、SPEF等关键数据的提取方法,以及对应工具的使用,如Innovus、ICC2、QRC和Star RC。
摘要由CSDN通过智能技术生成

9034dbe1b033efcca882cd5c39e16f2d.gif

众所周知,芯片设计是一个大型团体项目。每个人在里面扮演着不同角色,只有相互合作,才能正确及时地完成最后的signoff。(具体的分工可以参考以下文章)

【小白后端工程师成长记——项目角色】

而作为团队中人数比例最多的block PD工程师,是最能体现合作的重要性的一个角色。那今天给大家介绍一下,block PD工程师日常工作中需要完成的一项最基本的任务:如何正确地提交不同的数据? 

6c212e63aa2d4c77d12dfd5ef09498e7.png

参照前面介绍角色分配的文章,大家可以想象一下,block owner要分别给这些人提交哪些数据呢?

3e00f69ebe76645c9824f541123ed548.png

TOP PD

969d0b8b74a22ee837d4fe1f1bf2345e.png

首先,我们来想想要给top pd工程师应该提供什么文件呢?

LEF

这里的lef是指block abstract,可以理解为block的壳。对top pd工程师来说,每个切割下去的block里面的东西他是看不见的,相当于一个hard macro。因此他需要知道这个block的形状大小,还有具体io pin的位置。这些物理信息都存在block的lef abstract文件中,需要我们提取出来告诉top pd工程师。还有,需要额外注意的一点,需要包含block PG pin的信息,这样顶层工程师才能正确drop power via,并且检查power stripe是否对齐。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

Innovus

innovus 5> write_lef_abstract block.lef -5.8 -stripePin -PGPinLayers {1,2,3,4,5,6}  -specifyTopLayer 6

ICC2

ICC2更加方便,只要提供block的ndm db就行。

icc2_shell > save_lib block.ndm

ETM

我们知道了block壳上具体的物理信息,还需要知道它们的delay信息。就像memory的lef和lib文件一样。所以,我们需要提取block的lib文件给top pd计算端口上的延时。我们把这个lib文件叫做ETM model。全称extraction timing model。具体信息可以参考以下链接

【时序分析基本概念介绍ETM】

ETM可以在Place, CTS, Route以后分别提取,当然越往后的阶段,ETM的精确性越高。我们可以视项目进度而提取相应的ETM model。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

Innovus 

innovus 5> do_extract_model ${view}.lib -view $view

PT

ICC2同样只需提供block的ndm db就行,ICC无法产生ETM,需要在PT中产生,通常产生ss cmax, rcmax几个重要的corner就行。

pt_shell> extract_model -library_cell -output model2 -format {lib}

clock tree 平均长度

block PD还要提供给top pd的一个非常重要的信息是block里面每条clock tree的平均latency。因为top pd在生长clock tree时,看不到block里面的clock tree长度。这样生长的clock tree是虚假的balance。因此,block PD工程师需要计算出每个clock的平均latency(更精准的说,应该是大部分clock tree的长度落在哪个范围),top pd会设上对应的insertion delay来做balance。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

Innovus

innovus 5>report_ccopt_skew_groups –summary -skew_groups -delay_corners –late

ICC2

icc2_shell> report_clock_timing -type latency

3e00f69ebe76645c9824f541123ed548.png

TOP STA

969d0b8b74a22ee837d4fe1f1bf2345e.png

Timing signoff是我们最关心的一项指标。那我们block pd需要提供什么信息给top的STA工程师呢?

Netlist

首先最基本一个文件是网表,是指完成block level pr的网表。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

Innovus

innovus 5> saveNetlist route.v.gz

ICC2

icc2_shell> write_verilog -exclude {all_physical_cells pg_objects} route.v

DEF

其次,我们需要提供block的物理设计信息文件——def文件。它有很多用途,比如说用作RC寄生参数提取,timing signoff eco,功耗分析等等

dc8f049b001638466bd76c2298a146e2.png

如何提取?

Innovus

innovus 5> defOut block.def.gz -floorplan -netlist -routing –withShield

ICC2

icc2_shell> write_def -compress gzip  block.def

SPEF

最后,我们需要得到设计中金属连线的delay信息,因此需要提供block的RC寄生参数信息文件,也就是我们经常使用的spef文件。常用的RC extraction工具有QRC和Star RC,大家可以根据工具的user guide中的使用方法介绍来提取,很简单。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

QRC

QRC需要准备block中用到的lef,def文件,QRC的tech 文件,以及layer mapping file

Star RC

Star RC可以直接指定block的milkyway或者ndm db,当然也支持了lef/def格式的提取,同样的需要准备Star RC的tech文件(.nxtgrd)以及layer mapping file

fill.gds

另外,为了让timing更加真实,我们在提取RC信息时,需要提供block加完dummy fill的gds文件,尤其是一些density较低的设计,如何提取在后文中的PV部分有简单介绍。

3e00f69ebe76645c9824f541123ed548.png

TOP PV

969d0b8b74a22ee837d4fe1f1bf2345e.png

PV(Physical Verification)分为很多内容。最主要的两项是DRC和LVS。DRC signoff是与timing signoff齐头并行的工作。DRC的分析通常可分为两个阶段。一般在初期的FEOL drc checking(Front end of layer,只检查base layer)以及设计后期的full metal drc check。在这两个阶段,block owner需要提供什么文件信息呢?

GDS

这两个阶段我们都需要提供GDS文件,只是这两个阶段需要的GDS文件有所区别。

FEOL:初期的FEOL检查能尽早帮助设计者发现floorplan中base layer的violation。我们只需要merge design以后的gds文件。PR工具只能导出metal层的gds,所以我们还需要将standard cell 以及各种memory和IP的base layer层的gds全部merge起来。这个过程可以在Calibre里面完成。下面介绍一些简单过程,具体的需要设计者写脚本完成。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

1. 产生metal gds

Innovus

innovus 5>streamOut block.gds.gz –mapFile layer_map.file

ICC2

icc2_shell> write_gds block.gds.gz –library mylib –layer_maplayer_map.file

2. Merge Design

Calibre

set L [layout create block.gds.gz -dt_expand -preservePaths  -preserveProperties ]

$L create layer XX.XX 加text

$L gdsout block.modified.gds.gz block

layout filemerge \

-in block.modified.gds.gz \

-in standard_cell.gds

-in memory.gds \

-in ip.gds \

-topcell block \

-out  block.merged.gds.gz

Full Metal Layer: 完整的drc signoff阶段。需要加好dummy metal fill的完整GDS文件。为了保证chip的平坦度要求,我们在最后layout时需要填充metal dummy来达到density的要求。这个通常foundry都会提供相应的加dummy的runset。这边就不介绍了。

3e00f69ebe76645c9824f541123ed548.png

TOP LVS

969d0b8b74a22ee837d4fe1f1bf2345e.png

LVS是physical verification的另外一大内容。那么, block owner需要提供什么文件信息给top PV呢?

cdl

block owner需要将PR以后的verilog网表转成spice或者cdl格式的网表,通常在Calibre的v2lvs工具转换,需要将standard cell和IP的cdl文件都include进来。

dc8f049b001638466bd76c2298a146e2.png

如何提取?

v2lvs -v block.v -o block.cdl-s ram.cdl –s std.cdl -s0 VSS -s1 VDD

3e00f69ebe76645c9824f541123ed548.png

Power

969d0b8b74a22ee837d4fe1f1bf2345e.png

full chip的功耗分析也是signoff的一大重要指标,主要是IR drop和EM的分析。block owner需要提供PR以后的网表.v(包含PG信息),RC寄生参数文件,def文件。这三个文件产生方式与上文一样,不在过多介绍了。

3e00f69ebe76645c9824f541123ed548.png

Front-End

969d0b8b74a22ee837d4fe1f1bf2345e.png

前端设计包括DFT和综合都是和后端PD密切相关的,不管是前期的综合,还是后期的formal验证和仿真,都需要block PD提供数据。不过基本以网表为主,唯一可能需要的physical信息的文件是def文件,这里的def文件是指做完floorplan以后的def文件,主要用途是给综合人员做physical aware的synthesis。

8388e9327d73fda0d69fe771ec22d341.png

往期回顾

静态时序分析STA合集一

静态时序分析STA合集二

时序基本概念介绍

数字后端基本概念合集(一)

数字后端基本概念合集(二)

Low Power概念介绍合集

IC圈的世界杯 | 论芯片设计的胜利十一人

简历请戳邮箱:taozhang3260@163.com

  • 0
    点赞
  • 8
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值