Question about difference between Sparta and gem5

[dzwduan]

sprata and gem5 both event driven，in contrast, what are the advantages of sparta?

[dzwduan]

Open-Xiangshan is now using gem5，if i use sparta for xiangshan model，what can I gain differently?

[klingaard]

Thank you Zhen for your question! This has been asked of me before.

Gem5 is an excellent tool for processor/system modeling and development. It is a full system simulator and can run a workload "execution-driven style" meaning the application can run as-is on the simulator. That's a large benefit and at the same time, a deficit to that type of simulation platform. More on that below.

Sparta is a modeling framework allowing for dynamic, run-time modeling topologies and removing the overhead of tracking time progression, data delivery timing, data collection methodologies, report generation, etc. The models that are built using Sparta can be driven in whatever fashion a modeler wants: agitator/instigators, traces (like STF), or data driven like execution-driven models like Gem5.

I like to break down the difference between the two simulation offerings like this: models developed in Gem5 can be ported to use the Sparta framework quite easily. It's more difficult to go the other way due to the lack of support for timing/event handling in Gem5 (more on that below as well).

Below are the points I have made in the past, but now I can write them down. 😁 If there are errors in my understandings, please feel free to correct.

Licensing Issues

Gem5 licensing is not a risk-less license, which makes some companies leery to adopt Gem5 for research/patent analysis. Sparta is based on the Apache 2.0 license with no risks associated. Also, Sparta contains no licensing/copyrights from ARM or companies of the like.

The Framework

Gem5 is both a framework and a full system modeling solution. Sparta is a framework only with examples of how to build custom models like the one hosted by RISC-V International's Performance Modeling SIG and in the examples directory.

Sparta was built from the ground up to be a modeler's solution, enabling as many dynamic, run-time features as possible. These include topology definitions, multiple formats report generation, notification mechanisms. event ordering, modular unit definitions, data collection at any level at any moment in time, error handling (and resolutions), pipeline crawling, etc.

One advantage Sparta has over Gem5 is the ability to model unit interactions at a very detailed level especially when dealing with 0-cycle behaviors (see Modeling Differences below). This is all controlled by a proper use of the Discrete Event Simulation (DES) kernel in Sparta.

Modeling Differences

Gem5 o3 CPU model is not event driven. In fact, it is a PSNS model that is explicitly controlled by 1 event called by the Gem5 framework (examine the tick method and notice explicit advancement calls). The topology in the o3 model is fixed with each component being explicitly advanced in the order the modeler thinks is appropriate. This hard coded topology and explicit advancement is very restrictive especially if attempting a 0-cycle non-PSNS behavior between blocks or even exploring multiple topologies.

Sparta allows for 0-cycle communication between blocks via its precedence framework and allows the modeler to freely build unit blocks that can be dynamically connected enabling the exploration of different topologies at runtime. See an example of multiple topology definitions here (small, medium, big core) and how they are dynamically defined here.

When properly connected, the Sparta framework will automatically determine the proper order in which a pipeline is to be advanced. The framework is aware (or can be made aware) of 0-cycle dependency chains and ensure the ordering is adhered. The framework can also ensure cyclic behavior was not introduced which can lead to infinite loop conditions.

Model Performance and Use

I do not have much experience with Gem5's performance lately (used it many years ago), but I've been told it's pretty slow. This lack of simulation performance is mitigated by using SimPoint analysis to find relative hotspots in simulation and to use checkpoints to only analyze those areas. That helps...

Modelers who build custom CPU models using Sparta roughly follow the same pattern of workload analysis, but instead of running checkpoints, modelers typically create STF traces using the same SimPoint analysis flow and an instrumented functional model. This allows a modeler using Sparta to not care about functional accuracy but focus instead on performance analysis of his/her device.

Finally, if the event driven mechanism is properly utilized (i.e. only schedule events when there is work to do), the modeler has complete control of the performance of the simulation. The current design of the o3 model does not allow that.

Summary

Gem5 has advantages over Sparta; Sparta has advantages over Gem5. Either way the modeler must decide based on his/her use case and intended purpose.

If the use case is fast CPU/SoC/GPU designs and tradeoffs with multiple topology explorations and different architectures with precise event handling, I'd suggesting giving Sparta a try.

If the use case is rough performance adherence with full functional support and not much detailed exploration via topological differences or timing flows, then Gem5 will be a good start.