请选择 进入手机版 | 继续访问电脑版

开源计算机图形学社区(Open Source Computer Graphics Community) |OpenGPU Forum (2007-2013)| OpenGPU Project

 找回密码
 注册
搜索
查看: 12311|回复: 17

模拟 并发执行 的仿真速度比较: PLI , SystemC, 私有库 [复制链接]

Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20

注册时间
2010-9-18
积分
4105
发表于 2010-10-9 16:31:53 |显示全部楼层
本帖最后由 cqq 于 2010-10-13 16:10 编辑

经常被人问到这些问题:
- C Model为什么不直接用SystemC?
- Testbench用C++/SystemC做顶层有什么好处?

这里先抛开语言本身不说,就只关注比较实在的一点 : 仿真速度

这里用不同语言/工具实现一个功能简单的系统,该系统的数据流如下:


注意:这里的模块均是C Model, 只是采用不同方法来模拟 并发执行,这些方法分别是:
- 私有方法 (这里用Pthread简单实现,效果类似于SC_METHOD)
- SystemC (主要用SC_METHOD)
- Verilog仿真器提供的并发执行环境,例如: VCS + PLI
仿真颗粒度是: Pixel级别

Testcase:
input 576x304, output 800x400, 30 frames

机器配置: 酷睿2双核 2GHz
实验结果:
                      私有方法               SystemC + gcc          SystemC + VCS          PLI + VCS
时间(sec)         11.6                    15                               22.3                            53

速度差异比例是(从最快到最慢):  1   1.3   1.9   4.6
比较特别的是, 在同样使用SystemC的情况下,采用gcc编译运行,比通过VCS来编译运行要快。

希望在决定以下方面的时候,有所参考:
- 编写C Model的时候,是考虑采用私有库还是SystemC库
- 编写Testbench的时候: 用SystemC, 还是用传统的Verilog+PLI

TODO:
目前还缺少SystemVerilog + DPI的实验结果
80 字节以内
不支持自定义 Discuz! 代码

Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28

注册时间
2007-7-11
积分
32844
发表于 2010-10-13 12:13:17 |显示全部楼层
...

速度差异比例是(从最快到最慢):  1   1.3   1.9   4.6
比较特别的是, 在同样使用SystemC的情况下,采用gcc编译运行,比通过VCS来编译运行要快。


...
cqq 发表于 2010-10-9 16:31



联续两次浏览器崩溃,打得回复都没有了……重新来!!!

关于GCC比EDA工具速度快,这个问题好几年前我也遇到过了,当时用的是NCsim/QustaSIM,但是不大清楚其中的缘由,大牛可否指点一下!

另外,关于私有库比SC快,这也是很多有技术积累的大公司不愿意使用SC的愿因之一。但是这里技术积累很重要。如果对于打算使用ESL流程的公司来说,恐怕在性能模拟器上需要慎重考虑这个问题!我知道一个反面的案例,几年前Vmicro引进了一个AMD在美国十多年经验的架构师,那老大一进来就推广ESL流程,用私有库写Cmodel,而且花了不少时间来亲自培训手下工程师,还拿出来AMD CPU的Cmodel做教学案例。但是结果并不理想,原因有二:首先,公司做项目不比学校,项目进度本来就很紧张,但是还要额外做私有库,还需要单独花时间来验证这个库的正确性。由于第一次使用,所以可能在项目过程中架构师的需求发生变化,那库也需要花时间改进。这都很耽误时间。其次,由于以前工程师没有接触过这种新事物,所以学习曲线也是个问题,而且由于都是新手,所以大家为了保证项目速度,都是用最保险最丑的方法来实现,所以做出来的东西像个学校作业一样,并没有比SC的性能得到更高的提高。

所以私有库是否需要,这还需要仔细权衡 :〉不知道大牛怎么看?

使用道具 举报

Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28

注册时间
2007-7-11
积分
32844
发表于 2010-10-13 12:21:17 |显示全部楼层
经常被人问到这些问题:
- C Model为什么不直接用SystemC?
- Testbench用C++/SystemC做顶层有什么好处?
...
cqq 发表于 2010-10-9 16:31



另外,关于私有库和SC的性能问题,我觉得大牛的数据可否有提高的可能呢?比如我的需求可能是,需要把一个pipeline上不同的Stage都放在不同CPU上面跑,然后通过这种多核心之间做生产者-消费者(Productor-consumer)的数据传递,从而加速CA C model仿真,比如我们可以考虑使用OpenMP作为扩展来组建这样的OpenMP SystemC ? 不然现有的SC只能在一个核心上面跑的确有时候让人很着急:〉

类似的方法我在一个海归的小公司见过,那个公司主要是为了节省购买硬件加速器钱,但是他们做的也更为专用。他们主要在测试平台上面做手脚,而不是Cmodel。他们的测试平台可以把一个流水线上不同Stage的RTL和Cmodel都放在不同的PC上面跑。然后通过网络来进行Pipeline Stage之间的通信。他们实际上是通过Cluster来加速仿真而不是仅仅依靠一个UMA的多处理器服务器来加速仿真。


不知道大牛有什么看法

使用道具 举报

Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20

注册时间
2010-9-18
积分
4105
发表于 2010-10-13 14:31:00 |显示全部楼层
本帖最后由 cqq 于 2010-10-13 15:34 编辑
关于GCC比EDA工具速度快,这个问题好几年前我也遇到过了,当时用的是NCsim/QustaSIM,但是不大清楚其中的缘由,大牛可否指点一下!

所知甚少,我只能做一下合理推测。
这跟EDA simulator的实现有关,EDA的simulator是需要支持多个语言的,所以EDA simulator与SystemC simulator在实现上是分离的,这两个simulator之间的通信需要通过IPC(进程或线程间通信),通信代价较高。


所以私有库是否需要,这还需要仔细权衡 :〉不知道大牛怎么看?

同意大牛的看法,这需要结合公司的资源来仔细权衡,没有教条性的答案。

不过,不管是用私有库还是SystemC库,我提倡对这两种情况都适用的基本原则:
1. 如果使用SystemC库,对SystemC库提供的功能要 惜用,能有native C/C++实现的地方,尽量用native C/C++.
2. 提倡形式上还是使用私有库,只不过私有库的实现可以调用SystemC.
这样做的原因是为了让整套C Model维持一定的平台/库无关性,为未来的变化提供一些灵活性,或者说,使得应对变化的代价降低。

必须指出,如果类似于SC_METHOD的功能就能满足需求了,那么,私有库性能比SC库性能好是比较容易做到的。
但是,如果需要类似于SC_THREAD的功能,那么,我个人认为私有库很难做的比SC库好。因为SC库是使用QuickThread(一个轻量级的线程库,比Pthread库快很多)来实现SC_THREAD的, QuickThread的性能非常优秀,如果我来实现私有库,估计我也会首选QuickThread来实现SC_THREAD部分.


比如我们可以考虑使用OpenMP作为扩展来组建这样的OpenMP SystemC ? 不然现有的SC只能在一个核心上面跑的确有时候让人很着急

目前的SC只能在一个核心上跑,确实这一点让很多人诟病。
其实QuickThread是支持Multi-Core的(手册是这么说), QuickThread的主体实现是平台无关的,不过,它的Context switch部分的代码是平台相关的,目前支持的平台有:
    *  80386 family,
    * 88000 family,
    * DEC AXP (Alpha) family,
    * HP-PA family,
    * KSR,
    * MIPS family,
    * SPARC V8 family,
    * VAX family.
由于目前还不支持常用的酷睿2,i5, i7....平台,所以暂时只能在一个核跑。

对于OpenMP,我认为它不适合加速pipleline stage的仿真。(这是我粗略了解OpenMP之后做的判断,请大牛们批评指正)
因为典型的OpenMP代码是让for/while循环里面的语句并行执行(),这种并行跟我们需要的pipeline的stage并行是不一样。
例如这段代码利用OpenMP在4核上跑:
int input[8], output[8];
for( i=0; i<8; i++ ){
    output[ i ] = input[ i ] * N + M;
}
每个核所分担的计算部分是:
  时间            t                  t+1
核心0:   计算output[0],   ouput[1];
核心1:   计算output[2],   ouput[3];
核心2:   计算output[4],   ouput[5];
核心3:   计算output[6],   ouput[7];
这样的语句是很适合OpenMP的,因为输入量之间: input[0], input[2], input[4], input[6]没有数据相关性。
但是,如果计算所用的数据之间具有相关性的话,OpenMP就无法使用了。作為高層抽象,OpenMP並不適合需要複雜的執行緒間同步和互斥的場合.

我的推断是: 如果pipleline的stage不存在反馈路径,那么理论上应该可以使用multi-core加速。如果存在反馈,那么,multi-core之间通信的花销应该会远远抵消加速带来的好处。
他们的测试平台可以把一个流水线上不同Stage的RTL和Cmodel都放在不同的PC上面跑。然后通过网络来进行Pipeline Stage之间的通信。

所以,我推断它们加速的stage之间应该不存在反馈,或者说,他们想了一下办法来消除反馈。

由于需要尽量减少multi-core通信的花销,所以, 我觉得因根据模块/stage之间同步的频繁度来进行负载平衡的规划。
例如,假设是一个SoC,也许一个合理的划分是
核心0:  CPU + OS
核心1:低速外设,例如UART,USB..
核心2:子系统,例如decoder子系统,或者基带子系统?
核心4: ...
反正要让核心间的通信次数尽量减少.

需要把一个pipeline上不同的Stage都放在不同CPU上面跑

所以,我认为大牛的这个想法可能会导致core之间通信花销过大。应该把GPU割成几个大块,把大块放到不同的core跑,而不应该是pipleline stage这么小的块。
以上只是我推理的想法,缺乏实证,还请大牛批评指正。
1

查看全部评分

80 字节以内
不支持自定义 Discuz! 代码

使用道具 举报

Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28

注册时间
2007-7-11
积分
32844
发表于 2010-10-16 20:04:14 |显示全部楼层
所知甚少,我只能做一下合理推测。
这跟EDA simulator的实现有关,EDA的simulator是需要支持多个语言的, ...
cqq 发表于 2010-10-13 14:31



   
嗯,大牛说的极对,指出来我很多错误,学习了。我比较土,就是用SystemC,没有看过SystemC底层代码,刚刚看了一下QuickThread,挺强大的,比OpenMP更加灵活。这里有一个OpenMP和QuickThread比较。http://www.quickthreadprogramming.com/Comparison%20between%20QuickThread%20and%20OpenMP%203.0%20under%20system%20loads.htm


另外,关于Pipeline Stage之间互锁导致的反馈通信,我觉得大牛说的也是极对。我并没有说清楚,其实我想说的图形流水线(Graphics Pipeline),图形流水线的粒度好似图像视频处理的流水线一样,比如“时域至频域转换”算是一级,“量化”算是一级,等等~~ 这些流水线阶段之间除了由于FIFO填满引起的流水线互锁之外,几乎没有其他反馈~~在这种情况下,那个公司通过把不同的Pipeline Stage分布到不同PC上运行,从而加速整个仿真过程。

使用道具 举报

Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28Rank: 28

注册时间
2007-7-11
积分
32844
发表于 2010-10-16 20:18:01 |显示全部楼层
...

不过,不管是用私有库还是SystemC库,我提倡对这两种情况都适用的基本原则:
1. 如果使用SystemC库,对SystemC库提供的功能要 惜用,能有native C/C++实现的地方,尽量用native C/C++.
2. 提倡形式上还是使用私有库,只不过私有库的实现可以调用SystemC.
这样做的原因是为了让整套C Model维持一定的平台/库无关性,为未来的变化提供一些灵活性,或者说,使得应对变化的代价降低。
...
cqq 发表于 2010-10-13 14:31



大牛说的这几点,我还是比较赞同的,尤其是对于大公司来说的确如此。我稍微总结一下私有库的优点。

首先,私有库可以最大程度上避免因为标准改动而引起的流程改动,比如未来说不准搞一个SystemD出来和SystemC分庭抗礼,如果公司内部用自己的标准接口的话,那么只需要在内部做一个工具,让自己的私有库调用公共标准即可

其次,对于IP供应商来说,如果对客户释放(release)ESL IP时候也可以通过内部的工具把私有库Cmodel包装(wraper)成为SystemC Model,Carbon的那个公司就是这个干的……。而且

再次,私有库的另一个优点就是更高层次描述,即比SystemC更高层次的描述,比如ArchC那种针对可编程处理器的高层语言。针对不同应用的设计,可以有面向不同应用的私有库特性。


缺点就是耗费时间和公司资源……,不是大公司不便尝试 {:4_203:}



我个人比较土这方面没看过什么论文,我相信很多论文肯定就此论述过,欢迎大牛斧正和补充!!

使用道具 举报

Rank: 8Rank: 8

注册时间
2010-9-4
积分
165
发表于 2010-10-16 23:29:19 |显示全部楼层
我觉得这个还是比较容易解释的。

cmodel,是用c做的,实现最直接,最快。
systemc+gcc比cmodel慢,原因很简单,同样是gcc编译,systemc是一个c++框架,大量的用到了c++的继承重载特性,所以要比cmodel要稍慢。

systemc+vcs,是因为vcs在编译systemc的时候为了兼容hdl,在里面增加了一些vcs的特性,但是这些应该是c语言实现的(vcs提供的库)所以比上一种情况要稍稍差一点。

PLI+vcs,这种情况主要是HDL和c/sc model混合仿真,为了支持PLI,需要提供大量的供PLI遍历/访问的信息。所以最慢。

另外还有一种是DPI+VCS吧,应该在sc+vcs和PLI+vcs之间,DPI的访问能力比PLI差很多。所以效率稍优于PLI。

c/sc的模型和HDL之间应该只有两种标准化的接口PLI和DPI。对于公司项目,使用私有接口无所谓。开源项目,需要考虑在各种仿真平台下的兼容,所以还是看好DPI和PLI。

另外各位大佬,SC和HDL之间有标准接口吗?
RTL solution & Development

使用道具 举报

Rank: 8Rank: 8

注册时间
2010-9-4
积分
165
发表于 2010-10-17 00:00:37 |显示全部楼层
看不太懂lz在说什么,估计我上面的应该可以说明一部分问题。

一般对于HDL和C/SC联合仿真,中间选一个接口是必不可少的。
VSC。。。。好像可以不用。
但是对于多平台兼容VSC/ModelSim/QuestaSim/NCSim/Icarus,最好还是选一个标准接口吧。
LZ提到的几种情况,前面两种是没有HDL支持的。只有C/C++当然好说了。

CQQ,后面提到的应该是多线程的问题吧。一种是细粒度多线程,一种是粗粒度多线程。
细粒度的情况下必不可少会产生cache一致性/任务分配。。。问题,这些问题也会大量的消耗处理器的处理能力。
粗粒度的情况下,就需要在均衡任务的时候应该就是一个问题了,应该尽量避免任务分配不均和任务见关联过大的情况。
至于pipeline,感觉对于反馈较少的情况下应该是一种很高效的方法。对于任务的处理,感觉大多数是可以串行化的。对于任务中的每一个步骤,可以根据处理能力需求不同,可以分配不同个数的处理单元。
RTL solution & Development

使用道具 举报

Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20

注册时间
2010-9-18
积分
4105
发表于 2010-10-17 12:03:16 |显示全部楼层
本帖最后由 cqq 于 2010-10-18 10:16 编辑
CQQ,后面提到的应该是多线程的问题吧。一种是细粒度多线程,一种是粗粒度多线程

感谢大牛的指点,一语中的,问题确实就是细粒度和粗粒度的问题。


另外各位大佬,SC和HDL之间有标准接口吗?

我想把这问题提到更广大的范围来讨论,例如C调用C++,java调用C, verilog调用C等等...
这问题归结到这一点: 如何实现跨语言调用?

目前,实现跨语言调用的方法大概有两类:
1. 定义好一套访问对方的接口,让编程者自己去调用
2. 让工具隐藏访问对方的机制,不用编程者自己去显式调用。(例如使用编译器技术,或者一些更简单的code generator形式)

从解决方法的优雅性(或者说对编程者的便利性)来说,方法2是更好的。

目前EDA工具发展的情况是:
1. verilog/SV调用C/C++, 用的是方法1.
2. C++调用HDL, 用的是方法2. (我只用过VCS, 至于Modelsim/NCsim是否也如此请大牛们指正)

对于C++调用HDL, 以VCS为例,其原理大概是:
1. vcs 把 HDL 编译成 *.o 和 *.h
2. C++这边通过*.h调用上一个步骤编译HDL产生的*.o
3. gcc把C的*.o和HDL的*.o链接成可执行文件

所以,目前SC和HDL之间没有标准接口,其接口机制已经被EDA工具隐藏了,不需要编程者显式调用。
80 字节以内
不支持自定义 Discuz! 代码

使用道具 举报

Rank: 20Rank: 20Rank: 20Rank: 20Rank: 20

注册时间
2010-9-18
积分
4105
发表于 2010-10-17 12:21:07 |显示全部楼层
本帖最后由 cqq 于 2010-10-17 15:18 编辑

聊到这里,我想到另外一个话题

目前各个公司做ESL/写C Model基本是由架构组在弄。
架构组的工作职责可归结为2大点:
1. 学习算法,在了解算法的基础上对算法做一些架构上的规划(不懂具体算法一般做不出好架构),进而抽象出一套软硬件架构,并提供与之对应的C Models
2. 对仿真手段的选择/使用/提高:使用什么语言/工具,如何提高仿真速度。

我比较好奇对于职责2中的提高仿真速度这一点,一般是些什么人再弄。因为为了提高速度,采用的技术手段通常都是软件领域的手段了,跟IC设计已经关系不大。我目前的实践也是比较土,都是架构组成员自己想办法倒腾,如ic.expert兄所说,需要耗费时间精力,通常不便尝试。

呵呵,比较好奇其它公司在磨练/提高仿真手段方面,是怎么做的。
80 字节以内
不支持自定义 Discuz! 代码

使用道具 举报

Rank: 8Rank: 8

注册时间
2010-9-4
积分
165
发表于 2010-10-18 22:21:37 |显示全部楼层
感谢大牛的指点,一语中的,问题确实就是细粒度和粗粒度的问题。



我想把这问题提到更广大的范围来讨论 ...
cqq 发表于 2010-10-17 12:03



    vcs是唯一一个编译型的仿真器,ncsim和modelsim都是解释型的。
所以vcs里面systemc和HDL之间互相调用比较方便。
好像其他都提供了接口,但是非标的。
所以,如果公司使用某一个具体的仿真器,可以针对其做优化。
但是开源项目,我觉得一定要使用标准的接口。开源的HDL项目,最好还是使用标准接口。
在icarus上也要仿真的。

各个公司对SAE(系统架构师)的定义是不一样的。一般来说要求熟练使用UML,没有说过对C/HDL熟练的。
类似SE(系统工程师)和DE(设计师)定义在各个公司都不一样。
RTL solution & Development

使用道具 举报

Rank: 8Rank: 8

注册时间
2010-9-4
积分
165
发表于 2010-10-18 22:23:23 |显示全部楼层
另外,仿真速度最快的仿真器应该是ncsim,不是vcs

不知道为什么解释型的比编译型的要快。
RTL solution & Development

使用道具 举报

Rank: 1

注册时间
2010-8-19
积分
17
发表于 2010-10-20 08:46:14 |显示全部楼层
另外,仿真速度最快的仿真器应该是ncsim,不是vcs

不知道为什么解释型的比编译型的要快。 ...
tianguau 发表于 2010-10-18 22:23

NCSim 是解释型的?在我印象中好像除经典的Verilog-XL还是解释型的外,Cadence的HDL仿真器都是编译型的了。难道我记错了?
HIT MEC

使用道具 举报

Rank: 8Rank: 8

注册时间
2011-12-6
积分
146
发表于 2011-12-9 08:47:06 |显示全部楼层
ncsim是编译型的。不过我的测试表明,OSCI的simulator居然比ncsim还要快。

使用道具 举报

Rank: 1

注册时间
2014-11-27
积分
15
发表于 2015-2-13 11:17:24 |显示全部楼层
看了各大神的评述,感觉醍醐灌顶啊!
神贴一枚,各种受教!!!

使用道具 举报

Rank: 16Rank: 16Rank: 16Rank: 16

注册时间
2015-1-29
积分
2226
发表于 2015-3-3 11:14:08 |显示全部楼层
但是systemverilog +DPI是不是只支持 C 模型不能支持 C++模型?

使用道具 举报

Rank: 4

注册时间
2016-2-23
积分
21
发表于 2016-2-23 18:50:40 |显示全部楼层
各位大牛,最近看你们帖子里的讨论后受益匪浅,不过还是有很多疑问,不知你们是否还经常在这论坛上逛,请教一点:HDL和SC/C的联合仿真,用SC建模或是C++建模有什么区别吗?都是通过PLI或是DPI接口,SC建模能周期精准?C++建模就只能是untime吗?两者有何区别,如果非要用C++建模,需要注意什么啊,刚接触这些,忘指点一下?

使用道具 举报

Rank: 12Rank: 12Rank: 12

注册时间
2015-3-1
积分
760
发表于 2016-3-1 20:01:10 |显示全部楼层
好东西要赞

使用道具 举报

最近看过此主题的会员

您需要登录后才可以回帖 登录 | 注册

‹‹
我的工具栏

关于我们|手机版|Archiver|开源计算机图形学社区(Open Source Computer Graphics Community) | OpenGPU Project | OpenGPU Forum (2007-2013)

GMT+8, 2017-4-24 19:19 , Processed in 0.113247 second(s), 13 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部