[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