SystemC AMS扩展语言参考手册1.0

4星 · 超过85%的资源需积分: 9 18 浏览量更新于2024-08-01 收藏 1.61MB PDF 举报

"OSCI(SystemC AMS扩展)语言参考手册1.0版" 《OSCI(SystemC AMS扩展)语言参考手册》是针对SystemC在模拟混合信号(Analog Mixed Signal, AMS)领域的扩展进行详细阐述的专业文档，版本号为1.0。该手册由Open SystemC Initiative (OSCI)于2010年3月发布，旨在提供一套标准的SystemC AMS扩展规范，以支持硬件描述语言(Hardware Description Language, HDL)中的异质性建模与仿真。 SystemC是一种基于C++的高级系统级建模语言，最初设计用于数字系统的建模。然而，随着半导体技术的发展，模拟和混合信号设计的需求日益增加，OSCI引入了AMS扩展，使得SystemC能够处理模拟和数字混合的设计问题，从而覆盖更广泛的系统建模领域。关键词包括Open SystemC Initiative, SystemC, Analog Mixed Signal, Hardware Description Language以及Heterogeneous Modeling and Simulation，这些关键词强调了手册的核心内容：开放、标准化、多学科的系统级建模工具和方法。手册中的内容可能涵盖以下几点： 1. **系统C AMS扩展概述**：介绍SystemC如何通过AMS扩展支持模拟和混合信号设计的基本概念，包括新的数据类型、类库和操作。 2. **语言结构和语法**：详细描述新的AMS扩展对SystemC语言结构的扩展，包括类定义、模块、端口、操作和事件处理等方面的修改。 3. **模拟行为建模**：解释如何使用扩展来表示模拟电路的行为，如连续时间模型（CTMs）和离散时间模型（DTMs）。 4. **接口和互连**：说明如何设计和实现模拟和数字模块之间的接口，以及它们如何交互。 5. **仿真模型**：介绍如何构建和运行包含模拟组件的混合信号系统模型，以及仿真控制和结果分析。 6. **示例和应用**：提供实际的代码示例，帮助用户理解和应用AMS扩展到具体的设计问题中。 7. **版权和许可信息**：文档明确指出，软件和文档的使用和复制需遵循SystemC开源许可证，同时强调了对版权、商标和服务标记的尊重。 8. **目的地控制声明**：可能涉及到文档分发和使用的限制或规定。此手册对于从事模拟和混合信号系统设计、验证的工程师，以及系统级建模和仿真领域的研究人员来说，是一份极其重要的参考资料。通过学习和应用手册中的内容，用户可以更高效地开发和验证跨越数字、模拟边界的复杂系统。

March 8 2010 Standard SystemC AMS extensions Language Reference Manual

An AMS interface proper is an abstract class derived from the class sca_core::sca_interface and associated

with a model of computation.

An AMS channel is a non-abstract class derived from one or more interfaces and associated with a model

of computation.

An AMS node is an object of the class sca_eln::sca_node or sca_eln::sca_node_ref and is an AMS channel

associated with the electrical linear networks model of computation.

An AMS signal is an object of the class sca_tdf::sca_signal or sca_lsf::sca_signal and is an AMS channel

associated with the timed data flow or linear signal flow model of computation, respectively.

2.2. Syntactical conventions

2.2.1. Implementation-defined

The italicized term implementation-defined is used where part of a C++ definition is omitted from this

standard. In such cases, an implementation shall provide an appropriate definition that honors the semantics

defined in this standard.

2.2.2. Disabled

The italicized term disabled is used within a C++ class definition to indicate a group of member functions

that shall be disabled by the implementation so that they cannot be called by an application. The disabled

member functions are typically the default constructor, the copy constructor, or the assignment operator.

2.2.3. Ellipsis

An ellipsis, which consists of three consecutive dots (…), is used to indicate that irrelevant or repetitive

parts of a C++ code listing or example have been omitted for clarity.

2.2.4. Class names

Class names italicized and annotated with a superscript dagger (

†

) should not be used explicitly within

an application. Moreover, an application shall not create an object of such a class. An implementation

is strongly recommended to use the given class name. However, an implementation may substitute an

alternative class name in place of every occurrence of a particular daggered class name.

Only the class name is being considered here. Whether any part of the definition of the class is

implementation-defined is a separate issue.

The class names in question are the following:

sca_core::sca_assign_from_proxy

†

sca_tdf::sca_ct_vector_proxy

†

sca_core::sca_assign_to_proxy

†

sca_util::sca_information_mask

†

sca_tdf::sca_ct_proxy

†

sca_util::sca_traceable_object

†

2.2.5. Prefixes for AMS extensions

The AMS extensions are denoted with the prefix sca_ for namespaces, classes, functions, global definitions

and variables and with the prefix SCA_ for macros and enumeration values.

An application shall not make use of these prefixes for namespaces, functions, global definitions, variables,

macros, and classes derived from the classes as defined in this standard.

2.3. Typographical conventions

The following typographical conventions are used in this standard:

1. The italic font is used for:

Standard SystemC AMS extensions Language Reference Manual March 8 2010

• Cross references to terms defined in Subclause 2.1, “Terminology”, Subclause 2.2, “Syntactical

conventions”, and Annex B, “Glossary”.

• Arguments of member functions in class definitions and in the text that are generally substituted with

real values by the implementation or application.

2. The bold font is used for all reserved keywords of SystemC and the AMS extensions as defined in

namespaces, macros, constants, enum literals, classes, member functions, data members and types.

3. The constant-width (Courier) font is used:

• for the SystemC AMS class definition including its member functions, data members and data types.

• to illustrate SystemC AMS language examples when the exact usage is depicted.

• for references to the SystemC AMS language syntax and headers.

The conventions listed previously are for ease of reading only. Editorial inconsistencies in the use of

typography are unintentional and have no normative meaning in this standard.

2.4. Semantic conventions

2.4.1. Class definitions and the inheritance hierarchy

An implementation may differ from this standard in that an implementation may introduce additional base

classes, class members, and friends to the classes defined in this standard. An implementation may modify

the inheritance hierarchy by moving class members defined by this standard into base classes not defined

by this standard. Such additions and modifications may be made as necessary in order to implement the

semantics defined by this standard or in order to introduce additional functionality not defined by this

standard.

2.4.2. Function definitions and side-effects

This standard explicitly defines the semantics of the C++ functions for the AMS class library for SystemC.

Such functions shall not have any side-effects that would contradict the behavior explicitly mandated by

this standard. In general, the reader should assume the common-sense rule that if it is explicitly stated that

a function shall perform action A, that function shall not perform any action other than A, either directly

or by calling another function defined in this standard. However, a function may, and indeed in certain

circumstances shall, perform any tasks necessary for resource management, performance optimization, or to

support any ancillary features of an implementation. As an example of resource management, it is assumed

that a destructor will perform any tasks necessary to release the resources allocated by the corresponding

constructor. As an example of an ancillary feature, an implementation could have the constructor for class

sca_core::sca_module increment a count of the number of module instances in the module hierarchy.

2.4.3. Functions whose return type is a reference or a pointer

Many functions in this standard return a reference to an object or a pointer to an object, that is, the return

type of the function is a reference or a pointer. This subclause gives some general rules defining the lifetime

and the validity of such objects.

An object returned from a function by pointer or by reference is said to be valid during any period in which

the object is not deleted and the value or behavior of the object remains accessible to the application. If

an application refers to the returned object after it ceases to be valid, the behavior of the implementation

shall be undefined.

2.4.3.1. Functions that return *this or an actual argument

In certain cases, the object returned is either an object (*this) returned by reference from its own member

function (for example, the assignment operators), or is an object that was passed by reference as an actual

argument to the function being called (for example, std::ostream& operator<<(std::ostream&, const T&) ).

In either case, the function call itself places no additional obligations on the implementation concerning the

lifetime and validity of the object following return from the function call.

March 8 2010 Standard SystemC AMS extensions Language Reference Manual

2.4.3.2. Functions that return char*

Certain functions have the return type char*, that is, they return a pointer to a null-terminated character

string. Such strings shall remain valid until the end of the program.

2.4.4. Namespaces and internal naming

An implementation shall place every declaration and definition specified by this standard within one of the

following namespaces: sca_core, sca_tdf, sca_lsf, sca_eln, sca_ac_analysis or sca_util.

The core language base classes shall be placed in the namespace sca_core.

For the predefined models of computation, the following namespaces shall be used:

• The predefined classes for timed data flow shall be placed in the namespace sca_tdf.

• The predefined classes for linear signal flow shall be placed in the namespace sca_lsf.

• The predefined classes for electrical linear networks shall be placed in the namespace sca_eln.

The predefined classes for small-signal frequency-domain analyses shall be placed in the namespace

sca_ac_analysis. The utilities shall be placed in the namespace sca_util.

It is recommended that an implementation uses nested namespaces in order to reduce to a minimum the

number of implementation-defined names in these namespaces.

For predefined primitive modules, which use ports to connect to a different model of computation, the

namespace associated with the connected model of computation shall be used as nested namespace. The

nested namespace sca_de shall be used for modules or ports, which are used to connect to SystemC discrete-

event channels or ports.

In general, the choice of internal, implementation-specific names within an implementation can cause

naming conflicts within an application. It is up to the implementor to choose names that are unlikely to

cause naming conflicts within an application.

2.4.5. Non-compliant applications and errors

In the case where an application fails to meet an obligation imposed by this standard, the behavior of the

AMS implementation shall be undefined in general. When this results in the violation of a diagnosable

rule of the C++ standard, the C++ implementation will issue a diagnostic message in conformance with

the C++ standard.

When this standard explicitly states that the failure of an application to meet a specific obligation is an

error or a warning, the AMS implementation shall generate a diagnostic message by calling the function

sc_core::sc_report_handler::report. In the case of an error, the implementation shall call function report

with a severity of sc_core::SC_ERROR. In the case of a warning, the implementation shall call function

report with a severity of sc_core::SC_WARNING.

An implementation or an application may choose to suppress run-time error checking and diagnostic

messages because of considerations of efficiency or practicality. For example, an application may call

member function set_actions of class sc_core::sc_report_handler to take no action for certain categories

of reports. An application that fails to meet the obligations imposed by this standard remains in error. There

are cases where this standard states explicitly that a certain behavior or result is undefined. This standard

places no obligations on the implementation in such a circumstance. In particular, such a circumstance may

or may not result in an error or a warning.

2.5. Notes and examples

Notes appear at the end of certain subclauses, designated by the upper-case word “NOTE”. Notes often

describe consequences of rules defined elsewhere in this standard. Certain subclauses include examples

剩余151页未读，继续阅读

wbwauto

粉丝: 0
资源: 3

SystemC AMS扩展语言参考手册1.0

OSCI_SystemC_AMS_extensions_1v0_Standard

A SystemC Primer.pdf_systemC_

rcu_osci_stab_wait

GD32库函数rcu_osci_on

bsp_fwdgt_init

GD32F470如何从内部16M输出到200M

帮写一个GD32系统时钟设置代码设置为108兆

hopf_osci csdn

ICSPDAT/TX/CK/OSCI/AN17/RC0

OSCI和OSCO引脚有什么作用

最新资源