RE: port_discipline

From: Marq Kole <marq.kole_at_.....>
Date: Wed Sep 05 2007 - 01:58:23 PDT
Martin,

There is still the issue that the current syntax does not allow an
attribute on a module instance. Your example is not legal Verilog,
according to the IEEE 1364-2005 LRM. I do not think we should introduce
this new syntax as that would make the module instantiation for AMS
different from the IEEE 1364-2005 one. I presume that this has not changed
with IEEE 1800-2005.

At this moment there two positions in a module instantiation where an
attribute is allowed: on the module instantiation itself (according to IEEE
1364-2005 A.1.4):

(* port_discipline="electrical" *) mextram504
  q1 (node1, node2, node3, node4, (* port_discipline="thermal" *) nodet);

and on the individual ports (according to IEEE 1364-2005 A.4.1):

mextram504 q1 ((* port_discipline="electrical" *) node1,
               (* port_discipline="electrical" *) node2,
               (* port_discipline="electrical" *) node3,
               (* port_discipline="electrical" *) node4,
               (* port_discipline="thermal" *) nodet);

If the first item is not acceptable, the long-term solution would be to
request an update in IEEE 1364 and IEEE 1800 to allow attribute instances
also on the module instances in a module instantiation.

Cheers,
Marq




                                                                       
                                                                       
                                                                       
                                                                        To
                                       "Geoffrey.Coram"                
                                       <geoffrey.coram@analog.com>     
     "Martin O'Leary"                  "Marq Kole" <marq.kole@nxp.com> 
     <oleary@cadence.com>                                               cc
                                       "verilog-ams"                   
     05-09-2007 05:42                  <verilog-ams@eda-stds.org>      
                                                                   Subject
                                       RE: port_discipline             
                                                            Classification
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




I also don't think attributes should carry over like this. They are only
meant to apply to the object they proceed.

However a way to solve this issue is to allow the attribute on the
instance and on the port names.

The port_discipline attribute before a port binding would apply to that
port.

The port_discipline attribute before the instance would allow to apply
to all the ports unless overwritten by another port_discipline attribute
before a port binding.

Hence for the self heating device you would have;

mextram504 (* port_discipline="electrical" *) q1 ( node1, node2, node3,
node4,
               (* port_discipline="thermal" *) nodet);

Thanks,
--Martin

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Geoffrey.Coram
Sent: Tuesday, September 04, 2007 5:41 AM
To: Marq Kole
Cc: verilog-ams
Subject: Re: port_discipline

 > Another approach would be to have the port discipline of the first
port  > automatically apply to any successive ports, if those ports
following it  > do not have a port_discipline attribute specified. So:

In 1364-2005, does the attribute ever "carry over" in this fashion?
I suspect not, so I would be disinclined to make the discipline
attribute special in this way.

-Geoffrey

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





graycol.gif pic20020.gif ecblank.gif
Received on Wed Sep 5 02:01:19 2007

This archive was generated by hypermail 2.1.8 : Wed Sep 05 2007 - 02:01:23 PDT