Re: Multiple writers to sc_signal

Everyone (especially Cadence),

So there seems to be some enthusiasm for implementing a multiple writers
policy provided that we keep it simple. So what does simple mean?

I suppose we could just add the policy to sc_signal as proposed by Stuart.
The default would be the current rule, i.e. it is an error for multiple
process instances to write to the same signal, although multiple writes
are permitted during elaboration/sc_main/callbacks. The alternative policy
would remove all restrictions. Is that what everyone means by simple?

I guess that using a template parameter is going to mess up C++ type
compatibility when binding ports and signals. Would we do better to set
the multiple writers policy using a constructor argument (rather than
introducing a non-templated sc_signal_base and all that jazz).

Then what about the semantics of sc_inout? Currently it is an error to
bind more than one sc_inout port to a given sc_signal. Should that check
be relaxed depending on the policy of the sc_signal instance?

What would we say for the case of having multiple writers to an sc_inout
port? It is the responsibility of the model writer to highlight the need
for the multiple writer policy in their documentation?

John A

From:
Kaz Yoshinaga <yoshi@starc.or.jp>
To:
john.aynsley@doulos.com
Cc:
Kaz Yoshinaga <yoshi@starc.or.jp>, P1666 Technical WG
<systemc-p1666-technical@eda.org>
Date:
09/11/2010 11:13
Subject:
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.