仿真器并非万能之神

  现在已经到了关键时刻。我们已经确定了电路板的设计原型，现正送回实验室进行测试。由于后期规格更改，以及在布线后信号完整性分析过程中发现的问题，这个项目比原计划滞后了两周。这对我而言并非坏事，因为说实话我需要这两周时间，以便将仿真用的测试台准备得停停当当。
    此项目采用 VHDL 编码，而且我采取了一种循规蹈矩的方案——保持层级结构，所有黑盒子 (Black-box)、原语和宏指令都采用全局声明（以便完成的设计具有更高的可移植性并且可以符合 IEEE 标准），而且主要是一种 RTL 类型的方案。当然，我的部分设计具有行为属性，要不然就是我完全忽略了 HDL 的主要优势 ––– 应用行为抽象的能力。
      因此我多费了点事，不过现在我可以开始启动仿真工作了。仿真进行了数毫秒，我对结果相当满意。我可以通过 Wave 编辑器测量占空比与周期得到了我希望的结果，复位逻辑按照我所预测的时钟周期数出现，时钟合成器运行正确无误。而且I/O 信号显示出我所希望的 1、0 以及三态。值得一提的是，我很清楚地记得我在几千行代码中，已经谨慎地避免了异步过程和时钟域交叉，最重要的是解决信号 (Resolved signal)。我想起学科导师曾经略带讽刺地说‘PCB 与芯片设计师才用三态’。
      开始时的信心百倍让我想冒点险，我决定将设计综合在一起。幸运的是，我使用的工具允许我轻松尝试多种不同综合引擎，因此我开始从其中一个内置引擎入手。因为项目中采用了几种复杂的行为状态机，需要花点时间进行优化，不过完成时出现了少数几个次要警告。到目前为止一切顺利。
我的信心更足了一点，接着继续点击“创建 (Build)”按钮，接下来工作流程的“映射 (Map)”、“转换 (Translate)”、“布局布线 (Place and Route)”以及“位文件生成 (Bit File Generation)”，这些操作全部通过与芯片厂商工具的命令行接口在后台执行。映射设计进行了大约一分半就停止了，显示出一条有关 IBUFT 与 OBUFT 的难懂信息。唉……！我知道自己的好日子到头了，真是大梦初醒啊！
      我接下来通常会耸耸肩膀，然后切换到 FPGA 厂商的综合器，看看其优化器能否产生可以顺利布局与布线的结果。因此，点击几下鼠标之后我开始重新运行 “综合（Synthesis）”与“创建（Build）”。这次我注意到综合多少比以前快了一点。我心中燃起希望，因为厂商的引擎在进行较少程度的优化，而且将产生尽管更庞大、但更精确的实施方案。然后在映射过程中在同一地方嘎然而止，同样出现了让人费解的错误消息，然后是一条警告：
 
ERROR:NgdBuild:924 - bidirect pad net 'DATA_IO<15>' is driving non-buffer
   primitives:
     pin I1 on block U_dspboard_fpga/fb_epb_intf_inst/n12g with type AND2B1
WARNING:NgdBuild:465 - bidirect pad net 'DATA_IO<15>' has no legal load.

     我开始嘟嘟囔囔，旁边的同事眯起眼睛，像老鹰山姆那样斜眼着我。庆幸的是，我能够从消息屏幕中的错误消息中找到出现错误的代码行。双击与两个串联的缓冲区有关的第一个错误消息后我找到了以下代码片段：
DATA_IO  <= DATA_IN when CNTL_IN(4) = '0' -- write to Ext. Device
                    else (others => 'Z');
DATA_OUT <= DATA_IO; -- data from core to CF (5000_0050)
      我最初的想法是“啊哈，我弄出了一个三态端口与多路复用器，多么好的想法呀？”。聪明而又经验丰富的读者一眼就能看清这个问题，但是这种错误会让 FPGA 新手难倒好几天，让人寝食难安，心力憔悴。我盯着这三行代码看了半分钟，意识到应该随便找张纸画出我最初的意图：
 
     现在我认识到，我之前认为综合引擎会明白我并不想在器件中加入高阻抗信号。实际上，当我再次查看错误与警告消息之后才清楚它就是这么干的：
 
     如果您是一名出色的 FPGA 设计人员并且确实阅读了数据手册与程序库指南，那么您立刻就会明白这是不可能的事情。我所知道的任何 FPGA 布线资源都不会允许这种连接。[!--empirenews.page--]
我首先认识到可以用原理图当画出以下简单的 IOBUF 电路：
 
     由于DATA_IO 与 DATA_OUT连接到较高层文档中的 IO 接口，综合器会插入用于 DATA_OUT的适当 OBUF，因此我无需在此画出。这个例子可以很好地说明了原理图与方框图设计方案如何能实实在在地减少未知错误。我的第二个更加惊人的发现是我在 VHDL 代码中编写的内容能够全部得到正确仿真，这里显示出了我实际预期的信号变化。当然，我始终明白能够仿真与能够综合之间的区别。这里有一个新的误解 —— 我可以无错地仿真并合成我的设计。我敢断言，现在应该被问：“它可以仿真，那么可以合成吗？可以被映射吗？”
      这个场景是我虚构的，尽管它出自我亲身经历过的真实事件。我曾经与许多喜欢在设计流程中使用 VHDL 和 Verilog 的 FPGA 设计人员深入探讨过。我和他们有一致的看法，就是他们的大多数设计对于基于原理图的方法来说过于复杂。也就是说，您是否主要通过 RTL 进行设计。HDL 的发明可减少描绘逻辑函数的工作量，因为门电路与触发电路的数量太多，也太繁复。然而， FPGA（和 ASIC）一直继续遵循着摩尔定律。设计也是如此，复杂到使用VHDL 或 Verilog 设计会把你带入泥潭，让你再也看不清整体设计意图。上面问题就是例证。
      设计人员需要保持他们设计的领先地位。我深信他们将别无选择地这么做 —— 采用更高端的方法来赢得时间和自由，从而可以集中精力进行其产品最重要部分的设计，即在市场上能使他们脱颖而出的部分。这个行业正在面临的挑战是：技能娴熟的资深设计人员必须放下架子来使用与工具配套提供的免费的IP，而不是自己亲手通过 HDL 把它们重新出来。我能理解这个挑战：作为一个真正的工程设计迷，我所做的应该是这个世界上许多人都做不到的（或者说我也相信）。不过事实上，如果我想设计更好的产品，并且更快地完成，我就必须站在别人的肩上，对他说“谢谢”，然后采用方框图的方法迅速将我的系统组合出来。接下来我就可以专心致力于设计我的创意，并且把它集成到整体系统中，使整个系统更加可靠并出类拔萃。