Mixed Signal Support

Proposal Information

• Who Updates: KevinCameron, ...
• Date Proposed:
• Date Last Updated:
• Priority:
• Complexity:medium
• Focus:

Proposal

A. Support flat resolution by just using terminals for all connecctions and moving (discrete) driver type declarations to the architecture.

B. Allow marking conversion functions as lossy/lossless

C. Automatically allow up (lossless) conversions with mixed drivers to get all drivers to the same type (for resolution)

D. Implicit declaration of A/D conversion entities - users supply architectures for stateful conversions (as per Verilog-AMS methodology), or functions for stateless conversions.

E. Allow automatic lossy (down) conversion to receivers with warnings.

Requirement Summary

Suport plug-and-play rather than strict typing on connections.

Rationale

Existing connection scheme is too awkward to use in practice.

Related Issues: None = General

Too many to list.

Competing Issues: None at this time

Politics, no EDA company wants a product that does everything, it makes incremental licensing too hard.

Requirement details

Inject (analog) parasitics into an existing description (without changing types) while maintaing Kirchoff's current law.

Use Model

Just describe your circuit and have it work.

Arguments FOR

Long overdue.

Arguments AGAINST

?

General Comments

This is a generalization of resolution: all drivers of a wire need to be converted to a common type to be resolved - peferably losslessly, and after resolution the result is converted back to the receivers at the accuracy requested. I.e. driver and receiver type do not need to match on a wire, that allows modeling at high levels of abstraction and then mixing in lower level components like parastics (resistors and capacitors) wthout other major changes to the users description.

The major syntactic change is dropping the driver type declaration (usually combined with the port declaration) down to the architecture level. The minor addition is the tagging of conversion functions as lossy/lossless.

Note: requiring port direction is a user feature of the driver/receiver type, not an intrinsic attribute of a port connection.

Supporters

Add your signature here to indicate your support for the proposal