Re: Multiple writers to sc_signal

Hi John,

I vote YES.

Regrads,
--
Kaz Yoshinaga
Researcher
Design Standard Group
Semiconductor Technology Academic Research Center
yoshi@starc.or.jp

On Nov 9, 2010, at 2:23 AM, 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.