Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ati: Add ATI timing utilities #3

Draft
wants to merge 7 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions Bender.yml
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,15 @@ sources:
# levels 1 and 0, etc. Files within a level are ordered alphabetically.
# Level 0
- src/clk_rst_gen.sv
- src/interfaces.sv
- src/rand_id_queue.sv
- src/rand_stream_mst.sv
- src/rand_synch_holdable_driver.sv
- src/rand_verif_pkg.sv
- src/sim_timeout.sv
# Level 1
- src/rand_synch_driver.sv
- src/timing_pkg.sv
# Level 2
- src/rand_stream_slv.sv

Expand Down
15 changes: 15 additions & 0 deletions src/interfaces.sv
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
// Copyright (c) 2022 ETH Zurich, University of Bologna
//
// Copyright and related rights are licensed under the Solderpad Hardware
// License, Version 0.51 (the "License"); you may not use this file except in
// compliance with the License. You may obtain a copy of the License at
// http://solderpad.org/licenses/SHL-0.51. Unless required by applicable law
// or agreed to in writing, software, hardware and materials distributed under
// this License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
// CONDITIONS OF ANY KIND, either express or implied. See the License for the
// specific language governing permissions and limitations under the License.

interface clk_if();
logic clk;
logic rst_n;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

@colluca colluca Jan 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

endinterface
93 changes: 93 additions & 0 deletions src/timing_pkg.sv
Original file line number Diff line number Diff line change
@@ -0,0 +1,93 @@
// Copyright (c) 2022 ETH Zurich, University of Bologna
//
// Copyright and related rights are licensed under the Solderpad Hardware
// License, Version 0.51 (the "License"); you may not use this file except in
// compliance with the License. You may obtain a copy of the License at
// http://solderpad.org/licenses/SHL-0.51. Unless required by applicable law
// or agreed to in writing, software, hardware and materials distributed under
// this License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
// CONDITIONS OF ANY KIND, either express or implied. See the License for the
// specific language governing permissions and limitations under the License.

/// Package with functions and tasks commonly used in ATI timing
package timing_pkg;

class ati_utility;

typedef virtual clk_if clk_vif_t;

bit initialized;
clk_vif_t clk_vif;
time appl_delay, test_delay;

function new(clk_vif_t clk_vif);
this.clk_vif = clk_vif;
this.appl_delay = 0;
this.test_delay = 0;
this.initialized = 0;
endfunction

function void uninit_warning();
if (!this.initialized) $warning("ATI delays uninitialized");
endfunction

task init(time appl_delay, test_delay);
// Measure clock period
time st, clk_period;
@(posedge clk_vif.clk);
st = $time;
@(posedge clk_vif.clk);
clk_period = $time - st;

// Consistency checks on delays
assert (appl_delay < clk_period) else $error("Application delay greater than clock period");
assert (test_delay < clk_period) else $error("Test delay greater than clock period");

// Configure
this.appl_delay = appl_delay;
this.test_delay = test_delay;
this.initialized = 1;
endtask

task wait_cycles(int unsigned n);
repeat(n) @(posedge(clk_vif.clk));
endtask

task appl_wait_cycles(int unsigned n);
uninit_warning();
this.wait_cycles(n);
#(appl_delay);
endtask

task test_wait_cycles(int unsigned n);
uninit_warning();
this.wait_cycles(n);
#(test_delay);
endtask

task test_wait_sig(ref logic sig);
uninit_warning();
do begin
@(posedge(clk_vif.clk));
#(test_delay);
end while(sig == 1'b0);
endtask

task wait_test();
uninit_warning();
#(test_delay);
endtask

task wait_appl();
uninit_warning();
#(appl_delay);
endtask

task wait_appl_to_test();
uninit_warning();
#(test_delay - appl_delay);
endtask

endclass

endpackage