Re: Multiple writers to sc_signal

I vote "YES".

Comment: The explanation of the member function register_port in sec.
7.4.6. should be rewritten.

Hiroshi Imai
Chair of SystemC WG of JEITA

At 08 Nov 2010 17:23:41 +0000 john.aynsley@doulos.com wrote:
> Okay, let's have a straw poll. Please vote whether you would like the
> P1666 WG to pursue the proposal for having multiple writers to an
> sc_signal at this time - YES or NO.
>
> John A
>
>
>
>
> From:
> David C Black <dcblack@xtreme-eda.com>
> To:
> Jerome CORNET <jerome.cornet@st.com>
> Cc:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>,
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Bishnupriya
> Bhattacharya <bpriya@cadence.com>, Stuart Swan <stuart@cadence.com>, P1666
> Technical WG <systemc-p1666-technical@eda.org>
> Date:
> 08/11/2010 16:13
> Subject:
> Re: Multiple writers to sc_signal
>
>
>
> I would agree there are definite uses for such a model. I was sort of
> hoping Cadence would take up the cause. I really like Cadence previous
> proposal because it ensure the user is very aware of the issue. I was sort
> of hoping Cadence would take up the cause.
>
>
> On Nov 8, 2010, at 9:43 AM, Jerome CORNET wrote:
>
> > 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.
> >
> >
> >
>
> ------------------------------------------------------
> David C Black, XtremeEDA ESL Practice Leader
> http://www.Xtreme-EDA.com
> (Consulting, Services & Training for all your ESL, verification and DFT
> needs)
> Voice: 512.850.4322 Skype: dcblack FAX: 888.467.4609
>
>
>
>
>
> --
> 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.