求助！关于深度为4的buffer设计问题

JINNINE

请各位大哥指点！小弟需要一个深度为4的buffer，将数据暂存在里面（数据最多16个所以深度为4的buffer就够用了）。buffer的输出要做判断，buffer里存的每个数据自己都带着代表输出顺序的4位标志位（如4'b0000代表应该第一个输出，4'b0001代表应该第二个输出，以此类推），需要先找第一个（0000），输出；然后再查找第二个（0001），输出......

请问各位高手，如何实现这样的功能？具体的verilog代码可以参考一下吗？小弟先行谢过！！

IC.Michael

1. 数据最多16个 —— 》那么深度不应该是16吗？你说的4是指地址线4bit吧。
2. 从你的描述看，先进先出，还是随意进随意出？如果前者的话，用个fifo呗。如果是后者的话，进的顺序是如何呢？输出顺序编码唯一吗？如果唯一，那就搞个RAM，存的时候输出编码顺序和地址绑定；如果输出顺序编码不唯一，那还得搞个仲裁逻辑。

darkfay

弄个16输出的多路选择器，4bit buffer值在选择器的s端，信号在I0~I16输入

JINNINE

darkfay 发表于 2020-11-25 10:53
弄个16输出的多路选择器，4bit buffer值在选择器的s端，信号在I0~I16输入

这倒是个新的思路，我会好好思考一下的！

JINNINE

IC.Michael 发表于 2020-11-25 00:59
1. 数据最多16个 —— 》那么深度不应该是16吗？你说的4是指地址线4bit吧。
2. 从你的描述看，先进先出，还 ...

我和您的思路一致。对“深度”这个概念我不是很清楚。。。我使用了寄存器组，是4位的地址线，可以最多存储16个数据。然后和您说的一样，写入的时候把数据写到编码对应的地址。输出的时候如果编码为0000的地址里数据不为0，则输出对应数据，然后检查0001地址里的数据.......总体的思路我认为是没有问题的。谢谢大佬指点！

可以的话我想和您继续讨论：因为之前做标记位的时候，用了data.mshrid中无效的高四位做标记位，所以一次性只能最多处理16个数据。而且做标记的方法是串行输入数据时，来一个数据标记位置+1，这样就不会涉及到标记不唯一的问题了。但这同时又带来了新问题，如果说前置电路一次性进来的数据超过16个的话，该如何处理呢？我初步的想法是做一个用来计数的fifo，在写和读使能上做点手脚，实现计数满16就只写不读，等前16个数据传输完毕后再继续读出......想听听您的看法~


先行谢过！

IC.Michael

我没接触过DDR，对这个数据流不了解，我理解下，你的做法是利用冗余的信号，在数据过去的时候打个flag，然后数据回来的时候根据flag依次从buffer取回，这样就保证了相同ID保序返回，是吗？

【我初步的想法是做一个用来计数的fifo，在写和读使能上做点手脚，实现计数满16就只写不读，等前16个数据传输完毕后再继续读出.....】
——这个读写是相对SRC还是DST来说的呢？如果因为冗余信号只有4bit的限制导致你目前的解决方案只能同时处理16个数据，那么当fifo满时，如何反压SRC或者DST而不产生预期之外的影响呢，这个反压是可以确保没有问题的吗？如果进来超过16个数据，那么超过16个的数据是丢弃吗还是？
——另外，如果极端场景，比如SRC端出去的序列是：D1 D2 … D16，而DST端返回的次序是D16 D15 … D1，那岂不是会耗费15个等待的周期，等待D1优先从buffer打出？有评估过这种做法对性能损失由多少吗？
——如果不从根源解决乱序的问题，那我觉得，可能需要考虑下这种做法对带宽流量性能的影响，以及权衡下slave乱序的范围以及buffer深度的选取。

JINNINE

IC.Michael 发表于 2020-11-25 21:12
我没接触过DDR，对这个数据流不了解，我理解下，你的做法是利用冗余的信号，在数据过去的时候打个flag，然 ...

1、是这样的。就是将数据中冗余的四位作为标志位，标记写入时的顺序，在读出时就可以以此作为排序的依据。

2、1）Master发出准备写入的数据，经过计数器再写入Slave中。这里的读写是针对计数器而言的：写操作是指从主机到计时器，读操作是指计时器到从机。
     2）您提到的这点也是我目前头疼的地方。数据肯定是不能舍弃的，但已经在路上的第17个数据该放在哪呢？fifo满时如何反压也挺棘手的，我认为是要通过计数结果（是否满16）来控制fifo的写入使能端，但写入使能端同时还要受到主从机状态的影响...我还没有深入下去，但估计蝴蝶效应受到牵连的地方应该挺多的。您说到的这些问题直击要害。我会仔细思考的！如果您有好的想法也请不吝指教！

3、性能损失问题我提出设想的时候也考虑过。确实效率降低很多，但如果控制在16拍也还可以接受吧，现在没想到更优的解决方案。

4、我收到的项目要求是：在原则上不改动主从机的情况下，解决从从机读数据时乱序的问题。我目前的水平能想到的解决办法就只有现在这样了...我现在在想办法沟通，希望能一次突发只进行16个数据的传输。您说到的slave乱序的范围可能的确无法确定，只能按最坏的结果来处理了。

感谢大佬！如果您有好的想法也请不吝指教！

IC.Michael

JINNINE 发表于 2020-11-26 09:54
1、是这样的。就是将数据中冗余的四位作为标志位，标记写入时的顺序，在读出时就可以以此作为排序的依据 ...

0. 最好的解决办法还是从SRC或DST侧入手；
1. buffer池子大一点，可能对overall throughput影响相对小一点；
2. 确保目前16个数据的并发是安全可靠的；
3. 中间的buffer是否可以优化下，流水起来，不要等到16个数据来了再处理，处理完了这一批再重新收发；

JINNINE

IC.Michael 发表于 2020-11-26 13:28
0. 最好的解决办法还是从SRC或DST侧入手；
1. buffer池子大一点，可能对overall throughput影响相对小一 ...

都是很中肯且实用的建议。谢谢您！