发布：一种FPGA逻辑架构与相关规范

更新历史
201901026：

1. 首次发布

一些电子学工程师在设计FPGA逻辑时，选择的架构就是没有架构——他们并没有考虑过“架构”这个问题。对于中小型规模的FPGA逻辑来说，常见的有如下几种架构，这里对它们做了一下对比。

如上图所示的三种架构，最左边的"模块间信号传输无握手的SMMS架构"，便是所谓的“选择的架构就是没有架构”。当然，以上三种架构各有优劣，没有哪个是全面无死角地碾压另外两个的。我们不妨对它们做一些简单的对比：

条目	模块间信号传输无握手的SMMS架构	基于AXI4协议的环形MMMS架构	基于AXI4协议的互连MMMS架构
模块复用的难易程度	困难。主要原因在于接口不统一。	简单。因为接口是统一的。	简单。因为接口是统一的。
增、删模块的麻烦程度	很麻烦。增、删Slave模块时，接口模块需要作出相应的修改；增、删接口模块时，可能很多Slave模块都需要做修改。	很容易。	很容易。
信号传输的可靠性	可靠。因为信号传输的通道都是专用的。	存在隐患。共享的信号传输通道可能会因为某一个模块出现异常而被堵塞，需要想办法避免。	存在隐患。多个模块同时向一个模块传输信号时，可能会产生混乱，需要想办法避免。
信号传输的延迟	最小。	随着模块的增多，信号传输的延迟呈增加的趋势。	不是最小的，但有一个不大的上限。
逻辑对时钟频率的依赖程度	严重。一旦时钟频率改变，信号跨时钟域相关的处理很可能需要相应地修改。	很小。基于AXI4的握手机制，可以设计专门的模块来完成信号跨任意时钟域的处理。	很小。基于AXI4的握手机制，可以设计专门的模块来完成信号跨任意时钟域的处理。

从上表中可以看到，问题最多的是"模块间信号传输无握手的SMMS架构"。但是，如果在这种架构中用上AXI4协议且采取统一的接口，则这种架构在上表中的缺陷将只剩下一种，即"增、删模块的麻烦程度"：

条目	基于AXI4协议的SMMS架构	基于AXI4协议的环形MMMS架构	基于AXI4协议的互连MMMS架构
模块复用的难易程度	简单。因为接口是统一的。	简单。因为接口是统一的。	简单。因为接口是统一的。
增、删模块的麻烦程度	很麻烦。增、删Slave模块时，接口模块需要作出相应的修改；增、删接口模块时，可能很多Slave模块都需要做修改。	很容易。	很容易。
信号传输的可靠性	可靠。因为信号传输的通道都是专用的。	存在隐患。共享的信号传输通道可能会因为某一个模块出现异常而被堵塞，需要想办法避免。	存在隐患。多个模块同时向一个模块传输信号时，可能会产生混乱，需要想办法避免。
信号传输的延迟	最小。	随着模块的增多，信号传输的延迟呈增加的趋势。	不是最小的，但有一个不大的上限。
逻辑对时钟频率的依赖程度	很小。基于AXI4的握手机制，可以设计专门的模块来完成信号跨任意时钟域的处理。	很小。基于AXI4的握手机制，可以设计专门的模块来完成信号跨任意时钟域的处理。	很小。基于AXI4的握手机制，可以设计专门的模块来完成信号跨任意时钟域的处理。

可惜的是，即便"基于AXI4协议的SMMS架构"只剩下一个缺陷了，它也不是上述几种架构中最优的架构——通过分析可以发现，如果能够制定一个规范来消除"基于AXI4协议的互连MMMS架构"所存在的隐患，那么，该架构才是以上几种架构中最优的架构。不过，制定规范容易，推广规范使之形成一个"FPGA逻辑生态"才是困难的。今年(2019年)华为公司推出的鸿蒙系统，据说要比安卓系统更优秀，但它却无法在一夜之间就打败安卓系统，原因就在于没有成熟的软件生态。鄙人不才，但还是为"基于AXI4协议的互连MMMS架构"设计并发布了一个自定义的规范，小伙伴们如果觉得好用的话，可以自行采用：

其中：

• exchange_bus_core_N模块可以自行编写逻辑代码来实现。如果开发工具是Xilinx的Vivado的话，也可以通过调用Vivado中的IP core(AXI4-Stream Interconnect RTL)来快速实现。
• axi4_clk_domain_change模块可以自行编写逻辑代码来实现。如果开发工具是Xilinx的Vivado的话，也可以通过调用Vivado中的IP core(AXI Clock Converter)来快速实现。