Re: reset_signal_is

It makes perfect sense to me. Most designs have external reset inputs. The syntax should at least have some mechanism to allow this. From a synthesis perspective it makes sense also.

On May 14, 2010, at 8:15 AM, john.aynsley@doulos.com wrote:

> Anybody,
>
> Resets on out/inout ports? Where did that come from? Was it Andy's doing? Does the Synthesis WG need it?
>
> 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.

------------------------------------------------------
David C Black, XtremeEDA ESL Practice Leader
http://www.Xtreme-EDA.com
(Consulting, Services & Training for all your ESL, verification and DFT needs)
Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609

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