I have a multi-file Verilog / SystemVerilog Custom Instrument. To support several Moku models from a single source, I keep the per-device constants in a small SystemVerilog package in its own `.v` file:
// device_params\_<device>.v (one file per target; only this file changes per device)
package device_params_pkg;
localparam int unsigned CLK_HZ = 312_500_000;
localparam int unsigned LSB_PER_VOLT = 36440; // etc.
endpackage
and import it in the top design:
import device_params_pkg::\*; // design.v
Both files are uploaded in the same compile source set (the package `.v` next to `design.v` and the shared cores).
The problem: a sporadic synthesis error
ERROR: \[Synth 8-36\] 'device_params_pkg' is not declared \[src/design.v:101\]
ERROR: \[Synth 8-36\] 'CLK_HZ' is not declared \[src/design.v:551\]
ERROR: \[Synth 8-36\] 'LSB_PER_VOLT' is not declared \[src/design.v:558\]
INFO: \[Synth 8-10285\] module '...' is ignored due to previous errors
Failed to read verilog 'src/design.v'
The error fires during `synth_design`'s parse of `design.v`, before the package is seen. That is, the package file is either not in the compile set, or it is analyzed after the module that imports it.
Why this looks like a file-ordering / nondeterminism issue, not a source error
1. Same source, different results. On one target the identical uploaded source failed one compile run with the error above, then built successfully on a rerun with no changes (full synth, route, and bitstream). On another target the same package-import construct fails with the identical error on every rerun, no matter how many times I run it.
2. It appears tied to how many files MCC ingests and in what order. A standalone SystemVerilog package has to be analyzed before its importer, and the ordering does not seem to be guaranteed (or the package file is intermittently left out of the set). Renaming the package file so it would sort earlier did not change the outcome.
3. The design compiles cleanly in Verilator with the files in any order, so the SystemVerilog itself is valid. The only difference is how MCC assembles and orders the analysis.
4. I have seen it on both a standard CustomInstrument build and a CustomInstrumentInterlaced build. This is with Verilog / SystemVerilog. I do not know whether VHDL is affected; Liquid Instruments’ own BoxcarAveragerFullRate example ships a standalone Package.vhd, and VHDL analysis order is normally dependency-resolved, so VHDL may be immune.
What I am seeking
1. Is there a supported way to control the analysis / compile order of the uploaded files, or to declare that design.v depends on the package file, so a standalone SystemVerilog package is guaranteed to be read first?
2. Is a standalone SystemVerilog package file officially supported in Moku Cloud Compile? If not, is the recommended pattern to inline the package into the importing file?
3. If this is a known nondeterminism in how the compile set is assembled or ordered, is a fix planned? A stable ordering, or dependency resolution like the VHDL flow, would make multi-file SystemVerilog designs reliable.