myhdl-list

[myhdl-list] syntax sugar?

[Haitao Z. <ha...@gm...>]

One thing I miss in the MyHDL idiom is the simple concurrent statement:
a <= expr 
or
assign a = expr

In myhdl one has to do
def assign_blk():
    while 1:
        yield signals in expr
        a.next = expr

or:
def assign_blk():
    def blk():
        a.next = expr
    return always_comb(blk)

AND one needs to keep track of all the generators:
assign_blk_list.append(assign_blk())

Now of course the regular HDL statement and the myhdl are semantically
equivalent, so you may call the regular concurrent assignment simple
syntax sugar. But it does hide the details from the user and it is a
very good abstraction that can be consistently understood. In a real
design when one does a fair amount of concurrent assignment the tedium
of using the myhdl syntax could quickly add up.

I understand since myhdl is embedded in pure python it has to use all
the defs to control the evaluation and the partial evaluation. One
possibility is to add syntax sugar like the following:
assign("a", "expr")

And then hide the details in the assign function. One can try to
dynamically generate the necessary code in the assign function and
call exec, however this does not work with the inspect function used
by toVerilog and always_comb. I am not up to the task of adding this
capability natively to the myhdl codebase.  Another way to get around
it may be to use code generation tools to transform the short hand.
However with the tools I looked up on the web (Cog, Cheetah etc) the
solution seems to be worse than the problem.

Another nice to have (syntax sugar) is to be able to simply say:
clocked(
<code block>
)

instead of
def clocked_blk():
    while 1:
        yield posedge(clk)
        <code block>

clocked_blk_list.append(clocked_blk())

Comes in handy for all synchronous designs, but does not make as much
difference as the cocurrent assignment. This one is no longer python
semantics unless we put all <code block> in a '''string''', but that
would mess up the code highlighting in my editor :(

Haitao

[myhdl-list] Re: syntax sugar?

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

Haitao Zhang wrote:
> One thing I miss in the MyHDL idiom is the simple concurrent statement:
> a <= expr 
> or
> assign a = expr
> 
> In myhdl one has to do
> def assign_blk():
>     while 1:
>         yield signals in expr
>         a.next = expr
> 
> or:
> def assign_blk():
>     def blk():
>         a.next = expr
>     return always_comb(blk)

Why the overhead of an additional embedde function blk()?
You can just do:

     def assign_blk():
         a.next = expr

and use always_comb() when creating the instance.

> 
> AND one needs to keep track of all the generators:
> assign_blk_list.append(assign_blk())

Are you aware of the MyHDL function instances()? It is supposed to
track down all instances for you so that you can simply say:

     return instances()

> Now of course the regular HDL statement and the myhdl are semantically
> equivalent, so you may call the regular concurrent assignment simple
> syntax sugar. But it does hide the details from the user and it is a
> very good abstraction that can be consistently understood. In a real
> design when one does a fair amount of concurrent assignment the tedium
> of using the myhdl syntax could quickly add up.

It is true that MyHDL is more verbose and more explicit. But I think
you are a little pessimistic. You could group all assigns in a single
function, and use always_comb() and instances(), like so:

     ...
     def assignments():
         a.next = b
         c.next = d
         ...
     assignments_inst = always_comb(assignments)
     ....
     return instances()

That´s not too bad, I think.

> I understand since myhdl is embedded in pure python it has to use all
> the defs to control the evaluation and the partial evaluation. One
> possibility is to add syntax sugar like the following:
> assign("a", "expr")

I don´t like this, as functionality is hidden in strings
outside the reassuring scope of the Python interpreter.
I want to rely on it as much as possible.

In general I also don´t like syntactic sugar. Python itself
shows that you don´t need it, and that explicit code doesn´t
necessarily mean verbose code.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: syntax sugar?

[Haitao Z. <ha...@gm...>]

On 8/1/05, Jan Decaluwe <ja...@ja...> wrote:
Jan,
I generally agree with your comments against "syntax sugar" so I won't
argue about it. Also thanks for pointing out a less verbose way to
keep track.

On the following point I want to point out a drawback:
when you group all assignments you are making all the assignments
sensitive to all signals on the RHS, and therefore whenever an event
happens every single assignment will be evaluated. That may or may not
be acceptable in terms of simulation efficiency, but it is not
equivalent to multiple concurrent assignment blocks. Or maybe I don't
understand what instances() and always_comb() do?

Haitao

> It is true that MyHDL is more verbose and more explicit. But I think
> you are a little pessimistic. You could group all assigns in a single
> function, and use always_comb() and instances(), like so:
>=20
>     ...
>     def assignments():
>         a.next =3D b
>         c.next =3D d
>         ...
>     assignments_inst =3D always_comb(assignments)
>     ....
>     return instances()
>=20
> That=B4s not too bad, I think.
>

Re: [myhdl-list] Re: syntax sugar?

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

(I think something went wrong with gmane yesterday, and the following
message from Haitao Zhang didn=B4t show up in gmane. So I repost
it -- Jan Decaluwe)

Haitao Zhang wrote:
> On 8/1/05, Jan Decaluwe <ja...@ja...> wrote:
> Jan,
> I generally agree with your comments against "syntax sugar" so I won't
> argue about it. Also thanks for pointing out a less verbose way to
> keep track.
>=20
> On the following point I want to point out a drawback:
> when you group all assignments you are making all the assignments
> sensitive to all signals on the RHS, and therefore whenever an event
> happens every single assignment will be evaluated. That may or may not
> be acceptable in terms of simulation efficiency, but it is not
> equivalent to multiple concurrent assignment blocks. Or maybe I don't
> understand what instances() and always_comb() do?
>=20
> Haitao
>=20
>=20
>>It is true that MyHDL is more verbose and more explicit. But I think
>>you are a little pessimistic. You could group all assigns in a single
>>function, and use always_comb() and instances(), like so:
>>
>>    ...
>>    def assignments():
>>        a.next =3D b
>>        c.next =3D d
>>        ...
>>    assignments_inst =3D always_comb(assignments)
>>    ....
>>    return instances()
>>
>>That=B4s not too bad, I think.
>>
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dclick
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>=20


--=20
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: syntax sugar?

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

Haitao Zhang wrote:
> On 8/1/05, Jan Decaluwe <ja...@ja...> wrote:
> Jan,
> I generally agree with your comments against "syntax sugar" so I won't
> argue about it. Also thanks for pointing out a less verbose way to
> keep track.
> 
> On the following point I want to point out a drawback:
> when you group all assignments you are making all the assignments
> sensitive to all signals on the RHS, and therefore whenever an event
> happens every single assignment will be evaluated. That may or may not
> be acceptable in terms of simulation efficiency, but it is not
> equivalent to multiple concurrent assignment blocks. Or maybe I don't
> understand what instances() and always_comb() do?

With the current implementation, you are correct. However, this could
be optimized. This is similar to the current discussion in another
thread about conversion to Verilog assign statements.

always_comb() inspects the function source code to infer a sensitivity
list. It returns a single generator. It could be enhanced to detect
the case in which the function only contains assignments (no control
logic or declarations). In that case it could infer a sensitivity
list and return a generator per individual assignment.

Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     Using Python as a hardware description language:
     http://jandecaluwe.com/Tools/MyHDL/Overview.html