精华内容
下载资源
问答
  • 经验:网店运营的五个维度.docx
  • 从学生视角看数学深度学习的五个维度.pdf
  • 我们研究了在五个维度上控制刚性N = 1 $$ \ mathcal {N} = 1 $$超对称的方程。 如果超对称旋转子满足现实条件,则这些叶面将允许叶片上几乎复杂的结构族。 换句话说,所有这些流形都具有几乎是柯西-黎曼(CR)结构的...
  • Kaluza:通过安装github组件为您的项目添加第五个维度
  • 20210815-华西证券-城投新论投资策略:五个维度看城投.rar
  • 20210815-华西证券-城投新论投资策略:五个维度看城投.pdf
  • 为了可以将抽象的词汇具象出来,我们列出了验证人员在验证流程中需要具备的五个技术维度。接下来让我分别解释这五个维度:     完备性:该维度要求验证的充分。无论你从项目经理、系统人员、设计人员还是验...

    本文转自:http://www.eetop.cn/blog/html/28/1561828-433754.html

    可能在贯穿到整个验证系统思想里面,我们都会不断重复验证人员该具备的素质。为了可以将抽象的词汇具象出来,我们列出了验证人员在验证流程中需要具备的五个技术维度。接下来让我分别解释这五个维度:

     

     

    • 完备性:该维度要求验证的充分。无论你从项目经理、系统人员、设计人员还是验证人员,大家谈验证首先提到的就是要“充分”。然而充分一词对于验证而言边界时模糊的,很难量化到什么时候才可以达到验证的完成标准。所以,作为一名验证经理,需要引入各种数据来综合量化出验证的进度,这其中包括了验证功能点的覆盖率,代码覆盖率,是否经过了低功耗验证流程(power aware verification),是否经过了跨时钟域检查等等。 通过数据量化,来对验证人员和验证经理增强足够信心来宣布某一个项目节点中,验证已经得到了“充分”的验证。当然,对于功能覆盖率部分,如何将功能描述文档充分理解,进而充分列出要测试的功能点并尽可能地细分出来,这需要系统人员、设计人员和验证人员的共同努力。同时,如何将抽象的验证计划转换到功能覆盖语言(SystemVerilog function coverage)需要验证人员具备该能力。

    • 复用性:从项目的实际运用角度来看,复用性和完备性是同等重要的。没有人愿意会在下一个项目中将以前的验证环境做较大的更新,因为这意味着额外的资源消耗,包括时间、人力和项目进度的考虑。在硬件设计角度而言,通过标准总线协议,可以最大限度的讲模块之间实现相对独立和快速集成,所以对于目前项目进度不断缩紧的现状来看,一方面是市场的瞬息万变导致的,一方面也是由于SoC自身逐渐趋向于软件的快速周期迭代方式而成的。对于一个系列芯片而言,后续芯片的性能提高、功耗优化都是建立在前一代的基础上的,而这些不断地提高和优化具体到每一个硬件子系统而言,可能就是他们的存储大小、时钟快慢、动态电源开关、总线宽度、缓存深度来综合决定的,然而下一代硬件设计自身一般不会有第一代芯片的艰难历程(否则它也就称不上是系列芯片了)。 那么从硬件设计的角度来看,这些更新如果不会在逻辑上面有大的变动,那么带来的工作量是可以估计的。而从验证角度来看,我们也很自然地希望验证的工作量也不需要太大——可是事实并不一定是这样的。首先从芯片项目的集成性而言,设计人员相比较验证人员,在同一功能模块的稳定性是更高的,那么当一个验证人员在尝试阅读和修改上一个项目的验证代码时,就要看看他的运气。一般来讲,他的运气会跟上一个验证人员的代码风格有直接的关系……同时,验证人员在处理一些总线协议的时候要有意识引入参数来为日后的复用做好准备。而不断融合的验证方法学,走到今天,UVM(Universal Verification Methodology)之所以划分出不同的功能单元,实现小的颗粒度,提供快速插拔式的环境集成,也是为了复用性考虑的。

    • 高效性:指的是用尽可能少的工作量来完成验证工作。在保证验证完备性的情况考虑下,实际上复用性和高效性会有存在冲突的可能。例如,验证人员会考虑如何“短平快”地在一个紧张周期内完成验证工作,但可能他不会采用UVM等方法学框架,也有可能他不会考虑将参数引入到验证环境中,因为这些“额外”的因素虽然是对复用性有帮助的,但是也会跟高效性有冲突。所以,验证人员需要针对不同的情况来在上述的五种维度之间做好平衡,至少需要保持一种意识,那就是工程学的执行阶段本身就是一种平衡,对于验证人员来讲,他需要作出的判断就是在每一个项目每一项验证任务中做好取舍,来给出一个合适的验证考量维度。甚至对于同一项验证任务而言,采取不同的验证策略也会有不同的完成效果。例如,一开始考虑采用随机约束的验证方法,那么单单就约束而言,它的约束一开始是比较窄合适,还是一开始比较宽宽合适?
      这里我们再给出一张示意图来说明高效性实际上在不同的验证方法和同一个验证任务在不同状态时都需要有相应的变化。因为在开始阶段,考虑到设计不够完备而且尚未经历过验证,我们一开始的阶段称作基本功能验证阶段,这个阶段,我们会将随机约束域降低到基本范围,尽可能少的触碰到边界情况,而把重点放到如何先将各项基本功能都验证到。第二个阶段是在我们已经完成基本功能验证以后开始的完备功能验证,这时我们就可以逐渐放开随机约束域,而开发的速度跟合适能够设定最终的开放域范围需要验证人员充分考虑到各种合理的情形再做约束域的限定。而当了功能覆盖率一般上升到80%附近的时候,这就处于了最后的爬坡阶段,这个时候,如果再沿用之前广泛的约束域,那么会产生很多无效的随机种子,这些“无效”的随机种子基本对于剩下的验证覆盖率完善没有什么帮助,那么这个时候验证人员就需要通过理解设计本身和随机产生的约束两方面来考虑具体贡献覆盖率的测试序列,再进一步缩窄随机约束域,来定向(biasing)产生一些激励,对于最后的这一阶段,一种极端的情况就是将随机约束域缩到尽可能窄的情况,甚至和直接测试(directed test)没有什么区别。

       

    • 高产出:指的是在一定的时间,可以调试、报告、帮助修正出多少个设计缺陷,以及可以建立多么完整的验证环境。多年来数字硬件设计(RTL级别)的基础并没有发生太多变化,同时EDA厂商提供的自动化工具又进一步提供了便利,提高的设计本身的可靠性。但是这一情况却并不适用于数字验证,因为EDA工具目前仍然只能作为辅助手段,例如提供更多方便的调试功能和接口,却不能也随之自动化帮助建立复杂的验证环境。这也就不难解释了2014年Wilson在功能验证领域的调查数据显示,今天在设计和验证领域面临着最大的挑战之一就是为快速的芯片产品和员工数量增长之间找到一个平衡点, 实现单位产出的提高。

    • 代码性能:关于这一点要讲详细一点,需要专门开个话题。代码性能似乎也跟高效高产出有冲突的地方,因为对于验证代码的整洁性、复用性甚至一点点地美感都对于数字意义上的验证完备性没有直接联系,这也包括你的验证经理可能有好长时间都不会注意到你写的验证代码,除非有一天你验证的那个设计出了一个缺陷,而且是一个显而易见的缺陷却没有被发现,这可能才会引起验证经理的注意专门来访问可能是一团糟的代码结构。 但是每一位验证人员也需要记住一句台词“出来混迟早是要还的”,无论是你在看着别人写的验证代码没有注释、没有缩进、超长if-else判断语句等等这些让你已经无力吐槽是时刻,还是你因为项目紧张快速搭建验证环境和编写测试用例的时候没有考虑到“后来阅读者”和“你后来阅读”而偷的各种懒,相信我,时间会让你为此买单的。所以,作为一名验证人员,请在你写每一行代码的时候把它当做你日后行业名声的荣誉墙,尽管你还在迫于项目的压力快速建立环境疲于完成验证,但等到你有闲的时候会去再改善那些代码吗?不要再相信这些鬼话了,现在就去做吧!

     


    从上面的五个维度来看,做一名合格的验证人员实属不易,更不要说考虑到每一个项目每一项验证任务来分别针对制定出合适的五个维度指数。虽然项目执行没有尽善尽美,但是针对验证人员自身,如果可以意识到这五个维度的存在,并且能够在实际工作中都照顾到它们,运用到验证任务的考量当中,那你就是有意识地在培养自己成为一名验证师了

    展开全文
  • 驱动视界198 5个维度解读BOSCH、GKN、BorgWarner和ZF 电驱动桥.pdf
  • 完全从热力学的角度出发,我们借助Ruppeiner热力学几何学,探究了爱因斯坦理论中一有毛的黑洞的微观特征,该黑洞与五个维度上的标量场共形耦合。 我们证明了标量毛状黑洞在不同的参数空间中具有丰富的微观结构。 ...
  • 在IIA型超弦理论中,我们在一对(DD¯)4-布雷恩上获得了五个维度上的两非极端量子Kerr几何形状。 在量规的选择中,可以看到量子真空是非BPS麸的非传播扭转的基础。 有人认为,量子克尔真空发生隧穿并在低能量...
  • 关于驱动视界198 5个维度解读BOSCH、GKN、BorgWarner和ZF 电驱动桥的介绍说明.rar
  • 根据这些情况进行分析,得到了一新的软件需求评审框架,这新框架由5个维度组成: 1,组织形式;2,时机;3,侧重;4,评审者;5,对象 分析了分别在传统开发和敏捷开发下的典型需求评审情境,显示新框架能够...

    摘要 近年来随着CMMI、敏捷软件开发的推进,出现了多种多样的需求评审类型,这些类型超出了标准评审类型的范围。根据这些情况进行分析,得到了一个新的软件需求评审框架,这个新框架由5个维度组成:
    1,组织形式;2,时机;3,侧重;4,评审者;5,对象
    分析了分别在传统开发和敏捷开发下的典型需求评审情境,显示新框架能够适用于所有系统性的和非系统性的评审类型上。从分析中得到了15个有价值的启示。新需求评审类型的设计和对需求评审类型的选择可以从这个新五维需求评审框架中受益。根据启示,得到了一个多级小瀑布生命周期模型,这个新模型可以大幅度的优化传统瀑布生命周期模型,具备灵活的自调整自适应能力。
    关键词: 需求变更; 需求评审; 需求条目化; 多级小瀑布; 需求工程

    在软件开发中,需求变更被视为导致软件开发失败的主要原因。早在1988年BILL CURTIS等人的研究表明:需求的冲突和变化对于生产效率和质量存在巨大影响,识别到学习、技术交流、需求协商和客户交流是非常关键的过程[1]。这些过程在当时的软件过程模型中描述得非常糟糕,而当时的软件过程模型把重点放在了如何通过一系列的产物(比如需求功能规格说明,代码,等等)来得到软件产品。当时的软件过程模型对实际的软件开发没有提供足够的用于指导软件开发技术研究的洞察力,这些模型只是描述了一系列开发任务,而对以下事情没有帮助:项目团队成员必须要学习哪些新信息;如何协商不一致的需求;设计团队如何解决架构的冲突;这些因素及其它类似因素是如何影响项目本身的不确定性和风险。虽然时光过去了整整27年多,但是这一段文字在今天读来都仍然让人感觉汗颜。
    在1988年以前,瀑布型生命周期模型(下文简称称为瀑布模型)是占主导地位的生命周期模型,从时间上可以合理的推断[1]文中所说的当时软件过程模型就是以瀑布模型为主。而在[1]文中提到了螺旋模型-“Boehm的螺旋模型是一种很有前途的从宏观层面来管理这些问题的尝试”。螺旋模型的特征是快速原型迭代增量进化并结合风险分析[2]。
    复杂软件系统中分析和处理可能存在不一致的需求描述,这解决得好坏直接影响到需求规格说明的质量,进而影响到最终软件产品的质量[3]。为了在需求方面克服不一致和变更问题,需求评审成为试图解决此类问题的第一道关口:在需求阶段或需求活动时就马上识别到需求不一致,这样修复成本是最低的。人们对此开展了大量的研究[4][5]。但是直到最近几年的研究,需求变更导致软件开发延期甚至失败仍然是困扰软件行业多年的老大难问题[6][7][8]。
    源于瀑布模型的传统软件需求评审发展得很全面规范[9],其中最突出的代表是IEEE软件评审和审计标准Std.1028[10],最早版本是1028-1988,历经1028-1997,当前最新版是1028-2008,最新版IEEE Std. 1028-2008对比1997版没有本质性差异[10]。在最新版中,仍然是定义了5类评审审计,分别是管理评审(Management reviews)、技术评审(Technical reviews)、检查(Inspections)、走查(Walk-throughs)、审计(Audits)。这些类别都是系统性的(英文原文是“systematic types of reviews and audits”),不符合此标准的其它评审类型都是非系统性的。显然的,还有许多非系统性的评审类型,IEEE Std 1028-2008说明:“本标准无意阻止或禁止使用的非系统性评审”,“判断一个评审或审计必要性的流程没有定义,并且没有说明评审或审计结果的处置”,“本标准没有建立对于实施具体评审的需要,这些需要定义在其它软件工程标准或本地流程中”,“本标准的使用者应说明何时何地使用本标准与及任何的故意差异”[10]。所以,IEEE Std. 1028并没有完全解决上述问题,留出了大量的空白需要填补。而确实在实际的软件开发中,就算是需求文档得到了正式批准,遭遇需求变更仍然是经常性的[11]。
    自1991年起,软件能力成熟度模型(Capability Maturity Model,简称CMM)在全世界范围内广泛传播,2002年能力成熟度模型集成(Capability maturity model integration,简称CMMI)发布,2006年,CMMI全面替代了CMM,至今CMMI得到全世界大范围的使用。在CMM3/CMMI3中,同级评审(也称同行评审或者同级互查)是其要求[12][13],随着CMM/CMMI的推广,同级评审也被应用到包括需求文档在内的各类工作产物中,对传统的需求评审带来了变化[14]。
    传统的基于文档和文档评审的方法在2001年起的敏捷运动中被视为官僚繁琐、繁文缛节[15],而在敏捷首先着力的需求领域,IEEE Std. 1028简直就是“罪魁祸首”。而最近十多年来,敏捷软件开发带来了新的变化,提出拥抱变化,不再假设软件需求可以被冻结[16],传统的需求评审方法在敏捷环境下已经不再奏效[17],而敏捷软件开发确实带来了很好的效果。敏捷软件开发的特征有迭代增量开发、软件尽快可运行、短距沟通、业务方参与和快速反馈[18],简直是针对了1988年BILL CURTIS等人所识别的问题[1]。另外也明显可以看出敏捷软件开发与螺旋模型存在渊源关系[19],让人不得不感叹BILL CURTIS等人早在25年前的先见之明。
    但是敏捷软件开发各个流派对需求管理方法各异,实际效果并不完全尽如人意,仍然存在不少争议和模糊的地方。而以瀑布模型为核心的传统开发方式,对于有些组织而言是虽然难以(也许也不必)转换成敏捷短迭代开发,但也从近年来的敏捷发展中获得了启示,出现了新变化,就需求评审领域出现了更加高效的评审方式方法,将在下文进行说明分析。
    1995年Kim, Lesley Pek Wee等人发表了《一个软件开发技术评审的框架》[20],对当时出现的各类技术评审、审查和走查进行了分析,归纳了其框架,但显然的此框架不可能覆盖后续出现的新情况。而自敏捷开发在全球的推进传播,已经有许多研究表明敏捷开发其实同样是符合需求工程的宗旨[21],但却没有归纳整理传统需求评审和新出现的需求评审(需求验证确认类的实践)之间的框架或者结构。

    展开全文
  • 零售药房行业深度报告:从融资、并购、整合、自建、加盟五个维度评估药房的扩张能力和剖析其投资价值.pdf
  • 我们在五个维度中以规范的N = 8 $$ \ mathcal {N} = 8 $$超重力的一致截断形式研究荷电超对称流动方程。 该截断给出了耦合到两向量多重和两超多重子的规范N = 2 $$ \ mathcal {N} = 2 $$超重力。 我们从矢量和超...
  • 区块链颠覆银行的五个维度:支付、清算和结算、融资、证券、贷款和信用
    展开全文
  • 工作技能不等于工作能力——工作能力的5个维度 2015年8月12日 22:36 阅读 10 新浪博客 在职场混迹多年,发现一规律,工作技能越强的人,跳槽的频率越高,而技能平平的人反而能深扎一处,在一公司内苦心...

    工作技能不等于工作能力——工作能力的5个维度

    2015年8月12日 22:36 阅读 10 新浪博客

    在职场混迹多年,发现一个规律,工作技能越强的人,跳槽的频率越高,而技能平平的人反而能深扎一处,在一个公司内苦心耕耘多年,会发展的很好。而频繁跳槽的人,反而总觉得怀才不遇,每到一个新公司又得重新开始。

    技能强人往往有几种纠结:1、这个公司的工作,我轻而易举就搞定了,浪费了我的才华;2、与那些平庸之辈一起工作,实在无趣,浪费了我的才华;3、那些平庸的人,能在这个公司里混了很多年,可见这是一个没有前途的公司,所以,我不能再这里浪费我的才华。

    总之,技能强人一直会觉得自己的怀才不遇。但是,在现代社会里,工作技能只是工作能力的一个元素,职场所需要的才华是多维度的。

    维度1:团队协作精神。

    一个公司相当于一个社会,鱼有百种,网有千样,不能苛求每个人都是谦谦君子,每位同事都才华横溢。真正的职场强者,能在各种各样变局中发挥自己的能力,而不是假象出来一个职场“乌托邦”,让环境适应自己,最终只落得黄粱一梦。

    维度2:深的公司信任。

    每个公司都有一群人认为老板瞎了眼,其原因是一些平庸的员工,反而能委以重任。据我的观察,能委以重任的人不一定是技能强人,而是深的公司、老板信任的人。公司用人有一个底线,就是这个人不能出乱子。所以,获取信任也是能力的一种。

    维度3:遵守木桶原理。

    技能强者,出类拔萃,工作成绩总能鹤立鸡群,但这不一定是好事。公司或企业,也讲木桶原理,业绩取决于最短的木板,而不是最长的木板。有思维高度的员工,往往能从全局考虑,除了自己能做出成绩外,还可以弥补公司的“短板”。技能强者往往不这么想,他们认为,我的工作有成绩了,老板就应该表扬我,公司就应该奖励我,至于别人,我不关心,他们的工作没做好,与我何干?其实,与你有关,因为你们是一个团队。

    维度4:耐心等待机会。

    我身边有很多技能强者,每到一家新的公司,都会开出让老板咋舌的条件,例如,要参与公司的分红,要取得公司的股份等等。在我看来,这基本上是天方夜谭。他们的逻辑是,我的工作能力强,所以开出这样的条件是理所当然的。但是,技能强,不是一步登天的理由。在职场上,情商有时比智商更重要。在职场上,技能只是敲门砖,只是一个筹码,若想生根、发芽、结果,则需要耐心的等待。

    维度5:深谙人情世故。

    埋头做事,是件非常好,特别好的事情,但只是好事,对发展不一定有好处。我曾经的一个同事就是这样,工作技能超强,工作态度也没问题。但是,很多年了,没有加薪,没有升职。当时,我工作能力没有他强,资历没有他深,但工资却比他高,刚开始我替他鸣冤叫屈,结果后来我意识到,如果我要是老板,他也得不到重用。因为它经常给上级发脾气、甩脸子,与同事拌嘴闹矛盾,仗着自己的专业技能强,嘲笑老板能力有限。在另一家公司,我也看到过一些资历平平,能力一般的同事,深谙人情世故,受到公司重用,升职为公司高层。

    在职场能力方面,有一个古人值得我们学习,就是苏东坡先生,工作技能超强,又懂得团队合作,庙堂之上,与同僚司马光并肩作战,江湖之远,与政敌王安石吟诗作赋。苏东坡的文学成就与职场生涯都得以圆满。

    与苏东坡比,我们在职场上的才华算得了什么?

    高晓松在一档节目里讲:“人总是高看自己,就算只有一分才华,也觉得怀才不遇。”人们总是夸大自己的才华。我认为,现代社会根本没有怀才不遇的人,在古代,上升通道只有考试,的确有才华横溢的人被埋没了,但现代社会处处都是机会,当你得不到重用的时候,应该反思自己,是技能不行,还是能力不行?


    展开全文
  • 企业流程运行现状评估的5个维度

    万次阅读 2018-05-11 13:32:13
    下面总结了流程评估的16字目的和流程评估的维度。非常实用!一、流程评估的目的导致企业经营不佳、竞争力差、管理失控等多种问题的原因是非常综合的,主要源自于战略(执行)、流程设计,也有流程执行等诸多原因。...
  • 文章目录维度1 --- 从原始构成上来说维度2 --- 从使用方法上来说维度3 --- 从等待是否可中断上来说维度4 --- 从加锁是否公平角度来说维度5 --- 从线程间的通信来说 维度1 — 从原始构成上来说 synchronized是...
  •  品牌个性的五个维度 大多数品牌人物可以分为大类,或“维度”,因为它们是由社会心理学家詹妮弗·阿克(Jennifer Aaker)创造的(后来成为行业标准)。每个维度都有自己的个性特征和优势: 称职 可靠,成功,...
  • 1000只桶 = 1桶毒药水 + 999桶水,这些桶看起来别无二致,现以猪试毒,若一猪喝了毒药水便会在15min死去,如果想在1小时找出这桶毒药水,那么最少需要多少头猪 ? 2.迁移老鼠试酒,确定猪的数量: 老鼠试酒也是...
  • 当然也不仅仅是从这五个维度出发去说明,要讲述的维度其实还有很多,这就需要大家自己去研究了。 通过这一系列的梳理,我们知道如何找到影响设计风格的关键因素。剩下的就是由你来告诉需求方,...
  • 在使用神经网络的过程中,经常会用到把一tensor扩展一或多个维度的情况,然后把扩展后的维度用来广播。 扩展一个维度的情况,使用unsqueeze()函数,缩小一个维度使用squeeze()函数。参数是dim,是一int。也...
  • 个维度的玻尔空间

    2020-03-22 02:01:16
    Bohr模型中的共形因子将Bohr空间嵌入了六个维度,揭示了O(6)对称性及其在无穷大处对E(5)的收缩。 在五个球体上按六个维度对玻尔·哈密顿量进行重新公式化之后,讨论了现象学的后果。
  • D 93,085005(2016)]的研究接近六个维度,着眼于可能在五个维度上实现相互作用的共形场理论。 我们采用两环ε展开,两环固定维重归一化组和非摄动函数重归一化组。 在六个维度附近找到一相互作用的,真实的,...
  • 就目前而言,很多技术都是离不开数据科学的,这里提到的数据科学其实也是一知识面广泛的学科,...可以说,数据科学是数据分析中最高深的学科,这是因为数据科学有5个技术维度,而这五个技术维度基本涵盖了数据科学...
  • 性能优化的几个维度

    2020-05-13 18:39:16
    性能优化有迹可循,我们可以按照不同维度进行针对性的优化,在维度划分上可以分为如下三个维度。 第一维度:应用程序层面 1. 缓存 缓存的数据结构设计很重要,没有一种数据结构是万能的。数...
  • Numpy系列()给数组增加一个维度

    千次阅读 2020-08-16 16:18:36
    np.reshape(a, newshape):方法,给一个维度设置为1完成升维 方法1:np.newaxis关键字   注意:np.newaxis其实就是None的别名   即以下所有的np.newaxis的位置,都可以用None替代   数据现在是一行*列,...
  • 学习历史的8个维度

    2021-04-10 20:45:10
    学习历史的8个维度,这也是美国大学里学习历史,研究历史的套路:

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 337,570
精华内容 135,028
关键字:

五个维度