linux问题（3） (2008-06-08 09:36:41) 红旗redflag 6 硬盘安装全攻略首先你应该下载好安装镜像！红旗Linux桌面版6.0系统光盘 MD5SUM:918c94a7432799dbfee35507b530d888 请选择最近的链接下载：ftp://220.194.60.89/pub/redflag/dt6/rf6/RedFlag-dt6-sys.isoftp://60.232.126.152/os/linux/redflag/6/dt/RedFlag-dt6-sys.isoftp://60.232.126.154/RedFlag-dt6-sys.isoftp://60.232.126.156/RedFlag-dt6-sys.iso其次，你需要把你的安装镜像放在你的XP下的FAT32盘区的根目录下，然后从该镜像里提取两个安装引导文件－－vmlinuz 和i nitrd.img(在安装镜像里的isolinux文件夹里的），把这两个文件复制到安装镜像所在的盘的根目录下.接下来就是用GRUB引导redflag 6.0的安装镜像了！其实GRUB里的东东，我们只要有 grldl（我在后面提供了下载地址）这个文件就行了，然后我们自己动手写一个menu.lst（这个是GRUB的引导列表！）title Redflag 6 desktop kernel (hd0,0)/vmlinuz initrd (hd0,0)/initrd.img ramdisk_size=8192 把上面的代码粘贴到记事本里，然后保存为menu.lst就可以了，一定要保存到你的安装镜像所在的盘的根目录下。（声明一下，（hd0，0）可能会因你的安装镜像所在盘区而改变，这里是我的，我的安装镜像放在xp下的C盘且是FAT32格式的！）最后，我们要做的就是在XP的BOOT。INI中添加GRUB的引导的选项了，这个很简单了，你只需要打开你xp或2k中的boot。ini，然后在其中加入一句就可以了，下面的是我的boot.ini，以供参考！[boot loader] timeout=4 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows XP" /noexecute=optin /fastdetect c:\grldr="grub for redflag 6" 这其中的c:\grldr="grub for redflag 6" 可能与你选择的盘区有可能要改变，这得看你的grldl所在的盘区了。 其实安装红旗是很简单的。1、把isolinux中的vmlinuz & initrd.img解压到与安装文件相同的根目录下。2、在网上下载一个grub for dos，如果不好找，到我的博客loverf.cublog.cn上可以找到。3、进入dos，进入放grub for dos的分区，执行 grub4、在出来的Grub界面中输入kernel (hdx,y)/vmlinuz 回车initrd (hdx,y)initrd.img 回车boot就行了，x代表在哪个硬盘，如果只有一个硬盘，那就是0（数字）。y代表在哪个分区，C盘是1，D盘是4，E盘是5，依次推吧。分享：

linux问题（1） (2008-06-08 09:31:53) 进入图形窗口的问题"login out" 就可以回到命令行, 进入图形窗口是:＂startx＂ :loveliness:我安装的是Red Hat Linux 9（另一个系统是Windows Xp），安装时候无法进入图形界面，提示"注意：显示超出范围： H: xx KHz V: xxHz" ，然后黑屏，没有办法，只好使用文字界面安装，不过安装还是能成功的。采用grub登陆。之后进入Linux系统，在进入图形界面的时候，出现同样的提示，然后黑屏。 原因是默认显卡的驱动于显卡不符，我的显卡是GF FX5200 128M，找到驱动程序，但文件6MB多（NVIDIA-Linux-x86-1.0-5336-pkg1.run），没法用磁盘，因为我有Combo，所以，驱动程序刻在光盘上。（安装的时候参照http://www.nvidia.com/object/linux_display_ia32_1.0-5336.html） 具体解决过程： 1、在出现选择菜单时按e,然后选择第二行(kernel *那一行)再按e,在结尾处输入空格1.然后回车,按b引导. 2、出现提示符后,vi /etc/inittab把id:5:initdefault的5改成3。 （具体修改方法：用方向键找到要修改的地方，按键盘上的'Insert'，向Word编辑一样修改，之后按ESC，再按:W，然后Ctrl-z即可） 3、reboot 4、启动后用root登陆 5、把刻好的光盘放进光驱，mount /mnt/cdrom cd /mnt/cdrom 6、cp NVIDIA-Linux-x86-1.0-5336-pkg1.run \root cd /root 7、sh NVIDIA-Linux-x86-1.0-5336-pkg1.run 8、依照驱动程序的说明修改ftp://download.nvidia.com/XFree86/Linux-x86/1.0-5336/README 主要的一步如下：__________________________________________________________________________ (sec-03) EDITING YOUR XF86CONFIG FILE __ When XFree86 4.0 was released, it used a slightly different XF86Config file syntax than the 3.x series did, and so to allow both 3.x and 4.x versions of XFree86 to co-exist on the same system, it was decided that XFree86 4.x was to use the configuration file "/etc/X11/XF86Config-4" if it existed, and only if that file did not exist would the file "/etc/X11/XF86Config" be used (actually, that is an over-simplification of the search criteria; please see the XF86Config man page for a complete description of the search path). Please make sure you know what configuration file XFree86 is using. If you are in doubt, look for a line beginning with "(==) Using config file:" in your XFree86 log file ("/var/log/XFree86.0.log"). This README will use "XF86Config" to refer to your configuration file, whatever it is named. If you do not have a working XF86Config file, there are several ways to start: there is a sample config file that comes with XFree86, and there is a sample config file included with the NVIDIA driver package (it gets installed in /usr/share/doc/NVIDIA_GLX-1.0/). You could also use a program like 'xf86config'; some distributions provide their own tool for generating an XF86Config file. For more on XF86Config file syntax, please refer to the man page. If you already have an XF86Config file working with a different driver (such as the 'nv' or 'vesa' driver), then all you need to do is find the relevant Device section and replace the line: Driver "nv" (or Driver "vesa") with Driver "nvidia" In the Module section, make sure you have: Load "glx" You should also remove the following lines: Load "dri" Load "GLcore" if they exist. There are also numerous options that can be added to the XF86Config file to fine-tune the NVIDIA XFree86 driver. Please see Appendix D for a complete list of these options. Once you have configured your XF86Config file, you are ready to restart X and begin using the accelerated OpenGL libraries. After you restart X, you should be able to run any OpenGL application and it will automatically use the new NVIDIA libraries. （用vi 命令，和vi /etc/inittab一样用） 9、reboot 10、再在出现选择BOOT OS菜单时按e,然后选择第二行(kernel *那一行)再按e,在结尾处输入空格1.然后回车,按b引导. 11、出现提示符后,vi /etc/inittab把id:5:initdefault的3改成5。 12、reboot 这12部结束后，我就看到了我的图形界面了 有的地方可能写得太详细，太弱智了，不过是为了方便第一次安装和第一次接触Linux的朋友，请大虾们不要笑我。 一、安装的过程中默认语言是英文，而不是中文简体（安装过程中有两次制定语言选项，起决定作用的是第二次） 二、切换控制台，由图形转换到控制台模式：ctrl+alt+f1(同时按下3秒钟不要马上松开)。由控制台转向图形模式是：alt+f7 三、修改默认的语言项（在控制台下）：vi /etc/sysconfig/i18n中的LANG=zh_CN.GB18030(注意大小写，然后重启系统即可) 四、命令不会用，就在控制台下运行man ls就可以。（以ls命令为例）ctrl + alt + F1(F2;F3;F4;F5;F6)F7是图形界面了直到F12或者打开终端，也可以运行简单的命令分享：

linux问题（2） (2008-06-08 09:33:27) 在如何在Linux下加载移动硬盘、U盘1，登陆 　　 2，在/mnt 文件夹创建一个usbdisk目录，用来加载移动硬盘用。　　 3，检查核心是否加载USB模块　　 执行 #dmesg | grep usb　　 如果有"usb.c: registered....."信息说明模块已加载,否则需要执行: 　　 # modprobe usb-uhci 　　 # modprobe usb-storage 　　 #dmesg　　 （输出一托东西）　　 4，插入移动硬盘　　 然后查看加载结果：　　 #dmesg | tail　　 可以看到　　 。。。。　　 SCSI device sda: 19640880 512-byte hdwr sectors (10056 MB) 　　 sdb: sdb1 　　 WARNING: USB Mass Storage data integrity not assured 　　 USB Mass Storage device found at 3 　　 usb.c: USB disconnect on device 3 　　 usb.c: USB disconnect on device 2 　　　　 这里的sdb1就是USB对应的设备　　 5，执行如下命令　　 mount -t vfat /dev/sdb1 /mnt/usbdisk -o codepage=936,iocharset=cp936　　 注意命令里面sdb1和usbdisk分别是本机上USB对应设备和我们在mnt创建给USB的文件夹　　　　 一切完毕，到/mnt/usbdisk里面去看看，是不是你的U盘内容。不是的话，请仔细检查自己是否执行了以上步骤以及什么步骤出错。　　 另外如果加载不成功可能是核心不支持，这在第4步可以看到错误结果 linux内核和版本查询命令法一： 命令： uname -a作用： 查看系统内核版本号及系统名称方法二：命令： cat /proc/version作用： 查看目录"/proc"下version的信息，也可以得到当前系统的内核版本号及系统名称补充说明：　　　　／proc文件系统，它不是普通的文件系统，而是系统内核的映像，也就是说，该目录中的文件是存放在系统内存之中的，它以文件系统的方式为访问系统内核数据的操作提供接口。而我们使用命令“uname -a"的信息就是从该文件获取的，当然用方法二的命令直接查看它的内容也可以达到同等效果.另外，加上参数"a"是获得详细信息，如果不加参数为查看系统名称。在Linux系统下加载U盘或移动硬盘1.在插入U盘或硬盘之前,在命令行窗口运行:fdisk -l 命令,系统将显示目前所能识别到的硬件存储设备; 　　内容如:　　sda　　sda1　　sda2　　sdb　　sdb1　　sdb2　　等信息,其中,sda与sdb表示目前系统有两个硬盘,后面带有数字表示各个硬盘下的各区目录;　　硬盘或存储设备一般都是以sd开头.　　2.插入U盘或硬盘,再次运行fdisk -l 命令,系统将再次显示目前所能识别到的硬件存储设备,比较两次输出的不各,将发现第二次运行时会增加一些内容,;　　系统将在原来的基础上增加显示:sdc,等内容,表示新插入的U盘或 移动硬盘是挂靠在系统的sdc下.　　3.运行mount,如:　　#mkdir /mnt/usb　　#mount /dev/sdc /mnt/usb　　4.运行完毕,可以直接在/mnt/usb目录下对U盘或移动硬盘的数据进行访问或操作;　　5.想断开U盘或移动硬盘之前,运行umount命令,保证数据不会造成丢失,命令如下:　　#umount /dev/sdc分享：

基于模块化设计的嵌入式软件测试方法 此博文包含图片 (2008-06-08 09:27:34) 基于模块化设计的嵌入式软件测试方法发表时间:1970-01-01 08:00:00 来源: 责任编辑:ARM开发论坛 要害词：模块化设计　嵌入式软件　软件测试　测试方法　测试模型　数控系统 嵌入式设计已经成为工业现代化、智能化的必经之路，嵌入式产品已经深入到各行各业。嵌入式系统的专用程度较高，系统的整体继续性相对较小，为了保证系统的稳定性，软件的测试成为嵌入式开发的一个重要环节。由于嵌入式软件自身的特点，传统的软件测试理论不能直接用于嵌入式软件的测试，因此，研究嵌入式软件的测试有重要意义。１　基本概念简述 ARM １．１　模块化设计软件的设计是以一定的方法为基础的。面对越来越复杂的软件开发任务，人们提出了各种软件设计的模型。从用户需求和系统要实现的任务功能出发，把大型的软件划分为相对较小的模块。为了减少模块与模块之间的关联性，模块之间的逻辑结构相对独立，无函数的交叉调用，数据传递由全局变量完成，这就是模块化设计的基本思想。模块化设计的核心是模块的独立性，主要包括功能独立性和结构独立性，这使得软件开发的分工易于实现。软件测试是软件开发中的要害环节，基于模块化设计的软件测试模型简单，查错和纠错都易于实现。下面以单链路数据传递的软件模型说明模块化软件设计的软件测试的基本原则。在图１中，函数Ｆ（Ｘ－Ｙ）定义为软件模块Ｘ到软件模块Ｙ的接口函数，用来通过终端显示由模块Ｘ进入模块Ｙ的数据。假如模块Ｃ执行后发生错误，则由模块Ｂ和模块Ｃ的数据接口函数Ｆ（Ｂ－Ｃ）判定是否是模块Ｂ出来的数据就是错误的。假如Ｆ（Ｂ－Ｃ）不错，则证实模块Ｃ存在错误；假如Ｆ（Ｂ－Ｃ）传递数据错误，再察看Ｆ（Ａ－Ｂ）传出的数据是否错误，假如不错则证实模块Ｂ存在错误。用此依次前推孤立错误的方法，即可以很轻易地定位错误所在的模块。这就是模块化设计时软件测试的基本原则。 http://www.51testing.com/ddimg/uploadimg/20060908/1245370.jpg１．２　嵌入式系统 嵌入式系统开发有其自身的特点。一般先进行硬件部分的开发，主要包括形成裸机平台，根据需要移植实时操作系统，开发底层的硬件驱动程序等。硬件平台测试通过后，应该软件的开发调试是基于该硬件平台进行的，这同时也是对硬件平台的一个测试。整个嵌入式系统开发流程如图２所示。http://www.51testing.com/ddimg/uploadimg/20060908/1245371.jpg因此可以说，嵌入式系统的开发过程是一个软硬件互相协调，互相反馈和互相测试的过程。一般来说，在嵌入式系统软件中，底层驱动程序、操作系统和应用程序的界线是不清楚的，根据需要甚至混编在一起。这主要是由于嵌入式系统中软件对硬件的依靠性造成的。嵌入式软件对硬件的依靠性要求，软件测试时必须最大限度地模拟被测软件的实际运行环境，以保证测试的可靠性。底层程序和应用程序界限的不清楚增加了测试时的难度，测试时只有确认嵌入式系统平台及底层程序正确的情况下才能进行应用程序的测试，而且在系统测试时，错误的定位较为困难。软件的专用性也是嵌入式软件的一个重要特点。由于嵌入式软件设计是以一定的目标硬件平台为基础的、面向固定的任务进行的，因此，一旦被加载到目标系统上，功能必须完全确定。这个特点决定了嵌入式应用软件的继续性较差，延长的系统的测试时间，增加了测试费用。嵌入式软件的另外一个重要特点就是实时性。这是从软件的执行角度出发说明的，也就是说嵌入式软件的执行要满足一定的时间约束。嵌入式系统中，应用软件自身算法的复杂度和操作系统任务调度，决定了系统资源的分配和消耗，因此，对系统实时性进行测试时，要借助一定的测试工具对应用程序算法复杂度和操作系统任务调度进行分析测试。可见嵌入式软件与传统的面向对象和面向过程的软件相比有其自身的特点。针对这些特点对嵌入式软件的测试进行研究是必要的，有意义的。 １．３　嵌入式软件测试 字串8 软件测试是从经济、效率的角度出发，对软件代码进行质量、正确性保证的一个过程。软件测试是软件开发中的一个重要环节，也是软件从开发过程到应用过程的要害一环。嵌入式软件也不例外，图３给出了嵌入式软件测试的统一测试模型。软件测试逐渐成为一门成熟的学科，前人针对面向对象和面向过程的非实时软件的测试作了大量的研究，其中大部分方法可以用到嵌入式软件的测试。http://www.51testing.com/ddimg/uploadimg/20060908/1245372.jpg根据不同的指标，软件测试方法有不同的划分方法。从软件开发过程中测试所处的不同阶段可分为模块测试、集成测试和系统测试。根据是否需要运行目标代码分为动态测试和静态测试；根据目标代码的可见性可分为白盒测试（结构测试）和黑盒测试（功能测试）。在软件的测试中，每种测试方法都不是孤立的。为了最经济最有效地达到测试的目的，各种测试方法往往是互相嵌套的。例如，在软件的单元测试阶段，可以用黑盒测试和白盒测试的方法分别进行动态测试。 值得一提的是，近年来软件测试中，测试代码的覆盖率逐渐成为软件测试的统一标准，因此不管采用何种测试方法，尽可能地提高软件测试中的代码覆盖率是必需的。软件测试代码覆盖率是基于白盒测试方法的，因此，为了提高软件测试的代码覆盖率，测试人员必须清楚源代码的结构，拥有程序设计文档，以便设计测试用例使测试尽可能地覆盖程序内部结构的每条语句，提高代码的覆盖率。http://www.elecfans.com/article/UploadPic/2006-4/20064703235122.gif２　基于模块化设计的嵌入式软件四级测试流程 http://www.armforum.cn根据嵌入式系统的开发流程，为了最经济地实现系统的功能，采用自顶向下、层层推进的方法对嵌入式系统进行测试，提出了如图４所示的基于模块化设计的嵌入式软件四级测试流程。在四级测试中，本测试阶段以前的测试完成后，当发现错误时，可排队此测试阶段以前的错误，在本测试阶段内查找错误。这并不是一个绝对准确的方法，但最大限度地节了错误定位的时间。 ARM２．１　系统平台测试 字串4 这部分包括硬件电路测试、操作系统及底层驱动程序的测试等。硬件电路的测试需要用专门的测试工具进行测试。这里不再多述。操作系统和底层驱动程序的测试主要包括测试操作系统的任务调度、实时性能、通信端口的数据传输率。该阶段测试完成后，系统应为一个完整的嵌入式系统平台，用户只需添加应用程序即可完成特定的任务。 ２．２　模块测试 把大型的嵌入式软件系统划分为若干个相对较小的任务模块，由不同的程序员分别同时对其进行编码。编码完成后，把各个模块集成起来前，必须对单个模块进行测试。由于没有其它数据模块进行数据传递的支持，该阶段测试一段是在宿主机上进行的（宿主机有丰富的资源和方便的调试环境）。此阶段主要是进行白盒测试，尽可能地测试每一个函数、每一个条件分支、每一个程序语句，提高代码测试的覆盖率。由于只有单个模块正确才有整体集成的必要性，因此，单个模块测试时测试一定要充分、完整。模块测试阶段，测试用例的构造不但要测试系统正常的运行情况，还要进行边界测试。边界测试就是进行某一数据变量的最大值和最小值的测试，同时进行越界测试，即输入不该输入的数据变量测试系统的运行情况。理想的嵌入式系统是不应该由用户的信息交互导致死机的，这也是嵌入式设计的一个基本要求。因此，不论进行何种测试，系统死机都该被作为测试错误处理。在模块测试阶段，由模块化编程的基本思想，根据模块内部的紧凑程序，也可以把大的模块划分成小的模块。在程序内部，小模块之间数据传递的入口设计接口函数，用于快速地定位错误。用此模块嵌套的思想进行软件测试，需要模块内部结构清楚，数据链路简单。２．３　集成测试 ARM 单个软件模块测试正确之后，将所有模块集成起来进行测试。本阶段主要是找出各模块之间数据传递和系统组成后的逻辑结构的错误。在宿主机上采用黑盒与白盒相结合的方法进行测试，要最大限度地模拟实际运行环境，可以屏蔽掉一些不影响系统执行的和数据传递的难以模拟的函数。集成测试是模块化设计软件的测试优点充分体现的阶段。集成测试前，应该由程序员根据模块之间的数据的输入输出编写模块接口函数，这需要负责不同软件模块的程序员共同协调完成，然后将模块接口函数集成到接收数据模块的入口处。由前面的分析可知，单链路数据传递的软件模块集成测试时轻易定位错误所在的软件模块。一个软件模块的数据不一定只有另外一个模块提供，即软件模块的数据链路不一定只是单链路的，测试时可以把复杂链路结构的数据传递划分为单链路结构数据传送进行错误定位。修改输出数据的软件模块时，可能导致输入数据的软件模块引入新的错误，因此在这里引入关联矩阵确定修改某一模块后需要重要测试的模块。 假定模块化设计的嵌入式系统软件由软件模块Ａi(i=1,2,…，m,n)组成，m表示矩阵的行号，n表示矩阵的列号。图５所示的矩阵即为其关联矩阵。http://www.elecfans.com/article/UploadPic/2006-4/20064703235203.gif在关联矩阵中，Aij=1表示Aj接受了Ai输出的数据，故修改了Ai重新测试Ai的同时也需重新测试Aj。 http://www.elecfans.com/article/UploadPic/2006-4/20064703235656.gif集成测试是在拥有程序设计文档、程序结构和数据结构时，对软件模块在集成中出现的错误进行测试。集成测试时，根据模块接口函数定位错误修改代码，根据关联矩阵确定重新测试的软件模块。图６给出了模块化设计的嵌入式软件集成测试模型。 ２．４　系统测试 M开发论坛集成测试完成后，退出宿主机测试环境，把系统移植到目标机上来，完成应用到现场环境中，从用户的角度对系统进行黑盒测试，验证每一项具体的功能。由于测试者对程序内容程序执行情况一无所知，因此本测试阶段的错误定位比较困难。系统测试阶段应该进行意外测试和破坏性测试，即测试系统正常执行情况下不该发生的激发活动和人为的破坏性的测试，进一步验证系统性能。系统测试阶段不应该确定错误后立即修改代码，应根据一定的错误发生频率，确定测试周期，在每个测试周期结束时修改代码，进行反复测试；否则，不但增加了完全测试的任务量，而且降低了测试的可信度。http://www.elecfans.com/article/UploadPic/2006-4/20064703235169.gif２．５　测试结果分析 测试结果的分析可以定位错误，指导程序员修改代码，同时指出测试进行的程序并进一步指明测试方向。测试结果的分析是一个由测试结果和测试预得结果进行分析、比较和定位错误的过程。测试结果的分析是一次测试的最后环节，分析时应该考虑软件的运行环境和实际运行环境的差异以及各种外界因素的影响等。 字串4 ２．６　测试用例的构造与治理http://www.elecfans.com/article/UploadPic/2006-4/20064703235169.gif测试用例是为了测试目标程序设计的包括输入项和预得结果的一种文件，根据测试环境和测试目标程序的不同，可分为某种格式的文档或某种输入行为（如一次按键）等。测试用例的构造要尽可能覆盖所有可能的取值范围，使测试尽可能地覆盖所有程序代码，提高代码的测试覆盖率，同时又不作多余、重复和无意义的测试。在嵌入式软件测试的不同阶段，要构造不同的测试用例；在系统平台测试阶段，要构造针对系统任务调度、实时性能和底层驱动程序的测试用例；在模块测试阶段，应构造针对某一模块进行测试的测试用例；在集成测试阶段，针对系统集成时数据传递、结构斜接的问题构造相应的测试用例；在系统测试阶段，要构造针对某项功能的或多项功能结合在一起的测试用例，或使用已经在同类产品上已经验证正确的测试用例。测试用例是可复用的。此外大型的软件开发过程中，测试用例的种类繁多，应该按一定的方法进行治理。用数据库的来治理测试用例是一个很好的选择。根据测试阶段将测试用例进行划分，然后用要害字唯一确定。这样在使用、修改和保存测试用例时都很方便，直接用查询的方式就可以调出测试用例。 http://www.elecfans.com/article/UploadPic/2006-4/20064703235899.gif３　数控系统软件测试 M开发论坛本数控系统采用ＡＲＭ７处理器，操作系统采用μＣ／ＯＳ实时操作系统，是一个典型的嵌入式系统。由于数控系统较为复杂，开发过程中将任务进行了具体的划分，软件的开发采用模块化开发。模块的划分及数据流向如图７所示。 ARM开发论坛根据图７所示的软件模块和数据流向可构造关联矩阵，如图８所示。 ARM开发论坛 开发过程中，几个模块由不同的程序员分别进行编码，分别由程序员进行模块测试，并按白盒测试的方法进行覆盖测试。最后集成测试前，根据关联矩阵，程序员协作编写了模块接口函数Ｆ（A1-A2）、Ｆ（Ａ１－Ａ４）、Ｆ（Ａ１－Ａ５）、Ｆ（Ａ１－Ａ６）、Ｆ（Ｆ２－Ａ３）、Ｆ（Ａ３－Ａ４）、Ｆ（Ａ４－Ａ５）、Ｆ（Ｆ５－Ａ６）、Ｆ（Ａ６－Ａ２），然后根据图６所示的测试模型和图８所示的关联矩阵对系统进行了集成测试。分析可知，一些要害模块，如译码模块和刀补模块的测试代码覆盖率达到９０％之上。图９所示的整个系统经过系统测试之后性能稳定，图１０为其加工的零件，目前该系统已经小批量生产。４　结论 http://www.elecfans.com/article/UploadPic/2006-4/20064703235405.gif嵌入式软件的特点和传统的测试方法作了分析之后，提出了四级测试流程和集成测试的模型。此测试方法用于工程机械控制器和数控系统开发的测试。测试的效率和可靠性满足要求。文中的单链路数据传递的错误定位、模块接口函数、关联矩阵等方法也可以用于面向对象的和面向对象的软件系统。

Xilinx XST与Synplify综合结果差异分析（2） 此博文包含图片 (2008-06-08 09:25:15) 本文小结 http://www.eefocus.com/data/07-07/9143_1185687957/1185688341.gifXST与Synplify综合结果差异分析（2）" TITLE="Xilinx XST与Synplify综合结果差异分析（2）" /> 通过前面的分析，我们发现造成XST与Synplify的综合结果不一致的原因在于作者错误使用了锁存器结构。为了加强读者对“代码风格”、“综合后仿真”、RTL视图等概念的理解，在此引申谈一下上述问题。综合后仿真的概念与作用综合后仿真的最主要作用在于验证综合器的综合结果是否与设计意图一致。仿真时，把综合生成的延时文件反标到综合仿真文件中去，可估计逻辑门延时带来的影响。该仿真只能估计门延时，而不能估计线延时，仿真结果与布线后的实际情况还有一定的差距，并不十分准确。有些设计工程师认为综合器是永远可靠的，综合出的电路应该与设计意图一致，综合后仿真与功能仿真结果一致。这种观点是错误的，只要当代码风格合理，不出现让综合器误解的描述时，综合结果才会和设计意图完全一致。在一般情况下建议不要省略此步骤。代码设计风格对设计的影响在学习逻辑设计之初，老师总是强调代码风格的重要性。有些设计工程师认为现在综合器的优化功能越来越强，对大部分设计都可以优化。这种观点是不对的，综合器的优化结果主要是依靠设计工程师的代码风格。设计风格对综合结果的影响可以用一句话概括：“好的代码设计风格会使综合器事半功倍，达到最优的综合结果；不好的代码设计风格会使综合器南辕北辙，产生错误的综合结果。”本文的实例的所有问题都源于其代码风格不尽合理，而并不在于综合器。图7：是XST的RTL视图。 http://www.eefocus.com/data/07-07/9143_1185687957/1185688368.gifXST与Synplify综合结果差异分析（2）" TITLE="Xilinx XST与Synplify综合结果差异分析（2）" />状态机设计方法。状态机的设计方法很多，描述方法不一而同，目前如StateCAD等状态机辅助设计软件给用户提供了很多的帮助。这里需要强调的是在状态机的设计中使用条件判断语句一定要慎重，尽量使用“if...else”这种完整的判断结构。有时判断语句使用不合理，会造成综合器对设计的误解，不同的综合器的默认综合结果会因为是否使用了锁存器，是否使用了带有优先级的编译码器等结构而不同。一些有用的辅助分析工具。FPGA/CPLD等可编程逻辑器件的长足发展在一定程度上就是因为其EDA辅助设计工具的智能化、易学易用、功能强大等优势。在本例分析综合结果的过程中，并未直接分析综合器的输出网表，而是使用了RTL视图进行分析，直观、快捷，提高了分析效率。 作者：王诚，钟信潮，吴蕾 中兴通讯公司 薛小刚 如何解决XST与Synplify的综合结果不一致的问题在同步状态机设计中使用锁存器也会带来时序、稳定性等多方面的问题，而且在综合优化参数不一致的情况下，不同综合器对锁存器的综合结果有可能不一致。本文通过分析相同状态机在XST和Synplify下综合结果不同的实例，进一步阐述了这个观点。 一位同事所设计的状态机使用Synplify综合和XST(Xilinx ISE内嵌的综合工具)综合的结果不一致，对Synplify的综合结果以及布局布线后上板调试完全正确，而对XST的综合结果布局布线后上板调试发现了错误，因此认为XST的综合结果有误，并对为什么XST综合会出现错误结果产生疑问。 在帮助他解决这个疑问后，我发现其中涉及的许多问题很具代表性，希望通过对这个问题的分析能对设计工程师的实际工作有指导意义。 下面是这位同事设计的状态机源代码： 状态转移图 该同事设计的是一个数据通讯中同步接收装置的状态机：当“Reset_b”复位后，进入“DROP”状态；当接收指示信号“RXDV”有效后，从“IDLE”状态进入接收前缀信号状态“PREAMBLE”；当控制信号“RxDEQ5”有效后进入“SFD”状态接收一些指示关键字；当控制信号“RxDEQ”有效时，进入数据接收状态“DATA0”；接收完“DATA0”后接收“DATA1”，直到接收指示信号“RxDV”无效，返回到“IDLE”状态。其状态转移图如图1所示。 竞争冒险 粗略地读一下代码就发现一处问题，状态“DATA1”执行的代码有“竞争冒险”。该段为： 当前状态为DATA1，且“RxDV”为低电平的时候，NextState到底是什么？是IDLE还是DATA0？这是一处比较明显的竞争冒险，不同的综合器会综合出不同的逻辑结构，而且会出现毛刺。造成这个错误的原因是在使用if语句的时不慎重，这类问题是比较常见的问题。根据前面状态转移图描述的设计意图，修改为： 在消除竞争冒险后，再作综合后仿真，比较更改前后综合后仿真的结果。图2为该同事在更改“竞争冒险”前后，综合后仿真波形示意图。从综合后仿真波形可以看出，更改“竞争冒险”后XST的综合结果有了改进，但是仍然不符合设计要求。 锁存器的使用 为了验证综合后仿真结果，本人用相同的测试激励，在ModelSim中对修改了“竞争冒险”的代码进行功能仿真、XST综合后仿真、Synplify综合后仿真，综合时所用参数为默认参数。 从仿真波形可以看出，两种综合后仿真波形的最大差异在于“RxDEQ5”信号有效后状态转移的情况不同：Synplify的综合结果，在“RxDEQ5”信号有效期间锁存了状态“2”；而XST的综合结果，在“RxDEQ5”信号有效期间并未锁存状态“2”。这时再次分析代码，观察代码中大量使用的锁存器是否符合设计需求(当初认为是作者的设计意图)。原设计中在状态“IDLE”、“PREAMBLE”、“SFD”的转移条件中都使用了如下的命令格式： if(某转移条件) NextState<=某状态； 这种描述方法常会被综合器综合成锁存器结构，而在设计准则中我们常说“同步时序设计最好不要使用锁存器”。在同步状态机设计中使用锁存器也会带来时序、稳定性等诸多方面的问题。而且在综合优化参数不一致的情况下，不同综合器对锁存器的综合结果有可能不一致。XST与Synplify是否因为该问题造成的综合结果不一致呢？带着这个问题，我们分析XST和Synplify的综合结果。 分析综合结果的方法多种多样，我们可以直接打开综合输出的网表文件，观察逻辑网表的连接。但是更为方便的分析方法是使用RTL视图(寄存器传输级)分析综合结果。 Synplify Pro的RTL View是对源代码编译结果应用B.E.S.T技术再现的寄存器传输级原理图。该图高度抽象为模块化结构，帮助用户理解源代码对应的具体电路结构，检验设计的正确性。Xilinx的FPGA/CPLD设计平台ISE也提供了功能相似的RTL视图工具，可以使用ECS(原理图编辑器)观察XST的综合结果。 图6是Synplify的RTL视图，观察到状态转移变量“NextState”被综合成了锁存器(锁存器)。 图7是XST的RTL视图，其中状态转移变量“NextState”条件判断部分被综合成了组合判断电路，而不是锁存器。 从XST和Synplify的状态转移图可以清晰的看到，两种综合工具在默认参数条件下对“IDLE”、“PREAMBLE”、“SFD”等状态的转移条件的综合结果不一致，故而导致了综合后仿真波形的不同。Synplify将这些状态转移条件综合为锁存器，而XST却综合为组合逻辑判断电路，未使用锁存器资源。 但是我们并不能因此说XST综合器的综合结果是错误的，该综合器不可靠。这里两种综合结果有差异的根本原因在于作者的代码风格不合理。作者在同步状态机描述中使用了大量不完整的条件判断语句，而XST在默认参数条件下尽量避免使用锁存器，而通过组合逻辑判断实现状态转移。当然我们也可以通过设置XST参数，使XST将上述代码描述也综合为锁存器。但是好的同步时序设计要尽量避免使用锁存器，这里使用锁存器好像电路功能正确了，但是有很多隐含的错误。请读者思考一下，进入“PREAMBLE”状态后，如果“RxDV”变低将会出现什么情况？同理，进入SFD状态后，条件不满足呢？这时发生的状态转移未必是作者的设计意图。总之，使用锁存器造成的后果是状态机不健壮！ 解决方法 解决上面的问题很简单，只需根据设计意图将“IDLE”、“PREAMBLE”、“SFD”等状态的转移条件进行改写，将不完整的“if”条件语句改为“if...else”条件语句即可。如下所示： List4 作者提供的源代码在经过修改“竞争冒险”和“锁存器”两类问题后，XST和Synplify的综合结果的仿真波形完全一致，都符合了设计意图。 本文小结 通过前面的分析，我们发现造成XST与Synplify的综合结果不一致的原因在于作者错误使用了锁存器结构。为了加强读者对“代码风格”、“综合后仿真”、RTL视图等概念的理解，在此引申谈一下上述问题。综合后仿真的概念与作用综合后仿真的最主要作用在于验证综合器的综合结果是否与设计意图一致。仿真时，把综合生成的延时文件反标到综合仿真文件中去，可估计逻辑门延时带来的影响。该仿真只能估计门延时，而不能估计线延时，仿真结果与布线后的实际情况还有一定的差距，并不十分准确。有些设计工程师认为综合器是永远可靠的，综合出的电路应该与设计意图一致，综合后仿真与功能仿真结果一致。这种观点是错误的，只要当代码风格合理，不出现让综合器误解的描述时，综合结果才会和设计意图完全一致。在一般情况下建议不要省略此步骤。代码设计风格对设计的影响在学习逻辑设计之初，老师总是强调代码风格的重要性。有些设计工程师认为现在综合器的优化功能越来越强，对大部分设计都可以优化。这种观点是不对的，综合器的优化结果主要是依靠设计工程师的代码风格。设计风格对综合结果的影响可以用一句话概括：“好的代码设计风格会使综合器事半功倍，达到最优的综合结果；不好的代码设计风格会使综合器南辕北辙，产生错误的综合结果。”本文的实例的所有问题都源于其代码风格不尽合理，而并不在于综合器。状态机设计方法。状态机的设计方法很多，描述方法不一而同，目前如StateCAD等状态机辅助设计软件给用户提供了很多的帮助。这里需要强调的是在状态机的设计中使用条件判断语句一定要慎重，尽量使用“if...else”这种完整的判断结构。有时判断语句使用不合理，会造成综合器对设计的误解，不同的综合器的默认综合结果会因为是否使用了锁存器，是否使用了带有优先级的编译码器等结构而不同。一些有用的辅助分析工具。FPGA/CPLD等可编程逻辑器件的长足发展在一定程度上就是因为其EDA辅助设计工具的智能化、易学易用、功能强大等优势。在本例分析综合结果的过程中，并未直接分析综合器的输出网表，而是使用了RTL视图进行分析，直观、快捷，提高了分析效率。 作者：王诚，钟信潮，吴蕾，中兴通讯公司，薛小刚，Email: wang.cheng@zte.com.cn