Re: Draft 2 is now available - 7.10

From: Kevin Cameron <edaorg_at_.....>
Date: Sun Jan 06 2008 - 15:26:03 PST
You may well be able to do that for digital (SV), but for AMS it is
important that ports (on regular modules) are not considered drivers
when probing for values etc. for D2A calculations. If you consider the
each port down through the hierarchy as being a separate driver than it
would appear that you have multiple drivers (according to $driver_count)
when there is really only one.

For clarification we could say -

    For driver access functions a /driver/ of a signal is a process
    which assigns a value to the signal, or a connection of the signal
    to an output port of a simulation primitive.

In mixed-signal port connections need to be considered neutral
interconnect rather than as some kind of assignment because considering
them assignments would imply the insertion of unnecessary A2D/D2A elements.

For similar reasons I added the "alias" statement in SV to work around
the problem of people using explicit continuous assignments to connect
things when really a short-circuit is what is intended.

Kev.

Bresticker, Shalom wrote:
> In digital SV, the LRM says,
>  
>
> "Ports can always be represented as declared objects connected as follows:
>
> — If an input port, then a continuous assignment from an outside
> expression to a local (input) net or variables
>
> — If an output port, then a continuous assignment from a local output
> expression to an outside net or variables"
>
> and
>
> "Each port connection shall be a continuous assignment of source to
> sink, where one connected item shall be a signal source and the other
> shall be a signal sink. The assignment shall be a continuous
> assignment from source to sink for input or output ports."
>
> An exception is where port collapsing occurs.
>
> "all the ports through a hierarchy down to a process or primitive"
> would be a series connection of continuous assignments, unless port
> collapsing occurs.
>
> Shalom
>
>
>     ------------------------------------------------------------------------
>     *From:* owner-verilog-ams@server.eda.org
>     [mailto:owner-verilog-ams@server.eda.org] *On Behalf Of *Kevin Cameron
>     *Sent:* Sunday, January 06, 2008 11:14 AM
>     *To:* Verilog-AMS LRM Committee
>     *Subject:* Re: Draft 2 is now available - 7.10
>
>
>     Section 7.10 says -
>
>         A driver of a signal is a process which assigns a value to the
>         signal, or a connection of the signal to
>         an output port of a module instance or simulation primitive.
>
>     I think it should just say -
>
>         A driver of a signal is a process which assigns a value to the
>         signal, or a connection of the signal to
>         an output port of a simulation primitive.
>
>     Output ports on regular modules are not in themselves drivers just
>     connections to drivers. The implication of the current text is
>     that you would count all the ports through a hierarchy down to a
>     process or primitive as separate drivers.
>
>     Kev.
>
>
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean. 
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>   


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Jan 6 15:26:49 2008

This archive was generated by hypermail 2.1.8 : Sun Jan 06 2008 - 15:26:58 PST