排名前十的验证忠告

排名前十的验证忠告

1.这是遗留下的代码，所以不用验证
-小心！你能 100%保证你面对的是经过硅验证的代码吗？你能保证没有在上次工作之后
没有任何人碰过这代码吗？

2.我可以在 5 分钟内就把补丁加上
-只要你能保证你的验证环境不像是一大堆补丁堆在一起形成的，这样做到也可以。但
是想一下从今天起用一周时间来修改和修正你的验证环境是一件容易的事吗？难道多用几
分钟时间来写一个更健壮的代码不是更好吗？

3.随心所欲地计划和开始测试
-这是大大地错了！即使你的工作是小菜一碟你也要提前做好计划。你会惊讶地发现可
以避免多少无谓的问题。铭记 5 个 P:合适的计划排除差的性能。(proper planning prevents
poor performance)

4.这工作很简单，不必作测试计划
-将测试计划当作你的工作合同。你加入其中的定义了你当前所要做的工作，如果工作
真的很简单，就用半页纸把测试计划写下来。

5.验证不是产品，所以不必遵循软件标准
-验证的确不是产品，但是你仍需处理数千行的代骊，所以你最好可以确保一定程度的
一致性，更不用说可能存在代码错误的可能了。

6.别花时间在写注释上
-还记得最近一次你花费半天时间在反向研究别人的代码上吗？那么对于你自己写的代
码呢？更好的做法是，在开始每个测试前，保证代码中有足够的注释解释程序步骤，并要保
证注释的更新。

7.我知道了！让我们从外部强制这个信号的值就 OK 了
-强制的信号值往往会在整个流程中被遗忘，并在最后阶段才被发现，这时通常只有一周就
tapout 了！所以要极端的小心。

8.必须在后台一直运行回归运行(regression running)
-单纯的回归运行不能完成所有工作。你必须有一个分析人员(Regression Sitter)来监
视和分析运行结果-否则就是在白白磨损服务器！

9.我们己经实现了 100%的覆盖率真，所以没有必要再运行更多的测试了！
-实际上并不是这样。你的覆盖率模型只能捕捉到你提前想到的东西。很明显随机测试
平台可以产生能揭示出 bug 的额外情景。所以不要在 100%时停止。相反，要在这时加强覆
盖率模型。

10.验证应该寻找 bugs-这是一个很普遍的对验证工作的误解。验证者应该将注意力放在建立一个构建得很好的，强健和完整的测试平台上。bugs 将会自己被检测出来。

OpenRisc1200初解（四）

Debugging of Physical OpenRISC Targets

轉貼自http://opencores.org/openrisc,debugging_physical

Introduction

Physical implementations of OpenRISC systems can be debugged using a set of tools made available here at OpenCores.org. Whether simply poking registers in IP cores or debugging complex software executing on the processor, these tools provide a useful debugging capability. This section will outline how to setup the required tools, and perform debugging on a physical OpenRISC target.

胡錦濤對兒子胡海峰的告誡

管它是誰說的，至理良言是真的！      

說話要用腦子，做事慎言，話多無益。講話不要只顧一時痛快。信口開河，以為人家給你笑臉就是欣賞，沒完沒了的把掏心窩子的話都講出來，結果讓人家徹底摸清了家底，還偷笑你。

遇事不要急於下結論，即便有了答案也要等等，也許有更好的解決方式，站在不同的角度就有不同答案，要學會換位思維。

對小人一定要忍讓，退一步海闊天空，實在不行把屬於自己的空間也丟給他們，讓他們如鶯燕舞般陶醉吧.大人大度量.惹著小人就等與惹了麻煩，所以要敬而遠之.

這世道沒有無緣無故的愛，也沒有無緣無故的恨，不要參與評論任何人，做到心中有數就可以了。誰也沒有理論依據來界定好人與壞蛋，其實就是利益關係的問題.

做事情一定要事先設立道德底線，小偷也清楚有些東西是絕對不能偷的。所以說事情萬萬不可做絕，落井下石的事絕對不要幹，給人方便給已方便.

對於那些經常找你麻煩甚至欺負你的人，能忍則忍，沒必要時刻與莽夫過不去。但一定要給他攢著，新仇舊怨積累起來，正義和真理就屬於你了，那麼瞅准機會一定要徹底教訓他一次，在法律賦予的許可權以內，往死裡揍，讓小子永遠記住:除了你爹，沒人會慣你這些臭毛病.

明槍易躲，暗箭難防，背後算計你的小人永遠不會消失，這是中國特色。小人不可得罪，同樣小人也不可饒恕，這是萬世不變的真理。說到底小人也有心小的一面，對待這種人要穩准狠，你可以裝做什麼也沒發生，天下太平，萬事大吉，然後來個明修棧道，暗渡陳倉，以毒攻毒。讓小子知道:小人也不是誰都可以做的，做好人要有水準，做小人同樣有難度.

對待愛你的人一定要尊重。愛你是有原因的，不要問為什麼。接受的同時要用加倍的關愛回報。但是千萬不要欺騙人家的感情。愛是最珍貴的財富，這是你用錢買不來的財富。不要讓事業上的不順影響家人，更不要讓家庭的糾紛影響事業。那樣做很不划算，家人和事業都受影響，甚至損失。男人要善於扛事，要把眼淚咽下去。記住:輕視人家付出的情感就等於蔑視自己；玩物喪志，玩人喪德，愛人是一種美德。

背後誇獎你的人，知道了要珍藏在心裡，這裡面很少有水分。當面誇獎你那叫奉承，再難聽些叫獻媚，你可以一笑而過，就當什麼也沒發生。也許不久就有求於你，對於那種當眾誇獎你的人，就疏忽不得了。也許你轉過身去，就用指頭戳你。掌握一條原則：逢人多貶自己，少誇別人，選先評優的時候除外。

有些人習慣了占你小便宜，小人小肚腸，大人大度量，有機會坑他一把大的，出一次大血。同樣讓他記住：天下根本就沒什麼免費的午餐，哪有白揀的便宜讓你賺。小恩小惠攢多了就是一個大窟窿，只要接受就一定要找機會回報。行下春風望夏雨，付出就是為了收穫，其實就是一個簡單的種子與果實的關係。千萬別讓天真給害了。記住：人生如戲，都在尋找利益的平衡，只有平衡的遊戲才有可能玩下去.

患有心理疾病的人是不負法律責任的，可以沒有理由的咬你一口。所以對待瘋狗級的人物要敬而遠之，保持不來往，不交流。退一步，海闊天空，相信瘋狂也是一種人格，雖不值得尊重，但自有其存在的道理，生物鏈少不了這一環.

做一個人生的觀光客吧，說到底只要與人為善，以德服人，離是非遠點，靠家人近點，便有了心安，有了愜意。樂觀的心態來自寬容，來自大度，來自善解人意，來自與世無爭。壞心情是失眠時折磨出來的，其實現實並沒有你想的那樣糟糕，生命有高峰也有低谷，根本沒有一帆風順的人生，鄧小平怎麼樣？三起三落，最後還不是凡事他說了算.

所謂的緣分無非只有善惡兩種。珍惜善的，也不要絕對排斥惡的。相信擦肩而過也是緣吧，全世界近60億人口，碰上誰也不容易，所以遇到惡緣，也要試著寬容，給對方一次機會，不可以上來就全盤否定。

待人接物要擺正自己的位置，不可以老把自己當人物，老拿自己當領導，老把自己當富翁，老以為自己是情聖，老是自我感覺良好，即便真是小有作愚。其實人的最終結局都是一樣的，只是你把自己看複雜了，說句俗話：千萬別把自己當回事。

OpenRisc1200初解（三）

如何去build GCC 4.5.1 for OpenRISC version 1.0 release candidate 1

首先要確認library中有 GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+.


先下載gcc-4.5.1-or32-1.0rc1.tar.bz2


然後解壓縮

進入目錄後使用./configure

可以確認各種狀況

GNU Multiple Precision Library (GMP) version 4.3.2 (or later)

Necessary to build GCC. If you do not have it installed in your library search path, you will have to configure with the --with-gmp configure option. See also --with-gmp-lib and --with-gmp-include. Alternatively, if a GMP source distribution is found in a subdirectory of your GCC sources named gmp, it will be built together with GCC.

MPFR Library version 2.4.2 (or later)

Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The --with-mpfr configure option should be used if your MPFR Library is not installed in your default library search path. See also --with-mpfr-lib and --with-mpfr-include. Alternatively, if a MPFR source distribution is found in a subdirectory of your GCC sources named mpfr, it will be built together with GCC.

MPC Library version 0.8.1 (or later)

Necessary to build GCC. It can be downloaded from http://www.multiprecision.org/. The --with-mpc configure option should be used if your MPC Library is not installed in your default library search path. See also --with-mpc-lib and --with-mpc-include. Alternatively, if an MPC source distribution is found in a subdirectory of your GCC sources named mpc, it will be built together with GCC.



其實還需要升級GLIBCXX　到　3.4.9
請參考另一篇文章

所有的library都完成升級後
configure才會過

這樣就可以完成使用make來作build的工作了

make
make check (如果有錯，可忽略)

CentOS5 Linux 升級 glibc庫到2.7以上

CentOS5 Linux需要升級 glibc庫要2.7以上，所以就嘗試了下升級glibc。

由於找不到CentOS5的 glibc2.7 ，就在網上找到了fedora的rpm包來替代，試過暫時是沒發現什麽問題。以下是步驟。

http://rpm.pbone.net這裏下載相應的rpm包

由於我們目前linux都是64位系統，所以我下載4個x64文件：
glibc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm

然後升級的命令為：
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm

直接強制更新升級。

參考來源http://szypanther.blog.hexun.com.tw/60622860_d.html

OpenRisc1200初解（二）

下載openrisc的toolchain

可到http://opencores.org/openrisc,gnu_toolchain

 最簡當的方法就是直接對http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src/
用SVN來checkout

就可得到所有的openrisc toolchain的source file


如果需要The source for uClibc and Linux
 就用git來下載

uClibc and Linux kernel source

git clone git://git.openrisc.net/jonas/uClibc
git clone git://git.openrisc.net/jonas/linux

驗證計畫(十三)

验证计划小結

1. 验证计划是对所有测试用例和所支持的测试平台功能的验证规范。实现和验证
源自共同的规范。不要去验证一个实现。

2. 定义验证设计所用的不同层次的粒度：模块、单元、组件、FPGA、ASIC、子系统、板级
系统。为了更少地测试平台和更高集成度的测试，要在可观测性和可控制性之间做出平衡。

3. 定义能够检测错误的自检验策略。

4. 从设计规范确定功能，并列举哪些功能要验证。(function items)

5. 在设计阶段就要考虑验证。构建设计使之尽可能易于验证。(modify design for verification)

6. 如果测试用例的数量很少，可以使用直接的测试平台方法。对于每个功能，使用一个测试
用例。用单独的测试平台实现每个测试用例。

7. 从列举的功能里定义一个功能覆盖模型。从那些相同的功能里确定生成器所需的自由度和
约束度，以便生成验证每个功能所要的激励。

OpenRisc1200初解（一）

在http://opencores.org/download,or1k
下載了Or1ksim 0.4.0 stable release

然後到centos4.8及5.7中去作make的動作

依照文件上的說明
tar  jxf  or1ksim-0.4.0.tar.bz2
mkdir  builddir_or1ksim
cd  builddir_or1ksim

../or1ksim-0.4.0/configure  --target=or32-uclinux

make  all

結果產生錯誤
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../cpu/or32 -I.. -I../cpu/common -I../cpu/or1k -I../cache -I../mmu -I../bpb -I../peripheral -I../tick -I../peripheral/channels -I../pm -I../pic -I../debug -I../vapi -I../support -I../cuc -I../port -I../argtable2 -g -O2 -g -Wall -Werror -O2 -DOR32 -MT rsp-server.lo -MD -MP -MF .deps/rsp-server.Tpo -c -o rsp-server.lo rsp-server.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../cpu/or32 -I.. -I../cpu/common -I../cpu/or1k -I../cache -I../mmu -I../bpb -I../peripheral -I../tick -I../peripheral/channels -I../pm -I../pic -I../debug -I../vapi -I../support -I../cuc -I../port -I../argtable2 -g -O2 -g -Wall -Werror -O2 -DOR32 -MT rsp-server.lo -MD -MP -MF .deps/rsp-server.Tpo -c rsp-server.c -fPIC -DPIC -o .libs/rsp-server.o
cc1: warnings being treated as errors
rsp-server.c: In function ‘rsp_remove_matchpoint’:
rsp-server.c:2233: warning: dereferencing type-punned pointer will break strict-aliasing rules
rsp-server.c: In function ‘rsp_insert_matchpoint’:
rsp-server.c:2313: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[2]: *** [rsp-server.lo] Error 1
make[2]: Leaving directory `/home/strongleg/Project/OpenRISC/or32-build/or1ksim-0.4.0/debug'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/strongleg/Project/OpenRISC/or32-build/or1ksim-0.4.0'
make: *** [all] Error 2


根據
http://opencores.org/bug,view,1735
的說明
The last error here relates to or1ksim-0.4.0, the latest toolchain install script is using or1ksim-0.5.0rc2 and I'm quite sure these warnings have been resolved.

因此改下載
Or1ksim 0.5.0 release candidate 2

然後照上面的步驟在centos4.8上再作一次
make all　　--> 沒有錯誤
make check  --> 還是有錯，不與理會
make install  --> 在root下成功安裝　 or32-uclinux-sim
 
初步成功 

在centos5.7-64bits上再作一次 
也一切無誤

最後使用root帳號
make install 安裝 

安裝後產生三支執行檔
or32-uclinux-mprofile  
or32-uclinux-profile  
or32-uclinux-sim

在
/usr/local/bin

還有
or1ksim.a
or1ksim.so
在/usr/local/lib


or1ksim.h
在/usr/local/include




 

驗證計畫(十二)

测量进度

解决方法是根据功能覆盖点来测量进度，这些功能覆盖点可以确定一个功能是否被验证
过。这样，验证的目标变为填满设计的功能覆盖模型而不是编写一系列的测试集。你可以用很
大的直接的测试平台来填满这个覆盖模型，或者可以让一个随机的测试平台生成测试集替你验
证功能。

用带有随机测试平台的覆盖驱动方法进行测量的进度和传统的直接方法
测量的进度。前者的测试平台的初始开发时间较长，但长时间运行时的功能覆盖率更高。

直接的测试用例只能发现你想要查找的错误，而随机仿真可以生成一些在写验证计划时
未曾想过的条件。它们可以生成意想不到的条件。它们也可以减少验证工程师在编写直接的测
试平台时引入的偏差。代替生成很容易编码的输入序列，它们生成更符合实际的激励。由于设
计会在相当多的条件下进行验证（在同样的时间里相对于直接的方法来说），设计整体的质量
会更高。

使用约束驱动的方法需要约定。在进度压力下，很容易回去写直接的测试集。这种方法的
一个关键部分是需要对测试平台和设计进行仿真，以弄清楚已经完成了多少功能覆盖。如果
RTL 模型没有准时完成（它往往不能准时完成），要怎样调试自检验的随机测试平台呢？怎样
知道验证团队正在向它的功能覆盖目标前进呢？最简单的解决方法是开始把测试用例编写成直
接的伪随机的测试平台，毫无疑问它可以填充功能覆盖点。那会使你又回到楼梯曲线。更好的
方法是尽可能早地交付RTL、开始仿真并使用行为级模型。

 在覆盖驱动的方法中，功能覆盖测量用于确认哪些测试用例被执行了，而不是直接编写那
些测试用例。因此，实现功能覆盖模型并从一开始就收集功能覆盖率是很重要的。
功能覆盖从项目的一开始就用来记录哪些测试用例和条件被随机发生器自动生成
了。如果没有把功能覆盖和随机环境联合使用，那恐怕仅是在用随机激励做直接的测试用例。

每种功能都会在输入数据流、设计的配置或必定要经过的设计内部状态中体现出一种特性
或征兆。功能覆盖必须确认并记录那些特性和征兆。

只有明确地定义了目标，功能覆盖工具才能测量进度。它也会使功能覆盖分析更容易。进
度会以一个不变的目标进行测量。如果每次分析功能覆盖报告时目标被智能地定义，那么这些
目标属于人为的错误。因为你会下意识地把进度与迫近的截止日期进行比较，因此在项目快结
束时有一种要减小验证缺口的重要性的趋向。

理解目标的复杂性
不要让你的目标比需要的更准确。如果为了实现目标需要设定的值越多，你的工作就越
多。由于交叉覆盖，要设定的值的数目会成指数地增长。

收集大量的功能覆盖数据是很容易的。但是掌握的功能覆盖数据越多，分析结果就越困
难。总是需要询问适当的功能覆盖点。如果打算忽略一些覆盖报告或不再关注以后的报告，就
不该收集它。数据和信息之间有本质的区别。任意的功能覆盖点仅仅提供要分析的数据，而仔
细选择的功能覆盖点和精心定义的目标可以马上提供有意义的信息。

功能覆盖的定义是一种还在发展的艺术
为验证计划开发好的功能覆盖模型是不容易的。本节概要讨论了必要的步骤。功能覆盖模
型是一个可以并且应该被发展的明确定义的科学话题，需要一整本书来讨论它。

驗證計畫(十一)

檢驗测试平台的可靠度

如何验证测试平台是按照验证计划实现的
验证工作和编写测试平台的目的是为了验证设计能够满足设计规范的要求。如果验证计划
是验证工作的说明，如何確認测试平台是按照它们的说明实现的？如何防止由于人为的错误而
错过了相当一部分测试用例？测试平台经常包含一些临时代码结构来跳过测试平台的很多部分
以加速关键部分的调试。如何确定测试平台的哪些部分已经被去掉了，测试平台实现了它应该
包括的所有测试用例吗？

1. 通过人工的检查来验证测试平台
一种验证人为的变换（在这里指根据规范编写成测试平台）的方法是提
供冗余。一旦测试平台完成，它就要被其他验证工程师重新检查以确保测试平台实现了它应该
包含的所有测试用例。仿真输出的日志也应该被重新检查以确认测试平台是按照规范执行的。为了达到这样的效果，测试平台应该产生规则的报告，表明什么样的激励正在生成，什么样的错误和响应被检查到了。输出日志应该最终总结说明被执行过的测试用例。

這樣作是否真的可以完整的檢測，我是很懷疑的

2. 使用功能覆盖
另外一种冗余的方式是功能覆盖测量。通过功能覆盖模型，可以指定一个直接的测试用例
要完成的事，可以明确地了解测试用例执行的情况。在直接的测试平台运行以后，功能覆盖机
制应该 100％地满足目标。由于激励是手工编码的，它是确定的并100％地覆盖了相关的和感
兴趣的值。比如，一个测试用例要使某一特定的配置寄存器重复所有可能的值，这个测试用例
可以通过记录所有写到配置寄存器指定地址的值来覆盖。

Function items的定義需要仔細及完整的制定才有意義。

驗證計畫(十)

 测试例設計上的分组

把有相似验证需求的功能分为一组
功能分组是很自然的。一些功能需要相似的配置、粒度或验证策略来进行验证。为了最大
化生产效率，这些功能应该被分到同一组，并分配给同一位验证工程师。例如，所有和CPU接
口有关的功能应该被分到一起。不論是直接或隨機的測試力設計皆需要依照測試的功能來分組，

分組的方式如下


1. 功能清单中的交叉引用
每个测试用例应该有一个标签和对目标的一小段描述。描述应该包括测试用例中已验证功
能的清单。功能的清单应该链接到验证这个功能的测试用例。如果一个功能没有指向一个测试
用例的交叉引用，那么这个功能就没有验证。

2. 定义从属关系
对测试用例的描述应该包括被认为可操作并功能正确的功能的清单。依靠它们的从属关
系，可以决定测试用例编写的顺序，并确认在测试平台开发中是否有并行的机会。

3. 指定测试用例的激励
必须描述测试用例激励的顺序和特性。例如，要描述必须进行的各种操作或总线周期。用
随机数据或随机事务来填充所有不相关数据或背景数据是个好方法。

4. 指定可接受的准则
除了期望的响应，测试规范还必须说明如何判定响应是正确的。这包括期望的值、时序和
协议。例如，路由包处理器的输出的目标地址如果和它显示的输出端口是匹配的，那就可以判
定是正确的。或者可以用一些更严格的判定方法，例如，不同来源的包以一定的顺序排列并以
一定分布交织排列。

5. 指定要查找的错误
一种更直接的描述可接受准则的方法是描述要查找什么样的错误。例如，确认一个包有正
确的 CRC 校验值。另一个例子是描述不能同时发生的事件，如FIFO 中 full 标志和 empty 标志
的置位。直接描述要查找的错误可以让一个不太熟悉设计的验证工程师实现高度可靠的测试
平台。


6. 注入错误以确定它们被检测到
永远不要相信一个不生成错误信息的测试平台。每个测试用例应该包括一些错误注入机制
来确保测试平台可以发现并且报告错误。缺乏错误信息可能会成为测试用例的一个失败条件。
比如，一个用于验证串口奇偶位生成的测试用例应该能故意错误地配置奇偶位，以确保测试平
台能够检测到一个错误的奇偶位。当然，测试平台不能一发现错误信息就退出仿真。

7. 为每個分组的测试用例分配一名工程师
不管测试用例是如何分组到测试平台的，每一分组测试用例应该分配给一名验证工程师。同
一组测试用例有相似的实现需求。它们可以在同组中前一个测试用例的实现基础上完成。第一
个测试平台要花费最长的时间来完成。但是随着负责每组测试用例的工程师的经验增长和对基
础结构验证的调试，很多工作可以被重复使用。在接下来的测试平台中，只要剪切复制就可以
完成工作。每个测试平台被分配的人员名字应该被记录在验证计划中。那个人根据验证计划的
规范文档负责完成测试平台。

常見的sfk檔的出處

在一些linux上需要作破解動作的輔助執行檔sfk

其出自於
http://stahlworks.com/downloads.html

我們一般叫它為瑞士刀

加上一些shell script就可以作一些破解的動作了