在使用这个设计时，可以有几种方法： 1．我们预先知道我们的工作频率。然后就足以选择级数以便让时钟频率至少能那么高。选择更多的级数只会导致耗用更多的资源(触发器)。 2．尽量缩短运算时间。这将由级数和最大时钟频率来确定。如果我们认为设计将在这个频率运行(理论上)，我们可以获得下图所示的运算时间(n=1536)。我们可以看到，对我们的器件(Virtex 6)来说，当级长为4位时可以获得最短运算时间。
我们想要尽可能地减小时间与面积乘积。事实上，我们可以专注于最大限度地减小时间与FF数量的乘积，因为LUT数量基本上是常数。下图显示了不同流水线级长下的时间与FF数量乘积。当级长为8位时达到最小值。
首次测试 基于NFC的ZKPK 作为第一次实际测试，我们实现了基于NFC的简化Schnorr ZKPK，详见我们的嵌入式测试平台介绍。这种个嵌入式平台是验证方，而PC(连接有PN532电路板)用作证明方。 下表给出了不同操作数长度下的时序结果。很明显，当使用我们的硬件IP内核时，操作数长度对总的协议时间基本上没有影响。增加操作数长度会稍稍增加通信时间(这是预料中的)。然而，验证所需的时间将大大增加。 我们需要指出的是，通信占总时间的很大一部分。像产生随机数等一般数据操作也需要一定的时间。然而，我们的IP内核还无法克服这些挑战。
软件控制方案对比全自动操作 实现完整的并行求幂内核是一个英明的决策吗？为什么不只是乘法器和一些控制软件来实现算法1？因为我们可以将我们的IP内核用作乘法器，我们能够非常容易的测试它。我们可以在相同的系统上比较这两种方法。 即使我们将操作数存储在IP内核的RAM中(因此没有额外的总线业务量)，全自动操作的速度仍要比软件控制方案快一个数量级(见图2)。这是意料之中的。Linux不是一种实时操作系统。在操作系统处理中断之前，或者应用程序访问它们需要的资源(本例中为我们的存储器映射外设)之前，可能需要等待一定的时间。如果你知道一次求幂要求大约(7/4)t乘法(见算法1)，这种“损失时间”会很快累加起来。 如果你知道将乘法器转变成并行求幂内核所需的额外逻辑只由FIFO和一些计数器组成，那么我们可以说额外的硬件是比较值得的。 |
