Chapter 10: SIMULATION

| ## 10-7: The Function Entity (ALS) |

The function entity is an alternate method of specifying behavior. It makes reference to a C procedure that has been compiled into Electric. Because there are only a limited number of these procedures, and because the source code isn't always easy to update, the function entity is of limited use. However, the facility is very powerful and can be used to efficiently model complex circuits. It permits the designer to work at higher levels of abstraction so that the overall system can be conceived before the low level circuitry is designed. Examples of this include arithmetic logic units, RAM, ROM, and other circuitry which is easier to describe in terms of a software algorithm than a gate level hardware description.

The function entity is headed by a function declaration statement that gives a name and a list of exports (which are referenced in a higher level model description). The format of this statement is shown below:

Format: | function name(signal1, signal2, signal3, ... signalN)
Example: | function JK_FF(ck, j, k, out)
| function DFFLOP(data_in, clk, data_out)
| function BUS_TO_STATE(b7,b6,b5,b4,b3,b2,b1,b0, output)
| function STATE_TO_BUS(input, b7,b6,b5,b4,b3,b2,b1,b0)

The name refers to a C procedure, which will find the signal parameters in the same order that they appear in the argument list. The only four functions currently available are listed above. There are two flip-flops (JK and D) and two numeric converters that translate between a bus of 8 signals and a composite hexadecimal digit.

### Declaring Input and Output Ports

The i: and o: statements which follow the function declaration are used to tell the simulator which signals are responsible for driving the function and which drive other events. If any signal in the event driving list changes state, the function is called and the output values are recalculated. The format of an i: statement, which contains a list of event driving inputs, is shown below:

Format: | i: signal1 signal2 signal3 ... signalN
Example: | i: b7 b6 b5 b4 b3 b2 b1 b0
| i: input phi phi_bar set reset

The format of an o: statement which contains a list of output ports is shown below:

Format: | o: signal1 signal2 signal3 ... signalN
Example: | o: out1 out2 out3
| o: q q_bar

### Other Specifications

Just as there are special statements that affect the operating characteristics of a gate entity, so are these statements available to direct the function entity. The t: statement is used to set the time delay between input and output changes. The load statement is used to set the relative loading (capacitance) for the input and output ports. The priority statement is used to establish the scheduling priority. The set statement is used to initialize signals to specific logic states before the simulation run takes place. The format of these statement is identical to that of the gate entity. Note that the C procedure does not have to use the values specified in these statements and can schedule events with values that are specified directly inside the routine.

### Example of Function Use

The specification for a 3 bit shift register (edge triggered) is shown below. This circuit uses a function primitive to model the operation of a D flip-flop:

       model main(input, ck, q2, q1, q0)
       stage0: DFFLOP(input, ck, q0)
       stage1: DFFLOP(q0, ck, q1)
       stage2: DFFLOP(q1, ck, q2)

       function DFFLOP(data_in, clock, output)
       i: clock
       o: output
       t: delta=10e-9
       load clock=2.0

It should be noted that the clock is the only event driving input for the flip-flop function. There is no need to call the function if the signal "data_in" will be sampled only when the event driving signal ("clock") changes state. The designer can write the function so that it samples the data only when the function is called and the clock input is asserted high (rising edge triggered). If the clock signal is low when the function is called (falling clock edge) the procedure can ignore the data and return control back to the simulation program.

The calling arguments to the C procedure are set up as a linked list of signal pointers. The simulator places the arguments into this list in the same order that they appear in the declaration of the function entity. The programmer requires some knowledge of the internals of the simulator to extract the correct information from this list and to schedule new events. A complete discussion of function entity programming is beyond the scope of this document.

| Previous |  |  | Table of Contents |  | Next |