在添加文件后，Component Editor会调用Quartus II中的Analyzer对文件进行分析，获取文件的接口信号信息，再通过一系列的配置页面设定自定义模块和Avalon设备信号的对应关系，进而生成特定的配置文件，供SOPC Builder生成Avalon互连结构与自定义模块的连接。

    Component Editor只提取文件的接口属性，不关心文件的内容（但是由于Quartus II中的Analyzer会分析文件的语法，所以语法有问题的文件是不能通过Component Editor的第一步处理的）。我们可以利用这一点，只给Component Editor提供一个Wrapper文件，即只有接口描述而没有逻辑描述的文件，缩短文件的分析时间。在Wrapper文件添加成功后，可以重新编辑Wrapper文件的内容，或者在Wrapper文件中例化包含有效逻辑的设计文件，不需要重新在Component Editor中处理。

    上述方法适用于接口确定，逻辑可进一步改变的设计文件。但是当文件的接口发生改变时，就需要在Component Editor中重新添加模块设计文件和生成配置文件。这里有一点很不方便：Component Editor只读入模块设计文件而不读入已有的配置文件，造成先前的配置全部失效，需要用户重新配置。在文件接口复杂和数量较多的情况下会非常不方便：一方面容易出错，另一方面由于Component Editor运行速度较慢，重新配置需要较长的时间。

    在自主开发SOPC Builder模块时，这样的问题是很常见的。在没有工程压力，只想尝试一下的情况下，几个来回以后，我就没有耐心了。

    其实，Altera提供了一种模块接口命名方式，可以让Component Editor自动识别和映射自定义模块的接口信号，不需要用户手动配置。在Quartus II Version 7.1 Handbook Volume 4: SOPC Builder中专门有一段，给出了自动识别信号命名规范：在Section I. SOPC Builder Features中的5. Component Editor中的Signals Tab里的Naming Signals for Automatic Type and Interface Recognition。

    该方法可以通过在HDL文件中恰当地命名接口信号，让Component Editor自动识别任何类型的Avalon设备信号。包括：主设备接口信号（avm_*）、从设备接口信号（avs_*）、三态从设备接口信号（ats_*）和全局控制信号（gls_*）四种信号。其中包括与Avalon无关的对外接口信号（*_*_export_*）。

    采用这种方法后，即使需要Component Editor重新分析模块设计文件，原有的映射关系也不会被破坏；既省去了第一次手动配置的工作，也省去了进一步编辑模块的配置工作。提高了工作效率。

    如果对.PTF文件有很深入的认识，也可以手工编辑和修改.PTF文件，代替Component Editor的工作：Component Editor的目标就是为了生成.PTF文件。

    值得一提的是，在Quartus II7.1版中，SOPC Builder开始支持.TCL文件作为模块的接口配置文件，在运行Component Editor后生成的也只有.TCL文件。出于向下兼容的考虑，.PTF文件仍然是有效的配置文件，但是在新模块的添加中不再采用这种格式。.TCl文件的形式更简洁，内容更清晰，更加有利于手工编辑。

    此外，SOPC Builder生成的文件组织结构和以前也有差异：更简洁，更规范，相关性更强，更有利于移植和维护。

    还需要提到的一点是：Component Editor的HDL页也有变化。一个模块只能也只需要添加一个顶层文件，其余的下层文件在Quartus II执行综合时需要在用户自定义库或包含文件列表中添加。对于仿真，需要在Component Editor的HDL页的仿真文件中添加顶层文件和下层文件。这一点，也是几年来SOPC Builder的一大改进。毕竟，Component Editor只关心文件的接口，不关心文件的内容。

    总结一下，本文要点如下：

    1. 采用Wrapper文件代替原始设计文件添加到Component Editor中，有利于采用自顶向下的开发流程。

    2. 采用Altera的自动识别命名方式，可以显著减少手动配置的工作量。

    3. 手工编辑和修改.PTF或.TCL文件也是添加SOPC Builder模块的一种高效方式。