怎么能使Simulink的仿真速度更快?
时间:08-19
来源:互联网
点击:
作者:paradoxfx
现在的专业软件都是越做越大,功能成倍成倍地增加,而处理的对象也是越来越复杂,特别是使用一些仿真软件在高精度下建模仿真的时候,因为PC上硬件的发展速度慢于软件功能复杂化的速度,就造成了我们的仿真看起来是越跑越慢了。那以电子、通信、控制等领域都广泛使用的Simulink为例,有没有什么好的办法能让我们的仿真速度更快一点呢?在此总结一下,我们可以在以下的几点中进行一些改进。
首先是模型的搭建问题。在Simulink环境中建模时,以s域的表达式进行建模时问题要少一些,增大误差限、取消过零检测等可以提高发展速度,减少警告信息。而z域的情况下要注意的问题会多一点。第一点是把模型中的代数环(Algebraic Loop)要消除掉;因为z域处理的数据都是一拍一拍按照采样周期处理的,所以如果一个数据既作为输入,同时又无延时地作为输出,就产生了数值处理的问题,造成仿真速度显著下降,处理的方法一般也不难,把反馈加一个延时环节就好了。另外就是仿真步长的问题,在能保证仿真精度的情况下,尽量使用大的步长可以显著提高仿真速度;这个最大的仿真步长自然可以按照香农采样定律来确定,但是一般情况下选择仿真步长为4-10倍的最大采样频率是足够了。
其次是可以改变仿真的模式。在老版本Simulink中,这个选择很少,但是新版本有了Normal、Accelerator和Rapid Accelerator、HIL等模式。硬件在回路HIL显然速度最快,但是好多时候并不适用,因为首先要有相应的硬件,其次是仿真对象要支持代码生成。因为Simulink用的是一种解释性的语言,normal模式就可以理解为Matlab解释一句,操作系统执行一句,速度自然不会太快;Accelerator则是把一部分共享模块编译为库文件,例如dll进行调用,相当于混合模式,既有解释-执行,也有直接调用,速度;Rapid Accelerator则是把整个模型编译为操作系统下独立运行的程序,少了Simulink解释给操作系统的工作,自然运行速度快,代价则是需要一定的时间来编译模型;这种模式对PC的硬件配置要求是相对比较高的,内存少于3GB时容易出错。
再者就是有一些模块会显著拖慢仿真速度,它们相当于“木桶理论”中的那块“短板”了。例如Simulink中的X-Y图这样实时刷新绘图的模块。如果模式中有这个模块,则仿真的时候它会缓慢地刷新X-Y图,仿真速度肯定快不了。如果有别的方法替代则可以加快仿真速度,例如先把数据保存到工作空间里,等仿真结束之后再绘制X-Y图等。一些非线性的模块,例如一个非线性的MOSFET模型,自然也比理想开关所需要的仿真时间长。
第四种方法是并行执行和分布式执行,相当于多个人一起完成一项工作,前提是要有并行执行的许可和分布式执行的许可。并行执行就是在多核CPU的计算机上,打开多个Matlab,然后自动或者手动分配进行并行处理;分布式执行则是多台计算机使用高速网络互联之后分别处理。这种仿真方法其速度提高非常显著,特别是在处理大量迭代计算的时候,不过不是一般的开发者所能具备的。
此外,从2012b以后的版本开始,Simulink自带了Simulink Performance Advisor工具,可以帮助我们发现影响仿真速度的瓶颈,并提出相应的建议。不过它无法或者我们搭建模型的意图是神马,所以还需要我们在搭建模式的时候就按照前面几条建议进行一些必要的修改。
现在的专业软件都是越做越大,功能成倍成倍地增加,而处理的对象也是越来越复杂,特别是使用一些仿真软件在高精度下建模仿真的时候,因为PC上硬件的发展速度慢于软件功能复杂化的速度,就造成了我们的仿真看起来是越跑越慢了。那以电子、通信、控制等领域都广泛使用的Simulink为例,有没有什么好的办法能让我们的仿真速度更快一点呢?在此总结一下,我们可以在以下的几点中进行一些改进。
首先是模型的搭建问题。在Simulink环境中建模时,以s域的表达式进行建模时问题要少一些,增大误差限、取消过零检测等可以提高发展速度,减少警告信息。而z域的情况下要注意的问题会多一点。第一点是把模型中的代数环(Algebraic Loop)要消除掉;因为z域处理的数据都是一拍一拍按照采样周期处理的,所以如果一个数据既作为输入,同时又无延时地作为输出,就产生了数值处理的问题,造成仿真速度显著下降,处理的方法一般也不难,把反馈加一个延时环节就好了。另外就是仿真步长的问题,在能保证仿真精度的情况下,尽量使用大的步长可以显著提高仿真速度;这个最大的仿真步长自然可以按照香农采样定律来确定,但是一般情况下选择仿真步长为4-10倍的最大采样频率是足够了。
其次是可以改变仿真的模式。在老版本Simulink中,这个选择很少,但是新版本有了Normal、Accelerator和Rapid Accelerator、HIL等模式。硬件在回路HIL显然速度最快,但是好多时候并不适用,因为首先要有相应的硬件,其次是仿真对象要支持代码生成。因为Simulink用的是一种解释性的语言,normal模式就可以理解为Matlab解释一句,操作系统执行一句,速度自然不会太快;Accelerator则是把一部分共享模块编译为库文件,例如dll进行调用,相当于混合模式,既有解释-执行,也有直接调用,速度;Rapid Accelerator则是把整个模型编译为操作系统下独立运行的程序,少了Simulink解释给操作系统的工作,自然运行速度快,代价则是需要一定的时间来编译模型;这种模式对PC的硬件配置要求是相对比较高的,内存少于3GB时容易出错。
再者就是有一些模块会显著拖慢仿真速度,它们相当于“木桶理论”中的那块“短板”了。例如Simulink中的X-Y图这样实时刷新绘图的模块。如果模式中有这个模块,则仿真的时候它会缓慢地刷新X-Y图,仿真速度肯定快不了。如果有别的方法替代则可以加快仿真速度,例如先把数据保存到工作空间里,等仿真结束之后再绘制X-Y图等。一些非线性的模块,例如一个非线性的MOSFET模型,自然也比理想开关所需要的仿真时间长。
第四种方法是并行执行和分布式执行,相当于多个人一起完成一项工作,前提是要有并行执行的许可和分布式执行的许可。并行执行就是在多核CPU的计算机上,打开多个Matlab,然后自动或者手动分配进行并行处理;分布式执行则是多台计算机使用高速网络互联之后分别处理。这种仿真方法其速度提高非常显著,特别是在处理大量迭代计算的时候,不过不是一般的开发者所能具备的。
此外,从2012b以后的版本开始,Simulink自带了Simulink Performance Advisor工具,可以帮助我们发现影响仿真速度的瓶颈,并提出相应的建议。不过它无法或者我们搭建模型的意图是神马,所以还需要我们在搭建模式的时候就按照前面几条建议进行一些必要的修改。
- 在采用FPGA设计DSP系统中仿真的重要性 (06-21)
- 数字频率合成器的FPGA实现(08-07)
- 基于DSP的导弹仿真器嵌入式组件设计(04-30)
- 如何将DSP和MCU两者完美结合(08-10)
- 高性能仿真器与开发包加速普及DSP应用开发(11-22)
- 基于DSP内嵌PCI总线的卫星信号仿真器设计(04-17)