IC前端开发的一点感悟

最近在调数据交叉模块，简单的说就是三个收发端口，每一个端口都可以将数据发送到其他两个端口和当前端口（环回），当多个端口同时向一个端口发送数据的时候，就要涉及到数据间插，也就是说排队，但是不能只发同一个通道的，要间隔发送，使用状态机来做，想的很简单，三个端口三个状态，只要非空就去读，读完就跳到下一个有数据的通道，由于多通道发送到单通道要用到fifo缓存（公司的fifo模块使用的ram是延时两拍出数据），如果使用fifo的empty作为状态机的跳转指示，就要提前一拍结束读使能，不然就读超了，刚好公司的fifo有个almost_empty的信号，在counter==1的时候almost_empty生效，提示fifo快要空了，OK，一切都很完美，很快写完了代码，开始仿真，也很完美，修改了几个语法错误，然后丢给验证，不一会就出问题了，某个通道连续发送数据的时候没有问题，但是如果不连续，或者说只发送一个数据的时候没有接收，想了想，确实忘了这种极端情况，因为实际上很少有只发一个数据的情况，为什么出现这种情况呢，很简单因为almost_empty，只有一个数据的时候，读使能是无法生效的，所以，想当然的加了一个判断，当数据只有一个的时候还是要读，改了之后，反正反反复复又改了很多次，各种凑时序，最后终于满足了各种情况，但是回头一看代码，超级复杂，每个ifelse分支都有2-3个约束条件，我自己都不知道是干啥用的，然后冷静下来思考，其实开始就像当然了，觉得很简单，其实则不然，要考虑到各种情况，多数据和单数据，多通道和单通道，然后为了不浪费带宽还要连发不能中断，各种解决的一个问题又无法满足另外一种情况，有时候还是相互矛盾的，所以加了各种判断，然后验证终于清静了，但是始终觉得没有这么复杂的逻辑，还是觉得很简单，我屡了下思路，画了下时序图，发现问题还是在almost_empty这里，当almost_empty的时候如果读使能，那么下一个状态一定会empty，但是如果almost_empty是没有读使能，就需要在去单独产生一个读使能，这就可以解决全部的问题了，多么简单的逻辑！！！然后改代码，当almost_empty时，读使能=！读使能，仿真验证通过。

大部分时候我们是陷入到自己的思维定式里了，下意识的去凑时序，而不是去梳理逻辑，其实时序不是凑出来的，而是逻辑分析出来的！！！