Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2567096
  • 博文数量: 320
  • 博客积分: 9650
  • 博客等级: 中将
  • 技术积分: 3886
  • 用 户 组: 普通用户
  • 注册时间: 2009-03-27 21:05
文章分类

全部博文(320)

文章存档

2024年(1)

2017年(5)

2016年(10)

2015年(3)

2014年(3)

2013年(10)

2012年(26)

2011年(67)

2010年(186)

2009年(9)

分类:

2010-06-21 22:52:03

在联想做了半年的FPGA实习了,也实实在在的做了一个项目。下周就要离职,所做的项目也基本达到了预期目标,一些感受趁着现在还记得,写出来和大家一起分享。不对之处,希望得到大家的指正。我在联想研究院做的是一个无线显示(投影)设计项目下面的接收端的图像数据的解码(基本涉及的算法有DPCM, UVLC , RLC ,还有行间预测)。下面的感触点是随性而写,不是按重要性来排列的。有些感触只正对FPGA领域有效^_^ 1。要和人配合,交流。以我们做代码上板调试为例,调试的时候需要软件的配合,一个软件压缩发送,硬件接收解码的项目调试没有软件的支持是一个很复杂也很难调通的工作,调试都是分步骤的,比如说一开始让软件发送端发个图像块过来看看硬件这边能不能解码通过。然后发一个静态图像调试,最后才让发动态的屏幕。这些步骤修改都要软件工程师的配合,如果你不跟别人交流,自己一开始上板就调试动态图像,估计出了问题都不知道在哪里。其实在软件工程师那边这些改动他只要注释一段代码或者修改一个判断条件重新编译一下就可以给你想要的软件版本。有时候把出的问题跟软件组交流一下结果他们发现是软件端出了问题,这样我这边也省下好多心。所以要和人配合,找人交流。多听听别人的意见,多说说自己的想法,这样必然可以产生新的 know-how 从而加快调试和开发的速度,退一步讲,至少没有坏处。 2。有问题就多问,多找自己企业导师,就是带你做项目的那个工程师。很多问题在你认为是无法解释的,到了他们眼前就是两三句话的事情,这就是经验。不要怕丢面子,这不算什么,真正丢面子的事情恰好不是这些。多向老大汇报最近的进展,虽然老大要求一周汇报一次,你要有心,一天汇报一次让他时刻知道你在做什么,进展怎么样,不要说的太长他也不会嫌你烦。这样让他觉得招你这个实习生不是白招的。这样的好处还有就是当你遇到什么问题卡住了,他也会来想办法,实在没办法他也知道你的难处。这样你的压力就小了。懒得向直接老大汇报情况时,万一出现进度或者结果不符,所有责任都需要本人承担。到时候第一个炒鱿鱼的就是你,虽然你觉得其他实习生的水平跟你差不多。如果提前向老大汇报情况并取得许可,则一切后果都在可控范围内。 3。前期code仿真很重要。不要急于上板调试,很多问题可以在仿真阶段就可以消除的,等到上板调试的时候你会发现很麻烦,花的时间更多。虽然自己写的 code自己找bug很难,但是要有勇气去发现缺点的。不要想当然的认为自己写的就是这样那样的运行下去没问题。多载入几个测试序列就发现问题了。所以就算有问题,如果不严重就藏着掖着。该改的趁早改了好。 ( via: unus.cn ) 4.仿真过程中的错误仿真也很重要。当你仿真到一定程度发现基本上code没什么问题的时候,不妨特意设置几个错误测试序列载入代码看看你的code跑的怎么样。这就是逆向思维,很多时候你从理想的状况下仿真是发现不了问题的,然而当你仿了几个错误序列的时候你可能发现你的状态机不知道跑到哪里去了^_^。我就是吃了这个亏,后期调试老是画面死机。如果早期仿真时候多做几个错误序列仿真,同时写好错误恢复机制就后期不会这么麻烦的找bug了。 5.多点时间思考。出现问题后,不要急着修改。其实修改问题的时间总是会比思考问题的时间多,为何不多思考一下而节约大量的修改时间呢?要思考推测可能的原因,想清楚后把这些可能的原因都用debug pin或者chipscope引出来。好的code都会引出一些关键信号的debug pin的,就是你不需要用到但是还是引出到上层模块了,以便观察。注意复用已有的debug pin。很多时候,在测试过程中产生了一大堆测试信号,但是时间一长就忘了复用。实际上,当一个问题产生的时候,通过反复观察已有的debug-pin或许足以发现问题根源,而无需再引出新的pin,并浪费时间去综合和PAR。 6。同步设计的重要性。数字电路在时钟同步的设计原则下,其功能通过simulation就可以验证。simulation的结果和PAR后产生的 FPGA-image基本等价,老大经验之谈,其实我也怀疑。当然FPGA也要遵循同样的设计原则:即时钟同步。所以对于PAR的结果首先就要确保其时钟同步的特性。体现为寄存器之间的path必须在一个时钟周期内完成。(当然有其他约束的例外。)同时要满足FPGA器件的setup和hold要求。一旦出现timing-error必须通过各种途径消除error,因为error的存在,意味着时钟同步的大前提已经被破坏,这时,simulation取得的结果和FPGA是不等价的,继续调试也毫无意义了。同步设计不单单时钟同步的问题,复位信号也要同步,从A时钟域到B时钟域的复位信号最好让B时钟域的时钟打上两拍。不然综合发现关键路径居然在复位信号上,直接晕倒^_^。关于跨时钟域的信号最好都参照上面的方法,其实还有很多注意的地方,详细情况有兴趣多看看关于多时钟域设计的资料。 7。FPGA的约束要注意不可控的接口部分。FPGA内部的寄存器之间的timing完全可以通过PAR报告来确认是否有问题。但是和外界的接口部分却充满了疑问。我们一般通过假定的input-delay和output-delay来对接口部分进行约束。由于从一开始就施加的是假定的delay,所以即使没有timing-error,其结果也存在诸多疑问。这些问题都是经验的积累,没多少话说的了,很多时候你会发现很多无法解释的问题,还是找老大问问吧^_^。好的约束文件对设计性能有很大的帮助,慢慢去学习吧,这方面我自己水平也很低。 8.记得看综合报告。很多新人估计一开始没有看综合报告的习惯,不管是xilinx ISE也好,Quartus 也好都会产生一个很庞大的综合报告,新人觉得跟自己没有关系。我一开始也是这样,其实不然。这个综合报告就是综合工具对你设计的code的“评价”,你不想知道他对你的“评价”是好还是坏吗?^_^。综合报告里面有下面几个关键信息需要注意:(1)时钟频率,也就是你code最终能跑多快,这就决定了你的设计是否存在关键路径。这是模块性能优化过程的重头戏。(2)资源占用信息,看看是否跟当初预想的基本符合。(3)warning信息,很多时候大家都不看warning的,大一点的报告至少有上千个warning信息,挺耗时的。但是warning信息里面有一个点需要注意就是你用了的信号没定义报的warning,这个warning引起的后果跟error一样。可以通过查关键字tied找到。因为用了没定义的信号将被综合工具一律tied connect zero。 9.养成良好的code 风格,形式上的风格我就不说了。其他方面比如状态机编写,我一般用三段式,不知道大家怎样,三段便于修改和理解,比较经典,综合电路状态与data输出同步。另外复位无特殊情况我基本用同步。切忌不要在两个always模块中对同一个变量赋值,这个modelsim仿真一般不会有问题,综合的时候,有些综合工具也会报错(比如ISE的XST),这让我后来大骂XST是垃圾。这个问题造成的结果是致命的,害我花了一个礼拜才找出没出图像的原因。 10.出来实习要端正心态。学生阶段还是以学习为主吧,有机会就多学点吧,抓住一切学习的机会,以后你回忆的时候你会发现你收获真的很多。 11.写好设计文档。一般设计从写好设计文档开始的,大的项目都不是让你急于写code,都是把文档写出来大家讨论好才写code。很多问题在写文档的时候就解决了,不然写完了code也免不了返工。另外平时最好养成做设计笔记的习惯,有什么问题和想法做好笔记,你会发现当你一筹莫展的时候翻翻前面的笔记对你很有用。 写了这么多,其实自己也感觉没什么头绪的,希望对各位有所参考价值,也不枉费我下班后花一个晚上时间把头脑里面能想到的写下来^_^。肯定有很多不妥和不太完善的地方,以后继续修正补充,欢迎各位指正。最后祝愿各位师弟师妹学习进步,将来找到好实习。
阅读(839) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~