RE: Multiple writers to sc_signal

To concur with Philipp, we are currently evaluating internally the benefit of the proposal.
In many cases indeed, this could ease the implementation, say of TLM->RTL transactors.

Regards,

Jerome

-----Original Message-----
From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Philipp A. Hartmann
Sent: Monday, November 08, 2010 4:37 PM
To: john.aynsley@doulos.com
Cc: Bishnupriya Bhattacharya; Stuart Swan; P1666 Technical WG
Subject: Re: Multiple writers to sc_signal

All,

I find it somewhat sad, that this proposal is dropped for now.

  When writing transactors / adapters to RTL blocks with signal-level
interfaces, a (restricted) policy for multiple drivers of a signal can
ease the implementation in many cases.

  If the transactor already arbitrates concurrent requests, there may be
technically multiple writers to a signal (due to different initiators),
but the behaviour is still well-defined since there are no conflicting
updates during the same delta cycle. Thus, a policy that allows
multiple drivers in separate deltas would both be useful and safe.

  But since there seems to be no strong interest in P1666 in such a
feature, I think we can still pursue this topic inside OSCI after
P1666-2011.

Greetings from Oldenburg,
Philipp

On 08/11/10 12:55, john.aynsley@doulos.com wrote:
> Okay. I'll close the issue of the sc_multiple_sig_writers_policy class.
>
> John A
>
>
>
> From:
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Stuart Swan
> <stuart@cadence.com>
> Cc:
> P1666 Technical WG <systemc-p1666-technical@eda.org>
> Date:
> 08/11/2010 08:36
> Subject:
> RE: Multiple writers to sc_signal
>
>
>
> John,
>
> As Stuart also opined, there is currently no interest or motivation in
> pursuing a sc_multiple_sig_writers_policy class.
>
> Thanks,
> -Bishnupriya
>
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Friday, November 05, 2010 5:00 AM
> 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
>
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
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.