Heartbeat, clock and negedge

[katang]

I have found in the examples of the SCFTGU book examples

"a  heartbeat function similar to a clock except it is more efficient than an sc_signal<bool>."

It is used in one of the examples of the next chapter, but not at all in later examples, like the ones appended to 2.3.3.

Is there any specific reason of it?

Also, if defines only  posedge_event() ;

Can it be used in the simple_bus example, where negedge is also used?

 

[David Black]

You can use it however you like. We didn't use it everywhere and I'm sure there are more areas where it might be applicable. The main point is that "Performance is a function of simulator CPU activity and how well it used." In some cases such as clocks, there is a lot of activity that goes unused. Many designs really only use the positive edge of the clock. In some designs, the activity can even be reduced significantly.

Another instance is timers that often are only touched when they are set up and timeout after N clocks. The RTL approach to modeling a timer decrements the timer value on every clock. A behavioral approach would be:

void set_timer( int N ) {
  assert( N > 0 );
  delay = N * clock.period();
  setup_time = sc_time_stamp();
  projected_time = setup_time + delay;
  timeout_event.notify( delay );
}

 The current value of the timer can always be had with:

int get_timer_value( void ) {
  return ( projected_time - sc_time_stamp() ) % clock.period() );
}

So you really don't even need the clock in many instances. Instead replace clock.period() with a simple constant.

Fast and smart SystemC models don't use sc_clock at all.

[dilawar]

Thank you for this. Are there any list of guidelines you would suggest for improving simulation performance?

[David Black]

No specific guidelines or cookbooks; however, it is really quite straightforward to think about. First, you need to think about contributors to slow down. Some of the worst are:

1. I/O - for example printing out values every time something changes. During debug this may be helpful, but once it's working drop the messaging. Use SC_REPORT_INFO_VERB with appropriate verbosities (e.g. DEBUG).
2. Context switching - every call to wait() implies a context switch. This also applies to returns from SC_METHODs.

Second, when you have working code, you need to do code profiling to see where time is being spent. Then think about how to reduce it.

Common mistakes:

1. Coding at too low a level of abstraction - NO RTL please
2. Trying to outwit the compiler with "more efficient coding"
3. Using C rather than C++ techniques (e.g. implementing a linked list rather than using appropriate STL containers)
4. Preferring SC_METHOD over SC_THREAD because of the myth that it will be faster (and wasting a lot of coding time doing it)
5. Using sc_clock