Currently, vide.toml works well for source files inside the workspace, but real HDL projects often depend on files outside the workspace, such as Vivado primitives, vendor simulation models, or shared IP/RTL directories.
This is awkward to model today:
- External files do not fit naturally into
sources, because they are not owned by the current project.
- Writing toolchain paths directly in
vide.toml makes the config machine-specific.
- Some external directories, such as Vivado installation directories, cannot reasonably contain their own
vide.toml.
- It also becomes unclear how diagnostics, file watching, rename, and workspace edits should treat those files.
A typical case is a project that needs Vivado primitives from a path like $XILINX_VIVADO/.... It would be helpful for the project model to have a cleaner way to represent such external dependencies, instead of requiring users to hard-code local toolchain paths into the project config.
This issue is only meant to record the problem, not to propose a concrete design yet.
Currently,
vide.tomlworks well for source files inside the workspace, but real HDL projects often depend on files outside the workspace, such as Vivado primitives, vendor simulation models, or shared IP/RTL directories.This is awkward to model today:
sources, because they are not owned by the current project.vide.tomlmakes the config machine-specific.vide.toml.A typical case is a project that needs Vivado primitives from a path like
$XILINX_VIVADO/.... It would be helpful for the project model to have a cleaner way to represent such external dependencies, instead of requiring users to hard-code local toolchain paths into the project config.This issue is only meant to record the problem, not to propose a concrete design yet.