Re: [myhdl-list] Re: Some thoughts on toVerilog, toVHDL, etc.

[<dan...@we...>]

Hi Jan,

Jan Decaluwe wrote:
>> Now I was wondering when the 
>> netlist format is the key to that flexibility, whether MyHDL could 
>> take favor of developments already done in that area?
> 
> 
> I don't think so.
> 
> MyHDL directly converts from RTL/behavior to (perhaps somewhat lower
> level) RTL/behavior in the target language.
> 
> If toVerilog converted to netlist, it would be a synthesis tool.
> But that's a much bigger effort, and once in Verilog/VHDL, several
> decent synthesis tools are available. Moreover, despite appearances,
> toVerilog can also be used to convert non-synthesizable code, and that
> can be very useful also.
> 
> Alternatively, if toVerilog restricted the MyHDL input to a netlist-type 
> of format, the restrictions would be so high as to render the whole
> thing not very interesting.
> 

Thanks for you comment. I mixed things up. My idea was to have some HDL 
language independent interface that is documented. Then to build 
conversion tools to Verilog and VHDL starting from there. However, 
toVerilog is already implemented and the question is what such a 
interface would provide over the now used Abstract Syntax Tree way from 
Python.

My mix came in when I thought a netlist would be able to provide a way 
to define such an interface. I better take some time to study the 
Abstract Syntax Tree of Python to understand how to use it.

> Let me add that I fail to see the point of Confluence itself. It's
> one more attempt in a long tradition of non-procedural HDL languages.
> The reasoning is that as hardware is parallel, the HDL should *only*
> have parallel contructs too. In my opinion, this reasoning is flawed.
> The evidence of sucessful HDLs supports my views on this.
> 
> It is easy to claim, as Confluence does, that you need much fewer
> lines of code for a specific type of block, if you include it as a
> primitive in your language. The real point is that there are many
> kinds of useful hardware descriptions, including synthesizable ones,
> that need procedural constructs, and that therefore simply cannot be
> descibed elegantly in a non-procedural language like Confluence.
> 

Very well said!

Cheers,

Guenter