RE: Multiple writers to sc_signal

All,

I believe it should be ok to allow multiple writes prior to start of simulation. It sure makes the initialization process a little easier.

I'm not sure how much it makes sense to allow multiple writes during simulation.

Best regards,

Tor Jeremiassen

---
Tor Jeremiassen, Ph.D.
Simulation and Modeling CTO
SDO Foundational Tools
Texas Instruments                    Ph:    281 274 3483
P.O. Box 1443, MS 730                Fax:   281 274 2703
Houston, TX 77251-1443               Email: tor@ti.com<mailto:tor@ti.com>
________________________________
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Stuart Swan
Sent: Friday, November 05, 2010 2:58 PM
To: john.aynsley@doulos.com
Cc: P1666 Technical WG
Subject: RE: Multiple writers to sc_signal
All-
I may be coming late to this discussion, and I may have missed some prior discussion
on this, but my personal opinion is:
- It is OK to try to tighten up the LRM wrt the semantics of writes to unresolved signals
during elaboration, phase callbacks, etc.
- Many years ago (I think it was around the time of SystemC 2.0.1), we spent a fair amount of time
discussing adding a way to add "last writer wins" option to sc_signal.  This is in fact what users get
on the osci simulator with DEBUG_SYSTEMC off, but it is most likely a user error if this "feature" is used.
After a lot of discussion, we concluded that there was no relatively easy/clean way to add this feature
into the LRM, and we gave up on it.  My opinion is that there is neither the time nor the interest right
now to pursue this.
Thanks
Stuart
From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com]
Sent: Thursday, November 04, 2010 4:30 PM
To: john.aynsley@doulos.com; Stuart Swan
Cc: P1666 Technical WG
Subject: Re: Multiple writers to sc_signal
Bishnupriya, Stuart, All,
In the past, Cadence made a proposal to add an sc_multiple_sig_writers_policy as a template parameter to sc_signal (see below). Do you, Bisnupriya and/or Stuart, still wish to champion this proposal? Do others think it is a good idea?
Thanks,
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<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.