Jump to content

Recommended Posts

Posted

Hi all,

I'm using systemC to build timer model. ( Timer support compares match, overflow, underflow)

//constructor
    SC_METHOD(evaluate_method);
    dont_initialize();
    sensitive << m_evaluate;

    SC_METHOD(update_method);
    dont_initialize();
    sensitive << m_update;
void GTimer::evaluate_method()
{
    //check if compare match
    if(CNT_value == compare_match_value){
         compare_match_handling();
    }
    ...
     m_update.notify((double)period * compare_match_value, time_unit);
}
void GTimer::update_method()
{
    CNT_value = get_counter_value();
    m_evaluate.notify();
}
GT_API unsigned int GTimer::get_counter_value()
{
    unsigned int value;
    sc_time current_time = sc_time_stamp();
    value = (current_time.to_double() - start_time.to_double()) / period;
    return value;
}

Ex:

I set compare_match_value = 2;

period = 1000.0

time_unit = SC_PS

when I start timer and simulate on 2* period

sc_start(2*period ,time_unit)

compare match don't occur. because the time simulate is over but m_update event not trigger.

If I start timer and simulate on 3* period

compare match occur.

Do you have any idea? ( I want to compare match occur when I start timer and simulate on 2*period)

Thank all.

Posted

If you run a simulation until a certain point it time the kernel stops before evaluating the processes at this time point. So if you schedule an event for lets say 100ns and simulate for 100ns then the process being sensitive to this event will not be executed (yet). So this is intended behavior.

BR

Posted
4 hours ago, Eyck said:

If you run a simulation until a certain point it time the kernel stops before evaluating the processes at this time point. So if you schedule an event for lets say 100ns and simulate for 100ns then the process being sensitive to this event will not be executed (yet). So this is intended behavior.

BR

Thank @Eyck

I understand that. Do you have any idea for this problem? How to resolve?

Thanks very much.

Posted
3 hours ago, Philipp A Hartmann said:

You can run the delta cycles at the current time until everything settles:


while( sc_pending_activity_at_current_time() )
  sc_start( SC_ZERO_TIME );

 

Thanks @Philipp A Hartmann

it is OK if I use :

sc_start(2*period,time_unit);
while( sc_pending_activity_at_current_time() )
  sc_start( SC_ZERO_TIME );

But I want to pending in my code. Is it possible?

Posted
27 minutes ago, TRANG said:

But I want to pending in my code. Is it possible?

I don't fully understand the question?  My snippet above runs all remaining delta cycles at the current time without advancing the time any further. You can wrap your original sc_start call with the loop in a small helper function (e.g. sc_start_including_deltas(...) , if you find yourself copying the snippet too often.

Posted
11 minutes ago, Philipp A Hartmann said:

I don't fully understand the question?  My snippet above runs all remaining delta cycles at the current time without advancing the time any further. You can wrap your original sc_start call with the loop in a small helper function (e.g. sc_start_including_deltas(...) , if you find yourself copying the snippet too often.

i try :

void GTimer::end_of_simulation()
{
    while (sc_pending_activity_at_current_time()) {
        sc_start(SC_ZERO_TIME);
    }
}

But It is not true?

My problem is the time simulates is over before trigger event. I want to force trigger event before end simulate.

Posted
7 hours ago, Eyck said:

But what is the issue with running the simulation for 3*period?

Best regards

I'm sorry make you confused.

Summary:

if my test case is:

sc_start(2*period,time_unit);
while (sc_pending_activity_at_current_time()) {
        sc_start(SC_ZERO_TIME);
    }

or

sc_start(3*period,time_unit);

then compare match occur.( is correct)

If my test case is:

sc_start(2*period,time_unit);

then compare match don't occur .

I want to my source code detect when time simulate near the over to pending to execute event m_update before over.

Posted

The match will occur (almost) at the "correct" point in time during the simulation.  However, if you sample the value from an unrelated process, there might be some process evaluation ordering dependency (i.e. whether the update_method had already been run).  It depends on your requirements, whether this might be an issue. 

If you do the checks outside of the simulation, i.e. between sc_start calls, you would need to complete the deltas (as per the loop sketched above) before every check. You cannot call sc_start during end_of_simulation.

Posted
5 hours ago, Philipp A Hartmann said:

The match will occur (almost) at the "correct" point in time during the simulation.  However, if you sample the value from an unrelated process, there might be some process evaluation ordering dependency (i.e. whether the update_method had already been run).  It depends on your requirements, whether this might be an issue. 

If you do the checks outside of the simulation, i.e. between sc_start calls, you would need to complete the deltas (as per the loop sketched above) before every check. You cannot call sc_start during end_of_simulation.

Thank for your support,

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...