myhdl-list — Mailing list for discussions on MyHDL

Re: [myhdl-list] _cosimulation.py fails on Windows

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

Am Wednesday 13 January 2010 10:21:43 schrieben Sie:
> The error is:
> child_pid = self._child_pid = os.fork()
> AttributeError: 'module' object has no attribute 'fork'
> 
> Can anybody point me to the possible reason?
> Is it in myhdl or poython itself.


This is a Python issue, but intented to be used that way in myhdl. os.fork() 
is in Python only supported under Linux or on Windows using cygwin.

Cheers,

Guenter

[myhdl-list] _cosimulation.py fails on Windows

[Robert S. <rob...@gm...>]

The error is:
child_pid = self._child_pid = os.fork()
AttributeError: 'module' object has no attribute 'fork'

Can anybody point me to the possible reason?
Is it in myhdl or poython itself.
Regards
Robert

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

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

[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] len() of an intbv

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

>
>
>
> Is ther a particular reason why the number of bits (according to the len()
> finction is 1 in following example:
>
> a = intbv(0, min=0, max=1)
> len(a)
> --> returns 1 instead of an expected 0
>
> I thought 'a' can only store '0' in this case, and you don't need any bits
> for doing that.
>
> b = intbv(0,min=0,max=2)
> len(b)
> --> returns 1
>

This has come up before in this newsgroup.  I can't remember the reason (if
one) and haven't had time to search the old posts for the topic.  If you
look at the code (_intbv.py line 45) what happens is that the conversion to
binary string representation of 0 still creates a digit.

bin(0) = '0';   len(bin(0)) = 1

Not sure if this is intended or not but it does seem reasonable that you can
not have a 0 bit intbv.  It would default to a size of 1 for a zero range
value.

.chris

[myhdl-list] len() of an intbv

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

Hi all,

Is ther a particular reason why the number of bits (according to the len() finction is 1 in following example:

a = intbv(0, min=0, max=1)
len(a)
--> returns 1 instead of an expected 0

I thought 'a' can only store '0' in this case, and you don't need any bits for doing that. 

b = intbv(0,min=0,max=2)
len(b)
--> returns 1

This is not so important at the moment for me, but it should be interesting to know where this (according to me) unlogical behavior comes from.

Stefaan

Re: [myhdl-list] Signal getattr and setattr

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

Jan Decaluwe wrote:
> Chris:
> 
> I don't have a lot of time these days (moving to new house) but

No problem, this is not a bug often encountered and I have a work around 
for accessing the "contained" objects attributes/properties.  Enjoy 
moving to the new house!

> did your patch mean that __slots__ is the problem?

I don't believe __slots__ is the problem.  And you do get the 
performance increase from __slots__ but I don't know how much.

I believe the issue is how the copy works.  The copy tries to access 
variables before they exist?  I don't know the exact mechanism of the 
copy but that appears to be the issue.

By adding an attribute read in __init__ before it is set, a similar 
failure occurs.  Example first line of __init__ print self._val.

At this point two options would be remove __getattr__ or add __copy__ 
and __deepcopy__ to return a new instance and set attributes manually.

> 
> I would hesitate a lot to apply a patch that customizes __setattr__,
> and that makes every attribute access slower.

That is a good point, performance impact.  I do like the idea of a 
"transparent" Signal object but it is not looking to feasible.  But if 
the setattr isn't  propagated to the "contained" object does it make 
sense to allow __getattr__?


> 
> On the other hand, if __slots__ is the culprit, it would be one more
> argument to remove it. Explanations later.
> 
> (Removing __slots__ shouldn't change signal behavior, but may
> break some unit tests also.)
> 
> Jan
> 
> 
> 
> Christopher L. Felton wrote:
>> Ignore the patch that was previously sent for now!  I was careless and 
>> didn't run the regression tests.  After running the "tests" it exposed 
>> some issues.  It appears this method breaks the properties.
>>
>> Back to the drawing board.
>>
>> .chris
>>
>> Christopher L. Felton wrote:
>>> Attached is a patch with some modification to __getattr__ and adds the 
>>> __setattr__ in _Signal.py.
>>>
>>> I like the idea that the Signal class is "transparent".  Meaning that 
>>> the object that the Signal contains, its (the contained object) 
>>> attributes and properties can be accessed.
>>>
>>> The change checks the "slots" before accessing the "objects" (self._val) 
>>> attributes.
>>>
>>> The patch fixes the bug I previously posted, max recursion depth.
>>>
>>> I think I generated the bundle/patch correctly and tried to verify with 
>>> a separate repository clone.  The workspace I created the bundle from 
>>> has additional changes (mainly error/warning statements and prints) that 
>>> are not ready to be pushed.  The only changes should be the couple lines 
>>> in _Signal.py
>>>
>>> .chris
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>> ------------------------------------------------------------------------------
>> 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 
> 
> 

Re: [myhdl-list] Signal getattr and setattr

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

Chris:

I don't have a lot of time these days (moving to new house) but
did your patch mean that __slots__ is the problem?

I would hesitate a lot to apply a patch that customizes __setattr__,
and that makes every attribute access slower.

On the other hand, if __slots__ is the culprit, it would be one more
argument to remove it. Explanations later.

(Removing __slots__ shouldn't change signal behavior, but may
break some unit tests also.)

Jan



Christopher L. Felton wrote:
> Ignore the patch that was previously sent for now!  I was careless and 
> didn't run the regression tests.  After running the "tests" it exposed 
> some issues.  It appears this method breaks the properties.
> 
> Back to the drawing board.
> 
> .chris
> 
> Christopher L. Felton wrote:
>> Attached is a patch with some modification to __getattr__ and adds the 
>> __setattr__ in _Signal.py.
>>
>> I like the idea that the Signal class is "transparent".  Meaning that 
>> the object that the Signal contains, its (the contained object) 
>> attributes and properties can be accessed.
>>
>> The change checks the "slots" before accessing the "objects" (self._val) 
>> attributes.
>>
>> The patch fixes the bug I previously posted, max recursion depth.
>>
>> I think I generated the bundle/patch correctly and tried to verify with 
>> a separate repository clone.  The workspace I created the bundle from 
>> has additional changes (mainly error/warning statements and prints) that 
>> are not ready to be pushed.  The only changes should be the couple lines 
>> in _Signal.py
>>
>> .chris
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> 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
> 
> 
> ------------------------------------------------------------------------------
> 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 


-- 
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] Signal getattr and setattr

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

Ignore the patch that was previously sent for now!  I was careless and 
didn't run the regression tests.  After running the "tests" it exposed 
some issues.  It appears this method breaks the properties.

Back to the drawing board.

.chris

Christopher L. Felton wrote:
> Attached is a patch with some modification to __getattr__ and adds the 
> __setattr__ in _Signal.py.
> 
> I like the idea that the Signal class is "transparent".  Meaning that 
> the object that the Signal contains, its (the contained object) 
> attributes and properties can be accessed.
> 
> The change checks the "slots" before accessing the "objects" (self._val) 
> attributes.
> 
> The patch fixes the bug I previously posted, max recursion depth.
> 
> I think I generated the bundle/patch correctly and tried to verify with 
> a separate repository clone.  The workspace I created the bundle from 
> has additional changes (mainly error/warning statements and prints) that 
> are not ready to be pushed.  The only changes should be the couple lines 
> in _Signal.py
> 
> .chris
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 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

[myhdl-list] Signal getattr and setattr

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

Attached is a patch with some modification to __getattr__ and adds the 
__setattr__ in _Signal.py.

I like the idea that the Signal class is "transparent".  Meaning that 
the object that the Signal contains, its (the contained object) 
attributes and properties can be accessed.

The change checks the "slots" before accessing the "objects" (self._val) 
attributes.

The patch fixes the bug I previously posted, max recursion depth.

I think I generated the bundle/patch correctly and tried to verify with 
a separate repository clone.  The workspace I created the bundle from 
has additional changes (mainly error/warning statements and prints) that 
are not ready to be pushed.  The only changes should be the couple lines 
in _Signal.py

.chris

Re: [myhdl-list] fxintbv dependency on dspsim

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

Jan Decaluwe wrote:
> I'm not a fixed-point specialist, but am I correct in thinking that
> things would be considerably simpler if there would a fixed point
> datatype that we could map to in VHDL/Verilog?
> 
> I seem to have read that such a (synthesizable) datatype exists for
> VHDL, but not yet for Verilog. But even it's VHDL-only, it seems like
> an interesting path to investigate?

I believe there is a fixed-point type in the latest standard of VHDL 
(VHDL-2007).  I don't know much more about the new VHDL type.  If it has 
been ratified, supported in tools, etc.

 From a quick search, the VHDL fixed-point type doesn't do 
auto-promotion (what size should the result be).  The new types 
introduce the negative index in ranges (???).  I don't think it supports 
all features the lib attempts to support.

Regardless, I think this is one of highlights of MyHDL to handle these 
kinds "types".  I think the current MyHDL approach gives the design much 
more flexibility.  A designer might not always want the "default" rules 
for handling fixed-point.  If mapped to the VHDL type I think there 
would be a "collision" of rules and loss of control.

.chris

> 
> Jan
> 
> Felton Christopher wrote:
>> Jan L.,
>>
>> After our conversation I was thinking about this a little more.  Think I 
>> came up with a better scheme.  This still uses the elaboration phase to 
>> determine the size/alignment/type but I think it is more clear.  This 
>> way you can use an arbitrarily complex expression.  But the expression 
>> will have to be outside the generators (behavioral statement) so that 
>> the elaborate phase can determine the correct type/size.  And also in 
>> the generator for conversion/simulation.
>>
>> Example:
>> def fx_mix_ex(a,b,c,d,e):
>>
>>     e.Q = (b-a)*c + d
>>     @always_comb
>>     def rtl():
>>         e.next = (b-a)*c + d
>>
>>     return rtl
>>
>> But I have hit some issues with the base myhdl.Signal component (more 
>> than likely my mis-understanding and an issue in my stuff).  I will try 
>> to resolve these and let you know how it goes.  Attached is an updated 
>> version with the "Q" property.  Also the "Q" property removes all the 
>> *Rep methods.
>>
>> Thanks again for the previous patches.
>> .chris
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> On Dec 10, 2009, at 9:52 AM, Christopher L. Felton wrote:
>>
>>> Jan Langer wrote:
>>>> Hello Christopher,
>>>>
>>>> Am 10.12.2009 um 03:57 schrieb Christopher L. Felton:
>>>>> Jan Langer wrote:
>>>>>> Somehow, I dont really understand it. The return type of the 
>>>>>> fxintbv operators is just plain intbv, so I cannot write a - b*c 
>>>>>> for three fxintbv variables. If fxintbv does not take care of the 
>>>>>> point in operations and I need to remember and adjust it by hand, I 
>>>>>> dont see the advantages of fxintbv. fxint seems to do what I need, 
>>>>>> except the two questions I wrote yesterday. I am a little confused 
>>>>>> but maybe I just want the wrong things :-)
>>>>>>
>>>>> Correct, with the fxintbv a little more work needs to be done.  But 
>>>>> not as much as doing it all manually.  Keeping within the design 
>>>>> goals of MyHDL nothing will try to evaluate the expression x= a-b*c 
>>>>> and adjust the result.  But given the design of MyHDL and the 
>>>>> elaborate phase there are some options.  The fxintbv doesn't do the 
>>>>> auto promotion (adjusting the number of bits for the word) but there 
>>>>> are helper functions to determine the size of the word based on the 
>>>>> operations.
>>>>> These helper functions/methods help during design and analysis but 
>>>>> also can make the modules modular.  If an input size is adjusted the 
>>>>> module will automatically adjust.   The example in the  PDF (ooppps, 
>>>>> just notice didn't include everything in the PDF, my bad) or the 
>>>>> example in examples/sos/sos_hdl.py there is a function that gets the 
>>>>> types needed.  The function uses the fxintbv methods to determine 
>>>>> this.  This essentially auto-promotes.
>>>>>
>>>>> def getFxTypes(Q,N):
>>>>>  # Different fixed-point types (sizes) used
>>>>>  fx_t    = fxintbv(0, min=-1, max=1, res=2**-Q)
>>>>>  fxmul_t = fx_t.ProductRep(fx_t)
>>>>>  fxsum_t = fxmul_t.SummationRep(N)
>>>>>
>>>>>  return fx_t, fxmul_t, fxsum_t
>>>>>
>>>>> Right now there are a bunch of public functions to assist in 
>>>>> auto-promotion and alignment.  The ProductRep, AdditionRep, 
>>>>> SummationRep will determine the correct "type" given the inputs. 
>>>>>   For the specific example x = a-b*c something like the following 
>>>>> could be done
>>>>>
>>>>> def fxCalc(clk, x, a, b, c):
>>>>>    i_t  = fxintbv.ProductRep(b,c)
>>>>>  x_t  = fxintbv.AdditionRep(a, i_t)
>>>>>  x.NewRep(x_t.iwl, x_t.fwl)
>>>>>
>>>>>  @always(clk.posedge)
>>>>>  def rtl_result():
>>>>>      x.next = a-b*c
>>>>>
>>>>> return instances()
>>>>>
>>>>> In this scenario all the promotion and alignment etc will be 
>>>>> handled.  "x" will be adjusted in the elaboration phase based on the 
>>>>> a,b,c inputs.  It assumes that x, a, b, c are all of type fxintbv. 
>>>>>  The benefit of doing this is you will get the auto promotion of "x" 
>>>>> when the inputs change and you get some additional functions for 
>>>>> fixed point analysis.  I think this is a good balance between design 
>>>>> flexibility and automation.  The fxint does a lot more under the 
>>>>> hood (auto promotion, bit alignment) but it is not convertible.  I 
>>>>> don't think it makes sense for something like fxint to be 
>>>>> convertible.  You want a little more control when mapping to 
>>>>> hardware.  I think the fxintbv has the balance between right amount 
>>>>> of abstraction and design guidance.
>>>> Okay, I understand how its done. I will try it later. But I can't 
>>>> follow your argumentation that something like fxint should not be 
>>>> convertible. In my opinion, there is no semantic difference between 
>>>> the above code, which explicitly promotes the type, and implicit 
>>>> auto-promotion. The manual promotion will be used as a pattern and I 
>>>> dont see any additional control of the mapping process. I mean if 
>>>> there is a fixed and documented definition like
>>>>
>>>> a.b + c.d -> (max(a,c)+1).max(b,d)
>>>> a.b * c.d -> (a+c).(b+d)
>>>>
>>>> a mapping is easy to understand.
>>>>
>>>> I see that current myhdl might not be able to support a convertible 
>>>> auto-promotable fxint type, but somehow I think that would be 
>>>> desirable. :-)
>>>> Jan
>>>>
>>> It would require changes to the base MyHDL to evaluate the expressions 
>>> and generate the code.  I think this would be a fairly large project. 
>>>  MyHDL, for the most part, isn't that active in the conversion.  There 
>>> is a one to one mapping of expressions to the converted code.
>>> Arbitrarily complex expressions would have to handled.  Things like 
>>> having a "summation" embedded in a expression changes the rules that 
>>> you might want to apply.  The expression has to be decomposed such 
>>> that it would be an optimal synthesis of the expression.  Example If 
>>> you a take an expression like
>>> (a + b + c) * d
>>> You can apply the basic rules but if a,b and c are the same type (same 
>>> number bits and point alignment) more bits will be assigned to the 
>>> result than needed.  In general the addition result will require 
>>> another bit but a summation (multiple additions same type) only 
>>> requires log2(N) bits, where N is the number of additions.  This is a 
>>> general rule as well but it requires more advanced parsing of the 
>>> expressions which would have to be built into MyHDL.   Not saying it 
>>> cannot be done, just would take more effort than I would currently 
>>> have time for.
>>>
>>> At this point I don't think it is something that should be built into 
>>> the MyHDL language.  The fxint and fxintbv are simple 
>>> libraries/objects that can be used with MyHDL.  What might be possible 
>>> in the future (time is the limiting resource) is that MyHDL can be 
>>> modified slightly so that "plugins" can be added.  When an expression 
>>> is evaluate and unknown (non-convertible) types are present it can 
>>> search for a plugin with rules to guide the conversion.  This way the 
>>> base language doesn't explode with all kinds features but something 
>>> like you suggestion can be added.  Some serious thought would have to 
>>> be given to such an endeavor.  It is more complicated that single 
>>> expressions, could apply to blocks of expressions (like loops).  And 
>>> it would be changing the types on the fly, might require a two-pass 
>>> approach.  It would be a nice feature and a fun project but currently 
>>> not feasible.
>>>
>>> .chris
>>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 
> 

Re: [myhdl-list] MyHDL on Ubuntu

[Balau <ba...@us...>]

This work can be reused on debian-based distributions. The most famous
are Debian itself, Ubuntu (with Kubuntu, Edubuntu, etc...), Mint and
Knoppix.
As far as I know, other systems use completely different policies.

> On Dec 20, 2009, at 9:14 AM, Balau wrote:
>
> > Hello,
> >
> > I am currently working to package MyHDL for Ubuntu. I think it will
> > be an advantage for MyHDL, since it will be able to reach the
> > community of one of the most widespread Linux distribution (even if
> > I think the most used distribution for electronic designers is
> > Fedora Electronic Labs), and allow easy installation and updates.
> >
> > The process is not very simple but it does not imply any work for
> > the project developers, because it involves basically:
> > - getting the last release (for example myhdl-0.6)
> > - adding the "Debian" specific files for packaging
> > - build the package
> > - upload the built package to a public repository, that allows users
> > to download and update MyHDL.
> > I can take care of those steps, since I saw that the release cycle
> > of MyHDL is not pressing. It is also possible to push important
> > patches (for example security bugs) on the repository before the
> > next MyHDL release.
>
> Do you know if the packages for different systems, i.e. BSD ports and
> Mac ports, are similar? I believe the BSD ports are tcl scripts that
> inform the system where to download etc? I understand this effort is
> specifically for Ubuntu, I wonder if other system packages would be
> easily derived for this effort?
>
> .chris

Re: [myhdl-list] MyHDL on Ubuntu

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

On Dec 20, 2009, at 9:14 AM, Balau wrote:

> Hello,
>
> I am currently working to package MyHDL for Ubuntu. I think it will  
> be an advantage for MyHDL, since it will be able to reach the  
> community of one of the most widespread Linux distribution (even if  
> I think the most used distribution for electronic designers is  
> Fedora Electronic Labs), and allow easy installation and updates.
>
> The process is not very simple but it does not imply any work for  
> the project developers, because it involves basically:
> - getting the last release (for example myhdl-0.6)
> - adding the "Debian" specific files for packaging
> - build the package
> - upload the built package to a public repository, that allows users  
> to download and update MyHDL.
> I can take care of those steps, since I saw that the release cycle  
> of MyHDL is not pressing. It is also possible to push important  
> patches (for example security bugs) on the repository before the  
> next MyHDL release.

Do you know if the packages for different systems, i.e. BSD ports and  
Mac ports, are similar?  I believe the BSD ports are tcl scripts that  
inform the system where to download etc?  I understand this effort is  
specifically for Ubuntu, I wonder if other system packages would be  
easily derived for this effort?

.chris

[myhdl-list] MyHDL on Ubuntu

[Balau <ba...@us...>]

Hello,

I am currently working to package MyHDL for Ubuntu. I think it will be an
advantage for MyHDL, since it will be able to reach the community of one of
the most widespread Linux distribution (even if I think the most used
distribution for electronic designers is Fedora Electronic Labs), and allow
easy installation and updates.

The process is not very simple but it does not imply any work for the
project developers, because it involves basically:
- getting the last release (for example myhdl-0.6)
- adding the "Debian" specific files for packaging
- build the package
- upload the built package to a public repository, that allows users to
download and update MyHDL.
I can take care of those steps, since I saw that the release cycle of MyHDL
is not pressing. It is also possible to push important patches (for example
security bugs) on the repository before the next MyHDL release.

I am writing here to inform the owner Jan Decaluwe and to get feedback, also
from the MyHDL community.

Regards,
Francesco

Re: [myhdl-list] Adding Error Messages to MyHDL source

[Ben <ben...@gm...>]

On Thu, Dec 17, 2009 at 16:20, Jan Decaluwe <ja...@ja...> wrote:
> Thanks for using mercurial for patches!
> I have applied an pushed it.

Thanks, thank you for using Mercurial as VCS !

>
> Note:
>
> - It think the idiomatic way to check for None should
>  use 'is', not '=='

Make sense, my bad, want a patch that correct it ?

> - your patch reminds that I have to check whether it really
> makes sense to support 'None' as an intbv value. I once thought
> this was necessary to support 'X' and 'Z', but I now think
> this is not true: we can use special signals for that and
> leave the intbv simpler and more consistent. Now the 'None'
> support looks clumsy and half-baked (my bad).

The main trouble is Signal declaration and the initialisation that
comes with it, that taken apart, I don't use None as signal value. and
that's anyway being reported by the traceVCD step. So no trouble for
me to remove anything None related in the intbv type.

Regards,
Benoit

Re: [myhdl-list] Adding Error Messages to MyHDL source

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

Thanks for using mercurial for patches!
I have applied an pushed it.

Note:

- It think the idiomatic way to check for None should
  use 'is', not '=='
- your patch reminds that I have to check whether it really
makes sense to support 'None' as an intbv value. I once thought
this was necessary to support 'X' and 'Z', but I now think
this is not true: we can use special signals for that and
leave the intbv simpler and more consistent. Now the 'None'
support looks clumsy and half-baked (my bad).

Jan


Ben wrote:
> Hi there,
> 
> Thanks for reminding me that I had such a patch lying on my shelve also.
> 
> Here it is:
> 
> # HG changeset patch
> # User Benoit Allard <be...@ae...>
> # Date 1260897892 -3600
> # Node ID 4a33c0707e2268147ec8cc68330b1002772dbad4
> # Parent  1342b9d95452771835589c77af56d873b2704ac6
> Improve Error messages
> 
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_always_comb.py
> --- a/myhdl/_always_comb.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/_always_comb.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -37,7 +37,7 @@
>  _error.ArgType = "always_comb argument should be a classic function"
>  _error.NrOfArgs = "always_comb argument should be a function without arguments"
>  _error.Scope = "always_comb argument should be a local function"
> -_error.SignalAsInout = "signal used as inout in always_comb function argument"
> +_error.SignalAsInout = "signal (%s) used as inout in always_comb
> function argument"
>  _error.EmbeddedFunction = "embedded functions in always_comb function
> argument not supported"
>  _error.EmptySensitivityList= "sensitivity list is empty"
> 
> @@ -56,8 +56,11 @@
>      # handle free variables
>      if func.func_code.co_freevars:
>          for n, c in zip(func.func_code.co_freevars, func.func_closure):
> -            obj = _cell_deref(c)
> -            symdict[n] = obj
> +            try:
> +                obj = _cell_deref(c)
> +                symdict[n] = obj
> +            except NameError:
> +                raise NameError(n)
>      c = _AlwaysComb(func, symdict)
>      return c
> 
> @@ -163,7 +166,7 @@
>              self.visit(n)
>          for n in inputs:
>              if n in outputs:
> -                raise AlwaysCombError(_error.SignalAsInout)
> +                raise AlwaysCombError(_error.SignalAsInout % n)
> 
>      def visit_FunctionDef(self, node):
>          if self.toplevel:
> @@ -191,7 +194,7 @@
>              elif self.context == OUTPUT:
>                  self.outputs.add(id)
>              elif self.context == INOUT:
> -                raise AlwaysCombError(_error.SignalAsInout)
> +                raise AlwaysCombError(_error.SignalAsInout % id)
>              else:
>                  raise AssertionError("bug in always_comb")
> 
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_concat.py
> --- a/myhdl/_concat.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/_concat.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -63,7 +63,7 @@
>              raise TypeError("concat: inappropriate argument type: %s" \
>                              % type(arg))
>          if not w:
> -            raise TypeError, "concat: arg to concat should have length"
> +            raise TypeError, "concat: arg  %d to concat should have
> length" % arg
>          width += w
>          val = val*(2**w) + v
> 
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_extractHierarchy.py
> --- a/myhdl/_extractHierarchy.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/_extractHierarchy.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -41,7 +41,7 @@
>  class _error:
>      pass
>  _error.NoInstances = "No instances found"
> -_error.InconsistentHierarchy = "Inconsistent hierarchy - are all
> instances returned?"
> +_error.InconsistentHierarchy = "Inconsistent hierarchy inside %s -
> are all instances returned ?"
> 
> 
>  class _Instance(object):
> @@ -170,11 +170,11 @@
>          names[id(obj)] = name
>          absnames[id(obj)] = name
>          if not top_inst.level == 1:
> -                raise ExtractHierarchyError(_error.InconsistentHierarchy)
> +            raise ExtractHierarchyError(_error.InconsistentHierarchy % name)
>          for inst in hierarchy:
>              obj, subs = inst.obj, inst.subs
>              if id(obj) not in names:
> -                raise ExtractHierarchyError(_error.InconsistentHierarchy)
> +                raise
> ExtractHierarchyError(_error.InconsistentHierarchy % inst.name)
>              inst.name = names[id(obj)]
>              tn = absnames[id(obj)]
>              for sn, so in subs:
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_intbv.py
> --- a/myhdl/_intbv.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/_intbv.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -154,7 +154,11 @@
>                  self._val &= ~(1L << i)
>              self._checkBounds()
>          elif isinstance(key, slice):
> +            if val == None:
> +                raise ValueError, "cannot attribute None to a slice"
>              i, j = key.start, key.stop
> +            if (self._val == None) and (i != None) and (j != None):
> +                raise ValueError, "cannot slice value None"
>              if j is None: # default
>                  if i is None and self._val is None:
>                      self._val = val
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_traceSignals.py
> --- a/myhdl/_traceSignals.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/_traceSignals.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -140,6 +140,8 @@
>                  print >> f, "$upscope $end"
>          print >> f, "$scope module %s $end" % name
>          for n, s in sigdict.items():
> +            if s._val == None:
> +                raise ValueError("%s of module %s has no initial
> value" % (n, name))
>              if not s._tracing:
>                  s._tracing = 1
>                  s._code = namegen.next()
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/test/core/test_always_comb.py
> --- a/myhdl/test/core/test_always_comb.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/test/core/test_always_comb.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -136,7 +136,7 @@
>          try:
>              g = always_comb(h).gen
>          except AlwaysCombError, e:
> -            self.assertEqual(e.kind, _error.SignalAsInout)
> +            self.assertEqual(e.kind, _error.SignalAsInout % "c")
>          else:
>              self.fail()
> 
> @@ -148,7 +148,7 @@
>          try:
>              g = always_comb(h).gen
>          except AlwaysCombError, e:
> -            self.assertEqual(e.kind, _error.SignalAsInout)
> +            self.assertEqual(e.kind, _error.SignalAsInout % "c")
>          else:
>              self.fail()
> 
> diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/test/core/test_traceSignals.py
> --- a/myhdl/test/core/test_traceSignals.py	Tue Dec 15 18:45:10 2009 +0100
> +++ b/myhdl/test/core/test_traceSignals.py	Tue Dec 15 18:24:52 2009 +0100
> @@ -122,7 +122,7 @@
>          try:
>              dut = traceSignals(dummy)
>          except ExtractHierarchyError, e:
> -            self.assertEqual(e.kind, _error.InconsistentHierarchy)
> +            self.assertEqual(e.kind, _error.InconsistentHierarchy % "dummy")
>          else:
>              self.fail()
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 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] Adding Error Messages to MyHDL source

[Ben <ben...@gm...>]

Hi there,

Thanks for reminding me that I had such a patch lying on my shelve also.

Here it is:

# HG changeset patch
# User Benoit Allard <be...@ae...>
# Date 1260897892 -3600
# Node ID 4a33c0707e2268147ec8cc68330b1002772dbad4
# Parent  1342b9d95452771835589c77af56d873b2704ac6
Improve Error messages

diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_always_comb.py
--- a/myhdl/_always_comb.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/_always_comb.py	Tue Dec 15 18:24:52 2009 +0100
@@ -37,7 +37,7 @@
 _error.ArgType = "always_comb argument should be a classic function"
 _error.NrOfArgs = "always_comb argument should be a function without arguments"
 _error.Scope = "always_comb argument should be a local function"
-_error.SignalAsInout = "signal used as inout in always_comb function argument"
+_error.SignalAsInout = "signal (%s) used as inout in always_comb
function argument"
 _error.EmbeddedFunction = "embedded functions in always_comb function
argument not supported"
 _error.EmptySensitivityList= "sensitivity list is empty"

@@ -56,8 +56,11 @@
     # handle free variables
     if func.func_code.co_freevars:
         for n, c in zip(func.func_code.co_freevars, func.func_closure):
-            obj = _cell_deref(c)
-            symdict[n] = obj
+            try:
+                obj = _cell_deref(c)
+                symdict[n] = obj
+            except NameError:
+                raise NameError(n)
     c = _AlwaysComb(func, symdict)
     return c

@@ -163,7 +166,7 @@
             self.visit(n)
         for n in inputs:
             if n in outputs:
-                raise AlwaysCombError(_error.SignalAsInout)
+                raise AlwaysCombError(_error.SignalAsInout % n)

     def visit_FunctionDef(self, node):
         if self.toplevel:
@@ -191,7 +194,7 @@
             elif self.context == OUTPUT:
                 self.outputs.add(id)
             elif self.context == INOUT:
-                raise AlwaysCombError(_error.SignalAsInout)
+                raise AlwaysCombError(_error.SignalAsInout % id)
             else:
                 raise AssertionError("bug in always_comb")

diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_concat.py
--- a/myhdl/_concat.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/_concat.py	Tue Dec 15 18:24:52 2009 +0100
@@ -63,7 +63,7 @@
             raise TypeError("concat: inappropriate argument type: %s" \
                             % type(arg))
         if not w:
-            raise TypeError, "concat: arg to concat should have length"
+            raise TypeError, "concat: arg  %d to concat should have
length" % arg
         width += w
         val = val*(2**w) + v

diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_extractHierarchy.py
--- a/myhdl/_extractHierarchy.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/_extractHierarchy.py	Tue Dec 15 18:24:52 2009 +0100
@@ -41,7 +41,7 @@
 class _error:
     pass
 _error.NoInstances = "No instances found"
-_error.InconsistentHierarchy = "Inconsistent hierarchy - are all
instances returned?"
+_error.InconsistentHierarchy = "Inconsistent hierarchy inside %s -
are all instances returned ?"


 class _Instance(object):
@@ -170,11 +170,11 @@
         names[id(obj)] = name
         absnames[id(obj)] = name
         if not top_inst.level == 1:
-                raise ExtractHierarchyError(_error.InconsistentHierarchy)
+            raise ExtractHierarchyError(_error.InconsistentHierarchy % name)
         for inst in hierarchy:
             obj, subs = inst.obj, inst.subs
             if id(obj) not in names:
-                raise ExtractHierarchyError(_error.InconsistentHierarchy)
+                raise
ExtractHierarchyError(_error.InconsistentHierarchy % inst.name)
             inst.name = names[id(obj)]
             tn = absnames[id(obj)]
             for sn, so in subs:
diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_intbv.py
--- a/myhdl/_intbv.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/_intbv.py	Tue Dec 15 18:24:52 2009 +0100
@@ -154,7 +154,11 @@
                 self._val &= ~(1L << i)
             self._checkBounds()
         elif isinstance(key, slice):
+            if val == None:
+                raise ValueError, "cannot attribute None to a slice"
             i, j = key.start, key.stop
+            if (self._val == None) and (i != None) and (j != None):
+                raise ValueError, "cannot slice value None"
             if j is None: # default
                 if i is None and self._val is None:
                     self._val = val
diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/_traceSignals.py
--- a/myhdl/_traceSignals.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/_traceSignals.py	Tue Dec 15 18:24:52 2009 +0100
@@ -140,6 +140,8 @@
                 print >> f, "$upscope $end"
         print >> f, "$scope module %s $end" % name
         for n, s in sigdict.items():
+            if s._val == None:
+                raise ValueError("%s of module %s has no initial
value" % (n, name))
             if not s._tracing:
                 s._tracing = 1
                 s._code = namegen.next()
diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/test/core/test_always_comb.py
--- a/myhdl/test/core/test_always_comb.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/test/core/test_always_comb.py	Tue Dec 15 18:24:52 2009 +0100
@@ -136,7 +136,7 @@
         try:
             g = always_comb(h).gen
         except AlwaysCombError, e:
-            self.assertEqual(e.kind, _error.SignalAsInout)
+            self.assertEqual(e.kind, _error.SignalAsInout % "c")
         else:
             self.fail()

@@ -148,7 +148,7 @@
         try:
             g = always_comb(h).gen
         except AlwaysCombError, e:
-            self.assertEqual(e.kind, _error.SignalAsInout)
+            self.assertEqual(e.kind, _error.SignalAsInout % "c")
         else:
             self.fail()

diff -r 1342b9d95452 -r 4a33c0707e22 myhdl/test/core/test_traceSignals.py
--- a/myhdl/test/core/test_traceSignals.py	Tue Dec 15 18:45:10 2009 +0100
+++ b/myhdl/test/core/test_traceSignals.py	Tue Dec 15 18:24:52 2009 +0100
@@ -122,7 +122,7 @@
         try:
             dut = traceSignals(dummy)
         except ExtractHierarchyError, e:
-            self.assertEqual(e.kind, _error.InconsistentHierarchy)
+            self.assertEqual(e.kind, _error.InconsistentHierarchy % "dummy")
         else:
             self.fail()

Re: [myhdl-list] Max Recursion Depth on Signal Copy ERROR

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

On Tue, Dec 15, 2009 at 10:29 AM, Jan Decaluwe <ja...@ja...> wrote:

> Christopher L. Felton wrote:
> > The following will cause an error.
> >
> >  >>> from myhdl import *
> >  >>> from copy import copy
> >  >>> x = Signal(False)
> >  >>> y = copy(x)
> > Exception RuntimeError: 'maximum recursion depth exceeded while calling
> > a Python object' in <type 'exceptions.AttributeError'> ignored
> >
> >
> > Not sure why??
>
> Me neither :-)
>
> The Signal object is becoming a rather complex thing with
> (mutually) recursive dependencies on other objects, so I'm
> not really surprized however.
>

Yes, agree it is a complicated object.  So far been working pretty good,
only issues I have hit is this one and the issue that there is no Signal
type now (isinstance(x, Signal)).


> I hope you have other means to accomplish what you want?
>

I can probably think of some work around for now.  But a couple
observations.

   1. Tried adding a test hasattr(self._val, attr) before descending down to
   the object the Signal holds.  I think this makes sense to check before
   calling the _val object.  But this had the mechanical error self._val was
   checked before it existed.  I guess in the constructor when new "attributes"
   are created the __getattr__ is called by default and getattr must have some
   error handling or something?  But I only just learned about getattr and
   setattr, I might not be understanding what I am observing.
   2. I like the idea of getattr because it allows the Signal to be somewhat
   transparent.  Can still interact with the object that it holds.  Why no
   setattr?
   3. Adding a simply print to __getattr__ it appears this function is
   called frequently.  Don't know if this desired?

Some Background on what I have been working on.
MyHDL Fixed Point Object
Ran across this error for the fixed point object.  When I had a signal of
the fixed point (fxint) object couple issues occurred.  When an operation
executed on the signals (a+b) called the fxint __add__ and this is where the
copy was.  I should be able to remove the copy here (the work around).  The
getattr and setattr are very useful in this scenario.  Because in the
elaboration phase the fixed point sizing/alignment can be handled.
z.Q = a + b
# where z, a and b are type Signal(fxint(0)) and fxint has intbv as a base
class

DSP System Simulation / HDL Simulation
The other non-common use.  What I put together a DSP system simulation that
utilized the Signal object.  The dspsys allows me to define a DSP system
(testbench and analysis) kinda like simulink but it can also interface with
the HDL simulator.  In this case I needed the the Signal object to carry a
numpy array (sometimes large).  Had to override some of the functions, cause
I didn't want to copy the arrays on each "next" but simply to swap current
val and next.

Sorry for the previous duplicate posts, my spam filter decided to
get aggressive and I wasn't receiving the posts.

.chris

Re: [myhdl-list] fxintbv dependency on dspsim

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

Hi,
I havent yet looked into Christopher's new version of the lib, but I  
in general I think a perfect solution would be the possibility to  
write user-defined datatypes that do auto-promotion and all kinds of  
stuff, and give them some kind of "synthesis rules", that define a  
mapping to some lower level bit_vector (maybe intbv). Then Signal is a  
little more light-weight. With such a solution one could even write  
synthesizeable floating point types or synthesizeable records.
Jan

Am 15.12.2009 um 17:46 schrieb Jan Decaluwe:

> I'm not a fixed-point specialist, but am I correct in thinking that
> things would be considerably simpler if there would a fixed point
> datatype that we could map to in VHDL/Verilog?
>
> I seem to have read that such a (synthesizable) datatype exists for
> VHDL, but not yet for Verilog. But even it's VHDL-only, it seems like
> an interesting path to investigate?
>
> Felton Christopher wrote:
>> Jan L.,
>>
>> After our conversation I was thinking about this a little more.   
>> Think I
>> came up with a better scheme.  This still uses the elaboration  
>> phase to
>> determine the size/alignment/type but I think it is more clear.  This
>> way you can use an arbitrarily complex expression.  But the  
>> expression
>> will have to be outside the generators (behavioral statement) so that
>> the elaborate phase can determine the correct type/size.  And also in
>> the generator for conversion/simulation.
>>
>> Example:
>> def fx_mix_ex(a,b,c,d,e):
>>
>>    e.Q = (b-a)*c + d
>>    @always_comb
>>    def rtl():
>>        e.next = (b-a)*c + d
>>
>>    return rtl
>>
>> But I have hit some issues with the base myhdl.Signal component (more
>> than likely my mis-understanding and an issue in my stuff).  I will  
>> try
>> to resolve these and let you know how it goes.  Attached is an  
>> updated
>> version with the "Q" property.  Also the "Q" property removes all the
>> *Rep methods.
>>
>> Thanks again for the previous patches.
>>
>> On Dec 10, 2009, at 9:52 AM, Christopher L. Felton wrote:
>>
>>> Jan Langer wrote:
>>>> Hello Christopher,
>>>>
>>>> Am 10.12.2009 um 03:57 schrieb Christopher L. Felton:
>>>>> Jan Langer wrote:
>>>>>> Somehow, I dont really understand it. The return type of the
>>>>>> fxintbv operators is just plain intbv, so I cannot write a - b*c
>>>>>> for three fxintbv variables. If fxintbv does not take care of the
>>>>>> point in operations and I need to remember and adjust it by  
>>>>>> hand, I
>>>>>> dont see the advantages of fxintbv. fxint seems to do what I  
>>>>>> need,
>>>>>> except the two questions I wrote yesterday. I am a little  
>>>>>> confused
>>>>>> but maybe I just want the wrong things :-)
>>>>>>
>>>>> Correct, with the fxintbv a little more work needs to be done.   
>>>>> But
>>>>> not as much as doing it all manually.  Keeping within the design
>>>>> goals of MyHDL nothing will try to evaluate the expression x= a- 
>>>>> b*c
>>>>> and adjust the result.  But given the design of MyHDL and the
>>>>> elaborate phase there are some options.  The fxintbv doesn't do  
>>>>> the
>>>>> auto promotion (adjusting the number of bits for the word) but  
>>>>> there
>>>>> are helper functions to determine the size of the word based on  
>>>>> the
>>>>> operations.
>>>>> These helper functions/methods help during design and analysis but
>>>>> also can make the modules modular.  If an input size is adjusted  
>>>>> the
>>>>> module will automatically adjust.   The example in the  PDF  
>>>>> (ooppps,
>>>>> just notice didn't include everything in the PDF, my bad) or the
>>>>> example in examples/sos/sos_hdl.py there is a function that gets  
>>>>> the
>>>>> types needed.  The function uses the fxintbv methods to determine
>>>>> this.  This essentially auto-promotes.
>>>>>
>>>>> def getFxTypes(Q,N):
>>>>> # Different fixed-point types (sizes) used
>>>>> fx_t    = fxintbv(0, min=-1, max=1, res=2**-Q)
>>>>> fxmul_t = fx_t.ProductRep(fx_t)
>>>>> fxsum_t = fxmul_t.SummationRep(N)
>>>>>
>>>>> return fx_t, fxmul_t, fxsum_t
>>>>>
>>>>> Right now there are a bunch of public functions to assist in
>>>>> auto-promotion and alignment.  The ProductRep, AdditionRep,
>>>>> SummationRep will determine the correct "type" given the inputs.
>>>>>  For the specific example x = a-b*c something like the following
>>>>> could be done
>>>>>
>>>>> def fxCalc(clk, x, a, b, c):
>>>>>   i_t  = fxintbv.ProductRep(b,c)
>>>>> x_t  = fxintbv.AdditionRep(a, i_t)
>>>>> x.NewRep(x_t.iwl, x_t.fwl)
>>>>>
>>>>> @always(clk.posedge)
>>>>> def rtl_result():
>>>>>     x.next = a-b*c
>>>>>
>>>>> return instances()
>>>>>
>>>>> In this scenario all the promotion and alignment etc will be
>>>>> handled.  "x" will be adjusted in the elaboration phase based on  
>>>>> the
>>>>> a,b,c inputs.  It assumes that x, a, b, c are all of type fxintbv.
>>>>> The benefit of doing this is you will get the auto promotion of  
>>>>> "x"
>>>>> when the inputs change and you get some additional functions for
>>>>> fixed point analysis.  I think this is a good balance between  
>>>>> design
>>>>> flexibility and automation.  The fxint does a lot more under the
>>>>> hood (auto promotion, bit alignment) but it is not convertible.  I
>>>>> don't think it makes sense for something like fxint to be
>>>>> convertible.  You want a little more control when mapping to
>>>>> hardware.  I think the fxintbv has the balance between right  
>>>>> amount
>>>>> of abstraction and design guidance.
>>>>
>>>> Okay, I understand how its done. I will try it later. But I can't
>>>> follow your argumentation that something like fxint should not be
>>>> convertible. In my opinion, there is no semantic difference between
>>>> the above code, which explicitly promotes the type, and implicit
>>>> auto-promotion. The manual promotion will be used as a pattern  
>>>> and I
>>>> dont see any additional control of the mapping process. I mean if
>>>> there is a fixed and documented definition like
>>>>
>>>> a.b + c.d -> (max(a,c)+1).max(b,d)
>>>> a.b * c.d -> (a+c).(b+d)
>>>>
>>>> a mapping is easy to understand.
>>>>
>>>> I see that current myhdl might not be able to support a convertible
>>>> auto-promotable fxint type, but somehow I think that would be
>>>> desirable. :-)
>>>> Jan
>>>>
>>> It would require changes to the base MyHDL to evaluate the  
>>> expressions
>>> and generate the code.  I think this would be a fairly large  
>>> project.
>>> MyHDL, for the most part, isn't that active in the conversion.   
>>> There
>>> is a one to one mapping of expressions to the converted code.
>>> Arbitrarily complex expressions would have to handled.  Things like
>>> having a "summation" embedded in a expression changes the rules that
>>> you might want to apply.  The expression has to be decomposed such
>>> that it would be an optimal synthesis of the expression.  Example If
>>> you a take an expression like
>>> (a + b + c) * d
>>> You can apply the basic rules but if a,b and c are the same type  
>>> (same
>>> number bits and point alignment) more bits will be assigned to the
>>> result than needed.  In general the addition result will require
>>> another bit but a summation (multiple additions same type) only
>>> requires log2(N) bits, where N is the number of additions.  This  
>>> is a
>>> general rule as well but it requires more advanced parsing of the
>>> expressions which would have to be built into MyHDL.   Not saying it
>>> cannot be done, just would take more effort than I would currently
>>> have time for.
>>>
>>> At this point I don't think it is something that should be built  
>>> into
>>> the MyHDL language.  The fxint and fxintbv are simple
>>> libraries/objects that can be used with MyHDL.  What might be  
>>> possible
>>> in the future (time is the limiting resource) is that MyHDL can be
>>> modified slightly so that "plugins" can be added.  When an  
>>> expression
>>> is evaluate and unknown (non-convertible) types are present it can
>>> search for a plugin with rules to guide the conversion.  This way  
>>> the
>>> base language doesn't explode with all kinds features but something
>>> like you suggestion can be added.  Some serious thought would have  
>>> to
>>> be given to such an endeavor.  It is more complicated that single
>>> expressions, could apply to blocks of expressions (like loops).  And
>>> it would be changing the types on the fly, might require a two-pass
>>> approach.  It would be a nice feature and a fun project but  
>>> currently
>>> not feasible.
>

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

Re: [myhdl-list] fxintbv dependency on dspsim

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

I'm not a fixed-point specialist, but am I correct in thinking that
things would be considerably simpler if there would a fixed point
datatype that we could map to in VHDL/Verilog?

I seem to have read that such a (synthesizable) datatype exists for
VHDL, but not yet for Verilog. But even it's VHDL-only, it seems like
an interesting path to investigate?

Jan

Felton Christopher wrote:
> Jan L.,
> 
> After our conversation I was thinking about this a little more.  Think I 
> came up with a better scheme.  This still uses the elaboration phase to 
> determine the size/alignment/type but I think it is more clear.  This 
> way you can use an arbitrarily complex expression.  But the expression 
> will have to be outside the generators (behavioral statement) so that 
> the elaborate phase can determine the correct type/size.  And also in 
> the generator for conversion/simulation.
> 
> Example:
> def fx_mix_ex(a,b,c,d,e):
> 
>     e.Q = (b-a)*c + d
>     @always_comb
>     def rtl():
>         e.next = (b-a)*c + d
> 
>     return rtl
> 
> But I have hit some issues with the base myhdl.Signal component (more 
> than likely my mis-understanding and an issue in my stuff).  I will try 
> to resolve these and let you know how it goes.  Attached is an updated 
> version with the "Q" property.  Also the "Q" property removes all the 
> *Rep methods.
> 
> Thanks again for the previous patches.
> .chris
> 
> 
> ------------------------------------------------------------------------
> 
> 
> On Dec 10, 2009, at 9:52 AM, Christopher L. Felton wrote:
> 
>> Jan Langer wrote:
>>> Hello Christopher,
>>>
>>> Am 10.12.2009 um 03:57 schrieb Christopher L. Felton:
>>>> Jan Langer wrote:
>>>>> Somehow, I dont really understand it. The return type of the 
>>>>> fxintbv operators is just plain intbv, so I cannot write a - b*c 
>>>>> for three fxintbv variables. If fxintbv does not take care of the 
>>>>> point in operations and I need to remember and adjust it by hand, I 
>>>>> dont see the advantages of fxintbv. fxint seems to do what I need, 
>>>>> except the two questions I wrote yesterday. I am a little confused 
>>>>> but maybe I just want the wrong things :-)
>>>>>
>>>> Correct, with the fxintbv a little more work needs to be done.  But 
>>>> not as much as doing it all manually.  Keeping within the design 
>>>> goals of MyHDL nothing will try to evaluate the expression x= a-b*c 
>>>> and adjust the result.  But given the design of MyHDL and the 
>>>> elaborate phase there are some options.  The fxintbv doesn't do the 
>>>> auto promotion (adjusting the number of bits for the word) but there 
>>>> are helper functions to determine the size of the word based on the 
>>>> operations.
>>>> These helper functions/methods help during design and analysis but 
>>>> also can make the modules modular.  If an input size is adjusted the 
>>>> module will automatically adjust.   The example in the  PDF (ooppps, 
>>>> just notice didn't include everything in the PDF, my bad) or the 
>>>> example in examples/sos/sos_hdl.py there is a function that gets the 
>>>> types needed.  The function uses the fxintbv methods to determine 
>>>> this.  This essentially auto-promotes.
>>>>
>>>> def getFxTypes(Q,N):
>>>>  # Different fixed-point types (sizes) used
>>>>  fx_t    = fxintbv(0, min=-1, max=1, res=2**-Q)
>>>>  fxmul_t = fx_t.ProductRep(fx_t)
>>>>  fxsum_t = fxmul_t.SummationRep(N)
>>>>
>>>>  return fx_t, fxmul_t, fxsum_t
>>>>
>>>> Right now there are a bunch of public functions to assist in 
>>>> auto-promotion and alignment.  The ProductRep, AdditionRep, 
>>>> SummationRep will determine the correct "type" given the inputs. 
>>>>   For the specific example x = a-b*c something like the following 
>>>> could be done
>>>>
>>>> def fxCalc(clk, x, a, b, c):
>>>>    i_t  = fxintbv.ProductRep(b,c)
>>>>  x_t  = fxintbv.AdditionRep(a, i_t)
>>>>  x.NewRep(x_t.iwl, x_t.fwl)
>>>>
>>>>  @always(clk.posedge)
>>>>  def rtl_result():
>>>>      x.next = a-b*c
>>>>
>>>> return instances()
>>>>
>>>> In this scenario all the promotion and alignment etc will be 
>>>> handled.  "x" will be adjusted in the elaboration phase based on the 
>>>> a,b,c inputs.  It assumes that x, a, b, c are all of type fxintbv. 
>>>>  The benefit of doing this is you will get the auto promotion of "x" 
>>>> when the inputs change and you get some additional functions for 
>>>> fixed point analysis.  I think this is a good balance between design 
>>>> flexibility and automation.  The fxint does a lot more under the 
>>>> hood (auto promotion, bit alignment) but it is not convertible.  I 
>>>> don't think it makes sense for something like fxint to be 
>>>> convertible.  You want a little more control when mapping to 
>>>> hardware.  I think the fxintbv has the balance between right amount 
>>>> of abstraction and design guidance.
>>>
>>> Okay, I understand how its done. I will try it later. But I can't 
>>> follow your argumentation that something like fxint should not be 
>>> convertible. In my opinion, there is no semantic difference between 
>>> the above code, which explicitly promotes the type, and implicit 
>>> auto-promotion. The manual promotion will be used as a pattern and I 
>>> dont see any additional control of the mapping process. I mean if 
>>> there is a fixed and documented definition like
>>>
>>> a.b + c.d -> (max(a,c)+1).max(b,d)
>>> a.b * c.d -> (a+c).(b+d)
>>>
>>> a mapping is easy to understand.
>>>
>>> I see that current myhdl might not be able to support a convertible 
>>> auto-promotable fxint type, but somehow I think that would be 
>>> desirable. :-)
>>> Jan
>>>
>> It would require changes to the base MyHDL to evaluate the expressions 
>> and generate the code.  I think this would be a fairly large project. 
>>  MyHDL, for the most part, isn't that active in the conversion.  There 
>> is a one to one mapping of expressions to the converted code.
>> Arbitrarily complex expressions would have to handled.  Things like 
>> having a "summation" embedded in a expression changes the rules that 
>> you might want to apply.  The expression has to be decomposed such 
>> that it would be an optimal synthesis of the expression.  Example If 
>> you a take an expression like
>> (a + b + c) * d
>> You can apply the basic rules but if a,b and c are the same type (same 
>> number bits and point alignment) more bits will be assigned to the 
>> result than needed.  In general the addition result will require 
>> another bit but a summation (multiple additions same type) only 
>> requires log2(N) bits, where N is the number of additions.  This is a 
>> general rule as well but it requires more advanced parsing of the 
>> expressions which would have to be built into MyHDL.   Not saying it 
>> cannot be done, just would take more effort than I would currently 
>> have time for.
>>
>> At this point I don't think it is something that should be built into 
>> the MyHDL language.  The fxint and fxintbv are simple 
>> libraries/objects that can be used with MyHDL.  What might be possible 
>> in the future (time is the limiting resource) is that MyHDL can be 
>> modified slightly so that "plugins" can be added.  When an expression 
>> is evaluate and unknown (non-convertible) types are present it can 
>> search for a plugin with rules to guide the conversion.  This way the 
>> base language doesn't explode with all kinds features but something 
>> like you suggestion can be added.  Some serious thought would have to 
>> be given to such an endeavor.  It is more complicated that single 
>> expressions, could apply to blocks of expressions (like loops).  And 
>> it would be changing the types on the fly, might require a two-pass 
>> approach.  It would be a nice feature and a fun project but currently 
>> not feasible.
>>
>> .chris
>>
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-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] Max Recursion Depth on Signal Copy ERROR

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

Christopher L. Felton wrote:
> The following will cause an error.
> 
>  >>> from myhdl import *
>  >>> from copy import copy
>  >>> x = Signal(False)
>  >>> y = copy(x)
> Exception RuntimeError: 'maximum recursion depth exceeded while calling 
> a Python object' in <type 'exceptions.AttributeError'> ignored
> 
> 
> Not sure why??

Me neither :-)

The Signal object is becoming a rather complex thing with
(mutually) recursive dependencies on other objects, so I'm
not really surprized however.

I hope you have other means to accomplish what you want?


-- 
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] Adding Error Messages to MyHDL source

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

Christopher L. Felton wrote:
> Is there any general method for adding error messages?  In the MyHDL 
> base there seems to be a couple different methods used?  Assertions, 
> Exceptions, prints, etc.
> 
> I have added messages over time to my local copy.  Some of the messages 
> might be useful to the users as well.  Maybe we could add a section on 
> the wiki (maybe under open tasks) that outlines the best approach for 
> adding error, warning, and informative messages.

I often struggle with this and I have no golden rules.

Some observations:

I often use "naked" print statements for debugging. However, these
should never make it to a production release, if they do it's a bug.

assert statements and AssertionError exceptions are safety nets or
temporary placeholders. They mark something that either should never
happen (but I'm not sure), or something for which no unit test has
been written to check it. When they escape to a user, it should be
considered a bug to be fixed.

For warnings I sometimes try to use the warn module, but it's not
that user-friendly to use.

For errors I use exceptions, potentially accompanied by hopefully
informative error messages. (Sometimes I use the message string to
distinguish between idential exceptions in unit tests, e.g.
in the conversion stuff).

If applicable, I use prefined Python exceptions.
Otherwise, I define an exception per module or feature that
inherits from myhdl.Error. I'm reasonably satisfied with this
exception strategy. 

Jan

Re: [myhdl-list] Adding Error Messages to MyHDL source

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

Is there any general method for adding error messages?  In the MyHDL 
base there seems to be a couple different methods used?  Assertions, 
Exceptions, prints, etc.
>
> I have added messages over time to my local copy.  Some of the 
> messages might be useful to the users as well.  Maybe we could add a 
> section on the wiki (maybe under open tasks) that outlines the best 
> approach for adding error, warning, and informative messages.
>
> Thanks
> .chris

Re: [myhdl-list] fxintbv dependency on dspsim

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

Jan L.,

After our conversation I was thinking about this a little more.  Think  
I came up with a better scheme.  This still uses the elaboration phase  
to determine the size/alignment/type but I think it is more clear.   
This way you can use an arbitrarily complex expression.  But the  
expression will have to be outside the generators (behavioral  
statement) so that the elaborate phase can determine the correct type/ 
size.  And also in the generator for conversion/simulation.

Example:
def fx_mix_ex(a,b,c,d,e):

     e.Q = (b-a)*c + d
     @always_comb
     def rtl():
         e.next = (b-a)*c + d

     return rtl

But I have hit some issues with the base myhdl.Signal component (more  
than likely my mis-understanding and an issue in my stuff).  I will  
try to resolve these and let you know how it goes.  Attached is an  
updated version with the "Q" property.  Also the "Q" property removes  
all the *Rep methods.

Thanks again for the previous patches.
.chris



On Dec 10, 2009, at 9:52 AM, Christopher L. Felton wrote:

> Jan Langer wrote:
>> Hello Christopher,
>>
>> Am 10.12.2009 um 03:57 schrieb Christopher L. Felton:
>>> Jan Langer wrote:
>>>> Somehow, I dont really understand it. The return type of the  
>>>> fxintbv operators is just plain intbv, so I cannot write a - b*c  
>>>> for three fxintbv variables. If fxintbv does not take care of the  
>>>> point in operations and I need to remember and adjust it by hand,  
>>>> I dont see the advantages of fxintbv. fxint seems to do what I  
>>>> need, except the two questions I wrote yesterday. I am a little  
>>>> confused but maybe I just want the wrong things :-)
>>>>
>>> Correct, with the fxintbv a little more work needs to be done.   
>>> But not as much as doing it all manually.  Keeping within the  
>>> design goals of MyHDL nothing will try to evaluate the expression  
>>> x= a-b*c and adjust the result.  But given the design of MyHDL and  
>>> the elaborate phase there are some options.  The fxintbv doesn't  
>>> do the auto promotion (adjusting the number of bits for the word)  
>>> but there are helper functions to determine the size of the word  
>>> based on the operations.
>>> These helper functions/methods help during design and analysis but  
>>> also can make the modules modular.  If an input size is adjusted  
>>> the module will automatically adjust.   The example in the  PDF  
>>> (ooppps, just notice didn't include everything in the PDF, my bad)  
>>> or the example in examples/sos/sos_hdl.py there is a function that  
>>> gets the types needed.  The function uses the fxintbv methods to  
>>> determine this.  This essentially auto-promotes.
>>>
>>> def getFxTypes(Q,N):
>>>  # Different fixed-point types (sizes) used
>>>  fx_t    = fxintbv(0, min=-1, max=1, res=2**-Q)
>>>  fxmul_t = fx_t.ProductRep(fx_t)
>>>  fxsum_t = fxmul_t.SummationRep(N)
>>>
>>>  return fx_t, fxmul_t, fxsum_t
>>>
>>> Right now there are a bunch of public functions to assist in auto- 
>>> promotion and alignment.  The ProductRep, AdditionRep,  
>>> SummationRep will determine the correct "type" given the inputs.    
>>> For the specific example x = a-b*c something like the following  
>>> could be done
>>>
>>> def fxCalc(clk, x, a, b, c):
>>>    i_t  = fxintbv.ProductRep(b,c)
>>>  x_t  = fxintbv.AdditionRep(a, i_t)
>>>  x.NewRep(x_t.iwl, x_t.fwl)
>>>
>>>  @always(clk.posedge)
>>>  def rtl_result():
>>>      x.next = a-b*c
>>>
>>> return instances()
>>>
>>> In this scenario all the promotion and alignment etc will be  
>>> handled.  "x" will be adjusted in the elaboration phase based on  
>>> the a,b,c inputs.  It assumes that x, a, b, c are all of type  
>>> fxintbv.  The benefit of doing this is you will get the auto  
>>> promotion of "x" when the inputs change and you get some  
>>> additional functions for fixed point analysis.  I think this is a  
>>> good balance between design flexibility and automation.  The fxint  
>>> does a lot more under the hood (auto promotion, bit alignment) but  
>>> it is not convertible.  I don't think it makes sense for something  
>>> like fxint to be convertible.  You want a little more control when  
>>> mapping to hardware.  I think the fxintbv has the balance between  
>>> right amount of abstraction and design guidance.
>>
>> Okay, I understand how its done. I will try it later. But I can't  
>> follow your argumentation that something like fxint should not be  
>> convertible. In my opinion, there is no semantic difference between  
>> the above code, which explicitly promotes the type, and implicit  
>> auto-promotion. The manual promotion will be used as a pattern and  
>> I dont see any additional control of the mapping process. I mean if  
>> there is a fixed and documented definition like
>>
>> a.b + c.d -> (max(a,c)+1).max(b,d)
>> a.b * c.d -> (a+c).(b+d)
>>
>> a mapping is easy to understand.
>>
>> I see that current myhdl might not be able to support a convertible  
>> auto-promotable fxint type, but somehow I think that would be  
>> desirable. :-)
>> Jan
>>
> It would require changes to the base MyHDL to evaluate the  
> expressions and generate the code.  I think this would be a fairly  
> large project.  MyHDL, for the most part, isn't that active in the  
> conversion.  There is a one to one mapping of expressions to the  
> converted code.
> Arbitrarily complex expressions would have to handled.  Things like  
> having a "summation" embedded in a expression changes the rules that  
> you might want to apply.  The expression has to be decomposed such  
> that it would be an optimal synthesis of the expression.  Example If  
> you a take an expression like
> (a + b + c) * d
> You can apply the basic rules but if a,b and c are the same type  
> (same number bits and point alignment) more bits will be assigned to  
> the result than needed.  In general the addition result will require  
> another bit but a summation (multiple additions same type) only  
> requires log2(N) bits, where N is the number of additions.  This is  
> a general rule as well but it requires more advanced parsing of the  
> expressions which would have to be built into MyHDL.   Not saying it  
> cannot be done, just would take more effort than I would currently  
> have time for.
>
> At this point I don't think it is something that should be built  
> into the MyHDL language.  The fxint and fxintbv are simple libraries/ 
> objects that can be used with MyHDL.  What might be possible in the  
> future (time is the limiting resource) is that MyHDL can be modified  
> slightly so that "plugins" can be added.  When an expression is  
> evaluate and unknown (non-convertible) types are present it can  
> search for a plugin with rules to guide the conversion.  This way  
> the base language doesn't explode with all kinds features but  
> something like you suggestion can be added.  Some serious thought  
> would have to be given to such an endeavor.  It is more complicated  
> that single expressions, could apply to blocks of expressions (like  
> loops).  And it would be changing the types on the fly, might  
> require a two-pass approach.  It would be a nice feature and a fun  
> project but currently not feasible.
>
> .chris
>