Skip Nav
Home » Forums » SystemC Forum

Icon - KMLM List KMLM List

View email archives for the history of this mailing list.

List Home All Archives Dates Threads Authors Subjects
systemc-forum - [Systemc-forum] Re: delta cycles Message Thread: Previous | Next
  • To: systemc-forum@xxxxxxxxxxx
  • From: Fernando Herrera Casanueva <fherrera@xxxxxxxxxxxxxxx>
  • Date: Wed, 26 May 2004 19:29:20 +0200
Send Email to systemc-forum@osci.kavi.com:
Send new message
Reply to this message
Sudhanshu CHADHA wrote:


Hi Fernando
Thanx for the update
I want to know what does num_deltas correspond to
Is num_deltas equal to number of delta cycles in until one time step advances

Yes it is. It is a variable (not available to the user) that is included when you
compile the SystemC library by defining the DEBUG_SYSTEMC macro.


Its usage it is just to rise a warning when the number of delta cycles at certain
time stamp reach SC_MAX_NUM_DELTA_CYCLES, another value that it can be
found in the sources of the SystemC library (sc_constants.h). With a reasonable
value (10000 in the library), you can locate "points" with typical design bugs
(as combinational loops), although that does not necessarily mean that the code
to be wrong.


Be aware that this option has to be carefully used, since, apart from the warning,
a break of the deltas cycles loop at that time stamp is forced (although not the end
of simulation, that can go on till next scheduled timed notification). Therefore,
the behaviour observed would change respect to the specfication compiled without
DEBUG_SYSTEMC macro defined (default configuration).


In a post of 24/5/2004 of "delta count OK?" thread you can find the version of crunch
I posted. There you see that I print this value, together the m_delta_count, which
would account absolute delta count (althoug from "delta count OK?" thread we
have seen this is not clear yet) and would be accessed by the user by means of
delta_count() method of sc_simcontext class. This print is done just before delta
notification phase.



If yes then it should show the num of deltas and not reset again to 0 before the time changes
and it should not be reset to 0 inside the crunch) loop but reset only when time advances

From what I told in the previous paragraph we have:

* m_delta_count (returned by means of delta_count() method):
               Accounts absolute number of deltas

(but expecting the "polemic" of "delta count OK?" thread to be solved :-D )

* num_deltas (internal variable, not accessable by user):
Accounts number of deltas at each time stamp (thus, it requires a reset at each crunch entrance)


The loop of the sucesive delta iterations of a time stamp is contained in the
crunch function, so the reset of num deltas is done, although inside the crunch() method,
outside the delta iteration loop . Once out of this loop, either a time advance is given or
simulation is finished. No more deltas corresponding to the current time will happen.



Best Rgds Sudhanshu

I hope I solved something,

Best regards


Message: 1
Date: Tue, 25 May 2004 00:00:47 +0200
From: Fernando Herrera Casanueva <fherrera@xxxxxxxxxxxxxxx>
To: systemc-forum@xxxxxxxxxxx
Subject: Re: [Systemc-forum] Re: delta cycles

Hi sudhanshu,

I think there are several reason because you got confused.

To see one of it, I suggest you to have a look to the recent
"delta_counts_OK" discussion thread. There I argue that
delta_count() method has a bug. For me this is an important
method. Probably also for you, since as I mentioned you I do
not find a way to Know when a delta is the last one of certain
time.

I had the chance to check your code. Efectively I also obtain
the same results with the current release.

If I use the fix I provide in the "delta_counts_OK"  discussion
thread I obtain:

start P1
A P1: DELTA_COUNT: 1time0
B P1: DELTA_COUNT: 1time0
start P2
A P2: DELTA_COUNT: 1time0
DELTA CYCLE EXECUTED:    m_delta_count=1 num_deltas= 1
C P1: DELTA_COUNT: 2time0
start P1
A P1: DELTA_COUNT: 2time0
B P1: DELTA_COUNT: 2time0
B P2: DELTA_COUNT: 2time0
start P2
A P2: DELTA_COUNT: 2time0
DELTA CYCLE EXECUTED:    m_delta_count=2 num_deltas= 2
DELTA CYCLE EXECUTED:    m_delta_count=3 num_deltas= 1
DELTA CYCLE EXECUTED:    m_delta_count=4 num_deltas= 1
C P1: DELTA_COUNT: 5time1
start P1
A P1: DELTA_COUNT: 5time1
B P1: DELTA_COUNT: 5time1
B P2: DELTA_COUNT: 5time1
start P2
A P2: DELTA_COUNT: 5time1
DELTA CYCLE EXECUTED:    m_delta_count=5 num_deltas= 2
DELTA CYCLE EXECUTED:    m_delta_count=6 num_deltas= 1
DELTA CYCLE EXECUTED:    m_delta_count=7 num_deltas= 1
C P1: DELTA_COUNT: 8time2
start P1
..

Before just commenting you how the example and the delta_count()
method performs I would like to Know if , maybe, this is closer to
what you thought about delta_count() method. :-) if you still have
doubts about do not hesitate to tell me about.

Please be aware also that this could be a confusing example. This is
because the example has 2 indeterminism sources. Therefore,
the delta count (although, I think, correct when it includes the fix)
could vary from one simulator implementation to other.
More than that, if you change the order of SC_THREAD declarations
in the constructor you will appreciate the difference, obtaining
these results (using my modified crunch() method):

start P2
A P2: DELTA_COUNT: 1time0
start P1
A P1: DELTA_COUNT: 1time0
B P1: DELTA_COUNT: 1time0
B P2: DELTA_COUNT: 1time0
start P2
A P2: DELTA_COUNT: 1time0
DELTA CYCLE EXECUTED:    m_delta_count=1 num_deltas= 1
C P1: DELTA_COUNT: 2time0
start P1
A P1: DELTA_COUNT: 2time0
B P1: DELTA_COUNT: 2time0
B P2: DELTA_COUNT: 2time0
start P2
A P2: DELTA_COUNT: 2time0
DELTA CYCLE EXECUTED:    m_delta_count=2 num_deltas= 2
DELTA CYCLE EXECUTED:    m_delta_count=3 num_deltas= 1
DELTA CYCLE EXECUTED:    m_delta_count=4 num_deltas= 1
C P1: DELTA_COUNT: 5time1
start P1
A P1: DELTA_COUNT: 5time1
B P1: DELTA_COUNT: 5time1
B P2: DELTA_COUNT: 5time1
start P2
A P2: DELTA_COUNT: 5time1
DELTA CYCLE EXECUTED:    m_delta_count=5 num_deltas= 2
DELTA CYCLE EXECUTED:    m_delta_count=6 num_deltas= 1
DELTA CYCLE EXECUTED:    m_delta_count=7 num_deltas= 1
C P1: DELTA_COUNT: 8time2
start P1
A P1: DELTA_COUNT: 8time2
B P1: DELTA_COUNT: 8time2
B P2: DELTA_COUNT: 8time2
start P2
..

Do you see the difference? indeterminism can drive to a different
number of deltas executed. In the second case, the simulator
chooses to start first P2 so the immediate event did not get lost
(as it happens in the first case).
Notice that SystemC does not specifies how this scheduling must be
done, so different implementations of simulator will have different
event counts (and even with the same OSCI simulator in this case if
we change the order of declaration!!!)

So the clear indeterminism source here is the immediate
notification. I think this is also warned in the user guide.

The 2nd indeterminism source I find in the example is more tricky.
Processes start to run at 0 time once sc_start is called and do it till
all of them  reach a wait() or the end of process methods. At the same
time the clock you specified provokes a positive edge event at 0 time
(pos. edge at first and 0 start time are values on default if you do not
specify another thing). How to know which goes first, the clock event
or processes without dont_initialize() clauses? If had a look
of the sc_clock implementation, it seems that these events are scheduled
for the second delta (in the constructor, a delayed notification is done,
that is like notify(SC_ZERO_TIME) ). This would explain that processes
without don_initialize come first. However, I did not see anything
specifying this in the LRM, therefore this could be open to each
simulator implementation.

I think that the examples I provide in the "delta_counts_OK"  discussion
are deterministic, that is because I told there that I cannot admit for then
ambiguity in delta_count() function result among different simulators
(apart from the fact of the resulting figure being correct or not).

I hope to be helpful, do not hesitate on commenting or even asking me
about this in this example, I also thank any comment, critic, etc...
about

regards!

nando.

Sudhanshu CHADHA wrote:



HI Fernando
I have also got very confused in terms how systemc processes delta count
Any suggestions are welcome
consider the simulation

#include <systemc.h>
#include <systemc/datatypes/bit/sc_logic.h>
//sc_event AVALID_event; class Master : public sc_module {
public:
sc_in<bool> clk;


SC_HAS_PROCESS(Master);
Master(sc_module_name nm)
{
SC_THREAD(P1);
sensitive_pos << clk;
SC_THREAD(P2);
}
void P1() {
while(1)
{ cout<<"start P1"<<endl;
cout<<"A P1: DELTA_COUNT: " <<sc_get_curr_simcontext()->delta_count() << "time"<<sc_simulation_time() << endl ;
e1.notify();
cout<<"B P1: DELTA_COUNT: " <<sc_get_curr_simcontext()->delta_count() << "time"<<sc_simulation_time() << endl ;
wait();
cout<<"C P1: DELTA_COUNT: " <<sc_get_curr_simcontext()->delta_count() << "time"<<sc_simulation_time()<< endl ;
}
} void P2() {
while(1)
{
cout<<"start P2"<<endl;
cout<<"A P2: DELTA_COUNT: " <<sc_get_curr_simcontext()->delta_count() << "time"<<sc_simulation_time() << endl;
wait(e1);
cout<<"B P2: DELTA_COUNT: " <<sc_get_curr_simcontext()->delta_count() << "time"<<sc_simulation_time() << endl;
}
}
private:
sc_event e1;
};


class sctop : public sc_module {
public:
sctop(sc_module_name nm) : sc_module(nm),clk("clk", 1),master1("master1")
{
master1.clk(clk);
}


~sctop(){
} protected:
sc_clock clk;
Master master1;
};


This gives the followng results
start P1
A P1: DELTA_COUNT: 1time0
B P1: DELTA_COUNT: 1time0
start P2
A P2: DELTA_COUNT: 1time0
C P1: DELTA_COUNT: 2time0
start P1
A P1: DELTA_COUNT: 2time0
B P1: DELTA_COUNT: 2time0
B P2: DELTA_COUNT: 2time0
start P2
A P2: DELTA_COUNT: 2time0
C P1: DELTA_COUNT: 7time1
start P1
A P1: DELTA_COUNT: 7time1
B P1: DELTA_COUNT: 7time1
B P2: DELTA_COUNT: 7time1
start P2
A P2: DELTA_COUNT: 7time1
C P1: DELTA_COUNT: 12time2
start P1
i wonder how does the delta count processes itself
Rgds
Sudhanshu
Fernando Herrera Casanueva wrote:



Hi,

I really do not Know such a function, but what it is more, in with point of the SystemC code
do you intend to use such a function as "bool more_deltas_in_this_time_stamp()". I mean, I
find no place in call such a function, except perhaps for the update() code of a SC primitive
channel. Could you give me another example?


However, even in this case, a FALSE return value of this function could never be absolute,
since in the rest of this update() call (or in the rest of update function requested for the current
delta, but not executed yet), a notify(SC_ZERO_TIME) could still be done provoking a new delta
for the current time. Once this is done, the more_deltas_in_this_time_stamp() hypothetic
function should return true if it were called immediately after that notify.


The only way I gess to obtain an absolute meaning is just enabling an assert (probably by using
try-catch) in such a way that a user function could be executed within the simulation loop, just
between the crunch() call and the time-advance + timed notifications loop of the simulate
method of sc_simcontext class (i.e. in 497 line of sc_simcontext.cpp in 2.0.1 source). It seems
that it is assumed that one cannot predict if there will be or not a new delta, at least in an
absolute way (do you agree?). Notice also that this would be controled at the code of simulation
control rather in a process or channel code.


As far as I Know, SystemC does not provide such a function, thus, at each update() or code execution,
the only thing you can Know is which delta you are in (delta_count() method). (As you probably saw
I opened another disscusion thread about that some days ago).


I hope to clear something, any feedback is wellcome :-)

regards


Sudhanshu CHADHA wrote:



Hi
U can have a look at systemc phases of scheduler on Page 23of Funcspecs
It has the following phases
initialization phase
evaluation phase
Update phase
Delayed notification phase
then it advances the simulation time
then it determines which processese to run due to events that have pending notification at the current time


and this cycle repeats

Best Rgds
Sudhanshu


systemc-forum-request@xxxxxxxxxxxxxxxxxxx wrote:



Send Systemc-forum mailing list submissions to
   systemc-forum@xxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
   https://server2.systemc.org/mailman/listinfo/systemc-forum
or, via email, send a message with subject or body 'help' to
   systemc-forum-request@xxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
   systemc-forum-admin@xxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Systemc-forum digest..."


Today's Topics:

 1. delta cycles (bouchhima faouzi)

-- __--__--

Message: 1
Date: Tue, 18 May 2004 20:10:15 -0400 (EDT)
From: bouchhima faouzi <faouzibouch@xxxxxxxx>
To: systemc-forum@xxxxxxxxxxxxxxxxxxx
Subject: [Systemc-forum] delta cycles

--0-2142934676-1084925415=:76027
Content-Type: text/plain; charset=us-ascii

Hi,

It is possible to know, at some point before advancing the time, if the scheduler has ended its delta cycles.

regards,
Faouzi



---------------------------------
Post your free ad now! Yahoo! Canada Personals

--0-2142934676-1084925415=:76027
Content-Type: text/html; charset=us-ascii

<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV>It is possible to know, at some point&nbsp;before advancing the time,&nbsp;&nbsp;if&nbsp;&nbsp;the scheduler has&nbsp;ended&nbsp; its delta cycles.</DIV>
<DIV>&nbsp;</DIV>
<DIV>regards,</DIV>
<DIV>Faouzi</DIV><p><br><hr size=1>Post your free ad now! <a href="http://ca.personals.yahoo.com/";><b>Yahoo! Canada Personals</b></a><br>
--0-2142934676-1084925415=:76027--




-- __--__--

_______________________________________________
Systemc-forum mailing list
Systemc-forum@xxxxxxxxxxxxxxxxxxx
https://server2.systemc.org/mailman/listinfo/systemc-forum


End of Systemc-forum Digest




_______________________________________________
Systemc-forum mailing list
Systemc-forum@xxxxxxxxxxxxxxxxxxx
https://server2.systemc.org/mailman/listinfo/systemc-forum















--
-----------------------------------------------------
Fernando Herrera
Microelectronics Engineering Group
E.T.S.I.Industriales y Telecom. TEISA Dpt.
University of Cantabria
Avda. Los Castros s/n, 39005
Santander, Spain
   fherrera@xxxxxxxxxxxxxxx
   Tel. +34 942 200878
   Fax. +34 942 201873
-----------------------------------------------------






By Date: Previous | Next Current Thread By Thread: Previous | Next
  • [Systemc-forum] Re: delta cycles, Fernando Herrera Casanueva  (you are here)

  Mail converted by the most-excellent MHonArc 2.6.10