Scansion is not a simulator. It is a tool for viewing results from other simulators. While VCD is an industry standard for viewing logic waveforms, a file format for transaction traces is needed.
Scansion's SCNX file format is an open XML-based standard for recording transaction traces. It is described by a DTD located here. The format is simple and designed to be easy to add to any simulation environment if you know even a little bit of XML.
We only provide a library with source code for tracing SystemC at the moment, but we'll be adding tracers for SystemVerilog in the near future as well.
The file has the following primary elements: modules, event types, traces, events and properties.
Properties are available as sub elements for all of the other document elements. This is basically a key-value pair to allow you to create custom information for the other elements. This information will be made available in Scansion while you are viewing your results. For example event properties will show up in the Inspector when you click on events.
Module elements are used to describe the model hierarchy. Modules are named and can contain properties and other sub-modules.
Event Types describe an action to be performed on a transaction by a particular module. For example one event type might be named "Data Sent" to mark when the data phase was complete for some transaction. As their name implies they define a type not an instance. Thats the role of the Event described later. Event Types may also specify a category name to define the family of events it is a member of. For example, a category might be "PCIE Express" or "AHB".
Traces define generic objects that can have events attached to them. While these typically tend be packets or other requests that are being monitored though the system, they don't have to be. You can create an error logging trace and use it to attach error events to, for example.
Traces must have a unique name since they are global items in Scansion. Traces don't "live" in a module; Scansion associates a trace with a module if a module attaches any events to it. So a trace that has events from multiple modules will show up under each of those modules in Scansion's model browser.
Traces can define other traces as children, and conversely can define their own parent. Why? Imagine you are issuing a memory read. The read is one transaction, but the completion with the read data is another transaction that is really spawned by the first. Creating this completion trace as a child of the original request allows this to be viewed clearly in Scansion.
Events are instances of a particular event type at a particular time attached to a particular trace. Events always contain references to the trace they are being applied to, the type of event they are and the source module for the event.