Re: [myhdl-list] Reset functionality "synthesis"
Brought to you by:
jandecaluwe
From: Christopher F. <chr...@gm...> - 2012-07-04 19:21:33
|
<snip> > > 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. > I'm getting to this conversation a little late. It sounds like we decided explicitly listing the /level/ and /async/ is preferred. I am ok with this. If it wasn't enforced (I am ambivalent if is should be enforced) I would adopt the style to always list, I like how it looks. reset = ResetSignal(0, level=False, async=True) I use the common async assert, sync release type resets, as well. With the /always_seq/ something that might be worth discussing is the inclusion of clock gating. Clock gating is used frequently in ASIC designs and is becoming more common in FPGA designs. A clock gating description might look like the following with the original @always construct. @always(clock.posedge, reset.negedge) def hld(): if not reset: ... else: if(enable) : # clock gate signal x.next = somethingAwesome or somethingGreat Most @always blocks would have the if-else:if pattern. With the /always_seq/ this could look like @always_seq(clock.posedge, reset=reset, clock_gate=enable) def hdl(): x.next = somethingAwesome or somethingGreat The /clock_gate/ would be optional since it is not as common (required) as a reset. Regards, Chris |