Re: Multiple writers to sc_signal

I agree with the idea that it needs to be simple. So YES if simple. No if delays standardization because of complexity.

On Nov 8, 2010, at 1:28 PM, Philipp A. Hartmann wrote:

> I agree with Dave here: If it's simple enough to be added, it would be
> really good to have.
>
> That said, two more comments on this:
>
> - I like the proposal to add a "multiple writer" policy template
> parameter to sc_signal/sc_buffer.
>
> If we still check-for and disallow conflicting writes in the
> same delta, we would even avoid to define who is the "last
> one winning" and retain determinism.
>
> I would also vote for keeping the static check of a single writing
> port here. But this can be decided separately.
>
> - I'm not sure about specific multiple-writer ports, though. This
> doesn't seem to add "real" safety, as it stands now:
>
> sc_inout<bool> port;
> sc_inout_mw<bool> mw_port;
>
> mw_port.bind( port ); // would not work
> port.bind( mw_port ); // compiles (and fail at runtime)
>
> So the assumed IP vendor would still need to handle support requests
> due to this issue and add appropriate documentation to the model.
>
> Greetings from Oldenburg,
> Philipp
>
> On 08/11/10 18:55, david.long@doulos.com wrote:
>> 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.
>
>
>

------------------------------------------------------
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.