myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] newb question

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

Christopher L. Felton wrote:
> 
>>
>> In general, I would recommend to write a wiki page with considerations
>> and specs before implementing anything significant, so that others
>> can review it and perhaps help with specification and implementation.
>>
>> Jan
> 
> 
> I as contemplating creating a wiki page to start off a possible intbv 
> optimization page.  At first I simply wanted to add a small (emphasis on 
> small) design example with profiling and the results.  
> 
> While trying to do this I ran into an issue, maybe someone can point out 
> what I am doing wrong!  I created a simple sequential multiplier that I 
> thought would be an ok model for exercising intbv.
> 
> Note the following isn't complete, but hopefully it will convey the 
> issue.  The following is a very basic sequential multiplier, does a 
> magnitude multiplication and then does a 2's compliment at the end if 
> the answer should be negative.  The fist time my 2's compliment code 
> simulates and coverts fine.  But the 2's complement conversion towards 
> the bottom fails??  Any suggestions?  

I tried to duplicate the problem. The Verilog conversion fails on the
use of operator ~ on intbv's that may be negative (so it says.) Before
trying to remember why that might be - is that the problem that you are
seeing also?

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] About multiple simulations without leaving the interpreter

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

Hello:

There is some new functionality available since 0.6dev6 that I still
have to document.

It's relatively advanced, and depending on your usage patterns you
may never need it. So if the following doesn't ring a bell, you can
safely ignore the info.

In a recent project I defined the internal signals "globally" in
a separate module. This way, I could define lookup functions to
make it easier to define top-level netlists and test benches (and
keep them up to date.)

Also, running my test plan meant that I did multiple simulations
without leaving the interpreter.

This usage pattern implies that after the first simulation, the
*same* (in terms of object identity) Signals are reused in the second
one.

This led to problems. For example, at the end of a simulation Signals
were not "reset" to their initial value, leading to "unexpected"
values at the start of the next simulation. In general, the Simulation
and Signal data structures were not cleaned up systematically at
the end of a simulation.

This is now solved: at the end of a simulation, things are cleaned up
so that a subsequent simulation in the *same* interpreter gives the
expected results: the same behavior as if the new simulation would
run in a *new* interpreter.

Best regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

[Christopher L. F. <cf...@uc...>]

>
> In general, I would recommend to write a wiki page with considerations
> and specs before implementing anything significant, so that others
> can review it and perhaps help with specification and implementation.
>
> Jan

I as contemplating creating a wiki page to start off a possible intbv  
optimization page.  At first I simply wanted to add a small (emphasis  
on small) design example with profiling and the results.

While trying to do this I ran into an issue, maybe someone can point  
out what I am doing wrong!  I created a simple sequential multiplier  
that I thought would be an ok model for exercising intbv.

Note the following isn't complete, but hopefully it will convey the  
issue.  The following is a very basic sequential multiplier, does a  
magnitude multiplication and then does a 2's compliment at the end if  
the answer should be negative.  The fist time my 2's compliment code  
simulates and coverts fine.  But the 2's complement conversion towards  
the bottom fails??  Any suggestions?

Note the commented out code doesn't work, the expression Product.next  
= -1 * p0_r works but I don't believe it will convert correctly.

 >>> myhdl.__version__
'0.5.1'
 >>> myhdl.__revision__
'$Revision: 827 $'
 >>>


<<< ------------------  >>>
     @always(clk.posedge)
     def sm():
         if rst == 1:
             state.next = 0
             m0_r.next  = 0
             m1_r.next  = 0
             p0_r.next  = 0
             cnt.next   = MU_N-1
             rdy.next   = 1
             dv_o.next  = 0
             neg.next   = 0
         else:
             if state == 0:
                 if dv_i == 1 and rdy == 1:
                     state.next = 1

                     if Multiplicand[MC_N-1]:
                         m0_r.next = ~Multiplicand + 1
                     else:
                         m0_r.next  = Multiplicand
                     if Multiplier[MU_N-1]:
                         m1_r.next = ~Multiplier + 1
                     else:
                         m1_r.next  = Multiplier

                     if Multiplicand[MC_N-1] ^ Multiplier[MU_N-1]:
                         neg.next = 1
                     else:
                         neg.next = 0

                     p0_r.next  = 0
                     cnt.next   = MU_N-1
                     rdy.next   = 0
                     dv_o.next  = 0

             elif state == 1:
                 m0_r.next = m0_r << 1
                 m1_r.next = m1_r >> 1

                 if m1_r[0] == 1:
                     p0_r.next = p0_r + m0_r

                 if cnt == 0:
                     state.next = 2
                 else:
                     cnt.next = cnt - 1

             elif state == 2:
                 state.next = 0
                 dv_o.next  = 1

                 if neg:
                     Product.next = -1 * p0_r
#  Should Be ----->>>  Product.next = ~p0_r + 1
                 else:
                     Product.next = p0_r
                 rdy.next   = 1

<<< ------------------  >>>

Re: [myhdl-list] List of Signals == Memory

[Christopher L. F. <cf...@uc...>]

I agree I wouldn't like to see anything the currently works broken.   
In my original post I had proposed a something that would keep the  
feature but break current implementation.  Don't know if that would be  
acceptable.

Basically, I would like to use list syntax in generators, to preserve  
memory instantiation I proposed I seperate type.  I proposed this only  
because of my current understanding of the analyze and convert code.   
I had suggested (still lot to resolve before getting to this point)  
that another type be added, kinda like the following.

from myhdl import Signal

class Memory(Signal):
     pass

 >>> from memory_class import *
 >>> reload(memory_class)
<module 'memory_class' from 'memory_class.py'>
 >>> x = Memory(0)
 >>> type(x)
<class 'memory_class.Memory'>

Basically just an empty class that has all the same attributes and  
behavior as a signal.  This way the analyze and convert can easily  
tell if a list is intended to be memory or just a generic container  
for signals.

Declaring memory would look like

RAM = [Memory(intbv(0)[8:]) for i in range(N)]

This is probably getting a little head of myself.


On Feb 22, 2008, at 9:35 AM, Jan Decaluwe wrote:

> Tom Dillon wrote:
>> Hi,
>>
>> I am not quite following this discussion, sorry.
>>
>> Just want to make sure we would loose our ability to infer RAMs  
>> from lists, I thought that was a
>> nice feature.
>
> No worries. We'll investigate if certain restrictions can be lifted,
> but I don't want to lose anything that we can do today.
>
> Jan
>
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] List of Signals == Memory

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

Tom Dillon wrote:
> Hi,
> 
> I am not quite following this discussion, sorry. 
> 
> Just want to make sure we would loose our ability to infer RAMs from lists, I thought that was a 
> nice feature.

No worries. We'll investigate if certain restrictions can be lifted,
but I don't want to lose anything that we can do today.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] List of Signals == Memory

[Tom D. <TD...@di...>]

Hi,

I am not quite following this discussion, sorry. 

Just want to make sure we would loose our ability to infer RAMs from lists, I thought that was a 
nice feature.

Tom




On Friday 22 February 2008 07:50:38 am Christopher L. Felton wrote:
> >> This seems to break a very natural way of writing HDL
> >> in python.
>
> The above is definitely a very subjective statement/argument.  Came to
> this conclusion based on my own experience and the other posts.  I
> don't think I articulated my suggestion well.  I believe I understand
> the issues that led to the current implementation (I hope).
>
> I see that  the following may not be desired to be converted directly
>
>    x = [Signal(intbv(0)[8:]) for i in range(4)]
>
>    @always(clk.posedge)
>    def rtl():
>
>        for i in range(N):
>            x[i] = i
>    ...
>
> Converted to Verilog as
>
>      reg [7:0] x [0:3];
>
>    always @(posedge clk) begin
>        for (i=0; i<4; i=i+1) begin
>            x[i] <= i;
>        end
>    end
>
> In the above example, this is where the Verilog synthesis tools may
> get in trouble because it could infer a block of memory.   The memory
> may not be what the original description was intending.
>
> What I would like to propose is that the toVerilog/toVhdl does a
> little bit more work.  When it comes across a list of signals it
> converts the original MyHDL to the following Verilog.
>
>    reg [7:0] x_los_0;
>    reg [7:0] x_los_1;
>    reg [7:0] x_los_2;
>    reg [7:0] x_los_3;
>
>    always @(posedge clk) begin
>        x_los_0 <= 0;
>        x_los_1 <= 1;
>        x_los_2 <= 2;
>        x_los_3 <= 3;
>    end
>
> The Verilog/VHDL conversion will unroll the loops so list of signals
> can be used as generic containers etc.  This way the conversion is
> explicit and won't have the potential to confuse the Verilog/VHDL
> synthesis tools.
>
> Then there is the issue of actually describing RAM/ROM and co-
> simulation.  I believe those are solvable issues if the loop-unrolling
> method was adopted.
>
> I believe that the list extraction would allow a MyHDL developer to
> use lists in a very natural way, and the lists would always be
> expanded.  This way you could have complex structures, list of
> signals, inside a list, the python parse/converter will get to the
> primitive type (in this case a signal) and create a unique name that
> represents the structure.
>
> I have looked at the conversion python code some, I believe I know
> where these changes / enhancements could coded.  Maybe after some more
> hashing, if this change seems to make sense I can attempt the change.
>
> > that you're now all struggling with :-)
> >
> > Before doing anything else, I believe we should now review the
> > assumptions.
> > Synthesis tools have evolved and so has Verilog in the mean time.
> > Based on
> > that info, we may be able to do something sensible - otherwise we are
> > walking in the dark.
> >
> > Specifically, I'd like to know how memory syntax (including member
> > slicing
> > and indexing) is currently supported in (System)Verilog, and in
> > mainstream
> > synthesis tools. Anyone with useful info on this - please let us know.
>
> Personally, I like sticking with Verilog 1364-1995(2001), using basics
> of the language and converting more complex MyHDL structures to basic
> Verilog.  This puts more work in the conversion tools and kinda goes
> against the minimalist approach (doh).
>
> > I refer to the thread "RAM inference from toVerilog output" dated
> > 08/09/2005.
> > This announces the first release with RAM inteference support.
>
> Hopefully I am not repeating the previous thread (I don't think so), I
> will study this thread a little more.
>
> Thanks for the reply and all the work on MyHDL!

Re: [myhdl-list] List of Signals == Memory

[Christopher L. F. <cf...@uc...>]

>> This seems to break a very natural way of writing HDL
>> in python.

The above is definitely a very subjective statement/argument.  Came to  
this conclusion based on my own experience and the other posts.  I  
don't think I articulated my suggestion well.  I believe I understand  
the issues that led to the current implementation (I hope).

I see that  the following may not be desired to be converted directly

   x = [Signal(intbv(0)[8:]) for i in range(4)]

   @always(clk.posedge)
   def rtl():

       for i in range(N):
           x[i] = i
   ...

Converted to Verilog as
	
     reg [7:0] x [0:3];

   always @(posedge clk) begin
       for (i=0; i<4; i=i+1) begin
           x[i] <= i;
       end
   end

In the above example, this is where the Verilog synthesis tools may  
get in trouble because it could infer a block of memory.   The memory  
may not be what the original description was intending.

What I would like to propose is that the toVerilog/toVhdl does a  
little bit more work.  When it comes across a list of signals it  
converts the original MyHDL to the following Verilog.

   reg [7:0] x_los_0;
   reg [7:0] x_los_1;
   reg [7:0] x_los_2;
   reg [7:0] x_los_3;

   always @(posedge clk) begin
       x_los_0 <= 0;
       x_los_1 <= 1;
       x_los_2 <= 2;
       x_los_3 <= 3;
   end

The Verilog/VHDL conversion will unroll the loops so list of signals  
can be used as generic containers etc.  This way the conversion is  
explicit and won't have the potential to confuse the Verilog/VHDL  
synthesis tools.

Then there is the issue of actually describing RAM/ROM and co- 
simulation.  I believe those are solvable issues if the loop-unrolling  
method was adopted.

I believe that the list extraction would allow a MyHDL developer to  
use lists in a very natural way, and the lists would always be  
expanded.  This way you could have complex structures, list of  
signals, inside a list, the python parse/converter will get to the  
primitive type (in this case a signal) and create a unique name that  
represents the structure.

I have looked at the conversion python code some, I believe I know  
where these changes / enhancements could coded.  Maybe after some more  
hashing, if this change seems to make sense I can attempt the change.

> that you're now all struggling with :-)
>
> Before doing anything else, I believe we should now review the  
> assumptions.
> Synthesis tools have evolved and so has Verilog in the mean time.  
> Based on
> that info, we may be able to do something sensible - otherwise we are
> walking in the dark.
>
> Specifically, I'd like to know how memory syntax (including member  
> slicing
> and indexing) is currently supported in (System)Verilog, and in  
> mainstream
> synthesis tools. Anyone with useful info on this - please let us know.

Personally, I like sticking with Verilog 1364-1995(2001), using basics  
of the language and converting more complex MyHDL structures to basic  
Verilog.  This puts more work in the conversion tools and kinda goes  
against the minimalist approach (doh).

> I refer to the thread "RAM inference from toVerilog output" dated  
> 08/09/2005.
> This announces the first release with RAM inteference support.
Hopefully I am not repeating the previous thread (I don't think so), I  
will study this thread a little more.

Thanks for the reply and all the work on MyHDL!

Re: [myhdl-list] Time discrepancy

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

Kanchan Devarakonda wrote:
> Hi,
> 
> I am a PhD student and do Verilog design as part of my research work. In 
> order to perform benchmarking, I have been using cosimulation to test my 
> Verilog code. I have three designs described below that essentially do 
> the /*same */thing:
> 
> - Design A is completely written in Python
> - Design B has a Python framework, but the core functionality is written 
> in myhdl (with the clock )
> - Design C has the Verilog module performing the core function, and the 
> framework is in Python (as in the above two cases). I use the 
> $from_myhdl() and $to_myhdl() task calls to pass the stimuli between the 
> Verilog module and the Python module.
> 
> When I provide similar stimuli to all the three designs and use 
> time.clock()  to measure the simulation time,  Design A is the fastest 
> and Design B takes the longest to run.  My questions are the following:
> 
> 
> 1. How come Design C is faster than Design B? The set-up seems more 
> complex ( at least,intuitively) in the former case, since multiple task 
> calls are involved.

Perhaps because your Verilog simulator is much faster than MyHDL,
which more than compensates the PLI overhead?
> 
> 2.What may be the reason for one being faster than the other?

MyHDL/Python is interpreted, Verilog and VHDL are typically compiled.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Time discrepancy

[Kanchan D. <kan...@gm...>]

Hi,

I am a PhD student and do Verilog design as part of my research work. In
order to perform benchmarking, I have been using cosimulation to test my
Verilog code. I have three designs described below that essentially do
the *same
*thing:

- Design A is completely written in Python
- Design B has a Python framework, but the core functionality is written in
myhdl (with the clock )
- Design C has the Verilog module performing the core function, and the
framework is in Python (as in the above two cases). I use the $from_myhdl()
and $to_myhdl() task calls to pass the stimuli between the Verilog module
and the Python module.

When I provide similar stimuli to all the three designs and use time.clock()
to measure the simulation time,  Design A is the fastest and Design B takes
the longest to run.  My questions are the following:


1. How come Design C is faster than Design B? The set-up seems more complex
( at least,intuitively) in the former case, since multiple task calls are
involved.

2.What may be the reason for one being faster than the other?

Thanks
 KD

Re: [myhdl-list] List of Signals == Memory

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

Christopher L. Felton wrote:
> In this newsgroup a "List of Signals" appears to be a common theme or 
> misunderstanding.  I think it is a "natural" Pythonic usage of lists as 
> general containers, to group items, build structures, etc.
> 
> With the current implementation there are some limitations to using a 
> list of signals.  Example the "list syntax" cannot be used in the 
> generator code.  This seems to break a very natural way of writing HDL 
> in python.

Thanks for the analysis. However, I'm not sure we all understand where this
is coming from. I'll try to clarify that first.

It should be obvious (but perhaps useful to stress to newbies) that the
limitations have nothing to do with MyHDL modelling. Instead, the - admittedly
confusing - complexities are intended to avoid limitations of Verilog or
Verilog synthesis tools.

I refer to the thread "RAM inference from toVerilog output" dated 08/09/2005.
This announces the first release with RAM inteference support. You will note
that memories were given "priority" in that release, meaning that any list
of signals was simply declared as a memory. Clean and simple, so I thought.
But note the implication: memory syntax would potentially be introduced in always
blocks, even if not present in the original MyHDL generator. (This is a
consequence of the fact that the convertor flattens hierarchy.)

Tom Dillon spotted potential problems with cosimulation and synthesis. Let's
leave cosimulation aside for the moment. He indicated that synthesis tools
and/or Verilog would have problems with memory syntax, for example if a
memory member would be indexed or sliced.

I realized that he was right, so I backed off and did the "cleverer" thing
that you're now all struggling with :-)

Before doing anything else, I believe we should now review the assumptions.
Synthesis tools have evolved and so has Verilog in the mean time. Based on
that info, we may be able to do something sensible - otherwise we are
walking in the dark.

Specifically, I'd like to know how memory syntax (including member slicing
and indexing) is currently supported in (System)Verilog, and in mainstream
synthesis tools. Anyone with useful info on this - please let us know.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

[Prakash S. <pra...@gm...>]

Hello,  what Prof. Jan telling is right, before implementing we must review
this.
I have gone through it , i have 1-2 points , i will write after some time.

Thanks
Prakash , IIT Bombay

On Feb 19, 2008 4:12 PM, Jan Decaluwe <ja...@ja...> wrote:

> Christopher Felton wrote:
>
> > Does it make sense to formalize a possible plan for optimization
> > (quick wiki page)?  If different folks attack it in parallel they
> > would head down a similar path.  Define if it needs to be optimized
> > with C code or not.  If so, add ctype type for intbv (like numpy folks
> > did for arrays).  Then attributes etc. can easily be accessible from
> > C?
>
> In general, I would recommend to write a wiki page with considerations
> and specs before implementing anything significant, so that others
> can review it and perhaps help with specification and implementation.
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Prakash Sutradhar
Electrical Engineering Dept. , IIT Bombay
+91-9869956941

Re: [myhdl-list] newb question

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

Christopher Felton wrote:

> Does it make sense to formalize a possible plan for optimization 
> (quick wiki page)?  If different folks attack it in parallel they 
> would head down a similar path.  Define if it needs to be optimized 
> with C code or not.  If so, add ctype type for intbv (like numpy folks 
> did for arrays).  Then attributes etc. can easily be accessible from 
> C?

In general, I would recommend to write a wiki page with considerations
and specs before implementing anything significant, so that others
can review it and perhaps help with specification and implementation.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] List of Signals

[Vanheesbeke S. <Ste...@va...>]

Jan, 

I did this already, the assignments came in after some trials to make it work. 
In the real application I need one assignment, so the error occured. 

Stefaan


-----Original Message-----
From: myh...@li...
[mailto:myh...@li...]On Behalf Of Jan
Decaluwe
Sent: dinsdag 19 februari 2008 10:51
To: myh...@li...
Subject: Re: [myhdl-list] List of Signals


Vanheesbeke Stefaan wrote:
> Terrific, this is what I looked for, and indeed as you siggest the solution was already ion other posts...

Why not avoid combinatorial assignments alltogether, like so:

def TestSigs(Clk, Reset, Enable, DataIn, DataOut, Size=3):

     sigs = [Signal(bool(0)) for i in range(Size+1)]
     # aliases
     sigs[0] = DataIn
     sigs[Size] = DataOut

     blocks = []
     for i in range(Size):
         blocks.append(TestFunc(Clk, Reset, Enable, sigs[i], sigs[i+1]))

     return blocks

Jan

> 
> For a reference to others I send my little sample application, modified.
> 
> Thanks
> 
> <code>
> from myhdl import *
> 
> def TestFunc(Clk, Reset, Enable, DataIn, DataOut):
>    
>     @always(Clk.posedge, Reset.posedge)
>     def functionality():
>         if Reset:
>             DataOut.next = 0
>         elif Enable:
>             DataOut.next = DataIn
> 
>     return functionality
> 
> def TestFixed(Clk, Reset, Enable, DataIn, DataOut, Size=3):
>     #Size not used in fixed implementation (fixed to 3)
> 
>     Out0 = Signal(bool(0))
>     Out1 = Signal(bool(0))
>     Out2 = Signal(bool(0))
>     In0 = Signal(bool(0))
>     In1 = Signal(bool(0))
>     In2 = Signal(bool(0))
> 
>     @always_comb
>     def Connect():
>         In0.next = DataIn
>         In1.next = Out0
>         In2.next = Out1
>         DataOut.next = Out2
> 
>     blocks = []
>     blocks.append(TestFunc(Clk, Reset, Enable, In0, Out0))
>     blocks.append(TestFunc(Clk, Reset, Enable, In1, Out1))
>     blocks.append(TestFunc(Clk, Reset, Enable, In2, Out2))
>    
>     return Connect, blocks
> 
> def Connect(In, Out):
>     @always_comb
>     def connect():
>         Out.next = In
>     return connect
> 
> def TestGeneric(Clk, Reset, Enable, DataIn, DataOut, Size=3):
> 
>     Out = [Signal(bool(0)) for i in range(Size)]
>     In  = [Signal(bool(0)) for i in range(Size)]
>         
>     connect = []
>     connect.append(Connect(DataIn, In[0]))
>     for k in range(1,Size):
>         connect.append(Connect(Out[k-1], In[k]))
>     connect.append(Connect(Out[Size-1], DataOut))
>   
>     blocks = []
>     for i in range(Size):
>         blocks.append(TestFunc(Clk, Reset, Enable, In[i], Out[i]))
> 
>     return connect, blocks
> 
> 
> def convert_TestFunc():
>     """Verify testfunc conversion"""
>     Clk     = Signal(bool(0))        
>     Reset   = Signal(bool(0))        
>     Enable  = Signal(bool(0))        
>     DataIn  = Signal(bool(0))
>     DataOut = Signal(bool(0))
>     toVerilog(TestFunc, Clk, Reset, Enable, DataIn, DataOut)
> 
> def convert_TestFixed():
>     Clk     = Signal(bool(0))        
>     Reset   = Signal(bool(0))        
>     Enable  = Signal(bool(0))        
>     DataIn  = Signal(bool(0))
>     DataOut = Signal(bool(0))
>     toVerilog(TestFixed, Clk, Reset, Enable, DataIn, DataOut)
> 
> def convert_TestGeneric():
>     Clk     = Signal(bool(0))        
>     Reset   = Signal(bool(0))        
>     Enable  = Signal(bool(0))        
>     DataIn  = Signal(bool(0))
>     DataOut = Signal(bool(0))
>     toVerilog(TestGeneric, Clk, Reset, Enable, DataIn, DataOut)
> 
> 
> if __name__ == '__main__':
>     convert_TestFunc()
>     convert_TestFixed()
>     convert_TestGeneric()
> 
> </code>
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list

______________________________________________________________________
This email has been scanned by the Email Security System.
______________________________________________________________________

Re: [myhdl-list] List of Signals

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

Vanheesbeke Stefaan wrote:
> Terrific, this is what I looked for, and indeed as you siggest the solution was already ion other posts...

Why not avoid combinatorial assignments alltogether, like so:

def TestSigs(Clk, Reset, Enable, DataIn, DataOut, Size=3):

     sigs = [Signal(bool(0)) for i in range(Size+1)]
     # aliases
     sigs[0] = DataIn
     sigs[Size] = DataOut

     blocks = []
     for i in range(Size):
         blocks.append(TestFunc(Clk, Reset, Enable, sigs[i], sigs[i+1]))

     return blocks

Jan

> 
> For a reference to others I send my little sample application, modified.
> 
> Thanks
> 
> <code>
> from myhdl import *
> 
> def TestFunc(Clk, Reset, Enable, DataIn, DataOut):
>    
>     @always(Clk.posedge, Reset.posedge)
>     def functionality():
>         if Reset:
>             DataOut.next = 0
>         elif Enable:
>             DataOut.next = DataIn
> 
>     return functionality
> 
> def TestFixed(Clk, Reset, Enable, DataIn, DataOut, Size=3):
>     #Size not used in fixed implementation (fixed to 3)
> 
>     Out0 = Signal(bool(0))
>     Out1 = Signal(bool(0))
>     Out2 = Signal(bool(0))
>     In0 = Signal(bool(0))
>     In1 = Signal(bool(0))
>     In2 = Signal(bool(0))
> 
>     @always_comb
>     def Connect():
>         In0.next = DataIn
>         In1.next = Out0
>         In2.next = Out1
>         DataOut.next = Out2
> 
>     blocks = []
>     blocks.append(TestFunc(Clk, Reset, Enable, In0, Out0))
>     blocks.append(TestFunc(Clk, Reset, Enable, In1, Out1))
>     blocks.append(TestFunc(Clk, Reset, Enable, In2, Out2))
>    
>     return Connect, blocks
> 
> def Connect(In, Out):
>     @always_comb
>     def connect():
>         Out.next = In
>     return connect
> 
> def TestGeneric(Clk, Reset, Enable, DataIn, DataOut, Size=3):
> 
>     Out = [Signal(bool(0)) for i in range(Size)]
>     In  = [Signal(bool(0)) for i in range(Size)]
>         
>     connect = []
>     connect.append(Connect(DataIn, In[0]))
>     for k in range(1,Size):
>         connect.append(Connect(Out[k-1], In[k]))
>     connect.append(Connect(Out[Size-1], DataOut))
>   
>     blocks = []
>     for i in range(Size):
>         blocks.append(TestFunc(Clk, Reset, Enable, In[i], Out[i]))
> 
>     return connect, blocks
> 
> 
> def convert_TestFunc():
>     """Verify testfunc conversion"""
>     Clk     = Signal(bool(0))        
>     Reset   = Signal(bool(0))        
>     Enable  = Signal(bool(0))        
>     DataIn  = Signal(bool(0))
>     DataOut = Signal(bool(0))
>     toVerilog(TestFunc, Clk, Reset, Enable, DataIn, DataOut)
> 
> def convert_TestFixed():
>     Clk     = Signal(bool(0))        
>     Reset   = Signal(bool(0))        
>     Enable  = Signal(bool(0))        
>     DataIn  = Signal(bool(0))
>     DataOut = Signal(bool(0))
>     toVerilog(TestFixed, Clk, Reset, Enable, DataIn, DataOut)
> 
> def convert_TestGeneric():
>     Clk     = Signal(bool(0))        
>     Reset   = Signal(bool(0))        
>     Enable  = Signal(bool(0))        
>     DataIn  = Signal(bool(0))
>     DataOut = Signal(bool(0))
>     toVerilog(TestGeneric, Clk, Reset, Enable, DataIn, DataOut)
> 
> 
> if __name__ == '__main__':
>     convert_TestFunc()
>     convert_TestFixed()
>     convert_TestGeneric()
> 
> </code>
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

[Christopher F. <cf...@uc...>]

On Mon, 18 Feb 2008 17:38:33 +0100
  Jan Decaluwe <ja...@ja...> wrote:
> Jan Decaluwe wrote:
>> Christopher L. Felton wrote:
>> 
>> 
>>>For this test, most people would not simulate this design this way. 
>>>  
>>>The design has a simple state machine
>>>that controls the inputs to a bank of pwm's (controls the duty  
>>>cycle).  But the state machine goes to the next
>>>state on the order of 100ms real-time.  But since the simulation has 
>>> 
>>>little logic and the logic switches minimally
>>>it seemed like a good test to profile the MyHDL simulation execution
>>>(most the time spent in the simulation code and not the logic code).
>> 
>> 
>> This seems to imply that more "typical" code (e.g. with more logic
>> inside generators) could have a relatively larger intbv overhead,
>> and therefore more to gain from intbv optimization.
>> 
>> I'll see if I can do a profiling check on my recent designs.
> 
> Below you find a profiling output of a recent test plan. I believe 
>this
> is quite representative for the code I tend to write.
> 
> I used Python 2.5, cProfile, ordered by time (first 20 items).
> 
> I use intbv slicing a lot, and you see this takes a considerable 
>amount
> of time.
> 
> It seems that optimizing intbv would help significantly, but the 
>Simulation

Does it make sense to formalize a possible plan for optimization 
(quick wiki page)?  If different folks attack it in parallel they 
would head down a similar path.  Define if it needs to be optimized 
with C code or not.  If so, add ctype type for intbv (like numpy folks 
did for arrays).  Then attributes etc. can easily be accessible from 
C?

> (including Signal) overhead being what it is, we can't expect 
>miracles.
> 
> (Until the py.py team delivers a Python that is 10 times faster :-))
> 
> Jan
> 
> ----
> 
> Wed Feb 13 18:36:07 2008    runprof
> 
>          536613094 function calls (523280085 primitive calls) in 
>2643.025 CPU seconds
> 
>    Ordered by: internal time
> 
>    ncalls  tottime  percall  cumtime  percall 
>filename:lineno(function)
>  19119681  257.504    0.000  461.618    0.000 
>_intbv.py:148(__setitem__)
>        12  244.692   20.391 2623.724  218.644 _Simulation.py:95(run)
>  27579102  222.675    0.000  390.886    0.000 
>_Signal.py:180(_set_next)
>   2092116  144.248    0.000  937.835    0.000 _Waiter.py:184(next)
>  89188746  139.018    0.000  139.018    0.000 {isinstance}
>  25572768  126.633    0.000  126.633    0.000 
>_intbv.py:80(_checkBounds)
>   4748554  108.021    0.000 1078.335    0.000 _Waiter.py:152(next)
>  19675183  105.021    0.000  105.021    0.000 _Signal.py:46(purge)
> 41201947/30501215   94.226    0.000  168.693    0.000 {cmp}
> 27633083/26039251   93.698    0.000  248.657    0.000 
>_Signal.py:426(__cmp__)
>  10615743   93.432    0.000  140.551    0.000 
>_intbv.py:121(__getitem__)
>  28024120   84.658    0.000  107.350    0.000 
>_Signal.py:151(_update)
>    668592   76.952    0.000  447.660    0.001 xxx.py:131(xxx)
> 13568864/13268586   75.899    0.000  127.541    0.000 
>_intbv.py:428(__cmp__)
>  63303336   75.171    0.000   75.171    0.000 {method 'append' of 
>'list' objects}
>  25711177   61.852    0.000   61.852    0.000 
>_Signal.py:224(_setNextBool)
>   8153851   43.938    0.000  122.899    0.000 
>_Signal.py:284(__getitem__)
>  33114023   38.130    0.000   38.130    0.000 {id}
>  29873445   33.188    0.000   33.188    0.000 {method 'extend' of 
>'list' objects}
>   3053592   31.259    0.000   50.400    0.000 _intbv.py:39(__init__)
> 
> 
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] newb question

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

Jan Decaluwe wrote:
> Christopher L. Felton wrote:
> 
> 
>>For this test, most people would not simulate this design this way.   
>>The design has a simple state machine
>>that controls the inputs to a bank of pwm's (controls the duty  
>>cycle).  But the state machine goes to the next
>>state on the order of 100ms real-time.  But since the simulation has  
>>little logic and the logic switches minimally
>>it seemed like a good test to profile the MyHDL simulation execution
>>(most the time spent in the simulation code and not the logic code).
> 
> 
> This seems to imply that more "typical" code (e.g. with more logic
> inside generators) could have a relatively larger intbv overhead,
> and therefore more to gain from intbv optimization.
> 
> I'll see if I can do a profiling check on my recent designs.

Below you find a profiling output of a recent test plan. I believe this
is quite representative for the code I tend to write.

I used Python 2.5, cProfile, ordered by time (first 20 items).

I use intbv slicing a lot, and you see this takes a considerable amount
of time.

It seems that optimizing intbv would help significantly, but the Simulation
(including Signal) overhead being what it is, we can't expect miracles.

(Until the py.py team delivers a Python that is 10 times faster :-))

Jan

----

Wed Feb 13 18:36:07 2008    runprof

          536613094 function calls (523280085 primitive calls) in 2643.025 CPU seconds

    Ordered by: internal time

    ncalls  tottime  percall  cumtime  percall filename:lineno(function)
  19119681  257.504    0.000  461.618    0.000 _intbv.py:148(__setitem__)
        12  244.692   20.391 2623.724  218.644 _Simulation.py:95(run)
  27579102  222.675    0.000  390.886    0.000 _Signal.py:180(_set_next)
   2092116  144.248    0.000  937.835    0.000 _Waiter.py:184(next)
  89188746  139.018    0.000  139.018    0.000 {isinstance}
  25572768  126.633    0.000  126.633    0.000 _intbv.py:80(_checkBounds)
   4748554  108.021    0.000 1078.335    0.000 _Waiter.py:152(next)
  19675183  105.021    0.000  105.021    0.000 _Signal.py:46(purge)
41201947/30501215   94.226    0.000  168.693    0.000 {cmp}
27633083/26039251   93.698    0.000  248.657    0.000 _Signal.py:426(__cmp__)
  10615743   93.432    0.000  140.551    0.000 _intbv.py:121(__getitem__)
  28024120   84.658    0.000  107.350    0.000 _Signal.py:151(_update)
    668592   76.952    0.000  447.660    0.001 xxx.py:131(xxx)
13568864/13268586   75.899    0.000  127.541    0.000 _intbv.py:428(__cmp__)
  63303336   75.171    0.000   75.171    0.000 {method 'append' of 'list' objects}
  25711177   61.852    0.000   61.852    0.000 _Signal.py:224(_setNextBool)
   8153851   43.938    0.000  122.899    0.000 _Signal.py:284(__getitem__)
  33114023   38.130    0.000   38.130    0.000 {id}
  29873445   33.188    0.000   33.188    0.000 {method 'extend' of 'list' objects}
   3053592   31.259    0.000   50.400    0.000 _intbv.py:39(__init__)


-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] List of Signals

[Vanheesbeke S. <Ste...@va...>]

Terrific, this is what I looked for, and indeed as you siggest the solution was already ion other posts...

For a reference to others I send my little sample application, modified.

Thanks

<code>
from myhdl import *

def TestFunc(Clk, Reset, Enable, DataIn, DataOut):
   
    @always(Clk.posedge, Reset.posedge)
    def functionality():
        if Reset:
            DataOut.next = 0
        elif Enable:
            DataOut.next = DataIn

    return functionality

def TestFixed(Clk, Reset, Enable, DataIn, DataOut, Size=3):
    #Size not used in fixed implementation (fixed to 3)

    Out0 = Signal(bool(0))
    Out1 = Signal(bool(0))
    Out2 = Signal(bool(0))
    In0 = Signal(bool(0))
    In1 = Signal(bool(0))
    In2 = Signal(bool(0))

    @always_comb
    def Connect():
        In0.next = DataIn
        In1.next = Out0
        In2.next = Out1
        DataOut.next = Out2

    blocks = []
    blocks.append(TestFunc(Clk, Reset, Enable, In0, Out0))
    blocks.append(TestFunc(Clk, Reset, Enable, In1, Out1))
    blocks.append(TestFunc(Clk, Reset, Enable, In2, Out2))
   
    return Connect, blocks

def Connect(In, Out):
    @always_comb
    def connect():
        Out.next = In
    return connect

def TestGeneric(Clk, Reset, Enable, DataIn, DataOut, Size=3):

    Out = [Signal(bool(0)) for i in range(Size)]
    In  = [Signal(bool(0)) for i in range(Size)]
        
    connect = []
    connect.append(Connect(DataIn, In[0]))
    for k in range(1,Size):
        connect.append(Connect(Out[k-1], In[k]))
    connect.append(Connect(Out[Size-1], DataOut))
  
    blocks = []
    for i in range(Size):
        blocks.append(TestFunc(Clk, Reset, Enable, In[i], Out[i]))

    return connect, blocks


def convert_TestFunc():
    """Verify testfunc conversion"""
    Clk     = Signal(bool(0))        
    Reset   = Signal(bool(0))        
    Enable  = Signal(bool(0))        
    DataIn  = Signal(bool(0))
    DataOut = Signal(bool(0))
    toVerilog(TestFunc, Clk, Reset, Enable, DataIn, DataOut)

def convert_TestFixed():
    Clk     = Signal(bool(0))        
    Reset   = Signal(bool(0))        
    Enable  = Signal(bool(0))        
    DataIn  = Signal(bool(0))
    DataOut = Signal(bool(0))
    toVerilog(TestFixed, Clk, Reset, Enable, DataIn, DataOut)

def convert_TestGeneric():
    Clk     = Signal(bool(0))        
    Reset   = Signal(bool(0))        
    Enable  = Signal(bool(0))        
    DataIn  = Signal(bool(0))
    DataOut = Signal(bool(0))
    toVerilog(TestGeneric, Clk, Reset, Enable, DataIn, DataOut)


if __name__ == '__main__':
    convert_TestFunc()
    convert_TestFixed()
    convert_TestGeneric()

</code>

Re: [myhdl-list] List of Signals

[Christopher L. F. <cf...@uc...>]

As a rule for MyHDL you can't use the list syntax inside the behavior  
descriptions, if it is going to be converted to Verilog/VHDL.

>
>    @always_comb
>    def Connect():
>        In[0].next = DataIn
>        for k in range(1,Size):
>            In[k].next=Out[k-1]
>        DataOut.next=Out[Size-1]

The easiest most straight forward way to change it would be to change  
the above always_comb to a separate module that does the combinatorial  
logic for the assignments within the for loop, then make another list  
of instances for that logic, as such.

	def shiftOne(In, Out):
		@always_comb
		def Connect():
			Out.next = In
		return Connect

In TestGeneric, something like follows.
	
	....
	shift_inst = [None for i in range(N)]

	# This will create one shift register
	for i in range(1, Size):
		shift_inst[i] = shiftOne(In[i], Out[i-1])

	...

 From the above hopefully that is enough of an example (example is  
incomplete) to get the idea.

There are other posts in this mail group and solutions as well.  May  
also want to look at the manual, array of instances, the syntax in the  
manual probably safer for generating Verilog.

Hope that helps

On Feb 18, 2008, at 3:36 AM, sv...@te... wrote:

> I want to create a verilog module with a configurable number of  
> instances connected output to intput of the next (like registers in  
> a shift register).
>
> I ran in the "List contains Signals that are not unique to it: In"  
> error, because I defined a list of signals for the inputs and  
> outputs of the instances.
>
> Does someone has an idea how I can solve this?
>
> Included a trivial test module that (indeed) should generate a shift  
> register.
>
> Remark, I know how to do shift registers, this is only to show the  
> problem.
>
> <code>
> from myhdl import *
> from svhb_utils import *
>
> from numpy import *
>
> def TestFunc(Clk, Reset, Enable, DataIn, DataOut):
>
>    @always(Clk.posedge, Reset.posedge)
>    def functionality():
>        if Reset:
>            DataOut.next = 0
>        elif Enable:
>            DataOut.next = DataIn
>
>    return functionality
>
> def TestFixed(Clk, Reset, Enable, DataIn, DataOut, Size=3):
>    #Size not used in fixed implementation (fixed to 3)
>
>    Out0 = Signal(bool(0))
>    Out1 = Signal(bool(0))
>    Out2 = Signal(bool(0))
>    In0 = Signal(bool(0))
>    In1 = Signal(bool(0))
>    In2 = Signal(bool(0))
>
>    @always_comb
>    def Connect():
>        In0.next = DataIn
>        In1.next = Out0
>        In2.next = Out1
>        DataOut.next = Out2
>
>    blocks = []
>    blocks.append(TestFunc(Clk, Reset, Enable, In0, Out0))
>    blocks.append(TestFunc(Clk, Reset, Enable, In1, Out1))
>    blocks.append(TestFunc(Clk, Reset, Enable, In2, Out2))
>
>    return Connect, blocks
>
> def TestGeneric(Clk, Reset, Enable, DataIn, DataOut, Size=3):
>
>    Out = [Signal(bool(0)) for i in range(Size)]
>    In  = [Signal(bool(0)) for i in range(Size)]
>
>    @always_comb
>    def Connect():
>        In[0].next = DataIn
>        for k in range(1,Size):
>            In[k].next=Out[k-1]
>        DataOut.next=Out[Size-1]
>
>    blocks = []
>    for i in range(Size):
>        blocks.append(TestFunc(Clk, Reset, Enable, In[i], Out[i]))
>
>    return Connect, blocks
>
>
> def convert_TestFunc():
>    """Verify testfunc conversion"""
>    Clk     = Signal(bool(0))
>    Reset   = Signal(bool(0))
>    Enable  = Signal(bool(0))
>    DataIn  = Signal(bool(0))
>    DataOut = Signal(bool(0))
>    toVerilog(TestFunc, Clk, Reset, Enable, DataIn, DataOut)
>
> def convert_TestFixed():
>    Clk     = Signal(bool(0))
>    Reset   = Signal(bool(0))
>    Enable  = Signal(bool(0))
>    DataIn  = Signal(bool(0))
>    DataOut = Signal(bool(0))
>    toVerilog(TestFixed, Clk, Reset, Enable, DataIn, DataOut)
>
> def convert_TestGeneric():
>    Clk     = Signal(bool(0))
>    Reset   = Signal(bool(0))
>    Enable  = Signal(bool(0))
>    DataIn  = Signal(bool(0))
>    DataOut = Signal(bool(0))
>    toVerilog(TestGeneric, Clk, Reset, Enable, DataIn, DataOut)
>
>
> if __name__ == '__main__':
>    convert_TestFunc()
>    convert_TestFixed()
>    convert_TestGeneric()
>
> </code>
>
> Stefaan
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] List of Signals

[<sv...@te...>]

I want to create a verilog module with a configurable number of instances connected output to intput of the next (like registers in a shift register).

I ran in the "List contains Signals that are not unique to it: In" error, because I defined a list of signals for the inputs and outputs of the instances.

Does someone has an idea how I can solve this?

Included a trivial test module that (indeed) should generate a shift register. 

Remark, I know how to do shift registers, this is only to show the problem.

<code>
from myhdl import *
from svhb_utils import *

from numpy import *

def TestFunc(Clk, Reset, Enable, DataIn, DataOut):

    @always(Clk.posedge, Reset.posedge)
    def functionality():
        if Reset:
            DataOut.next = 0
        elif Enable:
            DataOut.next = DataIn

    return functionality

def TestFixed(Clk, Reset, Enable, DataIn, DataOut, Size=3):
    #Size not used in fixed implementation (fixed to 3)

    Out0 = Signal(bool(0))
    Out1 = Signal(bool(0))
    Out2 = Signal(bool(0))
    In0 = Signal(bool(0))
    In1 = Signal(bool(0))
    In2 = Signal(bool(0))

    @always_comb
    def Connect():
        In0.next = DataIn
        In1.next = Out0
        In2.next = Out1
        DataOut.next = Out2

    blocks = []
    blocks.append(TestFunc(Clk, Reset, Enable, In0, Out0))
    blocks.append(TestFunc(Clk, Reset, Enable, In1, Out1))
    blocks.append(TestFunc(Clk, Reset, Enable, In2, Out2))
   
    return Connect, blocks
    
def TestGeneric(Clk, Reset, Enable, DataIn, DataOut, Size=3):

    Out = [Signal(bool(0)) for i in range(Size)]
    In  = [Signal(bool(0)) for i in range(Size)]
        
    @always_comb
    def Connect():
        In[0].next = DataIn
        for k in range(1,Size):
            In[k].next=Out[k-1]
        DataOut.next=Out[Size-1]

    blocks = []
    for i in range(Size):
        blocks.append(TestFunc(Clk, Reset, Enable, In[i], Out[i]))

    return Connect, blocks


def convert_TestFunc():
    """Verify testfunc conversion"""
    Clk     = Signal(bool(0))        
    Reset   = Signal(bool(0))        
    Enable  = Signal(bool(0))        
    DataIn  = Signal(bool(0))
    DataOut = Signal(bool(0))
    toVerilog(TestFunc, Clk, Reset, Enable, DataIn, DataOut)

def convert_TestFixed():
    Clk     = Signal(bool(0))        
    Reset   = Signal(bool(0))        
    Enable  = Signal(bool(0))        
    DataIn  = Signal(bool(0))
    DataOut = Signal(bool(0))
    toVerilog(TestFixed, Clk, Reset, Enable, DataIn, DataOut)

def convert_TestGeneric():
    Clk     = Signal(bool(0))        
    Reset   = Signal(bool(0))        
    Enable  = Signal(bool(0))        
    DataIn  = Signal(bool(0))
    DataOut = Signal(bool(0))
    toVerilog(TestGeneric, Clk, Reset, Enable, DataIn, DataOut)


if __name__ == '__main__':
    convert_TestFunc()
    convert_TestFixed()
    convert_TestGeneric()

</code>

Stefaan

Re: [myhdl-list] newb question

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

Christopher L. Felton wrote:

> For this test, most people would not simulate this design this way.   
> The design has a simple state machine
> that controls the inputs to a bank of pwm's (controls the duty  
> cycle).  But the state machine goes to the next
> state on the order of 100ms real-time.  But since the simulation has  
> little logic and the logic switches minimally
> it seemed like a good test to profile the MyHDL simulation execution
> (most the time spent in the simulation code and not the logic code).

This seems to imply that more "typical" code (e.g. with more logic
inside generators) could have a relatively larger intbv overhead,
and therefore more to gain from intbv optimization.

I'll see if I can do a profiling check on my recent designs.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

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

Neal Becker wrote:
> Hi.  I just discovered myhdl.  I'm very interested.
> 
> Haven't tried any coding yet, just reading the docs - but I was immediately
> struck by the thought that intbv is going to be awfully slow coded in
> python - seems to cry out for a c++ implementation.  Is this worth
> pursuing?

I believe it is. At this point it's the first optimization I would
consider. There are a lot of attribute lookups that we could get
rid off. Also, slice assignment is often used and probably slow.
But this is just based on gut feeling - I have no quantitative data
to back it up.

Ideas on how to proceed:
* design some profiling test to check whether it's worth the trouble
and what to expect
* intbv is really like a long, so best to start from Python's long module
* perhaps best to use a Python in which int and long have completely
converged?
* on this occasion, review the intbv interface itself thoroughly,
some changes may be worthwhile

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

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

Thomas Heller wrote:

> IIUC, this means that modelsim is (only) a factor of ~5 faster?

I have some relevant data from a recent project. With the newest
MyHDL (development version) I can convert a test plan suited
to run under py.test to an equivalent test plan in VHDL and
in Verilog (significant coding restrictions apply, as always).

So it becomes easy to compare run times. The result for the
project were as follows:

MyHDL                        281s
modelsim VHDL RTL             21s
modelsim Verilog, gate level  41s

So VHDL RTL ran 13.4 times faster, Verilog gate level 6.9 times
faster for this project.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] newb question

[Thomas H. <th...@ct...>]

Christopher L. Felton schrieb:
> I don't have an exact number because Modelsim doesn't dump the time  
> running when it is complete.
> This particular simulation was setup to run for 4 seconds simulation  
> time with a 100ns simulation step.
> My guesstimate was that Modelsim took between 2hrs - 3hrs because  
> Modeslsim took 15-20 minutes
> to simulate 500ms.

IIUC, this means that modelsim is (only) a factor of ~5 faster?

> For this test, most people would not simulate this design this way.   
> The design has a simple state machine
> that controls the inputs to a bank of pwm's (controls the duty  
> cycle).  But the state machine goes to the next
> state on the order of 100ms real-time.  But since the simulation has  
> little logic and the logic switches minimally
> it seemed like a good test to profile the MyHDL simulation execution
> (most the time spent in the simulation code and not the logic code).
> 
> Also, I should be a little careful because I have not verified the  
> generated Verilog is 100% logically equivalent to
> the MyHDL logic.  I have only spot checked this with the waveform  
> outputs.

Well, we all know what benchmakrs tell us ;-)

Thomas

Re: [myhdl-list] newb question

[Christopher L. F. <cf...@uc...>]

I don't have an exact number because Modelsim doesn't dump the time  
running when it is complete.
This particular simulation was setup to run for 4 seconds simulation  
time with a 100ns simulation step.
My guesstimate was that Modelsim took between 2hrs - 3hrs because  
Modeslsim took 15-20 minutes
to simulate 500ms.

For this test, most people would not simulate this design this way.   
The design has a simple state machine
that controls the inputs to a bank of pwm's (controls the duty  
cycle).  But the state machine goes to the next
state on the order of 100ms real-time.  But since the simulation has  
little logic and the logic switches minimally
it seemed like a good test to profile the MyHDL simulation execution
(most the time spent in the simulation code and not the logic code).

Also, I should be a little careful because I have not verified the  
generated Verilog is 100% logically equivalent to
the MyHDL logic.  I have only spot checked this with the waveform  
outputs.

On Feb 8, 2008, at 11:24 AM, Thomas Heller wrote:

> Christopher L. Felton schrieb:
>> Couple more comments on this topic.
>>
>> One issue if the simulation were to be enhanced by C functions (no
>> need for C++) the build and distribution would become much more work
>> to build and build for the various platforms.
>>
>> But with that said, there have been posts that the simulation speed
>> in some cases seem a bit slow.  I used the python tool cProfile to
>> capture some information on a simulation.
>>
>> The following was a simulation that wasn't horribly efficient as
>> simulations go. The logic included some pwm's and other slowly
>> changing signals.  There were many clock cycles per event (many
>> simulation steps).  But to keep everything relative I had to keep the
>> ratio high (many clk/sim step per event).  The good thing is that
>> because it was a long simulation most of the cProfile errors should
>> of averaged out (this is my first experience with the python profile
>> tools).
>>
>> The MyHDL simulation took 50078.309 CPU seconds (~13 hours) where the
>> converted Verilog with same testbench (same timescale, etc) ran on
>> Modelsim was much shorter.
>>
>
> How long did it take in Modelsim?  Just curious;-)
>
> Thomas
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] newb question

[Thomas H. <th...@ct...>]

Christopher L. Felton schrieb:
> Couple more comments on this topic.
> 
> One issue if the simulation were to be enhanced by C functions (no
> need for C++) the build and distribution would become much more work
> to build and build for the various platforms.
> 
> But with that said, there have been posts that the simulation speed
> in some cases seem a bit slow.  I used the python tool cProfile to
> capture some information on a simulation.
> 
> The following was a simulation that wasn't horribly efficient as
> simulations go. The logic included some pwm's and other slowly
> changing signals.  There were many clock cycles per event (many
> simulation steps).  But to keep everything relative I had to keep the
> ratio high (many clk/sim step per event).  The good thing is that
> because it was a long simulation most of the cProfile errors should
> of averaged out (this is my first experience with the python profile
> tools).
> 
> The MyHDL simulation took 50078.309 CPU seconds (~13 hours) where the
> converted Verilog with same testbench (same timescale, etc) ran on
> Modelsim was much shorter.
> 

How long did it take in Modelsim?  Just curious;-)

Thomas