The SV-DC group is currently looking at introducing a proposal to support generic interconnects. This will have an impact on Verilog-AMS so we should make sure that whatever is introduced it behaves how we would like it.

Proposal

Subject: [sv-dc] Generic interconnect
Date: Tue, 31 May 2011 14:52:53 -0700
From: Gordon Vreugdenhil

In the last DC meeting, I had agreed to try to write up a basic proposal or direction for the generic interconnect ideas that I had suggested a long time ago. Here is some of the basic idea in an outline form; sorry for the late posting on this; I had hoped to have time between getting back from Washington and today to get this out a bit more
carefully but life interfered....

The basic problem that I believe needs to be addressed is a separation between the "interconnect" as a topological connection point and the kind (or type) of value present on the connection. Strongly separating these allows one to leverage the user defined type mechanisms and other language mechanisms to create flexible design compositions.

Assume we add "interconnect" as the name of a net_type. Also assume that a user has a design in which they have a very simple digital logic abstraction for some leaf cells and a more complex model using user-defined nettypes. It would be valuable to have something like the following:

module top;

  interconnect i1, i2;

  child1 c1(i1,i2);

  child2 c2(i1);

  child3 c3(i2);

endmodule

and then to allow a user to use configurations to change child1, child2, and child3 between the simple logic library cells and a more complex set of library cells that use atomic nettypes for a more accurate model. Ideally we would not want to modify "top" but still allow configurations to change the models in a manner in which consistent abstractions will result.

My ideas for the basic rules for an interconnect would be as follows:
1) an interconnect can only be used as a net declaration, a port formal or a port actual
2) an interconnect must collapse in a port connection
3) collapsing an interconnect with an interconnect yields an interconnect
4) collapsing a non-interconnect with an interconnect yields the non-interconnect (i.e. the dominant type is the non-interconnect)

I think that is about all that is needed. The upshot of the rules I'm suggesting is that any configuration of a design in which the actual port connections yields valid results would be valid. If conflicting nettypes are connected via an interconnect, an error would result (i.e. connecting a logic to an atomic nettype).

If we end up extending port connections to deal with type conversions or similar, the rules here would likely not need to be changed as the effective port connections are really only processed at the point when concrete types are impacted. This should map directly onto whatever we end up with for type conversions.

The main result of this approach is that one could change from a model using logic to a model using a nettype consisting of a pair of reals without having to touch the netlist or modify the ports or interconnect declarations in any way.

Gord.

---

Comments - Ian Wilson

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

---

Comments - Kevin Cameron

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.

---

Q & A - SV-DC Meeting 1st June 2011

The SV-DC meeting on the 1st June discussed the genric interconnects and contains some very useful answers about how at least Gordon and SV-DC are viewing the construct.

I have included the relevent sections from the minutes below. The full meeting minutes can be found at:

http://www.eda.org/sv-dc/hm/0362.html

GV: See my e-mail to the reflector. I would like to see a distinction between a topological connection point and the port. It behaves like a net except it doesn't have a type associated with it. It is meant to describe pure interconnect. Should be able to declare and use in port connections and that is it. There are a few rules that I give about how these can be used. Initially we should require that they collapse. This makes a bunch of the rules relating to their end behavior simpler.

Interconnects go away and if the actual types are correct then everything will be fine. I think that everything works out if we require collapsing of interconnect.

This is a minimal set of things that allows people to do what they want. It should allow people to switch out models with various levels of abstraction without having to insert models in between to do port conversion work. That is the basic idea. I don't think this is a terribly complicated thing if we keep it down to this minimal set of capabilities.

AK: Can you elaborate on the type conversion?

GV: We haven't talked about type conversion yet. Eventually we will want to talk about type conversion or how to convert between dissimilar items. That is in the future. Right now there are strong rules that prevent that. I am somewhat optimistic that adding a basic for of generic interconnect won't cause problems. They are typeless, so it shouldn't impact decisions about where you do nettype conversions.

AK: It depends on how we design the type conversion, but if you have typeless interconnect that will affect it.

GV: The way it is defined things are collapsed, so it shouldn't cause a difference.

ShC: If you have several levels of hierarchy does it work top down or bottom up? What about the error message?

GV: It shouldn't matter. The error message may be different.

ShC: Right now in VAMS electrical is dominating. Could user-defined netttypes also be dominating over others?

GV: That could be defined. Right now those sorts of things aren't defined.

FM: Can you also declare a port of the child to be an interconnect?

GV: Yes.

AK: If you have an interconnect port of a given direction can it have a direction?

GV: Why does it matter? If it is going to force a collapse why does it matter?

SC: When you say it must collapse it means that the two ports must collapse. Do we want that?

GV: I think we do because it simplifies the rules. It may not be as flexible as we want long term, but I don't thinks it causes a problem.

AK: This is going to be restrictive from a user's perspective.

GV: I agree. This is a minimal set of functionality. If you want to connect a var port to a port using generic interconnect then you may need to wrap it. If we want to go further then some effort will be required to define the rules. I prefer to leave that for now if not for this entire PAR. Let's leave it as a clean set of rules and then come back when we know more unless we believe it is too deficient.

AS: In your example would it be sufficient to say that i1 and i2 use a specific configuration?

GV: You don't talk about configuring the interconnect. Assume configurations aren't in play. Somewhere in your library you have definitions for child1, child2, and child3. The code is either legal or not. If you have a configuration you can change the models. This gives you the advantage to change the models as long as the types remain consistent.

FM: On the top module there isn't really any debugging capability?

GV: Within the HDL, no. Within the tool it depends.

FM: If the user wants to have some code that makes sure everything happens correctly there is nothing they can do. It has to be put into the children.

GV: Correct. You can put the debug capability in a module and then bind it in. Then you would get an error if the ports aren't what you expect.

AK: Can we go over my e-mail questions?

GV: "1. Can the interconnects be probed/accessed for value and type information?" This is related to this debug question. My perspective is no. I don't want to have any implementation knowledge about the type within the HDL. I want to be able to reason and compile a module without any knowledge of the type. Of course, a vendor tool can expose all sorts of information.

AK: In current SV is there a concept of net properties or metadata that can be associated with a net?

GV: There are attributes.

AK: Can interconnects attach an attribute.

GV: Yes.

AS: Attributes don't have any defined behavior. I don't think you want to worry about that.

GV: From an AMS perspective what you would have to do is extend the port collapsing rules. If you want to say that an electrical connection is the dominant type and if you connect something that is illegal that is fine and you would have to define it. I am not defining it here, but I don't see anything that would conflict.

AK: I should be able to attach an attribute to an interconnect net?

GV: Sure.

AK: Can I query an attribute?

GV: Within the HDL, no.

FM: Within the VPI.

AS: I think you want to think about UPF and all of these. They contain the metadata.

AK: You are right. I am thinking in that direction.

AS: We may be wise to think about how the UPF properties may be associated.

AK: We may want to think about how to attach high level information to an interconnect.

GV: "2. I assume nets with "matching nettypes" can be connected through an interconnect." Yes.

AK: Fair to extrapolate by saying that if I am an interconnect that the only thing I can connect to is a matching nettype or other interconnect?

GV: There is a simpler definition. An interconnect can connect ports that are legal to collapse together. If it is legal to collapse then it is fine to do with an interconnect.

SC: Do the port collapsibility rules include port direction?

GV: No. Port directions are immaterial.

AK: I can't connect a variable port directly to an interconnect?

GV: No. That is a much more complex set of rules.

AK: I can have an interconnect that connects to two other interconnects?

GV: Sure. I think we have covered question 3.

FM: Can you have expressions?

GV: You could have concats, selects, but not addition. Only collapsible, structural expressions are permitted. That leads to "4. Are interconnects allowed to be vectors? If yes, are different bits of the interconnect vector allowed to have different types?" Sure. Because of the fact that this is purely interconnect, you just process the interconnect via collapsing rules and you can actually end up with a heterogeneous vector. Part of it is dealing with an accurate model and the rest of it is simple you could end up having bits 0-7 of the interconnect vector be a complicated type and the rest being logic. As soon as you allow the HDL do stuff with an interconnect then this type of thing is going to be problematic.

FM: When you say the different bits of the interconnect vector can have different types I am assuming the different bits are connected to different instances.

GV: Yep.

FM: You started by saying it is a new kind of nettype, but the resolution function is defined by what it is connected to?

GV: Sure it just follows the collapsing rules.

ShC: One assumption on a vector is that all the bits will have the same type? Isn't that a fair assumption?

GV: I am explicitly saying that this doesn't have to hold for generic interconnect. What I am saying now is that because I am not going to give you the ability to talk about the value I can be more flexible about how these things collapse and now give you a different type on the bits of the array because there is no way to talk about the individual bits.

ShC: What about packed or unpacked?

GV: It doesn't matter. They either collapse or they don't. When you start talking about collapsing rules on an individual simulation nets whether it is packed or unpacked doesn't matter. Just like wires now. If you have wires now and describe them as packed or unpacked it doesn't matter. The only time it matters are times when you are trying to use the entire wire as a value. Here you can't do that, so it doesn't matter.

GV: "5. When conflicting nettypes are connected through interconnects, is the exact location of the error reporting left to the implementation?" Error reporting is left to the implementation just like other error reports. If you want to report "Error in design" that is a legal error according to the LRM. A vendor would want to be more informative.


GV: "7. Is the use of interconnects in certain behavioral constructs allowed?" I don't want to allow assign, but I would be okay to allow alias statements. I don't want to allow any behavior at all. Partially b/c of the heterogeneous nature of vectors and partially b/c I don't want to do anything that relates to the type of the nets.

FM: Are we going to list the legal operators?

GV: No, the structural collapsing expressions are well defined. If we allow additional behavior then we have to define it.

FM: That would get complicated.

AK: In the assign are you assuming i1 and i2 are interconnect?

GV: No.

AS: I suspect there is not simulation semantics for the interconnects?

GV: No.

AS: If you compile it and don't configure it then should it work?

GV: I would be inclined to say that interconnect can't exist in the final design, but I could be okay with it if we define what they mean.

-- DavidMiller - 2011-06-14