cycle delay concept

[carter]

...

[Philipp A Hartmann]

In case you've found a solution to your question all by yourself, please consider adding an answer with your findings instead of emptying out your previous post.  This way, all users can benefit in the long run.

Thanks,
  Philipp

[David Black]

'carter' wrote:

----------------------------------------------------------------------

Hi.

 

I have a question.

 

In Verilog, To 1cycle delay for input signal, i using like this.

 

always@(posedge clk1)

begin

 a <= b;

end

 

By the way, is there any like this feature in systemC?

Just use the primitive channel, sc_signal<T>. The sc_signal<T>::write() method uses sc_prim_channel::request_update() to schedule assignments into the update phase of the simulator kernel. Thus:

 

using namespace sc_core;
struct FF
: sc_module
{
  sc_out<int> a;
  sc_in<int>  b;
  sc_in<clk1> clk1;
  SC_HAS_PROCESS(FF);
  FF(sc_module_name instance_name) {
    SC_METHOD(FF_method);
      sensitive << clk1.pos();
  }
  void ff_method(void) {
    a->write(b->read()); // better than a = b; because it reminds of the odd nature of sc_signal::write()
  }
};

NOTE: I never recommend using 'a = b;' notation, because delta cycle delays are always surprising to programmers. I might be convinced if you agree to name all your signals with _signal suffix (e.g. a_signal = b_signal;).

[carter]

Just use the primitive channel, sc_signal<T>. The sc_signal<T>::write() method uses sc_prim_channel::request_update() to schedule assignments into the update phase of the simulator kernel. Thus:

 

using namespace sc_core;
struct FF
: sc_module
{
  sc_out<int> a;
  sc_in<int>  b;
  sc_in<clk1> clk1;
  SC_HAS_PROCESS(FF);
  FF(sc_module_name instance_name) {
    SC_METHOD(FF_method);
      sensitive << clk1.pos();
  }
  void ff_method(void) {
    a->write(b->read()); // better than a = b; because it reminds of the odd nature of sc_signal::write()
  }
};

NOTE: I never recommend using 'a = b;' notation, because delta cycle delays are always surprising to programmers. I might be convinced if you agree to name all your signals with _signal suffix (e.g. a_signal = b_signal;).

Would you please more explain to me about

a->write(b->read()); // better than a = b; because it reminds of the odd nature of sc_signal::write()

Why you recommend?

[David Black]

sc_in<> and sc_out<> are specialized ports that use an sc_signal<> channel. sc_signal<> is a primitive channel that makes use of delta delays and has a somewhat surprizing effect from a programmers view. Witness:

SC_MODULE(Example)
{
  sc_in<int> a, b
  int r1;

  sc_signal<int> r2;

SC_CTOR(Example) { SC_METHOD(method_process); }

void method_process(void)
{
// assume a=1, b=2, r1 = 0, r2 = 0;
r1 = a + b;
r2 = a + b;
std::cout << "r1=" << r1 << " r2=" << r2 << std::endl;
// prints "r1=3 r2=0
}
};

Most programmers would be surprized if not appalled at this behavior. Using explicit write() method reminds us that something special is happening. In languages such as Verilog or VHDL, the second statement would be written:

r2 <= a + b;

which is less surprizing because you see this weird operator <= and are reminded of the non-blocking signal assignment behavior.

 

Note, I don't mind too much the use of plain a and b vs. a->read() and b->read(); however, adding ->read() does remind us of the special nature of these identifiers.

 

On a related topic, you may notice I use the dagger operator (->) rather than the dot operator (.) for port access. This is because sc_in<> and sc_out<> are specialized ports that happen to have read() and write() methods defined (for backwards compatibility with SystemC 1.0 -- does anybody use this?); however, I often encounter designs that use standard sc_port<> where all the channel method calls must use the dagger operator. So I use -> for all SystemC port accesses as a matter of consistency. Note that the specialized port versions of read() and write() simply call ->read() and ->write() anyhow.