myhdl-list

[myhdl-list] func.verilog_code

[Christopher F. <chr...@gm...>]

I am wondering if I ran into an issue using the
.verilog_code and .verilog_instance function attributes?
When I use either of these attributes all the ports
are treated as inputs.  I have observed this with 0.8dev
(some print modifications) as well as 0.7.

A little background information.  In the past I have
had a small "top-level" written in Verilog.  I wanted
to try a complete MyHDL/Python design.  But this meant
wrapping calls to FPGA primitives such as PLL/DCMs.

The problem is that the outputs from the verilog_code
(or verilog_instance) modules don't appear to be driven (
because they were all treated as inputs).  It works
beautifully except this issue.  Because the outputs
don't appear to be driven the nets are assigned to the
default (drive by constant, default value).  I am using
the verilog_instance attribute to automatically create
the instantiation code but I also tried the verilog_code
attribute.

Example:

     def dcm12MHz(CLKIN_IN, RST_IN, CLKDV_OUT, CLKIN_IBUFG_OUT,
                  CLK0_OUT, CLKFX_OUT, LOCKED_OUT):

         @always(delay(2))
         def hdl_clkfx():
             CLKFX_OUT.next = not CLKFX_OUT

         @always(delay(4))
         def hdl_clk0():
             CLK0_OUT.next = not CLK0_OUT
             CLKIN_IBUFG_OUT.next = not CLKIN_IBUFG_OUT

         @always(delay(16))
         def hdl_clkdv():
             CLKDV_OUT.next = not CLKDV_OUT

         @always_comb
         def hdl_touch_inputs():
             LOCKED_OUT.next = True | CLKIN_IN | RST_IN;

         return hdl_clkfx, hdl_clk0, hdl_clkdv, hdl_touch_inputs

     dcm12MHz.verilog_instance = "ICLK"

Complete example here : http://bit.ly/OooWcl

When the converter is run all the ports are treated as
inputs.  Because the outputs are determined not driven
assigns to the defaults are created.  Currently I work
around this by modifying the generated Verilog.

I have not dug into this issue other than observing the
output, if anyone has insight, comments, or tips I
appreciated it.  I feel like I am missing/forgetting
something basic?

Regards,
Chris

Re: [myhdl-list] func.verilog_code

[Wesley N. <we...@sk...>]

Are you forgetting:

<output>.driven = "wire"

Regards

Wes

On Tue, Aug 28, 2012 at 5:29 AM, Christopher Felton
<chr...@gm...>wrote:

> I am wondering if I ran into an issue using the
> .verilog_code and .verilog_instance function attributes?
> When I use either of these attributes all the ports
> are treated as inputs.  I have observed this with 0.8dev
> (some print modifications) as well as 0.7.
>
> A little background information.  In the past I have
> had a small "top-level" written in Verilog.  I wanted
> to try a complete MyHDL/Python design.  But this meant
> wrapping calls to FPGA primitives such as PLL/DCMs.
>
> The problem is that the outputs from the verilog_code
> (or verilog_instance) modules don't appear to be driven (
> because they were all treated as inputs).  It works
> beautifully except this issue.  Because the outputs
> don't appear to be driven the nets are assigned to the
> default (drive by constant, default value).  I am using
> the verilog_instance attribute to automatically create
> the instantiation code but I also tried the verilog_code
> attribute.
>
> Example:
>
>      def dcm12MHz(CLKIN_IN, RST_IN, CLKDV_OUT, CLKIN_IBUFG_OUT,
>                   CLK0_OUT, CLKFX_OUT, LOCKED_OUT):
>
>          @always(delay(2))
>          def hdl_clkfx():
>              CLKFX_OUT.next = not CLKFX_OUT
>
>          @always(delay(4))
>          def hdl_clk0():
>              CLK0_OUT.next = not CLK0_OUT
>              CLKIN_IBUFG_OUT.next = not CLKIN_IBUFG_OUT
>
>          @always(delay(16))
>          def hdl_clkdv():
>              CLKDV_OUT.next = not CLKDV_OUT
>
>          @always_comb
>          def hdl_touch_inputs():
>              LOCKED_OUT.next = True | CLKIN_IN | RST_IN;
>
>          return hdl_clkfx, hdl_clk0, hdl_clkdv, hdl_touch_inputs
>
>      dcm12MHz.verilog_instance = "ICLK"
>
> Complete example here : http://bit.ly/OooWcl
>
> When the converter is run all the ports are treated as
> inputs.  Because the outputs are determined not driven
> assigns to the defaults are created.  Currently I work
> around this by modifying the generated Verilog.
>
> I have not dug into this issue other than observing the
> output, if anyone has insight, comments, or tips I
> appreciated it.  I feel like I am missing/forgetting
> something basic?
>
> Regards,
> Chris
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] func.verilog_code

[Christopher F. <chr...@gm...>]

On 8/28/12 1:00 AM, Wesley New wrote:
> Are you forgetting:
>
> <output>.driven = "wire"
>
> Regards
>
> Wes

Perfect, thanks I knew it was something basic I was forgetting.

Regards,
Chris

Re: [myhdl-list] func.verilog_code

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

On 08/28/2012 05:29 AM, Christopher Felton wrote:
> I am wondering if I ran into an issue using the
> .verilog_code and .verilog_instance function attributes?
> When I use either of these attributes all the ports
> are treated as inputs.  I have observed this with 0.8dev
> (some print modifications) as well as 0.7.

Some issues:

To infer signal direction from user-defined code properly, the
convertor needs some help:

http://www.myhdl.org/doc/current/manual/conversion.html#user-defined-code

This is required because the convertor skips any code
marked as user-defined.

Second, the .verilog_instance is not documented - I
vaguely remember that there were some issues that I
had to revisit but I haven't done that yet. If you
think it's useful and if can be turned into a robust
feature we can revisit it.


>
> A little background information.  In the past I have
> had a small "top-level" written in Verilog.  I wanted
> to try a complete MyHDL/Python design.  But this meant
> wrapping calls to FPGA primitives such as PLL/DCMs.
>
> The problem is that the outputs from the verilog_code
> (or verilog_instance) modules don't appear to be driven (
> because they were all treated as inputs).  It works
> beautifully except this issue.  Because the outputs
> don't appear to be driven the nets are assigned to the
> default (drive by constant, default value).  I am using
> the verilog_instance attribute to automatically create
> the instantiation code but I also tried the verilog_code
> attribute.
>
> Example:
>
>       def dcm12MHz(CLKIN_IN, RST_IN, CLKDV_OUT, CLKIN_IBUFG_OUT,
>                    CLK0_OUT, CLKFX_OUT, LOCKED_OUT):
>
>           @always(delay(2))
>           def hdl_clkfx():
>               CLKFX_OUT.next = not CLKFX_OUT
>
>           @always(delay(4))
>           def hdl_clk0():
>               CLK0_OUT.next = not CLK0_OUT
>               CLKIN_IBUFG_OUT.next = not CLKIN_IBUFG_OUT
>
>           @always(delay(16))
>           def hdl_clkdv():
>               CLKDV_OUT.next = not CLKDV_OUT
>
>           @always_comb
>           def hdl_touch_inputs():
>               LOCKED_OUT.next = True | CLKIN_IN | RST_IN;
>
>           return hdl_clkfx, hdl_clk0, hdl_clkdv, hdl_touch_inputs
>
>       dcm12MHz.verilog_instance = "ICLK"
>
> Complete example here : http://bit.ly/OooWcl
>
> When the converter is run all the ports are treated as
> inputs.  Because the outputs are determined not driven
> assigns to the defaults are created.  Currently I work
> around this by modifying the generated Verilog.
>
> I have not dug into this issue other than observing the
> output, if anyone has insight, comments, or tips I
> appreciated it.  I feel like I am missing/forgetting
> something basic?
>
> Regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com

Re: [myhdl-list] func.verilog_code

[Christopher F. <chr...@gm...>]

On 8/28/12 4:17 AM, Jan Decaluwe wrote:
> On 08/28/2012 05:29 AM, Christopher Felton wrote:
>> I am wondering if I ran into an issue using the
>> .verilog_code and .verilog_instance function attributes?
>> When I use either of these attributes all the ports
>> are treated as inputs.  I have observed this with 0.8dev
>> (some print modifications) as well as 0.7.
>
> Some issues:
>
> To infer signal direction from user-defined code properly, the
> convertor needs some help:
>
> http://www.myhdl.org/doc/current/manual/conversion.html#user-defined-code
>
> This is required because the convertor skips any code
> marked as user-defined.
>
> Second, the .verilog_instance is not documented - I
> vaguely remember that there were some issues that I
> had to revisit but I haven't done that yet. If you
> think it's useful and if can be turned into a robust
> feature we can revisit it.
>
>
<snip>

I realized it was undocumented but you had sent a detailed post to the 
newgroup indicating how you had used the .vhdl_instance or 
.verilog_instance to stitch together a bunch of MyHDL modules.  I 
thought I would give it a go.

Yes, I think it is a very useful feature.  In my case it is redundant to 
rewrite the actual verilog/vhdl code since it is only instantiating an 
FPGA IP.  I found it less error prone to use the .*_instance vs. *_code 
when simply instantiating (black box) other modules.

Regards,
Chris