myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] Adding Error Message to MyHDL source

[Felton C. <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 some messages over time to my local copy.  Some of the  
messages might be useful to other 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


p.s. sorry if this is a duplicate post, first attempt didn't appear  
successful.

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

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

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

.chris

[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

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

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

Re: [myhdl-list] fxintbv dependency on dspsim

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

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

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

Re: [myhdl-list] fxintbv dependency on dspsim

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

Jan, some additional information below,

Jan Langer wrote:
> Hello Christopher,
>
> Am 09.12.2009 um 06:02 schrieb Christopher L. Felton:
>> I will try and reply later with more detail.  You want to use the 
>> *fxintbv* object and not the fxint.  Page 8 of the pdf , 
>> http://www.myhdl.org/lib/exe/fetch.php/users:cfelton:projects:myhdlfixedpoint.pdf  
>> is an example of convertible fixed-point for add.  Should be exactly 
>> the same for subtract (given no bugs).
>
> 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.

Hope that helps
.chris

In the fixed_point/fxlib/_hdl.py there are some examples.  These are 
intended to be
>
>
>
> Jan Langer wrote:
>> Hello Christopher,
>> I finally switched my design to fxint and in general it works fine. 
>> However, I have two questions.
>>
>> Why is for example the result of subtracting two fxint Signals an int?
>> To solve this issue I wrote a helper function:
>>
>>  def sigtofx(x):
>>     return fxint(x.fValue,Q=(x.iwl,x.fwl))
>>
>> to convert the signal to an fxint, which has the correct subtraction. 
>> This is of course not synthesizeable. :-(
>>
>> The other thing is assignment of fxint signals, which requires 
>> alignment of the points. I see that this is necessary, but it will 
>> require tricky slicing operations. I solve it in another helper 
>> function for now, but is is also not convertible:
>>
>> def fxassign(dst,src):
>>     dst.next = fxint(src.fValue,Q=(dst.iwl,dst.fwl))
>>
>> For example, converting Q=(5,6) to Q=(5,3) is
>>
>> Is there a preferred "myhdl"-solution for my problems?
>>
>> I found two things which might be bugs and I enclose the 
>> corresponding patch file.
>>
>>
>>
>> Thanks for implementing the library,
>> Jan
>>
>> Am 03.12.2009 um 17:09 schrieb Felton Christopher:
>>> Attached is my latest dspsys (dspsim) and fixed_point.  As I 
>>> mentioned dspsys is not mature, use at your own risk.
>>>
>>> On Dec 2, 2009, at 4:37 AM, Jan Langer wrote:
>>>> I encountered a problem using the fixed_point library on the myhdl
>>>> website. It tries to find a module called dspsim (fixed_point/fxlib/
>>>> _blocks.py, line 23), which is not found on my system. A google search
>>>> didn't turn up anything useful. What is it and where can I get it?
>>
>

Re: [myhdl-list] [PATCH] Remove redundant copy operators

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

Benoît wrote:

> Hi Jan,
> 
> Of course you are right, thinking about it, I guess the only thing  
> that could justify those statements above is my hardware mind. That  
> same nasty one that makes me think ahead of the cost (latch, wire,  
> clock cycles) of each line I'm writting. That's the way I learnt to  
> write VHDL. Only, this does not apply to MyHDL.

I think VHDL and MyHDL are much more similar than you suggest here.
You could perfectly write MyHDL with the "think hardware" mindset
you describe.

Personally, I just don't think that "think hardware" is the most
effective design strategy. I prefer "synthesis-aware" design where
you raise the abstraction level as much as possible without
jeopardizing efficiency. You still have to know about hardware,
but more importantly, you have to understand what a synthesis
tool can and cannot do. Many "hardware thinkers" don't fully
appreciate this. They fail to see elegant, efficient solutions,
just because they can't visualize them readily in hardware.

I have written lots of VHDL since 1990 and I have always used
the "synthesis-aware" strategy. So I really don't think it's
a matter of HDL language, but of mindset.

Of course, some design decision in MyHDL are inspired by my
personal preferences, e.g. the intbv class. But I don't think
that makes an essential difference here.

> This just lead to one question ? How to write MyHDL code ? Depending  
> on what you're looking for I guess.

I do it exactly like I did with VHDL: the highest possible abstraction
level, but synthesis-aware. In practice this means e.g.

- preference for the clocked process template as a default
- no separation between "control" and "data" logic
- preference for variables inside processes, including for register inference

However, my guess is that many MyHDL users don't do it like that,
and MyHDL works for them too.

Jan



-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] [PATCH] Remove redundant copy operators

[Benoît <ben...@gm...>]

On 20 nov 2009, at 18:15, Jan Decaluwe <ja...@ja...> wrote:

> Ben wrote:
>
>
>> But still, i have the impression that the original problem comes from
>> a bit deeper, namely that there is no real combinatorial behavior. I
>> guess you recognized the "<=" in VHDL or the "assign" in verilog. I
>> have the feeling that those ShadowSignal are to fill this gap where
>> asignement is about slicing. All the other one are still there. I
>> always find a bit silly to write a new @always_comb for each MUX for
>> instance. One can argue that it works ...
>
> Ok, let's discuss this in detail.
>
> Of course there is true combinatorial behavior in MyHDL. With
> explicit sensitivity lists, you can have it the way you want
> just like in Verilog or VHDL.
>
> I think you mean that there is no implicit combinatorial behavior
> like with Verilog assign and some concurrent VHDL constructs.
> It's true that there are no one-liners. However, I think @always_comb
> comes a long way and is a more general solution. A bit more explicit,
> but the sensivity list is also inferred implicitly for you.
> More about it further on.
>
> First I'll argue that the problem of signal slices really is
> different than the continuous assign problem. In Verilog and VHDL,
> when you slice a signal you get (in some contexts) signal behavior.
> You don't have to construct any other object explicitly, and you
> don't need assignments. ShadowSignals are intended to emulate that
> behavior for them most useful cases. Without them, the overhead
> to emulate this yourself explicitly is considerable.
>
> In comparison, emulating continuous assigns with @always_comb
> means not much more than some syntax overhead (2 lines). Of
> course 2 lines is a lot for just a mux. But why indeed would
> you write a separate @always_comb for each mux?
> If explicit muxes is what you want, why not use one-liner
> mux instances? Otherwise, why not put all combinational
> behavior in one single @always_comb?
>
> In MARS.py, you write:
>
>    @always_comb
>    def updatewe1():
>        if state == t_State.LOAD:
>            we1_i.next = we1_load
>        else:
>            we1_i.next = we1_proc
>
>    @always_comb
>    def updateIP1():
>        if state == t_State.LOAD:
>            IP1_i.next = IP1_load
>        else:
>            IP1_i.next = IP1_proc
>
> what I might write as (I like explicit defaults):
>
>    @always_comb
>    def update():
>        we1_i.next = we1_proc
>        IP1_i.next = IP1_proc
>        if state == t_State.LOAD:
>            we1_i.next = we1_load
>            P1_i.next = IP1_load
>
> I'm a bit surprized that you raise the issue, because on other
> places in your code you do it already exactly as I suggest.
> Also, it is clear that your main descriptive tool is the
> clocked "process", which is my preferred RTL style. In this
> style, combinatorial processes are the exception. I might
> e.g. put the output assignments in the example above right in
> the FSM code itself.

Hi Jan,

Of course you are right, thinking about it, I guess the only thing  
that could justify those statements above is my hardware mind. That  
same nasty one that makes me think ahead of the cost (latch, wire,  
clock cycles) of each line I'm writting. That's the way I learnt to  
write VHDL. Only, this does not apply to MyHDL.

This just lead to one question ? How to write MyHDL code ? Depending  
on what you're looking for I guess. 
    

Re: [myhdl-list] fxintbv dependency on dspsim

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

Jan L.

Sorry for any confusion, I had put the fixed_point MyHDL object in the
user and projects space to share with the MyHDL community and others.
I mistakenly had the one testbench  in the examples that used the
"dspsim".  The "dspsim" is another tool that I put together and it
currently isn't available (also renamed to dspsys).  My intention was
only to make the fxintbv available as the "dspsys" is not complete.

The fixed_point package (fxint and fxintbv) can be used with out the
"dspsys" package.  Certain portions of the examples will not be
operational because of the "dspsys" dependency.

I will gladly send you a copy of the latest dspsys but it is in a
primitive state with no documentation and probably lots of bugs.  I
will try and send you a copy later tonight (GMT-6).

Little background on "dspsys" (dspsim) package.  It is a fork of the
"dsptools" provided by
Chris Terman (http://web.mit.edu/6.02/www/s2009/dsptools/index.html).
The signal processing hardware that I was creating with MyHDL in most
cases had similar testbenches.  There would be some set of DSP blocks
that were used to drive the HDL and some set of blocks to capture and
analyze the results.  The dspsys allows a user to simply define a
signal processing system for the testbench and mix high level blocks
and HDL blocks.  It can be used for "golden" model comparisons.  I
converted the dsptools to use the MyHDL simulation engine so that it
can be used to simulate (or run real-time) DSP systems or uses for
mixed simulation with HDL.

.chris

On Wed, Dec 2, 2009 at 4:37 AM, Jan Langer
<jan...@et...> wrote:
> Hi,
> I encountered a problem using the fixed_point library on the myhdl
> website. It tries to find a module called dspsim (fixed_point/fxlib/
> _blocks.py, line 23), which is not found on my system. A google search
> didn't turn up anything useful. What is it and where can I get it?
> Best regards,
> Jan
>
> traceback:
>
> --
> Jan Langer
> (Telefon) +49-371-531-33158 / (PGP) F1B8C1CC
> Schaltkreis- und Systementwurf / TU Chemnitz
>
>
> ------------------------------------------------------------------------------
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] fxintbv dependency on dspsim

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

Hi,
I encountered a problem using the fixed_point library on the myhdl  
website. It tries to find a module called dspsim (fixed_point/fxlib/ 
_blocks.py, line 23), which is not found on my system. A google search  
didn't turn up anything useful. What is it and where can I get it?
Best regards,
Jan

traceback:

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

Re: [myhdl-list] [PATCH] Remove redundant copy operators

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

Ben wrote:

 
> But still, i have the impression that the original problem comes from
> a bit deeper, namely that there is no real combinatorial behavior. I
> guess you recognized the "<=" in VHDL or the "assign" in verilog. I
> have the feeling that those ShadowSignal are to fill this gap where
> asignement is about slicing. All the other one are still there. I
> always find a bit silly to write a new @always_comb for each MUX for
> instance. One can argue that it works ...

Ok, let's discuss this in detail.

Of course there is true combinatorial behavior in MyHDL. With
explicit sensitivity lists, you can have it the way you want
just like in Verilog or VHDL.

I think you mean that there is no implicit combinatorial behavior
like with Verilog assign and some concurrent VHDL constructs.
It's true that there are no one-liners. However, I think @always_comb
comes a long way and is a more general solution. A bit more explicit,
but the sensivity list is also inferred implicitly for you.
More about it further on.

First I'll argue that the problem of signal slices really is
different than the continuous assign problem. In Verilog and VHDL,
when you slice a signal you get (in some contexts) signal behavior.
You don't have to construct any other object explicitly, and you
don't need assignments. ShadowSignals are intended to emulate that
behavior for them most useful cases. Without them, the overhead
to emulate this yourself explicitly is considerable.

In comparison, emulating continuous assigns with @always_comb
means not much more than some syntax overhead (2 lines). Of
course 2 lines is a lot for just a mux. But why indeed would
you write a separate @always_comb for each mux?
If explicit muxes is what you want, why not use one-liner
mux instances? Otherwise, why not put all combinational
behavior in one single @always_comb?

In MARS.py, you write:

    @always_comb
    def updatewe1():
        if state == t_State.LOAD:
            we1_i.next = we1_load
        else:
            we1_i.next = we1_proc

    @always_comb
    def updateIP1():
        if state == t_State.LOAD:
            IP1_i.next = IP1_load
        else:
            IP1_i.next = IP1_proc

what I might write as (I like explicit defaults):

    @always_comb
    def update():
        we1_i.next = we1_proc
        IP1_i.next = IP1_proc
        if state == t_State.LOAD:
            we1_i.next = we1_load
            P1_i.next = IP1_load

I'm a bit surprized that you raise the issue, because on other
places in your code you do it already exactly as I suggest.
Also, it is clear that your main descriptive tool is the
clocked "process", which is my preferred RTL style. In this
style, combinatorial processes are the exception. I might
e.g. put the output assignments in the example above right in
the FSM code itself.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] Sagasi Testing for ImpulseC generated VHDL source code

[David B. <dav...@ya...>]

Yes, I will provide the results.  Which studies and which designs would you like to see to be implemented???
 
 
David
 
 
 


--- On Wed, 11/18/09, Christopher Felton <chr...@gm...> wrote:


From: Christopher Felton <chr...@gm...>
Subject: Re: [myhdl-list] Sagasi Testing for ImpulseC generated VHDL source code
To: "General discussions on MyHDL" <myh...@li...>
Date: Wednesday, November 18, 2009, 10:45 AM










I will be utilizing the Sigasi environment for the testing of VHDL source code that has been generated both both the ImpulseC and MyHDL software entities !!
 
Is anyone interested in my results ?? 


Yes, I think it would be interesting to see the results for a MyHDL versus ImpulseC implementation for a particular design.  I think most of the MyHDL community would find the results interesting.  Can you post them to this mail group?


.chris 
 





 
 
David Blubaugh
 
 
 
 
 


--- On Tue, 11/10/09, Christopher Felton <cf...@uc...> wrote:


From: Christopher Felton <cf...@uc...>
Subject: Re: [myhdl-list] [Announce] Jan on HDL Design
To: ja...@ja..., "General discussions on MyHDL" <myh...@li...>
Date: Tuesday, November 10, 2009, 7:33 PM


Thanks for the link, I am always interested in your thoughts and opinions.  This leads to an interesting question, which is your preference,  MyHDL design or VHDL with modern development tools (hope that doesn't put you on the spot)? 


Chris


On Tue, Nov 10, 2009 at 9:22 AM, Jan Decaluwe <ja...@ja...> wrote:

Hello:

Today I am announcing a series of blog posts about my
views on HDL Design, hosted on the Sigasi website.

If you are interested, here is the page:
 http://www.sigasi.com/JanHDL
and the RSS feed:
 http://www.sigasi.com/taxonomy/term/52/0/feed

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a HDL: http://www.myhdl.org
   VHDL development, the modern way: http://www.sigasi.com
   Analog design automation: http://www.mephisto-da.com
   World-class digital design: http://www.easics.com


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list


-----Inline Attachment Follows-----


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----Inline Attachment Follows-----


_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



-----Inline Attachment Follows-----


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----Inline Attachment Follows-----


_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      

Re: [myhdl-list] [PATCH] Remove redundant copy operators

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

Hi Jan,

My deep apologies for the delayed answer, I've been diverted by $paying_job.

On Wed, Nov 4, 2009 at 12:51, Jan Decaluwe <ja...@ja...> wrote:
> I'm not entirely sure I understand the issue, but here are some
> upfront remarks.
>
> Something like a VHDL alias in its full generality would probably
> require Python language support. What we can do is try to
> accomodate for some limited but interesting cases.
>
> One issue that I have addressed myself is the fact the MyHDL signal
> slices aren't signals. I consider this a major weakness, and I have
> come up with a proposal to address what I consider the most important
> issues:
>
>    http://www.myhdl.org/doku.php/meps:mep-105
>
> An implementation is present in the development trunk. I would be
> interested to hear whether this can be a solution for you. E.g:
>
> class ControlWord(object):
>        pass
>
> ctrlword = ControlWord()
>
> a = intbv(0)[32:]
>
> ctrlword.subpart = a(4, 2) # shadow signal, only for reading, note round brackets
>
> Then: with Python you can of course do what you want, very clever
> tricks. This is abvolutely fine for modeling.
> However, when you also want Verilog/VHDL convertibility, your
> options are very limited. E.g. something like the above wouldn't work
> because signals as attributes are not yet supported by the convertor.
> However, somethink like:
>
> subpart = a(4, 2)
>
> would be convertible, because the convertor explicitly supports
> dedicated conversion code for shadow signals.
>

At this point, I'm impressed you found exactly even better than me the
origin of my troubles: "slices of Signals aren't Signals". That's to
say that I've been reading with great eager your MEP. And that one
answers those questions about slicing quite well.

But still, i have the impression that the original problem comes from
a bit deeper, namely that there is no real combinatorial behavior. I
guess you recognized the "<=" in VHDL or the "assign" in verilog. I
have the feeling that those ShadowSignal are to fill this gap where
asignement is about slicing. All the other one are still there. I
always find a bit silly to write a new @always_comb for each MUX for
instance. One can argue that it works ...

One of my first error messages I got when I was trying MyHDL was
something like "A signal is used as inout in a always_comb". First
think I did was to improve the error message to identify the signal,
and then, split my always_comb (Note to self: think about submitting
this patch). MyHDL has its advantages, sure,but I guess after two
weeks playing around with it, I can spot its weaknesses.

It's a great tool for prototyping, and that's exactly what I did:
prototyping. And, last but not least, please correct me if I'm wrong,
but it's one of the only simulation solution on MacOSX. And that's
greatly appreciated !!!

> Finally: the copy methods. I agree that they are not as they should be
> as they are not compatible with subclassing now. However, there was a
> a reason to have dedicated copy methods instead of the generic ones:
> performance. The Signal class is using copy all the time, and it
> makes a difference. However, I have to think about it again, because
> now that I look at it it may be done much better for the intbv case.
>

I completely agree, I did some test with my patched version and with
you genuine one, the testsuite runs in 14 second without the patch and
19 with it. It's clearly a no-go, I will pop my patch and redefine the
copy operators in my subclass.

As a side note, I found the DelayedSignal **really** usefull when
debugging, I wondered why it wasn't the default, neither documented
that much. My patched version has a default delay of 1 ns. And that
**greatly** highlight what's going on ...

Finally, if  you're interrested to look at the project I was/am
experimenting with, it can be found there:
http://bitbucket.org/benallard/puredarwin
You can even add a link from the wiki, if you like, and if my coding
style complies with the listed-on-wiki acceptance level ;)

Best Regards,
Benoit

PS: About the wiki, I had the great pleasure to follow the lecture
from Jean Demartini (listed on the wiki), but I can't remember
anything about MyHDL in there ... I know he refactored his lecture
just the year I followed it. Maybe in the past, I can't say ...

Re: [myhdl-list] Sagasi Testing for ImpulseC generated VHDL source code

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

> I will be utilizing the Sigasi environment for the testing of VHDL source
> code that has been generated both both the ImpulseC and MyHDL software
> entities !!
>
> Is anyone interested in my results ??
>

Yes, I think it would be interesting to see the results for a MyHDL versus
ImpulseC implementation for a particular design.  I think most of the MyHDL
community would find the results interesting.  Can you post them to this
mail group?

.chris


>
>
> David Blubaugh
>
>
>
>
>
>
>
> --- On *Tue, 11/10/09, Christopher Felton <cf...@uc...>* wrote:
>
>
> From: Christopher Felton <cf...@uc...>
> Subject: Re: [myhdl-list] [Announce] Jan on HDL Design
> To: ja...@ja..., "General discussions on MyHDL" <
> myh...@li...>
> Date: Tuesday, November 10, 2009, 7:33 PM
>
> Thanks for the link, I am always interested in your thoughts and opinions.
>  This leads to an interesting question, which is your preference,  MyHDL
> design or VHDL with modern development tools (hope that doesn't put you on
> the spot)?
>
> Chris
>
> On Tue, Nov 10, 2009 at 9:22 AM, Jan Decaluwe <ja...@ja...<http://us.mc327.mail.yahoo.com/mc/compose?to=ja...@ja...>
> > wrote:
>
>> Hello:
>>
>> Today I am announcing a series of blog posts about my
>> views on HDL Design, hosted on the Sigasi website.
>>
>> If you are interested, here is the page:
>>  http://www.sigasi.com/JanHDL
>> and the RSS feed:
>>  http://www.sigasi.com/taxonomy/term/52/0/feed
>>
>> Jan
>>
>> --
>> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>>    Python as a HDL: http://www.myhdl.org
>>    VHDL development, the modern way: http://www.sigasi.com
>>    Analog design automation: http://www.mephisto-da.com
>>    World-class digital design: http://www.easics.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...<http://us.mc327.mail.yahoo.com/mc/compose?to=myh...@li...>
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>
> -----Inline Attachment Follows-----
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> myhdl-list mailing list
> myh...@li...<http://us.mc327.mail.yahoo.com/mc/compose?to=myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>

Re: [myhdl-list] [Announce] Jan on HDL Design

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

On Wed, Nov 11, 2009 at 8:08 AM, Jan Decaluwe <ja...@ja...> wrote:

> Christopher Felton wrote:
> > Thanks for the link, I am always interested in your thoughts and
> > opinions.  This leads to an interesting question, which is your
> > preference,  MyHDL design or VHDL with modern development tools (hope
> > that doesn't put you on the spot)?
>
> Without constraints I would obviously choose MyHDL as the first option,
> if only to get the bugs out of my own stuff :-)
>
> However, note that even then I will likely need VHDL in the process:
> as the result from MyHDL, to integrate with 3rd party stuff, to
> synthesize from. From now on, I would always use Sigasi HDT to
> support that work. Note also that I could use refactoring e.g. to
> create hierarchy out of a flat design from the MyHDL convertor.
>
> MyHDL and VHDL should not be viewed as opponents. MyHDL's main
> inspiration is obviously VHDL. MyHDL can be viewed as VHDL's
> "scripting companion". I have a lot to thank to VHDL, but I've
> written so much of it already that it's also a simple matter
> of not getting bored! It's true however that Sigasi HDT makes
> it much more fun again. It avoids most of the boring stuff.
>
> I don't think my own situation is that relevant however. I believe
> that MyHDL (or at least its concepts) has a good future in the
> longer term, but there's also the short and medium term to take
> care of. There you have all kind of constraints, personal
> preferences, company policies etc. Realistically people in
> different situations need different solutions, and for me
> it's not a contradiction to work on various fronts of progress.
>
> Jan
>
> --
>

Thanks for the reply, btw I agree totally.  Based
on constraints, circumstances, ideologies, etc can/will drive the
technology.  One thing I did find interesting was the idea of refactoring
the generated VHDL.  That appears breaks the philosophy previously held, the
output is more of an intermediate form not required to be tampered with.
 The idea of not modifying the generated HDL in itself doesn't prevent
integration with legacy VHDL/Verilog.  So, is it more as a debug / analysis
tool?  The refactoring would have to be complete on each new generation of
the hdl, correct?

Thanks again,
.Chris

Re: [myhdl-list] [Announce] Jan on HDL Design

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

Christopher Felton wrote:
> Thanks for the link, I am always interested in your thoughts and 
> opinions.  This leads to an interesting question, which is your 
> preference,  MyHDL design or VHDL with modern development tools (hope 
> that doesn't put you on the spot)?

Without constraints I would obviously choose MyHDL as the first option,
if only to get the bugs out of my own stuff :-)

However, note that even then I will likely need VHDL in the process:
as the result from MyHDL, to integrate with 3rd party stuff, to
synthesize from. From now on, I would always use Sigasi HDT to
support that work. Note also that I could use refactoring e.g. to
create hierarchy out of a flat design from the MyHDL convertor.

MyHDL and VHDL should not be viewed as opponents. MyHDL's main
inspiration is obviously VHDL. MyHDL can be viewed as VHDL's
"scripting companion". I have a lot to thank to VHDL, but I've
written so much of it already that it's also a simple matter
of not getting bored! It's true however that Sigasi HDT makes
it much more fun again. It avoids most of the boring stuff.

I don't think my own situation is that relevant however. I believe
that MyHDL (or at least its concepts) has a good future in the
longer term, but there's also the short and medium term to take
care of. There you have all kind of constraints, personal
preferences, company policies etc. Realistically people in
different situations need different solutions, and for me
it's not a contradiction to work on various fronts of progress.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

[myhdl-list] Sagasi Testing for ImpulseC generated VHDL source code

[David B. <dav...@ya...>]

To All,
 
 
I will be utilizing the Sigasi environment for the testing of VHDL source code that has been generated both both the ImpulseC and MyHDL software entities !!
 
Is anyone interested in my results ?? 
 
 
David Blubaugh
 
 
 
 
 


--- On Tue, 11/10/09, Christopher Felton <cf...@uc...> wrote:


From: Christopher Felton <cf...@uc...>
Subject: Re: [myhdl-list] [Announce] Jan on HDL Design
To: ja...@ja..., "General discussions on MyHDL" <myh...@li...>
Date: Tuesday, November 10, 2009, 7:33 PM


Thanks for the link, I am always interested in your thoughts and opinions.  This leads to an interesting question, which is your preference,  MyHDL design or VHDL with modern development tools (hope that doesn't put you on the spot)?


Chris


On Tue, Nov 10, 2009 at 9:22 AM, Jan Decaluwe <ja...@ja...> wrote:

Hello:

Today I am announcing a series of blog posts about my
views on HDL Design, hosted on the Sigasi website.

If you are interested, here is the page:
 http://www.sigasi.com/JanHDL
and the RSS feed:
 http://www.sigasi.com/taxonomy/term/52/0/feed

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a HDL: http://www.myhdl.org
   VHDL development, the modern way: http://www.sigasi.com
   Analog design automation: http://www.mephisto-da.com
   World-class digital design: http://www.easics.com


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list


-----Inline Attachment Follows-----


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-----Inline Attachment Follows-----


_______________________________________________
myhdl-list mailing list
myh...@li...
https://lists.sourceforge.net/lists/listinfo/myhdl-list



      

Re: [myhdl-list] [Announce] Jan on HDL Design

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

Thanks for the link, I am always interested in your thoughts and opinions.
 This leads to an interesting question, which is your preference,  MyHDL
design or VHDL with modern development tools (hope that doesn't put you on
the spot)?

Chris

On Tue, Nov 10, 2009 at 9:22 AM, Jan Decaluwe <ja...@ja...> wrote:

> Hello:
>
> Today I am announcing a series of blog posts about my
> views on HDL Design, hosted on the Sigasi website.
>
> If you are interested, here is the page:
>  http://www.sigasi.com/JanHDL
> and the RSS feed:
>  http://www.sigasi.com/taxonomy/term/52/0/feed
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
>    Python as a HDL: http://www.myhdl.org
>    VHDL development, the modern way: http://www.sigasi.com
>    Analog design automation: http://www.mephisto-da.com
>    World-class digital design: http://www.easics.com
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

[myhdl-list] [Announce] Jan on HDL Design

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

Hello:

Today I am announcing a series of blog posts about my
views on HDL Design, hosted on the Sigasi website.

If you are interested, here is the page:
  http://www.sigasi.com/JanHDL
and the RSS feed:
  http://www.sigasi.com/taxonomy/term/52/0/feed

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com

Re: [myhdl-list] [PATCH] Remove redundant copy operators

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

I'm not entirely sure I understand the issue, but here are some
upfront remarks.

Something like a VHDL alias in its full generality would probably
require Python language support. What we can do is try to
accomodate for some limited but interesting cases.

One issue that I have addressed myself is the fact the MyHDL signal
slices aren't signals. I consider this a major weakness, and I have
come up with a proposal to address what I consider the most important
issues:

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

An implementation is present in the development trunk. I would be
interested to hear whether this can be a solution for you. E.g:

class ControlWord(object):
	pass

ctrlword = ControlWord()

a = intbv(0)[32:]

ctrlword.subpart = a(4, 2) # shadow signal, only for reading, note round brackets

Then: with Python you can of course do what you want, very clever
tricks. This is abvolutely fine for modeling. 
However, when you also want Verilog/VHDL convertibility, your
options are very limited. E.g. something like the above wouldn't work
because signals as attributes are not yet supported by the convertor.
However, somethink like:

subpart = a(4, 2)

would be convertible, because the convertor explicitly supports
dedicated conversion code for shadow signals.

Finally: the copy methods. I agree that they are not as they should be
as they are not compatible with subclassing now. However, there was a
a reason to have dedicated copy methods instead of the generic ones:
performance. The Signal class is using copy all the time, and it
makes a difference. However, I have to think about it again, because
now that I look at it it may be done much better for the intbv case.

Jan


Ben wrote:
> Hi there,
> 
> First of all, hello to everyone, and thanks for this great initiative
> which is MyHDL, till now, I enjoyed using it.
> 
> I ran into trouble though when I was looking for VHDL 'alias' ... I
> was trying to make my code more readable when dealing with
> ControlWords.
> 
> The first solution I found is to make a always_comb process, but
> still, we have to use a .next, so we don't have strictly the 'alias'
> behavior. This solution is sort of driven by my "think hardware" mind,
> or should I say, education.
> 
> The second solution I found, and there, MyHDL shows its supremacy, is
> to use Python as a tool, and not define my ControlWord as intbv, but
> to define my own class, say ctrlword that inherit from intbv, redefine
> "__getattr__", such that "ctrlword.subpart3" return the right slice
> from my intbv. THis also has the advantage that I keep complete
> compatibility (think conversion) with the intbv type. Clever isnt't it
> ? The only problem I got is that the intbv __copy__ function was
> forcing the return value as being an intbv, thus, removing all the
> information from my ctrlword.
> 
> As both __copy__ and __deepcopy__ are behaving the same as the Python
> default one, I was able to remove them, without influencing the
> testsuite result. (By the way on my MacOSX, I have some test failing
> with regard to set and Set)
> 
> Here is a patch that does what I described here.
> 
> Best Regards
> Benoit
> 
> # HG changeset patch
> # User Benoit Allard <ben...@gm...>
> # Date 1257160071 -3600
> # Node ID bd6b60949b4e68023e41f49ce853c0058e02019b
> # Parent  2ff17ece613127b174cb7a6a9aa8ba765ffcbd01
> Remove useless copy operators
> 
> The default one are making the same, and even beter.
> Those one were preventing us to subclass the intbv class, as the copy were
> forcing the return type to intbv, removing information about our subclass.
> 
> diff -r 2ff17ece6131 -r bd6b60949b4e myhdl/_intbv.py
> --- a/myhdl/_intbv.py	Tue Oct 06 07:02:37 2009 -0500
> +++ b/myhdl/_intbv.py	Mon Nov 02 12:07:51 2009 +0100
> @@ -90,12 +90,6 @@
>      def __hash__(self):
>          raise TypeError("intbv objects are unhashable")
> 
> -    # copy methods
> -    def __copy__(self):
> -        return intbv(self)
> -    def __deepcopy__(self, visit):
> -        return intbv(self)
> -
>      # iterator method
>      def __iter__(self):
>          if not self._nrbits:
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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] [PATCH] Remove redundant copy operators

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

On Tue, Nov 3, 2009 at 10:47 AM, Ben <ben...@gm...> wrote:

> Hi Christopher,
>
> On Tue, Nov 3, 2009 at 17:24, Christopher Felton <chr...@gm...>
> wrote:
> >>
> >> The first solution I found is to make a always_comb process, but
> >> still, we have to use a .next, so we don't have strictly the 'alias'
> >> behavior. This solution is sort of driven by my "think hardware" mind,
> >> or should I say, education.
> >>
> >> The second solution I found, and there, MyHDL shows its supremacy, is
> >> to use Python as a tool, and not define my ControlWord as intbv, but
> >> to define my own class, say ctrlword that inherit from intbv, redefine
> >> "__getattr__", such that "ctrlword.subpart3" return the right slice
> >> from my intbv. THis also has the advantage that I keep complete
> >> compatibility (think conversion) with the intbv type. Clever isnt't it
> >> ? The only problem I got is that the intbv __copy__ function was
> >> forcing the return value as being an intbv, thus, removing all the
> >> information from my ctrlword.
> >
> > It might be better to override the methods/functions in your ctlrword
> class
> > than removing them from the intbv object?  I did something similar with
> the
> > fixed-point
> > object, http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv,
> which
> > is convertible, as well.
>
> Actually, for completeness, this second solution still need a .next as
> a slice still is an intbv and isn't a Signal, giving it as parameter
> to a module kills it Signal nature. I still need to look at what can
> be done at the Signal level for that.
>
>
Ok, I am slowing catching on to what you are trying to achieve.  In this
case you might also have to cinherit the Signal class and override the
update method in the Signal class.  Currently the Signal class has "next"
handlers for the different types.  If the type passes isn't support an
exception will occur.  Since it is a derived class of intbv it will use the
default intbv "next handler"

Maybe this could be extended so that "type handlers" can be registered
without creating a new derived Signal class.  I have done this before with
numpy arrays but created a new class that inherits Signal and overloaded the
update (_setUpdateType).  Others might have better suggestions or comments
as well.

> Think this is/has been a sticky issue in the Python community in general.
> >  Seems like there are strong opinions one way or the other.  In general
> an
> > inheriting class needs to override all the base class methods to return
> the
> > new type.
>
> I would understand if the original function needs to do something,
> actually , looking to the history of the code (thanks mercurial), this
> function has been created returning a copy of "self._val", where it
> would have made sense to define it, and later corrected to return a
> copy of "self", where it doesn't make sense any more to define it as
> the vanilla __copy__ from Python does the same, but taking care of
> types.
>
> A "good" copy should looks like:
> def __copy__(self):
>    return self.__class__(self)
>
> There, we wouldn't have had troubles.
>
> > I believe you are asserting that the general copy returns the type of the
> > object being copied and there is no need to override the copy methods?
>
> That's right ! Even if it sound redundant, a copy of an object returns
> a /copy/ of the same object : same value, same type.
>

That is a good point!  As you originally suggested the copy functions are no
longer required.

.chris

Re: [myhdl-list] [PATCH] Remove redundant copy operators

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

Hi Christopher,

On Tue, Nov 3, 2009 at 17:24, Christopher Felton <chr...@gm...> wrote:
>>
>> The first solution I found is to make a always_comb process, but
>> still, we have to use a .next, so we don't have strictly the 'alias'
>> behavior. This solution is sort of driven by my "think hardware" mind,
>> or should I say, education.
>>
>> The second solution I found, and there, MyHDL shows its supremacy, is
>> to use Python as a tool, and not define my ControlWord as intbv, but
>> to define my own class, say ctrlword that inherit from intbv, redefine
>> "__getattr__", such that "ctrlword.subpart3" return the right slice
>> from my intbv. THis also has the advantage that I keep complete
>> compatibility (think conversion) with the intbv type. Clever isnt't it
>> ? The only problem I got is that the intbv __copy__ function was
>> forcing the return value as being an intbv, thus, removing all the
>> information from my ctrlword.
>
> It might be better to override the methods/functions in your ctlrword class
> than removing them from the intbv object?  I did something similar with the
> fixed-point
> object, http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv, which
> is convertible, as well.

Actually, for completeness, this second solution still need a .next as
a slice still is an intbv and isn't a Signal, giving it as parameter
to a module kills it Signal nature. I still need to look at what can
be done at the Signal level for that.

> Think this is/has been a sticky issue in the Python community in general.
>  Seems like there are strong opinions one way or the other.  In general an
> inheriting class needs to override all the base class methods to return the
> new type.

I would understand if the original function needs to do something,
actually , looking to the history of the code (thanks mercurial), this
function has been created returning a copy of "self._val", where it
would have made sense to define it, and later corrected to return a
copy of "self", where it doesn't make sense any more to define it as
the vanilla __copy__ from Python does the same, but taking care of
types.

A "good" copy should looks like:
def __copy__(self):
    return self.__class__(self)

There, we wouldn't have had troubles.

> I believe you are asserting that the general copy returns the type of the
> object being copied and there is no need to override the copy methods?

That's right ! Even if it sound redundant, a copy of an object returns
a /copy/ of the same object : same value, same type.

Regards,
Benoit

Re: [myhdl-list] [PATCH] Remove redundant copy operators

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

>
>
> The first solution I found is to make a always_comb process, but
> still, we have to use a .next, so we don't have strictly the 'alias'
> behavior. This solution is sort of driven by my "think hardware" mind,
> or should I say, education.
>
> The second solution I found, and there, MyHDL shows its supremacy, is
> to use Python as a tool, and not define my ControlWord as intbv, but
> to define my own class, say ctrlword that inherit from intbv, redefine
> "__getattr__", such that "ctrlword.subpart3" return the right slice
> from my intbv. THis also has the advantage that I keep complete
> compatibility (think conversion) with the intbv type. Clever isnt't it
> ? The only problem I got is that the intbv __copy__ function was
> forcing the return value as being an intbv, thus, removing all the
> information from my ctrlword.
>

It might be better to override the methods/functions in your ctlrword class
than removing them from the intbv object?  I did something similar with the
fixed-point object,
http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv, which is
convertible, as well.

Think this is/has been a sticky issue in the Python community in general.
 Seems like there are strong opinions one way or the other.  In general an
inheriting class needs to override all the base class methods to return the
new type.

I believe you are asserting that the general copy returns the type of the
object being copied and there is no need to override the copy methods?

.chris

[myhdl-list] [PATCH] Remove redundant copy operators

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

Hi there,

First of all, hello to everyone, and thanks for this great initiative
which is MyHDL, till now, I enjoyed using it.

I ran into trouble though when I was looking for VHDL 'alias' ... I
was trying to make my code more readable when dealing with
ControlWords.

The first solution I found is to make a always_comb process, but
still, we have to use a .next, so we don't have strictly the 'alias'
behavior. This solution is sort of driven by my "think hardware" mind,
or should I say, education.

The second solution I found, and there, MyHDL shows its supremacy, is
to use Python as a tool, and not define my ControlWord as intbv, but
to define my own class, say ctrlword that inherit from intbv, redefine
"__getattr__", such that "ctrlword.subpart3" return the right slice
from my intbv. THis also has the advantage that I keep complete
compatibility (think conversion) with the intbv type. Clever isnt't it
? The only problem I got is that the intbv __copy__ function was
forcing the return value as being an intbv, thus, removing all the
information from my ctrlword.

As both __copy__ and __deepcopy__ are behaving the same as the Python
default one, I was able to remove them, without influencing the
testsuite result. (By the way on my MacOSX, I have some test failing
with regard to set and Set)

Here is a patch that does what I described here.

Best Regards
Benoit

# HG changeset patch
# User Benoit Allard <ben...@gm...>
# Date 1257160071 -3600
# Node ID bd6b60949b4e68023e41f49ce853c0058e02019b
# Parent  2ff17ece613127b174cb7a6a9aa8ba765ffcbd01
Remove useless copy operators

The default one are making the same, and even beter.
Those one were preventing us to subclass the intbv class, as the copy were
forcing the return type to intbv, removing information about our subclass.

diff -r 2ff17ece6131 -r bd6b60949b4e myhdl/_intbv.py
--- a/myhdl/_intbv.py	Tue Oct 06 07:02:37 2009 -0500
+++ b/myhdl/_intbv.py	Mon Nov 02 12:07:51 2009 +0100
@@ -90,12 +90,6 @@
     def __hash__(self):
         raise TypeError("intbv objects are unhashable")

-    # copy methods
-    def __copy__(self):
-        return intbv(self)
-    def __deepcopy__(self, visit):
-        return intbv(self)
-
     # iterator method
     def __iter__(self):
         if not self._nrbits:

Re: [myhdl-list] Interesting

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

Thanks for the reference, very interesting.

It's interesting to see how Synopsys confirms that a higher
level coding style can also lead to a better QoR. Those who
"think hardware" all the time should take notice.

Even more interesting is how the author points out that
some of the Verilog languages choices are problematic, and
VHDL low level types have their problems too. Exactly
my point. I can't stress it enough: MyHDL's intbv simply
makes these problems go away!

Finally, the MyHDL converter generates Verilog and VHDL
code which is as far as I can see fully in line with
the recommended coding style in the paper. Therefore,
using MyHDL has a unique advantage: the highest possible
coding style, not available in Verilog and VHDL, and the
best QoR.

Spread the word!

Jan



Christopher Felton wrote:
> Synopsys released a white paper on "coding guidelines for datapath 
> synthesis <http://techonline.com/learning/techpaper/193102987>".  The 
> paper is about using signed attribute for VHDL and Verilog.  States that 
> the QoR is better when signed is used versus handling signed manually (I 
> quickly perused the article might be more assertions).  
> 
> This indirectly supports what Jan has already mentioned and discussed 
> here and in the "These Ints are made for Counting" 
> <http://www.jandecaluwe.com/hdldesign/counting.html> essay. 
> 
> Thought I would share with the MyHDL community.
> 
> .chris
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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