行业工程师对IC验证的理解
ic验证方法
ic验证方法IC验证方法是集成电路设计中非常重要的一环，它用于验证设计的正确性和功能性。
在集成电路设计中，IC验证方法是确保设计能够按照预期工作的关键步骤之一。
本文将介绍几种常见的IC验证方法，包括仿真验证、形式验证和硬件验证。
一、仿真验证仿真验证是最常用的IC验证方法之一。
它通过在计算机上模拟设计的工作情况来验证其正确性和功能性。
在仿真验证过程中，设计人员使用一种称为电路模拟器的软件工具来模拟集成电路的行为。
通过输入一组测试数据，电路模拟器可以模拟电路的输入和输出情况，从而判断设计是否按照预期工作。
仿真验证方法有两种主要类型：功能仿真和时序仿真。
功能仿真用于验证电路的逻辑功能是否满足设计要求。
时序仿真则用于验证电路的时序性能是否满足设计要求。
通过对设计进行这两种仿真验证，可以全面地评估电路的正确性和性能。
二、形式验证形式验证是一种基于数学推理的IC验证方法。
它通过使用形式化规范语言来描述设计的行为，并使用形式验证工具来自动验证设计是否满足规范。
形式验证方法可以在设计的所有输入条件下进行验证，因此可以发现设计中的潜在错误和漏洞。
形式验证方法的优势在于它可以提供严格的证明，而不仅仅是模拟验证中的几个测试用例。
然而，形式验证需要设计人员具备一定的数学和逻辑推理能力，并且对于复杂的设计，形式验证的时间和资源成本可能会很高。
三、硬件验证硬件验证是一种在实际硬件上验证设计的方法。
它通过将设计加载到芯片或FPGA等硬件平台上，并使用实际的输入数据来测试电路的功能和性能。
硬件验证可以提供最接近实际工作条件的验证环境，因此可以发现仿真验证中无法发现的问题。
硬件验证通常需要设计人员具备一定的硬件开发和调试能力。
在硬件验证过程中，设计人员需要使用测试仪器和设备来观察电路的行为，并根据观察结果进行调试和修复。
IC验证方法在集成电路设计中起着至关重要的作用。
通过仿真验证、形式验证和硬件验证等方法，设计人员可以全面地验证设计的正确性和功能性。
ic岗位种类
ic岗位种类
IC岗位种类多种多样，以下是一些常见的IC岗位种类：
1. IC设计工程师：负责集成电路（IC）的设计和验证工作，
包括电路设计、电路模拟、布局设计等。
2. 集成电路工艺工程师：负责集成电路制造过程中工艺流程的开发和控制，包括微纳米加工技术、工艺改进等。
3. 物理验证工程师：负责集成电路的物理验证，包括电路布局、线路规划、信号完整性等。
4. 芯片封装工艺工程师：负责芯片封装程序的工艺流程开发和控制，包括封装设计、封装工艺改进等。
5. 射频工程师：负责射频（RF）电路的设计和验证，包括射
频电路设计、天线设计、射频测试等。
6. 数字信号处理工程师：负责数字信号处理算法的设计和验证，包括信号处理算法研发、算法实现等。
7. 模拟电路工程师：负责模拟电路设计和验证，包括放大器、滤波器、功率电路等的设计和模拟。
8. 自动化测试工程师：负责集成电路的自动化测试工作，包括测试程序的开发、测试设备的选型和维护等。
9. FPGA工程师：负责现场可编程门阵列（FPGA）的设计和验证工作，包括FPGA的编程、逻辑设计等。
10. 工艺工程师：负责集成电路制造工艺的开发和改进，包括工艺流程、工艺设备等的研究和优化。
以上只是部分IC岗位种类，随着技术的不断发展和更新，IC 领域的岗位种类也在逐渐增加和变化。
关于IC验证经验的总结
关于IC验证经验的总结完整的、详细的设计规范是验证工作的重要起点。
验证工作根据设计规范（Specification）进行，详细的Spec是RTL代码的编写工作的依据，也是验证工作的依据。
当验证过程发现DUT的响应与testbench预计的不符时，需要根据Spec判断是DUT出现错误还是testbench出现错误。
参数化的全局定义∙Register相关位及其数值的全局宏定义。
reg_define.v∙相关路径的全局宏定义。
define_board.v∙系统重要变量的显示信息。
display.v∙与Register相关的比较任务和报错任务。
reg_cmp∙时钟周期参数的定义，一般局部定义，用parameter定义。
存取波形及相应变量的数据，使用`ifdef为全局定义使用1.波形源头文件是VCD波形，但过于庞大，可用来做功耗分析。
$dumpfile(“wave.vcd”);$dumpvars(0,xxx);$dump0ff;$dumpflush;2.SHM波形是Cadence的，可以用simvision打开。
$shm_open(“wave.shm”);$shm_probe(xxx,“AST”);$shm_close;3.FSDB波形是Novas的，可以用nwave打开。
$fsdbDumpfile(“wave.fsdb”);$fsdbDumpvars(0,xxx);4.VPD波形是Synopsys的，可以用dve打开。
$vcdplusfile(“wave.vpd”);$vcdpluson(0,xxx);5.变量的存取，可以使用宏来选择变量的存取与否与存取时间使用。
`ifdef SAVE_LROUTstart_save=1’b1;#(10e6)stop_save=1’b1;`endifxxx=$fopen(“xxx”,“w”);if(start_save&&!stop_save)$fwrite(xxx,“%f\n”,x);$fclose;测试案例，case1．case本身尽可能模块化。
芯片测试与验证的重要性
芯片测试与验证的重要性芯片测试与验证的重要性现代科技的快速发展使得芯片在我们生活中的重要性不可忽视。
芯片作为电子产品的核心组成部分，其性能和稳定性对整个设备的工作效果和可靠性产生直接影响。
因此，芯片测试与验证成为保证芯片质量的重要环节。
本文将探讨芯片测试与验证的重要性，并简要阐述其在不同领域的应用。
一、芯片测试与验证的意义芯片测试与验证是在芯片设计完成后对其性能、运行稳定性及兼容性等方面进行全面检测和验证的过程。
它可以帮助开发者发现和修复芯片设计过程中所产生的错误，确保芯片在实际应用中的可靠性。
具体来说，芯片测试与验证的意义主要体现在以下几个方面：1.确保芯片性能和稳定性：通过测试和验证，我们可以确保芯片在各种工作环境下的性能和稳定性。
这将有助于提高芯片的可靠性，确保其正常工作。
2.提高芯片的生产效率：芯片测试与验证可以帮助开发者在芯片设计阶段尽早发现问题并进行调整和修复。
这有助于缩短产品开发周期，提高生产效率。
3.减少开发成本：通过芯片测试与验证，我们可以在设计阶段及时发现并纠正问题，减少了在后期生产和应用过程中出现问题的成本，从而降低了整体开发成本。
二、芯片测试与验证的方法芯片测试与验证涉及多种方法和技术。
常见的测试和验证方法包括：1.功能测试：对芯片的功能进行全面测试，确保各项功能正常运行。
例如，针对特定芯片的指令集进行测试，验证其是否按照设计规范执行。
2.性能测试：测试芯片在不同负载条件下的性能表现，包括计算能力、存储容量、响应速度等。
通过性能测试，我们可以评估芯片的实际工作能力。
3.电气测试：测试芯片的电气特性，例如电流、电压、功耗等。
这些测试可以帮助开发者确定芯片在各种工作条件下的电气性能。
4.兼容性测试：验证芯片与其他硬件或软件的兼容性，确保其可以正常与其他设备进行通信和协作。
5.可靠性测试：通过长时间运行测试和极限条件测试来评估芯片的可靠性。
例如，在高温、低温、高湿度等环境条件下测试芯片的工作情况。
IC测试工程师岗位职责简洁版(二篇)
IC测试工程师岗位职责简洁版IC测试工程师的主要职责是进行集成电路（Integrated Circuit，简称IC）的测试和验证工作。
具体职责包括：1. 制定测试计划和测试策略：根据IC设计规格和测试需求，制定相应的测试计划和测试策略，确保测试工作的高效进行。
2. 设计测试方案：根据测试计划和测试策略，设计测试方案，包括测试流程、测试程序和测试设备的选择等，确保测试的全面性和准确性。
3. 开发测试程序：使用测试编程语言（如C/C++、Python等）开发测试程序，实现对IC的自动测试和验证，提高测试效率和测试精确度。
4. 进行测试和数据分析：使用测试设备进行IC的测试，并进行测试数据的采集和分析，确保IC的性能和功能达到设计要求。
5. 故障排除和修复：分析测试数据，识别IC的故障和问题，并进行故障排查和修复，确保IC的质量和可靠性。
6. 编写测试报告：根据测试结果和分析，编写测试报告，汇总测试数据和问题，提供有效的测试反馈和改进建议。
7. 参与测试流程改进：根据测试经验和问题反馈，参与测试流程的改进工作，提高测试效率和质量。
8. 与相关部门协作：与IC设计团队、制造团队和质量团队等紧密合作，共同完成IC的测试和验证工作。
总之，IC测试工程师负责进行IC的测试和验证工作，确保IC的性能和功能符合设计要求，提供有效的测试反馈和改进建议，以提高IC的质量和可靠性。
IC测试工程师岗位职责简洁版（二）IC测试工程师是集电子技术、自动化技术和测试管理技能于一身的专业人员，主要负责测试集成电路(IC)产品的性能、可靠性和功能。
以下是一个IC测试工程师的岗位职责模版，具体的职责根据实际工作环境和公司需求可能会有所不同，需要根据具体情况进行调整。
一、IC测试策略和计划1. 根据产品规格和测试需求，制定合适的IC测试策略，并进行测试计划的制定和优化。
2. 研究和选择合适的测试设备、工具和软件，并进行测试方案的开发和调试。
IC验证报告
IC验证报告概述本报告旨在对IC的验证结果进行分析和总结。
IC验证是一项重要的过程，它验证了IC的设计与规格之间的一致性，确保IC的功能和性能符合预期。
验证方法在IC验证过程中，我们采用了以下方法和工具：1. 功能仿真：使用仿真工具对IC的逻辑功能进行仿真验证，确保各个逻辑部分的正确运行。
2. 时序仿真：通过时序仿真验证，确保IC的时序符合设计要求，与规格一致。
3. 电气仿真：通过电气仿真验证，确保IC的电气性能满足设计要求，例如电压范围、功耗等。
4. 特殊测试：对IC的特殊功能进行测试，以验证其在各种特殊情况下的表现。
验证结果通过IC验证过程，我们得到了以下结果：1. 功能一致性验证：IC的各个逻辑功能均正常工作，与设计规格一致。
2. 时序一致性验证：IC的时序满足设计要求，与规格一致。
3. 电气性能验证：IC的电气性能符合设计要求，例如电压范围、功耗等。
4. 特殊功能测试：IC在各种特殊情况下表现良好，无异常现象。
总结通过IC验证过程，我们确认了IC的功能和性能与设计规格一致。
这表明IC的设计和制造工艺是成功的，可以继续进行后续生产和应用。
在验证过程中，我们采用了多种方法和工具，确保了验证结果的准确性和可靠性。
推荐措施为了进一步提高IC的质量和性能，我们推荐以下措施：1. 继续优化设计和制造工艺，以提高IC的性能和可靠性。
2. 定期进行IC验证和测试，以确保每一批IC的质量和性能达到预期。
3. 不断研究和应用新的验证技术和方法，以跟上行业的发展趋势。
我们相信，通过以上的措施，我们能够进一步提高IC的质量和性能，为客户提供更好的产品和服务。
iqc芯片检验个人工作总结
iqc芯片检验个人工作总结作为IQC芯片检验员，我的工作主要是负责对进货的芯片进行初步检验，确保其质量符合公司的要求。
在工作中，我遵循严格的检验流程，精确地测试每一块芯片的功能和性能，保证产品的稳定性和可靠性。
在工作中，我学到了很多关于芯片的知识，包括不同芯片的性能特点和测试方法。
通过持续学习和实践，我提高了自己的检验技能和分析能力，能够快速准确地发现产品中的问题并提出解决方案。
我也学会了如何与供应商进行有效沟通，并及时反馈产品质量情况，以便及时解决问题并提高产品品质。
在工作中，我还意识到了质量管理的重要性。
我时刻牢记自己的责任和使命，将产品质量放在首位，不轻易放过任何可能存在的质量问题。
在与同事合作的过程中，我也懂得了团队协作的重要性，时刻保持良好的沟通和合作，共同为公司的发展贡献自己的力量。
总的来说，通过IQC芯片检验工作，我获得了很多宝贵的经验和收获。
我将继续不断提升自己的技能和知识水平，为公司的发展贡献自己的力量，为客户提供更具竞争力和高品质的产品。
I will continue to upgrade my skills and knowledge, and contribute my strength to the company's development, providing customers with more competitive and high-quality products.在IQC芯片检验的个人工作总结中，我还要提到在工作中遇到的挑战和如何应对。
有时候，我会遇到一些复杂的技术问题，需要借助相关资料和专业人士的帮助来解决。
在这个过程中，我会不断学习，积累更多的经验，以便更好地应对类似的问题。
此外，作为一名IQC芯片检验员，我要求自己保持高度的专注和细致，因为任何一个疏忽都可能导致产品质量的问题。
因此，我经常进行自我反思和总结，找出自己的不足之处，然后努力改进，提高工作效率和准确性。
芯片设计验证分析确保设计符合规范与要求
芯片设计验证分析确保设计符合规范与要求芯片设计验证分析是确保芯片设计符合规范与要求的关键步骤。
在芯片设计中，验证分析可以帮助设计团队发现并解决潜在的问题，确保设计的可靠性和稳定性。
本文将探讨芯片设计验证分析的重要性，并介绍一些常用的验证方法和技术。
一、芯片设计验证分析的重要性芯片设计验证分析是芯片设计过程中不可或缺的一步。
它可以帮助设计团队发现设计中的问题并加以解决，确保设计的正确性和可用性。
验证分析还可以提前发现潜在的故障和缺陷，避免芯片制造过程中的延误和成本增加。
此外，验证分析还可以提高芯片的可靠性和稳定性，减少故障率，提升产品的竞争力。
二、常用的芯片设计验证方法和技术1. 功能验证：通过验证芯片的功能是否符合设计规范和要求。
这通常包括设计复杂的测试用例，模拟各种工作负载，检查芯片的输出是否与预期结果一致。
功能验证可以发现设计中的逻辑错误和功能缺陷。
2. 微结构验证：通过验证芯片的微结构是否符合设计要求。
这包括验证芯片的物理结构、排布布局、连线等是否符合设计规范。
微结构验证可以发现布局错误和连线问题，确保芯片的电路完整性和信号可靠性。
3. 时序验证：通过验证芯片的时序特性是否符合设计要求。
时序验证可以发现时钟信号的延迟、时序逻辑错误等问题，确保芯片的时序工作正常。
4. 功耗验证：通过验证芯片的功耗是否符合设计要求。
功耗验证可以帮助设计团队发现功耗过高的部分，并优化设计以降低功耗。
5. 安全验证：通过验证芯片的安全性是否符合设计要求。
安全验证可以发现芯片中的漏洞和安全风险，并提供相应的改进措施。
三、芯片设计验证分析的流程芯片设计验证分析通常分为五个步骤：需求分析、设计分析、实施验证、分析结果和修复。
首先，需求分析阶段需要明确芯片设计的规范和要求，以确保验证的准确性。
然后，在设计分析阶段，设计团队将验证目标转化为实际测试用例，并制定验证计划。
在实施验证阶段，设计团队会根据验证计划进行测试，记录和分析验证结果。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
行业工程师对IC验证的理解行业工程师对IC验证的理解-下面这些问题和回答是基于我个人对验证（主要是动态仿真验证）的理解，可能有理解的不到位、理解有偏差的地方，欢迎大家指正。
Q：验证的目的？A：发现Bug，发现所有的Bug，或者证明没有Bug（转自夏晶的帖子）Q：对验证工程师的要求？Hacker mentality ，Organized testing ，Tool automation。
如何做更多的testcase、如何覆盖更多的测试点、如何充分的利用服务器、如何尽可能最大化的自动比对强调一下：“注重细节”是验证工程师一个非常非常好的工作习惯。
Q：语言、方法学有多重要？A：我的观点是：这两个都不重要。
做事情的是验证工程师，来源是Spec，所以Testplan （全覆盖testplan）最重要。
重要的是验证的意识，愿不愿意去实现H-O-T，即使一开始做的“土”一些也没关系。
比如tb里经常要做的“自动比对功能”：1）维护queue，然后foreach的比较2）利用file-operation （fopen fread fwrite fscanf）来做文件比对3）直接$system(diff a b > c)以后看c文件大小。
上述三种方法都可以（虽然2）会导致比较多的文件IO，硬盘读写会影响仿真速度，3）不能做实时的比对。
不必拘泥于方法，关键是有这个意识。
Q：EDA行业对验证的支持？A：个人感觉虽然(动态)验证这些年在理论方面的突破不大（静态验证一直是热点），但是EDA行业一直都很重视，实现类的工具主要是在做算法优化，这些年突破不大。
但是验证方向上的点工具一直在不停的出（虽然最终可能也没有几个好使的工具），但是说明EDA行业一直在致力于寻求在验证上的突破。
而且由于现在做SoC的太多，IP又太多，大家都是越来越重视验证，很多上规模的公司里验证人员较设计人员多不少。
个人觉得这可能也是EDA重视验证的一个原因（用牛工具替代掉一些人LL）。
Q：如何跟踪缺陷？A：可以考虑bug-zillar这类的工具---- 自动跟踪问题。
Q：作业提交系统（lsf或grid-engine）A：充分和合理的利用计算资源。
Q：环境变量的管理？A：个人推荐使用Module 工具。
很多公司都是用这个免费的工具Q：Testbench用到的编程语言？A：我觉得tb里systemverilog和verilog是可以互相替换（当然了，systemverilog特有的内容用verilog来实现会很复杂），所以推荐tb基于systemverilog来搭建，一些仿真模型可以用verilog。
C除了Cmodel以外，firmware也会用C和汇编写。
基本上我做过的项目里用到的语言：脚本：perl、makefile、shell（perl用的很多，其他用的很少）Tb（包括vmm的组件）：基本是systemverilog仿真模型：systemverilog和verilog混着用Cmodel ：C或C++Firmware ：汇编和CQ：验证工程师需要掌握的基本技术？A：分享一份我做的基本培训内容安排，供参考Perl，Makefile，AMBA介绍，SVTB.pdf ，sva,几种用到的编程语言的File operation ，Low-power，C-pointer，Cshell-AWK+SED，体系结构相关的一些内容，SV-1Day training ，VMM_source_code ,Arm的嵌入式编程的基本概念Q：自动化必须吗？A：不是必须的，但是应该尽量去实现自动化。
总之是多让机器跑。
如果人均License太少的话，要尽量做到白天debug、晚上让机器跑。
“比对”这种事情太机械了，所以尽量让机器做，做这种事情机器的效率比人高太多。
把精力放在构造testcase、testbench、coverage以及debug和分析上。
Q：Testplan如何做？A：形式不重要，xls可以、word也可以、txt 的也可以。
但是来源于Spec！testplan里除了要罗列function-test-piont，还应该有error-injection 和random-test-point以及cover-point和assertion。
需要和各个team仔细逐条review testplan，有些针对具体实现的coverpoint可能只有designer能提出来，需要尽早提出。
Tb搭建之前，要充分的review testplan，因为Testplan的较大修改有可能会导致整个testbench的架构调整，effort较大。
Testplan 是一个需要不停增加，不停迭代、不停review的东西。
Error injection要和RTL-designer逐条review，一个是看看RTL-designer是不是没有想到，一个是设计是不是本身就不允许、或者架构上本身不可能出现。
Error-injection 应该往深里去好好挖掘。
例如：内存控制器长时间不回数据（这里本身是一个随机点）à由于长时间不回数据是否产生错误中断à产生错误中断以后如何响应à响应不过来如何恢复à必须用software reset做恢复的话，对software的时机是否有要求àsoftware前需要遵守什么要求和步骤虽然现在有一些工具可以根据规范化描述的testplan自动生成cover-point和assertion，不过我觉得自然语言描述的testplan应该是最“自然”的。
Q：哪些地方做随机？A：1）随机配置（一般都想得到的），但是对于一个封闭的系统常常是最不重要的，因为firmware可以自己开发，从而控制配置的流程和数值2）随机激励数据（很重要）3）随机时序（通常容易被忘记）但是有一点要明确：随机不是全随机，是约束随机，是在合理的范围内尽量充分的随机。
Q：写约束随机哪些地方要注意？A：推荐看snug paper。
(over-constraint导致测试不完全，欠约束导致不必要的debug 和资源的浪费)约束的效率：写的不好会导致随机失败Q：Coverage如何做？A：code-coverage和function-coverage （covergroup, assertion coverage）。
对于constraint-random的地方用covergroup做，对于一些时序的coverage可以用assertion-coverage。
Q：核心脚本？A：单个仿真的脚本---- 建立所使用的不同的目录、不同的seed（目录可以叫case_$seed这样的格式；当然对于直接的testcase，可以是case_$casename）；环境变量和license的管理；如果需要做离线比对也可以让脚本来自动调用比对脚本或命令（也可以在tb的代码里使用$system或者$systemf）。
批量仿真的脚本----自动批量提交到lsf上。
自动收集log信息以判断哪些case失败，对于失败的case能自动重新提交，并且自动dump波形。
以及产生批量仿真结束以后的汇总信息。
Q：SV中重要的点？A：特殊的数据类型，比如新增的三种array （动态、associate、queue）、string（match 函数、backref函数，参考vcs的svtb.pdf）；面向对象编程思想（handle）；coverage；constraint-random。
熟练掌握这些语言点的用法很有必要。
Q：VMM 1.0够不够？A：刚开始用1.0来建立起vmm的概念，然后转到1.1或者1.2上。
个人觉得不是必须一下子就转到1.1或1.2上（当然，1.1的一些扩展宏的确很好用）。
个人建议vmm1.0+1.1的扩展宏+subenvQ：是否要使用VIP？A：VIP的使用--- 复杂仿真模型推荐用VIP，简单的建议自己做。
如果自己开发仿真模型的话，也推荐看看VIP的文档，经常可以看到一些有价值的error-injection和random-test-points来完善你自己的testplan。
Q：要不要做门级仿真？A：如果是走design-service，不知道最终带sdf的netlist仿真是否需要做，如果做的话，最好在release 综合后netlist的时候也做一下（插完scan-chain和做完CTS以后有条件也做一下），如果需要VCD文件做power分析和指导PR工具的话，那么门仿是必须做的。
如果design-service公司不负责调量产pattern的话，那么ATPG等的门仿是需要自己做的。
门仿并不是sign-off标准，但是推荐还是做一下，经常还是能跑出问题来的。
如果做sdf反标的门仿的话，对于async的多级dff要剔除掉（VCS和NC都有option，vcs可以查手册里“+optconfigfile”,NC查”+nctfile”）。
反标Sdf仿真的时候推荐notimingcheckàno_notifyàchecking_timing with optconfigfile 的三步走。
前期在评估IP的时候，有可能个别模块可能需要单独搭门级环境，比如CPU-IP有RTL，要自己做flow，那么通常是需要做门仿的（有可能主要是为了跑vcd或saif做power 分析）。
Tb的修改：由于CTS和综合的原因，导致时钟名字和信号名字有变化，所以tb有可能要修改。
另外，tb里的probe文件建议使用反沿采样，也是为了避免带sdf反标以后clk踩不到整个data-vector。
除此之外，个人不太建议在门仿的时候依然使用自动化的tb。
因为你的tb里抓的很多内部信号可能名字变了（或者被优化掉了），这样导致tb在门级跑的时候维护起来有些麻烦。
有些信号即便名字不变，可能会反向，这样会导致你的checker误报错。
毕竟在门仿的时候不用跑太多的testcase，可以靠几条和rtl 仿真一一对应的仿真来覆盖。
门仿毕竟不是为了function，而是为了检查timing。
如果你的设计里用了不带reset的dff的描述，由于开始不定态的传播，可能导致你门仿失败。
个人推荐的方法是：如果特别多的话，用脚本找到对应模块里所有dff，产生一个force-release文件（注意：很影响编译时间，所以能不用就不用）Q：FPGA和仿真如何安排顺序？A：首先是schedule优先，其次是力所能及。
但是原则上是先仿真然后再上FPGA，仿真可以很快的扫清一些基本的bug。
给仿真的时间充裕的话，那就仿真尽量往前赶，尽量在上FPGA之前多测一些（不是太多case的情况下，FPGA的测试速度毕竟要快一些）。