myhdl-list Mailing List for MyHDL (Page 81)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I am curious if there are any thoughts on a 0.8 target
release date.  Are there *items* that are targeted for
0.8 but not yet implemented?

Regards,
Chris

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

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

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

A bug - I had only used VHDL conversion of this brand
new featur so far. I have solved this, it's in the
public repo's.

Worked very well in VHDL, so thanks for trying this
out in Verilog also.

On 08/28/2012 05:38 AM, Christopher Felton wrote:
>
> I apologize in advance to the lack of information
> but I was modifying some old code and decide to give
> the always_seq a whirl in the code.  I ran into a small
> issue.  If I have a description like the following,
> the generated Verilog does not have the correct /begin/ /end/.
>
> MyHDL description:
>
>     from myhdl import *
>
>      def p_edge(clock, reset, slow_sig, sig_posedge):
>          _delay = Signal(False)
>          @always_seq(clock.posedge, reset=reset)
>          def hdl_edge():
>              _delay.next = slow_sig
>              if not _delay and slow_sig:
>                  sig_posedge.next = True
>              else:
>                  sig_posedge.next = False
>
>          return hdl_edge
>
>      def convert():
>          clock = Signal(False)
>          reset = ResetSignal(True, active=0, async=True)
>          sig = Signal(False)
>          edge = Signal(False)
>          toVerilog(p_edge, clock, reset, sig, edge)
>
>      if __name__ == '__main__':
>          convert()
>
>
> Generated Verilog:
>
>      always @(posedge clock, negedge reset) begin: P_EDGE_HDL_EDGE
>          if (reset == 0) begin
>              sig_posedge <= 0;
>              _delay <= 0;
>          end
>          else
>              _delay <= slow_sig;
>              if (((!_delay) && slow_sig)) begin
>                  sig_posedge <= 1'b1;
>              end
>              else begin
>                  sig_posedge <= 1'b0;
>              end
>          end
>
>      endmodule
>
>
> 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

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
>

I apologize in advance to the lack of information
but I was modifying some old code and decide to give
the always_seq a whirl in the code.  I ran into a small
issue.  If I have a description like the following,
the generated Verilog does not have the correct /begin/ /end/.

MyHDL description:

    from myhdl import *

     def p_edge(clock, reset, slow_sig, sig_posedge):
         _delay = Signal(False)
         @always_seq(clock.posedge, reset=reset)
         def hdl_edge():
             _delay.next = slow_sig
             if not _delay and slow_sig:
                 sig_posedge.next = True
             else:
                 sig_posedge.next = False

         return hdl_edge

     def convert():
         clock = Signal(False)
         reset = ResetSignal(True, active=0, async=True)
         sig = Signal(False)
         edge = Signal(False)
         toVerilog(p_edge, clock, reset, sig, edge)

     if __name__ == '__main__':
         convert()

Generated Verilog:

     always @(posedge clock, negedge reset) begin: P_EDGE_HDL_EDGE
         if (reset == 0) begin
             sig_posedge <= 0;
             _delay <= 0;
         end
         else
             _delay <= slow_sig;
             if (((!_delay) && slow_sig)) begin
                 sig_posedge <= 1'b1;
             end
             else begin
                 sig_posedge <= 1'b0;
             end
         end

     endmodule

Regards,
Chris

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

On 8/10/12 9:27 AM, Jose Ignacio Villar wrote:
> Hi all,
> I'd like to know about the current status of MEP 107 or if there is
> someone working on it, since I could understand from some messages in
> the list that at least part of the work might be in progress.

Sorry for the late reply, I have been extremely busy and
will continue to be occupied for a couple months.  Best
of my knowledge, I have updated the MEP with the latest
comments and there are no major objections.  The MEP has
been proposed and informally accepted(?).  I believe, we
are ready to move forward with the implementation.  Other
than basic feasibility experiments I have not made
progress on the implementation.

It should be noted, while we were discussing the MEP it
was noted that "interfaces" can be implemented in version
0.7 but you have to locally reference the Signals in the 
interface/container.  The following is an example of
locally referencing the signals.

     def complex_mult(clock, reset, a, b, c):
         a_real,a_imag = a.real,a.imag
         b_real,b_imag = b.real,b.imag
         c_real,c_imag = c.real,c.imag

         @always_seq(clock.posedge, reset=rest)
         def hdl():
             c_real.next = (a_real*b_real) + -1*(a_imag*b_imag)
             c_imag.next = (a_imag*b_real) + (a_real*b_imag)

         return hdl

The full example available here : http://bit.ly/QpEm5j
I also have a larger example here : http://bit.ly/QMhDuP,
this example might not be of much use without some description?

When MEP 107 is implemented the above can be expressed as:

     def complex_mult(clock, reset, a, b, c):

         @always_seq(clock.posedge, reset=rest)
         def hdl():
             c.real.next = (a.real*b.real) + -1*(a.imag*b.imag)
             c.imag.next = (a.imag*b.real) + (a.real*b.imag)

         return hdl

If someone wants to use interfaces today, I don't think
the local references is (should be) a huge deterrent. Some
have indicated they prefer the local references.

Hope that helps,
Chris

On 08/11/2012 12:40 AM, Per Karlsson wrote:
> On Fri, Aug 10, 2012 at 11:06 PM, Jan Decaluwe <ja...@ja...
> <mailto:ja...@ja...>> wrote:
>
> On 08/10/2012 02:37 PM, Per Karlsson wrote:
>> Let's say I want to make a design that can realize chips with
>> between 0 and 64 PCI-Express interfaces. How can I write that
>> parametrized top module in MyHDL?
>
> That is not a problem at all.
>
> Once again, the only problem is conversion.
>
>
> Without conversion there won't be any ASICs! :)
>
> Let me ask a question in return: how would you deal with the
> parametrization in VHDL/Verilog?
>
>
> I would do it using a parametrized perl or python pre-processor
> capable of generating each of the needed configurations as static
> verilog.

Ok. Presumably, you would provide some way for the user
to specify a particular configuration, in particular:

1) the port names you want in VHDL/Verilog
2) the port order
3) the port types

In MyHDL, 1) and 2) are specified by the the top-level
function. 3) by the Signals you call it with.

The reason to do it like that is that it is conceptually
identical to what you always do when instantiating in
MyHDL: calling a function. However, it is true that this
particular function call is more restrictive than others,
because of the additional functionality listed above.

In a workflow, one could develop a fully parametrized
module, and only provide a top-level wrapper as late as
possible,as a way to configure a specific instance for
conversion.

Jan

-- 
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

On 08/10/2012 02:37 PM, Per Karlsson wrote:
> Hm, without kwargs in toVerilog I still don't see how I can make a
> parametrized design for conversion in pure MyHDL without a
> preprocessor that generates the MyHDL code for the toplevel (which in
> all fairness would be fine I guess).
>
> Let's say I want to make a design that can realize chips with between
> 0 and 64 PCI-Express interfaces. How can I write that parametrized
> top module in MyHDL? /Per
>
> ps. I haven't looked at the source code yet so I shouldn't venture
> into that discussion, but what is keeping us from looking into the
> kwarg dictionary for the port names?

One issue would be that a dictionary doesn't specify an
order, which is likely something that you want to control
when going to Verilog/VHDL.

-- 
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

On Fri, Aug 10, 2012 at 11:06 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 08/10/2012 02:37 PM, Per Karlsson wrote:
> > Let's say I want to make a design that can realize chips with between
> > 0 and 64 PCI-Express interfaces. How can I write that parametrized
> > top module in MyHDL?
>
> That is not a problem at all.
>
> Once again, the only problem is conversion.

Without conversion there won't be any ASICs! :)

> Let me ask a question in return: how would you deal with the
> parametrization in VHDL/Verilog?

I would do it using a parametrized perl or python pre-processor capable of
generating each of the needed configurations as static verilog.

However, I am sick of mixing languages---it's a mess!
MyHDL holds the promise of replacing System-C for system simulation, perl
for pre-processing, verilog/VHDL for leaf-design, and Modelsim/VCS for
module test, and thus give me the integrated design environment I crave!
Perhaps MyHDL 0.7 can do it, perhaps it cannot. This is what I'm trying to
figure out.
/Per

ps. Besides conversion the main thing I'm worried about is simulation speed
for system simulation. But I'm too in fascinated with being able to write
the system model and the synthesizable model in the same language and use
them interchangeably that I'm prepared to overlook that for now. I
guess I'll have to write a toSystemC function eventually... :)

Could you provide an example, as simple as possible, of
what you try to do?

It seems you suggest that attribute access outside a generator
(which works in conversion currently) doesn't work for you,
inside a generator it would. I don't understand that.

On 08/10/2012 04:27 PM, Jose Ignacio Villar wrote:
> Hi all, I'd like to know about the current status of MEP 107 or if
> there is someone working on it, since I could understand from some
> messages in the list that at least part of the work might be in
> progress.
>
> In the following paragraphs I'd like to show the source of my
> interest on this MEP: I'm currently developing a set of libraries
> upon MyHDL to perform System on Chip integration by using components
> hosted in public repositories in an easy way. My aim is to develop a
> tool able to make it easier the use and reuse of components under
> free licenses such as those found in Opencores in a very
> straightforward way. The idea is that the components will be hosted
> at on-line repositories, in a similar way to debian packages, wrapped
> with an XML description similar to IP-Xact, but simpler and more
> parameterizable. This way, the SoC description is performed in an
> object oriented/structural paradigm. Instances are objects created by
> simple calls to convenience functions like i.e.
> cpu=get_instance("openrisc"), and interconnection between components
> is performed through helper methods like
> comp1.get_wb().connect("wb_int", comp2.get_wb()). The the network of
> components and links can be converted or cosimulated. One of the key
> aspects of this structural paradigm is that you can model components
> as objects in a very parameterizable way, like in example a logic
> gate which a undefined number of inputs as the simplest case. Or
> components with an undefined number of Wishbone interfaces in a more
> complex case. I've already developed an XML description format
> similar to IP-Xact capable to describe components with this level of
> parameterizability and I have classed in Python to work with this
> descriptions and use components hosted in the remote repositories.
> Currently I'm working in the integration of all of this into MyHDL.
> My first take, assuming that this external components in the first
> stage will only be cosimulated or converted since there is no MyHDL
> models available was to create an abstract class called
> ExternalComponent. This class models and behaves as any possible
> external component using the information found in the XML
> description, to understand the structure of the component's
> interface, ports, set of files, parameters, etc. So depending on the
> content of the XML file, the objects will expose a particular
> interface. This point is where MEP107 plays a key role for me. The
> component's port list is unknown until a particular component is
> instances, so it is passed as **kwargs. So being able to dynamically
> add attributes to the each object instance, that can be used inside
> the generators could allow to also add a MyHDL simulatable model,
> since by now, neither object attributes nor kwargs accesses, can be
> used inside generators. Another solution would be binding kwargs
> accesses to variables outside generators, but is not possible in this
> case because the members of kwargs are unknown until a particular
> component is instanced. By now I've come over it using several hacks,
> in the first step I made some modifications to MyHDL core to be able
> to use kwargs inside generators, but I discarded it because it was
> not a  general solution and I wanted to use a MyHDL without
> modifications. In the second try I used a trick, assigning to
> locals()["varname"]=kwargs["varname"] I could dynamically bind kwargs
> to variables that could be used inside generators, but this trick is
> deprecated in Python 3.0. Finally, I found in MEP 107 to be a much
> more general solution capable to go over my problem and open a wide
> range of new modeling techniques.
>
> Jose.
>
> José Ignacio Villar <jo...@dt... <mailto:jo...@dt...>>
> Departamento de Tecnología Electrónica Escuela Técnica Superior de
> Ingeniería Informática Universidad de Sevilla Avda. Reina Mercedes,
> s/n 41012 - Sevilla (Spain)
>
> Tlf: 954 55 99 62 Fax: 954 55 27 64
>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
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

On 08/10/2012 02:37 PM, Per Karlsson wrote:
> Hm, without kwargs in toVerilog I still don't see how I can make a
> parametrized design for conversion in pure MyHDL without a
> preprocessor that generates the MyHDL code for the toplevel (which in
> all fairness would be fine I guess).
>
> Let's say I want to make a design that can realize chips with between
> 0 and 64 PCI-Express interfaces. How can I write that parametrized
> top module in MyHDL?

That is not a problem at all.

Once again, the only problem is conversion. Let me ask a question
in return: how would you deal with the parametrization in VHDL/Verilog?

> ps. I haven't looked at the source code yet so I shouldn't venture
> into that discussion, but what is keeping us from looking into the
> kwarg dictionary for the port names?

Could be done at first sight, but it might be strange to
support kwarg and not vararg.

-- 
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

Am 10.08.2012, 14:37 Uhr, schrieb Per Karlsson <bas...@gm...>:

> Hm,
> without kwargs in toVerilog I still don't see how I can make a  
> parametrized
> design for conversion in pure MyHDL without a preprocessor that generates
> the MyHDL code for the toplevel (which in all fairness would be fine I
> guess).

i did something like this to give a adjustable number of arguments to the  
toVHDL function, bilding up the string of the code
with the number of arguments i wannted and then exec it.

	for i in range(NumberArguments):
	    code="A"+str(i)+"= Signal(bool(0))"
	    exec(code)

	code="toVHDL(PicoBoard"
	for i in range(NumberArguments):
     		code=code+",A"+str(i)
	code=code+")"
	exec(code)

...hm probably not the best solution.

greetings norbo

Hi all,
I'd like to know about the current status of MEP 107 or if there is someone
working on it, since I could understand from some messages in the list that
at least part of the work might be in progress.

In the following paragraphs I'd like to show the source of my interest on
this MEP:
I'm currently developing a set of libraries upon MyHDL to perform System on
Chip integration by using components hosted in public repositories in an
easy way. My aim is to develop a tool able to make it easier the use and
reuse of components under free licenses such as those found in Opencores in
a very straightforward way. The idea is that the components will be hosted
at on-line repositories, in a similar way to debian packages, wrapped with
an XML description similar to IP-Xact, but simpler and more
parameterizable. This way, the SoC description is performed in an object
oriented/structural paradigm. Instances are objects created by simple calls
to convenience functions like i.e. cpu=get_instance("openrisc"), and
interconnection between components is performed through helper methods like
comp1.get_wb().connect("wb_int", comp2.get_wb()). The the network of
components and links can be converted or cosimulated.
One of the key aspects of this structural paradigm is that you can model
components as objects in a very parameterizable way, like in example a
logic gate which a undefined number of inputs as the simplest case. Or
components with an undefined number of Wishbone interfaces in a more
complex case. I've already developed an XML description format similar to
IP-Xact capable to describe components with this level of
parameterizability and I have classed in Python to work with this
descriptions and use components hosted in the remote repositories.
Currently I'm working in the integration of all of this into MyHDL.
My first take, assuming that this external components in the first stage
will only be cosimulated or converted since there is no MyHDL models
available was to create an abstract class called ExternalComponent. This
class models and behaves as any possible external component using the
information found in the XML description, to understand the structure of
the component's interface, ports, set of files, parameters, etc. So
depending on the content of the XML file, the objects will expose a
particular interface. This point is where MEP107 plays a key role for me.
The component's port list is unknown until a particular component is
instances, so it is passed as **kwargs. So being able to dynamically add
attributes to the each object instance, that can be used inside the
generators could allow to also add a MyHDL simulatable model, since by now,
neither object attributes nor kwargs accesses, can be used inside
generators. Another solution would be binding kwargs accesses to variables
outside generators, but is not possible in this case because the members of
kwargs are unknown until a particular component is instanced.
By now I've come over it using several hacks, in the first step I made some
modifications to MyHDL core to be able to use kwargs inside generators, but
I discarded it because it was not a  general solution and I wanted to use a
MyHDL without modifications. In the second try I used a trick, assigning to
locals()["varname"]=kwargs["varname"] I could dynamically bind kwargs to
variables that could be used inside generators, but this trick is
deprecated in Python 3.0. Finally, I found in MEP 107 to be a much more
general solution capable to go over my problem and open a wide range of new
modeling techniques.

Jose.

José Ignacio Villar <jo...@dt...>
Departamento de Tecnología Electrónica
Escuela Técnica Superior de Ingeniería Informática
Universidad de Sevilla
Avda. Reina Mercedes, s/n
41012 - Sevilla (Spain)

Tlf: 954 55 99 62
Fax: 954 55 27 64

Hm,
without kwargs in toVerilog I still don't see how I can make a parametrized
design for conversion in pure MyHDL without a preprocessor that generates
the MyHDL code for the toplevel (which in all fairness would be fine I
guess).

Let's say I want to make a design that can realize chips with between 0 and
64 PCI-Express interfaces. How can I write that parametrized top module in
MyHDL?
/Per

ps. I haven't looked at the source code yet so I shouldn't venture into
that discussion, but what is keeping us from looking into the kwarg
dictionary for the port names?

On Fri, Aug 10, 2012 at 1:12 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 08/09/2012 06:42 PM, Per Karlsson wrote:
> > Ah, I see! (And thanks for the explanation!)
> >
> > Well, if I cannot use classes as interfaces, and I cannot
> > automatically explode lists of ports at the top for conversion, then
> > I'll feel severely hampered.
>
> The top level function is special and restrictive in conversion,
> that is all.
>
> It uses the arg names as the spec of the port names in Verilog
> and VHDL. Where else should it get them, e.g. in case of varargs?
> But I concede there should be an error message that varargs and
> kwargs are not supported in the top level function.
>
> For the rest, you can basically do what you want. Use classes
> a interfaces, pass modules as a parameter to other modules,
> whatever. Just don't try to convert such functions as the
> top-level.
>
> The only restrictions apply to the syntax *inside* generator
> code, see the manual. The basic trick is therefore to do all
> the complex stuff and lookup outside generator code ("at
> elaboration time").
>
> For example, you cannot use attribute lookup inside a generator
> but you can do it outside. This may be a good idea in general:
> it makes the "action" code smaller, and it only does the lookup
> once at elaboration time, instead of all the time during
> simulation.
>
> --
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>

On 08/09/2012 06:42 PM, Per Karlsson wrote:
> Ah, I see! (And thanks for the explanation!)
>
> Well, if I cannot use classes as interfaces, and I cannot
> automatically explode lists of ports at the top for conversion, then
> I'll feel severely hampered.

The top level function is special and restrictive in conversion,
that is all.

It uses the arg names as the spec of the port names in Verilog
and VHDL. Where else should it get them, e.g. in case of varargs?
But I concede there should be an error message that varargs and
kwargs are not supported in the top level function.

For the rest, you can basically do what you want. Use classes
a interfaces, pass modules as a parameter to other modules,
whatever. Just don't try to convert such functions as the
top-level.

The only restrictions apply to the syntax *inside* generator
code, see the manual. The basic trick is therefore to do all
the complex stuff and lookup outside generator code ("at
elaboration time").

For example, you cannot use attribute lookup inside a generator
but you can do it outside. This may be a good idea in general:
it makes the "action" code smaller, and it only does the lookup
once at elaboration time, instead of all the time during
simulation.

-- 
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

Ah, I see!
(And thanks for the explanation!)

Well, if I cannot use classes as interfaces, and I cannot automatically
explode lists of ports at the top for conversion, then I'll feel severely
hampered.

What I want to do, ideally, is to begin the design as a high level TLM
model and testbench, and then refine it module by module to be first cycle
accurate, and then synthesizable RTL. (All the time maintaining a
functioning test environment)

I have managed to do the first two steps in MyHDL, but the
last---indispensable---step eludes me. But then again I'm relatively new to
python and a novice at MyHDL.
/Per

On Thu, Aug 9, 2012 at 5:57 PM, Jose Ignacio Villar <jo...@dt...> wrote:

> Hi!
> it's happening because of the method used by myhdl to extract the port
> list at the top level function.
> In the first case, the function passed to toVerilog has a fully defined
> arg list, in the second case it only has args and kwargs.
> If you debug your example, you will see that
> _AnalyzeTopFuncVisitor->visit_FunctionDef() in the first case
> node.args.args contains the arguments in the prototype of wrap(), but in
> the second case it is empty since only args and kwargs were declared in the
> prototype of kwarg_wrap()
>
> I think that this strange effect is limited to the top level function. If
> you redefine the first case in the following way you will see kwarg_wrap()
> working as expected. The problem is not in kwarg_wrap(), but in the fact
> that the functions passed as top level to toVerilog() need an explicit
> declaration of the arguments that will be in the port list.
>
>
> def wrap(d,q,clk,rstn):
>     kwargs={
>         'd': d,
>         'q': q,
>         'clk': clk,
>         'rstn': rstn
>         }
>     wrap_inst = kwarg_wrap(**kwargs)
>     return wrap_inst
>
> Another discussion would be if this limitation is stopping some nice
> features like the possibility to describe highly parameterizable designs in
> myhdl and what could be done to go over it. I'd like to know what other
> people think about this. Maybe that changes like the proposed by Chris
> Felton in MEP107 (Conversion of Attribute Signal Containers) could be
> useful for this purpose.
>
> Jose.
>
> José Ignacio Villar <jo...@dt...>
> Departamento de Tecnología Electrónica
> Escuela Técnica Superior de Ingeniería Informática
> Universidad de Sevilla
> Avda. Reina Mercedes, s/n
> 41012 - Sevilla (Spain)
>
> Tlf: 954 55 99 62
> Fax: 954 55 27 64
>
>
>
> On Wed, Aug 8, 2012 at 10:54 PM, Per Karlsson <bas...@gm...>wrote:
>
>> Hi!
>> I'm about to embark on a fairly substantial ASIC/FPGA IP design project.
>> The design is meant to be highly customizable and I'm in the process of
>> figuring out if we should go for a home brewn preprocessor or for MyHDL.
>> So here is my first in what will---in all likelihood---be a string of
>> silly questions:
>>
>> Below I have made a flop with asynchronous reset, and then wrapped it in
>> two different empty shells.
>> The first using normal named arguments, and the second using **kwargs.
>> For simulation both work, but for conversion to verilog only the first is
>> OK.
>> The kwargs wrapper looses the ports in conversion.
>>
>> Do any of you guys have an idea why?
>> /Per
>>
>> from myhdl import *
>>
>> def flop(d,q,clk,rstn):
>>     @always(clk.posedge, rstn.negedge)
>>     def flop_rtl():
>>         if not rstn:
>>             q.next = 0
>>         else:
>>             q.next = d
>>     return flop_rtl
>>
>> def wrap(d,q,clk,rstn):
>>     kwargs={
>>         'd': d,
>>         'q': q,
>>         'clk': clk,
>>         'rstn': rstn
>>         }
>>     wrap_inst = flop(**kwargs)
>>     return wrap_inst
>>
>> def kwarg_wrap(*args, **kwargs):
>>     wrap_inst = flop(*args, **kwargs)
>>     return wrap_inst
>>
>>
>> def generate_flop():
>>      clk  = Signal(bool(0))
>>     rstn = Signal(bool(0))
>>     d    = Signal(bool(0))
>>     q    = Signal(bool(0))
>>
>>     toVerilog(wrap, d=d, q=q, clk=clk, rstn=rstn)
>>
>>     top_args = ()
>>     top_kwargs={
>>         'd': d,
>>         'q': q,
>>         'clk': clk,
>>         'rstn': rstn
>>         }
>>
>>      toVerilog(kwarg_wrap, *top_args, **top_kwargs)
>>
>> generate_flop()
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Hi!
it's happening because of the method used by myhdl to extract the port list
at the top level function.
In the first case, the function passed to toVerilog has a fully defined arg
list, in the second case it only has args and kwargs.
If you debug your example, you will see that
_AnalyzeTopFuncVisitor->visit_FunctionDef() in the first case
node.args.args contains the arguments in the prototype of wrap(), but in
the second case it is empty since only args and kwargs were declared in the
prototype of kwarg_wrap()

I think that this strange effect is limited to the top level function. If
you redefine the first case in the following way you will see kwarg_wrap()
working as expected. The problem is not in kwarg_wrap(), but in the fact
that the functions passed as top level to toVerilog() need an explicit
declaration of the arguments that will be in the port list.

def wrap(d,q,clk,rstn):
    kwargs={
        'd': d,
        'q': q,
        'clk': clk,
        'rstn': rstn
        }
    wrap_inst = kwarg_wrap(**kwargs)
    return wrap_inst

Another discussion would be if this limitation is stopping some nice
features like the possibility to describe highly parameterizable designs in
myhdl and what could be done to go over it. I'd like to know what other
people think about this. Maybe that changes like the proposed by Chris
Felton in MEP107 (Conversion of Attribute Signal Containers) could be
useful for this purpose.

Jose.

José Ignacio Villar <jo...@dt...>
Departamento de Tecnología Electrónica
Escuela Técnica Superior de Ingeniería Informática
Universidad de Sevilla
Avda. Reina Mercedes, s/n
41012 - Sevilla (Spain)

Tlf: 954 55 99 62
Fax: 954 55 27 64

On Wed, Aug 8, 2012 at 10:54 PM, Per Karlsson <bas...@gm...>wrote:

> Hi!
> I'm about to embark on a fairly substantial ASIC/FPGA IP design project.
> The design is meant to be highly customizable and I'm in the process of
> figuring out if we should go for a home brewn preprocessor or for MyHDL.
> So here is my first in what will---in all likelihood---be a string of
> silly questions:
>
> Below I have made a flop with asynchronous reset, and then wrapped it in
> two different empty shells.
> The first using normal named arguments, and the second using **kwargs.
> For simulation both work, but for conversion to verilog only the first is
> OK.
> The kwargs wrapper looses the ports in conversion.
>
> Do any of you guys have an idea why?
> /Per
>
> from myhdl import *
>
> def flop(d,q,clk,rstn):
>     @always(clk.posedge, rstn.negedge)
>     def flop_rtl():
>         if not rstn:
>             q.next = 0
>         else:
>             q.next = d
>     return flop_rtl
>
> def wrap(d,q,clk,rstn):
>     kwargs={
>         'd': d,
>         'q': q,
>         'clk': clk,
>         'rstn': rstn
>         }
>     wrap_inst = flop(**kwargs)
>     return wrap_inst
>
> def kwarg_wrap(*args, **kwargs):
>     wrap_inst = flop(*args, **kwargs)
>     return wrap_inst
>
>
> def generate_flop():
>      clk  = Signal(bool(0))
>     rstn = Signal(bool(0))
>     d    = Signal(bool(0))
>     q    = Signal(bool(0))
>
>     toVerilog(wrap, d=d, q=q, clk=clk, rstn=rstn)
>
>     top_args = ()
>     top_kwargs={
>         'd': d,
>         'q': q,
>         'clk': clk,
>         'rstn': rstn
>         }
>
>      toVerilog(kwarg_wrap, *top_args, **top_kwargs)
>
> generate_flop()
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Hi!
I'm about to embark on a fairly substantial ASIC/FPGA IP design project.
The design is meant to be highly customizable and I'm in the process of
figuring out if we should go for a home brewn preprocessor or for MyHDL.
So here is my first in what will---in all likelihood---be a string of silly
questions:

Below I have made a flop with asynchronous reset, and then wrapped it in
two different empty shells.
The first using normal named arguments, and the second using **kwargs.
For simulation both work, but for conversion to verilog only the first is
OK.
The kwargs wrapper looses the ports in conversion.

Do any of you guys have an idea why?
/Per

from myhdl import *

def flop(d,q,clk,rstn):
    @always(clk.posedge, rstn.negedge)
    def flop_rtl():
        if not rstn:
            q.next = 0
        else:
            q.next = d
    return flop_rtl

def wrap(d,q,clk,rstn):
    kwargs={
        'd': d,
        'q': q,
        'clk': clk,
        'rstn': rstn
        }
    wrap_inst = flop(**kwargs)
    return wrap_inst

def kwarg_wrap(*args, **kwargs):
    wrap_inst = flop(*args, **kwargs)
    return wrap_inst

def generate_flop():
    clk  = Signal(bool(0))
    rstn = Signal(bool(0))
    d    = Signal(bool(0))
    q    = Signal(bool(0))

    toVerilog(wrap, d=d, q=q, clk=clk, rstn=rstn)

    top_args = ()
    top_kwargs={
        'd': d,
        'q': q,
        'clk': clk,
        'rstn': rstn
        }

    toVerilog(kwarg_wrap, *top_args, **top_kwargs)

generate_flop()

On 8/3/12 8:54 AM, Christopher Felton wrote:
> On 8/3/12 8:39 AM, Christopher Felton wrote:
>> On 8/3/12 8:14 AM, Geoffrey Brown wrote:
>>> Thanks,  that's a help.  But I notice you don't trace when doing
>>> co-simulation so I guess you haven't seen
>>> in practice the error that started this thread.   It is the case that
>>> tracing is forbidden when conversion is
>>> performed in the same program execution (why ???), but tracing does
>>> work with co-simulation except for the
>>> annoying error at the end.
>>>
>>> Geoffrey
>>
>> I missed the fact the the error was caused when
>> tracing with cosimulation.  With cosimulation you
>> have two simulation engines running, MyHDL sim
>> and the Icarus (or whatever Verilog sim) running.
>>
>> If you want/need to trace the verilog signals you
>> need to enable tracing in the verilog sim eng.  You
>> can do this by adding $dumpvars to the tb_*.v file.
>>
>> You can simultaneously trace the signals in your
>> MyHDL testbench, you just need a separate function.
>>
>>      g_tb = traceSignals(tb_test)
>>      g_dut = Cosimulation(...)
>>      # need to manually create/modify the tb_test
>>
>>
>> Note, I was planning on posting the /testbench/
>> template example.  It was intended to be an example
>> but not necessarily to solve this exact issue.
>>
>> Regards,
>> Chris
>>
>
> I modified the example to trace the testbecn
> and enable tracing in the cosimulation verilog.
> This will generate two different vcd files.  I
> didn't get any errors/warnings.
>
> To run the example:
>      >> python test_myadder.py --cosim --trace
>
>
> Note, the attached files are only useful for
> cosimulation.  It will only trace the testbench
> in the MyHDL sim.  If you trace in only MyHDL
> sim you will not get any of the DUT signals.
>
> Hope this helps,
> Chris

Forgot to attached the modified verilog file
testbench.

.chris

On 8/3/12 8:39 AM, Christopher Felton wrote:
> On 8/3/12 8:14 AM, Geoffrey Brown wrote:
>> Thanks,  that's a help.  But I notice you don't trace when doing
>> co-simulation so I guess you haven't seen
>> in practice the error that started this thread.   It is the case that
>> tracing is forbidden when conversion is
>> performed in the same program execution (why ???), but tracing does
>> work with co-simulation except for the
>> annoying error at the end.
>>
>> Geoffrey
>
> I missed the fact the the error was caused when
> tracing with cosimulation.  With cosimulation you
> have two simulation engines running, MyHDL sim
> and the Icarus (or whatever Verilog sim) running.
>
> If you want/need to trace the verilog signals you
> need to enable tracing in the verilog sim eng.  You
> can do this by adding $dumpvars to the tb_*.v file.
>
> You can simultaneously trace the signals in your
> MyHDL testbench, you just need a separate function.
>
>      g_tb = traceSignals(tb_test)
>      g_dut = Cosimulation(...)
>      # need to manually create/modify the tb_test
>
>
> Note, I was planning on posting the /testbench/
> template example.  It was intended to be an example
> but not necessarily to solve this exact issue.
>
> Regards,
> Chris
>

I modified the example to trace the testbecn
and enable tracing in the cosimulation verilog.
This will generate two different vcd files.  I
didn't get any errors/warnings.

To run the example:
     >> python test_myadder.py --cosim --trace

Note, the attached files are only useful for
cosimulation.  It will only trace the testbench
in the MyHDL sim.  If you trace in only MyHDL
sim you will not get any of the DUT signals.

Hope this helps,
Chris

On 8/3/12 8:14 AM, Geoffrey Brown wrote:
> Thanks,  that's a help.  But I notice you don't trace when doing
> co-simulation so I guess you haven't seen
> in practice the error that started this thread.   It is the case that
> tracing is forbidden when conversion is
> performed in the same program execution (why ???), but tracing does
> work with co-simulation except for the
> annoying error at the end.
>
> Geoffrey

I missed the fact the the error was caused when
tracing with cosimulation.  With cosimulation you
have two simulation engines running, MyHDL sim
and the Icarus (or whatever Verilog sim) running.

If you want/need to trace the verilog signals you
need to enable tracing in the verilog sim eng.  You
can do this by adding $dumpvars to the tb_*.v file.

You can simultaneously trace the signals in your
MyHDL testbench, you just need a separate function.

    g_tb = traceSignals(tb_test)
    g_dut = Cosimulation(...)
    # need to manually create/modify the tb_test

Note, I was planning on posting the /testbench/
template example.  It was intended to be an example
but not necessarily to solve this exact issue.

Regards,
Chris

>
> On Fri, Aug 3, 2012 at 8:58 AM, Christopher Felton
> <chr...@gm...> wrote:
>> On 7/31/12 10:50 PM, Christopher Felton wrote:
>>>
>>> I have been using a simple testbench template
>>> for small single module tests.  I use this testbench
>>> template so that I can quickly add basic test stimulus
>>> to a module.  From the testbench I can do operations
>>> that require similar setup.
>>>
>>>     >> python test_.py trace
>>>     >> python test_.py convert
>>>     >> python test_.py cosim
>>>
>>> Note, I usually have a more complicated test environment
>>> (only as complicated as needed and no more) for full
>>> designs.  In addition to the *full* verification
>>> environment I typically have individual module tests
>>> that use the template.
>>>
>>> I attached the template and an example using a simple
>>> adder.  Might be useful (might not).  Feel free to
>>> comment, always room for improvement.  This is a
>>> template that needs to be manually modified and uses
>>> some features only available in 0.8dev branch.
>>>
>>> Regards,
>>> Chris
>>>
>>>
>>
>> I modified the /testbench/ template to be a class
>> which is more reusable.  Also, used the Python
>> argparser for the command line options.
>>
>>
>> Using the same example as the previous post the
>> CLI is:
>>
>>     python test_myadder.py -h
>>     usage: test_myadder.py [-h] [--trace] [--cosim] [--convert]
>>                            [-Tclk CLOCK_PERIOD]
>>
>>     Testbench
>>
>>     optional arguments:
>>       -h, --help            show this help message and exit
>>       --trace               enable testbench tracing (create VCD file)
>>       --cosim               run cosimulation
>>       --convert             convert the module
>>       -Tclk CLOCK_PERIOD, --clock_period CLOCK_PERIOD
>>                             set the clock period
>>
>> Again, this is intended to streamline the creation
>> of tests for small single module designs.
>>
>> Regards,
>> Chris

Thanks,  that's a help.  But I notice you don't trace when doing
co-simulation so I guess you haven't seen
in practice the error that started this thread.   It is the case that
tracing is forbidden when conversion is
performed in the same program execution (why ???), but tracing does
work with co-simulation except for the
annoying error at the end.

Geoffrey

On Fri, Aug 3, 2012 at 8:58 AM, Christopher Felton
<chr...@gm...> wrote:
> On 7/31/12 10:50 PM, Christopher Felton wrote:
>>
>> I have been using a simple testbench template
>> for small single module tests.  I use this testbench
>> template so that I can quickly add basic test stimulus
>> to a module.  From the testbench I can do operations
>> that require similar setup.
>>
>>    >> python test_.py trace
>>    >> python test_.py convert
>>    >> python test_.py cosim
>>
>> Note, I usually have a more complicated test environment
>> (only as complicated as needed and no more) for full
>> designs.  In addition to the *full* verification
>> environment I typically have individual module tests
>> that use the template.
>>
>> I attached the template and an example using a simple
>> adder.  Might be useful (might not).  Feel free to
>> comment, always room for improvement.  This is a
>> template that needs to be manually modified and uses
>> some features only available in 0.8dev branch.
>>
>> Regards,
>> Chris
>>
>>
>
> I modified the /testbench/ template to be a class
> which is more reusable.  Also, used the Python
> argparser for the command line options.
>
>
> Using the same example as the previous post the
> CLI is:
>
>    python test_myadder.py -h
>    usage: test_myadder.py [-h] [--trace] [--cosim] [--convert]
>                           [-Tclk CLOCK_PERIOD]
>
>    Testbench
>
>    optional arguments:
>      -h, --help            show this help message and exit
>      --trace               enable testbench tracing (create VCD file)
>      --cosim               run cosimulation
>      --convert             convert the module
>      -Tclk CLOCK_PERIOD, --clock_period CLOCK_PERIOD
>                            set the clock period
>
> Again, this is intended to streamline the creation
> of tests for small single module designs.
>
> 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
>

2003	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (14)	Nov (4)	Dec
2004	Jan (1)	Feb (10)	Mar (19)	Apr (14)	May (1)	Jun (4)	Jul (10)	Aug	Sep (2)	Oct (7)	Nov (17)	Dec (12)
2005	Jan (6)	Feb (10)	Mar (17)	Apr (10)	May (9)	Jun (5)	Jul (26)	Aug (34)	Sep (10)	Oct (38)	Nov (71)	Dec (74)
2006	Jan (20)	Feb (20)	Mar (7)	Apr (2)	May (13)	Jun	Jul	Aug (4)	Sep (37)	Oct (43)	Nov (30)	Dec (33)
2007	Jan (3)	Feb	Mar	Apr	May (30)	Jun (9)	Jul (1)	Aug	Sep (8)	Oct (13)	Nov	Dec (4)
2008	Jan (13)	Feb (46)	Mar (25)	Apr (7)	May (20)	Jun (73)	Jul (38)	Aug (47)	Sep (24)	Oct (18)	Nov (9)	Dec (36)
2009	Jan (31)	Feb (24)	Mar (73)	Apr (13)	May (47)	Jun (28)	Jul (36)	Aug (2)	Sep (5)	Oct (8)	Nov (16)	Dec (29)
2010	Jan (34)	Feb (18)	Mar (18)	Apr (5)	May	Jun (24)	Jul (53)	Aug (3)	Sep (18)	Oct (33)	Nov (19)	Dec (15)
2011	Jan (9)	Feb (4)	Mar (39)	Apr (213)	May (86)	Jun (46)	Jul (22)	Aug (11)	Sep (78)	Oct (59)	Nov (38)	Dec (24)
2012	Jan (9)	Feb (22)	Mar (89)	Apr (55)	May (222)	Jun (86)	Jul (57)	Aug (32)	Sep (49)	Oct (69)	Nov (12)	Dec (35)
2013	Jan (67)	Feb (39)	Mar (18)	Apr (42)	May (79)	Jun (1)	Jul (19)	Aug (18)	Sep (54)	Oct (79)	Nov (9)	Dec (26)
2014	Jan (30)	Feb (44)	Mar (26)	Apr (11)	May (39)	Jun (1)	Jul (89)	Aug (15)	Sep (7)	Oct (6)	Nov (20)	Dec (27)
2015	Jan (107)	Feb (106)	Mar (130)	Apr (90)	May (147)	Jun (28)	Jul (53)	Aug (16)	Sep (23)	Oct (7)	Nov	Dec (16)
2016	Jan (86)	Feb (41)	Mar (38)	Apr (31)	May (37)	Jun (11)	Jul (1)	Aug (1)	Sep (3)	Oct (1)	Nov (5)	Dec (3)
2017	Jan	Feb (4)	Mar (2)	Apr (2)	May	Jun (3)	Jul (2)	Aug (2)	Sep (1)	Oct (2)	Nov (1)	Dec (1)
2018	Jan (1)	Feb (1)	Mar (7)	Apr (1)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan (1)	Feb	Mar (2)	Apr (1)	May (1)	Jun (2)	Jul	Aug	Sep (1)	Oct	Nov (3)	Dec
2020	Jan (1)	Feb (2)	Mar	Apr (1)	May	Jun	Jul (1)	Aug (1)	Sep (1)	Oct	Nov	Dec (3)
2021	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (2)	Aug	Sep	Oct	Nov (12)	Dec (11)
2022	Jan (7)	Feb (2)	Mar (1)	Apr	May	Jun (1)	Jul (3)	Aug (2)	Sep (1)	Oct	Nov	Dec (1)
2023	Jan	Feb (1)	Mar (1)	Apr (3)	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec (1)
2024	Jan (1)	Feb (2)	Mar (4)	Apr (2)	May (2)	Jun (1)	Jul	Aug (1)	Sep (1)	Oct	Nov	Dec (2)
2025	Jan (1)	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

myhdl-list Mailing List for MyHDL (Page 81)

myhdl-list — Mailing list for discussions on MyHDL