RE: Multiple writers to sc_signal

On 11/11/2010 09:41, john.aynsley@doulos.com wrote:
Stuart, Bishnupriya, Everyone,

Let me restate what I think you are proposing:

"NOT OK" =
   * It is an error for more than one process instance to call
sc_signal::write for a given signal instance at any time (excludes
elaboration/callbacks/sc_main)
   * It is an error to bind more than one sc_port<sc_signal_inout_if> to a
given sc_signal instance
   * The default

"OK" =
   * Multiple process instances may call sc_signal::write for a given
signal instance in different deltas
   * It is an error for more than one process instance to call
sc_signal::write in the same delta (equivalently, in the same evaluation
phase)
   * It is permitted to bind more than one sc_port<sc_signal_inout_if> to
a given sc_signal instance

Hi John,
  can you just spell out (for me!) the significance of disallowing writes
in the same evaluation phase - is it to keep deterministic behaviour? I
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.

And, presumably, remove all other compile-time switches from the PoC
simulator (SC_SIGNAL_WRITE_CHECK, DISABLE) ?

As for the naming, I propose

enum sc_writer_policy {
   SC_ONE_WRITER,
   SC_MULTIPLE_WRITERS
};

virtual sc_writer_policy get_writer_policy() const;

Does that work for everyone?

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.

regards
Alan

John A

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. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 
-- 
Alan Fitch
Senior Consultant
Doulos ? Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
Services
Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24 
1AW, UK
Tel:  + 44 (0)1425 471223                                Email: 
alan.fitch@doulos.com 
Fax:  +44 (0)1425 471573                                 
http://www.doulos.com
------------------------------------------------------------------------
This message may contain personal views which are not the views of Doulos, 
unless specifically stated.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.