Verilog & Testbench学习笔记1

1. 验证自动化

自动比较的原理就是用计算机代替人去比较实际响应和期望相应是否相同，然后把相关信息显示出来，从而减少了人工的干预，提高了验证效率。

实现方法：利用时钟同步验证，or经过一定数据包再异步比较验证。

2. 增强testbench的重用性，避免因为重新开发而带来的风险和额外的开发时间。

3. reg类型定义了一种暂存数据的变量，但其物理模型并不一定是一个寄存器，也可能仅是一根连线：只有在时序逻辑中它对应的才是寄存器；而在组合逻辑中，它则表示一根连线。

在实际应用中，凡是在initial(initial是行为级语法，不可综合)、always块中的被赋值的信号都必须定义成reg。

4. wire与reg的差异? 什么时候该用wire?什么时候又该用reg?

    若参数出现在begin...end之内，则须使用reg；
    使用wire，须搭配assign；
    若wire和reg用错，compiler都会提醒，所以不必太担心。

     需要注意：在Verilog中使用reg，并不表示综合后就是暂存器(register)。若在组合电路中使用reg，综合后仍只是net，唯有在时序电路中使用reg，合成后才会以flip-flop形式表示成register。

5. Verilog中出现小数，Modelsim编译时不会报错or警告，虽然小数是不可综合的。而且利用小数进行比较的时候，如cnt <>

linux下查找字符串命令

1. set命令可以显示出当前shell下所有全局参量定义及其值;

2. 查找并删除当前目录下小文件：
find . -type f -size -10k -exec rm {} \;
说明：
-type f 查找文件
-size -10k，
小于10k的。"＋"是表示要求系统只列出大于指定大小的文件，而使用"-"则表示要求系统列出小于指定大小的文件。

3. 遍历文件夹grep一个字符串
find . -name "*c" | xargs grep "strings"

在当前文件夹下所有c文件中查找字符串“string”

4. 在某目录下文件中查找某字符串
grep -r youcode dir
例如：查找home下文件中查找hello
grep -r hello /home

例如：在当前所有目录下文件中查找hello，不区分大小写
grep -ir hello .

（转）Qt简介

Qt 是一个跨平台的 C++ 图形用户界面库，由挪威 TrollTech
公司出品，目前包括Qt， 基于 Framebuffer 的 Qt Embedded，快速开发工具 Qt
Designer，国际化工具 Qt Linguist 等部分 Qt 支持所有 Unix 系统，当然也包括
Linux，还支持 WinNT/Win2k，Win95/98 平台。

Trolltech 公司在 1994 年成立，但是在 1992 年，成立 Trolltech
公司的那批程序员 就已经开始设计 Qt 了，Qt 的第一个商业版本于 1995
年推出然后 Qt 的发展就很快了，下面是 Qt 发展史上的一 些里程碑:
1996 Oct KDE 组织成立
1998 Apr 05 Trolltech 的程序员在 5 天之内将 Netscape5.0 从 Motif 移植到 Qt
上
1998 Apr 08 KDE Free Qt 基金会成立
1998 Jul 09 Qt 1.40 发布
1998 Jul 12 KDE 1.0 发布
1999 Mar 04 QPL 1.0 发布
1999 Mar 12 Qt 1.44 发布
1999 Jun 25 Qt 2.0 发布
1999 Sep 13 KDE 1.1.2 发布
2000 Mar 20 嵌入式 Qt 发布
2000 Sep 06 Qt 2.2 发布
2000 Oct 05 Qt 2.2.1 发布
2000 Oct 30 Qt/Embedded 开始使用 GPL 宣言
2000 Sep 04 Qt free edition 开始使用 GPL

基本上，Qt 同 X Window 上的 Motif，Openwin，GTK 等图形界 面库和
Windows 平台上的 MFC，OWL，VCL，ATL 是同类型的东西，但是 Qt 具有下列优点:
优良的跨平台特性:

Qt支持下列操作系统: Microsoft Windows 95/98， Microsoft Windows NT，
Linux， Solaris， SunOS， HP-UX， Digital UNIX (OSF/1， Tru64)， Irix，
FreeBSD， BSD/OS， SCO， AIX， OS390，QNX 等等。
面向对象

Qt 的良好封装机制使得 Qt
的模块化程度非常高，可重用性较好，对于用户开发来说是非常 方便的。 Qt
提供了一种称为 signals/slots 的安全类型来替代 callback，这使得各个元件
之间的协同工作变得十分简单。
丰富的 API

Qt 包括多达 250 个以上的 C++ 类，还替供基于模板的 collections，
serialization， file， I/O device， directory management， date/time
类。甚至还包括正则表达式的处理 功能。

支持 2D/3D 图形渲染，支持 OpenGL

大量的开发文档

XML 支持

但是真正使得 Qt 在自由软件界的众多 Widgets (如
Lesstif，Gtk，EZWGL，Xforms，fltk 等等)中脱颖而出的还是基于 Qt
的重量级软件 KDE 。 有趣的是，KDE 也是使得 Trolltech
公司承受巨大压力的一个原因。下面我们将来看看这场 著名的自由软件圣战 --
"KDE/QT .VS. Gnome/Gtk" 是怎么发生的。

在 Unix 的图形界面一向是以 MIT 的 X Window 系统为标准，
可是在商业应用上有两大流派，一派是以 Sun 公司领导的 Openlook 阵营，一派是
IBM/HP 领导的OSF (Open Software Foundation) 的 Motif，
双方经过多年竞争之后， Motif 最终 胜出，成为最普遍使用的界面库，
后来双方又妥协出一个 CDE(Common Desktop Enviroment)
作为一个标准的图形界面。 但是 Motif/CDER 的价格非常昂贵，在这同时微软的
Windows 图 形界面发展速度非常快，而 Unix 界的后起之秀 Linux
也急需一个可靠并且免费的图形界面。

1996 年 10 月，由开发图形排版工具Lyx的德国人 Matthias Ettrich 发起了
KDE 计划。 KDE 的全称为 K Desktop Environment，可以看出是针对 CDE。 KDE
本身是采用 GPL 宣言的，但是 KDE 却是使用 Qt 来作为其底层库，因为当时 Qt
已经将其 Unix 版 本自由发布了，但是 Qt 并不遵循 GPL， 因此 KDE
被很多自由软件的作者攻击，认为利用非自由软件开发违背了 GPL 的精神，于是
GNU 的狂热信徒兵分两路，一路是去制作 Harmonny，试 图重写一套兼容于 Qt
的替代品，另一路是由一个 26 岁的墨西哥程序员 Miguel De Icaza
领导下重新开发一套叫 GNOME(GNU Network Object Enviroment)来替代 KDE。

由于 Linux 界的老大 RedHat 不喜欢 KDE/Qt 的版权，因此 RedHat
甚至专门派出了几个全职程序员来加入 GNOME 进行开发工作，于是一场同 Motif VS
Openlook 相 似的圣战就这么打起来了。 Trolltech 为了 KDE 曾数次修改 Qt
的版权，从成立 KDE Free Qt 基金会到采用 QPL，可谓是费尽心机，但是 GNOME
采用的 GTK 一开始就是完全的 GPL，因此在这个方面 GNOME 有一定的优势，加上
Qt/KDE 采用 C++ 开发，入门的门槛比较高，而 GTK/Gnome 采用 C， 因此 GNOME
吸引了更多的自由软件开发者，但是 KDE 毕竟先走了一步， 推出的 KDE1.1.2
十分稳定， 而当时急忙中推出的 GNOME1.0 的系统稳定性奇差，有人甚至笑称
GNOME1.0 还没有 KDE 1.0 Alpha 稳定。但是 GNOME
后来发展比较快，大有迎头赶上的势头。 当时双方的开发者在网络
上炒得天翻地覆，连 Linux 之父 Linus 只是说了一句喜欢用 KDE 都倍受指责。

战争到了第三个年头，也就是2000年，可谓是风云突变，一个接
一个重大的事件先后发生: 首先是一批从 Apple 公司出来的工程师成立了一个叫
Eazel 的公司替 GNOME 设计界面，然后是一批 GNOME 程序员成立了一个 Helix
Code 公司替 GNOME 提供商业支持，而大家期待以久的 KDE 2.0
也终于发布了，这恐怕是目前最为庞大的自由软件了之一， 除了 KDE 本身，还包括
Koffice 套件，和集成开发环境 Kdevelop 等等大批软件，其 主力软件 Kounqueror
也是第一个可以同微软的 Internet Exploer 相抗衡的浏览器。 而 Sun 公司，Red
Hat 公司， Eazel 公司，Helix Code 等一批公司成立了一个GNOME 基金会， Sun
还宣布将把重量级办公软件 Star office 同 GNOME 集成， Trolltech
公司自然不能坐以待毙，于2000年 10 月 4 日将 Qt 的 free edition 变为 GPL
宣言，彻底解决了 KDE 的版权问题， 又推出了嵌入式 Qt ，给了 GNOME
阵营一个有力的回击。

到现在为止，这场战争还在继续， 相信我们不能很快看到结果。一般说来，
目前 GNOME 吸引的公司比较多，但是 KDE/Qt 的开发的效率和质量比 GNOME
高，而且在 Office/嵌入式 环境中先走一步，在一定时间内还将处于优势地位。

那么对于用户来说，如何在 Qt/GTK 中作出选择呢?一般来说，如果用户使用
C++，对库的稳定性，健壮性要求比较高，并且希望跨平台开发的话，那么使用 Qt
是较好的选择， 但是值得注意的是，虽然 Qt 的 Free Edition 采用了 GPL
宣言，但是如果你开发 Windows 上的 Qt 软件或者是 Unix
上的商业软件，还是需要向 Trolltech 公司支付版权费用的。

Linux启动过程步骤

一. Bootloader
二.Kernel引导入口
三.核心数据结构初始化--内核引导第一部分
四.外设初始化--内核引导第二部分
五.init进程和inittab引导指令
六.rc启动脚本
七.getty和login
八.bash

（转）深入理解switch-case语句

更深入一点理解 switch 语句 及 c/c++ 对 const 的处理
作者： 谢煜波
原地址：http://blog.csdn.net/xiaohan13916830/archive/2004/08/17/76724.aspx

前段时间在论坛上看见台湾李维在<<Borland传奇>>一书中对windows编程模式中,消息处理部分有如下的一些分析:
他说,在消息处理循环中,一般的形式是这样的
MSG msg ;
switch( msg ){
case WM_XXXXXXX :
....
case WM_XXXXXXX :
....
case WM_XXXXXXX :
....
} ;
李维说,这种模式是很低效的,因应经过汇编后,这种C代码会产生如下的汇编代码
cmp .... .....
jnz .... .....
cmp .... .....
jnz .... .....
cmp .... .....
jnz .... .....
如果你的 case
足够多,比如,你有一万条消息需要处理,而不幸的是你把一条最常用的消息
放在了最后一位,那么当这条消息要得到处理,会首先经过一万次的cmp与jnz,
李维认为,这
是非常非常低效的,实在是低效的忍无可忍,无需再忍~~:P

在起初,我也是这样认为的,但近来的阅读及实验却发现,这种看法非常片面,今天就来谈谈这个问题(
所有实验在 linux 平台下完成 )

首先看一到用 c 编写的程序
/* -------------------- filename : ta.c --------------- */
int switch_test_first( int x )
{
int res ;
switch( x ){
case 100 :
res = 1 ;
break ;
case 102 :
res = 2 ;
break ;
case 103 :
res = 3 ;
break ;
}
return res ;
}
然后,我们用 gcc 将它编译成汇编文件( 使用 -S 开关 )
gcc -S ta.c
将得到如下的汇编文件( ta.s )
.file "ta.c"
.text
.globl switch_test_first
.type switch_test_first,@function
switch_test_first:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
.file "ta.c"
.text
.globl switch_test_first
.type switch_test_first,@function
switch_test_first:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
movl %eax, -8(%ebp)
cmpl $102, -8(%ebp) // 1
je .L4 // 2
cmpl $102, -8(%ebp) // 3
jg .L8 // 4
cmpl $100, -8(%ebp) // 5
je .L3 // 6
jmp .L2 // 7
.L8:
cmpl $103, -8(%ebp)
je .L5
jmp .L2
.L3:
movl $1, -4(%ebp)
jmp .L2
.L4:
movl $2, -4(%ebp)
jmp .L2
.L5:
movl $3, -4(%ebp)
.L2:
movl -4(%ebp), %eax
leave
ret
.Lfe1:
.size switch_test_first,.Lfe1-switch_test_first
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"

注意看文件中 // 1 ~ // 7
的部份,从这个部份,我们可以看出,gcc确实是把一些case语句转成了李维所说的那种方式进行处理,我们看见了代码中存在有众多的
cmpl 与 jmp 语句
这就相当于你使用if..else..一样,但是否总是这样呢?

我们下面改动一下 ta.c 这个文件,在里面再多加一些 case 语句
/* -------------- filename : new_ta.c ------------------- */
int switch_test_first( int x )
{
int res ;
switch( x ){
case 100 :
res = 1 ;
break ;
case 102 :
res = 2 ;
break ;
case 103 :
res = 3 ;
break ;
case 104 :
res = 4 ;
break ;
case 105 :
res = 5 ;
break ;
case 106 :
res = 6 ;
break ;
}
return res ;
}
这个 new_ta.c 与原来的 ta.c 在结构上完全相同,唯一不同的就是 case
语句的数量变多了,下面我们来编译一下这个文件
gcc -S new_ta.c
下面是我们产生的更新的汇编文件
.file "new_ta.c"
.text
.globl switch_test_first
.type switch_test_first,@function
switch_test_first:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
subl $100, %eax
movl %eax, -8(%ebp)
cmpl $6, -8(%ebp)
ja .L2
movl -8(%ebp), %edx
movl .L9(,%edx,4), %eax
jmp *%eax
.section .rodata
.align 4
.align 4
.L9: // A
.long .L3
.long .L2
.long .L4
.long .L5
.long .L6
.long .L7
.long .L8
.text
.L3: // 1
movl $1, -4(%ebp)
jmp .L2
.L4: // 2
movl $2, -4(%ebp)
jmp .L2
.L5: // 3
movl $3, -4(%ebp)
jmp .L2 // 4
.L6:
movl $4, -4(%ebp)
jmp .L2 // 5
.L7:
movl $5, -4(%ebp) // 6
jmp .L2
.L8: // 7
movl $6, -4(%ebp)
.L2:
movl -4(%ebp), %eax
leave
ret
.Lfe1:
.size switch_test_first,.Lfe1-switch_test_first
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"

仔细比较一下这个最新的 new_ta.s 与前面的 ta.s,精华全在里面了!
首先 new_ta.s 比前面的 ta.s 多了一个 .L9 部分，而且它的 // 1 ~ // 7
中没有了前面
ta.s 文件中所存在的众多的 cmpl 与 jmp
语句，那么，现在这样的代码又是怎么实现
switch 语句中的跳转的呢？我们来仔细分析一下它新多出来的 .L9 部份。
.section .rodata
.align 4
.align 4
.L9:
.long .L3
.long .L2
.long .L4
.long .L5
.long .L6
.long .L7
.long .L8
.text
显而易见，.L9
部份是一个我们最常见的数据结构——表，它的每一项都是一个标号，而这个标号，恰恰是每个
case 语句的入口标号！
这很容易让我们想到，它很可能是用了一张表来存放所有的 case
语句的入口，然后，在
执行 switch 语句的时候就从这个表中直接检出相应的 case
语句的入口地址，然后跳转
到相应的 case
语句去执行，就像hash_table似的。具体是不是这样呢？我们看看进入
switch 部份的代码:

pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl 8(%ebp), %eax
subl $100, %eax
movl %eax, -8(%ebp)
cmpl $6, -8(%ebp)
ja .L2
movl -8(%ebp), %edx
movl .L9(,%edx,4), %eax // 1
jmp *%eax // 2
果然如此！首先在 // 1
处根据%edp的值（其值相当于表的下标）在.L9的表中找到相应
case 语句的入口地址，并把这个地址存到%eax中，然后通过 // 2
（这是一个间接跳转
语句）转到%eax存放的地址中，也即相应的case语句处。
C编译器，果然聪明！

通过这个分析我们可以知道如下两点：
1. 当 case 语句少的时候，C编译器将其转成 if..else..
类型进行处理，运用较多的
cmp 与 jmp 语句 ，而当 case
语句较多的时候，C编译器会出成一个跳转表，而直
接通过跳转表进行跳转，这让 switch 具有非常高的效律，而且效律几乎不会因为
case 语句的增长而减小，李维所担忧的问题是完全不会发生的
2. 可以问答下面几个问题：
1. 为什么 case 语句中需要的是整数类型而不能是其余的类型？
这是因为，case
语句中的这个值是用来做跳转表的下标的，因此，当然必须是整数
2. 为什么 case 语句在不加break的时候具有直通性?
这是因为跳转是在进入 switch
是计算出的，而不是在case语句中计算出的，整个
case
语句群就是一块完整而连续的代码，只是switch让其从不同的位置开始执行。

上面的内容，在《Computer Systems A Programmer's
Perspective》中有很详细的论述，
感兴趣可以去找来仔细看看~~~

既然，case 语句需要的是整数的常量值，那么我们是否可用 const
类型呢？比如下面
一段代码：

const int c_1 = 100 ;
const int c_2 = 102 ;

void test( int x )
{
switch( x ){
case c_1 :
++x ;
case c_2 :
--x ;
}
}

这段代码，用 c 编译器编译，编译器会提示错误，但在 c++
编译器中却不会，这主要是由于 c , 与 c++ 编译器对 const
这个东东的处理不同。我们来看看下面一段 c 程序
/*------------- filename : const_c.c -----------*/
const int a = 15 ;

void f( int x )
{
x = a ;
}
同样用 gcc 编译
gcc -S const_c.c
然后，来看看它的汇编文件
.file "const_c.c"
.globl a
.section .rodata
.align 4
.type a,@object
.size a,4
a: // 1
.long 15
.text
.globl f
.type f,@function
f:
pushl %ebp
movl %esp, %ebp
movl a, %eax // 2
movl %eax, 8(%ebp)
leave
ret
.Lfe1:
.size f,.Lfe1-f
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
注意 // 1 处，C 编译器为 a 分配了地址，并把它的值设为 15 ，而在 // 2
处，它是将
a 这个地址中的值赋给了 %eax，这同一般的普通变量而非const 变量赋值没什么两样

下面我们用 c++ 编译器来编译这段代码，它产生的汇编文件如下：
.file "const_cpp.cpp"
.text
.align 2
.globl _Z1fi
.type _Z1fi,@function
_Z1fi:
.LFB2:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
movl $15, 8(%ebp) // 1
leave
ret
.LFE2:
.Lfe1:
.size _Z1fi,.Lfe1-_Z1fi
.section .rodata
.align 4
.type a,@object
.size a,4
a:
.long 15
.ident "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"
同样注意// 1 处，它以经把 a 的值用 15 来取代了，
也就是说，在c中const变量的行为更像一个非const变量，而在cpp中，const变量的行为就像是#define
由于 c++ 中，const 变量的值是在编译时就计算出来的，因此，它可以用在 case
语句中，而 c 中，const值在编译时只是一个变量的地址，因此，它无法用在 case
语句中.
-----------------------------------------------------------------------------
参考文献：<<Computer Systems A Programmer's Perspective>>

利用auto工具来快速生成Makefile

Linux
C程序开发，免不了用Makefile来编译，Makefile的规则定义学习容易，一段时间不用，难免会忘。现在有Automake工具，自动化生成Makefile，用好了那是事半功倍，相当的有效率。
　　下面将介绍 如何利用 GNU Autoconf 及 Automake 来协助『自动』产生
Makefile 文件，并且让开发出来的程序or软件，只要会 ``./configure'',
``make'', ``make install''
就可以安装到系统中。刚开始学，了解不多，介绍个例子，先掌握其流程：

　　1. 简介

　 　Makefile 基本上就是『目标』(target), 『关连』(dependencies)
和『动作』三者所组成的一连串规则。而 make 就会根据 Makefile
的规则来决定如何编译 (compile) 和连结 (link) 。
　 　Makefile
基本构造虽然简单，但是妥善运用这些规则就也可以变出许多不同的花招。却也因此，许多刚开始学习写
Makefile 时会感到没有规范可循，每个人写出来的 Makefile
长得都不太一样，不知道从何下手，而且只要环境变数不同或路径改一下，可能Makefile
就得跟着修改。虽然有 GNU Makefile Conventions (GNU Makefile 惯例)
订出一些使用 GNU 程序设计时撰写 Makefile
的一些标准和规范，但是内容很长而且很复杂,
并且经常做些调整，为了减轻软件开发者维护 Makefile
的负担，因此有了Automake。

　　软件编写人员只需写一些预先定义好的巨集 (macro)，交给 Automake
处理后会产生一个可供Autoconf 使用的 Makefile.in 文件。再配合利用Autoconf
产生的自动设定文件 configure 即可产生一份符合 GNU Makefile惯例的 Makeifle
了。

　　2. 开始之前

　　在开始试着用 Automake 之前，请先确认你的系统已经安装以下的软件：

　　1. GNU Automake

　　2. GNU Autoconf

　　3. GNU m4

　　4. perl

　　5. GNU Libtool (生成shared library时需要)

　　3. 一个简单的例子

　　Automake 所产生的 Makefile
除了可以做到程序的编译和连结，也已经把如何产生程序文件(如 manual page,
info 文件及 dvi 文件)
的动作，还有把原始程序包装起来以供散的动作都考虑进去了，所以原始程序所存放的目录架构最好符合
GNU 的标准惯例，接下来我拿hello.c 来做为例子。

　　在工作目录下建立一个新的子目录 ``devel''，再在 devel
下建立一个``hello'' 的子目录，这个目录将作为我们存放 hello
这个程序及其相关文件的地方：

　　% mkdir devel

　　% cd devel

　　% mkdir hello

　　% cd hello

　　用编辑器写个 hello.c 文件，

　　#include stdio.h

　　int main(int argc, char** argv)
　　{
　　printf(``Hello, Slitaz! \n'');
　　return 0;
　　}

　　接下来就要用 Autoconf 及 Automake 来帮我们产生 Makefile 了，

　　1. 用 autoscan 产生一个 configure.in 的雏型，执行 autoscan
后会产生一个configure.scan 的文件，我们可以用它做为configure.in文件的蓝本。

　　% autoscan

　　% ls

　　configure.scan hello.c

　　2. 编辑 configure.scan 文件，如下所示，并且把它的文件名改成configure.in

　　#Process this file with autoconf to produce a con figure script.

　　AC_INIT(hello.c)

　　AM_INIT_AUTOMAKE(hello, 1.0)

　　# Checks for programs.

　　AC_PROG_CC

　　# Checks for libraries.

　　# Checks for header files.

　　# Checks for typedefs, structures, and compiler ch aracteristics.

　　# Checks for library functions.

　　AC_OUTPUT(Makefile)

　　3. 执行 aclocal 和 autoconf ，分别会产生 aclocal.m4 及 configure
两个文件

　　% aclocal

　　% autoconf

　　% ls

　　aclocal.m4 configure configure.in hello.c

　　4. 编辑 Makefile.am 文件，内容如下

　　AUTOMAKE_OPTIONS= foreign

　　bin_PROGRAMS= hello

　　hello_SOURCES= hello.c

　　5. 执行 automake --add-missing ，Automake 会根据 Makefile.am
文件产生一些文件，包含最重要的 Makefile.in

　　% automake --add-missing

　　automake: configure.in: installing `./install-sh'

　　automake: configure.in: installing `./mkinstalldirs'

　　automake: configure.in: installing `./missing'

　　6. 最后执行 ./configure ，

　　% ./configure

　　creating cache ./config.cache

　　checking for a BSD compatible install... /usr/bin/in stall -c

　　checking whether build environment is sane... yes

　　checking whether make sets ${MAKE}... yes

　　checking for working aclocal... found

　　checking for working autoconf... found

　　checking for working automake... found

　　checking for working autoheader... found

　　checking for working makeinfo... found

　　checking for gcc... gcc

　　checking whether the C compiler (gcc ) works... yes

　　checking whether the C compiler (gcc ) is a cross-co mpiler... no

　　checking whether we are using GNU C... yes

　　checking whether gcc accepts -g... yes

　　updating cache ./config.cache

　　creating ./config.status

　　creating Makefile

　　现在你的目录下已经产生了一个 Makefile 文件，下个 ``make''
指令就可以开始编译 hello.c 成执行文件，执行 ./hello 和 GNU 打声招呼吧！

　　% make

　　gcc -DPACKAGE="hello" -DVERSION="1.0" -I. -I. -g -O2 -c he llo.c

　　gcc -g -O2 -o hello hello.o

　　% ./hello

　　Hello，Slitaz!

　　你还可以试试 ``make clean''，''make install''，''make dist''
看看会有什么结果。

　　4. 一探究竟

　 　上述产生 Makefile
的过程和以往自行编写的方式非常不一样，舍弃传统自行定义 make 的规则，使用
Automake 只需用到一些已经定义好的巨集即可。我们把巨集及目标 (target)写在
Makefile.am 文件内，Automake读入 Makefile.am
文件后会把这一串已经定义好的巨集展开并且产生对应的Makefile.in 文件，
然后再由 configure 这个 shell script 根据Makefile.in 产生适合的 Makefile。
　　在上面例子中可借由 Autoconf 及 Automake 工具所产生的文件有
configure.scan、aclocal.m4、configure、Makefile.in，需要我们加入设定者为
configure.in 及 Makefile.am。

　　4.1 编辑 configure.in 文件

　 　Autoconf 是用来产生 'configure' 文件的工具。'configure' 是一个shell
script，它可以自动设定原始程序以符合各种不同平台上 Unix
系统的特性，并且根据系统叁数及环境产生合适的 Makefile 文件或是C 的标头文件
(header
file)，让原始程序可以很方便地在这些不同的平台上被编译出来。Autoconf 会读取
configure.in 文件然后产生 'configure' 这个shell script。

　 　configure.in 文件的内容是一连串 GNU m4 的巨集，这些巨集经过autoconf
处理后会变成检查系统特徵的 shell script。configure.in
内巨集的顺序并没有特别的规定，但是每一个 configure.in
文件必须在所有巨集前加入 AC_INIT 巨集，然后在所有巨集的最后面加上
AC_OUTPUT 巨集。我们可先用 autoscan 扫描原始文件以产生一个 configure.scan
文件，再对 configure.scan 做些修改成 configure.in
文件。在范例中所用到的巨集如下：

　　#
这个巨集后面的字不会被处理，可视为注解。

　　AC_INIT(FILE)
　　这个巨集用来检查原始码所在的路径，autoscan 会自动产生，我们不必修改它。

　　AM_INIT_AUTOMAKE(PACKAGE,VERSION)
　　这是使用 Automake 所必备的巨集，PACKAGE
是我们所要产生软件套件的名称，VERSION 是版本编号。

　　AC_PROG_CC
　　检查系统可用的 C 编译器，如果原始程序是用 C 写的就需要这个巨集。

　　AC_OUTPUT(FILE)
　　设定 configure 所要产生的文件，如果是 Makefile 的话，configure
便会把它检查出来的结果带入 Makefile.in 文件然后产生合适的 Makefile。

　 　实际上，我们使用 Automake
时，还须要一些其它的巨集，这些额外的巨集我们用 aclocal来帮我们产生。执行
aclocal 会产生 aclocal.m4文件，如果没有特别的用途，我们可以不必修改它，用
aclocal 所产生的巨集会告诉 Automake 怎么做。

　　有了 configure.in 及 aclocal.m4 两个文件后，便可以执行 autoconf来产生
configure文件了。

　　4.2 编辑 Makefile.am 文件

　　接下来我们要编辑 Makefile.am 文件，Automake 会根据 configure.in
中的巨集把Makefile.am 转成 Makefile.in 文件。Makefile.am
文件定义我们所要产的目标：

　　AUTOMAKE_OPTIONS

　 　设定 automake 的选项。Automake 主要是帮助开发 GNU
软件的人员维护软件套件，所以在执行 automake 时，会检查目录下是否存在标准
GNU 软件套件中应具备的文件文件，例如 'NEWS'、'AUTHOR'、'ChangeLog'
等文件文件。设成 foreign 时，automake 会改用一般软件套件的标准来检查。

　　bin_PROGRAMS

　　定义我们所要产生的执行文件文件名。如果要产生多个执行文件，每个文件名用空白字元隔开。

　　hello_SOURCES

　　定义 'hello' 这个执行文件所需要的原始文件。如果 'hello'
这个程序是由多个原始文件所产生，必须把它所用到的原始文件都列出来，以空白字元隔开。假设
'hello' 这个程序需要 'hello.c'、'main.c'、

　　'hello.h'

　　三个文件的话，则定义

　　hello_SOURCES= hello.c main.c hello.h

　　如果我们定义多个执行文件，则对每个执行文件都要定义相对的filename_SOURCES。

　 　编辑好 Makefile.am 文件，就可以用 automake --add-missing
来产生Makefile.in。加上 --add-missing 选项是告诉 automake
顺便帮我们加入包装一个软件套件所必备的文件。Automake 产生出来的
Makefile.in文件是完全符合 GNU Makefile 的惯例，我们只要执行 configure
这个shell script 便可以产生合适的 Makefile 文件了。

　　4.3 使用 Makefile

　　利用 configure 所产生的 Makefile
文件有几个预设的目标可供使用，我们只拿其中几个简述如下：

　　make all

　　产生我们设定的目标，即此范例中的执行文件。只打 make
也可以，此时会开始编译原始码，然后连结，并且产生执行文件。

　　make clean

　　清除之前所编译的执行文件及目的文件 (object file, *.o)。

　　make distclean

　　除了清除执行文件和目的文件外，也把 configure 所产生的
Makefile也清除掉。

　　make install

　　将程序安装至系统中。如果原始码编译无误，且执行结果正确，便可以把程序安装至系统预设的执行文件存放路径。如果我们用bin_PROGRAMS
巨集的话，程序会被安装至 /usr/local/bin 这个目录。

　　make dist

　 　将程序和相关的文件包装成一个压缩文件以供散播 (distribution)
。执行完在目录下会产生一个以 PACKAGE-VERSION.tar.gz 为名称的文件。PACKAGE
和 VERSION 这两个变数是根据 configure.in 文件中AM_INIT_AUTOMAKE(PACKAGE,
VERSION) 的定义。在此范例中会产生 'hello-1.0.tar.gz' 的文件。

　　make distcheck

　　和 make dist
类似，但是加入检查包装后的压缩文件是否正常。这个目标除了把程序和相关文件包装成
tar.gz 文件外，还会自动把这个压缩文件解开，执行 configure，并且进行 make
all 的动作，确认编译无误后，会显示这个 tar.gz
文件已经准备好可供散播了。这个检查非常有用，检查过关的套件，基本上可以给任何一个具备
GNU 发展境的人去重新编译。就 hello-1.tar.gz 这个范例而言，除了在 Red Hat
linux 上，在 FreeBSD 2.2.x 版也可以正确地重新编译。

　 　要注意的是，利用 Autoconf 及 Automake
所产生出来的软件套件是可以在没有安装 Autoconf 及 Automake
的环境上使用的，因为 configure 是一个 shell script，它己被设计可以在一般
Unix 的 sh 这个 shell 下执行。但是如果要修改 configure.in 及 Makefile.am
文件再产生新的configure 及 Makefile.in 文件时就一定要有 Autoconf 及
Automake 了。

　　5. 说明

　 　Autoconf 和 Automake 功能十分强大，你可以从它们所附的 info
文件找到详细的用法。你也可以从许多现存的 GNU 软件或 Open Source
软件中找到相关的 configure.in 或 Makefile.am 文件，它们是学习 Autoconf
及Automake 更多技巧的最佳范例。

　　本文只用到了 Autoconf 及 Automake
的皮毛罢了，希望这篇文件能帮助你对产生
Makefile有个简单的依据。其它有关开发 GNU程序或 C 程序设计及 Makefile
的详细运用及技巧，请参阅http://www.gnu.org上的说明文档。
　 　有了Autoconf 及 Automake 的辅助，产生一个 Makefile
似乎不再像以前那么困难了，而使用 Autoconf 也使得我们在不同平台上或各家
Unix之间散播及编译程序变得简单，这对于在 Unix
/linux系统上开发程序的人员来说减轻了许多负担。妥善运用这些 GNU
的工具软件，可以帮助我们更容易去发展程序，而且更容易维护原始程序码。

输入法生效

由于linux下以源代码形式发行的软件的安装方式，一般都是三步：

./configure

make

make install

如果有特殊的安装需要，可以先

./configure --help

看看你需要改什么预定的值，一般来说安装过后可以用make
clean来清除编译过程中产生的临时文件。至于卸载的话，可以查查这个软件都有哪些文件，直接删除就是了，有的软件可以用make
uninstall来卸载。

安装完毕后重启，再对其进行设置

注意：输入法要正常运行，有三个条件，locale，XMODIFIERS和中文字体。locale是使用中文的基本条件，没有locale，就不能使用中文。XMODIFIERS是输入法和应用程序对话的通道，应用程序通过这个变量，来知道应该与哪个输入法(XIM)对话。

把隐藏文件夹给开起来….

如果你在安装系统的时候，选了简体中文，那么locale就已经设置好了，在你的用户目录下，找到.bashrc文件（是隐藏文件，所以前面有一个"."），在这个文件最后面加上：

export XMODIFIERS="@im=fcitx"

export XIM=fcitx

export XIM_PROGRAM=fcitx

C太厉害的Verilog会学不好

Verilog的优点是让你不用再花时间去学习一个新的语言（如VHDL），但缺点
是很容易用C的思维去写Verilog而不自知，因为代码实在太像了。

Verilog只是语法跟C相似，但观念却是硬件电路的概念。

主要的区别有：

1. C语言靠位置先后决定执行顺序；而Verilog却靠时钟来分先后，跟语句位置先后毫无关系。

如以下的Verilog:
  always@(posedge clk) begin
  e <= a & b;
  f <= c & d;
  end

虽然看起来是 e <= a & b; 在 f <= c & d;前面，但实际e和f并没有先后之分，是并行的。

2. 硬件要循序，要靠clock和FSM
或许你会说，『我的算法就是要循序一步一步的做，如C语言那样，那怎么办?』，若Verilog要这样，就得靠clock并且搭配FSM，当一个state完成后，进入下一个state，这样就能依照clock的进行，而达成循序的要求。

3.Verilog程序代码没有先后之分
除了blocking assignment有先后执行顺序，而nonblocking assignment同时执行外，Verilog的程序没有前后顺序之分，所以才称为硬件『描述』语言，而非硬件『程序』语言，先写的不代表先执行，后写的也不代表后执行，只是代表硬件的架构的描述，也就是说，将原来的电路图，变成文字描述而已。

4.多用RTL Viewer和ModelSim观察自己写的code
Verilog写法小小的差异，合成出来的硬件就可能有天壤之别，多用RTL Viewer观察合成出来的硬件是否和自己预期的一样，并多用ModelSim观察跑出来的波形，这样会增加你对Verilog的掌握度。

Conclusion
很多人学了Verilog，还是把它当C语言写，事实上他们只是语法类似，但背后的思维并不一样，唯有『心中有硬件』，才能设计出好的电路。

正在读的书：
王钿、卓兴旺 2007，基于Verilog HDL的数字应用设计，国防工业出版社

modelsim的一些常用命令

vlib work 建库
vmap work work 映射
vlog div.v tdiv.v 编译verilog写的代码
vcom div.vhl tdiv.vhl 编译vhdl 写的代码
vsim work.module 仿真相应模块
view wave/dataflow 显示波形窗口/数据流窗口
restart -f
run -all
quit -sim 退出仿真
pwd
cd
add wave /tdiv/* 把tdiv中的所有信号都加到wave波形图中

当然在modelsim中也可以用批处理文件，比如有一批处理文件file.do,则可用如下命令来调用它
do file.do

关于do文件的编写，有一个快速学习的好方法：
你执行的每一步鼠标点击or选择操作，在modelsim的命令行都有相应的代码输
出，你可以仿照写出正确的do文件。

(转)永远不要因为工作不好而辞职

其中的两句话很值得分享：

永远不要因为这个工作不好而辞职。一定要因为另一个工作更好而辞职。

人所拥有的「最后的」（last）自由是，我们可以选择我们的态度。

有一位老人，独自住在家里。他的儿女轮流回来照顾他。后来觉得最好还是住到老人院去比较好，因为他的眼睛已经完全看不见了。

迁入老人院的那一天，服务员牵着他的手告诉他，房间的样子，墙上的壁画，窗户外面是一大片草地，还有水池，这位老人回答说，真的好美，我想我在这里会很开心。服务员瞪着他，一脸讶异的说，你什么都看不见，你怎么知道美不美呢？

讲到这里，你大概已经知道这故事想要说的是什么了？

我们比那位老人的情况好多了。我们每天早上起来的时候有没有这么振奋，这么积极？

办公室里的事好像永远都做不完。烦恼的事不知道为什么总是那么多。房子、车子、小孩的学业，今天的早饭该吃什么，这些事从未间断过，就待会儿出
门，从车子开出去到抵达停车场，至少会发三次火：有人换车道没打信号灯；某段路塞车因为有人在路边并排停车；再有就是乱按喇叭。

想到这里，怪不得我们真的要做一选择。选择今天我要找到美好的事，还是要专注于烦恼的事。我们要选择感恩、宽容，抑或是要让抱怨、愤怒来折磨我。我们甚至可以在今天选择关心他人，对他人感兴趣的机会，而不要让冷漠习惯性的在心头。

30年前，我对当时的工作非常不满，时常抱怨，也多次口头叫嚷要辞职。有一天一位其它部门的年长主管跟我说，永远不要因为这个工作不好而辞职。一定要因为另一个工作更好而辞职。

这二句话对我很重要。影响也很大。卅年后的今天，回想起来，他说的真的很有道理。

现在的公司制度不好，下一个工作机构的体制多半也有缺陷。现在的公司不公平，谁能保证新的公司一切都很合理公道。现在的公司有派系，天知道多少公司有同样的权力斗争问题。跟现在的主管处不好，新工作的主管就一定处得好吗？

因而换工作不是解决办法。

根本的办法是改变态度。曾在集中营里住过，遭受过人类最悲惨的折磨的奥地利心理学家Victor
Frankel就认为，人所拥有的「最后的」（last）自由是，我们可以选择我们的态度。遭遇同样的打击，有的人选择的是绝望，有的人却选择了希望。

朋友，你选择的是什么？你准备怎样过这一天？