Update Documentation with recent changes for Yosys Plugins

[sdamghan]

Description

This PR includes:

• updating the Odin-II documentation for recent changes in its input HDL argument
• updating the Yosys+Odin-II documentation for recent changes related to SystemVerilog and UHDM plugins
• updating the run_vtr_flow documentation for recent changes to all of the VTR front-ends
• updating the Yosys documentation for recent changes related to SystemVerilog and UHDM plugins

Related Issue

#2068
#2086
#2110

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

[sdamghan]

@vaughnbetz - This PR is ready for your review. It would be great to know your comments.

[vaughnbetz]

Looks good; some typos and clarifications (e.g. what is UHDM?) requested.

There's a comment that vpr can only handle positive-edge triggered registers; asking @kmurray if that's true since I thought Tatum handled negative-edge triggered registers.

[vaughnbetz]

Seems like we should explain what a UHDM file is and how it was created (run an earlier Surelog command?). Can be brief and include a link to the UHDM documentation, but should give some idea I think.

[sdamghan]

@vaughnbetz - I have applied some changes to address your reviews. Kindly, let me know if you want additional modifications.

[vaughnbetz]

Thanks Seyed.

[vaughnbetz]

I think it looks good and am going to merge it. I have one last thing to consider for a follow-up PR though.
Thanks for adding the UHDM definition. From an end-user perspective though, they will specify a .sv file as input even when using surelog, not a UHDM file, right? If so I think that should be made clear in the UHDM format description you've added; we use UHDM to mean this alternative flow, but the input file is still systemverilog (or perhaps can be either .sv or .v).

[sdamghan]

Thanks @vaughnbetz - that absolutely makes sense. I will investigate more about the file extensions and will add more info to the documentation. Meanwhile, I noticed that Surelog or even Yosys plugins do not check the file extension; they only read whatever is inside the file using the user-specified parser. For instance, you can have a file with .v extension while it contains a SystemVerilog HDL, and based on what the user specified as the parser, Yosys performs the synthesis for the given HDL.
With the recent change I made, our approach would be similar to Surelog or Yosys, i.e., whatever the VTR flow receives, regardless of its extension, will be passed to the front-ends and based on the -parser value that is specified by the user, the front-end performs parsing and synthesis.
Overall, the VTR flow script does not accept any format other than what specified below for Yosys:

vtr-verilog-to-routing/vtr_flow/scripts/python_libs/vtr/yosys/yosys.py

Lines 11 to 21 in 6eb8a0a

	FILE_TYPES = {
	".v": "Verilog",
	".vh": "Verilog",
	".sv": "SystemVerilog",
	".svh": "SystemVerilog",
	".blif": "BLIF",
	".aig": "aiger",
	".json": "JSON",
	".lib": "Liberty",
	".ys": "RTLIL",
	}

Overall, the VTR flow does not check the file extension for deciding about the parser, the same as Surelog and Yosys. That means, the file extension is unimportant; however, the parser value is. If you would like, I can add to the documentation that files that include UHDM descriptions can have both .v and .sv extensions; though, considering the synthesizers' approach, they can have any extension.

[vaughnbetz]

Thanks Seyed. You could just say "typically .v or .sv files". Basically right now the documentation makes it sounds like UHDM is a file type (some .uhdm extension or some such) and it really isn't -- it's a parser flow. Clarifying that would be good.