RE: [sv-dc] Generic interconnect

Gord,
Here is an example for our discussion:

           top.w
      | |
top.I1.w1 top.12.w2

w - interconnect
w1 - nettype1
w2 - nettype2

Lets say we have semantics in future to convert between types nettype1 and nettype2.

Possibilities are:

1. top.w and top.I1.w1 collapse first, conversion happens at top.w and top.I1.w2 boundary

2. top.w and top.I2.w2 collapse first, conversion happens at top.w and top.I1.w1 boundary

Depending on collapsing rules, the place of conversion changes.

Eg: Testbench monitoring or TCL interfaces which query on top.w can get different values.

If we leave those implementation, they could confuse the users.
cheers,
Shekar.

-----Original Message-----
From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Wednesday, June 01, 2011 7:16 AM
To: Abhi Kolpekwar
Cc: sv-dc@eda.org
Subject: Re: [sv-dc] Generic interconnect

On 6/1/2011 7:05 AM, Abhi Kolpekwar wrote:
> 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?

No, at least I don't. The only thing I am allowing is declaration and port connection.

Of course a vendor tool (such as a debugger) could and should provide more information, but *within the HDL* there should be not value/type inspection allowed as that would defeat separate compilation and the independence of the interconnect netlist.

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

Of course -- that follows from my suggested collapsing rules.

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

That wouldn't be allowed under my suggested rules. At least what I've suggested requires collapsing. Getting away from that is a bit more troublesome as one would have to deal with various "direction" issues that become problematic in some cases.

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

Sure -- just follows normal collapsing rules which are defined on a per-connection basis. Note that this means that the effective type of an array of interconnect could be heterogeneous. Yet another reason to say "no" on point 1.

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

As with any "error" or "illegal" statement in the LRM, the details of how such an illegal state is reported is up to the implementation.

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

I'm not sure that I understand your point/question here. Could you clarify this?

> 7. Is the use of interconnects in certain behavioral constructs allowed?
>
> e.g. assign i1 = i2 (in the example below)

Note in what I've proposed. I would be Ok with allowing "alias i1 = i2;" as that is just a directed collapse, but I would prefer to avoid having anything else. I don't think it is impossible, but it will complicate lots of other areas in the LRM (expression and assignment rules for example). Unless there is a compelling reason to do so, I'd prefer to avoid that at this point.

Gord.

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

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