SystemC vs Sparta

[klingaard]

In this discussion, I wanted to elaborate on differences between SystemC and Sparta. This isn't a discussion on why one should use one framework over the other, but there are advantages of using Sparta over SystemC and vice-versa.

For my part of the discussion, I can list what I and others have added to Sparta that differ from SystemC. I hope others that wander into this discussion with a stronger background in SystemC than I can contribute as to the advantages of SystemC over Sparta. Of course, those deficiencies might turn into Sparta enhancements. 😉

[klingaard]

Event Ordering

When we started on the development of Sparta back in the day, we (3 engineers) listed numerous requirements Sparta needed to satisfy based on our 20+ years of building performance models and frameworks. A subset of the requirements can be found in this presentation.

One of the main requirements, which SystemC lacks, is the ability to order events in simulation. Specifically, when modeling a block that has numerous inputs that are collected in the same cycle to form a single output (think about a mux) knowing when the modeler can calculate that final output is challenging. I believe SystemC solves this issue with the delta cycle, allowing a block to "recalculate" the output if new stimulus is provided in the same cycle.

Sparta solves this problem by allowing a modeler to order events within a block or even across blocks. In this fashion the modeler can indicate that the calculation event must be scheduled after all input events are satisfied. No need to recalculate anything. If the calculation event is called, the modeler is guaranteed that all inputs are finalized.

[aohzju]

This is a great thread.
I got to know Sparta framework via a Youtube presentation. I've got a few questions. It's much appreciated if someone could help to answer:

1. Is Sparta a library based on SystemC? Or totally a different simulation framework?
2. Does Sparta include a simulation scheduler, similar to the one coming in SystemC?
3. How does Sparta interact with SystemC modules? Especially if Sparta has its own scheduler, is it compatible with SystemC's design philosophy?
4. How about Sparta's simulation speed? With SystemC, the slower the simulation, the more timing details annotated.

Thanks
-Oscar

[klingaard]

1. Is Sparta a library based on SystemC? Or totally a different simulation framework?

Sparta is not based on SystemC, but rather a different simulation framework designed from the ground up to be more of a software developer's framework for performance and functional modeling. The framework was designed, written, and tested to facilitate the following concepts:

1. Modular component development, design, and dynamic relationships that are easy to configure
2. Easy parameterization without the uncertainty of simulation construction ordering.
3. Enables on-the-fly topology changes without the need for a recompile
4. Easy data collection for counter, statistics, reports, pipeline crawls, performance events, observation events, etc
5. Deterministic event ordering ensuring the exact same simulation results every time
6. Ability to build simulations in either standalone/command line form or library
7. Easy debugging tools like logging mechanisms, error log dumping, content collection on fail, etc
8. Etc...

Take a peek at the online presentation for Sparta here for slightly more information. Or, feel free to browse the online documentation as well.

2. Does Sparta include a simulation scheduler, similar to the one coming in SystemC?

Sparta does contain a scheduler, but nothing like SystemC's. Specifically, Sparta's scheduler is more similar to a calendar based scheduler design than a present-state, next-state phase design as in SystemC. Sparta's scheduler is agnostic to phases, meaning the modeler can use/define as many phases and he/she desires and define their order. In turn, those phases are converted to event groups in the Scheduler, with each event given a specific place in the Scheduler at schedule time. This enables Sparta to enforce ordering between events.

To compare schedulers, you can look at Sparta's main run loop and compare to SystemC's main run loop which is composed to mostly 2 phases (hence the present-state/next-state concept).

3. How does Sparta interact with SystemC modules? Especially if Sparta has its own scheduler, is it compatible with SystemC's design philosophy?

When we designed Sparta, there was an interoperability requirement with SystemC. To enable that, a SystemC/Sparta adapter class was written to allow the two schedulers to "work together" and is documented here. But there is more documentation on this Discussion link.

There is 1 caveat with the two simulation frameworks working together: if there is a 0-cycle request/response requirement between a SystemC module and a Sparta unit, this isn't supported. See the above documentation for more details.

4. How about Sparta's simulation speed? With SystemC, the slower the simulation, the more timing details annotated.

I did an experiment many months ago writing a simple producer/consumer model using both frameworks. I'll have to try and find it...

The results from that experiment:

1. Writing a simple producer/consumer model in SystemC was easier/faster than in Sparta. Sparta requires more up-front definitions and construction than SystemC
2. SystemC was compiled with highest optimizations as well as disabling assertions, VCD collection, etc that allowed the framework to run as fast as possible
3. Sparta was compiled as is with full functionality enabled
4. Sparta's producer/consumer application was roughly 5x faster than SystemC and produced the exact same results.

Good questions. Thank your for asking them!