Fwd: [sv-dc] Generic interconnect

Thought I should forward this to our group, as the concept of a generic
interconnect will have an impact on us, especially with connect module
resolution etc.

Would be good if we could all think about what Gordon is proposing and collect
our comments so that Ian can raise any concerns we have within the next SV-DC
meeting.

Regards
Dave

-------- Original Message --------
Subject: [sv-dc] Generic interconnect
Date: Tue, 31 May 2011 14:52:53 -0700
From: Gordon Vreugdenhil <gordonv@model.com>
To: sv-dc@eda.org <sv-dc@eda.org>

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.