Jump to content

The conceptual behavior of sc_in<>


katang

Recommended Posts

I want to simulate a module, the input signal of which changes externally. In the object I have a port

    sc_in<int> Address;

and in the constructor I have

   SC_THREAD(InputChanged);
   sensitive <<Address;
   dont_initialize();

and the method is

void XXX::
InputChanged(void){
    wait(SC_ZERO_TIME); // Be sure value asserted
    cerr << '@' << sc_time_stamp() << '  ' << Address<< endl;
}

In my testbench file I have
 

  sc_signal<int> Address;

...

    XXX->Address(Address);

...

    testbench_i->Address = 12;
    ...
    wait(150,SC_US);

This latter instruction triggers execution of InputChanged, as I wanted. However, if I write out the value of the signal, it prints out the old value, until I precede it with a  ' wait(SC_ZERO_TIME);' My questions:

1) at this point, the method is triggered signaling that the value of the input has changed, but reading the value results in the old value. How is it conceptually? (I understand that the effect of writing needs time, so it happens at the end of the delta cycle. But, why triggering of the member occurs earlier, immediately, and specially not synchronized with the change of the value? I myself expected to put ' wait(SC_ZERO_TIME);' after writing the signal, and that InputChanged() is triggered only after that.)

2) To circumvent the problem I used ' wait(SC_ZERO_TIME);' Is it acceptable, or I shall use some rise-time instead? Any better idea? (It is something like a noisy ADC, so reading the exact value is not so critical)

3) May it raise issues that I use SC_THREAD (beause of the wait()), triggered multiple times,  rather than SC_METHOD

 

Link to comment
Share on other sites

Simulation semantics is described in SystemC standard, paragraph 4.2 Simulation.  sc_signal is particular kind of primitive channel, it's value is updated in Update phase.

 

You don't need to wait for delta cycle in your SC_THREAD. Most likely your signal value changes multiple times, but you catch only first change (the one you don't expect).

Try to rewrite your thread with with inifinite loop to catch all signal change events:

void XXX::InputChanged() {
  while (1) {
    cerr << '@' << sc_time_stamp() << '  ' << Address<< endl;
  }
}

 

Link to comment
Share on other sites

In the case Roman described you need to declare InputChanged as SC_METHOD. Otherwise your simulation time won't progress.

If you want/need to stick with SC_THREAD you would want to write something:

void XXX::InputChanged() {
  while (1) {
    wait(); // wait for the events in the sensitivity list. For explicit wait use wait(Address.default_event())
    cerr << '@' << sc_time_stamp() << '  ' << Address<< endl;
  }
}

Best regards

Link to comment
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...