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

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

On 06/18/2012 07:18 PM, Christopher Felton wrote:
> <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?
>
>
> 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?

Yes, that is exactly the idea.

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

Seems a very good idea. Perhaps even introduce a
Signal subclass, ResetSignal, to set the properties
at construction time and allow type checking in the
always_ff decorator:

reset = ResetSignal(0, active=0, async=True) # defaults shown

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

Right.

-- 
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
     World-class digital design: http://www.easics.com