1. 介绍
所以选择C++而不选择Java作为系统级建模语言的basis的原因在于Java缺乏相关的实验性的实现，在表达系统级规约方法使用的人不多，且性能可能也是一个问题。
没有一个标准的、被广泛接受的系统级建模语言，IP核在系统级的开发、交流、重用都存在很大的问题。RTL级别的IP核存在仿真速度慢、知识产权保护困难、高层体系结构探索受限等等许多问题。VSIA制定了IP核的系统级模型应该满足的一些特点，如接口实现分离等等，所有这些特点在SystemC中都有很好的对应construct支持。
引文26有关于软硬件协调设计的信息。
SystemC2.0规范的开发时间为2000年中至2001年中。2.0版本改进了时间模型，包括了动态敏感表、通道、端口、基本通道和分层通道，另外，将SystemC之前与特点开发方法学相关的内容分离出来，形成与开发方法学无关的语言核和方法学相关的库。
Real design hardly ever start with a “clean sheet paper”，言下之意即是说没有任何设计是没有任何“负担”，从头开始的；或者说，任何设计都是基于一些现有的基础开始的。
一些需要同时使用不同层次的抽象模型的设计场景：
手头待测设计是一个详细的、实现级的模型，而该待测设计的激励生成以及响应检测模块则是一个抽象模型；
手头的设计的确是详细的、实现级的模型，但为了提高测试速度、保护知识产权，特意为其创建一个高层的抽象模型；
系统由很多模块组成，一个模块已经完成从高层抽象模型逐渐精化为一个实现级模型的过程了，但其他模块还没有完成此精化过程。
模型的所谓“精确”应该是有好几个维度的，分别为：
结构精确：包括硬件和软件。硬件指各模块的管脚精确；软件则是指各模块之间的通信已经精化到由RTOS的原语表达。
时序精确
功能精确：高层抽象中为简化模型不排除对一些功能也做了简化的可能，比如在高层模型中使用了浮点数，那么在底层模型中肯定要被替换为定点数。
数据组织精确：SystemC的软件模块中使用的数据结构与最终的软件实现是否一致。
通信协议精确：高层模型中的通信协议可能是比较抽象的，如TLM就将所有的通信统一抽象成阻塞式和非阻塞式两种，模型精化过程中当然要代之以具体的通信协议。
此外，讨论精确性时我们还有区分所谓精确是仅仅在模块的边界上精确还是深入到模块内部所有的子模块了。
几个不同的抽象层次：
可执行规约：有系统规约直接转换为SystemC得到，与任何可能的具体实现都没有关系，如果该模型中有时延，那么该实现是系统约束。可惜书中没有给出一个这样的与任何实现无关的、有系统规约直接转化来的SystemC可执行规约的例子，我很希望能看到一个这样的从系统规约开始直至RTL的系统的完整实现。
无时序功能模型：书上说其与可执行规约非常相视，不同点仅在于无时序功能模型没有任何时间约束， 不太明白什么意思。又说无时序功能模型中模块之间的通信都是点对点的，通过Fifo，没有为像总线这样的用于通信共享的模块建模， 还是不太明白。
时序功能模型：时序功能模型与无时序功能模型的相似之处就在于它们的模块的通信都是点对点的，无需为像总线这样的共享通信模块建模，并且模块的通信都是使用的fifo的阻塞式读写方法。不同之处在于，在时序功能模型中，需要为process添加时延以模拟处理需要的时延，需要修改fifo添加时延以模拟通信时延。此外，时序功能模型广泛应用于确定软硬件划分，通过将同一个process分别映射为软件实现和硬件实现来比较效果。 如何应用于确定软硬件划分的啊，又是泛泛而谈。
注意以上的可执行规约、无时序功能模型、时序功能模型都无法对应最终实现的结构，因为它们根本就没有结构信息。书上说第五章会描述如何用SystemC建立以上三种模型。 但似乎没有看到可执行规约啊。
事务级模型：在TLM中，模块间的通信是通过方法调用来完成的，因此就功能来说，TLM的通信是功能精确的，甚至通过在方法调用中加入时延，还可以让TLM的通信达到时序精确。但TLM的通信不是结构精确的。另外，所谓平台TLM，除了以上TLM的特点，就结构而言，还精确描述了系统的模块及模块间的关系。因此，平台TLM可精确模拟总线负载、总线竞争以及系统的整体性能，并且可以在系统开发的早期，就提供一个高性能、精确、高效的方式来模拟软硬件交互。
行为模型：行为模型中的模块在模块边界上是结构精确和功能精确的，但不是时序精确的，且在模块内部也不是结构精确的。行为模型可以为工具直接综合。
RTL：RTL在模块边界上是结构精确、时序精确、功能精确的，且在模块内部也是结构精确的。
本书的源码按照书中所说的方式根本下不到，书中描述的网站的Product & Solution 都根本不存在。
3. MoC
计算模型的非形式化定义：
使用的时间模型（实数时间、整数时间、无时间）和事件机制（全序还是偏序）；
事件的激活机制；
对同步进程的通信机制的支持
像Verilog、VHDL这样的硬件描述语言只支持一种计算模型，且该计算模型还不可定制，SystemC则不然，虽然它也有一个基本的计算模型，但该模型可非常容易的定制且它还支持其他计算模型。
SystemC可支持的计算模型包括：
静态multirate数据流
动态multirate数据流
Kahn process network
RTL硬件建模
网络建模
基于事务的SoC平台建模
以上这些模型分别是什么意义，SystemC 是如何支持它们的，不太清楚。
为什么SystemC要支持那么多计算模型？因为很多系统本身就不是同构的，而是由很多模块组成，各个模块使用了不同的计算模型。且同一个模块在不同的抽象层次上用不同的计算模型表达可能更加合适，例如，一个模块在功能建模时可能用静态multirate数据流表示比较合适，而在硬件建模时则用RTL模型更为合适。
目前OSCI有很多工作组，正在致力于为不同的计算模型制定标准。
RTL计算模型其实是对通过时钟信号来同步数字硬件的建模风格的一种非正式称谓。
RTL风格的建模中，process之间通过signal进行通信，process可通过敏感于时钟信号来表达时序逻辑，也可通过敏感于所有输入来表达组合逻辑。RTL模块是管脚精确以及时钟周期精确的。SystemC中的signal与VHDL的signal相似，与verilog的时延赋值（<=）相似，但SystemC的signal不能指定赋值时延，因为SystemC的开发者认为既然也无法指定组合逻辑的时延和门时延，那么指定赋值时延就没有什么意义了。 评论都说 verilog 在RTL 的表达能力最强，而SystemC 最弱，不知是否就是因为这个原因，那么我孜孜以求的想找一个从系统级精化至RTL 级的示例，这样的示例也许因为没有意义而根本就不存在。
Kahn Process Networks（KPN）：在KPN计算模型中，所有模块都通过一些无限长的fifo通信，无限长fifo使得模块对fifo的写是非阻塞的、读仍然是阻塞（初始时fifo可能还无数据）的。如果系统完全使用KPN建模，那么系统一定是确定的，既是说进程不同的执行顺序不会影响系统的对外表现， 但具体是如何保证的，我还是不太理解。KPN系统中没有时间的概念。无时序功能模型就可以认为是KPN了。
静态数据流（SDF）：KPN的一种特殊情况，表现在：
进程执行被明显的分为读数据、处理数据和写数据三个明显的阶段；
进程执行时将读写的数据是确定的，在编译时就已知了。
用SystemC表达SDF的方式就是使用
第五章中描述的数据流建模风格。注意数据流建模风格较之SDF更加的一般化，
何谓更一般化，没看懂。
TLM：TLM中模块之间的通信是通过方法调用完成的，进程之间通过共享数据完成数据交换，因此，如果没有一个同步机制，这种数据共享的方式很可能造成系统行为的不确定性。SystemC往往通过所谓的两阶段同步机制来保证系统行为的确定性。
