Re: Multiple writers to sc_signal

Alan, all,

On 11/11/10 12:43, alan.fitch@doulos.com wrote:

[snip]
> can you just spell out (for me!) the significance of disallowing writes
> in the same evaluation phase - is it to keep deterministic behaviour? I

Yes, that's goal.

But this covers of course only multiple writes from distinct(!)
processes within the same evaluation phase. A single process can still
write multiple values to a signal at will, the last one
deterministically wins:

void method()
{
  out.write( default_value );
  if( condition )
    out.write( other_value ); // fine! and even good style at RTL :-)
}

> think (?) the current implementation *does* allow multiple writes in the
> same evaluation phase. As far as I remember it only checks the process id,
> it doesn't check the delta counter.

The delta counter doesn't need to be checked in the future as well.
"The same evaluation phase" is probably a better wording anyhow. The
idea is to just "lock" the signal to the first writing process id per
evaluation phase, instead for the full simulation run.

> On 11/11/2010 09:41, john.aynsley@doulos.com wrote:
> And, presumably, remove all other compile-time switches from the PoC
> simulator (SC_SIGNAL_WRITE_CHECK, DISABLE) ?

I would prefer to keep support for SC_SIGNAL_WRITE_CHECK in the PoC
simulator for compatibility. But this can be decided by OSCI, I guess.

> As for the naming, I propose
>
> enum sc_writer_policy {
> SC_ONE_WRITER,
> SC_MULTIPLE_WRITERS
> };
>
> virtual sc_writer_policy get_writer_policy() const;

I like these (more generic) names. Theoretically, this discussion could
be extended to sc_fifo, I guess. Currently, there is no dynamic check
in sc_fifo, only a static one. So future versions could add the same
policy parameter to sc_fifo as well.

> Would it make sense to include the word "signal" in the names, just to
> avoid any confusion? E.g.
> SC_SIGNAL_ONE_WRITER
> SC_SIGNAL_MULTIPLE_WRITERS
> sc_signal_writer_policy
>
> I have no strong opinion, I just imagine new users thinking they can do
> multiple writes to some other primitive channel.

As I said: the generic names may be already useful for other channels,
although not yet supported by any of the builtin ones.

Greetings from Oldenburg,
Philipp

> From:
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> To:
> Stuart Swan <stuart@cadence.com>, "john.aynsley@doulos.com"
> <john.aynsley@doulos.com>, "Philipp A. Hartmann"
> <philipp.hartmann@offis.de>
> Cc:
> P1666 Technical WG <systemc-p1666-technical@eda.org>
> Date:
> 11/11/2010 04:12
> Subject:
> RE: Multiple writers to sc_signal
>
>
>
>
>
> One addition.
>
> Regarding if multiple sc_inout ports are bound to a sc_signal with
> MULTIPLE_WRITERS_OK policy, then is it an error or not - we believe it
> should not be an error.
>
> Thanks,
> -Bishnupriya
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Stuart Swan
> Sent: Thursday, November 11, 2010 4:24 AM
> To: john.aynsley@doulos.com; Philipp A. Hartmann
> Cc: P1666 Technical WG
> Subject: RE: Multiple writers to sc_signal
>
> John, All-
>
> We?ve had some discussions in Cadence and here is what we seem to
> have settled on as our position on this topic:
>
> - We think it is very desirable to add a simple multiple writers sc_signal
> feature
> in this round for the standard.
>
> - We think the ?multiple writers ok? option should be specified via an
> optional template
> parameter to sc_signal, and the default behavior should be to check for
> multiple processes performing
> writes to the signal (as is currently done with DEBUG_SYSTEMC ) enabled.
> We think only the ?OK? and ?not OK?
> options are needed ? the other additional options seem excessive, maybe
> can be added later if needed.
>
> - If the ?multiple writers ok? option is set, then it shall be an error if
> more than one write is made to
> the same signal in the same delta cycle. Philip has made a strong argument
> that this check can be performed
> efficiently, and if the check is not performed then the model is at best
> non-deterministic if the situation exists.
>
> - Having a query function on sc_signal to see what the multiple writers
> policy is is a good idea. This will enable
> ports to check at end of elaboration that they are hooked to signals with
> the expected policy. But this is not
> essential to the overall proposal.
>
> - We do not think that adding additional port types to enable users to
> declare ?multiple writer signal ports? is
> needed now. We?ve thought about this approach, but it seems there are many
> issues, and it is really not essential.
>
> Thanks
> Stuart
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Wednesday, November 10, 2010 3:12 AM
> To: Philipp A. Hartmann
> Cc: P1666 Technical WG
> Subject: Re: Multiple writers to sc_signal
>
> Philipp, All,
>
> I can see the sense in Philipp's proposal to have several distinct
> policies to allow/disallow multiple writes in the same and in separate
> deltas, but based on the premise that people want a simple solution, I am
> keeping to my position of just two choices, effectively formalizing in the
> LRM the two ways (legal and illegal) that people have used sc_signal in
> the past. Please speak up, everybody!
>
> I guess the pure approach is the use a template parameter, as Stuart
> proposed, to maximize speed for the unchecked case.
>
> I agree that a specialized port in a piece of IP can do an
> end_of_elaboration check that it is indeed bound to a promiscuous
> sc_signal.
>
> John A
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> john.aynsley@doulos.com
> Cc:
> P1666 Technical WG <systemc-p1666-technical@eda.org>
> Date:
> 10/11/2010 10:48
> Subject:
> Re: Multiple writers to sc_signal
>
>
>
>
>
>
>
>
>
> John, all,
>
> answers below.
>
> On 10/11/10 10:59, john.aynsley@doulos.com wrote:
>>
>> If we were starting from a clean sheet, there may be merit in having
>> distinct policies allowing or disallowing signal writes within the same
>> delta. But simulation-time multiple writer checks are expensive, which
> is
>> why the PoC simulator turned them off by default. So I am only in favour
>
>> of two policies, as originally proposed by Stuart:
>
> As it stands now, the PoC simulator actually _does_ checking for
> multiple writers by default, even on every write() call unless the
> environment variable SC_SIGNAL_WRITE_CHECK is set to DISABLE.
>
> This is done by storing the sc_object * of the writing process and
> compare it with the current one, if it's already set. So allowing for
> multiple writers only in distinct deltas merely boils down to forgetting
> the writing process during the update() phase. Why should this be costly?
>
>> * SC_MULTIPLE_WRITERS_NOT_OK = the default, the implementation should
>> check for multiple writers at every level and issue error reports
>
> This is already the default, yes.
>
>> * SC_MULTIPLE_WRITERS_OK = no checks, period.
>> What do people think?
>
> As said above, an SC_MULTIPLE_WRITERS_RELAXED is more or less the
> addition of the following lines to the implementation:
>
> if( m_policy & SC_MULTIPLE_WRITERS_RELAXED )
> m_writer = 0;
>
>> I take your point that ports bind to interfaces, not channels, so we
> have
>> the choice of the policy being a template parameter or a constructor
> arg.
>> What do people think?
>
> If you think that performance is a strong issue, a template parameter
> may help the compiler to avoid the checks completely at runtime. But I
> think it should not make any measurable difference.
>
>> Now for binding multiple sc_inout ports to a signal that allows multiple
>
>> writers. You suggest this is still an error. I suggest this is allowed,
>> but I can see the sense in your argument. What do people think?
>
> I especially want a separation of concerns here. The port check is done
> in register_port() of the signal. It does not affect the dynamic checks
> at all. Since there may not be a use case for a single process writing
> via multiple ports, I would prefer to combine this with the RELAXED
> policy, though.
>
>> Regarding multiple writers to a single sc_inout port, I don't see how
> you
>> are going to detect that at end_of_elaboration, the point being that you
>
>
> You are right. I don't think, that it is possible to detect multiple
> writers via a single port, since you can't determine from within
> operator->, whether the caller will perform a read or a write.
>
> But, the issue at hand in the original Cadence proposal was to enable
> a way to detect from an output port, whether it will be OK to write to
> this port from multiple processes (within an IP model for instance). If
> you ask the bound channel about its policy, you can determine this at
> end_of_elaboration. Am I missing something?
>
>> don't know whether a process instance is going to write to a signal
> until
>> it does so - during simulation. Hence the need for expensive dynamic
>> checks.
>
> Yes, expensive in terms of a policy query and a pointer comparison. ;-)
> Are there actually any benchmarks on this?
>
>> I am saying that having multiple writers to an sc_inout port is
>> necessarily allowed (because it is undetectable), It can only be
> detected
>
> Yes. But let's keep the deltas distinct by default in that case, as
> proposed in my last mail. A completely unchecked SC_MULTIPLE_WRITERS_OK
> depends on the internal scheduler, is unreliable and can hide errors,
> that are otherwise detected. This should be avoided in models excepts
> for very strong reasons.
>
> I'm really in favour to add a relaxed policy, that keeps the model
> semantics well-defined and solves problems for writing transactors or
> using different dynamic processes. It's trivially implementable (see
> above) and does not impose higher cost than the default policy.
>
>> when there is a signal instance in the loop. I am tentatively proposing
>> that the rule should then be very simple: the signal either allows
>> multiple writers or does not allow multiple writers, irrespective of how
>
>> many sc_inout ports are involved.
>
> Well, yes. Obviously allowing multiple ports would include allowing
> multiple drivers (in different deltas), see above.
>
> Greetings from Oldenburg,
> Philipp
>
>> In other words, the situation where
>> multiple processes drive the signal through a single sc_inout port is
>> indistinguishable from the situation where multiple processes drive the
>> signal through an equal number of sc_inout ports, one-per-driver. (This
>> scenario does not stop people from creating specialized ports that can
>> only be bound to signals of a particular flavour, if they wish,
>> interrogating the signal using get_writer_policy().) What do people
>> think?
>>
>> John A
>>
>>
>>
>> From:
>> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
>> To:
>> john.aynsley@doulos.com
>> Cc:
>> P1666 Technical WG <systemc-p1666-technical@eda.org>
>> Date:
>> 10/11/2010 00:34
>> Subject:
>> Re: Multiple writers to sc_signal
>>
>>
>>
>> John, All,
>>
>> some points from my side on this topic.
>>
>> On 09/11/10 14:46, john.aynsley@doulos.com wrote:
>>>
>>> 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?
>>
>> Hmmm, I'm not sure about removing all restrictions. I would vote to
>> lift only the writing process limitation towards allowing multiple
>> writers at different deltas/points in time. IMHO, this covers the needs
>> in most (all?) valid use cases and keeps the semantics well-defined.
>>
>> What about the following policies (names to be discussed):
>>
>> enum sc_signal_writer_policy
>> {
>> SC_SIGNAL_WRITER_UNIQUE // default, one port, one process
>> , SC_SIGNAL_WRITER_RELAXED // multiple processes, distinct deltas
>> , SC_SIGNAL_WRITER_MULTIPLE_PORTS // multiple ports, distinct deltas
>> , SC_SIGNAL_WRITER_UNCHECKED // no restrictions - impl. defined
>> };
>>
>> For the fully unchecked policy, there should be a prominent warning
>> that the actual "winner" of the conflicting writes is (at most)
>> implementation-defined.
>>
>>> 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).
>>
>> AFAICS, we don't need to change anything in the ports, if the policy
>> template parameter is only added to the signal, not to the interfaces.
>> But I agree, that a constructor parameter is sufficient and probably
>> simpler.
>>
>> NB: Wrt to sc_vector, this is a nice example for a simple creator
>> function:
>>
>> template< typename T, sc_signal_writer_policy POL >
>> sc_signal<T>* create_signal( const char * nm, size_t )
>> { return new sc_signal<T>( nm, POL ); }
>>
>> sc_vector< sc_signal<int> > sig_vec;
>> sig_vec.init( 4, create_signal< int, SC_SIGNAL_WRITER_RELAXED > );
>>
>> We should then add an accessor function for the policy, in addition to
>> the constructor:
>>
>> explicit
>> sc_signal( const char* nm,
>> sc_signal_writer_policy pol = SC_SIGNAL_WRITER_UNIQUE );
>>
>> sc_signal_writer_policy writer_policy() const;
>>
>> This way, special ports (or IP vendors) can check the policy at
>> end_of_elaboration() as done in sc_in_resolved and friends.
>>
>> That said, the sc_signal_rv/resolved classes should then of course
>> return SC_SIGNAL_WRITER_UNCHECKED as their policy for consistency, and
>> sc_buffer should get a constructor with a policy as well.
>>
>>> 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?
>>
>> I would like to separate this (see above). IMHO, multiple driving
>> ports indicate a design error in most cases. So let's separate this
>> from the other, safer cases.
>>
>>> 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?
>>
>> With the accessor as described above, the model writer could issue an
>> appropriate error at end_of_elaboration(). So I don't see an immediate
>> need for specialised ports in the core language.
>>
>> Greetings from Oldenburg,
>> Philipp
>>
>
>

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