ati: Add ATI timing utilities

[colluca]

ATI timing utility class. Provides convenience methods to time apply and acquire signal operations according to ATI specification.

[andreaskurth]

Thanks for this useful addition, @colluca!

I agree with the design, and I have a few comments on the implementation.

[andreaskurth]

This signal is currently unused. Why is it part of clk_if?

[colluca]

To the purpose of this class it is not used. But since a clock is generally coupled with a reset, I thought this way one would only have to declare a single virtual interface, e.g. to pass to drivers, rather than have another interface just with the clock.

What are your opinions regarding this?

[andreaskurth]

I would keep the reset outside the driver and thus also outside the virtual interface. As evident from recent group discussions, such a rst_n signal cannot be used as functional reset without careful consideration, so I would avoid giving that impression to users. A driver typically provides a reset method that is called by the TB-level reset controller when appropriate.

The current implementation of ati_utility demonstrates one problem quite nicely: even though it is supposed to work with rst_n, none of the methods are affected by it. For example, what would the wait_cycles method do if the reset becomes active (i.e., goes low) while it is counting down? Stop counting and restart counting when the reset is deactivated? Or pause counting and continue when the reset is deactivated?

[colluca]

These are very good questions indeed, and maybe even justifies having these methods in a centralized place, so that it is taken care of for future programmers, avoiding that they incur in the same questions (or, worse, problems). How do you suggest we face these questions?

[andreaskurth]

I see two main alternatives:

Handling reset inside ati_utility

Define that reset asynchronously terminates any of the wait tasks. This could be implemented, e.g., as

/// Wait for `n` cycles of `clk_vif.clk` or for a negative edge of `clk_vif.rst_n`.
task wait_cycles(int unsigned n);
    fork
        repeat(n) @(posedge(clk_vif.clk));
        @(negedge(clk_vif.rst_n));
    join_any
endtask

Handling reset outside ati_utility

Remove rst_n from clk_vif. The user then has the responsibility (but also the flexibility) of handling reset behavior themselves.

Deciding on one alternative

I think this boils down to the following question pair: Do we consider resetting a feature and design goal of ati_utility and then implement it as we see fit? Or do we leave resetting entirely to the user, to be implemented outside ati_utility if necessary?

I further think a good rule of thumb is: Do we see a real use case for this feature and know we want to implement it one way or the other? If not, I think we should defer this feature to when we really need it.