George Frazier Blog

Speeding up SystemC compilation with Incisive SystemC

georgef — Fri, 19 Jun 2009 13:00:00 GMT

If you’re a C++ and SystemC programmer you know that when you’ve spent all day tracking down a nasty bug, nothing can bum your trip more than having to wait around for a long recompile. Compile time is a bottleneck for SystemC development. Long compile times can come as a particular surprise for HDL programmers who aren’t used to the lag time caused by template instantiation, dependency checking, and the mysterious thinking that goes on the in the guts of g++ as it creates object code from source.

Incisive SystemC offers three tool-based methodologies for easing the burden of long compile times: precompiled headers, catcxx, and distcomp. We’ll explore all three in this posting.

Precompiled headers can dramatically speed up compilation for some projects. There are two ways to gain the advantages of precompiled headers in NC-SC. One is free (if you are using GCC 4.1 – GCC 3.2.3 does not support precompiled headers). By default, ncsc_run, irun, and the example makefiles get the main SystemC and SCV header files from a special directory that contains precompiled versions. In many cases, this speeds up compilation from 10 to 40%.

If you’re working with your own Makefiles you can still use the precompiled versions of the SystemC headers. Just keep the following rules in mind. A precompiled header is either a file or directory that exists in the same directory as the base header file and contains the suffix .gch. So, systemc_h.h.gch is a precompiled header version of systemc_h.h. Your source files that include either systemc.h, systemc, scv.h, and so on, as the very first line can use the precompiled version with the following caveats:

Only one precompiled header can be used in a particular compilation.
A precompiled header cannot be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you can even include a precompiled header from inside another header, as long as there are no C tokens before the #include.
The precompiled header file must be produced for the same language as the current compilation. You cannot use a C precompiled header for a C++ compilation.
The precompiled header file must be produced by the same compiler version and configuration as the current compilation is using. The easiest way to guarantee this is to use the same compiler binary for creating and using precompiled headers.
Any macros defined before the precompiled header (including with -D) must either be defined in the same way as when the precompiled header was generated, or must not affect the precompiled header, which usually means that they do not appear in the precompiled header at all.
Certain command-line options must be defined in the same way as when the precompiled header was generated. At present, it is not clear which options are safe to change and which are not; the safest choice is to use exactly the same options when generating and using the precompiled header.

The second and preferred method for using precompiled headers is to carefully organize your project so that large header files that seldom change are all included (with #include) into a single header file that you can then precompile along with systemc.h, scv.h, and so on. This might require code reorganization in your project, but usually it’s worth it since you can gain significant compile time improvement.

An example shipped based on the OSCI simple_bus (found at www.systemc.org) unit test in:

`ncroot`/tools/systemc/examples/precompiled_headers

demonstrates how to organize your code. The header files have all been included in project_h.h. Note especially that the file systemc.h is also included. ncsc_run is used to compile the header file:

% ncsc_run –noscv –gnu –GCC_VERS 3.4 –stop comp project_h.h

Another file, project.h, is introduced that includes (with #include) project_h.h. This extra layer is necessary, so we can use #ifdef guards around the inclusion of project_h.h. Then each .cpp file in the project includes (with #include) project.h as the first line in the source. This code arrangement leads to roughly a 20% improvement in compile-time performance for this example.

Moving on from precompiled headers, ncsc_run offers a more exotic approach to compile time reduction. When you specify the –catcxx option, i.e:

%ncsc_run –catcxx file1.cpp file2.cpp file3.cpp

ncsc_run creates a temporary file that includes (with the #include directive) all of the .cpp files in your model. Instead of compiling each file, it compiles the single "catcxx" file. I’ve seen compile time speedup with catcxx on the order of 80%, so in certain cases it will make your compiles sizzle.

It is important that you prepare the files for compilation first. In particular, to avoid multiple definitions of symbols caused by inclusion of header files in multiple source files, protect the header files with the #ifndef and #endif directives. Also, be aware that the #define directive will affect all of the .cpp files in the model that are included in the temporary file. This situation can cause unexpected results (for example redefinition warnings that can be suppressed by the use of the #ifndef macros in front of any #define). Also, include files are passed forward to every .cpp file in the model. If, for example, you need to define NCSC_INCLUDE_TASK_CALLS for one .cpp file that is not the first file in the list, then if systemc.h is already included before the #define comes into effect, you get a compilation failure. In cases like this, you should use the -D option on the command line, instead of #define in the .cpp file. Catcxx works best if the number of files in your model is between two and ten. When the number of files exceeds ten, the compilation improvement starts to diminish.

The third tool Incisive SystemC offers for compilation speed-up is LSF support for distributed compilation of SystemC/C++ source files on multiple machines. You have to use ncsc_run -distcomp to get this support and you must have LSF installed on your local. First point the path environment variable to the LSF bin directory. LSF provides various commands, but ncsc_run uses only bsub, LSF's batch job facility used by ncsc_run to run compile commands on remote machines.

The bsub command can take optional arguments that give you more flexibility: -x for exclusive execute mode, -c to set maximum cpu time, -m to specify host machines. You can pass these arguments to bsub using the -distcompargs option to ncsc_run. Because these options are supported by bsub and not ncsc_run, you should refer to the documentation that came with the distributed platform to resolve any issues related to using these options. By default, ncsc_run passes the -K option to bsub (to indicate waiting for the command to finish), and the -o option to log the bsub results into the bsub_results.log file located in the working directory.

ncsc_run uses make –j num to spawn concurrent bsubjobs; the number of jobs is controlled by the - distcompjobs option, the default being 20 parallel bsub jobs. For example, for a design containing 40 C++ source files, a new bsub call will be issued when one of the first 20 bsub calls finishes up, until all 40 are compiled. The purpose of the - distcompjobs option is to prevent flooding of bsub calls for very large designs. The other options used by ncsc_run to control distributed compilation are: -distplat, -distcomp, and nodistcomp.

Here’s an example:

-DISTPLAT lsf -NODISTCOMP file1.cpp file2.cpp -DISTCOMP file3.cpp file4.cpp

With this option applied, file1 and file2 are compiled locally, file3 and file4 are distributed.

So the next time you’re feeling the blues of a long build, consider one of Incisive SystemC’s strategies for speeding things up. Then get back to debugging.

George Frazier

Tracing TLM 2.0 Activity in an ESL Design – Part 3

georgef — Thu, 07 May 2009 13:00:00 GMT

Last time I discussed how to use –sctlmrecord to produce an SST2 database of TLM 2.0 transaction data (http://www.systemc.org). In this post, we’ll explore the data in the Simvision Waveform Viewer, the Transaction Explorer, and with TxE. This is the first step towards tying TLM 2.0 trace data to TLM 2.0 debug, a topic I’ll explore in greater detail in future entries.

The example can be found in an IUS 8.2 install at `ncroot`/tools/systemc/examples/tlm2/tutorial. If you want to follow along type:

%ncsc_run \

+txscmain \
simple_dma.cpp \
simple_rxtx.cpp \
sc_main.cpp \
simple_host.cpp \
simple_memory.cpp \
-nocopyright \
-DNCSC_INCLUDE_TASK_CALLS \
-scupdate \
-sctlmrecord \
-tlm2 \
-sctlmdbname tlm.shm \
-debug

And then launch Simvision to view the results:

%simvision tlm.shm/tlm.trn1

Previously, we produced a transaction stream and zeroed in on an area of interest: activity clustered around time 5400 ns for transaction stream isocket_1_0_SCTLMX.. In Simvision, you can drill down to time range 5400ns : 5500ns by typing in the time range box to the left of the magnifying glass. You will see a rectangle representing a transaction that begins at time 5400 ns (the rectangle is left-aligned with 5400 ns). Select that transaction by pressing the shift key and selecting with the left mouse button. If you are using the default color scheme in Simvision, the transaction outline will turn yellow. Next display a quick-view of the attributes by selecting the red resizing icon at the bottom left of the transaction and pulling it down until the entire transaction is visible (Figure 1).

Figure 1

Some of the attribute values are visible in the Waveform viewer. A powerful feature of Simvision is the ability to expand a stream by attribute value. Here, it would be interesting to separate transactions into rows of READS and WRITES. To do this, hover over the "Command" attribute of the selected transaction in the right window and right-click select the option "Expand Stream By Command" (see Figure 2):

Figure 2

To see the resulting rows expand the time range 0 ns – 20,000 ns. You will see two new rows below the original row (Figure 3).

Figure 3

It is easy to see that the dma is performing a block of READS (the topmost of the two new rows) followed by a series of WRITES followed later by another block of READS. You can move the WRITE row above the READ row by grabbing the [Command == "WRITE"] row heading in the name column on the left and dragging it by pressing the middle mouse button up above the [Command == "READ"] row. These expansions can be done by any attribute value (and the resulting rows can be rearranged or deleted as necessary).

Now change the time range back to 5400ns : 5500ns. Sometimes multiple transactions are recorded at the same time. In the default view only one of those transactions will be visible. Note that the original transaction at time 5400ns is still selected. To see if any other transactions are recorded in this time range right-click on the selected transaction and choose "Expand Stream." The resulting view (Figure 4) shows that one transaction begins at time 5400ns and three transactions begin at time 5410 ns. Selecting the transaction at time 5400 ns shows the three transactions aligned at 5400 ns all colored yellow: they are different views of the same transaction – one in the default stream, one broken out by time, the other broken out by command READ

Figure 4

Next, select the transaction that begins at time 5400 ns in the Waveform viewer. The best way to examine the value of its attributes is to display them in the Transaction Explorer. On the Transaction Explorer toolbar (which you can bring up by clicking the TxE button on the topmost tool bar) immediately to the right of the TxE button is a button that displays the detailed attributes of the transaction. Clicking the button brings up the Transaction Explorer Window (Figure 5):

Figure 5

This transaction corresponds to the first “hop” in an attempt to read 8 bytes from address 0x6000 with the blocking transport protocol (b_transport). ID 34 indicates this is the 34^th TLM 2.0 read or write operation attempted during this simulation. All of the remaining hops in the transaction sequence will share this ID because the same generic payload object is being passed across each transport boundary. This transaction is the initial transaction that connections simple_dma to memory_1. Since the operation is blocking, the start and end times represent the total time needed to complete the operation. However, there are three more hops remaining:

1. TOP_TB.TOP.dma_0.isocket_1_0 to TOP_TB.TOP.arbiter_0.tsocket_1_0
2. TOP_TB.TOP.arbiter_0.isocket_0 to TOP_TB.TOP.router_0.tsocket_0
3. TOP_TB.TOP.router_0.isocket_2_0 to TOP_TB.TOP.arbiter_1.tsocket_0_0
4. TOP_TB.TOP.arbiter_1.isocket_0 to TOP_TB.TOP.mem_1.tsocket_0

Simvision can build a graph representing this path based on the information recorded by TLM 2.0 tracing. To see the relations, open the View menu and select family_tree (Figure 6).

Figure 6

The yellow node corresponds to the Initiator transaction. The arrows show the order of transaction initiation which also corresponds to the connections in Figure 7.

Figure 7

Selecting any of the other graph nodes will update the attribute values in the Attribute window to the left. If you click the “See” button the Waveform window will be brought into focus with the transaction highlighted. The Waveform Viewer also reflects the information in the family tree (Figure 8).

Figure 8

The last four rows on the right show the Initiator transaction in yellow followed by the three succeeding transactions in green (the top row is the unexpanded view). The database generated by TLM 2.0 represents a complete history of the life spans of generic payload objects in a TLM 2.0 simulation. Within this data is a wealth of information about the functioning and performance of the design. Future versions of Cadence IUS will include a rich set of TLM data anlysis capabilities. One way to unlock this information in IUS 8.2 is through the use of TxE scripts. Here I present one script you can use as a starting point if you are interested in mining TLM 2.0 data. The script is simple, but you can expand it to include more of the generic payload fields or computed fields such as latency. The script prints basic information about each transaction to a file named “dump.log”. The attributes printed are start_time, end_time, Initiator, Target, and ID. To customize you can choose any attribute generate by TLM 2.0 tracing and add a “col” entry in the table section.

txe_file_version 4

txe_search_create search dump_log {

source {}

init {}

apply {

fiber * {

trans_type * {

}

exit {

}

table {

col {Begin Time} [tformat 12.2ns [start_time]]

col {End Time} [tformat 12.2ns [end_time]]

col {Initiator} [attribute "Initiator"]

col {Target} [attribute "Target"]

col {ID} [attribute "ID"]

sort {Begin Time}

}

doc {}

}

set text_file [open "dump.log" "w"]

foreach s [txe_search_get_list] {

# Execute the search.

txe_search_execute $s

# Write the results table

puts $text_file "[txe_search_get_path $s]"

puts $text_file "-------------------------------"

txe_table_write $text_file text $s

puts $text_file ""

}

# Close the text files.

close $text_file

Here’s the output from running the script on our database:

%txe –input dump.txe tlm.shm/tlm.trn

% more dump.log

My three posts on TLM 2.0 tracing in Incisive provide a small peek at the capabilities built into Incisive for working natively with TLM 2.0 data. This is just the beginning though, look for a richer set of TLM 2.0 tool features coming in IUS 9.2.

George Frazier

Tracing TLM 2.0 Activity in an ESL Design – Part 2

georgef — Tue, 07 Apr 2009 13:05:00 GMT

In my last post I discussed two ad hoc approaches for tracing TLM 2.0 activity in a design: using output statements to write to a text file or the terminal and using SCV transaction recording to write to a database such as SST2. If your goal is to debug the TLM-specific aspects of a design, you need to get a handle on the values of generic payload objects as they flow through the transport methods of your system. Whether or not you think printf debugging is barbaric, both ad hoc approaches force you to modify your design. More importantly for debugging, critical TLM 2.0 connectivity information is difficult to capture in trace logs.

Here’s what I mean by connectivity information. In TLM 2.0, the transport interfaces – b_transport, nb_transport_fw, and nb_transport_bw – model reads and writes between initiators and targets. An initiator is a module that initiates transactions (for example a processor); a target is a module that serves as the destination for transactions (for example a memory). An interconnect module such as an arbiter or a router is both an initiator and a target, but it doesn’t serve as the beginning or ending point of a transaction. As generic payload objects travel between initiators and targets, their "passports" might receive several stamps along the way. Figure 1 shows a design with a Processor, a Bus Bridge, and a Memory. Each arrow represents a "hop" in the lifespan of the generic payload object. A successful read or write will consist of four "hops" between the Processor and the Memory, two along the forward path and two along the backward path.

Figure 1 – a TLM 2.0 Design with an Initiator, an Interconnect, and a Target.

The –sctlmrecord feature of ncsim is based on the observation that to completely trace activity between an initiator and a target, each read or write should be broken up into a sequence of snapshots as generic payload objects progress through a series of hops. -sctlmrecord traces all the fields of the generic payload object and the before and after values of transport function parameters at each hop by recording an SST2 transaction into the database. Each read or write is modeled as a sequence of transactions. Connectivity information is captured by linking those transactions through SST2 parent/child relationships. The rules of TLM 2.0 determine when to terminate a transaction sequence (i.e. when the read or write has finished). Transactions that pass through calls to b_transport have completed when the call (which blocks) returns. Thus the timing points of a b_transport call can be determined by calling sc_time_stamp immediately before and after the call to b_transport. Determining when a transaction that passes through calls to nb_transport_fw and nb_transport_bw is complete is handled by the generic payload’s memory manager. The use of the non-blocking interfaces requires that a memory manager be set for each generic payload object. When the last component relinquishes control of the object and is available for pooling or deletion, the last "hop" of the transport chain has been finished.

The following ncsim command line options control TLM 2.0 tracing:

sctlmrecord

Turns on TLM 2.0 tracing mode for designs using transport calls:

sctlmdbname <dbname>

Specifies the database for TLM 2.0 tracing data:

sctlmnodata

Excludes recording of data transferred across the transport boundary, which improves efficiency because transferred data could be very large. Without this flag the data field is recorded as a string in hexadecimal format.

When you launch ncsim with –sctlmrecord, a transaction stream is created for each Initiator that actively participates in the design. Figure 2 shows two TLM 2.0 tracing streams in the Simvision Design Browser that are associated with initiator sockets in a DMA block (sc_main.TOP_TB.TOP.dma_0):

Figure 2 – A design with two initiator sockets.

Either during or after simulation, you can send TLM 2.0 tracing streams to the Simvision Waveform viewer to get a quick view of TLM 2.0 activity (Figure 3). For this design there is some activity between 4000 and 9000 ns, but things don’t really get “warmed up” until 10000 ns.

Figure 3 – High Level view of TLM 2.0 tracing activity.

Here’s a typical debugging scenario. You notice a latency in your design and have narrowed it down to activity between 5400 and 6000 ns. To use sctlmrecord to help shine light on the problem, first launch ncsim with –sctlmrecord. At the tcl prompt, immediately turn recording off. That’s right. You don’t want to record transactions until you get to the interesting part of your simulation, which is 5400 ns. Note that any read or write in progress at time 5400 will not be recorded. Only reads and writes that begin after the start time make it into the database. Future versions of Incisive SystemC will support a full command interface for toggling tracing, but in IUS 8.2 you turn tracing off by issuing the following c function call:

ncsim> call sc_tlm_record_off

Next, run to ahead:

ncsim> run 5400 ns

Now you’re ready to go. Turn tracing back on and run until time 6000 ns:

ncsim> call sc_tlm_record_on

ncsim> run 600 ns

When control returns, you’ll be ready to analyze the interesting part of your design – the bottleneck. In my next post, I’ll cover exactly how to do this using Simvision, the database produced by sctlmrecord, and TxE.

George Frazier

Tracing TLM 2.0 Activity In An ESL Design – Part I

georgef — Mon, 23 Mar 2009 15:28:00 GMT

Many design teams that use SystemC are in various stages of evaluating TLM 2.0 – the Open SystemC Initiative’s transaction level library designed for modeling memory-mapped buses and on-chip communication networks. The new standard takes us one step closer to creating an ecosystem where ESL models can interoperate across the boundaries of design teams, IP providers, and tool vendors. TLM 2.0 designs are much faster than equivalent RTL designs. TLM 2.0 processor models often run faster than the actual hardware they’re emulating.

But this doesn’t mean it’s easy to fish out a particular sequence of reads or writes from the ocean of transport calls a simulation session might produce. If you’ve worked with real TLM 2.0 designs, you know that a typical loosely timed model can generate millions of calls between sockets. Consider a virtual platform where a processor can read from a number of memories connected via multiple layers of interconnects. The volume of information – expressed as the set of all data member values of generic payload objects traveling through b_transport(), nb_transport_fw(), and nb_transport_bw() calls – can be formidable. Sure, looking through sequences of TLM 2.0 reads and writes might be easier than making sense of the equivalent RTL-level information, but it’s still like searching for a lost grain of sand – it doesn’t much matter whether you’re at Destin Beach or in the Sahara Desert. Without proper tools you might as well grab a Corona Light and look for an umbrella.

The quickest way to get a sense for what’s happening in the guts of a TLM 2.0 target is to instrument your transport methods with print statements. Almost every TLM 2.0 example I see on the Internet does this. Here’s an example of a simple memory block that reports some data for each successful operation:

#include <systemc>

#include "tlm.h"

void simple_memory::b_transport(tlm_generic_payload& tx, sc_time& dt)

{

tlm_command opcode = tx.get_command();

uint64 addr = tx.get_address();

unsigned length = tx.get_data_length();

unsigned char * data_ptr = tx.get_data_ptr();

wait(10*(length/4), SC_NS);

if (tx.get_byte_enable_length() != 0) {

tx.set_response_status(TLM_BYTE_ENABLE_ERROR_RESPONSE);

return;

}

int strw = tx.get_streaming_width();

int nb_cpy;

if (tx.get_streaming_width() < length) {

nb_cpy = length / strw;

}

else {

nb_cpy = 1;

strw = length;

}

if (nb_cpy*strw != length) {

tx.set_response_status(TLM_BURST_ERROR_RESPONSE);

return;

}

if (addr + strw <= size) {

for(int cpy = 0; cpy < nb_cpy; cpy++) {

if (opcode == TLM_READ_COMMAND) {

memcpy(data_ptr+cpy*strw, &mem_array[addr], strw);

}

if (opcode == TLM_WRITE_COMMAND) {

memcpy(&mem_array[addr], data_ptr+cpy*strw, strw);

for (int i=0; i<strw; i++) {

notify_write_access(addr+i);

}

tx.set_response_status(TLM_OK_RESPONSE);

}

else {

tx.set_response_status(TLM_ADDRESS_ERROR_RESPONSE);

}

if (tx.get_response_status() == TLM_OK_RESPONSE){

if (opcode == TLM_READ_COMMAND) {

std::cout << "Reading " << length <<

" bytes from " addr << std::endl;

}

else {

std::cout << "Writing " << length <<

" bytes from " addr << std::endl;

}

This might be OK for small examples, but you can’t do much with text output. A better approach, though still manual, is to use the SCV transaction recording API to create an SST2 database of memory accesses. SCV transaction recording fits naturally into the TLM 2.0 paradigm. Presuming our simple_memory class has the following members:

scv_tr_stream *m_streamHandle;

scv_tr_generator< > *m_genHandle;

scv_tr_db* m_db;

and some initialization code in the constructor to create the database:

m_db = new scv_tr_db("MemoryDatabase");

we can change our transport routine to write generic payload information to a database. Now our simple_memory class creates a transaction for each successful read or write. It uses scv_tr_handle::record_attribute() to write attribute data to the transaction.

#include <systemc>

#include "scv.h"

#include "tlm.h"

void simple_memory::b_transport

(tlm_generic_payload& tx, sc_time& dt)

{

tlm_command opcode = tx.get_command();

uint64 addr = tx.get_address();

unsigned length = tx.get_data_length();

unsigned char * data_ptr = tx.get_data_ptr();

// Create a transaction stream

// and a transaction generator if they don’t exist

if (!m_genHandle)

{

m_streamHandle =

new scv_tr_stream("MemoryStream",

"TRANSACTOR", m_db);

m_genHandle =

new scv_tr_generator< >("MemoryTx",

*m_streamHandle), "addr", "data");

}

// Get a handle for the new transaction

scv_tr_handle h = m_genHandle->begin_transaction();

wait(10*(length/4), SC_NS);

…

// Write the command type

if (tx.get_response_status() == TLM_OK_RESPONSE){

if (opcode == TLM_READ_COMMAND) {

h.record_attribute("command", "READ");

}

} else {

h.record_attribute("command", "READ");

}

// Write the address and data length

h.record_attribute("addr", addr);

h.record_attribute("length", length);

// End the transaction

h.end_transaction();

}

The resulting SST2 database is better than text, but for complex designs you might end up writing a significant amount of transaction recording code. Unless you add the ability to turn tracing on and off, large designs can slow significantly depending on how much data they produce. Also, this strategy doesn’t capture information about the connectivity of the design. There is no history of where reads and writes initiated or which interconnects they traveled across to reach the memory.

In my next post I’ll cover a new feature in IUS 8.2 that addresses these problems and provides a framework for debugging TLM 2.0 designs. The feature, called sctlmrecord, automatically creates a complete transaction history of generic payload values as they flow through a TLM 2.0 design. You can simulate up to a point of interest in a design and then turn on recording, capturing only the information you need to debug your problem. The database can be viewed in the Simvision Waveform Viewer or Transaction Explorer. You can query it with TxE scripts.

Best of all, you don’t have to write a single line of code to get it to work.

SystemC Save and Restore Part 2 - Advanced Usage

georgef — Mon, 09 Mar 2009 13:00:00 GMT

In my last post I discussed how to use save / restore in the Cadence Incisive Simulator to create checkpoints for designs that contain SystemC. The algorithm for SystemC save / restore is fundamentally different than the algorithm for HDL designs. Although most of the functionality is equivalent between the two styles, there are a few differences.

During restart, all internal variables are restored to their saved values (for example, C variables declared static). While this behavior helps assure that SystemC state information is properly saved and restored, it can also leave variables that reference the process environment (like file descriptor and sockets to other processes) in limbo. To allow control before and after both save and restart, IUS provides the following virtual function definitions:

virtual void start_of_save()

virtual void end_of_save()

virtual void start_of_restore()

virtual void end_of_restore()

These methods are defined for those class definitions that have similar phase callback methods currently defined (for example, start_of_simulation or end_of_simulation).

Here’s a simple example. Class scchild has a thread that writes some data to a log file. If a save operation is performed when the file is open then problems can arise if the program attempts to write to the same file after restore (because the file descriptor associated with the open file will be in a different state after restore). Keep in mind that you could decide to restore this session weeks or months after the original save. The file could be modified or even deleted in that time. Here, in the start_of_restore method, we "fix up" the file by opening it again. Granted, things would be trickier if this was an input file, but you get the idea.

class scchild : public sc_module {

public:

sc_in<sc_logic> in;

SC_CTOR(scchild): in("in") {

SC_THREAD(main);

}

void main() {

int *count = new int;

open_out_log("my_log");

for (*count=0; *count < 10000; (*count)++) {

fprintf(out_log, "*count = %d\n", *count);

wait(10, SC_NS);

}

void start_of_save() {

}

void end_of_save() {

}

void start_of_restore() {

}

void end_of_restore() {

}

void open_out_log(const char *name){

out_log = fopen(name);

}

private:

FILE *out_log;

};

In case you’re wondering why we don’t close the file in start_of_restore, the file descriptor associated with out_log before save is gone after the snapshot is restored. The core save / restore code actually does the close.

SystemC save / restore does not work for designs that contain AMS or simulation sessions that are instrumented with IBM PurifyPlus products. However you can use electric fence for debugging memory violations (ncsc_run –efence).

Finally, while using restart with a saved snapshot, ncsim overwrites any SHM databases that were active before restart. With HDL save / restore, a new trn sequence file is generated for each save and restore operation. Thus if you have probes in your design and do a save followed by 2 restarts:

ncsim> probe -create sctop.es.run -database waves -waveform

ncsim> run 20 ns

ncsim>save –over x

ncsim>run 10 ns

ncsim>restart x

ncsim>run 1000 ns

ncsim>restart x

ncsim>run 10 ns

You’ll get an shm directory that contains the following files:

georgef%ls -1 ncsim.shm

ncsim.dsn

ncsim.trn

ncsim.trn-1

ncsim.trn-2

ncsim.trn-3

ncsim.trn contains the probe activity from time 0 to save, ncsim.trn-1 contains the probe activity from after save to the first restart, ncsim.trn-2 contains the probe activity from after the first restart to the second restart, and ncsim.trn-3 contains the probe activity after the second restart.

Because of the SST2 format, we can’t support this kind of data continuity between restarts with the SystemC approach. After the first restore, the entire database (ncsim.shm and ncsim.trn) will be overwritten.

We have an option for restart, however, that allows you to save data between restores in entirely separate databases. Use the –savedb option to keep a complete history of probe activity in a session with multiple restarts:

ncsim> probe -create sctop.es.run -database waves -waveform

ncsim> run 20 ns

ncsim>save –over x

ncsim>run 10 ns

ncsim>restart –savedb x

ncsim>run 1000 ns

ncsim>restart –savedb x

ncsim>run 10 ns

Now instead of a single ncsim.shm directory you will also have ncsim-1.shm and ncsim-2.shm. Each directory contains data written after restart. Note that no separate directory is created after save (as in HDL save / restore).

If you’re using Incisive SystemC, I hope you’ll give save and restore a try. Let us know what you think if you do.

How to Save OS Boot Time In Your SystemC Virtual Platform With Save and Restore

georgef — Wed, 18 Feb 2009 15:00:00 GMT

One advantage of using a virtual platform or virtual prototype over real hardware for embedded software development and testing is the ability of some simulators to save snapshots of their state. If your processor model is detailed enough, it might take several minutes (or even hours) to simulate booting the OS. If you save a snapshot of your simulation just after you’ve finished booting, each time you want to run your embedded software you can simply restore the snapshot and go. Restarting a snapshot typically takes a few seconds. This can translate into a major productivity gain, especially if you’re running a thousand short software tests on the processor.

Save and restore (or restart) has existed in HDL simulators for years, but things are trickier if SystemC is involved. For one thing, SystemC simulators use external tools for compilation and linking: i.e. gcc. They have more or less a “black box” understanding of global variables, local variables, file descriptors and heap values that make up the simulation state at any point in time. When you throw in multiple threads implemented with application-level threading packages and the fact that C++ heap objects are impractical to save programmatically, it’s easy to see why save and restore tools for HDL simulators can’t be easily extended for SystemC.

Beginning with version 6.2 of the Cadence Incisive Simulator (released in mid-2007), Incisive SystemC has supported the ability to save and restart simulation sessions for designs that include not only SystemC, but any combination of SystemC, VHDL, Verilog, and System Verilog. Currently the capability exists on Linux platforms.

Incisive implements save by storing a snapshot of the simulation state to a file. The state is restored when the saved snapshot file is used to start a new process. To save a snapshot from the command line, use the Tcl save command:ncsim> save saved_snap.

To save a snapshot from Simvision, choose "Save Checkpoint" from the simulation menu:

To restore, you can launch Incisive from the command line with the name of saved snapshot. For example:

georgef% ncsim -input sim.tcl saved_snap

You can also use the Tcl restart command to restore a snapshot if you are using the command line interface (restart is not supported in Simvision, you should use reinvoke instead):

ncsim> restart saved_snap

This saved state is separate from the state of the simulation environment, so you can launch a new session with the saved snapshot and vary simulation parameters by passing different arguments to ncsim. This is a great way to test different scenarios from a known “safe” point before a problem occurs.

There are a few things to keep in mind with SystemC save / restart. During restart, all internal variables inherit the same values from the process as it existed at the time of save (for example, C variables declared static). While this behavior helps assure that SystemC state information is properly saved and restored, it can also leave variables that reference the process environment (like file descriptor and sockets to other processes) in limbo. In my next post I'll show you how to handle these kinds of issues and point out some other things you should be aware of when using SystemC save / restart.