精华内容
下载资源
问答
  • 对Unity中的线程的一些理解

    千次阅读 2018-04-26 19:55:36
    当然,线程也能实现,但是同步问题比较麻烦,会加大编程难度。Unity中有大量的异步机制,比如:异步加载资源,异步加载场景。SceneManager.LoadSceneAsync("xxx"); 这段代码就是异步加载场景。(异步...

    大多数游戏引擎都是单线程的,Unity也不例外。
    为什么使用单线程,原因主要为:

    游戏中画面更新和逻辑更新的时间点必须有确定性,必须严格按照帧序列进行同步。当然,多线程也能实现,但是同步问题比较麻烦,会加大编程难度。


    Unity中有大量的异步机制,比如:异步加载资源,异步加载场景。

    SceneManager.LoadSceneAsync("xxx");  这段代码就是异步加载场景。(异步加载场景一般是在一个loading场景中进行,加载完成后再转换到异步加载好的场景中)

    那么Unity中的异步加载是不是用多线程实现的呢?

    答案不是,Unity中异步加载机制使用的协程来实现(对于协程和线程的具体分析,将在其他部分)。协程并不是线程,协程也是在Unity主线程中被调用的,调用的时机和次数,程序员可以通过编码确定。

    那么在Unity中能不能使用多线程呢?

    我在Unity中第一次用到多线程,是在学习客户端和服务器端Socket通信的时候,在建立socket连接之后,在客户端,使用了
    BeginReceive这个方法(具体分析在其他部分),这个方法是在System.Net.Sockets中定义的。使用这个方法不用手动开启线程,这个方法使用的线程是用C#线程池实现的。

    在Unity中合理的使用多线程,可以提高CPU的利用率
    那么在哪些场景下才是合理的在Unity中使用多线程呢?

    1.网络通信。
    2.需要处理复杂算法的计算时。
    3.复杂密集的I/O操作。
    4.Unity3D的NativePlugin中可以新建子线程。通过NativePlugin可以接入移动端iOS与Android中的成熟库,可以是Objective C, Java, C++三种语言交叉混合的方式组成NativePlugin,然后使用Android或者iOS的SDK开辟子线程。(这里的知识我是直接复制别人的参考博客:https://www.cnblogs.com/yangxiaohang/articles/6505302.html,我并不是很了解,以后学习到的时候再补充。)

    使用多线程时有一些限制:
    1.UnityEngine中的API对象不能在子线程中使用。
    2.UnityEngine总定义的基本数据结构可以使用,(如float,int,struct可以使用)。而texture2d不可以,因为它是根父类是UnityEngine.Object。
    简单来说,就是不是画面更新,不是常规的逻辑更新。

    这是我参考许多前辈的心得,加上自己理解写的,肯定有很多不足,欢迎指出错误。在我学习深入,有所得之后,我也会逐渐完善这些内容。






    展开全文
  • 我们知道在线程编程中,我们很大的一部分内容是为了解决线程间的资源同步问题和线程间共同协作解决问题。...本篇文章的重点不在此,也不是在此一下子能分析完,我们先从Java JVM的角度来理解多线程的一些方面。

        我们知道在多线程编程中,我们很大的一部分内容是为了解决线程间的资源同步问题和线程间共同协作解决问题。线程间的同步,通俗我们理解为僧多粥少,在粥有限情况下,我们怎么去防止大家有秩序的喝到粥,不至于哄抢都没得喝。线程讲协作,我们可以理解为我们在医院看病的时候,我们要先挂号,才能看病。现在医院有很多病人排队,怎么协调病人都有秩序的先挂号,后看病。本篇文章的重点不在此,也不是在此一下子能分析完,我们先从Java JVM的角度来理解多线程的一些方面。

      我们知道多线程间的数据同步,我们是通过加锁的操作来实现的。线程间的锁是怎么体现的?首先,我们看Java线程都需要对什么样的数据进行处理。我们顺便简单介绍下关于Java线程内存分配。

      首先,Java程序的数据分配的最小单位是进程,在进程里至少会有一个主线程,线程间是可以进行数据共享的。但是,我们的每个线程还有属于自己的线程栈,所以,Java线程不需要去考虑每个线程的私有线程栈里的私有数据。如:类的对象中非同步方法或者(代码块中定义的临时变量),他们在线程栈中分配内存,由于他们是方法中定义的临时变量,其他对象根本获得不了它的内存,所以,也就不用去考虑对这类数的同步。

      我们简单总结至少有以下两类数据在多个线程访问的时候,我们需要考虑数据同步:1.存在堆中的类的实例;2.类的方法作用域中的类变量。

      所以,我们的多个线程有可能会同时访问这两类数据的时候,我们需要给它们加上锁,先到先得的每次只准单一访问。通过学习我们知道,Java中的对象的锁是排他锁,每个类和对象都会有对应的锁。我们在平时编程中,常用触发锁的方式是通过互斥量的方式来同步共享资源,使得对代码块的访问每次都只允许一个对象访问。在Java语法中,我们至少有两种方式来同步代码块来对共享资源进行同步,如:synchronized 和ReentrantLock上锁的方式。

      关于Synchronized和ReenTrantLock的一点认识  

      关于synchronized 和ReentrantLock的性能讨论很多文章说法不一,有一种说法,JavaSE 的java.util.concurrent中ReentrantLock的设计就是对synchronized的替代方案,性能更好(http://www.ibm.com/developerworks/cn/java/j-jtp10264/index.html),也有一种说法,在JDK 1.6后,两个并没有性能的差别(《Java Concurrency In Pratice》)。但是有点,我们必须可以统一认识,使用ReetrantLock,在设计上弥补了synchronized存在的一些不足,至少在设计上有两点我们可以看出ReetrantLock对synchronized的改进:

      1.ReetrantLock能方便捕捉上锁的代码块的异常,代码如下:

    Lock lock = new ReentrantLock();  
    ...  
    lock.lock();  
    try {  
        // 对锁定对象进行更新等操作 
    } finally {  
        lock.unlock();  
    }  

      2.ReetrantLock实现了中断的锁机制,synchronized加锁线程可能一直无限制的等待下去,就算那些正在占用资源的线程死锁了,正在等待的那些资源还是会继续等待,但是ReentrantLock可以选择放弃等待(该方法lockInterruptibly()的实现)。ReetrantLock应用可以举例说明:如果A、B2个线程去竞争锁,A线程得到了锁,B线程等待,但是A线程这个时候实在有太多事情要处理,就是一直不返回,B线程可能就会等不及了,想中断自己,不再等待这个锁了,转而处理其他事情。这个时候ReentrantLock就提供了2种机制,第一,B线程中断自己(或者别的线程中断它),但是ReentrantLock不去响应,继续让B线程等待,你再怎么中断,我全当耳边风(synchronized原语就是如此);第二,B线程中断自己(或者别的线程中断它),ReentrantLock处理了这个中断,并且不再等待这个锁的到来,完全放弃。  

    展开全文
  • 关于自然语言理解的一些理解

    千次阅读 2017-12-13 19:23:32
    (当下的很方法忽略了语言的控制功能只看到了信息承载功能) 2)机器是靠着编译器解释执行程序的,自然语言是是否也存在着翻译过程,而后是理解与执行过程呢 3)程序与机器结构是一体的,自然语言是否也无法脱离...
    1)自然语言不仅仅应当看做简单的数据,它更应当看作是"人脑"这台机器的“程序”;(当下的很多方法忽略了语言的控制功能只看到了信息承载功能)
    2)机器是靠着编译器解释执行程序的,自然语言是是否也存在着翻译过程,而后是理解与执行过程呢
    3)程序与机器结构是一体的,自然语言是否也无法脱离人脑结构?


    自然语言理解的过程:

      语言--》通过已有的知识体系与偏好进行翻译--》根据对应的信息进行运算--》得出最终信息
       

    因此自然语言理解的特点:
    1)非唯一性,与不同的人不同的时间不同的地点不同的文化不同的背景有关
    2)相似性,由于人类处在相似的世界,因此同一句话最终产生的信息具有相似性

    构建机器理解自然语言的关键点:
    1)构建合适的人类的世界的背景知识
    2)构建相似的语言信息执行单元
    3)如何对语言进行翻译
    4)如何对翻译后的数据进行处理,(换句话说就是那些是数据背景,那些是动作控制,通过控制信息决定如何补充,关联,加工数据信息)

    1-2是数据积累
    3-4是算法功能
    自然语言理解既需要数据积累也需要算法改进

    当下的LSTM这些神经网络对自然语言的处理,只能算是"在某个简单模式下的语言加工过程"而已,虽说LSTM也引入了门,也引入了embeding信息,但是门仅仅是简单的根据当前已有的信息决定的,而embeding更算不上是对现实世界的精确量化。因此lstm只能算是对人脑理解语言过程的拙劣模仿,

    我们需要更加完备的基于广泛信息(各种多媒体)以及之间的关联构建的embeding,而且是同一个空间下的
    我们需要各种基本的信息加工能力以充当执行单元,如联想,调用,加工等
    我们同样需要一个完整的信息处理框架来整合这些资源。



    改进的形式更可能是广义的神经图灵机NTM.
    1.改进embeding数据或过程,不在只是简单的映射
    2.改进读写控制器,使得读写控制器能根据不同的信息自由的切换不同的控制单元

    换句话说,我们储备了一堆embeding或者一堆embeding映射网络(解决歧义问题)

    Controls={embeding_maps,联想control,功能controls,........}
    主结构,NTM


    eg."孕妇能吃螃蟹吗?"的理解过程.
    1.根据已有经验embeding_maps过程对这句话进行,进行信息编码与映射
    2.处理单元,调用执行网络或者关联网络或者联想网络进行信息加工
    3.返回结果。


    如果执行的是搜索能力网络,人脑就启用控制人去搜寻有关信息,如问别人或者搜索引擎,返回答案
    如果执行的是关联网络,可能之前有存储相关信息,我们直接告诉答案
    如果执行的是推理网络,我们会根据也有的信息,进行推理告诉答案
    如果执行的是默认网络,则我们会根据心情处理信息,告诉答案
    如果执行的是其他网络,我们可能会采取其他方式回答。

    可以看出不同的经验的人,对这句话的首先embeding1就会不同,而后是在不同的状况下采取的控制器网络也不同,
    也因而回答的结果就不同,这就造成了以下各种千奇百怪的回答:


    ===================================================================================
    还是少吃为好,偶尔吃些没事的,螃蟹属海鲜类凉性食物
    如果最好是不要吃螃蟹甲鱼之类的海鲜,因为这些都是比较寒性的,可能会对胎儿不利的,
    宝妈你好、螃蟹是性寒之物、还是慎吃吧
    我特别喜欢吃螃蟹,今年一个都没有吃,为了宝宝忍忍吧
    吃一个不要紧不能吃脚的部分我连续吃了三天也没事不要多吃其实什么都能吃
    孕妇应慎吃螃蟹。孕妇慎吃螃蟹的原因
    你好,螃蟹是活血化淤的,习惯性流产的孕妇是不宜吃的,怀孕早期也尽量不要吃
    这个最好是到了孕后期的时候适当吃一点没事的
    蟹是滑胎圣品。
    亲爱的,小宝宝最好是不要吃螃蟹,螃蟹是寒性的食物,小宝宝现在的肠胃还没有完全发育好,还是等宝宝在大
    因为螃蟹有活血化淤的功效,可能使胎气不安,起到动胎作用,也很有可能导致流产,因此孕期不能吃螃蟹。
    螃蟹属于寒性强的食物,孕妇使用寒性大的食物容易流产的,尤其是螃蟹腿,而且螃蟹容易引起过敏,所以不适
    我怀孕时,有经验的妈妈叫我一定不要吃螃蟹,说吃了的话容易流产,并且还说海鲜类的东西也要少吃,其实我
    头三个月我没吃,6个月的时候吃了点。都说是凉性的东西,容易滑胎,我感觉跟个人的体质有关系,还是谨慎吧
    准妈妈不要吃蟹呀,吃蟹容易流产!
    ==================================================================================
    展开全文
  • IC验证的一些理解

    万次阅读 多人点赞 2018-05-21 13:03:56
    下面这些问题和回答是基于我个人对验证(主要是动态仿真验证)的理解,可能有理解的不到位、理解有偏差的地方,欢迎大家指正。Q:验证的目的?A:发现Bug,发现所有的Bug,或者证明没有Bug。Q:对验证工程师的要求?...

    下面这些问题和回答是基于我个人对验证(主要是动态仿真验证)的理解,可能有理解的不到位、理解有偏差的地方,欢迎大家指正。

    Q:验证的目的?

    A:发现Bug,发现所有的Bug,或者证明没有Bug。

    Q:对验证工程师的要求?

    A:Hacker mentality ,Organized testing ,Tool automation。

    如何做更多的testcase、如何覆盖更多的测试点、如何充分的利用服务器、如何尽可能最大化的自动比对

    强调一下:“注重细节”是验证工程师一个非常非常好的工作习惯。

    Q:语言、方法学有多重要?

    A:我的观点是:这两个都不重要。做事情的是验证工程师,来源是Spec,所以Testplan(全覆盖testplan)最重要。重要的是验证的意识,愿不愿意去实现H-O-T,即使一开始做的“土”一些也没关系。比如tb里经常要做的“自动比对功能”:1)维护queue,然后foreach的比较;2)利用file-operation(fopen fread fwrite fscanf)来做文件比对;3)直接$system(diff a b > c)以后看c文件大小。上述三种方法都可以(虽然2)会导致比较多的文件IO,硬盘读写会影响仿真速度,3)不能做实时的比对。不必拘泥于方法,关键是有这个意识。

    Q:EDA行业对验证的支持?

    A:个人感觉虽然(动态)验证这些年在理论方面的突破不大(静态验证一直是热点),但是EDA行业一直都很重视,实现类的工具主要是在做算法优化,这些年突破不大。但是验证方向上的点工具一直在不停的出(虽然最终可能也没有几个好使的工具),但是说明EDA行业一直在致力于寻求在验证上的突破。而且由于现在做SoC的太多,IP又太多,大家都是越来越重视验证,很多上规模的公司里验证人员较设计人员多不少。个人觉得这可能也是EDA重视验证的一个原因(用牛工具替代掉一些人LL)。

    Q:如何跟踪缺陷?

    A:可以考虑bug-zillar这类的工具---- 自动跟踪问题。

    Q:作业提交系统(lsf或grid-engine)

    A:充分和合理的利用计算资源。

    Q:环境变量的管理?

    A:个人推荐使用Module 工具。很多公司都是用这个免费的工具

    Q:Testbench用到的编程语言?

    A:我觉得tb里systemverilog和verilog是可以互相替换(当然了,systemverilog特有的内容用verilog来实现会很复杂),所以推荐tb基于systemverilog来搭建,一些仿真模型可以用verilog。C除了Cmodel以外,firmware也会用C和汇编写。

    基本上我做过的项目里用到的语言:

    脚本:perl、makefile、shell(perl用的很多,其他用的很少)

    Tb(包括vmm的组件):基本是systemverilog

    仿真模型:systemverilog和verilog混着用

    Cmodel :C或C++

    Firmware :汇编和C

    Q:验证工程师需要掌握的基本技术?

    A:分享一份我做的基本培训内容安排,供参考:

    Perl,Makefile,AMBA介绍,SVTB.pdf ,sva,几种用到的编程语言的File operation ,Low-power, C-pointer,Cshell-AWK+SED,体系结构相关的一些内容,SV-1Day training ,VMM_source_code ,Arm的嵌入式编程的基本概念。

    Q:自动化必须吗?

    A:不是必须的,但是应该尽量去实现自动化。总之是多让机器跑。如果人均License太少的话,要尽量做到白天debug、晚上让机器跑。“比对”这种事情太机械了,所以尽量让机器做,做这种事情机器的效率比人高太多。把精力放在构造testcase、testbench、coverage以及debug和分析上。

    Q:Testplan如何做?

    A:形式不重要,xls可以、word也可以、txt的也可以。但是来源于Spec!testplan里除了要罗列function-test-piont,还应该有error-injection 和 random-test-point以及cover-point和assertion。

    需要和各个team仔细逐条review testplan,有些针对具体实现的coverpoint可能只有designer能提出来,需要尽早提出。Tb搭建之前,要充分的review testplan,因为Testplan的较大修改有可能会导致整个testbench的架构调整,effort较大。Testplan是一个需要不停增加,不停迭代、不停review的东西。

    Error injection要和RTL-designer逐条review,一个是看看RTL-designer是不是没有想到,一个是设计是不是本身就不允许、或者架构上本身不可能出现。Error-injection应该往深里去好好挖掘。例如:内存控制器长时间不回数据(这里本身是一个随机点)->由于长时间不回数据是否产生错误中断-> 产生错误中断以后如何响应-> 响应不过来如何恢复-> 必须用software reset做恢复的话-> 对software的时机是否有要求-> software前需要遵守什么要求和步骤。

    虽然现在有一些工具可以根据规范化描述的testplan自动生成cover-point和assertion,不过我觉得自然语言描述的testplan应该是最“自然”的。

    Q:哪些地方做随机?

    A:1)随机配置(一般都想得到的),但是对于一个封闭的系统常常是最不重要的,因为firmware可以自己开发,从而控制配置的流程和数值


    2)随机激励数据(很重要)


    3)随机时序(通常容易被忘记)

    但是有一点要明确:随机不是全随机,是约束随机,是在合理的范围内尽量充分的随机。

    Q:写约束随机哪些地方要注意?

    A:推荐看snug paper。(over-constraint导致测试不完全,欠约束导致不必要的debug和资源的浪费)约束的效率:写的不好会导致随机失败

    Q:Coverage如何做?

    A:code-coverage和function-coverage(covergroup, assertion coverage)。对于constraint-random的地方用covergroup做,对于一些时序的coverage可以用assertion-coverage。

    Q:核心脚本?

    A:单个仿真的脚本 ---- 建立所使用的不同的目录、不同的seed(目录可以叫case_$seed这样的格式;当然对于直接的testcase,可以是case_$casename);环境变量和license的管理;如果需要做离线比对也可以让脚本来自动调用比对脚本或命令(也可以在tb的代码里使用$system或者$systemf)。

    批量仿真的脚本----自动批量提交到lsf上。自动收集log信息以判断哪些case失败,对于失败的case能自动重新提交,并且自动dump波形。以及产生批量仿真结束以后的汇总信息。

    Q:SV中重要的点?

    A:特殊的数据类型,比如新增的三种array(动态、associate、queue)、string(match函数、backref函数,参考vcs的svtb.pdf);面向对象编程思想(handle);coverage;constraint-random。

    熟练掌握这些语言点的用法很有必要。

    Q:VMM 1.0够不够?

    A:刚开始用1.0来建立起vmm的概念,然后转到1.1或者1.2上。个人觉得不是必须一下子就转到1.1或1.2上(当然,1.1的一些扩展宏的确很好用)。个人建议vmm1.0+1.1的扩展宏+subenv

    Q:是否要使用VIP?

    A:VIP的使用 --- 复杂仿真模型推荐用VIP,简单的建议自己做。如果自己开发仿真模型的话,也推荐看看VIP的文档,经常可以看到一些有价值的error-injection和random-test-points来完善你自己的testplan。

    Q:要不要做门级仿真?

    A:如果是走design-service,不知道最终带sdf的netlist仿真是否需要做,如果做的话,最好在release 综合后netlist的时候也做一下(插完scan-chain和做完CTS以后有条件也做一下),如果需要VCD文件做power分析和指导PR工具的话,那么门仿是必须做的。如果design-service公司不负责调量产pattern的话,那么ATPG等的门仿是需要自己做的。

    门仿并不是sign-off标准,但是推荐还是做一下,经常还是能跑出问题来的。如果做sdf反标的门仿的话,对于async的多级dff要剔除掉(VCS和NC都有option,vcs可以查手册里“+optconfigfile”,NC查”+nctfile”)。反标Sdf仿真的时候推荐notimingcheck -> no_notify -> checking_timing with optconfigfile的三步走。

    前期在评估IP的时候,有可能个别模块可能需要单独搭门级环境,比如CPU-IP有RTL,要自己做flow,那么通常是需要做门仿的(有可能主要是为了跑vcd或saif做power分析)。


    Tb的修改:由于CTS和综合的原因,导致时钟名字和信号名字有变化,所以tb有可能要修改。另外,tb里的probe文件建议使用反沿采样,也是为了避免带sdf反标以后clk踩不到整个data-vector。除此之外,个人不太建议在门仿的时候依然使用自动化的tb。因为你的tb里抓的很多内部信号可能名字变了(或者被优化掉了),这样导致tb在门级跑的时候维护起来有些麻烦。有些信号即便名字不变,可能会反向,这样会导致你的checker误报错。毕竟在门仿的时候不用跑太多的testcase,可以靠几条和rtl仿真一一对应的仿真来覆盖。门仿毕竟不是为了function,而是为了检查timing。

    如果你的设计里用了不带reset的dff的描述,由于开始不定态的传播,可能导致你门仿失败。个人推荐的方法是:如果特别多的话,用脚本找到对应模块里所有dff,产生一个force-release文件(注意:很影响编译时间,所以能不用就不用)

    Q:FPGA和仿真如何安排顺序?

    A:首先是schedule优先,其次是力所能及。但是原则上是先仿真然后再上FPGA,仿真可以很快的扫清一些基本的bug。给仿真的时间充裕的话,那就仿真尽量往前赶,尽量在上FPGA之前多测一些(不是太多case的情况下,FPGA的测试速度毕竟要快一些)。即便FPGA很着急上,起码也让仿真先用几条直接testcase调试通过最基本的功能。第一版FPGA可能因为接死、悬空和信号反向导致逻辑被优化掉,这些问题有时候用仿真也不能全发现,就要结合leda等lint工具。

    Q:仿真如何复现FPGA发现的bug?

    A:首先保证配置的一致性,可以考虑做一些内部的工具。仿真上要probe寄存器操作端口,FPGA上要能把firmware里的配置流程转成文本。

    如果配置一样还是不能发现的话,再去逻辑分析仪上debug时序。当然,CDC的问题在仿真上是看不到的。

    个人不建议做FPGA网表的门仿,有点得不偿失。

    Q:FPGA不能cover的部分的验证?

    A:PAD_Mux(Test_mux)、Clkrst、Power-management-unit 以及FPGA跑不到的高频所对应的功能。Clkrst这部分主要就是pll config、clock-gate、divider、soft-and-hard reset,从测试点的角度还是很明确的,RTL代码修改的少的话,可以考虑不用做太复杂的验证(但是clkrst模块里可能会有一些控制逻辑或者状态机,比如:sdram的切频,这里一般是需要一个状态机控制的,这个需要仔细和小心的验证。)


    PAD_mux个人比较推荐使用自动化的流程,因为代码风格非常固定,所以可以用脚本生成RTL和用脚本生成testcase(一般这样的testcase是一堆的force)


    PMU建议看看VCS的MVsim的文档,里面介绍的很清晰了。(还是要配合静态验证工具MVRC一起来做)没有MVSim的话,可以考虑用VCS的$power $isolate。

    Q:固化的firmware如何验证?

    A:个人不建议让仿真去覆盖firmware,但是对于FPGA和ASIC不一样的地方要重点覆盖到。大的流程要覆盖到,其他细节由FPGA保证。

    Q:架构评估?

    A:我经验也不多,举几个例子。比如你的总线拓扑合理不合理?内存控制器的效率(机制)是否满足你的应用?使用哪类Cache?Cache的大小?模块的FIFO深度够不够(error-injection可以测到)?算法需要多少mips(rvds等工具带的模拟器可以给出结论,但是要让模拟器能考虑到内存access的latency)?软件里如果有不少memcpy的话,要模拟系统运行起来以后memcpy的效率。

    如果没有人手专门用ESL(如Carbon的CMS)工具的话,建议在验证平台上做(当然一旦有大问题,要推翻架构会很麻烦)。

    Q:哪些资源要节省?

    A:当然首先是人(数)要节省,人的成本比起计算资源成本和存储资源成本要大多了。提高技术、提高自动化程度才能节省人的成本。(低Package这种方法属于伤天害理的手段,不是正当途径)

    减少硬盘需求(如果有必要) 共享simv/simv.daidir csrc(包括regression过程中自动清理磁盘空间);激励数据是否可以不一下子全产生出来(对于通讯类的比较有意义,由于是floating的激励数据,所以经常很短时间就需要GB的空间)。注意对每个人每个项目设置硬盘quota,避免被个别人撑爆存储。

    减少编译次数(soc项目里比较有必要,testcase基于firmware),parallel-compile or separate-compile ,vmm-test,在一个testcase里做多个功能点的覆盖,fsdb/vpd的dump层次的改变不要重新编译(fsdb有command,vpd可能得用ucli)。

    Q:设计规模大了编译很慢怎么办?

    A:有时候设计规模太大导致编译很慢,但是SoC项目很多情况下,功能模块彼此之间是用总线隔开的(即便在功能模块之间有硬件连线也可以考虑用仿真模型来做替代)。在仿真某一个功能模块的时候,可以考虑dummy掉不相关的模块。

    但是这就引入了一个新问题“文件列表的维护”。基于这种dummy的思想,文件列表的维护就成了tb里的一个很关键的地方,要尽量避免维护太多的文件列表。我个人比较推荐利用脚本来自动产生所需要文件列表。除此之外,仿真用的文件列表里我个人比较推荐用绝对路径(避免别人debug的时候出现调错文件的问题,另外可以指定不同的工作目录)。CVS里用相对路径,相对路径转绝对路径的工作由脚本自动完成。

    Q:编译还是运行option?

    A:为了减少编译的次数,能使用运行的option就使用运行的option。比如使用$value$plusargs $test$plusargs

    Q:Assertion谁来写?

    A:建议RTL designer和IC验证工程师都写。内部实现细节的描述由RTL-designer自己写,模块之间的时序由IC验证工程师来写。

    Assertion的抽象层次有些高,写复杂了有时候极容易出现和你想象不一致的地方。而且如果spec上描述的不清楚,误报assertion-fail也会引入不必要的debug时间。

    Q:IC验证工程师要不要看RTL?

    A:不是很必要,但是有些设计背景比较强的验证工程师看代码通常能看到一些问题。个人建议还是拿出点时间来review一下RTL code。

    Q:自动化的tb搭好了,波形对验证工程师来说还那么重要吗?

    A:非常非常的重要。毋庸置疑!!波形是最直接的,checker可能写错,有问题没有报出来。但是没有激励就没有所要的波形信息。

    Q:如何重用?

    A:reuse可以分为横向和纵向。

    横向是指项目之间。这个reuse主要包括:文档和tb、script。

    纵向是指同一个项目内,一般是模块级和系统级(包括子系统级)。一般是tb和script。

    比如在一个项目中,所有的tb都是用run_sim和regress脚本的,只是带的filelist不同。对于tb来说,driver和generator可能不能reuse,但是一般monitor和scoreboard这类被动接收的一般都可以reuse。而且testcase通常是可以reuse的。

    对于SoC类项目,为了保持testcase的一致性,我个人比较倾向于都使用firmware做testcase,这就要求


    1)模块的验证也要基于一个(类)soc的tb下验证。

    2)cpu-ip要尽量简单,否则cpu会占用太多的仿真资源。个人推荐用iss做cpu-ip,负责配置寄存器。

    Q:regression什么时候做?做多少次?

    A:tb好了以后,任何时候都可以做。下班后尽量提交regression到lsf里,让机器充分的跑。如果你的环境是random的,那么随机空间实际是很大的(随着random-test-point的增长指数级增长),所以只要seed不同,其实是可以跑到各种各样的情况。

    Q:DPI要不要用?

    A:有的人很喜欢用DPI,不过我个人不喜欢用。我尽量是把C封装好(自己写wrapper),产生可执行文件,然后在tb里用$systemf来调。不喜欢用DPI的原因主要是因为如果代码里有不太安全的地方(比如C代码里你不是在堆上而是在栈上开了一个大数组,或者C和SV之间的参数传递写法不合理),很容易造成coredump。而且你也不确定到底是SV写的不安全还是C写的不安全。另外,有些大公司的算法源代码是不提供的,只给你一个.o文件,这样coredump了你debug起来会让你有砍人的冲动。

    但是不用DPI也带来一些坏处:

    1)

    要自己写一些wrapper之类的代码

    2)

    静态变量处理要小心。举个例子:我是每帧调一次systemf来做比对,某个函数每次比对会被调用一次。函数里的静态变量就没什么静态的意义了。如果不做修改的话,肯定会出错。一般是要求算法组尽量少用静态变量,非用不可的话,我们会把静态变量改成全局变量,然后让systemf多一个参数。

    要说明的是:DPI“天然”的就是tb的一部分。但是我觉得把时间浪费在debug 算法C代码的优劣上是一件很不值得的事情(无论什么时候都是schedule优先),当然我也很佩服有些人对任何事情都“精益求精”的态度。

    无论用不用DPI,你都可以使用DDD这类debug工具。DDD这种工具在非DPI情况下用起来会更加的得心应手。

    Q:Force要不要用?

    A:有的人比较抵触用Force-release,觉得如果写的不注意的话,可能会浪费时间(debug或者re-compile)。个人觉得“规定所有人把各自模块的force语句写在一个文件里,然后再被一个统一的force_prj.sv include进去,并且include前要有`ifdef保护起来”应该可以规避掉一些风险。

    Q:人手少的情况下怎么做验证?

    A:我个人觉得验证不能大包大揽,人手少的话就要更多的靠RTL-designer自己做验证。对于某些模块验证工程师就不要做了,否则陷进去出不来,反而影响了核心模块的验证力度。可以适当的更多依赖FPGA。但是对于核心模块一定要做好验证(比如内存控制器以及FPGA覆盖不到的模块等)

    Q:IP要不要验证?

    A:首先是去找业界口碑好的IP(个人觉得对数字IP来说silicon-validition一样重要)。人手不够的时候,可以考虑让FPGA多承担一些IP的验证,对于IP里一些FPGA无法cover到的测试功能点,可以考虑用直接testcase的方法覆盖。

    Q: Debug到什么程度请designer来debug?

    A:首先schedule优先,然后本着“力所能及”的原则,有时间有精力就debug的深入一些,否则checker报错以后,确认一下不是checker误报,就可以先提交给RTL-designer。

    Q:遗漏bug怎么办

    A:开发过程(FPGA)乃至最终silicon-validition甚至已经产品化后都可能发现遗漏的bug,要重视这些被仿真遗漏掉的bug。要一个一个的做case-analysis,仔细的分析为什么testbench没有抓到这样的问题。而且对于TO以后发现的Bug,要在下一版里重点review,以保证不犯同样的错误。另外,对于每个bug都应该尽量加一条对应的assertion。

    Q:验证工程师要不要深入了解自己负责验证的模块?

    A:虽然不深入了解,也不影响刚开始的工作,但是要把自己负责的模块吃透的话我觉得是很有必要的,我希望验证工程师能从系统(架构)一直到应用这些层面上都能深入的了解自己负责的模块。

    Q:分享的氛围。

    A:我个人觉得验证的范围很广,一个人很难把各个方面都搞的很精通。经常的技术讨论和培训是非常有必要的。Team-leader应该营造一个很好的技术分享的氛围。

    -----------------------------------------------------------

    推荐的学习材料(For VMM User)

    1)

    svtb.Pdf

    2)

    vmm源代码

    3)

    systemverilog for Verification

    4)

    VCS目录下的文档(包含vmm文档)

    5)

    例子(先把VCS目录下的例子看懂)

    6)

    Snug paper

    7)

    转夏晶帖:总结我的思路,如何在验证中发现和定位Bug(里面有些观点太偏激)

    8)

    一些资源网站 比如verification-guild EEtimes EETOP等等

    展开全文
  • glActiveTexture和glBindTexture的一些理解

    千次阅读 2019-05-09 18:53:37
    在openGL中,存在一系列的texture unit,通过 ...而当前的texture unit中存在个texture target,例如GL_TEXTURE_2D, GL_TEXTURE_CUBEMAP。 通过glBindTexture将一个texture object绑定到当前激活的texture unit...
  • 关于W5500的一些理解

    千次阅读 2017-11-27 15:12:44
    做了这么天的W5500了,看到一些人在问我这个东西到底要怎么玩,今天就很简单的说一下思路。 W5500实际上已经为我们实现到传输层了,而我们需要做的只要告诉W5500一些参数就可以实现网络连接。而这些参数无非就是...
  • 工作多年,我对架构的一些理解

    千次阅读 多人点赞 2020-07-13 09:41:54
    每一个程序员都听过架构这个词,每一个程序员都有自己对此的理解和看法,本文分享我对架构的理解。 什么是架构? 因为我是程序员,所以本文讨论的架构特指软件架构(Soft Architecture)。 我看过很关于架构方面的书...
  • MVVM的一些理解

    千次阅读 2017-02-17 11:46:47
    最新开始做一个新的项目,由于之前项目越来越...如果你的项目没有那么大,没有那么的业务逻辑。MVC最合适你了,不用考虑更换了。 首先,MVC和MVVM的区别,从字面上看似乎是把C变成了VM这么简单。其实不然,是把C拆
  • 串级PID的一些理解

    万次阅读 多人点赞 2019-05-12 21:29:34
    本篇博文主要来回答为何旋翼无人机控制使用的是串级PID而非单级PID这一问题。 我们可以从如下几个角度来回答这个问题: 1.输出反馈和状态反馈 首先,以无人机的姿态通道为例,系统的状态变量为姿态角和姿态角...
  • 首先作者在第一篇文章就说了,线程之间是共享全局变量的,具体体现在,...1,线程同时对全局变量进行操作 import threading # 定义全局变量 g_num = 0 # 循环一次给全局变量加1 def sum_num1(): for i in r...
  • 嵌入式软件可靠性设计的一些理解

    万次阅读 多人点赞 2013-12-04 15:00:51
    这里着重谈一下作者自己对嵌入式软件可靠性设计的一些理解,通过一定的技巧和方法提高软件可靠性。这里所说的嵌入式设备,是指使用单片机、ARM7、Cortex-M0,M3之类为核心的测控或工控系统。  嵌入式软件可靠性设计...
  • 本人很年前接触完成端口以来,期间学习和练习了很次,本以为自己真正地理解了其原理,最近在看网狐的服务器端源码时又再一次拾起完成端口的知识,结果发现以前理解的其实很偏差,有些理解的甚至都是错误的。...
  • 软件测试的一些理解

    千次阅读 2016-07-17 17:33:49
    这也决定了很情况都必须被动接受。即使某个测试工程师理论知识丰富,辨识风险能力强,但是一个产品需求的变更就可以让他傻眼,接着很努力去适应这种节奏。产品运营主导必然是趋势,测试主导是做不好产品的还有一个...
  • AnchorBox的一些理解

    千次阅读 2018-12-21 09:51:35
    Anchor box相当于对对一个中心点,取不同的窗口,从而用来检测重叠在一起的个目标量。 首先我们需要知道anchor的本质是什么,本质是SPP(spatial pyramid pooling)思想的逆向。而SPP本身是做什么的呢,就是将不同...
  • 关于S参数的一些理解

    万次阅读 多人点赞 2017-10-17 20:55:52
    本文将从S参数的定义,S参数的表达方式,S参数的特性,混合模式S参数,S参数测量等个方面介绍S参数的一些最基本的知识。 1,S参数的定义 人们都喜欢用一句话来概括一个术语。 譬如用一句话
  • FreeRTOS系统的一些理解

    千次阅读 2018-09-03 10:19:35
    最近在学些FreeRTOS,从初学者的...2. FreeRTOS使用广泛,网上各种资料比较。 3. 协议栈代码整体编码风格统一,逻辑比较清晰。 4. FreeRTOS现在属于Amazon,背靠大树,基本不用担心版本断档问题。 FreeRTOS ...
  • 对Vue组件化的一些理解

    千次阅读 2019-06-26 22:01:38
    对Vue组件化的一些理解 一、基础概念 1、概念:组件是html、css、js等的一个聚合体 2、为什么要使用组件? ​ 1、组件化 将一个具备完整功能的项目的一部分进行处使用 加快项目的进度 可以进行项目的复用 2...
  • 关于switch的一些理解

    万次阅读 2017-06-12 10:17:09
    switch 语句类似于具有同一个表达式的一系列 if...很场合下需要把同一个变量(或表达式)与很不同的值比较,并根据它等于哪个值来执行不同的代码。这正是 switch 语句的用途。 这是 PHP 官方对 switch 语句的解释,
  • 关于电机双闭环PID控制一些理解

    万次阅读 多人点赞 2017-11-18 09:39:32
    目前网上流传的一些关于双闭环的资料有很我觉得是不对或者不够清楚的,在这边分享一下自己的理解,希望大家也能指点一下。 双闭环的作用串级控制系统是改善控制质量的有效方法之一,在过程控制中得到了广泛的应用...
  • 我对合伙人制度的一些理解

    千次阅读 2019-03-02 09:13:31
    合伙人,就是一起做大事的人。这些人是如何做事的,我们简单分析下。 汉高祖刘邦,斩白色起义,一堆合伙人,这些人组到一起就是”事业合伙人“,大家奔的是消灭...当然还有很别的模式,但大同小异,本质不变。 ...
  • 关于高斯滤波的一些理解

    千次阅读 2019-02-18 20:14:28
    答:边缘检测的算法有很种,这些算法通常容受图像本身的一些噪声干扰,尤其当用偏微分方程获取图像边缘时候,如果边缘不连续,甚至导致函数水平集无法停止收敛。比如,几何活动轮廓模型,高斯滤波...
  • 对Git的一些理解

    千次阅读 2013-07-25 07:29:59
    平时可以根据shell的管道命令,组合一些命令比如git show commitID | grep “diff”来看看某次提交修改了哪些文件,还经常帮助同事解决git上面的问题。但是自己心里明白,还是有很地方不是很懂。这几天抽空温故了...
  • Nginx的工作模式和一些理解

    千次阅读 2016-05-06 10:52:07
    2、Nginx的工作模式以及可以处理高并发的一些理解   Nginx的工作模式很简单,就是采用一个master进程和个worker工作进程,其中master进程的作用也是很明确的就是负责管理worker进程,同时监听连接请求,当连接...
  • 变量名与变量地址的一些理解

    千次阅读 多人点赞 2017-12-23 13:33:03
    要想彻底理解变量名与变量地址,能有一些《计算机组成原理》里与存储器相关的知识储备,和《数据结构》里有关堆栈的内容。 在C中,内存分成五个区,他们分别是堆、栈、自由存储区、全局静态存储区和常量存储区。 不...
  • 对闭环控制系统的一些理解

    千次阅读 2019-04-17 21:48:21
    由上篇博客的分析控制系统中"带宽"的理解,我们知道,只要系统的截止频率足够高,就会有足够频率的分量通过,输出就能很好的跟随输入。然而,不幸的是,有很系统,其截止频率没有足够高,那怎么办呢?举个例子:...
  • 算法——个人对算法的一些理解

    千次阅读 2018-02-05 14:08:49
    个人对算法的一些理解  在学校的同学们之间,算法总是被放在一个非常高的位置,有高呢?嗯...就是非常非常高啦,高到有人只要能说出几个非常牛掰的和算法有关的名词,比如NP完全问题啦、模拟退火啦就觉得自己是...
  • 分享对BIM的一些理解

    千次阅读 2013-01-14 20:29:04
    因为有幸参与由东南大学建筑学院领导的工业化...对于 BIM 也有了一些自己的理解和体会。并在2012年的AU大师汇上用一个专题演讲的方式和很同行进行了讨论和分享。有兴趣的朋友可以通过如下链接了解我心目中的BIM。 ...
  • FileLock的疑惑和一些理解

    千次阅读 2017-03-24 14:44:36
    最近碰到一个项目,有个进程,同时操作同一目录的同一文件,笔者使用java语言。由于文件比较小,所以上线后并没有碰到什么问题。但是,我不禁想到一些问题:不同进程对同一个文件进行操作,如何保证数据的正确性。...
  • 在我们做vue项目时通常会创一个config文件夹,里面一般会包含 api.js和index.js,其中api.js一般用于存放一些url地址,例如 let base = 'http://192.168.1.110:8081/hhdj/' export default { login: `$...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 48,452
精华内容 19,380
关键字:

多一些理解