使用SystemC AMS扩展进行系统级设计与验证入门指南

需积分: 10 80 浏览量更新于2024-07-15 1 收藏 7.58MB PDF 举报

"Accellera发布的《Accellera_SystemC_AMS_Users_Guide_January_2020.pdf》是一本针对电子系统级工程师和架构师的入门指南，旨在介绍如何使用SystemC™模拟/混合信号(AMS)扩展进行系统级设计和验证任务。该指南基于IEEE Std. 1666-2011、IEEE Std. 1666.1-2016标准以及ISO/IEC 14882:2003定义的C++编程语言，提供了一个自我学习平台，帮助读者理解并运用SystemC AMS扩展。 SystemC AMS是用于混合信号系统设计的一种重要工具，它扩展了SystemC的基本功能，允许在不同抽象层次上创建离散时间和连续时间模型。该用户指南假设读者对SystemC建模和仿真以及C++有基本了解，并熟悉模拟/混合信号设计和建模。阅读此指南后，读者应能： 1. 了解SystemC AMS扩展的适用场景和需求。 2. 理解引入的计算模型和相关执行语义。 3. 使用语言构造来创建不同抽象层次的离散时间模型和连续时间模型。 4. 结合SystemC和AMS扩展设计混合信号系统。 5. 进行时域和频域分析以及AMS信号的追踪。该用户指南中的AMS设计方法、建模风格和示例都基于上述标准。任何兼容该标准的模拟器都可以用来构建和执行这些示例。虽然Accellera通过共识开发过程制定标准，但不保证标准中的信息准确性，使用标准完全是自愿的，Accellera不承担任何因使用标准可能造成的个人伤害、财产损失或其他损害的责任。" 在这篇用户指南中，读者将深入学习到如何使用SystemC AMS扩展来处理模拟和混合信号的设计挑战，包括如何利用其独特的建模技术进行高级抽象设计。此外，通过实际示例，读者将学会如何将这些模型结合到实际的混合信号系统中，并进行必要的分析和调试。这使得设计者能够在更早的阶段发现和解决问题，提高了设计效率和质量。同时，该指南还涵盖了执行语义和分析技巧，这些都是成功应用SystemC AMS扩展的关键要素。

SystemC Analog/Mixed-Signal User’s Guide

User Perspective on IEEE Std. 1666.1-2016

2. Timed Data Flow modeling

2.1 Modeling fundamentals

The Timed Data Flow (TDF) model of computation is based on the Cyclo-static Synchronous Data Flow

(CSDF) modeling formalism. Unlike the untimed CSDF model of computation, TDF is a discrete-time

modeling style, which considers data as signals sampled in time. These signals are tagged at discrete points in

time and carry discrete or continuous values like amplitudes.

Figure 2.1 shows the basic principle of the Timed Data Flow modeling. In this figure, there are three

communicating TDF modules called A, B, and C. A TDF model is composed of a set of connected

TDF modules, which form a directed graph called TDF cluster. TDF modules are the vertices of the graph,

and TDF signals correspond to its edges. A TDF module may have several input and output TDF ports. A

TDF module containing only output ports is also called a producer (source), while a TDF module with only

input ports is a consumer (sink). TDF signals are used to connect ports of different modules together.

Each TDF module contains a C++ method that computes an arbitrary function f (i.e., f

, f

, and f

), which

depends on its direct inputs and possible internal states. The overall behavior of the cluster is therefore defined

as the mathematical composition of the functions of the involved TDF modules in the appropriate order, f

(...))), indicated with schedule {A→B→C} in Figure 2.1.

Figure 2.1—A basic TDF model with 3 TDF modules and 2 TDF signals

A given function is processed (or ‘fired’ according to the SDF formalism) if there are enough samples available

at the input ports. In this case, the input samples are read by the TDF module, where the function uses

these values to compute one or more resultants, which are written to the appropriate output ports. During the

execution of a schedule, the number of samples read from or written to the module ports is fixed, where the

number of read and written samples by a TDF module are not necessarily equal. The number of samples read

from or written to the module ports can be changed during the simulation after the execution of each schedule.

A time stamp is associated to each sample using the local TDF module time. The interval between two samples

is called the time step.

2.1.1 TDF module and port attributes

The flexibility and expressiveness of TDF modeling comes from the ability to define the attributes of each

TDF module and of each of its TDF ports. In TDF, it is possible:

— To assign a particular time step to a TDF module. The module time step defines the time interval

between each module activation. Figure 2.2a shows a TDF module A with a module time step (Tm)

of 20 µs.

— To assign a particular maximum time step to a TDF module. The maximum time step enforces the

module activation if this time period is reached. Figure 2.2a shows a TDF module A with a module

time step (Tm,max) of 1 second.

SystemC Analog/Mixed-Signal User’s Guide

User Perspective on IEEE Std. 1666.1-2016

— To assign a particular time step to a given port of a TDF module belonging to the cluster. The time step

defines the time interval between two consecutive samples which are written to or read from the port.

Figure 2.2b shows a TDF module B with a TDF input port time step (Tp) of 10 µs.

— To assign a particular maximum time step to a given port of a TDF module belonging to the cluster.

The maximum time step defines the maximum allowed time interval between two consecutive samples

which are written to or read from the port. Figure 2.2b shows a TDF module B with a TDF input

maximum port time step (Tp,max) of 1 second.

— To assign a particular rate to a given port of a module belonging to the cluster. Figure 2.2b shows a

TDF module B, where at each module activation 2 samples are read (input port rate R set to 2, indicated

with R:2).

— To assign a particular delay to a given port of a module belonging to the cluster. Figure 2.2c shows a

TDF module C, where at each module activation, the sample corresponding to the previous time step

is written (output port delay D set to 1 sample, indicated with D:1).

— To assign a particular continuous-time delay to a given decoupling port of a module belonging to the

cluster. Figure 2.2d shows a TDF module D, where at each module activation, the sample is written to

the output port with a continuous-time delay of 0.8 µs.

Figure 2.2—TDF module and port attributes

Provided that the attribute assignment on the ports and modules of a TDF model are compatible, the order

of activation of the TDF modules in a cluster and the number of samples they read (consume) and write

(produce) can be statically determined before simulation starts and may be changed after the execution of

each schedule. Thus, and more formally, a TDF cluster can be defined as the set of connected TDF modules,

which belong to the same static schedule. The latter may change over time in terms of order and number of

activations of each TDF module, but no new TDF modules can be added to a cluster nor TDF modules can be

removed from the cluster during simulation. If the attribute assignments are not compatible, the static schedule

cannot be established and the TDF cluster is said to be not schedulable (see also Section 2.1.4). Therefore,

after the required TDF cluster consistency check, the schedule defines a sequence, in which the algorithmic

or procedural description of each TDF module is executed.

The main advantage of using a static schedule is that the execution of TDF models does not rely on the evaluate/

update mechanism of SystemC’s discrete-event kernel, resulting in more efficient and thus faster simulations.

TDF models are processed independently, using a local time annotation mechanism. Interactions between

TDF models and pure SystemC models are supported through specific converter ports, as discussed in Section

2.4.

2.1.2 Static and dynamic modes of operation

The TDF model of computation supports two modes of operation, which defines the way how changes of the

TDF attributes (time step, rate or delay) are handled while executing the schedule.

—

Static: in this case, TDF module attributes are not changed during simulation. Attributes are only

defined prior to simulation and remain fixed during simulation.

SystemC Analog/Mixed-Signal User’s Guide

User Perspective on IEEE Std. 1666.1-2016

—

Dynamic: in this case, the TDF model attributes are changed during simulation. Attributes can be

redefined, and will be evaluated at the end of the execution of the schedule, and–if valid–will become

effective in the next execution of the schedule.

An application may switch between the static and dynamic modes of operation during simulation. The mode of

operation will be based on the properties of each individual TDF module in a cluster. To this end, the application

can mark each TDF module to accept or reject attribute changes, and to do or not do attribute changes itself.

By default, a TDF module does not accept attribute changes and also does not make attribute changes itself,

which will enforce a static mode of operation. This means that in order to use TDF modules in a dynamic mode

of operation, each individual TDF module in a cluster shall define explicitly that changes to the TDF attributes

are supported.

Figure 2.3 shows a TDF cluster with three TDF modules for the static mode of operation. TDF module A

has no specific settings defined on how to deal with TDF attributes. It relies on the default settings, which

means it will reject attribute changes from other TDF modules in the cluster and it does not change attributes

itself. TDF module B explicitly defines that it will accept attribute changes from other TDF modules. By

default, TDF module B does not change attributes itself, similar as module A. TDF module C explicitly defines

that it does not change attributes itself. By default, TDF module C will reject attribute changes from other

TDF modules in the cluster. Even though TDF module B accepts attribute changes, none of the modules does

make changes to the attributes. As a result, the TDF cluster operates under the static mode of operation.

Figure 2.3—TDF modules and their settings resulting in a static mode of operation

Figure 2.4 shows a TDF cluster with three TDF modules for the dynamic mode of operation. The TDF modules

A, B, and C accept attribute changes from other TDF modules in the cluster. TDF module B does change the

TDF attributes, whereas module A and C by default do not change attributes.

Figure 2.4—TDF modules and their settings resulting in a dynamic mode of operation

If some TDF modules in a cluster define attributes for dynamic mode of operation and other TDF modules in

the same cluster specify attributes for static mode of operation, then an inconsistent set of attributes is specified.

For example, Figure 2.5 shows TDF module B, and C which both accept attribute changes. As TDF module

SystemC Analog/Mixed-Signal User’s Guide

User Perspective on IEEE Std. 1666.1-2016

B does make attribute changes, it enforces the dynamic mode of operation. However, TDF module A rejects

attribute changes (by default). This results in an inconsistency in the cluster attributes, which will cause an

error in simulation.

Figure 2.5—TDF modules attributes settings resulting in an inconsistency in the cluster.

2.1.3 TDF model topologies

Figure 2.6 shows an example of a TDF model with multirate characteristics. A port rate assignment with

rate value 2 (R:2) has been performed on the output port of TDF module A. Ports with no rate attribute are

considered to have a rate of 1 (not graphically represented). When module A is activated, 2 samples are written.

Since both modules, B and C, read one sample at each activation, a possible schedule for this TDF cluster is

{A→B→C→B→C}.

Figure 2.6—Multirate TDF model using port rate assignment

In order to handle TDF models containing loops, it is compulsory to introduce a delay on a module port

belonging to one of the modules of the loop. This port delay has to be defined during elaboration of the

simulation, to make the static scheduling feasible. A simple example is given in Figure 2.7, without loop, that

shows a module A with a delay of one sample associated to the output port (D:1). One possible schedule is

{A→B}. Schedule {B→A} is also possible since when module B first activated its input port will read the

sample already available thanks to the assigned delay defined in the elaboration phase.

Figure 2.7—TDF model with port delay

The initial value of the sample of a port with a delay is determined by the constructor of the corresponding

data types. The user is advised to set the values of the initial samples if port delays are used, because the value

will be undefined for C++ fundamental types due to the lack of a default constructor.

剩余197页未读，继续阅读

幻影盖伊

粉丝: 55
资源: 30

使用SystemC AMS扩展进行系统级设计与验证入门指南

2019.06VCS SystemC User Guide.pdf

SystemC资料.pdf

SystemC_AMS_2_0_LRM.pdf

my_systemc.rar

OSCI_SystemC_AMS_extensions_1v0_Standard

Accellera_Applauds_IEEE_SV_PR_110905-2_FINAL

uvm_users_guide_1.2.zip_UVM手册_site:www.pudn.com_uvm user guide 1

uvm_users_guide_1.1.pdf

SystemC_Synthesis_Subset_1_4_7.pdf

UVM_Class_Reference_Manual_1.2.pdf

最新资源