sc_time_stamp().value(): bug or feature

[katang]

In my program I define

#define SCTIME_RESOLUTION 10,sc_core::SC_US

and set

    sc_set_time_resolution(SCTIME_RESOLUTION);

The lines are executed

    cerr << sc_time_stamp() << endl;
    cerr << sc_time_stamp().value() << endl;

with the result

150 us
15

Is it bug (rest of the concept change) or feature (with long time support)?

I guess it is the rest of the "default_time_unit"
and is not completely what "time_resolution" means.
For me a default time unit is what I want to see my time results expected in,
and time resolution is what is considered for a delta cycle.
In my case, I want to see the results in msecs, with two decimal digits,
i.e. in steps of 0.01 ms. Is it possible to format it with SystemC?
Especially, to format it with proper fields width for a table?

 

 

[Eyck]

The time resolution is the minimal time step the simulater can advance, not how it is formatted or printed. Internally time is represented as in integer value which you multiply with the time resolution to get the actual time. And BTW, a delta cylce has by definition not time associated.

If you want to format the time appropriately you would want to get this internal time value (sc_time_stamp().value()) and format it accordingly based on the time resolution. Another way would be to use to_seconds() (which returns a double) multiply it with 1000 and fomat it accordingly using the io manipulators

std::cout << std::setprecision(2) << sc_time_stamp().to_seconds()*1000. << " ms"

or the respective printf format string.

Best regards

[katang]

Well, the idea of the time resolution is clear, and it looks like I need to play with C++ formatting to get the result I want.

I took the idea from the 'heartbeat' example, where the !period! defaults in this way  to the time resolution, i.e. the signal (at least conceptually) changes there and back during the delta cycle.