Re: Multiple writers to sc_signal

I agree that
 using the constructor is probably a better place to put the option.
 two policies seems best to me
if folks want more, they could always write their own primitive channel (not too hard to do really)
 re. sc_inout ports, I agree with not making it an explicitly checked error. We could document it as an error that is not required to be checked by the implementation. Static tools could check this (e.g. AccurateC).

On Nov 10, 2010, at 3:59 AM, john.aynsley@doulos.com wrote:

> Philipp, All,
>
> 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:
>
> * SC_MULTIPLE_WRITERS_NOT_OK = the default, the implementation should check for multiple writers at every level and issue error reports
> * SC_MULTIPLE_WRITERS_OK = no checks, period.
> What do people think?
>
> 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?
>
> I agree we need a get_writer_policy() method, whatever.
>
> 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?
>
> 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 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. I am saying that having multiple writers to an sc_inout port is necessarily allowed (because it is undetectable), It can only be detected 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. 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.

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