关于前端做的dcg，产生的def文件做什么用的

xingyun666666

Lover_Momo 发表于 2018-2-8 09:58
回复 9# 大龄文艺男青年

很感谢，我之前在DC中write_def 并没有看到这个命令，使用man write_def可以看到 ...

前辈，请教两个问题：
1.如果用的是Innovus,本来后端读的是netlist,sdc，lib,lef，tlu+；如果是ddc的话，后端应该都读什么文件？还用读其他文件吗？
2.如果是读了DCG出的def,是不是直接做place就行了？

Lover_Momo

xingyun666666 发表于 2021-10-12 13:59
前辈，请教两个问题：
1.如果用的是Innovus,本来后端读的是netlist,sdc，lib,lef，tlu+；如果是ddc的话， ...

1.如果用的是Innovus,本来后端读的是netlist,sdc，lib,lef，tlu+；如果是ddc的话，后端应该都读什么文件？还用读其他文件吗？-》ddc是S家的数据打包格式，C 家的工具是无法支持的。后端工具icc&icc2&fc应该支持直接读ddc的，具体没有吃过。 另外Innovus好像不吃tlu+, qrc/captable好像是吃的。
2.如果是读了DCG出的def,是不是直接做place就行了？

-》这个设计到两个Flow的对比，一种是只拿DCG的net list，Innovus然后自己摆FP，然后Place ...;还有一种是拿DCG的Netlist和已经摆放好STD的DEF（一般这个DEF Inn哦vu是吃进去Cell的位置都是illeagle的，需要refinePlace一下到leagle location）,然后拿这版本数据当Place的数据，直接往后做PreCTs Opt。至于两个版本的结果，需要Run一下才知道。只是只能说，第二种情况是C家拿S的Place Engine结果，然后往后做。。。至于结果，对比之后再决定吧。

comeon_lsl1

学习了

墨默

我的理解是，前端做完DC优化后，在PD这边PR阶段的timing不够好。因此出def给前端，让DC做优化时考虑inst等的物理位置。因此拿到DCG def，可以在place阶段defIn,然后place_opt_design。

dingyisuper1

如果你pr工具是innovus，那不用管那个def，因为synopsis和cadence两家工具内部的算法可能不一样，我试过吃进去之后效果还更差；如果你pr用icc icc2，那可以吃进去那个def，然后place -incremental；相当于dcg帮你做了第一轮place，可以节省run time（上面这些是我在dcg文档里看的，我没用过icc系列的0.0）

songsbb

后端给的def 需要包含什么信息，需要包含PG 信息么？

dingyisuper1

songsbb 发表于 2024-10-16 10:44
后端给的def 需要包含什么信息，需要包含PG 信息么？

后端给综合的def里，没有特别强制性的要求，你给的def包含的信息越多，理论上说dcg综合结果就越接近APR之后的情况；

通常这个def里可以包括block die size、macro位置、port位置；PG信息当然也可以包括，这样DC会知道这个地方的metal被pg stripe占住了，他就绕开这部分来（虚拟）绕线；
总之就是你提供的信息越多，DCG考虑进去的内容就越多