设计不能一上来就写代码，总体架构很重要，详细设计也很重要。首先时钟方案，复位方案，初始化方案（加载、初始化配置等），时钟域划分（尽量做到同时钟域），都要开始时想清楚，这样才能避免后期大改，或是每有修改都到处掣肘。详细设计则要将模块间接口，模块内部处理层次划分，时钟域转换方式，接口间数据格式，时序关系，维测方式，关键时序（有时信号传递间有较耦合的时序打拍要求）等都要设计清楚，只有这样设计后，动笔写代码才能够条理清楚，不会有后期的大问题。往往写完后，经过静态检查，基础仿真验证后，上板即可无大碍。

这样的好处还在于，设计承载于文档，不管是检视还是后期维护，才有章可循，还可增加检视等环节的效果。文档的表达形式，个人非常认可，字不如表，表不如图的说法。流程图用于描述过程性处理，时序图用于描述重要时序关系，协议交互图可以用于描述模块间交互关系，框图描述架构划分，详细设计设计到管脚级，每拍时序都不为过，前期细致的设计会带来后期大量拆东墙补西墙式的修改和问题定位所花费的时间。这都是经过血泪史之后得到的体会。

看过xilinx的手册，风格挺好，图和标注的一致性，让文档看起来轻松很多，图的描述能够让人对器件层次结构很清晰的了解，配以文字的讲述，基本可以很好的理解器件设计关键信息。个人还比较赞同清晰的分层解析图，同样的框图结构下，分不同层次介绍各类信息，比如说时钟走线，业务面信息走线，维护控制面走线等，在同一套框图背景下，分几张图呈现，效果会很好，感觉也很专业。

总体设计和详细设计完成后，充分的检视是重要环节。检视可以弥补个人思维的不足，也可以将集体的经验落地于每一个新的设计，还可以优化设计。重要的方案需要保证专家人员的参与检视，比如说，serdes初始化设计需要将AE的IO专家邀请过来参加，他们会提出器件必需的设计方案，减少设计的不合理之处，此外，有时器件有些小bug或者隐藏要求，可能在器件手册中没有体现，而是在AE日常接触问题中记录下来的，就可以尽早引入避免设计错误，举个小例子，xilinx有款器件serdes初始化时要求，复位管脚在前500ns内必须是高电平，随后要检测到上升沿才真正触发复位，否则会出现初始化概率失败，这样的设计要求，如果没有AE前期介绍将容易忽略，而导致后期出现低概率问题，定位花费可想而知。

代码设计过程中，多次的检视，也非常有效果。软件设计有“小黄鸭”思想，硬件描述设计也适用，就是程序人员能够将每行代码都讲解清楚其含义，虽然个人一直认为硬件描述语言由于属于并行语言，检视不易，但是对于程序员个人理清思路是有帮助的，所以还是可以代码检视（我之前做版本经理时，还不太认同代码检视，不过最近的一个项目过后，还是觉得是有效果的，如果参与检视的人员经验足够丰富）。硬件描述还有一个好帮手就是仿真波形，时序关系可以在仿真波形的帮助下，看的较清楚，但是由于信号众多，可以一组组分析，总的要确保每组信号的准确性，一拍差误都不要有。

仿真的时候，单元测试重要性较高，真理和魔鬼都处于细微处，只有经得其推敲才是真正的好代码，那么单元测试每组信号的分析，就是解析的手术刀，帮我们剖析代码，眼见为实，单元测试平台个人不觉得要多么高级，只要能够真正构造出信号间的时序关系即可，哪怕是用force，也可以起到效果。系统仿真，看护系统级问题，模块配合级问题，以前曾要求大家自动化，长时间，现在看来必要性不大，记得和TI verification enginerr交流过，他们每个测试只发5,6个pkt，边界通断即可。板级测试，则是另一头重要活动，发现可靠性问题，要满足性能、压力的要求，满规格、长时间、动态切换、加扰、高低温、电压压力测试等，都是挖掘可靠性问题的手段，经过这样的测试以及测试出问题定位过程之后，我们设计面对市场应用时，才能稳定且有有效的维测手段。设计人员才能算是交出一份高质量的设计，自己也才能轻松和喜悦。