Re: Multiple writers to sc_signal

If there is a simple proposal that can be agreed upon without lots of
discussion then I vote YES, otherwise I do not think it a high priority at
this time.

Dave L

From:
john.aynsley@doulos.com
To:
P1666 Technical WG <systemc-p1666-technical@eda.org>
Date:
08/11/2010 17:24
Subject:
Re: Multiple writers to sc_signal
Sent by:
owner-systemc-p1666-technical@eda.org

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.