图9
再提特权同学发现问题后，如何处置优化提高了这里的利用率（实际上，如果真用EP2C8Q完成这个工程，也不是非得做这个优化的工作，只不过最终的设计是要实现在向下兼容的EP2C5Q上，所以，就诞生了这篇文章的故事……）？很简单，前面其实都已经给了大家暗示，移位寄存器的存储资源利用率不高不是因为本身存储量大（只有1280*8bit=10Kbit，需要3个M4K足够），而是因为生成的taps占用的port过多，前面配置24个taps就占用了6个M4K块，那么如果配置成12个taps，distance值为128会怎样呢？6个taps，distance值为256会怎样呢？答案马上揭晓，如图10所示。其实两者都是占用了3个M4K。这里做的变化就是最终优化成功的玄机。
图10
如图11所示，其实这个工程最终实现到EP2C5Q上是没有问题的，但是如果没有类似移位寄存器例子中的一些优化，存储器资源还是很紧张的。
图11
说到这里，虽然已经洋洋洒洒图文并茂好长一篇文章了。但是，还是很想再提一些和FPG***上存储资源相关的问题。关于Cyclone/Cyclone II的M4K到Cyclone III的M9K，可能还有一些M512，将来不知道会不会有什么M32K/M128K/M1M云云的概念出来。但是就特权同学对目前器件使用的一点经验上来看，这个MXX的块存储量越大，虽然总的存储量也会越来越大（不能否定它能够满足片内大存储量应用的需求），但是相应的在工程需要的很多小存储应用中对存储块的利用率也会越来越低。因为，对于用户例化的任何一个存储器，如果使用M4K块实现一个8bit的512B/256B/128B/64B甚至哪怕只有1B的应用，其实他们都需要占用1个M4K块。打一个更形象更极端的例子，我的设计中需要两个1*8bit的FIFO（当然实际应用中没有人这么傻，^o^），那么例化完编译后，我的M4K资源别占用了2个，这就是问题。这也是制约着极大多数的应用中，特权同学提到的FPG***内存储资源利用率无法100%的原因。其实，这也是最近特权同学的另一个项目中搭建的NIOS2平台，如图12所示，各种简单的外设都分别要占用一点片内存储器（没有充分的利用M9K的资源），直接导致整个利用率很低的原因。针对与这种情况，不知道器件厂商是否有所考虑，也许对他们而言，也是处在一种鱼和熊掌不可兼得的矛盾之中。