Rich, Sorry for the delay in responding. Ali and I were comparing notes to come up with a unified response.
We appreciate your interest in gem5. We're very curious about what you are looking for in a simulation tool, and what features or capabilities you see are missing from other tools. Even if gem5 doesn't meet your needs out of the box, we'd be very interested in discussing with you whether and how we might work to make gem5 something that does address your needs. We're always interested in increasing gem5's value, and it's typically the case that by working together in an open-source framework like gem5 we can leverage each other's investments to our mutual benefit. > 1. How does gem5 currently interact with or support SystemC models? I see lots of references to them being similar but not exactly that they are compatible. You're correct that gem5 and SystemC are not currently compatible. The original M5 simulation environment (from which gem5 derives) began development before SystemC TLM took off, but gem5 and TLM have roughly the same goals in terms of supporting both "loosely timed" and "cycle approximate" object-based modeling in a common environment, and as a result have evolved some comparable (though distinct) internal interfaces. Thus we find it very useful for people who are familiar with SystemC TLM to use that as a point of reference when explaining the goals of gem5. Though we can't currently interoperate with SystemC models, this feature has long been on our radar. It's certainly very feasible. Some universities and companies have connected SystemC models to the simulator in the past and there are some papers about their experiences, although none of them have contributed those interfaces back to the public code base. Additionally, we have been converting the memory system within gem5 to use four-phase TLM2-like handshakes, which should make an adapter straightforward to write. We think it's just a matter of someone having the motivation both to do the work and to contribute the code back. > 2. How much of the model library includes non-generic IPs? For example, an ARM PL341 instead of generic memory? There are some non-generic devices in the dev directory (PL111, PL031, and other devices that are required for booting a system). Most gem5 users are looking for larger trends where generic models that are suitably configured are sufficient. The object-oriented nature of the simulator allows different memory controllers or other devices to be plugged in. Some people in industry have developed models of their IPs, but these tend to be more difficult to share so they don't show up in the public code base. > 3. For users who have extensive use of gem5 in architecture analysis, how much confidence do you have in comparing the simulation results from different configurations and relating that to real system architecture decisions? In other words, how well do the behavior changes in different configurations of generic models translate to different configurations of real IP? We've done some work on correlating gem5 performance results with real systems. Much of that has been internal to AMD and ARM so it's not possible to say anything concrete. One published work (from when Ali was a grad student) is here: http://web.eecs.umich.edu/~stever/pubs/iosca05.pdf Another correlation study was presented at a recent workshop: Accuracy Evaluation of GEM5 Simulator System. A. Butko, R. Garibotti, L. Ost, and G. Sassatelli. In the proceeding of the IEEE International Workshop on Reconfigurable Communication-centric Systems-on-Chip (ReCoSoC), York, United Kingdom, July 2012. That paper doesn't seem to be easily accessible online, but the conclusion states "According to the results, the accuracy varies from 1.39% to 17.94% depending on the memory traffic. In the worst scenario, mismatch has been shown to result from overly simple model of the external DDR memory in GEM5 that does not fairly model DRAM specifics." Regards, Steve & Ali On Thu, Oct 4, 2012 at 11:21 AM, Rich Podraza <rich.podr...@open-silicon.com > wrote: > Hi all,**** > > ** ** > > I never got any responses on this, so instead I’ll ask: is there a better > forum or resource to find information and opinions on these questions? > Seems like this mailing list is not the place.**** > > ** ** > > Thanks,**** > > Rich**** > > ** ** > > *From:* gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] *On > Behalf Of *Rich Podraza > *Sent:* Tuesday, October 02, 2012 10:35 AM > *To:* gem5-users@gem5.org > > *Subject:* [gem5-users] Questions on gem5 and SystemC, IP modeling, and > architectural analysis.**** > > ** ** > > I just reviewed the HiPEAC Computer Systems Week slides and videos posted > on the tutorials page and I have some questions about gem5. I am doing > system modeling with some other tools right now and am interested in how > gem5 may or may not overlap with them. I think the tools look very > promising but am unsure about the level of abstraction and seeming lack of > cycle-accuracy. **** > > ** ** > > **1. **How does gem5 currently interact with or support SystemC > models? I see lots of references to them being similar but not exactly that > they are compatible.**** > > **2. **How much of the model library includes non-generic IPs? For > example, an ARM PL341 instead of generic memory?**** > > **3. **For users who have extensive use of gem5 in architecture > analysis, how much confidence do you have in comparing the simulation > results from different configurations and relating that to real system > architecture decisions? In other words, how well do the behavior changes in > different configurations of generic models translate to different > configurations of real IP?**** > > ** ** > > Thanks for any comments!**** > > ** ** > > Rich**** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material.If you are not the intended recipient of this message please do not > read, copy, use or disclose this communication and notify the sender > immediately.It should be noted that any review, retransmission, dissemination > or other use of, or taking action or reliance upon, this information by > persons or entities other than the intended recipient is prohibited.**** > > ** ** > > ** ** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material.If you are not the intended recipient of this message please do not > read, copy, use or disclose this communication and notify the sender > immediately.It should be noted that any review, retransmission, dissemination > or other use of, or taking action or reliance upon, this information by > persons or entities other than the intended recipient is prohibited. > > > _______________________________________________ > 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
