Back to the Contents of PARTHENON User's Manual

6. Logic Synthesizer: SFLEXP

6.1 Starting SFLEXP
6.2 Dealing with Errors
6.3 External Terminals and Component Elements of the Initial Circuit Produced by SFLEXP
6.4 Practical Logic Synthesis

SFLEXP (SFL EXPander) reads SFL files and performs logic synthesis for each SFL module.

SFLEXP produces the resultant netlist in the form of a file in HSL language. Although the netlist description language in PARTHENON is NLD, SFLEXP adopts HSL for historical development reasons. However, designers need not learn HSL because an HSL file can easily be converted into an NLD file using HSL_NLD.

Logic synthesis results given in NLD are transferred to the following programs for logic compression and assignment of components.


6.1 Starting SFLEXP

Let's take a simple example of logic synthesis from an SFL description.

To begin logic synthesis for the above files, enter the following at MS-DOS command prompt A>.

A>sflexp abc.sfl abc.hsl

A large number of messages will be output in response. The following message, on the second line from the bottom of the message list, indicates that the logic synthesis has been executed correctly.

There are 0 errors.
The format of the command for starting SFLEXP is as follows:

sflexp sfl_file_name hsl_file_name [switch ...]

sfl_file_name : name of SFL source file for logic synthesis

hsl_file_name : name of HSL file in which the netlist is to be output

switch ::= {-single | -multi | -nopost}
| {-nld | -nonld}
| -fin param
| -level_factor param
| -mem param

As many switches as desired may be specified in random order. If a particular switch is omitted, the first of the options listed above is assumed for the selective switches, and default values are assumed for the switches specifying param.

The following describes each switch.

(1) -single | -multi | -nopost

SFLEXP performs logic synthesis for each SFL module in two steps. First, it converts the SFL module into an initial structure, simplifying the logic at the same time. It then performs "logic simplification" a second time. The latter is called post-opt processing, and it allows "Write collision" to be discovered. Post-opt processing is controlled by the -single | -multi | -nopost switch.

'-single' specifies execution of post-opt processing for every action. The word, action, here means the write enable logic of a register or the select logic of a selector.

'-multi' specifies that post-opt is to be batch-processed for all actions.

'-nopost' specifies that no post-opt processing is to be executed.

Among these three switch options, '-multi' might appear the best selection. However, while '-multi' indeed simplifies the entire logic of the module and thus reduces the circuit well, it causes the following problems:

In general, therefore, '-single' yields better results, and so the default is '-single.'

(2) -nld | -nonld

'-nld' specifies that SFLEXP should output not only the netlist synthesized from the SFL module but also the netlist of selectors and registers having bit widths greater than one (described as logic cells that can be disassembled in Section 4.3

'-nonld' specifies that SFLEXP should output only the netlist synthesized from the SFL module

(3) -fin param

After it converts a logic procedure in the SFL module into a logic structure, SFLEXP converts 'and' and 'or' logic elements into 'nand' and 'nor' logic elements. This is because 'nand' and 'nor' are more closely related to physical logic gates. During this conversion, the types of 'nand' and 'nor' gates used in the circuit can be limited in terms of the number of inputs. Since the number of inputs is referred to as the number of fin-ins, the switch name is 'fin.' For example,

-fin 5

indicates that 'nand' and 'nor' gates with 2 to 5 inputs are to be used. If '1' is specified, no conversion from 'and' and 'or' to 'nand' and 'nor' is made and the fin-in number is not limited. If 'fin' is not specified, the default value of 8 is used.

(4) -level_factor param

During logic synthesis, SFLEXP extracts and bundles common logic parts. This process forces the logic to be composed in multi-level logic gates, thus reducing the area of logic circuit. The downside of this process is that sometimes the number of logic levels becomes excessive. If it happens in the critical path of the arithmetic circuit, overall LSI performance is degraded. This switch is thus used to control the degree of extraction of common parts.

The '-level_factor' switch indicates that potential logic part extraction is not to be performed if the number of inputs that can be reduced by bundling it is only as large as param.

For example:

-level_factor 3

indicates that, if a certain extraction would reduce the number of logic gate inputs by only 3, it is not to be performed. If 'param' is '0,' extraction is performed as long as it is effective. If 'param' is not specified, the default value of 0 is used.

(5) -mem param

Since SFLEXP requires advanced programming using list processing and pattern matching, the logic synthesis part is written in the Prolog language. The Prolog processing requires a static memory area for making stacks.

The remainder is written in the C language for high-speed operation. This portion requires a dynamic heap area.

In consequence, SFLEXP requires both:

If Prolog's memory area becomes insufficient, a 'static overflow' message is output. If C runs short of dynamic memory, a 'general protection violation' message is output. The amount of each type of memory needed depends on each SFL description. This switch is provided to control the memory area.

The -mem switch determines how large a static area is to be allocated for Prolog. The rest of the area is allocated for C.

The area to be used as the Prolog stack area is defined by assigning 'param' the values sss, ss, s or m, as below.

For settings sss, ss, s and m in param, the following amounts of memory are allocated:

If the available memory size is 3MB, 5MB, 10MB, or 14MB or more, sss, ss, s, and m should be specified, respectively.


6.2 Dealing with Errors

The following problems may occur during logic synthesis.

(1) Syntax error
(2) Overflow
(3) Write collision error
(4) State transition error due to the non-existence of the state specified as the transition destination

(1) Syntax error

SFLEXP starts by reading the SFL description. Errors detected in the SFL description during this process are called syntax errors.

If a syntax error is detected, an error message such as the following is output:

??? The facility name: xx (in operation) is not defined.
After that, the following message is output:
"Press any key when ready."
If you press a key, the editor is activated to allow you to correct the error.

The editor activation mechanism is specified in file 'sfl_edit.bat' in %PARTHENON%\com. The editor can be changed. (The default editor is Village Center's Vz Editor, and it is assumed that Vz Editor is installed in the directory indicated by the activation path.) When the editor is activated, the cursor is positioned in the line where the error has been detected. If you press the F4 key, the line and letter where an error may exist is displayed.

After you have corrected the error, close the editor, and type 'r.' The analysis recommences from the point where the correction was made. 'r.' is an SFLEXP sub-command indicating retry.

The only sub-commands allowed here are the following:

r. :retry
a. :abort
h. :help
Entering 'a.' terminates SFLEXP at that point. If the following message appears during the entry of an SFLEXP sub-command
prolog: syntax error at LINE=2, COLUMN=0
repeat the following several times
.<CR> (period followed by return)
until you see ":" displayed as an input prompt. Then enter the sub-command. The errors that can be detected at this point are:

Unless a syntax error is detected, logic synthesis begins immediately. Since logic synthesis involves many steps, numerous messages are displayed to assure you that the program has not entered an endless loop. Although they have a meaning, you can normally ignore them.

(2) Overflow

While a software compiler only "converts one procedure to another," logic synthesis "converts a procedure to a structure" , and in doing so, is required to simplify logic expressions. Depending on the detail of the SFL description, this process sometimes requires such a huge amount of memory and calculation that overflow can occur, , even if the SFL description is correct. If an overflow occurs, you must change the description. For further details on overflow, see Section 6.4.

(3) Write collision error

A write collision error may be reported when there is a problem in the SFL description. If the error count displayed just before the completion of the SFLEXP execution is not 0, then either a write collision error or a state transition error has been detected.

<List 6.1> Example of a description causing a write collision error

 1:	module ng1 {
 2:	    input a<8>;
 3:	    input b<8>;
 4:	    input c;
 5:	    instrin start;
 6:	    reg r<8>;
 7:	    instrin start any {
 8:	        c: r:=a;
 9:	        c: r:=b;
10:	    }
11:	}

In this example (List 6.1), the assignments to register 'r' specified in the 8th and 9th lines always cause a collision. Of course, a complete simulation should have detected the problem. However, since the simulator cannot report errors unless the conditions for a collision have been set up, the simulation may miss such errors. In contrast, logic synthesis develops and sorts out all logic issues, and thus can detect a collision caused by the assignment to register 'r.' The error message would appear as follows:

???ERROR data collision must occur, because select condition becomes 'true' in action(2) ???
This allows you to identify the action from 'id' in 'action(id).' As described above in discussing the post-opt process, action denotes "writing into a register," etc. Although this section does not go into details about how to trace the source of the error, you may find a clue by looking carefully at the portion around the error message. Until you get really experienced, the best advice for finding the causes of errors is to review the SFL description.

(4) State transition error

A state transition error, where the specified transition destination is non-existent occurs when, as shown in List 6.2, there is a description (goto statement) indicating a transition to the only effective state (only st1 is effective since a transition to st2 never occurs). In such a case, the logic synthesis cannot proceed correctly, and a state transition error is output.

A transition from one state to the same state is equivalent to no transition, and you should never write such a transition, since it is meaningless.

<List 6.2> An example of a description where an error occurs due to a meaningless state transition

 1:	module ng2 {
 2:	    stage_name s {
 3:	        task t();
 4:	    }
 5:	    stage s {
 6:	        state_name st1;
 7:	        state_name st2;
 8:	        first_state st1;
 9:	        state st1 goto st1;
10:	        state st2 goto st2;
11:	    }
12:	}


6.3 External Terminals and Component Elements of the Initial Circuit Produced by SFLEXP

SFLEXP converts an SFL description into a circuit (the initial circuit) for each SFL module. As was mentioned earlier, logic cells are used for the component elements in the initial circuit, which is then optimized by the OPT_MAP, RINV and ONSET programs and finally converted into a circuit consisting of only real cells. This section (6.3) and the following section (6.4) explain more about the initial circuit.

This section describes the component elements in the initial circuit, which are directly associated with the SFL component elements, and the fixed connections, which are independent of the SFL description of operation. Section 6.4 describes how the various SFL operation descriptions are converted into connections between component elements.

• External terminals of a module

The external terminals of the initial circuit (nld module) include the following four external input terminals in addition to the external terminals specified in the SFL module.

p_reset power-on reset
m_clock master clock
s_clock slave clock
b_clock bus clock

The types of the external terminals in the initial circuit correspond to the terminal types in the SFL module as follows:

<Terminal type in the SFL module> <Terminal type in the initial circuit>
Data input terminal and control input terminal -> External input terminal
Data output terminal and control output terminal -> External output terminal
Bidirectional data terminal -> External bidirectional terminal
• Sub-modules and external terminals of sub-modules

A sub-module in SFL becomes a sub-module in the initial circuit. The sub-module instance name is the same as the instance name in SFL. The external terminals of the sub-module include the above four terminals (p_reset, m_clock, s_clock and b_clock) in addition to the external terminals of the SFL sub-module.

• Data registers

The data registers defined in SFL by key words 'reg', 'reg_wr' and 'reg_ws' become data registers 'reg-N,' 'regr-N' and 'regs-N' for the logic cells in the initial circuit. The instance names are the same as the SFL instance names. (KDF I didn't understand the reason for the brackets, so I have changed it to read more naturally.)

• State registers

The stages and segments in SFL become as many as log2N 'reg--1' state registers where N is the total number of states in the stage (including the number of segment states). The instance name is "stage name-bit_posi" or "stage name-segment name-bit_posi," where bit_posi is 0, 1, 2, ...

• Task register

Task register 'reg---1' with the instance name "stage name-all" is generated from the SFL stage. A task in SFL becomes task register reg---1 with the instance name "stage name-task name."

• Connections of resets and clocks

The p_reset, m_clock, s_clock and b_clock terminals of sub-modules and logic cells (data register, state register and task register) are directly connected to the p_reset, m_clock, s_clock and b_clock terminals of the module. That is, the polarity of the reset signals and clock signals, and the significance of pulse waveforms are not defined in PARTHENON programs. The information on them is given in the cell library.

For example, suppose a register of an edge trigger type using a single clock is adopted and 'm_clock' is used as a clock terminal in designing or selecting a cell library. This information is described in PCD and transferred to OPT_MAP, and the OPT_MAP function deletes the 's_clock' terminal and its connections from the final circuit.

• Bus driver circuit for a bidirectional terminal and insertion of a selector

The external bidirectional terminals of a module or a sub-module are connected to and driven by bus driver circuit 'bdrv-N.' Their instance names are respectively: bidirectional data terminal name-drive, and sub-module name-bidirectional data terminal name-drive. If multiple transfer sources are connected to a bidirectional data terminal, selector 'slN-M' is inserted in front of the bus driver circuit.

• Insertion of a selector before an output terminal

If only one transfer source sends data to a data output terminal, the transfer source is directly connected to the external output terminal in the initial circuit. If there are multiple transfer sources, a selector is inserted in front of the external output terminal.

• Register selector insertion

If multiple transfer sources send data to a register, a selector is inserted in front of the input terminal of the register.

• Cell name and instance name of inserted selectors

Logic cells 'slN-M' are used as the inserted selectors, and their instance names are sel-1, sel-2, ...

• Internal control terminal

The internal control terminal in SFL becomes relay terminal 'inst-dum' for control in the initial circuit. The instance name is the same as the internal control terminal name in SFL. If the internal control terminal is activated from more than one place, an 'or' gate is inserted in front of 'inst-dum.'

• Internal data terminal (situations where there are multiple data transfer sources)

If there are multiple data transfer sources, internal data terminals defined with 'bus_v', 'bus', 'sel_v' or 'sel' are converted into 'bsN-M' or 's1N-M' as follows.

bus_v or bus --> bsN-M (3-state data selector)
sel_v or sel --> slN-M (and-or data selector)
The instance names of 'bsN-M' or 'slN-M' are the same as the internal data terminal names in SFL.

Internal data terminals defined with 'bus_v' and 'sel_v' may be eliminated during logic compression. In that case, they do not appear in the initial circuit.

• Internal data terminal (situations where there is only one data transfer source)

If there is only one data transfer source, an internal data terminal defined with 'sel' or 'bus' is converted into a data relay terminal 'bus-N'. The instance name of 'bus-N' is the same as the internal data terminal name in SFL.

• Logic gate, constant

The instance names of logic gates and constants generated from SFL operation descriptions are as follows:

	<Logic cell name>	<Instance name>

	high-		high-
	low-		low-
	inv-		inv-1, inv-2, inv-3, ...
	and--M		and-1, and-2, and-3, ...
	nand--M		nand-1, nand-2, nand-3, ...
	or--M		or-1, or-2, or-3, ...
	nor--M		nor-1, nor-2, nor-3, ...
	eor--2		eor-1, eor-2, eor-3, ...




6.4 Practical Logic Synthesis

We stated earlier that logic synthesis is the "conversion of a procedure into a structure, unlike a software compiler, which converts one procedure into another." In reality, logic synthesis operates by having a template ready for each SFL syntax or element and executing conversion of these one by one. However, without a high level of optimization, it is difficult to select appropriate templates. Thus, logic simplification can be said to be a key technique in logic synthesis (although this document does not go into the details of this subject).

As described in Section 6.3, SFLEXP converts the elements corresponding to actual entities (e.g., registers) directly into logic cells and interconnects them through control logic. During this conversion, selectors may be inserted as necessary to enable data selection.

• Example in which control and data are separated

Let's synthesize List 6.3 in a batch program as follows:

    sflexp %1.sfl %1.hsl
    mkdir %1.1st
    hsl_nld %1.hsl %1.1st
    nld_ps -o %1.ps %1 %1.1st %PARTHENON%/CELLDEMO/START
    type %1.ps > prn

Since OPT_MAP, ONSET and RINV are not included for execution, circuit optimization may be insufficient. However, SFLEXP output may be more easily understood with this program example. This batch program requires a PostScript printer.


<List 6.3> Example in which control and data are separated

 1:	module test1 {
 2:	    input abc;
 3:	    bidirect xyz;
 4:	    instrin start;
 5:	    instruct start xyz = abc;
 6:	}

The logic synthesis result is shown in Figure 6.1.

<Fig 6.1> Logic synthesis result of List 6.3

Since a value is set to bidirectional data terminal 'xyz' in this example, 'bdrv-1' is inserted in front of 'xyz' and its output 'out' is connected to 'xyz.' Since 'abc' is the only input to 'xyz' , 'abc' is simply connected to input 'in' of 'bdrv-1.' Since the timing of setting a value to 'xyz' is when 'start' is "1," 'start' is connected to 'enb' of 'bdrv-1.'

• Example in which control is eliminated

Let's look at an example in which control is eliminated. List 6.4 is the same as the above example except that xyz is defined as a data output terminal. The synthesis result is shown in Figure 6.2.

This SFL description indicates that 'abc' is set to 'xyz' if 'start' is "1", but does not say anything about the case where 'start' is '0'. That is, any value is allowed for 'xyz' when 'start' is not "1", and, therefore, synthesis is performed such that 'abc' is output continuously. As a result, 'abc' is simply connected to 'xyz', and terminal 'start' is unnecessary.


<List 6.4> Example eliminating control

 1:	module test2 {
 2:	    input abc;
 3:	    output xyz;
 4:	    instrin start;
 5:	    instruct start xyz = abc;
 6:	}

<Fig 6.2> Synthesis result of List 6.4



• Example of logic compression

The next example is a case in which an operator is included. The synthesis result of List 6.5 is shown in Figure 6.3. When an operator appears as in this example, SFLEXP does not simply develop connections as described before, but attempts to simplify the logic. This circuit shows the result of simplification. Since SFLEXP does not optimize polarity from a global viewpoint, unnecessary inverters may be included. However, such redundant inverters are eliminated by OPT_MAP, ONSET or RINV.


<List 6.5> Example in which an operator is included

 1:	module test3 {
 2:	    input abc;
 3:	    input def;
 4:	    output xyz;
 5:	    instrin start;
 6:	    instruct start xyz = abc & def;
 7:	}


<Fig 6.3> Synthesis result of List 6.5


To see how SFLEXP simplifies logic, let's consider the slightly more complicated example of logic in List 6.6. The result is shown in Figure 6.4. You will see that the logic is simpler than the original logic expression. You can also see that the logic for f1 and that for f2, which are the same, are both extracted during logic simplification.


<List 6.6> Example of logic compression

 1:	module test4 {
 2:	    input     a, b, c, d;
 3:	    output    f1, f2;
 4:	    instrin   start ;
 5:	    instruct start par {
 6:	        f1 = (^a & ^b & ^c & ^d)
 7:	           | (^a & ^b & ^c &  d)
 8:	           | (^a &  b & ^c & ^d)
 9:	           | ( a & ^b & ^c & ^d)
10:	           | ( a &  b & ^c & ^d)
11:	           | ( a &  b &  c &  d) ;
12:	        f2 = (^a & ^b & ^c & ^d)
13:	           | (^a & ^b & ^c &  d)
14:	           | (^a &  b & ^c & ^d)
15:	           | ( a & ^b & ^c & ^d)
16:	           | ( a &  b & ^c & ^d)
17:	           | ( a &  b &  c &  d) ;
18:	    }
19:	}

<Fig.6.4> Synthesis result of List 6.6


• Example of conditional syntax

The next example shows how SFL conditional syntax is handled in synthesis. The description of List 6.7 denotes that, if data input terminal 'cnd' is '0', input abc is output to data output terminal 'xyz', and that if data input terminal 'cnd' is quot;1quot;, input 'def' is output to data output terminal 'xyz'. The result of the synthesis is shown in Figure 6.5. Since there are two transfer sources that send values to 'xyz', a selector is inserted and the transfer condition is simplified to the selector's select input.


<Fig.6.7> Example of a selector being inserted

 1:	module test5 {
 2:	    input   cnd<2>;
 3:	    input   abc<4>;
 4:	    input   def<4>;
 5:	    output  xyz<4>;
 6:	    any {
 7:	        cnd == 0b00 : xyz = abc;
 8:	        cnd == 0b01 : xyz = def;
 9:	        cnd == 0b10 : xyz = def;
10:	        cnd == 0b11 : xyz = abc;
11:	    }
12:	}


<Fig. 6.5> Synthesis result of List 6.7

What would happen if data transfer sources 'abc' and 'def' were constants as shown in List 6.8? The only difference between List 6.8 and List 6.7 is that 'abc' and 'def' in the previous example are now replaced with 'ob1110' and 'ob0101', respectively. The result of synthesis is shown in Figure 6.6 (a). Since SFLEXP simplifies transfer sources and conditions separately for data transfer to the data output terminal, selector simplification is insufficient. However, OPT_MAP, ONSET and RINV achieve further simplification as shown in Figure 6.6 (b). This circuit diagram is output by the following batch program.

auto test6 ps celldemo
type test6.ps > prn

<List.6.8> Example of selecting constants

 1:	module test6 {
 2:	    input   cnd<2>;
 3:	    output  xyz<4>;
 4:	    any {
 5:	        cnd == 0b00 : xyz = 0b1110;
 6:	        cnd == 0b01 : xyz = 0b0101;
 7:	        cnd == 0b10 : xyz = 0b0101;
 8:	        cnd == 0b11 : xyz = 0b1110;
 9:	    }
10:	}


<Fig. 6.6(a)> Synthesis result of List 6.8

<Fig. 6.6(b)> Synthesis result of List 6.8 (after execution of OPT_MAP, ONSET and RINV)



• Example in which both conditions and constants are compressed

If a constant is to be transferred to the internal data terminal defined by 'sel_v' or 'bus_v' in an exclusive-or condition, SFLEXP simplifies transfer sources and transfer conditions collectively.

List 6.9 satisfies this condition. The synthesis by SFLEXP achieves simplification to some extent as shown in Figure 6.7 (a). However, if, as in this example, not all conditions are specified, it is recommended to use OPT_MAP, ONSET and RINV to achieve simplification (i.e., 'sel_v' should not be used in the description as in List 6.8). Theoretically, taking the 'don't care' condition for 'cnd' into account should yield a result with as much simplification as in Figure 6.6 (b). In reality, however, the simplification achieved falls short of that expectation, as may be seen in Figure 6.7 (b).

<List 6.9> Example of specifying selector part compression

 1:	module test7 {
 2:	    input   cnd<4>;
 3:	    sel_v   tmp<4>;
 4:	    output  xyz<4>;
 5:	    par {
 6:	        any {
 7:	            cnd == 0x0 : tmp = 0b1110;
 8:	            cnd == 0x1 : tmp = 0b0101;
 9:	            cnd == 0x2 : tmp = 0b0101;
10:	            cnd == 0x3 : tmp = 0b1110;
11:	        }
12:	        xyz = tmp;
13:	    }
14:	}

<Fig. 6.7(a)> Synthesis result of List 6.9



<Fig. 6.7(b)> Synthesis result of List 6.9 (after execution of OPT_MAP, ONSET and RINV)



• Example of overflow

Let's take an example of unsuccessful synthesis. Although List 6.10 is a simple description, a synthesis attempt causes overflow.


<List 6.10> Example of memory overflow

 1:	module test8 {
 2:	    input   abc<8>;
 3:	    input   def<8>;
 4:	    output  xyz;
 5:	    xyz = /& ^ (abc & def);
 6:	}

<Fig. 6.8> Expansion into product sums

In simplifying the logic, SFLEXP first expands the logic expression in product sums. In the case of this logic expression, there are 28 products, i.e., 256 products as shown in Figure 6.8. Humans understand the pattern of the logic structure and think nothing of it. However, SFLEXP performs simplification of this logic expression in the same way as it does on random logic, and causes overflow.

If you know the pattern of the logic structure, you can prevent overflow by inserting terminals at appropriate places to isolate a particular part of the logic structure. The internal data terminal and sub-module terminal defined with 'sel' or 'bus' can be used for this purpose. List 6.11 shows an example where an internal data terminal divides the logic in List 6.10.


<List 6.11> Example of using an internal terminal

 1:	module test9 {
 2:	    input   abc<8>;
 3:	    input   def<8>;
 4:	    sel     tmp<8>;
 5:	    output  xyz;
 6:	    par {
 7:	        tmp = abc & def ;
 8:	        xyz = /& ^ tmp ;
 9:	    }
10:	}

• Example in which stages and state transitions are included

List 6.12 provides an example of a sequential circuit for the first time. Stage 'stg' has two states 'st1' and 'st2' and controls data transfer and processing. The state alternates between 'st1' and 'st2'. This stage does not begin operation until control input terminal 'start' is activated and a job is generated for the stage. In state st1, an in1 value is written to reg1 and the reg1 contents are output to 'out'. In state 'st2', the value of 'in2' is written into 'reg2' and the value of 'reg2' is output to 'out'. The result of synthesis with an auto command is shown in Figure 6.9.


<List 6.12> Example in which stages and state transitions are included

 1:	module test10 {
 2:	    input in1,in2;
 3:	    output out;
 4:	    reg reg1,reg2;
 5:	    instrin start;
 6:	    stage_name stg {
 7:	        task tsk();
 8:	    }
 9:	    instruct start generate stg.tsk();
10:	    stage stg {
11:	        state_name st1,st2;
12:	        first_state st1;
13:	        state st1 par {
14:	            reg1 := in1;
15:	            out = reg1;
16:	            goto st2;
17:	        }
18:	        state st2 par {
19:	            reg2 := in2;
20:	            out = reg2;
21:	            goto st1;
22:	        }
23:	    }
24:	}


Register 'stg-0' indicates the state of the stage, the value "0" or "1" of this register differentiating between the two states. Task register 'stg-all' represents the on/off of the stage.

You can see that the reverse output (nout) of state register 'stg-0' is fed into input (in) and that the value is reversed in each machine cycle. You can also see that this reverse operation occurs only when the task register is "1".

Writing into 'reg1' and 'reg2' is controlled by both the state and task registers. In contrast, the value output from data output terminal 'out' is controlled only by the state register, and the on/off operation of the task register is judged unnecessary and thus omitted.

This should be a good example for clarifying what stages, tasks and states are.


<Fig. 6.9> Synthesis result of List 6.12



• SFL description taking transfer path into account

Compare List 6.13 with List 6.14. Both are SFL descriptions where data input terminal 'in' and registers 'a', 'b', 'c' and 'd' are specified as transfer sources, and registers a, b, c and d are specified as transfer destinations. However, while List 6.13 directly describes all transfer operations, List 6.14 collects data in an internal data terminal 'tmp' and then transfers it to registers 'a', 'b', 'c' and 'd'.

If SFLEXP could determine what transfer operations occur concurrently, it could minimize transfer paths for any description. However, parallel operations defy such determination. Therefore, SFLEXP generates transfer paths just as they are described. As a result, List 6.13 generates a total of 20 transfer paths from 5 transfer sources to 4 transfer destinations. It is therefore recommended to write the description as shown in List 6.14.

As illustrated in this example, when using PARTHENON you should take into account details of the transfer paths that will be generated.

<List 6.13> Description not taking transfer paths into account

 1:	module test11 {
 2:	    input case<4>;
 3:	    input in<1>;
 4:	    output out<1>;
 5:	    reg a<1>,b<1>,c<1>,d<1>;
 6:	    par {
 7:	        out = d;
 8:	        any {
 9:	            case == 0x0: a := in;
10:	            case == 0x1: a := b;
11:	            case == 0x2: a := c;
12:	            case == 0x3: a := d;
13:	            case == 0x4: b := a;
14:	            case == 0x5: b := in;
15:	            case == 0x6: b := c;
16:	            case == 0x7: b := d;
17:	            case == 0x8: c := a;
18:	            case == 0x9: c := b;
19:	            case == 0xa: c := in;
20:	            case == 0xb: c := d;
21:	            case == 0xc: d := a;
22:	            case == 0xd: d := b;
23:	            case == 0xe: d := c;
24:	            case == 0xf: d := in;
25:	        }
26:	    }
27:	}


<List 6.14> Description taking transfer paths into account

 1:	module test12 {
 2:	    input case<4>;
 3:	    input in<1>;
 4:	    output out<1>;
 5:	    reg a<1>,b<1>,c<1>,d<1>;
 6:	    sel tmp<1>;
 7:	    par {
 8:	        out = d;
 9:	        any {
10:	            case == 0x0: par { tmp = in; a := tmp; }
11:	            case == 0x1: par { tmp = b;  a := tmp; }
12:	            case == 0x2: par { tmp = c;  a := tmp; }
13:	            case == 0x3: par { tmp = d;  a := tmp; }
14:	            case == 0x4: par { tmp = a;  b := tmp; }
15:	            case == 0x5: par { tmp = in; b := tmp; }
16:	            case == 0x6: par { tmp = c;  b := tmp; }
17:	            case == 0x7: par { tmp = d;  b := tmp; }
18:	            case == 0x8: par { tmp = a;  c := tmp; }
19:	            case == 0x9: par { tmp = b;  c := tmp; }
20:	            case == 0xa: par { tmp = in; c := tmp; }
21:	            case == 0xb: par { tmp = d;  c := tmp; }
22:	            case == 0xc: par { tmp = a;  d := tmp; }
23:	            case == 0xd: par { tmp = b;  d := tmp; }
24:	            case == 0xe: par { tmp = c;  d := tmp; }
25:	            case == 0xf: par { tmp = in; d := tmp; }
26:	        }
27: }
28: }