Re: P1666 Ballot resolution discussion - Part 3

All,

This is the third-and-final set of issues related to the OSCI
Proof-of-concept work and the process control corner cases.

Each of the issues described below involves a minor specification change,
so you probably want to read them carefully! The first two issues
(async_reset and terminated()) probably require some discussion. The
remaining issues are minor technical enhancements to ensure consistency
and should be uncontroversial.

6.2.13 reset_signal_is and async_reset_signal_is
6.6.6.5 reset

The LRM permits synchronous and asynchronous resets for a method process,
either using reset_signal_is, async_reset_signal_is or the reset() or
sync_reset_on() methods. However, the only effect of such a reset on a
method process is to clear any dynamic sensitivity and to restore the
static sensitivity: the process function itself is not executed.

We propose changing the specification such that the occurrence of a reset
does cause the method process to be called and reset_event() to be
notified. This would allow method processes to be used in a natural way to
express synchronous and asynchronous reset behaviour, for example:

SC_METHOD(proc);
  sensitive << clock.pos();
  async_reset_signal_is(reset, true);
...

void proc()
{
  if (reset)
    // Asynchronous reset behavior, executed when reset goes active (not
the case the LRM as it stands)
  else
    // Synchronous behavior, only executed on a positive clock edge
}

In the case of synchronous resets (reset_signal_is or sync_reset_on), the
only change would be that synchronous resets are explicitly permitted for
method processes (rather than being ignored) and that the reset_event()
would get notified.

If this enhancement were not to be accepted, the fall-back position would
be that it should be an error to asynchronously reset a method process
that has no static sensitivity (because there would be no way such a
process could become runnable again).

6.6.5
bool terminated() const;

In 1666-2005, terminated() shall return false for an invalid handle. But
with the process control methods, we now have a new way in which a process
can get terminated, namely kill(), and we have also clarified the rules
concerning how an implementation is allowed to invalidate process handles
(even though the OSCI PoC implementation does not do so). So, the use
case:

   if (process_handle.terminated())

will become more common, but as things stand, such a test would need to be
guarded:

  if (process_handle.valid()) {
    if (process_handle.terminated())
      // Terminated
  }
  else
    // Process may have been terminated, but there is no way of telling.
 
We propose a choice between two alternative solutions:

A) Have terminated() always return the value true for an invalid handle

B) Have terminated() return false for an empty process handle and true for
a terminated process, regardless of whether or not the process handle is
valid or invalid

Technically, either solution would work.

6.13 sc_export

We propose to add a new method to sc_export

  operator const IF&() const;
 
This is required to enable the implementation of the new virtual, const
get_base* overloads in the TLM-2.0 sockets (see below, 14.2).

9.5 sc_vector

We propose adding two new methods to sc_vector_assembly<T,MT>, taking a
base-vector iterator as an offset:

  template< typename BindableIterator >
  iterator bind( BindableIterator first, BindableIterator last,
                 sc_vector<T>::iterator from );

  template< typename ArgumentIterator >
  iterator operator()( ArgumentIterator first, ArgumentIterator last,
                       sc_vector<T>::iterator from );

This would mean that the rather clumsy

  sc_assemble_vector( mods, &module::in )
    .bind( sigs.begin(), sigs.end(),
           sc_assemble_vector( mods, &module::in ).begin()+1 );

could be re-written as

  sc_assemble_vector( mods, &module::in )
    .bind( sigs.begin(), sigs.end(), mods.begin()+1 );

Moreover, we propose the following wording be added to the LRM (9.5.8):

  An object of type 'iterator' shall be implicitly convertible to a
'const_iterator' object, referring to the same element.

  An object of type sc_vector_assembly<T,MT>::iterator shall be implicitly
convertible to both an 'iterator' or a 'const_iterator' of sc_vector<T>,
referring to the enclosing object of the underlying vector. The
assembly's 'const_iterator' objects shall respect constness and therefore
be implicitly convertible to the corresponding 'const_iterator' only.

The above wording would permit the following, which would otherwise fail:

  sc_vector< module >::iterator mi = mods.begin() + 1;
 
  mi = sc_assemble_vector( mods, &module::in ).bind( sigs.begin(),
sigs.end(), mi );
 
 
 

14.2 Initiator and target sockets

New const overloads have been added for the functions

  get_base_port() const
  get_base_export() const
  get_base_interface() const

The definition of the explicit implementation in tlm_base_*_socket to
return the corresponding member, can't be implemented currently:

  get_base_interface() const { return m_export; }

m_export is const within the body of the function, therefore the
conversion to its bound interface via 'operator IF&' can't be called.

We propose to add a const overload to sc_export to solve this:

  operator const IF&() const;

17.1.4 Multi-sockets
 
This issue is related to the previous issue. The multi_socket classes
override two virtual functions
 
  get_base_export()
  get_base_interface()

without adding the newly defined const-overloads.

  Since these two functions are used to resolve the binding of the
different interfaces during the elaboration, they can't be implemented as
a 'const' function in the same manner (they return different objects at
different calls, changing the internal state of the socket).

  We propose to add const overloads for these functions explicitly and
require an error report from the implementation to avoid a hidden
inconsistency between the two signatures when called polymorphically.

John A

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.