FPGA开发有一个很少被写进教程的烦恼仿真文件太散了。跑完一轮ModelSimtranscript.log躺在仿真目录里波形文件.wlf在另一个运行目录覆盖率数据.ucdb又在第三处。如果用了 QuestaSim 的-work参数指定库目录文件分布就更没有规律。同一套工程跑多个 testbench 时同名文件交替覆盖等你想回头整理归因时已经晚了。这个痛点我在实际项目中碰过不止一次。后来我用 Tcl/Tk 写了一个交互界面对应的就是标题里这句“基于Tcl/Tk的FPGA仿真文件获取交互界面”。它要解决的问题很具体在一个图形界面上选择工程目录、填好仿真参数、一键启动仿真等后台工具跑完后自动把需要的仿真文件按时间戳归档到指定目录避免手动翻目录、漏文件、被覆盖。这个界面不是大而全的验证管理平台而是一个贴着FPGA仿真日常走的“小工具”。这篇文章我会把那个界面的设计思路、核心代码、以及实测中踩过的坑完整记录下来。开发环境是 Tcl/Tk 8.6适用于 ModelSim、QuestaSim、Vivado XSim 这几种常见仿真工具链适合正在做 FPGA 验证、对脚本自动化感兴趣的工程师参考。1. 仿真文件管理在FPGA开发流程中的真实痛点1.1 一次仿真的产物到底散落在哪里FPGA仿真跑完绝不只产生一个文件。以 ModelSim/QuestaSim 为例一次典型的行为级仿真会生成波形文件比如.wlfModelSim Native Format如果你在 do 文件里配置了vcd2wlf或log -r /*文件可能很大且默认存放在当前工作目录仿真日志比如你自己log -l指定的.log文件带上-l选项后路径由你定但如果你图省事不指定它就写到当前目录的transcript里覆盖率数据QuestaSim 默认输出.ucdbXSim 则是.crr这些数据文件经常被工程顶层目录统一定位还有各种中间文件像宏定义文件、内存初始化文件、以及仿真器生成的临时缓存。更乱的是很多团队的工程目录结构是“代码目录 仿真目录”双层的RTL 在rtl/testbench 在tb/仿真输出却在sim/run_xxx/下面。你在sim/run_1/、sim/run_2/、sim/run_3/三个目录里分别跑过同一个用例最后想对比三版波形就得把三个目录翻个遍。就算文件都找到了复制到一个汇总目录时如果同名还会互相覆盖。文件类型常见扩展名生成工具典型用途波形文件.wlf.vcd.fsdbModelSim / QuestaSim / XSim / Verilator查看信号时序、定位bug仿真日志.logtranscript各类仿真器记录告警、错误、断言结果覆盖率文件.ucdb.crr.infoQuestaSim / XSim收集行覆盖率、分支覆盖率、功能覆盖率时序/资源报告.timing.utilVivado后端实现阶段的时序与资源统计内存/初始化文件.mem.coe.hex仿真器、IP核加载到存储模型中的数据这张表里后两类文件往往由综合实现阶段生成和前几类仿真产物不在同一时刻出现。所以“获取仿真文件”这个动作本质上是一次跨目录、跨时间点的文件收集任务。1.2 为什么是Tcl/Tk而不是Python或C#程序在FPGA行业谈脚本自动化必须先提一个事实Vivado、Quartus、ModelSim、QuestaSim 这些主流工具都原生内置了Tcl解释器。你做工程构建、仿真汇编、IP 配置、时序约束全都可以用 Tcl 脚本驱动。也就是说Tcl 是 FPGA 工具链的“通用语言”而不是我硬选的技术栈。Tk 是 Tcl 自带的图形库不需要额外安装第三方运行时。在公司的编译服务器或者多台工程师机器上往往没有预装 Python GUI 依赖PyQt/PySide 要装一堆东西但 Tcl/Tk 基本是“躺”在 EDA 工具安装目录里的。这就让基于 Tcl/Tk 写的界面有了一个突出优势几乎零依赖部署直接把.tcl脚本拷过去在 Vivado 的 Tcl Console 里 source或者用系统 tclsh 运行就能出界面。有人会说 Python 写 GUI 更现代、更好看。这话没错但注意场景FPGA 工程师的日常需求是“能快速用、能随手改、不折腾环境”。我用 Tcl/Tk 写完这个工具在公司的 Windows 和 Linux 两台机器上都没装任何额外东西直接就跑了。这种便携带来的效率对一个辅助工具来说比界面颜值重要得多。1.3 这个界面解决的三个具体问题第一是“找文件”。我不用再凭记忆在各种 run 目录里翻箱倒柜界面上点一下“收集”匹配规则就把仿真文件全部列出来。第二是“防覆盖”。每次归档都生成带时间戳的新目录上一轮的结果不会因为新一轮同名文件被抹掉。第三是“统一入口”。把启动仿真和文件收集合到一个按钮里不用先开命令行、敲 vsim、再跑另一个脚本去拷贝。界面交互流程并不复杂但它把最容易浪费时间的重复劳动拆掉了。后面我会详细展开设计细节。2. 界面设计思路从“缺什么”到“怎么摆”2.1 用户操作路径的取舍在设计界面布局之前我先想清楚了一个问题用户来这个界面上到底打算做几步操作。最自然的使用路径是这样的打开工具 → 选择工程目录 → 填写仿真顶层模块和仿真时间 → 选择要用的仿真工具 → 点“开始仿真并获取文件” → 看日志输出 → 等仿真结束 → 查看归档结果。这个流程里真正需要用户每次手动敲的只有三项目录、top 模块、仿真时间。其他都可以做成下拉框或按钮。所以界面上不需要堆太多东西保持一条主线就好。坦白说刚开始我把界面设计得比较复杂想着把所有参数都放上去结果自己用起来都烦。后来简化成现在这个版本上半部分是参数区中间是日志显示区下半部分是文件列表和操作按钮。信息流是单向的从上往下符合阅读习惯。2.2 三段式布局的具体实现我用 Tk 的grid布局管理器来做三段式结构而不是pack。原因在于参数区的标签和输入框天然是表格状的两列结构用grid才能让每行左右对齐如果全部用pack就得靠嵌套 frame 拼来拼去代码会绕。顶部参数区用两个frame嵌套实现外层 frame 用grid摆放标签和输入框内层用grid的columnconfigure来分配宽度。工程目录选择框旁边放了一个“浏览”按钮调tk_chooseDirectory弹原生目录选择器。中间日志区我直接放一个只读的Text控件横向和纵向都带滚动条。日志区在交互中承担了“反馈”作用用户看到仿真器输出才能确认当前到底跑到了哪个阶段。第三部分则是文件列表Listbox和“收集文件”“打开归档目录”两个按钮。这样一个布局的优点是即使是不熟悉工具的正确性验证工程师看一遍界面就知道先填什么、点什么、结果在哪看。2.3 状态反馈让用户知道仿真真的在跑GUI 工具最忌讳的问题之一是点击按钮后界面毫无响应用户不知道程序卡住了还是在正常工作。Tcl/Tk 原生是单线程环境后面我会详细讲异步管道的坑这里先提界面层面的状态设计。我在界面上放了一个状态栏Label专门显示当前状态。流程中的状态切换如下点击按钮前显示“就绪”点击按钮后显示“正在启动仿真...”→ 按钮禁用防止重复点击仿真过程中把仿真器的输出实时追加到日志 Text 控件里状态栏显示“仿真运行中...已完成 xx 行输出”仿真结束状态栏显示“仿真已完成正在收集文件...”文件归档完成后显示“归档完成共 N 个文件”。这个状态反馈看似简单但能大幅改善工具使用体验。在实现上就是靠异步轮询进程管道后更新变量再配合update idletasks强制刷新界面。3. 代码实现文件识别、进程调用与自动归档3.1 目录扫描与仿真文件识别核心的文件收集动作可以用一个过程完成传入源目录和扩展名列表递归或非递归扫描返回所有匹配文件的绝对路径。proc collect_sim_files {srcDir extList} { set result [list] # 先做路径标准化避免后续因为相对路径/绝对路径问题匹配不到 set srcDir [file normalize $srcDir] if {![file isdirectory $srcDir]} { return $result } set entries [glob -nocomplain -directory $srcDir *] foreach entry $entries { if {[file isfile $entry]} { set ext [string tolower [file extension $entry]] if {$ext in $extList} { lappend result $entry } } } return $result }这里有两个容易忽视的细节。第一我用file normalize先把路径转成绝对路径。原因是 Tcl 脚本执行时的“当前目录”可能和你想象的不一样。特别是在 Vivado 的 Tcl Console 里当前目录跟着工程走在命令行 tclsh 里当前目录跟着启动位置走。如果不显式标准化后面往Listbox里填的路径可能是相对路径用户双击打开时会出错。第二我没有在glob里直接写*.wlf而是遍历所有条目再判断扩展名。这样做的目的是方便扩展到更多的文件类型。界面设计里会让用户勾选“波形文件”“日志文件”“覆盖率文件”背后其实展开成不同的扩展名列表一次性扫描比多次glob更高效也方便统一去重。3.2 时间戳归档目录生成归档目录的命名我用“前缀_年月日_时分秒”的格式。实际编码时注意clock format默认生成的时间戳是20250216_143522带两个数字的月日时分秒排序的时候时间顺序就是字符串字典序文件名本身就体现了先后顺序很方便。proc make_stamp_dir {baseDir {tag sim_result}} { set ts [clock format [clock seconds] -format %Y%m%d_%H%M%S] set stampDir [file join $baseDir ${tag}_${ts}] file mkdir $stampDir return $stampDir }我在实际工具里默认把归档目录放到“工程目录下的 result 文件夹”。如果不存在file mkdir会自动创建。这里不建议把归档目录和仿真运行目录混在一起因为仿真工具经常会在运行目录里删除或重建文件归档目录最好单独隔离。3.3 异步等待仿真进程结束界面不能卡死这是整篇里最关键的技术点。如果直接用 Tcl 的exec去调用仿真器界面会整个卡住。Tcl/Tk 是单线程事件循环exec是阻塞式的子进程不退出界面就不响应。用户看到的效果就是窗口白屏、鼠标转圈像死机了一样。正确做法是把外部命令放到管道里执行然后用after定时轮询管道输出。先看启动部分proc start_sim {cmd logFile} { global pipeState # 打开管道不加 -blocking让读取操作非阻塞 set pipe [open |$cmd 21 r] fconfigure $pipe -blocking 0 set pipeState(pipe) $pipe set pipeState(logFile) $logFile set pipeState(output) # 启动 100ms 一次的轮询 after 100 [list poll_sim] }这里open |$cmd 21的写法值得注意。管道符号在 Tcl 的open里表示“创建子进程并连接其标准输入输出”21是要把标准错误也合并到管道里不然仿真器的报错信息不会出现在日志里。然后看轮询过程proc poll_sim {} { global pipeState if {![info exists pipeState(pipe)]} { return } set pipe $pipeState(pipe) # 循环读取当前管道里已有的全部输出 while {[gets $pipe line] 0} { append pipeState(output) $line\n # 把输出追加到界面日志控件 log_text_insert $line\n update idletasks } if {[eof $pipe]} { set rc [catch {close $pipe} err] set pipeState(exitCode) $rc set pipeState(done) 1 after 200 [list archive_sim_files] } else { after 100 [list poll_sim] } }几个关键判断gets $pipe line返回 -1 时有两种情况一是管道里暂时没有新数据这时eof $pipe为 0继续after轮询二是子进程真的结束管道关闭这时eof $pipe为 1这时就可以安全地去收集文件了。中间那行update idletasks非常重要它强制 Tk 刷新界面否则日志内容要等程序完全阻塞退出后才能看到。这样设计之后仿真进程跑 5 分钟、10 分钟都不会卡界面用户还能实时看到仿真输出。我自己在实际使用时还会在这个基础上加一个“取消”按钮本质就是close $pipeState(pipe)杀掉子进程逻辑不复杂但很实用。3.4 串起整个“启动获取”流程当仿真进程结束后我应该自动触发文件收集还是让用户手动点按钮我选择的是自动触发但在自动归档前给 200ms 的延时。原因是实测发现仿真器进程已经退出了但操作系统层面的文件句柄可能还没完全释放立刻读文件偶尔会失败。加一个小延时能有效规避。仿真结束后的归档过程如下proc archive_sim_files {} { global cfg pipeState set stampDir [make_stamp_dir [file join $cfg(projectDir) result]] set extList [list .wlf .vcd .log .ucdb .fsdb .saif] set files [collect_sim_files $cfg(simDir) $extList] set copied [list] foreach f $files { # 用 file copy 保留原文件不移动 file copy -force $f [file join $stampDir [file tail $f]] lappend copied [file join $stampDir [file tail $f]] } # 把搜集结果填到 Listbox display_file_list $stampDir $copied status_bar_update 归档完成共 [llength $copied] 个文件 }如果只是重复拷贝当前目录下有同名文件就会直接覆盖。考虑到归档目录是“时间戳用例名”隔离的一般情况下不会冲突。但如果你在同一个秒级时间戳里跑两个相同 testbench还是可能覆盖。所以我在这个函数里额外加了一个处理如果 [file join $stampDir [file tail $f]] 已经存在就自动在文件名后追加_1、_2再复制。4. 实测中遇到的四个典型问题与修复方式4.1 exec阻塞导致界面“假死”这个坑我在开发第一版时就踩了。当时图省事按钮回调里直接写# 错误的示范 exec vsim -c -do run.tcl -l sim.log结果点击按钮后整个窗口拖不动、按钮点了没反应要等仿真跑完才能恢复。仿真用例简单还好复杂用例跑 5 分钟以上这界面就没法用了。根因就是 Tcl/Tk 的事件循环被exec阻塞。解决办法在第 3.3 节已经给出这里再补充一个细节启动按钮回调里要立刻禁用自身等轮询结束再恢复。如果不这样做用户可以在仿真运行期间再次点击按钮启动第二个仿真进程两个进程同时写同一个 log 文件大概率文件名冲突日志也会乱套。正确的回调应该长这样proc on_start_clicked {} { global cfg set btn .main.bottom.start $btn configure -state disabled upgrade_status 正在启动仿真... # 组装命令 set doFile [file join $cfg(projectDir) sim run_${cfg(topModule)}.do] if {![file exists $doFile]} { tk_messageBox -message do文件不存在: $doFile $btn configure -state normal return } set simCmd vsim -c -do $doFile -l $cfg(logFile) start_sim $simCmd $cfg(logFile) # 在 poll_sim 结束归档后恢复按钮 after 300 [list try_enable_start_btn] }after 300只是一个保险真实的恢复动作应该放在poll_sim检测到eof之后。如果只靠固定延时恢复仿真没跑完按钮就恢复了还是会出问题。所以我在poll_sim结尾调用了enable_start_btn过程。4.2 glob匹配不到文件的隐蔽原因第一次跑通基础功能后我在 Windows 上遇到一个奇怪现象仿真日志明明就在目录里但collect_sim_files返回空列表。排查了好一阵发现问题出在路径写法上。我当时用glob -nocomplain -directory $srcDir *.log在 Linux 上没问题但在 Windows 上如果$srcDir本身包含空格比如D:\My Project\sim\glob的解析会被空格截断匹配模式变成D:\My导致什么都匹配不到。修复方法有两个。一是在glob之前用file normalize转路径二是所有传给glob的模式必须用列表包裹而不是字符串。最终我在collect_sim_files里不直接写*.log这种模式而是先file normalize再用glob遍历目录条目再按扩展名过滤。这样即使路径有空格、有特殊字符也不会匹配错误。另一个隐蔽原因是大小写。Windows 的文件系统不区分大小写.wlf和.WLF都能被 glob 匹配到但 Linux 上.WLF文件和*.wlf模式不匹配。为了跨平台一致我在扩展名比对时统一转小写保证string tolower后比较。代码里已经写了这行。4.3 Windows下文件被占用与归档失败在做连续回归测试时我遇到过归档失败的情况file copy报错“permission denied”原因是仿真进程虽然退出了但 Windows 下某些仿真器的子进程比如vsimk.exe的后台编译进程还没完全结束波形文件句柄被占住。解决办法分三层。第一层是仿真进程结束后的延时after 200就能解决大部分问题。第二层是检查进程状态——在 Windows 下可以用tasklist过滤仿真器进程名。第三层是归档失败时不要静默吞掉错误用catch捕获并弹窗提示哪些文件复制失败。proc archive_sim_files {} { ... foreach f $files { set dest [file join $stampDir [file tail $f]] if {[catch {file copy -force $f $dest} err]} { lappend failedList $f } } if {[llength $failedList] 0} { tk_messageBox -icon warning -message 以下文件复制失败:\n[join $failedList \n] } }注意catch是 Tcl 处理异常的核心语法和 Python 的try...except类似。GUI 工具最常见的错误就是外部命令执行失败、文件操作被占用如果你不在关键位置加catch脚本会直接弹出一个晦涩的 Tcl 错误对话框用户根本不知道怎么处理。4.4 字体与中文路径跨平台的隐性坑Tk 自带的默认字体在 Windows 上显示中文经常是“方块”。我在 Linux 上开发时没注意部署到 Windows 后发现整个界面按钮文字全是乱码。解决方法是全局指定字体if {$tcl_platform(platform) eq windows} { option add *font {Microsoft YaHei 10} } else { option add *font {DejaVu Sans 10} }另一个问题是中文路径。如果工程目录或 testbench 名包含中文open |$cmd传命令字符串给 cmd.exe 时可能编码出错。我的解决办法是在工具内部不强制限制中文路径但在生成目录名、文件名时统一用英文和数字。也就是说用户选的工程目录可以是中文但我生成的归档子目录名一定用sim_result_20250216_143522这种格式避免中文出现在文件名里带来编码兼容问题。关于脚本文件本身的编码建议所有.tcl文件保存为 UTF-8。Tcl 8.6 默认按 UTF-8 解析源文件老机器上如果还是 8.5需要encoding system utf-8显式设置。我在脚本开头会写一行if {$tcl_version 8.6} { encoding system utf-8 }这样在旧版 Tcl 上也能正确显示中文注释和提示。5. 只花小代价就能提升体验的扩展功能5.1 记住最近使用的配置工具用顺手之后你会发现每次重新打开都要重新选目录、填 top 模块虽然不算累但次数一多还是想省掉。我在工具里加了一个简单的配置记忆功能把上次使用的工程目录、top 模块、仿真时间存在用户主目录下的一个配置文件里。proc save_config {} { global cfg set fpath [file join $env(HOME) .fpga_sim_gui.conf] set fh [open $fpath w] puts $fh projectDir$cfg(projectDir) puts $fh topModule$cfg(topModule) puts $fh simTime$cfg(simTime) close $fh } proc load_config {} { global cfg set fpath [file join $env(HOME) .fpga_sim_gui.conf] if {![file exists $fpath]} { return } set fh [open $fpath r] while {[gets $fh line] 0} { set kv [split $line ] if {[llength $kv] 2} { set key [string trim [lindex $kv 0]] set val [string trim [lindex $kv 1]] set cfg($key) $val } } close $fh }这个做法成本很低但使用体验提升非常明显。界面初始化时调用load_config把上次的值填到输入框里用户不用每次都重新填所有字段。退出时在关闭窗口回调里调用save_config下次打开就是上次的状态。5.2 日志关键词高亮与摘要仿真日志动辄几千行手翻找 Error 和 Warning 很累。我在日志 Text 控件里做了关键词高亮用 Tk 的tag机制就可以实现proc highlight_keywords {} { set text .main.log.text # 清空旧的高亮 tag $text tag remove error_style 1.0 end $text tag remove warn_style 1.0 end # 扫描全文匹配关键词并打 tag set start 1.0 while {true} { set pos [$text search -nocase -regexp {\b(Error|Fatal)\b} $start end] if {$pos eq } break $text tag add error_style $pos $pos 5c set start $pos 1c } while {true} { set pos [$text search -nocase -regexp {\b(Warning)\b} $start end] if {$pos eq } break $text tag add warn_style $pos $pos 7c set start $pos 1c } }再配 two 个 tag 样式定义$text tag configure error_style -foreground red -font {TkDefaultFont 10 bold} $text tag configure warn_style -foreground orange -font {TkDefaultFont 10 bold}每次日志追加后调用一次highlight_keywords扫描全文会有轻微性能开销但对几千行的日志来说完全可接受。这个功能在找 bug 时真的有用尤其是回归测试跑出几百条告警的时候红色错误一眼就能扫到。如果想让摘要更进一步我还会在状态栏显示“Error: 3Warning: 5”在log_text_insert里用regexp -all计数即可。5.3 一键打开波形文件归档完成后用户最常见的下一个动作是用波形查看器打开波形文件。界面上的“打开波形”按钮只需要调用系统默认程序打开文件即可。跨平台处理如下proc open_file_external {filePath} { if {![file exists $filePath]} { tk_messageBox -message 文件不存在: $filePath return } switch -exact -- $tcl_platform(platform) { windows { exec {*}[auto_execok cmd] /c start [file nativename $filePath] } unix { exec xdg-open $filePath } default { tk_messageBox -message 当前平台不支持自动打开 } } }注意 Windows 下cmd /c start后面的空引号不能省否则start会把第一个引号内的内容当成窗口标题。这个细节是实际使用中踩出来的不加空引号时文件路径如果有空格就会被解析成标题和参数根本打不开文件。5.4 两轮日志对比同一个 testbench 跑两遍想确认两轮之间的 warning 差异时一个简单的 diff 功能就很省事。我在底部加了一个“对比日志”按钮选择两条日志文件调用外部 diff 工具或者用 Tcl 自带的方式逐行比对。对于精简单实现我会用 Tcl 本身读入两个文件逐行比较并统计差异行数输出到日志区域。如果系统装了 KDiff3、Beyond Compare 这类工具也可以调exec拉起来。这里的关键是不要把 diff 的核心逻辑做成全量文本对比否则在跨平台时文本行尾符差异Windows\r\n和 Linux\n会导致大量无关差异。简单做法是读入时统一string trim掉行尾符再比。6. 工具边界这套方案的适用场景和局限6.1 典型使用场景还原我用一个具体场景来还原这套工具的日常价值做一个小型 SOC 验证工程里 5 个 testbench。以前跑一轮回归需要手动进入每个 run 目录启动仿真等它结束再手动把.wlf、.log、.ucdb拷到指定的报告目录。有了这个界面流程变成打开工具 → 选择工程目录 → 填写 top 模块和仿真时间 → 点“开始仿真并获取文件”。每个用例跑完归档目录自动多出一个用例名_时间戳文件夹里面基础文件全部齐了。跑 5 个用例重复 5 次即可。整个过程不需要敲一行命令行不需要在多个终端窗口之间来回切。实际使用中我发现这个工具的价值不止于“省时间”更重要的是它的操作路径是可视化的。新来的实习生看一眼界面就知道怎么用不用先学一套复杂的 do 文件传参语法。6.2 工具链兼容范围我测试过的组合包括ModelSim SE-64 10.7Windows 10QuestaSim 2020.4Linux CentOS 7Vivado XSim通过xvlog、xelab、xsim三件套Windows 11。这三类场景都能正常跑通“启动收集”流程。对于 Verilator 这类开源仿真工具理论上也能用因为 Verilator 最终生成的是可执行文件你的 Tcl 脚本可以把它当作普通外部程序来调用只要命令路径配好就行。如果你用的是其他仿真器只需要改start_sim里那一条命令字符串的组装逻辑文件收集部分与仿真器无关完全通用。6.3 什么时候不建议用Tcl/Tk做这个事再往后我会补充一些我自己对这套工具适用范围的理解。首先是多人协作的大团队。如果你的团队有专门的验证平台使用持久化数据库管理测试结果、自动生成 HTML 报告、有集中的任务分发系统那这个独立的小工具确实显得鸡肋你需要的是一套完整回归管理系统而不是一个单机 GUI。其次是当你想频繁操作模型、需要复杂图表交互时Tk 的原生控件确实不够现代。比如要做功能覆盖率数据的趋势折线图、要做多轮的对比曲线Tk Canvas 能画但代码量和维护成本都比 Python 生态高很多。最后是如果整个团队已经统一使用 Python 且依赖管理良好那用 PyQt 做同功能的界面会更顺手。技术选型永远要看约束条件Tcl/Tk 的优势在于工具链内置、零外部依赖、单文件便携这些特点在 FPGA 的现场调试和跨机器快速部署场景下非常吃香但在需要现代 UI、大规模数据可视化和复杂交互时它有明显边界。我做这个工具的过程中最大的体会是GUI 辅助工具的核心价值不是界面好看而是把重复劳动集中到一个入口上。Tcl/Tk 虽然老但在 FPGA 工具链里属于“原生语”环境学一天就能上手。用好了它能帮你省掉大量整理文件的时间让你把精力花在真正的验证逻辑上。后面如果还想扩展可以继续做仿真回归的批量排队、邮件通知、覆盖率合并提醒这些功能方向上都是可叠加的。