3、日志的艺术（下）：条件编译与日志开关，日志文件轮转与归档策略，我在项目中遇到的日志风暴问题。
好，咱们接着聊日志。上一节我们把日志的格式和分级聊透了。这一节，咱们来点更实战的——怎么管住日志，怎么让日志不把硬盘撑爆，以及我当年被日志“教做人”的一次惨痛经历。
3.1 条件编译与日志开关：别让代码里全是print
你想想看，一个大型验证环境，动辄几十万行代码。如果每个模块都无脑地往终端里打信息，那仿真跑起来，终端刷屏的速度比看弹幕还快。根本找不到有用的信息。
我个人习惯，从来不在代码里直接写 `$display` 或 `$fwrite`。为什么？因为后期想关掉某个模块的日志，你得满世界去找。太累了。
正确的做法，是用条件编译或者宏定义来控制。
核心思想： 日志输出必须是一个可配置的行为，而不是硬编码的语句。
方法一：`ifdef` 条件编译
这是最传统的方法。在编译阶段就决定要不要这段日志代码。
`ifdef DEBUG_UVM_DRIVER
`uvm_info("DRV", $sformatf("发送数据包: %0h", pkt.data), UVM_HIGH)
`endif
我在项目中遇到过，有人把整个环境的 `ifdef` 开关写了几十个。最后编译脚本里，光定义这些宏就写了一长串。说实话，维护起来挺头疼的。
方法二：运行时日志开关（推荐）
我个人更倾向于用运行时开关。说白了，就是定义一个全局的“日志使能位”。仿真跑起来之后，通过命令行或者配置文件动态控制。
class log_switch;
static bit en_monitor = 1;
static bit en_driver = 1;
static bit en_scoreboard = 0;
endclass
// 使用
if (log_switch::en_monitor)
$display("[MON] 监测到信号变化 @ %0t", $time);
这样做的好处是，你不需要重新编译。跑回归的时候，发现某个模块日志太多，直接在命令行里 `+define+LOG_OFF_MONITOR` 就能关掉。嗯，这里要注意，全局变量一定要用 `static`，不然每个实例一份，你关了这个，那个还开着。
小技巧： 我习惯把日志开关和 UVM 的 verbosity 设置结合起来。比如 `+UVM_VERBOSITY=UVM_MEDIUM` 时，只打印关键信息；调到 `UVM_DEBUG` 时，才打开那些细粒度的内部调试日志。这样既灵活又统一。
3.2 日志文件轮转与归档策略：别让一个文件撑爆硬盘
仿真跑个几天几夜，日志文件能有多大？我见过最大的，一个 `sim.log` 文件，50GB。你想用 `vim` 打开它？直接卡死。想用 `grep` 搜个关键词？等半小时。
所以，日志文件必须做轮转（Rotation）。
常见的轮转策略：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 基于大小轮转 | 单个日志文件达到 100MB 或 1GB 时，自动切分 | 长时间仿真、大型回归 |
| 基于时间轮转 | 每小时或每天生成一个新日志文件 | 持续集成（CI）环境 |
| 基于仿真阶段轮转 | 每个 testcase 或每个 phase 结束后切分 | 调试单个用例时 |
我个人习惯用“基于大小轮转 + 归档”。具体怎么做？
在仿真脚本里，我一般会这样写（以 Shell 为例）：
#!/bin/bash
# 日志轮转函数
rotate_log() {
local logfile=$1
local maxsize=$((100*1024*1024)) # 100MB
local size=$(stat -c%s "$logfile" 2>/dev/null || echo 0)
if [ $size -gt $maxsize ]; then
mv "$logfile" "${logfile}.$(date +%Y%m%d_%H%M%S)"
gzip "${logfile}.$(date +%Y%m%d_%H%M%S)" & # 后台压缩
touch "$logfile"
fi
}
# 仿真主循环
while true; do
# 运行仿真，输出到 sim.log
./simv +UVM_VERBOSITY=UVM_MEDIUM | tee sim.log
rotate_log sim.log
sleep 60 # 每分钟检查一次
done
你看，核心就是：切分 + 压缩 + 保留有限份数。我一般只保留最近 10 个压缩包，更早的自动删除。不然硬盘再大也不够用。
避坑指南： 我曾经犯过一个错——在仿真还没结束的时候，直接用 `mv` 命令去移动正在被写入的日志文件。结果日志写到一半丢了，后半段全没了。正确的做法是：要么用 `logrotate` 这类工具（它支持 `copytruncate` 模式），要么在仿真程序内部实现轮转逻辑，确保文件句柄正确切换。
3.3 我在项目中遇到的日志风暴问题
说到这，我必须跟你分享一个让我印象深刻的教训。
那是一个大型 SoC 项目，验证环境跑起来要三天。第三天早上，我兴冲冲地来看结果。结果发现仿真在第二天晚上就停了。不是报错，是硬盘满了。
我一看，`sim.log` 文件，200GB。什么概念？整个服务器硬盘才 500GB。
我赶紧去查。发现是某个接口的 monitor 里，有一个 `forever` 循环。循环里每拍都打印一句 `[MON] 检测到数据`。本来这也没什么，但那天 regression 跑了 200 个 testcase，每个 testcase 都调用了这个 monitor。200 个进程同时往一个文件里写，那速度，简直了。
更坑的是，这个 monitor 的日志开关是 `ifdef DEBUG` 控制的。而回归脚本里，为了调试某个 bug，临时把 `DEBUG` 宏打开了。跑完那个 bug 之后，忘了关。
结果就是：日志风暴。
从那以后，我给自己定了三条铁律：
- 所有日志输出必须有限速机制。 比如，同一个信息在 1 秒内最多打印一次。用 `$time` 做时间戳判断。
- 回归环境默认关闭所有调试日志。 只有明确指定 testcase 时，才打开对应模块的详细日志。
- 日志文件必须设置硬上限。 比如，单个日志文件超过 2GB 时，自动停止写入并报警。宁可丢日志，也不能让仿真崩。
总结一句话： 日志是帮你 debug 的，不是给你制造新 bug 的。管好日志，就是管好你的项目进度。
好了，这一节就聊到这。下一节，咱们聊聊怎么从海量日志里快速定位问题——说白了，就是 grep 的艺术。