GPU验证和CPU验证哪个更有挑战？

自己顶一下，看到最新的低功耗GPU都是八核的，是不是说GPU验证比CPU要复杂？

国内做这个的不多
不如说下你是不是有相关的机会，或者为什么问这个呢

估计拿到了ARM挪威或者英国的OFFER吧
最近好像在狂招做GPU 硬件验证的
.123

说一点个人看法。对个人的发展来说，如果没到lead或者manager级别的话，越复杂的验证项目对提高水平的帮助越小。
因为复杂的项目意味着人很多，意味着分工非常细，意味着环境非常复杂，经常掩盖了本质。面试过一些所谓的大公司里出来的，一谈起来就是原来的流程如何如何，一问深了经常就一问三不知，人都被毁了。

多少人的团队算是大项目呢？ARM CPU的验证算是大项目么？

就是楼上说的，在欧洲的位置。我的背景不是做CPU的，所以想知道这些职位是否值得一跳。

做gpu的，Mali是他们搞出来的。有七八十人了。
.242

原来是叫fab啥的。是ARM收购的一家挪威做图形IP的小公司
.45

不如说下你之前做了啥，预期CPU是怎么验证的，预期能怎么发展，这样大家可以就自己的
认识继续讨论
你在欧洲，我估计版上没几个人能把你挖出来的，放心

一直都做一个大系统的螺丝钉，是很危险的
我觉得新人最好能从模块到IP到系统一直做起来，无论做到哪一个块，要尽量让自己对
testbench有完整的掌控能力，经常问自己，这个东西我一个人负责，hold不hold得住
这样就可以慢慢往验证架构发展了

我资历很浅，之前就是用systemverilog/VMM做过一些界面的验证，就是比如一个AMBA的协议控制。具体的细节，和大多数验证书上的差不多，我也说不出什么独特的东西。
CPU的验证我完全没有概念，因为CPU不止是一个界面，内部的寄存器，加法器，乘法器，流水线，状态机，似乎可能比较复杂，需要分块一个一个验证。每一个块有一些界面。
除此以外，我感觉CPU不象某个协议可以使用通用的VIP来自动编码解码，所以BFM的编写可能需要很大的工作量？
还有，不知道哪位前辈有systemC的经验，可否指点一下，systemC在验证中的作用，和systemverilog的区别？systemC可以用来编写BFM么？谢谢！

你之前做的,只是用VIP随机发stimulus验interface而已
我没做过CPU，但应该也是分成各个模块验，根据定义的功能去验证它，然后拼在一
块，真的指令或者编译后的HEX
具体还是得等你真的做了才能理解，光说不做，没什么意义
BFM LS已经解释了，一种可以经常reuse的component，把signal转成transaction
level而已。仅仅是testbench一个小部件而已
ARM还是很令人敬佩的公司的，这个工作应该不错的。而且欧洲的ST，CSR好像都不大行
了
至于能做牛人还是螺丝钉，我觉得就看自己表现了，争取掌控CPU的模块验证，系统验
证，然后到自己能定义整个CPU的验证，这就离牛人不远了

average will go to the botton
大公司倒了怎么办呢，到时候老了，也没有年轻人那样有干劲了

在他们倒下之前很多小公司估计早就投胎四五次了

所以不靠谱的小公司更加不要去，除非有大量股份+够硬的技术不怕没饭吃+不错的个人成
长机会

SystemC 在验证中的作用越来越微弱，通常作为Reference Model出现
不过过几年如果SystemC design真流行起来，SystemC就变成DUT了

谢谢LeuSe，trevon以及Synapse的中肯建议和指点。
【 在 trevon (trevon) 的大作中提到: 】
: 你之前做的,只是用VIP随机发stimulus验interface而已
: 我没做过CPU，但应该也是分成各个模块验，根据定义的功能去验证它，然后拼在一
: 块，真的指令或者编译后的HEX
: ...................
※ 来源:·水木社区 newsmth.net·[FROM: 198.182.37]

这句话的意思是说还有其他的验证方法学可以使用？能举例子展开说说么？〉
【 在 Synapse (Synapse) 的大作中提到: 】
: GPU/CPU的验证方法不要仅仅局限在SV上
※ 来源:·水木社区 newsmth.net·[FROM: 198.182.37]

你这个理解是不对的，systemC从开发的开始就立足于native C++的完美兼容。现在整个systemC的库完全不依赖于任何simulator，任何的C++编译器都可以运行SC，这才是SC的灵魂。至于做constraint random，也是在标准C++的语法下实现的，06年就做好了还是非常牛逼的。

SC输给SV，我个人的理解是技术输给了business。SC太开放了，EDA厂商赚不到任何钱。看看synopsys推vera和cadence推e的劲头就可以了。如果有这么多的资源支持SC，现在估计SC已经一统天下了。

谢谢指正，刚才看了一下SystemC Verification Standard的确是有constraint的部分，但现在使用的人的确是微乎其微了。
我觉得SC败给SV的一个因素还是他是C，而SV由Verilog发展而来对于一般的designer而言学习起来更加容易一些.类似的，e败给SV也有差不多的原因，直到今天仍有不少人批评SV不如e.