myhdl-list

[myhdl-list] fixed_point library and VHDL generation

[Jan L. <jan...@et...>]

Hi all,
i have solved my issues regarding Christopher's fixed_point library :-)

There is one more thing I want to share. The following situation:

a = Signal(fxintbv(0,Q=(0,16))
b = Signal(fxintbv(0,Q=(0,16))

i = 2

@always(clk.posedge)
def beh():
	if b < 0:
		d = 1
	else:	
		d = -1
	a.next = a - ((d*b) >> i)

The way I made that code working correctly is just casting a to int:  
a.next = a*1 - ((d*b) >> i)

However, this is not the correct way, but I was too lazy to do it  
right, and I am still not really sure, what the correct way is.

The second thing I want to share were two issues during VHDL  
synthesis. First, the assignments of constants of bit lengths greater  
32 does not work. I will append a patch for that, that uses bit  
strings in this case.

Re: [myhdl-list] fixed_point library and VHDL generation

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

Jan L.

Thanks for the input and glad to hear you are having fun with myhdl.  I
regret that I have not had more time to make the fixed_point library more
usable and flexible.  Thanks for keeping interest in some of the projects
(more inlined).

On Tue, Jan 12, 2010 at 12:33 PM, Jan Langer <jan...@et...
> wrote:

> Hi all,
> i have solved my issues regarding Christopher's fixed_point library :-)
>
> There is one more thing I want to share. The following situation:
>
> a = Signal(fxintbv(0,Q=(0,16))
> b = Signal(fxintbv(0,Q=(0,16))
>
> i = 2
>
> @always(clk.posedge)
> def beh():
>        if b < 0:
>                d = 1
>        else:
>                d = -1
>        a.next = a - ((d*b) >> i)
>
> The way I made that code working correctly is just casting a to int: a.next
> = a*1 - ((d*b) >> i)
>

The actual problem is that I relied on the lower level intbv to handle the
logical and shift operators. The lower level intbv operators simply return
an 'int' type.  I need to add the operator overloads (all of them) to the
fxintbv and have them return fxintbv type.  They you will not get the error.
 I will try to have the 0.4 release ASAP to fix this.


>
> However, this is not the correct way, but I was too lazy to do it right,
> and I am still not really sure, what the correct way is.
>
> The second thing I want to share were two issues during VHDL synthesis.
> First, the assignments of constants of bit lengths greater 32 does not work.
> I will append a patch for that, that uses bit strings in this case.
>
>
>
>
>
>  Second, local variables in processes hide global variables on top level.
> The following code generates wrong VHDL:
>
> ---------------------
>
> from myhdl import *
>
> def Block2(clk,b):
>        @always(clk.posedge)
>        def beh():
>                a = 4
>                b.next = b + a
>
>        return instances()
>
> def Block1(clk):
>        a = Signal(intbv(0)[4:])
>
>        b2 = Block2(clk,a)
>
>        return instances()
>
> clk = Signal(bool(0))
> toVHDL(Block1,clk)
>
> ----------------------
>
> You can work around that problem easily by giving unique names, but its
> quite annoying and hard to prevent when using third party blocks.
>
> Apart from me always posting about problems or issues I do not understand,
> I think myhdl is just a great effort in the direction I personally see
> hardware development evolve in the future.
>
> Best regards,
> Jan
>
> --
> Jan Langer
> (Telefon) +49-371-531-33158 / (PGP) F1B8C1CC
> Schaltkreis- und Systementwurf / TU Chemnitz
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] fixed_point library and VHDL generation

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

On Tue, Jan 12, 2010 at 3:30 PM, Christopher Felton
<chr...@gm...>wrote:

> Jan L.
>
> Thanks for the input and glad to hear you are having fun with myhdl.  I
> regret that I have not had more time to make the fixed_point library more
> usable and flexible.  Thanks for keeping interest in some of the projects
> (more inlined).
>
> On Tue, Jan 12, 2010 at 12:33 PM, Jan Langer <
> jan...@et...> wrote:
>
>> Hi all,
>> i have solved my issues regarding Christopher's fixed_point library :-)
>>
>> There is one more thing I want to share. The following situation:
>>
>> a = Signal(fxintbv(0,Q=(0,16))
>> b = Signal(fxintbv(0,Q=(0,16))
>>
>> i = 2
>>
>> @always(clk.posedge)
>> def beh():
>>        if b < 0:
>>                d = 1
>>        else:
>>                d = -1
>>        a.next = a - ((d*b) >> i)
>>
>> The way I made that code working correctly is just casting a to int:
>> a.next = a*1 - ((d*b) >> i)
>>
>
> The actual problem is that I relied on the lower level intbv to handle the
> logical and shift operators. The lower level intbv operators simply return
> an 'int' type.  I need to add the operator overloads (all of them) to the
> fxintbv and have them return fxintbv type.  They you will not get the error.
>  I will try to have the 0.4 release ASAP to fix this.
>
>
>>
>> Oooppps, I spoke a little too early, the shift operators are overloaded
but there must be and issues somewhere.  I will look into it when I have a
little more time.

.chris

Re: [myhdl-list] fixed_point library and VHDL generation

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

On 1/12/10 3:30 PM, Christopher Felton wrote:
> Jan L.
>
>     a = Signal(fxintbv(0,Q=(0,16))
>     b = Signal(fxintbv(0,Q=(0,16))
>
>     i = 2
>
>     @always(clk.posedge)
>     def beh():
>             if b < 0:
>                     d = 1
>             else:
>                     d = -1
>             a.next = a - ((d*b) >> i)
>
>     The way I made that code working correctly is just casting a to int:
>     a.next = a*1 - ((d*b) >> i)
>
>
> The actual problem is that I relied on the lower level intbv to handle
> the logical and shift operators. The lower level intbv operators simply
> return an 'int' type.  I need to add the operator overloads (all of
> them) to the fxintbv and have them return fxintbv type.  They you will
> not get the error.  I will try to have the 0.4 release ASAP to fix this.

I have fixed these issues and put a new release on

http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv

I explain the issue incorrectly previously.  The math operators (add, 
sub, mul) were returning an int value the same as the underlying intbv 
(not the shift op).  That in turn would break the point alignment checking.

There should be more examples included in this release.

.chris

Re: [myhdl-list] fixed_point library and VHDL generation

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

Jan Langer wrote:
> Hi all,
> i have solved my issues regarding Christopher's fixed_point library :-)
> 
> There is one more thing I want to share. The following situation:
> 
> a = Signal(fxintbv(0,Q=(0,16))
> b = Signal(fxintbv(0,Q=(0,16))
> 
> i = 2
> 
> @always(clk.posedge)
> def beh():
>     if b < 0:
>         d = 1
>     else:   
>         d = -1
>     a.next = a - ((d*b) >> i)
> 
> The way I made that code working correctly is just casting a to int: 
> a.next = a*1 - ((d*b) >> i)

What exactly wasn't working correctly? I believe that similar
code with intbv should work without problems.

> However, this is not the correct way, but I was too lazy to do it right, 
> and I am still not really sure, what the correct way is.
> 
> The second thing I want to share were two issues during VHDL synthesis. 
> First, the assignments of constants of bit lengths greater 32 does not 
> work. I will append a patch for that, that uses bit strings in this case.

The convertor has some provisions to handle this type of problems,
please let me know where it still goes wrong.

>  Second, local variables in processes hide global variables on top 
> level. The following code generates wrong VHDL:
> 
> ---------------------
> 
> from myhdl import *
> 
> def Block2(clk,b):
>     @always(clk.posedge)
>     def beh():
>         a = 4
>         b.next = b + a
> 
>     return instances()
> 
> def Block1(clk):
>     a = Signal(intbv(0)[4:])
>     
>     b2 = Block2(clk,a)
> 
>     return instances()
> 
> clk = Signal(bool(0))
> toVHDL(Block1,clk)
> 
> ----------------------
> 
> You can work around that problem easily by giving unique names, but its 
> quite annoying and hard to prevent when using third party blocks.

Correct. At this moment, when the hierarchy is flattened, ports and
signals are given new names in one namespace, and there are no
provisions to prevent name clashes. I have been thinking about a
good way to handle all cases, but it's not always that straightforward.


> 
> Apart from me always posting about problems or issues I do not 
> understand, I think myhdl is just a great effort in the direction I 
> personally see hardware development evolve in the future.
> 
> Best regards,
> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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] fixed_point library and VHDL generation

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

On Jan 15, 2010, at 2:31 AM, Jan Decaluwe wrote:

> Jan Langer wrote:
>> Hi all,
>> i have solved my issues regarding Christopher's fixed_point  
>> library :-)
>>
>> There is one more thing I want to share. The following situation:
>>
>> a = Signal(fxintbv(0,Q=(0,16))
>> b = Signal(fxintbv(0,Q=(0,16))
>>
>> i = 2
>>
>> @always(clk.posedge)
>> def beh():
>>    if b < 0:
>>        d = 1
>>    else:
>>        d = -1
>>    a.next = a - ((d*b) >> i)
>>
>> The way I made that code working correctly is just casting a to int:
>> a.next = a*1 - ((d*b) >> i)
>
> What exactly wasn't working correctly? I believe that similar
> code with intbv should work without problems.

Correct, the intbv would work correctly and the bug is in the fxintbv.

Simple example why you would use the fxintbv you can do the following
x = fxintbv(3.142592).  Yes, you could do the conversion by hand and  
pass the integer to intbv.  The fixed point classes give some  
additional features when dealing with non-integers numbers.

>
>> However, this is not the correct way, but I was too lazy to do it  
>> right,
>> and I am still not really sure, what the correct way is.
>>
>> The second thing I want to share were two issues during VHDL  
>> synthesis.
>> First, the assignments of constants of bit lengths greater 32 does  
>> not
>> work. I will append a patch for that, that uses bit strings in this  
>> case.
>
> The convertor has some provisions to handle this type of problems,
> please let me know where it still goes wrong.
>
>> Second, local variables in processes hide global variables on top
>> level. The following code generates wrong VHDL:
>>
>> ---------------------
>>
>> from myhdl import *
>>
>> def Block2(clk,b):
>>    @always(clk.posedge)
>>    def beh():
>>        a = 4
>>        b.next = b + a
>>
>>    return instances()
>>
>> def Block1(clk):
>>    a = Signal(intbv(0)[4:])
>>
>>    b2 = Block2(clk,a)
>>
>>    return instances()
>>
>> clk = Signal(bool(0))
>> toVHDL(Block1,clk)
>>
>> ----------------------
>>
>> You can work around that problem easily by giving unique names, but  
>> its
>> quite annoying and hard to prevent when using third party blocks.
>
> Correct. At this moment, when the hierarchy is flattened, ports and
> signals are given new names in one namespace, and there are no
> provisions to prevent name clashes. I have been thinking about a
> good way to handle all cases, but it's not always that  
> straightforward.
>
>
>>
>> Apart from me always posting about problems or issues I do not
>> understand, I think myhdl is just a great effort in the direction I
>> personally see hardware development evolve in the future.
>>
>> Best regards,
>> Jan
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast  
>> and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] fixed_point library and VHDL generation

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

> Correct, the intbv would work correctly and the bug is in the fxintbv.
> 
> Simple example why you would use the fxintbv you can do the following
> x = fxintbv(3.142592).  Yes, you could do the conversion by hand and  
> pass the integer to intbv.  The fixed point classes give some  
> additional features when dealing with non-integers numbers.
> 

Embarrassing yes, I fat fingered the value of pi.

Re: [myhdl-list] fixed_point library and VHDL generation

[Jan L. <jan...@et...>]

Am 15.01.2010 um 09:31 schrieb Jan Decaluwe:
> Jan Langer wrote:
>> The second thing I want to share were two issues during VHDL  
>> synthesis.
>> First, the assignments of constants of bit lengths greater 32 does  
>> not
>> work. I will append a patch for that, that uses bit strings in this  
>> case.
>
> The convertor has some provisions to handle this type of problems,
> please let me know where it still goes wrong.


Hello Jan,
I think it still goes wrong. Just checked with the current repository.
Jan

-- 
Jan Langer
(Tel) +49-371-531-33158 / (PGP) F1B8C1CC
Schaltkreis- und Systementwurf / TU Chemnitz