SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsvmhw

vmhw

Coding & development

View repository

Updated 10-16 00:30

About this skill

Hardware EDA VM

Use ssh vmhw to invoke the dedicated hardware EDA environment. This Skill is responsible for selecting that host, preparing the runtime environment, and executing and observing EDA tools; the simulation, synthesis, place-and-route, or signoff methods for a specific project are still governed by user requirements and project scripts.

Fixed environment

Project Information
SSH alias vmhw
System CentOS 6.10，Linux 2.6.32，x86_64
User and home directory crazy，/home/crazy
EDA environment entry point /opt/skel/tools_env/bashrc
Authoritative workspace Windows：D:\develop\Virtual Machines\Project；VM：/mnt/hgfs/Project
VM local scratch area ~/temp/
Shared temporary directory /mnt/hgfs/Project/temp

Verified tools include VCS, Verdi, Design Compiler, ICC2, Innovus, Genus, and Questa/ModelSim. The installed versions are old and may change; for each task, rely on command -v in the login shell and the tool version output, and do not rely solely on this list.

Host routing

  • For commercial or licensed EDA, hardware tasks that depend on the existing toolchain in /opt , and that need to reproduce the lab's old-version behavior, use vmhw。
  • For general compilation, Python, Git, modern Linux tools, software dependency handling, and open-source auxiliary tasks suitable for Icarus Verilog or Verilator, use vmsw。
  • Hybrid tasks can do generation, compilation, or data processing on vmsw , and run dedicated EDA stages on vmhw . The two sides hand off through the shared Project .
  • Do not silently switch to a similarly named tool on vmhw just because a tool is missing or too old on vmsw ; versions and implementations may change results. Explain the difference, then switch according to user intent.
  • Do not have both VMs write to the same build directory at the same time. When parallel or cross-environment builds are needed, use separate output directories.

Workspace rules

Keep project-relative paths unchanged:

D:\develop\Virtual Machines\Project\<relative_project_path>
                              ↕
/mnt/hgfs/Project/<relative_project_path>

Prefer file lookup, viewing, and editing on the Windows side; execute via SSH only when a command truly depends on the EDA/Linux environment. VM artifacts should be written back to the corresponding shared project directory to avoid maintaining two authoritative copies.

Confirm the working directory and inputs exist before running tools:

ssh -o BatchMode=yes vmhw "whoami; hostname; test -r /mnt/hgfs/Project/<relative_project_path>"
ssh -o BatchMode=yes vmhw "bash -lc 'cd /mnt/hgfs/Project/<relative_project_path> && command -v <eda-command> && <eda-command> <arguments>'"

The login shell is used to load EDA paths and license variables. When the environment is abnormal, check:

ssh vmhw "bash -lc 'command -v <eda-command>; printenv SNPSLMD_LICENSE_FILE; printenv LM_LICENSE_FILE'"

Do not install, upgrade, or replace EDA software by default, and do not rewrite global environment scripts.

Long tasks and result observation

When it needs to run detached from SSH, close standard input and write output to a task-specific log:

ssh vmhw "bash -lc 'cd /mnt/hgfs/Project/<relative_project_path> && nohup <command> > run.log 2>&1 < /dev/null &'"
ssh vmhw "pgrep -fl '<process-pattern>'; tail -n 60 /mnt/hgfs/Project/<relative_project_path>/run.log"

When determining completion status, check the exit marker, expected artifacts, and log errors together; the mere disappearance of a process or the existence of an artifact file is not sufficient to prove success. CentOS 6's pgrep does not support some new parameters; use pgrep -fl。

Exceptions for shared mounts

Copy to the VM's native file system only when a tool is clearly affected by the shared file system's permissions, symbolic links, file locks, or I/O performance:

ssh vmhw "mkdir -p ~/temp/<project_name>; cp -a /mnt/hgfs/Project/<relative_project_path>/. ~/temp/<project_name>/"

After completion, copy back only the modifications and results that need to be preserved to the shared project. Fall back to SCP only if the shared directory is not mounted at all or is not writable; use Legacy SCP when connecting to that old host:

scp -O <local_file> vmhw:~/temp/<project_name>/
scp -O vmhw:~/temp/<project_name>/<remote_file> .

GUI and DISPLAY

Start graphical programs only when the user explicitly requests opening an EDA GUI. The current environment has been verified as: user crazy logged in on the virtual machine graphical desktop :0, the X socket is /tmp/.X11-unix/X0, and the same user successfully executes DISPLAY=:0 xdpyinfo . The desktop session may change, so it is still necessary to probe before actually launching, and do not treat :0 as a permanent invariant:

ssh vmhw "who; ls -la /tmp/.X11-unix"
ssh vmhw "DISPLAY=:0 xdpyinfo >/dev/null 2>&1 && echo X11_OK"

SpyGlass is launched via Make

When the Makefile launches SpyGlass and the GUI should be displayed on the virtual machine desktop, you must put DISPLAY into the process environment of make so that it is inherited by Make and the SpyGlass child process:

export DISPLAY=:0
make <spyglass-target>

It can also be executed once on the Windows side:

ssh vmhw "bash -lc 'cd /mnt/hgfs/Project/<relative_project_path> && DISPLAY=:0 make <spyglass-target>'"

When executing in the background, likewise pass the variable explicitly:

ssh vmhw "bash -lc 'cd /mnt/hgfs/Project/<relative_project_path> && DISPLAY=:0 nohup make <spyglass-target> > spyglass.log 2>&1 < /dev/null &'"

Prefer using DISPLAY=:0 make ... or first execute export DISPLAY=:0. Do not rely on make DISPLAY=:0unless the Makefile explicitly export DISPLAY; command-line Make variables do not necessarily become environment variables for all recipe child processes.

If only batch processing is needed, do not connect the GUI merely to eliminate the Cannot connect to X11 Display warning; prefer the project's existing batch/no-GUI targets or SpyGlass batch options to avoid hidden pop-up windows causing the task to wait.

Launch in the background using the detected display number, and simultaneously check the process, window tree, and logs:

ssh vmhw "DISPLAY=:0 nohup <gui-command> > /mnt/hgfs/Project/temp/<gui-name>.log 2>&1 < /dev/null &"
ssh vmhw "pgrep -fl '<process-pattern>'; DISPLAY=:0 xwininfo -root -tree; tail -n 60 /mnt/hgfs/Project/temp/<gui-name>.log"

If display to Windows is required, you can use ssh -X vmhw <gui-command>, but an X Server must already be present on the local machine. Currently the crazy user accessing the virtual machine's :0 does not require additional XAUTHORITYsettings; if the Makefile uses sudo or switches users, X11 authorization will not be inherited automatically. Do not use the insecure xhost +, and do not assert that the window has opened based solely on the process being alive.

Legacy system compatibility and security

  • CentOS 6 does not have systemctl, use service; avoid assuming that modern GNU/Linux options exist.
  • command not found When the license variable is missing, first confirm that bash -lcis used, then check the environment entry point and license status.
  • Could not resolve hostname vmhw If it appears only in a restricted execution environment, retry according to the permission mechanism, and do not modify the user's SSH configuration without authorization.
  • By default, perform read-only probing first. Before deleting or overwriting results, terminating processes not belonging to this task, or modifying licenses or system configuration, you must confirm the explicit target and authorization.
  • Unless the user explicitly requests it, do not clean up the shared workspace or the VM local directory.