Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2563017
  • 博文数量: 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-08-04 15:47:22

规范很重要
工作过的朋友肯定知道,公司里是很强调规范的,特别是对于大的设计(无论软件还是硬件),不按照规范走几乎是不可实现的。逻辑设计也是这样:如果不按规范做的话,过一个月后调试时发现有错,回头再看自己写的代码,估计很多信号功能都忘了,更不要说检错了;如果一个项目做了一半一个人走了,接班的估计得从头开始设计;如果需要在原来的版本基础上增加新功能,很可能也得从头来过,很难做到设计的可重用性。

在逻辑方面,我觉得比较重要的规范有这些:
1.设计必须文档化。要将设计思路,详细实现等写入文档,然后经过严格评审通过后才能进行下一步的工作。这样做乍看起来很花时间,但是从整个项目过程来看,绝对要比一上来就写代码要节约时间,且这种做法可以使项目处于可控、可实现的状态。

2.代码规范。
a.设计要参数化。比如一开始的设计时钟周期是30ns,复位周期是5个时钟周期,我们可以这么写:
parameter CLK_PERIOD = 30;
parameter RST_MUL_TIME = 5;
parameter RST_TIME = RST_MUL_TIME * CLK_PERIOD;
...
rst_n = 1'b0;
# RST_TIME rst_n = 1'b1;
...
# CLK_PERIOD/2 clk <= ~clk;
如果在另一个设计中的时钟是40ns,复位周期不变,我们只需对CLK_PERIOD进行重新例化就行了,从而使得代码更加易于重用。
b.信号命名要规范化。
1) 信号名一律小写,参数用大写。
2) 对于低电平有效的信号结尾要用_n标记,如rst_n。
3) 端口信号排列要统一,一个信号只占一行,最好按输入输出及从哪个模块来到哪个模块去的关系排列,这样在后期仿真验证找错时后 方便很多。如:
module a(
//input
clk,
rst_n, //globle signal
wren,
rden,
avalon_din, //related to avalon bus
sdi, //related to serial port input
//output
data_ready,
avalon_dout, //related to avalon bus
...
);
4) 一个模块尽量只用一个时钟,这里的一个模块是指一个module或者是一个entity。在多时钟域的设计中涉及到跨时钟域的设计中最好有专门一个模块做时钟域的隔离。这样做可以让综合器综合出更优的结果。
5) 尽量在底层模块上做逻辑,在高层尽量做例化,顶层模块只能做例化,禁止出现任何胶连逻辑(gluelogic),哪怕仅仅是对某个信号取反。理由同上。
6) 在FPGA的设计上禁止用纯组合逻辑产生latch,带D触发器的latch的是允许的,比如配置寄存器就是这种类型。
7) 一般来说,进入FPGA的信号必须先同步,以提高系统工作频率(板级)。
所有模块的输出都要寄存器化,以提高工作频率,这对设计做到时序收敛也是极有好处的。
9) 除非是低功耗设计,不然不要用门控时钟--这会增加设计的不稳定性,在要用到门控时钟的地方,也要将门控信号用时钟的下降沿 打一拍再输出与时钟相与。
10)禁止用计数器分频后的信号做其它模块的时钟,而要用改成时钟使能的方式,否则这种时钟满天飞的方式对设计的可靠性极为不利,也大大增加了静态时序分析的复杂性。如FPGA的输入时钟是25M的,现在系统内部要通过RS232与PC通信,要以rs232_1xclk的速率发送数据。
不要这样做:
always (posedge rs232_1xclk or negedge rst_n)
begin
...
end
而要这样做:
always (posedge clk_25m or negedge rst_n)
begin
...
else if ( rs232_1xclk == 1'b1) ;

//疏桐注:在综合的时候综合器会把if条件综合成使能信号,至少我常用的Synplify是这样综合。
...
end
11)状态机要写成3段式的(这是最标准的写法),即
...
always @(posedge clk or negedge rst_n)
...
current_state <= next_state;
...
always @ (current_state ...)
...
case(current_state)
...
s1:
if ...
next_state = s2;
...
...
always @(posedge clk or negedge rst_n)
...
else
a <= 1'b0;
c <= 1'b0;
c <= 1'b0; //赋默认值
case(next_state)//疏桐注:这里是next_state,而不是current_state,需要注意这一点
s1:
a <= 1'b0; //由于上面赋了默认值,这里就不用再对b
、c赋值了(b、c在该状态为0,不会产生锁存器,下同)
s2:
b <= 1'b1;
s3:
c <= 1'b1;
default:
...
...

=================================================================================
时序是设计出来的
我的boss有在华为及峻龙工作的背景,自然就给我们讲了一些华为及altera做逻辑的一些东西,而我们的项目规范,也基本上是按华为的那一套去做。在工作这几个月中,给我感触最深的是华为的那句话:时序是设计出来的,不是仿出来的,更不是湊出来的。

在我们公司,每一个项目都有很严格的评审,只有评审通过了,才能做下一步的工作。以做逻辑为例,并不是一上来就开始写代码,而是要先写总体设计方案和逻辑详细设计方案,要等这些方案评审通过,认为可行了,才能进行编码,一般来说这部分工作所占的时间要远大于编码的时间。

总体方案主要是涉及模块划分,一级模块和二级模块的接口信号和时序(我们要求把接口信号的时序波形描述出来)以及将来如何测试设计。在这一级方案中,要保证在今后的设计中时序要收敛到一级模块(最后是在二级模块中)。什么意思呢?我们在做详细设计的时候,对于一些信号的时序肯定会做一些调整的,但是这种时序的调整最多
只能波及到本一级模块,而不能影响到整个设计。记得以前在学校做设计的时候,由于不懂得设计时序,经常因为有一处信号的时序不满足,结果不得不将其它模块信号的时序也改一下,搞得人很郁闷。

在逻辑详细设计方案这一级的时候,我们已经将各级模块的接口时序都设计出来了,各级模块内部是怎么实现的也基本上确定下来了。

由于做到这一点,在编码的时候自然就很快了,最重要的是这样做后可以让设计会一直处于可控的状态,不会因为某一处的错误引起整个设计从头进行。

阅读(1672) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~