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.