Re: Fwd: [sv-dc] Generic interconnect

You can view AMS analog drivers (aka contributions) as just another user-defined type as far as the connection scheme goes. IMO all physical interconnect should be generic and collapsed, and connection (at ports) should only depend on having matching disciplines. Driver/receiver disciplines are orthogonal to driver/receiver type, so discipline resolution is independent of "net type". Disciplines used on wire segments that have no drivers/receivers should not be considered in resolution, but only for connection rules.

The port-bound stuff in Verilog-AMS which splits across ports is a legacy from having two simulators and a netlister driven by schematic capture at Cadence, and was never the right thing to do. The mere passage of time does not correct the fault.

The simple test for a working mixed-signal simulation methodology is: does my algorithm give me the same voltage everywhere on a physical wire? That doesn't happen if you do port-bound splitting/conversion, and it applies equally if you are doing discrete modeling of voltages.

The default behavior in a simulation language should be accurate-to-hardware, anything else will be expensive in Silicon.

Kev.

On 06/01/2011 01:34 PM, Ian Wilson wrote:
> Dave - thank you for forwarding this.
>
> This proposal appears to me to have significant impact on the feasibility
> of integrating SV with Verilog-AMS, since it must somehow interact with the
> AMS elaboration and net partitioning process.
>
> (On the other hand, the user-defined types part of the proposal seems to
> me to be less of a problem; I am expecting that we will be able to find a
> way to use the rich type and class mechanisms in SV to import disciplines
> in some way).
>
> Gordon places much emphasis on the port collapsing semantics of Verilog
> to remove complexity from the Generic Interconnect proposal. It may be that
> any port connection that would be regarded by AMS as a candidate for
> net splitting/connect module insertion is not collapsible, thus not a potential
> conflict (but if that is true, doesn't that restrict the domain of usefulness of
> Generic Interconnect severely)?
>
> It seems to me that there are two incompatible views of interconnect within
> the Verilog-AMS community:
> a) (the 'physical view'): interconnect does not affect the types of the drivers
> and/or loads on the net, and therefore should not be considered whe
> doing discipline resolution
> b) (the 'IP view'): disciplines and other attributes can be applied to interconnect;
> when present, these plays a primary role in discipline resolution
>
> Gordon's proposal probably has different implications depending on which of
> the above views you hold.
>
> We need to understand the potential impact of the proposal on the future
> feasibility of a Verilog-AMS integration with SV.
>
> --ian
>
> ----------------------------------
> Ian M Wilson
> Architect
> Berkeley Design Automation
> Office: 408-496-6600 x238
> Cell: 714-272-7040
> ian.wilson@berkeley-da.com
> http://www.berkeley-da.com
> ----------------------------------
> True SPICE accuracy, 5X-20X faster
> Don't Be Left Behind!
> ----------------------------------
>
>
>
>

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