wip: Set version based on CORE_VERSION

[gastmaier]

PR Description

For historical reasons, we have been creating linux dt-bindings suffixed
with 1.00.a, because that was the default vivado set value, and what
would be outputted by
SDTGen.

Nowadays, vivado default is 1.0 and the auto-generated devicetrees never
really matched with the actual devicetree bindings.
To improve overall coherence between hdl and linux, I propose the
following:

• semantic versioning across the board,
• dt-bindings are suffixed by -<major>, and should match the filename
  and compatible
• Bus connected Ips should have the IP-XACT version set to
  . (I developed a method to autoset based on
  CORE_VERSION)
• Drivers should print the version reg as %u.%u.%u

New software:

• dt-bindings suffixed by -<major>
• driver print in format %u.%u.%u Old software:
• update drivers to print %u.%u.%u instead of %u.%u.%c

Existing software:

• Format patch version as decimal, without bumping, e.g. ‘a’ -> 61

HDL usage:
At each register capable IP _ip.tcl:
adi_ip_set_version_from_regmap "_regmap.v"

HDL progress:

• Standardized all IP version format to have a single regexp (or at least all that I could pattern match)
• Added methods for all vendors

HDL TODO:

• Use methods on all IPs that contain CORE_VERSION
• Update all touched files license headers :)

When can this be merged?

After #1831

FAQ

Why no minor or patch in dt-bindings?
dt-bindings don’t describe a specific driver, nor internal features, but
mostly how things are wired. If how things are wired changes, in a way
that the previous biding does work (e.g. port removal), this is a
breaking change, and the major must be bumped.

Why can’t we keep patches starting at ‘a’/61?
Common…

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)
• Documentation

PR Checklist

• I have followed the code style guidelines
• I have performed a self-review of changes
• I have compiled all hdl projects and libraries affected by this PR
• I have tested in hardware affected projects, at least on relevant boards
• I have commented my code, at least hard-to-understand parts
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe files, Copyright etc)
• I have not introduced new Warnings/Critical Warnings on compilation
• I have added new hdl testbenches or updated existing ones