LayoutEdit相关基础

# （一）单元视图标识符和实例母体标识符 
## 简述：
- `Cell View Identifier（单元视图标识符）`：定义了一个独立的、完整的设计模块本身。它是“蓝图”或“模板”的ID。
- `Instance Master Identifier（实例母体标识符）`：定义了一个被引用的、具体的母体对象。它是“根据蓝图制造出来的那个具体零件”的ID。
## Cell View Identifier（单元视图标识符）
- 这指的是一个完整的设计“单元”在库中的唯一身份。它通常由三部分（在某些工具中是两部分）组成：
    - Library: 库名
    - Cell: 单元名
    - View: 视图名
- 例如： `myLib / inverter / schematic`，又例如：` myLib / inverter / layout`
- 它的作用是：
    - 唯一地标识一个设计文件。当你说“打开 myLib 库下的 inverter 单元的 layout 视图”时，工具就是通过这个标识符来找到并打开那个具体的版图或电路图文件的。
    - 它代表的是一个可编辑的源文件。你可以直接打开、修改并保存它。
- 一个形象的比喻：- myLib/inverter/layout 就像是一张 “反相器的建筑设计蓝图” 。这张蓝图本身存放在“myLib”这个档案库中。

## Instance Master Identifier（实例母体标识符）
这指的是在一个设计中被实例化（引用）的那个目标对象的身份。

当你在一个上层设计（比如 top_level 的版图）中，放置一个子单元（比如 inverter）时，你创建的是一个 “实例”。这个实例本身并不是一个独立的文件，它只是一个指针，指向它所代表的那个底层单元。

这个指针所指向的目标，就是 Instance Master。

它的标识符和 Cell View Identifier 是完全一样的！ 也是 Library/Cell/View。

例如：
在你的顶层版图 myLib/top_level/layout 中，你放置了一个反相器。这个反相器实例所指向的 Master 就是 myLib/inverter/layout。

它的作用是：

告诉工具：“我这个实例，是依据哪个蓝图（Cell View）创建出来的”。

它代表的是一个被引用的、只读的（在当前上下文中）对象。在 top_level 中，你不能直接修改这个 inverter 实例内部的晶体管，你只能整体移动、旋转它，或者修改它的某些实例属性（如取向）。

接上文的比喻：
myLib/inverter/layout 作为 Instance Master，就像是施工队在建大楼（top_level）时，所使用的那个标准的、已经预制好的反相器零件。这个零件是根据那张“反相器蓝图”制造出来的。

## 为了更好地理解，我们来看一个典型的流程：
- 设计底层模块：你创建并绘制了 `myLib/inverter/layout`。这是一个 `Cell View`。

- 在顶层设计中引用：你打开 `myLib/top_level/layout` 进行绘制。从库中把 inverter 拖进来（或按 i 键调用）。

- 创建实例：此时，你在 `top_level` 中创建了一个 `Instance`。

- 指定母体：这个` Instance` 的内部属性会记录：我的`Master` 是 `myLib/inverter/layout`。这就是它的 `Instance Master Identifier`。

- 联动更新：如果你回到 `myLib/inverter/layout`这个 `Cell View` 中修改了版图（比如改变了晶体管的尺寸），那么所有在其它地方引用了这个 `Master` 的 `Instance`（比如 `top_level` 中的那个反相器）都会自动更新，因为它们都是根据同一份“蓝图”制造的。

## 为什么这个区别很重要？
- 理解层次化设计：
这是理解版图（和电路图）如何通过引用来构建复杂系统的基础。
- 管理设计变更：
你知道修改一个底层` Cell View`，会全局影响所有引用它的实例。
- 解决依赖关系：
在工具中，你可以查询一个 `Instance `的 `Master`，甚至可以“降级”到它对应的` Cell View `中进行编辑。
## 结论
所以，从物理文件的角度讲，它们指向的是同一个东西；但从设计上下文的逻辑角度讲，它们扮演着完全不同的角色：一个是定义者（`Definition`），一个是引用者（`Reference`）。

- 注意，内容参考自deepseek等AI；在pyAether的dbCrtInst接口中，就会有这两个参数。

# (二)新建Library选项
## 简述 
在 EDA 版图工具（如 Cadence Virtuoso）中创建新库时，为 Technology 参数选择合适的选项非常关键，它决定了你的设计库如何与半导体制造工艺的底层规则（技术文件，Techfile）关联。下面这个表格清晰地展示了这四个选项的核心区别和典型应用场景：

|选项|	核心机制|	技术文件来源与更新|	适用场景|
|:---|---|----|
|Attach To Library|	动态链接到现有的工艺库（通常是PDK库）|	共享目标库的techfile，随其更新而自动更新| 常规IC设计：确保设计始终使用最新的、统一的工艺规则。|
|Reference To Libraries	|复制指定库的techfile到你的新库，成为其私有资产	|独立于原库，不会自动更新️| 定制化需求：需要修改techfile（如添加自定义脚本或层定义）。|
|Load ASCLL File|	通过读取ASCII格式的工艺文件来定义技术|	由提供的文件定义，更新需重新加载文件| 特殊流程：从非标准来源（如特定工具导出）或旧版本导入工艺数据。|
|Do Not Need|	新库不关联任何工艺技术|	不包含工艺信息| 非物理设计：纯逻辑设计（如原理图、符号）、仿真模型库或文档库。|
## 建议
- 如何在实际工作中做出正确选择呢？这里有一些实用的建议：

- 首选 Attach 以保证一致性：对于绝大多数基于标准PDK的芯片设计，`Attach to an existing technology library` 是推荐且安全的选择。它能确保团队所有成员都使用相同且最新的工艺信息，避免因技术文件版本不统一导致的潜在风险。
    
    - 谨慎使用 Reference 以管理复杂性：虽然 `Reference` 提供了灵活性，但它也会造成技术文件的"碎片化"。如果多个项目都复制了各自的techfile，后续PDK的升级和管理会变得复杂。因此，仅在确有明确的定制需求时使用此选项。
    
    - 留意工具版本与工艺库格式：有时无法成功关联工艺库，可能与数据格式（如OA与CDBA）有关。确保你的设计库和工艺库使用工具兼容的格式。如果遇到问题，可以检查工艺库是否已正确通过 cds.lib 文件引入到当前设计环境中。

## 简单来说，
- 这四个选项的核心区别在于技术文件与设计库的关联方式和独立性：
    - `Attach `是共享，保持同步。
    - `Reference `是复制，独立发展。
    - `Load ASCLL File` 是从文件初始化。
    - `Do Not Need `是完全独立，不涉及工艺规则。
# (三) 版图(layout)原理图(schematic)和符号(symbol)的区别
## 3.1 三者概念与区别
- **设计流程中的协作关系** 在一个典型的设计流程中，这三者紧密协作：
    - 设计师首先根据系统需求，绘制`Schematic`。在绘制时，他们会从库中调取预先定义好的`Symbol`（如与门、或门、运放等）进行连接。
    
    - 版图工程师根据完成的`Schematic`，开始绘制`Layout`。他们会把`Schematic`中的每一个元器件（对应一个`Symbol`）用实际的几何图形“摆放”出来，并用金属线“连接”起来。
    
    - 在整个过程中，EDA工具会确保`Schematic`和`Layout`之间通过`LVS`检查保持一致。也就是说，工具会提取`Layout`的网表，并与`Schematic`的网表进行对比，确保它们在电气连接上是完全一致的。

## 3.2 注意事项
- 在绝大多数专业的EDA系统中，你不能直接在顶层`Schematic`中放置另一个`Schematic`。你必须通过`Symbol`来引用它。
    - 如果直接放置Schematic：当你在查看顶层电路时，你会被迫看到所有下层模块的内部细节——所有的晶体管、电阻、连线等等。这会导致信息过载，让你无法专注于当前层级的任务——即模块之间的互连和系统架构。这就像在阅读一本书的目录时，却把每一章的详细内容都打印在目录页上一样，根本无法阅读。
    - 使用Symbol：Symbol提供了一个干净、简洁的接口视图。它只告诉你：“这是一个反相器，这里是输入，这里是输出，这里是电源和地”。它隐藏了你暂时不需要关心的内部实现细节，让你能清晰地把握系统的宏观结构。
    - 不只是在抽象与信息隐藏方面，原因还包括：symbol可以强制明确接口规定，是层次化设计的基石，并且有助于实例化和复用等。
    
- 为什么layout可以直接放其它的layout，而没有"接口级"的新概念(类似于symbol)?
    - 在Layout（版图）设计中，我们确实直接放置子对象的Layout，而不是通过一个抽象的“接口视图”。
    - 核心原因：抽象的对象不同
        - `Schematic` 抽象的是**“功能”***
        - `Layout `抽象的是**“物理实体”**
    - 在Schematic中，我们处理的是功能。一个Symbol代表了一个功能黑盒。
        - 隐藏实现细节：看到一个“与门”的Symbol，我不需要关心它内部是用CMOS、NMOS还是其他技术实现的。我只需要知道它的逻辑功能是“与”。这实现了功能抽象。
        - 接口是电气性的：Schematic的接口（引脚）是电气网络。它们只需要一个名称（如 A, B, Y）来标识，而不需要物理形态。
        - 实现方式的多样性：同一个Symbol（功能），可能对应多种不同的Layout（物理实现）。比如，一个反相器Symbol，其Layout可以根据驱动能力、速度、功耗要求被画成多种尺寸和形状。
        - 因此，Symbol在Schematic中是一个功能性、电气性的抽象接口，它将“做什么”与“如何做”分离开来。 
    - 在Layout中，我们处理的是物理实体。当我们放置一个子对象的Layout时，我们放置的就是一个物理黑盒。
        - 没有“功能”需要抽象：Layout本身已经是物理实现的最终描述。一个标准单元的Layout，它的形状、引脚位置、所有层次的几何图形，就是它最底层的、无可替代的物理实体。当我们调用它时，我们调用的就是这个实体本身。
        - 接口是物理性的：Layout的接口是物理引脚。这些引脚本身就是一块具体的、有形状的金属层几何图形。它们的位置、大小、所在金属层，是物理连接（布线）的唯一依据。这些物理信息无法被进一步“抽象”，除非你再画一个更简单的图来表示它——但那其实就是这个Layout的俯视图，而不是一个新的抽象类型。
        - 物理实现的唯一性：对于一个给定的Layout Cell，它的物理接口（引脚位置和形状）是固定的、唯一的。你不能在不知道引脚具体物理位置的情况下进行布线。
        - 那么，Layout中真的完全没有“接口”概念吗？
            - 有的！ 但这个接口概念被直接嵌入到了Layout Cell本身之中。
            - Pin（引脚）图层：在版图编辑中，你会专门用一个特殊的图层（通常叫 pin 或 text 层）在金属引脚图形的上方进行标注，告诉工具：“这是一个名为 ‘A’ 的输入引脚”。
            - 这个被标注的物理图形，本身就是它的“接口”。当你调用一个子Layout时，你同时获得了它的内部实现（所有几何图形）和它的接口（被标记的引脚图形）。
            
    - 在Layout中，子Layout Cell本身就是一个既包含内部实现又包含物理接口的完整实体。因此，不再需要一个独立的、像Symbol那样的“接口视图”来代表它。直接实例化子Layout，是管理物理设计复杂性的最直接、最自然的方式。

- 这种`Schematic`和`Layout`在层次化引用方式上的差异，完美地体现了从“功能设计”到“物理实现”的思维转换。

lee-romantic 's Blog

导航

最近发表

友情链接