聊聊SOC设计质量相关的规范
你们以为我要讲的是coding-style?
no，我主要讲的是其它和设计质量相关的规范。
1、代码篇
1.1、手撕代码部分
module name需要包含一定的功能展现，什么意思呢，比如要设计address remap，你就叫xxx_addr_remap或者xxx_addr_decoder。切记不要叫xxx_misc，一定是迫不得已再写这个module，否则集成或者debug会很头疼，谁知道这玩意是干啥用的。
当然，内容部分就是老生常谈的：
·加注释
·组合和时序
·缩进
·状态机
·阻塞赋值和非阻塞赋值
·一个module一个变量
·begin end对齐
·？语句和：的对齐等
1.2、第三方ip
我们除了仔细写的代码外，还会用第三方工具例如arm和designware生成很多简单ip，例如ahb2ahb桥，i2c,dwt,uart,timer等，我们除了要清楚我们的功能feature外，还要注意module一定要加前缀，文件名同样，否则我们无法与其他人的代码区分开，这样就会存在设计风险。
1.3、common cell
什么是common cell，就是我们常用的lib cell，例如mux，ckmux，ckg，ckand，ckor，sync_cell，dft_dff，等。为什么要单独拎出来呢？因为这里不做好标准，后端很痛苦。
我们一般会由专人负责设计和维护，以后所有人无特殊情况禁止直接手写lib cell，比如在某个module内用always语句写sync cell。
为什么呢？因为这些cell和后端约束强相关，和dont touch list强相关，和timing强相关，因此，从synth开始就要用专门的dc lib替换他们，如果我们自己随便在一个module里写这些逻辑，dc工具和脚本无法抓取信息，但是如果我们例化common cell的话，他们处理起来就方便多了。
当然，有一个细节就是define分支，一般会有sim和asic分支，但是因为fpga没有ckg，所有我们会在这里增加fpga分支将ckg变为ckbuf。
1.4、memory cell
采用多级wrapper的方式，底层wrapper例化我们的physcal memory，并且在这一级对dft信号，和timing相关调整信号做tie值处理。
二级wrapper做分支，分为sim分支，fpga分支和asic分支。这样的话，即便没有真实的物理memory，也不影响fpga和sim的同事使用。
当然也可以再加一级wrapper，将所有的memory放在一起，通过generate if不同的参数(例如宽度，深度，tag)决定例化哪一个memory，这样做的好处就是集成方便，不好的地方就是维护起来太麻烦。
2、filelist篇
soc设计的下游分为fpga，sim和synth。但是三者的要求不同
fpga要求filelist内容fpga vivado可综合（有相关资源）。
sim要求可以存在sim model，不需要可综合。
synth要求必须可综合。
因此，我们一般需要维护三个filelist，xx_fpga.f，xx_sim.f和xx_syn.f，来满足不同同事的需求，防止他们自己处理出现问题。
仅仅是这样，对于大型soc还是不够的，需要一个filelist去重脚本，因为每个子系统subsys都可能例化了common cell（因为可能会单独仿真或者综合呀），所以soc top拿到的filelist一定是有很多重复的文件，所以需要脚本展开并去重，重复的不是删除，而是注释，方便review（不知道脚本删除的对不对，需要review）。
3、difine macro篇
设计中一定会有很多define，主要分为两类：common define和function define
3.1、common define
例如synth,fpga,sim这些，主要存在于memory wrapper和common cell中，我们需要整个项目组采用统一的格式，不能一会用synth，一会用asic，这样dc同事会经常漏define，需要resynth。
3.2、function define
例如设计一个i2c，内部多个模块，这样的话我们的位宽，地址宽度等会是由define参数传递，这些参数往往不需要给其他人展示，我们自己在define中定义，最后undefine就可以了，但是顺序一定是最先编译define，最后undefine，所以刚才的filelist去重脚本还有一点很重要的就是不能调整filelist顺序哟。
4、交付质量hand-off
我们每个需要综合的节点一定要保证hand-off质量，我们通常会使用spyglass做lint检查，这是最基本的，否则dc同事一定无法综合。会显得我们的设计很low。
不同的节点有不同的要求，如果dft也要进场，我们需要用spyglass跑dft flow，例如scan-ready，bist-ready和best-practice等几个重要的goal。
当然还有非常重要的cdc flow，也是静态时序检查，只是sta关注的是同步逻辑，spyglass cdc关注异步处理，两个都做好了，才能保证设计的rtl和真实芯片的时序是一致的。
英飞凌将助力汽车行业打造出更智能更清洁更安全的汽车解决方案
中国移动强调不会为推广5G降低4G网络质量
奥迪电机驱动器(MCU)系统框图、芯片、功能拆解
无线视频监控体系的场景应用介绍
LT8522EX是Lontium的矩阵开关芯片
聊聊SOC设计质量相关的规范
梅卡曼德全新AI+3D技术赋能重工行业自动化
爱普生EF10、极米H3S、当贝X3哪个好？
对于当前的快充功率方面的拉高，我们一定要重视起来
英飞凌支持Matter标准，助推绿色智能家居落地
比特币为什么还没挖完
基于UCC38083的电源电路图_UCC38083典型应用电路
电视辐射有多大_如何预防电视辐射
迪拜副酋长阿勒马克图姆推出迪拜海关综合电子报关系统 Mirs
优化lSD系列语音芯片的开发平台设计方案介绍
煤电与汽油之争，电动汽车并不环保吗？
具有可调光功能的LED灯条电路
非正交多址是什么 非正交多址技术有哪些
北斗星通加速构建全球领先的 “位置数字底座”
51单片机对LCD1602液晶显示的驱动控制设计
no，我主要讲的是其它和设计质量相关的规范。
1、代码篇
1.1、手撕代码部分
module name需要包含一定的功能展现，什么意思呢，比如要设计address remap，你就叫xxx_addr_remap或者xxx_addr_decoder。切记不要叫xxx_misc，一定是迫不得已再写这个module，否则集成或者debug会很头疼，谁知道这玩意是干啥用的。
当然，内容部分就是老生常谈的：
·加注释
·组合和时序
·缩进
·状态机
·阻塞赋值和非阻塞赋值
·一个module一个变量
·begin end对齐
·？语句和：的对齐等
1.2、第三方ip
我们除了仔细写的代码外，还会用第三方工具例如arm和designware生成很多简单ip，例如ahb2ahb桥，i2c,dwt,uart,timer等，我们除了要清楚我们的功能feature外，还要注意module一定要加前缀，文件名同样，否则我们无法与其他人的代码区分开，这样就会存在设计风险。
1.3、common cell
什么是common cell，就是我们常用的lib cell，例如mux，ckmux，ckg，ckand，ckor，sync_cell，dft_dff，等。为什么要单独拎出来呢？因为这里不做好标准，后端很痛苦。
我们一般会由专人负责设计和维护，以后所有人无特殊情况禁止直接手写lib cell，比如在某个module内用always语句写sync cell。
为什么呢？因为这些cell和后端约束强相关，和dont touch list强相关，和timing强相关，因此，从synth开始就要用专门的dc lib替换他们，如果我们自己随便在一个module里写这些逻辑，dc工具和脚本无法抓取信息，但是如果我们例化common cell的话，他们处理起来就方便多了。
当然，有一个细节就是define分支，一般会有sim和asic分支，但是因为fpga没有ckg，所有我们会在这里增加fpga分支将ckg变为ckbuf。
1.4、memory cell
采用多级wrapper的方式，底层wrapper例化我们的physcal memory，并且在这一级对dft信号，和timing相关调整信号做tie值处理。
二级wrapper做分支，分为sim分支，fpga分支和asic分支。这样的话，即便没有真实的物理memory，也不影响fpga和sim的同事使用。
当然也可以再加一级wrapper，将所有的memory放在一起，通过generate if不同的参数(例如宽度，深度，tag)决定例化哪一个memory，这样做的好处就是集成方便，不好的地方就是维护起来太麻烦。
2、filelist篇
soc设计的下游分为fpga，sim和synth。但是三者的要求不同
fpga要求filelist内容fpga vivado可综合（有相关资源）。
sim要求可以存在sim model，不需要可综合。
synth要求必须可综合。
因此，我们一般需要维护三个filelist，xx_fpga.f，xx_sim.f和xx_syn.f，来满足不同同事的需求，防止他们自己处理出现问题。
仅仅是这样，对于大型soc还是不够的，需要一个filelist去重脚本，因为每个子系统subsys都可能例化了common cell（因为可能会单独仿真或者综合呀），所以soc top拿到的filelist一定是有很多重复的文件，所以需要脚本展开并去重，重复的不是删除，而是注释，方便review（不知道脚本删除的对不对，需要review）。
3、difine macro篇
设计中一定会有很多define，主要分为两类：common define和function define
3.1、common define
例如synth,fpga,sim这些，主要存在于memory wrapper和common cell中，我们需要整个项目组采用统一的格式，不能一会用synth，一会用asic，这样dc同事会经常漏define，需要resynth。
3.2、function define
例如设计一个i2c，内部多个模块，这样的话我们的位宽，地址宽度等会是由define参数传递，这些参数往往不需要给其他人展示，我们自己在define中定义，最后undefine就可以了，但是顺序一定是最先编译define，最后undefine，所以刚才的filelist去重脚本还有一点很重要的就是不能调整filelist顺序哟。
4、交付质量hand-off
我们每个需要综合的节点一定要保证hand-off质量，我们通常会使用spyglass做lint检查，这是最基本的，否则dc同事一定无法综合。会显得我们的设计很low。
不同的节点有不同的要求，如果dft也要进场，我们需要用spyglass跑dft flow，例如scan-ready，bist-ready和best-practice等几个重要的goal。
当然还有非常重要的cdc flow，也是静态时序检查，只是sta关注的是同步逻辑，spyglass cdc关注异步处理，两个都做好了，才能保证设计的rtl和真实芯片的时序是一致的。
英飞凌将助力汽车行业打造出更智能更清洁更安全的汽车解决方案
中国移动强调不会为推广5G降低4G网络质量
奥迪电机驱动器(MCU)系统框图、芯片、功能拆解
无线视频监控体系的场景应用介绍
LT8522EX是Lontium的矩阵开关芯片
聊聊SOC设计质量相关的规范
梅卡曼德全新AI+3D技术赋能重工行业自动化
爱普生EF10、极米H3S、当贝X3哪个好？
对于当前的快充功率方面的拉高，我们一定要重视起来
英飞凌支持Matter标准，助推绿色智能家居落地
比特币为什么还没挖完
基于UCC38083的电源电路图_UCC38083典型应用电路
电视辐射有多大_如何预防电视辐射
迪拜副酋长阿勒马克图姆推出迪拜海关综合电子报关系统 Mirs
优化lSD系列语音芯片的开发平台设计方案介绍
煤电与汽油之争，电动汽车并不环保吗？
具有可调光功能的LED灯条电路
非正交多址是什么 非正交多址技术有哪些
北斗星通加速构建全球领先的 “位置数字底座”
51单片机对LCD1602液晶显示的驱动控制设计