Module not routed because Yosys proc is missing

[pars97]

While setting up my pins location around my core, I saw that some of them were not connected at all.
The messages I get while running the make command for my design (and also the ibex design of the sky130hd tech) is that my modules are ignored because the 'proc' command has to be ran first?

Warning: Ignoring module fsm_controller because it contains processes (run 'proc' command first).
Warning: Ignoring module spi_slave because it contains processes (run 'proc' command first).

Where should I put such command?

In simulation everything works smooth; I see the signal being propagated from the external input into my simulated device but it is in a clocked thread of a finite state machine.

I.e. in a @Posedge statement which is operating a case (state) statement.

The unconnected pads are a 12-bits wide bus meant to be an ADC reading which is supplied externally.

The weird thing is that in the same block [the 'case (state)'], i have pads that are connected into the circuit. Where they are different is that those pads are either conditions (flags) or output pads being driven by the circuit.

I can include my .v files if needed.

Thanks a lot

[maliberty]

This sounds like a better question for the yosys repo but maybe @povik might now

[pars97]

While looking at the yosys documentation and how the 'proc' was coded I tried a couple of things and here what worked for me.

In the file synth_preamble.tcl, line 58-67 i added the "yosys proc" line:

if {[env_var_exists_and_non_empty PRESERVE_CELLS]} {
  # Expand hierarchy since verilog was read in with -defer
  hierarchy -check -top $::env(DESIGN_NAME)
  yosys proc
  foreach cell $::env(PRESERVE_CELLS) {
    select -module $cell
    setattr -mod -set keep_hierarchy 1
    select -clear
  }
}

I also had the

export PRESERVE_CELLS = "_my forgotten cells_"

in my config.mk file for my design.
Since then, my design doubled in size and all my IN/OUT are connected inside the circuit.

[povik]

@pars97 Can you provide more details about the step which printed out "Warning: Ignoring module fsm_controller because it contains processes (run 'proc' command first)."?

It means a concrete Yosys pass is ignoring the module but it shouldn't directly cause removal of the module from the design.

[pars97]

It is in the first steps :

1. Executing Verilog-2005 frontend: /home/phars10/OPENROAD/OpenROAD-flow-scripts/flow/designs/src/CORE_2501PH/CORE_2501PH.v
2. Executing Verilog-2005 frontend: /home/phars10/OPENROAD/OpenROAD-flow-scripts/flow/designs/src/CORE_2501PH/fsm_controller.v
3. Executing Verilog-2005 frontend: /home/phars10/OPENROAD/OpenROAD-flow-scripts/flow/designs/src/CORE_2501PH/spi_slave.v
4. Executing Liberty frontend: ./objects/amf/CORE_2501PH/base/lib/amf_tt_025C_5v00.lib
5. Executing Liberty frontend: ./objects/amf/CORE_2501PH/base/lib/amf_tt_025C_5v00.lib
6. Executing HIERARCHY pass (managing design hierarchy).
7. Executing AST frontend in derive mode using pre-parsed AST for module `\CORE_2501PH'.
7.1. Analyzing design hierarchy..
7.2. Executing AST frontend in derive mode using pre-parsed AST for module `\spi_slave'.
7.3. Executing AST frontend in derive mode using pre-parsed AST for module `\fsm_controller'.
7.4. Analyzing design hierarchy..
7.5. Analyzing design hierarchy..
Using ABC speed script.
Extracting clock period from SDC file: ./results/amf/CORE_2501PH/base/clock_period.txt
Setting clock period to 100
8. Executing HIERARCHY pass (managing design hierarchy).
8.1. Analyzing design hierarchy..
8.2. Analyzing design hierarchy..
9. Executing OPT_CLEAN pass (remove unused cells and wires).
Warning: Ignoring module fsm_controller because it contains processes (run 'proc' command first).
Warning: Ignoring module spi_slave because it contains processes (run 'proc' command first).
10. Executing RTLIL backend.
Warnings: 2 unique messages, 2 total

Also, it doesnt remove the module from the design outright, it removes the procedural parts of the designs.
What that meant is that in my designs I had and 12 bits ADC input that was only used in the procedural part and when the opt -purge was ran, it found that the ADC inputs were not connected inside the circuit.

Bizzarely, rerunning without my fix does give me the warning but now, the circuit seems connected.

(amf_tt_025C.lib is the copy of the GF180 025C one)