Feature request: port groups

[amb5l]

My application needs an object hierarchy to represent VHDL design units and their contents. I want to capture port grouping information - where sets of port clauses have empty lines and/or comments between them - so I have created a fork of pyVHDLModel with support for port groups. It is backward compatible with the standard (flat) way of accessing port information.

Would it make any sense to make a PR to allow port groups to be considered here?

[Paebbels]

Thanks for reaching out @amb5l.

Can you share a link to your fork and branch and point me to the modifications you applied. I would like to see how it fits into the pyVHDLModel or what would be needed as adjustments to fit with the project goals.

In general I'm open to such contributions, especially as pyVHDLModel is made to be used in investigation and documentation tools like Sphinx. Thus grouping ports by name, prefix, direction, separation (empty lines) or comments is a goal.

I haven't yet thought about an extension to the pyVHDLModel, because it's currently close to the VHDL language itself.

I could imaging to have a "view" per entity, which groups ports (and/or generics).

---

How did you find the separation between ports?
By GHDL's documentation preservation feature?

[amb5l]

Can you share a link to your fork and branch and point me to the modifications you applied. I would like to see how it fits into the pyVHDLModel or what would be needed as adjustments to fit with the project goals.

The development repository is here. PyHDLio is a package comprising a parser and using a fork of pyVHDLModel. The parser is inspired by pyVHDLParser and uses your grammar, but is much simpler.

I am writing a diagramming application and want to

• create VHDL or Verilog code from block diagrams
• create diagram elements (blocks) from VHDL entity/component or Verilog module declarations

Detecting port groups in the source and handing the grouping information over through the API will make the diagramming app better.

In general I'm open to such contributions, especially as pyVHDLModel is made to be used in investigation and documentation tools like Sphinx. Thus grouping ports by name, prefix, direction, separation (empty lines) or comments is a goal.

I haven't yet thought about an extension to the pyVHDLModel, because it's currently close to the VHDL language itself.

I could imaging to have a "view" per entity, which groups ports (and/or generics).

How did you find the separation between ports? By GHDL's documentation preservation feature?

See the visitPortClause method of my VHDLVisitor class.

[Paebbels]

I checked your addition. It looks quite nice. I think there are just a few modification needed to accept it upstream.

I see you modifications are on the main branch. I suggest to rename you branch to e.g. amb5l/main as a so-called modification branch. This allows you to create a pull-request and later update your main with the merged result.

Please create the PR against branch dev.

Having a PR allows me to fully check all modifications line-by-line and give you a line-by-line feedback + code suggestions.

[Paebbels]

I see the parser is based on ANTLR4. Have you noticed that this implementation is awfully slow? That's why I aborted working on ANTLR4. Please note, ANTLR4 doesn't create a FSM for parsing a language, it learns and trains it's statistical models on the fly creating a huge overhead.

It's still in discussion to try out ANTRL3, which doesn't do creepy predictions like ANTLR4.

/cc @skoehler

[amb5l]

I checked your addition. It looks quite nice. I think there are just a few modification needed to accept it upstream.

I see you modifications are on the main branch. I suggest to rename you branch to e.g. amb5l/main as a so-called modification branch. This allows you to create a pull-request and later update your main with the merged result.

Please create the PR against branch dev.

Having a PR allows me to fully check all modifications line-by-line and give you a line-by-line feedback + code suggestions.

Understood. I will work on this and come back to you.

[amb5l]

I see the parser is based on ANTLR4. Have you noticed that this implementation is awfully slow? That's why I aborted working on ANTLR4. Please note, ANTLR4 doesn't create a FSM for parsing a language, it learns and trains it's statistical models on the fly creating a huge overhead.

It's still in discussion to try out ANTRL3, which doesn't do creepy predictions like ANTLR4.

/cc @skoehler

Thanks for this insight - very interesting. I have no experience in working with parsers and would never have known.

I have not noticed a performance issue but have only been parsing small test sources. My diagramming app only needs to read entity and component declarations (to create blocks) so I may not have performance problems. Creating a complete diagram from source (code to graphics) is - currently - outside the scope of my project.

I will look at ANTLR3.