myhdl-list

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

[Jos H. <jos...@gm...>]

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

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

[Christopher F. <chr...@gm...>]

On 3/29/16 8:54 AM, 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

I have, in the past, attempted to use returns other
than the myhdl.generators but I haven't been too
successful.  I can see the utility because often
the ports are a function of the inputs.  I do not
know if it will be possible with the new implementation.

It isn't the most DRY but you could attach a function
to the ~~module~~ block:

     outputs = myblock.get_outputs(**inputs)
     inst = myblock(**inputs, **outputs)

>
> 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.

If this is not supported with MEP114, we might want
to add alternative suggestions to the MEP/documentation
for users that have used returns which include more
than generators.

Regards,
Chris

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

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

I have been thinking about this for about
a month now, without a good resolution,
and it is holding development back.

We need to resolve this urgently though,
because if we go forward with @block a
release has to made before GSoC. (May 23).

It is a style I didn't think about before,
but of course it is something you can do
with dynamic Python...

My thoughts:

In this style, the return values become
part of the block interface. If we want to
support this with @block, we need to
permit different (perhaps all) types
of return values, and reorder them
using the decorator.

This seems to become complicated, and
also defies the purpose of @block somewhat
(stricter type checking).

So: if we don't support this, are we
really going to miss something in the
future? The workaround is of course
to use only the argument list for
the block interface, and to do type-dependent
processing of ports outside the @block.

Also, an intermediate workaround may
be to pass an "interface object" as
an argument, and populate it with
Signal objects locally within the @block.

Feedback is more than welcome.

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

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

[Henry G. <he...@ma...>]

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

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

[Samuele D. <sm...@gm...>]

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...> 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...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

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

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

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

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

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

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

[Henry G. <he...@ma...>]

On 10/05/16 10:32, Jan Decaluwe wrote:
> 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.

I think your reasoning is sound.

Do you object to alternative strategies for constructing Block
operators? This could leave @block as the default usual case, with more
esoteric cases handled by direct access to the construction of the Block
object. This could allow the best of both worlds - simple default and
arbitrary control if desired.

Henry

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

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

On 10/05/16 11:45, Henry Gomersall wrote:
> On 10/05/16 10:32, Jan Decaluwe wrote:
>> 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.
>
> I think your reasoning is sound.
>
> Do you object to alternative strategies for constructing Block
> operators? This could leave @block as the default usual case, with more
> esoteric cases handled by direct access to the construction of the Block
> object. This could allow the best of both worlds - simple default and
> arbitrary control if desired.

I have nothing against collecting good ideas.

However, for this specific feature, I am unconvinced
that the additional complexity is warranted. I may
change that opinion with future evidence - until
now it has only been brought up once as an alternative
possibility and does not seem enough.

My priority is moving forward with the simplifications
enabled by @block, and I believe there are several
much more relevant new features that these simplifications
will make possible.

Jan

-- 
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

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

[Henry G. <he...@ma...>]

On 10/05/16 10:45, Henry Gomersall wrote:
> On 10/05/16 10:32, Jan Decaluwe wrote:
>> > 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.
> I think your reasoning is sound.
> 
> Do you object to alternative strategies for constructing Block
> operators? This could leave @block as the default usual case, with more
> esoteric cases handled by direct access to the construction of the Block
> object. This could allow the best of both worlds - simple default and
> arbitrary control if desired.

Actually, a neat solution could be to allow optional decorator arguments
taking the class constructor and allow subclassing of _Block.

e.g.

class MyBlock(_Block):

    @property
    def some_exposed_property(self):
        return 20

@block(block_class=MyBlock)
def foo():
    ...

In the case of handling alternative default args, it's simply a case
then of an alternative Block. Something like (untested so may be wrong)...

(it actually doesn't matter whether it is right or easy, it provides an
opportunity to add later).

class ExtractExtraArgsBlock(_Block):
    @property
    def extra_args(self):
        return extra_args

    def __init__(self, func, deco, srcfile, srcline, *args, **kwargs):
        self.extra_args = []
        def wrapper_func(*args, **kwargs):
            inst, output_stuff = func(*args, **kwargs)
            self.extra_args.append(output_stuff)
            return inst

        wrapper_srcfile = inspect.getsourcefile(wrapper_func)
        wrapper_srcline = inspect.getsourcelines(wrapper_func)[0]

        super(self, _Block).__init__(
            wrapper_func, deco, wrapper_srcfile,
            wrapper_srcline, *args, **kwargs)

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

[Henry G. <he...@ma...>]

On 10/05/16 11:02, Henry Gomersall wrote:
> super(self, _Block).__init__(
>             wrapper_func, deco, wrapper_srcfile,
>             wrapper_srcline, *args, **kwargs)

Of course, that should be

super(ExtractExtraArgsBlock, self).__init__(...)

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

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

On 10/05/16 12:02, Henry Gomersall wrote:
> On 10/05/16 10:45, Henry Gomersall wrote:
>> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>> 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.
>> I think your reasoning is sound.
>>
>> Do you object to alternative strategies for constructing Block
>> operators? This could leave @block as the default usual case, with more
>> esoteric cases handled by direct access to the construction of the Block
>> object. This could allow the best of both worlds - simple default and
>> arbitrary control if desired.
>
> Actually, a neat solution could be to allow optional decorator arguments
> taking the class constructor and allow subclassing of _Block.
>

Independent of this feature, decorator arguments may be
useful, but as you know a decorator without arguments
behaves completely differently from a decorator with
arguments.

Until now, the only way I saw to handle both cases
with a single decorator was with some ad-hoc check
that I didn't find very elegant.

Jan

-- 
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

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

[Henry G. <he...@ma...>]

On 10/05/16 12:30, Jan Decaluwe wrote:
> On 10/05/16 12:02, Henry Gomersall wrote:
>> > On 10/05/16 10:45, Henry Gomersall wrote:
>>> >> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>>> >>>> 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.
>>> >> I think your reasoning is sound.
>>> >>
>>> >> Do you object to alternative strategies for constructing Block
>>> >> operators? This could leave @block as the default usual case, with more
>>> >> esoteric cases handled by direct access to the construction of the Block
>>> >> object. This could allow the best of both worlds - simple default and
>>> >> arbitrary control if desired.
>> >
>> > Actually, a neat solution could be to allow optional decorator arguments
>> > taking the class constructor and allow subclassing of _Block.
>> >
> Independent of this feature, decorator arguments may be
> useful, but as you know a decorator without arguments
> behaves completely differently from a decorator with
> arguments.
> 
> Until now, the only way I saw to handle both cases
> with a single decorator was with some ad-hoc check
> that I didn't find very elegant.

Yeah this is an issue. There's a somewhat neat way using keyword args
exclusively, but it does require keyword args (which is not overly
restrictive since this would be an "advanced" feature).

In this case it might work reasonably neatly in the simpler case though
since we can check it's either a callable or a _Block, and reject
anything else.

Henry

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

[Henry G. <he...@ma...>]

On 10/05/16 13:09, Henry Gomersall wrote:
> On 10/05/16 12:30, Jan Decaluwe wrote:
>> > On 10/05/16 12:02, Henry Gomersall wrote:
>>>> >> > On 10/05/16 10:45, Henry Gomersall wrote:
>>>>>> >>> >> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>>>>>>>> >>>>> >>>> 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.
>>>>>> >>> >> I think your reasoning is sound.
>>>>>> >>> >>
>>>>>> >>> >> Do you object to alternative strategies for constructing Block
>>>>>> >>> >> operators? This could leave @block as the default usual case, with more
>>>>>> >>> >> esoteric cases handled by direct access to the construction of the Block
>>>>>> >>> >> object. This could allow the best of both worlds - simple default and
>>>>>> >>> >> arbitrary control if desired.
>>>> >> >
>>>> >> > Actually, a neat solution could be to allow optional decorator arguments
>>>> >> > taking the class constructor and allow subclassing of _Block.
>>>> >> >
>> > Independent of this feature, decorator arguments may be
>> > useful, but as you know a decorator without arguments
>> > behaves completely differently from a decorator with
>> > arguments.
>> > 
>> > Until now, the only way I saw to handle both cases
>> > with a single decorator was with some ad-hoc check
>> > that I didn't find very elegant.
> Yeah this is an issue. There's a somewhat neat way using keyword args
> exclusively, but it does require keyword args (which is not overly
> restrictive since this would be an "advanced" feature).
> 
> In this case it might work reasonably neatly in the simpler case though
> since we can check it's either a callable or a _Block, and reject
> anything else.

To be clear, what is seen by a naive user need not changed.

Both @block and @block(MyCustomBlock) can be made to work.

Speaking of that, another solution is to have something like an
@custom_block() decorator which _must_ take an argument.

Henry

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

[Jos H. <jos...@gm...>]

Jan Decaluwe <jan <at> jandecaluwe.com> writes:

> I have nothing against collecting good ideas.
> 
> However, for this specific feature, I am unconvinced
> that the additional complexity is warranted. I may
> change that opinion with future evidence - until
> now it has only been brought up once as an alternative
> possibility and does not seem enough.

I didn't expect to raise such discussion ;-), and I guess we have to give 
it more thought. I have used all kinds of return values, next to Signals, 
especially in testbenches. The example I showed was a small part of a 
template based testbench+design which I will revisit, hopefully soon,  
with the current simplification.

> My priority is moving forward with the simplifications
> enabled by  <at> block, and I believe there are several
> much more relevant new features that these simplifications
> will make possible.
> 
> Jan
> 

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

[Henry G. <he...@ma...>]

On 13/05/16 15:45, Jos Huisken wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
> 
>> > I have nothing against collecting good ideas.
>> > 
>> > However, for this specific feature, I am unconvinced
>> > that the additional complexity is warranted. I may
>> > change that opinion with future evidence - until
>> > now it has only been brought up once as an alternative
>> > possibility and does not seem enough.
> I didn't expect to raise such discussion ;-), and I guess we have to give 
> it more thought. I have used all kinds of return values, next to Signals, 
> especially in testbenches. The example I showed was a small part of a 
> template based testbench+design which I will revisit, hopefully soon,  
> with the current simplification.
> 

Do you have any of this code to share?

I've made an attempt with Veriutils
(https://github.com/hgomersall/Veriutils) to solve the problem of HDL
tests needing lots of boilerplate (think random vectors, clock
generators, reset initialisation) and integrating that with a framework
for a poor man's cosimulation (when the tools don't allow "proper"
cosimulation e.g. Vivado), by recording MyHDL signals and playing them
back inside the testbench.

I'm interested to know about alternative tools to make the process of
verification simpler and more robust.

Cheers,

Henry

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

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

On 13/05/16 16:45, Jos Huisken wrote:
> Jan Decaluwe <jan <at> jandecaluwe.com> writes:
>
>> I have nothing against collecting good ideas.
>>
>> However, for this specific feature, I am unconvinced
>> that the additional complexity is warranted. I may
>> change that opinion with future evidence - until
>> now it has only been brought up once as an alternative
>> possibility and does not seem enough.
>
> I didn't expect to raise such discussion ;-), and I guess we have to give
> it more thought. I have used all kinds of return values, next to Signals,
> especially in testbenches. The example I showed was a small part of a
> template based testbench+design which I will revisit, hopefully soon,
> with the current simplification.

For the record: the problem is limited to the return
values of blocks themselves. You will need to use
blocks for certain applications, but you are not
forced to use them for all modeling applications.

You can still use blocks within non-blocks and then
do whatever you want in terms of return values or
other sophisticated techniques.

The current Simulation API will remain available
to simulate such cases, in test benches or for
high-level modeling.

Blocks are merely intended to make hiearchy extraction
easier and much more robust, as needed for the important
sub-applications of conversion and signal tracing.

Jan


-- 
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