Jump to content
katang

Heartbeat, clock and negedge

Recommended Posts

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?

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...