[myhdl-list] Reset functionality "synthesis"

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

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!

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