Avoiding Odin's xml config file to be considered as arch file

[sdamghan]

Signed-off-by: Seyed Alireza Damghani [email protected]

Description

the following warnings are showing while dev/upgrade_vtr_archs.sh is called. Odin's XMLs are to read the configuration of each run. There is no need to go through the Odin directory looking for XML files.

Related Issue

Motivation and Context

removing warning generated by upgrade_vtr_arch.sh

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]

@sdamghan : I think you should add a comment in some appropriate place about why you use the .oxml extension though (so the flow scripts don't think this is an architecture file).

Is there any downside to renaming these files .oxml? E.g. can you open them with an xml viewer? Not a major concern for me if it doesn't bother you, but thought I'd ask in case there is an alternative way to get this warning to go away (e.g. make upgrade_vtr_archs.sh a bit smarter, having it avoid files that have _odin.xml in their name, or make the flow script calling it a bit smarter, etc.

[sdamghan]

@sdamghan : I think you should add a comment in some appropriate place about why you use the .oxml extension though (so the flow scripts don't think this is an architecture file).

Is there any downside to renaming these files .oxml? E.g. can you open them with an xml viewer? Not a major concern for me if it doesn't bother you, but thought I'd ask in case there is an alternative way to get this warning to go away (e.g. make upgrade_vtr_archs.sh a bit smarter, having it avoid files that have _odin.xml in their name, or make the flow script calling it a bit smarter, etc.

@vaughnbetz Odin's configuration file is actually an XML file. To remove the warnings related to Odin in upgrade_vtr_archs.sh, there are two approaches. First, we can specify not to read any XML files in the Odin directory (this is actually how we can make the flow script calling smarter). However, I think it is not a good approach since deciding about a specific behaviour using file names, not file extensions, may be confusing for users and future developers. Second, we can work on the extension of Odin's configuration file to avoid misinterpretation by the upgrade_vtr_archs.sh script. The extension .oxml is actually the same concept you mentioned about _odin.xml, and the point is that the configuration file is still an XML file, and it is read using an XML reader. I used OXML because it still shows this file is an XML file, in addition to making Odin's configuration files unique compared to regular architecture files. Only one point could be a downside for the OXML files: operating systems cannot recognize it as an XML file that I think is not a major concern. Please let me know your thoughts; once we agree on a solution, I will modify the documentation as well.

[vaughnbetz]

I actually think it is more clear if we keep the standard extension (.xml) so the format is obvious. That's usually what a filename extension means -- if it is a standard format, the extension says what it is. That lets OS'es figure out how to open it etc.

If we can just change upgrade_vtr_archs.sh to skip the odin-II files (since it doesn't need to upgrade them or know how to do it) I think that's best. Is simply removing OdinII from the directory list at https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/master/dev/upgrade_vtr_archs.sh doable?

If that's not doable, using ODIN-II config files that are something like _odin.xml would let us remove them with a filename matching rule in the upgrade_vtr_archs.sh script, which I think is also OK.

[vaughnbetz]

Thanks. This is a nice simple fix!
The CI failures are unrelated (due to CI refactoring).