verilog代码连线集成工具的实践

目录

引言

代码解析

解析器的需求

数据结构

基础class

集合class：

界面

模块例化里界面

连线界面

连线界面示例

消息传递

---

引言

工作中经常需要开发很多自动化的脚本或者小工具来提升开发效率。在没有读《Cad Frameworks: Principles And Architecture》之前，这些脚本或者工具的开发，只是按照功能需求，用各种function和变量、类堆砌而成。但是随着脚本代码规模的增加，脚本就像一个打满补丁的轮胎，每迭代一次，都很恼火。

最近刚好完成一个公司内部的自动连线工具，在开发前按照书中的结构划分，照猫画虎做了类似的分层设计。目前迭代很多版，修改起来比以前轻松很多。回看书中的framework，有多了一些认知，对这本1994年初版的书心中默默点了个赞。

此外，还要感谢pyverilog的作者，从他的代码中借鉴了部分数据结构。

代码解析

代码解析直接使用开源的解析工具。然后从工具中提取需要的数据，组成module的数据结构。

解析器的需求

1. 支持宏定义的展开

2. 支持提取parameter的名字和值。目前用的verilog-perl只能提取parameter的定义字符，对于parameter之间的嵌套引用，还需要自己处理。

3. 支持端口名、位宽、方向等信息

4. 支持按照定义的顺序获取端口信息

目前在用verilog-perl，基本上满足端口解析的需求。

解析结果通过转换为xml或者json，提供给自研的工具进行读取。

使用json作为中间格式，除了便于调试，还便于以后切换不同的编译工具。

数据结构

基础class

分为：module（解析好的module信息）、instance（例化模块信息），top_module（连线后生成的顶层模块）、project（编译顺序等配置信息）。

module主要包含端口名、位宽、类型。

instance主要包含例化名、端口的连线信息。

top_module包含：端口名、位宽、类型、wire的定义名、位宽。

集合class：

modules（module的实例列表）、instances（例化模块的实例列表）。

界面

界面分为3大块：

1. 模块例化界面：完成module的添加和更新，例化模块的创建和重命名、参数配置等

2. 连线操作界面：显示例化模块和顶层的pin，提供连线操作——例如链接和断开、创建顶层引脚和重命名等。

3. 消息界面：显示修改记录或者状态变更信息，方便用户查阅和问题定位。

模块例化里界面

需要考虑verilog文件的添加、重新加载（这个经常用到，尤其是在代码频繁迭代时）。

如果考虑宏文件的加载，就会更复杂，需要支持解析顺序的配置。

需要支持parameter的重定义（在重定义的界面，还要显示module内的parameter的默认值）。

连线界面

连线界面的功能需求比较多--显示例化模块和port，port显示位宽，链接的wire名称，显示顶层模块的引脚信息，支持端口连接和断开，支持顶层引脚的添加和删除，支持wire的重命名，支持端口的固接。支持自动和手动连线，支持按照名字筛选模块和port，支持筛选port的链接状态。

自动连线其实因为按照同名进行连接，反而比较简单。（这也是很多）

对非同名信号的手动链接，对于工具的易用性有较大的提升。这一点，gui界面的优点就提现出来了。

还要考虑wire的拼接、截取，或者固接。

连线界面示例

连线界面分为左右两半。特意把顶层的引脚input和例化模块的output、input分为一边。这样划分的好处是，只有半屏之间存在连线关系；半屏之内不会需要连接——交互方式的处理上比较简单。

例化模块的端口显示示意

port name用来显示端口的名称

port width显示端口的宽度定义

connection用来显示连接信息，显示连接的wire或者顶层port、固接。

 上图为连线的示例。

实施通过在界面中显示连线的wire名称来表示连接关系，没有使用绘图来表示连线。绘图的方式在连线很多的时候，感觉会比较混乱。

消息机制

因为使用不同类封装了界面的区域，有时候还需要建立消息传输的机制，用于不同区域的协同更新。例如某个顶层引脚删除，还需要断开例化模块相连的引脚。这就需要从顶层通知到例化模块的变量，让其相应的断开连线。

---

随着工具不断地迭代，发现连线工具除了可以提高连线效率，通过增加筛选功能，可以降低连线出错的概率，并且可以在编译前更早的发现问题。

例如支持筛选连线与端口宽度不匹配的connection、筛选端口名和连线名不同的connection、筛选未连接的端口。