随着社会越来越发达，大家都选择在网络上汲取相关知识内容，比如modelsim仿真软件介绍，为了更好的解答大家的问题，小编也是翻阅整理了相应内容，下面就一起来看一下吧！
1、 仿真的目的：
(资料图片仅供参考)
在软件环境下，验证电路的行为和设想中的是否一致。
2、 仿真的分类：
a) 功能仿真：在RTL层进行的仿真，其特点是不考虑构成电路的逻辑和门的时间延迟，着重考虑电路在理想环境下的行为和设计构想的一致性;
b) 时序仿真：又称为后仿真，是在电路已经映射到特定的工艺环境后，将电路的路径延迟和门延迟考虑进对电路行为的影响后，来比较电路的行为是否还能够在一定条件下满足设计构想。
3、 功能仿真的目的：
a) 设计出能工作的电路：因此功能仿真不是一个孤立的过程，其和综合、时序分析等形成一个反馈工作过程，只有这个过程收敛，各个环节才有意义。而孤立的功能仿真通过是没有意义的，如果在时序分析过程中发现时序不满足需要更改代码，则功能仿真必须从新进行。因此正确的工作流程是：
b)代码排错：功能仿真是代码排错的最重要的手段之一。
4、 modelsim的高级功能：Code Coverage
a) 代码覆盖率是验证激励是否完备，检验代码质量的一个重要手段。测试激励的代码覆盖率至少要达到95%以上，才能基本认为代码在逻辑上是通过质量控制的，才能进入综合步骤;
b) 代码覆盖率是保证高质量代码的必要条件，但却不是充分条件。即便代码行覆盖和分支覆盖都能够达到100%，也不能肯定的说代码已经得到100%的验证。除非所有的分支覆盖都能够进行组合遍历。
c) 在大的设计中，如果想通过一个激励就验证完一个设计或者模块是不现实的。一方面是从逻辑功能上很难做到;另外一方面是因为如果在一个激励中包括了各种情况，整个仿真过程的速度会随着计算机内存的消耗而成线性下降，效率低下。
d) 通常的做法是每一个激励只验证电路功能的某个方面。整个电路的功能验证由数个激励共同完成。在这种验证方法中代码覆盖率更显重要，因为可以通过代码覆盖率来控制激励对功能的覆盖程度。
e) modelsim的Code coverage不但能记录各个激励对代码的“行覆盖”和“分支覆盖”，而且能够将各个激励的覆盖记录进行合并，做到对覆盖率的全面监测。
f) 演示。。。。。。。。。。。。。。。。。。。。。。。。
5、 Debussy：仿真辅助调试工具：
a) 看仿真波形无疑是代码排错的主要手段，在 Modelsim中的波形窗口在大的仿真中有如下缺陷：a、只能显示出在仿真前设置好的信号波形，如果在仿真完成后想观察其他的信号，唯一的办法就是添加需要观察的信号从新开始仿真。b、波形只是简单显示，和代码没有对应和关联关系，不能借助波形直观的调试代码;c、如果观察的信号太多，由于其是实时全信号显示，在仿真时间较长后，仿真速度明显减慢，屏幕的刷新速度也明显减慢。
b) 这些缺点不单Modelsim有，其他的优秀仿真工具也有，而且历史由来以久，因此很早人们就提出了“先转储后观察调试”方法，在verilog语言中以$dumpXXX开头的系统函数就是做波形转储用的。就是先将波形先存在文件中，等仿真结束后在调出来显示观察和调试。
c) 这种观察功能很多EDA工具都有，并不足为奇;但Debussy的独特之处在于，它不但能显示波形，而且还能非常智能化的将波形中的任何一个变化和引起这个变化的RTL代码联系起来，使代码排错的效率大幅度提高。在原来IC所的一个大型项目中，由于引进了Debussy，使调试效率至少提高了3倍。
d) 先介绍verilog语言中的转储系统函数。其实转储函数就是一种典型的文件操作函数，最为常用的为一下几种：
i. $dumpfile(“filename.vcd”)：打开一个文件准备转储波形数据;
ii. $dumpall：转储所有信号的波形数据;
iii. $dumpvars：转储层次信号;
iv. $dumpon：开始转储;
v. $dumooff：停止转储;
e) 演示Modelsim转储功能
f) 演示Debussy工具中的辅助调试功能;
6、 SDF反标注
a) SDF是一种标准延时格式文件，用于记录综合布线后电路的线延迟和门延迟信息。如果在仿真输出的波形上叠加上这些信息，将使波形更接近实际。
b) 演示。。。。。。。。。。。。。。。。。。。。。。。。。。
c) 但是由于电路已经被综合布线过，原来的RTL代码的逻辑层次和代码命名都已经发生变化，即便看到波形也很难直接对应到RTL代码上，因此后仿真来确定电路是否符合要求的方法已经逐渐被新的方法所代替。另外还有后仿真速度缓慢也是一个主要原因。新的方法是：时序分析、静态时序分析、形式验证。
7、 一个重要的观念：电路的性能取决于电路构思和Coding Style：
a) 经常有人说“不要用写软件的方法去写硬件”，或者说“要用朴实无华的语言风格来写代码”，这些说法只是描述了事务的表明现象，并没有真正指出问题的真正症结所在;
b) RTL描述语言，虽然是一种语言，但它是描述RTL的语言，所以其着眼点是电路实现而非逻辑推理;RTL就是电路在寄存器层的一种表现，虽然已经不像门级那样具体，但也没有抽象到逻辑层。
c) 因此写代码的真正正确的方法是：在大脑中构思出电路的结构，然后用代码把它点滴不漏的表现出来，而不是先写一些只是逻辑上行得通的代码等待工具帮你综合成能实现的电路。工具永远只能做繁重而低级的工作，至少要比人的工作低级，这是未来几百年内不会改变的公理。因此如果你的电路性能不好，说明你对如何实现电路还没有清晰的思路。
d) 不要只使像通过提高器件的速度等级来使你的电路达到要求，恰恰相反，正确的方法是：如果你的电路在第一次综合后已经有80%的路径满足时间要求了，那么就不要想着用更快的器件，而应该考虑改变你的电路拓扑结构和设计构架，来使另外的20%逐渐达到要求。
