myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] arithmetic trouble

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

> if that would be the best approach.  Or to simply restrict shifting.
>
> My time is severely limited right now as well.  If I find some free
> cycles I can try to methodically approach this issue.


Ok, I am going to get in trouble for being late to work.  But here is  
a quick cver simulation.  Just posting as FYI and info for others if  
interested.  What it shows, is that the Verilog simulator (at least  
cver, ?? how consistent are other simulators) will use the largest bit- 
width in the assignment, left or right hand side.

This "rule" would be hard to duplicate (if even desired) in MyHDL  
because the math operation doesn't know about the left-hand side. Some  
more thought and investigation is needed but this information might be  
useful for now.

Results
Left hand side is 8-bit (c16 == right hand 16 bit result).
123 = 248 + 255 --   251(c16) --         251(int)
   0 = 248 * 255 --   247(c16) --         247(int)
124 = 249 + 255 --   252(c16) --         252(int)
   0 = 249 * 255 --   248(c16) --         248(int)
124 = 250 + 255 --   252(c16) --         252(int)
   0 = 250 * 255 --   249(c16) --         249(int)
125 = 251 + 255 --   253(c16) --         253(int)
   0 = 251 * 255 --   250(c16) --         250(int)
125 = 252 + 255 --   253(c16) --         253(int)
   0 = 252 * 255 --   251(c16) --         251(int)
126 = 253 + 255 --   254(c16) --         254(int)
   0 = 253 * 255 --   252(c16) --         252(int)
126 = 254 + 255 --   254(c16) --         254(int)
   0 = 254 * 255 --   253(c16) --         253(int)
127 = 255 + 255 --   255(c16) --         255(int)
   0 = 255 * 255 --   254(c16) --         254(int)

Left hand side is 8bit and 'a' (i.e. a + b) is 16 bit
251 = 255 + 255 --   251(c16) --         251(int)
247 = 255 * 255 --   247(c16) --         247(int)
252 = 255 + 255 --   252(c16) --         252(int)
248 = 255 * 255 --   248(c16) --         248(int)
252 = 255 + 255 --   252(c16) --         252(int)
249 = 255 * 255 --   249(c16) --         249(int)
253 = 255 + 255 --   253(c16) --         253(int)
250 = 255 * 255 --   250(c16) --         250(int)
253 = 255 + 255 --   253(c16) --         253(int)
251 = 255 * 255 --   251(c16) --         251(int)
254 = 255 + 255 --   254(c16) --         254(int)
252 = 255 * 255 --   252(c16) --         252(int)
254 = 255 + 255 --   254(c16) --         254(int)
253 = 255 * 255 --   253(c16) --         253(int)
255 = 255 + 255 --   255(c16) --         255(int)
254 = 255 * 255 --   254(c16) --         254(int)
0 simulation events and 0 declarative immediate assigns processed.
242 behavioral statements executed (1 procedural suspends).
   Times (in sec.):  Translate 0.0, load/optimize 0.1, simulation 0.1.
   There were 0 error(s), 0 warning(s), and 1 inform(s).
End of GPLCVER_2.12a at Thu May 14 09:38:00 2009 (elapsed 0.0 seconds).

Simple TestBench
module test;

    integer i,j,x;
    reg [7:0] c;
    reg [15:0] c16;
    reg [7:0] a, b;
    reg [15:0] a16, b16;

    initial begin
       // 8 bit operands
       for(i=248; i<256; i=i+1) begin
	 for(j=255; j<256; j=j+1) begin
	    a = i;
	    b = j;
	    c   = (a + b) >> 1;
	    c16 = (a + b) >> 1;
	    x   = (i + j) >> 1;
	    $display("%d = %d + %d -- %d(c16) -- %d(int) ", c, a, b, c16, x);
	    c   = (a * b) >> 8;
	    c16 = (a * b) >> 8;
	    x   = (i * j) >> 8;
	    $display("%d = %d * %d -- %d(c16) -- %d(int)", c, a, b, c16, x);
	 end
       end // for (i=248; i<256; i=i+1)

       // a = 16 bit operand
       for(i=248; i<256; i=i+1) begin
	 for(j=255; j<256; j=j+1) begin
	    a16 = i;
	    b = j;
	    c   = (a16 + b) >> 1;
	    c16 = (a16 + b) >> 1;
	    x   = (i + j) >> 1;
	    $display("%d = %d + %d -- %d(c16) -- %d(int) ", c, a, b, c16, x);
	    c   = (a16 * b) >> 8;
	    c16 = (a16 * b) >> 8;
	    x   = (i * j) >> 8;
	    $display("%d = %d * %d -- %d(c16) -- %d(int)", c, a, b, c16, x);
	 end
       end
    end


endmodule

Re: [myhdl-list] arithmetic trouble

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

>
>
>>
>> Should my_hdl try to workaround this?
>
> Yes - in the worst case it should refuse to convert shifts
> of expressions and suggest to use a temporary variable instead.
> Not ideal, but much better than simulation mismatches.
>
> I have no time right now to investigate these issues,
> I would appreciate if someone seeks this out systematically,
> ideally with more than one Verilog simulator (cver and
> icarus are free.)
>
> Jan
>

Well this could be an interesting problem, doing a little searching on  
google found this quote from another newsgroup (take it with a grain  
of salt)

"""
In Verilog, the width of the result of a binary operation is the  
maximum width of the operands. In your case, each operand is 8 bits so  
the result of the multiplication will be 8 bits. When you add the two  
8-bit numbers, the result will also be 8 bits.
"""

That statement agrees with what I recall (without looking up the  
Verilog standard) and the empirical results from your simulation.  The  
quick fix is to extend the result or one of the operands bit-widths  
(or the two step approach).

For the MyHDL fix the same rules could be enforced.  This is somewhat  
related to another thread which the intbv math operators return an  
intbv instead of an int.  I don't have the insight / opinion right now  
if that would be the best approach.  Or to simply restrict shifting.

My time is severely limited right now as well.  If I find some free  
cycles I can try to methodically approach this issue.

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

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

>
> 2) It appears that to work with lists of signals, one must ensure  
> that at the
>     instance level the list has been unpacked into individual  
> signals and at
>    the top level these lists are built from individual signals.     
> Is this correct ?
>

Here would be a possible approach, using the list of signals using  
your recursive approach.  There is an issue with it but I thought I  
would share my variant in any case, ran out of time to spend on it.

Re: [myhdl-list] arithmetic trouble

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

Neal Becker wrote:


> 
> The problem is, it seems that (a * b) >>> 16 all in 1 step doesn't work 
> correctly.  I'm using cadence (version is 8.1?).  The simulator gives 
> strange results.  It seems to act as if it doesn't understand the bitwidth 
> of the intermediate result of (a*b), so that when shifted it's not correctly 
> handling the sign.
> 
> It works correctly if I break into 2 steps, where I use a tmp variable of 
> _the correct bit width_ before shifting.
> 
> Is this a common issue with verilog simulators, or is mine just broken?

Both are possible, though my guess is that your simulator works correctly
in terms of Verilog rules.

My guess is that we are being hit by Verilog's obscure rules for inferring
sizes and signedness. I would start by trying whether the bit width
of the left-hand side makes a difference. Perhaps the bit width of
the expression is reduced before the shift instead of after as it
"should" be.

> 
> Should my_hdl try to workaround this?

Yes - in the worst case it should refuse to convert shifts
of expressions and suggest to use a temporary variable instead.
Not ideal, but much better than simulation mismatches.

I have no time right now to investigate these issues,
I would appreciate if someone seeks this out systematically,
ideally with more than one Verilog simulator (cver and
icarus are free.)

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] arithmetic trouble

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

Christopher Felton wrote:
> 
> 
>     It works correctly if I break into 2 steps, where I use a tmp
>     variable of
>     _the correct bit width_ before shifting.
> 
>     Is this a common issue with verilog simulators, or is mine just broken?
> 
>     Should my_hdl try to workaround this?
> 
> 
> 
> I don't recall the exact rules off the top of my head, either.  But I 
> think this is correct.  The language doesn't presume to know what the 
> intermediate bit representation of the operator is (Verilog language). 
>  If you want full precision for the multiply you have to do it in two 
> steps as you indicated or have your output be the full range.
> 
> BOMK everything is working correctly.  What you notice is a simulation 
> mismatch?  The MyHDL simulates fine because the * uses full precision 
> (infinite bits) and the bounds are not checked until the left hand side 
> is assigned and that is after the shift.   Hmmmm, don't know if this 
> would be a bug or not.  Not all aspects are convertible and this would 
> fit that scenario.

My rule is crystal-clear: if MyHDL code simulates fine and converts fine,
simulations should match. Otherwise, there is a bug - either in the
convertor or in the HDL simulator. For this it is not relevant whether
MyHDL does the "right" thing or not.

So it looks like we have a bug here and now we have to find out
what it is. Of course, it may be that something cannot be reliably
converted, in which case the convertor should issue an error.

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] a few questions relating to recursive designs

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

On May 13, 2009, at 3:31 PM, 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
>
>    I resorted to the (ugly) approach of passing an integer through  
> the hierarchy
>    so I could do the bit selection at the leaves.  Another ugly  
> solution would
>    be to define the selector as a list of signals and slice this  
> up.  The problem
>    with this approach is that at the top level of the design one has  
> to bridge
>    from the single intbv to list of signals.
>
>    Any thoughts on a more elegant approach ?
>
> 2) It appears that to work with lists of signals, one must ensure  
> that at the
>     instance level the list has been unpacked into individual  
> signals and at
>    the top level these lists are built from individual signals.     
> Is this correct ?
>

Well I was going to suggest a list of signals was your best option,  
see the MyHDL below.  But there is a problem with this  
implementation.  The converters want to treat the list of signals (at  
least in this case) as memory.  It assumes that the input, A, is  
internal and not a port.

I still think a list of signals is your best option.   Personally I  
would like to see the list of signals be more generic, not always  
resulting in a memory conversion (see earlier posts).  But the issue  
is how to distinguish a memory model from a generic usage??  In this  
example a little too much freedom (IMO) was taken in the conversion,  
because port A was removed in the resulting Verilog.

If your example was to experiment with the recursive property and not  
simply a mux, I think you can experiment with 'A' and 'sel' being a  
list of signals.

from myhdl import *

def nmux(z, A, sel):
     """
     A    --  List of Signal
     z    --  select output, z type should be the same as the
              types in A
     sel  --  select the signal
     """

     @always_comb
     def muxlogic():
         z.next = A[int(sel)]

     return muxlogic


if __name__ == '__main__':

     N    = 23
     # Direct indexing example
     A    = [Signal(intbv(0)[1:]) for i in range(N)]
     sel  = Signal(intbv(0)[N:])
     z    = Signal(intbv(0)[1:])

     toVerilog(nmux, z, A, sel)

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

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

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

   I resorted to the (ugly) approach of passing an integer through the
hierarchy
   so I could do the bit selection at the leaves.  Another ugly solution
would
   be to define the selector as a list of signals and slice this up.  The
problem
   with this approach is that at the top level of the design one has to
bridge
   from the single intbv to list of signals.

   Any thoughts on a more elegant approach ?

2) It appears that to work with lists of signals, one must ensure that at
the
    instance level the list has been unpacked into individual signals and at
   the top level these lists are built from individual signals.    Is this
correct ?

Geoffrey

--------------------------------------------------

def Mux0(sw, z, A0, A1, sel):
   """ Generate A Two-way Multiplexor

       sw     -- sel bit to use at this level (...,3,2,1,0)
       z      -- data output
       A1, A0 -- data inputs
       sel    -- (multibit) selector
   """
   @always_comb
   def muxLogic():
       if sel[sw]:
           z.next = A1
       else:
           z.next = A0
   return muxLogic


def Mux(sw, z, A, sel):
    """ Recursively Generate A Multiplexor Tree

        sw -- sel bit to use at this level (...,3,2,1,0)
              should match tree depth at top level
         z -- output data
         A -- array of input data
        sel-- selector for array
    """
    assert len(A) >= 2
    if len(A) == 2:
       return Mux0(sw, z, A[0], A[1], sel)
    else:

       # signals for two halves

        Mid  = [Signal(intbv(0)[len(z):]) for i in range(2)]

        # recursively generate muxes for two data halves

        l = len(A)/2
        m1   = Mux(sw-1, Mid[1], A[l:], sel) # top
        m0   = Mux(sw-1, Mid[0], A[:l], sel) # bottom

        # generate top level mux

        top  = Mux(sw, z, Mid, sel)
        return m0, m1, top

Re: [myhdl-list] arithmetic trouble

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

>
>
>
> It works correctly if I break into 2 steps, where I use a tmp variable of
> _the correct bit width_ before shifting.
>
> Is this a common issue with verilog simulators, or is mine just broken?
>
> Should my_hdl try to workaround this?
>
>
>
I don't recall the exact rules off the top of my head, either.  But I think
this is correct.  The language doesn't presume to know what the intermediate
bit representation of the operator is (Verilog language).  If you want full
precision for the multiply you have to do it in two steps as you indicated
or have your output be the full range.

BOMK everything is working correctly.  What you notice is a simulation
mismatch?  The MyHDL simulates fine because the * uses full precision
(infinite bits) and the bounds are not checked until the left hand side is
assigned and that is after the shift.   Hmmmm, don't know if this would be a
bug or not.  Not all aspects are convertible and this would fit that
scenario.

[myhdl-list] arithmetic trouble

[Neal B. <ndb...@gm...>]

I'm still learning verilog.  Anyway, I found the following problem.

------------------------------
from myhdl import Signal, always, intbv, Simulation, delay, toVerilog, 
traceSignals, instance, always_comb

def test1 (a, b, out):
    @always_comb
    def test1_logic():
        out.next = (a * b) >> 16

    return test1_logic

def max_signed (bits):
    return ~(-1 << (bits-1))

def min_signed (bits):
    return (-1 << (bits-1))

a = Signal (intbv(0, min_signed (16), max_signed (16)+1))
b = Signal (intbv(0, min_signed (16), max_signed (16)+1))
out = Signal (intbv(0, min_signed (16), max_signed (16)+1))

toVerilog (test1, a, b, out)

-----------------------------
module test1 (
    a,
    b,
    out
);

input signed [15:0] a;
input signed [15:0] b;
output signed [15:0] out;
wire signed [15:0] out;





assign out = $signed((a * b) >>> 16);

endmodule
-----------------------

The problem is, it seems that (a * b) >>> 16 all in 1 step doesn't work 
correctly.  I'm using cadence (version is 8.1?).  The simulator gives 
strange results.  It seems to act as if it doesn't understand the bitwidth 
of the intermediate result of (a*b), so that when shifted it's not correctly 
handling the sign.

It works correctly if I break into 2 steps, where I use a tmp variable of 
_the correct bit width_ before shifting.

Is this a common issue with verilog simulators, or is mine just broken?

Should my_hdl try to workaround this?

Re: [myhdl-list] MyHDL development tasks

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

Jian LUO wrote:
> Jan Decaluwe wrote:
>> Recently I got some inquiries from people offering
>> to help with MyHDL development. I have now created
>> a page with some of the tasks I'm thinking about
>> for a future release. Help on them is welcome.
>>
>> http://www.myhdl.org/doku.php/dev:tasks
>>
>>   
> Good to see myhdl evolving.
> 
> Back in January I've posted a patch here that partly implements 
> conditional expressions.
> Unfortunately, at that time I had no time to figure out how to check it 
> in in merurial.
> And now I'm still willing to give it a try.

I remember. I had a few issues: it was not done with mercurial, there
was no unit test, but the main (external) issue was that the compiler package
was becoming obsolete. So I didn't want to add further conversion features
until the move to the ast package was completed. But this is done now (in
development), so we can proceed now. However, take into account that
you need Python 2.6 for development. (We need the ast package functionality
from that version.)

> So Jan, how can I contribute? 

Use your expertise and do it again, this time with ast :-)
(I realize it feels redundant. However, I just had to do this for
*all* convertor code, so you'll forgive me.)

> Does the myhdl repo need a account a/o 
> password?

No, just install mercurial and follow the guidelines here:

http://www.myhdl.org/doku.php/dev:repo

The whole world (including Python itself) seems to be moving to
mercurial these days, so I'm confident that we made the right
choice. So in any case, it's not a waste of your time.

To contribute changesets, follow the guidelines here:

http://www.myhdl.org/doku.php/dev:patches

I have listed the conditional expression support as an open task:

http://www.myhdl.org/doku.php/dev:tasks#conversionsupport_for_conditional_expressions

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] MyHDL development tasks

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

On Tue, May 12, 2009 at 2:43 PM, Jian LUO <jia...@go...>wrote:

> Jan Decaluwe wrote:
> > Recently I got some inquiries from people offering
> > to help with MyHDL development. I have now created
> > a page with some of the tasks I'm thinking about
> > for a future release. Help on them is welcome.
> >
> > http://www.myhdl.org/doku.php/dev:tasks
> >
> >
> Good to see myhdl evolving.
>
> Back in January I've posted a patch here that partly implements
> conditional expressions.
> Unfortunately, at that time I had no time to figure out how to check it
> in in merurial.
> And now I'm still willing to give it a try.
>
> So Jan, how can I contribute? Does the myhdl repo need a account a/o
> password?
>

The information you need is available here,
http://www.myhdl.org/doku.php/dev:repo

Re: [myhdl-list] MyHDL development tasks

[Jian L. <jia...@go...>]

Jan Decaluwe wrote:
> Recently I got some inquiries from people offering
> to help with MyHDL development. I have now created
> a page with some of the tasks I'm thinking about
> for a future release. Help on them is welcome.
>
> http://www.myhdl.org/doku.php/dev:tasks
>
>   
Good to see myhdl evolving.

Back in January I've posted a patch here that partly implements 
conditional expressions.
Unfortunately, at that time I had no time to figure out how to check it 
in in merurial.
And now I'm still willing to give it a try.

So Jan, how can I contribute? Does the myhdl repo need a account a/o 
password?

Jian

Re: [myhdl-list] MyHDL development tasks

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

Christopher Felton wrote:
> 
> 
>     Recently I got some inquiries from people offering
>     to help with MyHDL development. I have now created
>     a page with some of the tasks I'm thinking about
>     for a future release. Help on them is welcome.
> 
>     http://www.myhdl.org/doku.php/dev:tasks
> 
> 
> If someone starts working on a task, would you like them to update the 
> wiki page stating such work is being undertaken?  And possible status? 
>  Obviously it would not be a requirement (impossible to enforce) but it 
> might be useful to see which tasks are currently under development and 
> by who.  

Certainly, I plan to do the same.

-- 
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] MyHDL development tasks

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

Recently I got some inquiries from people offering
> to help with MyHDL development. I have now created
> a page with some of the tasks I'm thinking about
> for a future release. Help on them is welcome.
>
> http://www.myhdl.org/doku.php/dev:tasks
>

If someone starts working on a task, would you like them to update the wiki
page stating such work is being undertaken?  And possible status?  Obviously
it would not be a requirement (impossible to enforce) but it might be useful
to see which tasks are currently under development and by who.

Re: [myhdl-list] hierarchy flattening on conversion to vhdl/verilog

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

>
> The loss of hierarchy seems unnecessary and makes it
> > harder to relate the output and input.
>

If this is desired for debug I imagine it is straight forward enough to have
a script to individually convert each "block".  You would have to manually
wire the top-level.  But it is an option.  For final generation I haven't
notice the flat hierarchy being an issue.


> Conversion after elaboration was the insight I needed to make
> conversion a feasible project for me. The python interpreter
> does as much work as possible and adds information
> without which I don't think it is even possible.


In my opinion this is one of the huge benefits of MyHDL (Python based HDL)
over the traditional HDLs.  There is a lot of power in this feature.

[myhdl-list] MyHDL development tasks

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

Recently I got some inquiries from people offering
to help with MyHDL development. I have now created
a page with some of the tasks I'm thinking about
for a future release. Help on them is welcome.

http://www.myhdl.org/doku.php/dev:tasks

-- 
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] hierarchy flattening on conversion to vhdl/verilog

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

Geoffrey Brown wrote:
> I'm curious about the decision to elaborate  designs before generation
> of vhdl/verilog.  The loss of hierarchy seems unnecessary and makes it
> harder to relate the output and input.   What was the thought process
> leading to this decision ?

About time to turn this into a FAQ :-)

Conversion after elaboration was the insight I needed to make
conversion a feasible project for me. The python interpreter
does as much work as possible and adds information
without which I don't think it is even possible.

Moreover, a nice side effect is that elaboration give you a free
ride on some aspects, for example the conversion restrictions
only apply to code inside generators. Outside them, you can
do what you want which makes some powerful applications.

Look at this (extreme) example:

http://www.myhdl.org/doku.php/cookbook:bitonic

With conversion after elaboration, it is straightforward.
Without it, the recursion would have to be mapped to
Verilog - I'm pretty sure this isn't even possible.

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] hierarchy flattening on conversion to vhdl/verilog

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

I'm curious about the decision to elaborate  designs before generation
of vhdl/verilog.  The loss of hierarchy seems unnecessary and makes it
harder to relate the output and input.   What was the thought process
leading to this decision ?

Geoffrey

[myhdl-list] Move to ast package completed

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

In the past weeks, I have completed the move to the
ast package to replace the compiler package.

This is done in the default development branch and
requires Python 2.6. It was necessary to prepare for
the future, as the compiler package is deprecated.
With this rewrite, we are ready for new developments
including the eventual move to Python 3.x.

This has been an intensive major rewrite with
(hopefully) no changes to MyHDL users :-(. With a thing
like this, there's no choice but to "jump" at a certain
point. Initially, everything breaks down and all
unit tests fail. They have to be conquered again, one
at a time.

The unit tests proved their merit. When one started
working, typically the others still failed. This means
that they test different things of the implementation,
as they should.

It is very well possible that you will still find
conversion errors with your code. This would mean that
the unit test suite is not complete enough. This is
a good time to check this. If you find errors that
were not there previously, additional unit tests
will have to be written.

I would appreciate if some of you would try the new
code on your designs. However - this requires updating
to the default branch in development, and it requires
Python 2.6 (imposed by the ast package). There's no
hurry. However, new convertor developments will be
based on the new code.

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

Felton Christopher wrote:

>>
> 
> In my experience if you have a type (object) and some operations are  
> performed the result is the same type.

I agree with that. However, in my mind, intbv is a subtype of int,
in which case this would be acceptable.

It is true that technically, intbv is *not* implemented as a subclass
of int. The reason why this couldn't be done is that it turns out to be
impossible to derive a mutable type (like intbv) from an immutable type
(like int). But that's a pity, it would have simplified many things.

> Also, I think it would simply  
> matters some what for users (but could cause other issues) not having  
> to use the [:].  There could be more negatives than positives to such  
> a change.

I assume you refer to the requirement to assign to intbv instances as follows:

a[:] = b

to change their value.

This is *not* related to the return type of intbv operations. It would
still be necessary when the return type is changed.

The reason is that when you would use plain name assignment:

a = b

the original intbv object is gone, including its constraints. So in
simulation, you lose run-time bound checking, and conversion would
become close to impossible. I think it's a small price to pay
for these features.

I'm thinking about adding a "val" property to intbv though so you
could do:

a.val = b

Perhaps this makes more sense when you're not thinking about the
bit representation.


> I imagine it might be difficult to change at this point because it  
> could affect much of the user code.  Also, don't know if it would have  
> any implications on conversion, checking, etc.

No, I think it would be straighforward. I expect that everything that
works now would continue working, except that you could do some
additional things. In particular, you could index and slice an
arithmetic expression.

The only price would be simulation performance hit. The question is
whether this is worthwhile for a feature that is seldom (?) used.
Someone would have to analyze this in detail to make a good
decision. Perhaps the performance hit is irrelevant - I don't know.

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] assertion error in toVerilog

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

Jan Decaluwe wrote:
> Neal Becker wrote:
>> Traceback (most recent call last):
>>   File "test3.py", line 65, in <module>
>>     tb = toVerilog (testbench)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_toVerilog.py", line
>> 115, in __call__
>>     genlist = _analyzeGens(arglist, h.absnames)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line
>> 160, in _analyzeGens
>>     compiler.walk(ast, v)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 106, in walk
>>     walker.preorder(tree, visitor)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 63, in preorder
>>     self.dispatch(tree, *args) # XXX *args make sense?
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line
>> 939, in visitModule
>>     self.visit(node.node)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
>>     self.dispatch(child, *args)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line
>> 998, in visitFunction
>>     self.visit(node.code)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 40, in default
>>     self.dispatch(child, *args)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line
>> 486, in visitAugAssign
>>     self.visit(node.node, _access.INOUT)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line
>> 632, in visitGetattr
>>     self.visit(node.expr, *args)
>>   File "/usr/lib64/python2.5/compiler/visitor.py", line 57, in dispatch
>>     return meth(node, *args)
>>   File "/usr/lib/python2.5/site-packages/myhdl/conversion/_analyze.py", line
>> 743, in visitName
>>     raise AssertionError
>> AssertionError
>>
>> Here is code:
>> from myhdl import Signal, always, intbv, Simulation, delay, toVerilog,
>> traceSignals, always_comb, instance
>>
>>
>>
>> def Counter (count, clock, n):
>>     @always (clock.posedge)
>>     def cntLogic():
>>         if count == n-1:
>>             count.next = 0
>>         else:
>>             count.next = count + 1
>>
>>         print "count:", count
>>     return cntLogic
>>
>> def accum (x, result, count, clock, n):
>>     _sum = Signal (intbv(0)[8:])
>>     
>>     @always (clock.posedge)
>>     def accum_logic():
>>         _sum.next += x
>>         if count == n-1:
>>             ##print 'count:', count, 'sum:', _sum
>>             result.next = _sum
>>             _sum.next = 0
>>
>>     return accum_logic
>>
>> def Decimator (clock, x, n, count, result):
>>     cnt1 = Counter (count, clock, n)
>>     acc1 = accum (x, result, count, clock, n)
>>     return cnt1, acc1
>>
>> def testbench():
>>     HALF_PERIOD = delay(1)
>>
>>     n = 16
>>     x = Signal (intbv(0)[4:])
>>     #clock = Signal()
>>     clock = Signal (intbv(0)[1:])
>>     result = Signal(intbv()[8:])
>>     count = Signal (intbv(0)[4:])
>>     
>>     decimator1 = Decimator (clock, x, n, count, result)
>>     
>>     @always(HALF_PERIOD)
>>     def clockGen():
>>         clock.next = not clock
>>
>>     @instance
>>     def stimulus():
>>         while (1):
>>             yield clock.posedge
>>             x.next = 1
>>         
>>     @instance
>>     def monitor():
>>         while 1:
>>             yield clock.posedge
>>             print 'x:', x, 'count:', count, 'result:', result
>>
>>     return clockGen, stimulus, decimator1, monitor
>>
>>
>> tb = toVerilog (testbench)
>>
>> def main():
>>     Simulation(tb).run(50)
>>
>> if __name__ == "__main__":
>>     main()
>>
>> Any ideas?
> 
> Yes:
>       _sum.next += x
> 
> has no equivalent in VHDL or Verilog, as it is equivalent to:
> 
>      _sum.next = _sum.next + x
> 
> In other words, it updates the future value by adding to the future value.
> (I'm not sure it's useful in MyHDL either.)
> 
> So it cannot be converted. However, this problem should be indicated with
> a proper exception and error message, and not with an assertion, so the
> AssertionError is a bug.

This has been fixed in development.


-- 
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] Named branches in repository

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

As announced, I am now using named branches in the repository.

They implement different development lines with different
policies. Currently I use them to separate "bleeding edge"
development on the default branch from bug fixes for 0.6
in branch 0.6-maint. Merges occur only in one direction,
from 0.6-maint to default.

The alternative would have been different repositories,
which is the principal method advocated in the mercurial
documentation. Named branches are "advanced" but I
prefer them because you can switch development lines
without changes to your python setup.

I have documented this on the website:\

http://www.myhdl.org/doku.php/dev:repo#named_branches


-- 
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] Development status

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

Those who track the mecurial repo - be careful.

As announced, I am now working with 2 branches, one for maintenances
(0.6-maint) and the default trunk for the bleeding edge.

The trunk is currently UNSTABLE, as I am in the middle of a major
rewrite to replace package compiler by ast. In normal circumstances,
I try to avoid an unstable trunk, but this rewrite is really major.
(Next time I may use another branch.) I didn't want to delay a
push any longer, as I also use the external repo a backup.

When you pull now, you will get changesets for all branches. If you
want to track bug fixes for 0.6, make sure to switch to 0.6-maint
before installing:
   hg update -C 0.6-maint.

I will explain all of this better later on when I have more time.

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

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

On Apr 19, 2009, at 3:08 AM, Jan Decaluwe wrote:

> Christopher L. Felton wrote:
>> Curiosity, what was the rational behind the mathematical operators  
>> for
>> the intbv object returning the integer values and the logic operators
>> (shifts, and, or, xor, etc) returning an intbv object?
>>
>> Example
>> a = intbv(1)
>> b = intbv(2)
>>
>> c = a + b
>> type(c)
>> <type 'int'>
>>
>> c = a ^ b
>> type(c)
>> <class 'myhdl._intbv.intbv'>
>
> If the return value is an intbv, you can slice and index it.
> This probably makes sense for "bit-oriented" operations,
> and perhaps less for "arithmetic" operations.
> Therefore, for the latter case it might be a good idea
> to avoid the overhead of intbv construction.
>
> This is all a little bit arbitrary and speculative -
> for example, I haven't done tests to check how significant
> the intbv construction overhead exactly is.
> We always have the option to change the return type
> to intbv if there's a real need.
>
> Jan
>

In my experience if you have a type (object) and some operations are  
performed the result is the same type.  Also, I think it would simply  
matters some what for users (but could cause other issues) not having  
to use the [:].  There could be more negatives than positives to such  
a change.

I imagine it might be difficult to change at this point because it  
could affect much of the user code.  Also, don't know if it would have  
any implications on conversion, checking, etc.

The reason I had come across this question was because I spend some  
time putting together a fixed-point object that used the intbv as the  
base class.  Hence it would be convertible.  I came across this  
scenario, for the mathematical operations leave the same  
implementation as intbv or return the type.

I have uploaded a draft document I started for the fixed-point  
object.  It is very (very, very, very) rough at this point http://www.myhdl.org/lib/exe/fetch.php/users:cfelton:projects:myhdlfixedpoint.pdf?id=users%3Acfelton%3Aprojects%3Afxintbv&cache=cache

Thanks

Re: [myhdl-list] the path not taken

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

Neal Becker wrote:
> I'm having a problem with this code:
> 
> def rnd (x, bits, output):
>     min_val = x.min
>     max_val = x.max
>     @always_comb
>     def rnd_logic():
>         if (bits < 1):
>             output.next = x
>         else:
>             y1 = intbv (int (x >> (bits-1)), min_val, max_val)
>             #y1 = intbv (int(x), min_val, max_val)
>             y2 = intbv (int (y1 + 1), min_val, max_val)
>             y3 = intbv (int (y2 >> 1), min_val, max_val)
>             output.next = y3
>     return rnd_logic
> 
> When translating to verilog:
> ValueError: negative shift count
> 
> If the commented line #y1 is used, no error.
> 
> So myhdl is complaining about neg shift count if bits < 1, even though I
> tried to eliminate that with the if (bits < 1).
> 
> What can I do?

I think the problem can be solved by making the code much
clearer at the same time. I would separate object contruction
from usage. Also, I would avoid using redundant objects and
constructors - now they look like ugly type conversions.

For example:

def rndn (x, bits, output):
    min_val = x.min
    max_val = x.max
    @always_comb
    def rnd_logic():
        y = intbv(0, min_val, max_val)
        if (bits < 1):
            output.next = x
        else:
            y[:] = x >> bits-1
            y += 1
            output.next = y >> 1
    return rnd_logic




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