概述 通过前面的研究学习,已经可以在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的长度,从而达到节省资源的目的。