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> </DIV>
<DIV>It is possible to know, at some point before advancing
the time, if the scheduler
has ended its delta cycles.</DIV>
<DIV> </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
-----------------------------------------------------
|
KMLM List