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

Instantiator merges access connections #676

Closed
joeseibel opened this issue Feb 17, 2016 · 5 comments · Fixed by #1979
Closed

Instantiator merges access connections #676

joeseibel opened this issue Feb 17, 2016 · 5 comments · Fixed by #1979
Assignees
Milestone

Comments

@joeseibel
Copy link
Contributor

@joeseibel joeseibel commented Feb 17, 2016

Consider the following model:

package pkg
public
    abstract aType
        features
            da: requires data access;
    end aType;

    system s
    end s;

    system implementation s.i
        subcomponents
            d: data;
            a: abstract aType;
            b1: bus;
            b2: bus;
        connections
            conn1: data access d -> a.da;
            conn2: data access a.da -> d;
        properties
            Actual_Connection_Binding => (reference (b1)) applies to conn1;
            Actual_Connection_Binding => (reference (b2)) applies to conn2;
    end s.i;
end pkg;

When instantiated, there is only one ConnectionInstance created. It is a bidirectional connection which is the merger of conn1 and conn2. Is this the correct thing for the instantiator to do? If so, what should the value of Actual_Connection_Binding be in the instance model?

@lwrage
Copy link
Contributor

@lwrage lwrage commented Aug 19, 2019

Check if not merging fixes issues with flows through access connections.

@lwrage lwrage added this to the 2.6.0 milestone Aug 27, 2019
@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 27, 2019

Merging happens in CreateConnectionSwitch.addConnectionInstance()

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 29, 2019

So this is interesting: If I have an explicit declarative bidirectional access connection, it creates a single unidirectional connection instance.

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 29, 2019

I shut off the merging of access connections into a single bidirectional connection. This seems to fix Issue #643.

But, as said bidirectional declarative access connections are not always instantiated correctly. Consider

package test_access_connections
public
    abstract aType
        features
            da: requires data access;
    end aType;

    system s
    end s;

    system implementation s.i
        subcomponents
            d1: data;
            a1: abstract aType;
            
            d2: data;
            a2: abstract aType;
            
            d3: data;
            a3: abstract aType;
            
            d4: data;
            a4: abstract aType;
            
            d5: data;
            a5: abstract aType;
    	connections
    		-- We connect both ways -- Should not be merged anymore
            conn1a: data access d1 -> a1.da;
            conn1b: data access a1.da -> d1;

			-- Bidirectional, should have 2 connection instances
			conn2: data access d2 <-> a2.da;
			
			-- Bidirectional, should have 2 connection instances
			conn3: data access a3.da <-> d3;
			
			conn4: data access d4 -> a4.da;
			
			conn5: data access a5.da -> d5;            
    end s.i;
end test_access_connections;

There should be two connection instances generated from conn2, and two generated from conn3. For conn2 we only get a connection instance for "d2 -> a2.da". Strangely, conn3 gives both connection instances.

The equivalent example using ports instead of data access creates the expected connections in all cases:

package test_regular_connections
public
    abstract aType
        features
            f1: in out event port;
    end aType;
        
	system s		
	end s;

    system implementation s.i
    	subcomponents
    		s1a: abstract aType;
    		s1b: abstract aType;
    		
    		s2a: abstract aType;
    		s2b: abstract aType;
    		
    		s3a: abstract aType;
    		s3b: abstract aType;
    		
    		s4a: abstract aType;
    		s4b: abstract aType;
    		
    		s5a: abstract aType;
    		s5b: abstract aType;
    	connections
    		-- connect both ways. should not be merged, should have 2 connection instances
    		conn1a: feature s1a.f1 -> s1b.f1;
    		conn1b: feature s1b.f1 -> s1a.f1;
    		
    		-- bidirectional, should have two connection instances
    		conn2: feature s2a.f1 <-> s2b.f1;
    		
    		-- bidirectional, should have two connection instances
    		conn3: feature s3b.f1 <-> s3a.f1;
    		
    		conn4: feature s4a.f1 -> s4b.f1;
    		
    		conn5: feature s5b.f1 -> s5a.f1;
    end s.i;
end test_regular_connections;

@AaronGreenhouse
Copy link
Contributor

@AaronGreenhouse AaronGreenhouse commented Aug 30, 2019

Above problem is submitted as Issue #1977

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants