Re: Block return values (myhdl.BlockError)
Jan Decaluwe <[email protected]> Sun, 1 May 2016 21:14:29 +0200
| Newsgroups | gmane.comp.python.myhdl |
|---|---|
| Organization | resources |
| Message-ID | <[email protected]> |
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 <[email protected]
> <mailto:[email protected]>> 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 [email protected]
> <mailto:[email protected]>
> 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 [email protected]
> 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
------------------------------------------------------------------------------
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