Re: reset_signal_is

Reset on sc_in is required to get the reset to the various processes and threads throughout the hierarchy which require reset.

Reset on sc_out is needed to support a style of design where the test harness is a peer to the design to be synthesized, and hence the test harness passes out a reset to the parent's sc_signal, which passes the reset into the child design(s) to be synthesized.

I guess one could use sc_inout to model a single reset line which is driven from different parts of the hierarchy.

Mac

________________________________
From: owner-systemc-p1666-technical@eda.org <owner-systemc-p1666-technical@eda.org>
To: john.aynsley@doulos.com <john.aynsley@doulos.com>
Cc: systemc-p1666-technical@eda.org <systemc-p1666-technical@eda.org>
Sent: Fri May 14 07:50:13 2010
Subject: 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<mailto: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<mailto:philipp.hartmann@offis.de>>
To: "john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>" <john.aynsley@doulos.com<mailto:john.aynsley@doulos.com>>
Cc: systemc-p1666-technical@eda.org<mailto: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<mailto: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<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, and is
believed to be clean.

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