标签: tdc

概述 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的长度，从而达到节省资源的目的。

ECO那些事之ALM端口DATAF 概述 这里继续《ECO那些事之LE和ALM》一文，详细了解下ALM的端口DATAF，在前文中列举了ALM和LE的差异，其中之一就是DATAF端口。随着基于FPGA的TDC设计深入，越来越发现了解DATAF端口细节的重要性。 ALUT子LUT掩码真值 首先列举一些常识，LUT（ALUT的子LUT，打开属性编辑器，Top ALUT分为一个F0和两个F2子LUT，Bottom ALUT分为一个F1和两个F3 子LUT）只有DATAA端口的输入时其16位LUT掩码真值为“AAAA”，只有DATAB端口的输入时其16位LUT掩码真值为“CCCC”，只有DATAC端口的输入时其16位LUT掩码真值为“F0F0”，只有DATAD端口的输入时其16位LUT掩码真值为“FF00”。 端口DATAE和DATAF不直接作为子LUT输入 。 上述信息是笔者应用属性编辑器的时候观察总结得到，而如果查阅器件handbook，对于ALM工作算术模式的描述是这样的，ALM工作在算术模式时使用两组各包含2个四输入LUT以及两个专用全加器。如图1所示，两个4输入LUT共享DATAA和DATAB输入端口。 图1：工作在算术模式的ALM 这几个DATA端口在ALM内的具体路径可以参考《基于FPGA的TDC那些事之设计资源LAB》一文中的ALM内部结构图，或者查阅相关器件手册，本文后续会基于属性编辑器详细剖析。 注意图1中端口DATAE和DATAF与笔者观察总结属性编辑器的差异，由于DATAE和DATAF不直接feed属性编辑器中的“子LUT”，所以通过ECO方式修改子LUT等式或者掩码的时候需要特别小心 。 针对DATAF解剖ALM 在《ECO那些事之LE与ALM》一文中对于ALM配置为normal和算术模式，都给出了其在属性编辑器中概览。图2给出DATAF端口进来的信号第一条可能路径，图3是该ALUT的逻辑属性。其中图3-(a)的F2 LUT的等式为“!a&!b&!c”，而F2的掩码真值为“0101”，这个真值可以根据上一节的单个端口输入的真值推导得到，即“!(AAAA)&!(CCCC)&!(F0F0)”=“(5555)&(3333)&(0F0F)”=“0101”。观察COMBOUT等式，分别与F0 LUT等式、F2 LUT等式以及DATAF有关，而此时DATAF不参与构成子LUT等式。 图2：DATAF端口信号进入ALM后可能路径（一） 图3：ALUT属性栏 图4显示了一个更复杂的例子，DATAF的路径和图2一样，同时DATAE走的也是这种路径，而且图4是一个7输入查找表的具体实现。 图4：7输入LUT功能实现 以下是图4的组合逻辑输出等式，由于太长，图4无法全部展示： ( E & ( F & ( (!A & ((!B) # ((!C)))) # (A & (C & ((D) # (B)))) ) ) ) # ( !E & ( F & ( (!B & (((C & D)))) # (B & (!A $ ((C)))) ) ) ) # ( E & ( !F & ( (!B & ((!A) # ((C & D)))) ) ) ) # ( !E & ( !F & ( (!B & (C & D)) ) ) ) ( E & ( F & ( (!A & ((!B) # ((!C)))) # (A & (C & ((D) # (B)))) ) ) ) # ( !E & ( F & ( (!B & (((C & D)))) # (B & (!A $ ((C)))) ) ) ) # ( E & ( !F & ( (!B & ((!A) # ((C & D)))) ) ) ) # ( !E & ( !F & ( (!B & (C & D)) ) ) ) 图2和图4显示的都是ALM配置在Normal模式下DATAF进入ALM的一种路径，当ALM配置成算术模式时，DATAF进入ALM的路径 图5显示了当ALM被配置为算术模式时，DATAF进入ALM的路径，如图中绿圈所示，同时图中红圈所示和图2中的路径一样，只是这里的combout等式为N/A，也即其没有fan out。另外注意图5右侧属性栏中的F0和F2 LUT等式，虽然同样为“!d”，但是F0 LUT的输出作为加法器一个输入，而F0 LUT的输入只有DATAD，所以其输出也只与DATAD有关，对应Sumout和Carryout等式中的“D”项。同理，观察DATAF位于绿圈的路径，尽管其没有“直接输入”到F2 LUT，但是此时DATAF就是F2 LUT的唯一输入，并且F2 LUT的输出作为加法器的另一个输入，对应Sumout和Carryout等式中的“!F”项。 图5：算术模式下DATAF进入ALM的路径 根据上述分析，DATAE和DATAF虽然没有作为F？LUT的直接输入，但是F2和F3 LUT和其后面的3输入模块构成了图1中ALUT的下面的那个4输入LUT。 图5显示了一个非常简单加法器例子，DATAF和DATAD直接作为加法器的两个输入，尽管DATAF被取反了，图中黄圈模块就是取反。另外，信号在ALM端口处是不是首先被取反了？！如图5所示的F0 LUT的等式为!d，输入为DATAD，F0 LUT到加法器直接是直通，并没有取反器，为何SUMOUT表现为“D”呢，所以推断端口处信号均被“取反”，可以放大图5端口处，发现DATA前似乎有取反符合“！”，从属性编辑器可以找到很多例子来印证上述猜测。 分析及结论 本文试图详细了解DATAF端口上的信号“feed in”ALM后的路径，从而为TDC设计中需要微小修改时提供帮助。 附：

基于FPGA的TDC设计中使用PLL来模拟HIT 概述 在进行基于FPGA的TDC设计时，为了测试方便，一般通过PLL来模拟外部“HIT”，这是进行码密度测试基本操作。通常的做法是需要FPGA片外提供两个非同源的时钟，一个用于系统时钟以及TDC的高速锁存时钟，另外一个用于产生模拟HIT。假如使用片内的PLL，那么就没必要这么麻烦了。 读本文之前，还可以参考之前博客 ： https://mbb.eet-china.com/blog/1010859-213148.html ， https://mbb.eet-china.com/blog/1010859-213159.html 乘除因子的真相 图1：PLL框图 如图1所示为PLL的内部结构框图，那么所谓的PLL的乘除因子与内部的这些counter的关系如下所示： FREF = FIN / N FVCO = FREF × M = FIN × M/N FOUT = FVCO / C = (FREF × M) / C = (FIN × M) / (N × C) 其实我们在讲乘除因子的时候必须搞清楚PLL的几个counter，即M、N以及C计数器。首先我们可以确定的是Megawizard里“Clock multiplication factor”就等于M计数器的值，而“Clock division factor”等于N计数器的值乘以C计数器的值，这些可以从上述公式里找到答案。 在进行PLL输出时钟设置的时候，Megawizard一般不提供，且ALTERA也不建议客户直接去设置M、N以及C计数器，而是通过设置乘除因子来设置PLL，编译器会自动设置这些计数器的值。只有高级应用，即高级用户可以通过特殊方式来设置M、N以及C计数器来配置PLL。另外，应用ECO工具手动修改FPGA设计的时候也可以修改这些计数器以及其他参数。 一个TDC模拟HIT设计实例 有篇参考论文上提到过一个利用FPGA的PLL产生HITs的例子，其中有两个问题一直没弄明白。最近几天通过不断的做实验终于搞清楚了问题，特总结一篇记录与此以备后查。 整个例子如图2所示，外部给FPGA一个100MHz的时钟，第一个PLL由100MHz产生一个387.5MHz的TDC时钟。第二个PLL产生一个33.68MHz的HIT时钟。我所说的问题，第一是为什么20MHz时钟要从FPGA外面兜一圈；第二是作者给出两个PLL的输出时钟之间的相位关系有256种组合，而没有直接给出原因。 图2：关联校准脉冲发生器 首先谈第一个问题，由于作者没有给出其具体使用的器件型号，所以这里我猜测这个20MHz在FPGA外部兜一圈的原因也许是因为作者使用的器件的PLL不支持逻辑时钟作为其输入，而必须是从FPGA引脚来的时钟才能作为PLL的输入，而ALTERA早期的Cyclone系列就有此限制。另外，早期的ALTERA器件也不支持PLL级联，所以也没有从第一个PLL产生一个20MHz来驱动第二个PLL。还有就是《PLL那些事之乘除因子》一文中有提到PLL的输出受限于PLL的FVCO，所以第一个PLL输出一个387.5MHz时钟后，无法再输出33.68MHz或者20MHz。否则，图2完全可以只用一个PLL产生387.5MHz和33.68MHz这两个时钟。 接着谈第二个问题，即387.5MHz和33.68MHz这两个时钟之间为何相位关系就有256种组合呢？分别用CLKH和CLKL来代替387.5MHz和33.68MHz这两个时钟。根据图2，可以得到CLKH=100*，而CLKL=100**。因此将第二个等式代入第一个等式我们得到CLKH=CLKL*5**=CLKL*，反过来也就是2945*TH=256*TL，也即是说低速时钟和高速时钟有256种不同的相位关系组合，因为每256个时钟周期低速时钟和高速时钟关系重复一次。所以，图2所示的使用PLL在FPGA内部产生TDC的模拟HIT输入是可行的。图2所示的这些256种可能的脉冲平均分布在2580ps范围内，那么每两个相邻脉冲的时间间隔就是10.08ps，这个值可以通过求n*29687.5和2580的模来得到（29687.5ps是33.68MHz时钟的周期）。图2还显示了一种增加HIT和TDC时钟之间的时间关系可能性的办法，即通过相移90度得到另外一个33.68MHz时钟，这样模拟的HIT多出一倍，同理，通过改变相移可以继续增加HIT的种类。 改进型模拟HIT 图2所示的模拟HIT产生电路相对比较复杂，原因前面提到了，是由于器件本身限制造成的。笔者自己使用的ArriaGX系列FPGA，该系列FPGA的PLL支持片内级联。也可以通过一个PLL同时产生TDC时钟和模拟HIT时钟。实际应用的时候还是用到了PLL级联，这是因为产生TDC时钟的PLL在产生TDC时钟的时候其FVCO频率已经被确定下来，所以在现有FVCO频率下是否能产生合适的用以模拟HIT的时钟还需认真考虑。 笔者实际使用的TDC时钟是250MHz，那么就需要另外一个PLL产生一个低速时钟，并且相位关系越复杂越好（即相关性越差越好）。为了验证上述分析，笔者作了三个实验，这三个实验分别用PLL产生了三个与250MHz时钟不同相位关系的模拟HIT时钟，实验的结果分别如图3、图4和图5所示。 图3：模拟HIT时钟和TDC时钟有10种相位关系 图4：模拟HIT时钟和TDC时钟有19种相位关系 图5：模拟HIT时钟和TDC时钟有205种相位关系 图3可以明显看出实际测量的结果模拟的HIT和TDC时钟确实只有10种相位关系（不考虑时钟的skew和jitter），而图4虽然看不出19种相位关系，但是时钟的skew，jitter以及延时链的非线性特性，某些相位的HIT很有可能已经重合而连在了一起，但是从数据上还是可以明显分辨出13组独立的数据，那些长连续的数据可以被高度怀疑为两个相邻相位拼接在一起了。图5的测试结果和实际使用随机（random）HIT所得到的测试结果基本相同，如图6所示。 图6：随机HIT测试结果

基于Cyclone V GX FPGA的TDC设计及测试结果分析 概述 基于老工艺的FPGA的TDC已经经过验证测试，可以安全可靠的用于产品。在逻辑资源受限的情况下，单通道TDC测量精度可以做到15ps左右，如果给予足够资源的情况下可以进一步提升精度。 之前已经分析了28nm器件逻辑资源的结构，与老工艺器件还是有些差别，如果应用这种工艺器件来实现TDC是否可以从老器件无缝移植过来呢？这是本文需要探讨的问题。 新老工艺相对TDC设计的不同挑战 使用老工艺FPGA进行TDC设计的时候，设计者首先面临的最大挑战是LAB之间以及LAB内部存在超大时延，所以TDC设计者在进行TDC设计的时候首先需要将这些超大BIN进行“切割”后平滑，否则TDC的精度会受到限制。 新工艺在ALTERA高端器件的表现（或者从公开发表的有关竞争对手Xilinx器件的论文同样提到）就是这种“超大”BIN已经消失，各延时单元的延时已经解决并得到均衡。可是从之前我们对应CycloneVGX器件逻辑单元的分析发现，这种超大时延仍然存在LAB之间。更为严重的情况是，每间隔一个延时单元，出现0延时的单元。这为TDC设计者带来了额外的挑战，意味着很可能大量的0尺寸BIN出现。这个结论在公开发表的论文中已经得到证实，如图1所示。 图1：通过码密度测试得到的BIN尺寸（a），TDL延时链中不同BIN尺寸对应的计数直方图（b） 从图1中b可以看出，大量统计位于0尺寸的BIN，也就是说延时链中大量单元的延时时间是0。 该论文讨论了作者使用了优化方法来解决上述问题，该办法非常灵巧，通过BIN重新定位解决了0尺寸BIN“乱入”等问题。这个方法在需要使用Xilinx器件设计TDC的时候也有应用到。通过研究，个人理解此方法比较繁琐，可能需要大量的离线迭代最终统计得到重定位的BIN，经过一段时间的尝试，放弃此方法，采用其它方法同样解决了上述问题。 初步测量结果 Cyclone第五代器件逻辑单元ALM中包含4个寄存器，所以延时单元与寄存器的比例是1：2。那么在形成TDC的时候，存在两种可能，使用顶部寄存器锁存还是选择底部寄存器锁存。甚至不加约束，让编译器自己选择寄存器锁存，只不过这样的话锁存的寄存器一致性大打折扣。 测试结果显示，不管使用顶部寄存器锁存还是使用底部寄存器锁存，实验结果差别并不大。如图2所示为实测结果。 图2：使用400MHz采用时钟采集延时链Tap输出结果 上述测试结果中，总共占用了486个延时单元，测试显示第11个延时单元有一个超大延时，延时结果大概56ps左右。剩余单元的延时尺寸均被压制在30或30ps之内。出现这个问题的原因，初步分析应该是使用的512个延时单元的延时链长度不足导致的。 如何处理第一个LAB较大延时？ 在上面图2的实验结果中，在第一个LAB中出现几个延时较大（最大57ps，远大于平均值，即5ps）的延时单元。能想到的办法无非是两个，第一个是增大采样时钟到500MHz，这个方法在Cyclone V系列器件里似乎很难实现，内部逻辑很难保证稳定跑在这个速率。第二个方法就是增长延时链长度到640，然后截断出现大延时的延时单元。如图3所示，采用640个延时单元后，采用截断8个，初始段仍然存在超大尺寸BIN（类似事件“堵车”堵塞一样）。对比如2和图3，图3后段还存在空间，那么是否可以将截断长度增大，看看是否能解决此问题呢？ 图3中最大延时单元出现在第14个（cell - 13）上，所以需要截断cell13之前的延时单元，经过实验发现不能随意截取，否则编译器会报布局错误（原因不明），经过不断尝试发现将截断点选择在cell-23上能通过编译，结果如图4所示，当增大截断长度后，确实可以解决该问题。图5测试查找表校准曲线。注意图4中平均BIN尺寸是5.5ps。 图3：640个延时单元 截断前面8个，最大延时为48ps 图4：640个延时单元，400MHz采样，最大延时29ps，其余大都低于20ps 图5：查找表校准曲线