Yosys+VTR

[sdamghan]

Description

This PR provides the VTR flow with scripts to run Yosys as the synthesizer.
The Yosys synthesis script is mostly inspired by what Eddie Hung proposed for VTR-to-Bitstream. However, some changes like removing the ABC stage from inside of the Yosys and adding new designs to perform depth splitting for single_port_ram and dual_port_ram are added, and updating the yosys_models with recent Yosys changes have been applied.

Comparison:

Yosys_vs_Odin-II	Yosys+Odin-II_vs_Odin-II
VTR_Yosys_vs_Odin.xlsx	VTR_Yosys+Odin_vs_Odin.xlsx
Micro_Yosys_vs_Odin.xlsx	Micro_Yosys+Odin_vs_Odin.xlsx
FIR_Yosys_vs_Odin.xlsx	FIR_Yosys+Odin_vs_Odin.xlsx

Steps to run VTR flow with the Yosys front-end

% Compile the VTR project with "-DWITH_YOSYS=ON" flag
$(VTR_ROOT) > make CMAKE_PARAMS="-DWITH_YOSYS=ON"
$(VTR_ROOT) > cd vtr_flow/scripts
$(VTR_ROOT) > ./run_vtr_flow.py  $(PATH_TO_CIRCUIT) $(PATH_TO_ARCH) -start yosys

---

Related

Issue

Motivation and Context

Complimentary changes to PR #1798

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

[vaughnbetz]

nightly_test_3 failed due to arm_core getting less logic and somewhat more memory (QoR failure). This doesn't really seem like a problem, but do you expect this @sdamghan ? If so, you can update QoR data to make it pass.
odin_tech_strong: modest result changes on arm_core and boundtop. Expected? If so, you can update the golden to make that pass too.

 Failed . . . . . . . . . . . . . . . vtr/arm_core/k6_frac_N10_frac_chain_mem32K_40nm
    - Longest Path                        [-5360-]{+5421+}
  Ok . . . . . . . . . . . . . . . . . vtr/bgm/k6_frac_N10_frac_chain_mem32K_40nm
  Ok . . . . . . . . . . . . . . . . . vtr/blob_merge/k6_frac_N10_frac_chain_mem32K_40nm
  Failed . . . . . . . . . . . . . . . vtr/boundtop/k6_frac_N10_frac_chain_mem32K_40nm
    - logic element                       [-4141-]{+4204+}
    - latch                               [-857-]{+871+}
    - Adder                               [-136-]{+151+}
    - Estimated LUTs                      [-4435-]{+4510+}
    - Total Node                          [-5167-]{+5259+}

[vaughnbetz]

Looks good overall @sdamghan .

1. I think you should add a README to yosyslib explaining where these files came from, and what they are for, and giving a link to the relevant yosys documentation.
2. I see changes to arm_core and boundtop, so the QoR changes look OK. But you'll need to update the golden results.
3. You should update the VTR documentation with a Yosys tab and brief information on how to run it with the other tools (but that can be another PR).

[sdamghan]

Looks good overall @sdamghan .

1. I think you should add a README to yosyslib explaining where these files came from, and what they are for, and giving a link to the relevant yosys documentation.
2. I see changes to arm_core and boundtop, so the QoR changes look OK. But you'll need to update the golden results.
3. You should update the VTR documentation with a Yosys tab and brief information on how to run it with the other tools (but that can be another PR).

@vaughnbetz
I have just fixed the problem that caused yosys not to transform implicit memories to SPRAM/DPRAM blocks. So, hopefully, the arm_core mismatch should not appear anymore. However, I should also regenerate Yosys+Odin-II golden results because of the boundtop changes.
My apologies for the belated response; I have been busy with the thesis stuff.

I am going to investigate the memory packing problem with Yosys as the VTR flow synthesizer. I think it would be better to merge this PR once this problem is solved,
Regarding the documentation, I will definitely add elaborated info about how Yosys+VTR is also working.

[vaughnbetz]

Sounds good; thanks.

[sdamghan]

@vaughnbetz, it seems last week I made a mistake; I still see the memory packing issue using Yosys synthesizer. As you suggested, I tested a simple single ram module to see the difference between these two synthesizers. I could not find any effective difference between the generated BLIF files by both synthesizers, expect, Yosys put a wrapper around signals connected to single_port_ram blocks. That would be really appreciated if you or anyone you suggest could have a look at them as well.

simple_ram_test.zip

[vaughnbetz]

Thanks @sdamghan . I took a look, and the yosys design connects an additional 7 address lines to LUTs (.names) that output gnd, while odin-ii leaves them unconnected.
vpr sees all 15 address lines of the single port RAM connected, and assumes that all 15 are needed. That forces use of the deepest (32k word) RAM mode in the architecture file, and that mode can only support a data width of 1. So two RAM blocks are used. Here's the mode that gets used:

<mode name="mem_32768x1_sp">
  <pb_type name="mem_32768x1_sp" num_pb="1" blif_model=".subckt single_port_ram" class="memory">
  <input name="addr" num_pins="15" port_class="address"/>
  <input name="data" num_pins="1" port_class="data_in"/>
  <input name="we" num_pins="1" port_class="write_en"/>
  <output name="out" num_pins="1" port_class="data_out"/>

<clock name="clk" num_pins="1" port_class="clock"/>

Two possible fixes:

1. Make yosys connect the unused address pins to a special "unconn" signal like odin-ii does.
2. or, make vpr's netlist sweepers remove gnd inputs to RAMs, or make the RAM packer understand they don't count when figuring out the mode of a RAM.

If 1 is doable, it is probably simpler; would you know how to do #1?

[sdamghan]

Thanks @sdamghan . I took a look, and the yosys design connects an additional 7 address lines to LUTs (.names) that output gnd, while odin-ii leaves them unconnected. vpr sees all 15 address lines of the single port RAM connected, and assumes that all 15 are needed. That forces use of the deepest (32k word) RAM mode in the architecture file, and that mode can only support a data width of 1. So two RAM blocks are used. Here's the mode that gets used:

<mode name="mem_32768x1_sp">
  <pb_type name="mem_32768x1_sp" num_pb="1" blif_model=".subckt single_port_ram" class="memory">
  <input name="addr" num_pins="15" port_class="address"/>
  <input name="data" num_pins="1" port_class="data_in"/>
  <input name="we" num_pins="1" port_class="write_en"/>
  <output name="out" num_pins="1" port_class="data_out"/>

<clock name="clk" num_pins="1" port_class="clock"/>

Two possible fixes:

1. Make yosys connect the unused address pins to a special "unconn" signal like odin-ii does.
2. or, make vpr's netlist sweepers remove gnd inputs to RAMs, or make the RAM packer understand they don't count when figuring out the mode of a RAM.

If 1 is doable, it is probably simpler; would you know how to do #1?

I appreciated it @vaughnbetz , I didn't know unused address signals with gnd value could make such a difference versus the unconn value. The first option has a simple solution and again thanks it worked :) I will tide up the code and push this change in a new commit.

[vaughnbetz]

Great, thanks.

[sdamghan]

@QuantamHD would you please add a Kokoro runner for the VtR Yosys test? [presubmit] [continous]

[vaughnbetz]

@sdamghan : I think you've addressed my comments except adding a README or some other documentation explaining where yosyslib came from -- I assume it is copied from somewhere, so explaining where it came from (and why it is copied instead of referenced, and if anyone would ever want to update it from the original source and how) would be good.

[vaughnbetz]

Thanks for the README -- it is very clear!

[sdamghan]

Thanks for the README -- it is very clear!

@vaughnbetz thank you. I believe once a new Kokoro runner is allocated for the VtR_Yosys CI test the PR is ready to merge.

[vaughnbetz]

Is @mithro or someone else allocating that kokoro runner already? If not, good to ping someone or file an issue.

[mithro]

@sdamghan - Please create a GitHub issue and assign it to @QuantamHD to complete.