Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
base: master
Are you sure you want to change the base?
ati: Add ATI timing utilities #3
Changes from 1 commit
1ac7896
03985b6
5ec5595
d95efef
0714cd8
67963d7
15fb795
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
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
?There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 areset
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 withrst_n
, none of the methods are affected by it. For example, what would thewait_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?There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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., asHandling reset outside
ati_utility
Remove
rst_n
fromclk_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 outsideati_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.