在排查 Cadence License Server 时，lmstat 可以查看服务器状态和 feature 的使用情况，但它本身不会以当前用户身份实际检出一个许可。

如果希望确认某台客户端上的用户能否从 License Server 检出指定 feature，可以使用 Cadence 提供的 ckout_test。该工具不需要启动 Genus、Innovus 或 Xcelium 等产品，也不需要准备 design 数据。

本文环境示例：

项目 示例值
License Server eda-lic.lab.icinfra.ltd
lmgrd 端口 5280
License Server 地址 5280@eda-lic.lab.icinfra.ltd
测试 feature Xcelium_Single_Core
请求的许可版本 21.100

上述 feature 和版本取自 Cadence 的示例。实际测试时，应替换为目标产品实际请求的 feature 名称和许可版本；软件发行版本、License 文件中的版本和程序实际请求的版本不能简单视为相同。

一、查找 ckout_test 命令

根据 Cadence 官方说明，ckout_test 随 Cadence License Server 软件提供，通常位于：

1

<INSTALL_DIR>/tools/bin/ckout_test

其中 <INSTALL_DIR> 是安装根目录。具体目录随安装位置和版本不同而变化。

如果已知 Cadence 安装路径，可以通过 find 查找：

1

find /tools/Cadence -type f -name ckout_test -print 2>/dev/null

如果可执行文件是符号链接，也可以一并查找：

1

find /tools/Cadence \( -type f -o -type l \) -name ckout_test -print 2>/dev/null

请根据实际情况替换 /tools/Cadence。如果命令已经加入 PATH，也可以执行：

1

command -v ckout_test

找到程序后，先查看本机版本的帮助：

1

/path/to/ckout_test -h

后文中的 /path/to/ckout_test 需要替换为实际路径。

二、准备测试环境

建议在实际运行 EDA 的客户端上，使用需要验证的普通用户执行。这样可以同时覆盖客户端网络、用户身份及相关 License 访问策略。

先查看现有环境变量：

1
2

printf 'CDS_LIC_FILE=%s\n' "${CDS_LIC_FILE-<未设置>}"
printf 'LM_LICENSE_FILE=%s\n' "${LM_LICENSE_FILE-<未设置>}"

如果希望单独测试一台服务器，可以在子 Shell 内临时指定：

1
2
3
4
5
6
7
8

(
    export CDS_LIC_FILE='5280@eda-lic.lab.icinfra.ltd'
    unset LM_LICENSE_FILE

    /path/to/ckout_test \
        -f Xcelium_Single_Core \
        -v 21.100
)

子 Shell 退出后，不会更改当前 Shell 的这两个变量。

上述命令用于单独指定测试地址，但现场仍可能存在产品或站点级 License 配置。若输出显示请求了其他服务器，应检查实际生效的配置和诊断日志。测试三服务器冗余 License 时，应使用环境中已配置的正确冗余服务器格式，不要直接将其简化为单台地址。

三、使用 ckout_test 检出 feature

1. 基本命令格式

1
2
3

/path/to/ckout_test \
    -f <feature名称> \
    -v <请求的许可版本>
参数 说明
-f 指定要请求的 License feature 名称。
-v 指定请求的许可版本。
-h 查看当前安装版本的帮助信息。

<feature名称> 和 <请求的许可版本> 是占位符，执行时不要保留尖括号。

2. 测试 Xcelium feature

Cadence 官方文章提供了 Xcelium_Single_Core 和 21.100 这一示例。可以按以下方式测试单个 feature：

1
2
3

/path/to/ckout_test \
    -f Xcelium_Single_Core \
    -v 21.100

程序是交互式的。执行后观察终端输出，确认是 checkout 成功还是失败，并根据程序提示操作。

成功的判定应以程序实际报告的检出结果为准。仅看到程序启动、打印服务器信息，或者 feature 存在，并不能单独证明 checkout 成功。

3. 测试其他产品的 feature

例如，目标应用的日志确认请求了 Genus_Synthesis，即可将 -f 换成该名称，-v 填写实际请求版本：

1
2
3

/path/to/ckout_test \
    -f Genus_Synthesis \
    -v <实际请求的许可版本>

应从目标应用的 License 日志、对应版本的产品文档或 Cadence 支持资料确认 feature 和请求版本。不要直接把安装目录名、产品名或软件版本号当作 feature 和许可版本。

Cadence 的文章也展示了重复使用 -f 和 -v 的方式。初次排查建议一次测试一个 feature，避免结果难以区分；多个 feature、数量及其他参数请以本机 ckout_test -h 为准。

四、使用 lmstat 查看 License 占用

ckout_test 实际检出的是服务器上的许可。测试时，可以在另一个终端使用 lmstat 观察对应 feature 的使用情况。

1. 查找 lmutil

1

command -v lmutil

如果没有加入 PATH，可在 License Server 或 Cadence 软件安装目录下查找：

1

find /tools/Cadence \( -type f -o -type l \) -name lmutil -print 2>/dev/null

下面假设 lmutil 已加入 PATH；如果没有，请使用它的完整路径。

2. 查询单个 feature

保持 ckout_test 进程运行，并在它持有许可期间执行：

1
2
3

lmutil lmstat \
    -c 5280@eda-lic.lab.icinfra.ltd \
    -f Xcelium_Single_Core

如果测试的是 Genus，则替换 feature 名称：

1
2
3

lmutil lmstat \
    -c 5280@eda-lic.lab.icinfra.ltd \
    -f Genus_Synthesis

输出格式随 FlexNet 版本、服务端配置及权限而异。通常可关注：

  • feature 名称；
  • License 总数及已使用数量；
  • 用户名、客户端主机等 checkout 明细；
  • 测试前后是否出现与本次测试相符的占用记录。

有些服务器会限制明细输出；这时查询结果未显示明细，不能单凭这一点判定 ckout_test 没有检出。可结合客户端输出和服务端日志确认。

3. 查看 License Server 整体状态

1

lmutil lmstat -a -c 5280@eda-lic.lab.icinfra.ltd

-a 会查询较多信息；在 feature 多、用户多的环境中，优先使用 -f 查询目标 feature，避免不必要的服务器负载。

lmstat 是状态查询工具。即使它能查询到 feature，也不代表当前用户一定能检出；实际 checkout 结果仍以 ckout_test 的输出和服务端记录为准。

五、退出测试并确认许可归还

测试完成后，按照 ckout_test 当前版本的交互提示正常退出。随后再次运行：

1
2
3

lmutil lmstat \
    -c 5280@eda-lic.lab.icinfra.ltd \
    -f Xcelium_Single_Core

结合测试用户、客户端和时间，确认本次记录已消失或占用数量已恢复。共享 License Server 上其他用户可能同时 checkout 或归还许可，因此仅比较总数不一定能准确判断。

如果 ckout_test 退出很快，或者 feature 的记录变化过快，可能来不及通过 lmstat 捕捉。此时可请 License 管理员查看 cdslmd debug log 中与测试用户、客户端、feature 和时间相符的 checkout/checkin 记录。

测试会实际占用许可。在生产环境中，建议一次只测试必要的 feature，完成后及时退出；不要为了测试而长期持有稀缺许可。

六、常见问题

1. 能查到 feature，为什么 checkout 失败？

可依次检查：

  1. feature 名称和大小写是否与实际请求一致；
  2. -v 请求的许可版本是否与目标应用的请求一致，并受现有许可支持；
  3. 当前是否有可用数量；
  4. License 是否过期，或是否存在用户、主机、组等访问限制；
  5. 客户端到 lmgrd 和 vendor daemon 的网络通信是否正常；
  6. 实际连接的是否是预期的 License Server；
  7. 客户端报错和服务器日志中具体的 FlexNet 错误信息。

具体原因应根据实际错误码和日志判断，不建议仅凭某一条现象下结论。

2. ckout_test 成功，是否代表真实产品一定可以正常运行？

不能完全代表。ckout_test 验证的是指定 feature、指定请求版本在当前测试条件下能否检出。真实产品还可能：

  • 请求不同的许可版本或使用不同的 feature；
  • 按一定顺序尝试其他许可；
  • 在启用某个功能时动态申请附加许可或 token；
  • 同时依赖其他 License Server、运行环境或产品组件。

因此，如需确认完整产品流程，仍应进一步执行对应产品的实际启动或功能测试。

3. 不知道应该测试哪个 feature 和版本怎么办？

优先查看目标应用的启动日志、License 错误日志及产品文档，确认应用实际请求的 feature 和版本。lmstat 可辅助了解服务器上提供的 feature 和当前占用，但不应仅凭服务器列表推断产品的实际请求版本。

参考资料