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.

Sign up for GitHub

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

Jump to bottom

410.bwaves spec benchmark not working with LTAGE predictor #138

Open
krithi96 opened this issue Jun 6, 2019 · 2 comments
Open

410.bwaves spec benchmark not working with LTAGE predictor #138

krithi96 opened this issue Jun 6, 2019 · 2 comments

Comments

@krithi96
Copy link

krithi96 commented Jun 6, 2019 •
edited
Loading

To fix the 410.bwaves spec benchmark error while running it with LTAGE predictor.

  • The error is : assertion fail for MaxAddr : “Assertion `corrTarget != MaxAddr' failed.”
  • Error occurs in file:build/X86/cpu/pred/ltage.cc
  • The experiment was run on SE mode.

config script:
1.Use Spec_run.py and spec_processes.py
2.Set branchPredictor to LTAGE in the spec_run.py.

Run script
1.Use run_gem5_experiments.sh.
2.Set workload: by making variable bms = 410.bwaves : The used executables and input files
3. Set (cpu): cpus to any of this or all of this: DefaultO3.O3_W256, O3_W2K.
4. Set memory : SingleCycle
@krithi96 krithi96 changed the title 410.bwaves Spec benchmark not working with LTAGE predictor 410.bwaves spec benchmark not working with LTAGE predictor Jun 6, 2019
@powerjg
Copy link
Member

powerjg commented Jun 6, 2019

Thanks for opening this issue! As I alluded to last week, we need to come up with a set of guidelines to help make these bug-related issues easier to work on.

So, how do I reproduce this issue? What information do I need to reproduce it?

@powerjg
Copy link
Member

powerjg commented Jun 24, 2019

This looks great!

A couple of questions...

  • How long does the error take to happen?
  • Can you reproduce the error without using run_gem5_experiments.sh? I.e., just using config/run scripts, not using other wrapper scripts.

It's really hard to know what's wrong. I suggest using some debug flags to try to get more insight into what's going on inside gem5.

kaustav-goswami pushed a commit that referenced this issue Oct 31, 2023
@powerjg
gpu-compute: "<random>" -> "base/random.hh" in testers/gpu... (#140)
81cc57b 
In "src/cpu/testers/gpu_ruby_test" a random number generator was used.
This was using the CPP "<random>" library. This patch changes it to the
gem5 random class (that declared in "base/random.hh").

In addition to this, undeterministic behavior has been removed. Via
"protocol_tester.cc" the RNG is either seeded with a seed specified by
the user, or goes with the gem5 default seed. This ensures reproducable
runs. Prior to this patch the RNG was seeded with `time(NULL)`. This
made finding faults difficult.

This, at least partially, addresses Issue #138

Change-Id: Ia8e9f7b87e91323f828e0b7f6c3906c0c5793b2c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@powerjg @krithi96