Combinational cycle wrongly detected on array assignement

[Daemiryon]

This following design lead to a combinational cycle :

// In place array sum rediction
unit main(output uint8 leds)
{
	int16 X[8]={1,2,3,4,5,6,7,8};
	algorithm
	{
		X[0] = X[0] + X[4];
		X[1] = X[1] + X[5];
		X[2] = X[2] + X[6];
		X[3] = X[3] + X[7];
++:
		X[0] = X[0] + X[2];
		X[1] = X[1] + X[3];
++:
		X[0] = X[0] + X[1];
		__display("%d",X[0]);
	}		
	
	
}

[sylefeb]

Hi, so you've hit a current limitation of Silice (edit: to be nuanced, be sure to read follow-up comment): it does not know how to detect combinatorial cycles through either members of tables or bits accesses independently ; from the point of view of Silice accessing any part of X mean it has been previously accessed. This is a limitation that cannot easily be solved for now (due to the structure of the code) but that would be the main focus of a next iteration of Silice.

[sylefeb]

Additional note: the design above could be easily determined, because all indices are constant. However, indices can also be coming from variables / expressions, meaning the compiler cannot easily determine the combinational chain:

X[i] = some_input & mask;
X[j] = X[i] * 4;
...

If i and j are distinct this is all fine, if i == j this is a cycle.
The only thing the compiler can do here (pending some complex + costly determination of actual possible values for i and j akin to formal checks) is to assume a combinational cycle could exist and therefore conservatively reject this.

So to complete my previous comment, this is a limitation of Silice when indices are indeed constant. This however is not a rare case in particular when using bit-fields / part-selects.