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 为事务层，这一层的系统模型带有时间信息，但并不是时钟精确周期，系统是时间驱动执行的。