大家好，我是《Verilog编程艺术》的作者，欢迎大家的反馈和提问

weijiaming

第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之外，就是说我们必须要有各方面的知识，要有条不紊的开发管理，要充分理解协议和标准，要写出完整的应用文档，要设计出优美的算法，要使用灵活的数据结构，要经过完整的验证。

nbuzs

刚看了几天， 感觉内容比较务实。
跟一般介绍Verilog的书相比，还是有点干货的

saga009

卖给我一本 啊 以后多请教

weijiaming

本书在当当、京东、Amazon都可以买到，但是在淘宝上可以找到更便宜的，买不买全由您的选择。

weijiaming

第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. 提早集成，就意味着要使用空模块方法。空模块就是约定好协议和接口，输入信号不关心，输出信号使用缺省值，以后用真实模块代替空模块。

huiyuanai3

回复 9# weijiaming

各路豪杰中可有我EETOP的毕老大。。。@jackzhang

574920045

回复 1# weijiaming


    楼主放个目录上去啊！！！

courageheart

JD上买的，感觉设计案例少！

zuiqiangzhe

打算买，看了下目录，不错。

zuiqiangzhe

打算买，看了下目录，不错。