Method Process

[manikanta.mashetti]

Hello, 

 

In system C, A method is called when ever the event in the sensitivity list changes. Like always block in Verilog. Triggering event in sensitive list can be either edge sensitive or level sensitive.

 

But at the same simulation time, more than one signal in the sensitivity list changes then that method will be triggered more than once, so at the same simulation time  the method is executed more no of times, where as in verilog always block after all signals finalized it enters in to the block, how will I overcome this problem in systemC.

 

Eg:   SC_METHOD(writing_to_memory);

          sensitive<<data<<address<<rst;

    

           void  writing_to_memory()

            {

              -----

              -----

            }

 

            In the above example at the simulation time of 100ns, data is changed, and address also changed so the method will be called twice and executed twice..But I don't want this type of bahaviour how will implement..

 

please help me...

thank you..

[apfitch]

Hi,

 

the behaviour of SC_METHODs is the same as for Verilog always blocks (note 1).

 

If you see the SC_METHOD process executing twice, the changes on the signals must be happening on different deltas, which is the same behaviour as you'd get in Verilog. You need to re-write your code so that the signals you are sensitive to change on the same delta.

 

To confirm what's happening, you can print out sc_delta_count() from within the process to see on which deltas it is called,

 

kind regards

Alan

 

(note 1) except at initialization; unless you're using SV always_comb in which case it really is the same even at initialization.

[manikanta.mashetti]

thank you for your reply,

 

I am the beginner to system C,

 

what is delta ?

 

can you give me the hint how to rewrite the code, so that the signals that are sensitive to change on the same delta ?

[apfitch]

There's a tutorial on the Doulos website http://www.doulos.com/knowhow/systemc/tutorial/ which talks about deltas in the last section.

 

The traditional way around problems with deltas is synchronous design, i.e. make sure all outputs are assigned as the result of a clock edge, and sample the inputs on a clock edge.  Then the timing depends only on the clock, and not on the delays or deltas of individual signals.

 

In the code you have shown you do not have a clock.

 

Of course it depends if you are modelling hardware. If you are modelling software, you may have to follow a different approach.

 

regards

Alan

[manikanta.mashetti]

Thanks for reply,

 

Actually I am modelling a processor using system C,

 

In this in the ALU (execute stage), one method is there in that depending on the signals coming from the decode stage it triggers, in this case I should  signals in the sensitivity list(other than clock), so here only  I am getting the problem. It triggers more no of times at a same simulation time.

 

And I checked with sc_delta_count(), at same simulation time it is giving two count values. How will I resolve this. 

[dakupoto]

There's a tutorial on the Doulos website http://www.doulos.com/knowhow/systemc/tutorial/ which talks about deltas in the last section.

 

The traditional way around problems with deltas is synchronous design, i.e. make sure all outputs are assigned as the result of a clock edge, and sample the inputs on a clock edge.  Then the timing depends only on the clock, and not on the delays or deltas of individual signals.

 

In the code you have shown you do not have a clock.

 

Of course it depends if you are modelling hardware. If you are modelling software, you may have to follow a different approach.

 

regards

Alan

 

Dear Sir,

Ir is not always possible to have a clock - consider pure combinational logic circuits.

In this case, the output is synchronized to each of the inputs, and the output changes

if ANY of the inputs change. 

[David Black]

When dealing with pure combinational circuits, the behavior of SystemC is completely reasonable. Usually with pure combinational signals, timing issues prevent signals from arriving at the same time, so the issues of multiple delta cycles is actually an artifact of modeling in the absence of real timing information. It is also the case with pure combinational signals that re-executing a method would not be a problem other than the slight overhead it incurs.

 

One small issue does remain however... in the current model SystemC model, there is nowhere to identify the final resolved value of a variable as it leaves a timeslot (i.e. after the last delta cycle of a given time). This notion is covered in Verilog with the 'postponed' timing region. Implementation of similar concept is currently under investigation by the SystemC language working group within Accellera. This does not affect most users of SystemC, since the primary use of SystemC is at the architectural level rather than RTL and other low level modeling.

 

This is all carefully spelled out in section 5 (esp. 5.2.1) of the IEEE 1666-2011 standard, which any serious SystemC user should take time to understand.

 

I observe that students at universities are most likely to see this issue because they view SystemC as an inexpensive (i.e. free) RTL/circuit simulator with a low learning curve (ie. C++), which SystemC is not designed for. Verilog or VHDL are more appropriate for those activities. SystemC can suffice if you are willing to put up with these small limitations.

[apfitch]

Hi Manikanta,

   Unfortunately there's no easy way round this. One solution is to figure out which signal changes first and remove that from the sensitivity list. So for instance if data changes before address, take data out of the sensitivity list and leave address in. However that's not a very easy to use solution as you have to work out which signal changes first. And later changes may break your code.

 

Assuming your model is "just a model" i.e. not for synthesis, you could trigger an event shortly after address and data have changed. So suppose address and data are assigned somewhere in your design. You can create a delayed event based on address. E.g.

sc_event e;

void memory_needs_updating() {
   e.notify(1, SC_NS);
}
    
void  writing_to_memory()
{
         -----
              -----
}

SC_CTOR .... {
    SC_METHOD(memory_needs_updating);
    sensitive << address;  // doesn't matter which one as they both change on the same delta

  SC_METHOD(writing_to_memory);   // now runs 1 ns after address/data change
    sensitive << e;
    
}

What you're doing is manually scheduling the order of operations in your processor model. So you could have a fetch event, a decode event, an execute event and trigger them one after the other.

 

I'm sure they are other ways of doing it (like using a clock!)

 

kind regards

Alan

[dakupoto]

When dealing with pure combinational circuits, the behavior of SystemC is completely reasonable. Usually with pure combinational signals, timing issues prevent signals from arriving at the same time, so the issues of multiple delta cycles is actually an artifact of modeling in the absence of real timing information. It is also the case with pure combinational signals that re-executing a method would not be a problem other than the slight overhead it incurs.

 

One small issue does remain however... in the current model SystemC model, there is nowhere to identify the final resolved value of a variable as it leaves a timeslot (i.e. after the last delta cycle of a given time). This notion is covered in Verilog with the 'postponed' timing region. Implementation of similar concept is currently under investigation by the SystemC language working group within Accellera. This does not affect most users of SystemC, since the primary use of SystemC is at the architectural level rather than RTL and other low level modeling.

 

This is all carefully spelled out in section 5 (esp. 5.2.1) of the IEEE 1666-2011 standard, which any serious SystemC user should take time to understand.

 

I observe that students at universities are most likely to see this issue because they view SystemC as an inexpensive (i.e. free) RTL/circuit simulator with a low learning curve (ie. C++), which SystemC is not designed for. Verilog or VHDL are more appropriate for those activities. SystemC can suffice if you are willing to put up with these small limitations.

Dear Sir,

Unfortunately high level tools as SystemC linearize and abstract

out almost all of a typical circuit's physical characteristics and

therefore the resulting simulation just provides a brief overview

of circuit behavior - there is NO information on perfromance

characteristics. For performance characteristics, one has to

depend on good old SPICE.

An inteeligent student should recognize this issue, or his/her

instructor should point it out.  

[David Black]

SystemC was never intended for such low-level modeling anyhow. It can be used to model RTL, but SystemC is not the best option. Choosing it because it is "free" doesn't make it the right choice. If you need SPICE level modeling, then use SPICE. If you want System Level Modeling, then SystemC is a decent choice. I use SystemC for modeling -ABOVE- RTL level.

[Gurmeet Singh Taank]

As long it is storing the right data in the memory  you want to model; this behavior should be fine. If this would have been a purely asynchronous ram hardware this must have happened in the actaul hardware as well since it is imposible to align the edges of two indepedent buses(data and address here) below some practical limits of few pico seconds(however the first write may not settle properly in actual hardware). System-C is not for low level modeling, you should use it for modeling above the RTL level.If you still want to avoid this, one way would be to combine two different buses into single bus(say common_bus) and make the SC_METHOD sensitive to it.

common_bus = {data,address}

Regards,

Gurmeet