Re: Declaring that two disciplines are incompatible

From: Jonathan David <jb_david_at_.....>
Date: Tue Feb 19 2008 - 11:56:12 PST
Actually, we should just extend the case.. If disciplines are used, How they are allowed to connect (or not) 
must be defined in the connect rules..   -- if there is no connect statement , or  resolve to, statement that covers the case, 
or Level shifter used in the design.. then the connection should fail. 
It shouldn't matter if the disciplines are compatible, or if they cross the analog/digital domain. 
The connection rules should RULE for ALL the connections. 
It might be nice to have a "forbid" connection type of rule.. 
but the types of rules done so far should work.

Jonathan

 
Jonathan David
j.david@ieee.org
jb_david@yahoo.com
http://ieee-jbdavid.blogspot.com
Mobile 408 390 2425

----- Original Message ----
From: Marq Kole <marq.kole@nxp.com>
To: verilog-ams <verilog-ams@eda-stds.org>
Sent: Monday, February 18, 2008 12:19:45 AM
Subject: Re: Declaring that two disciplines are incompatible



Hi Ken,



By making the two disciplines not derive from the same base discipline (electrical or voltage) they would become incompatible according to LRM 2.2 sec. 3.8.1. To use this you would need to declare a separate electrical discipline and use that for example for the logic32, while the regular electrical discipline would be used for logic18.



This is what the standard says, I've not actually tested this out. I believe Jonathan David had a presentation on this use of multiple disciplines at the 2006 BMAS.



Cheers,

Marq





owner-verilog-ams@server.eda.org wrote on 17-02-2008 04:02:30:



> Dave,

>      Thanks for the suggestion. Unfortunately, connect modules are only 

> an option when there are two disciplines, and one is discrete and the 

> other is continuous. In my example, I purposely gave two discrete 

> domains. As such, they are naturally compatible. I need a way that works 

> for disciplines that are compatible (either two discrete, or two 

> compatible continuous).

> 

> -Ken

> 

> David Sharrit wrote:

> > Perhaps a workaround would be to create a dummy connect module, that doesn't

> > actually connect anything and possibly just prints out a warning, and then

> > have the two incompatible disciplines resolve to that.

> > 

> > David 

> > 

> >> -----Original Message-----

> >> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On

> >> Behalf Of Ken Kundert

> >> Sent: Saturday, February 16, 2008 7:36 PM

> >> To: Verilog-AMS LRM Committee

> >> Subject: Declaring that two disciplines are incompatible

> >>

> >> All,

> >>      Is there a way in Verilog-AMS to declare that two disciplines are

> >> incompatible and should never be interconnected. For example, say I

> >> declare two discipline, logic18 and logic32, one for 1.8V logic and the

> >> other for 3.2V logic. Can I use the resolveto construct to declare them

> >> incompatible?

> >>

> >> discipline logic18

> >>      domain discrete;

> >> enddiscipline

> >> discipline logic32

> >>      domain discrete;

> >> enddiscipline

> >> connectrules myRules

> >>      connect logic18, logic32 resolveto ;

> >> endconnectrules

> >>

> >> Currently I don't think the language has the ability to do this, but it

> >> seems like a nice feature. This way I could prevent logic from different

> >> supply domains from interconnected by accident.

> >>

> >> -Ken

> >>

> >> --

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

> 

> [attachment "ken.vcf" deleted by Marq Kole/EHV/RESEARCH/PHILIPS] 
-- 

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.
Received on Tue Feb 19 12:08:39 2008

This archive was generated by hypermail 2.1.8 : Tue Feb 19 2008 - 12:09:04 PST