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.