Linux Handbook for VLSI Engineers

A comprehensive, practical guide to Linux commands, workflows and best practices used in VLSI design flows and tool automation.

Author: Afzal Malik — Circuit Design Engineer, STMicroelectronics

Why Linux matters in VLSI

Linux is the industry standard for EDA tools. Typical flows—synthesis, place & route, LVS/DRC, SPICE simulations, extraction, STA—are run on Linux. The OS affects:

how tools are installed and launched
how scripts behave (shell differences)
file and permission management for shared resources
automation, nightly regressions and resource scheduling

This handbook focuses on the Linux skills you will actually use in VLSI workflows: managing files, reading logs, automating flows, debugging EDA issues, and working safely on shared systems and clusters.

Linux basics for VLSI
Filesystem & quotas
Navigation & file management
Permissions & ownership
Viewing and searching logs/netlists
Wildcards, regex & mass ops
Redirection & piping
Compression & archiving
Process management & monitoring
Disk usage, NFS, scratch spaces
Environment variables & tool setup
Shell scripting & best practices
Cron & nightly regressions
SSH, keys & working on clusters
VLSI-oriented directory structure & naming
Common errors in EDA and fixes
Productivity tips & checklist
Resources & references

Filesystem & quotas (what matters)

Important directories for VLSI workflows:

Path	Use
`/home/username`	Personal files, code, small docs. Usually quota-limited.
`/scratch/username`	Large temporary storage for simulations — use this for big runs.
`/tools` or `/cad`	Installed EDA tools (Synopsys, Cadence, Mentor, Open-source tools).
`(NFS)`	Network-mounted file systems for shared IP and libraries.

Home quotas & scratch

Companies enforce quotas on /home. Never use /home for large simulations or extracted files. Use /scratch or cluster-local storage. Keep /home for sources, scripts and small results.

Navigation & file management (practical commands)

Basic navigation

pwd                # print working directory
ls -ltr            # list files by time (useful to find recent logs)
cd ~/projects/adc  # go to a project
cd -               # go to previous directory
cd ..              # go up

File operations

mkdir -p sim/run1              # create directories
cp source.sp /scratch/user/    # copy to scratch
cp -r folder /backup/          # recursive copy
mv oldname.sp newname.sp       # rename or move
rm filename                    # remove file
rm -r directory                # remove directory recursively (careful!)

Best practice: write small helper scripts to perform backups before big deletes. Name files with dates (YYYYMMDD) for traceability.

Links (symlinks)

ln -s /cad/tsmc180/models ./models      # create symbolic link
readlink models                          # show link target

Symlinks keep project directories small and avoid duplicate copies of large process files.

Permissions & ownership (critical for tools)

Many EDA issues stem from wrong file permissions or ownership—especially when transferring files between systems or copying from shared locations.

Viewing permissions

ls -l filename      # long listing with permissions and owner
stat filename       # detailed file info

Changing permissions & owner

chmod +x script.sh     # make script executable
chmod 755 dir           # common directory permissions
chmod 644 file.txt      # read/write owner, read others
chown user:group file   # change ownership (requires sudo)
sudo chown -R user:grp /scratch/user  # recursively change owner

Tip: If a tool fails with permission errors, check both file permissions and the directory permissions (execute bit on directories).

Setgid/setuid basics

You will rarely use setuid in EDA, but setgid bit on directories is useful to ensure group-writable outputs in a shared project directory:

chmod g+s /shared/project

Viewing & searching logs, netlists, reports

Being fast at reading and extracting useful lines from large logs is a superpower in VLSI.

Basic viewing

cat file.log          # print whole file (not recommended for huge logs)
less file.log         # scroll easily (use /pattern to search)
tail -n 200 file.log  # show last 200 lines
tail -f file.log      # follow live updates

Searching with grep

grep -i "error" file.log                # case-insensitive search
grep -n "Timing" report.txt              # show line numbers
grep -r "violation" ./                  # recursive search in folder

Useful patterns to search in EDA logs

grep -i "error", grep -i "failed" — obvious starting points
grep -i "warning" — some warnings are actionable
grep -E "slack|negative slack|ns|ps" — timing issues
grep -E "(lvs|drC|LEVEl|unsatisfied)" — DRC/LVS messages (patterns differ per tool)

Filtering and context

grep -n "error" file.log | head -n 50     # show first 50 matches
grep -n "error" file.log | tail -n 5      # show last 5 matches
grep -n -A 3 -B 2 "error" file.log        # show 2 lines before and 3 after

Use -A/-B/-C to see context—critical when logs are terse.

Wildcards, regular expressions & mass operations

Working with many files (multiple testcases, waveform dumps) requires safe mass operations.

Basic wildcard examples

ls *.log
rm sim_*.out
cp *_report.txt /results/
mv *.vhdl vhdl_files/

Using find for precise operations

find . -name "*.log" -mtime +7 -exec rm {} \;    # delete logs older than 7 days
find . -name "*.sp" -exec chmod 644 {} \;        # change permissions
find /scratch -type f -size +100M -ls            # list large files

Regular expressions and awk

grep -E "^(ERROR|FATAL)" biglog.log
awk '/Total negative slack/ {print $NF}' timing.rpt
sed -n '1,200p' file           # print first 200 lines

Use find and awk to automate housekeeping tasks safely. Test commands on a small set before running wide operations.

Redirection & piping (data processing)

Piping and redirection are indispensable when extracting data from reports or creating summary metrics.

Common patterns

grep -i "error" log.txt > errors.txt
cat file1 file2 | grep -i "violation" | sort | uniq > violations.txt
awk '{print $1, $NF}' timing.rpt | sort -k2 -nr | head -n 20

Example: extracting negative slack counts

grep -i "neg slack" timing.rpt | awk '{count++} END {print count " negative slack instances"}'

Combine grep, awk, sort and uniq to build small analytics pipelines for daily regressions.

Compression & archiving

Compress logs, results or backup directories before moving between systems.

tar -cvf project.tar project/
tar -czvf project.tar.gz project/         # gzip compression
tar -xzf project.tar.gz                   # extract
gzip bigfile                              # compress single file
gunzip bigfile.gz                         # decompress
rsync -avh --progress src/ dest/          # efficient copy (with resume)

Use rsync to copy large directories to remote servers reliably. Use --exclude to skip large binary outputs.

Process management & monitoring

EDA flows are resource heavy. Know how to monitor CPU, memory and kill processes safely.

Monitoring

top                # live update of processes and CPU/memory
htop               # nicer interface (if installed)
ps -ef | grep dc   # find design compiler jobs
watch -n 5 'ps -ef | grep run_sim'  # watch a pattern every 5s

Killing processes

ps -ef | grep java         # find java-based tools
kill PID                   # polite kill
kill -9 PID                # force kill (use sparingly; risk of leaving locks)
lsof -p PID                # list files opened by process (diagnose locks)

Before killing a process, check for locks, shared resources and whether the job is on a cluster scheduler (doing so there could be counterproductive).

Disk usage, NFS & scratch spaces

Always check disk usage before running big flows—lack of space causes tool crashes and corrupted outputs.

Check disk usage

df -h               # show filesystem usage
du -sh *            # folder sizes in current directory
du -sh /scratch/*   # see per-user usage on scratch
ncdu                # interactive disk usage (if installed)

NFS caveats & best practices

Avoid heavy I/O on NFS-mounted home directories for simulation outputs. Use local scratch where possible.
Network latency can make many small files very slow—use fewer, larger files when possible.
Be mindful of stale file handles when the server reboots—run umount/mount as admin if needed.

Environment variables & EDA tool setup

Tools depend heavily on your environment. Standard practice involves setting up tool environment scripts that you source when you login.

Typical variables

export PATH=/tools/synopsys/bin:$PATH
export CDS_ROOT=/tools/cadence
export LM_LICENSE_FILE=27000@license-server.company.com  # license server
export PDK_ROOT=/cad/pdk/tsmc180

Setup scripts & dotfiles

Place common exports in ~/.bashrc or ~/.bash_profile depending on login shell. For reproducibility, add a project-level env.sh that others can source:

# env.sh (project-specific)
export PDK_ROOT=/cad/pdk/tsmc180
export PATH=$PDK_ROOT/bin:$PATH
export PROJECT_ROOT=/scratch/username/projectX

Avoid hard-coding absolute paths in tools; prefer variables so projects are portable across users and servers.

Shell scripting for automation (best practices)

Scripting is the multiplier of productivity. Learn to write scripts that are safe, logged and idempotent.

Script skeleton

#!/bin/bash
set -euo pipefail
IFS=$'\n\t'

LOG=run.log
exec > >(tee -a "$LOG") 2>&1

echo "Starting simulation: $(date)"
# commands...
echo "Done: $(date)"

Explanation:

set -euo pipefail makes scripts fail early and reliably.
Redirect stdout & stderr to a logfile using tee for traceability.
Use functions for repeated tasks and parameterize inputs.

Example: batch-run SPICE files

#!/bin/bash
set -euo pipefail
for spf in sims/*.sp; do
  echo "Running $spf"
  ngspice -b "$spf" -o "results/$(basename $spf .sp).log"
done

Use a proper directory structure: sims/, results/, scripts/.

Logging & exit codes

Always check exit codes of tools and log failures. Example:

run_tool arg1 arg2
if [ $? -ne 0 ]; then
  echo "Tool failed" >&2
  exit 1
fi

Cron, job scheduling & nightly regressions

Large verification teams run nightly regressions. Cron is the simplest scheduler; real clusters use Slurm, LSF, or PBS. Still, cron is useful for lightweight tasks.

Edit crontab

crontab -e
# Example: run script every day at 3:00 AM
0 3 * * * /home/user/project/scripts/run_regression.sh >> /home/user/logs/reg.log 2>&1

Best practices for regression scripts

Use absolute paths
Lock runs using a lockfile to prevent overlapping runs
Rotate logs (logrotate) to avoid filling disk
Notify failures via email or Slack webhook

Lock file pattern

LOCK=/tmp/regression.lock
if [ -f "$LOCK" ]; then
  echo "Already running" && exit 0
fi
trap 'rm -f "$LOCK"; exit' EXIT
touch "$LOCK"
# run jobs...

SSH, keys & working on clusters

Remote cluster usage is standard. SSH keys are necessary for passwordless logins and scripting.

Generate SSH key & copy to server

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
ssh-copy-id user@cluster.company.com
ssh user@cluster.company.com

Using multiplexing & config

# ~/.ssh/config example
Host cluster
  HostName cluster.company.com
  User youruser
  IdentityFile ~/.ssh/id_rsa
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 600

Cluster schedulers (quick notes)

Most companies use LSF, Slurm or PBS. Learn how to submit a job, request CPUs, memory and GPUs if needed:

# Simple Slurm batch script: run_sim.sbatch
#!/bin/bash
#SBATCH --job-name=sim1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=8
#SBATCH --mem=16G
#SBATCH --time=06:00:00
srun ngspice -b sims/test.sp -o results/test.log

Always test locally before scheduling jobs that consume many cluster resources.

Project & directory structure for VLSI projects

A consistent layout helps collaboration and automation. Example:

project-name/
├── doc/                 # design notes, reports
├── sims/                # spice / testbenches
├── rtl/                 # verilog / vhdl
├── scripts/             # automation scripts
├── results/             # simulation outputs (don't store large files in home)
├── pdk/                 # symlink to PDK (read-only)
└── env.sh               # environment variables for the project

Use README.md for the top-level project description and CONTRIBUTING.md for rules if there are multiple contributors.

Common Linux & EDA errors — diagnosis & fixes

Tool fails to start — license error

Error: cannot obtain license
# Fixes:
# 1. Check LM_LICENSE_FILE environment variable
echo $LM_LICENSE_FILE
# 2. Check network connectivity to license server
ping license-server.company.com
# 3. Verify port and license server availability (telnet or nc)
nc -vz license-server.company.com 27000

Permission denied when launching tool

# Diagnose:
ls -l /tools/cadence/bin/tool
# Fix:
chmod +x /tools/cadence/bin/tool
# Or ensure group has execute permission and you belong to group
sudo chown -R user:cad_group /tools/cadence

Out-of-disk errors during simulation

df -h
du -sh results/*
# Fix:
# move large outputs to /scratch or compress older outputs
tar -czvf old_results.tar.gz results/old/
rsync -avh --remove-source-files old_results.tar.gz user@storage:/backup/

Stale locks or file handle errors on NFS

# Check for stale NFS handles or re-export issues:
lsof | grep 'stale'   # platform dependent
# If server rebooted, you might need to remount or contact admin
umount /path && mount /path

Slow operations on many small files

Use tar/gzip to combine small files into fewer large archives before transfer, or convert outputs to formats that consolidate many small files.

Productivity tips, aliases & shortcuts

Small habits save hours. Add these to your ~/.bashrc:

# Aliases
alias ll='ls -ltr'
alias ..='cd ..'
alias gs='git status'

# Quick disk check
alias duf='du -sh * | sort -h'

# Common grep patterns for EDA logs
alias grep_err="grep -i -nE 'error|failed|fatal'"

# Safe remove (move to /tmp)
safe_rm() { mv "$1" /tmp/removed_$(date +%s)_$1; }

Use tmux or screen for persistent sessions when working over SSH—prevents loss of progress when connection drops.

Security & collaborative best practices

Avoid sharing private keys; use passphrases and an SSH agent.
Use group permissions for shared projects—don’t use world-writable directories.
Use git for sources; store binaries and large outputs in artifact storage (not in git).
Document environment setup in env.sh for reproducibility.

Final practical checklist (print & use)

☐ Use /scratch for big outputs — keep /home light
☐ Always run ls -ltr to identify the latest logs
☐ Check df -h before big jobs
☐ Wrap runs in scripts with set -euo pipefail and logging
☐ Use SSH keys and configure ~/.ssh/config for servers
☐ Use grep/awk pipelines to extract key metrics from reports
☐ Keep project env scripts (env.sh) and README up to date
☐ Use rsync for large transfers with --progress and --partial
☐ Automate nightly jobs with cron or cluster schedulers; always log outputs

Resources & references

Linux man pages: man command (e.g. man grep)
Advanced text processing: The AWK Programming Language, online awk tutorials
Shell scripting: Bash Guide and Advanced Bash-Scripting Guide
Cluster schedulers: Slurm/LSF/PBS official docs
Your uploaded PDF (full Linux commands guide): /mnt/data/426035c7-db49-4cff-ba70-223e13521bc2.pdf — host or link it from your server if you want readers to download the full manual

Written by: Afzal Malik

Circuit Design Engineer, STMicroelectronics

Contribute an article • Follow on LinkedIn

Saturday, 22 November 2025