Re: reset_signal_is and multi-ports

All,

Nobody apart from Philipp seems to care about adding reset_signal_is to
multiports, and the consensus seems to be that we can live without it.
Hence I propose NOT making this change unless anyone mounts a strong
challenge.

This leaves the declarations for sc_module::reset_signal_is in the draft
LRM are as follows:

void reset_signal_is( const sc_in<bool>& , bool );
void reset_signal_is( const sc_inout<bool>& , bool );
void reset_signal_is( const sc_out<bool>& , bool );
void reset_signal_is( const sc_signal_in_if<bool>& , bool );
void async_reset_signal_is( const sc_in<bool>& , bool );
void async_reset_signal_is( const sc_inout<bool>& , bool );
void async_reset_signal_is( const sc_out<bool>& , bool );
void async_reset_signal_is( const sc_signal_in_if<bool>& , bool );

with similar member functions for sc_spawn_options

John A

From:
"Philipp A. Hartmann" <philipp.hartmann@offis.de>
To:
john.aynsley@doulos.com
Cc:
Stuart Swan <stuart@cadence.com>, "systemc-p1666-technical@eda.org"
<systemc-p1666-technical@eda.org>
Date:
16/09/2010 20:45
Subject:
Re: reset_signal_is and multi-ports

John, All,

since I came up with the idea of multi-port resets in the first place,
I'll give my opinion as well.

  First of all, this has been more or less a crazy idea, since we
actually needed something like this in a design a while back. We had a
module waiting for a configurable number of other modules to finish
their initialisation, where this would have been handy.

  With the ability to manually add multiple resets per process, the
multiport reset can still be set up explicitly during/after elaboration
by adding the bound signals in a loop. So the functionality is strictly
necessary.

  The only other benefit I see from this, is the slightly lighter
interface, since sc_inout and sc_out don't have to be distinguished.
But this would be possible with the definition of N=1 in the port
argument:

void reset_signal_is( const sc_port<sc_signal_inout_if<bool>,1>& port
                    , bool level );

Greetings from Oldenburg,
Philipp

On 16/09/10 18:31, john.aynsley@doulos.com wrote:
> Thanks, Stuart. Does anyone else have an opinion?
>
> John A
>
>
>
> From:
> Stuart Swan <stuart@cadence.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>,
> "philipp.hartmann@offis.de" <philipp.hartmann@offis.de>,
> "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>
> Date:
> 13/09/2010 18:59
> Subject:
> RE: reset_signal_is and multi-ports
>
>
>
> John, All-
>
> We have not seen the need for reset_signal_is() for multiports. We?re
> certainly willing
> to listen if others have reasons why they think it is necessary, but
right
> now we think should
> skip it and focus on other things.
>
> -Stuart
>
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of
> john.aynsley@doulos.com
> Sent: Monday, September 13, 2010 5:50 AM
> To: philipp.hartmann@offis.de; systemc-p1666-technical@eda.org
> Subject: reset_signal_is and multi-ports
>
> All,
>
> Philipp wrote:
>
> "Regarding multi-ports for all variants, it would be enough to have
>
> template< typename N >
> void reset_signal_is( const sc_port<sc_signal_in_if<bool>,N>& port
> , bool level );
> template< typename N >
> void reset_signal_is( const sc_port<sc_signal_inout_if<bool>,N>& port
> , bool level );
>
> since sc_out<> is also derived from the generic inout port, right?
> An implementation of course could still drop the templates internally."
>
> Does the WG wish to pursue the idea of defining reset_signal_is for
> multiports? Are there any futher proposals?
>
> Thanks,
>
> John A
>

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