CPLD与单片通讯用外总总线接口速度可达到多少?
CPLD： Max EPM570时钟 50MHZ
单片机: AVR32 UC3A051212MHZ PLL 66MHZ
CPLD与单片机通过EBI总线相连.
现在要把大量的数据从单片机送到CPLD(CPLD另接了一片RAM,把单片机送过来的数据存入,RAM的读写时钟25MHZ).
CPLD驱动一片800*480的TFT屏, 所以数据量很大. TFT驱动是60HZ扫描, 从RAM中读出数据送LCD.
扫描时钟为25MHZ,由50MHZ分频得到. 数据在时钟上升沿读出送LCD. 所以外部写RAM时只能在25MHZ时钟的下降沿写入.这样才可以不打断LCD的刷新.
与MCU的接口写入算法为:
always @(posedge clk)
begin
wr_q1 <= wr_n; //wr_n 为CPU的写信号 WR
end
always @(negedge clk)
begin
wr_q2 <= wr_q1;//对wr_n打两拍(在下降沿打了一拍,应该算一拍半了)
end
数据在wr_n下降沿数据存入CPLD.
always @(posedge clkor negedge rst_n)
begin
if(!rst_n)
begin
cmd <= 0;
end
else if( wr_q2 && !wr_q1) //下降沿
begin
cmd <= Data;//从总线读入数据
end
end
现在发现这样写的效率也不是很高.
现在是CPU速度比CPLD时钟快.那主要问题应该是CPLD的处理算法.
有什么好算法速度可以提升,且稳定呢? 需要FIFO吗? 有必要吗? 现在在UC3A0512上跑了FreeRTOS + UCGUI系统, 点这个自己的TFT驱动. 运行是OK了, 但刷新不理想,主要是MCU写CPLD部份影响了速度. 你做了就知道了,不是好玩的东东.
LCD的时钟为23.04MHZ,RAM才25MHZ的读写速度?
16位色都驱动不起来,8位还可以.但必须用FIFO.
如果你等得了,就用我的现成的吧.
可以到65MHZ的RAM访问率(130B/S).点时钟最大32.5MHZ. 错了,130MB/S,总线可以到20MHZ,更快没试, 【3楼】 Oliver
期待你的算法!
我现在点LCD是25MHZ时钟,晶振用的是50MHZ的.
因为我是用AVR32驱动的, 所以16位色没问题. 数据总线就是16位的.
RAM用的是-10T的, 是不是就是10ns?
现在点是可以点起来了,但就因为与MCU的IO速度跟不上,写一屏的数据量太大了. 显示个图片有点拉窗帘了....
FIFO我还没用过.. verilog也不是很熟,边用边学的.. 你现在的问题是RAM的访问太慢了,让CPLD跑快点吧,75MHZ或者100MHZ.
没有空闲的时间给MPU接口操作.
我是把RAM的访问速度控制到108MB/S(最高150MB/S),当640*480*3*60=55.296MB/S,所以我的显存还有90多MB的空闲可供读取,16位的话也就是可以到48MHZ,而异步时钟域同步后不可能到48MHZ的,所以我的显存带宽还有很大余量
而你的...几乎相等了
还有大数据量交换不一定是CPLD或者接口的问题,我分析下来FOR循环占用了太多时间,等STM32回来后用DMA来处理
不然总线数据压力过大 但是RAM的速度跟得上吗? 你刷新LCD用多少时钟? 我800*480 16bit 色 60HZ扫描 RAM可以到200MB/秒(10ns,16bits).
LCD点时钟可以设置分频因子.最高32MHZ,这时还可以驱动成24位色,还有空闲带宽留给总线读写.
你800*480:
点时钟大概:800*480*68=26MHZ
16位色RAM带宽:800*480*2*60=46MB/S 主要是点时钟与写入顺序逻辑设计部份,可能我的算法还不够优化. 感觉写数据很慢.
CPLD内部直接清零倒是很快. 一瞬间就可以清完了. 也是25M的时钟写入RAM清的.
但外部写进来就变慢了. 如果要一点点的清,那非常的慢..50MHZ的异步时钟读入外部的数据的. 没理由那么慢的.
现在将就用着,先把程序的功能做出来了才来优化这部份. UCGUI运行效果
http://cache.amobbs.com/bbs_upload782111/files_14/ourdev_442758.jpg
(原文件名:img275.jpg) 分析了一下,AVR32我不清楚,用同等ARM7级别速度比较快的STM32的FSMC驱动这么大屏(800 480,16位色)
图片放FLASH最快12fps.如果处理不好或者模拟总线还要打折扣...
ST的AN显示STM32在72MHZ时,FSMC刷320*240最多67fps.
----------------------
之前错误的以为STM32的DMA可以把内存数据后台传递给FSMC的,原来不可以,不要被我误导啊 【7楼】 Oliver
请教一下，你的RAM读写时序是怎样的？
10ns的ASRAM，写入时WE占了8ns，剩下2ns置高？还是WE长低直接跳地址？
如果直接跳地址，寻址方式是线性还是格雷码？线性寻址WE长低会不会引起寻址错误？ 一直拉低就可以
规格书上很清晰的写着对于SRAM的写是对若干控制信号,地址信号的逻辑组合(里面应该有延时电路来处理),非边沿触发.
线性地址 【12楼】 Oliver
你的时序分配是怎么样的呢?
EPM570 跑100M稳不稳定?
http://cache.amobbs.com/bbs_upload782111/files_14/ourdev_442972.JPG
(原文件名:tft.JPG)
系统在A步检测是否有数据写入到CPLD(来自MCU的数据),同时在A步送出点屏的地址到RAM准备读数据
在B步输出地址到一临时寄存器,在C步送到RAM地址.并拉低RAM的写(WR)信号
在C步把RAM的数据读出送到LCD上(在A步已经送出了屏地址),同时在C步也把准备写入RAM的外部数据的地址锁存到RAM上
如此循环... 即读写各需时间均为20ns...
RAM是10ns的,这样花了20ns浪费了一半的资源..
你们都是怎么处理的呢? 【12楼】 Oliver
之前没弄过高速异步SRAM，对接近存取极限速度时的时序不太了解。
ISSI的datasheet没说地址变化具体在什么时间点生效，担心线性寻址时多位地址变化会出错，所以布线的时候在想要不要像DDR那样布等长线。我看你的板没有什么特殊处理，如果时序也没什么特别，那我就放心了。
感觉异步SRAM的工作方式还是比较怪异，假如WE长低，地址100ns才变一次，那它的写周期是从最先变化的地址位边缘算起，还是从所有地址线稳定后算起呢？如果1ns变一个地址位，会发生什么事情呢？同样地，如果WE长低，地址不变，数据位这样变化，又会怎样呢？感觉没有了同步时钟，一切都变得不是很可靠…… 我用的是流水线结构
全部模块化操作.感觉你这样A啊B的把很多模块绞合在一起了(MPU接口,LCD显示,SRAM访问....)
不利于时序分析,自己也搞不懂代码,还带来很多仿真排障困难.
按优先级,谁优先谁操作,都是并行运行的
另外你异步时钟域转换就这么检测一下肯定不行的,必须同步2-3拍,你想一拍搞定很容易因为冒险引起恶性循环甚至系统崩溃.
也许等你吃亏后你就能明白了 异步时钟域已经在A前打了两拍了...
如果不分步时序会不会打乱?总需要一个同步点吧?
还有LCD的扫描算是固定的吧, 如60HZ扫描周期. 那就好,只要打了1-2拍(最好是2拍以后)那就基本不会有冒险恶化的问题了
只要你的逻辑是清楚的不会乱,它是一个系统性的东西,乱不了
我做的不是固定的,
DCLK可设置分频
THB,THP,THD,THF,TVB,TVP,TVD,TFV可设置
所有输出脚极性可设置
等
LCD按规格书搞,一般都是60HZ 我现在处理的时序应该是对的了, 因为已经可以正常点屏. 也可以由MCU送数据刷新等操作.
现在问题是怎么优化算法来提高读写速度的了. 为得提高速度, 我在CPLD里做了一些命令, 如: 清屏, 一字节(8/16bit)变8点或16点一次性写入, 多点写地址自动+1,水平线, 垂直线等加速算法. 方面绘制GUI界面显示点阵汉字等
这些算法只对单色有效. 如要送真彩色图像就要一个点一个点的送数据了.
以AVR32全速的写进去会丢数据.证明处理不过来了! 现在最笨的作法就是 加了一个BUSY口检测是否准备好才写入数据. 这也是导致数据跟不上的原因了 如能实现如下写入方式就好了
memset,memcpy
unsigned char *screen_ptr; //指向显存的地址
memcpy(screen_ptr,buf,xxxx); //转移数据
memset(screen_ptr,0x00,800*480); //清屏
直接寻址,不需要额外等待
就算不需要DMA,能达到这样应该也可以接受了 前面我不是给你算过了吗?最快只有几fps.
如果你不能忍受就赶紧的换方案,努力努力呢可以到几fps的.
你现在写一屏图片需要多少时间 没实测过有几fps. 不过已经可以感觉到慢... 数一下嘛,很简单,10秒刷了几次,或者30分刷了几次,一除就有了.
我那个35fps就是数出来的.
太快了程序上来个刷10次扭一个IO,数LED变化次数,还太快就刷100屏扭一次IO 我弄个测试程序试一下...
你的能达到35fps已经很不错了.. 主时钟是多少? 35是个测试程序,刷固定颜色.
我的FLASH存不了一张图片,现在是SD卡中读BMP. 经过测试结果, 我现在刷新速度都不好意思说出来了...
倒是测试也一个问题, AVR32 跑66MHZ上,SMC的速度也快不了多少. 10几M的速度.
就算CPLD的处理速度上来了, CPU送数据也是跟不上的.
【25楼】 Oliver
CPLD的算法上可给个指点? 谢谢了... 看你发过的贴,你在这方面有很多研究了..我也才是刚开始弄,
虽然可以显示了,但这速度实在跟不上. 还得多花点时间研究研究了... 【26楼】 cicnx:你这么大的屏,速度肯定上不来的.
一般总线速度为3周期以上
(WR:地址/数据/控制线建立1周期;WR释放1周期;地址/数据/控制线保持1周期)
(RD:地址/控制线建立1周期;延迟1周期后读数据;地址/控制线保持1周期)
如此看来通常总线最快为3分频,STM32可以2分频,我还没理解过它的原理;
我当前试过LPC2214 @11.0592*5MHZ,WST1=0;WST2=1,也就是写需要延迟1周期.读不要延迟. To 27# Oliver
一般来说，内部使用同步时序的异步总线接口，能达到这样的分频
读：不分频，因为异步数据读不需要任何信号跳变，CS/RD都是低，地址稳定足够长时间就能在DB获得稳定的数据输出。周期合适，上升沿打出来地址，下个上升沿锁数据就行了。
写：二分频，主要是WR信号必须有跳变，如果不是双边沿同步，这个就没办法了。 你所谓的SMC速度10多MHZ?算他10MHZ吧.如果总线发挥到极致可以26fps左右(10MHZ/800/600).
当然这只是假设,实际上更多的时间全部浪费在运算和循环上了.
关于CPLD方面的指点我是选择性的,很抱歉
(如果你善于收集整理资料信息会收获很大)
当然我还是希望你用成熟的方案,把精力放到自己最具优势的地方,学习另当别论. 【28楼】 dr2001:
你说的这个是访问异步存储器,和CPLD就不能.
原因很简单,任何信号跳变都有产生"冒险"的风险,除非你CPLD时钟比你总线速度快几倍,那你总线分不分频都无所谓也可以. to 【30楼】 Oliver
你已经帮了不少了! 在论坛上看了你发过的回过的贴,帮助很大!
做这个1是为了学习,2也是为了以后开发产品有个可选方案..
其实现在我要求也不是很高, 驱动这么大的屏单片机想达到60fps是不太可能的了.
有个24fps,至少清屏不能看到拉窗帘吧?
现在呢AVR32送出的数据速度是12.5M左右了(实测),并把WR信号宽度故障调到40ns,以方便CPLD中检测.
如果能让这12.5M写入CPLD中不需要等待就OK了.
点屏(读RAM)是25M ,还有25M的带宽可以写RAM的. 速度比输入的速度快,理论上可以处理过来的..
算法还有很大空间优化... 12.5MHZ啊?是慢了点.
不过就算CPLD能提高3倍也未必能满足你的要求(你现在都不好意思说fps,那肯定是<1fps的,提高3倍又能如何??)
但对于CPLD要提高3倍却难于登天,不要在这个位置纠缠了.
1.加大GRAM位宽
2.双图层切换
我觉得以上比较靠谱,希望对你有用 是考虑过双图层, 但这么大的屏占用的内存还挺大的.
其实现在的fps大概可刷2fps左右 :(
用来显示一下GUI还是可以接受的.GUI本身有剪切,并不需要全清屏, 且单色清屏我有专门的指令硬件清. 不需要送整屏数据.
只是全部程序功能都写得差不多了, 自己也对这个刷新效果不太理想. 不甘心才一直想搞好一点的.
不过还是非常感谢 Oliver的帮助! 那也不错了,72MHZ的STM32(36MHZ总线速度)用FSMC刷800*480
图片放内部只有5fps. 优化了一下有点进步...
读入一800*480的图片,在内存中(SDRAM)中. 不断显示到屏幕上.
大概有8pfs左右... (用逻辑分析仪监测WR信号线计算出来的,3-4Mbit * 16的写入速度) 【35楼】 cicnx:
AVR32你挂的是SDRAM啊?程序在哪里运行?如果也是外部的话会影响数据存取(指令数据共用总线),这个也很好资源.
况且你的主时钟只有66MHZ 程序还是在flash中运行, SDRAM只是用来存数据用的.
现在没法往下测试了,因为AVR32 SMC的速度没法提高了. 不过还没试DMA方式 我的堆分配是在SDRAM中的. 跑了FreeRTOS,他的堆是动态分配的, 也就是堆栈是在SDRAM中了 学习 MARK 学习一下这个帖子。 MARK
页:
[1]