Re: [myhdl-list] Block return values (myhdl.BlockError)

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

It's not so much an implementation problem as an
expectations problem.

Previously, one could do

    return m, sig1, sig2

and make a "contract" with oneself that m should be a list
of instances.

The problem I have is that this kind of decision would now
become part of the @block specification, valid for all, instead
simply being a local decision.

For example, what if one uses:
  
    return m1, m2, sig1, sig2

should that fail? And on what ground? And if it doesn't
fail, should the decorator than modify the return values
into something like:

    return Block(m1, m2), sig1, sig2

changing the argument aspect completely?

And what about

    return sig1, sig2, m


Or

    return m, siglist

And so on.

Jan


On 01/05/16 16:57, Samuele Disegna wrote:
> Hi! I am not getting the problem completely so I will try to give a
> probably wrong solution, I would like to hear some feedback on it in
> order to rise a more practical discussion:
>
> Block connections are usually indicated as arguments of the block
> functions, can we stick to this phylosophy and pass an empty list for
> signals defined inside the block itself? (the block will fill the
> list)
>
> Hardware Instances are usually passed through the return statement as
> single object, lists or tuples (Is this the maintenance problem?) and
> we are not capable of return anything else with the current
> implementation without getting errors (Have I got it right?). Can we
> decide to use a list for hardware instances embedded as the first
> element of a tuple (or in a dictionary)? The other elements will
> contain all kinds of return objects.
>
> Jan, could you list your thoughts about the problems you are getting
> on the implementation side :)? I am definitely interested.
>
> Samuele
>
> On Sun, May 1, 2016 at 12:46 PM, Henry Gomersall <he...@ma...
> <mailto:he...@ma...>> wrote:
>
> On 01/05/16 11:40, Jan Decaluwe wrote:
>> Feedback is more than welcome.
>
> Another potential option is to make the Block class part of the user
> API, or perhaps an alternative Block factory, to allow these more
> esoteric use cases.
>
> So, the @block decorator is used in the simple/common case. If you
> want to do something more complicated, you can use the alternative
> tools to extract the block object. Exactly how this would be realised
> I'm not sure, but I'm sure there would be a neat way.
>
> It touches on my comments in issue #162, which is another
> manifestation of the limitations of the decorator implementation.
>
> Henry
>
> ------------------------------------------------------------------------------
>
>
Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple
> tiers of your business applications. It resolves application problems
> quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________ myhdl-list mailing
> list myh...@li...
> <mailto:myh...@li...>
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>
>
>
>
> ------------------------------------------------------------------------------
>
>
Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple
> tiers of your business applications. It resolves application problems
> quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>
>
>
> _______________________________________________ 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
   Urubu, a static website CMS: http://urubu.jandecaluwe.com