Conversion between VHDL and Verilog and reverse not working

[rhinton]

I expect this ticket to be a site of discussion. I assume more specific issues will be created as appropriate as the discussion progresses.

Do you expect hdlConverter to be able to read a simple VHDL or Verilog file and write it back out in the other language? My conclusion is that it cannot do this.

I wrote a simple VHDL file and a simple Verilog file. Both have no complaints when parsing, but neither can be written back out in the other language. Here are my test files. They are very simple, so I was surprised to encounter problems.

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;

entity adder is 
  port (
    aa : in  signed;
    bb : in  signed;
    cc : out signed);
end entity adder

architecture behave of adder is
begin
  cc <= aa + bb;
end architecture behave;

Next is the Verilog file. Feel free to offer corrections if I messed something up.

module adder ( input [3:0]  aa,
               input [3:0]  bb,
               output [3:0] cc);
   assign cc = aa + bb;
endmodule // adder

I am attaching these files and my test (Python) files for convenience.

vhdl_to_verilog_ex.tar.gz

When I read the VHDL file and try to write it out in Verilog (exp004), I get a NotImplementedError for the HdlLibrary I just added. If I comment this out to simulate the previous behavior, I get a NotImplementedError for the HdlImport statement ('use' clause).

When I read in the Verilog and try to write it out as VHDL (exp003), I get a NotImplementedError for HdlBuiltinFn.PARAMETERIZATION when trying to write the type of port 'aa' in the port declaration.

Any suggestions on how to fix these problems? I have a good idea of what's going on in the VHDL -> Verilog case, but I'm not sure how you would like it approached.

[Nic30]

Do you expect hdlConverter to be able to read a simple VHDL or Verilog file and write it back out in the other language?

#103 (comment)

In general case no, it would require a typesystem interpretation translation of unsupported construct etc. However I am using some transformation functions which can translate most of SV to VHDL and VHDL to SV.

So the response is: yes but the explicit translation will be required.

Any suggestions on how to fix these problems?

I can push the WIP translation methods to a https://github.com/Nic30/hdlConvertor/tree/verilog_pp_line_directive if you want, otherwise I will finish it at the end of March (Conferences and other PhD/work related deadlines).

[rhinton]

To make sure I understand, I believe you're saying that the hdlObjects created by the Verilog and VHDL parsers represent a union of the concepts from these languages. The VHDL parser will produce some objects in the AST that don't have any corresponding concept in Verilog, and vice versa. So in order to convert from one to the other, a distinct translation phase/tool is required.

I like this approach. I just hadn't guessed that a project called "hdlConvertor" didn't yet support any conversion between HDLs. :-)

I hope to have some time on Friday (GMT-7) to investigate this project further. Here are some of my ideas. Any suggestions? What do you think is most important?

• Rework my solution for issue VHDL library statement not supported in Python #102 to create a real candidate merge request. I plan to do this first.
• If you push your WIP on the translator, I could test it, comment, propose changes or additions, etc.
• I could continue testing hdlConverter with my code and other code I'm aware of (e.g. https://github.com/philippefaes/vhdl2008-tester).
• I could write dedicated, detailed parser tests. (See discussion on pull request (REJECT THIS) First cut at HdlLibrary addition for VHDL library clause, issue #102. #103 .)

Any ideas I missed where you might want my help? (I don't know Verilog, so I won't be much help there. :-)

[Nic30]

If you can help me with tests for translator it would be a great help. However I do not have sufficient amount of time now. Currently the translator branch is derived from feature branch which is not fully implemented yet. This complicates the testing as some tests take ridiculous amount of time.
And also code itself is not perfect.

Based on this I would prefer if you can rather finish #102, 1-4 tests for library can be enough. I will try to deliver the fix for #90 #51 and the translator.

[rhinton]

Sounds great. I look forward to helping with the translator. (This is one of the main reasons I am helping. :-)