Snapshots
As constructing the object graph can be quite complex, it is useful to do this once using the command line interface.
The object graph can then be serialized to a JSON file.
This is done using the snapshot-save and snapshot-restore commands (these have aliases save and restore).
A snapshot normally consist of the JSON file containing the object graph and property values, and separate binary blobs containing ROM and RAM contents.
The JSON snapshots are human readable, so, simple editing can be done on them by hand using a text editor.
Snapshot Restore Phases
The JSON snapshot mechanism follows a phased approach. This is important in case of implementing custom snapshot restore logic.
In particular this mean that the following holds:
-
All non-registered pointers to TEMU objects will become invalid after objects have been recreated.
-
Object constructors will be called without arguments. It is up to the model implementor to ensure that restore is successful using properties and custom restore logic.
-
Processor and clock custom logic is responsible to restore the event queues. Do not register events outside the object constructor.
JSON Caveats
64-Bit Values
JSON does not allow for larger than 53 bit integers to be stored in a portable way (as JavaScript uses doubles for storing integer values).
In case a JSON file is edited, pay attention that when data of type uint64_t is serialized, it is split into two separate 32 bit values, thus the arrays storing the values will contain twice the elements that are actually in the object’s property.
ROM and RAM Contents
Another issue is that JSON is not practical for storing RAM and ROM dumps which are needed if saving and restoring a snapshot not at time 0. Thus ROM and RAM is stored in a binary dump (which is host endian dependent) and the JSON file with the saved system configuration contain references to these RAM and ROM dump files.