一直以来，都觉得搭建一个SOPC系统很难。不是因为软件的使用存在问题——我可以阅读文档、咨询论坛上的高手、自己动手试试；而是因为搭建一个功 能完备、结构自洽的SOPC系统太不易了——随便打开一个Altera提供的设计示例就会发现那么多的设备、那么多的DMA控制器、那么复杂的启动过程。

对我来说，看懂一个设计示例不难，照葫芦画瓢设计一个也不是难事。但是真的要自己定义需求，搭建一个SOPC系统——这个系统需要多个主设备协同工作，主 设备之间需要竞争从设备的不可重入的使用权，需要自己定义从设备的操作接口，需要采用Scatter-Gather DMA，甚至不要采用Nios II......——我想了很久，一直还没有一个整体而清晰的轮廓。

回想最近一个项目，虽然我的工作FPGA设计是唱戏的主角，但搭台的是系统设计工作。由于外部器件和IP的限制，我们的系统还不是一个SOPC系统，而是 一个“SOPCB”系统。系统设计和PCB布局工作是由我们硬件组的“老大”完成的，PCB上的总线用245搭建，还用CPLD完成Nor Flash换页和FPGA配置工作。“老大”就是老大，系统搭建得漂亮简洁。那么多器件，两层板搞定，尺寸还中规中矩。“老大”的功底让人不得不佩服。

工作快三年了，技术上一直在进步，不只是广度上的，我更看重的是深度上的。让我在FPGA内部设计一个工作稳定的模块基本上不是难事，可是让我像“老大” 那样设计一个“自给自足”的PCB系统，还真是无从下手。模块设计和系统设计的差距是很大的，三年的技术积累还不足以让我跨入系统设计的门槛。

由于有了上面的思考，我决定要补一补系统设计的知识，在网上搜了搜，在书上查了查，大家都推荐Computer Architecture：A Quantitative Approach。到图书馆借来一本07年出的第四版，在前言中读到这样一段话：

The architect's role is not that of a scientist or inventor who will deeply study a particular phenomenon and create new basic materials or techniques. Nor is the architect the craftsman who masters the handling of tools to craft the finest details. The architect's role is to combine a thorough understanding of the state of the art of what is possible, a thorough understanding of the historical and current styles of what is desirable, a sense of design to conceive a harmonious total system, and the confidence and energy to marshal this knowledge and available resources to go out and get something built. To accomplish this, the architect needs a tremendous density of information with an in-depth understanding of the fundamentals and a quantitative approach to ground his thinking.

由此恍然大悟——自己离Architect的目标还远着呢，充其量是个SOPC Builder。