RE: Multiple writers to sc_signal

Agreed. I will do as you suggest. I think we are done with this issue.

John A

From:
Bishnupriya Bhattacharya <bpriya@cadence.com>
To:
"john.aynsley@doulos.com" <john.aynsley@doulos.com>
Cc:
P1666 Technical WG <systemc-p1666-technical@eda.org>
Date:
08/11/2010 08:36
Subject:
RE: Multiple writers to sc_signal

John,
 
About non-process writes from sc_main() during simulation, it should be
specified one way or the other in the LRM. I feel it is better to allow it
than to disallow it. You can think of it as depositing/initializing a
signal value between runs as say a command prompt would let you do.
 
About update(), I would be in favor of tightening up the LRM wording such
that signal writes are clearly disallowed.
 
Thanks,
-Bishnupriya
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Friday, November 05, 2010 5:10 AM
To: Bishnupriya Bhattacharya
Cc: john.aynsley@doulos.com; P1666 Technical WG
Subject: RE: Multiple writers to sc_signal

Bishnupriya,

I am ambivalent about allowing non-process writes from sc_main during
simulation. I guess it would allow re-initialization between calls to
sc_start, which could be a good thing.

Regarding update(), update() is forbidden (6.15.6) from messing with the
state of any storage outside of the current primitive channel object. IMHO
it would be very much outside the spirit of sc_prim_channel to allow a
call to write() to another sc_signal, although I don't think the LRM
explicitly disallows this. I would rather close this loophole than allow
write(). It this what you were thinking, or am I on the wrong page?

Thanks,

John A

-----Bishnupriya Bhattacharya <bpriya@cadence.com> wrote: -----
To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>
From: Bishnupriya Bhattacharya <bpriya@cadence.com>
Date: 11/03/2010 02:46AM
Cc: P1666 Technical WG <systemc-p1666-technical@eda.org>
Subject: RE: Multiple writers to sc_signal

John,
 
The first point below is fine. For the second point, a little more is
needed.
 
* Writing to a given signal during elaboration (from any context) is
permitted; neither sc_main nor the callbacks count as drivers

What about non-process writes during simulation? Like from sc_main() after
the first sc_start(), or from the update() phase of a user-defined
channel? IMO all these should be legal. Hangs together by your rationale
also that the result is deterministic since all non-process writes are
single-threaded.
 
Thanks,
-Bishnupriya

From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Wednesday, November 03, 2010 5:24 AM
To: Bishnupriya Bhattacharya
Cc: P1666 Technical WG
Subject: Re: Multiple writers to sc_signal

Bishnupriya,

Re-reading the first point below, it looks like we agreed that we should
clarify the wording of the LRM to the effect that:

* Writing to a given signal from multiple processes is illegal (subject to
any further enhancements we may make)
* Writing to a given signal during elaboration (from any context) is
permitted; neither sc_main nor the callbacks count as drivers

Does that still work for you?

John A

-----owner-systemc-p1666-technical@eda.org wrote: -----
To: bpriya@cadence.com, systemc-p1666-technical@eda.org
From: john.aynsley@doulos.com
Sent by: owner-systemc-p1666-technical@eda.org
Date: 11/02/2010 04:09PM
Subject: Multiple writers to sc_signal

Bishnupriya, All,

Next on the list is the issue of multiple writers to sc_signal.

As a reminder, I include some historical notes below.

John A

[BB] 6.4.4 The LRM states that it is an error for multiple processes to
write to an sc_signal. The LRM also says it is ok to write to a sc_signal
during elaboration in order to initialize it. The category of writes that
the LRM does not specify are mainly those coming from sc_main and from
other unusual places, like phase callbacks (e.g, start_of_simulation), a
channel's update phase etc. This can all be generalized under the umbrella
of writing to a signal from a non-process context (the current process is
0). We think extrapolating what the LRM says, all such writes to a signal
can be considered ok, and do not contribute as a driver. It seem
reasonable to have a consistent rule like sc_main (generally, any
non-process context) never counts as a writer when writing to a signal.

  [JA] My take on it is that the LRM is explicit that sc_signal::write()
calls request_update(), that update() changes the value and notifies an
event. Moreover, request_update() can be called during elaboration (it is
explicitly allowed in the callbacks). When multiple writes() are made in
the same phase, the most recent write() wins. Writes from multiple
processes instances are forbidden, the (implicit, unstated) reason being
that the behaviour would be non-deterministic. Writes from outside
processes are permitted, the (implicit, unstated) reason being that the
behavior would be deterministic (because elaboration is single-threaded).
I think that hangs together?

  However, I don't think there is a strong reason to change the OSCI
simulator. Old code should still work (because the OSCI sim supports many
deprecated features). New code should comply with 1666 (whether or not a
tool implements the checks properly). In time, the OSCI sim may get
changed to be less tolerant of legacy code.

  [AG] The existing simulator ignores initializations by sc_main if they
occur before any process writes, but reports an error if sc_main tries to
change a value that has been written by the process. I think I should just
fix things to ignore writes out of the simulator's purview, e.g. by
sc_main.
 
  [BB/JA] Need an LRM clarification to that effect

[BB] 6.4.4 The LRM clearly states that having multiple processes write
to a sc_signal is an error. In the refsim, the implementation is somewhat
flaky. The multiple writer check is performed only if the DEBUG_SYSTEMC
macro is defined and is liable to break for pre-defined signals like
sc_signal<bool> etc., if the systemc library is not compiled with
DEBUG_SYSTEMC defined. It would be nice to have a cleaner solution.
 
From user experience, it turns out that people hardly ever have
DEBUG_SYSTEMC on, and are often surprised in the case that DEBUG_SYSTEMC
is on, and the check reports an error. It is not uncommon for a model to
use to two different processes that write to the same signal in a mutually
exclusive fashion, e.g., at the posedge and negedge of a clock,
respectively. People expect such models to work and are surprised that the
check rejects this.
 
In view of all of the above, in the past, Stuart has proposed that this
fact be made explicit in the signal declaration by adding a second
template parameter to sc_signal that specifies if multiple writers are ok
or not, with the default value being not ok. I'm trying out an
implementation at my end that explores this option.

enum sc_multiple_sig_writers_policy {
  SC_MULTIPLE_WRITERS_NOT_OK, // default
  SC_MULTIPLE_WRITERS_OK
};

template <class T,sc_multiple_sig_writers_policy POL =
SC_MULTIPLE_WRITERS_NOT_OK>
class sc_signal { ... };

If the template parameter value is SC_MULTIPLE_WRITERS_NOT_OK, then
sc_signal::write() checks for multiple writers and reports an error if
more than one process writes to it. This check always happens irrespective
of the DEBUG_SYSTEMC flag.

If the template parameter value is SC_MULTIPLE_WRITERS_OK, then
sc_signal::write() allows multiple writers and the last one wins.

This is the basic proposal for sc_signal. Typically, users won't bother
with the second template parameter, and by default it would perform the
check, thus being LRM compliant. In the cases where users do want to have
the convenience of multiple writers, they can specify the second template
parameter value to be SC_MULTIPLE_WRITERS_OK.
 
A related topic is for IP vendors writing a module with output ports -
these output ports will be bound to signals externally and is not
controlled by the IP vendor. However, the IP vendor may also choose to
have the convenience of using multiple processes to write to an output
port, in which case it will be an error if the sc_signal bound to that
port does not allow multiple writers. There should then be a way for an IP
vendor to specify that you can only connect a sc_signal that allows
multiple writers to this output port. This is similar to the concept of
the sc_out_resolved port, which can only be bound to a sc_signal_resolved.
The port proposal is

template <class T> class sc_out_mw : public sc_out<T> { ... };

template <class T> class sc_inout_mw : public sc_inout<T> { ... };

Such a port cannot be bound to a resolved signal (sc_signal_resolved or
sc_signal_rv) because it is inconsistent for the port to say I've multiple
processes writing to me and the last one wins, and at the same time ask
for resolution

Such a port cannot be bound to a sc_signal<T,SC_MULTIPLE_WRITERS_NOT_OK>
because it will generate a run time error due to multiple processes
writing to the signal via the port

Such a port can only be bound to a sc_signal<T,SC_MULTIPLE_WRITERS_OK>
In its end_of_elaboration, this port type will check that it is bound to
the correct type of sc_signal

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.