soc设计方法学
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
基于 SystemC 的 SoC 事 务级多视图建模方法
研究
姓名： 学号： GS11062352 学院： 计算机学院
1.引言 事务级别建模一直是 SystemC 中一种重要的建模技术, 今天的日益复杂的片上系统
(SoC)设计包括嵌入式软件的运行在多个处理器核心,连接到内存和外围设备。随着复杂性的 增长,越来越多的软件和硬件外围设备组成的重用知识产权(IP)块。需要一个设计方法,其中 一个混合的应用软件和算法可以被映射到一个架构组成的可重用的 IP 模块。在这种情况下, 需要一个硬件合作设计的方法,允许快速地分析之间的取舍在硬件和软件的实现。验证和实 施工作都变得非常重要和有效的方法是要求涉及到创建一个最小数量的模型。为了达到这一 复杂的设计上有足够的仿真性能、高级模型不仅需要模拟软件对一个模型的硬件,但是也来 加速这个过程建模的硬件 IP 在公共汽车上独立,重用友好的方式。模型还需要允许简单而快 速的芯片上的配置总线架构或通信网络。正是在这样的背景下,事务级别的建模被广泛的应 用了起来。
p_slave,
};
myPVResp PVSlave::theTransportfunc(const myPVReq& arg_Req){
cout << sc_time_stamp() << name()
<< " transport function is called with address "
使用显式的时机结构建模 4.4 systemc 的实现：隐式的时机。
这里概述一下使用显式的差异。这个 putRequest 在发起者和 getRequest 在目标是不同 的。他们把一个 sc_time 参数标注延迟时间。在此时间上的行为，需要遵照下面的调度。序 列用于发起者的 putRequest 使用隐式时间如下。
<< hex << arg_Req.getAddress() << endl << endl;
myPVResp theResp;
theResp.setResponse(pvOk);
return theResp;
};
3.5.2 DMA 模型
DMA 模式 4. SoC 的体系结构视图建模方法
简要概述体系结构视图建模对 SoC 设计验证的作用，结合典型实例论述 SoC 的体系结构 视图建模的技术方法。
的技术方法。 5.1 简介 在上面的讲述中,我们已经看到了如何创建一个易于使用,通用和提供良好的仿真速度的
事务建模接口, 但这个 API 不能建模时间上错综复杂的协议。作为设计改进失灵抽象层有一 个点,所有周期时间一个协议的细节是重要的。对于一个特定的类的互连策略循环周期交互 设计模块互连线总体系统性能有很大影响。详细的硬件设计还需要更多的时间周期。详细的 硬件设计可以发生在 SystemC，但也可以使用硬件描述语言(VHDL 和 Verilog），在所有这些 情况中这是一个我们之前讨论过可要重用模型，对于这个问题有两种解决方法，这允许以验 证是否精致块仍然实现了原始功能。验证了系统的总体时间模型还需要进一步改善。它不允 许验证互连行为的周期影响。
事务级建模的主要目的提高动态模拟速度,同时还要提供足够的精度来设计手头的任 务。事务级建模提供了一种最小化事件数量和信息数量的方法,因此事务级别建模应用最好 的是在设计问题这一级上,因为这一级沟通和系统级集成是主导。
事务级建模也是为了减少大量的细节,而这些细节是设计者们必须考虑的,因此让建模 更加容易。事务级模型让通信从行为中分离出来。这使得每个建模不相互影响。建模技术可 以支持不同的抽象级别,这样的细节可以添加或抑制了所需的一个给定的发展状态。
4.1 简要介绍 关键的问题在于,结构视图建模需要解决的问题是提高早期的架构平衡系统的设计,使设 置正确的设计约束对 HW 和 SW 实现团队。这个问题的解决方案空间非常大,因此需要设计者 的经验来找到最好的解决方案。建模风格的目标是使设计师评估不同的设计决策。评价是通 过模拟和分析来完成的。 为了有好的设计决策架构，一个足够精确的通信模型和/或内存需求需要来自系统的需 求。因此建模风格将专注于通信时间和资源共享(point2point,共享总线,…)以及数据的大 小。建模风格应该在处理系统的需求,不实现这些需求,在这种情况下,它面对的主要是高水 平的版本的系统功能和估计。另一方面许多今天的设计重用以前的设计元素,所以建模风格 应该是开放的足以允许插入更详细的实现模型。
隐式时机的结构模型
4.5 混合模式类型 从程序员的角度来说能够重用模式对于创建结构模式来说是有益的，在这种情况下,需要 创建的适配器,把“运输”协议 PV 的架构建模的接口。这需要考虑到同步以及数据类型转换。 在伪代码创建一个适配器连接 PV 发起者一 AV 通道如下:
RESP Transport(const & REQ){ RESP Transport(const & REQ){ putRequest (REQ); wait (ok_to_get_response); getResponse (RESP); return RESP; }
•响应状态：可以了 ，错误 3.4 SystemC 的实现 事物级建模接口是实例化自定义数据结构。
template< typename AT, typename DT > class PV_if : virtual public tlm_transport_if< PVReq< AT, DT>, PVResp< DT> > { public : virtual PVResp< DT> transport( const PVReq< AT, DT> & ) = 0; };
myPVResp theTransportfunc(const myPVReq& arg_Req);
};
PVSlave::PVSlave(sc_module_name name) : sc_module(name),
p_slave(){
REGISTER_PVSLAVE( theTransportfunc);
p u 重要的是了解可重入的代码时必须有多个线程可以调用这个传输函数(参见注三)。当连 t 接一个 AV 通道到一个 PVR目标需要创建一个适配器,它包含一个线程从双向传输 API 阻塞, e 因此需要被称为从一个线程。对于这样一个线程的伪代码如下: q u e s t
( R E
5 SoC 的验证视图建模方法 简要概述验证视图建模对 SoC 设计验证的作用，结合典型实例论述 SoC 的验证视图建模
程序员视图事物建模的一个关键风格是,它应该链接到一个有效的指令集仿真器。嵌入式 软件设计者将使用一个空间站模型一起使用他们平常的调试环境。一个嵌入式软件设计师可 以为平台开发软件来使用多任务操作系统的 API,并使用编译器为目标处理器来创建一个对 象文件的软件。
3.2 协议层 双向阻塞接口作为对程序员视图的最低层协议栈V。协议层在传输层建立一套方便的功
结构探索流程图
结构化视图有足够的时间来量化整体性能和辨别系统中潜在的瓶颈，时间可以是显式的 或隐式的。
4.2 数据结构 数据的准确性通常在是封装级别,即认为数据粒度是一组相关数据的功能,结合起来的抽 象数据类型(ADTs)。REQ 和 RESP 是基于应用的抽象数据类型,从数据结构概述了使用与程序 员看来,增强了一些数据的成员隐含的时机到携带大量的数据的结构,例如,一个完整的 IP 数据包。 4.3 System C: 显式的时机 一个请求放在通道启动程序(I),运输网络(N)到目标(T),起始者和目标是通过一个同步 信道(C)连接在一块。一个典型的请求交互事件发生的顺序如下:
但是有可能利用事务建模深入到细化过程,并创建一个事务建模风格,具有所有必需的周 期时间的细节硬件设计。在这一部分中创建验证视图是一个风格。验证视图包含足够的细节 以使周期准确的进行 HW 开发和验证。因此周期准确总线模型是必需的,以及交易人与 RTL 启用联合仿真,信号是被利用而不是一个事物级建模的 API。
本文的目的是提供了一个基于 SystemC 的事务级建模方法。更具体地说,我们将解决如何 支持不同的 SoC 设计和资料交换层级验证任务。在本文中我们将首先介绍事务级别建模描述 的目，它怎样标准化,并概述不同的解决方法。 2.SoC 设计任务与多视图设计和验证方法
论述 SoC 软件设计、体系结构设计、系统验证的主要任务和目标，论述 SoC 的多视图设 计验证方法与设计流程，论述事务级模型对支持 SoC 多视图设计和验证的重要性。
Figure 2: design flow
3.SoC 的程序员视图建模方法 简要概述程序员视图建模对 SoC 设计验证的作用，结合典型实例论述 SoC 的程序员视图
建模的技术方法。 3.1 简介 一个程序员的目标的观点是含有足够的细节以使大部分的嵌入式软件开发不同的处理元
素设计。一些需求是直截了当的:一个程序员的视图模型需要准确记录，它还需要能够中断 处理。一个值得注意的例子是周期需求的准确性来发展关键软件。这个软件需求的开发模型, 有更多的时间精度。事实上,公共汽车和芯片上沟通网络以及目标外围设备可以被建模而且 非常有利于仿真速度和开发时间。很明显,不同处理元素间的同步需要实现足够的细节来确 保正确的功能。同样重要的一点是同步不能依靠这个时间。
3.5 程序员视图模块实例 3.5.1 简单外设，下面是一个简单的 PV 外设模型的例子。
ຫໍສະໝຸດ Baidu
class PVSlave : public sc_module{
public:
PVTarget_port p_slave;
PVSlave(sc_module_name name);
SC_HAS_PROCESS(PVSlave);
另一种方法是定义目标基类,它实现运输。多个对象的实例化这些类可以在目标和直接 绑定到相应的 sc_export 建立目标端口。这对应于构建一个层次的目标。这种方法的问题是 目标数据成员不能被直接访问这个传输实现类。因此,数据或参考数据或目标的这个指针需 要通过分解成这些类。
另一种替代方法是相同的传输函数绑定到多个端口。这需要传递的信息在 REQ 结构,允许 解码的目标端口实际上是触发。这种编码风格也分开的原则冲突沟通和行为。
5.2 基于多转移的协议栈 验证观点是建立在具有相同的单向非阻塞接口中如同在体系结构视图被使用的那样。体 系结构视图使用两种基本的接口或转移来创建一个协议。用于验证协议实现视图使用更多的 转移来添加更多的细节给事务性建模协议。一个事务是一个对象,包含了一系列的信号和握 手系统组件所需的数据交换。一个传输是一个原子操作,例如一个地址或数据的转移。它代 表了一个故障的事务到细微的细节。对建模来说细节是必须的,例如，当一些数据不可用仍 然允许开始一个事物。与每个转一组属性相关联的信息,它代表的事务,这样的信息如，地址、 类型、规模等。使用非阻塞的事物级加墨的接口，每一次转移都有一个方法和事件来实现通 信与同步。
能来向用户提供。 •在传输层运输将请求转发到接口。 •阅读以一个地址,创建一个请求结构、调用和返回数据的传输。 •将地址和数据项写入请求结构并调用运输。
3.3 数据结构 传输函数是双向的,但是数据分成了运输的是在 2 结构。数据从发起者运送目标放在请求 结构和响应结构中包含的数据发送回来以启动程序。请求结构通常具有以下数据成员: • 地址 •写数据 •传输类型：写或者读 •属性，例如 获取字节，字节使能 •读数据
当设计一个 SoC 时，可以使用不同的设计流程,设计流程的选择是根据设计任务来确定的, 一个设计流的例子如图 2 所示。设计这种流功能模型需要建立不同的算法,。这些功能模型 使用的架构师要定义正确的硬件/软件分区,并探讨系统架构。结果是一个高级的、功能正确 的模型,它可以作为一个可执行的规范设计。一个软件开发模型可以从此模型中提取。这里 的目标是消除任何对软件设计师来说不重要的细节,相同的可执行的规范可以精炼到一个更 精确的模型,用于验证工程师。
研究
姓名： 学号： GS11062352 学院： 计算机学院
1.引言 事务级别建模一直是 SystemC 中一种重要的建模技术, 今天的日益复杂的片上系统
(SoC)设计包括嵌入式软件的运行在多个处理器核心,连接到内存和外围设备。随着复杂性的 增长,越来越多的软件和硬件外围设备组成的重用知识产权(IP)块。需要一个设计方法,其中 一个混合的应用软件和算法可以被映射到一个架构组成的可重用的 IP 模块。在这种情况下, 需要一个硬件合作设计的方法,允许快速地分析之间的取舍在硬件和软件的实现。验证和实 施工作都变得非常重要和有效的方法是要求涉及到创建一个最小数量的模型。为了达到这一 复杂的设计上有足够的仿真性能、高级模型不仅需要模拟软件对一个模型的硬件,但是也来 加速这个过程建模的硬件 IP 在公共汽车上独立,重用友好的方式。模型还需要允许简单而快 速的芯片上的配置总线架构或通信网络。正是在这样的背景下,事务级别的建模被广泛的应 用了起来。
p_slave,
};
myPVResp PVSlave::theTransportfunc(const myPVReq& arg_Req){
cout << sc_time_stamp() << name()
<< " transport function is called with address "
使用显式的时机结构建模 4.4 systemc 的实现：隐式的时机。
这里概述一下使用显式的差异。这个 putRequest 在发起者和 getRequest 在目标是不同 的。他们把一个 sc_time 参数标注延迟时间。在此时间上的行为，需要遵照下面的调度。序 列用于发起者的 putRequest 使用隐式时间如下。
<< hex << arg_Req.getAddress() << endl << endl;
myPVResp theResp;
theResp.setResponse(pvOk);
return theResp;
};
3.5.2 DMA 模型
DMA 模式 4. SoC 的体系结构视图建模方法
简要概述体系结构视图建模对 SoC 设计验证的作用，结合典型实例论述 SoC 的体系结构 视图建模的技术方法。
的技术方法。 5.1 简介 在上面的讲述中,我们已经看到了如何创建一个易于使用,通用和提供良好的仿真速度的
事务建模接口, 但这个 API 不能建模时间上错综复杂的协议。作为设计改进失灵抽象层有一 个点,所有周期时间一个协议的细节是重要的。对于一个特定的类的互连策略循环周期交互 设计模块互连线总体系统性能有很大影响。详细的硬件设计还需要更多的时间周期。详细的 硬件设计可以发生在 SystemC，但也可以使用硬件描述语言(VHDL 和 Verilog），在所有这些 情况中这是一个我们之前讨论过可要重用模型，对于这个问题有两种解决方法，这允许以验 证是否精致块仍然实现了原始功能。验证了系统的总体时间模型还需要进一步改善。它不允 许验证互连行为的周期影响。
事务级建模的主要目的提高动态模拟速度,同时还要提供足够的精度来设计手头的任 务。事务级建模提供了一种最小化事件数量和信息数量的方法,因此事务级别建模应用最好 的是在设计问题这一级上,因为这一级沟通和系统级集成是主导。
事务级建模也是为了减少大量的细节,而这些细节是设计者们必须考虑的,因此让建模 更加容易。事务级模型让通信从行为中分离出来。这使得每个建模不相互影响。建模技术可 以支持不同的抽象级别,这样的细节可以添加或抑制了所需的一个给定的发展状态。
4.1 简要介绍 关键的问题在于,结构视图建模需要解决的问题是提高早期的架构平衡系统的设计,使设 置正确的设计约束对 HW 和 SW 实现团队。这个问题的解决方案空间非常大,因此需要设计者 的经验来找到最好的解决方案。建模风格的目标是使设计师评估不同的设计决策。评价是通 过模拟和分析来完成的。 为了有好的设计决策架构，一个足够精确的通信模型和/或内存需求需要来自系统的需 求。因此建模风格将专注于通信时间和资源共享(point2point,共享总线,…)以及数据的大 小。建模风格应该在处理系统的需求,不实现这些需求,在这种情况下,它面对的主要是高水 平的版本的系统功能和估计。另一方面许多今天的设计重用以前的设计元素,所以建模风格 应该是开放的足以允许插入更详细的实现模型。
隐式时机的结构模型
4.5 混合模式类型 从程序员的角度来说能够重用模式对于创建结构模式来说是有益的，在这种情况下,需要 创建的适配器,把“运输”协议 PV 的架构建模的接口。这需要考虑到同步以及数据类型转换。 在伪代码创建一个适配器连接 PV 发起者一 AV 通道如下:
RESP Transport(const & REQ){ RESP Transport(const & REQ){ putRequest (REQ); wait (ok_to_get_response); getResponse (RESP); return RESP; }
•响应状态：可以了 ，错误 3.4 SystemC 的实现 事物级建模接口是实例化自定义数据结构。
template< typename AT, typename DT > class PV_if : virtual public tlm_transport_if< PVReq< AT, DT>, PVResp< DT> > { public : virtual PVResp< DT> transport( const PVReq< AT, DT> & ) = 0; };
myPVResp theTransportfunc(const myPVReq& arg_Req);
};
PVSlave::PVSlave(sc_module_name name) : sc_module(name),
p_slave(){
REGISTER_PVSLAVE( theTransportfunc);
p u 重要的是了解可重入的代码时必须有多个线程可以调用这个传输函数(参见注三)。当连 t 接一个 AV 通道到一个 PVR目标需要创建一个适配器,它包含一个线程从双向传输 API 阻塞, e 因此需要被称为从一个线程。对于这样一个线程的伪代码如下: q u e s t
( R E
5 SoC 的验证视图建模方法 简要概述验证视图建模对 SoC 设计验证的作用，结合典型实例论述 SoC 的验证视图建模
程序员视图事物建模的一个关键风格是,它应该链接到一个有效的指令集仿真器。嵌入式 软件设计者将使用一个空间站模型一起使用他们平常的调试环境。一个嵌入式软件设计师可 以为平台开发软件来使用多任务操作系统的 API,并使用编译器为目标处理器来创建一个对 象文件的软件。
3.2 协议层 双向阻塞接口作为对程序员视图的最低层协议栈V。协议层在传输层建立一套方便的功
结构探索流程图
结构化视图有足够的时间来量化整体性能和辨别系统中潜在的瓶颈，时间可以是显式的 或隐式的。
4.2 数据结构 数据的准确性通常在是封装级别,即认为数据粒度是一组相关数据的功能,结合起来的抽 象数据类型(ADTs)。REQ 和 RESP 是基于应用的抽象数据类型,从数据结构概述了使用与程序 员看来,增强了一些数据的成员隐含的时机到携带大量的数据的结构,例如,一个完整的 IP 数据包。 4.3 System C: 显式的时机 一个请求放在通道启动程序(I),运输网络(N)到目标(T),起始者和目标是通过一个同步 信道(C)连接在一块。一个典型的请求交互事件发生的顺序如下:
但是有可能利用事务建模深入到细化过程,并创建一个事务建模风格,具有所有必需的周 期时间的细节硬件设计。在这一部分中创建验证视图是一个风格。验证视图包含足够的细节 以使周期准确的进行 HW 开发和验证。因此周期准确总线模型是必需的,以及交易人与 RTL 启用联合仿真,信号是被利用而不是一个事物级建模的 API。
本文的目的是提供了一个基于 SystemC 的事务级建模方法。更具体地说,我们将解决如何 支持不同的 SoC 设计和资料交换层级验证任务。在本文中我们将首先介绍事务级别建模描述 的目，它怎样标准化,并概述不同的解决方法。 2.SoC 设计任务与多视图设计和验证方法
论述 SoC 软件设计、体系结构设计、系统验证的主要任务和目标，论述 SoC 的多视图设 计验证方法与设计流程，论述事务级模型对支持 SoC 多视图设计和验证的重要性。
Figure 2: design flow
3.SoC 的程序员视图建模方法 简要概述程序员视图建模对 SoC 设计验证的作用，结合典型实例论述 SoC 的程序员视图
建模的技术方法。 3.1 简介 一个程序员的目标的观点是含有足够的细节以使大部分的嵌入式软件开发不同的处理元
素设计。一些需求是直截了当的:一个程序员的视图模型需要准确记录，它还需要能够中断 处理。一个值得注意的例子是周期需求的准确性来发展关键软件。这个软件需求的开发模型, 有更多的时间精度。事实上,公共汽车和芯片上沟通网络以及目标外围设备可以被建模而且 非常有利于仿真速度和开发时间。很明显,不同处理元素间的同步需要实现足够的细节来确 保正确的功能。同样重要的一点是同步不能依靠这个时间。
3.5 程序员视图模块实例 3.5.1 简单外设，下面是一个简单的 PV 外设模型的例子。
ຫໍສະໝຸດ Baidu
class PVSlave : public sc_module{
public:
PVTarget_port p_slave;
PVSlave(sc_module_name name);
SC_HAS_PROCESS(PVSlave);
另一种方法是定义目标基类,它实现运输。多个对象的实例化这些类可以在目标和直接 绑定到相应的 sc_export 建立目标端口。这对应于构建一个层次的目标。这种方法的问题是 目标数据成员不能被直接访问这个传输实现类。因此,数据或参考数据或目标的这个指针需 要通过分解成这些类。
另一种替代方法是相同的传输函数绑定到多个端口。这需要传递的信息在 REQ 结构,允许 解码的目标端口实际上是触发。这种编码风格也分开的原则冲突沟通和行为。
5.2 基于多转移的协议栈 验证观点是建立在具有相同的单向非阻塞接口中如同在体系结构视图被使用的那样。体 系结构视图使用两种基本的接口或转移来创建一个协议。用于验证协议实现视图使用更多的 转移来添加更多的细节给事务性建模协议。一个事务是一个对象,包含了一系列的信号和握 手系统组件所需的数据交换。一个传输是一个原子操作,例如一个地址或数据的转移。它代 表了一个故障的事务到细微的细节。对建模来说细节是必须的,例如，当一些数据不可用仍 然允许开始一个事物。与每个转一组属性相关联的信息,它代表的事务,这样的信息如，地址、 类型、规模等。使用非阻塞的事物级加墨的接口，每一次转移都有一个方法和事件来实现通 信与同步。
能来向用户提供。 •在传输层运输将请求转发到接口。 •阅读以一个地址,创建一个请求结构、调用和返回数据的传输。 •将地址和数据项写入请求结构并调用运输。
3.3 数据结构 传输函数是双向的,但是数据分成了运输的是在 2 结构。数据从发起者运送目标放在请求 结构和响应结构中包含的数据发送回来以启动程序。请求结构通常具有以下数据成员: • 地址 •写数据 •传输类型：写或者读 •属性，例如 获取字节，字节使能 •读数据
当设计一个 SoC 时，可以使用不同的设计流程,设计流程的选择是根据设计任务来确定的, 一个设计流的例子如图 2 所示。设计这种流功能模型需要建立不同的算法,。这些功能模型 使用的架构师要定义正确的硬件/软件分区,并探讨系统架构。结果是一个高级的、功能正确 的模型,它可以作为一个可执行的规范设计。一个软件开发模型可以从此模型中提取。这里 的目标是消除任何对软件设计师来说不重要的细节,相同的可执行的规范可以精炼到一个更 精确的模型,用于验证工程师。