如图2所示，standalone比较适合在设计流程的尾端使用。典型情况下，这种形式的DFM工具都在设计阶段的末尾执行。虽然DFM工具也可在设计中间执行，但是与外部模块交互验证的工作一般也是在流程的末端进行的。

    根据软件的设计规则定义，DFM检查工具往往反馈大量的违规、警告、建议，这时设计者通常有3个常规的策略：

    1.减全功能全设计检查，花更多的时间做结果检视;

    2.在部分设计中进行全功能的检查，在最后一次检查中再进行全设计检查；

    3.多使用特定功能检查（而不是全功能检查），更多但更短的设计检视。

    选择1是最彻底的，因为任何违规都会被发现。不幸的是，选择1也会检出大量的设计错误，以至于有价值的检出设计错误会被大量的假象所掩盖。此外，选择1意味着在设计的后阶段设计错误才会被检出来。由于此时的设计也许已经被优化好了，所以某些布局需要做大的修改。这些修改会花费很多的资源。

    选择2是检查层次和模型设计的通用方法，尽管规则检查很全面，但是在一个支回路和相近回路中的任何违规将会丢失。由此造成的结果是，工程师不能完全信任这个模型方法，因此需要在设计循环的末端最少执行一次选择1系列以保证设计的清晰。

    选择3做为一种准交互式的设计检验方法在IC中普遍应用。

    基于网络的设计检查工具

    网络工具有多种实现方式，本文主要介绍三种。网路处理任务：仅仅通过邮件连接来获得检查工具。在执行中，用户用邮件发送GERBER给检查者；然后检查者根据其自身维护的设计规则来进行检查。错误报告会用邮件发送给用户5。

    交互式网络检查：用户在自己的本地计算机上安装客户应用软件进行DFM检查，DFM软件设计者将检查规则放在网络服务器上。每个设计检查开始前都会询问客户的检查规则是否是最新版本；如果有新的程序文件，它将下载并运行检查。

    我们至今没有发现任何一种这样的交互式网络检查工具。

    ASP模式：在这种实现方式中，执行程序置于网络服务器上，用户通过浏览器来访问。将设计文件上传后选择合适的检查项目，通过服务器的CPU运算来执行检查。这个模式类似于GOOGLE MAPS，salesforce.com等。优点是任何新的功能配制可以立即分发给该工具的所有用户，而不像客户端系统那样需要客户自己关注并更新他们的本地数据。

    交互式工具 

    交互式工具是指可在本地运行的设计环境或者能够被网络设计环境中以插件的形式在本地调用。对软硬件的详细讨论超出了该文的范围。无论怎样，读者必须熟悉这样一个观念：一个在后工序发现的设计缺陷，相比前工序发现的缺陷而言，其修复成本呈指数级增长。换句话说，错误发现的越早越容易改正并且成本更低。

    积极推动交互式DFM设计检查工具的发展是明智的。设计工程师将逐渐深入理解其设计方案如何对制造产生显著影响，设计工程师将利用这些信息做出更健壮的设计。

    在通常情况下，一个交互式解决方案是基于检查引擎的。这些检查引擎可以实时运行，也可以根据用户的需要及命令来调用。这些参数文件，或者叫做规则文件，在计算能力方面的差异可能非常大。一些规则可以是简单的预定义数字参数（通过表格查询），也有一些工具（特别是 IC设计）可以提供非常强大的程序语言运算环境。设计规则语言的强大性与设计规则的复杂性之间是相互关联的。