第一章 SystemC基础知识（一）

基于SystemC的高层次综合（HLS）技术已经开在美国和中国台湾地区并且有大量成功流片的实例，而关于HLS尚无一本书籍介绍该技术，本文稿将主要介绍Cadence的CTOS（C-to-Silicon）工具，在适当的地方也将介绍Synopsys的Cocentric System Studio，Mentro的catapult-C和Forte的Cynthesizer 。

作为本文稿的开篇，我们首先介绍SystemC的基础知识，或许你已经阅读过与SystemC主题相关的教程或者阅读过IEEE 1666-2011的SystemC语言标准，但仍请你稍微留意本章，本章将主要结合CtoS工具讨论SystemC的可综合子集。

在本章中，我们将讨论到适于CtoS综合的代码风格，规范的代码风格将让CtoS获得最大的性能提升并且将错误降到最低。CtoS可以接受大部分的C++和SystemC代码风格，如C++的模版，类，用户定义类型和一些指针用法；针对硬件，SystemC对C++进行了扩展，包括对定义接口的方法进行标准化，增加了对整形数据类型的比特分割（bit-slicing）和对并发与进程通信的控制能力。

CtoS可以将输入代码转换为从快速的I/O周期精确仿真模型到可综合的Verilog RTL等各种抽象层次的模型。这些模型可以使用传统的逻辑综合工具和物理设计流程进行综合。

要进行这些转换，显然CtoS必然要对代码风格做一些限制，这样才能创建可预测且一致的结果。这其中大部分的限制就是CtoS必须可以静态决定期望行为，比如动态的创建对象就是不支持的，因为这在硬件实现中没有对应的结构，因此这样的代码必须从设计中去掉。

作为CtoS输入的任何设计都必须有且只有一个顶层sc_module。输入模型的接口必须是信号级的描述，即接口必须用sc_in和sc_out端口进行描述。对于TLM设计，基于事务的被测模型必须使用transactor进行实例化，由transactor实现事务到顶层的信号转换，关于TLM设计的更多讨论，我们将在后面章节展开。

如果设计是层次化的，即顶层sc_module包含一个乃至更多的进程或者包含其他的sc_module，这些进程或者sc_module之间进行通信会使用sc_signal或者TLM接口，而对内部进程的描述我们可以使用C++，也可以用SystemC。

sc_module的构造函数不仅可以对声明为该sc_module成员的sc_module进行实例化，可以定义内部sc_module实例化成员之间的连接关系，而且还可以对定义在模块中的进程进行注册；当然sc_module的构造函数能做的事情还不仅于此，但是CtoS目前为止仅支持以上三种，在SystemC中，sc_siganl数据类型可以避免SystemC进程通信的竞争。

那么CtoS如何知道哪个sc_module是最顶层的module呢?答案之一是使用SC_MODULE_EXPORT宏，例如，我们将顶层的module使用SC_MODULE_EXPORT[1]宏进行声明，那么CtoS就知道该module是设计的最顶层module了；如果我们已经将最顶层sc_module实例化进了SystemC代码中，那么就不需要再显式的实例化一次，而可以在source_files属性中将实例化最顶层sc_module的SystemC文件包含进去并且在top_module_path属性中设置最顶层sc_module的实例，如下面的代码段：

而在top_module模块中，实例化了一个名为sub_module的模块：

为CtoS指定指定sub_module_inst为最顶层模块，我们可以将top_module_path属性设置为top_module.sub_module_inst并将source_file属性设置为SystemC源文件列表。

注意到上面的代码段中出现了SC_MODULE和SC_CTOR，这其实是分别定义sc_module和构造函数的宏，接下来我们将讨论到这两个宏。

作为最基本的综合单元，module其实就是一个C++类，该类继承自SystemC的sc_module类。在定义module时我们可以使用SC_MODULE宏，如：

我们在定义module时使用的SC_MODULE是一个宏，其定义为：

大侠，请继续，非常好的内容！

顶顶顶顶