Re: 看到各种VM有感

呵呵，看你都列了那么多SV的好处了，这还不能说明问题么？^_^

正是因为有了 还要大家学习新的东西去实现相同的功能 不太合理吧
constrained random 的问题，这种严重依赖于simulator实现的东西，用起来感觉不太可靠啊。对一个具体的问题来说，很多时候用户自己需要random的时候，正向的生成带约束的随机激励的思路是很明确的，而一定要用constrained的方式让simulator逆向求解，万一由于仿真器的缺陷 总是漏掉一些corner怎么办
呵呵 可能我的想法比较想当然

C++已经很强大了，
但是，
还是有java，c#等出现。

最该摒弃的是verilog这个老古董
这些VM不好用的祸首之一
可惜high level synthesis这些年研究也没什么进展
SystemC RTL也一直成不了气候
看到Cadence有些广告提到C 2 sillicon，没试过具体产品，但不看好

C写的model我觉得最大的优点是速度快，而不是因为C的表达能力强；C语言处理大部分
数据结构基本都是通过动态存储自己实现，而SV本身内置的list，queue，hash表等就足
以大大节省开发维护效率。
verilog写monitor checker什么的，反正对我来说 简直就是想起来就是噩梦，自己实现
动态存储分配，残废的多线程，race-condition等等，总之就是很不好用，尤其是功能
稍微复杂一点的，代码量一下暴增，代码耦合很大，可维护性很低。当然可能是我水平
有限，没有积累很多经验所致；
你说SV的新功能没用，因为这些新功能在其他语言里可以找到。按这个逻辑我们就不用
发明新语言了，java能干的事情C++都能干，我用C也能实现OOP，要那么多语言干嘛？每
种语言都有自己的优势，SV的OOP就天然比C++的OOP更好地支持验证环境的开发（当然，
C++要比SV快得多），至于CRT，我不知道你凭什么认为simulator的结果不可靠，自己开
发的就更可靠，就算它的伪随机数算法有问题，你可以用functional coverage来自己检查嘛。你说你自己不愿意学就算了，说人家没用未免太武断了。至于各种VM，
无非就是一些验证框架类库；java中的hibernate，python中的django，都挺麻烦的，但
也没听做网站的谁说是“乱七八糟”的东西，你要是足够牛或不嫌麻烦，自己搭一套框
架自己用也不是不行啊。
你说SV没人用，那是因为SV的学习曲线上升缓慢，另外就是切换到SV的技术成本和风险
还都比较大，这些都要靠时间来解决。但不管是从设计还是验证上来讲，SV都比Verilo
g强太多，从语言的角度完全可以替代Verilog，现在阻碍SV普及的障碍，从设计的角度
主要是综合器（包括SV的可综合子集标准）不成熟，从验证的角度主要是速度问题和工
程师的习惯问题，毕竟让工程师放弃原来的习惯学习新的东西，一个是人家不愿意，另
一个也是有成本和风险的。但是我相信，只有真正重视验证，或者说重视设计验证方法
流程改进的公司，才能在技术上比别人做的更好。
从以前的 OVM AVM VMM 到今天的 UVM 各种VM眼花缭乱 让人应接不暇
不过不知道真的有多少公司在用这些乱七八糟的东西  又有多少公司坚持为了兼容已有
的代
码 还在坚守PLI 1.0 ？这真是对systemverilog的讽刺
我一直不明白一个问题：systemverilog扩充这一大堆功，号称是HVDL，能真的是有意义
的
么？
很多时候 验证中的reference model还是要用C 来写，那么何不彻底一些，除了
driver/monitor level继续在verilog中实现，上层（包括trans senerio 等等）直接转
入
C来进行，通过完善的定义DPI ，反正C和HDL的双向调用都可以实现了。这不是很完美的
解
决方案么？
至于system verilog 各种新功能，很多都不是必要的：例如
OOP和可重用性 ：systemverilog说自己面向对象，支持集成；C++笑了
constrained randomization： 这个simulator如何实现还是个问题，何不直接让用户自
己
实现呢？不说效率了，不同simulator实现的你能相信么。
不过system verilog 还有一个很有用的功能就是 assertion 机制 看上去C很难取代
至于其他的优势，包括效率 数据结构支持，verilog再怎么扩充还是不能和C比了吧。为
啥
大家都纠结于system verilog 框架下的各种验证方法学呢？
验证接触不深，理解有限,欢迎拍砖~~