Re: 有哪些外企干活比较有技术含量？
反之，越复杂的设计，verification越是关键，大公司大项目，verification与design
人数的比例是1~2:1.
要做好验证，不懂设计能做好验证？还有各种 高级验证语言验证方法，脚本等等。
技术面要比设计宽的多。大公司招验证工程师通常要三年以上工作经验的。设计的一二年的
都行。
当然，如果只是跑跑别人写好的用例，testbench别人搭好，有问题叫设计的人来定位，
这确实简单，但这也敢叫验证？有人要才怪。
这个讨论就事论事，我从来没觉得自己是牛人，我只是认为你在不熟悉验证工作的情况下，就轻易下结论否定这份工作（国内）是不合适的，或者说这样做可能会误导其他的网友。
关于验证工作的技术细节，就轮不到我来总结描述了，比较好的参考资料有：
《Advanced Verification Methodolog Cookbook》和《SystemVerilog for Verification》。其中，前者是Mentor公司的Mark Glasser主笔的（此人亲自参与了AVM验证方法学的创建工作），内容描述得浅显易懂结构清晰，可以让大家对AVM这个验证方法学有一个明确的认识，而且该书特意在第三章给硬件工程师介绍了软件编程中的OOP技术（很多人在接触SystemVerilog或System C的时候比较头疼的地方）；后者是Synopsis公司的Chris Spear主笔的——这位大牛我就不用介绍了，该书有很多SystemVerilog的实例，有助于大家快速掌握SystemVerilog这个语言。
关于验证工作的行业发展，我个人观点是：
1. 随着芯片复杂度的提升、流片成本的增加以及产品上市速度的加快，验证工作变得愈发复杂愈发重要，传统的基于仿真、波形检查以及直接测试例的手段已经无法满足功能验证的需要，目前行业的发展趋势是采用Functional Coverage，Constrained Random，Event-Driven Verification等等技术手段来进行RTL级的验证，而验证结果大部分是以transcript的形式输出——除非进行RTL Debug，否则不需要人工观察波形，从而在某种程度上实现验证自动化。此外在行为级验证方面，大家正在逐步接受并采用System C来进行验证——其工作即可以直接演进为RTL级设计，又可以作为Golden Model嵌入到RTL级验证的Testbench中。
2. 当前的验证工作已经吸收了大量的软件编程思想（例如OOP技术），非常强调编写环境/模型、可重用性/可继承性等等概念，甚至有人认为验证工作已经开始软件化。对于硬件工程师而言，快速掌握和接受这些东西可能有些困难，不过其实也没有那么痛苦。以我们这个团队为例（除我以外其他的工程师都是EE出身），在经过强化训练和学习之后，大家都能够在三～四个星期之内掌握新的验证方法学——延伸说一下，无论是AVM还是VMM，二者都是不错的验证方法学；前者从一开始就立足于开源，而后者在工具支持方面（例如功能、灵活性等）比较强。
3. 当验证更多地强调Functional Coverage之后，在验证规划初期对于设计中的Function Point/Feature的定义就变得十分的重要。前面的讨论中有人提出这一步是非常主观的操作——没错，就是这样，所以才强调它的重要性。目前大家的做法是尽可能地将spec及design中的Function Point罗列完整，从而定义出验证工作所需要覆盖的验证范围。以往的验证思路是枚举出大量的独立的Directed Testcase，以及Corner Testcase，这已经不适应于现在的验证环境了。根据业界的经验，在Constrained Random的支持下，通过随机方式能够发现的bug，肯定要比通过工程师绞尽脑汁想出来的Corner Testcase所发现的bug要多。换句话说，把Function Point总结完整，要比把所有的Corner Testcase列举完整要容易得多。
....
最后谈一下个人发展，目前我所了解到的行情是：在北美地区，已经开始出现验证工程师的待遇高于设计工程师的情况（当然都是有经验的）；在国内的外企甚至是本土大公司，验证工程师与RTL工程师的待遇大致上也是相差不多；对于其它的国内公司，由于他们的RTL和验证职位在很多时候并不是严格地区分开，因此不好评论二者在待遇上的差别。BTW，类似于仅仅编写testcase的职位严格来讲算不上是验证工程师，或许叫“测试例工程师”比较合适。
很多人都觉得搭testbench比写testcase写checker要高深，可是我觉得testcase和checker本身就是testbench的一部分。这些东西本来就不应该分离开讨论啊。
如果你使用先进的验证方法（其实先进不先进都无所谓，关键是流行的，或者是即将流行的），你的验证经验自然会被人肯定啊。7000行的checker应该是一个相当完善的checker了，如果别人不接受的话，应该原因是
1）这个被验证的模块不是这个公司所要做的东西
2）这个公司不使用你用的方法
3）这个公司面试人员没有发现你在验证方面的潜力和素质。
ps: 可否给我发个简历，我们公司在招验证工程师。