RE: [sv-dc] Generic interconnect

Some quick questions/comments off the top of my head:

1. Do we expect the interconnects to derive their type information from their connections? In other words, can the interconnects be probed/accessed for value and type information?

2. We introduced a concept of "matching nettypes" in mantis 3398 (section 6.22.6). I assume nets with "matching nettypes" can be connected through an interconnect.

3. Imagine a case where a variable and a net with the same datatype are connected through an interconnect. Also, assume that the interconnect is connected to the port of the parent. In this case, does interconnect propagate a variable semantic or a net semantic through the hierarchies?

4. Are interconnects allowed to be vectors? If yes, are different bits of the interconnect vector allowed to have different types?

5. When conflicting nettypes are connected through interconnects, is the exact location of the error reporting left to the implementation? In other words, does the language need to provide guidelines on how the type propagation occurs through interconnects?

6. At this point, I am not sure if allowing interconnects to perform type conversions is a good idea. This will change their scope and complicate things very quickly.

7. Is the use of interconnects in certain behavioral constructs allowed?

    e.g. assign i1 = i2 (in the example below)

Thanks,
Abhi

+-----Original Message-----
+From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
+Gordon Vreugdenhil
+Sent: Tuesday, May 31, 2011 4:53 PM
+To: sv-dc@eda.org
+Subject: [sv-dc] Generic interconnect
+
+
+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.
+
+--
+--------------------------------------------------------------------
+Gordon Vreugdenhil 503-685-0808
+Model Technology (Mentor Graphics) gordonv@model.com
+
+
+--
+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.