Re: [myhdl-list] Re: inference problem?

[Haitao Z. <ha...@gm...>]

Thanks for the explaination. There seems to be a little more to it:
toVerilog does not always flag different  port name and signal name as
a problem (e.g. the q signal for the q3 port was fine). It actually
seemed content to let most pass but somehow caught on to the
particular example I gave. Even though the signals are defined in a
single statement (therefore positional wise identical). Moving the
function def around also does not make a difference.

I agree with Dave in the subsequent email that one should use port
names (as it currently seems to do correctly most of the times) for 
Verilog generation.

Haitao

On Wed, 02 Mar 2005 11:48:44 +0100, Jan Decaluwe <ja...@ja...> wrote:
> Haitao Zhang wrote:
> > More challenge if you are still there:). This time I did simulate (but
> > I haven't stepped throuigh toVerilog failure yet). The code simulates
> > (here q2 has been defined globally):
> >
> > def reg_dq3(clk,d0,q3):
> >     reg1=reg_dq2(clk,d0,q2)
> >     reg2=reg_dq(clk,q2,q3)
> >     return reg1,reg2
> >
> > If I do toVerilog like this:
> > my_delay2=toVerilog(reg_dq3, clk, d0, q)
> >
> > it works. But if I change it to:
> > my_delay2=toVerilog(reg_dq3, clk, cntr_out, q)
> >
> > toVerilog complains about shadowing. What is shadowing?
> 
> Shadowing refers to the following situation:
> 
> def top(a, b, c, ...):
>    a = Signal(...)
>    ...
> 
> In other words, an internal Signal "shadows" a port with the
> a same name. This is perfectly valid (though meaningless) in
> Python, but cannot be converted into meaningful Verilog. MyHDL
> attempts to detect this, and raises a error.
> 
> What you describe is something else:
> 
> a1 = Signal(a, b, c, ...):
> 
> def top(a, b, c):
>     ...
> 
> instance = toVerilog(top, a1, b, c, ...)
> 
> In other words, you use a different name for the Signal
> than for the port at instantiation time. This is perfectly
> valid Python and MyHDL, and could be converted into
> meaningful Verilog. However, the current port name test
> is too severe and detects this situation also, apart
> from the real "shadowing" case.
> 
> Conclusion: in any case, the current error is misleading
> for the situation you encounter. This has to be solved.
> There are 3 options, and I ask for feedback:
> 
> - top level signal names should be the same as their
> corresponding top level port names (as currently), and
> a clear error should be raised in the other case.
> - in the generated Verilog, the MyHDL port names should be
> used.
> - in the generated Verilog, the actual MyHDL signal names
> should be used. In this case, the Verilog module interface
> will use different port names than the MyHDL function.
> 
> Jan
> 
> --
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Using Python as a hardware description language:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>