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

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

On 07/03/2012 04:33 PM, Angel Ezquerra Moreu wrote:
> On Tue, Jul 3, 2012 at 1:57 PM, Jan Decaluwe<ja...@ja...>  wrote:
>> On 06/27/2012 06:08 AM, Christopher Felton wrote:
>>> <snip>
>>>>>>
>>>>>> 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
>>>
>>> That seems very reasonable, I like it.  This should be a
>>> pretty cool addition!
>>
>> I have gone forward with implementing this, because I am
>> working on a project in which it is immediately useful.
>>
>> I have decided to rename the decorator to always_seq, for
>> sequential, as opposed to combinatorial.
>>
>> always_ff in SystemVerilog means something else, and suggests
>> a much lower level by referring to flip-flops, so reusing
>> this name would be confusing. So now we have always_comb
>> and always_seq, much more logical in RTL coding.
>>
>> The draft implementation is in the public repo.
>> There is a ResetSignal as discussed. Conversion is implemented
>> for VHDL and Verilog.
>>
>> No unit tests yet.
>> I have only tried it for async reset with active level 0,
>> so for other cases there may be bugs.
>>
>> I think this is going to be a great feature. My code becomes
>> so much smaller in one pass, and you get "to the point"
>> immediately instead of being distracted by all those reset
>> assignments.  At first, it looks a little suprizing
>> (where are my reset values?) but I think it's a matter of
>> getting used to the concept.
>>
>> Note that you can construct "local" signals close to the
>> generator where they are used, not necessarily all in
>> the beginning.
>>
>> Example usage:
>>
>>       ...
>>       reset = ResetSignal(0)
>>       ...
>>       ready = Signal(bool(0))
>>       s0, s1, s2 = [Signal(bool(0)  for i in range(3)]
>>
>>       @always_seq(clock.posedge, reset=reset)
>>       def synchronizer():
>>           s0.next = ready_toggle
>>           s1.next = s0
>>           s2.next = s1
>>           ready.next = s2 != s1
>>
>> When reset goes low, the signals are asynchronously reset to
>> their initial values.
>
> Jan,
>
> how do you choose between synchronous and asynchronous reset?

reset = ResetSignal(0, async=False)

Note that you can change the reset style (and the
active level) for the whole reset tree by merely
changing the reset constructor.
Changing styles has never been so easy!

> Is asynchronous reset the default?

Yes.

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