Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Instantiation of feature group connections can create unnecessary connection instances #2059

AaronGreenhouse opened this issue Nov 12, 2019 · 1 comment


Copy link

Consider the example below:

  • There is a feature group with both a port feature and a data access feature
  • The feature groups is used as a on a thread
  • The thread has a data subcomponent that is connected to the data access feature of the feature group

The instance model will have

  • A connection instance (through the feature group connection) that goes directly to the data subcomponent (as fixed in issue Shared subprogram access yields too many connection instances in instance model #2032)
  • Two connection instances consisting of just the feature group connections: one between the data sub features and one between the subprogram access features of the feature groups. These exist because the port connection and the fact that we stop at edge of thread for port connections we will create a connection instance between the thread and the other thread. This is good. But because we unwrap the contents of the feature group, we also end up with a connection instance between the two data access features of the threads.
package ExtraConnection
    feature group FG1
    		output: out data port;
    		shared_sub: provides subprogram access;
    end FG1;
    feature group FG2
    		input: in data port;
    		provided_sub: requires subprogram access;
    	inverse of FG1
    end FG2;
    thread T1
    		fg1: feature group fg1;
    		output: out data port;
    		shared_sub: provides subprogram access;
    end T1;
    thread implementation T1.i
    		s: subprogram;
    		xxx: subprogram access s <-> fg1.shared_sub;
    		yyy: subprogram access s <-> shared_sub;
    end T1.i;
    thread T2
            fg2: feature group fg2;
            input: in data port;
            provided_sub: requires subprogram access;
    end T2;
    thread implementation T2.i
    end T2.i;
    process p
    end p;
    process implementation p.i
            t1: thread t1.i;
            t2: thread t2.i;
            cc: feature group t1.fg1 <-> t2.fg2;
            dd1: subprogram access t1.shared_sub <-> t2.provided_sub;
            dd2: port t1.output -> t2.input;
    end p.i;
    system Root
    end Root;
    system implementation Root.impl
            p: process p.i;
    end Root.impl;
end ExtraConnection;

Thus we have an extra data access connection that we shouldn't have and isn't present if you do the same with with just features and not feature groups. The above example has the following connections currently:

Screen Shot 2019-11-12 at 1.19.12 PM.png

The unwanted extra connection instance is t1.fg1.shared_sub -> t2.fg2.provided_sub.

Lutz suggests the following to deal with this problem:

Is the longer correct connection always inserted before the shorter incorrect one? The we could brute force it by comparing the shorter connection to all existing connections and not inserting it if it's contained in an existing one. IIRC we have similar code to detect duplicates, already.

Copy link

lwrage commented Jan 3, 2020

Fixed in 16b4255 (and 1b43a6a)

@lwrage lwrage closed this as completed Jan 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

2 participants