Fix user guide

[arturum1]

• Generate 'VERSION' conf as macro instead of constant.
• Don't include core's constants ('C') and derived parameters ('D') in user guide.
• Remove 'Table of' string from table descriptions.
• Update 'interfaces.py' to try evaluating width math expressions - avoids strings like '32/8'.
• Update 'interfaces.py' add support for STRB_W configuration parameter - allows user to pass custom values, like '4' instead of using the default '32/8'.

[Copilot]

Pull request overview

This PR improves the user guide documentation by making several targeted fixes: changing VERSION from a constant to a macro, removing unnecessary "Table of" prefixes from LaTeX table captions, excluding internal constants and derived parameters from the user guide, and evaluating width expressions to display concrete values instead of raw math strings.

Changes:

• Changed VERSION configuration type from constant ('C') to macro ('M')
• Added try_evaluate() function to evaluate mathematical expressions in width parameters
• Removed documentation sections for constants ('C') and derived parameters ('D')
• Updated table captions to remove redundant "Table of" prefixes

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
py2hwsw/scripts/iob_core.py	Changes VERSION type from 'C' to 'M' to generate as macro
py2hwsw/scripts/iob_base.py	Adds try_evaluate() utility function for safe math expression evaluation
py2hwsw/scripts/interfaces.py	Updates width parameters to use try_evaluate() for computed values
py2hwsw/scripts/config_gen.py	Removes sections documenting constants and derived parameters
py2hwsw/scripts/block_gen.py	Simplifies subblocks table caption
py2hwsw/py2hwsw_document/document/tsrc/standard_interfaces.tex	Removes "Table of" from attributes table caption
py2hwsw/py2hwsw_document/document/tsrc/core_lib.tex	Removes "Table of" from core library table caption
py2hwsw/lib/iob_system/submodules/iob_eth	Updates submodule commit reference
py2hwsw/lib/iob_system/submodules/iob_cache	Updates submodule commit reference
py2hwsw/lib/iob_system/iob_system_linux/submodules/iob_uart16550	Updates submodule commit reference
py2hwsw/lib/hardware/memories/iob_memwrapper/iob_memwrapper.py	Simplifies memories table caption

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jjts]

Evaluating constants is messy. Either the user enters 4 explicitly, or enters the expression for python to calculate it immediately. It should never be a py2 job.

[arturum1]

Evaluating constants is messy. Either the user enters 4 explicitly, or enters the expression for python to calculate it immediately. It should never be a py2 job.

Normally, the user just specifies which interface he wants py2 to generate, and gives it a value for the address and data widths.
For example:

        {
            "name": "uart_s",
            "descr": "Uart csrs interface",
            "signals": {
                "type": "iob",
                "ADDR_W": 3,
                "DATA_W": 32,
            },
        },

Py2hwsw then uses the given data_w value to automatically generate and calculate the wstrb signal width (data_w/8).
https://github.com/IObundle/py2hwsw/pull/422/files#diff-4181be170848482b7baeced461b244e4f904026313f56b41de968f2a947e4cebR632

Currently, the py2hwsw script that generates interfaces, does not allow the user to specify the "WSTRB_W" directly. So, it is always automatically calculated based on the given data_w.
Should we change this to allow (or even enforce?) the user to directly specify the wstrb_w like so?

        {
            "name": "uart_s",
            "descr": "Uart csrs interface",
            "signals": {
                "type": "iob",
                "ADDR_W": 3,
                "DATA_W": 32,
                "WSTRB_W": 4,  # Should this value (always) be passed by the user?
            },
        },

[jjts]

yes, value or expression should be entered by the user , not by py2

[jjts]

I suggest saying something like this:

There may be other macros or generic parameters in the code that are not documented. They are typically derived from other primary macros or parameters or exist for documentation purposes.