请教大牛一个前端设计的问题
reg [127:0] mask;
其中mask中1的个数是固定40个
要求是把data中对应mask是1的位选出拼接到
reg [39:0] result;
里，有什么好办法能少于128拍么。。目前只想到128拍用移位的说。。。
设俩result，同时开始一个从data低位开始，一个从data高位开始，计数够64，然后俩result或一下。怎么样？
.55
这个只要规模大可以快很多
128周期和64周期都比较容易
再少就要想些别的方法了
1， 128位分成若干段，分别实现，然后拼接。推荐16x8
2， 每一段通过查找表实现。mask做地址。查找表内容是dada的映射(有效位数目＋有效值)。举例data = 10101010的话。
entry_0 = 0 ＋ 0 （假设mask是0的话，没有输出）
entry_1 = 1 + 0000000_0 （假设mask是1的话，输出1位0）
entry_2 = 1 + 0000000_1 (假设mask是2的话，输出1位1)
。。。
entry_254 = 7 + 0_1010101 (假设mask是254的话，输出7位，result是1010101)
entry_255 ＝ 8 + 10101010 (假设mask是255的话，输出8位有效值，result是10101010)
3，在2中已经把有效值都归并到低位，所以根据有效位数目做个大逻辑合并各段的有效位。
大致只需要3。4个周期就OK了
感觉有点像通信ACK的一种编码吧
其实要不了128个周期的
思想是 1） 数据格式分段处理
2） 如果分段处理模块处理性能不够，设计多个处理模块
比如 8Bit 处理一次，进行Mask抽取处理，你只要才一个查表法 就能实现数据的拼接
算下来只要16拍，如果时间不够，用2个抽取器，对分段的数据并行处理
（一个256的查表，面积应该很小的）
分段的时候我本来想用16Bit的表，那表就非常大，面积估计是8Bit表的200倍，不符合面积优化的优势，当你设计成8Bit表，面积小，速度也会块很多，可以在减少16拍运算周期的基础上考虑，并行增加查表逻辑，如果用2个查表，速度可以变成8拍， 4个表，速度可以可以变成4拍。
不过寄存器的增加代价也需要考虑在内
设计思想就是用面积换速度
bow to everybody~ 真是大有启发啊。。。哎看来作为新手路还很遥远T_T。。。。
再详细问一下 如果按照这个方法做，那查找表里的内容怎么在运行时构造呢？data和mask都是要经常变的值。。。
还有最后有效值合并怎么做呢。。？各块的有效值长度并不固定 怎么把它们串接起来呢。。？靠移位么？求细节@@
如果这样的话，就不适合用查找表了。基本思路还是分段处理，再合并。每一段用移位来实现。
还有一个思路就是用一个128x128的阵列。每一行，根据各位mask的值，如果mask[n]为1，data[n]保持；如果mask[n]为0，data[n]<= data[n+1]。比如mask[3:0] = 1010; data[3:0] = 0101, mask[0]/[2]是0，所以data[0] <= data[1]; data[2] = data[3]。这样经过128行的处理以后，所有mask为1的位都会集中在低端。因为最终结果总是40位，所以你取低40位就行了。这个思路有点象冒泡排序的样子。虽然单个data/mask处理需要128个周期，但是流水线一旦跑起来，基本就是1个周期出结果。细节没细想，你可以仔细考虑一下
补充一点。貌似不需要128行。只需要128-40=88行。但是没细想。我想这个应该是最优解了。
合并 长度增加的时候，也只要处理若干拍就可以了( 比如分类查表用了16拍，合并最多用个16拍)
设计成流水线的形式，把合并于查表分成两个流水段，也就17拍就能处理完毕。
我以前应该做个累死的设计，其实用个40Bit内 8Bit 的滑动窗口，做个合并的查表，应该很容易的
如果用我的方案2，就不要合并了。直接输出最低40位。但是这个128x128的处理矩阵面积会比较大。
对呀，其实，这种电路在信号处理中很常见，
我们很多时候都是用把16x16之类的运算单元， 变成 多个8x8的小单元，状态机稍微复杂点
验证稍微复杂点，面积省的不是一点点。其实，做ASIC
都是不断的平衡 面积性能比
两个功能单元实现
一个单元负责从输入的8-bits中选出使能为1的，硬连线实现，
输出为使能1的个数和合并的数据（0~8 bits）
另一个单元就是把上一级的结果合并到当前的结果中，
保存上一级的移位位置，基本上是一个0~8级的40 bits移位器。
两个单元都要16拍，加上流水，一共17拍
感觉这样设计就差不多了。