myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] Shadow signals

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

Christopher Felton wrote:
> On Tue, Jun 23, 2009 at 3:47 AM, Jan Decaluwe <ja...@ja...> wrote:
>> Basically I tried to address the problem that some of
>> you have struggled with: the inflexibility of MyHDL signals.
>> For example, the fact that signal slices don't behave
>> as signals.
>>
>> It's all documented here:
>>
>>    http://www.myhdl.org/doku.php/meps:mep-105
>>
>> Feedback welcome!
>>
>> Jan
> 
> I pulled the latest code from the repository this morning and was
> unable to check if a variable was a "Signal".  It looks like the
> "Signal" changed from a class to a function?

Yes, I turned it into a factory function. The existing implementation
was way to complex (i.e. using __new__ to construct different Signal
subclasses depending on constructor parameters. With the additional
Signal subclasses coming up, this was becoming really ugly.

I thought this would be an innocent change - I didn't anticipate
that a MyHDL user would ever need to test whether an object belongs
to the Signal class. Why do you need this?

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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] sets.py: DeprecationWarning

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

James F. Carroll wrote:
> MyHDL Users,
> 
> I installed Python 2.6 and MyHDL 0.6.0 on Windows.  When I run the 
> "hello world" example, I get the following warning:
> 
>     C:\Python26\lib\sets.py:85: DeprecationWarning: functions overriding
>     warnings.showwarning() must support the 'line' argument
> 
>       stacklevel=2)
> 
>     ** DeprecationWarning: the sets module is deprecated
> 
> 
> Is this warning normal?  

Yes, with Python 2.6. This is solved in development, using
the built-in set.

> Should we support the 'line' argument?

Probably, same reason.



-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] sets.py: DeprecationWarning

[James F. C. <jca...@by...>]

MyHDL Users,
I installed Python 2.6 and MyHDL 0.6.0 on Windows.  When I run the "hello
world" example, I get the following warning:

C:\Python26\lib\sets.py:85: DeprecationWarning: functions overriding
> warnings.showwarning() must support the 'line' argument

  stacklevel=2)

** DeprecationWarning: the sets module is deprecated


Is this warning normal?  Should we support the 'line' argument?

Details on my install:

   - Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit
   (Intel)] on win32
   - Windows XP SP3

Cheers,

James Carroll

Research Assistant
Configurable Computing Lab
Brigham Young University
jca...@by...

Re: [myhdl-list] a few questions relating to recursive designs

[Geoffrey B. <geo...@gm...>]

I haven't downloaded the development snapshot, but I'm pretty certain
that what you have designed will work -- either bottom up by concatenating
signals or top down by splitting signals.

In my heart, I wish the extra syntax wasn't needed; however, I take your
point about the efficiency of compiled vs interpreted simulation with
respect
to compound signals.

In any case, I appreciate the effort you've taken in reaction to
the demands of your user community

Geoffrey

On Tue, Jun 23, 2009 at 4:51 AM, Jan Decaluwe <ja...@ja...> wrote:

> Geoffrey Brown wrote:
> > I thought I'd plunge in with a recursive structure (an N-way mux) which
> > follows.  I'm embarrassed
> > how long it took me to figure this out.   Now here are a few questions.
> >
> > 1)  I wanted to use a selector both as a bit vector and an integer.
> > Naturally
> >    I made a signal from an intbv, but found the hard way that the obvious
> >    thing, picking off bits by slicing, doesn't give you what is needed
> > (in this
> >    context) -- another signal which has a subset of the bits from the
> > original
> >
>
> Geoffrey:
>
> Please check whether a _SliceSignal would solve your problem:
>
> http://www.myhdl.org/doku.php/meps:mep-105
>
> --
> 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
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of unconference:
> $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
>
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] Shadow signals

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

On Tue, Jun 23, 2009 at 3:47 AM, Jan Decaluwe <ja...@ja...> wrote:
>
> Basically I tried to address the problem that some of
> you have struggled with: the inflexibility of MyHDL signals.
> For example, the fact that signal slices don't behave
> as signals.
>
> It's all documented here:
>
>    http://www.myhdl.org/doku.php/meps:mep-105
>
> Feedback welcome!
>
> Jan

I pulled the latest code from the repository this morning and was
unable to check if a variable was a "Signal".  It looks like the
"Signal" changed from a class to a function?

What would be the correct approach now to check a variable type (see
example below)?  Would old code be converted to check type
myhdl._Signal versus myhdl.Signal?

This change (which is good) would not be backward compatible?

My "use case", I have used this in modeling modules.  A module might
be used outside myhdl environment and will except basic inputs.  The
same module is used in a testbench and thus the module is flexible to
use a Signal or not.

Example code that previously was valid.
>>> from myhdl import Signal, intbv
>>> x = Signal(intbv(0))
>>> isinstance(x, Signal)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: isinstance() arg 2 must be a class, type, or tuple of
classes and types

Thanks
Chris

Re: [myhdl-list] Shadow signals

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

Jan Decaluwe wrote:
> I just went to a few weeks of creative work, I hope
         ^^^^^^^
         went through    (it's done :-)

Re: [myhdl-list] a few questions relating to recursive designs

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

Geoffrey Brown wrote:
> I thought I'd plunge in with a recursive structure (an N-way mux) which 
> follows.  I'm embarrassed
> how long it took me to figure this out.   Now here are a few questions.
> 
> 1)  I wanted to use a selector both as a bit vector and an integer.  
> Naturally
>    I made a signal from an intbv, but found the hard way that the obvious
>    thing, picking off bits by slicing, doesn't give you what is needed 
> (in this
>    context) -- another signal which has a subset of the bits from the 
> original
> 

Geoffrey:

Please check whether a _SliceSignal would solve your problem:

http://www.myhdl.org/doku.php/meps:mep-105

-- 
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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Lists of signals as synthesizable arguments

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

Eric Jonas wrote:
> I'm trying to construct modules that will take in lists of signals and
> gang them together as address lines, where I don't want to manually
> break out those signals or pre-invocation gang them into a single
> signal. 

Eric,

please check whether the ConcatSignal would be a solution for
your problem:

http://www.myhdl.org/doku.php/meps:mep-105

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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Shadow signals

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

I just went to a few weeks of creative work, I hope
you will like the results :-)

Basically I tried to address the problem that some of
you have struggled with: the inflexibility of MyHDL signals.
For example, the fact that signal slices don't behave
as signals.

It's all documented here:

    http://www.myhdl.org/doku.php/meps:mep-105

Feedback welcome!

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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Automatic registration on myhdl.org disabled

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

Through problems of a user I just realized that automatic
registration on myhdl.org was broken: on webfaction it is
not by default possible to send emails from php-based
sites.

The symptom is that you don't get a confirmation email
upon registration (or for any other purpose for that matter.)

I have disabled automatic registration and I have added
as page that says that one should email me to request
an account:

http://www.myhdl.org/doku.php/request_account

Sorry for the inconvenience. Solving this would require some
php patching to dokuwiki - I'm not sure whether this
is worth the trouble.

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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] TimingAnalyzer -- request for opinions

[Dan F. <dfa...@ya...>]

> 
> Dan,
> 
> That would be a useful "feature" automatic myhdl testbench creation and
> validation based on a timing-diagram.
> Chris
> 
> 
> I agree; it sounds like a great idea.  What is your time frame and resources? 
Are you able to work on it full-time?
> Cheers,James 

I agree this would be useful and its possible now to generate test vectors from
a timing diagram using java scripts. I have written scripts to generate detailed
timing diagrams for microprocessor transactions like read and write cycles so
you can run the scripts multiple times to show back to back transactions.  

This is a feature in the program now. Scripting to add features, generate test
vectors, create testbenches, or draw timing diagrams. There are example scripts
that do some of these things now.

I would need some help with this.  I just learning python and don't have any
experience with open source projects.  First, I want to convert most of the code
converted to python so there is a functional program that can be used as the
start for the open source repository.  I don't have any planned time frame but I
think the conversion should take about 3 months. I'm the only one working on it
part time. 

Let me know what you think.
Thanks,  Dan 

Re: [myhdl-list] TimingAnalyzer -- request for opinions

[James F. C. <jca...@by...>]

Dan,

On Thu, Jun 18, 2009 at 11:49 AM, Christopher L. Felton <
chr...@gm...> wrote:

> On Thu, Jun 18, 2009 at 11:19 AM, Dan Fabrizio <dfa...@ya...> wrote:
> >
> > I'm the author of the TimingAnalyzer.
> >
> > I was hoping to get your opinions about this, and see if anyone might
> > have any ideas for using this with MyHDL?
>
> That would be a useful "feature" automatic myhdl testbench creation and
> validation based on a timing-diagram.
>
> Chris
>

I agree; it sounds like a great idea.  What is your time frame and
resources?  Are you able to work on it full-time?

Cheers,

James Carroll

Research Assistant
Configurable Computing Lab
Brigham Young University
jca...@by...

Re: [myhdl-list] TimingAnalyzer -- request for opinions

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

>
> I'm the author of the TimingAnalyzer.  
>  
> www.timing-diagrams.com
>  
> I'm considering converting the program from Java to Python and making 
> the project open source.  With a scripting interface in Python, you 
> can make complex timing diagrams quickly with part delays and 
> constraints.  It will also display simulation outputs from VCD files 
> so you can easily convert them to timing diagrams.  
>  
> I was hoping to get your opinions about this, and see if anyone might 
> have any ideas for using this with MyHDL?    
>  
A previous user, George, had explored some options with using a 
text-based timing diagram definition.  This would allow a developer to 
define a timing diagram and create a testbench (BOMK). 

That would be a useful "feature" automatic myhdl testbench creation and 
validation based on a timing-diagram.

There are some threads on the text based topic in this newgroup.

Side note, wxpython (wxwidgets) in my experience, is a good GUI toolbox 
that is supported on multiple platforms, linux, mac, widows, etc.  I 
always use the WXAgg configuration for matplotlib on linux, mac, and 
windows.

Chris

[myhdl-list] TimingAnalyzer -- request for opinions

[Dan F. <dfa...@ya...>]

Hello All, 
 
I'm the author of the TimingAnalyzer.   
 
www.timing-diagrams.com 
 
I'm considering converting the program from Java to Python and making  
the project open source.  With a scripting interface in Python, you  
can make complex timing diagrams quickly with part delays and  
constraints.  It will also display simulation outputs from VCD files  
so you can easily convert them to timing diagrams.   
 
I was hoping to get your opinions about this, and see if anyone might  
have any ideas for using this with MyHDL?     
 

Thanks,
Dan Fabrizio 


      

Re: [myhdl-list] verilog conversion bug ?

[Geoffrey B. <geo...@gm...>]

Thanks.  I was pretty sure I understood why the Verilog behaves the way it
does, but as you say, the converter should refuse to convert.  Actually,
I think the right thing to do is to forbid  next on the rhs (it should be
write-only)

Thus

y = x.next

should be illegal in any context.

Geoffrey

On Sat, Jun 13, 2009 at 3:05 PM, Jan Decaluwe <ja...@ja...> wrote:

> The bug is that the convertor should refuse to convert this.
> In Verilog and VHDL, there is no way to check on the future value
> of a signal (non-blocking assignment.)
>
> If you need this functionality, you have to use variables instead
> of signals.
>
> Jan
>
>
> Geoffrey Brown wrote:
> > The following is an attempt to create a simple PWM module.   When I
> > simulate in myhdl and simulate the generated verilog in quartus,
> > I get different results.  Specifically the "pulse" output is delayed one
> > clock period in quartus which suggests that my use of
> > count.next in myhdl doesn't translate into semantically equivalent
> > verilog.  Clearly, I can rewrite things to get the behavior
> > I want, but I'm worried about the inconsistency.
> >
> > from myhdl import *
> >
> >
> >
> > def pwm(clk, clken, width, cycles, pulse):
> >
> >     count = Signal(intbv(0,cycles.min,cycles.max))
> >
> >     @always(clk.posedge)
> >     def pwmlogic():
> >         if (clken):
> >             if (count == cycles):
> >                 count.next = 0
> >             else:
> >                 count.next = count + 1
> >             if (count.next < width):
> >                 pulse.next = 1
> >             else:
> >                 pulse.next = 0
> >
> >     return pwmlogic
> >
> > if __name__ == '__main__':
> >
> >     from random import randrange
> >     clk     = Signal(bool(0))
> >     clken   = Signal(bool(0))
> >     width   = Signal(intbv(8)[4:])
> >     cycles  = Signal(intbv(12)[4:])
> >     pulse   = Signal(bool(0))
> >
> >     def test():
> >         cnt = 0
> >         for i in range(1000):
> >             yield delay(10)
> >             clk.next = not clk
> >             if (clk):
> >                 if (cnt == 15):
> >                     clken.next = 1
> >                     cnt = 0
> >                 else:
> >                     clken.next = 0
> >                     cnt = cnt + 1
> >     pwmbody = traceSignals(pwm, clk, clken, width, cycles, pulse)
> >     test1 = test()
> >     sim = Simulation(pwmbody, test1)
> >     sim.run(quiet=1)
> >
> >     toVerilog(pwm, clk, clken, width, cycles, pulse)
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> ------------------------------------------------------------------------------
> > Crystal Reports - New Free Runtime and 30 Day Trial
> > Check out the new simplified licensing option that enables unlimited
> > royalty-free distribution of the report engine for externally facing
> > server and web deployment.
> > http://p.sf.net/sfu/businessobjects
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] verilog conversion bug ?

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

The bug is that the convertor should refuse to convert this.
In Verilog and VHDL, there is no way to check on the future value
of a signal (non-blocking assignment.)

If you need this functionality, you have to use variables instead
of signals.

Jan


Geoffrey Brown wrote:
> The following is an attempt to create a simple PWM module.   When I 
> simulate in myhdl and simulate the generated verilog in quartus,
> I get different results.  Specifically the "pulse" output is delayed one 
> clock period in quartus which suggests that my use of
> count.next in myhdl doesn't translate into semantically equivalent 
> verilog.  Clearly, I can rewrite things to get the behavior
> I want, but I'm worried about the inconsistency.
> 
> from myhdl import *
> 
> 
> 
> def pwm(clk, clken, width, cycles, pulse):
>    
>     count = Signal(intbv(0,cycles.min,cycles.max))
> 
>     @always(clk.posedge)
>     def pwmlogic():
>         if (clken):
>             if (count == cycles):
>                 count.next = 0
>             else:
>                 count.next = count + 1
>             if (count.next < width):
>                 pulse.next = 1
>             else:
>                 pulse.next = 0
>            
>     return pwmlogic
> 
> if __name__ == '__main__':
> 
>     from random import randrange
>     clk     = Signal(bool(0))
>     clken   = Signal(bool(0))
>     width   = Signal(intbv(8)[4:])
>     cycles  = Signal(intbv(12)[4:])
>     pulse   = Signal(bool(0))
> 
>     def test():
>         cnt = 0
>         for i in range(1000):
>             yield delay(10)
>             clk.next = not clk
>             if (clk):
>                 if (cnt == 15):
>                     clken.next = 1
>                     cnt = 0
>                 else:
>                     clken.next = 0
>                     cnt = cnt + 1
>     pwmbody = traceSignals(pwm, clk, clken, width, cycles, pulse)
>     test1 = test()
>     sim = Simulation(pwmbody, test1)
>     sim.run(quiet=1)
> 
>     toVerilog(pwm, clk, clken, width, cycles, pulse)
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] verilog conversion bug ?

[Geoffrey B. <geo...@gm...>]

No testbench -- I just simulated with the VCD file generated by the myhdl
module.   So the simulation output of myhdl became the driver for quartus.


Geoffrey

On Sat, Jun 13, 2009 at 9:39 AM, Felton Christopher
<chr...@gm...>wrote:

> On Jun 12, 2009, at 2:33 PM, Geoffrey Brown wrote:
>
> > The following is an attempt to create a simple PWM module.   When I
> > simulate in myhdl and simulate the generated verilog in quartus,
> > I get different results.  Specifically the "pulse" output is delayed
> > one clock period in quartus which suggests that my use of
> > count.next in myhdl doesn't translate into semantically equivalent
> > verilog.  Clearly, I can rewrite things to get the behavior
> > I want, but I'm worried about the inconsistency.
>
> Do you have your Verilog testbench for Quartus, think it might be is
> mismatch in your testbenches and not the pwm module.  Does you clken
> change on the falling edge of clock in your Verilog testbench as well?
>
> Chris
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

Re: [myhdl-list] verilog conversion bug ?

[Felton C. <chr...@gm...>]

On Jun 12, 2009, at 2:33 PM, Geoffrey Brown wrote:

> The following is an attempt to create a simple PWM module.   When I  
> simulate in myhdl and simulate the generated verilog in quartus,
> I get different results.  Specifically the "pulse" output is delayed  
> one clock period in quartus which suggests that my use of
> count.next in myhdl doesn't translate into semantically equivalent  
> verilog.  Clearly, I can rewrite things to get the behavior
> I want, but I'm worried about the inconsistency.

Do you have your Verilog testbench for Quartus, think it might be is  
mismatch in your testbenches and not the pwm module.  Does you clken  
change on the falling edge of clock in your Verilog testbench as well?

Chris

[myhdl-list] verilog conversion bug ?

[Geoffrey B. <geo...@gm...>]

The following is an attempt to create a simple PWM module.   When I simulate
in myhdl and simulate the generated verilog in quartus,
I get different results.  Specifically the "pulse" output is delayed one
clock period in quartus which suggests that my use of
count.next in myhdl doesn't translate into semantically equivalent verilog.
Clearly, I can rewrite things to get the behavior
I want, but I'm worried about the inconsistency.

from myhdl import *



def pwm(clk, clken, width, cycles, pulse):

    count = Signal(intbv(0,cycles.min,cycles.max))

    @always(clk.posedge)
    def pwmlogic():
        if (clken):
            if (count == cycles):
                count.next = 0
            else:
                count.next = count + 1
            if (count.next < width):
                pulse.next = 1
            else:
                pulse.next = 0

    return pwmlogic

if __name__ == '__main__':

    from random import randrange
    clk     = Signal(bool(0))
    clken   = Signal(bool(0))
    width   = Signal(intbv(8)[4:])
    cycles  = Signal(intbv(12)[4:])
    pulse   = Signal(bool(0))

    def test():
        cnt = 0
        for i in range(1000):
            yield delay(10)
            clk.next = not clk
            if (clk):
                if (cnt == 15):
                    clken.next = 1
                    cnt = 0
                else:
                    clken.next = 0
                    cnt = cnt + 1
    pwmbody = traceSignals(pwm, clk, clken, width, cycles, pulse)
    test1 = test()
    sim = Simulation(pwmbody, test1)
    sim.run(quiet=1)

    toVerilog(pwm, clk, clken, width, cycles, pulse)

Re: [myhdl-list] arithmetic trouble

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

Christopher Felton wrote:
> 
> 
> On Sat, May 16, 2009 at 2:16 AM, Jan Decaluwe <ja...@ja... 
> <mailto:ja...@ja...>> wrote:
> 
>     Christopher L. Felton wrote:
> 
>      > But the questions can be asked, since the operation is broken into
>      > intermediate steps, could the converter do this?  Could it
>     automagically
>      > break a complex operation into multiple steps?
> 
>     It could potentially do this, just as it now does resizes in VHDL.
>     Of course it may not worth the trouble.
> 
>      > I believe you would have to be careful here though.  You do not want
>      > complication or too much inference from the converter.  You would
>     want a
>      > very simple rule for Verilog that could be implemented.  There
>     are many
>      > scenarios where an intermediate result requires a larger bit-value.
>      > Basically anytime a complex operation (equation) has an
>     increasing and
>      > decreasing component you can run into this simulation mismatch.
>      If we
>      > prevent the operations we would have to prevent all combinations of
>      > increasing and decreasing, such as:
>      >   (a + b)  - c
>      >   (a + b)  >> c
>      >   (a * b)  - c
>      >   (a * b)  >> c
>      >   (a << b) - c
>      >   (a << b) >> c
>      > etc, etc.
>      >
>      > Some of these may not make sense (rarely used) but they are all
>     (BOMK)
>      > valid statements.  The verilog converter would have to restrict
>     all of
>      > these or handle all of them.  I don't know which is the best
>     answer, yet.
> 
>     Implementing the restriction is probably easy to do: the right operand
>     of certain operations (>>>, -) should be a plain name.
> 
>     I'm inclined to start with this solution. I guess most designers will
>     find it acceptable.
> 
>     A fundamental solution would be easiest with a resize like in VHDL.
>     Absent that, we would have to infer intermediate variables etc.,
>     which would add all kinds of complexities. Probably not worth the
>     effort at this point.
> 
>     Jan
> 
> 
> Should we add this to the open task list 
> (http://www.myhdl.org/doku.php/dev:tasks) 
> <http://www.myhdl.org/doku.php/dev:tasks>?  As mentioned this is 
> considered a bug because of the simulation mismatch.  Think we have 
> captured information on the issue.  
> 
> Verilog will only use the largest "size" that exists in a expression. 
>  Intermediate results will only be as large as the largest declared reg 
> / wire.  This doesn't match how python handles the operations.  
> 
> Since I have been following this issue, some, I can volunteer for this 
> task.  I just can't promise any fast results. 

Thanks for volunteering! However, after thinking further about it
I believe the problem points to a more fundamental flaw in the
way signedness and sizes are inferred in the Verilog convertor.
I think the VHDL convertor does it right, and it is also more
complex than the Verilog case. I think I need to put something
similar into the Verilog convertor to get it right for the
future. In short, this is not a local change but a major
rewrite - I guess I should clean up my own mess :-)

I think I jumped the original conclusions a little.
If Verilog doesn't have a resize, we can write one or even put
in sign extensions and castings directly. In this way, we can
solve the issues without temporary variables in the same way
as for VHDL conversion. Otherwise, the functionality of
VHDL and Verilog conversion would diverge.

This will take some time. Currently I'm working on solving
the most important remaining flaw in MyHDL: the fact that
sliced signals are not signals, and the problems this creates
occasionally. I think I have a good solution but I need to
work further on it and document it - stay tuned.

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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv return types and a fixed-point Object

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

Christopher Felton wrote:
> 
>      >
>      > The change was to the _intbv.py.  All math operations were changed to
>      > return a intbv type versus an int type.
> 
>     Thanks for the work, that really helps.
> 
>     In your example, the peformance hit is around 7%. Not dramatic perhaps,
>     but not negligible either.
> 
>     On the other hand, we would probably get this back easily (and more) if
>     _intbv.py is redone in C, which may make a lot of sense just like
>     Signal.
> 
>     I still hesitate. If the reason is purely esthetics, that doesn't seem
>     enough for the change. But if there is a valid technical reason, I have
>     nothing against it either. What does the community think?
> 
>     Jan
> 
> 
> If such performance improvements were attempted would it be better to 
> focus on the Signal class.  In the profiles I have captured the Signal 
> class consumes much more than intbv.

It is clear that Signal is expensive. I prefer coding styles in which
they are not over-used.

In many cases Signal wraps an intbv object. From you profiles, is it
always clear to what functionality the time should be attributed?

What you gain by a C implementation is very much dependent on the
module. I once rewrote the basic simulation engine in MyHDL in C,
with almost no gain. If you mainly use the Python API in C, there's
little gain. On the other hand, if you can rewrite numeric operations
in C directly instead of with the Python API, the gains can be
very large. For this reason, I expect the potential relative gains
for intbv to much larger than for Signal.

On the other hand, as you mention, numeric operations that mimic
intbv (or int) may be very tricky in C. I wouldn't want to try it!
The best starting point would probably be the Python int module.

> The C implementations get tricky, cross-compile multiple platforms etc. 
>  Before such an effort is undertaken it might make sense to simply 
> define the C interface.  The numpy folks have done something similar. 
>  Defined "ctypes" types.  
> http://www.scipy.org/Cookbook/Ctypes
> http://mentat.za.net/ctpug-numpy/ctypes.html
> 
> If "ctype" types were defined for intbv and Signal that might be enough 
> to start implementing portions in C-code.
> Ctypes might not be as efficient as actually embedding  C code but could 
> be a easier approach.  I don't have much experience in this area others 
> may want to comment.
> 
> Another major bottleneck is how python handles the generators (schedules 
> them)?  Would this be correct?  Is the simulation performance mainly 
> dictated by this?

Python doesn't schedule the generators. The MyHDL  Simulation does,
according to a strict algorithm that mimics what VHDL does. The simulation
engine contains optimizations already. For example, every generator is
inspected before the simulation starts. Depending on its sensitivity lists,
it is wrapped in an appropriate wrapper to mimimize the number of tests
during simulation. This makes sense because many generators are endless
loops that run over and over again.

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
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] intbv addition

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

On Jun 6, 2009, at 4:32 PM, Christopher L. Felton wrote:

>
>> Dear Chris,
>>
>> Thank you for your reply. I am trying to add numbers in MyHDL, I  
>> tried
>> to add numbers modeled by 'intbv' in two stages; the first was simple
>> program with no 'next' command included, and the other with 'next'.
>> The first one worked as expected but the second one strangely gave
>> weird results, when the numbers are positive, but when they are
>> extended to negative ranges the interpreter complains about exceeding
>> the minimum range of 0.  Here is the code:
>>
>> from myhdl  import Signal, delay, always, intbv, Simulation, bin
>> from random import randrange
>> from math   import pow
>>
>> def AddNum(B):
>>
>>     #interval = delay(10)
>>     max_num = pow(2,B-1) - 1
>>     min_num = -1 * pow(2,B-1)
>>
>>     a = Signal(intbv(0)[B:])
>>     b = Signal(intbv(0)[B:])
>>     c = Signal(intbv(0)[B+1:])

I probably didn't explain very well.  Below is code that works.

from myhdl  import Signal, delay, always, intbv, Simulation, bin
from random import randrange
from math   import pow

def AddNum(B):

    max_num = pow(2,B-1) - 1
    min_num = -1 * pow(2,B-1)

    a = Signal(intbv(0, min_num, max_num))
    b = Signal(intbv(0, min_num, max_num))
    c = Signal(intbv(0, 2*min_num, 2*max_num))

    for i in range(10):

        a.next = randrange(min_num+1, max_num)
        b.next = randrange(min_num+1, max_num)
        c.next = a + b

        yield  delay(10)
        print "i: %s a: %s, b: %s sum = %s binary %s" %(i, a, b, c,  
bin(c, B))


def main():
    bitwidth = 9
    inst = AddNum(bitwidth)
    sim  = Simulation(inst)
    sim.run()


if __name__ == '__main__':
    main()

>>
> The error you are seeing is correct.  There is basically two modes  
> for the intbv.  Constraint integer (see Jan's essay for more info)  
> and the regular bit-vector.  When using the intbv for integer  
> representation, as in your case with negative and positive numbers,  
> you need to define the maximum and minimum.  Instead of defining the  
> number of bits you only need to define the expected max and min for  
> the design.
>
> Example
> a = Signal(intbv(0, min=min_num, max=max_num))
> b = Signal(intbv(0, min=min_num, max=max_num))
> c = Signal(intbv(0, min=min_num, max=max_num))
> This is a little different than what you maybe use to in Verilog or  
> VHDL but it can be very powerful.  When you define the bit width it  
> is expected that the intbv is used as a generic bit array (no  
> numeric value).  But the implicit numeric min is zero and the max is  
> the size of the bit vector.
>
> Hope that helps
>
>>     for i in range(10):
>>
>>         a.next = randrange(0, max_num)
>>         b.next = randrange(0, max_num)
>>         c.next = a + b
>>
>>         yield  delay(10)
>>         print "i: %s a: %s, b: %s sum = %s binary %s" %(i, a, b, c,  
>> bin(c, B))
>>
>>
>> def main():
>>     bitwidth = 9
>>     inst = AddNum(bitwidth)
>>     sim  = Simulation(inst)
>>     sim.run()
>>
>>
>> if __name__ == '__main__':
>>     main()
>>
>> As I said, when negative numbers are used, i.e.
>>
>>  a.next = randrange(min_num, max_num)
>>  b.next = randrange(min_num, max_num)
>>
>> Python complains. What do you think is the problem?
>>
>> On Sat, Jun 6, 2009 at 5:34 PM, Christopher L.
>> Felton<chr...@gm...> wrote:
>>
>>>> a=intbv(3)[2:]
>>>> b=intbv(1)[2:]
>>>> c=a+b
>>>>
>>>> the sum (c) is not 'intbv' class, its 'long' if I'm not mistaken.  
>>>> How
>>>> can we get the sum to be 'intbv' of the same bitwidth (in this case
>>>> 2)?
>>>>
>>>>
>>>>
>>> You would want to do the following (which is the same as other HDLs)
>>>
>>> a = intbv(3)[2:]
>>> b = intbv(1)[2:]
>>> c = intbv(1)[2:]
>>> c[:] = a+b
>>>
>>> As you noticed, the result of the intbv math operations returns an
>>> integer (long).  What you need to do is create an intbv type for the
>>> left hand side of the operation.  For the above example you will  
>>> get an
>>> error.  The intbv will check the limits of addition.  You will  
>>> need to
>>> create "c" to be large enough for the result of the addition.
>>>
>>> c = intbv(1)[3:]
>>>
>>>
>>> Hope that helps, for more background information see Jan's essay on
>>> constraint integer, http://www.jandecaluwe.com/hdldesign/counting.html 
>>> .
>>>
>>> Chris
>>>
>>> ------------------------------------------------------------------------------
>>> OpenSolaris 2009.06 is a cutting edge operating system for  
>>> enterprises
>>> looking to deploy the next generation of Solaris that includes the  
>>> latest
>>> innovations from Sun and the OpenSource community. Download a copy  
>>> and
>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>> _______________________________________________
>>> myhdl-list mailing list
>>> myh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>>
>>>
>>
>>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the  
> latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get_______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] intbv addition

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

> Dear Chris,
>
> Thank you for your reply. I am trying to add numbers in MyHDL, I tried
> to add numbers modeled by 'intbv' in two stages; the first was simple
> program with no 'next' command included, and the other with 'next'.
> The first one worked as expected but the second one strangely gave
> weird results, when the numbers are positive, but when they are
> extended to negative ranges the interpreter complains about exceeding
> the minimum range of 0.  Here is the code:
>
> from myhdl  import Signal, delay, always, intbv, Simulation, bin
> from random import randrange
> from math   import pow
>
> def AddNum(B):
>
>     #interval = delay(10)
>     max_num = pow(2,B-1) - 1
>     min_num = -1 * pow(2,B-1)
>
>     a = Signal(intbv(0)[B:])
>     b = Signal(intbv(0)[B:])
>     c = Signal(intbv(0)[B+1:])
>
>   
The error you are seeing is correct.  There is basically two modes for 
the intbv.  Constraint integer (see Jan's essay for more info) and the 
regular bit-vector.  When using the intbv for integer representation, as 
in your case with negative and positive numbers, you need to define the 
maximum and minimum.  Instead of defining the number of bits you only 
need to define the expected max and min for the design. 

Example

a = Signal(intbv(0, min=min_num, max=max_num))
b = Signal(intbv(0, min=min_num, max=max_num))
c = Signal(intbv(0, min=min_num, max=max_num))

This is a little different than what you maybe use to in Verilog or VHDL 
but it can be very powerful.  When you define the bit width it is 
expected that the intbv is used as a generic bit array (no numeric 
value).  But the implicit numeric min is zero and the max is the size of 
the bit vector.

Hope that helps

>     for i in range(10):
>
>         a.next = randrange(0, max_num)
>         b.next = randrange(0, max_num)
>         c.next = a + b
>
>         yield  delay(10)
>         print "i: %s a: %s, b: %s sum = %s binary %s" %(i, a, b, c, bin(c, B))
>
>
> def main():
>     bitwidth = 9
>     inst = AddNum(bitwidth)
>     sim  = Simulation(inst)
>     sim.run()
>
>
> if __name__ == '__main__':
>     main()
>
> As I said, when negative numbers are used, i.e.
>
>  a.next = randrange(min_num, max_num)
>  b.next = randrange(min_num, max_num)
>
> Python complains. What do you think is the problem?
>
> On Sat, Jun 6, 2009 at 5:34 PM, Christopher L.
> Felton<chr...@gm...> wrote:
>   
>>> a=intbv(3)[2:]
>>> b=intbv(1)[2:]
>>> c=a+b
>>>
>>> the sum (c) is not 'intbv' class, its 'long' if I'm not mistaken. How
>>> can we get the sum to be 'intbv' of the same bitwidth (in this case
>>> 2)?
>>>
>>>
>>>       
>> You would want to do the following (which is the same as other HDLs)
>>
>> a = intbv(3)[2:]
>> b = intbv(1)[2:]
>> c = intbv(1)[2:]
>> c[:] = a+b
>>
>> As you noticed, the result of the intbv math operations returns an
>> integer (long).  What you need to do is create an intbv type for the
>> left hand side of the operation.  For the above example you will get an
>> error.  The intbv will check the limits of addition.  You will need to
>> create "c" to be large enough for the result of the addition.
>>
>> c = intbv(1)[3:]
>>
>>
>> Hope that helps, for more background information see Jan's essay on
>> constraint integer, http://www.jandecaluwe.com/hdldesign/counting.html.
>>
>> Chris
>>
>> ------------------------------------------------------------------------------
>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>> looking to deploy the next generation of Solaris that includes the latest
>> innovations from Sun and the OpenSource community. Download a copy and
>> enjoy capabilities such as Networking, Storage and Virtualization.
>> Go to: http://p.sf.net/sfu/opensolaris-get
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>>     
>
>
>
>   

Re: [myhdl-list] intbv addition

[Sami Al D. <sam...@gm...>]

Dear Chris,

Thank you for your reply. I am trying to add numbers in MyHDL, I tried
to add numbers modeled by 'intbv' in two stages; the first was simple
program with no 'next' command included, and the other with 'next'.
The first one worked as expected but the second one strangely gave
weird results, when the numbers are positive, but when they are
extended to negative ranges the interpreter complains about exceeding
the minimum range of 0.  Here is the code:

from myhdl  import Signal, delay, always, intbv, Simulation, bin
from random import randrange
from math   import pow

def AddNum(B):

    #interval = delay(10)
    max_num = pow(2,B-1) - 1
    min_num = -1 * pow(2,B-1)

    a = Signal(intbv(0)[B:])
    b = Signal(intbv(0)[B:])
    c = Signal(intbv(0)[B+1:])

    for i in range(10):

        a.next = randrange(0, max_num)
        b.next = randrange(0, max_num)
        c.next = a + b

        yield  delay(10)
        print "i: %s a: %s, b: %s sum = %s binary %s" %(i, a, b, c, bin(c, B))


def main():
    bitwidth = 9
    inst = AddNum(bitwidth)
    sim  = Simulation(inst)
    sim.run()


if __name__ == '__main__':
    main()

As I said, when negative numbers are used, i.e.

 a.next = randrange(min_num, max_num)
 b.next = randrange(min_num, max_num)

Python complains. What do you think is the problem?

On Sat, Jun 6, 2009 at 5:34 PM, Christopher L.
Felton<chr...@gm...> wrote:
>
>> a=intbv(3)[2:]
>> b=intbv(1)[2:]
>> c=a+b
>>
>> the sum (c) is not 'intbv' class, its 'long' if I'm not mistaken. How
>> can we get the sum to be 'intbv' of the same bitwidth (in this case
>> 2)?
>>
>>
> You would want to do the following (which is the same as other HDLs)
>
> a = intbv(3)[2:]
> b = intbv(1)[2:]
> c = intbv(1)[2:]
> c[:] = a+b
>
> As you noticed, the result of the intbv math operations returns an
> integer (long).  What you need to do is create an intbv type for the
> left hand side of the operation.  For the above example you will get an
> error.  The intbv will check the limits of addition.  You will need to
> create "c" to be large enough for the result of the addition.
>
> c = intbv(1)[3:]
>
>
> Hope that helps, for more background information see Jan's essay on
> constraint integer, http://www.jandecaluwe.com/hdldesign/counting.html.
>
> Chris
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
Best Regards
Sami Aldalahmeh

Re: [myhdl-list] intbv addition

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

> a=intbv(3)[2:]
> b=intbv(1)[2:]
> c=a+b
>
> the sum (c) is not 'intbv' class, its 'long' if I'm not mistaken. How
> can we get the sum to be 'intbv' of the same bitwidth (in this case
> 2)?
>
>   
You would want to do the following (which is the same as other HDLs)

a = intbv(3)[2:]
b = intbv(1)[2:]
c = intbv(1)[2:]
c[:] = a+b

As you noticed, the result of the intbv math operations returns an 
integer (long).  What you need to do is create an intbv type for the 
left hand side of the operation.  For the above example you will get an 
error.  The intbv will check the limits of addition.  You will need to 
create "c" to be large enough for the result of the addition.

c = intbv(1)[3:]


Hope that helps, for more background information see Jan's essay on 
constraint integer, http://www.jandecaluwe.com/hdldesign/counting.html.

Chris