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

Stall and Flush Counter (Initial Iteration) #203

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

matms
Copy link

@matms matms commented Mar 26, 2022

As per #174, I am opening a PR for adding a stall and flush counter.

However, note this PR is probably not quite mergeable yet. In particular, there are two "bugs", so we'd need to discuss how to fix these. In particular:

  • An instruction is considered and counted as stalled or flushed when it reaches WB, rather than when it leaves WB. This diverges from the behaviour of instructionsRetired, which counts an instruction as retired upon leaving WB.

  • The dual-issue processor currently considers only only one way for counting stalls and flushes. I suspect we might need a way to generically query a processor for which stages contain instructions that are about to be retired. Right now I'm using proc->stageInfo(proc->stageCount() - 1) to gather information about these instructions, which only works for the single cycle issue processors.

Once both these issues are resolved, we should be able to refactor instructionsRetired to be implemented in a manner similar to the stall and flush counter.

(Also, the diff for processortab.ui is quite messy... I hope this is not an issue)

@mortbopet
Copy link
Owner

mortbopet commented Mar 26, 2022

which only works for the single cycle processors.

do you mean single issue processors?

I suspect we might need a way to generically query a processor for which stages contain instructions that are about to be retired.

I've considered whether we need to switch up the way that a stage reports its # of stages. By only having the ability to specify # of stages, we miss out on the processor telling about its structure, as in, # of issue slots/lanes. Which then restricts itself to single-issue processors.
Instead, a processor could return a std::map<int, int> of specifying the lane # (key) and the stages in that lane (value). For the existing processors, this would be:

  • single cycle: {(0, 1)}
  • 5 stage: {(0, 5)}
  • 5 stage: {(0, 6), (1, 6)}

This scheme could (potentially) also work for out-of-order processors which could be cool to eventually have in Ripes!
StageInfo would then follow this mapping, wherein it is indexed by a tuple of (lane, stage #). From there, it would then be up to the stall/flush counting mechanism to determine how to map this information to a counter. What do you think about this?

(Also, the diff for processortab.ui is quite messy... I hope this is not an issue)
No worries, I'm assuming that you're using the UI Design tab in QtCreator, and so as long things look and act as expected, then all good!

mortbopet added a commit that referenced this pull request Mar 26, 2022
numStages is only sensible for single issue processors. In this commit, we introduce the ProcessorStructure type, a 2d mapping suitable for communicating more information about the datapath of a processor.
@matms matms force-pushed the stall-flush-counter branch from 3e72696 to a963fb3 Compare April 26, 2022 17:27
@matms
Copy link
Author

matms commented Apr 26, 2022

I've updated the flush and stall counter to use the new ProcessorStructure interface.

Sorry for the delay in updating, I've been quite busy the past few weeks.

@mortbopet mortbopet force-pushed the master branch 17 times, most recently from 30de4a0 to 057adf5 Compare April 16, 2023 17:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants