大家好，我是《Verilog编程艺术》的作者，欢迎大家的反馈和提问
我是《Verilog编程艺术》的作者，欢迎大家的反馈，欢迎大家提出问题和意见。
有的人可能觉得本书很好，有的人可能觉得本书不好，好不好全凭大家的感觉，下面是我从京东商城和当当网收集的对本书评价：
1. 2014-03-30 10:11 工程师的作品
心得：老师推荐的，我就毫不犹豫地买了
2. 2014-03-27 23:17 一般般，不咋地
心得：各种网上凑成的版本，感觉思路不是很清晰。
3. 2014-03-23 21:45 写得不错
心得：内容面向工程实际，讲了不少实际项目中遇到的问题及设计技巧，挺有参考价值。
4. 2014-03-23 08:34来自京东iPad客户端
心得：很不错，适合工程师看
5. 2014-03-19 09:06 买回来看了100 页特别适合verilog提高
心得：书中介绍了很多其他书中没有的知识，能学到很多实际的东西，不过得对verilog比较熟悉之后读会比较有用！
6. 2014-03-18 10:34 好书不错
心得：内容不错，很好 适合有一定基础的人看
7. 2014-03-17 21:13 不错的书
心得：写的不错，很有参考性！推荐
8. 2014-02-25 16:48 Verilog编程艺术
心得：ASIC设计老师推荐的书，相当给力，值得推荐。
sculiubing 回复 yintengfei ： 你读过这本书么?到底写得怎么样?
252572883_m 回复 yintengfei ： 李广军，成电，哈哈
yanhai325 ： 壮哉 我大成电
yintengfei ： 李老师的课吧 。
9. 2014-02-17 22:10 非常有帮助的一本书
心得：工程师写的书，介绍了很多工程概念 本书更加注重Verilog编程的方法论和实用性, ........................
10. 正版很赞 内容不错 纸质很好
书很好，是正版，内容也好！由于有活动，价格比其他地方便宜一点！
11. 内容不错
书买回来后拆开包装看了一下，有一些折过得痕迹，感觉有点小失望
有人说本书是拼凑的，这个我承认，我承认我使用了很多网上的资料，这个我在前言中已经做了说明，
但是本书还包含了我的多年的工作总结，而且在我之前还没有拼凑出这样的书，如果有这样的书，
那就不用我费这么大劲编写此书了。
希望大家仔细研究一下，肯定会对你的Verilog编程有很大的提高。
谢谢大家。
书有电子版的嘛?还是怎么看?
对不起，我不能提供电子版，这是和出版社的约定。
verilog 不是有标准吗 而且有那么多e文的优秀书籍 电子版也有
查了一下，评价不错，考虑ing
这是给自己打广告吗?
1. 我承认我是在给自己打广告，希望能多卖出去一些书，出版社是按8%给我出版费，
但是对于我来说这只是一笔很小的收入罢了。
2. 我希望能从大家获得各种反馈、意见和提问，希望能有改进和提高。
3. 我希望我们能就我们感兴趣的问题进行讨论。
4. 虽然有Verilog-2005标准，还有很多的电子文档，请问有几个人仔细看过?
5. 欢迎有人将其扫描后放到网上，帮我做一下宣传。
谢谢大家！
觉得出点样章出来看看，不然大家都不知道好坏，只能一味的广告
1. 有兴趣者可以到书店去翻一翻，再做决定。
2. 可以到京东商城查看评论，咨询一下那些购买人。
3. 我是希望有人加入我的群，我又不是非得希望你们购买。
4. 我明确地告诉大家，那些联合力荐是出版社找人写的，我不认识那些推荐人，是出版社搞的营销手段。
我看中的是从工程师的实际反馈，这样对于我和大家来说更有说服力。
同意小编的宣传，也支持小编
建议送本书给我，我可以反馈你我的看法。
语法以外的话题是我感兴趣的，高级设计。我没看到过其他书讨论书写文档，从名称上来我对此有兴趣。是讨论把如何把程序逻辑用WORD等软件用日常语言和流程图呈现出来吗?
稍微介绍一下啊，看看有没有大家感兴趣的点
不然谁花那么多钱去买一本可能用不上的书
给个电子版吧，印刷板的不方便。
看了下介绍，感觉作者写的verilog说很另类，明天买一本来看看
书名很霸气呀.
很不错，谢谢
看了一下不错
序 言
Verilog 是一种硬件描述语言（Hardware Description Language，HDL），是一种以文本形式描述数字系统硬件结构和行为的语言，可以在多个抽象层次上（从开关级到算法级）为数字设计建模。Verilog提供了一套功能强大的原语，其中包括逻辑门（Gate）和用户定义原语（UDP），还提供范围宽广的语言结构，不但可以为硬件的并发行为建模，也可以为硬件的时序特性和电路结构建模。Verilog具有下述这些描述硬件的能力：行为特性、数据流特性、结构组成、监控响应和验证能力。
Verilog HDL的发展历史如下：
1. 1983年，GDA（Gateway Design Automation）公司的Philip Moorby首创Verilog语言。Moorby后来成为Verilog HDL-XL的主要设计者和Cadence公司的第一合伙人。
2. 1984年，Moorby设计出第一个用于Verilog仿真的EDA工具。
3. 1986年，Moorby提出用于快速门级仿真的XL算法。随着Verilog-XL的成功，Verilog得到迅速发展。
4. 1987年，Synonsys公司开始把Verilog作为综合工具的输入。
5. 1989年，Cadence公司收购GDA公司，Verilog成为Cadence公司的私有财产。
6. 1990年，Cadence公司公开发布Verilog。随后成立的OVI（Open Verilog HDL International）负责Verilog的发展，制定标准。
7. 1993年，几乎所有的ASIC厂商都开始支持Verilog，并且认为Verilog-XL是最好的仿真器。同时，OVI推出Verilog-2.0规范，并把它提交给IEEE。
8. 1995年，IEEE发布Verilog的标准IEEE1364-1995。
9. 2001年，IEEE发布Verilog的标准IEEE1364-2001，增加了一些新特性，但是验证能力和建模能力依然较弱。
10. 2005年，IEEE发布Verilog的标准IEEE1364-2005，只是对Verilog-2001做一些小的修订。
11. 2005年，IEEE发布SystemVerilog的标准IEEE1800-2005，极大地提高了验证能力和建模能力。
12. 2009年，IEEE发布SystemVerilog的标准IEEE1800-2009，它把SystemVerilog和Verilog合并到一个标准中。
13. 2012年，IEEE发布SystemVerilog的标准IEEE1800-2012。
有的工程师可能觉得既然Verilog已经进化到SystemVerilog，那么就干脆直接去学习SystemVerilog吧。其实Verilog和SystemVerilog之间的关系就如同C和C++之间的关系，虽然C++很好，但是C现在还是被广泛地使用，包含各种操作系统和各种应用软件，同样Verilog还是被广泛地在设计中使用，大量的系统和IP还是用Verilog写成。另外，当我们清楚地理解Verilog的语言特性之后，我们可以更好地学习SystemVerilog，例如，为什么要在SystemVerilog中增加unique case和 priority case?为什么要增加always_comb、always_ff和always_latch?由于篇幅所限，本书的重点在于Verilog编程，对SystemVerilog将只简单地介绍一下它的特点。
Verilog语言发展很快，相应的EDA工具发展也很快，但是在Verilog编程上还存在很多的问题：
1. Verilog的编码风格多样，工程师之间的风格不统一，而且某些工程师的风格很不好，导致在代码的整洁度、可读性、可重用性上有很大欠缺。
2. Verilog的语法比较自由，在某些方面存在易混淆和易出错的地方，导致竞争条件，导致前后仿真不一致。
3. 很多工程师还局限在Verilog-1995上，没有考虑使用Verilog-2001的新特性，导致啰嗦冗余的代码。
4. 很多工程师对Verilog的某些语言元素没有充分地理解，可能存在错误使用的情况，导致设计失败。
5. 很多工程师对可配置和可重用的设计不够重视，导致设计难以维护、难以移植，导致设计成为“一锤子的买卖”。
6. 对于常用设计中的时钟生成和复位设计，缺少讨论，事实上这是我们需要高度关注的地方。
7. 对于验证，有些工程师或者对其不够重视，或者存在概念上的偏差，或者存在设计上的误解。
前 言
本书来源于实际工程的设计，是从工程设计方面对Verilog编程的反馈。本书既包含作者对Verilog编程规范的总结，也包含作者对多年工程设计的经验总结。
本书更加注重Verilog编程的方法论和实用性，深入地探讨编码风格、语言特性、简洁高效和时钟复位等实际问题，深入探讨如何避免使用易混淆和易错误的语句，如何避免前后仿真不一致，如何充分发挥Verilog-2001的特性。本书主要分为以下几大部分：
1. 开发原则：探讨高效开发的原则、开发的组织管理、开发工具的使用和切实可行的编码风格等。作者对开发的原则、管理、工具和风格做了详细的介绍，强调只有把它们有机地结合在一起，我们才能做出好的设计。作者对各种编码风格（书本上的和网上的，好的和差的）做了较为详尽的总结，强调只有在好的编码风格约束下，我们才能写出美的Verilog程序。
2. 语言特性：探讨Verilog语言的特性，重点在Verilog-2001标准、always语句、case语句、task和function、循环语句、调度和赋值等。作者对Verilog-1995和Verilog-2001做了对比，探讨如何发挥Verilog-2001的新特性，如何用其编写出简洁的代码。作者对某些语言元素做了详细的说明，例如signed应用、loop语句、disable语句、task和function等。作者对Verilog中各种容易混淆和错误的地方（例如，敏感列表、case语句、静态函数等）做了详细的说明，探讨如何避免混淆和出错，探讨如何避免前后仿真不一致。作者对赋值和调度做了详细的探讨，因为它们是理解仿真执行和避免竞争条件的关键。
3. 书写文档：探讨如何写出优秀的应用文档和设计文档，并以GPIO文档为实例。作者强调Verilog编程只是设计的一部分，写出优秀的文档也是非常重要的。
4. 高级设计：探讨IP使用、代码优化、状态机设计、可配置设计和可测性设计，并给出大量的示例代码。作者在此介绍IP分类、选择和使用，介绍几种优化代码的方法，介绍状态机的分类和如何编写出强壮的状态机，介绍可测性设计的方法。作者着重地探讨可配置设计的实现方法，并用不同例子说明这些实现方法。
5. 时钟复位：探讨异步设计、亚稳态、时钟生成和复位设计。作者在此探讨异步设计中的亚稳态和对应的解决方法，探讨时钟生成的方法和实际例子，探讨同步复位、异步复位、复位同步器、复位分布树等问题。
6. 验证之路：探讨整洁验证、验证方法和验证环境。作者对验证方法做了一些介绍，探讨验证中可能遇到的问题（例如，网表验证、灵活验证等），并以实际例子说明如何搭建验证环境。
7. 其他介绍：介绍SystemVerilog的特点，介绍相对于Verilog的增强，还对VMM、OVM和UVM做了对比。作者强调为了加强我们的设计和验证，我们必须要从Verilog过渡到SystemVerilog。
本书参考并引用了著名的Verilog专家Cliff Cummings写的一些论文，这些论文探讨了我们在设计中可能遇到的各种问题和相应的解决办法，探讨了如何写出简洁严谨一致的Verilog代码，作者在此向他表示致敬。如果读者对原文感兴趣，可以到http://www.sunburst-design.com下载这些论文，非常值得一读。
另外，作者在编写本书的时候，充分地考虑了阅读的友好性，直接用1、2、3、......列出来各种特性和要点，而且特地在一些地方增加了空行以便于阅读，总之要让人看得舒服，看得明白。
第1章 美的设计
我们为了寻求美，排成一条队，美在前面等着你，把美来品味。
我们为了创造美，汗水湿衣背，假如你要怕吃苦，美将要引退。
美在那青青的山，美在绿绿的水，美在那云雾里，和你来相会。
.................................................................................................
——张藜《为了寻求美》
1.1 美学观点
“程序设计是一门艺术”这句话有两个意思：一方面是说，程序设计像艺术设计一样，深不可测，奥妙无穷；另一方面是说，程序员像艺术家一样，也有发挥创造性的无限空间[梁肇新]。
Donald Knuth认为“计算机科学”不是科学，而是一门艺术。它们的区别在于：艺术是人创造的，而科学不是；艺术是可以无止境提高的，而科学不能；艺术创造需要天赋，而科学不需要。所以Donald Knuth把他的4卷本巨著命名为《计算机程序设计艺术》（The Art of Computer Programming）。
Donald Knuth不仅是计算机学家、数学家，而且是作家、音乐家、作曲家、管风琴设计师。他的独特的审美感决定了他的兴趣广泛、富有多方面造诣的特点，他的传奇般的生产力也是源于这一点。对于Donald Knuth来说，衡量一个计算机程序是否完整的标准不仅仅在于它是否能够运行，他认为一个计算机程序应该是雅致的、甚至可以说是美的。计算机程序设计应该是一门艺术，一个算法应该像一段音乐，而一个好的程序应该如一部文学作品一般。
Bjarne Stroustrup，C++语言发明者，说“我喜欢优雅和高效的代码。代码逻辑应当直截了当，让缺陷难以隐藏；应当减少依赖关系，使之便于维护；应当依据分层战略，完善错误处理；应当把性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来”。他特别使用“优雅”这词来说明“令人愉悦的优美、精致和简单”[Robert C. Martin]。
一个人的美学观点会影响他的程序设计，因为Knuth有这么多的艺术爱好，所以他把程序设计看成艺术设计，在程序设计中要体现出程序的美。同样，当Bjarne Stroustrup编写优雅且高效的代码的时候，他也是在程序设计中寻求美。
我的美学观点是简单和谐、整洁有序；某导演的美学观点是宏大华丽、空洞无味；还有些人的美学观点是乱七八糟、凑合了事；你的美学观点是什么呢?有些人很自负，感觉良好，以为领悟到了编程的真谛，看到代码可以运行，就洋洋得意，可是却对自己造成的混乱熟视无睹。那堆“可以运行”的程序，就在眼皮底下慢慢腐坏，然后废弃扔掉。
因为Verilog编程就是一种程序设计，所以Verilog编程也应该象设计艺术作品一样，要仔细打磨、精雕细琢，要经历痛苦与无奈，也要经历快乐与自得。设计要有自己方法论，要体现自己的奇思妙想，要让自己的设计有更长的生命力，而不是豆腐渣工程。
为什么那么多人对Apple的手机和电脑情有独钟?因为它们都是美的设计，因为它们的设计者都在追求美。同理，我们在做Verilog编程的时候也要追求美，也要设计出美的Verilog程序。
1.2 美是修养
你的文档是否清晰明了?你的设计是否符合要求?你的代码是否书写整洁?你的验证是否覆盖全面?你的环境是否设计完美?你的能力是否日益提高?
你是否达到庖丁解牛的境界，“恢恢乎其于游刃必有余地矣，…….，提刀而立，为之四顾，为之踌躇满志，善刀而藏之”?
任何东西都是有章法可循的，美的设计也需要遵循一定的原则和模式，需要严谨精确，需要规范详细，需要亲身体验，需要刻苦实践，需要习以为常，然后才能设计出干净清爽、无懈可击的代码，才能达到庖丁解牛之境界。
图1-1 庖丁解牛的牛（来源于网络）
德国人非常注重规则和纪律，干什么都十分认真。凡是有明文规定的，德国人都会自觉遵守；凡是明确禁止的，德国人绝不会去碰它。在一些人的眼中，在许多情况下，德国人近乎呆板，缺乏灵活性，甚至有点儿不通人情。但细细想来，这种“不灵活”甚为有益。没有纪律，何来秩序?没有规矩，何有认真?
德国人很讲究清洁和整齐，不仅注意保持自己生活的小环境的清洁和整齐，而且也十分重视大环境的清洁和整齐。在德国，无论是公园、街道，还是影剧院或者其它公共场合，到处都收拾得干干净净，整整齐齐。德国人也很重视服装穿戴。工作时就穿工作服，下班回到家里虽可以穿得随便些，但只要有客来访或外出活动，就一定会穿戴得整洁。看戏、听歌剧时，女士要穿长裙，男士要穿礼服，至少要穿深色的服装。参加社会活动或正式宴会更是如此。
德国人能研究出高精尖的技术，能制造出精密的仪器，是不是与他们的“守纪律讲整洁”有极大关系呢?
“汝果欲学诗，功夫在诗外”，陆游认为：一个作家，所写作品的好坏高下，是其经历、其阅历、其见解、其识悟所决定的。当然，他所说的“功夫在诗外”，也不仅仅是这些，其才智、其学养、其操守、其精神等等形而上的东西，同样也是诗人要想写出好诗的“功夫”。但陆游强调作家对于客观世界的认知能力，主张作家从身体力行的实践，从格物致知的探索，从血肉交融的感应，从砥砺磨淬的历练，获得诗外的真功夫。陆游在另一首诗中又说“纸上得来终觉浅，绝知此事要躬行”，所以所谓的“功夫在诗外”，就是强调“躬行”，要到生活中广泛涉猎，开阔眼界。
我们要对Veilog编程要做出美的设计，但是我们有好的编码风格只是我们设计出优美代码的基础，功夫其实是在Verilog之外，就是说我们必须要有各方面的知识，要有条不紊的开发管理，要充分理解协议和标准，要写出完整的应用文档，要设计出优美的算法，要使用灵活的数据结构，要经过完整的验证。
刚看了几天， 感觉内容比较务实。
跟一般介绍Verilog的书相比，还是有点干货的
卖给我一本 啊 以后多请教
本书在当当、京东、Amazon都可以买到，但是在淘宝上可以找到更便宜的，买不买全由您的选择。
第2章 高效之道
这里参考了《敏捷软件开发》、《代码清洁之道》和《高效程序员的45个习惯》等书。
2.1 敏捷开发
如同做软件开发一样，做数字电路设计的过程也是充满了各种问题：矛盾、吵架、无奈、拖拉、笨重、繁杂、低效、设计拖后腿、验证不充分、错误层出不穷。
敏捷开发（Agile Development）是一种更好的软件开发方法，它着重关注那些真正重要的事情，少关注那些占用大量时间而且又没多大益处的事情。它的开发宗旨是：以人为本、团队合作、快速响应变化和可工作的软件。
敏捷开发是软件工程的一个重要的发展，它强调软件开发应当能够对未来可能出现的变化和不确定性作出全面反应。敏捷开发是一种轻量级的方法，最负盛名的轻量级方法应该是极限编程（Extreme Programming）。重量级方法是与轻量级方法相对的方法，它强调以开发过程为中心，而不是以人为中心。
敏捷方法可以快速响应变化，强调团队合作，专注于具体可行的目标，这就是敏捷的精神。它打破了那种基于计划的瀑布式软件开发方法，把软件开发的重点转移到更加自然和可持续的开发方式上。敏捷开发就是在一个高度协作的环境中，不断地使用反馈进行自我调整和完善。
1. 要有结构合理的研发队伍，要求有规划、软件、硬件、算法、前端、后端、模拟、验证、测试、应用、市场等工程师。
2. 要有团结协作、全心投入、严谨踏实、勤奋上进、高效快速、专业精深的精神，要避免出现影响团队和谐的因素。
3. 要不断地学习新知识、新技术、新方法和新标准，要有打破砂锅问到底的精神。
4. 要使用反馈纠正开发方法和开发过程，当发现问题时，不要试图掩盖问题。
5. 要和客户保持协作，保证项目符合客户的需求。
6. 要保证开发持续不断，要持续注入能量，切勿时断时续，但是我们也要注意欲速则不达。长时间高强度的工作之后，我们的工作也许不再有效率，烦恼拖沓低效，那么就需要改变一下，休息一下，放松一下，也许我们就灵光乍现呢。
7. 要保证代码的整洁和可扩展，防止代码慢慢变坏，最后变得不可收拾。不要让代码失去清晰度，不要让代码失去控制。代码的整洁程度，很大程度上影响着代码的维护难度。实行团队成员之间代码的互相审核制度，提出修改意见，这样能更好地保证代码的可读性。
8. 要提高验证效率，节省验证时间。使用单元验证方法，低层次的模块要尽量做到随机验证和全覆盖验证。模块验证可以保证设计出更清晰的代码，可以更方便地理解整个模块。
“流水不腐，户枢不蠹”，厨房脏了就擦一下，总比满墙都是油烟以后再去清理的代价小得多。有价值的东西，比如回顾、重构、验证，一切有利于团队建设、提高生产力的的实践都应该频繁且持续去做，然后日积月累就养成了习惯。
2.2 代码质量
数字电路设计是非常复杂的，它的成功不但依赖于架构和项目管理，也与代码质量紧密相关。代码质量与其整洁度成正比，整洁的代码，既在质量上较为可靠，也为后期维护、升级奠定了良好的基础。代码质量要通过一条条的规则来保证，只有在良好的编码风格保证下，才能编写出优质的代码。
在梁肇新的《编程高手箴言》里，“以前所有的C语言书中，不太注重格式的问题，写的程序像一堆堆的垃圾一样。这也导致了现在的很多程序员的程序中有很多是废码、垃圾代码，这和那些入门的书非常有关系。因为这些书从不强调代码规范，而真正的商业程序绝对是规范的。你写的程序和他写的程序应该是格式大致相同，否则谁也看不懂。如果写出来的代码大家都看不懂，那绝对是垃圾。如果把那些垃圾‘翻’了半天，勉强才能把里面的‘金子’找出来，那这样的程序不如不要，还不如重新写过，这样，思路还会更清楚一点。这是入门首先要注意的事情，即规范的格式是入门的基础”。
“正确的程序设计思路是成对编码，先写上面的大括号，然后写下面的大括号。这样一个函数体就已经形成了，它没有任何问题。成对编码就涉及到代码规范的问题。为什么我说上面一个大括号，下面一个大括号，而不说成是前面一个大括号，后面一个大括号呢?如果是一般C语言的书，则他绝对是说后面加个大括号，回头前面加个大括号。事实上，这就是垃圾程序的写法。正确的思路是写完行给它回车，给它大括号独立的一行，下面大括号独立的一行，而且这两个大括号跟那个for单词中间错开一个TAB”。
“代码一定不能乱，一定要格式清楚。就是你写的程序我能读，我写的程序你也能读，不需要再去习惯彼此不同的写法”。
垃圾代码体现在什么地方呢?
1. 有些人没有好的书写风格，没有好的命名习惯，没有清晰的层次结构，没有好的文件和目录结构，繁琐啰嗦，在可读性和可维护性上没有什么保证。
2. 有些人认为代码能正确运行就可以了，就万事大吉了，即使是对于非常糟糕的代码，他们也是自我感觉良好，他们不会在代码上精益求精。
3. 有些人编写代码，为了修正错误或为了支持新功能，打了一个补丁又一个补丁，最后成了一件“百衲衣”。
4. 有些人不敢对能正确运行的代码重构，担心稍微的改动就会导致代码运行不正常，这样的代码像个易碎的瓷器。
所有这些都是不负责任的表现，都是懒惰，最后的代码只能是偏离正道、乱七八糟、惨不忍睹、死气沉沉、难以管理、难以阅读、难以维护，随着混乱的增加，团队生产力持续下降，最后趋于零，会使整个开发团队深陷沼泽，难以自拔，最后只能像扔垃圾一样扔掉这些垃圾代码。
我们是不是很鄙视那些在公共场所乱丢垃圾的人?那么我们为什么能容忍这些给项目带来垃圾代码的人呢?
让代码工作和让代码整洁是两种不同的工作态度。只要代码“能工作”就转移到下一个任务上，然后那个“能工作”的代码就留在了那个所谓的“能工作”的状态，这其实是一种自毁行为。而让代码整洁则是对设计的精益求精，是对工作的认真负责。
我很爱看《我爱发明》，因为里面的发明都很巧妙，解决了很多我们以为不能自动化的事情，例如收土豆机、收花生机、收西红柿机、采棉机、炒菜机、摊煎饼机、柠条平茬机、砸核桃机、山楂去核机、抓老鼠机等，这些发明的发明人都在不断地改进优化自己的设计，精益求精，提高工作效率和工作质量。
代码的质量体现在每一个细节里，包括每一个信号的名字，每一行代码的书写，每个模块的构造，否则就如同“一个脏乱差的桌面会影响你的美好的办公环境”一样。下面就是代码整洁的原则：
1. 好的代码需要在一定的原则、模式和实践下保证的。好的代码不是一天练成的，需要非常的用功，需要阅读大量的代码，需要仔细琢磨那些好的代码。
2. 在遵循一定的原则和模式下，得到代码整洁的感觉，这种代码整洁感使得设计人员制定修改计划、按图索骥、重构代码。
3. 整洁的代码只做一件事，意图清晰、干净利落、直截了当、力求集中，全神贯注。糟糕的代码想做太多事，意图混乱，目的含混。
4. 整洁代码是以增量式方式开发出来的，这样可以精炼并结构化代码。
5. 代码的重构要在完整的验证下保证的。如果没有得到完整的验证，很难做到重构代码。
6. 源代码可以被读懂，不是因为其中的注释，而应该是由于它本身的优雅：变量名意义清楚，空行和空格使用得当，逻辑分块清晰，表达式简洁明了。代码能够自我解释，而不用依赖注释。
7. 使用注释描述设计意图，但是注释不能代替优秀的代码。
8. 代码简单，便于阅读。但要想达到代码简单，你所做的并不简单，简单并不意味着简陋、业余和不足，简单意味着你的技术精华。
9. 不要说“稍后我再调整代码”，因为有个原则，“稍后等于永不（Later equals never）”。要随时随地地调整代码，让代码始终处于整洁状态，最后达到美好的设计。
我们应该从一开始就编写易读易维护的代码，我们应该不停地重构我们的代码，提高表达力，整理编码格式，整理数据结构，提取公共模块和函数，清除陈腐无用的代码，最终写出优雅高效的代码。
2.3 版本控制
在项目开发中，要用版本控制（Revision control）统一管理所有的源代码、验证代码和脚本文件。可是令人惊讶的是，很多团队仍然喜欢把这些文件放到一个网络共享设备上或者就放到每个人的目录里，这是一种很不专业很低效的做法，一方面没有达到统一的管理，另一方面开发的步骤记录不全，难以恢复到以前的状态。
版本控制是对设计实行全面配置管理的基础，用以保证设计状态的一致性。版本控制是对设计不同版本进行标识和跟踪的过程。版本标识的目的是便于对版本加以区分、检索和跟踪，以表明各个版本之间的关系。一个版本是设计的一个实例，在功能上和性能上与其他版本有所不同，或是修正、补充了前一版本的某些不足。实际上，对版本的控制就是对版本的各种操作控制，包括检入检出（Checkin/Checkout)控制、版本的分支和合并（Branch/Merge）、版本的历史记录和版本的发行。
常用的版本控制软件有很多，例如CVS、VSS和SVN等，我们要根据设计的需要选择合适的版本控制软件。
2.4 提早集成
代码集成是主要的风险来源，要想规避这个风险，只有提早、持续而有规律地进行集成。成功的集成就意味着系统在不停地通过验证。
1. 提早集成可以尽早地暴露系统问题，越容易发现系统和模块在设计上的错误。
2. 提早集成可以推动整个系统的设计，提早展开各项工作，规划时钟、复位和测试等工作，设计综合和时序分析脚本，做出全芯片的管脚列表，做出全芯片效率、功耗和面积的分析。
3. 提早集成模块，如同建筑上的框架结构一样，一旦框架结构建好，各方面工作就可以同时施工，例如外墙装修、内部装修、通水电气。
4. 提早集成需要强大的构建系统，编译、仿真和综合的过程都要脚本化和自动化，这样才能把集成的工作变得容易一些。
5. 提早集成，就意味着要使用空模块方法。空模块就是约定好协议和接口，输入信号不关心，输出信号使用缺省值，以后用真实模块代替空模块。
各路豪杰中可有我EETOP的毕老大。@jackzhang
小编放个目录上去啊！
JD上买的，感觉设计案例少！
打算买，看了下目录，不错。
打算买，看了下目录，不错。