Re: [myhdl-list] Reset functionality "synthesis"

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

<snip>
>
> However, I think we can do better. Recall that always_comb
> already inferres a sensitivity list. What if we introduced
> a new decorator, always_ff, that would infer the reset
> structure? The advantages would be:
>
> * reset functionality automatically correct by construction
> * no need to write code dedicated to reset functionality
>
> The latter feature is important because reset code tends
> to take up a lot of lines for non-functional reasons.
> Also, we would save a level of indentation.
>
> For example, suppose we have a wrap-around incrementer
> as follows:
>
>       ...
>       count = Signal(modbv(0)[8:])
>       ...
>       def Inc(count, enable, clock, reset):
>
>           @always(clock.posedge, reset.negedge)
>           def incLogic():
>               if reset == 0:
>                   count.next = 0
>               else:
>                   if enable:
>                       count.next = count + 1
>
>           return incLogic
>
> With an always_ff decorator, we could rewrite it as follows:
>
>       def Inc(count, enable, clock, reset):
>
>           @always_ff(clock.posedge, reset=reset)
>           def incLogic():
>               if enable:
>                   count.next = count + 1
>
>           return incLogic
>
> and it would do exactly the same as the original.


I really like this idea.  I think it can be very useful.
If I understand correctly, the initial value of the Signal
is used for the /reset/ value?  If the above was change to

     ...
     count = Signal(modbv(17)[8:])
     ...

Then the inferred reset logic would be

         ...
         if reset == 0:
             count.next = 17
         ...

Correct?

>
> Currently, I think always_ff would have an argument
> list as follows:
>
>       always_ff(edge, reset=False, level=0, async=True)
>
> The False default for the reset parameter would allow
> to force the presence of a reset signal. (A block
> without reset would require reset=None explicitly).
> The reset level and style can also be specified, with
> defaults that correspond to the most common case in
> my opinion.
>
> Feedback welcome!
>

Haven't thought this fully through but would it be better
to have the /reset/ properties passes as arguments to the
decorator or properties of the Signal?  Example if properties
used:

     reset = Signal(False)
     reset.level = 0
     reset.async = True

     @always_ff(clock.posedge, reset=reset)

The property defaults would be the same as you stated.

I guess the benefit of this is you could easily change
the reset characteristics by only changing a couple lines
of code (not all always_ff decorators).

Also, I think if the @always_ff is used you have to
explicitly state the reset.  The reset argument would
not have a default value.

     @always_ff(edge, reset)

The @always_ff expects 1 edge and 1 reset.  Anything more
complicated fall back to the @always.  In this case
reset=None is a valid option.

Regards,
Chris