VHDL exporter

[MarekPikula]

Hi, first of all thanks for the great work in all SystemRDL/PeakRDL projects. It's really impressive what has been accomplished here 👍
I'm currently looking into some automation tools to use for AXI slave generation from SystemRDL we currently extensively use in the company I work for. For some projects, we are required to write in VHDL, so the current SV exporter (although pretty darn nice by itself) doesn't really meet our needs. I have found https://github.com/MicroTCA-Tech-Lab/hectare project which looks sufficient for now, yet limited and seems to be abandoned over the last year. So here comes my question, whether there is a VHDL exporter in the pipeline for this project, or only SV variant development is planned?

Thanks again for the great work.

[amykyta3]

Thanks for the enthusiasm!
At this moment, I don't have any immediate plans to add support for a VHDL exporter. Ever since I switched to the "dark side" and started using SystemVerilog exclusively, VHDL has fallen out of favor in my projects.

That said, I agree that it would be valuable to have an option to generate VHDL. As far as I can tell, nearly all of the language concepts I use in the SystemVerilog exporter could technically be transcribed to VHDL, so it is certainly doable (with the exception of SV interface ports. We'll have to wait for VHDL 2019 to be more widely adopted in tools).
So in short, its not on my current roadmap, but I also don't want to rule it out, since it could make for an interesting enhancement in the future.

I'll keep this feature request open in case I feel inspired to add this 😄

[MarekPikula]

Just a quick update. It appears that hectare has many drawbacks and produces wrongly synthesisable code, but I've found a way better alternative (and a successor to hectare): https://gitlab.desy.de/fpgafw/tools/desyrdl.

It looks nice in terms of supported features and quality of generated code and most importantly is actively maintained. It also uses VHDL records, similar to this project, so the regfile interfacing works nicely. I recommend it to anyone looking for a VHDL generator.

Actually, I wonder if this issue could be closed as DesyRDL looks really good in terms of quality. What do you think @amykyta3?

[amykyta3]

Thanks for pointing me to this!
I have reached out to the DesyRDL folks and see if they are interested in having their tool be a plugin to the PeakRDL command line application I released recently.

I'll leave this issue open in case I decide to extend support to VHDL in the future.

[MarekPikula]

Sure, sounds good 👍

[Botnic]

Hi @amykyta3

Did you ever hear back from the DesyRDL folks?
I am also looking for VHDL support and checking out the DesyRDL project.

[darsor]

I've been working on a VHDL port of the SystemVerilog regblock exporter in a fork here. It's close to done. Remaining tasks tracked here.

Goals for VHDL conversion:

• Keep the structure and conventions of the code as much as possible, to allow merging back into upstream in the future if it makes sense.
• Use the same (SystemVerilog) unit tests with an auto-generated test adapter module
  • eliminate bugs introduced by trying to translate the unit tests
  • easier to keep up to date with upstream
• Support up to VHDL-2008
  • no 2019 constructs (like interfaces) due to lack of tool support

Eventually I'd like to either merge these changes back into this repo or host the VHDL exporter under the SystemRDL project. I've kept a running list of changes required due to the differences in language here. @amykyta3, what are your thoughts on trying to support both languages in this repo vs. keeping them separate?

[amykyta3]

Hey @darsor,
That's awesome that you were able to adapt the exporter to VHDL!
Regarding how to handle these changes, I can see this progressing in two different ways. I'm leaning towards keeping them separate, but would also like to hear your thoughts whether merging could be done in a way that is constructive and not destructive.
Below are my thoughts on the two options:

Merge into PeakRDL-regblock

This would be great, but I also want to avoid having peakrdl-regblock effectively become two separate tools in a trenchcoat. That would end up creating more complexity than simply keeping the tools as separate lineages. Merging the tools together should not be the goal in itself.
I would be open to merging, but only if it can be done in a way that the main program flow and code generation components can be unified, with an easy to understand language abstraction layer. As you've probably noticed in the current implementation, I have tried hard to keep concepts cleanly compartmentalized into smaller bite-sized conceptual modules so that the tool complexity doesn't become too overwhelming. I wonder if there could be a nice way to create a nice language abstraction layer so that the VHDL/Verilog split doesn't muddy up the entire tool.

This may be a tall order.. If it ends up hindering readability of the tool, or makes the user-experience worse or more confusing, then this wouldn't make sense. I want to be very careful to not add excessive complexity that would make maintenance and feature additions more difficult.

Keep as a separate VHDL fork

This would certainly be the easiest option. If the first option becomes too much of an inherent complexity to manage, this may be the more maintainable option as well. This would inherently let the two code generators specialize in their own language-specific concepts which would generally be a good thing for maintenance and long-term feature growth. Of course there is the risk that they would diverge over time, but that may not be as strong of a design-goal in the end. After all, the PeakRDL community is really good at letting me know what features are broken/missing 😄