Prime Time User Guide 中英对照 第三章（下）

LunarJanuary

抽出时间终于把第三章剩下的部分翻译完了。

话不多说，直接上天

Loading Scenario Data Into the Master

You can load scenario data into the DMSA master so that you can query the scenario netlist, attributes, and timing path data, as well as control worker processes. This feature is in addition to the merged timing reporting capability described in Merged Reporting.

The following diagram shows the additional netlist and path query capabilities when you load the scenario data into the master.

Without the netlist loaded into the master, the get_timing_paths command at the master returns only text, not actual path collections, and the report_timing command produces merged reports in the master context.

如果没有将网表加载到主机中，主机的 get_timing_paths 命令仅返回文本，而不返回实际的路径集合，并且 report_timing 命令会在主机环境中生成合并的报告

The netlists of all the scenarios must be exactly the same. Only the constraints and operating conditions may vary between the scenarios. If there are any differences between netlists, or if there is no scenario loaded in the master, a command like report_timing or get_timing_paths uses the master-only mode to generate merged reports from the active scenarios.

所有scenario的网表必须完全相同。只有约束和操作条件可能因scenario而异。如果网表之间存在任何差异，或者主机中没有加载任何scenario，则 report_timing 或 get_timing_paths 等命令将使用master-only模式从活动scenario生成合并报告。

To load the scenario netlist, timing path data, and object attributes into the master, use the load_distributed_design command. The master loads the netlist from a scenario in the command focus. After loading the scenario data, the get_timing_paths command at the master returns a true collection, which you can then query to get more detailed information. You can also query the netlist and object attributes.

要将scenario网表、时序路径数据和对象属性加载到master中，请使用 load_distributed_design 命令。master从command focus中的scenario加载网表。加载scenario数据后，master 上的 get_timing_paths 命令将返回一个 true 集合，然后可以查询该集合以获取更详细的信息。您还可以查询网表和对象属性。

To query an object attribute in the design, the attribute value must be the same across all scenarios.

若要在设计中查询对象属性，属性值必须在所有方案中相同。

Loading a netlist at the master reserves a PrimeTime license for the DMSA master, meaning that this license (or part of it in the case of core-based licensing) is not shared with any worker processes running DMSA scenarios. In contrast, without loading the netlist, a PrimeTime license checked out by the master at startup is shared with remote workers.

在主机上加载网表会为DMSA主机使用一个PrimeTime许可证，这意味着此许可证（或在core-based的许可证其中的一部分）不会与运行DMSA scenarios的任何工作进程共享。相比之下，在不加载网表的情况下，主机启动时签出的PrimeTime许可证将与remote workers共享。

To remove loaded distributed data, use the remove_distributed_design command.

若要删除加载的分布式数据，请使用 remove_distributed_design 命令

Saving and Restoring Your Session

You can find the images generated by the master-issued save_session command in the $sh_launch_dir/images/scen1 and $sh_launch_dir/images/scen2 directories. You can then reload these images into a single scenario PrimeTime session.

您可以在 $sh_launch_dir/images/scen1 和 $sh_launch_dir/images/scen2 目录中找到 master 发出的 save_session 命令生成的images。然后，您可以将这些images重新加载到单个scenario的PrimeTime session中。

The save and restore features allow you to explicitly restore a saved image into a DMSA scenario. This is achieved with the addition of the create_scenario -image option. By using the -image option, you can load any single-core analysis PrimeTime image that has been produced by the save_session command (either inside or outside of DMSA). Load this image into DMSA directly as a scenario. You can then operate upon it in the normal way within the context of DMSA.

保存和重建功能允许您将保存的image显式还原到 DMSA scenario中。这是通过添加 create_scenario -image 选项来实现的。通过使用 -image 选项，您可以加载由 save_session 命令生成的任何单核分析 PrimeTime image（在 DMSA 内部或外部）。将此image直接加载到 DMSA 中作为scenario。然后，您可以在 DMSA 的context中以正常方式对其进行操作

License Resource Management

By default, the master takes care of its own licensing regardless of the licenses required to perform multi-scenario analysis. After the master is launched, it acquires any needed PrimeTime licenses from the license pool in the same way as a single scenario PrimeTime session. The master then dynamically distributes the licenses to the worker processes.

默认情况下，无论执行多场景分析所需的许可证如何，主服务器都会处理自己的许可。启动主服务器后，它会以与单个方案PrimeTime会话相同的方式从许可证池中获取任何所需的PrimeTime许可证。然后，主服务器将许可证动态地分发给工作进程。

To specify the maximum number of licenses of a particular feature that the master can check out from the license pool for multi-scenario processing, use the set_license_limit command. Any licenses that the master checks out are available for worker usage.

要指定主机可以从许可证池中签出的以进行多scenario处理的特定功能的许可证的最大值，请使用 set_license_limit 命令。主机签出的任何许可证都可供worker使用。

In the following example, the limit on the number of PrimeTime licenses to use is set to five.

在以下示例中，可使用的PrimeTime许可证数量限制为5个。

pt_shell> set_license_limit PrimeTime -quantity 5

The master process checks out no more than four additional licenses (but might check out fewer depending on the availability in the main licensing pool).

主机可签出的许可证不超过四个（但可签出的许可证可能更少，取决于主许可证池中的可用许可证的数量）。

By default, licenses are checked out only after the workers begin processing tasks. To check out licenses immediately, use the get_license command with the -quantity option.

默认情况下，只有在worker开始处理任务后，才会签出许可证。要立即签出许可证，请使用 get_license 命令带 -quantity 选项。

If any analysis being performed involves crosstalk analysis, you must set the limit on the number of PrimeTime SI licenses to use during multi-scenario analysis. For example, the following command sets the limit on the number of PrimeTime SI licenses for worker usage to six. Since the master has not checked out a PrimeTime SI license, it checks out up to six PrimeTime SI licenses for worker usage during multi-scenario analysis:

如果正在执行的任何分析涉及串扰分析，则必须对在多scenario分析期间使用的PrimeTime SI许可证数量设置限制。例如，以下命令将worker使用的PrimeTime SI许可证数量限制设置为6个。由于主机尚未检出PrimeTime SI许可证，因此在多scenario分析期间，它最多会检出6个PrimeTime SI许可证供worker使用

pt_shell> set_license_limit PrimeTime-SI -quantity 6

Since the master dynamically allocates licenses to the worker processes on an as-needed basis, a worker process uses a license only when it is actively executing a task. This is important in the context of maximizing the overall performance of the multi-scenario mechanism. Therefore, it is possible to have more worker processes added than licenses available for them to use. The master distributes tasks across all of the worker processes, and as each begins to execute a task, it checks out the appropriate licenses from the master for the duration of time it takes to execute the task. After the task is complete, the worker process returns the licenses to the master for other worker processes to use

由于主机会根据需要，动态地将许可证分配给工作机，因此工作进程仅在主动执行任务时才使用许可证。这在最大限度地提高多scenario机制的整体性能方面非常重要。因此，这使工作机数量多于可使用的许可证成为可能。主机在所有工作机中分配任务，当每个进程开始执行任务时，它会在执行任务所需的时间内从主进程中签出相应的许可证。任务完成后，工作机将许可证返给主机，供其他工作机使用

The benefit of this mechanism is that if you have more worker processes than licenses, you can maximize the multi-scenario system throughput by minimizing the expensive process involved in swapping out a scenario.

此机制的好处是，如果工作进程数多于许可证数，你可以通过把交换scenario的昂贵进程最小化来将多scenario系统吞吐量最大化。

For optimal system performance of DMSA, match the license limit to the number of worker processes added. In this way, all worker processes can execute concurrently, thereby maximizing the system throughput.

为了获得 DMSA 的最佳系统性能，请将许可证限制与添加的工作进程数相匹配。这样，所有工作机都可以并发执行，从而最大限度地提高系统吞吐量

DMSA provides the following license management capabilities:

• Core-Based Licensing – Allows you to check out licenses based on the number of scenarios running (one license set per scenario, the default) or the number of cores used (once license set per 32 cores).

• 基于核数的许可 - 允许您根据运行的scenario数量（每个scenario一个许可证，默认）或使用的核数（每 32 个核设置一个许可证）签出许可证

• Incremental License Handling – Lowers the license limit; any licenses over the limit are returned to the license server pool.

• 增量许可证处理 – 降低许可证数量;任何超出限制的许可证都将返回到许可证服务器池

• License Pooling – Checks out licenses for different features from different license servers.

• 许可证池 – 从不同的许可证服务器签出不同功能的许可证

• License Autoreduction – Instructs the master to automatically reduce the number of licenses for features checked out to a minimum when those licenses are not needed.

• 许可证自动缩减 - 指示主服务器在不需要这些许可证时自动将签出的功能的许可证数量减少到最低限度

• License Queuing – Waits for licenses to become available if all of them are currently in use.

• 许可证队列 – 如果所有许可证当前都在使用中，则等待许可证变成可用状态

Core-Based Licensing

By default, each scenario requires its own license set while it is running. For example, running four scenarios with crosstalk and advanced analysis requires one license set (PrimeTime, PrimeTime-SI, and PrimeTime-ADV licenses) for each of the four scenarios, irrespective of the number of cores used. This mode is called scenario-based licensing.

默认情况下，每个scenario在运行时都需要自己的许可证。例如，运行具有串扰和高级分析功能的四个scenario需要为四个scenario中的每一个都设置一个许可证集（PrimeTime、PrimeTime-SI 和 PrimeTime-ADV 许可证），而不考虑使用的内核数量。此模式称为基于scenario的许可

You can optionally choose an alternative licensing mode called core-based licensing, in which one license is required for each 32 core processes running, irrespective of the number of scenarios. Using this mode requires a PrimeTime-ADV license.

您可以选择一种称为基于核数的许可模式作为替代，在这种模式下，每运行 32 个核心进程都需要一个许可证，而不考虑scenario的数量。此模式需要一个PrimeTime-ADV许可证。

To select core-based licensing, change the multi_scenario_license_mode variable setting from scenario to core in the DMSA master process:

若要选择基于核数的许可模式，请在 DMSA 主进程中将multi_scenario_license_mode变量设置从scenario更改为核数

pt_shell> set_app_var multi_scenario_license_mode core

After you set the variable, running any number of scenarios requires just one license set per 32 cores used. The 32 cores can be divided among multiple scenarios in any combination. For example, once license set can handle any of the following:

设置变量后，处理任意数量的scenario只需要每 32 个核设置一个许可证。这 32 个核可以任意组合地划分给多个scenario。例如，一个许可证集可以处理以下任何一项：

• 1 scenario x 32 cores per scenario

• 2 scenarios x 16 cores per scenario

• 4 scenarios x 8 cores per scenario

• 16 scenarios x 2 cores per scenario

If you need to run more than 32 cores, each additional 32 (or fraction thereof) requires another license set:

如果您需要32 个核以上，则每增加 32 个（或不满32个）就需要另一个许可证集

• 1 to 32 cores: 1 license set

• 33 to 64 cores: 2 license sets

• 65 to 96 cores: 3 license sets

• 97 to 128 cores: 4 license sets

Incremental License Handling

By default, incremental license handling is enabled and provides these capabilities:

默认情况下，增量许可证处理被使能，并提供以下功能

• You can increase or decrease the number of checked out licenses for a feature by using the get_license or remove_license command, respectively.

• 您可以分别使用 get_license 或 remove_license 命令来增加或减少签出各种功能许可证数量。

• You can use the set_license_limit command to change the maximum number of licenses checked out. if you reduce the limit, PrimeTime checks in enough licenses of the feature to meet the new target limit.

• 您可以使用 set_license_limit 命令更改签出的最大许可证数。如果您降低限制，PrimeTime 会签入足够的许可证以满足新的目标限制。

To disable incremental license handling, set the following environment variable:

要禁用增量许可证处理，请设置以下环境变量：

% setenv SNPSLMD_ENABLE_INCREMENTAL_LICENSE_HANDLING 0

If you disable incremental license handling, the master cannot check licenses back into the central license server until it exits. Changing the environment variable from within the master session has no effect.

如果禁用增量许可证处理，则主机在退出之前无法将许可证签回中央许可证服务器。从主session中更改环境变量不起作用。

License Pooling

License pooling allows you to check out licenses of different features from different license servers. You can activate license pooling by enabling incremental license handling. Before the master is launched, set the SNPSLMD_ENABLE_INCREMENTAL_LICENSE_HANDLING environment variable to 1. This variable enables incremental license check in, which allows PrimeTime to automatically return unused licenses during the timing update.

许可证池允许您从不同的许可证服务器签出不同功能的许可证。您可以通过启用增量许可证处理来激活许可证池。在启动主机之前，将 SNPSLMD_ENABLE_INCREMENTAL_LICENSE_HANDLING 环境变量设置为 1。此变量启用增量许可证签入，从而允许PrimeTime在timing更新期间自动返回未使用的许可证。

All licenses of a single feature must be provided by a single license server. License spanning, the ability to check out licenses for the same feature from multiple license servers, is currently unsupported.

单个功能的所有许可证必须由单个许可证服务器提供。目前不支持许可证跨区，即从多个许可证服务器签出同一功能的许可证的功能。

License Autoreduction

License autoreduction instructs the master to automatically reduce the number of licenses for features checked out to a minimum level when those licenses are not being used to perform work. You can enable or disable license autoreduction at any time from within the master by setting the enable_license_auto_reduction global variable to true to enable or false to disable. When autoreduction is enabled, if a scenario task is completed and no additional scenarios are waiting for the license, the license is returned to the central license pool.

许可证自动缩减指示主机在未使用这些许可证执行工作时，自动将签出的某一功能的许可证数量减少到最少。您可以随时在主机中启用或禁用许可证自动缩减，方法是将 enable_license_auto_reduction 全局变量设置为 true 以启用或 false 设置为禁用。启用自动缩减后，如果一个scenario的任务已完成，并且没有其他scenario正在等待许可证，则许可证将返回到中央许可证池

It is important to use this feature carefully because although it allows licenses to return to the central license server, there is no guarantee that subsequent analysis can reacquire those licenses for further use. If the master cannot reacquire the licenses or can only partially reacquire them, the level of concurrency in the DMSA is reduced. This can affect performance and time-to-results. Also, the time needed to repeatedly check in and check out the licenses themselves can significantly slow down interactive work, such as merged reporting or the execution of Tcl scripts or procedures that communicate heavily with the scenarios. In these cases, it might be desirable to enable autoreduction during the initial timing update and then disable it during interactive work as follows:

请务必谨慎使用此功能，因为尽管它允许许可证返回到中央许可证服务器，但不能保证后续分析可以重新获取这些许可证以供进一步使用。如果主机无法重新获取许可证或只能重新获取部分许可证，则 DMSA 中的并发级别会降低。这可能会影响性能和获得结果的时间。此外，重复签入和签出许可证本身所需的时间会显著减慢交互工作的速度，例如合并报告或执行与方案进行大量通信的 Tcl 脚本或过程。在这些情况下，可能需要在initial timing update期间启用自动缩减，然后在交互工作期间禁用它，如下所示

# get all scenarios to update their timing

set enable_license_auto_reduction true

remote_execute {update_timing}

# generate merged reports

set enable_license_auto_reduction false

report_timing ...

report_qor ;# Tcl proc from SolvNet (Doc ID 008602)

dmsa_fix_hold ... ;# Tcl proc from SolvNet (Doc ID 018510)

License Queuing

If all licenses are currently in use, you can wait for available licenses by enabling license queuing. To do this, set the SNPSLMD_QUEUE environment variable to true in the user environment.

如果所有许可证当前都在使用中，可以通过启用许可证队列来等待可用的许可证。为此，请在用户环境中将 SNPSLMD_QUEUE 环境变量设置为 true。

If you enable license queuing, also specify the maximum queue wait time (in seconds) by setting the SNPS_MAX_QUEUETIME environment variable. In DMSA, you should set this variable to a low value.

如果启用许可证队列，则还要通过设置 SNPS_MAX_QUEUETIME 环境变量来指定最大队列等待时间（以秒为单位）。在 DMSA 中，应将此变量设置为较低的值

When queuing for licenses, the master process is blocked until the requested license is available or when the maximum queue time expires. In the meantime, the worker processes with available licenses can proceed; when these worker processes finish, the master reassigns the available licenses to other workers.

排队获取许可证时，主进程将被阻止，直到请求到可用的许可证或达到最大排队时间。同时，具有可用许可证的工作进程可以继续进行;当这些工作进程完成时，主服务器会将可用许可证重新分配给其他工作进程。

Worker Process Fault Handling

When a fault occurs in a worker process that causes an abnormal termination, the tool takes action as determined by the multi_scenario_fault_handling variable, which you can set to ignore or exit.

当工作进程中发生导致异常终止的故障时，该工具将执行由 multi_scenario_fault_handling 变量确定的操作，您可以将其设置为忽略或退出。

When the variable is set to ignore (the default) and a critical fault occurs in a worker process, the abnormally terminated scenarios and the scenarios that depend on those that terminated are excluded from further analysis within the context of the current session. A warning message is displayed showing which scenarios abnormally terminated. The session then proceeds to analyze the remaining scenarios that are in command focus. The following situations might occur:

当变量设置为忽略（默认值）并且工作进程中发生严重故障时，异常终止的方案和依赖于终止的方案将从当前会话上下文中的进一步分析中排除。将显示一条警告消息，显示哪些方案异常终止。然后，会话继续分析命令焦点中的其余方案。可能会出现以下情况

• If all scenarios in command focus of the current session abnormally terminate, any subsequent distributed command issued at the master fails, and an error message explains that there are no scenarios in command focus. You need to change the command focus within the context of the current session and analyze the selected scenarios.

• 如果当前session的command focus中的所有scenario都异常终止，则在主机上发出的任何后续分步式命令都将失败，并且会显示一条错误消息，说明此comman focus中没有scenario。您需要在当前会话的上下文中更改命令焦点并分析所选方案

• If all scenarios in the current session abnormally terminate, the current session terminates and you receive a warning saying the session is removed. Any subsequent distributed commands issued at the master causes an error message explaining that there is no current session.

• 如果当前session中的所有scenario都异常终止，则当前session将终止，并且您会收到一条警告，指出session已被删除。在主机发出的任何后续分步式命令都会导致一条错误消息，说明没有当前session

• Critical faults cause resources to go offline. If the resources available are reduced to the point where none are online, the session must terminate and you receive an error message explaining that the current session has terminated.

• 严重故障导致资源下线。如果可用资源减少到没有一个在线，则session必须终止，并且您会收到一条错误消息，说明当前session已终止。

When the variable is set to exit and a critical fault occurs in a worker process, the active command completes its task and then the master process terminates the entire analysis. An information message is displayed explaining what occurred.

当变量设置为退出并且工作机的进程中发生严重故障时，活动命令将完成其任务，然后主机将终止整个分析。将显示一条信息说明发生的情况。

Merged Reporting and Worker Fault Handling

Merged reporting is a mechanism that works with all the scenarios in command focus to eliminate redundant data automatically across scenarios and sort the data in order of criticality. This allows you to treat all the scenarios in command focus as if they are a single virtual PrimeTime instance.

合并报告是一种适用于command focus中的所有scenario的机制，以自动消除跨scenario的冗余数据，并按关键程度对数据进行排序。这允许您将command focus中的所有scenario视为单个虚拟PrimeTime实例。

Due to the distributed feature, if one or more worker processes terminate abnormally, the relevant information for the reporting command is not available. Therefore, when a scenario terminates abnormally, you receive a warning message, and PrimeTime removes this scenario from the current session. It then automatically reissues the reporting command to the remaining scenarios in command focus. Any reporting command issued afterwards is applied only to the remaining scenarios in command focus and any abnormally terminated scenarios are excluded from further analysis.

由于分布式功能，如果一个或多个工作机进程异常终止，则报告命令的相关信息不可用。因此，当scenario异常终止时，您会收到一条警告消息，PrimeTime会从当前session中删除此scenario。然后，它会自动向command focus中的其余scenarios重新发出报告命令。之后发出的任何报告命令仅应用于command focus中的其余scenarios，并且任何异常终止的scenario都排除在进一步分析之外

Netlist Editing Commands and Worker Fault Handling

Before a netlist change is committed to any scenario from the master, it must be possible to commit the change to all scenarios. Thus, PrimeTime first checks that the netlist change could be successful in all scenarios and next it commits the change.

在将主机提交任一网表更改到任何scenario之前，必须能够将更改提交到所有scenario。因此，PrimeTime首先检查网表更改能否在所有scenario下都能成功，然后才提交更改。

If a scenario terminates abnormally while PrimeTime is checking the possibility of successfully executing the netlist change, this scenario is removed from the command focus, and the netlist editing command is automatically reissued to the remaining scenarios in command focus.

如果在PrimeTime检查执行网表更改成功的可能性时scenario异常终止，则该scenario将从command focus中删除，并且网表编辑命令会自动重新发出给command focus中的其余scenario。

If all of the checking processes succeeded in all scenarios, but there was a scenario that terminated abnormally when PrimeTime went to commit the change, a warning message is issued, and all the remaining scenarios in command focus apply the netlist change. Subsequent netlist editing commands are applied only to the remaining scenarios in command focus and any abnormally terminated scenarios are excluded from further analysis.

如果所有检查在所有scenario中都成功，但在PrimeTime提交更改时异常终止，则会发出警告消息，并且command focus中的所有其余scenarios都将应用更改后的网表。后续的网表编辑命令仅应用于command focus中的其余scenarios，任何异常终止的scenario都被排除在进一步分析之外

remote_execute Command and Worker Fault Handling

DMSA supports execution of any number of commands on all scenarios in command focus by using the remote_execute command. If the remote_execute command encounters a scenario that terminated abnormally, a warning message is issued, the scenario is removed from the current session, and subsequent calls to the command apply only to the remaining scenarios in command focus. Abnormal termination of one or more scenarios has no effect on command execution in other scenarios.

DMSA 支持使用 remote_execute 命令在command focus中的所有scenarios上执行任意数量的命令。如果 remote_execute 命令遇到异常终止的scenario，则会发出警告消息，从当前session中删除该scenario，并且对该命令的后续调用仅适用于command focus中的其余scenario。一个或多个scenarios的异常终止对其他scenario的命令执行没有影响。

Other Commands and Worker Fault Handling

The following commands do not come under the categories that have been listed, but they are handled in a similar way when an abnormal termination occurs.

• get_distributed_variables command

When a scenario terminates abnormally, you receive a warning message, and the scenario is removed from the current session. PrimeTime then automatically reissues the command to the remaining scenarios in command focus.

• get_timing_paths command

When a scenario terminates abnormally, you receive a warning message, and the scenario is removed from the current session. PrimeTime then automatically reissues the command to the remaining scenarios in command focus.

• save_session command

When a scenario terminates abnormally, you receive a warning message, and the scenario is removed from the current session. PrimeTime then automatically reissues the command to the remaining scenarios in command focus.

• set_distributed_variables command

When a scenario terminates abnormally, you receive a warning message, and the scenario is removed from the current session. The command executes as normal for the remaining scenarios in command focus.

Messages and Log Files

Multi-scenario analysis has the potential to generate large amounts of data. To avoid overloading you with data at the master, all data is written to a set of log files. A limited set of interactive messages are displayed at the master.

多scenario分析有可能生成大量数据。为了避免主机的数据过载，所有数据都将写入一组日志文件。在主机上显示一组有限的交互式消息

If you use the -verbose option, the remote_execute command sends all data to the master terminal.

如果使用 -verbose 选项，那么 remote_execute 命令会将所有数据发送到主终端

To learn about the types of messages and log files available in DMSA, see

• Interactive Messages

• 互动消息

• Progress Messages

• 进度消息

• User Control of Task Execution Status Messages

• 用户控制任务执行状态消息

• Error Messages

• 错误消息

• Warning Messages

• 警告消息

• Log Files

• 日志文件

• Command Output Redirection

• 命令输出重定向

Interactive Messages

While a task is executing on the workers, the workers send messages back to the master to indicate their progress.

当任务在工作机上执行时，工作机会向主机发送消息以表明其进度

Progress Messages

As the workers progress through each analysis stage, the workers send confidence messages to update you on the progress of the analysis. For example:

随着工作机完成每个分析阶段的进展，工作机会发送“信心”消息，以更新分析进度。例如：

User Control of Task Execution Status Messages

You can control the verbosity of DMSA task execution status messages. You can set the multi_scenario_message_verbosity_level variable to one of two values, default and low. When you set to the default, all task execution status messages are displayed. For example:

您可以控制 DMSA 任务执行状态消息的详细程度。您可以将 multi_scenario_message_verbosity_level 变量设置为以下两个值之一：default 和 low。设置为默认值时，将显示所有任务的执行状态消息。例如

When you set the variable to low, only error, fatal, and failure messages are displayed. You might find this useful for Tcl scripts where you need more control over the output. If this variable is changed by a Tcl script, it is desirable to change the variable back to its original value after completing the script or procedure to avoid confusion.

将变量设置为低时，仅显示错误、致命和失败消息。您可能会发现这对于需要对输出进行更多控制的 Tcl 脚本很有用。如果此变量由 Tcl 脚本更改，则希望在完成脚本或过程后将变量更改回其原始值，以避免混淆。

Error Messages

When an error occurs on a worker for a given scenario, the error is reported in full at the master together with the name of that scenario. For example:

当给定scenario的工作机上发生错误时，该错误将与该scenario的名称一起完整地报告在主机上。例如：

Warning Messages

When a warning occurs on a worker for a given scenario, the warning is reported at the master only if it is the first time that this warning has occurred in that scenario. For example:

当给定scenario的工作机上发生警告时，仅当该警告首次在该scenario中发生时，才会在主机上报告该警告。例如：

Log Files

You can examine all information generated by the workers in the log, output log, command log, or merged error log file. The root working directory for all multi-scenario analysis data, including log files, is determined by the multi_scenario_working_directory variable. If you do not explicitly set this variable, it is set to the current directory from which the PrimeTime master was invoked. You must have write permission to the working directory, and the directory must be accessible by the master and to all workers.

你可以在日志、输出日志、命令日志或合并的错误日志文件中检查工作机生成的所有信息。所有多scenario分析的数据（包括日志文件）的根目录由 multi_scenario_working_directory 变量确定。如果你没有设置此变量，则会将其设置为调用PrimeTime主机的当前目录。你必须具有对工作目录的写入权限，并且该目录必须可供主机和所有工作机访问。

Output Log

Each scenario has its own output log file, which is located in the scenario working directory. For example, for a scenario named s1, the log is the following:

每个scenario都有自己的输出日志文件，该文件位于scenario的工作目录中。例如，对于名为 s1 的方案，日志如下

multi_scenario_working_directory/s1/out.log

You cannot set or change the name of the output log. The output log for a particular scenario contains all errors, warnings, and information messages, which is all of the information that you normally see in the terminal window of a conventional single analysis PrimeTime run.

你不能设置或更改输出日志的名称。特定scenario的输出日志包含所有错误、警告和信息消息，通常这是您在传统单次分析PrimeTime运行的终端窗口中看到的所有信息

Command Log

Each remote process has its own command log file that you can find in the command_log directory under the working directory. For example, for a process launched on a host named srv1 that is the sixth process to be launched, the command log would be in the following file:

每个远程进程都有自己的命令日志文件，您可以在工作目录下的 command_log 目录中找到该文件。例如，对于在名为 srv1 的主机上启动的进程（这是要启动的第六个进程），命令日志将位于以下文件中：

multi_scenario_working_directory/command_log/srv1_6_pt_shell_command.log

You cannot set or change the name of the command log of remote processes. The command log for a particular process contains all commands executed on that process. You can locate the masters command log in the following file:

你不能设置或更改远程进程的命令日志名称。特定进程的命令日志包含在该进程上执行的所有命令。您可以在以下文件中找到 masters 命令日志

$sh_launch_dir/pt_shell_command.log

The sh_source_logging variable, when set to true, causes individual commands from sourced scripts to be written to the command log file.

当 sh_source_logging 变量设置为 true 时，会导致源脚本中的单个命令写入命令日志文件

Merged Error Log

Large numbers of errors, warnings, and information messages can occur during a multi-scenario analysis. To help you debug these messages, you can set the merged error log variable at the master. For example, the following command creates a merged error file in multi_scenario_working_directory/error.log:

在多scenario分析期间，可能会出现大量错误、警告和信息消息。为了帮助您调试这些消息，您可以在主机上设置合并错误日志变量。例如，以下命令创建合并错误文件 multi_scenario_working_directory/error.log :

pt_shell> set_app_var multi_scenario_merged_error_log "error.log"

When this variable is set, all error messages from the start of a particular task to the end of the task are merged together. If the same error message occurs on a number of scenarios, the message is printed to the merged error file only one time, with a list of the scenarios in which the message occurred.

设置此变量后，从特定任务开始到任务结束的所有错误消息将合并在一起。如果在多个scenario中出现相同的错误消息，则该消息打印到合并错误文件中仅一次，并附有发生该消息的scenario列表

Note:You must set the multi_scenario_working_directory and multi_scenario_merged_error_log variables before issuing the start_hosts command.

注： 在发出 start_hosts 命令之前，必须设置 multi_scenario_working_directory 和 multi_scenario_merged_error_log 变量。

Command Output Redirection

Command output redirection is supported in multi-scenario analysis. Be sure to redirect output to different destination files for each process. Otherwise, an error occurs when two different processes attempt to control the same file at the same time.

命令输出重定向是支持多scenario分析的。请确保将每个进程的输出重定向到不同的目标文件。否则，当两个不同的进程尝试同时控制同一文件时，将发生错误

Note:When using output redirection, be sure use a relative path. Do not use an absolute path; if you do, all worker processes attempt to write to the same file, which could lead to read/write conflicts and cause the worker processes to fail.

注意：使用输出重定向时，请确保使用相对路径。不要使用绝对路径;如果这样做，所有工作进程都会尝试写入同一个文件，这可能会导致读/写冲突并导致工作进程失败。

As with the previous log file example, the value of the multi_scenario_working_directory variable is used along with the scenario name to determine the output destination file name. The following examples demonstrate the file naming conventions.

与前面的日志文件示例一样，multi_scenario_working_directory变量的值与scenario名称一起使用，以确定输出目标文件名。以下示例演示了文件命名约定。

Example 1: Interactive redirection

pt_shell> set x myfile

pt_shell> remote_execute {report_timing} > $x.out

The output of the remote_execute command is directed to a file named

remote_execute 命令的输出将定向到名为

myfile.out的文件

in the current working directory. The $x variable is evaluated only at the master process.

在当前工作目录中。$x变量仅在主机中有效。

Example 2: Script-based redirection

The multi_scenario_working_directory variable has been set to /mypath, and there are two scenarios in command focus, s3 and s4. The master issues the remote_execute {"source myscript.tcl"} command, which sources the myscript.tcl Tcl script in the scenarios in command focus. The myscript.tcl script contains the following line:

multi_scenario_working_directory变量已设置为 /mypath，command focus中有两种方案：s3 和 s4。主机发出 remote_execute {“source myscript.tcl”} 命令，该命令在command focus的scenario中获取 myscript.tcl Tcl 脚本。myscript.tcl 脚本包含以下行：

report_timing > rt.log

The output of the report_timing command goes into the following files:

/mypath/s3/rt.log

/mypath/s4/rt.log

DMSA Variables and Commands

For lists of commands and variables that you can use with DMSA, see

• DMSA Variables

• DMSA Commands

• Commands Not Allowed on Worker Processes

DMSA Variables

To customize multi-scenario reporting, set the following variables.

DMSA Commands

The following table lists the commands that you use throughout the DMSA flow.

Commands Not Allowed on Worker Processes

You cannot run the following commands on worker processes.

Limitations of DMSA

The DMSA feature has the following limitations:

• The maximum number of worker processes that the master process can control is 256 concurrent hosts.

• 主机可以控制的最大工作进程数为 256 个并发主机

• Usage of the GUI is not supported.

• 不支持使用 GUI

Reporting the cpu Time and Memory Usage

The amount of memory and CPU resources that PrimeTime uses to perform static timing analysis depends on several factors such as the size of your design, which analysis mode you are using, and your reporting requirements. PrimeTime provides performance and capacity information for distributed processes. Regardless of whether you use single-core analysis, multicore analysis, or distributed multi-scenario analysis, you can monitor memory and CPU usage in PrimeTime.

PrimeTime用于执行静态时序分析的内存和CPU资源量取决于几个因素，例如design的大小、使用的分析模式以及报告要求。PrimeTime为分布式进程提供性能和容量信息。无论您使用单核分析、多核分析还是分布式多scenario分析，您都可以在PrimeTime中监控内存和CPU使用率。

To report the overall processor time (in seconds) associated with the current pt_shell process, use the cputime command. To report the total memory (in KB) allocated by the current pt_shell process, use the mem command. When specifying the memory requirements for subsequent PrimeTime sessions, use this reported memory value with an additional 20 percent allowance for efficient operation of the operating system.

要报告与当前pt_shell进程关联的总处理器时间（以秒为单位），请使用 cputime 命令。要报告当前pt_shell进程分配的总内存（以 KB 为单位），请使用 mem 命令。在为后续PrimeTime session指定内存要求时，请使用此报告的内存值，并额外留出20%的余量，以实现操作系统的高效运行。

To report all the host options set in a distributed multi-scenario analysis (DMSA) flow, use the report_host_usage command. This command also reports peak memory, CPU usage,and elapsed time for the local process. In DMSA, it also reports peak memory, CPU usage, and elapsed time for all distributed processes. The report displays the host options specified, status of the distributed processes, number of CPU cores each process uses, and licenses used by the distributed hosts.

要报告 distributed multi-scenario analysis（DMSA） 流程中设置的所有主机选项，请使用 report_host_usage 命令。此命令还报告本地进程的峰值内存、CPU 使用率和运行时间。在 DMSA 中，它还报告所有分布式进程的峰值内存、CPU 使用率和运行时间。该报告显示指定的主机选项、分布式进程的状态、每个进程使用的 CPU 内核数以及分布式主机使用的许可证。

For processes that are configured to using multiple CPU cores on the same host machine, such as a single-core or threaded multicore analysis, the report_host_usage command provides the resource usage for the current PrimeTime session. Here is an example of the report output for a single-core or threaded multicore analysis flow.

对于配置为在同一主机上使用多个CPU内核的进程，例如单核或线程多核分析，report_host_usage命令提供当前PrimeTime session的资源使用情况。下面是单核或线程多核分析流程的报告输出示例。

In DMSA flows, resources can be spread over several hosts. Therefore, the resource usage data is provided for each distributed process. Here is an example of the report_host_usage output for a DMSA flow.

在 DMSA 流程中，资源可以分布在多个主机上。因此，将为每个分布式进程提供资源使用情况数据。下面是 DMSA 流的report_host_usage输出示例。

When you exit PrimeTime, the tool reports the peak memory, CPU usage, and the elapsed time for the session:

Maximum memory usage for this session: 31.08 MB

CPU usage for this session: 23 seconds

Elapsed time for this session: 211 seconds

When exiting a DMSA session, the tool reports information about the distributed processes:

Profiling the Performance of Tcl Scripts

To identify runtime and memory bottlenecks in your Tcl scripts, you can perform Tcl profiling during your timing runs. This capability can help you fix performance and capacity issues.

要识别 Tcl 脚本中的运行时长和内存瓶颈，可以在timing runs期间执行 Tcl 分析。此功能可帮助你解决性能和容量问题。

To perform Tcl profiling:

• Start collecting profiling data by running the start_profile command.
• 通过运行 start_profile 命令开始收集分析数据。
  By default, start_profile tracks commands that take more than 0.1 second to run or use more than 100 KB of memory. If you use the -verbose option, start_profile tracks all commands.
  默认情况下，start_profile跟踪运行时间超过 0.1 秒或使用超过 100 KB 内存的命令。如果使用 -verbose 选项，start_profile将跟踪所有命令
• Run the Tcl scripts that you want to analyze.
  2. 运行要分析的 Tcl 脚本。
• Stop collecting profiling data by using the stop_profile, exit, or quit command.
  3. 使用 stop_profile、exit 或 quit 命令停止收集分析数据。
• Evaluate the automatically generated Tcl profile and stopwatch reports. By default, the tool writes these files to the profile subdirectory of the current working directory.
  

4. 评估自动生成的 Tcl 配置文件和秒表报告。默认情况下，该工具将这些文件写入当前工作目录的配置文件子目录。

Here is an example of the Tcl script profile report summary. The get_timing_paths command was called one time from the gtp_only.tcl script and took 8 seconds to execute, which is shown in the Elapsed column.

下面是 Tcl 脚本配置文件报告摘要的示例。get_timing_paths 命令是从 gtp_only.tcl 脚本调用一次的，执行时间为 8 秒，显示在“Elapsed”列中。

The stopwatch report (tcl_stopwatch_*.txt), is an ASCII text file that shows the time, performance, and memory metrics of each command. Here is an example of a stopwatch report.

stopwatch报告 （tcl_stopwatch_*.txt） 是一个 ASCII 文本文件，显示每个命令的时间、性能和内存指标。下面是stopwatch报告的示例。

binnq

楼主辛苦