Shell脚本在数字IC流程中的自动化实战：从入门到工程化-代码聚汇网

1. 数字IC工作流里，Shell脚本到底在解决什么问题

入行数字IC验证和设计这行，绝大多数时间不会花在写RTL上，而是在跟环境、工具、日志和回归结果较劲。跑仿真要敲命令，检查时序报告要翻日志，批量修改文件要写循环，十几个case跑挂了要看波形，全手点一遍会把人逼疯。Shell脚本在这个环节里的角色，就像是连接EDA工具链和人之间的胶水：EDA工具本身只认命令行调用，你只是把这一堆命令行敲击词汇变成可复用、可批量执行的逻辑。

实际项目里最常见的场景我列一下，你感受一下就知道这个技能值不值钱：

从RTL编译到仿真跑完，中间要经历vcs、verdi、vmanager等一堆工具的参数拼装，不同项目、不同分支下的参数还不一样，不用脚本会改到怀疑人生。
回归测试跑上千条用例，跑完要看哪些pass、哪些fail，fail了还要自动抓log里的关键词和波形路径，纯靠肉眼盯log，眼睛会瞎。
前后端交互、SDC约束、时序报告、面积报告，一堆文本文件要批量提取数据、打表、比对，手搓Excel都比写脚本慢。
服务器上多用户同时跑任务，环境变量、库路径、license配置只要错一次，后面全崩。

所以Shell脚本在数字IC工程师手里，本质上是一个“流程自动化工具”，不是编程学习任务。你要追求的不是写出多优雅的代码，而是能用最短的时间把一串串工具命令变成可复用的自动化流程。这篇文章里我把日常工作中真正高频的Shell命令挑出来讲透，每一条都对应一个具体场景。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 先过一遍：数字IC日常最常用的Shell基础命令清单

2.1 路径定位：你连自己在哪都不知道，后面全是白搭

很多刚入行的同学在服务器上跑命令，最常出现的问题就是“找不到文件”“命令不存在”“路径写错”，根源绝大多数在于对当前路径没有明确意识。在数字IC流程里，编译生成的中间文件、log文件、波形文件散落在各个目录，路径一错，后面整个流程都会引用到错误的文件，而且排查起来极其痛苦。

基础命令先过一遍：

bash复制pwd                       # 显示当前工作目录
ls -l                     # 列出当前目录下文件的详细属性
ls -lt                    # 按时间排序，找最近改过的文件特别好用
ls -lrt                   # 反时间序，写脚本遍历文件时我常用

有一个小细节很多人忽略：ls 在脚本里其实很少用于解析，因为它的输出格式受alias影响很大。比如你.bashrc里有人定义了 alias ls='ls --color=auto'，脚本里解析ls的输出就可能夹带颜色转义符，直接干扰结果。所以脚本里如果要列出文件做循环，更推荐用通配符或者 find，而不是解析 ls 的输出。

路径操作的进阶组合：

bash复制cd $(dirname "$0")       # 切换到脚本自身所在目录，这个是脚本里最常用的写法
cd "$(cd "$(dirname "$0")" && pwd)"   # 保险写法，先切换到脚本目录再取绝对路径

这里的 $0 代表脚本自身路径，dirname 取目录名，cd 进去之后再用 pwd 拿绝对路径。为什么要搞这么复杂？因为很多EDA工具要求你用绝对路径引用文件，如果你在某个子目录里执行脚本，用相对路径调用库文件，工具会因为它自己启动时的工作目录跟你不同而找不到文件。

2.2 文件操作：批量复制、改名、删除的标准姿势

前端综合、后端PR、验证编译，每一轮迭代都会产生大量中间文件。旧版本的log、网表、约束文件，要么归档要么清理。手动 rm 一个个删到天亮，这种事情我实习时候干过，后来学乖了。

文件删除的标准做法：

bash复制rm -rf ./run_*.log       # 删除所有run开头的log文件
find ./work -name "*.tmp" -delete    # 删除work目录下所有tmp文件
find ./logs -mtime +7 -name "*.log" -delete   # 删除7天前的log文件

find 加 -delete 是一个极其好用的组合，比 rm 更灵活，支持按时间、按大小筛选。但这里有个坑要提醒：find 默认不会跟随符号链接，如果你有链接指向其他目录，-delete 不会动链接本身，这其实是安全行为，别想着让它去穿透删除，容易出事故。

批量改名的需求更常见。版本号变更、文件后缀调整、case编号重排：

bash复制for f in test_case_*.log; do
    mv "$f" "${f%.log}_backup.log"
done

这一段做了三件事：用通配符 * 匹配所有 test_case_ 开头的log文件，然后在循环里把每个文件的 .log 后缀替换为 _backup.log。${f%.log} 是Shell的参数扩展，意思是去掉结尾的 .log，这种方法比 sed 处理文件名更安全，因为不会误修改文件名中间的内容。

批量复制和归档：

bash复制mkdir -p ./backup_$(date +%Y%m%d)
cp -r ./run_dir/*.log ./backup_$(date +%Y%m%d)/
tar czf regression_$(date +%Y%m%d).tar.gz ./backup_$(date +%Y%m%d)

date +%Y%m%d 是生成日期戳的标准写法，输出类似 20250520。拿日期做归档目录名，可以防止覆盖旧数据。如果你需要小时级粒度，用 date +%Y%m%d_%H%M%S，秒级归档都行。

2.3 环境变量与Source链：EDA工具跑不起来八成是环境问题

数字IC流程里的环境变量管理，比绝大多数软件开发场景更讲究。每个工艺库、每个PDK、每个工具版本都有自己的环境变量，加错了路径，轻则编译警告，重则仿真结果全是X态。EDA工具链的环境变量依赖关系，经常是一个source套一个source，最终形成一个长长的source链。

日常操作的常用命令：

bash复制export PATH=$PATH:/home/xxx/eda/synopsys/bin
export LD_LIBRARY_PATH=/home/xxx/eda/mentor/lib:$LD_LIBRARY_PATH
source /home/xxx/eda/synopsys/setup.sh

里面最坑的就是 LD_LIBRARY_PATH。大家习惯性地把新路径追加到前面，因为这样系统会优先加载你指定的库版本。但问题在于，某些EDA工具对库版本极敏感，你前面放一个旧版本库，可能就会导致工具启动时crash。我的经验是：能不动 LD_LIBRARY_PATH 就不动，实在要追加，先把原来的值存一份备份：

bash复制export LD_LIBRARY_PATH_SAVE=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=/your/new/path:$LD_LIBRARY_PATH
# 跑完工具之后，用完马上还原
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH_SAVE

另外，写进 .bashrc 的环境变量，不会对已经打开的终端生效，必须 source ~/.bashrc 或者重新登录。这个细节经常被忽略，很多人改完 .bashrc 后直接跑命令发现还是不生效，就一脸懵。记住：.bashrc 只在交互式shell启动时加载，.bash_profile 在登录shell时加载，有的服务器上你还要检查 /etc/profile.d/ 下面有没有全局配置干扰。

2.4 进程与后台任务：仿真跑到一半被中断是最大的浪费

仿真回归一次少则几十分钟，多则十几个小时。如果直接在终端前台跑，网络一抖、终端一关，任务就挂了。所以进程管理和后台运行是数字IC工程师的必备技能。

最基础的用法：

bash复制nohup vcs -full64 -f ./run.f > vcs.log 2>&1 &

这行的含义拆解一下：nohup 让进程忽略挂断信号，即使终端关闭也不会被杀掉；> vcs.log 把标准输出重定向到文件；2>&1 把标准错误也合并到同一文件里；最后的 & 让整个命令在后台运行。四个部分缺一不可。

查看任务状态：

bash复制ps -ef | grep vcs
ps -aux | grep simulation
kill -9 <pid>

ps -ef 输出所有进程的完整信息，grep 筛选出包含vcs的进程行。这里有个坑：grep 本身也是一个进程，会出现在结果里。如果不想看到它自己，用 grep -v grep 过滤，或者直接用 pgrep：

bash复制pgrep -f "vcs -full64"
pkill -9 -f "vcs -full64"

pgrep 比 grep + ps 干净得多，直接返回匹配进程的PID。pkill 按进程名批量杀任务，适合清理挂死的仿真进程。

更进阶的用法是用 wait 实现并行任务同步：

bash复制# 同时跑3个仿真任务
vcs -full64 -f test1.f > test1.log 2>&1 &
pid1=$!
vcs -full64 -f test2.f > test2.log 2>&1 &
pid2=$!
vcs -full64 -f test3.f > test3.log 2>&1 &
pid3=$!

# 等所有任务结束再继续
wait $pid1
wait $pid2
wait $pid3
echo "所有仿真任务已完成"

$! 是Shell内置变量，代表上一个后台进程的PID。把三个仿真任务同时丢到后台跑，再用 wait 分别等待它们结束，这个方法在跑多组不同参数的回归时极其高效。

3. 学完基础直接上手：数字IC流程里的高频Shell实战场景

3.1 批量日志巡检：从几百个log里快速抓出报错关键词

跑完回归之后，你面对的是几百个log文件。逐个打开用编辑器搜索？太慢了。用 grep 几个组合就能搞定：

bash复制grep -l "Error" ./logs/*.log
grep -n "Fatal" ./logs/test_case_*.log
grep -rn "UVM_ERROR" ./logs/ | wc -l

-l 只输出包含关键词的文件名，适合快速定位哪些case挂了。-n 显示行号，适合回溯具体出错位置。-r 递归搜索整个目录，wc -l 统计行数，适合快速评估错误规模。

但实际项目里，log里的关键词很杂。同样的UVM_ERROR，有的case报1条，有的报50条。如果你想找出所有报错case并统计每个case的错误数量，一行命令做成报告：

bash复制for f in ./logs/*.log; do
    count=$(grep -c "UVM_ERROR" "$f")
    if [ "$count" -gt 0 ]; then
        echo "$f: $count errors"
    fi
done

这里 grep -c 统计文件里匹配行的数量。循环里先统计错误数，再判断是否大于0，最后输出文件名和错误数。如果case太多，这个输出会非常长，可以直接重定向到文件：

bash复制for f in ./logs/*.log; do count=$(grep -c "UVM_ERROR" "$f"); if [ "$count" -gt 0 ]; then echo "$f: $count errors"; fi; done > error_summary.txt

3.2 时序报告自动提取：用awk和sed把关键数据打成表格

综合或者PR之后生成的时序报告，动辄几百行。你要从里面提取关键路径的slack、端点名称、延迟值。纯手工翻，一天就废了。awk 是最适合干这个的：

bash复制awk '/slack/{print $0}' timing.rpt

这行的意思是：顺序读取 timing.rpt 每一行，如果这一行包含 slack，就打印整行。$0 代表当前完整行。如果你只想要第一列和第二列数据：

bash复制awk '/slack/{print $1, $2}' timing.rpt

sed 的强项是文本替换和按行号操作。比如你想从时序报告里把路径延迟的单位从ns改成ps：

bash复制sed 's/ns/ps/g' timing.rpt > timing_ps.rpt

s/ns/ps/g 是sed的替换命令：把每行所有 ns 替换为 ps，最后的 g 代表全局替换。如果你想删除文件里的空行：

bash复制sed '/^$/d' timing.rpt

awk和sed的组合还能实现更复杂的逻辑。比如统计所有报出violation的路径，并按照slack值排序：

bash复制grep "slack" timing.rpt | awk '{print $NF, $0}' | sort -n | head -20

这里 $NF 表示当前行的最后一个字段，如果本来slack值就在末尾，那 $NF 就是slack值。排序后用 head -20 取出最差的20条。这种组合逻辑，解决的就是“从混乱文本里提取结构化数据”的问题。

3.3 批量文件内容替换：版本号更新和约束批量修改

一个项目从alpha到beta到release，版本号要改的地方可能散落在十几个文件里。手改不现实，用 sed -i 批量替换：

bash复制sed -i 's/version_alpha/version_beta/g' ./config/*.cfg
sed -i 's/DEFINE_VERSION 1/DEFINE_VERSION 2/g' ./rtl/*.v

-i 表示原地编辑，直接修改文件内容。但要注意，sed -i 在Linux和macOS上的语法有差异：macOS要求必须带后缀参数 sed -i '' 才行。如果你在公司服务器上操作，通常是Linux没问题；如果你在本地macOS上测试，记得加 ''：

bash复制sed -i '' 's/old/new/g' ./file.txt

还有一个更安全的方式是先生成新文件再替换：

bash复制sed 's/old/new/g' ./input.txt > ./output.txt
mv ./output.txt ./input.txt

这种方式保留了原始文件的一份副本，出错可以回滚。在生产环境操作批量修改时，我强烈建议用这种方式，或者至少在改动前先备份：

bash复制cp -r ./config ./config_backup_$(date +%Y%m%d)
sed -i 's/old/new/g' ./config/*.cfg

3.4 仿真回归状态判断：自动化判定pass还是fail

每个仿真case跑完，log末尾通常会打印 TEST PASSED 或 TEST FAILED。你要做的不是在终端里一条条看，而是写一个循环脚本，让它自己判断：

bash复制#!/bin/bash
for log in ./logs/*.log; do
    if grep -q "TEST PASSED" "$log"; then
        echo "PASS: $log"
    elif grep -q "TEST FAILED" "$log"; then
        echo "FAIL: $log"
    else
        echo "UNKNOWN: $log (log可能不完整)"
    fi
done

grep -q 是静默模式，不输出内容，只返回退出状态码。匹配到了返回0，没匹配到返回1，if 语句根据退出状态码来做分支。这个脚本跑完，你会得到三列清晰的状态汇总。

很多刚入门的朋友不理解“退出状态码”这个概念。简单说，Linux里每个命令执行完都会返回一个数字，0代表成功，非0代表失败。if 语句判断的就是这个数字。这也解释了为什么脚本里经常看到 if cmd; then 的写法，它不是判断命令输出内容，而是判断命令是否执行成功。

对于框架自带的UVM日志体系，通常 UVM_ERROR 的数量是判定标准：

bash复制#!/bin/bash
pass_count=0
fail_count=0
for log in ./logs/*.log; do
    error_count=$(grep -c "UVM_ERROR" "$log")
    if [ "$error_count" -eq 0 ]; then
        echo "PASS: $log"
        pass_count=$((pass_count + 1))
    else
        echo "FAIL: $log ($error_count errors)"
        fail_count=$((fail_count + 1))
    fi
done
echo "==== 汇总 ===="
echo "PASS: $pass_count"
echo "FAIL: $fail_count"

$((pass_count + 1)) 是Shell的算术运算语法，因为Shell变量默认是字符串，只有用这种写法才能做整数运算。这段脚本的滚雪球效应在于：今天你写一次，以后每次跑回归都可以复用，而且可以把结果通过邮件或者企业微信机器人发出去，真正实现全自动回归。

4. 让脚本更健壮：数字IC工程师的Shell进阶技巧

4.1 set -e你以为没用？关键时候能救命

很多同学写Shell脚本，写了一堆命令但从不关心每一条是否执行成功。这在数字IC流程里是大忌。比如你编译RTL，第一行编译失败，如果不做判断，脚本继续跑后面的仿真，最后拿到的结果完全是无效的，还浪费了n个小时的机器时间。

解决这个问题最粗暴有效的方式，是脚本开头加一行：

bash复制#!/bin/bash
set -e

set -e 的意思是：任何一个命令执行失败（退出状态码非0），整个脚本立即终止。这样一旦编译报错，脚本马上停下来，不会再跑后面的仿真，自然也就不会拿到无效结果。

但 set -e 也有“误伤”的时候。比如你想 grep 一个关键词，有的文件里匹配不到，grep 会返回1，如果脚本开了 set -e，整个脚本会直接退出。解决办法是用 || true 来“接住”这个非0状态：

bash复制grep -q "TEST PASSED" "$log" || echo "未找到PASS标记"

这样 grep 失败时，|| 后面的 echo 会执行，整条命令的退出状态码变为0，脚本得以继续。

更精细的控制是用条件判断结构。如果失败后的处理逻辑比较复杂，用 if 包裹：

bash复制if ! grep -q "TEST PASSED" "$log"; then
    echo "FAIL: $log"
    continue
fi

这里的 ! 对退出状态码取反，即 grep 失败时整个条件成立，会进入then分支。这比 set -e 更精密，适用于不同的业务分支。

4.2 变量和参数保护：不要裸奔着用变量

Shell脚本里最大的潜在问题之一，是变量没有引号包裹。这句话听起来很简单，但实际操作中踩坑的人特别多。

看一个经典 bug：

bash复制# 文件名里有空格就会出问题
for file in $(ls ./logs/); do
    echo $file
done

如果某个log文件名是 test case 01.log，那么 $(ls ./logs/) 输出时会被空格拆分成多个词，循环会变成三次迭代。解决办法是给变量加双引号：

bash复制for file in ./logs/*.log; do
    echo "$file"
done

用通配符展开替代 ls 命令，并且所有变量使用都用双引号包裹。这是一个良好的习惯，能避免80%以上的Shell脚本隐藏bug。

参数保护同理。脚本接受外部输入时，一定要校验参数数量和合法性：

bash复制#!/bin/bash
if [ $# -lt 2 ]; then
    echo "用法: $0 <compile.f> <output_dir>"
    exit 1
fi

compile_file=$1
output_dir=$2

if [ ! -f "$compile_file" ]; then
    echo "错误: 文件 $compile_file 不存在"
    exit 1
fi

mkdir -p "$output_dir"
echo "开始编译: $compile_file -> $output_dir"

$# 是参数个数，$1 $2 是位置参数。脚本开头判断参数数量，再做文件存在性检查，最后才执行实际逻辑。这样的脚本，别人拿到手也能放心用，不会因为输入错误而莫名其妙挂掉。

4.3 临时文件处理：用trap保证清理

仿真脚本经常要生成临时文件，比如文件列表、临时拼接的脚本等。这些文件如果不清理，日积月累会把工作目录弄得一团乱。更严重的是，如果脚本异常退出，临时文件残留，下次跑脚本时可能会读到上一次的残留数据，导致结果错误。

trap 命令可以帮你在脚本退出时自动清理：

bash复制#!/bin/bash
temp_file=$(mktemp)
trap "rm -f $temp_file" EXIT

# 正常业务逻辑
echo "hello" > "$temp_file"
cat "$temp_file"

mktemp 生成一个随机的临时文件名，避免多线程或多用户冲突。trap "rm -f $temp_file" EXIT 注册了一个退出时要执行的清理命令，无论脚本是正常结束还是异常退出，这条命令都会执行。

这个技巧在日常跑回归时特别有用。比如我习惯在脚本里生成一个当前回归的文件列表，跑完之后自动删除，保持工作目录干净。

4.4 超时保护与重试机制：仿真卡住时怎么办

仿真进程有时候会“假死”，既不报错也不退出，一直占着CPU跑。这时候如果没有超时保护，整个回归会被一个case卡住，后续所有case都等不到结果。

用Shell实现超时控制，可以借助 timeout 命令：

bash复制timeout 3600 vcs -full64 -f ./run.f > run.log 2>&1
if [ $? -eq 124 ]; then
    echo "ERROR: 仿真超时（超过1小时）"
fi

timeout 命令如果在指定时间内命令未完成，会发送TERM信号终止进程，并返回退出码124。脚本捕获这个状态码，就能识别出超时场景，进行针对性的处理。

另外一个我常用的实践是重试机制。比如多用户同时抢license，经常第一次启动工具失败，重试一次就成功了：

bash复制#!/bin/bash
max_retry=3
retry_count=0
while [ $retry_count -lt $max_retry ]; do
    vcs -full64 -f ./run.f > run.log 2>&1
    if [ $? -eq 0 ]; then
        echo "编译成功"
        break
    fi
    retry_count=$((retry_count + 1))
    echo "编译失败，第 $retry_count 次重试..."
    sleep 10
done
if [ $retry_count -eq $max_retry ]; then
    echo "ERROR: 编译失败，已重试 $max_retry 次"
    exit 1
fi

while 循环配合重试计数变量，最多尝试3次，每次失败后等待10秒再重试。这个模式在真实项目中极其常用，因为licence抖动、磁盘满、网络闪断都是偶发问题，简单重试往往就能解决。

5. 数字IC工程师最常见踩坑记录（每条都付过学费）

5.1 为什么我source了环境变量还是找不到命令

这个问题我见过无数人问过。现象很明确：执行 source /path/to/setup.sh 之后，紧接着运行 vcs 却提示 command not found。

排查思路按顺序来：

确认setup.sh里的 export PATH=... 是否真的包含了vcs所在目录。用 echo $PATH 查看当前PATH内容，which vcs 查看命令路径。
确认setup.sh里的export是写在if判断里面的，如果某个前置条件不满足，整个export可能不会执行。
有可能是setup.sh依赖了其他环境变量，比如 setup_common.sh，你得先source基础文件再source当前文件。
有的shell（比如csh）和bash语法不兼容，如果你的setup.sh是 setenv 开头，那它是写给csh用的，在bash里source会报错。这种情况通常需要先切换shell，或者在bash环境下用 sed 把 setenv 替换成 export。

5.2 脚本在命令行执行正常，放到cron里就不行

很多人写好自动回归脚本，在终端手动跑一切正常，但放进 crontab 定时执行就各种报错。最典型的原因有三个。

第一个是环境变量不一致。cron执行脚本时用的是非交互式shell，不会加载你的 .bashrc 和 .bash_profile，PATH大幅缩水，原来能用的命令全部找不到。解决办法是在脚本开头显式加载环境：

bash复制#!/bin/bash
source /home/xxx/.bashrc
source /home/xxx/eda/synopsys/setup.sh

第二个是相对路径问题。手动运行时你的 PWD 是某个目录，cron运行时的工作目录可能完全不同。解决办法仍然是脚本开头先 cd 到固定目录：

bash复制cd /home/xxx/project/regression

第三个是输出重定向问题。cron环境下，如果脚本里有交互式命令等待输入，它会一直卡住。解决办法是尽量使用非交互模式，或者把标准输入重定向为 /dev/null：

bash复制# 确保不需要交互输入
vcs -full64 -f ./run.f < /dev/null > run.log 2>&1

5.3 grep不到东西，但log里确实有

这个问题的坑在于：log文件是Windows格式的，每行结尾是 \r\n，Linux下显示时会多一个 ^M 字符。如果你grep的是纯关键字，比如 grep "ERROR" file.log，因为 ERROR 后面没有特殊字符，正常情况下应该能匹配到。但如果你grep的内容包含行首或行尾锚点，比如用正则的 $ 符号，就会匹配不上。

处理方式是用 dos2unix 命令转换格式：

bash复制dos2unix file.log
sed -i 's/\r$//' file.log

dos2unix 如果没装，可以用sed的替换命令去行尾的 \r。这个坑在数字IC行业特别常见，因为很多EDA工具跑在Windows上，生成的log拿到Linux服务器上处理，格式不兼容。

5.4 管道里用了set -e，脚本直接退出

set -e 配合管道符时有很隐蔽的行为。比如：

bash复制set -e
grep "ERROR" file.log | wc -l

如果 grep 没匹配到任何内容，grep 会返回1，但此时整个管道的退出状态码取决于最后一个命令 wc -l 的返回值，也就是0。所以 set -e 并不会触发退出。这其实是安全的，但严格来说这不是bug，只是行为和直觉不一致。

更隐蔽的问题出在使用 set -o pipefail 之后。pipefail 会让管道返回第一个非0命令的状态码，此时再配合 set -e，grep 没匹配到就会导致脚本退出。所以如果你开了 pipefail，要格外注意管道的第一个命令是否会因为“没有匹配结果”而返回非0：

bash复制#!/bin/bash
set -e
set -o pipefail

# 这个写法如果没匹配到就退出，会让脚本中断
grep "PASS" run.log | wc -l

# 安全写法
count=$(grep "PASS" run.log | wc -l || true)

|| true 的作用是把管道整体退出状态码强制变为0，从而避免 set -e 触发。或者把 grep 换成不会报错的替代命令：

bash复制count=$(grep "PASS" run.log 2>/dev/null | wc -l || true)

6. 脚本实战：一个可复用的数字IC回归自动执行框架

前面聊了那么多命令和技巧，最后用一套完整的示例脚本把它们串起来。这个脚本参考的是实际项目里验证工程师最常用的一套回归框架，我简化了业务细节，保留了核心骨架，你可以直接抄走改造。

6.1 脚本功能设计

这套脚本要完成的功能：

自动加载EDA工具环境
编译RTL和testbench
批量跑回归用例
实时输出每个case结果
汇总最终结果，生成统计报告
支持传入参数，指定跑的用例范围

6.2 完整代码

bash复制#!/bin/bash
# =============================================
# 数字IC回归测试自动执行脚本
# 用法: ./run_regression.sh [case列表文件]
# =============================================

set -e
set -o pipefail

# ---------- 环境加载 ----------
source /home/xxx/.bashrc
source /home/xxx/eda/synopsys/setup.sh   # VC静态验证工具
source /home/xxx/eda/synopsys/vcs_setup.sh  # VCS仿真工具
source /home/xxx/eda/mentor/questasim_setup.sh  # QuestaSim

# ---------- 路径定义 ----------
PROJ_ROOT="$(cd "$(dirname "$0")" && pwd)"
RTL_DIR="$PROJ_ROOT/rtl"
TB_DIR="$PROJ_ROOT/tb"
WORK_DIR="$PROJ_ROOT/work"
LOG_DIR="$PROJ_ROOT/logs"
RESULT_FILE="$PROJ_ROOT/result_summary.txt"

# ---------- 参数解析 ----------
CASE_FILE=""
if [ $# -ge 1 ]; then
    CASE_FILE="$1"
fi

# ---------- 初始化 ----------
mkdir -p "$WORK_DIR" "$LOG_DIR"
echo "==== 回归测试开始: $(date) ====" > "$RESULT_FILE"

echo "[INFO] 项目根目录: $PROJ_ROOT"
echo "[INFO] 工作目录: $WORK_DIR"
echo "[INFO] 日志目录: $LOG_DIR"

# ---------- 编译阶段 ----------
echo "[INFO] 开始编译RTL设计..."

cd "$WORK_DIR"

vcs -full64 \
    -sverilog \
    +v2k \
    -debug_access+all \
    -f "$PROJ_ROOT/rtl/filelist.f" \
    -f "$PROJ_ROOT/tb/filelist.f" \
    -o simv \
    -l "$LOG_DIR/compile.log" \
    > "$LOG_DIR/compile_stdout.log" 2>&1

if [ $? -ne 0 ]; then
    echo "[ERROR] 编译失败，请检查 compile.log"
    exit 1
fi

echo "[INFO] 编译成功"

# ---------- 回归测试阶段 ----------
pass_count=0
fail_count=0
total_count=0

if [ -z "$CASE_FILE" ]; then
    # 默认跑所有test目录下的用例
    TEST_CASES=$(ls "$TB_DIR"/test_*.sv)
else
    # 从指定文件读取用例列表
    TEST_CASES=$(cat "$CASE_FILE")
fi

echo "[INFO] 开始执行回归用例..."

for test_case in $TEST_CASES; do
    total_count=$((total_count + 1))
    test_name=$(basename "$test_case" .sv)

    echo "[RUN ] $test_name"

    # 运行仿真，设置超时保护（每个case最多10分钟）
    timeout 600 ./simv +testname="$test_name" \
        -l "$LOG_DIR/${test_name}.log" \
        > "$LOG_DIR/${test_name}_stdout.log" 2>&1

    exit_code=$?

    if [ $exit_code -eq 124 ]; then
        echo "[FAIL] $test_name (超时)"
        echo "FAIL: $test_name (超时)" >> "$RESULT_FILE"
        fail_count=$((fail_count + 1))
    elif [ $exit_code -ne 0 ]; then
        echo "[FAIL] $test_name (仿真退出码 $exit_code)"
        echo "FAIL: $test_name (仿真退出码 $exit_code)" >> "$RESULT_FILE"
        fail_count=$((fail_count + 1))
    elif grep -q "UVM_ERROR" "$LOG_DIR/${test_name}.log"; then
        error_count=$(grep -c "UVM_ERROR" "$LOG_DIR/${test_name}.log")
        echo "[FAIL] $test_name (UVM_ERROR $error_count)"
        echo "FAIL: $test_name (UVM_ERROR $error_count)" >> "$RESULT_FILE"
        fail_count=$((fail_count + 1))
    elif grep -q "TEST PASSED" "$LOG_DIR/${test_name}.log"; then
        echo "[PASS] $test_name"
        echo "PASS: $test_name" >> "$RESULT_FILE"
        pass_count=$((pass_count + 1))
    else
        echo "[WARN] $test_name (无法判断结果，请手动检查)"
        echo "WARN: $test_name (无法判断结果)" >> "$RESULT_FILE"
    fi
done

# ---------- 汇总报告 ----------
echo ""
echo "==== 回归结果汇总 ===="
echo "总用例数: $total_count"
echo "通过: $pass_count"
echo "失败: $fail_count"
echo ""
echo "==== 回归结果汇总 ====" >> "$RESULT_FILE"
echo "总用例数: $total_count" >> "$RESULT_FILE"
echo "通过: $pass_count" >> "$RESULT_FILE"
echo "失败: $fail_count" >> "$RESULT_FILE"

# 失败时输出失败列表
if [ "$fail_count" -gt 0 ]; then
    echo "[INFO] 失败用例列表："
    grep "^FAIL:" "$RESULT_FILE"
fi

# ---------- 清理临时文件 ----------
rm -f "$WORK_DIR"/*.fsdb 2>/dev/null || true

echo "[INFO] 回归结束，结果保存在 $RESULT_FILE"

6.3 脚本里的设计要点

这个脚本最核心的设计在于“分层判断失败原因”。用了三级状态判断：先判断超时，再判断仿真退出码，最后才判断log里的UVM_ERROR和PASS标志。为什么要这么设计？因为不同失败模式对应的处理手段完全不同：超时意味着case可能陷入死循环，需要检查testbench；退出码非0说明是编译或仿真崩溃，需要看core dump；UVM_ERROR则说明是断言或比较失败，需要看波形对比。如果只笼统输出一个 FAIL，排查效率会低很多。

另一个值得学习的点是所有临时文件最后统一清理，避免残留。rm -f "$WORK_DIR"/*.fsdb 2>/dev/null || true 里的 2>/dev/null 把错误信息丢弃，|| true 防止删除不存在的文件时被 set -e 中断。

实际使用中，你还要根据自己的工具链调整：VCS换成QuestaSim，把 simv 换成 vsim；UVM_ERROR的应用要用 grep -c "UVM_ERROR :" 并区分 UVM_FATAL；有的验证环境用的是 SystemVerilog 特有的宏定义，要在编译命令里加对应的 +define+ 参数。

7. 从命令到工程习惯：Shell能力对数字IC工程师的真正价值

说了那么多具体命令和脚本片段，如果只把Shell当“背命令”，那就浪费了。我在面试新人时，经常问一个问题：你写过多少行Shell脚本？其实问的不是代码量，而是他有没有“脚本化思维”。

数字IC流程里真正提高效率的，从来不是单条命令，而是把重复的动作变成可复用的“流水线”。你每发现一个要重复操作两次以上的动作，就应该条件反射地考虑写成脚本。典型的例子：从几十个simulation log里提取覆盖率数据，今天的case和明天的case操作方式一模一样，唯一的区别就是文件路径和数量。这种场景不脚本化，就是在浪费生命。

另外一个经验是脚本要追求“能被别人看懂”，而不仅仅是“自己能跑”。数字IC项目经常需要多个工程师协作，你的回归脚本、数据提取脚本、环境配置脚本，都会成为团队的公共资产。如果脚本写得一团乱，变量名毫无意义，逻辑分支不清楚，别人宁可手点也不用你的脚本，那脚本的价值就归零了。所以写脚本要有基本的代码规范：开头说明用途、关键步骤加注释、变量命名有意义、路径统一用变量。

我个人在实际工作里还有一个习惯：每次解决完一个Shell相关的问题，就把关键点记录到一个个人笔记里。半年下来，这份笔记会成为你的“Shell避坑手册”，很多问题翻一下笔记就能解决，不用再花几小时排查。这也是我开始写这类技术分享文章的初衷——踩过的坑如果不沉淀下来，过几个月连自己都会忘掉。

Shell脚本和数字IC设计本身一样，入门容易，精通靠积累。命令是死的，场景是活的，真正的高手是能把几百条命令灵活组合，解决工作里各种奇奇怪怪的问题。你如果能在实际项目里坚持用脚本解决重复劳动，三个月后回头看，一定会发现效率有了质的提升。

最后再分享一个我最近常用的小技巧：在EDA工具的log文件里，很多EDA工具的 warning 数量也是有价值的统计项，用 grep -c "Warning" 配合 awk 做汇总，可以快速评估一次综合或仿真的健康状况。比如把以下几行加到任何脚本末尾：

bash复制total_warning=$(grep -hc "Warning" "$LOG_DIR"/*.log | awk '{s+=$1} END {print s}')
total_error=$(grep -hc "Error" "$LOG_DIR"/*.log | awk '{s+=$1} END {print s}')
echo "[SUMMARY] 警告总数: $total_warning, 错误总数: $total_error"

这里的 grep -h 表示不输出文件名，-c 是计数，awk '{s+=$1} END {print s}' 对每个文件的结果做累加。两行命令就能得到全回归的警告/错误总数，对评估代码质量和工作稳定性非常有参考价值。这种组合用法，正是Shell脚本魅力的体现：单个命令毫不起眼，组合起来就能解决复杂问题。

Shell脚本在数字IC流程中的自动化实战：从入门到工程化