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

全部博文(319)

文章存档

2017年(5)

2016年(10)

2015年(3)

2014年(3)

2013年(10)

2012年(26)

2011年(67)

2010年(186)

2009年(9)

分类:

2010-12-07 22:48:15

From:http://blog.ednchina.com/ilove314/1915401/message.aspx

DEV_CLRn复位

         关于DEV_CLRn管脚,在Altera的Knowledge Database中有如下描述:

 

Problem

Do I need to connect all reset ports of relevant registers in MAX II devices after I enable the “DEV_CLRn” pin in Quartus II software?

Solution

No, you do not need to connect all reset ports of relevant registers in MAX? II devices after enabling the “DEV_CLRn” pin in Quartus? II software. After you have enabled the dual purpose pin “DEV_CLRn” in Quartus II software, you do not need to connect the reset port of each register in schematic / HDL language design entry. 

 

Problem

Does the DEV_CLRn pin affect combinatorial logic?

Solution

No, the DEV_CLRn pin will not affect combinatorial logic. This optional chip-wide reset pin allows you to override all the clear ports on all device registers. When this pin is driven low, all registers are cleared; when this pin is driven high, all registers behave as programmed.

 

         其实很多器件手册中对DEV_CLRn都有与第二个Problem相同的定义。其大意是说DEV_CLRn不会影响组合逻辑。这个可选的芯片全局复位引脚的清除操作覆盖器件上的所有寄存器端口。当此引脚为低时,所有的寄存器被清零,当该引脚为高时,所有的寄存器处于可编程状态。

         大多数时候,特权同学喜欢把复位管脚接在这个DEV_CLRn上。在Enable device-wide reset (DEV_CLRn)选项off的情况下,做如下测试:

测试1:

always @(posedge clk or negedge rst_n)

         if(!rst_n) cnt <= 1'b0;

         else cnt <= ~cnt;

测试2:

always @(posedge clk or negedge rst_n)

         if(!rst_n) cnt <= 1'b1;

         else cnt <= ~cnt;

测试3:

always @(posedge clk) begin

         cnt <= ~cnt;

end

         很显然,地球人都知道在复位管脚有效时(低电平)cnt在测试1中处于电平0,测试2中处于电平1,测试3中不断变化。

         而在Enable device-wide reset (DEV_CLRn)选项on的情况下,复位管脚是不可以再接到DEV_CLRn上(这里是指当前的DEV_CLRn管脚是用户不可分配的管脚),若是随意接到一个IO上,并且处于非复位状态。那么,重复做测试1、2、3,得到的结果只有测试2是电平1,测试1和测试3是电平0。由此可见,DEV_CLRn正如其定义中所描述的,其复位覆盖到所有的内部寄存器。因此即便是在代码中没有体现异步复位的测试3,仍然逃不了被清零的命运。究其根本原因,如图1所示,在输入给寄存器的CLRN端,异步清除逻辑里不仅包含了用户代码中体现的清除信号,而且总是包含了在On情况下有效的DEV_CLRn信号。

图1


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