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

[Tom D. <td...@di...>]

One question, will you still be able to have a register that is not 
reset and doesn't have an initial value?

I often use those in FPGAs when I want a shift register to get optimized 
to local memory.

On 06/15/2012 09:02 AM, Jan Decaluwe wrote:
> I think I have a good idea for a "micro-killer feature" -
> something that one can't do with traditional HDLs, but
> that makes a designer's life much easier.
>
> This was triggered by the latest discussion and work on
> initial values. Here is a summary of the starting point.
>
> I believe all signals/variables should have an initial
> value in RTL. Ideally, those initial values should be
> present in the converted Verilog/VHDL also, and we are
> currently discussing how and when to do so.
>
> However, there is the question of the reset functionality
> at the lower levels. Some people use the fact that
> signals are not initialized to check whether the reset
> works properly. With initial values, this is no longer
> possible (in simulation at least).
>
> The idea I have started as follows. Initial values and
> reset functionality seem related but at a different level.
> However, I don't see why there can ever be a good reason to
> use an initial value that is different from the reset value.
> The question is then if we can use that redundancy to our
> advantage.
>
> In a language like SystemVerilog, there is a dedicated
> always construct, always_ff, which can be used to check
> correctness of blocks with flip-flop inference, e.g.
> whether all flip-flops have a reset. In MyHDL, we could
> improve by checking that all flip-flops are reset to the
> initial value.
>
> 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.
>
> 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!
>