Upgrade the Yosys+Odin-II Front-end

[sdamghan]

Description

In this PR, the Yosys script for the Yosys+Odin-II is updated to perform the synthesis for basic operations by Yosys. Then Yosys generates the BLIF file with unmapped and coarse-grained memories, arithmetic operations, simple DFF types with set/reset, and latches so that the Odin-II partial mapper will take care of them.

Related Issue

Motivation and Context

Fixing issues raised by the Koios 2.0 development team

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

[sdamghan]

@aman26kbm - this branch improves the Yosys+Odin-II front-end and should address some of the issues we discussed for Koios 2.0. Would you please give it a run and let me know your thoughts on the results?

[aman26kbm]

Sure, lemme try it out.

[sdamghan]

Thanks @aman26kbm - JFYI, no worries about the last commits as they only include updates in expected results.

[aman26kbm]

Hi Seyed, this PR seems to have some issue.

I ran these designs:

attention_layer
clstm_like.small
conv_layer
dla_like.small
eltwise_layer
lstm
robot_rl
softmax
spmv
stereovision2
tiny_darknet_like.small

I ran them in 4 modes:

1. Odin-only, with automatic inference of dsps and brams (i call this "soft")
2. Yosys+ODIN, with automatic inference of dsps and brams
3. Odin-only, with hard instantiations of dsps and brams (i call this "hard")
4. Yosys+ODIN, with hard instantiations of dsps and brams

The results are tabulated in this spreadsheet: https://utexas.sharepoint.com/:x:/s/LCATeam3-VTR-ML-Benchmarks/EWQwBjnUJLxPjnq5QqTwP-wB50gk4hfGXz9YwkroBCB4lg?e=LtxlGI
See tabs: odin_vs_yosodin_aug29_hard and odin_vs_yosodin_aug29_soft

In most of the Yosys+ODIN runs, you'll see the results are blank. That's because I see this error in the log files:

 87 /export/aman/vtr_aman/vtr-verilog-to-routing/ODIN_II/SRC/BlockMemories.cpp:1081: create_nrmw_dual_port_ram: Assertion num_rd_ports > 2 failed
 88   1079 |
 89   1080 |     /* should have been resovled before this function */
 90   1081 |     oassert(num_rd_ports > 2);
 91         ^~~~
 92   1082 |     oassert(num_wr_ports > 2);
 93   1083 |
 94 Command terminated by signal 6

In the "hard" runs, I see the error mentioned above only in 1 design - tiny_darknet_like.small.
But in the "soft" runs, I see the error mentioned above in 7 out of 11 designs.

Also, for the designs that do pass, I still see some differences because of packing (attention_layer, eltwise_layer, lstm, robot_rl, softmax).

[sdamghan]

Thanks @aman26kbm - let me go through it one more time. Meanwhile, can you provide me with the Koios++ scripts you use to run the VTR flow?

[aman26kbm]

Sure. The scripts are located here:
https://github.com/aman26kbm/vtr-verilog-to-routing/tree/master/vtr_flow/tasks/koios

There are scripts here for generating various folders for experiments, generating task configs, parsing results, etc. But don't worry about all that.

I name experiments as exp1a, exp1b, exp4c, etc. They correspond to the different experiments we conduct for the paper.
For example, exp1a is the normal run for all designs, but exp4c is the run with the "densest" architecture.

For the current case, the relevant folders that you need are:
exp1a_odin_hard
exp1a_odin_soft
exp1a_yosodin_hard
exp1a_yosodin_soft

You can go inside each folder and you'll see the run file. You'll see 3 commands pointing to 3 different task lists (see files called task_list_exp*). I have categorized the designs into 3 lists - short, normal, large - based on how long each design takes.

You can just execute the run file to run all designs, but you can delete some of the designs in the task lists and then execute the run file to run a few designs. (In the current case, I deleted all but the 11 designs I listed above)

[sdamghan]

Moving an email thread here:

Hi Aman,

Thanks for the results. I have outlined my results in the QoR_results sheet. I do see some minor inconsistency in the number of CLBs, however, I am not sure where are they coming from.

Based on my observations, the new upgrade works better than the previous version as we survive the SPMV benchmark in terms of num of DSPs and Memories. Also, if you look at the DSP column for the comparison tables, you would notice that overall, the new YosysOdin has results closer to Odin-II than the previous version. Concerning the number of memory blocks with hard blocks enabled, they are both equal except for the SPMV benchmarks, which are fixed and increased by the new updates to the synthesizer.

There are a lot of improvements within the new upgrade. However, we lost the tiny_darknet_benchmark as it failed in the ABC stage. I have not had the chance to run all koios++ benchmarks with the new synthesizer, but we can decide better when we see its behaviour for other benchmarks as well.

Regarding the new upgrade, I should say the synthesis load of basic logic (such as AND ,OR reduction) and FFs has transferred to Yosys (whatever the simplemap command is for in Yosys). Moreover, additional memory optimization passes are added to the Yosys synthesis script. This should provide more assurance about the connection as partially fine-grained synthesis is performed for these basic logics.

---

Hi Seyed,

Thanks for the detailed analysis. I also agree that the new results are much closer to ODIN. So, this upgrade certainly looks better. I will run all benchmarks with this new upgrade and tabulate the results.

Btw another thing came to my mind about the differences that are because of packing.. I think this is a non-issue because the Yosys+ODIN generated netlist is such that VPR is able to pack the blocks better. We can mention this in the paper. I wasn't thinking about it this way earlier.

Regarding the other benchmarks where the difference is not because of packing (clstm, dla and stereovision2), we had said that we will use the results from ODIN for these designs. We can do the same for tiny darknet. I think we have to decide and start writing the paper.

The QoR Comparison for all front-ends, including the comparison of the previous version of Yosys+Odin-II to the upgraded one, is in the following links.

Upgraded Yosys+Odin-II QoR comparisons for a small set of Koios2.0 benchmarks

Upgraded Yosys+Odin-II QoR comparisons for VTR benchmarks

[sdamghan]

@aman26kbm - Would you please share a short summary of the results and your thoughts here? If there is no more roadblock or issue, we can move forward and merge this PR.

[aman26kbm]

Here's the update from the runs from yesterday (only ran these 5 designs because these are the ones that have been giving us trouble lately):

Yosys+ODIN hard
Tiny darknet small -> Fail at abc stage
Lenet -> Fail at abc stage
Deepfreeze style1 -> ODIN crash
Deepfreeze style2 -> ODIN crash
Deepfreeze style3 -> ODIN crash

ODIN-only hard
Tiny darknet small -> Pass
Others fail, but that's expected. These designs have never passed ODIN-only flow, coz they have some SV syntax in them that's not supported by ODIN.

Yosys+ODIN soft
Tiny darknet small -> Fail at abc stage
Lenet -> Fail at abc stage
Deepfreeze style1 -> Pass
Deepfreeze style2 -> ODIN crash
Deepfreeze style3 -> Pass

ODIN-only soft
Tiny darknet small -> Pass
Others fail, but that's expected. These designs have never passed ODIN-only flow, coz they have some SV syntax in them that's not supported by ODIN.

[sdamghan]

We temporarily suspend this PR to provide appropriate solutions for the bugs mentioned above.

[sdamghan]

Hey @alirezazd and @poname , this PR is about upgrading the Yosys+Odin-II front-end by using more Yosys side by performing some simple mapping and postponing technology mapping of the memory hard blocks and DSPs to Odin-II partial mapper. So going forward, please keep @aman26kbm posted about your updates/enhancements, specifically about this PR.

[vaughnbetz]

CI is green and the code looks OK to me -- should this be merged at this point? @aman26kbm @sdamghan please let me know.

[aman26kbm]

These changes were leading to some degradation in results for some designs (in addition to the improvement in many designs). So, we decided to hold off merging this PR until they are debugged.