The most closest feature to it, is if you use labels instead wires (labels in and out)

Hi @olofk, you can convert wire into a bus using the Verilog vector notation in the block port (e.g. bus[7:0]). This can be used to group wires, but only input or output, not mixed in the same bus.

I believe that this issue is precisely to request better/complete support; i.e. not to be constrained to input/outputs or to a single wire/signal. In the context of Wishbone and AXI, mentioned by @olofk, each bundle would/might be a struct/object/record composed of multiple signals (each with a different bit-size). @cavearr, do labels allow to (un)pack groups of signals?

Sorry for the delay, i'm on holidays this days!

this new feature is very interesting, labels has been the first aproximation to this approach, but not support mixing different kind of signals.

We are working on a new version of icestudio (now only in design and concepts) and this concept will be very usefull and interesting. In the current version will be complicated to implement it but for the new version i think this will a great enhance.

Thanks for all!

We are working on a new version of icestudio (now only in design and concepts) and this concept will be very usefull and interesting. In the current version will be complicated to implement it but for the new version i think this will a great enhance.

Does "new version" mean a bump (0.5.1 or 0.6.0)? Or do you mean an actual rewrite of the tool (from scratch)?

will be an actual rewrite of the tool. We have been learned a lot this years and we want to rethink the architecture completely.

But for this there is still time, we go slower than we would like :)

That sounds really interesting. Is there any public discussion about the requirements, frameworks and/or proposed architecture? IMHO, given the limited human resources, it would be interesting to allow the community to get involved and contribute from the foundation. That would hopefully help with not having black boxes that are difficult to maintain in the future.

Totally agree, in fact the idea is precisely to try to disconnect from libraries and frameworks that need a great maintenance effort, the idea will be to document the entire architecture very well from the beginning and create a simple workflow for the community, we have a long way ahead but I think it is a necessary step for the study to become a great tool.

Right now we are stabilizing the dev branch and we want to add a new feature of plugins, so that the community can create small functionalities while rethinking the new version and that these plugins are then reusable in the new architecture.

At the moment there is no open discussion, but there will be !

Right now we are stabilizing the dev branch and we want to add a new feature of plugins

I'm looking forward to that! I cloned the repository, but there seem to be many outdated dependencies and security issues. I tried to bring them up to date with partial success only.

Yes, for the moment icestudio is very outdated. When we publish a set of features than we want to try with the community (feedback from users has been very usefull ) , we start a new icestudio version with new architecture, until that moment we need to live in the caverns! :)

Hello! I am reorganizing the issues, trying to give more visibility and be able to better organize and prioritize the work and my roadmap (I will publish it very soon), I am converting some issues that are new feature requests as ideas on Github discussions.

Thanks for understanding.