《机载系统复杂电子硬件适航要求审定规范》(征求意见稿)

1T/CECC000—2024机载系统复杂电子硬件适航要求审定规范本文件规定了机载系统复杂电子硬件的需求标准、设计标准以及编码标准。本文件适用于规范机载系统复杂电子硬件的设计、制造和审定流程，评估机载系统复杂电子硬件的生命周期完整性、可维护性、安全性。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。HB/Z420-2014民用飞机机载电子硬件合格审定保证指南RTCADO-254机载电子硬件的设计保证指南RTCADO-178B-1992机载系统和设备认证中的软件注意事项3术语和定义MH/T1039-2011、GB/T25069-2022、GB/T18041-2000界定的以及术语和定义适用于本文件。3.1复杂电子硬件complexelectronichardware复杂电子硬件指由多个电子组件、模块或子系统组成的电子设备。这些设备由于功能复杂性、设计多样性和潜在隐蔽状态，不能通过简单、明确的验证手段完全确认其功能在所有情况下的正确性和可靠性。因此，它们需要通过更高级的验证方法和工具来确保其符合性和安全性，特别是在安全关键系统中，如航空电子设备中的应用。复杂电子硬件通常包括FPGA、ASIC和其他可编程逻辑设备。3.2跨时钟域crossclockdomain在数字电子系统中，时钟域是指由一个共同的时钟信号控制的逻辑区域。当一个系统包含多个不同频率或相位的时钟时，就涉及到了跨时钟域3.3电磁兼容electromagneticcompatibility指设备或系统在其电磁环境中能正常工作，且不对环境中的任何设备产生不能承受的电磁干扰的能力。环境可靠性：指设备或系统在规定的环境条件下能够持续稳定运行的能力。4复杂电子硬件需求标准4.1需求模块集2T/CECC000—2024需求捕获过程对需求进行识别、定义和记录，包括非派生需求和派生需求，派生需求来自架构、技术选择，基本功能和可选功能、环境和性能需求，且经由安全性评估，将产生的派生需求反馈至相应过程，以便可以评估对系统需求的影响。应向系统开发过程提供在此过程中发现的需求遗漏或错误。4.1.1需求模块应使用IBMRationalDOORS或其他需求管理专用软件管理需求应在一个需求模块中捕获需求需要按产品将需求适当分组到模块中。其目的是创建有意义的需求分组，从而便于管理和确认需求。每个需求模块应包含以下需求属性：ObjectIdentifier/ID、ObjectText、Requirement、Derived_Requirement、Rationale、Safety、Change_history、Validation_Method、Requirement_Status、Verification_Method、Allocation、Type_Requirement表1提供了每个必需属性的定义。表1需求模块强制属性将该需求分配至一个较低需求层级模什么不能进一步分解该需求，则一个说明该需求是否属于派生需求(Pured是是需求文本–也用于非需求的标题文是例如：该属性可以通过列举创建：Y,3T/CECC000—2024是说明该需求是否是可追溯至系统安全性分析(None/PSSA/Safety_Credit/VPSSA:标签表示该需求派生自一个PSSA。需求的原理将包含参考PSSA，该PSafety_Credit:标签表示这条需求对应的功能为其他需求安全性分析的验VSA:标签表示该需求通过安全性分析否是说明是否已确认需求(Novalidated/V是(Test/Simulation/AnThecombinationofthese是提供可接受的确认方法列表(Analysis是是4T/CECC000—2024是onal/Interface/Timing//Hardware/Performance/Reliability/EnvironmenPerformance:表示此需求为Reliability:表示此需求是可靠性需求Environmental:表示此需求是环境性否该属性表示在ICD文件中是否有一个注：此项虽然按照[2]的解释为强制项，但存在例外情况：由于最低需求层级不需要进行分每个需求模块都建议包括注释和标题。注释、标题提供了关于该需求的介绍性描述。通常将需求划分为几段，每段都有简短的注释。每个模块都应包含注释。注释、标题不属于需求，建议在Requirement属性中进行适当标记。每个需求模块都应建立基线。基线用于提供一组稳定的需求，以便审查或开发。由于需求可能会持续发生变化，因此有必要提供一条基线，这样可以确保审核者或开发人员没有移动目标。需在单个项目的需求变更管理过程中评估并确认基线之间发生的任何需求模块变更。在建立第一条基线后，每个需求模块都应含有所有需求的历史记录该历史记录含有所有基线和任何已删除的需求。不得重新使用唯一需求标识，以确保正在讨论的需求不会发生任何混淆。所有属性都应进行归档，而不仅仅是需求文本。尽管该需求标准只要求第一条基线后的历史记录，但是最好记录所有的历史数据（包括第一条基线前的数据）。DOORS工具提供了该功能。DOORS管理员应小心，不要使用“清除”功能，这会删除该历史记录。在生产发布之前，应确认所有需求模块需求对项目开发和生产阶段之间的转换点进行生产发布。每条需求都需要确认为完整和正确的，以确保待建立产品的设计满足相应的安全性和适航性需求。商业设计保证标准DO-254要求确认这些需求。已确认需求的“Requirement_Status”属性需要标记为“Validated”。4.1.2需求层级应在一个或多个需求模块中捕获每个需求层级在适当情况下，一个层级可以基于其父层级分配分成多个模块。每个需求层级应从其父需求层级中分解得出5T/CECC000—2024当需求从高层级传递到低层级时，应复制需求的关键词。当需求的“Derived_Requirement”属性列标为“No”时，此需求的测试证据就可以用于高层级需求的测试证据。如果一条需求被分配至多个低层级需求模块，则需要评审所有子需求(而不仅是在同一模块中的那些需求)，以确保涵盖父需求的每个方面。4.2需求规则4.2.1使用“应(shall)”、“将(will)”、“建议(should)”、“可能(may)”和“待定(tobedetermined)”明确区分强制性需求、事实陈述和设计目标“应”一词用来表示强制性需求“是”、“曾是”和“必须”等术语不能用于表示一条需求。这些术语可用在澄清或解释需求需要的描述性材料中，但不能用来代替“应”。注释和基本原理中应避免使用“应”一词。在Requirement属性中，应将“应”语句需求标记为需求。“将”一词应用于表示受保证的条款或服务“将”语句的示例为“飞机接口将为装置提供28.0±0.1VDC电源”。在该例中，“将”用于表示飞机接口提供的内容，而相关的“应”语句则适用于该装置。装置的开发人员可以依赖飞机来提供所述的电源。“将”语句通常以假设为基础。在这种情况下，相关需求应在其“基础原理”章节中注明假设，并将“Assumption”属性设置为“Y”。“将”语句并不是需求，并且禁止在Requirement属性中将其标记为需求。可以用于注释。“建议”一词用来表述设计目标“建议”语句表示项目是非强制性的但是可取的。应避免在设计/开发保证等级A或B程序中使用“建议”语句。在这种情况下，最好的解决方案是在相关的非需求文件中设定任何目标，如设计说明或操作概念。可用于注释中。“可能”一词应用来表示一项可能的需求“可能”语句通常基于一种假设:可否建立此假设。“待定”一词建议用来表示一项尚不可能决定的需求，将在未来对该需求做出决定“待定”语句的一个例子是：“在此项目中添加的缩放功能仍然待定”。在这个例子中，“待定”意思是：此项目中添加的缩放功能是否尚未决定，当将来具备所有条件后，将对它做出决定。4.2.2基本需求规则本节定义了单条需求的方方面面，这些是创建明确、正确、完整且可验证的有效需求所需的内容。单个的需求应含有一个“应”字。简明的需求应由单个语句组成，该语句明确陈述了要完成的内容。一致的需求不应自相矛盾或与需求模块中的任何其他需求相矛盾。6T/CECC000—2024完整的需求应在逻辑上是完整的。应确认个别需求或一组相关需求，以确保这些需求不会含有任何未定义的输入或输出状态。像“告警灯应只在传感器出现故障时点亮”这样的简单需求是完整的，这是因为它清晰地表明了指示灯建议亮和不建议亮的时间。应确认含有多个输入或滞后的更复杂需求集，以确保该需求不会含有未指定的“无关”或“未知”状态。为需求逻辑填写卡诺图通常有助于确认完整性。明确的.1所述需求应是明确的如果需要，建议使用基本原理来定义术语并解决需求文本中存在的任何歧义。建议避免使用使需求含糊不清的词或短语，如大约、足够、近似、最大化、最小化、不限于、粗略地、平顺等。在需求开发期间，常见的工程实践是使用“待定”或“待验证”占位符来表示数值，直至可以执行某分析。在确认某项需求之前，应消除这种模糊性。.2应定义所有的需求缩略词应限制缩略词的使用，因为这些缩略词可能会对不熟悉需求集详细情况的读者造成困惑。为使需求简洁需要使用缩略词时，则应使用相关注释来消除不明确之处。所有缩略词应在需求模块的缩略词列表中进行定义。.3需求模块中所使用的命名规则一致在同一个项目中使用不同名称的同义词来提及相同项或行为的需求可能会造成混淆并导致需求重复。术语的一致使用对避免这种模糊性很重要。还应避免整个需求层或需求和相关接口控制文档(ICD)之间存在命名差异。必要的和非冗余的.1该需求应是必要的“必要”定义为该需求对于需求模块是适当的，不能从任何其它需求中明显地推导出以及它不是其它需求的组合。应检查对其父需求具有”弱”链接的非派生需求，以确保这些需求确实是必要的并且不具有“很好”的增强功能。.2需求不应重复同一需求模块中任何其他需求的内容除了导致不必要的确认和验证工作，重复需求也还会在变更流程期间造成危险，因为这些需求可能只在一个位置处进行变更。.3建议避免使用指定了过程的需求需求应指明该产品，而不是产品的开发方式。难以验证过程需求，因为这些需求不适用于产品，而是适用于如何开发产品。“硬件应根据DO-254进行开发”等需求应包含在工作说明书或工作指导书中，而不是包含在需求中。唯一标识应为每一个需求模块对象分配唯一标识。7T/CECC000—2024通过将标识记录到“ObjectIdentifier”属性中来分配唯一标识。应为需求、标题、注释分配唯一标识。在整个系统生命周期内，该标识始终分配给该对象。不得重新使用已删除对象的“ObjectIdentifier”标识号。由于项目需求通常被分为多个模块，因此标识对于该项目应是唯一的。DOORS自动为所有对象分配唯一标识符。标记为一条需求每条需求的Requirement属性应标记为“Y”。Requirement属性用于区分需求和非需求。对于派生需求和非派生需求的Requirement属性应标记为“Y”。非需求的Requirement属性建议视情况标记为“N”，“Headling”或“Delete”，但不得标记为“Y”。可行的需求应是可行的。可行在项目限制范围内被定义为可实现。为了避免后期变更导致的代价，建议在项目早期和客户或父层级所有者一起对不切实际的父需求进行讨论。0可验证的0.1需求应是可验证的可验证被定义为有明确方法来确认产品符合需求。需要注意的是，”验证”并不相当于”测试”。通常可使用包括评审、检查、建模和分析在内的其它方法验证一条需求。需求的编写者应避免使用造成需求验证困难的词语或短语。此类别的词语和短语包括明显地、容易地、灵活的、如有必要、最小化、最大化、迅速地、充分地、容易使用的、应能够以及应支持。需要检查否定式”不应”需求，因为这些需求通常较难验证。例如，”警告指示灯应在检测到故障时亮起”这一需求是可验证的，而”除非检测到某个故障，否则警告指示灯不应亮起”则难以验证，这是因为该验证测试应重建指示灯未亮起的每一种情形。0.2建议避免使用适用于其他需求的需求建议避免使用适用于其他需求的需求，这是因为在制定验证程序时，这些需求适用于待验证的其它需求这一点并不明显。建议避免使用这类需求的示例是“第3.4节中的需求仅在该装置处于安全模式时适用”。相反，对每个受影响的需求增加条件短语“当该装置处于安全模式时”则更为恰当。在某些系统中，可能需要诸如环境需求之类的一般需求，但建议尽量减少其使用以确保验证简单易行。4.2.3性能需求本节提供了性能需求的产品需求标准。性能需求提供了测量值（多少、多快等并且通常与配套功能需求相关。每项性能需求应包括测量值的容差性能需求定义为测量某个数值或作用于测量值的需求。举个有关性能需求的例子，”该装置应提供28±0.2VDC”。”大于”或”小于”等短语也可作为容差。例如，”当结温高于75ºC时，该装置应报告故障”是有效的。该需求标准不适用于计数值（以整数值测量的项目）。在提供公差时，务必确保边界值定义良好，且公差不会重叠或留下间隙。时间相关需求应有界限8T/CECC000—2024复杂的系统架构通常不仅依赖于一个动作的发生，而且依赖于一个动作在特定时间内的发生。应检查每条需求，以确保当存在这种时序依赖关系时，它是有适当界限的。这项活动可能很困难，因为它需要产品设计工程师与系统和安全性工程师一起处理复杂的高层体系结构问题，而系统和安全性工程师可能不熟悉设计的底层细节。4.2.4派生需求与非派生需求派生需求由建议的架构、技术的选择、基本功能和选项功能、环境要求、性能要求、及系统安全性评估产生的。“Purederived”的需求是在一些设计决策后所考虑的需求。“Refine”的需求是来自上层级的一条需求，并且在这个需求中添加了一些附加的数据。需求的格式建议是一致的，并建议向上追溯，除非它们是派生需求。4.2.5尽管本文件中所使用的派生和非派生定义与航空领域相关开发和设计保证标准（如DO-254）中所使用的定义一致，但应注意其他行业会使用与派生相反的定义，即从父需求中细化。派生需求.1非派生需求建议自由实施非派生需求将其父需求分解为更详细的需求，但不建议强制实施。例如，非派生需求可能规定了需要的处理能力值、输入/输出带宽等，但是该需求不建议规定满足那些需求的处理器部件号。该选择应留给设计师或在派生需求中进行规定。.2非派生需求的Derived_Requirement属性都应标记为“No”Derived_Requirement属性唯一可接受的条目是“No”，“Refine”或“Purederived”。派生需求派生需求是设计选择的结果，因此派生需求会定义下一层级需求的实现方法。派生需求没有父需求。由于派生需求仍是一条需求，因此需求标准适用于派生需求。.1派生需求应在其Rationale中解释派生原因由于派生需求不具有父需求，因此应解释创建该需求以及其为必要需求的原因。通常，我们将陈述“由于......而存在该派生需求”的解释置于满足需求标准的Rationale中。如可能，该解释建议引用产生该需求的相关文件。.2在被确认之前，派生需求应进行系统安全性评估因为派生需求是一个设计选择，它可能影响系统安全性分析。例如，使用两个冗余电源满足安全性需求的执行决定可能会影响（规定飞机提供多少电流的）更高级系统需求。.3每个派生需求的Derived_Requirement属性要区分“Refine”和“Purederived”Refine表示是来自上层级的一条需求，并且在这个需求中添加了一些附加的数据，Purederived是在一些设计决策后所产生的需求。.4每个Refine需求应追溯到父需求4.2.6需求的链接、参考和分配每个非派生需求都应链接到其父需求9T/CECC000—2024低层级需求(子需求)分解高层级需求(父需求)。当两个需求集都在DOORS中可用时，应做需求链接。此需求标准应解释为要求所有已确认的非派生需求应有父需求。虽然有时某个需求可能合法地具有多个父需求，但应检查这些需求，以确保没有链接问题或父层不具有重复的需求。需求不应具有指向相同需求层级其他需求的父链接不允许使用同层内需求链接，这是因为它们会导致链接循环。如果需要在同层内分解需求，则该层次结构划分可能不正确。该禁止项适用于在两个需求模块之间扩展的内层链接。与ICD相关的需求应引用接口控制文件(ICD)的具体编号与ICD相关的需求本质上是一个接口需求。需求应在ICD属性中标注“Y”，并在需求正文中写明ICD的具体编号。需求应引用其来源当需求从某个非需求中派生或部分派生时，该需求应引用文件、架构/设计说明、分析、白皮书、工作说明书或其派生的其它类似项目。应在Rationale属性列内进行描述。除了最低层级需求外，每条需求都应进行分配Allocation属性规定了该需求分配给哪个需求模块（或多个模块）。在建立父-子链接之前，它有助于在需求开发过程的早期定义系统架构，并进行功能分配。如果不需要进一步分解该需求，则填写本需求模块。4.2.7需求确认和验证方法确认是一种过程，检查需求以确保它们是完整和正确的，以便待开发产品达到安全性和适航性标准，同时满足客户、用户、供应商、维护人员、认证机构、开发人员和其它利益相关方的需要。需求确认包括为需求确认设置目标，进行需求确认活动，识别需求确认的方法，和提供需求确认的数据。验证是一种提供保证的过程，保证实施了这些需求。验证由验证计划中定义的评审、分析和测试构假设的确认在开发过程中，通常基于无法确认的假设来编写需求，直至项目寿命周期的后期。需要确认这些假设，以使需求不是基于一个错误的前提。假设应是“明确阐述的，适当散播的，并通过支持数据证明的。”.1应在需求的Rationale中明确阐述所有的需求假设基于假设的需求通常与“将”语句相关，在这种语句中提供了有关接口的信息。例如：对于来自某风扇的气流的需求可能基于由飞机提供的冷气温度。需要对此假设进行注释，这样一来，如果冷气温度范围发生变化，则可以重新评估该需求，以查看是否需要一个更强力的风扇。.2如果一条需求是基于一个假设，则它的Assuption属性应标记为“Y”Assumption属性唯一可接受的条目是“Y”和“N”。.3如果一条需求不是基于一个假设，则它的Assuption属性应标记为“N”Assumption属性唯一可接受的条目是“Y”和“N”。T/CECC000—20.4在确认需求之前，应确认每条需求假设。仅在如果一条需求所基于的假设是有效的情况下，这项需求才是有效的。用与需求一样的严苛度来确认假设。在较高层级进行确认的假设也可能用于较低层级。一般确认需求标准.1应根据本文件要求的需求标准来确认每条需求通过将一条需求的Requirement_Status设置为“Validated”，将它标记为已确认。.2应确认每条需求，以确保该需求允许产品满足所有适用的安全性标准此需求标准的设计目的是确保所施加的产品需求不会造成安全性问题。通过客户需求、政府/军方标准、或商务开发和设计保证标准，譬如SAEARP4754A和DO-254，来定义适用的安全性和适航性需求。每个项目都建议有一条需求确认计划和一个系统安全性评估，它们一起用来描述适当水平的确认细查。.3如果一条需求影响飞机安全性，则它的Safety属性应标记为“PSSA”,“VSA”or“SafetyCredit”如系统安全性分析中所述，安全性需求包括系统功能可用性和完整性的最低性能需求。该需求具体描述了一个安全性需要，例如：有关监视器或机内测试的一条需求，即它是一项安全性需求。.4确认过的需求如果发生变化，应重新确认此需求如果一条需求的任意属性（而不是仅指需求文本）发生任何变更，则认为该需求已发生变更。大多数项目形成了一条需求变更过程，该过程相当于通常用来确认需求的检查评审。这使得在不重新评估所有模块需求的情况下，可以对个别需求进行变更。在所有情况下，需求变更过程需要使用与原始确认过程保证同样程度的严苛度。受控需求的变更将导致该需求处于未确认的状态，并需要将其Requirement_Status属性设置为“Novalidated”。.5应在需求“Changehistory”属性中引用用来更改一条需求的变更请求单号记录该变更请求单号可以更容易地追溯需求变更，并为已确认的需求提供一个更清晰的谱系。在“Changehistory”属性中可以记录相应的变更文件ID，以便追溯。.6如果一条需求已得到确认，则它的Requirement_Status属性应标记为“Validated”Requirement_Status属性唯一可接受的条目是“Validated”和“Novalidated”。.7如果一条需求没有得到确认，则它的“Requirement_Status”属性应标记为“Novalidated”Requirement_Status属性唯一可接受的条目是“Validated”和“Novalidated”。5复杂电子硬件设计标准在概念设计过程和详细设计过程中使用硬件设计标准定义硬件设计的规则、程序、方法、指南和标准。设计标准的目的是提供：a)硬件设计表述方法和注释；b)设计规范和命名惯例；c)有关设计方法的指南；d)有关硬件设计工具使用的指南；T/CECC000—2024e)用于电子组件选择的指南；f)用于评估故障保护和容错设计结构的指南；g)用于提供反馈至需求过程以及阐明需求的方法描述。h)用于提供电磁兼容性和环境可靠性设计标准5.1硬件设计表述应用图表、文本和硬件描述语言(HDL)描述复杂电子硬件。复杂电子硬件设计将分解成若干子模块，使用文本和图形记录和描述这些子模块，最终在HDL中实施。5.2设计规范和命名惯例模块命名应参考需求、架构的相关描述，并准确的表达它实现的功能。5.3设计方法的指南图表是重要的设计表述方法。模块框图、数据流向图、状态转换图等应该被用于需求向功能架构的分解、功能架构到代码实现、设计的描述中。接口描述表格应被用于描述芯片对外和模块之间的端口。这些图表将被保存在需求、架构文档中。5.3.1设计输入指南架构顶层设计在架构设计中，使用自顶而下的设计流程。在顶层设计阶段，用框图描述芯片对外的连接关系，用表格描述启用的芯片对外接口。使用功能框图对芯片内部功能模块进行划分。功能框图中应包含主要的数据流向，以描述各模块之间连接关系。架构层级设计一个复杂的可编程逻辑设计内部一般以层级方式进行设计，这样使得设计师能够专注于电路的一个功能部分。架构功能块设计在完成层级设计后，进行功能块内部的设计。可以使用流程图描述功能的前后步骤，使用状态机转换图描述状态机切换，使用接口描述表格描述功能块的输入输出接口。同步/异步设计应首选同步设计，而不是异步设计。因为异步设计通常对于元件的延迟很敏感，很难预测和保证该延迟。静态时序分析进一步提高了同步设计时序的可靠性，为整体时序的一个良好整体保证，因为仿真的方法受限于仿真激励的完整性，并不一定能够仿真到所有的时序路径。并且，当设计转移至更新一代器件，或从原目标器件转移至另一厂家器件时，同步逻辑设计由于对不同型号的器件的物理延迟不是那么敏感，所有更有利于移植。但对于CPLD，异步设计往往是不可避免的。时钟设计在可编程设计中，应避免使用门控时钟，因为这必然会在时钟信号的产生时引入组合逻辑，使得竞争冒险产生的风险增加，产生毛刺。为了保证更好的时序，还应尽量避免使用逻辑生成的时钟，在生成内部时钟时，应当首先考虑使用片内提供的专用资源，比如片内晶振、PLL或DLL。T/CECC000—2024时钟信号往往是片内扇出最大的信号之一，为了进一步保证时序，减小时钟偏移对时序带来的影响，应确保时钟信号被连接到全局网络中，往往设计工具会在综合时自动进行相应的连接，设计人员在综合后需要进行确认。时钟约束设计应根据可编程器件上下游器件的时延特性及PCB走线延迟，计算得到可编程器件的输入输出延迟。应根据需求，设置输入时钟、衍生时钟的周期、占空比、相位参数、倍/分频系数等参数。应根据布局布线后的STA报告，修改逻辑内部的时序约束，通过迭代的过程，达到最终的时序收敛。复位设计应注意隔离不同时钟域的复位源，以免非预期的复位源会影响相关功能的复位。在同步设计中，复位信号控制着所有相关复位域下寄存器的工作起点。对于包含有多时钟域的设计，不同时钟域承载的不同功能的复位信号的复位源可能不一样。应对复位信号进行“异步复位，同步释放”处理。一般而言，相比于复位信号的生效，往往复位信号的释放更受关注，因为复位信号的释放决定了相关复位域下的寄存器是否“同时”开始工作，使得后续的同步逻辑按照预期的工作节拍同步工作，为了保证这一点需要对复位信号进行相应时钟域下的“同步释放”处理。并且，由于“同步复位”操作往往会额外消耗组合逻辑资源，而往往复位信号会大量分布，因此占用大量组合逻辑，综合以上考虑，为了节省逻辑资源，无特殊要求时，一般对复位信号进行“异步复位，同步释放”处理。复位信号应连接到全局网络中。与时钟信号一样，复位信号往往是片内扇出最大的信号之一，为了进一步保证时序，提升时序性能，复位信号最好连接到全局网络中，往往设计工具会在综合时自动进行添加。跨时钟域设计应采用合理的方式进行数据的跨时钟域传输。在多时钟域的设计中，信号的跨时钟域几乎是不可避免的，为了避免数据跨时钟域产生的亚稳态对功能产生不利的影响，应对跨时钟域的数据进行相应的处理。跨时钟基本场景有：快时钟与慢时钟之间、单bit/多bit数据、连续/非连续、单周期/多周期等。常见的跨时钟域方法有2-DFF、DPRAM、FIFO、握手、格雷码等，应根据实际场景正确的选择跨时钟域方法。片上资源评估应采用合理的方式进行数据的跨时钟域传输。在多时钟域的设计中，信号的跨时钟域几乎是不可避免的，为了避免数据跨时钟域产生的亚稳态对功能产生不利的影响，应对跨时钟域的数据进行相应的处理。跨时钟基本场景有：快时钟与慢时钟之间、单bit/多bit数据、连续/非连续、单周期/多周期等。常见的跨时钟域方法有2-DFF、DPRAM、FIFO、握手、格雷码等，应根据实际场景正确的选择跨时钟域方法。5.3.2综合指南在完成HDL编码后，转至综合阶段。整合在Libero里的SynplifyPro是专门用于FPGA的综合工具。QuartusII工具用于CPLD的综合。通常，应设置一个整体频率。不建议使用综合优化选项，因为它会引起编码和工具生成的网表之间的一致性检查，除非正常选项不能实现性能或资源利用量。T/CECC000—2024应在综合完成之后，保证最后的综合报告中没有ERROR。应在综合完成之后，查看综合报告，分析所有的WARNING，确保报告的WARNING信息，不会对功能实现产生影响。尤其要关注的WARNING类型有：DPRAM读写冲突、安全状态机是否建立、寄存器的删减应在综合完成之后，查看综合过程中状态机的编码方式是否符合预期。5.3.3布线后指南设计师应当在布局布线前完成以下时序约束：a)周期约束：主时钟和衍生时钟周期、相位及占空比等b)Port约束：输入延迟，输出延迟c)伪路径约束：对于已经做了跨时钟域设计的路径，应进行伪路径约束。d)多周期约束：对于有多周期约束的设计的路径，应添加相应的约束。e)Port至Port：如对Port到Port的延迟有需要，应进行此约束。f)其他约束：网络的Maxskew/Maxdelay等（如必要）设计师应在布局布线完成后进行STA检查时序。设计者应针对时序报告中约束的工作频率检查实际能够达到的频率，并确保留有足够的余量。同时，设计师应根据时序报告检查是否有报告时序为例，并根据实际情况对时序约束进行迭代，使得最终的布局布线结果满足所有时序约束。5.3.4电子元件选择选择CEH元件，应当考虑以下标准：a)供应商的稳定供应能力：尽量考虑已有成熟应用的器件，而不是新产品，且供货商能保证稳定的产品供应b)抗单粒子翻转（SEU）：选择FLASH等工艺的器件c)所选择的封装应当满足环境需求：如工作温度范围d)片上资源：应保证预估资源余量在30%或以上5.3.5故障保护和容错设计在需求、架构、详细设计阶段，应增加设计故障保护功能以提高容错性，比如考虑增加数据通信中的校验、纠错功能，内建自测试（BIT）功能、关键参数的监控功能等。5.4电磁兼容性与环境可靠性设计指南5.4.1电磁环境分析a)暗室结构：暗室为进行辐射发射和抗扰度试验的核心设施，确保其屏蔽性至关重要。暗室的设计需使用高导电性材料，以防止外部电磁波干扰试验结果，保证测试的准确性和有效性。b)干扰源识别：识别所有可能的电磁干扰源，如天线、变频器、开关电源等，分析其对试验系统的影响程度，确保采取相应的抑制措施以减少干扰。c)信号传播：研究信号在电气系统中的传播路径，评估电磁耦合可能带来的影响，通过合理设计信号通道来降低噪声干扰的传递。d)设备布局：合理安排各设备的位置和方向，减少互相之间的电磁干扰，确保高频信号与低频信号设备相对隔离，提升整体系统性能。e)噪声管理：持续监测电源线、接地线中的噪声水平，实施主动噪声抑制措施，如使用滤波器和干扰抑制装置，以确保信号的完整性和稳定性。T/CECC000—2024f)环境影响评估：分析外部环境因素（如温度、湿度、振动等）对设备性能的潜在影响，确保设计在各种环境条件下均能正常运行。g)屏蔽设计：根据设备类型和工作频率设计合适的屏蔽措施，如金属外壳或导电涂层，旨在隔离电磁干扰，提高系统的电磁兼容性。h)可靠性测试：进行全面的环境可靠性测试，评估设备在极端条件下的性能表现，确保其长期稳定运5.4.2设备选型a)选型标准：依据电磁兼容性标准，选择具有良好电气性能和环境适应性的设备，以确保其在机载系统中的有效运行。b)变频器配置：针对进气温度调节装置，采用具有高性能滤波功能的变频器，并在其输入和输出侧分别安装滤波器和电抗器，以有效抑制高频噪声和限制谐波干扰。c)电机驱动：后驱动装置应选用具有良好抗干扰特性的变频驱动系统，配置适当的滤波器，确保其在各种工作条件下的电磁兼容性，降低对其他设备的干扰。d)电源设计：在起动主路电源的直流输出回路中添加L型滤波器，并在控制电源的直流输出回路中加入LC滤波器，以显著提高电磁兼容性并降低电源噪声。e)控制电路：电气控制柜内的继电器和接触器应并联浪涌吸收电路，以有效控制交流和直流噪声，确保系统运行的稳定性和可靠性。f)控制系统选型：采用适合电磁环境的可编程逻辑控制器，确保其具备强大的抗干扰能力，能够适应复杂的电磁环境。g)测试设备：选用具备独立供电和强抗干扰能力的测试系统，以确保测试数据的准确性和可靠性。h)复位电路：设计复位信号处理电路时，确保实现“异步复位，同步释放”的功能，以降低潜在的干扰风险，确保系统在复位时的可靠性。i)设备测试：机载系统复杂电子综合性测试，评估在极端条件下的性能表现，确保其长期稳定运行。（机载系统复杂电子综合性测试见附录C）5.4.3电缆布线a)布线原则：遵循最短路径原则，合理规划电缆走向，减少电缆之间的交叉和重叠，以降低干扰耦合的可能性。b)屏蔽要求：选择具备良好屏蔽效果的电缆，推荐使用符合EMC标准的屏蔽电缆，其具有优异的抗干扰能力，能够有效隔离外部电磁干扰，并减少信号在传输过程中的衰减。同时，需确保屏蔽层与接地系统良好连接，增强其屏蔽效果。c)绝缘材料：电缆应采用PVC绝缘和外护套材料，以提供良好的耐化学性、阻燃性和机械保护，确保在各种环境条件下可靠运行。d)电缆类型：动力电缆使用符合电气规范的屏蔽电力电缆，具有良好的抗干扰性，确保电力传输的稳定性和可靠性。e)信号线布置：通讯电缆应使用符合EMC标准的专用电缆，避免与高电流电源线交叉布置，确保信号传输的清晰度和可靠性。f)接地处理：确保电缆接地良好，降低干扰影响，提升系统的整体电磁兼容性。g)走线路径：合理规划走线路径，确保信号线与电源线之间保持适当的间距，降低电磁干扰的风险。h)定期检查：实施定期检查和维护，确保布线质量和系统的长期稳定性。6复杂电子硬件编码标准6.1命名规则6.1.1模块名应大写T/CECC000—2024应用范围：Verilog,VHDL。6.1.2参数名(Verilog：parameter;VHDL：CONSTANT)应大写应用范围：Verilog，VHDL。6.1.3宏定义名(Verilog：define;VHDL：CONSTANT)应大写应用范围：Verilog,VHDL。6.1.4文件名与模块名应一致应用范围：Verilog,VHDL。6.1.5低有效复位信号名应以‘_n’or‘_N’结尾应用范围：Verilog,VHDL。6.1.6信号名应不超过32个字符应用范围：Verilog,VHDL。6.1.7子模块调用名应基于子模块名，不能只有数字序号应用范围：Verilog,VHDL。[VerilogHDL]InstanceInstance_u2(//right.Data_out(Data_out),.Data_in(Data_in),.Clk(Clk),.Cs_n(Cs_n),…InstanceU2(//wrong.Data_out(Data_out),.Data_in(Data_in),.Clk(Clk),.Cs_n(Cs_n),…T/CECC000—20246.2源代码设计规则使用if描述组合逻辑的时候，每个if应有else与之配套，以防产生锁存（latch）应用范围：Verilog,VHDL。“if…else”的层级应不超过10。如果超过10，应使用case语句应用范围：Verilog,VHDL。6.2.2case语句case语句的所有分支都应定义（当分支定义不完整时，需要定义default分支）用case语句描述组合逻辑时，所有输出都应被赋值，以防生成锁存器（latches）6.2.3时钟应避免使用门控时钟。应用范围：Verilog,VHDL。应使用PLL资源来替代门控时钟，或者保持原时钟不变，使用时钟使能信号进行后续处理。6.2.4信号敏感列表Verilog:组合逻辑块中，“always”过程中的敏感列表应描述为“*”或在该过程中读取的所有信号应在敏感列表中列出；VHDL：过程中出现的所有读取的信号都应列入敏感列表。应用范围：Verilog,VHDL。always@(*)always@(Clr,D,SET)T/CECC000—2024process(Clr,D,SET)Endprocess;6.2.5函数函数底部应有返回值。应用范围：Verilog,VHDL。6.3格式源代码的格式不影响功能，但对可读性和可维护性有重大影响。最重要的原则是确保项目中所有源代码都有统一的格式。6.3.1每个HDL文件的文件头应包含下列信息a)ModuleNameb)FileNamec)Authord)Description：abriefdescriptionofthefunctionofthemodulee)Companyinformationf)Revision:currentrevisiong)RevisionHistory:changehistoryinformationh)Copyrightinformation：companynameandthestartyearofcopyright应用范围：Verilog,VHDL。//--------------------------------------------------------------------//ModuleName：LED5228//FileName：LED5228.v//Author：ZhangSan//Description：//TocollectthestatusofthePHYchip(BCM5228),anddriveexternal//ledlampstodisplaythestatusofeachport//Company：SAVICT/CECC000—2024//Revision:1.01//RevisionHistory://1.00:Sep15,2010EISCEH-701//1.01:Dec20,2010EISCEH-730//Copyright:SAVIC,20206.3.2一组定义或声明应在垂直方向上对齐应用范围：Verilog,VHDL。只需将最左侧对齐。wire[7:0]Data_in;wire[7:0]Data_temp;//“Data_in”and“Data_temp”twolinesarealigned.SignalData_in:std_logic_vector(7downto0);SignalData_temp:std_logic_vector(7downto0);6.3.3Verilog中always块，或者VHDL中的Process块应命名应用范围：Verilog,VHDL。6.3.4每个端口信号应加注释应用范围：Verilog,VHDL。6.3.5一个描述语句应占用一行应用范围：Verilog,VHDL。6.3.6一行的宽度应小于等于95个字符应用范围：Verilog,VHDL。6.4状态机6.4.1复位后状态机应进入确定的状态应用范围：Verilog,VHDL。parameterCHECK=4’b0010;parameterWAITER=4’b0100;parameterDONE=4’b1000;T/CECC000—2024always@(posdgeclkornegedgerstn)beginif(!rstn)beginendelse…6.4.2状态机的所有状态都应被执行应用范围：Verilog,VHDL。case(current_state)S_IDLE:beginif(dha_frame_fsn_ready)next_state=S_RD_PERSONALITY;elsenext_state=S_IDLE;endS_RD_PERSONALITY:beginnext_state=S_RD_PARAM;endS_RD_PARAM:beginif(spi_ram_rd_addr==8'h36)next_state=S_WAIT_DONE;elsenext_state=current_state;endS_WAIT_DONE:beginif(frame_done)next_state=S_IDLE;elsenext_stateenddefault:beginnext_stateendendcaseT/CECC000—2024=current_state;=S_IDLE;endcase(current_state)S_IDLE:beginif(dha_frame_fsn_ready)next_state=S_RD_PERSONALITY;elsenext_state=S_IDLE;endS_RD_PERSONALITY:beginnext_state=S_RD_PARAM;endS_SET_ADDR:begin//ruleviolationnext_state=S_RD_PARAM;endS_RD_PARAM:beginif(spi_ram_rd_addr==8'h36)next_state=S_WAIT_DONE;elsenext_state=current_state;endS_WAIT_DONE:beginif(frame_done)T/CECC000—2024next_state=S_IDLE;elsenext_state=current_state;enddefault:beginnext_state=S_IDLE;endendcaseend6.5其他规则6.5.1对于比较和赋值语句，两侧变量应有相同位宽应用范围：Verilog,VHDL。reg[3:0]Cnt;beginbeginsignalData_In：std_logic_vector(7downto0);signalCnt：std_logic_vector(3downto0);If(Data_In=(b”0000”&CT/CECC000—2024If(Data_In=b”0000_0000”)then6.5.2应避免使用内部三态门应用范围：Verilog,VHDL。三态门只能用于芯片管脚。6.5.3子模块例化时的端口和参数（generic、parameter）的传递应以名称关联形式应用范围：Verilog,VHDL。Instance_u2:Instance_TypePortmap(Data_out=>Data_out,Data_in=>Data_in,Clk=>Clk,Cs_n=>Cs_n,…);--ComplywiththeruleInstance_u2:Instance_TypePortmap(Data_out,Data_in,Clk,Cs_n,…);--violatestheruleINSTANCE_TYPEINSTANCE_TYPE_U0(T/CECC000—2024.Data_out(Data_out),.Data_in(Data_in),…);--ComplywiththeruleINSTANCE_TYPEINSTANCE_TYPE_U0(Data_out,Data_in,Clk,Cs_n,…);--violatestherule6.5.4所有进入芯片的跨时钟域信号应被同步后再使用。同步技术包括异步FIFO,握手，寄存两拍应用范围：Verilog,VHDL。6.5.5所有内部跨时钟域信号应先同步后再使用应用范围：Verilog,VHDL。T/CECC000—2024复杂电子硬件设计标准实施与工具使用附录本附录旨在为复杂电子硬件设计项目提供详细的设计实施和工具使用指南。通过遵循本附录中的指导原则和推荐实践，设计团队可以确保项目的顺利进行，提高设计质量，并有效利用设计资源。2设计实施2.1需求分析明确项目目标和功能需求，包括输入输出信号、性能指标等。确定设计的约束条件，如尺寸、功耗、成本等。2.2架构设计选择合适的体系结构，如微处理器系统、FPGA或ASIC实现。定义模块划分和接口，确保系统的模块化和可扩展性。2.3详细设计使用硬件描述语言（HDL）如Verilog或VHDL进行模块级设计。利用仿真工具验证设计的正确性和性能。2.4综合与布局布线使用综合工具将HDL代码转换为门级网表。进行布局布线，优化电路的速度和面积。2.5时序分析和验证使用静态时序分析(STA)工具检查设计的时序是否满足要求。根据需要调整设计以满足时序要求。2.6物理实现生成制造所需的文件，如GDSII或OASIS格式。确保设计符合制造厂商的工艺要求。2.7测试与调试制定详细的测试计划，包括功能测试、性能测试和可靠性测试。使用逻辑分析仪、示波器等工具进行调试。3工具使用指南3.1设计工具T/CECC000—2024HDL编辑器：选择功能强大且易于使用的编辑环境，如QuartusII或Vivado。综合工具：根据设计规模和复杂度选择合适的综合工具，如SynplifyPro或XilinxISE。仿真工具：使用ModelSim或VCS进行功能仿真和时序验证。STA工具：采用PrimeTime或XTA进行检查以确保满足时序要求。3.2版本控制使用版本控制系统如JIRA管理源代码和文档，确保团队成员之间的协作和