systemC的一些问题
既然已经有verilog,vhdl这些硬件语言了，为什么还要一个systemc可综合。而且具有现在所掌握的信息来看，systemC如果要写可综合的话和verilog基本是一样的，甚至还比verilog麻烦。如果说他是写系统级的，那么再实现的时候不得还要翻译成硬件语言吗?这和写C有什么区别?
第二个问题是验证
系统级验证，这个东西很抽象；不还是有C差不多吗?还有提出一种协同验证，也就是他所说的一边搭平台一边写硬件代码，写好一部分立即可以拿到平台上进行验证。那么你在搭平台的时候就要考虑时序的问题，这不是很麻烦吗?到底有多少公司或学校在做这方面的工作?
第三个问题是发展问题
systemC已经提出很多年了吧，但貌似还没成为IEEE标准。而且国内几乎很难找到这方面的书籍，从这方面是不是可以看到systemC发展并不是很好。对比于同样是新兴的语言systemverilog的资料就多很多。
第四个问题是仿真问题
仿真快不快我没一个直观的感觉。但我感觉到systemc编译和仿真是很麻烦的一件事情，不知道有人和我有同感没。比如用VC++进行编译，出错提示老是不直观，而且想要检查结果，还得加测试跟踪语句，产生波形文件，再观察。如果用支持systemC的EDA工具，仿真也是很麻烦的事情。
第五个问题是继承问题
比如他里面定义了很多通道之类的，但是不知道怎么去用，没有文档的说明，感觉整个语言体系很乱。不知道这个问题大虾们又怎么看
小弟现在对这方面有兴趣，望各位大虾指点迷津！
个人意见，仅供参考：
第一个问题是可综合问题：
ASIC的设计发展是：直接画版图->Gate级设计->RTL级设计。其主要原因是设计规模的增加，当ASIC超过1亿门规模时，RTL设计难以满足，业界推介使用ESL设计。SystemC语言是业界公认的最适合ESL设计的语言。你可以参考ESL相关资料。虽然目前ESL发展不成熟，但这是发展趋势。ST、三星、高通等就有ESL设计成功的ASIC，可以查查相关资料。
第二个问题是验证
我对系统级验证理解是解决部分在模块级验证无法涉及的功能，如连线、多模块协调、全局时钟和电源管理、总线验证等。系统验证还是有一定的必要。另外你提到的“协同验证”，是不是HW/SW协同验证?目前我也在做这方面的项目，感觉还是很有必要的，尤其是可以大幅度加速软件开发时间，对整个项目时间控制有利。至于小编说的一边搭平台一边写硬件代码，写好一部分立即拿到平台上进行验证，我也遇到多次，都是因为项目时间太紧张，不得已为之。
第三个问题是发展问题
SystemC的资料还是很多的，前面说到SystemC优势在于ESL，SV的优势在于验证。而目前业界尤其是国内，ESL发展很不成熟，自然显得SystemC比SV冷门。
第四个问题是仿真问题
SystemC和SV我都是用VCS编译的，感觉SystemC是要麻烦点，但还是可以接受。
第五个问题是继承问题
建议去读源代码，即使是SV，虽说有很多方法学支持，且文档也很多，但要真正理解还是要仔细去理解源代码。
非擦感谢你这么耐心解答这些问题，很多不明白的地方有了一个比较直观的理解，能够找到一些方向。
再次衷心感谢！
哪麻烦了，就是个C++的库，g++就编译了。
非常棒的帖子~谢谢~
"systemC已经提出很多年了吧，但貌似还没成为IEEE标准。"
你确定你了解过SystemC?
问题虽然很老了，但是这个问题对很多不了解sc的人来说还是有同样的问题，我也是新手，呵呵。对于问题一：sc的综合除了可综合的RTL 子集外，还有HLS(高层次综合），算法级别的HLS综合出来的效果据说比手工写RLT更好。问题二：sc的验证指的是功能验证，也有对应的验证库scv，与sv的约束随机差不多，但是标准还不支持覆盖率特性（也有其他办法可以产生功能覆盖率）。基于sc开发的ESL，在规格定了后，可以软件应用开发，功能验证，以及由此进行硬件实现（RTL），相应的sc模型可以作为参考模型。问题四：仿真速度，对应小模块来说，肯定感觉不到，但是对应芯片级仿真，有资料表明是对应RTL级的1000倍以上，主要原因是sc本质是c++，相比其他HDL语言来说更接近“系统”语言，速度更快，并且ESL平台中，类似时序细节忽略了，减少了交互，速度快是理所当然。问题五：sc可以看做是一个基类库，里面开发了不同通道，模块等基类，便于用于由此开发。类似做法的还有U(O)VM,VMM等流行方法学，如果细究源码，会发现完全就是一样的原理，因为都是基于TLM开发，尤其是TLM1.0。
有道理，可要讨论技术? 超越皮特
海思的平台就是systemc的
路过学习了