====== The refine sublanguage ====== The ''refine'' sub-language takes the form refine { /* any standard ACT body element can appear here */ } This is used to provide an implementation of a process that replaces the CHP, dataflow, HSE, or PRS body. For example, imagine you had a process defined at the CHP level defproc example (...) { int x; chp { *[ L?x; R!x ] } } You can include its production-rule level description in the same process definition, as follows: defproc example (...) { ... chp { *[ L?x; R!x ] } prs { // circuit goes here } } At this point, a tool can select the level of abstraction/detail for the process by picking one of the two sub-languages provided. Now imagine that instead of writing the production rules directly, you'd like to instantiate a set of gates to implement the circuit. Suppose we write the following: defproc example(...) { ... chp { *[ L?x; R!x ] } inst1 i1; inst2 i2; // the other instances and connctions... } As written, this means that the process has a CHP definition, and //in addition// it has the specified instances! This is not what we intended to specify; we'd like to use the CHP definition //or// the instances. To provide support for this, the ''refine'' body is used. The example would be written: defproc example(...) { ... chp { *[ L?x; R!x ] } refine { inst1 i1; inst2 i2; // the other instances and connctions... } } Now you can //pick// the refined version of the process by using the ACT command-line option ''-ref=1'', and so a tool can pick either the ''chp'' or the ''refine'' sub-language, giving us the desired effect. This approach is used in the ''chp2prs'' tool to provide an implementation of the CHP. This is the standard convention used in any tool that takes CHP and generates a circuit-level description. By augmenting the definition of the process in this manner, you can model the process at both the CHP level of abstraction as well as a more detailed representation containing a collection of instances that implement the CHP.