ic-design-prj

IC Design Project

Treat the accompanying C model and RTL project as a hardware-software co-design system, not as two unrelated code directories. First inspect and edit authoritative files on the physical machine, then route commands that genuinely depend on the Linux or EDA environment to the corresponding VM.

Authoritative directories and applicable boundaries

• C model directory: depends on the current project's pj_c_model directory (for example D:\develop\Virtual Machines\Project\<your_project>\pj_c_model）
• RTL directory: depends on the current project's pj_rtl directory (for example D:\develop\Virtual Machines\Project\<your_project>\pj_rtl）
• VM shared mapping:D:\develop\Virtual Machines\Project\<relative> ↔ /mnt/hgfs/Project/<relative>
• The original descriptions are located in each of the two projects' document/. The descriptions may lag behind the scripts; before execution, rely on the current source code, Makefile, configuration files, and actual tested tools.
• You must search for and operate on files based on the real module names of the current real project (such as <module_name>). Use source/、build/linux/、script/run/、simulation/、synthesis/ and similar structures to locate roles. It is absolutely forbidden to hardcode invalid sample names included with templates (such as xkcalc、xkmsc , etc.) into any operations and paths; they do not exist in real projects.

Environment skills that must be explicitly invoked

Before executing VM commands, you must explicitly load and declare the invocation of the corresponding skill; merely mentioning the VM in text does not count as invoking it.

Work	Must be explicitly invoked	Host
File search, reading, editing, diff review	Does not enter the VM	Windows physical machine
C model's C/C++, CMake, Make, Python, Perl, Doxygen, Graphviz, Git, data processing	$vmsw	Ubuntu vmsw
VCS compilation, simulation, and regression for RTL/netlist, as well as Verdi/DVE, Design Compiler, Formality, SpyGlass	$vmhw	CentOS vmhw

First read $vmsw or $vmhw 's current SKILL.md, and follow the connection, shared directory, long task, GUI, compatibility, and security rules therein. If the skill is unavailable, stop the corresponding VM phase and explain why; do not silently switch to the local machine, another VM, or a similarly named tool.

Working method

1. On the Windows side, determine the C model root, RTL root, target module, input data, expected artifacts, and existing modifications. First look for local instructions such as AGENTS.md within the project.
2. Read only the relevant references according to the task:
   • To identify directories, hosts, tools, and documentation entry points: read references/project-and-environment.md。
   • To modify, build, run, or regress the C model: read references/c-model-workflow.md。
   • To modify RTL, file lists, simulation, Lint, synthesis, or formal verification: read references/rtl-workflow.md。
   • To generate RTL stimuli/golden results from the C model, or to execute the full delivery loop: read references/co-design-flow.md。
   • Naming, templates, documentation, checklists, or reviews: read references/conventions-and-delivery.md。
3. Edit on the Windows side. Preserve the existing directory hierarchy, relative paths, file headers, naming system, and generated file boundaries.
4. Perform pre-checks before entering the VM: verify that the shared path exists, use command -v to check the actual tools, and run a side-effect-free make/make cfg_view to view the current target and expanded parameters.
5. Prefer to run in an independent build/session directory. The two VMs must not write to the same output directory at the same time; use task-specific directories and logs for long tasks.
6. Determine success jointly by exit status, complete logs, expected artifacts, and result content; do not look only at the top-level make return value.
7. Report the hosts actually executed on, command categories, key parameters, artifact locations, pass/fail evidence, phases not run, and the reasons.

Authority and Generation Boundaries

• Read the actual scripts first, then use the documentation examples. The same command name may behave differently due to tool versions, paths, or template defects.
• The manual sources of the C model configuration are *_cfg.csv and a small amount of hand-written checking/export code;*_cfg_proc.cpp、*_cfg_type.hpp、*_cfg.rst and the regression configuration are usually generated by the *_cfg.pl in the same directory.
• The RTL compilation set is driven hierarchically by *_inc.f、*_lib.f、*_rtl.f . After adding source files, the file list must be updated along the hierarchy; do not just let some temporary command directly see the new files.
• define*.vh and the corresponding undef*.vh are maintained in pairs; after a module ends, cancel the local macros to avoid cross-module pollution.
• The dut_setting.vh and *_dumpDatInp*.dat/*_dumpDatOut*.dat exported by the C model are the software-hardware co-simulation interfaces; when changing fields, bit widths, saturation modes, data order, or file names, both sides must be synchronized.

Safety Boundaries

• runListUpdate.sh will rewrite formats in bulk, regenerate files, and delete empty directories; first record the working tree state, and review the differences item by item after execution.
• make clean、make clean_all, regression scripts, and generation scripts contain recursive deletion. Before execution, parse and verify that the targets must be located in the expected build, session, dump, or VM temporary directories.
• Do not automatically execute runListPush.sh: the sample script contains a force push to master , and it may only be run after explicit user authorization and verification of the remote/branch.
• Before running memory generation, DC, Formality, or other EDA flows, first verify the script inputs, process libraries, constraints, tools, and license configuration.
• Start the Verdi, DVE, SimVision, IMC, Quartus, or Vivado graphical interfaces only when the user explicitly requests a GUI.
• Do not silently substitute open-source tools because a commercial tool fails; results from different simulators, synthesizers, and versions cannot be considered equivalent.

Minimum Completion Criteria

Select sufficient evidence according to the task scope:

• C model changes: configuration generation is consistent, build has no warnings,--dryRun/single run passes, and related regression and output checks pass.
• RTL changes: the file list is closed, and in $vmhw use VCS to complete compilation, elaboration, single-case simulation, and necessary regression; then complete Verdi, SpyGlass, DC, and/or Formality according to the task scope.
• Software-hardware consistency: under the same configuration, the C model vectors are consumed by the RTL testbench, correct cases have no ERROR, and deliberately wrong cases can be detected.
• Synthesis/formal verification: library and constraint sources have been confirmed, reports have no unexplained errors, and Formality uses a DC session that exactly matches the target netlist.
• Delivery: artifact and report locations are clear, source file differences caused by batch scripts have been reviewed, and documentation/performance records are updated as interfaces or results change.