myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] always_comb from a change in Signal list does not get triggered

[Thomas T. <tho...@de...>]

Günter Dannoritzer wrote:

> This is my code:
> 
> def pipe(clk,en,din, dout, N,width):
> 
>   pipe = [Signal(intbvSigned(width)) for i in range(N)]
> 
>   print "N: ", N
> 
>   @always(clk.posedge)
>   def rtl1():
>     if en:
>       for i in downrange(N,1):
>         print "i: %d"% i
>         pipe[i].next = pipe[i-1]
>       pipe[0].next = din
>     print "pipe: %s"% pipe
> 
> 
>   @always_comb
>   def rtl2():
>     print "pipe[N-1]: %d"% pipe[N-1]
>     dout.next = pipe[N-1]
> 
> 
>   return instances()
> 
> I changed the code so that the pipe memory has only N-1 entries and dout 
> being the Nth register, which worked fine. I just would like to know 
> what I am doing wrong so that the always_comb gets not triggered anymore?

I think this is a bug in myhdl.

BTW, some related comments/questions:

 >       for i in downrange(N,1):
 >         pipe[i].next = pipe[i-1]

The following should also work:

	for i in range(1,N):
           pipe[i].next = pipe[i-1]

It will not override, the current value because you write to the 
next-attribute.


In your simple example you could put the
	dout.next = pipe[N-1]
inside the rtl1 generator so you don't need rtl2 (you probably know it, 
your code might be a simplification).


Also in this simple case. Is there something bad about the following 
code, using a @always instead of @always_comb ?

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


Have a nice weekend,

Thomas

-- 

Thomas Traber
DESY, MDI
Notkestrasse 85
D-22603 Hamburg, Germany
email:	tho...@de...
phone:	+49 40 8998 4246

[myhdl-list] always_comb from a change in Signal list does not get triggered

[Günter D. <dan...@we...>]

Hi,

I am trying to create a word wide shift register and the output register 
is connected with an always_comb to the output signal of the function. 
Now this always_comb gets only triggered one time, even so I see the 
output register signal change during the shift operation.

This is my code:

def pipe(clk,en,din, dout, N,width):

   pipe = [Signal(intbvSigned(width)) for i in range(N)]

   print "N: ", N

   @always(clk.posedge)
   def rtl1():
     if en:
       for i in downrange(N,1):
         print "i: %d"% i
         pipe[i].next = pipe[i-1]
       pipe[0].next = din
     print "pipe: %s"% pipe


   @always_comb
   def rtl2():
     print "pipe[N-1]: %d"% pipe[N-1]
     dout.next = pipe[N-1]


   return instances()



I attached the test bench for it. Running the test bench will fill the 
pipe with values and print the output dout.

I changed the code so that the pipe memory has only N-1 entries and dout 
being the Nth register, which worked fine. I just would like to know 
what I am doing wrong so that the always_comb gets not triggered anymore?


BTW, in the above example I am using a convenience function to create a 
signed intbv instance:

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

def intbvSigned(width, value=0):

   max = 2**(width-1)
   min = -max
   r = intbv(value, min, max)

   return r



Thanks for any help.

Guenter

Re: [myhdl-list] intbv with min -1, max 1 has 2 bits?

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
...
>> I might be oblivious and the reason is obvious, but I don't see it at 
>> the moment. Anyone can explain why I need a leading zero bit and cannot 
>> create a 1 bit intbv?
> 
> 1) why a leading zero bit
> Well, for a number that can be both positive or negative you need to
> have room for a sign bit, right? that's what the leading zero bit does.
> 
> 2) why not a 1 bit signed intbv
> That seems to be a bug. The one bit can function as a sign bit in
> this (corner) case. I guess the test should really be:
> 
>                  ...
>                  elif max <= 1: # not 0
>                      _nrbits = len(bin(min))
>                  ...

Thanks for the explanation.

> 
> 
> A sidenote: To get insight in this, I used the brand new web interface
> to the brand new mercurial repository at:
> 
>      http://myhdl.sourceforge.net/hg/myhdl
> 
> If you go to _intbv.py through "files", and then "annotate", you see the changeset
> when these lines were introduced. Click on it and then go to "changeset" to review
> that changeset. Great isn't it :-)

That feature is really great. What I haven't understood yet is, does 
sourceforge now support hg repositories or does hg export the repository 
as a bunch of html pages, so you can basically host that repository on 
any basic html page without extra software?

Is there a way to check the source out with hg?

Guenter

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Ok, below was my quick test to double check if it could be done.  A  
real implementation probably need more thought (if feasible at all).

With that said, I do think this approach will work.  Even if you have  
a non power of 2 limit you still need N bits to represent the max and  
min values.  If the msb of the "bit container" is modified it will  
change the sign.   If the designer is changing any of the other bits  
she/he hopefully know what they are trying to achieve.  I didn't think  
much about the slice assignment but again I believe the same approach  
could be taken just the implementation would need some thought.

Because this is handled in the intbv class the conversion to Verilog/ 
VHDL should still be valid.

<
<              
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<             # CFELTON EDIT
<             if self._min < 0:
<                 msb = (self._val >> self._nrbits-1) & 0x1
<                 if msb and not val:
<                     self._val = -1 * self._val
<              
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<
167,181d157
<
<              
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
<             # CFELTON EDIT
<             # If the new value msb is set and the number is not
<             # negative make it negative
<             # If the intbv is a signed number (min < 0) then
<             # modify the value accordingly
<             if self._min < 0:
<                 msb = (self._val >> self._nrbits-1) & 0x1
<                 print val, msb, self._val, self._min, self._max,  
self._nrbits
<                 if msb and self._val > 0:
<                     self._val = -1 * self._val
<
<              
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



On Jun 12, 2008, at 2:39 PM, Christopher Felton wrote:

> Yes I will send the patch when I get home.  I believe you are correct
> my quick implementation probably only covers the power of 2 cases.
> For the non-power of 2 cases, I think it still works cause you have
> to have a power of 2 (can't have fraction of a bit) the msb of the
> least number of bits (which is the _nrbits) is still the sign bit?
> Just thinking out loud.
>
> Thanks
>
> On Thu, 12 Jun 2008 20:45:12 +0200
>  Jan Decaluwe <ja...@ja...> wrote:
>> Christopher L. Felton wrote:
>>
>>> Below is the output example for a small change that I made to the
>>> bit
>>> vector class
>>>>>> from myhdl import *
>>>>>> x = intbv(0, min=-8, max=8)
>>>>>> x[3] = 1
>>>>>> x
>>> intbv(-8L)
>>>>>> x[3] = 0
>>>>>> x
>>> intbv(0L)
>>>
>>> To implement the above I simply modified __setitems__ and used the
>>> _min
>>> and _nrbits values determine what type of number is being
>>> represented.
>>> If the number is signed multiply the value by -1 if the msb is
>>> being
>>> modified.
>>
>> Could you show your patch (just a diff)? I don't see how this
>> would be correct for non-powers of 2.
>>
>> Jan
>>
>> -- 
>> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>>    From Python to silicon:
>>    http://myhdl.jandecaluwe.com
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Yes I will send the patch when I get home.  I believe you are correct 
my quick implementation probably only covers the power of 2 cases. 
 For the non-power of 2 cases, I think it still works cause you have 
to have a power of 2 (can't have fraction of a bit) the msb of the 
least number of bits (which is the _nrbits) is still the sign bit? 
 Just thinking out loud.

Thanks

On Thu, 12 Jun 2008 20:45:12 +0200
  Jan Decaluwe <ja...@ja...> wrote:
> Christopher L. Felton wrote:
> 
>> Below is the output example for a small change that I made to the 
>>bit 
>> vector class
>>>>> from myhdl import *
>>>>> x = intbv(0, min=-8, max=8)
>>>>> x[3] = 1
>>>>> x
>> intbv(-8L)
>>>>> x[3] = 0
>>>>> x
>> intbv(0L)
>> 
>> To implement the above I simply modified __setitems__ and used the 
>>_min 
>> and _nrbits values determine what type of number is being 
>>represented. 
>>  If the number is signed multiply the value by -1 if the msb is 
>>being 
>> modified.  
> 
> Could you show your patch (just a diff)? I don't see how this
> would be correct for non-powers of 2.
> 
> Jan
> 
> -- 
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>     From Python to silicon:
>     http://myhdl.jandecaluwe.com
> 
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] intbv with min -1, max 1 has 2 bits?

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

Günter Dannoritzer wrote:
> Hi,
> 
> I tried to create a signed intbv with one bit in the form:
> 
>  >>>a = intbv(-1,-1,1)
>  >>>print "a: %d, min: %d, max: %d, _nrbits: %d"%(
>            a, a.min, a.max, a._nrbits)
> 
> a: -1, min: -1, max: 1, _nrbits: 2
> 
> It turns out that intbv uses 2 bits for it. Looking in the 
> intbv.__init__() function there is this code section starting at line 46:
> 
>             if max is not None and min is not None:
>                  _nrbits = maxfunc(len(bin(max-1)), len(bin(min)))
>                  if min >= 0:
>                      _nrbits = len(bin(max-1))
>                  elif max <= 0:
>                      _nrbits = len(bin(min))
>                  else:
>                      # make sure there is a leading zero bit in positive 
> numbers
>                      _nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))
> 
> 
> What is interesting about this is that the first assignment to _nrbits 
> right after the if clause is actually overwritten by any of the 
> following assignments.
> 
> So the reason for the -1,1 range to have 2 bits seems to lay in the 
> comment about having a leading zero bit for positive numbers.
> 
> I might be oblivious and the reason is obvious, but I don't see it at 
> the moment. Anyone can explain why I need a leading zero bit and cannot 
> create a 1 bit intbv?

1) why a leading zero bit
Well, for a number that can be both positive or negative you need to
have room for a sign bit, right? that's what the leading zero bit does.

2) why not a 1 bit signed intbv
That seems to be a bug. The one bit can function as a sign bit in
this (corner) case. I guess the test should really be:

                 ...
                 elif max <= 1: # not 0
                     _nrbits = len(bin(min))
                 ...


A sidenote: To get insight in this, I used the brand new web interface
to the brand new mercurial repository at:

     http://myhdl.sourceforge.net/hg/myhdl

If you go to _intbv.py through "files", and then "annotate", you see the changeset
when these lines were introduced. Click on it and then go to "changeset" to review
that changeset. Great isn't it :-)

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] Slicing an unsigned intbv to a signed one

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

Christopher L. Felton wrote:

> Below is the output example for a small change that I made to the bit 
> vector class
>>>> from myhdl import *
>>>> x = intbv(0, min=-8, max=8)
>>>> x[3] = 1
>>>> x
> intbv(-8L)
>>>> x[3] = 0
>>>> x
> intbv(0L)
> 
> To implement the above I simply modified __setitems__ and used the _min 
> and _nrbits values determine what type of number is being represented. 
>  If the number is signed multiply the value by -1 if the msb is being 
> modified.  

Could you show your patch (just a diff)? I don't see how this
would be correct for non-powers of 2.

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] intbv with min -1, max 1 has 2 bits?

[Günter D. <dan...@we...>]

Hi,

I tried to create a signed intbv with one bit in the form:

 >>>a = intbv(-1,-1,1)
 >>>print "a: %d, min: %d, max: %d, _nrbits: %d"%(
           a, a.min, a.max, a._nrbits)

a: -1, min: -1, max: 1, _nrbits: 2

It turns out that intbv uses 2 bits for it. Looking in the 
intbv.__init__() function there is this code section starting at line 46:

            if max is not None and min is not None:
                 _nrbits = maxfunc(len(bin(max-1)), len(bin(min)))
                 if min >= 0:
                     _nrbits = len(bin(max-1))
                 elif max <= 0:
                     _nrbits = len(bin(min))
                 else:
                     # make sure there is a leading zero bit in positive 
numbers
                     _nrbits = maxfunc(len(bin(max-1))+1, len(bin(min)))


What is interesting about this is that the first assignment to _nrbits 
right after the if clause is actually overwritten by any of the 
following assignments.

So the reason for the -1,1 range to have 2 bits seems to lay in the 
comment about having a leading zero bit for positive numbers.

I might be oblivious and the reason is obvious, but I don't see it at 
the moment. Anyone can explain why I need a leading zero bit and cannot 
create a 1 bit intbv?

Cheers,

Guenter

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

We had a similar issue/discussion with the invert (not) function of  
the intbv class.  There seems to be a couple different specific use  
cases of the intbv.

1. Generic bit container, this is then MyHDL intbv when there is no  
min, no max value.  This is similar to the Verilog bit vector (reg [],  
wire []) or VHDLs std_logic_vector.

2. Unsigned number, this is the MyHDL min=0, similar to the Verilog  
bit vector, and VHDL unsigned()

3. Signed numbers, this is the MyHDL min is < 0,  similar to the  
Verilog signed (reg or wire, Verilog 2001 and later) and VHDL signed()

The current implementation seems have all the properties that Jan  
discussed, high level approach while maintaining the low-level  
hardware access for cases 1 and 2.  For case 3 there are the issues  
that Günter pointed out, you can't modify the msb and maintain the  
state of the signed number (or pass the bound checks).

Could we do something similar as the invert solution (not) and use the  
knowledge of the type of number being represented and modify the bits  
accordingly?

Below is the output example for a small change that I made to the bit  
vector class
 >>> from myhdl import *
 >>> x = intbv(0, min=-8, max=8)
 >>> x[3] = 1
 >>> x
intbv(-8L)
 >>> x[3] = 0
 >>> x
intbv(0L)

To implement the above I simply modified __setitems__ and used the  
_min and _nrbits values determine what type of number is being  
represented.  If the number is signed multiply the value by -1 if the  
msb is being modified.  There is probably a more elegant way to  
implement this but I think this approach will meet the requirements  
that have been discussed, which are

1.  Support high level modeling
2.  Support low level hardware modeling while maintaining high level  
representation
3.  Synthesizable

I believe the above approach (or one similar) will meet all the above  
requirements and put the work in the intbv class (good or bad?).

My 2 cents.




On Jun 11, 2008, at 2:52 PM, Günter Dannoritzer wrote:

> Jan Decaluwe wrote:
> ...
>> I'm now thinking aloud for the case you describe, sign-extension.
>>
>> The ideal solution might be if we could somehow give an addional
>> parameter to slicing, e.g. asking for "signed" slicing instead
>> of the default, unsigned. But I don't see how.
>
> We actually do that in the DeFixedInt class
>
>  http://www.dilloneng.com/documents/downloads/demodel/
>
> Similar to intbv for an instance of that class a bit width can be
> specified. The msb based on the specified width is considered the sign
> bit. The decision is made whether the msb is included in the slice or
> not. To quote from the doc string of the __getitem__ function:
>
>     When the slice includes the sign bit it is taken over to the  
> return
>     value. If the sign bit is excluded the bits are taken as is with  
> the
>     sign bit set to 0.
>
>     For example using the 4-bit number -6 = b1010, slicing bits 3:1  
> -->
>     b101 includes the sign bit, the result is -3.
>
>     Now using the 4-bit number -3 = b1101, slicing bits 2:1 --> b10,
>     however, the slice excludes the sign bit, hence the result is 2.
>
>
> However, for the case of intbv I would not focus on where the bits  
> come
> from, but rather where they should go to. So if the destination is
> supposed to be signed, then don't worry about where the bits come  
> from.
> With a slice there is a fixed number of bits and depending on how this
> slice gets assigned to the destination should make the decision about
> the sign of the destination. So let's say the destination is a signed
> intbv with _nrbits set and the slice gets assigned to it. If that  
> slice
> matches _nrbits and in the slice the msb is set, that should turn the
> value into a negative value.
>
>>
>> Another interesting way might be to introduce methods to intbv's
>> at this point. We could do this like for python strings: the
>> methods don't modify the object in-place, but instead return a
>> new object with the modified value. (In MyHDL tradition,
>> those intbv methods would return integers.) The advantage
>> of this approach (as opposed to creating new functions)
>> is that adding new methods doesn't pollute the myhdl
>> namespace further.
>
> In a way the sign extension could be done through the __setitem__
> function. Basically the _min, _max attributes decide about how the  
> value
>  assigned is interpreted. If _min=0 the intbv instance is seen as
> unsigned. If _min = -_max the intbv instance is seen as signed and the
> assigned value is interpreted as signed with _nrbits specifying the  
> msb
> and if that bit in the assigned value is set, the value is considered
> negative.
>
> That would allow to assign bit slices that come actually from unsigned
> values and convert to a signed value.
>
> I am probably overlooking something, but maybe some ideas are a  
> starting
> point?
>
> Guenter
>
>
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
...
> I'm now thinking aloud for the case you describe, sign-extension.
> 
> The ideal solution might be if we could somehow give an addional
> parameter to slicing, e.g. asking for "signed" slicing instead
> of the default, unsigned. But I don't see how.

We actually do that in the DeFixedInt class

  http://www.dilloneng.com/documents/downloads/demodel/

Similar to intbv for an instance of that class a bit width can be 
specified. The msb based on the specified width is considered the sign 
bit. The decision is made whether the msb is included in the slice or 
not. To quote from the doc string of the __getitem__ function:

     When the slice includes the sign bit it is taken over to the return
     value. If the sign bit is excluded the bits are taken as is with the
     sign bit set to 0.

     For example using the 4-bit number -6 = b1010, slicing bits 3:1 -->
     b101 includes the sign bit, the result is -3.

     Now using the 4-bit number -3 = b1101, slicing bits 2:1 --> b10,
     however, the slice excludes the sign bit, hence the result is 2.


However, for the case of intbv I would not focus on where the bits come 
from, but rather where they should go to. So if the destination is 
supposed to be signed, then don't worry about where the bits come from. 
With a slice there is a fixed number of bits and depending on how this 
slice gets assigned to the destination should make the decision about 
the sign of the destination. So let's say the destination is a signed 
intbv with _nrbits set and the slice gets assigned to it. If that slice 
matches _nrbits and in the slice the msb is set, that should turn the 
value into a negative value.

> 
> Another interesting way might be to introduce methods to intbv's
> at this point. We could do this like for python strings: the
> methods don't modify the object in-place, but instead return a
> new object with the modified value. (In MyHDL tradition,
> those intbv methods would return integers.) The advantage
> of this approach (as opposed to creating new functions)
> is that adding new methods doesn't pollute the myhdl
> namespace further.

In a way the sign extension could be done through the __setitem__ 
function. Basically the _min, _max attributes decide about how the value 
  assigned is interpreted. If _min=0 the intbv instance is seen as 
unsigned. If _min = -_max the intbv instance is seen as signed and the 
assigned value is interpreted as signed with _nrbits specifying the msb 
and if that bit in the assigned value is set, the value is considered 
negative.

That would allow to assign bit slices that come actually from unsigned 
values and convert to a signed value.

I am probably overlooking something, but maybe some ideas are a starting 
point?

Guenter

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Günter Dannoritzer wrote:

>>I have not mixed the "signed" (limits set) and the generic bit-vector in 
>>the past with MyHDL, I usually have to approach the design from a MyHDL 
>>perspective.
> 
> 
> I think that is my deficit. I am getting comfortable with Verilog and 
> having a hard time getting rid of the low level bit twiddling and 
> looking at a problem form a higher level with MyHDL.

For numeric operations, I suspect the "higher level" comes naturally.
But there may still be a legitimate need for bit-level manipulations,
and MyHDL should have an answer to that also.

The general problem is to convert some bit pattern to another,
relevant bit pattern. The case you describe is sign-extension,
but there may be others. We would have to find the truly
relevant ones, and find a way to implement them in MyHDL,
including conversion.

I'm now thinking aloud for the case you describe, sign-extension.

The ideal solution might be if we could somehow give an addional
parameter to slicing, e.g. asking for "signed" slicing instead
of the default, unsigned. But I don't see how.

Another interesting way might be to introduce methods to intbv's
at this point. We could do this like for python strings: the
methods don't modify the object in-place, but instead return a
new object with the modified value. (In MyHDL tradition,
those intbv methods would return integers.) The advantage
of this approach (as opposed to creating new functions)
is that adding new methods doesn't pollute the myhdl
namespace further.

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] Slicing an unsigned intbv to a signed one

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

Christopher L. Felton wrote:
> I don't believe there is an easy way to do this in MyHDL.  

I think that is correct at the current stage.

 > I have  found
> is some cases that the Verilog way of doing thing isn't always a  good 
> way in MyHDL.  In most cases Verilog doesn't really care about  the 
> number that the bits represent.  And MyHDL is different (at least  the 
> case when using min and max)  that it is concerned with the actual  
> value that the bits represent.

The goal is that MyHDL should make certain things easier, while
keeping other things at least as easy as in Verilog/VHDL.

I believe that using intbv's can avoid unsigned/signed
confusion often found in VHDL/Verilog for numeric operations.
But of course, hardware designers also have a need to access and
manipulate bit representations. I believe it's possible to make
this as easy as in VHDL/Verilog. But we may not be there yet
completely, as this case shows.

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] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
...
>>
>> Setting the msb is setting the sign bit. However, that does not work in 
>> MyHDL, as the underlying data type is an integer and despite the value 
>> restriction the sign bit is not bit 3 in this case. MyHDL will just 
>> complain that the value exceeds the range.
> 
> Right, as in Python there is an "indefinite" number sign
> bits to the left.
> 
> An implication is that there is no way to make an intbv
> negative by setting some indivitual bit. To make it
> negative, you'd first have to do:
> 
> a[:] = -1
> 
> and after that, it would stay negative whatever you
> do to indivual bits.

How about if there would be an additional concat() function. Like 
concatSigned().

The difference to the concat() function would be that it considers the 
concatenated bits as signed and if the msb of the concatenation is set, 
it has the effect that value is considered negative?

For example:

 >>> a = concat('101')
 >>> print a, a.min, a.max
5 0 8

 >>> a = concatSigned('101')
 >>> print a, a.min, a.max
-3 -4 4

This would allow to simplify the creation of signed intbv from bit 
slices and could be convertible to Verilog for example. I am not that 
familiar with VHDL to know how the signed values are handled there.

Guenter

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

Günter Dannoritzer wrote:

> For example in Verilog you can do:
> 
>    reg signed  [3:0] a;
>    reg         [3:0] b;
> 
>    a[3] = 1'b1;
>    b[3] = 1'b1;
>    $display("a: %d b: %d", a,b);
> 
> a: -8 b:  8
> 
> Setting the msb is setting the sign bit. However, that does not work in 
> MyHDL, as the underlying data type is an integer and despite the value 
> restriction the sign bit is not bit 3 in this case. MyHDL will just 
> complain that the value exceeds the range.

Right, as in Python there is an "indefinite" number sign
bits to the left.

An implication is that there is no way to make an intbv
negative by setting some indivitual bit. To make it
negative, you'd first have to do:

a[:] = -1

and after that, it would stay negative whatever you
do to indivual bits.

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] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Christopher L. Felton wrote:
> I don't believe there is an easy way to do this in MyHDL.  I have found 
> is some cases that the Verilog way of doing thing isn't always a good 
> way in MyHDL.  In most cases Verilog doesn't really care about the 
> number that the bits represent.  And MyHDL is different (at least the 
> case when using min and max)  that it is concerned with the actual value 
> that the bits represent.

Well, I think the core difference is that Verilog really only considers 
the bits as specified whereas in MyHDL there is still an integer data 
type underneath.

For example in Verilog you can do:

   reg signed  [3:0] a;
   reg         [3:0] b;

   a[3] = 1'b1;
   b[3] = 1'b1;
   $display("a: %d b: %d", a,b);

a: -8 b:  8

Setting the msb is setting the sign bit. However, that does not work in 
MyHDL, as the underlying data type is an integer and despite the value 
restriction the sign bit is not bit 3 in this case. MyHDL will just 
complain that the value exceeds the range.

...
> 
> I have not mixed the "signed" (limits set) and the generic bit-vector in 
> the past with MyHDL, I usually have to approach the design from a MyHDL 
> perspective.

I think that is my deficit. I am getting comfortable with Verilog and 
having a hard time getting rid of the low level bit twiddling and 
looking at a problem form a higher level with MyHDL.

> 
> Below is a version that worked, I don't think it is an approach that you 
> would want to take though.  It synthesizes correctly, if you look at the 
> Verilog netlist for the Xilinx XST synthesis tool.  You are relying a 
> lot on the synthesis tool to determine that you are doing nothing but 
> relocating bits.

Thanks for the code. Interesting to see how it could work.

Cheers,

Guenter

Re: [myhdl-list] Slicing an unsigned intbv to a signed one

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

I don't believe there is an easy way to do this in MyHDL.  I have  
found is some cases that the Verilog way of doing thing isn't always a  
good way in MyHDL.  In most cases Verilog doesn't really care about  
the number that the bits represent.  And MyHDL is different (at least  
the case when using min and max)  that it is concerned with the actual  
value that the bits represent.

As you mentioned you are looking for a way to start out representing  
the value as a generic collection of bits and then convert slices of  
the bit-vector to a signed version.  Also as you pointed out, in  
Verilog if you need the language to know that the value is signed (for  
signed extension or other built in operators that the sign would  
affect) you can essentially cast with  the $signed or by using signed  
types.

I have not mixed the "signed" (limits set) and the generic bit-vector  
in the past with MyHDL, I usually have to approach the design from a  
MyHDL perspective.

Below is a version that worked, I don't think it is an approach that  
you would want to take though.  It synthesizes correctly, if you look  
at the Verilog netlist for the Xilinx XST synthesis tool.  You are  
relying a lot on the synthesis tool to determine that you are doing  
nothing but relocating bits.

[myhdl-list] Slicing an unsigned intbv to a signed one

[Günter D. <dan...@we...>]

Hi,

I try to figure out whether there is a simple way to slice bits from an 
unsigned intbv and assign them to a signed intbv and have the msb of the 
slice specify the sign of the signed intbv? In addition to that it 
should be convertible with toVerilog/VHDL.

For example, what I try to do is split up a 8 bit wide data word that is 
considered unsigned, that means min=0 and max=256, into two 4 bit wide 
data words with those being considered signed, meaning min=-8 max = 8.

In Verilog that can be done using the $signed() system task. Is there a 
simple way to do that with myhdl?

The problem I am running into is when the msb in the slice is set, that 
when assigning it to a signed intbv it is complaining that the value 
exceeds the max allowed value as the slice is considered a positive value.

Thanks for the help.

Cheers,

Guenter

[myhdl-list] OT: Increase in SPAM after post

[Günter D. <dan...@we...>]

Hi,

After posting on the myhdl mailing list I noticed that I received more 
spam the recent days. My suspicion is that this is due to the gmane 
usenet interface.

Doing some search I found the information that gmane supports the 
encryption of email addresses:

http://gmane.org/tmda.php

The gist is that the mail needs to have an extended header:

X-Archive: encrypt

Then gmane will encrypt all email addresses it finds in the post.

For Thunderbird this page explains how to add that feature to a message:

http://kb.mozillazine.org/Custom_headers

I did my last post and this one with that feature enabled and checking 
the post in the gmane usenet list I see that I don't see my email 
address anymore.

Just thought this might be interesting to share.

Guenter

Re: [myhdl-list] GeSHi version; was blocking and non-blocking assignments in toVerilog code.

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:

>>
>> Do you know what version of GeSHi you are using?
> 
> I read this in the dokuwiki files I'm using:
> 
> /** The version of this GeSHi file */
> define('GESHI_VERSION', '1.0.7.21');

I got this reply from the GeSHi mailing list:

 >> The myhdl page does use a different color scheme. Like keywords are
 >some type of sand color, comments are gray. Now what is even more
 >strange is that the myhdl page suddenly in the line:
 >>
 >>    if ((goRight == 0)) begin
 >>          dir <= 1'b0|>;
 >The | is a bug with 1.0.7.21 trz updating that version to the latest
 >SVN
 >version and that bug should disappear. Mazbe it|s also the reason for
 >the misinterpretation of that char there.

So it seems like that this is a bug with 1.0.7.21. They are in code 
freeze now and plan to release a new version soon. So maybe we can try 
that again then.

But maybe the Verilog syntax highlighter will already be part of that 
next release.

Guenter

Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.

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

Günter Dannoritzer wrote:

> 
> 
> OK, got it, I just thought that the color was weired. I haven't heard 
> anything back yet. I will do some more reading to see what possibly 
> could cause that.
> 
> Do you know what version of GeSHi you are using?

I read this in the dokuwiki files I'm using:

/** The version of this GeSHi file */
define('GESHI_VERSION', '1.0.7.21');

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] blocking and non-blocking assignments in toVerilog code.

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
> 
>> Now, I have another question about a Verilog construct I haven't seen 
>> yet. Again in the Johnson Counter example in the Verilog code there is 
>> this construct:
>>
>>    dir = 1'b0|>;
>>
>> What does the "|>" stand for?
> 
> Nothing - it must be a geshi thing :-)

How funny. And I thought I missed something in understanding Verilog :-)

> 
> This was the "strange" thing I was talking about before. I have
> temporarily reinstalled my previous verilog.php file, and then
> it's not there as you can see on the web site.

OK, got it, I just thought that the color was weired. I haven't heard 
anything back yet. I will do some more reading to see what possibly 
could cause that.

Do you know what version of GeSHi you are using?

Guenter

Re: [myhdl-list] blocking and non-blocking assignments in toVerilog code.

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

Günter Dannoritzer wrote:

> 
> Now, I have another question about a Verilog construct I haven't seen 
> yet. Again in the Johnson Counter example in the Verilog code there is 
> this construct:
> 
>    dir = 1'b0|>;
> 
> What does the "|>" stand for?

Nothing - it must be a geshi thing :-)

This was the "strange" thing I was talking about before. I have
temporarily reinstalled my previous verilog.php file, and then
it's not there as you can see on the web site.

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] OT; Verilog syntax highlighter for GeSHi

[Günter D. <dan...@we...>]

Jan Decaluwe wrote:
> Günter Dannoritzer wrote:
...
>>
>> The keywords are actually to be brown. There must be something else, 
>> like from the color scheme of the web page that takes over and adjusts 
>> the used colors?
> 
> Mm, I remember vaguely that dokuwiki does something like that,
> I'll have to look into it more closely.
> 

I have posted a question about that to the GeSHi-devel mailing list. 
Will see whether I am getting some feed back from there.

Guenter

Re: [myhdl-list] OT; Verilog syntax highlighter for GeSHi

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

Günter Dannoritzer wrote:
> Jan Decaluwe wrote:
> ...
> 
>>I have now included your file. Not sure this is what you'd expect.
>>I also see something strange with rendering constants like 1'b0.
> 
> 
> The keywords are actually to be brown. There must be something else, 
> like from the color scheme of the web page that takes over and adjusts 
> the used colors?

Mm, I remember vaguely that dokuwiki does something like that,
I'll have to look into it more closely.

-- 
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] Moved to webfaction

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

Brendan Rankin wrote:

> I have a couple of sites (well... 5) there, myself.  Webfaction are great and
> their panel stuff is teh bomb!

... although right after I had signed up, they had a fire in one of their
datacenters and my server was down for a couple of days :-(
I hope it wasn't something I did :-)

http://statusblog.webfaction.com/

Jan

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