一、IP核配置
使用非实时模式配置如下
二、时序
是遵守AXIS协议的，不像real time mode，一旦开始吭哧吭哧的读数据，根本不管s_axis_data_tvalid信号了。
三、资源消耗
在implement查看两者的资源消耗差不多
四、仿真
4.1 中间不停顿
输入
结果
4.2 中间停顿4拍再写最后一位
信号整体情况
event_data_in_channel_halt
有个有意思的点是event_data_in_channel_halt信号拉高了。查了手册，原因是表明在IP核在non-realtime的情况下需要数据，但是现在没有有效的数据可以给IP核消耗。
但是在real time的情况下，就意味着会读取之前的数据，出现错误。
输入
输出
4.3 back-to-back的（上一个8点数据输入完毕，立马输入下一个8点数据）
信号整体情况
输入
输出
唯一有点奇怪的就是最后的多算了一个36，但是输出valid也没有把它那一块拉高。
4.4 在4.3 back-to-back的基础上，输入7个数据之后，停10个时钟周期，然后输入第八个数据，然后接着输入7个数据，再停10个时钟周期，输入第二组数据的第八个数据，考虑到之前数据过于简单，可能会出现问题，从这里开始切换更复杂的数据
更改输入数据
FFT的输入是99, 100, 78, 76, 82, 98, 10000, 555
输出是
整体信号
输入信号
输出信号
4.5 目的：上一次FFT结束之后，过了很久再次重新输入数据会不会有问题
在4.3 back-to-back的基础上，输入7个数据之后，停10个时钟周期，然后输入第八个数据，然后停16个时钟周期，接着输入7个数据，再停10个时钟周期，输入第二组数据的第八个数据，
整体信号
输入信号
输出信号
整体信号分析
可以看到输出和之前不一样，没有像之前一样连起来，这个我记得文档上面有写明这个情况，如果输入数据是连在一起的，那么输出数据也是连在一起的。测试的时候两个FFT的输入相差12个是时钟周期，那么前一帧的最后一位输出和下一帧的第一位输出就是相差12个时钟周期。
4.6 上一个实验，将两帧之间的延迟降低到4个时钟周期
输出信号
确实输出结果也相差4个时钟周期。
五、结论
能行。
