如何上传网站数据库推广策划方案
目录
引言
代码解析
解析器的需求
数据结构
基础class
集合class：
界面
模块例化里界面
连线界面
连线界面示例
消息传递
引言
工作中经常需要开发很多自动化的脚本或者小工具来提升开发效率。在没有读《Cad Frameworks: Principles And Architecture》之前，这些脚本或者工具的开发，只是按照功能需求，用各种function和变量、类堆砌而成。但是随着脚本代码规模的增加，脚本就像一个打满补丁的轮胎，每迭代一次，都很恼火。
最近刚好完成一个公司内部的自动连线工具，在开发前按照书中的结构划分，照猫画虎做了类似的分层设计。目前迭代很多版，修改起来比以前轻松很多。回看书中的framework，有多了一些认知，对这本1994年初版的书心中默默点了个赞。
此外，还要感谢pyverilog的作者，从他的代码中借鉴了部分数据结构。
代码解析
代码解析直接使用开源的解析工具。然后从工具中提取需要的数据，组成module的数据结构。
解析器的需求
-
支持宏定义的展开
-
支持提取parameter的名字和值。目前用的verilog-perl只能提取parameter的定义字符，对于parameter之间的嵌套引用，还需要自己处理。
-
支持端口名、位宽、方向等信息
-
支持按照定义的顺序获取端口信息
目前在用verilog-perl，基本上满足端口解析的需求。
解析结果通过转换为xml或者json，提供给自研的工具进行读取。
使用json作为中间格式，除了便于调试，还便于以后切换不同的编译工具。
数据结构
基础class
分为：module（解析好的module信息）、instance（例化模块信息），top_module（连线后生成的顶层模块）、project（编译顺序等配置信息）。
module主要包含端口名、位宽、类型。
instance主要包含例化名、端口的连线信息。
top_module包含：端口名、位宽、类型、wire的定义名、位宽。
集合class：
modules（module的实例列表）、instances（例化模块的实例列表）。
界面
界面分为3大块：
-
模块例化界面：完成module的添加和更新，例化模块的创建和重命名、参数配置等
-
连线操作界面：显示例化模块和顶层的pin，提供连线操作——例如链接和断开、创建顶层引脚和重命名等。
-
消息界面：显示修改记录或者状态变更信息，方便用户查阅和问题定位。
模块例化里界面
需要考虑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、筛选未连接的端口。