Add gatesi_mode to init gates under gates_mode in BLIF format

[XutaxKamay]

What are the reasons/motivation for this change?

Hello,

This is a proposal in order to give BLIF some extra information to initialize gates (specifically DFFs and Latches).

There's probably another way to get these values but since it was easier for me to parse the BLIF file this way in order to run my own simulation tool, I thought I might give a try to contribute to it.

Explain how this is achieved.

I added -gatesi in order to indicate the initial values for the specific gates (mainly for DFFs and Latches outputs) in a non BLIF standard way.

If applicable, please suggest to reviewers how they can test the change.

With write_blif enabling both -gates -gatesi should be enough normally you should see something like this which indicates how to initialize the Q variable output:

.gate DFF 0 C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372067 Q=\5.internal_registers[533]
.gate DFF 1 C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372069 Q=\5.internal_registers[534]
.gate DFF 2 C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372071 Q=\5.internal_registers[535]
.gate DFF 0 C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372073 Q=\5.internal_registers[536]

instead of simply:

.gate DFF C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372067 Q=\5.internal_registers[533]
.gate DFF C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372069 Q=\5.internal_registers[534]
.gate DFF C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372071 Q=\5.internal_registers[535]
.gate DFF C=clk D=$abc$372906$auto$rtlil.cc:2985:MuxGate$372073 Q=\5.internal_registers[536]

Of course, I might be able to understand why it wouldn't be appreciated to be accepted, but I would be grateful if possible since it would get into my package manager and not sitting in another fork, in the worst cases it doesn't modify the default behavior of yosys at all if not both are enabled.

Thank you.

[widlarizer]

I don't think there's any problem with adding an extra mode like this. It's not the first non-standard feature. I think it's notable that this seems to be the first non-standard feature that can't then be parsed with read_blif. Without parsing support, it becomes difficult to test via roundtrip. With parsing support, we're affecting the parser, but that shouldn't cause trouble for parsing any .blif without this feature as I expect all parameter names to be reasonable and not start with a number, even if this is only a convention caused by users and developers being used to C and Verilog variable name restrictions. If you add support in read_blif and use it to write a test I'd be in favor of accepting this change

[XutaxKamay]

I don't think there's any problem with adding an extra mode like this. It's not the first non-standard feature. I think it's notable that this seems to be the first non-standard feature that can't then be parsed with read_blif. Without parsing support, it becomes difficult to test via roundtrip. With parsing support, we're affecting the parser, but that shouldn't cause trouble for parsing any .blif without this feature as I expect all parameter names to be reasonable and not start with a number, even if this is only a convention caused by users and developers being used to C and Verilog variable name restrictions. If you add support in read_blif and use it to write a test I'd be in favor of accepting this change

Alright, I'll write a read version aswell (don't mind the pull request being closed, it closed it because I force pushed from a fresh main branch and github automatically closed it)