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

[Angel E. <ezq...@gm...>]

On Jul 3, 2012 6:32 PM, "Jan Decaluwe" <ja...@ja...> wrote:
>
> 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,

given how contentious the asynchronous vs synchronous reset debate is I
would argue that there should be no default value in this case, and that
the reset type should always be set explicitly.

Cheers,

Angel