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