dc综合中mapped与unmapped状态的区别是什么？

Question

在Design Compiler（DC）综合过程中，模块或寄存器处于“mapped”与“unmapped”状态有何本质区别？常见问题如下：当RTL设计中实例化的模块未被正确解析为具体工艺库单元时，该模块将保持“unmapped”状态，意味着尚未绑定到目标工艺库中的实际门级单元，此时电路仍以行为级或通用逻辑形式存在，无法进行精确时序和面积评估；而“mapped”状态表示该逻辑已成功映射到目标工艺库中的标准单元（如AND2X1、DFFPOSX1等），已完成技术映射，具备了物理实现意义。这一区别直接影响综合后的网表是否可用于后续布局布线。如何判断和确保关键路径上的逻辑已被正确映射？为何部分寄存器或组合逻辑在综合后仍显示为unmapped？这些问题常出现在脚本遗漏link_library设置、未正确引用设计环境或使用了未被支持的原语等情况中。

Answer 1

Design Compiler中“mapped”与“unmapped”状态的本质区别及综合问题深度解析

1. 基本概念：什么是“mapped”与“unmapped”？

在Synopsys Design Compiler（DC）的综合流程中，设计从RTL描述逐步转换为门级网表。这一过程中，逻辑单元会经历从行为级描述到工艺库单元映射的转变。

• Unmapped状态：表示该模块、寄存器或组合逻辑尚未绑定到目标工艺库中的具体标准单元。此时逻辑以通用功能形式存在（如“AND”，“DFF”等抽象符号），无法进行精确的时序分析和面积估算。
• Mapped状态：意味着该逻辑已成功映射到特定工艺库中的标准单元（如AND2X1、DFFPOSX1），完成了技术映射（Technology Mapping），具备了物理实现的基础。

这种状态差异直接决定了综合输出是否可用于后续的布局布线（P&R）阶段。

2. 状态判断方法：如何确认逻辑是否被正确映射？

可通过以下命令和工具检查映射状态：

1. report_cell -hierarchy：查看所有单元的实例及其对应的标准单元名称，若显示为U_MUX21或UNMAPPED_CELL则为未映射。
2. check_design：自动检测设计完整性，包括未解析模块、悬空端口和未映射逻辑。
3. report_qor -significant_digits 3：质量报告中若关键路径包含未映射逻辑，则时序结果不可信。
4. 使用GUI工具（如Design Vision）可视化查看单元颜色标识——通常红色代表unmapped。

3. 常见导致“unmapped”的根本原因分析

原因类别	具体场景	典型表现
Library配置缺失	link_library未设置或路径错误	所有实例均无法识别
设计环境未加载	未读取.dcx或.synlib环境文件	高层模块保持行为级
原语不支持	使用FPGA专用原语（如IBUF/OBUF）用于ASIC流程	寄存器/IO缓冲未映射
模块未定义	子模块未通过read_verilog或analyze/elaborate引入	elaborate时报错“undefined module”
命名冲突	用户自定义模块名与库单元重名	DC误将其当作库单元处理
工艺库版本不匹配	使用旧版库但RTL含新特性（如retention cell）	特定低功耗寄存器未映射

4. 关键路径上的映射验证策略

确保关键路径完全mapped是保证时序收敛的前提。建议采用如下流程：

# 示例脚本片段
set_critical_path_options -max_paths 10
report_timing -path_type full -nworst 5 > timing_before_mapping.rpt

# 检查关键路径节点是否映射
foreach_in_collection p [get_timing_paths -max_paths 5] {
  set src [get_property $p startpoint]
  set inst [get_cells -of_objects $src]
  if {[get_property $inst is_unmapped]} {
    puts "WARNING: Critical path contains unmapped instance: $inst"
  }
}

5. 解决方案与最佳实践

针对不同成因，应采取分层应对措施：

1. 库配置校验：

   set link_library [list *.db $MY_TECH_LIB]
   set target_library [list $MY_TECH_LIB]

   确保*.db包含所有依赖库，且顺序正确。
2. 显式映射控制：对特定模块强制映射

   compile_ultra -map_only -scan

   使用-map_only模式仅执行映射而不优化，便于调试。
3. 自定义单元建模：对于非标准IP，提供.db模型或Verilog behavioral+synopsys_translate_on/off注释块。
4. 脚本自动化检查：集成CI/CD流程中加入映射状态断言

   if {[llength [get_cells -filter "is_unmapped==true"]]} {
     exit -code 1
   }

6. 高级调试技巧：结合DC内部机制深入排查

graph TD
  A[RTL Input] --> B{Elaborate完成?}
  B -- Yes --> C[Generic Technology]
  B -- No --> D[Missing Module/File]
  C --> E{Link Library正确?}
  E -- No --> F[All Cells Unmapped]
  E -- Yes --> G[Tech Mapping Phase]
  G --> H{Cell in Target Library?}
  H -- Yes --> I[Mapped Cell]
  H -- No --> J[Stays Unmapped]
  I --> K[Netlist for P&R]
  J --> L[Error/WARNING in compile]

通过上述流程图可见，映射失败往往发生在elaborate后但compile前的环节。利用link elaborated design命令可触发库链接过程，其输出日志是定位问题的关键。

7. 实际工程案例：某SoC项目中寄存器未映射问题复盘

某28nm项目中，部分低功耗寄存器（SDFFL）始终处于unmapped状态，尽管库文件已正确加载。

• 现象：report_cell显示U_SDFFL_1，而非预期的SDFFL_X1。
• 根因：工艺库虽包含该单元，但未在target_library中显式声明，仅存在于link_library。
• 修复：set target_library [concat $target_library "sdffl.db"]后问题解决。
• 教训：并非所有库单元都会自动参与映射，必须确保关键单元在target_library中可用。

8. 对后续流程的影响评估

未映射逻辑将引发连锁反应：

下游流程	影响类型	后果严重性
静态时序分析（STA）	延迟估算失真	高
功耗分析	无准确电容模型	高
形式验证（Formality）	结构不匹配	中
物理实现（ICC/Innovus）	无法放置单元	致命
DFT插入	扫描链断裂	高