Re: Multiple writers to sc_signal

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.