[myhdl-list] Re: Adoption / verilog parser/stub gen

[Jan D. <ja...@ja...>]

Ken Horn wrote:
> I've just read the stopwatch example, and it certainly seems like MyHDL
> can provide a productivity benefit for HDL development. I'd like to use
> it for a project or two I'm working on, however there is one main
> barrier to adoption for me.

Welcome!

> The projects are typically very modular, and even leaf nodes in the
> hierarchy need to call vendor modules (eg block rams, DSP slices). The
> current support for black box modules - as I understand it - means I
> need to create a stub python module for the verilog one, and then
> declare that certain signals are being driven by the block. This seems
> sane and reasonable. However, what would *really* drive adoption for me,
> would be to be able to point MyHDL at a directory of verilog modules and
> have it generate the stubs, including output drivers based on the output
> signals in the verilog code.

Let me see if I understand. A typical "stub" module would contain:
1) a string with a Verilog module instantiation assigned to __verilog__
2) the declarations of signals being driven
3) some MyHDL code for simulation purposes

I believe you are talking about automating 1) and 2) - I believe it's
clear that generating 3) from Verilog is unrealistic for the forseeable
future.

By making certain assumptions this could perhaps be done, but do you
really gain that much? After all, if you stay in Verilog, you have
to do 1) anyway somewhere, right? Moreover, I think that
(unfortunately) the biggest part of the work would be 3) - writing
an equivalent MyHDL model for simulation.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com