Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Last revision Both sides next revision
language:connections [2019/04/18 14:10]
rajit [Array expressions] 		language:connections [2023/04/09 19:10]
rajit [Simple connections]
Line 14: Line 14:
 variables of type ''bool''. variables of type ''bool''.
  
-<code>+<code act>
 bool x, y; bool x, y;
 x=y; x=y;
Line 27: Line 27:
 parameters. parameters.
  
-<code>+<code act>
 pint x, y; pint x, y;
 x=5; x=5;
Line 36: Line 36:
 meta-language variables is not symmetric, as illustrated below. meta-language variables is not symmetric, as illustrated below.
  
-<code>+<code act>
 pint x, y; pint x, y;
 x=5; x=5;
 x=y*1+2; x=y*1+2;
 +</code>
 +<code>
 -[ERROR]-> id: y -[ERROR]-> id: y
            FATAL: Uninitialized identifier            FATAL: Uninitialized identifier
Line 49: Line 51:
 meta-language variable assignments. meta-language variable assignments.
  
-<code>+<code act>
 pint x; pint x;
 x=5; x=5;
 x=8; x=8;
 +</code>
 +<code>
 -[ERROR]-> Id: x -[ERROR]-> Id: x
            FATAL: Setting immutable parameter that has already been set            FATAL: Setting immutable parameter that has already been set
Line 72: Line 76:
 parameter variables as //immutable types//---they can only be parameter variables as //immutable types//---they can only be
 defined once. defined once.
 +
 +===== Assertions =====
 +
 +Sometimes it is useful to be able to check that a parameter (or an expression of parameters) has a reasonable 
 +value. To express this, ACT supports explicit assertions. We use Hoare's syntax for assertions, so the assertion that 
 +''x'' must be ''8'' would be written
 +<code act>
 +{x=8};
 +</code>
 +If a more meaningful message is required, the following syntax is also supported:
 +<code act>
 +{x=8 : "This assertion failed"};
 +</code>
 +which also reports the message specified when the assertion failed.
 +
 +During circuit development/debugging, it may be helpful to assert that two signals are connected to each
 +other or in fact disconnected from each other at a particular point during circuit construction. To assert that ''a'' is connected to ''b'', use:
 +<code act>
 +bool a;
 +bool b;
 +
 +{ a !== b : "a and b are connected connected!" };  // this will pass
 +a = b;
 +{ a === b : "a and b are not connected!" }; // this will pass
 +{ a !== b : "a and b are connected connected!" };  // this will fail
 +</code>
 +
 +The operators ''==='' and ''!=='' are used to check that the two signals are connected or disconnected at the point the  assertion was encountered during circuit construction.
  
 ===== Array and subrange connections ===== ===== Array and subrange connections =====
Line 82: Line 114:
 nodes ''y[10]'', ..., ''y[19]'' respectively. nodes ''y[10]'', ..., ''y[19]'' respectively.
  
-<code>+<code act>
 bool x[10]; bool x[10];
 bool y[10..19]; bool y[10..19];
Line 90: Line 122:
 Connecting two arrays of differing sizes is an error. Connecting two arrays of differing sizes is an error.
  
-<code>+<code act>
 bool x[10]; bool x[10];
 bool y[10..20]; bool y[10..20];
 x=y; x=y;
 +</code>
 +<code>
 -[ERROR]-> Connection: x = y -[ERROR]-> Connection: x = y
              LHS: bool[10]              LHS: bool[10]
Line 106: Line 140:
 ''y[16]''. ''y[16]''.
  
-<code>+<code act>
 x[3..7] = y[12..16]; x[3..7] = y[12..16];
 </code> </code>
Line 125: Line 159:
 so on. so on.
  
-<code>+<code act>
 bool x[3..4][5..6]; bool x[3..4][5..6];
 bool y[2][2]; bool y[2][2];
Line 134: Line 168:
 become aliases for each other. So while the connection statement become aliases for each other. So while the connection statement
  
-<code>+<code act>
 x[3..4][5..6] = y[0..1][0..1]; x[3..4][5..6] = y[0..1][0..1];
 </code> </code>
Line 143: Line 177:
 visible in the case of sparse arrays. visible in the case of sparse arrays.
  
-<code>+<code act>
 bool x[3..4][5..6]; bool x[3..4][5..6];
 bool y[2][2]; bool y[2][2];
 x = y; x = y;
 bool x[5..5][5..5]; bool x[5..5][5..5];
 +</code>
 +<code>
 -[ERROR]-> Array being extended after it has participated in a connection -[ERROR]-> Array being extended after it has participated in a connection
              Type: bool[ [3..4][5..6]+[5..5][5..5] ]              Type: bool[ [3..4][5..6]+[5..5][5..5] ]
Line 177: Line 213:
 it in braces. it in braces.
  
-<code>+<code act>
 bool x[3]; bool x[3];
 bool x0,x1,x2; bool x0,x1,x2;
Line 197: Line 233:
 (excluding the left-most dimension). (excluding the left-most dimension).
  
-<code>+<code act>
 bool x[5]; bool x[5];
 bool y[3]; bool y[3];
Line 211: Line 247:
 list of lower dimensional arrays enclosed in braces. list of lower dimensional arrays enclosed in braces.
  
-<code>+<code act>
 bool x[2]; bool x[2];
 bool y[2]; bool y[2];
Line 230: Line 266:
 row and one column from a two-dimensional array. row and one column from a two-dimensional array.
  
-<code>+<code act>
 bool row[4],col[4]; bool row[4],col[4];
 bool y[4][4]; bool y[4][4];
Line 241: Line 277:
 following is a valid connection statement: following is a valid connection statement:
  
-<code>+<code act>
 bool a[2][4]; bool a[2][4];
 bool b[4..4][4..7]; bool b[4..4][4..7];
Line 249: Line 285:
 </code> </code>
  
 +===== User-defined Type Connections =====
  
 +The result of connecting two user-defined types is to alias the two
 +instances to each other. A connection is only permitted if the two
 +types are compatible.
 +
 +==== Connecting identical types ====
 +
 +If two variables have identical types, then connecting them to each
 +other is a simple aliasing operation.
 +
 +==== Connecting types to their implementation ====
 +
 +If one type is an implementation of a built-in type, then they can be
 +connected to each other. The combined object corresponds to the
 +implementation (since the implementation contains strictly more
 +information). Consider the example below, where ''d1of2''
 +implements an ''int<1>''. 
 +
 +<code act>
 +int<1> x;
 +d1of2 y;
 +bool w;
 +
 +x=y;
 +
 +y.d0 = w; // success!
 +x.d1 = w; // failure
 +</code>
 +
 +While the first connection operation will succeed, the
 +''d0''/''d1'' fields of the ''d1of2'' implementation are not
 +accessible through variable ''x'' since ''x'' was declared as
 +an ''int<1>''.
 +
 +However, both ''x'' and ''y'' refer to the same object. For
 +example, consider the CHP body below that uses ''x'', ''y'', and
 +''w''. (Note: the situation we are discussing here is not a
 +recommended one. It is only being used to illusrate how connections behave.)
 +
 +<code act>
 +chp {
 +   x:=1;
 +   [w->skip [] ~w->x:=0];
 +}
 +</code>
 +
 +
 +Setting variable ''x'' modifies ''w'', since ''y.d0'' is
 +aliased to ''w'' and ''x'' is aliased to ''y''.
 +
 +If there are two different implementations of the same type,
 +attempting to connect them to each other is a type error. Suppose we
 +have two implementations of an ''int<2>'': ''d2x1of2'' which
 +uses two dual-rail codes, and ''d1of4'' which uses a one-of-four
 +code. Consider the following scenario:
 +
 +<code act>
 +int<2> ivar;
 +d1of4 x;
 +d2x1of2 y;
 +</code>
 +
 +Now the operation ''x=ivar'' is legal, and so is
 +''y=ivar''. However, if both connections are attempted, it is an
 +error. This is because one cannot connect a ''d1of4'' type to a
 +''d2x1of2'' type. This can get confusing, and is a problem for
 +modular design.
 +
 +To encapsulate this problem within the definition of a type, we impose
 +the following constraint: if a port parameter is aliased within the
 +definition of a type, then the type in the port list must be the most
 +specific one possible. This prevents this problem from crossing type
 +definition boundaries.
 +
 +Connecting subtypes is a bit more complicated, but not that different
 +from the rules for connecting implementations. Consider the following
 +situation, where ''bar'' and ''baz'' are both subtypes of ''foo''.
 +
 +<code act>
 +foo f1;
 +bar b1;
 +baz b2;
 +
 +f1=b1;
 +f1=b2;
 +</code>
 +
 +This would only succeed if there is a //linear// implementation
 +relationship between ''foo'', ''bar'', and ''baz''. In other
 +words, the connection succeeds if and only if either ''bar <: baz''
 +or ''baz <: bar'', and the the object it represents corresponds to
 +the most specific type.
 +
 +If ''bar'' and ''baz'' are not linearly related, the connection
 +fails even though individually the operations ''f1=b1'' and
 +''f1=b2'' would have succeeded. To avoid having this situation
 +escape type definition boundaries, types used in the port list must be
 +the most specific ones possible given the body of the type.
 +
 +==== Port connections ====
 +When instantiating a variable of a user-defined type, the variables in
 +the parameter list can be connected to other variables by using a
 +mechanism akin to parameter passing.
 +
 +<code act>
 +defproc dualrail (bool d0, d1, a)
 +{
 +  spec {
 +    exclhi(d0,d1)  // exclusive high directive
 +  }
 +}
 +  
 +bool d0,d1,da;
 +dualrail c(d0,d1,da);
 +</code>
 +
 +In the example above, nodes ''d0'', ''d1'', and ''da'' are
 +connected to ''c.d0'', ''c.d1'', and ''c.da'' respectively.
 +Nodes can be omitted from the connection list. The following statement
 +connects ''d1'' to ''c.d1'' after instantiating ''c''.
 +
 +<code act>
 +dualrail c(,d1,);
 +</code>
 +
 +Since parameter passing is treated as a connection, all the varied
 +connection mechanisms are supported in parameter lists as well.
 +
 +Two other mechanisms for connecting ports are supported. The first
 +mechanism omits the type name.  The example below is equivalent to the
 +one we just saw.
 +
 +<code act>
 +dualrail c;
 +
 +c(,d1,);
 +</code>
 +
 +While this may appear to not be useful (since the earlier example is
 +shorter), it can be helpful in the context of array declarations. For
 +example, consider the following scenario:
 +
 +<code act>
 +dualrail c[4];
 +bool d1[4];
 +
 +(i:4: c[i](,d1[i],); )
 +</code>
 +
 +A second mechanism is useful to avoid having to remember the order of
 +ports in a process definition. Instead of using the port list of the
 +form where we simply specify the instance to be passed in to the port,
 +we can instead use the following syntax.
 +
 +<code act>
 +bool d1;
 +dualrail c(.d1=d1);
 +
 +dualrail x[4];
 +bool xd1, xd0;
 +
 +x[0](.d1=xd1,.d0=xd0);
 +</code>
  
language/connections.txt · Last modified: 2023/04/09 19:13 by rajit
Except where otherwise noted, content on this wiki is licensed under the following license: GNU Free Documentation License 1.3


  • Show page
  • Old revisions
  • Backlinks
  • Recent Changes
  • Media Manager
  • Sitemap