Re: reset_signal_is

John,

for modelling convenience, I can see the benefit of these variants now.
 It just never occurred to me to use it this way. So I'm fine with this.

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.

Regards,
Philipp

On 20/05/10 18:50, john.aynsley@doulos.com wrote:
> Philipp, All,
>
> Within an sc_module you could have
> - a module instance containing a reset generator driving an sc_out port of
> that instance
> - a synthesizable SC_CTHREAD that reads the same reset
> - and the reset could be an output port of that sc_module, and hence an
> sc_inout port
> - ultimately bound to an sc_signal instance at the top level of the
> hierarchy
>
> So I can see that for the sake of generality we might want to allow the
> full set of 4 reset_signal_is declarations shown below.
>
> As for resets with multi-ports, does anyone else have an opinion?
>
> John A
>
>
>
>
> From:
> "Philipp A. Hartmann" <philipp.hartmann@offis.de>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc:
> systemc-p1666-technical@eda.org
> Date:
> 10/05/2010 19:18
> Subject:
> Re: reset_signal_is
>
>
>
> John, All,
>
> I've just noticed, that in the current OSCI internal version of the
> simulator the other boolean signal ports are supported for resets as well:
>
> void reset_signal_is( const sc_in<bool>& port, bool level );
> void reset_signal_is( const sc_inout<bool>& port, bool level ); // <--
> void reset_signal_is( const sc_out<bool>& port, bool level ); // <--
> void reset_signal_is( const sc_signal_in_if<bool>& iface, bool level );
>
> Actually, I do not really like to have sc_(in)out as reset sources, but
> this is the way it looks like in the 2.3.16jun09_beta package.
>
> Regarding the superset, I agree wrt. the signal variant. In the light
> of multiple possible reset signals supported by the Process Control
> extensions, I would even prefer to have a superset for the port variant
> supporting multiports. This would simplify the registration of
> multiple reset sources (sharing the same level sensitivity):
>
> template< typename N >
> void reset_signal_is( const sc_port<sc_signal_in_if<bool>,N>& , bool );
>
> (An implementation could internally use a mechanism like sc_port_b<...>
> to avoid the template function.)
>
> What do you think?
>
> Greetings from Oldenburg,
> Philipp
>
> On 07/05/10 12:51, john.aynsley@doulos.com wrote:
>>
>> Bishnupriya raised the following point a while back:
>>
>> The LRM specifies 2 signatures for reset_signal_is
>>
>> void reset_signal_is( const sc_in<bool>& , bool );
>> void reset_signal_is( const sc_signal<bool>& , bool );
>>
>> (The process control extensions spec uses the above signatures)
>>
>> The 4feb06 kit implements the following 2 signatures
>>
>> void reset_signal_is( const sc_in<bool>& port, bool level );
>> void reset_signal_is( const sc_signal_in_if<bool>& iface, bool level
> );
>> <---------- this is a superset of what the LRM says
>>
>> Should the LRM be modified (in the future) to allow the superset that
> the
>> 4feb06 kit allows?
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS
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.