实现稳健的微控制器到 FPGA SPI 接口: 第2部分 - 协议定义

作者:Alan Yang,DigiKey 员工

本系列文章的主要目标是开发一种在微控制器(uC)和现场可编程门阵列(FPGA)之间快速可靠地传输数据的机制。在本系列文章中,我们将描述通信协议和相关帧的属性。

设计uC到FPGA接口的方法有很多。让我们先建立一套通用的设计要求来框定这个对话:

  • 尽量减少uC和FPGA之间的线数
  • 允许uC和FPGA之间有针对性的(可寻址的)信息交换
  • 容纳数千个可寻址的FPGA寄存器
  • 优化消息长度
  • 易于在uC中编程,而不会在FPGA中过于复杂
  • 高速
  • 提供数据完整性的度量
  • 跨平台兼容,例如,不特定于Xilinx
  • 请注意,FPGA资源的最小利用率不是设计要求之一。本系列的 第1部分将探讨这种明显遗漏的原因。回想一下,所有FPGA模块输出都是在时钟域内注册和同步的。这种设计规定被认为是一种可接受的权衡,平衡FPGA结构的消耗与设计稳定性和减少故障排除时间。虽然本文中描述的RTL没有经过优化,但它只消耗了Digilent Basys 3 的Xilinx Artix-7 XC7A35T-1CPG236C FPGA中可用总资源的一小部分。

    协议的概念
    设计及其需求最好通过硬件和数据协议进行可视化。这类似于开放系统互连(OSI)模型的第一层和第二层。第一层物理层描述电气规范。在本设计中,低线数意味着我们可以使用I2C, SPI,双SPI,甚至四路SPI。从这些选项中,SPI脱颖而出,因为它允许全双工通信,并且很容易从uC内部编程。顺便说一句,我们假设FPGA可以比uC更快地处理数据,从而消除了对流量控制机制的需求。

    第2层数据链路级别要求我们定义一个数据交换的协议。这一层关注的是将数据分成适当大小的块,以及适当的报头和错误检测。请注意,第2层和第1层是相互独立的,因为第2层不直接与第1层指定的电接口有关。在未来,这可能允许我们的SPI接口被四SPI甚至八SPI所取代,前提是保留层之间的字节级接口。

    据我所知,目前还没有使用SPI进行数据交换的既定协议。设备特定的实现是规范。例如,传感器可能有制造商或设备特定的协议来读取和写入数据。这将包括涉及单个或块寄存器的数据交换规则。选择的设备可能包含循环冗余检查(CRC),允许对数据读写操作的数据完整性进行测量。最后,大多数SPI设备都使用半双工协议。一个典型的SPI传输从一个包含读/写标志的字节开始。然后,设备将对后续的时钟八字节采取适当的动作。在MOSI和MISO线上发现同时传输的全双工是很少见的。

    从uC的角度来看,一个全双工SPI主控是每个实现。这是一个Arduino实现,包括芯片选择信号内SPI传输的帧。

    // prepare buf for SPI transmission
    // append CRC

    digitalWrite(CS_PIN, LOW);
    SPI.transfer(buffer, bufferSize); // full-duplex: each uC byte in buff is replaced with an FPGA byte
    digitalWrite(CS_PIN, HIGH);

    // verify and handle CRC
    // unpack and handle FPGA data

    802.3帧对SPI的适配
    在我们继续之前,有必要检查一下802.3以太网帧,因为它是SPI协议的起点。如图1所示,以太网帧以包含前言、MAC目的地加源和长度字段的报头开始。接下来是有效载荷,它可以从46到1500字节不等。后面是一个32位的CRC码。

    图1:简化的802.3以太网帧。

    我们可以减小以太网帧的尺寸,以更好地适应uC到FPGA的接口。有了SPI,就不需要序言和寻址了。SPI CS_not控制线和SPI的一对一特性使这些字段冗余。大小字段和可变长度的有效载荷是需要保留的特性。这将允许uC读取或写入单个FPGA寄存器。它还将允许传输一个数据块。最后,CRC将允许对数据进行验证。

    出于我们的目的,字段的大小可能会减少。一个合理的折衷办法是使用单个字节来标识有效载荷的长度。这自然将帧的长度限制为256个元素,包括报头和CRC的空间。考虑到帧长度的减少,16位CRC是合理的。

    均衡消息类型要求
    回想一下,SPI提供了一个全双工通信通道。如上所示,从uC编程的角度来看,这并不过于复杂。然而,为了利用这种全双工模式,我们现在必须确定如何处理FPGA内部的特定硬件。

    要使用这种方法,FPGA硬件必须是可寻址的。例如,FPGA训练板的led可能与一个基址相关联-安装在Basys 3上的16个led的两个字节。电路板的16个滑动开关可以与另外两个地址相关联。有了这种结构,FPGA就像uC的另一个外设一样。uC通过SPI使用帧协议对FPGA硬件进行读写。

    在本文的其余部分中,我们将把FPGA硬件称为外设。这反映了uC通过SPI接口有效地使用FPGA作为高性能外设的设计。

    设计要求之一是可扩展性,能够处理几个到几千个FPGA寄存器。考虑到这一要求,一个字节宽度的地址将我们限制在256个项目中过于狭窄。然而,2字节宽的接口是可以接受的,因为它允许uC在FPGA内寻址多达65536个项目。

    我们可以在这一点上停下来,并为我们的SPI帧确定一个报头。它将包含指示命令类型(读或写)的一个字节、有效载荷长度的一个字节、地址的两个字节、可变长度的有效载荷和CRC。对应的长度为4字节,负载最大可达250字节,CRC为2字节。

    这对于很多设计来说可能已经足够了。然而,这种方法隐含了半双工的假设。要了解原因,请考虑与SPI转移相关的因果关系。假设控制板的16个led灯的寄存器位于基址0x0200。如果我们要在这个寄存器上启动SPI传输,我们将有效地读取FPGA寄存器,然后向其写入。读取操作将是毫无意义的,因为它将包含旧数据。在这里,我们假设在所有FPGA寄存器上实现双缓冲,以防止与多字节寄存器更新相关的不稳定。

    对于全双工,我们需要添加另一个寻址字段。假设我们有一个寄存器,它保存位于地址0x0202的FPGA板的开关状态。如果我们在帧中添加另一个寻址字段,我们现在可以执行有意义的读写操作。

    我们现在可以读取开关状态,同时更新led灯。

    新的报头长度为5个字节,有效载荷可达249个字节,CRC为2个字节。注意,命令字节不再是必需的了。

  • Payload Length:(1字节)header和Payload中的num字节
  • To地址字段(2字节)标识要写入的FPGA寄存器
  • 来自地址字段(2字节)标识要读取的FPGA硬件
  • Payload:(1 ~ 249字节)
  • CRC:(2字节)
  • 仔细比较这两个选项,就会发现一个字节的差异。具有读/写命令字节的半双工帧需要8字节的传输才能写入FPGA板的16个led。相应的全双工操作则需要9个字节。然而,该设计现在可以同时读取开关并写入led。根据你的看法,我们要么在这个过程中浪费了一个字节,要么节省了八个字节加上与事务相关的时间开销。

    在考虑了这些设计权衡之后,我们将专门关注全双工选项。uC开销和FPGA编程开销是无关紧要的。小载荷传输的速度差异是最小的。对于大载荷,这种变化是无关紧要的。

    这种全双工协议有一个缺点,必须加以识别。事实上,现在每一次数据传输都涉及到一次写操作。有时这样做会很不方便。我们将保留从0xFF00到0xFFFF位置的FPGA地址的空/非功能块,而不是混淆写操作。当需要进行只读内存操作时,uC将“写”到这个空位置。通过这种简单的修改,全双工操作可以作为半双工读操作来操作。

    向FPGA写入和读取
    全双工uC到FPGA协议的命令和响应帧如图2所示。报头内容在帧之间密切相关。我们看到读地址和长度报头信息在响应中得到呼应。注意,有一个与响应相关的因果关系问题。由于字段是同时进行逐字节传输的流,因此响应将被延迟。例如,作为发送的第一个字节的长度字段不能作为响应中的第一个字段,因为当FPGA锁定要发送的第一个字节时,它尚未被接收。这不是一个问题,因为写地址对响应帧并不重要。相反,FPGA可以发送程序特定的标志,而uC正在流式传输第一个字节的长度。

    帧字段的其余部分是类似的。FPGA响应将从基读地址开始流式传输数据。同时,FPGA将同时将uC数据移动到临时缓冲区。计算出相应的CRC并附加到帧中。

    图2:命令帧和响应帧之间的关系。

    命令帧的数据完整性
    CRC提供了数据完整性的度量。回想一下,CRC是应用于帧内容的。让我们从uC的角度来考虑这个三步流程。uC将首先准备一个带有相关数据的帧缓冲区。然后,它将调用一个函数来计算并将CRC追加到缓冲区。最后,uC将调用函数通过SPI传输数据。

    FPGA将把流数据放入缓冲区,同时计算命令帧CRC。当帧完成后,FPGA将比较接收到的和计算得到的命令帧CRC。如果它们匹配,FPGA将快速地将数据从缓冲区传输到相关的硬件寄存器。这是一个相对快速的操作,需要大约5个uS来完成一个完整的负载。如果接收到的和计算的CRC不一致,FPGA将丢弃帧。它还会触发帧错误机制。

    包含一个帧错误计数器用于故障排除,如图2响应帧所示。还可以增加从FPGA到uC的物理线的规定。这将允许uC快速检测并响应帧错误。

    FPGA临时帧缓冲器的重要性怎么强调都不为过。在CRC验证之前,FPGA不会对新数据采取行动。这个重要的主题将在另一期文章中讨论。

    响应框架的数据完整性
    响应框架的完整性需要在uC中仔细编程。我们必须首先认识到,在命令帧被验证之前,FPGA将立即响应uC读取请求。因此,由uC来验证FPGA开发数据的完整性以及FPGA对命令的理解。这是通过响应帧中的帧长度和基读地址的回声来完成的。uC可以通过比较响应帧和命令帧中的数据来识别错误。

    例如,假设从uC到FPGA的命令帧的读地址字段中有一个位错误。在uC到FPGA的写入操作中有一个很好的完整性措施,因为错误有非常高的可能性被FPGA的CRC机制检测到。FPGA将忽略该帧。同时,我们必须考虑与FPGA并行结构相关的因果关系。

    FPGA将在它知道命令帧损坏之前很久流式传输读取的数据。事实上,它会尽职尽责地从错误的读地址开始流式传输数据。它甚至会向帧追加一个有效的CRC。

    当事务完成时,uC将拥有响应框架的完整副本。在采取行动之前,它必须验证数据。这是一个两步走的过程:

    1. uC必须首先验证发送和接收字段的长度和读地址是否匹配。
    2. 然后,它必须验证响应帧的CRC。

    当这两个操作完成后,uC可以采取适当的措施来处理通信错误。

    本文转载自:DigiKey

    最新文章

    最新文章