[gem5-users] Debug flag output format
Hi all, I am using debug flags to generate output traces. How can I know the exact format of the output produced by each specific flag? I know that in each line first the current tick and the name of the simobject is printed, but I do not know the exact format for a specific, say CachePort, flag. Thank you very much Best, Mohammad Ahmadi ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Announcing the beta of gem5's new website
Hi all, I'm excited to announce that we have a beta version of a re-designed website at new.gem5.org! The old wiki has needed a refresh for a few years, and we’re excited to finally have something to share with the community! We hope the new site has better usability and makes it easier to find information about gem5 and how to use it. If you have any questions or comments, don’t hesitate to reach out by replying to this email. We will leave this website at new.gem5.org for the next few weeks. Please let us know if there’s any blocking issues before we turn off the old wiki pages. Before fully transitioning, we will download a static copy of the entire old website (including the old code reviews) and move this to old.gem5.org for archival purposes (and in case we missed anything!). I'd like to thank all of those that have contributed so far. Specifically: Jingwen Low who designed the site Ali Saidi who kicked this off by converting the wiki to markdown almost two years ago Bobby Bruce who has put it a ton of time moving documentation And Jared Barosci, Hoa Nguyen, Krithiga Murugavel, Ayaz Akram, Trivikram Reddy, Marjan Fariborz, Mahyar Samani, Julian Toya Angeles, and Muhammet Soytürk who have helped move documentation from the old wiki to the new site. See https://github.com/gem5/new-website/graphs/contributors for details Details on the current status of the migration can be found on Jira ( https://gem5.atlassian.net/browse/GEM5-110). We also have a specific issue for migrating the old documentation to the new site ( https://gem5.atlassian.net/browse/GEM5-115). We’ve already moved most of the documentation, but there are still a few pages that we could use your help with! There will be some rough edges as we transition. Some links may be broken, and it’s possible we missed pages that should be migrated. If you find any issues, please let us know via the mailing list or by opening an issue on Jira. The website is currently hosted on GitHub pages. If you’d like to contribute, feel free to create a pull request on the source repository ( https://github.com/gem5/new-website). Cheers, Jason ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] gem5 stable release proposal [PLEASE VOTE!]
I am happy for the efforts put in to make the GEM5 stable. "Developers can meddle. Please let the user have the pleasure of accessing stable version in main branch" "1 sounds late, 3 sounds obsessive, 2 is active. If possible make it 2 release per annum - just my opinion, discard if impossible" ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, I think master should be stable. I think gem5 should be released three times per year. Thanks, Karthik ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hello Jason My vote is: "I think master should be stable" Best regards J.Osmany > -Original Message- > From: gem5-users [mailto:gem5-users-boun...@gem5.org] On Behalf Of Jason > Lowe-Power > Sent: 16 December 2019 19:50 > To: gem5 Developer List ; gem5 users mailing list > > Subject: [gem5-users] gem5 stable release proposal [PLEASE VOTE!] > > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a "stable" > version of gem5. Below is the current proposal. There are a couple of points > below where there has not been general consensus reached. We would > appreciate feedback *from everyone in the community* on the points where > a decision hasn't been made below. gem5 is a community-driven project, and > we need feedback to make sure we're making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are doing this > for the following reasons: > - Provide a way for developers to communicate major changes to the code. > We will be providing detailed release notes for each stable release. > - Increase our test coverage. At each stable release, we will test a large > number of "common" benchmarks and configurations and publicize the > current state of gem5. > - Provide a way for researchers to communicate to the rest of the community > information about their simulation infrastructure (e.g., in a paper you can > say > which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the next > release, > but we will not make any API changes or add new features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier for > users > to get the most recent stable branch. If master is the development branch, > it's > more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it clear. > > Please let us know which you prefer by replying "I think master should be > stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three times per > year (April, August, and December). Once per year means that if you use the > stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from (but a > newer release should always be better). On the development side, I don't > think one will be more work than the other. Once per year means more > backporting, and three times per year means more testing and time spent on > releases. > > Please let us know which you prefer by replying "I think gem5 should be > released once per year" or "I think gem5 should be released three times per > year." > > > > > A couple of notes to everyone who's been following the discussion on the > gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that there > was some pushback on having only major releases when this was proposed on > the gem5 roadmap, but it sounded like the consensus was to drop minor > releases for now. > - We will still allow feature branches *in rare circumstances*. This will be > by > request only (send mail to gem5-dev if you would like to discuss adding a new > branch), and the goal will be integration within a few months. All code review > will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head of the > branch > 2) many features take more than a few months to implement, so if it's not > ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories and > *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to hear > back by the end of the week. However, I don't expect any concrete actions will > be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, I think master should be stable. I think gem5 should be released once per year. Best, Andreas On Tue, Dec 17, 2019 at 10:30 AM Muhammet Abdullah Soytürk < muhammetabdullahsoyt...@gmail.com> wrote: > Hi Jason, > > For the first one, I think master should be stable. > > For the second one, I think gem5 should be released three times per year. > > Cheers, > Muhammet > > Jason Lowe-Power , 16 Ara 2019 Pzt, 22:50 tarihinde > şunu yazdı: > >> Hi all, >> >> As many of you have seen on gem5-dev, we are going to be adding a >> "stable" version of gem5. Below is the current proposal. There are a >> couple of points below where there has not been general consensus >> reached. We would appreciate feedback *from everyone in the community* >> on the points where a decision hasn't been made below. gem5 is a >> community-driven project, and we need feedback to make sure we're >> making community-focused decisions. >> >> We will be introducing a new "stable" branch type to gem5. We are >> doing this for the following reasons: >> - Provide a way for developers to communicate major changes to the >> code. We will be providing detailed release notes for each stable >> release. >> - Increase our test coverage. At each stable release, we will test a >> large number of "common" benchmarks and configurations and publicize >> the current state of gem5. >> - Provide a way for researchers to communicate to the rest of the >> community information about their simulation infrastructure (e.g., in >> a paper you can say which version of gem5 you used). >> >> On the stable version of gem5, we will provide bugfixes until the >> next release, but we will not make any API changes or add new >> features. >> >> We would like your feedback on the following two questions: >> >> **Which branch should be default?** >> >> We can either have the master branch in git be the "stable" or the >> "development" branch. If master is the stable branch, then it's easier >> for users to get the most recent stable branch. If master is the >> development branch, it's more familiar and easier for most developers. >> Either way, we will be updating all of the documentation to make it >> clear. >> >> Please let us know which you prefer by replying "I think master should >> be stable" or "I think master should be development". >> >> **How often should we create a new gem5 release?** >> >> We can have a gem5 release once per year (likely in April) or three >> times per year (April, August, and December). Once per year means that >> if you use the stable branch you will get updates less frequently. >> Three times per year will mean there are more releases to choose from >> (but a newer release should always be better). On the development >> side, I don't think one will be more work than the other. Once per >> year means more backporting, and three times per year means more >> testing and time spent on releases. >> >> Please let us know which you prefer by replying "I think gem5 should >> be released once per year" or "I think gem5 should be released three >> times per year." >> >> >> >> >> A couple of notes to everyone who's been following the discussion on >> the gem5-dev mailing list: >> - We have dropped the proposal for major vs minor releases. Note that >> there was some pushback on having only major releases when this was >> proposed on the gem5 roadmap, but it sounded like the consensus was to >> drop minor releases for now. >> - We will still allow feature branches *in rare circumstances*. This >> will be by request only (send mail to gem5-dev if you would like to >> discuss adding a new branch), and the goal will be integration within >> a few months. All code review will still happen in the open on gerrit. >> The benefits will be >> 1) rebases won't be required as you can just make changes to the head >> of the branch >> 2) many features take more than a few months to implement, so if it's >> not ready by a release it can be pushed to the next >> 3) large changes won't be hidden in AMD or Arm-specific repositories >> and *anyone* will be able to request a branch. >> >> Thanks everyone for the discussions so far! It would be most useful to >> hear back by the end of the week. However, I don't expect any concrete >> actions will be taken until after the holidays. >> >> Cheers, >> Jason >> ___ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, For the first one, I think master should be stable. For the second one, I think gem5 should be released three times per year. Cheers, Muhammet Jason Lowe-Power , 16 Ara 2019 Pzt, 22:50 tarihinde şunu yazdı: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hello, - I think master should be stable. - I think gem5 should be released three times per year. Regards, -- Kleovoulos Kalaitzidis Doctorant - Équipe PACAP Centre de recherche INRIA Rennes - Bretagne Atlantique Bâtiment 12E, Bureau E301, Campus de Beaulieu, 35042 Rennes Cedex, France - Original Message - > From: "Jason Lowe-Power" > To: "gem5 Developer List" , "gem5 users mailing list" > > Sent: Monday, December 16, 2019 8:50:12 PM > Subject: [gem5-users] gem5 stable release proposal [PLEASE VOTE!] > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] Router Inactive
Hello everyone, I want to cut all the four links to the router so that it will become inactive. Is there any way to make the router inactive in gem5 simulations? Thanks and best regards, J Durairaj ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
