Fix DSP blocks synthesis bug in Yosys+Odin-II

[sdamghan]

Description

Except for the VTR primitives, the rest of models in architecture files could not be parsed by Yosys elaborator in the Yosys+Odin synthesizer unless Yosys is provided with modules' signature. This was possible previously, by adding the modules signatures manually in a Verilog file and pass it to Yosys+Odin-II. This PR automate this process by:

• A VerilogWriter entity is added to go through the arch.xml and generate a Verilog file including the declaration of all models, except for VTR primitive hard blocks (i.e., single_port_ram, dual_port_ram, adder, and multiply)
• Yosys is provided with the signature of models defined in the arch file via the generated Verilog file ( arch_dsp.v) in the ODIN_II directory. Additionally, the -blackbox option is added to the write_blif command in the yosys script to print out the definition of the used hard blocks in the coarse-grained BLIF file, and the -purge_lib option is added to the hierarchy command to avoid printing the definition of unused ones.
• Odin-II BLIF Reader creates a HARD_IP nodes for blackboxes and passes them untouched to the subsequent phases.

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[aman26kbm]

Thanks for working on this, @sdamghan. The general solution looks good to me. I'm not familiar with ODIN internals so can't really provide any meaningful comments on the code. I can help with some testing though.

[sdamghan]

Thanks @aman26kbm
I believe generating DSP blocks declaration in a Verilog like what is added in this PR could also help to avoid defining duplicated ports (like the one, I removed in commit 780688).
BTW, if you test the new feature and find any bugs please let me know.

[karanmathur]

HI @sdamghan, I am working with @aman26kbm and was testing out your fixes. I have instantiated a hard block in my circuit file and tested the yosys + odin ii flow. I am appending the results.

I ran the following command on your fix_yosys_odin_dsp branch
/home/data1/karan/vtr-sdamghan/vtr-verilog-to-routing/ODIN_II$ ./odin_II --elaborator yosys -V /home/data1/karan/vtr-sdamghan/vtr-verilog-to-routing/vtr_flow/benchmarks/verilog/test_yosys.v -a /home/data1/karan/vtr-sdamghan/vtr-verilog-to-routing/vtr_flow/arch/COFFE_22nm/k6FracN10LB_mem20K_complexDSP_customSB_22nm.xml -o output.blif

output on the terminal;
output_terminal_fix_yosys_odin_dsp.txt

output for master branch;
output_master.txt

elaborator.yosys.log for master branch;
elaborator.yosys.log

verilog test file;
test_yosys.txt

[sdamghan]

@karanmathur - Thanks for the results.

[karanmathur]

@sdamghan I forgot to mention, but the output on your branch shows that the bug seems to have been fixed.

[aman26kbm]

Can we merge this?

[sdamghan]

@aman26kbm - I believe the code is ready. Once the PR gets approved I will merged it.

@vaughnbetz - would you mind letting me know your comments on this PR?

[sdamghan]

As of today's meeting, I have updated the branch with recent changes in the master branch and added more comments and clarified the pull request description. Will merge once CI tests are green

[aman26kbm]

Hey @sdamghan , turns out there is still some issue here.

When we have a hard block instantiated in the design, we get an error at the ABC stage. Here's the error in abc0.out:
Line 34: Cannot find the model for subcircuit int_sop_4.

Sorry for not verifying properly earlier. We only verified the fix using the ./ODIN_II command (i.e. synthesis only). We didn't run run_vtr_flow or run_vtr_task to verify this change.

Can you please take a look?

[sdamghan]

@aman26kbm - let me investigate more, will let you know the result

[aman26kbm]

There are 3 BLIF files in the run directory:

-rw-rw-r-- 1 aman aman 18K Mar 11 11:23 coarsen_netlist.yosys.blif
-rw-rw-r-- 1 aman aman 17K Mar 11 11:23 dsp_slice_chain_test.odin.blif
-rw-rw-r-- 1 aman aman 17K Mar 11 11:23 0_dsp_slice_chain_test.odin.blif

Only coarsen_netlist.yosys.blif contains the .model declaration for int_sop_4 (the dsp hard block).
But the abc0.out file shows that the file fed to ABC was 0_dsp_slice_chain_test.odin.blif
Should coarsen_netlist.yosys.blif be provided to ABC by the flow?

[sdamghan]

There are 3 BLIF files in the run directory:

-rw-rw-r-- 1 aman aman 18K Mar 11 11:23 coarsen_netlist.yosys.blif
-rw-rw-r-- 1 aman aman 17K Mar 11 11:23 dsp_slice_chain_test.odin.blif
-rw-rw-r-- 1 aman aman 17K Mar 11 11:23 0_dsp_slice_chain_test.odin.blif

Only coarsen_netlist.yosys.blif contains the .model declaration for int_sop_4 (the dsp hard block). But the abc0.out file shows that the file fed to ABC was 0_dsp_slice_chain_test.odin.blif Should coarsen_netlist.yosys.blif be provided to ABC by the flow?

Not actually, since the coarsen_netlist.yosys.blif is the coarse grained BLIF file which is required to be technology mapped first and then passed to ABC.