Re: reset_signal_is

Mac,

Are you saying this is a hard requirement, in which case it should go into
the LRM? No problem - just asking for confirmation.

John A

From:
"Michael (Mac) McNamara" <mcnamara@cadence.com>
To:
"'dcblack@xtreme-eda.com'" <dcblack@xtreme-eda.com>,
"'john.aynsley@doulos.com'" <john.aynsley@doulos.com>
Cc:
"'systemc-p1666-technical@eda.org'" <systemc-p1666-technical@eda.org>
Date:
14/05/2010 16:00
Subject:
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 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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.