每天进步一点点------预估数据吞吐量的方法
先说SDRAM数
据吞吐量方面的一些思考。由于在一个液晶屏上要显示的两个层的数据都存储在SDRAM中，因此初步的预计，SDRAM每秒需要处理的数据流大体有以下四块：
1． 实时采集的视频写入数据量：640*480*16bit*50Hz；
2． 实时显示的视频读出数据量：< 640*480*16bit*60Hz；
3． 叠加层读出数据量：640*480*16bit*60Hz；
4． 叠加层写入数据量：不确定，假设写入一帧的图像数据，为640*480*16bit。
对于该项目中使用的SDRAM，每次写入N个数据的时间开销为：N*10ns+80ns；而每次读出N个数据的时间开销为：N*10ns+100ns。而视频数据读写和叠加层数据读都是以160个数据为一页进行操作的，唯有叠加层写入数据是单独一个数据一个数据操作（即单字突发写）。因此，初步计算上面四块数据每秒的时间开销为：
1． (640*480*16bit*50Hz/160)*(160*10ns+80ns) = 161.28ms
2． (640*480*16bit*60Hz/160)*(160*10ns+100ns) = 195.84ms
3． (640*480*16bit*60Hz/160)*(160*10ns+100ns) = 195.84ms
4． 640*480*(10ns+80ns) = 27.648ms
此外，需要额外再计算一下SDRAM每隔15.625us（64ms一个全部地址预刷性周期）一次的预刷新操作所占用的时间开销（每次预刷新时间<110ns，这里就以110ns为准）：
(1s/15.625us)*110ns = 7.04ms
那么，下面可以得出SDRAM在1s时间内的时间余量：
1s - 161.28ms - 195.84ms - 195.84ms - 27.648ms - 7.04ms = 412.352ms
换句话说，当前SDRAM的空闲时间还是有近一半的，从理论上看如此利用SDRAM是可行的。
从整体方面论证了SDRAM的吞吐量足以胜任当前的任务，下面还需要从一些可能出现的实时性最强的数据流中找寻速度瓶颈。
个人认为，这个设计中，数据流最大的情况很显然是上文提到的四种对SDRAM的操作同时出现。而此时由于每个读或写操作对应的都有一个1024B的缓冲FIFO，所以在这些操作同时出现于某一个显示行中，也不需要过于担心数据会出现被丢弃的现象。下面也简单的计算一下余量，由于叠加层写入是特别需要验证的数据流，所以这里就计算其他三种操作同时发生的情况下可以执行多少次叠加数据写入操作。
液晶显示某一行的时间为：800*40ns=32us
视频层显示一行数据的操作时间为：4*（160*10ns+80ns）= 6.72us
叠加层显示一行数据的操作时间为：4*（160*10ns+80ns）= 6.72us
视频层写入一行的时间为：4*（160*10ns+100ns）= 6.8us
自刷新的时间为：< (32us/15.625us)*110ns = 0.33us
因此剩下的时间为：32us – 6.72us – 6.72us -6.8us - 0.33us = 11.43us
为了给足余量，这里取剩余时间的60%作为叠加层可写入的时间，那么可以执行的叠加层写入数据次数为：(11.43us*60%)/90ns = 76次。因此，需要尽量控制叠加层数据量，如果从最保险的操作看，叠加层的写入一次数据的时间应该小于32us/76 = 420ns。
如此理了一下思路，感觉清晰很多，对于正在进行的设计也显得更加有把握。这种理论的评估是很有用的，至少可以让自己在实际设计中少走一些弯路，对可能出现的问题尽早的做一些预判甚至避免。
再说仲裁逻辑方面的一些思考，其实仲裁二字在总线设计中出现得最频繁，相信仲裁设计也是非常有讲究和学问的。苦于特权同学还没有太多这方面的理论学习和实践积累，也许在项目中也无形的DIY了很多还算凑合的所谓仲裁逻辑，但是近来调试中发现自己的设计里关于仲裁控制逻辑的弊端或者说很多不成熟的想法都会如同一个定时炸弹一般时不时的引爆。因此，自己确实需要加强这方面理论的深入学习和探讨。下一段时间希望找一些合适的材料进行学习和借鉴，欢迎大家提供这方面好的素材，也希望能花点精力梳理一下这方面的知识。
再说一点，设计思路的梳理和知识的梳理一样重要，随着当前项目的深入特权同学在这一点上感受极为深刻。
