标签: cyclone

概述 Intel 要求用户为其10代FPGA器件使用特定的上电和掉电顺序，这就要求用户在进行FPGA硬件设计的时候必须选择恰当的FPGA供电方案，并合理控制完整的供电上电顺序。经过在Cyclone 10 GX测试板上实际验证，统一上电确实会导致FPGA无法正常工作，具体表现为JTAG接口无法探测或识别到目标器件。 上电顺序要求 Cyclone 10 GX，Arria 10以及Stratix 10系列器件所有的电源轨被划分成了三个组合，三组电源轨要求依次上电，如图1所示，为三组电源轨上电顺序示意图。 图1：Cyclone 10 GX器件上电顺序示意图 三组电源轨具体划分如表1所示，而在具体设计的时候，有些电源轨电平相同，此时相同电平的电源轨当电流合适的情况下，在进行合理隔离后可以进行合并。具体情况可以参考 。 表1：Cyclone 10 GX供电电压轨分组划分 Group1 VCC，VCCP，VCCERAM，VCCR_GXB，VCCT_GXB Group2 VCCPT，VCCH_GXB，VCCA_PLL Group3 VCCPGM，VCCIO 在分组2中所有电源轨开始爬升之前，分组1中的所有电源轨可以任何顺序爬升到其标称电平的90%水平。 在分组1中所有电压轨以任何顺序爬升到其标称电平的90%后，分组中所有电压轨才可以任何顺序开始爬升。 同样，分组3中的电压轨，也只有等到分组2中所有电压轨均爬升到其标称电压水平的90%之后，才可以任何顺序开始爬升。 之前提到，当分组之中或不同分组之中电压轨标称电平一直时，在合理隔离情况下可以共享供电模块，后面再详细介绍。 需要注意的是，确保新合并的电压轨不会导致未通电的GPIO或收发器引脚获得“驱动”。 所有电压轨都必须单调爬升，且上述上电顺序控制，必须满足标准或快速POR延迟时间要求。也即，整个爬升时间必须控制在最小的POR延迟时间之内。POR延迟时间指标如表2所示。 表2：POR延迟时间指标 Cyclone 10 GX器件电压轨供电共享指导原则 查参考 给出了两种共享供电模块例子，这里就第一个例子进行讨论，详细信息可以查看 。如表3所示，为Cyclone 10 GX器件电压轨共享分组方案之一。 表3：Cyclone 10 GX器件电压轨共享方案 电源 引脚名称 分组 压值(V) 供电公差 电压源 模块共享 备注 VCC 1 0.9 ±30mV 开关电源 可共享 VCCP VCCERAM VCCR_GXBL 2 0.95 ±30mV 开关电源 可共享 为获得更好性能，将VCCR_GXB与VCCT_GXB隔离 VCCT_GXBL VCCBAT 3 待定 ±5% 开关电源 均为1.8V可共享 这四个均为1.8V时，可以使用同一电源模块供电 VCCPT 1.8 VCCIO 待定 VCCPGM VCCH_GXBL 1.8 隔离 可共享，但需要进行正确隔离 VCCA_PLL 参考 AN 692: Power Sequencing Consideration for Intel Cyclone 10 GX, Intel Arria 10, and Intel Stratix 10 Devvices. Intel Cyclone 10 GX Device Family Pin Connection Guidelines

概述 Cyclone 10 GX器件的ALM结构与Cyclone V类似，所以在Cyclone 10 GX器件上实现TDC功能理论上是可以完全参考甚至移植自Cyclone V系列的成功案例。但是，现实却是更多的问题出现当在Cyclone 10 GX使用和Cyclone V同样策略实现TDC的时候。 本文主要记录在Cyclone 10 GX器件上实现TDC时的探索，并为后续TDC设计、测试等展开前期研究。 Cyclone 10 GX ALM结构 如图1所示，Cyclone 10 GX器件的ALM结构延续自Stratix II，只是从5代开始，每个ALM中的寄存器从2个增加到4个。 图1：Cyclone 10 GX ALM内部结构 如图1所示，使用进位链可以实现所需长度的TDL，每级进位链的Sumout？则可以通过ALM内的寄存器TAP输出。以前进位链单元与寄存器时1：1对应，图1中进位单元与寄存器的比例是1：2的关系。这使得用户在进行TDC设计的时候，可以利用该比例关系，获得双倍的TAP输出码元，从而在使用同样的进位资源的情况下获得双倍的TDC精度。笔者称此方法为双寄存（Dual Reg）方法，而之前方法对应为单寄存（Single Reg）方法，两种方式实现的TDL如图2所示。 图2：单寄存（Single Reg）TDL（左）与双寄存器（Dual Reg）TDL（右） Intel ALTERA与Xilinx双寄存器的比较 已有研究者分别在Xilinx和Intel ALTERA的器件（28nm及以后）中使用了上述双寄存方法实现TDL，如果仔细研究二者的逻辑单元（CLB与ALM）的结构，可以发现进位单元到寄存器的路径还是有区别，如图3所示为Xilinx器件中进位到寄存器路径。 图3：Xilinx器件中进位到寄存器之间路径 如图3所示，和ALTERA类似，（a）为老器件的单寄存，而（b）为新器件中的双寄存，不管单寄存还是双寄存，Xilinx的进位到寄存器的路径有2条（分别为C与S，而ALTERA器件如图1所示只有S，C并未引入到寄存器），而ALTERA只有一条，所以有研究者分别探索了使用两种不同路径的效果，相关结果可以查看对应的论文，这里不在赘述。 TDC初步测试结果 依据前期对Cyclone 10 GX的研究，以及前期在Cyclone V系列器件上对TDC实现的经验，通过直接调用进位链和寄存器原语的方式完成TDC功能完整例化实现。总共有3种不同类型的TDC得到了实现，并进行了初步的测试，TDL的Tap时钟为500MHz。三种TDC的DNL测试结果列举如下。 1、单TDL单寄存，TDL的长度为256，足够覆盖2ns的时钟周期 图4：256 cells的TAP输出单寄存器阵列锁存（8-bit细时间，LSBav=8.9ps） 2、单TDL双寄存 图5：256 cells的TAP输出双寄存器阵列锁存（9-bit细时间，LSBav=4.3ps） 3、双TDL双寄存 图6：双256 cells TDL链的TAP输出双寄存器阵列锁存，然后合并（10-bit细时间，LSBav=2.2ps） 参考 Cyclone 10 GX FPGA Handbook “LCELL WYSIWYG Description for the Cyclone II Architecture,” p. 13, 2005. . Available: https://community.intel.com/t5/ Intel-Quartus-Prime-Software/Designing-with-low-level-primitives/ td-p/110485?profile.language=en&attachment-id=30610

概述 通过前面的研究学习，已经可以在CycloneVGX器件中成功实现完整的TDC（或者说完整的TDL，即延时线），测试结果也比较满足，解决了超大BIN尺寸以及大量0尺寸BIN的问题，但是还是存在一些之前系列器件还未遇到的问题，这些问题将在本文中进行详细描述介绍。 在五代Cyclone器件内部系统时钟受限的情况下，意味着大量逻辑资源将被浪费在于实现较大长度的TDL上面。是否可以找到方法可以对此前TDL的长度进行优化呢？本文还将探讨这个问题。 TDC前段BIN颗粒堵塞问题分析 将延时链在逻辑中实现后，进行码密度测试的时候，总是发现所获得码中，位于链路起始段总会出现1个到2个码尺寸相较其余码过大的问题。之前怀疑是否是TDL的长度不够长，导致大量码颗粒堆积在延时链的初段。仔细查看各次测量结果，发现512的长度在使用400MHz采样时钟的时候应该还是足够覆盖一个完整的时钟周期的，那为何还会出现上述问题呢？（问题具体展示如图5所示，512和640长度均出现该问题） 从测试结果来看，采用640长度的延时链后，实际用到的延时单元仅到cell467，排除开头截取掉的延时单元，实际用到延时单元数量只有453个。所以，在采样时钟为400MHz情况下，一个时钟周期并不会超过512长度。但是，最开始用512测试时，为了截取掉前面的大延时单元（cell10位置）时，测试结果显示512长度不够用，如图1所示，右则已经超出512范围，从而导致部分“事件”并未统计进来，也就是说部分数据丢失。这是最初将TDL长度从512修正到640的根本原因。 图1：部分统计数据“溢出”后丢失情况 物理位置锁定不同导致延时不同 那么为何会出现640和512不同长度导致的测试结果不一样呢（本质是延时单元的平均延时时间不一样，所以这两个延时链实际用到的延时单元数量差异较大）？ 经过检查发现，在增加延时链长度的时候，笔者无意间将延时线的位置锁定换到了别处（应该原始锁定位置碰到了无法布局的问题，从而更换了位置）。原始512长度锁定在起始ALM的坐标为X34_Y46，而640锁定位置为起始ALM坐标在X22_Y54。而且在锁定的时候，延时单元的节点名称也有差异，前者为MLABCELL_X34_Y46_N*，而后者则为LABCELL_X22_Y54_N*，如果后者锁定继续使用MLABCELL编译器被报错。实际查看延时单元内部延时也有些微差异，如图2、图3和图4所示。 图2：第一个LAB的第二ALM（左）和第三个ALM（右） 图3：第一个LAB的第五ALM（左）和第六个ALM（右） 图4：第二个LAB的第一ALM（左）和第二个ALM（右） 对比之前的位置，可以看到延时链的“大”额延时有较大差别，比如LAB中间全部为135ps，LAB之间则为142ps，而且所有其它单元的延时时间较统一（为50ps）。 截掉前面11个cell后，测试结果如图5所示。 图5：512长度延时链锁定位置更换和640一样后，测试结果与之类似 从图5可知，还需要截取一段BIN尺寸过大的单元，而且从图5后半段可以看到还有足够裕度用于截取（远未到511），不会出现“溢出”问题。经过多次尝试后，最终结果如图6所示，而图7则是查找表校准曲线图。注意图6中的码密度测试结果，平均BIN尺寸最终优化到了5.3ps，相较之前640长度的5.5ps有些微提升。 图6：截掉前21个延时单元，这样剩下最大延时在22ps左右，其余均处于20ps下 图7：截掉前21个延时单元，得到其LUT统计结果 总结 通过上述分析，找到了512长度的TDL溢出问题的原因，而640长度TDL由于锁定位置变化帮助笔者认清了此问题出现的原因。其实还是不同逻辑单元特性差异带来的问题，ALTERA器件内部逻辑单元还可细分两类，LABCELL和MLABCELL。在CycloneV中，通过上述实验测试，可明显发现它们之间的差别。 后面将尝试将系统时钟从400MHz提高到500MHz，看看是否可以进一步缩小TDL的长度，从而达到节省资源的目的。

概述 同一组前端模拟信号接入由不同型号ADC组成的模数转换电路时，采样后在FPGA中发现采样用时差异较大。本文主要分析这个时间差异形成的原因，并记录该差异产生对系统造成的影响。 系统数字化简介 项目前端的模拟信号是由PMT或者SiPM加上LYSO探测器产生的整形脉冲波，同时随路产生时间脉冲，这个两个脉冲到达数字化板的时间保持不变，所以可以以时间脉冲为参考检测数字化后的整形模拟脉冲。即数字化脉冲上升沿触发后，固定周期后就可以得到对应的整形脉冲位置。如图1所示，在逻辑上，t1与t2之间的时间间隔在硬件确定后，即已确定，宏观上的差异不会存在纳秒级以上。 图1：模拟信号数字化框图及逻辑时序关系 数字化转换时差展示 这里需要首先明确一个前提，即大转换时差仅存在于AD采样电路中使用了不同型号的ADC。如果使用相同的AD采样电路，虽然存在采样时差，但是差异很小，这时候讨论的不是宏观的时差，而应该是通道之间的skew。 另外，本系统早期使用了AD9288 ADC，中期修改为AD9218，当前升级为AD9633。这里比较的是AD9218与AD9633之间的转换时间差异。如图2所示，即为早期AD9218采集PMT整形脉冲的实际时序关系。 图2：AD9218采集PMT产生的整形脉冲结果 如图2所示，SignalTapII的触发脉冲是时间脉冲信号，时间脉冲触动后，大概10个系统时钟后，整形脉冲被数字化完成并送到了FPGA。SiPM系统的时间关系大致如此，这个时间关系与硬件电路上的布线延时以及线缆连接造成的延时关系不大，因为这里关注的是基于系统时钟（100MHz）周期上的差异。硬件布线、连接等造成的延时基本上达不到时钟周期级别，故可忽略。图3则展示了AD9633采集SiPM后得到的时间脉冲与整形之间的时序关系。 图3：AD9633采集SiPM产生的整形脉冲结果 如上图所示及之前分析，PMT与SiPM硬件电路上产生的时间脉冲与整形脉冲之间时间间隔差异并不大，这个也使用AD9218采样后验证过。而上图使用AD9633采集后得到的这个时间间隔在30个时钟周期，大于图2中的10个时钟周期，差异在20个时钟周期。 数字化转换时差原因分析 通过查看两个ADC的数据手册，发现在流水延迟这个参数上，二者有着很大的不同。AD9218给出的数字输出流水延迟是5个时钟周期，如图3所示中箭头所指。 图3：AD9218正常工作的通道时序 而同样的参数，AD9633给出的是16个时钟周期，所以这里的差异在11个时钟周期。但是，还有9个左右的时钟差异在哪儿呢？ 剩下的9个时钟差异应该来自于FPGA内部，因为AD9218是并行输出，FPGA直接获取AD的输出数字码，而AD9633是LVDS串行输出，FPGA收到后首先需要进行解串，解串LVDS逻辑模块运行周期目前还不明确，需要查看资料确认。 参考 LVDS SERDES Intel FPGA IP User Guide: Intel Arria 10 and Intel Cyclone 10 Devvices. AD9218手册 AD9633手册

概述 项目使用的FPGA目标器件为Cyclone 10 GX系列规模最大一颗料，由于功能升级增加了功能模块更多，发现器件片内RAM不够使用了。为了探索片内RAM使用的利用率问题，从代码RTL级与编译软件的优化选项方面进行了思考。表1是器件手册中给出的C10GX器件片内RAM颗粒，即M20K，可配置模式。 表1：Intel Cyclone 10 GX器件单端口片内存储器配置 对于MLAB来说，一个MLAB大小是640bit，是由双功能逻辑阵列模块（LAB）配置而成。MLAB是宽而浅型存储阵列的最佳选择，每个MLAB由10个自适应逻辑模块（ALM）组成，在Intel Cyclone 10 GX器件中，这些ALM可配置成10个32x2模块，这样的每个MLAB可实现32x20的简单双端口SRAM模块，Cyclone 10 GX系列器件中片内存储器性能及分布如表2所示。 表2：Intel Cyclone 10 GX器件中片内存储器性能及分布 项目遭遇片内RAM不够问题 升级的项目，在之前逻辑设计的基础上增加了两个模块，理论上存储器消耗要增加一倍。逻辑修改后，工程全编译时，在Fit阶段报错，提示目标器件无法提供足够的RAM来完成布局，如图1所示。 图1：因RAM不足，导致布局失败 Info ( 170034 ) : Selected device has 587 memory locations of type M20K block. The current design requires 626 memory locations of type M20K block to successfully fit. Info ( 170033 ) : Memory usage required for the design in the current device: 107 % M20K block memory block locations required Info ( 170043 ) : The Fitter setting for Equivalent RAM and MLAB Paused Read Capabilities is currently set to Care. More RAMs may be placed in MLAB locations if a different paused read behavior is allowed. 从编译消息列表中摘出上述3条有关出错的消息，第一条提示器件总共587个M20K颗粒，当前设计需要626个来完成布局。第二条给出当前设计完成布局需要消耗器件片内RAM颗粒数量是目标器件能提供的107%。第三条消息提示Fitter的关于“Equivalent RAM and MLAB Paused Read Capabilities”当前设置是“Care”，如果允许更改该设置，则可以将更多的RAM消耗替换为MLAB消耗。 在Quartus的Settings设置中，找到编译器设置页面，并在该页面中找到属于Fitter的Settings高级设置按钮，如图2所示，并点击此按钮进入高级Fitter设置页面。 图2：编译器设置页面 如图3所示，为Fitter的高级设置页面，找到“Equivalent RAM and MLAB Paused Read Capabilities”设置选项，可以将默认设置“Care”修改为“Don’t Care”，如此再重新编译后则可以解决上述报错问题，如图4。 如图4所示，虽然经过上述修改解决该报错问题，但是整个RAM消耗已经达到了100%。100%的RAM消耗率，如果设计功能已经达到目标要求，则是可以作为最终设计提交，但是这仅仅这是项目的预先编译评估，所以并不能就此停止。比如，在后期调试时需要添加SignalTap功能的时候，就可能面临无RAM可用的情况。同时，还需要了解上述设置修改对逻辑设计是否产生负面影响进行评估，即需要对该设置进行深入了解，否则不要轻易修改默认设置。 如果需要进一步减小RAM消耗，那么就需要针对当前设计进行深度优化，这是下一节的内容。 图3：高级Fitter设置页面 片内RAM耗尽后，优化思考 Cyclone 10 GX最大型号器件，总共有587颗片内M20K颗粒，如图4所示，按照图3所示对Fitter高级设置进行修改后，对工程再编译，全编译无报错通过，编译报告提示所有M20K颗粒已经100%耗尽。 图4：M20K颗粒耗尽统计报告信息 如果查看Fitter给出的各个M20K颗粒使用详尽信息，可以发现，各个颗粒容量的使用率不尽相同，有些颗粒甚至使用了不到1%，如图5所示，这些颗粒有12个。 图5：Cyclone 10 GX系列最大器件中M20K颗粒使用情况信息 上述不到1%利用率的M20K颗粒很大可能是为了与其它颗粒“凑整”过程中被消耗的，一旦被占据，该M20K颗粒空余空间就无法开放给其它逻辑使用了。如此大大降低了RAM颗粒的利用率，在进行逻辑设计的初始阶段就应该核算RAM、FIFO或ROM的大小与实际片内RAM颗粒的尺寸来进行规划，提高资源的利用效率。 举个简单的例子说明RAM被“奢侈”利用，AD9633分解为8个LVDS接收器通道，解串后得到了48-bit的并行数据，这时创建了一个FIFO来缓冲该数字转换数据，所以FIFO的位宽48-bit，深度选择为8。所以一个FIFO实际消耗384-bit的RAM，但是经过编译，该FIFO必须要使用2个M20K颗粒（共40960-bit）来实现，RAM利用率不到1%。是不是很奢侈，很浪费？！ 这个FIFO的读写时钟不一样，所以属于异步FIFO，修改图3所示的高级设置选项也无法将FIFO转换为MLAB来实现。在例化FIFO的时候倒是可以强制指定使用MLAB来实现它。 参考 Intel Cyclone 10 Devvices Overview.