Enforce more consistent type naming #197
Conversation
There was a problem hiding this comment.
I see the need for this change: especially the resp_t type collides with types of the same name in many tools. (This is a bug in the respective tool; if the tool implemented type resolution correctly according to the System Verilog standard, there would be no collision. However, as we cannot expect all tool vendors to fix this bug in the foreseeable future, we have to do our best to not trigger it.)
However, I have two concerns:
- The types should be named according to the scheme we discussed in Harmonize ports and parameters #153.
- This change will break many usages of our modules. We therefore need to be careful about its rollout. We probably want to do one release where we make all the breaking changes agreed upon in Harmonize ports and parameters #153, so that users only have to adapt their code once. However, this will require more work.
What do you think?
|
I was unaware of #153, but aligning to this makes sense, thanks for pointing me in that direction. I agree that limiting the breaking changes to one release is the "cleanest" approach. I can convert this branch to a draft, and we could have this as a working branch for the changes, if that makes sense? |
Yes please! |
micprog
force-pushed
the
type_naming
branch
5 times, most recently
from
eaf3e9e
to
8e172ec
Compare
Unify type naming across modules, using `axi_req_t` for AXI request and `axi_lite_req_t` for axi lite request. May fix some issues for vivado (see HERO). Similar for `resp` types.
Unify type naming across modules, using
axi_req_tfor AXI request andaxi_lite_req_tfor axi lite request. May fix some issues for vivado (see HERO). Similar forresptypes.