SoC（system on chip） 是微电子技术发展的一个新的里程碑，SoC不再是一种功能单一的单元电路，而是将信号采集、处理和输出等完整的系统集成在一起，成为一个有专用目的的电子系统单片。其设计思想也有别于IC，在一个或若干个单片上完成整个系统的功能。
SoC开发和设计存在一些问题，如描述语言不统一、抽象层次低、仿真速度慢、可重用性差、设计性能无法保障、RTL级发现的问题需要重新进行整个的设计流程才能解决，因此SoC的建模与设计的方法成为当前刻不容缓的课题。上述种种问题与曾经困惑软件业的“软件危机”的表现非常类似，为了解决软件危机，人们提出了软件工程。因此，本文的思路是将软件工程中应用最为广泛的面向对象技术引入到SoC设计当中。
设计模式是面向对象的精髓，在软件中已经得到了广泛的运用，在SoC设计中使用设计模式，可以降低软硬件开发之间的鸿沟，对于软硬件协同设计有很大的帮助，使系统得到更大的可伸缩性。
SoC设计方法学
传统的设计方法
在传统SoC设计过程中，系统一开始就被划分为软件和硬件2大部分，软件和硬件独立进行开发设计。 这样隐含一些问题，如软硬件之间的交互受到很大限制、软硬件之间的相互性能影响造成很难评估和系统集成相对滞后，导致设计质量差、设计修改难和研制周期不能有效保障。
传统SoC设计流程中，EDA设计方法只作用于SoC后级，缺乏SoC前级设计方法与系统验证策略，从而导致了RTL电路模型中错误成分复杂化与验证人工开销激增。 另外，软件开发者必须等到硬件的设计和结构都完成并通过验证之后，才能开始软件的设计和实现，所以开发的周期将会持续很长，产品的竞争力会因此而下降。
基于模式的设计方法
针对传统设计方法的不足，新的SoC设计方法应该在行为级就开始建立仿真模型和进行行为与结构的验证，同时必须强调结构化、封装和重用硬件设计在高层次的抽象的重要性。
因此，本文提出基于模式的SoC设计方法PBSOC ，如图1所示，强调高层次的系统建模，更有利于设计的复用。 在需求分析阶段，根据规格说明，使用面向对象的分析方法，给出用例的关系和顺序图。 在系统级设计阶段，使用统一的语言SystemC进行软硬件协同设计。SystemC是由Open SystemC Initiative （OSCI） 提出和维护的开放源代码的基于C++统一软硬件建模平台。 软硬件模块都用C++ 描述，对不同软硬件划分方案的评估和权衡可以方便地进行。
PBSOC使用形式化方法和面向对象的Petri网对系统的行为和结构建模，不涉及任何结构和时间的细节，并通过实时UML进行可视化的描述。 它不仅具备传统面向对象方法所具有的风格，而且具有Petri网直观模拟系统动态行为的优点，从而能够更加简洁、清楚地描述系统的静态结构和组成元素之间的层次关系。将Petri网思想引入面向对象建模当中，可将系统看作是一些相互作用的对象组成的集合。集合中的每个对象都具有自己的属性和任务，它们根据收到的消息、句柄等来完成相应的任务，从而实现系统的整体功能。在系统级建立面向对象的设计模式库和IP复用库，OO库即面向对象数据库，主要存放的是各种SoC设计模式（pattern） ，在SoC系统框架设计、IP设计以及IP通信设计中都可以使用模式。IP库中存放的可以是普通的IP核，即其他厂商设计的成熟的IP；也可以是用面向对象的方法设计的一些IP 核，即IP 的设计过程也遵从于PBSOC。
图1 PBSOC 设计框架
SOC设计的设计模式
设计模式
模式是解决某一类问题的方法论，它把解决某类问题的方法总结归纳到理论高度。虽然模式起源于建筑，但其思想也同样适用于面向对象设计模式。指导模式设计有3个重要概念，即重用（ reuse） 、接口与实现分离和低耦合（loose couple）。重用是系统的设计目标，主要通过继承（inheritance） 和对象复合（composition） 实现。 接口与实现分离指接口保持不变，用分离带来灵活性，主要表现形式为多态性（polymorphism）。低耦合可以降低复杂性。
现存的硬件设计模式和重用方法主要是处理RTL（寄存器传输级） 设计和编码的。这种在设计过程中积累的经验在设计重用时是非常重要和有用的，然而并没有涉及系统级设计的问题。因此在系统级应用面向对象的方法可以克服这些鸿沟，使用设计模式还可以更快速和直观地捕捉设计的内容，提高设计的可理解性，将抽象的级别上升到系统级，能够处理更复杂的硬件设计。
SoC设计模式
SoC的设计模式与软件的设计模式的不同，主要在于软件和硬件的设计差别。SoC的设计不仅包括软件，还有硬件以及软硬件的协同设计，因此，它涉及物理约束、实时性和并发等关键问题。所以要将软件的模式进行改造，并使用软硬件通用的描述语言进行描述。
软件设计模式中运用得比较多的面向对象方法是继承，它同样适用于SoC的设计模式当中，但必须考虑SoC系统中的物理约束。一些软件设计模式，主要是创建型模式，能够动态地生成系统的对象，而SoC系统中硬件部分结构是静态的，因此，它们不适合于SoC硬件部分设计模式，但是对于SoC系统中的软件模块还是可以适用的，例如原型模式和命令模式等。
大部分的结构型模式只需要稍做修改就可以应用到SoC设计中，主要是实现方式的问题，即用软硬件通用的语言来重新描述它。而行为型的模式，需要加入实时系统中一些约束。对于典型软件模式改造的前提和目标是设计的可重用性，主要是SoC系统级设计的可重用。在SoC中FSM（有限状态机） 是最常用的一种行为表达方式，因此状态转换的频率是非常多的。如下面的状态模式，通过改造，可以用于描述硬件设计。
新的SoC设计模式的提出是PBSOC 最终的目标。它主要针对的就是高层次SoC设计中最常用的一些设计方法，以及构筑SoC系统的基本组件和基本结构，如层适配模式（layerAdapter pattern） 和包装器模式（wrapper）。本文仅给出了模式的结构，具体的实现不在此赘述。
（1） 状态模式（state pattern）
状态模式的意图是使一个对象在内部状态改变时可以改变自己的行为，从客户看来，好像对象改变了它的类。即不同的状态，不同的行为；或者说，每个状态有着相应的行为。考虑SoC片上总线协议， 片上总线总是有3 个状态： 闲（ IDL E） 、忙（BUSY） 和关闭（CLOSE） 。 而各个状态的处理过程不一样。 如图2 所示，BusProtocol 类维护一个表示总线当前状态的状态对象（一个BusState 子类的实例） 。 BusProtocol 类将所有与状态相关的请求委托给这个状态对象。 BusProtocol 使用它的BusState 子类实例来执行特定于连接状态的操作。 一旦总线状态改变， BusProtocol 对象就会改变它所使用的状态对象。 例如，当片上总线从闲置状态转为忙状态时，BusProtocol 会用一个BusBusy 的实例来代替原来的BusIdle 的实例。
图2 状态模式的系统结构
State 模式不指定哪一个参与者定义状态转换准则。 如果该准则是固定的， 那么它们可在Context 中完全实现。 然而若让State 子类自身指定它们的后继状态以及何时进行转换， 通常更灵活、更合适。 这需要Context 增加一个接口， 让State 对象显式地设定Context 的当前状态。
首先定义类BusProtocol ，它提供了一个片上总线的基本协议通道并处理改变状态的请求。BusProtocol 在state 成员变量中保持一个BusState 类的实例。类BusState 复制了BusProtocol的状态改变接口。每一个BusState 操作都以一个BusProtocol 实例作为一个参数， 从而让BusState 可以访问BusProtocol 中的数据和改变总线的状态。BusProtocol 将所有与状态相关的请求委托给它的BusState 实例state。BusProtocol 还提供了一个操作用于将这个变量设为一个新的BusState。BusProtocol 的构造器将该状态对象初始化为BusIdle 状态。
（2） 层适配模式
层适配模式为SoC通信建模提供分层的协议转换，将不同架构的网络协议通过接口的匹配，实现各层次的数据通信，提供事务级建模各层的适配方式。系统建模中通信机制可以分为4 层，其中事务级建模分为3 层，即除L0 之上的3 层为事务级。其中：L3 为消息层，这一层没有任何的时间信息，系统行为是事件驱动的，并建立点到点的通信。 L2 为事务层，这一层的系统模型带有时间信息，但并不是时钟精确周期，系统是时间驱动执行的。
事务层将理想的结构映射到需要考虑资源分配和设计约束的结构中，完成SoC体系结构的分析和建模，并开始软件的开发。L1为传输层，它在RTL层之上，系统由精确到周期的行为组成，但比RTL 级的仿真速度要快。传输层建模一般对应一定的总线协议，将精确到周期的协议映射到给定的硬件接口和总线结构上，隐藏了接口的管脚，将事务直接映射到总线周期。层适配模式将通过适配完成各层次的模型转换。如图3 所示，TL1 Master Adapter通过适配TL1通道和TL2 通道，使TL1 Master 和TL2 Slave 通信。
图3 层适配模式结构
（3） 包装器模式
包装器模式的目的是通过调整接口和IP 组件的行为来适应特定的应用环境，它属于结构型模式。在SoC设计中，功能组装正在逐渐代替功能设计，而成为主流的设计方法。因此，各个IP模块的互连，以及与片上总线的通信成为研究的重点。IP的本质特征是可重用性，通常必然满足以下基本特征：通用性好，正确性有保证，可移植性好。因为许多IP在设计之初都是针对特定的应用，而很少考虑到要与外来电路搭配使用。IP的定义没有一个通用的接口标准，因为芯片实现的功能千差万别，性能方面的要求也由于应用领域的差异而不同，即使同样功能的IP模块在速度、面积、功耗、对外接口等方面也表现各异包装器模式的系统结构如图4 所示。
图4 包装器模式的系统结构
通过包装器模式的封装，能适配各种IP 接口。即使用包装器模式来调整组件接口以适应于环境要求。包装器模式的匹配程度，对IP Component 的接口与其他的接口进行匹配的工作量各个WrapperModel 可能不一样。从简单的接口转换（例如改变操作名） 到支持完全不同的操作集合，WrapperModel 的工作量取决于Component 接口与需要转换接口的相似程度。
结束语
在SoC设计中，可重用性是应该考虑的一个很重要的因素。 除了IP复用，设计的可重用也是非常重用的。在讨论将现有软件设计模式应用到SoC设计当中后，提出了SoC设计模式，主要针对高层次的SoC设计中的最常用的一些设计方法，以及构筑SoC系统的基本组件和基本结构。除了上述的3 种模式，还提出的一系列的SoC设计模式中，总线模式属于体系结构的模式，包装器模式和层适配模式属于结构型模式，总线协议模式、管道模式和FSM模式属于行为型模式。下一步的工作是深入研究系统级设计方法，以及基于UML的软件设计模式描述如何自动地转换为元（meta） 程序。
SoC（system on chip） 是微电子技术发展的一个新的里程碑，SoC不再是一种功能单一的单元电路，而是将信号采集、处理和输出等完整的系统集成在一起，成为一个有专用目的的电子系统单片。其设计思想也有别于IC，在一个或若干个单片上完成整个系统的功能。
SoC开发和设计存在一些问题，如描述语言不统一、抽象层次低、仿真速度慢、可重用性差、设计性能无法保障、RTL级发现的问题需要重新进行整个的设计流程才能解决，因此SoC的建模与设计的方法成为当前刻不容缓的课题。上述种种问题与曾经困惑软件业的“软件危机”的表现非常类似，为了解决软件危机，人们提出了软件工程。因此，本文的思路是将软件工程中应用最为广泛的面向对象技术引入到SoC设计当中。
设计模式是面向对象的精髓，在软件中已经得到了广泛的运用，在SoC设计中使用设计模式，可以降低软硬件开发之间的鸿沟，对于软硬件协同设计有很大的帮助，使系统得到更大的可伸缩性。
SoC设计方法学
传统的设计方法
在传统SoC设计过程中，系统一开始就被划分为软件和硬件2大部分，软件和硬件独立进行开发设计。 这样隐含一些问题，如软硬件之间的交互受到很大限制、软硬件之间的相互性能影响造成很难评估和系统集成相对滞后，导致设计质量差、设计修改难和研制周期不能有效保障。
传统SoC设计流程中，EDA设计方法只作用于SoC后级，缺乏SoC前级设计方法与系统验证策略，从而导致了RTL电路模型中错误成分复杂化与验证人工开销激增。 另外，软件开发者必须等到硬件的设计和结构都完成并通过验证之后，才能开始软件的设计和实现，所以开发的周期将会持续很长，产品的竞争力会因此而下降。
基于模式的设计方法
针对传统设计方法的不足，新的SoC设计方法应该在行为级就开始建立仿真模型和进行行为与结构的验证，同时必须强调结构化、封装和重用硬件设计在高层次的抽象的重要性。
因此，本文提出基于模式的SoC设计方法PBSOC ，如图1所示，强调高层次的系统建模，更有利于设计的复用。 在需求分析阶段，根据规格说明，使用面向对象的分析方法，给出用例的关系和顺序图。 在系统级设计阶段，使用统一的语言SystemC进行软硬件协同设计。SystemC是由Open SystemC Initiative （OSCI） 提出和维护的开放源代码的基于C++统一软硬件建模平台。 软硬件模块都用C++ 描述，对不同软硬件划分方案的评估和权衡可以方便地进行。
PBSOC使用形式化方法和面向对象的Petri网对系统的行为和结构建模，不涉及任何结构和时间的细节，并通过实时UML进行可视化的描述。 它不仅具备传统面向对象方法所具有的风格，而且具有Petri网直观模拟系统动态行为的优点，从而能够更加简洁、清楚地描述系统的静态结构和组成元素之间的层次关系。将Petri网思想引入面向对象建模当中，可将系统看作是一些相互作用的对象组成的集合。集合中的每个对象都具有自己的属性和任务，它们根据收到的消息、句柄等来完成相应的任务，从而实现系统的整体功能。在系统级建立面向对象的设计模式库和IP复用库，OO库即面向对象数据库，主要存放的是各种SoC设计模式（pattern） ，在SoC系统框架设计、IP设计以及IP通信设计中都可以使用模式。IP库中存放的可以是普通的IP核，即其他厂商设计的成熟的IP；也可以是用面向对象的方法设计的一些IP 核，即IP 的设计过程也遵从于PBSOC。
图1 PBSOC 设计框架
SOC设计的设计模式
设计模式
模式是解决某一类问题的方法论，它把解决某类问题的方法总结归纳到理论高度。虽然模式起源于建筑，但其思想也同样适用于面向对象设计模式。指导模式设计有3个重要概念，即重用（ reuse） 、接口与实现分离和低耦合（loose couple）。重用是系统的设计目标，主要通过继承（inheritance） 和对象复合（composition） 实现。 接口与实现分离指接口保持不变，用分离带来灵活性，主要表现形式为多态性（polymorphism）。低耦合可以降低复杂性。
现存的硬件设计模式和重用方法主要是处理RTL（寄存器传输级） 设计和编码的。这种在设计过程中积累的经验在设计重用时是非常重要和有用的，然而并没有涉及系统级设计的问题。因此在系统级应用面向对象的方法可以克服这些鸿沟，使用设计模式还可以更快速和直观地捕捉设计的内容，提高设计的可理解性，将抽象的级别上升到系统级，能够处理更复杂的硬件设计。
SoC设计模式
SoC的设计模式与软件的设计模式的不同，主要在于软件和硬件的设计差别。SoC的设计不仅包括软件，还有硬件以及软硬件的协同设计，因此，它涉及物理约束、实时性和并发等关键问题。所以要将软件的模式进行改造，并使用软硬件通用的描述语言进行描述。
软件设计模式中运用得比较多的面向对象方法是继承，它同样适用于SoC的设计模式当中，但必须考虑SoC系统中的物理约束。一些软件设计模式，主要是创建型模式，能够动态地生成系统的对象，而SoC系统中硬件部分结构是静态的，因此，它们不适合于SoC硬件部分设计模式，但是对于SoC系统中的软件模块还是可以适用的，例如原型模式和命令模式等。
大部分的结构型模式只需要稍做修改就可以应用到SoC设计中，主要是实现方式的问题，即用软硬件通用的语言来重新描述它。而行为型的模式，需要加入实时系统中一些约束。对于典型软件模式改造的前提和目标是设计的可重用性，主要是SoC系统级设计的可重用。在SoC中FSM（有限状态机） 是最常用的一种行为表达方式，因此状态转换的频率是非常多的。如下面的状态模式，通过改造，可以用于描述硬件设计。
新的SoC设计模式的提出是PBSOC 最终的目标。它主要针对的就是高层次SoC设计中最常用的一些设计方法，以及构筑SoC系统的基本组件和基本结构，如层适配模式（layerAdapter pattern） 和包装器模式（wrapper）。本文仅给出了模式的结构，具体的实现不在此赘述。
（1） 状态模式（state pattern）
状态模式的意图是使一个对象在内部状态改变时可以改变自己的行为，从客户看来，好像对象改变了它的类。即不同的状态，不同的行为；或者说，每个状态有着相应的行为。考虑SoC片上总线协议， 片上总线总是有3 个状态： 闲（ IDL E） 、忙（BUSY） 和关闭（CLOSE） 。 而各个状态的处理过程不一样。 如图2 所示，BusProtocol 类维护一个表示总线当前状态的状态对象（一个BusState 子类的实例） 。 BusProtocol 类将所有与状态相关的请求委托给这个状态对象。 BusProtocol 使用它的BusState 子类实例来执行特定于连接状态的操作。 一旦总线状态改变， BusProtocol 对象就会改变它所使用的状态对象。 例如，当片上总线从闲置状态转为忙状态时，BusProtocol 会用一个BusBusy 的实例来代替原来的BusIdle 的实例。
图2 状态模式的系统结构
State 模式不指定哪一个参与者定义状态转换准则。 如果该准则是固定的， 那么它们可在Context 中完全实现。 然而若让State 子类自身指定它们的后继状态以及何时进行转换， 通常更灵活、更合适。 这需要Context 增加一个接口， 让State 对象显式地设定Context 的当前状态。
首先定义类BusProtocol ，它提供了一个片上总线的基本协议通道并处理改变状态的请求。BusProtocol 在state 成员变量中保持一个BusState 类的实例。类BusState 复制了BusProtocol的状态改变接口。每一个BusState 操作都以一个BusProtocol 实例作为一个参数， 从而让BusState 可以访问BusProtocol 中的数据和改变总线的状态。BusProtocol 将所有与状态相关的请求委托给它的BusState 实例state。BusProtocol 还提供了一个操作用于将这个变量设为一个新的BusState。BusProtocol 的构造器将该状态对象初始化为BusIdle 状态。
（2） 层适配模式
层适配模式为SoC通信建模提供分层的协议转换，将不同架构的网络协议通过接口的匹配，实现各层次的数据通信，提供事务级建模各层的适配方式。系统建模中通信机制可以分为4 层，其中事务级建模分为3 层，即除L0 之上的3 层为事务级。其中：L3 为消息层，这一层没有任何的时间信息，系统行为是事件驱动的，并建立点到点的通信。 L2 为事务层，这一层的系统模型带有时间信息，但并不是时钟精确周期，系统是时间驱动执行的。
事务层将理想的结构映射到需要考虑资源分配和设计约束的结构中，完成SoC体系结构的分析和建模，并开始软件的开发。L1为传输层，它在RTL层之上，系统由精确到周期的行为组成，但比RTL 级的仿真速度要快。传输层建模一般对应一定的总线协议，将精确到周期的协议映射到给定的硬件接口和总线结构上，隐藏了接口的管脚，将事务直接映射到总线周期。层适配模式将通过适配完成各层次的模型转换。如图3 所示，TL1 Master Adapter通过适配TL1通道和TL2 通道，使TL1 Master 和TL2 Slave 通信。
图3 层适配模式结构
（3） 包装器模式
包装器模式的目的是通过调整接口和IP 组件的行为来适应特定的应用环境，它属于结构型模式。在SoC设计中，功能组装正在逐渐代替功能设计，而成为主流的设计方法。因此，各个IP模块的互连，以及与片上总线的通信成为研究的重点。IP的本质特征是可重用性，通常必然满足以下基本特征：通用性好，正确性有保证，可移植性好。因为许多IP在设计之初都是针对特定的应用，而很少考虑到要与外来电路搭配使用。IP的定义没有一个通用的接口标准，因为芯片实现的功能千差万别，性能方面的要求也由于应用领域的差异而不同，即使同样功能的IP模块在速度、面积、功耗、对外接口等方面也表现各异包装器模式的系统结构如图4 所示。
图4 包装器模式的系统结构
通过包装器模式的封装，能适配各种IP 接口。即使用包装器模式来调整组件接口以适应于环境要求。包装器模式的匹配程度，对IP Component 的接口与其他的接口进行匹配的工作量各个WrapperModel 可能不一样。从简单的接口转换（例如改变操作名） 到支持完全不同的操作集合，WrapperModel 的工作量取决于Component 接口与需要转换接口的相似程度。
结束语
在SoC设计中，可重用性是应该考虑的一个很重要的因素。 除了IP复用，设计的可重用也是非常重用的。在讨论将现有软件设计模式应用到SoC设计当中后，提出了SoC设计模式，主要针对高层次的SoC设计中的最常用的一些设计方法，以及构筑SoC系统的基本组件和基本结构。除了上述的3 种模式，还提出的一系列的SoC设计模式中，总线模式属于体系结构的模式，包装器模式和层适配模式属于结构型模式，总线协议模式、管道模式和FSM模式属于行为型模式。下一步的工作是深入研究系统级设计方法，以及基于UML的软件设计模式描述如何自动地转换为元（meta） 程序。
举报
