Question: Porting a complex manycore design (OpenPiton) to OpenROAD-flow-scripts - recommended approach for multi-clock RTL

[ShivaranjaniGR]

Hi,

I am working on porting an OpenPiton tile to OpenROAD-flow-scripts targeting the Nangate45 PDK, as part of building an open-source activity-driven power estimation flow. The plan is to synthesize the tile through OpenROAD, generate SAIF files from Verilator simulation, and annotate them in OpenSTA for workload-aware power analysis.

OpenPiton has significantly more complexity than the example designs currently in the repo. A few questions before I begin:

1. For a design with multiple asynchronous clock domains (e.g. a core clock and a NoC clock), what is the recommended way to handle this in constraint.sdc? Should clock domain crossings be explicitly cut with set_clock_groups -asynchronous, or is there another preferred approach in OpenROAD?

2. The tile RTL spans many files across subdirectories. Is there a recommended way to specify VERILOG_FILES for large designs — glob patterns, a filelist, or explicit enumeration?

3. Are there known limitations with mixed Verilog/SystemVerilog designs in the current Yosys-based synthesis flow that I should audit for before attempting synthesis?

I will contribute the resulting config.mk and constraint.sdc back once the flow is working.

Thanks
G R Shivaranjani

[maliberty]

1 - I believe set_clock_groups is ok
2 - its just make so you can use any of its facilities, eg
export VERILOG_FILES = $(sort $(wildcard $(DESIGN_HOME)/src/aes/*.v))
3 - I don't know of any

How many instances do you expect in a synthesized netlist for this design?

[ShivaranjaniGR]

Thank you for the response! I'll follow up on the instance count shortly.
On a related note, I'm also exploring the UPF source as part of preparing a GSoC 2026 proposal for the UPF Improvements project. While reading through the codebase I noticed the README.md limitations section is entirely empty even though several UPF 2.1 commands like create_supply_net and add_power_state seem incomplete.
Quick question : is there an internal tracking document or issue list for known UPF gaps, or is the README limitations section itself meant to be the canonical reference for what's missing?
Thanks!
G R Shivaranjani