本次分享华为公司的《大规模逻辑设计指导书》中的“可编程ASIC设计方法简介”的部分内容。
3.2.4 具体电路设计 （详细设计文档）
当各个模块划分完毕，且模块间接口时序基本清楚之后，就可以交给项目组各成员进行具体电路开发。
在进行模块设计时，应先画出每个模块的原理结构，而后画出其工作原理时序图，在工作原理时序图的指导下，进行具体电路设计。这种 “先时序后电路” 设计方法的好出是：
思路清晰 考虑周到 不容易出错。
电路即使出错误 也很容易查出问题原因所在。
在越复杂的电路 原理时序图越容易让人理解 便于项目组成员之间进行交流和互相查错。
事实上，“先时序后电路” 的设计方法也体现了 “时序是设计出来的” 思想。
在进行大规模逻辑电路设计时，显然采用VHDL或Verilog语言进行设计是目前最好地选择，熟练掌握其中之一是未来硬件设计工程师的必备知识。为了能与将来ASIC设计接轨， 最好能掌握Verilog语言。另外，熟练使用各种先进的EDA工具，如综合工具，仿真工具，静态时序分析工具等等，也是进行正常芯片设计所不可缺少的。
3.2.5 设计验证 （仿真测试方案）
设计验证手段有 软件 和 硬件 之分。软件验证包括 ：RTL级功能仿真，静态时序分析和时序仿真。硬件验证主要是指单板测试或系统测试。
一 软件验证
1. RTL级功能仿真 （功能验证）
在进行RTL级功能仿真时，在可能的情况下，最好是对每一个子模块进行仿真。确保90% 以上的错误在设计前期就得到解决，否则会增加设计后期的困难，如查错。至少 需对设计的关键部分进行充分的RTL级验证。
当设计代码全部完成之后，可以进行整个设计的RTL级仿真，在进行芯片RTL级仿真之前应与相关人员进行仔细讨论，制定完善的仿真测试方案，尽可能覆盖所有情况。不过 ，根据我们的经验，要想100% 的覆盖 完全靠RTL级仿真是很困难的，必须借助其它手段才有可能。但是，RTL级仿真是所有验证环节中最重要的一环，有时是决定设计成败的关键。在进行RTL级功能仿真时，我们的目标是解决所有的功能方面的问题，因此，RTL级功能仿真可称之为功能验证。
2. 静态时序分析
静态时序分析有两个作用：分析设计是否满足时序要求，分析设计容限。
传统的动态时序分析，指带延时参数的时序仿真，受条件限制，无法完成100% 的时序电路分析。而静态时序分析所采用的方法与动态时序分析不同，它根据电路的拓扑结构和工艺参数 来分析电路的时序关系，在进行静态时序分析时，分析工具需要设计者给出相应的，合法路径由分析工具自动地完成时序分析，如路径延时等信息。
在进行静态时序分析时，要求设计者针对所有路径提出具体时序要求，如I/O管脚之间时序要求，内部 “合法路径” 时序要求等。这样就能保证时序分析的全面性，避免给设计者以错误信息 。
在Xilinx FPGA设计过程中，ucf文件中的时序约束就是设计本身的时序要求。在进行布局布线时，工具本身针对该时序要求不断进行静态时序分析，并进行有关调整，使设计尽量满足要求。
在设计中要切记，通过静态时序分析进行的时序调整只是一种微调，对于大的时序调整，必须从设计本身来保证。
3. 时序仿真 （在ASIC设计领域，有前仿真和后仿真之分）
时序仿真既有动态时序分析功能，又有功能验证之功能。由于时序仿真带有延时信息，因此软件在仿真，其运算量比RTL级仿真时要多得多。而且，若设计改动较多 ，每次功能验证都通过时序仿真来完成的话，极为费时，严重影响设计进度。因此，设计的功能验证应主要由RTL级仿真来保证，时序验证主要由静态时序分析来保证。
然而 在设计中我们无法保证：
1 功能验证通过的设计代码无法保证按照设计原样真实地体现在最终的设计版图上。
2 静态时序分析时 设计者有可能忽略某种情况 但事实上这是错误的。
3 某些功能无法或很难通过RTL级仿真和静态时序分析来保证其功能的正确性。如一些异步处理电路的容限问题等。因此，一定程度的时序仿真是有必要的，但是，时序仿真的次数越少越好 甚至可以为零（目前不推荐）。
二 硬件验证 单板测试方案
完善的硬件验证是保证设计高可靠性的重要手段。为了进行完善的硬件验证，需要所有的单板人员，包括单板软件人员，一起来制定测试方案。同时 ，为了方便硬件测试 ，有必要在原设计中增加必要的辅助测试电路 ，针对可能出现问题的部分 ，根据错误类型设置不同的错误判断电路， 有利于在硬件测试时方便地定位故障。
无论是从硬件测试角度，还是从可靠性设计角度出发，都要求我们的设计尽可能的 “透明化” ：希望在单板硬件出现问题时，能很迅速地定位是否是芯片自身问题， 若是芯片自身问题能很迅速地知道是哪部分出现问题 ，从而采取有针对的处理措施。
3.3 设计的可靠性
一般而言,同步电路比异步电路可靠,并且容易实现。
3.4 设计的规范性
设计应当尽可能规范，目的是：
增加代码可读性，方便相关人员进行设计交流和代码检查。
增加代码的可移植性，类似软IP，方便经验技术交流，加快设计进度。有关规范性的内容参见 “VHDL语言设计规范” 和 “Verilog语言设计规范”。
4 附录
4.1 ASIC可靠性设计
产品可靠性是产品质量的重要指标，是产品维护成本最重要的驱动因素，控制了产品的可靠性指标也就在源头上基本控制了维护成本。根据日本电子行业的统计，产品不可靠的原因中 设计占80%，元器件占15%，制造工艺占5%，持续不断地对产品进行优化，测试，制定和推行产品的可靠性增长计划，对降低产品维护成本非常显著。
在我司发展的历程中，由于在产品的开发设计中没有有意识地强化可靠性设计，对产品的使用环境条件论证不充分，导致产品投放市场后故障率较高，不仅维护成本大增 ，也影响了公司的声誉。从我们基础部ASIC设计角度来看，由于我们设计的芯片在某些方面的不稳定性和不可靠性，一方面影响了公司整个产品的开发进度 ， 影响公司声誉 。另一方面影响了我们基础部的形象，导致其它部门对我们设计出的芯片持怀疑态度，不敢用我们设计出的芯片。如果我们任这种状况发展下去，那么，在不久的将来 ，可以说我们ASIC部门没必要继续存在。
开发产品犹如建一座大厦，芯片犹如大厦的“基石”，“基石”没打好，即便大厦建成，过不了多久也会轰然倒塌 。“基石”稍微有一点换动，住在 大厦 里的人 （用户） 感觉就是一场“地震”。在128模块开发过程中，尤其是在系统联调过程中，我们项目组提供的 “基石” （SD530） 曾给128这座大厦带来若干次 “地震” 而且震感一次比一次强。造成这些 “地震” 的原因有许多，但最重要的是我们当初在设计时对芯片外部工作环境了解不够，对芯片在系统中的重要性认识不足，在芯片可靠性方面考虑很少。根据这几个月的调试 ，我觉得应在以下几个方面认真考虑：
一 时钟。
1 主时钟“抖动”处理 。
在芯片实际应用中，主时钟不可能完全一致，应当有一个正常波动范围。当芯片的主时钟和系统提供的同步信号 （例如8K同步信号） 是来自不同的源时 ，也就是说这两者之间没有固定地相位关系，则 “抖动” 处理尤为重要。这种情况下，时钟同步调整点附近不应该安排任何操作。
2 时钟 “丢失” 处理
正常情况下，这种现象不应当发生。然而，当系统发生意外时，有可能导致在一段时间内时钟没了（例如8K同步信号）不久又恢复正常 ，此时我们的芯片应当随之恢复正常。
二 输入控制信号
1 去毛刺处理。这一点大家基本都知道 ，也比较有经验， 这里就不在罗嗦。
2 误码处理。所谓误码是指输入信号不是毛刺，但出现了正常情况下不可能出现的信号。在这种情况下， 要注意芯片不能陷入 死循环 或者陷入不可恢复的错误状态。
三 芯片 “透明性”
所谓 “透明性” 是指芯片的一些 “活动” 应尽可能让系统知道。例如芯片收到多少帧，发现多少错误帧，芯片由于本身队列溢出丢弃多少帧，发出多少帧等。
在系统联调时，什么问题都有可能出现，如果芯片的 “透明性” 不高 ，对系统来讲是一个黑箱，则很难进行故障定位，会严重推迟开发进度。在系统实际应用过程中 芯片越 “透明” 系统越容易监控芯片。一旦发生故障 ，可在故障起始阶段就进行处理， 不致故障被放大提高系统的可靠性。因此， 增加芯片透明度 ，一可方便故障定位， 加快调试进度， 二可起到一定的防患作用， 提高系统可靠性。
1 接口处理透明 。
在芯片接口处， 芯片应提供各种各样的统计表， 供系统分析判断 。例如 ，在时隙交换网络里 ，输入UHW上收到多少有效帧数据， 错误帧数据 ，输出DHW发送多少帧数据 ，溢出丢弃多少帧数据等。
2 存储管理处理透明
或者说芯片核心处理透明 。一般而言 ，芯片的存储管理部分是芯片的核心， 也是最容易出问题的环节。正常情况下， 芯片的存储管理基本不会出错， 然而， 当系统出现一些意想不到的情况时， 有可能导致存储管理出错， 严重时会导致整个芯片工作不正常 ，进而导致整个系统崩溃。因此 ，芯片的核心处理部分， 应尽可能向系统开放， 很多问题是通过它才得以定位。
四 异常复位 即芯片可恢复性。
百密难免一疏 ，有很多情况是我们设计者在设计之初所无法想象的 。但是 ，当发生异常现象时 ，芯片应保证能极时检查到 ，并将异常信息反映给系统 ，由系统决定如何处理。
如果发生重大异常情况 ，导致芯片工作极不正常， 并有可能引发整个系统崩溃 。此时 ，芯片应提供异常复位功能， 由系统在 错误放大 之前 ，对芯片强行进行软复位。
异常复位是一种破坏性恢复手段，为了处理突发性异常现象。出现问题并不十分可怕，可怕的是出现问题后无法恢复正常
“可恢复性”是芯片可靠性最重要的一个指标。
未完待续！！
往期精彩
本文完！！！
欢迎关注，更精彩的内容等着你！
959
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
