Re: Block return values (myhdl.BlockError)

I have considered this issue for some time now
and I have basically decided to leave the constraints
as they are, that is, blocks should only return
block and instantiator objects. So I plan to reject
the requested feature. My rationale follows,
for the record.

The purpose of @block is to make MyHDL usage more
robust (checks and error reporting) and simplify
the code drastically (e.g. by removing the dubious
use of the profiler).

I did not find a good way to keep these advantages
while relaxing the constraints on the type of the
return values.

Here is why I believe the feature to return other
object types will not be missed that much.

First, it is "advanced" usage. People coming
from other HDLs will not think about it initially.
Instead, they will find it intuitive to use the
argument list for the interface, similar to
other HDLs.

Moreover, if we would have had @block early
on, I don't think anyone would have missed the
feature. After all, the intuitive workaround is
simply to use the argument list.

It is true that the feature would permit
parametrization of output ports inside
a block. However, I don't think it is bad
style to enforce to do this externally. After
all, the ports in question are external
signals.

Finally, the requested feature goes in the
opposite direction of other requests, that
is, to find a way to remove the "redundant"
return statement. (We may consider to
support a nonexisting return statement as an
indication to assemble blocks and instantiators
automatically.)

Jan

On 29/03/16 15:54, Jos Huisken wrote:
> Hi,
>
> Sometimes I'm using a block like this:
>
> def tb():
>      m, clk, rst = clkrst()
>      return m, clk, rst
>
> In which 'm' is the list of instantiator objects, and 'clk'/'rst' are
> Signals.
> So this way you can specify a block in general:
>
> def unit(inputports):
>      ...
>      return m, outputports
>
> Note that this could be a preferred way of design. It just happened that I
> created few such examples.
>
> With the new block decorator this is not allowed anymore, raising a
> myhdl.BlockError.
>
> I can imagine that also other return values may be wanted by users.
> Is this something which can be taken into account?
> Or: should 'block's really be constrained in returning just block or
> instantiator objects?
>
> Thanks,
> Jos
>
>
> ------------------------------------------------------------------------------
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
>


-- 
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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com


------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j