Copyright: ispDesignExpert 8.10 Copyright ©, 1992-2000, Lattice Semiconductor Corporation, All Rights Reserved
Citation: ispDesignExpert 8.10 Copyright ©, 1992-2000, Lattice Semiconductor Corporation, All Rights Reserved


ABEL-HDL Source File Examples

The following examples are representative of programmable logic applications and serve to illustrate significant ABEL-HDL features. You can use these examples to get started creating your own source files.

All the examples in this section are installed with your software, and you can use them without making any changes, or modify them in your designs.


Truth Table Examples

Seven-segment Display Decoder

This display decoder decodes a four-bit binary number to display the decimal equivalent on a seven-segment LED display. The design incorporates a truth table.

Design Specification

Figure A-15 shows a block diagram for the design of a seven-segment display decoder and a drawing of the display with each of the seven segments labeled to correspond to the decoder outputs. To light a segment, the corresponding line must be driven low. Four input lines D0-D3 are decoded to drive the correct output lines. The outputs are named a, b, c, d, e, f, and g corresponding to the display segments. All outputs are active low. An enable, ena, is provided. When ena is low, the decoder is enabled; when ena is high, all outputs are driven to high impedance.

Figure A-15: Block Diagram of Seven-segment Display Decoder

Design Method

Figure A-16 and Figure A-17 show the simplified block diagram and the source file for the ABEL-HDL implementation of the display decoder. The binary inputs and the decoded outputs are grouped into the sets bcd and led. The constants ON and OFF are declared so the design can be described in terms of turning a segment on or off. To turn a segment on, the appropriate line must be driven low, thus we declare ON as 0 and OFF as 1.

Figure A-16: Simplified Block Diagram: Seven-segment Display Decoder

The design is described in two sections, an equations section and a truth table section. The decoding function is described with a truth table that specifies the outputs required for each combination of inputs. The truth table header names the inputs and outputs. In this example, the inputs are contained in the set named bcd and the outputs are in led. The body of the truth table defines the input to output function.

Because the design decodes a number to a seven segment display, values for bcd are expressed as decimal numbers, and values for led are expressed with the constants ON and OFF that were defined in the declarations section of the source file. This makes the truth table easy to read and understand; the incoming value is a number and the outputs are on and off signals to the LED.

The input and output values could have just as easily been described in another form. Take for example the line in the truth table:

5 -> [ ON, OFF, ON , ON, OFF, ON, ON]

This could have been written in the equivalent form:

[ 0, 1, 0, 1 ] -> 36

In this second form, 5 was simply expressed as a set containing binary values, and the LED set was converted to decimal. (Remember that ON was defined as 0 and OFF was defined as 1.) Either form is supported, but the first is more appropriate for this design. The first form can be read as, “the number five turns on the first segment, turns off the second, .  .  .” whereas the second form cannot be so easily translated into meaningful terms.

Figure A-17: Source File: 4-bit Counter with 2-input Mux

Test Vectors

The test vectors for this design test the decoder outputs for the ten valid combinations of input bits. The enable is also tested by setting ena high for the different combinations. All outputs should be at high impedance whenever ena is high.


State Diagram Examples

Three-state Sequencer

The following design is a simple sequencer that demonstrates the use of ABEL-HDL state diagrams. The design is implemented in a P16R4 device. The number of State Diagram states that can be processed depends on the number of transitions and the path of the transitions. For example, a 64-state counter uses fewer terms (and smaller equations) than a 63-state counter. For large counter designs, use the syntax CountA:= CountA + 1 to create a counter rather than using a state machine. See also example COUNT116.abl for further information on counter implementation.

Design Specification

Figure A-18 shows the sequencer design with a state diagram that shows the transitions and desired outputs. The state machine starts in state A and remains in that state until the 'start' input becomes high. It then sequences from state A to state B, from state B to state C, and back to state A. It remains in state A until the 'start' input is high again. If the 'reset' input is high, the state machine returns to state A at the next clock cycle. If this reset to state A occurs during state B, a 'halt' synchronous output goes high, and remains high until the machine is again started.

During states B and C, asynchronous outputs 'in_B' and 'in_C' go high to indicate the current state. Activation of the 'hold' input will cause the machine to hold in state B or C until 'hold' is no longer high, or 'reset' goes high.

Design Method

The sequencer is described by using a STATE_DIAGRAM section in the source file. Figure A-19 shows the source file for the sequencer. In the source file, the design is given a title, the device type is specified, and pin declarations are made. Constants are declared to simplify the state diagram notation. The two state registers are grouped into a set called 'sreg' and the three states (A, B, and C) are declared, with appropriate values specified for each.

The state values chosen for this design allow the use of register preload to ensure that the machine starts in state A. For larger state machines with more state bits, careful numbering of states can dramatically reduce the logic required to implement the design. Using constant declarations to specify state values saves time when you make changes to these values.

The state diagram begins with the STATE_DIAGRAM statement that names the set of signals to use for the state register. In this example, 'sreg' is the set of signals to use.

Figure A-18: State Diagram: Three-state Sequencer

Within the STATE_DIAGRAM, IF-THEN-ELSE statements are used to indicate the transitions between states and the input conditions that cause each transition. In addition, equations are written in each state that indicate the required outputs for each state or transition.

For example, state A reads:

State A:
  in = 0;
  in_C = 0;
  if (start & !reset) then B with
halt := 0;
  else A with halt := halt;

This means that if the machine is in state A, and start is high but reset is low, it advances to state B. In any other input condition, it remains in state A.

The equations for in_B and in_C indicate those outputs should remain low while the machine is in state A. The equations for halt, specified with the with keyword, indicate that halt should go low if the machine transitions to state B, but should remain at its previous value if the machine stays in state A.

Test Vectors

The specification of the test vectors for this design is similar to other synchronous designs. The first vector is a preload vector, to put the machine into a known state (state A), and the following vectors exercise the functions of the machine. The A, B, and C constants are used in the vectors to indicate the value of the current state, improving the readability of the vectors.

Figure A-19: Source File: Three-state Sequencer


Combined Logic Descriptions

This section contains an advanced logic design and builds on examples and concepts presented in the earlier sections of this manual. This design, a blackjack machine, is the combination of more than one basic logic design. Design specification, methods, and complete source files are given for all parts of the blackjack machine example, which contains the following logic designs.

•	Multiplexer

•	5-bit adder

•	Binary to BCD converter

•	State machine

This example is a classic blackjack machine based on C.R. Clare's design in Designing Logic Systems Using State Machines (McGraw Hill, 1972). The blackjack machine plays the dealer's hand, using typical dealer strategies to decide, after each round of play, whether to draw another card or to stand.

The blackjack machine consists of these functions:

•	A card reader that reads each card as it is drawn

•	Control logic that tells it how to play each hand (based on the total point value of the cards currently held)

•	Display logic that displays scores and status on the machine's four LEDs.

For this example, we are assuming that the two digital display devices used to display the score have built-in seven-segment decoders.

To operate the machine, insert the dealer's card into the card reader. The machine reads the value and, in the case of later card draws, adds it to the values of previously read cards for that hand. (Face cards are valued at 10 points, non-face cards are worth their face value, and aces are counted as either 1 or 11, whichever count yields the best hand.) If the point total is 16 or less, the GT16 line will be asserted (active low) and the Hit LED will light up. This indicates that the dealer should draw another card. If the point total is greater than 16 but less than 22, no LEDs will light up (indicating that the dealer should draw no new cards). If the point total is 22 or higher, LT22 will be asserted (active low) and the Bust LED will light (indicating that the dealer has lost the hand).

As Figure A-20 shows, the blackjack machine is implemented in three PLDs.

•	A multiplexer-adder-comparator, which adds the value of the newly drawn card to the existing hand (and indicates an ace to the state machine);

•	A binary to binary-coded-decimal (BCD) converter, which takes in the five-bit binary score and converts it to two-digits of BCD for the digital display.

•	The blackjack controller (a state machine that contains the game logic). This logic includes instructions that determine when to add a card value, when to count an ace as 1, and when to count an ace as 11.

Figure A-20: Schematic of a Blackjack Machine Implemented in Three PLDs

Circuits that are a straightforward function of a set of inputs and outputs are often most easily expressed in equations; the adder is such a circuit. The PLD for the adder function (identified as MUXADD in Figure A-20) includes three elements: a multiplexer, the adder itself, and a comparator.

The multiplexer selects either the value of the newly dealt card or one of the two fixed values used for the ace (ADD10 or SUB10). The adder adds the value selected by the multiplexer to the previous score when triggered by the clock signal, ADDCLK. The comparator detects when an ace is present and passes this information on to the blackjack controller, BJACK.

Outputs that do not follow a specific pattern are most easily expressed as truth tables. This is the case with the binary-to-BCD converter that is identified in the schematic (Figure A-20) as BINBCD. This PLD converts five bits of binary input to BCD output for two digital display elements.

The following text describes the internal logic design necessary to keep the card count, to control the play sequence, and to show the count on the digital display (or the state on the Hit and Bust LEDs). Neither the card reader nor the physical design is discussed here. Assume that the card reader provides a binary value that is representative of the card read.

The design has eight inputs (four of which are the binary encoded card values, V0-V3). The remaining four inputs are signals that indicate the following:

•	Restart (the machine is to be restarted)

•	CardIn (a card is in the reader)

•	CardOut (no card is in the reader)

•	CLK (a clock signal to synchronize the design to the card reader)

CardIn, CardOut, and Clk are provided by the card reader. Restart is provided by a switch on the exterior of the machine.

Device	Function in the Blackjack Machine
P22V10	Multiplexer/Adder/Comparator
P16L8	Binary-BCD converter
P16R6	State machine


Hierarchy Examples

The following ABEL-HDL source files show how to combine the three blackjack examples into one top-level source for implementation in a larger device.

The three lower-level modules are unchanged from the non-hierarchical versions and still include their original device declarations. The device declarations in this example provide the ABEL-HDL compiler with information about device-specific requirements, such as implied logic and default signal attributes.

Note: To process this design, you must enable the “compatible” and “implied” properties of the Compile Logic process.

The test vectors have been removed because this design is not targeted for a programmable device.


ABEL and Synario Projects

The following ABEL-HDL source, p6top.abl, (Figure A-25) instantiates variable instances of prep6.abl (Figure A-26).

Figure A-25: Top-level ABEL-HDL Source

Lower-level Sources

Figure A-26 shows the lower-level ABEL-HDL file instantiated by p6top.abl. This file does not contain an interface statement, which is optional in lower-level files.

Figure A-26: Lower-level ABEL-HDL Source

MODULE prep6

TITLE ‘16-Bit Accumulator’

D15..D0 pin;

Q15..Q0 pin istype ‘reg’;

Clk, Rst pin;

Q = [Q15..Q0];

B = [D15..D0];

@carry 2;

EQUATIONS

  Q := D + Q;

  Q.C = Clk;

  Q.AR = Rst;

END


Memory Address Decoder

Address decoding is a typical application of programmable logic devices, and the following describes the ABEL-HDL implementation of such a design.

Design Specification

Figure A-1 shows the block diagram for this design and a continuous block of memory divided into sections containing dynamic RAM (DRAM), I/O (IO), and two sections of ROM (ROM1 and ROM2). The purpose of this decoder is to monitor the 6 high-order bits (A15-A10) of a sixteen-bit address bus and select the correct section of memory based on the value of these address bits. To perform this function, a simple decoder with six inputs and four outputs is designed for implementation in a simple PLD.

Figure A-1: Block Diagram: Memory Address Decoder

The address ranges associated with each section of memory are shown below. These address ranges can also be seen in the source file in Figure A-3.

Memory Section	Address Range (hex)
DRAM	0000-DFFF
I/O	E000-E7FF
ROM2	F000-F7FF
ROM1	F800-FFFF
Design Method

Figure A-2 shows a simplified block diagram for the address decoder. The decoder is implemented with equations employing relational and logical operators as shown in Figure A-3.

Significant simplification is achieved by grouping the address bits into a set named Address. The ten address bits that are not used for the address decode are given no-connect values in the set. This indicates that the address in the overall design (that beyond the decoder) contains 16 bits, but that bits 0 to 9 do not affect the decode of that address and are not monitored. In contrast, defining the set as

Address = [A15,A14,A13,A12,A11,A10]

ignores the existence of the lower-order bits. Specifying all 16 address lines as members of the address set allows full 16-bit comparisons of the address value against the ranges shown above.

Figure A-2: Simplified Block Diagram: Memory Address Decoder

Figure A-3: Memory Address Decoder Source File

module decode
title 'memory decode'

        A15,A14,A13,A12,A11,A10 pin 1,2,3,4,5,6;
        ROM1,IO,ROM2,DRAM       pin 14,15,16,17 istype 'com';
        H,L,X   = 1,0,.X.;
        Address = [A15,A14,A13,A12, A11,A10,X,X, X,X,X,X, X,X,X,X];

equations
        !DRAM   = (Address <= ^hDFFF);
        !IO     = (Address >= ^hE000) & (Address <= ^hE7FF);
        !ROM2   = (Address >= ^hF000) & (Address <= ^hF7FF);
        !ROM1   = (Address >= ^hF800);

test_vectors
             (Address -> [ROM1,ROM2,IO,DRAM])
              ^h0000  -> [  H,  H,  H,   L ];
              ^h4000  -> [  H,  H,  H,   L ];
              ^h8000  -> [  H,  H,  H,   L ];
              ^hC000  -> [  H,  H,  H,   L ];
              ^hE000  -> [  H,  H,  L,   H ];
              ^hE800  -> [  H,  H,  H,   H ];
              ^hF000  -> [  H,  L,  H,   H ];
              ^hF800  -> [  L,  H,  H,   H ];
end

Test Vectors

In this design, the test vectors are a straightforward listing of the values that must appear on the output lines for specific address values. The address values are specified in hexadecimal notation.


12-to-4 Multiplexer

The following describes the implementation of a 12-input to 4-output multiplexer using high level equations.

Design Specification

Figure A-4 shows the block diagram for this design. The multiplexer selects one of the four inputs and routes that set to the output. The inputs are a0-a3, b0-b3, and c0-c3. The outputs are y0-y3. The routing of inputs to outputs is straightforward: a0 or b0 or c0 is routed to the output y0, a1 or b1 or c1 is routed to the output y1, and so on with the remaining outputs. The select lines, s0 and s1, control the decoding that determines which set is routed to the output.

Figure A-4: Block Diagram: 12-to-4 Multiplexer

Design Method

Figure A-5 shows a block diagram for the same multiplexer after sets have been used to group the signals. All of the inputs have been grouped into the sets a, b, and c. The outputs and select lines are grouped into the sets, y and select, respectively. This grouping of signals into sets takes place in the declaration section of the source file listed in Figure A-6.

When the sets have been declared, specification of the design is made with the following four equations that use When-then statements.

when (select == 0) then y = a;
when (select == 1) then y = b;
when (select == 2) then y = c;
when (select == 3) then y = c;

The relational expression (==) inside the parentheses produces an expression that evaluates to true or false value, depending on the values of s0 and s1.

Figure A-5: Simplified Block Diagram: 12-to-4 Multiplexer

In the first equation, this expression is then ANDed with the set a, which contains the four bits, a0-a3, and could be written as

y = (select == 0) & a

Assume select is equal to 0 (s1 = 0 and s0 = 0), so a true value is produced. The true is then ANDed with the set a on a bit by bit basis, which in effect sets the product term to a. If select were not equal to 0, the relational expression inside the parentheses would produce a false value. This value, when ANDed with anything, would give all zeroes.

The other product terms in the equation work in the same manner. Because select takes on only one value at a time, only one of the product terms pass the value of an input set along to the output set. The others contribute 0 bits to the ORs.

Test Vectors

The test vectors for this design are specified in terms of the input, output, and select sets. Note that the values for a set can be specified by decimal numbers and by other sets. The constants H and L, used in the test vectors, were declared as four bit sets containing all ones or all zeroes.

Figure A-6: Source File: 12-to-4 Multiplexer


4-Bit Universal Counter

The following design describes the implementation of a 4-bit up/down counter with parallel load and count enable. The design is described using high-level ABEL-HDL equations. Figure A-7 shows a block diagram of the counter and its signals. Figure A-8 shows the source file for this design.

Figure A-7: Block Diagram: 4-bit Universal Counter

The outputs q3, q2, q1, and q0 contain the current count. The least significant bit (LSB) is q0 the most significant bit (MSB) is q3.


Design Description

Hierarchical Interface Declaration

Directly after the module name, the design contains a hierarchical interface declaration that is used by the ABEL-HDL compiler and linker if another ABEL-HDL source instantiates this source. The interface list shows all of the input, output, and bidirectional signals (if any) in the design.

Declarations

The declarations contain sections that make the design easier to interpret. The sections are as follows:

Constants	Constant values are defined.
Inputs	Design inputs are declared.
Outputs	The output pin list contains an istype declaration for retargetability.
Sets	The names data and count are defined as sets (groups) containing the inputs d3, d2, d1, and d0, and the outputs q3, q2, q1, and q0, respectively.
Modes	The “Mode equations” are actually more Contants declarations. First MODE is defined as the set containing cnten, ld, and u_d, in that order. Next, LOAD is defined as being true when the members of MODE are equal to X, 1, and X, respectively. HOLD, UP, and DOWN are defined similarly.
Equations

The design of the counter equations enables you to easily define modes and your actual register equations will be easily readable. The counter equation uses When-then-else syntax. The first line

when LOAD then count := data

uses the symbolic name LOAD, defined earlier in the source file as

LOAD = (MODE == [X, 1, X])

and MODE itself is a set of inputs in a particular order, defined previously as

MODE = [cnten, ld, u_d]

The first line of the equation could have been written as

when ((cnten == X) & (ld == 1) & (u_d == X)) then count := data

which is functionally the same, but the intermediate definitions used instead makes the source file more readable and easier to modify.

Figure A-8: Source File: 4-bit Universal Counter

Note: You can also see the advantages of set notation in the test vector section (which has been edited in this manual, but can be seen in the actual .abl file). In the test vectors, the input data is applied as a decimal value, and the output count is a decimal value rather than a set of binary bits.


Using Sets to Create Modes

The counter has four different modes of operation: Load Data From Inputs, Count Up, Count Down, and Hold Count. You select the modes by applying various combinations of values to the inputs cnten, ld, and u_d, as described below. The four modes have different priorities, which are defined in the ABEL-HDL description.

The Load mode has the highest priority. If the ld input is high, then the q outputs reflect the value on the d inputs after the next clock edge.

The Hold mode has the next highest priority. Provided ld is low, then when the cnten input is low, the q outputs maintain their current values upon subsequent clock edges, ignoring any other inputs.

The Up and Down modes have the same priority, and by definition are mutually exclusive. Provided cnten is high and ld is low, then when u_d is high, the counter counts up and when u_d is low, the counter counts down.


Counter Reset

The counter is reset asynchronously by assertion of the input rst.


Using Range Operators

Because this design uses range operators and sets, you can modify the counter to be any width by making changes in the declarations section. You could create a 9-bit counter by changing the lines which read “d3..d0” and “q3..q0” to “d8..d0” and “q8..q0,” respectively. The range expressions are expanded out and create register sets of corresponding width.


Bidirectional Three-state Buffer

A four-bit bidirectional buffer with tristate outputs is presented here. The design is implemented in an F153 FPLA with bidirectional inputs/outputs and programmable output polarity. Simple Boolean equations are used to describe the function.

Design Specification

Figure A-9 shows a block diagram for this four-bit buffer. Signals A0-A3 and B0-B3 function both as inputs and outputs, depending on the value on the select lines, S0-S1. When the select value (the value on the select lines) is 1, A0-A3 are enabled as outputs. When the select value is 2, B0-B3 are enabled as outputs. (The choice of 1 and 2 for select values is arbitrary.) For any other values of the select lines, both the A and B outputs are at high impedance. Output polarity for this design is positive.

Figure A-9: Block Diagram: Bidirectional Three-state Buffer

Design Method

A simplified block diagram for the buffer is shown in Figure A-10. The A and B inputs/outputs are grouped into two sets, A and B. The select lines are grouped into the select set. Figure A-11 shows the source file that describes the design.

Figure A-10: Simplified Block Diagram: Bidirectional Three-state Buffer

High-impedance and don't-care values are declared to simplify notation in the source file. The equations section describes the full function of the design. What appear to be unresolvable equations are written for A and B, with both sets appearing as inputs and outputs. The enable equations, however, enable only one set at a time as outputs; the other set functions as inputs to the buffer.

Test vectors are written to test the buffer when either set is selected as the output set, and for the case when neither is selected. The test vectors are written in terms of the previously declared sets so the element values do not need to be listed separately.

Figure A-11: Source file: Bidirectional Three-state Buffer

module tsbuffer
title 'bidirectional three state buffer'

        S1,S0           Pin 1,2;         Select = [S1,S0];
        A3,A2,A1,A0     Pin 12,13,14,15;   A    = [A3,A2,A1,A0];
        B3,B2,B1,B0     Pin 16,17,18,19;   B    = [B3,B2,B1,B0];

        X,Z     = .X., .Z.;

equations
        A = B;
        B = A;

        A.oe = (Select == 1);
        B.oe = (Select == 2);

test_vectors
        ([Select,  A,  B]-> [  A,  B])
         [  0   ,  0,  0]-> [  Z,  Z];
         [  0   , 15, 15]-> [  Z,  Z];

         [  1   ,  X,  5]-> [  5,  X];
         [  1   ,  X, 10]-> [ 10,  X];

         [  2   ,  5,  X]-> [  X,  5];
         [  2   , 10,  X]-> [  X, 10];

      [  3   ,  0,  0]-> [  Z,  Z];
         [  3   , 15, 15]-> [  Z,  Z];
end


4-Bit Comparator

This is a design for a 4-bit comparator that provides an output for “equal to,” “less than,” “not equal to,” and “greater than” (as well as intermediate outputs). The design is implemented with high level equations.

Design Specification

The comparator, as shown in Figure A-12, compares the values of two four-bit inputs (A0-A3 and B0-B3) and determines whether A is equal to, not equal to, less than, or greater than B. The result of the comparison is shown on the output lines, EQ, GT, NE, and LT.

Figure A-12: Block Diagram: 4-bit Comparator

Design Method

Figure A-13 and Figure A-14 show the simplified block diagram and source file listing for the comparator. The inputs A0-A3 and B0-B3 are grouped into the sets A and B. YES and NO are defined as 1 and 0, to be used in the test vectors.

The equations section of the source file contains the following equations:

EQ = A == B;
NE = !(A == B);
GT = A > B;
LT = !((A > B) # (A == B));

Figure A-13: Simplified Block Diagram: 4-bit Comparator

You could also use the following equations for the design of this comparator. However, many more product terms are used in the FPLA:

EQ  = A == B;
NE  = A != B;
GT  = A > B;
LT  = A < B;

The first set of equations takes advantage of product term sharing within the target FPLA, while the latter set requires a different set of product terms for each equation. For example, the equation

NE  = !(A == B);

uses the same 16 product terms as the equation

EQ  = A == B;

thereby reducing the number of product terms. In a similar manner, the equation

LT  = !((A > B) # (A == B));

uses the same product terms as equations

EQ  = A == B;
GT  = A > B;

whereas the equation

LT  = A < B;

(in the second set of equations) requires the use of additional product terms. Sharing product terms in devices that allow this type of design architecture can serve to fit designs into smaller and less expensive logic devices.

Figure A-14: Source File: 4-bit Comparator

module comp4a
title '4-bit look-ahead comparator'

   A3..A0         pin  1..4;
   A              =    [A3..A0];
   B3..B0         pin  5..8;
   B              =    [B3..B0];

   NE,EQ,GT,LT    pin 16..19 istype 'com';

   No,Yes  = 0,1;

equations
   EQ  =   A == B;
   NE  = !(A == B);
   GT  =   A > B;
   LT  = !((A > B) # (A == B));

" test_vectors deleted...

end

Test Vectors

Three separate test vectors sections are written to test three of the four possible conditions. (The fourth and untested condition of NOT EQUAL TO is simply the inverse of EQUAL TO.) Each test vectors table includes a test vector message that helps make report output from the compiler and the simulators easier to read.

The three tested conditions are not mutually exclusive, so one or more of them can be met by a given A and B. In the test vectors table, the constants YES and NO (rather than 1 and 0) are used for ease of reading. YES and NO are declared in the declaration section of the source file.


Design Specification -- MUXADD

MUXADD consists of an input multiplexer, an adder, and a comparator. The multiplexer determines what value is added to the current score (by the adder) The added value consists of the contents of the external card reader (V0-V1 declared as Card), a numeric value of +10, or a numeric value of -10.

The inputs Add10 and Sub10 from the controller (state machine) BJACK determine which of the three values the multiplexer selects for application to the adder. Card is applied to the adder when Add10 and Sub10 are active high, as generated by the BJACK controller. When Add10 becomes active low, 10 is added to the current score (to count an ace as 11 instead of 1), and when Sub10 is active low, -10 is added to the current score (to count an ace as 1 instead of 11).

The adder provides an output named Score (S0-S4) which is the sum of the current adder contents and the value selected by the input multiplexer (the card reader contents, +10, or -10). The comparator monitors the contents of the external card reader (Card) and generates an output, is_Ace, to the BJACK controller that signifies that an ace is present in the card reader.


Design Method -- MUXADD

MUXADD is implemented in a P22V10, and consists of a three-input multiplexer, a five-bit ripple adder, and a five-bit comparator. These circuit elements are defined in the equations shown in Figure A-21. For the multiplexer inputs, a set named Card defines inputs V0 through V4 as the value of the card reader, while inputs Add10 and Sub10 are used directly in the following equations to define the multiplexer. The multiplexer output to the adder is named Data and is defined by the equations

Data     =  Add10 &  Sub10 & Card
         # !Add10 &  Sub10 & ten
         #  Add10 & !Sub10 & minus_ten;

The adder (MUXADD) contained in the P22V10 is a five-bit binary ripple adder that adds the current input from the multiplexer to the current score, with carry. The adder is clocked by a signal (AddClk) from the BJACK controller and is described with the following equations.

Score    := Data $ Score.FB $ CarryIn;
CarryOut  = Data & Score.FB # (Data # Score.FB) & CarryIn;
Reset     = !Clr;

In the above equations, Score is the sum of Data (the card reader output, value of ten, or value of minus ten), Score (the current or last calculated score), and CarryIn (the shifted value of CarryOut, described below). The new value of Score appears at the S0 through S4 outputs of MUXADD at the time of the AddClk pulse generated by the BJACK controller (state machine).

Before the occurrence of the AddClk clock pulse, an intermediate adder output appears at combinatorial outputs of the P22V10, labeled C0 through C4 and defined as the set named CarryOut (shown below). A second set named CarryIn defines the same combinatorial outputs as CarryOut, but the outputs are shifted one bit to the left, as shown below.

CarryIn   = [C4..C1, 0];
CarryOut  = [ X,C4..C1];

The set declarations define CarryIn as CarryOut with the required shift to the left for application back to adder input. At the time of the AddClk pulse from the BJACK controller, CarryIn is added to Score and Data by an exclusive-or operation.

The comparator portion of MUXADD is defined with

is_Ace = Card == 1;

which provides an input to the BJACK controller whenever the value provided by the card reader is 1.


Test Vectors -- MUXADD

The test vectors shown in Figure A-21 verify operation of MUXADD by first clearing the adder (so Score is zero), then adding card reader values 7 and 10. The test vectors then input an ace (1) from the card reader (Card) to produce a Score of 1 and pull the is_Ace output high. Subsequent vectors verify the -10 function of the input multiplexer and adder. The trace statement lets you observe the carry signals in simulation.

Figure A-21: Source File: Multiplexer / Adder / Comparator

module MuxAdd
title '5-bit ripple adder with input multiplex'

   AddClk,Clr,Add10,Sub10,is_Ace   pin  1,9,8,7,14;
   V4..V0                  pin 6..2;
   S4..S0                  pin 15..19;
   C4..C1                  pin 20..23;

   X,C,L,H   = .X., .C., 0, 1;

   Card      = [V4..V0];
   Score     = [S4..S0];
   CarryIn   = [C4..C1, 0];
   CarryOut  = [ X,C4..C1];
   ten       = [ 0, 1, 0, 1, 0];
   minus_ten = [ 1, 0, 1, 1, 0];

   S4..S0 istype 'reg' ;

" Input Multiplexer
        Data     =  Add10 &  Sub10 & Card
                 # !Add10 &  Sub10 & ten
                 #  Add10 & !Sub10 & minus_ten;

@DISP MARG = equations
   Score   := Data $ Score.FB $ CarryIn;
   CarryOut = Data & Score.FB # (Data # Score.FB) & CarryIn;
   Score.ar  = !(Clr # Clr);
   Score.clk = AddClk;
   is_Ace   = Card == 1;

" test_vectors edited...
end MuxAdd


Design Specification -- BINBCD

To display the Score, appearing at the output of MUXADD, a binary to bcd converter is implemented in a P16L8. It is the function of the converter to accept the four lines of binary data generated by MUXADD and provide two sets of binary coded decimal outputs for two bcd display devices; one to display the units of the current score, and the other to display the tens. The four-bit output bcd1 (D0-D3) contains the units of the current score, and is connected to the high-order display digit. The two-bit output bcd2 (D4 and D5) contains the tens, and is fed to the low-order display digit.

BINBCD also provides a pair of outputs to light the Bust and Hit LEDs. Bust is lit whenever Score is 22 or greater; while Hit is lit whenever Score is 16 or less.


Design Method -- BINBCD

The design of BINBCD is shown in the source file of Figure A-22. The design of the converter is easily expressed with a truth table that lists the value of Score (inputs S0 through S4 are declared as Score) for values of bcd1 and bcd2. bcd1 and bcd2 are sets that define the outputs that are fed to the two digital display devices. The truth table lists Score values up to decimal 31.

The truth table represents a method of expressing the design “manually.” You could use a macro to create a truth table in the following manner:

clear(binary);
@repeat 32 { binary - [binary/10,binary%10]; inc(binary);}

As indicated in Figure A-22 (and described in “Test Vectors — BINBCD”), this macro is used to generate the test vectors for the converter. The generated *.lst file shows the truth table created from the macro.

The BINBCD design also provides the outputs LT22 and GT16 to control the Bust and Hit LEDs. A pair of equations generate an active-high LT22 signal to turn off the Bust LED when Score is less than 22, and an active-high GT16 signal to turn off the Hit LED when Score is greater than 16.


Test Vectors -- BINBCD

The test vectors shown in Figure A-22 verify operation of the LT22 and GT16 outputs of the converter by assigning various values for Score and checking for the corresponding outputs.

The test vectors for the binary to bcd converter are defined by means of the following macro:

test_vectors ( score - [bcd2,bcd1])
  clear(binary);
  @repeat 32 { binary - [binary/10,binary%10]; inc(binary);}

This macro generates a test vector with the variable binary set to 0 by the macro (a) {@const ?a=0}; (in the binbcd.abl source file shown in Figure A-22), followed by 31 vectors provided by the @repeat directive. The 31 vectors are generated by incrementing the value of the variable binary by a factor of 1 for each vector. Refer to the inc macro (a) {@const ?a=?a+1;}; line in Figure A-22. On the output side of the test vectors, division is used to create the output for bcd2 (tens display digit), while the remainder (modulus) operator is used to create the output for bcd1 (units display digit).

Figure A-22: Source File: 4-bit Counter with 2-input Mux


Design Specification -- BJACK

BJACK, the blackjack controller, is technically a state machine (a circuit capable of storing an internal state reflecting prior events). State machines use sequential logic, branching to new states and generating outputs on the basis of both the stored states and external inputs.

In the case of the controller, the state machine stores states that reflect the following blackjack machine conditions:

•	The value of Score in one of the decimal value ranges (0 to 16, 17 to 21, or 22+).

•	The status of the card reader (card in or card out).

•	The presence of an ace in the card reader.

On the basis of these stored states (and input from each new card), the controller decides whether or not a +10 or -10 value is sent to the adder.


Design Method -- BJACK

Developing a bubble diagram is the first step in describing a state machine. Figure A-23 shows a bubble diagram (pictorial state diagram) for the controller. This bubble diagram indicates state transitions and the conditions that cause those transitions. Transitions are represented by arrows and the conditions causing the transitions are written alongside the arrow.

You must express the bubble diagram in the form shown in the state_diagram in Figure A-24. There is a one-to-one correlation between the bubble diagram and the state diagram described in the source file (Figure A-24). The table below describes the state identifiers (state machine states) illustrated in the bubble diagram and listed in the source file.

State  Identifier	Description
Clear	Clear the state machine, adder, and displays.
ShowHit	Indicate that another card is needed. Hit indicator is lit.
AddCard	Add the value at the adder input to the current count.
Add10	Add the fixed value 10 to the current count, effectively giving an ace a value of 11.
Wait	Wait until a card is taken out of the reader.
Test17	Test the current count for a value less than 17.
Test22	Test the current count for a value less than 22.
Sub10	Add the fixed value -10 to the current count, effectively subtracting 10 and restoring an ace to 1.
ShowBust	Indicate that no more cards are needed. Bust indicator is lit.
ShowStand	Indicate that no more cards are needed. Neither Hit nor Bust indicators are lit.
Figure A-23: Pictorial State Diagram: Blackjack Machine

Note that in Figure A-24, each of the state identifiers (for example, ShowHit) is defined as sets having binary values. These values were chosen to minimize the number of product terms used in the P16R6.

Operation of the state machine proceeds as follows if no aces are drawn.

•	If a card is needed from the reader, the state machine goes to state ShowHit.

•	When CardIn goes low, meaning that a card has been read, a transition to state AddCard is made. The card value is added to the current score.

•	The machine goes to Wait state until the card is withdrawn from the reader.

•	The machine goes to Test17 state.

•	If the score is less than 17, another card is drawn.

•	If the score is greater than or equal to 17, the machine goes to state Test22.

•	If the score is less than 22, the machine goes to the ShowStand state.

•	If the score is 22 or greater, a transition is made to the ShowBust state.

•	In either ShowStand or ShowBust state, a transition is made to Clear (to clear the state register and adder) when Restart goes low.

•	When Restart goes back to high, the state machine returns to ShowHit and the cycle begins again.

Operation of the state machine when an ace is drawn is essentially the same. A card is drawn and the score is added. If the card is an ace and no ace has been drawn previously, the state machine goes to state Add10, and ten is added to the count (in effect making the ace an 11). Transitions to and from Test17 and Test22 proceed as before. However, if the score exceeds 21 and an ace has been set to 11, the state machine goes to state Sub10, 10 is subtracted from the score, and the state machine goes to state Test17.


Test Vectors -- BJACK

Figure A-24 shows three sets of test vectors; each set represents a different “hand” of play (as described above the set of vectors) and tests the different functions of the design. The Restart function is used to set the design to a known state between each hand, and the state identifiers are used instead of the binary values (which they represent).

Figure A-24: Source File: State Machine (Controller)


Example 7

module bjacktop;
title 'instantiating bjack, muxadd, binbcd'

// Sub-module prototypes...
    bjack  interface (Clk,ClkIN,GT16,LT22,is_Ace,Restart,CardIn,CardOut,Ena
                  :> AddClk, Add10,Sub10,Q2..Q0, Ace);

    muxadd interface (V0..V4,AddClk,Clr,Add10,Sub10 :> S0..S4 -> is_Ace);

    binbcd interface (S0..S4, LT22, GT16 -> D0..D5);

// Sub-module instantiations...
    BJ functional_block bjack;
    MA functional_block muxadd;
    BB functional_block binbcd;

// Top level inputs...
    Clk             pin;      "System clock          -- bjack
    CardIn,CardOut  pin;      "Card present switches -- bjack
    Restart         pin;      "Restart game          -- bjack
    V4..V0          pin;      "                      -- muxadd
    Ace                         pin;
    Card            = [V4..V0];
    Sensor          = [CardIn,CardOut];
    _In             = [  0   ,   1   ];
    InOut           = [  1   ,   1   ];
    Out             = [  1   ,   0   ];

// Top level outputs...

    D5..D0          pin istype 'com';            "            -- binbcd
    BCD1            = [D3..D0];
    BCD2            = [D5,D4];

// Top level pins (for observing state machine)...
    Q2..Q0          pin istype 'com';
    Add10,Sub10     pin istype 'com';
    AddClk          node istype 'com,keep';

    Qstate          =  [Add10,Sub10,Q2,Q1,Q0];
    Clear           =  [  1  ,  1  , 1, 1, 1]; "31
    ShowHit         =  [  1  ,  1  , 1, 1, 0]; "30
    AddCard         =  [  1  ,  1  , 0, 0, 0]; "24
    Add_10          =  [  0  ,  1  , 0, 0, 0]; "16
    Wait            =  [  1  ,  1  , 0, 0, 1]; "25
    Test_17         =  [  1  ,  1  , 0, 1, 0]; "26
    Test_22         =  [  1  ,  1  , 0, 1, 1]; "27
    ShowStand       =  [  1  ,  1  , 1, 0, 0]; "28
    ShowBust        =  [  1  ,  1  , 1, 0, 1]; "29
    Sub_10          =  [  1  ,  0  , 0, 0, 1]; "17
    Zero            =  [  0  ,  0  , 0, 0, 0]; "0

    Hit         = !BB.GT16;
    Bust        = !BB.LT22;

    C,X,L,H           = .c.,.x.,0,1;

equations

// Describe the input connections...
    MA.[V4,V3,V2,V1,V0] = Card;
    MA.Clr      = Restart;
    BJ.Clk      = Clk;
    BJ.ClkIN    = Clk;
    BJ.Restart  = Restart;
    BJ.CardIn   = CardIn;
    BJ.CardOut  = CardOut;
    BJ.Ena = 0;

// Describe the output connections...
    [D5,D4,D3,D2,D1,D0]    = BB.[D5,D4,D3,D2,D1,D0];
    Add10       = BJ.Add10;
    Sub10       = BJ.Sub10;
    Q0          = BJ.Q0;
    Q1          = BJ.Q1;
    Q2          = BJ.Q2;
        Ace             = BJ.Ace;

// Describe inter-module connections...
    MA.Sub10    = BJ.Sub10;
    MA.Add10    = BJ.Add10;
    AddClk      = BJ.AddClk;
    MA.AddClk   = AddClk;
    BB.[S0,S1,S2,S3,S4] = MA.[S0,S1,S2,S3,S4];
    BJ.is_Ace   = MA.is_Ace;
    BJ.GT16     = BB.GT16;
    BJ.LT22     = BB.LT22;

end;

module bjack   ;
title 'BlackJack state machine controller'

       bjack   device  'P16R6';

"Inputs
        Clk,ClkIN       pin 1,2;      "System clock
        GT16,LT22       pin 3,4;      "Score less than 17 and 22
        is_Ace          pin 5;        "Card is ace
        Restart         pin 6;        "Restart game
        CardIn,CardOut  pin 7,8;      "Card present switches
        Ena             pin 11;

        Sensor          = [CardIn,CardOut];
        _In             = [  0   ,   1   ];
        InOut           = [  1   ,   1   ];
        Out             = [  1   ,   0   ];

"Outputs
        AddClk          pin 12;         "Adder clock
        Add10           pin 13;         "Input Mux control
        Sub10           pin 14;         "Input Mux control
        Q2,Q1,Q0        pin 15,16,17;
        Ace             pin 18;         "Ace Memory

        High,Low        = 1,0;
        H,L,C,X         = 1,0,.C.,.X.;  "test vector charactors

        Qstate          =  [Add10,Sub10,Q2,Q1,Q0];
        Clear           =  [  1  ,  1  , 1, 1, 1]; "31
        ShowHit         =  [  1  ,  1  , 1, 1, 0]; "30
        AddCard         =  [  1  ,  1  , 0, 0, 0]; "24
        Add_10          =  [  0  ,  1  , 0, 0, 0]; "16
        Wait            =  [  1  ,  1  , 0, 0, 1]; "25
        Test_17         =  [  1  ,  1  , 0, 1, 0]; "26
        Test_22         =  [  1  ,  1  , 0, 1, 1]; "27
        ShowStand       =  [  1  ,  1  , 1, 0, 0]; "28
        ShowBust        =  [  1  ,  1  , 1, 0, 1]; "29
        Sub_10          =  [  1  ,  0  , 0, 0, 1]; "17
        Zero            =  [  0  ,  0  , 0, 0, 0]; "0

equations
        [Qstate,Ace].c  = Clk;
        [Qstate,Ace].oe = !Ena;

@dcset
state_diagram Qstate

        State Clear:    AddClk    = !ClkIN;
                        Ace      := Low;
                        if (Restart==Low) then Clear else ShowHit;

        State ShowHit:  AddClk    = Low;
                        Ace      := Ace;
                        if (CardIn==Low) then AddCard else ShowHit;

        State AddCard:  AddClk    = !ClkIN;
                        Ace      := Ace;
                        if (is_Ace & !Ace) then Add_10 else Wait;

        State Add_10:   AddClk    = !ClkIN;
                        Ace      := High;
                        goto      Wait;

        State Wait:     AddClk    = Low;
                        Ace      := Ace;
                        if (CardOut==Low) then Test_17 else Wait;

        State Test_17:  AddClk    = Low;
                        Ace      := Ace;
                        if !GT16 then ShowHit else Test_22;

        State Test_22:  AddClk    = Low;
                        Ace      := Ace;
                        case     LT22           : ShowStand;
                                !LT22 & !Ace    : ShowBust;
                                !LT22 &  Ace    : Sub_10;
                        endcase;

        State Sub_10:   AddClk    = !ClkIN;
                        Ace      := Low;
                        goto      Test_17;

        State ShowBust: AddClk    = Low;
                        Ace      := Ace;
                        if (Restart==Low) then Clear else ShowBust;

        State ShowStand: AddClk    = Low;
                        Ace      := Ace;
                        if (Restart==Low) then Clear else ShowStand;

       State Zero:      goto Clear;

end

module muxadd ;
title '5-bit ripple adder with input multiplex'

        muxadd  device  'P22V10';

        AddClk,Clr,Add10,Sub10,is_Ace   pin  1, 9, 8, 7,14;
        V4,V3,V2,V1,V0                  pin  6, 5, 4, 3, 2;
        S4,S3,S2,S1,S0                  pin 15,16,17,18,19;
        C4,C3,C2,C1                     pin 20,21,22,23;

        X,C,L,H   = .X., .C., 0, 1;

        Card      = [V4,V3,V2,V1,V0];
        Score     = [S4,S3,S2,S1,S0];
        CarryIn   = [C4,C3,C2,C1, 0];
        CarryOut  = [ X,C4,C3,C2,C1];
        ten       = [ 0, 1, 0, 1, 0];
        minus_ten = [ 1, 0, 1, 1, 0];

        S4,S3,S2,S1,S0 istype 'reg' ;

" Input Multiplexer
        Data     =  Add10 &  Sub10 & Card
                 # !Add10 &  Sub10 & ten
                 #  Add10 & !Sub10 & minus_ten;

equations
        Score   := Data $ Score $ CarryIn;

        CarryOut = Data & Score # (Data # Score) & CarryIn;

        Score.ar = !Clr;

        Score.c  = AddClk;

        is_Ace   = Card == 1;

end;

module binbcd;
title 'comparator and binary to bcd decoder for Blackjack Machine'

" The 5 -bit binary (0 - 31) score is converted into two BCD outputs.
" The interger division '/' and the modulus operator '%' are used to
" extract the individual digits from the two digit score.
" 'Score % 10' will yield the 'units' and
" 'Score / 10' will yield the 'tens'
"
" The 'GT16' and 'LT22' outputs are for the state machine controller.

        binbcd  device  'P16L8';

        S4,S3,S2,S1,S0  pin 5,4,3,2,1;
        score           = [S4,S3,S2,S1,S0];

        LT22,GT16       pin 12,13       istype 'com';

        D5,D4           pin 14,15       istype 'com';
        bcd2            = [D5,D4];

        D3,D2,D1,D0     pin 16,17,18,19 istype 'com';
        bcd1            = [D3,D2,D1,D0];

" Digit separation macros
        binary    = 0;      "scratch variable
        clear   macro (a) {@const ?a=0};
        inc     macro (a) {@const ?a=?a+1;};

equations
        LT22    = (score < 22);  "Bust
        GT16    = (score > 16);  "Hit / Stand

test_vectors ( score -> [GT16,LT22])
                 1   -> [ 0  , 1  ];
                 6   -> [ 0  , 1  ];
                 8   -> [ 0  , 1  ];
                16   -> [ 0  , 1  ];
                17   -> [ 1  , 1  ];
                18   -> [ 1  , 1  ];
                20   -> [ 1  , 1  ];
                21   -> [ 1  , 1  ];
                22   -> [ 1  , 0  ];
                23   -> [ 1  , 0  ];
                24   -> [ 1  , 0  ];

truth_table ( score -> [bcd2,bcd1])
                 0  -> [  0 ,  0 ];
                 1  -> [  0 ,  1 ];
                 2  -> [  0 ,  2 ];
                 3  -> [  0 ,  3 ];
                 4  -> [  0 ,  4 ];
                 5  -> [  0 ,  5 ];
                 6  -> [  0 ,  6 ];
                 7  -> [  0 ,  7 ];
                 8  -> [  0 ,  8 ];
                 9  -> [  0 ,  9 ];
                10  -> [  1 ,  0 ];
                11  -> [  1 ,  1 ];
                12  -> [  1 ,  2 ];
                13  -> [  1 ,  3 ];
                14  -> [  1 ,  4 ];
                15  -> [  1 ,  5 ];
                16  -> [  1 ,  6 ];
                17  -> [  1 ,  7 ];
                18  -> [  1 ,  8 ];
                19  -> [  1 ,  9 ];
                20  -> [  2 ,  0 ];
                21  -> [  2 ,  1 ];
                22  -> [  2 ,  2 ];
                23  -> [  2 ,  3 ];
                24  -> [  2 ,  4 ];
                25  -> [  2 ,  5 ];
                26  -> [  2 ,  6 ];
                27  -> [  2 ,  7 ];
                28  -> [  2 ,  8 ];
                29  -> [  2 ,  9 ];
                30  -> [  3 ,  0 ];
                31  -> [  3 ,  1 ];

" This truth table could be replaced with the following macro.
"       clear(binary);
"       @repeat 32 {
"               binary -> [binary/10,binary%10]; inc(binary);}
"
"
" The test vectors will demonstrate the use of the macro.
"
test_vectors ( score -> [bcd2,bcd1])
        clear(binary);
        @repeat 32 {
                binary -> [binary/10,binary%10]; inc(binary);}
end


Example 8

Top-level ABEL-HDL Source

module p6top (rep)
title 'Variable instances of PREP6 described in
       Hierarchical ABEL-HDL'

   @ifb (?rep)
   { @message 'Must specify -arg N'
     @exit  }
   D15..D0 pin;
   Q15..Q0 pin istype 'reg';
   Clk, Rst pin;

   Q = [Q15..Q0];
   D = [D15..D0];

   @const N = ?rep - 1;

prep6 interface (D15..D0, Clk, Rst -> Q15..Q0);

   ACC macro (i)
   { @expr {ACC}?i; }

   @const i = 0;
   @repeat ?rep
   { ACC(i) functional_block prep6;
     @const i = i + 1; }

equations
   ACC0.[D15..D0] = D;

      @const i = 0;
      @repeat ?rep
      { ACC(i).[Clk, Rst] = [Clk, Rst];
        @const i = i+1; }

      @const i = 0;
      @repeat ?rep-1
      { ACC(i+1).[D15..D0] = ACC(i).[Q15..Q0];
        @const i = i+1; }
   Q = ACC(N).[Q15..Q0];
end


Example 1

12-to-4 Multiplexer

module Mux12T4
title '12 to 4 multiplexer'

     a0..a3     pin     1..4;
        b0..b3     pin     5..8;
        c0..c3     pin     9..13;
        s1,s0     pin     18,19;
        y0..3     pin     14..17;

        H       =       [1,1,1,1];
        L       =       [0,0,0,0];
        X       =       .x.;
        select  =       [s1, s0];
        y       =       [y3..y0];
        a       =       [a3..a0];
        b       =       [b3..b0];
        c       =       [c3..c0];

equations
        when (select == 0) then y = a;
        when (select == 1) then y = b;
        when (select == 2) then y = c;
        when (select == 3) then y = c;

test_vectors ([select, a, b, c] -> y)
              [0     , 1, X, X] -> 1;"select = 0, gates lines a to output
              [0     ,10, H, L] -> 10;
              [0     , 5, H, L] -> 5;
              [1     , H, 3, H] -> 3;"select = 1, gates lines b to output
              [1     ,10, 7, H] -> 7;
              [1     , L,15, L] -> 15;
              [2     , L, L, 8] -> 8;"select = 2, gates lines c to output
              [2     , H, H, 9] -> 9;
              [2     , L, L, 1] -> 1;
              [3     , H, H, 0] -> 0;"select = 3, gates lines c to output
              [3     , L, L, 9] -> 9;
              [3     , H, L, 0] -> 0;
end


Example 2

Source File: 4-bit Universal Counter

module unicnt
interface (d3..d0, clk,rst,ld, u_d -> q3..q0) ;

title '4 bit universal counter with parallel load' ;

"Constants
    X,C,Z = .X., .C., .Z. ;

"Inputs
    d3..d0  pin ;    "Data inputs, 4 bits wide
    clk     pin ;    "Clock input
    rst     pin ;    "Asynchronous reset
    cnten   pin ;    "Count enable
    ld      pin ;    "Load counter with input data value
    u_d     pin ;    "Up/Down selector: HIGH selects up

"Outputs
    q3..q0  pin istype 'reg';  "Counter outputs

"Sets
    data  = [d3..d0];   "Data set
    count = [q3..q0];   "Counter set

"Mode equations
            MODE =  [cnten,ld,u_d];   "Mode set composed of control pins.
    LOAD = (MODE == [  X  , 1, X ]);  "Various modes are defined by
    HOLD = (MODE == [  0  , 0, X ]);  "values applied to control pins.
    UP   = (MODE == [  1  , 0, 1 ]);  "Symbolic name may be defined as
    DOWN = (MODE == [  1  , 0, 0 ]);  "a set equated to a value.

Equations
    when LOAD then count := data "Load counter with data
    else when UP   then count := count + 1   "Count up
    else when DOWN then count := count - 1   "Count down
    else when HOLD then count := count ;     "Hold count

    count.clk = clk;                    "Counter clock input
    count.ar  = rst;                     "Counter reset input

"Test_vectors edited...

End

Note: You can also see the advantages of set notation in the test vector section (which has been edited in this manual, but can be seen in the actual .abl file). In the test vectors, the input data is applied as a decimal value, and the output count is a decimal value rather than a set of binary bits.


Example 3

4-bit Counter with 2-input Mux

module  bcd7
title 'seven segment display decoder'
"          a
"         ---       BCD-to-seven-segment decoder similar to the 7449
"       f| g |b
"         ---           segment identification
"       e| d |c
"         ---

        D3,D2,D1,D0,Ena pin 2,3,4,5,6;
        a,b,c,d,e,f,g   pin 13,14,15,16,17,18,19 istype 'com';

        bcd     = [D3,D2,D1,D0];
        led     = [a,b,c,d,e,f,g];

        ON,OFF  = 0,1;                  " for common anode LEDs
        L,H,X,Z = 0,1,.X.,.Z.;

equations
        led.oe = !Ena;
@dcset
truth_table (bcd -> [ a ,  b ,  c ,  d ,  e ,  f ,  g ])
              0  -> [ ON,  ON,  ON,  ON,  ON,  ON, OFF];
              1  -> [OFF,  ON,  ON, OFF, OFF, OFF, OFF];
              2  -> [ ON,  ON, OFF,  ON,  ON, OFF,  ON];
              3  -> [ ON,  ON,  ON,  ON, OFF, OFF,  ON];
              4  -> [OFF,  ON,  ON, OFF, OFF,  ON,  ON];
              5  -> [ ON, OFF,  ON,  ON, OFF,  ON,  ON];
              6  -> [ ON, OFF,  ON,  ON,  ON,  ON,  ON];
              7  -> [ ON,  ON,  ON, OFF, OFF, OFF, OFF];
              8  -> [ ON,  ON,  ON,  ON,  ON,  ON,  ON];
              9  -> [ ON,  ON,  ON,  ON, OFF,  ON,  ON];
" test_vectors edited
end


Example 4

Three-state Sequencer

module sequence
title 'State machine example';

 q1,q0                        pin   14,15 istype 'reg,invert';
        clock,enab,start,hold,reset  pin   1,11,4,2,3;
        halt                         pin   17;
        in_B,in_C                    pin   12,13;
        sreg                         =     [q1,q0];

       "State Values...
        A = 0;          B = 1;          C = 2;

equations
        [q1,q0,halt].clk = clock;
        [q1,q0,halt].oe  = !enab;

state_diagram sreg;
        State A:      " Hold in state A until start is active.
          in_B = 0;
          in_C = 0;
          IF (start & !reset) THEN B WITH halt := 0;
          ELSE A WITH halt := halt.fb;

        State B:      " Advance to state C unless reset is active
          in_B = 1;   " or hold is active. Turn on halt indicator
          in_C = 0;   " if reset.
          IF (reset) THEN A WITH halt := 1;
          ELSE IF (hold) THEN B WITH halt := 0;
          ELSE C WITH halt := 0;

        State C:      " Go back to A unless hold is active
          in_B = 0;   " Reset overrides hold.
          in_C = 1;
          IF (hold & !reset) THEN C WITH halt := 0;
          ELSE A WITH halt := 0;

" test_vectors edited...
end


Example 5

4-bit Counter with 2-input Mux

module BINBCD
title 'comparator and binary to bcd decoder for Blackjack Machine'

" The 5 -bit binary (0 - 31) score is converted into two BCD outputs.
" The integer division '/' and the modulus operator '%' are used to
" extract the individual digits from the two digit score.
" 'Score % 10' will yield the 'units' and
" 'Score / 10' will yield the 'tens'
"
" The 'GT16' and 'LT22' outputs are for the state machine controller.

   S4..S0  pin 5..1;
   score           = [S4..S0];
   LT22,GT16       pin 12,13 istype 'com';

   D5,D4      pin 14,15 istype 'com';
   bcd2       = [D5,D4];
   D3..D0     pin 16..19 istype 'com';
   bcd1       = [D3..D0];

" Digit separation macros
   binary          = 0;            "scratch variable
   clear   macro (a) {@const ?a=0};
   inc     macro (a) {@const ?a=?a+1;};

equations
        LT22    = (score < 22);         "Bust
        GT16    = (score > 16);         "Hit / Stand

" test_vectors edited...

truth_table ( score -> [bcd2,bcd1])
                 0  -> [  0 ,  0 ];
                 1  -> [  0 ,  1 ];
                 2  -> [  0 ,  2 ];
                 3  -> [  0 ,  3 ];
                 4  -> [  0 ,  4 ];
                 5  -> [  0 ,  5 ];
                 6  -> [  0 ,  6 ];
                 7  -> [  0 ,  7 ];
                 8  -> [  0 ,  8 ];
                 9  -> [  0 ,  9 ];
                10  -> [  1 ,  0 ];
                11  -> [  1 ,  1 ];
                12  -> [  1 ,  2 ];
                13  -> [  1 ,  3 ];
                14  -> [  1 ,  4 ];
                15  -> [  1 ,  5 ];
                16  -> [  1 ,  6 ];
                17  -> [  1 ,  7 ];
                18  -> [  1 ,  8 ];
                19  -> [  1 ,  9 ];
                20  -> [  2 ,  0 ];
                21  -> [  2 ,  1 ];
                22  -> [  2 ,  2 ];
                23  -> [  2 ,  3 ];
                24  -> [  2 ,  4 ];
                25  -> [  2 ,  5 ];
                26  -> [  2 ,  6 ];
                27  -> [  2 ,  7 ];
                28  -> [  2 ,  8 ];
                29  -> [  2 ,  9 ];
                30  -> [  3 ,  0 ];
                31  -> [  3 ,  1 ];

" This truth table could be replaced with the following macro.
"       clear(binary);
"       @repeat 32 {
"               binary -> [binary/10,binary%10]; inc(binary);}
"
" The test vectors will demonstrate the use of the macro.
test_vectors ( score -> [bcd2,bcd1])
        clear(binary);
        @repeat 32 {
                binary -> [binary/10,binary%10]; inc(binary);}
end


Example 6

State Machine (Controller)

module bjack
title 'BlackJack state machine controller'

"Inputs
   Clk,ClkIN       pin 1,2;      "System clock
   GT16,LT22       pin 3,4;      "Score less than 17 and 22
   is_Ace          pin 5;        "Card is ace
   Restart         pin 6;        "Restart game
   CardIn,CardOut  pin 7,8;      "Card present switches
   Ena             pin 11;

   Sensor          = [CardIn,CardOut];
   _In             = [  0   ,   1   ];
   InOut           = [  1   ,   1   ];
   Out             = [  1   ,   0   ];

"Outputs
   AddClk          pin 12 istype 'com';                  "Adder clock
   Add10           pin 13 istype 'reg_D,invert';         "Input Mux control
   Sub10           pin 14 istype 'reg_D,invert';         "Input Mux control
   Q2,Q1,Q0        pin 15,16,17 istype 'reg_D,invert';
   Ace             pin 18 istype 'red_D,invert';         "Ace Memory

   High,Low        = 1,0;
   H,L,C,X         = 1,0,.C.,.X.;  "test vector characters

   Qstate          =  [Add10,Sub10,Q2,Q1,Q0];
   Clear           =  [  1  ,  1  , 1, 1, 1]; "31
   ShowHit         =  [  1  ,  1  , 1, 1, 0]; "30
   AddCard         =  [  1  ,  1  , 0, 0, 0]; "24
   Add_10          =  [  0  ,  1  , 0, 0, 0]; "16
   Wait            =  [  1  ,  1  , 0, 0, 1]; "25
   Test_17         =  [  1  ,  1  , 0, 1, 0]; "26
   Test_22         =  [  1  ,  1  , 0, 1, 1]; "27
   ShowStand       =  [  1  ,  1  , 1, 0, 0]; "28
   ShowBust        =  [  1  ,  1  , 1, 0, 1]; "29
   Sub_10          =  [  1  ,  0  , 0, 0, 1]; "17
   Zero            =  [  0  ,  0  , 0, 0, 0]; "0

equations
   [Qstate,Ace].c  = Clk;
   [Qstate,Ace].oe = !Ena;

@dcset
state_diagram Qstate

        State Clear:    AddClk    = !ClkIN;
                        Ace      := Low;
                        if (Restart==Low) then Clear else ShowHit;

        State ShowHit:  AddClk    = Low;
                        Ace      := Ace;
                        if (CardIn==Low) then AddCard else ShowHit;

        State AddCard:  AddClk    = !ClkIN;
                        Ace      := Ace;
                        if (is_Ace & !Ace) then Add_10 else Wait;

        State Add_10:   AddClk    = !ClkIN;
                        Ace      := High;
                        goto      Wait;

        State Wait:     AddClk    = Low;
                        Ace      := Ace;
                        if (CardOut==Low) then Test_17 else Wait;

        State Test_17:  AddClk    = Low;
                        Ace      := Ace;
                        if !GT16 then ShowHit else Test_22;

        State Test_22:  AddClk    = Low;
                        Ace      := Ace;
                        case     LT22           : ShowStand;
                                !LT22 & !Ace    : ShowBust;
                                !LT22 &  Ace    : Sub_10;
                        endcase;

        State Sub_10:   AddClk    = !ClkIN;
                        Ace      := Low;
                        goto      Test_17;

        State ShowBust: AddClk    = Low;
                        Ace      := Ace;
                        if (Restart==Low) then Clear else ShowBust;

       State ShowStand: AddClk    = Low;
                        Ace      := Ace;
                        if (Restart==Low) then Clear else ShowStand;

       State Zero:      goto Clear;

@page
" test_vectors edited...


ABEL-HDL Language Reference

This chapter provides detailed information about each of the language elements in ABEL-HDL. It assumes you are familiar with the basic syntax discussed in ABEL-HDL Design Entry. Each entry contains the following sections (if applicable):

•	Syntax — is the required syntax for the element.

•	Purpose — is a brief description of the intended use of the element.

•	Use — is a discussion of the potential uses of the element, including any special considerations.

•	Examples — are examples of the element as it is used in a design description.

•	See Also — refers to other elements and discussions, and to design examples that demonstrate the use of an element.


Dot Extensions (.ext)

Syntax

signal_name.ext

Purpose

Dot extensions provide a way to refer specifically to internal signals and nodes that are associated with a primary signal in your design.

Use

Signal dot extensions describe, more precisely, the behavior of signals in a logic description, and remove the ambiguities in equations.

You can use ABEL-HDL dot extensions in complex language constructs, such as nested sets or complex expressions.


Signal Attributes (attr)

See Also

lstype


Directives (@directive)

Purpose

Directives control the contents or processing of a source file. You can use directives to conditionally include sections of ABEL-HDL source code, bring code in from another file, and print messages during processing. The available directives are given on the following pages.

Use

Some of the directives use arguments to determine how the directive is processed. The arguments can be actual arguments, or dummy arguments preceded by question marks (?). The rules applying to actual and dummy arguments are presented in Chapter 4, "ABEL-HDL Design."


Async_reset and Sync_reset

Syntax

SYNC_RESET symbolic_state_id : input_expression ;
ASYNC_RESET symbolic_state_id : input_expression ;

Purpose

In symbolic state descriptions, the SYNC_RESET and ASYNC_RESET statements specify synchronous or asynchronous state machine reset logic in terms of symbolic states.

Use

symbolic_state_id	An identifier used for reference to a symbolic state.

input_expression	Any expression.

Examples

ASYNC_RESET Start : Reset ;

SYNC_RESET Start : Reset ;

See Also

State

State-diagram

Using Symbolic State Descriptions in Chapter 4


Case

Syntax

CASE  expression : state_exp;
[ expression : state_exp; ] ...
ENDCASE ;

Purpose

Use the CASE statement in a State_diagram to indicate transitions of a state machine when multiple conditions affect the state transitions.

Use

expression	An expression.
state_exp	An expression identifying the next state, optionally followed by WITH transition equations.
You can nest CASE statements with If-Then-Else, GOTO, and other CASE statements, and you can use equation blocks.

Note: Equation blocks used within a conditional expression such as IF-THEN, CASE, or WHEN-THEN result in logic functions that are logically ANDed with the conditional expression that is in effect.

The state machine advances to the state indicated by state_exp (following the expression that produces a true value). If no expression is true, the result is undefined, and the resulting action depends on the device being used. (For devices with D flip-flops, the next state is the cleared register state.) For this reason, you should be sure to cover all possible conditions in the CASE statement expressions. If the expression produces a numeric rather than a logical value, 0 is false and any non-zero value is true. The expressions contained within the Case-endcase keywords must be mutually exclusive (only one of the expressions can be true at any given time). If two or more expressions within the same Case statement are true, the resulting equations are undefined.

Examples

"Mutually exclusive Case statement
case a == 0 : 1 ;
     a == 1 : 2 ;
     a == 2 : 3 ;
     a == 3 : 0 ;
endcase ;

"Not mutually exclusive Case statement
case (a == 0) : 1 ;
     (a == 0) & (B == 0) : 0 ;
endcase ;

See Also

State_diagram

Goto

If-Then-Else

With


Cycle

This keyword specifies the signal to repeat until the end of simulation. The default time unit is nano-second. The syntax for CYCLE is:

CYCLE signal_name ( logic_value, integer) ( logic_value, integer) [( logic_value, integer)];

Example

CYCLE clk1 (0,3) (1,5);

Note: The Wait keyword is only defined in the Lattice Logic Simulator. They cannot be used with all of the supported special constants, except .R. See Special Constants for information.


Declarations

Syntax

Declarations declarations

Purpose

The declarations keyword allows you to declare declarations (such as sets or other constants) in any part of the ABEL-HDL source file.

Use

declarations	You can use any declarations after the Declarations keyword.
The Declarations keyword is not necessary for declarations immediately following the module and/or title statement(s).

Examples

An example of declared equations is shown below:

module castle
  moat device  'P16V8C'; "declarations implied
  A,B        pin 1,2;
  Out1       pin 15 istype 'com';
Equations
  Out1 = A & B;

Declarations "declarations keyword required
  C,D,E,F    pin 3,4,5,6;
  Out2   pin 16 istype 'com';
  Temp1 = C & D;
  Temp2 = E & F;

Equations
  Out2 = Temp1 # Temp2;
end;


Device

Syntax

device_id DEVICE real_device ;

Purpose

The device declaration statement associates the device name used in a module with an actual programmable logic device on which designs are implemented.

Use

device_id	An identifier used for the programmer to load filenames.
real_device	A string describing the architecture name of the real device represented by device_id.
The device declaration is optional.

You should give device identifiers, used in device declarations, valid filenames since JEDEC files are created by appending the extension .jed to the identifier. The architecture name of the programmable logic device is indicated by the string, real_device.

The ending semicolon is required.

Examples

D1 DEVICE 'P16R4' ;


End

Syntax

end module_name

Purpose

The end statement denotes the end of the module.

Use

The end statement can be followed by the module name. For multi-module source files, the module name is required.


Equations

Syntax

equations
element [?]= condition ;
element [?]:= condition ;
when-then-else_statement ;

Purpose

The equations statement defines the beginning of a group of equations associated with a device.

Use

condition	An expression.
element	An identifier naming a signal, set of signals, or actual set to which the value of the expression is assigned.
expression	An expression.
=, :=, ?= and ?:=	Combinational and registered (pin-to-pin) on-set and dc-set assignment operators.
when-then-else	When-then-else statements.
Equations specify logic functions with an extended form of Boolean algebra.

A semicolon is required after each equation.

The equations following the equation statement are equations as described in Chapter 4, "ABEL-HDL Design."

CAUTION: Use the := and ?:= operators only when writing pin-to-pin registered equations. Use the = and ?= assignment operators for registered equations with detailed dot extensions.

Examples

A sample equations section follows:

equations
A = B & C # A ;
[W,Y] = 3 ;
!F = (B == C) ;
Output.D = In1 # In2

See Also

When-Then-Else

State_diagram

Truth_table

Operators, Expressions and Equations in chpater 4 ABEL-HDL Design


Functional_block

Syntax

DECLARATIONS
instance_name FUNCTIONAL_BLOCK source_name ;

EQUATIONS
instance_name.port_name = signal_name;

Purpose

You can use a functional_block declaration in an upper-level ABEL-HDL source to instantiate a declared lower-level module and make the ports of the lower-level module accessible in the upper-level source. You must declare modules with an interface declaration before you can instantiate them with a functional_block statement.

Use

instance_name	A unique identifier for this instance of the functional block in the current source.
source_name	The name of the lower-level module that is being instantiated.
Note: When a module is instanced by an upper-level source, any signal attributes (explicit or implied) are inherited by the upper-level source signals. Therefore, you do not need to specify ISTYPEs in higher-level sources for instantiated signals.


Fuses

Syntax

FUSES
fuse_number = fuse_value ;
or
FUSES
[ fuse_number_set ] = fuse_value ;

Purpose

The fuses section explicitly declares the state of any fuse in the targeted device.

Use

fuse_number	The fuse number obtained from the logic diagram of the device.
fuse_number_set	The set of fuse numbers (contained in square brackets).
fuse_value	The number indicating the state of fuse(s).
The fuses statement provides device-specific information, and precludes changing devices without editing the statement in the source file.

Fuse values that appear on the right side of the = symbol can be any number. If a single fuse number is specified on the left side of the = symbol, the least significant bit (LSB) of the fuse value is assigned to the fuse. A 0 indicates an intact fuse and a 1 indicates a blown fuse. In the case of multiple fuse numbers, the fuse value is expanded to a binary number and truncated or given leading zeros to obtain fuse values for each fuse number.

CAUTION: When fuse states are specified using the FUSES section, the resulting fuse values supersede the fuse values obtained through the use of equations, truth tables and state diagrams, and affect device simulation accordingly.

ABEL-HDL has a limit of 128 fuses per statement, due to the set size limitations.

Examples

FUSES
3552 = 1 ;
[3478...3491] = ^Hff;


Goto

Syntax

GOTO state_exp ;

Purpose

The GOTO statement is used in the State_diagram section to cause an unconditional transition to the state indicated by state_exp.

Use

state_exp	An expression identifying the next state, optionally followed by WITH transition equations.
GOTO statements can be nested with If-Then-Else and CASE statements.

Examples

GOTO 0 ; "goto state 0
GOTO x+y ;  "goto the state x + y

See Also

State_diagram

Case

If-Then-Else

With


If-Then-Else

Syntax

IF exp THEN state_exp
[ ELSE state_exp ] ;

Chained IF-THEN-ELSE:

IF expr THEN state_exp
    ELSE IF exp THEN state_exp
        ELSE state_exp ;

Nested IF-THEN-ELSE:

IF exp THEN state_exp
    ELSE IF exp THEN
                 IF exp THEN state_exp
                 ELSE state_exp
         ELSE state_exp ;

Nested IF-THEN-ELSE with Blocks:

IF exp THEN
{       IF exp THEN state_exp
        IF exp THEN state_exp
}
ELSE state_exp ;

Purpose

The If-then-else statements are used in the State_diagram section to describe the progression from one state to another.

Use

exp	An expression.
state_exp	An expression or block identifying the next state, optionally followed by WITH transition equations.
CAUTION: If-Then-Else is only supported within a state_diagram description.  Use When-Then-Else for equations.

Note:  Equation Blocks used within a conditional expression (such as If-then, Case, or When-then) results in logic functions that are logically ANDed with the conditional expression that is in effect.

The expression following the If keyword is evaluated, and if the result is true, the machine goes to the state indicated by the state_exp, following the Then keyword. If the result of the expression is false, the machine jumps to the state indicated by the Else keyword.

Any number of If statements may be used in a given state, and the Else clause is optional. The indenting and formatting of an If-then-else statement is not significant: breaking a complex transition statement across many lines (and indenting) improves readability.

If-then-else statements can be nested with Goto, Case, and With statements. If-then-else and Case statements can also be combined and nested.

Chained IF-THEN-ELSE Statements

Any number of If-then-else statements can be chained, but the final statement must end with a semicolon. The chained If-then-else statement is intended for situations where the conditions are not mutually exclusive. The Case statement more clearly expresses the same function as chained mutually-exclusive If-then-else statements.

Chained If-then-else statements can provide multiway branching transition logic. For example, multiple If-then-else statements can be chained to describe a three-way branch in the following manner:

STATE S0:
   IF (address < ^h0400)
        THEN S0
   ELSE
   IF (address <= ^hE100)
        THEN S2
   ELSE
        S1;

Examples

if A==B then 2 ;   "if A equals B goto state 2
if x-y then j else k; "if x-y is not 0 goto j, else goto k
if A then b*c;     "if A is true (non-zero) goto state b*c

Chained IF-THEN-ELSE

if a then 1
  else
if b then 2
  else
if c then 3
  else 0 ;

Nested IF-THEN-ELSE with Blocks

IF (Hold) THEN
{         IF (!RESET) THEN State1 ;
          IF (Error)  THEN State2 ;
}
ELSE State3 ;


Nested IF-THEN-ELSE Statements

A complex state transition could be written with nested transitions in the following manner:

STATE S0:
    CASE (select == 1): IF (address == ^h0100)
                             THEN S16
                        ELSE
                        IF (address > ^hE100)
                             THEN S17
                        ELSE
                             S0;
         (select == 2): S2;
         (select == 3): IF (address <= ^hE100)
                             THEN IF (reset)
                                       THEN S3
                                  ELSE S0;
                        ELSE S17;
         (select == 0): S0;
    ENDCASE;

See Also

State_diagram

Case

Goto

With


Interface (top-level)

Syntax

source_name INTERFACE (input/set[=value] -> output/set :> bidir/set);

Purpose

The interface keyword declares lower-level modules and their ports (signals) that are used in the current source. This declaration is used in conjunction with a functional_block declaration for each instantiation of the module.

Use

module_name	The name of the module being declared.
inputs->outputs:>bidirs	A list of signals in the lower-level module used in the current source.  Signal names are separated by commas.  Use -> and :> to indicate the direction of each port of a functional block.
value	An optional default value for an input that overrides defaults in the lower-level module.
If the lower-level module uses the interface keyword to declare signals, the upper-level source interface statement must exactly match the signal listing.

CAUTION:  Interface declarations cannot contain dot extensions.  If you need a specific dot extension across a source boundary (to resolve feedback ambiguities, for example), you must introduce an intermediate signal into the lower-level module to provide the connection to the higher-level source.  All dot extension equations for a given output signal must be located in the ABEL-HDL module in which the signal is defined.  No references to the signal's dot extensions can be made outside of the ABEL-HDL module.

Note:  When you instantiate a lower-level module in an upper-level source, any signal attributes (either explicit or implicit) are inherited by the higher-level source signals that map to the lower-level signals.  Do not specify ISTYPEs for instantiated signals.

Examples

module top;
cnt4 interface (ce,ar,clk -> [q3..q0])

Map port names to signal names with equations.

See Also

Functional_block

Hierarchy in chapter 4


Interface (lower-level)

Syntax

MODULE module_name
INTERFACE (input/set[=port_value] -> output/set [:> bidir/set]);

Purpose

The interface declaration is optional for lower-level modules. Use the interface declaration in lower-level modules to assign a default port list and input values for the module when instantiated in higher-level ABEL-HDL sources. If you use the interface statement in an instantiated module, you must declare the signals and sets in the upper-level source in the same order and grouping as given in the interface statement in the lower-level module.

Declaring signals in the lower-level module, although optional, does allow the compiler to check for signal declaration mismatches and therefore reduces the possibility of wiring errors.

Use

module_name	The standard module statement.
signal/set	Signals or sets in the lower-level module used as ports to higher-level sources. Use -> and :> to indicate the direction of each port of a functional block. Use commas to separate groups of signals
port_value	The default value for the port for input signals only. Default values do not apply to output and bidirectional signals.


Istype _ Attribute Declarations

Syntax

signal [, signal...] [PIN | NODE [##s ] ]  ISTYPE 'attr [,attr  ]...';

Purpose

The ISTYPE statement defines attributes (characteristics) of signals (pins and nodes). You should use signal attributes to remove ambiguities in architecture-independent designs. Even when a device has been specified, using attributes ensures that the design operates consistently if the device is changed later.

Use

signal	A pin or node identifier.
attr	A string that specifies attributes for the signal(s). Supported attributes are described below.
Signal attributes are specified with the ISTYPE statement, which can be combined with pin or node declarations in a single declaration. The attributes defined with ISTYPE specify the architectural constraints for signals that have not been assigned to a specific device, pin, or node number, or a specified device (and/or pin number) that has programmable characteristics.

All attributes listed on the right side of the ISTYPE statement are applied to each signal specified on the left side.

Declarations of the pin and node names used in the ISTYPE statement must be made before or with the ISTYPE statement.

The following table summarizes the available attributes.

CAUTION:  If you do not specify signal attributes with Istype, the compiler makes assumptions about signal attributes that may or may not be what you intended.

Table G-5: Attributes

See Also

Dot Extensions


Library

Syntax

LIBRARY 'name' ;

Purpose

The LIBRARY statement causes the contents of the indicated file to be inserted in the ABEL-HDL source file. The insertion begins at the LIBRARY statement.

Use

name	A string that specifies the name of the library file, excluding the file extension.
The file extension of '.inc' is appended to the name specified, and the resulting filename is searched for. If no file is found, the abel5lib.inc library file is searched.

See Also

Module

@Include


Macro

Syntax

macro_id MACRO [ (dummy_arg [,dummy_arg ]... ) ] {block } ;

Purpose

The macro declaration statement defines a macro. Macros are used to include ABEL-HDL code in a source file without typing or copying the code everywhere it is needed.

Use

macro_id	An identifier naming the macro.

dummy_arg	A dummy argument.

block	A block.

A macro is defined once in the declarations section of a module and then used anywhere within the module as frequently as needed. Macros can be used only within the module in which they are declared.

Wherever the macro_id occurs, the text in the block associated with that macro is substituted. With the exception of dummy arguments, all text in the block (including spaces and end-of-lines) is substituted exactly as it appears in the block.

When debugging your source file, you can use the -list expand option to examine macro statements. The -list expand option causes the parsed and expanded source code (and the macros and directives that caused code to be added to the source) to be written to the listing file.

Macros and Declared Equations

Use declared equations for constant expressions (instead of macros ) for faster processing. The file, mac.abl, in  Figure G-11 demonstrates the difference:

Figure G-11: Differences Between MACRO and Declared Equations

Examples

The dummy arguments used in the macro declaration allow different actual arguments to be used each time the macro is referenced. Dummy arguments are preceded by a "?" to indicate that an actual argument is substituted for the dummy by the compiler.

The equation,

NAND3 MACRO (A,B,C) { !(?A & ?B & ?C) } ;

declares a macro named NAND3 with the dummy arguments A, B, and C. The macro defines a three-input NAND gate. When the macro identifier occurs in the source, actual arguments for A, B, and C are supplied.

For example, the equation

D = NAND3 (Clock,Hello,Busy) ;

brings the text in the block associated with NAND3 into the code, with Clock substituted for ?A, Hello for ?B, and Busy for ?C.

This results in:

D = !( Clock & Hello & Busy ) ;

which is the three-input NAND.

The macro NAND3 has been specified by a Boolean equation, but it could have been specified using another ABEL-HDL construct, such as the truth table shown here:

NAND3 MACRO (A,B,C,Y)
{ TRUTH_TABLE ( [?A ,?B ,?C ] -> ?Y )
                [ 0 ,.X.,.X.] ->  1 ;
                [.X., 0 ,.X.] ->  1 ;
                [.X.,.X., 0 ] ->  1 ;
                [ 1 , 1 , 1 ] ->  0 ; } ;

In this case, the line,

NAND3 (Clock,Hello,Busy,D)

causes the text,

TRUTH_TABLE ( [Clock,Hello,Busy] -> D )
               [  0  , .X. ,.X. ] -> 1 ;
              [ .X. ,  0  ,.X. ] -> 1 ;
              [ .X. , .X. , 0  ] -> 1 ;
              [  1  ,  1  , 1  ] -> 0 ;

to be substituted into the code. This text is a truth table definition of D, specified as the function of three inputs, Clock, Hello, and Busy. This is the same function as that given by the Boolean equation above. The truth table format is discussed under Truth_table.

Other examples of macros:

"macro with no dummy arguments
nodum macro { W = S1 & S2 & S3 ; } ;

onedum MACRO (d) { !?d } ; "macro with 1 dummy argument

and when macros are called in logic descriptions:

nodum
X = W + onedum(inp) ;
Y = W + onedum( )C ; "note the blank actual argument

resulting in:

"note leading space from block in nodum
 W = S1 & S2 & S3 ;
X = W + ! inp ;
Y = W + ! C ;

Recursive macro references (when a macro definition refers to itself) are not supported, and the compiler halts abnormally. If errors appear after the first use of a macro, and the errors cannot be easily explained otherwise, check for a recursive macro reference by examining the listing file.

See Also

Constant Declarations

Arguments and Argument Substitution in Chapter 4, "ABEL-HDL Design"


Module

Syntax

MODULE modname [ ( dummy_arg [,dummy_arg ] ...  ) ]

Purpose

The module statement defines the beginning of a module and must be paired with an END statement that defines the module's end.

Use

modname	An identifier naming the module.

dummy_arg	Dummy arguments.

The optional dummy arguments allow actual arguments to be passed to the module when it is processed. The dummy argument provides a name to refer to within the module. Anywhere in the module where a dummy argument is found preceded by a "?", the actual argument value is substituted.

Examples

MODULE MY_EXAMPLE (A,B)
  :
  C = ?B + ?A

In the module named MY_EXAMPLE, C takes on the value of "A + B" where A and B contain actual arguments passed to the module when the language processor is invoked.

See Also

Title

Interface (submodule)

End

Arguments and Argument Substitution in Chapter 4


Node

Syntax

[!]node_id [,[!]node_id...] NODE [node# [,node# ]] [ISTYPE 'attributes' ];

Purpose

The NODE keyword declares signals assigned to buried nodes.

Use

node_id	An identifier used for reference to a node in a logic design.
node#	The node number on the real device.
attributes	A string that specifies node attributes for devices with programmable nodes. Any number of attributes can be listed, separated by commas. Attributes are under Attributes in Chapter 4, "ABEL-HDL Design"
Note:  Using the NODE keyword does not restrict a signal to a buried node.  A signal declared with NODE can be assigned to a device I/O pin by a device fitter.

You can use the range operator (..) to declare sets of nodes. The ending semicolon is required after each declaration.

When lists of node_id and node # are used in one node declaration, there is a one-to-one correspondence between the identifiers and numbers.

The following example declares three nodes A, B, and C.

A, B, C NOD

E  ;

The node attribute string, Istype 'attributes,' should be used to specify node attributes. Since a node declaration is only required in a detailed description, use detailed attributes, not pin-to-pin attributes. The ISTYPE statement and attributes are discussed under Istype.

The node declaration,

B NODE istype 'reg' ;

specifies that node B is a buried flip-flop.

Example

a0..a3 node 22..25;

assigns a0, a1, a2 and a3 to nodes 22, 23, 24 and 25, respectively.

See Also

lstype

Pin

Module

Attribute Assignment and Architecture-independent Designs In chapter 4


Pin

Syntax

[!]pin_id [,[!]pin_id...] PIN  [pin# [, pin# ]] [ISTYPE 'attr' ];

Purpose

The PIN keyword declares input and output signals that must be available on a device I/O pin.

Use

pin_id	An identifier that refers to a pin in a module.
pin#	The pin number on the physical device.
attr	A string that specifies pin attributes for devices with programmable pins.  Attributes are listed in ISTYPE.
When lists of pin_ids and pin#s are used in a pin declaration statement, there is a one-to-one correspondence between the identifiers and numbers given. There must be one pin number associated with each identifier listed.

You can use the range operator (..) to declare sets of pins. The ending semicolon is required after each declaration.

Note:  Assigning pin numbers defines the particular pin-outs necessary for the design.  Pin numbers only limit the device selection to a minimum number of input and output pins.  Pin number assignments can be changed later by a fitter.

The ! operator in pin declarations indicates that the pin is active-low, and is automatically negated when the source file is compiled.

The pin attribute string, Istype 'attributes,' should be used to specify pin attributes. The ISTYPE statement and attributes are discussed under Istype. Istype attribute statements are recommended for all pins.

Examples

Clock, !Reset, S1 PIN 1,15,3;

Clock is assigned to pin 1, Reset to pin 15, and S1 to pin 3.

a0..a3 PIN 2..5 istype 'reg,buffer';

Assigns a0, a1, a2 and a3 to pins 2, 3, 4 and 5, respectively.

See Also

lstype

Node

Module

Architecture-independent Designs in chapter 4


Property

Syntax

property_id PROPERTY 'string' ;

Purpose

The property declaration statement allows you to specify additional design information associated with an external processing module (such as a device kit)  .

The format of the string depends on the fitter to which the property is being passed. See your device kit user manuals for syntax descriptions.

Note: You can specify properties for any number of fitters in your design, since all fitters process only properties with their property ID and ignore all other properties.

Use

property_id	Identifies properties relevant to specific external modules, such as fitters.
string	Argument containing the actual property data.
CAUTION: Property IDs and strings can be case-sensitive. Check your vendor's fitter documentation.

CAUTION: Property Information will not be present in pre-route/functional simulation. Consider using schematics to access property features that affect simulation

Example

AMDMACH property 'GROUP A Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0';.


State (Declaration)

Syntax

state_id [, state_id ...] STATE [IN statereg_id] ;

Purpose

The State declaration is made to declare a symbolic state name and, optionally, associate it with a state register.

Use

state_id	A symbolic state name to be referenced in a symbolic state description.
statereg_id	An identifier for a state register.
If your design includes more than one symbolic state machine, use the IN keyword to associate each state with the corresponding state register.

Each state you declare corresponds to one flip-flop in a one-hot machine.

See Also

Async_reset

State_register

Sync_reset

Symbolic State Declarations and Using Symbolic State Descriptions in chapter 4


State (in State_diagram)

Syntax

[STATE state_exp : [equation ]
       [equation ]
  :
  :
  :
trans_stmt ; ...]

Purpose

The state keyword and the associated section describes one state of a state diagram. It includes a state value (or a symbolic state name), a state transition statement, and optional state output equations.

Use

state_exp	An expression, value, or symbolic state name giving the current state.
equation	An equation that defines the state machine outputs.
trans_stmt	IF-THEN-ELSE, CASE, or GOTO statements, optionally followed by WITH transition equations.
The specification of a state description requires the use of the State_diagram syntax (which defines the state machine) and the If-Then-Else, Case, Goto, and With statements (which determine the operation of the state machine). Symbolic state machines (machines for which the actual state registers and state values are unspecified) require additional declarations for the symbolic state register and state names. See Symbolic State Declarations in Chapter 4, "ABEL-HDL Design".

A semicolon is required after each transition statement.

See Also

Async_reset	State
Case	State_diagram
@Dcset	Sync_reset
Equations	Truth_table
Goto	With
If-The-Else	Chapter 4
Module


State_diagram

Syntax

State_diagram state_reg
[-> state_out ]
[STATE state_exp : [equation ]
[equation ]
  :
trans_stmt ; ...]

Purpose

The state description describes the operation of a sequential state machine implemented with programmable logic.

Use

state_reg	An identifier or set of identifiers specifying the signals that determine the current state of the machine. For symbolic state diagrams, this identifier is a symbolic state register name that has been declared with a State_register declaration.
state_out	An identifier or set of identifiers that determines the next state of the machine (for designs with external registers).
state_exp	An expression or symbolic state name giving the current state.
Equation	An equation that defines the state machine outputs.
trans_stmt	IF-THEN-ELSE, CASE, or GOTO statements, optionally followed by WITH transition equations.
A semicolon is required after each transition statement.

Use State_diagram syntax to define a state machine, and the If-Then-Else, Case, Goto, and With statements to determine the operation of the state machine. Symbolic state machines (machines for which the actual state registers and state values are unspecified) require additional declarations for the symbolic state register and state names (see Symbolic State Declarations in Chapter 4, "ABEL-HDL Design").

The syntax for the IF-THEN-ELSE, CASE, GOTO, WITH, SYNC_RESET, and ASYNC_RESETstatements are presented here briefly, and are discussed further in their respective sections.

A state machine starts in one of the states defined by state_exp. The equations listed after that state are evaluated, and the transition statement (trans_stmt) is evaluated after the next clock, causing the machine to advance to the next state.

Equations associated with a state are optional; however, each state must have a transition statement. If none of the transition conditions for a state is met, the next state is undefined. (For some devices, undefined state transitions cause a transition to the cleared register state.)


State_register

Syntax

statereg_id STATE_REGISTER ;

Purpose

For symbolic state diagrams, the State_register is made to declare a symbolic state machine name.

Use

statereg_id	An identifier naming the state register.

See Also

State

State_diagram

Symbolic State Declarations and Using Symbolic Descriptions


Sync_reset

See Also

Async_reset


Test_vectors

Syntax

Test_vectors [note ]
(input [,input ]... -> output[,output ]...)

[invalues -> outvalues ; ]
  :

Purpose

Test vectors specify the expected functional operation of a logic device by explicitly defining the device outputs as functions of the inputs.

Note: Test_vectors are only used with PLD JEDEC file simulation. For functional simulation with the ABEL Simulator, use a test stimulus file.

Use

note	An optional string that describes the test vectors.
inputs	An identifier or set of identifiers specifying the names of the input signals, or feedback output signals.
outputs	An identifier or set of identifiers specifying the output signals.
invalues	An input value or set of input values.
outvalues	A pin-to-pin output value or set of output values resulting from the given inputs.
Test vectors are used for simulation of an internal model of the device and functional testing of the design and device. The number of test vectors is unlimited.

The format of the test vectors is determined by the header. Each vector is specified in the format described within the parentheses in the header statement. An optional note string can be specified in the header to describe what the vectors test, and is included as output in the simulation output file, the document output file, and the JEDEC programmer load file.

The table lists input combinations and their resulting outputs. All or some of the possible input combinations can be listed. All values specified in the table must be constants, either declared, numeric, or a special constant (for example, .X. and .C.). Each line of the table (each input/output listing) must end with a semicolon. Test vector output values always represent the pin-to-pin value for the output signals.

Test vectors must be sequential for state machines. Test vectors must go through valid state transitions.

The Trace keyword can be used to control simulator output from within the source file.

Functional testing of the physical device is performed by a logic programmer after a device has been programmed. The test vectors become part of the programmer load file.

Examples

Following is a simple test vectors section:

TEST_VECTORS
( [A,B] -> [C, D] )

  [0,0] -> [1,1] ;
  [0,1] -> [1,0] ;
  [1,0] -> [0,1] ;
  [1,1] -> [0,0] ;

The following test vectors are equivalent to those specified above because values for sets can be specified with numeric constants.

TEST_VECTORS
( [A,B] -> [C, D] )

    0   ->   3   ;
    1   ->   2   ;
    2   ->   1   ;
    3   ->   0   ;

If the signal identifiers in the test vector header are declared as active-low in the declaration section, then constant values specified in the test vectors are inverted accordingly (interpreted pin-to-pin).

See Also

Cycle

Module

Trace

Wait


Title

Syntax

title 'string'

Purpose

The title statement gives a module a title that appears as a header in both the programmer load file and documentation file created by the language processor.

Use

The title is specified in the string following the keyword, title. The string is opened and closed by an apostrophe and is limited to 324 characters.

The title statement is optional.

Asterisks in the title string do not appear in the programmer load file header in order to conform with the JEDEC standard.

Examples

An example of a title statement that spans three lines and describes the logic design is shown below:

module m6809a
title '6809 memory decode
Jean Designer
Data I/O Corp Redmond WA'

See Also

Module


Trace

Syntax

TRACE (inputs -> outputs) ;

Purpose

The TRACE statement controls which inputs and outputs are displayed in the simulation output.

Use

TRACE statements can be placed before a test vector section, or embedded within a sequence of test vectors.

Note: Test_vectors are only used with Equation and JEDEC file simulation. For functional simulation with the Verilog Simulator, use a test stimulus file.

Examples

TRACE        ( [A,B] -> [C  ] );
TEST_VECTORS ( [A,B] -> [C,D] )
                 0   ->   3    ;
                 1   ->   2    ;
TRACE        ( [A,B] -> [  D] );
                 2   ->   1    ;
                 3   ->   0    ;

See Also

Test_vectors


Truth_table

Syntax

TRUTH_TABLE ( in_ids -> out_ids )
              inputs -> outputs ;
    or
TRUTH_TABLE ( in_ids :> reg_ids )
              inputs :> reg_outs ;
    or
TRUTH_TABLE
( in_ids :> reg_ids  -> out_ids )
  inputs :> reg_outs -> outputs ;

Purpose

Truth tables specify outputs as functions of input combinations, in a tabular form.

Use

in_ids	Input signal identifiers.
out_ids	Output signal identifiers.
reg_ids	Registered signal identifiers.
Inputs	The inputs to the logic function.
outputs	The outputs from the logic function.
reg_outs	The registered (clocked) outputs.
->  :>	Indicates the input to output function for combinational (->) and registered (:>) outputs.

Truth tables are another way to describe logic designs with ABEL-HDL and may be used in lieu of (or in addition to) equations and state diagrams. A truth table is specified with a header describing the format of the table and with the table itself.

A semicolon is required after each line in the truth table.

The truth table header can have one of the three forms shown above, depending on whether the device has registered or combinational outputs or both.

The inputs and outputs (both registered and combinational) of a truth table are either single signals, or (more frequently) sets of signals. If only one signal is used as either the input or output, its name is specified. Sets of signals used as inputs or outputs are specified in the normal set notation with the signals surrounded by brackets and separated by commas (see Sets in Chapter 4, "ABEL-HDL Design").

The syntax shown in the first form defines the format of a truth table with simple combinational outputs. The values of the inputs determine the values of the outputs.

The second form describes a format for a truth table with registered outputs. The symbol ":" preceding the outputs distinguishes these outputs from the combinational outputs. Again the values of the inputs determine the values of the outputs, but now the outputs are registered or clocked: they will contain the new value (as determined by the inputs) after the next clock pulse.

The third form is more complex, defining a table with both combinational and registered outputs. It is important in this format to make sure the different specification characters "-" and ":" are used for the different types of outputs.


Wait

This keyword represents the relative time delay which effects the test vectors immediately following the WAIT statement. It can be used in the MACRO block only when MACRO is used in the TEST_VECTORS block. The default time unit is nano-second. The syntax for WAIT is:

WAIT < integer>;

Example

test_vectors MACRO {

WAIT 10;

1 -> [0,1];

WAIT 24;

6 -> [0,1];

WAIT 34;

8 -> [1.0];

};

Note: The Wait keyword is only defined in the Lattice Logic Simulator. They cannot be used with all of the supported special constants, except .R. See Special Constants for information.


When-Then-Else

Syntax

[ WHEN condition    THEN ] [  ! ] element=expression;
[ ELSE equation ];
          or
[ WHEN condition    THEN ] equation;  [ ELSE equation];

Purpose

The When-then-else statement is used in equations to describe a logic function.

Use

condition	Any valid expression.
element	An identifier naming a signal or set of signals, or an actual set, to which the value of the expression is assigned.
expression	Any valid expression.
=, :=, ?= and ?:=	Combinational and registered (pin-to-pin) assignment operators.
Equations use the assignment operators = and ?= (combinational), and := and ?:= (registered) described in Chapter 4, "ABEL-HDL Design".

The complement operator, "!", expresses negative logic. The complement operator precedes the signal name and implies that the expression on the right of the equation is to be complemented before it is assigned to the signal. Using the complement operator on the left side of equations is also supported; equations for negative logic parts can just as easily be expressed by complementing the expression on the right side of the equation.

CAUTION: When-Then-Else is only supported in equations. Use If-Then-Else in state_diagram descriptions.

Note: Equation blocks in conditional expressions such as WHEN-THEN result in logic functions that are logically ANDed with the conditional expression that is in effect.

Examples

WHEN        (Mode == S_Data) THEN  { Out_data := S_in;
                                     S_Valid  := 1;  }
ELSE WHEN   (Mode == T_Data) THEN  { Out_data := T_in;
                                     T_Valid  := 1;  }

See Also

Equations in chapter 4


With

Syntax

trans_stmt  state_exp WITH equation
[equation ]..;

Purpose

The WITH statement is used in the State_diagram section. When used in conjunction with the IF-THEN or CASE statement, it allows output equations to be written in terms of transitions.

Use

trans_stmt	The IF-THEN-ELSE, GOTO, or CASE statement.

state_exp	The next state.

equation	An equation for state machine outputs.

You can use the WITH statement in any transition statement, in place of a simple state expression.

The WITH statement is also useful when you are describing output behavior for registered outputs, since registered outputs written only for a current state would lag by one clock cycle.

To specify that a set of registered outputs should contain a specific value after one particular transition, specify the equation using a WITH statement similar to the one shown below:

STATE S0:
   IF (reset)  THEN S9 WITH { ErrorFlag := 1;
                              ErrorAddress := address;}
   ELSE   IF (address <= ^hE100)
          THEN S2
          ELSE   S0;

Examples

State 5 :
           IF a == 1 then 1   WITH { x := 1 ;
                                    y := 0 ;}
           ELSE 2    WITH { x := 0 ;
                           y := 1 ;}

See Also

State_diagram

Case

Goto

If-Then-Else


XOR_Factors

Syntax

XOR_Factors
signal name = xor_factors  ;

Purpose

Use XOR_factors to specify a Boolean expression to be factored out of (and XORed with) the sum-of-products reduced equations. Factors can dramatically reduce the reduced equations if you use a device featuring XOR gates.

Use

XOR_factors converts a sum of products (SOP) equation into an exclusive OR (XOR) equation. The resulting equation contains the sum of product functions that, when exclusive ORed together, have the same function as the original. The XOR_Factors equation is divided into the original equation, with the factor (or its complement) on one side of the XOR and the remainder on the other.

After deciding the best XOR_Factors, remember to revise the source file to use an XOR device for the final design.

Note: The assignment operator you use in XOR_Factors equations must match the assignment operator in the Equations section.

Examples

!Q16 =    A &  B &     !D
       #  A &  B & !C
       #      !B &  C &  D
       # !A &       C &  D;

Reordering the product terms indicates that (A & B) and (C & D) are good candidate factors, as shown below:

!Q16 =  A &  B & (!C # !D)
    # (!A # !B) &  C &  D;

If we process the following source file, the program reduces the equations according to the XOR_Factors, A & B.

module xorfact
   xorfact     device 'P20X10';
   Clk,OE      pin 1,13;
   A,B,C,D     pin 2,3,4,5;
   Q16         pin 16 istype 'reg,xor';
XOR_Factors
   Q16 := A & B;
equations
   !Q16   :=   A &  B &      !D
           #       !B &  C &  D
           #  !A &       C &  D
           #   A &  B & !C;
end

Using A & B as the XOR_Factors, the reduced equations are

!Q16 := ((A & B) $ (C & D));

Example 2

The example octalf.abl uses a more complex high-level equation:

module OCTALF
title 'Octal counter with xor factoring'

   octalf device 'P20X8';
   D0..D7                 pin  3..10;
   Q7..Q0                 pin  15..22 istype 'reg,xor';
   CLK,I0,I1,OC,,CarryIn  pin  1,2,11,13,23;
   CarryOut               pin  14 istype 'com';
   H,L,X,Z,C = 1, 0, .X., .Z., .C.;

   Data  = [D7..D0];
   Count = [Q7..Q0];

   Mode  = [I1,I0];
   Clear = [ 0, 0];
   Hold  = [ 0, 1];
   Load  = [ 1, 0];
   Inc   = [ 1, 1];

xor_factor
        Count.FB := Count & I0;

" ..comments removed..
equations
   Count  := (Count.FB + 1) & (Mode == Inc) & !CarryIn
           # (Count.FB    ) & (Mode == Inc) &  CarryIn
           # (Count.FB    ) & (Mode == Hold)
           # (Data     ) & (Mode == Load)
           # (0        ) & (Mode == Clear);

   !CarryOut       = !CarryIn & (Count.FB == ^hFF);

   Count.C  = CLK;
   Count.OE = !OC;
"..test vectors removed..
"..comments removed..
end OCTALF;


Using Pin-to-Pin Vs. Detailed Dot Extensions

Dot extensions allow you to refer to various circuit elements (such as register clocks, presets, feedback and output enables) that are related to a primary signal.

Some dot extensions are general purpose and are intended for use with a wide variety of device architectures. These dot extensions are therefore referred to as pin-to-pin (or "architecture-independent"). Other dot extensions are intended for specific classes of device architectures, or require specific device configurations. These dot extensions are referred to as detailed (or "architecture-dependent" or "device-specific") dot extensions.

In most cases, you can describe a circuit using either pin-to-pin or detailed dot extensions. Which form you use depends on the application and whether you want to implement the application in a variety of architectures. The advantages of each method are discussed later in this section.

Table G-1 lists the ABEL-HDL dot extensions. Pin-to-pin dot extensions are indicated with a check in the Pin-to-Pin column.


Detailed Design Dot Extensions

Table G-2 shows the dot extensions that are supported (and which of those are required) for different register types in detailed design descriptions. The required dot extensions are indicated with a check in the Extension Required column.

Table G-2: Dot Extensions for Device-specific (detailed) Designs


Pin-to-Pin Design Dot Extensions

Table G-3 shows the dot extensions that are allowable (and which of those are required) for pin-to-pin design descriptions. The required dot extensions are indicated with a check in the Required column.

Table G-3: Dot Extensions for Architecture-independent (pin-to-pin) Designs

Register Type	Required	Allowable Extensions	Definition
combinational (no register)		none  .oe  .pin	output  output enable  pin feedback
registered logic		.clr  .aclr  .set  .aset  .clk  .com  .fb  .pin	synchronous preset  asynchronous preset  synchronous set  asynchronous set clock  combinational feedback  registered feedback  pin feedback
Figure G-1 through Figure G-8 shows the effect of each dot extension. The actual source of the feedback may vary from that shown.

Figure G-1: Pin-to-pin Dot Extensions in an Inverted Output Architecture

Figure G-2: Pin-to-pin Dot Extensions in a Non-inverted Output Architecture

Figure G-3: Detailed Dot Extensions for a D-type Flip-flop Architecture

Figure G-4: Detailed Dot Extensions for a T-type Flip-flop Architecture

Figure G-5: Detailed Dot Extensions for an RS-type Flip-flop Architecture

Figure G-6: Detailed Dot Extensions for a JK-type Flip-flop Architecture

Figure G-7: Detailed Dot extensions for a Latch with active High Latch Enable

Figure G-8: Detailed Dot Extensions for a Latch with Active Low Latch Enable

Figure G-9: Detailed Dot Extensions for a Gated-clock D Flip-flop

Examples

These equations precisely describe the desired circuit as a toggling D-type flip-flop that is clocked by the input Clock, assuming ISTYPE 'reg_D,buffer':

Q1.clk = Clock;
Q1.D = !Q1.Q # Preset;

Register preset:

Q2.PR = S & !T;

Register reset:

Q2.RE = R & !T;

The same circuit can be described without ISTYPE 'buffer' as:

Q1.clk = Clock;
Q1 := !Q1.FB # Preset;
Q2.SET = S & !T; Q2.CLR = R & !T;

Three-state Output Enables

Output enables are described in ABEL-HDL with the .oe dot extension applied to an output signal name. For example,

Q1.oe = !enab;

The equation specifies that the input signal enab controls the output enable for an output signal named Q1.

Note: If you explicitly state the value of a fixed output enable, you restrict the device fitters' ability to map the indicated signal to a simple input pin instead of a three-state I/O pin.

See Also

Lstype

Attributes - Language Structure and Dot Extensions in Chapter 4


Constant Declarations

Syntax

id [,id ]... = expr [,expr ]... ;

Purpose

A constant declaration that defines constants used in a module.

Use

id	An identifier naming a constant to be used within a module.
expr	An expression defining the constant value.
Note: The equal sign (=) used for constant declarations in the Declarations section is also used for equations in the Equations section. See Operators in Chapter 4, "ABEL-HDL Design"

A constant is an identifier that retains a constant value throughout a module.

The identifiers on the left side of the equals sign are assigned the values listed on the right side. There is a one-to-one correspondence between the identifiers and the expressions listed. There must be one expression for each identifier.

The ending semicolon is required after each declaration.

Constants are helpful when you use a value many times in a module, especially when you may be changing the value during the design process. Constants allow you to change the value once in the declaration of the constant, rather than changing the value throughout the module.

Constant declarations may not be self-referencing. The following examples will cause errors:

X = X;

a = b;
b = a;

An include file, constant.inc, in the ABEL-HDL library file contains definitions for the most frequently used ABEL-HDL constants. To include this file, enter

Library 'constant' ;

Examples

ABC = 3 * 17;          " ABC is assigned the value 51
Y = 'Bc' ;             " Y =  ^h4263 ;
X =.X.;                " X means 'don't care'
ADDR = [1,0,15];       " ADDR is a set with 3 elements
A,B,C = 5,[1,0],6;     " 3 constants declared here
D pin 6;               " see next line
E = [5 * 7,D];         " signal names can be included
G = [1,2]+[3,4];       " set operations are legal
A = B & C;             " operations on identifiers are valid
A = [!B,C];            " set and identifiers on right


@Alternate -- Alternate Operator Set

Syntax

@alternate

Use

@Alternate enables an alternate set of operators. If you are more familiar with the alternate set, you may want to use this directive.

The alternate operators remain in effect until the @Standard directive is used or the end of the module is reached.

Using the alternate operator set precludes use of the ABEL-HDL addition, multiplication, and division operators because they represent the OR, AND, and NOT logical operators in the alternate set. The standard operators !, &, #, $, and !$ still work when @Alternate is in effect.

The alternate operator set is listed in Table G-4.

Table G-4: Alternate Operator Set

ABEL-HDL Operator	Alternate Operator	Description
!	/	NOT
&	*	AND
#	+	OR
$	: + :	XOR
!$	: * :	XNOR
See Also

@STANDARD


@Carry -- Maximum Bit-width for Arithmetic Functions

Syntax

@carry expression ;

Use

expression	A numeric expression.

The @Carry directive allows you to reduce the amount of logic required for processing large arithmetic functions by specifying how adders, counters, and comparators are generated.  The number generated by the expression indicates the maximum bit-width to use when performing arithmetic functions.

For example, for an 8-bit adder, a @Carry statement with an expression which results in 2 would divide the 8-bit adder into four 2-bit adders, creating intermediate nodes. This would reduce the amount of logic generated.

The statement:

@carry 1;

generates chains of one-bit adders and comparators for all subsequent adder and comparator equations (instead of the full look-ahead carry equations normally generated).

This directive automatically generates additional combinational nodes. Use different values for the @Carry statement to specify the types of adders and comparators required for the design. To specify that full lookahead carry should be generated (the default if no @Carry has been specified) use the statement:

@carry 0

Examples

@carry 2; "generate adder chain
[s8..s0] = [.x.,a7..a0]+[.x.,b7..b0]

See Also

Constant Declarations

Constants in Chapter 4, "ABEL-HDL Design"


@Const -- Constant Declarations

Syntax

@const id = expression ;

Use

id	An identifier.

expression	An expression.

@Const allows new constant declarations to be made in a source file outside the normal (and required) declarations section.

The @Const directive defines internal constants inside macros. Constants defined with @Const override previous constant declarations. You cannot use @Const to redefine an identifier that was used earlier in the source file as something other than a constant (for example, a macro or pin).

Examples

@CONST count = count + 1;

See Also

Constant Declarations

Constants in Chapter 4, "ABEL-HDL Design"


@Dcset -- Don't Care Set

Syntax

@dcset

Use

ABEL-HDL uses don't-care conditions to help optimize partially-specified logic functions. Partially-specified logic functions are those that have less than 2n significant input conditions, where n is the number of input signals. The @Dcset directive allows the optimization to use either 1 or 0 for don't cares to optimize these functions.

CAUTION: The @Dcset directive overrides Istype attributes 'dc', 'neg' and 'pos'.

See Also

@Onset

Istype 'dc'

?:= and ?= Assignment Operators


@Dcstate -- State Output Don't Cares

Syntax

@dcstate

Use

When @dcstate   is specified, all unspecified state diagram states and transitions are applied to the design outputs as don't cares. You must use this option in combination with @dcset or with the 'dc' attribute.

See Also

@DCSET

Istype 'dc'


@Exit -- Exit Directive

Syntax

@exit

Use

The @Exit directive stops processing of the source file with error bits set. (Error bits allow the operating system to determine that a processing error has occurred.)


@Expr -- Expression Directive

Syntax

@expr [ {block} ] expression ;

Use

block	A block.

expression	An expression.

@Expr evaluates the given expression and converts it to a string of digits in the default base numbering system. This string and the block are then inserted into the source file at the point where the @Expr directive occurs. The expression must produce a number.

@Expr can contain variable values and you can use it in loops with @Repeat.

Examples

@expr {ABC} ^B11 ;

Assuming that the default base is base ten, this example causes the text ABC3 to be inserted into the source file.


@If -- If Directive

Syntax

@if expression {block }

Use

expression	An expression.

block	A block of text.

@IF includes or excludes sections of code based on the value of an expression. If the expression is non-zero (logical true), the block of code is included.

Dummy argument substitution is supported in the expression.

Examples

@if (A > 17) { C = D $ F ; }


@Ifb -- If Blank Directive

Syntax

@IFB (arg) {block }

Use

arg	An actual argument, or a dummy argument preceded by a "?"

block	A block of text.

@IFB includes the text contained within the block if the argument is blank (if it contains 0 characters).

Examples

@IFB ()
{text here is included with the rest of the source file.}

@IFB ( hello ) { this text is not included }

@IFB (?A) {this text is included if no value is substituted for A.  }

See Also

Arguments and Argument Substitution in Chapter 4, "ABEL-HDL Design"


@Ifdef -- If Defined Directive

Syntax

@ifdef id {block }

Use

id	An identifier.

block	A block of text.

@IFDEF includes the text contained within the block, if the identifier is defined.

Examples

A pin 5 ;
@ifdef A { Base = ^hE000 ; }
"the above assignment is made because A was defined


@Ifiden -- If Identical Directive

Syntax

@ifiden (arg1,arg2 ) {block }

Use

arg1,2	Actual arguments, or dummy argument names preceded by a "?"

block	A block of text.

The text in the block is included if arg1 and arg2 are identical.

Examples

@ifiden (?A,abcd) { ?A device 'P16R4'; }

A device declaration for a P16R4 is made if the actual argument substituted for A is identical to abcd.


@Ifnb -- If Not Blank Directive

Syntax

@ifnb (arg) {block }

Use

arg	An actual argument, or a dummy argument name preceded by a "?"

block	A block of text.

@IFNB includes the text contained within the block if the argument is not blank (if it contains more than 0 characters).

Examples

@IFNB () { ABEL-HDL source here is not included with the rest of the source file.  }

@IFNB ( hello ) { this text is included }

@IFNB (?A) {this text is included if a value is substituted for A}


@Ifndef -- If Not Defined Directive

Syntax

@ifndef id {block }

Use

id	An identifier.

block	A block of text.

@IFNDEF includes the text contained within the block, if the identifier is undefined. Thus, if no declaration (pin, node, device, macro, or constant) has been made for the identifier, the text in the block is inserted into the source file.

Examples

@ifndef A{Base=^hE000;}
"if A is not defined, the block is inserted in the text


@Ifniden -- If Not Identical Directive

Syntax

@ifniden (arg1,arg2 ) {block }

Use

arg1,2	Actual arguments, or dummy argument names preceded by a "?"

block	A block of text.

The text in the block is included in the source file if arg1 and arg2 are not identical.

Examples

@ifniden (?A,abcd) { ?A device 'P16R8'; }

A device declaration for a P16R8 is made if the actual argument substituted for A is not identical to abcd.


@Include -- Include Directive

Syntax

@include filespec

Use

filespec	A string specifying the name of a file.

@INCLUDE causes the contents of the specified file to be placed in the ABEL-HDL source file. The inclusion begins at the location of the @INCLUDE directive. The file specification can include an explicit drive or path specification that indicates where the file is found. If no drive or path specification is given, the default drive or path is used.

Examples

@INCLUDE 'macros.abl' "file specification
@INCLUDE '\\incs\\macros.inc'  "DOS paths require 2 slashes

See Also

Library


@Irp -- Indefinite Repeat Directive

Syntax

@irp dummy_arg ( arg [,arg ]...  ) {block }

Use

dummy_arg	A dummy argument.
arg	An actual argument, or a dummy argument name preceded by a "?"
block	A block of text.
@IRP causes the block to be repeated in the source file n times, where n equals the number of arguments contained in the parentheses. Each time the block is repeated, the dummy argument takes on the value of the next successive argument.

Examples

@IRP A (1, ^H0A,0)
{B = ?A ; }

results in:

B = 1 ;
B = ^H0A ;
B = 0 ;

which is inserted into the source file at the location of the @IRP directive. Note that multiple assignments to the same identifier result in an implicit OR.

Note that if the directive is specified like this:

@IRP A (1,^H0A,0)
{B = ?A ; }

the resulting text would be:

B = 1 ; B = ^H0A ; B = 0 ;

The text appears all on one line because the block in the @IRP definition contains no end-of-lines. Remember that end-of-lines and spaces are significant in blocks.


@Irpc -- Indefinite Repeat, Character Directive

Syntax

@irpc dummy_arg (arg) {block }

Use

dummy_arg	A dummy argument.
arg	An actual argument, or a dummy argument name preceded by a "?"
block	A block.
@IRPC causes the block to be repeated in the source file n times, where n equals the number of characters contained in arg. Each time the block is repeated, the dummy argument takes on the value of the next character.

Examples

@IRPC A (Cat)
{B = ?A ;
}

results in:

B = C ;
B = a ;
B = t ;

which is inserted into the source file at the location of the @IRPC directive.


@Message -- Message Directive

Syntax

@message 'string'

Use

string	Any string.

@Message sends the message specified in string to your monitor. You can use this directive to monitor the progress of the parsing step of the compiler, or as an aid to debugging complex sequences of directives.

Examples

@message 'Includes completed'


@Onset -- No Don't Care's

Syntax

@onset

Use

The @onset directive disables the use of don't care input conditions for optimization.

See Also

@Dcset

lstype 'dc'


@page -- Page Directive

Syntax

@page

Use

Send a form feed to the listing file. If no listing is being created, @page has no effect.


@Radix -- Default Base Numbering Directive

Syntax

@radix expr ;

Use

expr	An expression that produces the number 2, 8, 10 or 16 to indicate a new default base numbering.
The @Radix directive changes the default base. The default is base 10 (decimal). This directive is useful when you need to specify many numbers in a base other than 10. All numbers that do not have their base explicitly stated are assumed to be in the new base. (See Numbers in Chapter 4, "ABEL-HDL Design".

The newly-specified default base stays in effect until another @radix directive is issued or until the end of the module is reached. Note that when a new @radix is issued, the specification of the new base must be in the current base format.

When the default base is set to 16, all numbers in that base that begin with an alphabetic character must begin with leading zeroes.

Examples

@radix 2 ;    "change default base to binary
@radix 1010 ;  "change from binary to decimal


@Repeat -- Repeat Directive

Syntax

@repeat expr {block }

Use

expr	A numeric expression.

block	A block.

@REPEAT causes the block to be repeated n times, where n is specified by the constant expression.

Examples

The following use of the repeat directive,

@repeat 5 {H,}

results in the insertion of the text "H,H,H,H,H," into the source file. The @REPEAT directive is useful in generating long truth tables and sets of test vectors. Examples of @REPEAT can be found in the example files.


@Setsize -- Set Indexing

Syntax

@setsize [expression];

Purpose

The @setsize directive generates a number corresponding to the number of elements in the expression, which must be a set. This directive is useful for set indexing operations.

Example

@SETSIZE [a,b,c]

generates the number 3.

For set indexing, you can use the @SETSIZE directive in macros in the following manner:

high macro (s) {?S[@SETSIZE(?S);-1..@SETSIZE(?S);/2-1]};

The high macro returns the upper half of a set of any size (the high 4 bits of an 8-bit set, for example).

Note: The terminating semicolons are required.

See Also

Set Indexing in Chapter 4, "ABEL-HDL Design"


@Standard -- Standard Operators Directive

Syntax

@standard

Use

The @standard option resets the operators to the ABEL-HDL standard. The alternate set is chosen with the @alternate directive.


Using Intermediate Expressions

You can use intermediate (constant) expressions in the declarations section to reduce the number of output pins required to implement multi-level functions. Intermediate expressions can be useful when a module has repeated expressions. In general, intermediate expressions

•	decrease the number of output pins required, but

•	increase the amount of logic required per output.

A constant expression is interpreted as a string of characters, not as a function to be implemented. For example, for the following Declarations and Equations

Declarations
  TMP1 = [A3..A0] == [B3..B0];
  TMP2 = [A7..A4] == [B7..B4];
Equations
  F = TMP1 & TMP2;

the compiler substitutes the declarations into the equations, creating

F = (A7 !$ B7) & (A6 !$ B6) & (A5 !$ B5) & (A4 !$ B4) &
    (A3 !$ B3) & (A2 !$ B2) & (A1 !$ B1) & (A0 !$ B0);

In contrast, if you move the constant declarations into the equations section:

Declarations
  TMP1,TMP2 pin 18,19
Equations
  TMP1 = [A3..A0] == [B3..B0];
  TMP2 = [A7..A4] == [B7..B4];
  F = TMP1 & TMP2;

the compiler implements the equations as three discrete product terms, with the result

TMP1 =(A3 !$ B3) & (A2 !$ B2) & (A1 !$ B1) & (A0 !$ B0);
TMP2 =(A7 !$ B7) & (A6 !$ B6) & (A5 !$ B5) & (A4 !$ B4);
  F = TMP1 & TMP2;

The first example (using intermediate expressions) requires one output with 16 product terms, the second example (using equations) requires three outputs with less than 8 product terms per output. In some cases, the number of product terms required for both methods can be reduced during optimization.

Note: As an alternate method for specifying multi-level circuits such as this, you can use the @CARRY directive. See "@directive" later in this chapter.

See Also

Declarations

Equations

Constants in Chapter 4


Creating Multiple Instances

You can use the range operator (..) to instantiate multiple instance names of the module. For example,

CNT0..CNT3 functional_block cnt4 ;

creates 4 instances of the lower-level module cnt4.


Mapping Ports to Signals

Signal names are mapped to port names, using equations (similar to wiring the signals on a schematic). You need to specify only the signals used in the upper-level source, if default values have been specified in the lower-level module interface statement. See "Interface (lower-level)" in this chapter for more information on setting default values.

To specify the signal wiring, map signal names to the lower-level module port names with dot extension notation. There are three kinds of wire: input, output, and interconnect.

Input Wire	Connects lower-level module inputs to upper-level source inputs.  Instance.port = input
Output Wire	Connects upper-level source outputs to lower-level module outputs.  output = instance.port
Interconnect Wire	Connects the outputs of one instance of a lower-level module to another instance's inputs.  Instance0.port = instance1.port
Examples

module counter;

cnt4 interface (ce, ar, clk, [q0..q3]); // cnt4's top-level interface declaration.
CNT0..CNT3 functional_block cnt4;       // Four instances of cnt4.

Clk, AR, CE pin;
Q0..Q3 pin;

equations
    CNT0.[clk, ar, ce] = [Clk; AR, CE]; // Connecting to Clk, AR, and CE inputs.
    CNT0.[q0..q3] = [Q0..Q3];           // Connecting to Q0..Q3 outputs.
End

Figure G-10 shows how the above ABEL-HDL file wires the upper-level source's signals to the lower-level module's ports. Note that the above file instantiates four instances of cnt4, but only one (CNT0) is wired.

Figure G-10: Wiring of CNT0


Unused Outputs (no connects)

If you do not want to use a lower-level module's outputs, specify them as No Connects (NC) by not wiring up the port to a physical pin. For example, to make a 3-bit counter out of a 4-bit counter in the upper-level source, you might use the following wiring equations:

q2..q0 pin ; "upper-level signals
Equations
  [q2..q0] = CNT_A.[q2..q0]

See Also

Interface (top-level)

Hierarchy in Chapter 4 ABEL-HDL Design


Overriding Default Values

You can override the default values given in a lower-level module's interface statement by specifying default equations in the higher-level source. For example, if you have specified a default value of 1 for the signal ce in interface cnt4 (but in instance CNT0, you want ce to be 0), you would write:

CNT0.ce = 0 ;

This equation overrides the 1 with a 0. If you override the default values, you may want to re-optimize the post-linked design.

Figure G-10: Wiring of CNT0


Declared Signals

Declared signals can be a list of lower-level pins, sets, or a combination of both. The following constraints apply to the different signal types:

Signal Type	Constraints
Input	Default values must be binary if applied to an individual bit, or any positive integer applied to a set. All inputs must be listed.
Output	Unlisted outputs are interpreted as No connects (NC). Unlisted, fed-back outputs are interpreted as nodes in the upper-level source, following the naming convention  instance_name/node_name
Bidirectional	Listing bidirectional signals is optional, except for those with output enable (OE). If you specify bidirectional signals, the compiler checks for invalid wire connections.
CAUTION:  Interface declarations cannot contain dot extensions.  If you need a specific dot extension across a source boundary (to resolve feedback ambiguities, for example), you must introduce an intermediate signal into the lower-level module to provide the connection to the higher-level source.  All dot extension equations for a given output signal must be located in the ABEL-HDL module in which the signal is defined.  No references to the signal's dot extensions can be made outside of the ABEL-HDL module.

Note:  When you instantiate a lower-level module in a higher-level source, any signal attributes (explicit or implicit) are inherited by the higher-level source signals that map to the lower-level signals.  Do not specify ISTYPEs for instantiated signals.


Unlisted Signals

If you do not list some signals of the lower-level module in the interface statement, the following rules apply:

Unlisted Pins Are:	The Compiler Interprets Them As:
Inputs or Bidirectionals with OE	Errors
Outputs	No Connects (NC), and they can be removed
Feedback outputs	Nodes in the upper-level source, following the naming convention:  instance_name/node_name
Examples

The following interface statement declares inputs ce, ar, and clk (giving default values for two of them) and outputs q3 through q0.

module cnt4 interface (ce=1,ar=1,clk -> [q3..q0]) ;

Specifying default values allows you to instantiate cnt4 without declaring the ce and ar inputs in the upper-level source. If you do not declare these inputs, they are replaced with the constants 1 and 0, respectively. Since these constants may affect optimization, you may need to re-optimize the lower-level module with the constants.

Note:  Supported default values are 1, 0, or X (don't care).  You can  give default values for a set with a positive integer, and each digit of the integer's binary form supplies the default value for the corresponding signal in the set.

See Also

Interface (top-level)

Functional_block

Hierarchy in chapter 4


'buffer'

The target architecture does not have an inverter between the associated flip-flop (if any) and the actual output pin.


'invert'

The target architecture has an inverter between the associated flip-flop (if any) and the actual output pin.

Control of output inversion in devices is accomplished through the use of the 'invert' or 'buffer' attributes. These attributes enforce the existence ('invert') or non-existence ('buffer') of a hardware inverter at the device pin associated with the output signal specified.

In registered devices, the 'invert' attribute ensures that an inverter is located between the output pin and its associated register output.

Note:  Ensuring an inverter is important for both pin-to-pin and detailed design descriptions because the location of the inverter affects a register's reset, preset, preload, and powerup behavior as observed on the associated output pin.


'collapse'

Collapse (remove) this combinational node. If neither 'keep' nor 'collapse' is specified, the optimization and fitter programs will keep or collapse the node for best optimization. In the following example, signal b is given the 'collapse' attribute:

module coll_b
a,c,d,e   pin ;
b         node istype 'collapse'

equations
a = b & e;
b = c & d;
end

The resulting equation collapses b out of the equations:

a = c & d & e ;


'keep'

Do not collapse this combinational node from equations.  In the example under 'collapse,' b would be retained.


'com'

Specifies a combinational symbol.


'dc,' 'neg,' and 'pos'

These attributes control the value of unspecified logic in your design, and are mutually exclusive.  The values they specify are shown below:

Istype Attribute	Unspecified Logic is
'dc'	X (don't care)
'neg'	1
'pos'	0
The 'dc' attribute is equivalent to the @DCSET directive, except it operates on signals instead of applying to a whole section.

Note: The 'neg' or 'pos' attribute is implied if a device is specified.  For example, 'neg' is implied if the device output is inverted (for example, with a 16L8).

CAUTION: The @DCSET directive overrides 'dc,' 'neg,' and 'pos'.


'reg'

The signal specified is a registered output. Equations, state diagrams, and truth tables will generate logic for a D-type flip-flop, normalized to take into account any inverters in the target device.


'reg_d'

The signal specified is a registered output. Equations, state diagrams, and truth tables will generate logic for a D-type flip-flop, but you must specify if the output is inverted in the target device (with attribute 'invert' or 'buffer').


'reg_g'

The signal specified is a registered output. Equations, state diagrams, and truth tables will generate logic for a D-type flip-flop, but you must specify if the output is inverted in the target device (with attribute 'invert' or 'buffer'). Write equations and truth tables using the .D and .CE dot extensions when you use this attribute.


'reg_jk'

The signal specified is a JK-type registered output. State diagrams generate logic for this register type, but you must specify if the output is inverted in the target device (with attribute 'invert' or 'buffer'). Write Equations and truth tables using the .J and .K dot extensions when you use this attribute.


'reg_sr'

The signal specified is an SR-type registered output. State diagrams will generate logic for this register type, but you must specify if the output is inverted in the target device (with attribute 'invert' or 'buffer'). Write equations and truth tables using the .S and .R dot extensions when you use this attribute.


'reg_t'

The signal specified is a T-type registered output. State diagrams will generate logic for this register type, but you must specify if the output is inverted in the target device (with attribute 'invert' or 'buffer'). Write equations and truth tables using the .T dot extension when you use this attribute.


'retain'

Do not minimize this output. Preserve redundant product terms for the signal.


'xor'

The signal specified will be implemented using an XOR gate fed by two sum-of-products logic circuits. If you use XOR operators in the design equations for this output (or if you use high-level operators that result in XOR operations), then one XOR operator is retained through optimization. Use this attribute if you are implementing your design in an architecture featuring XOR gates.

Examples

F0, A istype 'invert, reg' ;

This declaration statement defines F0 and A as inverted registered outputs. You must define both F0 and A earlier in the module. The following signal declarations are all supported

q3,q2,q1,q0   NODE ISTYPE 'reg_SR';
Clk,a,b,c     PIN 1,2,3,4;
reset         PIN;
reset         ISTYPE 'com';
Output        PIN 15 ISTYPE 'reg,invert';

See Also

ext

Pin

Node

Dot Extensions and Attribute Assignment in chapter 4

Architecture-independent Designs and XOR Factor in chapter 4


Transitions Statements

Transition statements describe the conditions that cause transition from one state to the next. Each state in a state diagram must contain at least one transition statement. Transition statements can consist of GOTO statements, IF-THEN-ELSE conditional statements, CASE statements, or combinations of these different statements.

GOTO Syntax

GOTO state_exp ;

The GOTO statement unconditionally jumps to a different state. When GOTO is used, it is the only transition for the current state. Example:

STATE S0:
   GOTO S1;  "unconditional branch to state S1

CASE Syntax

CASE  expression : state_exp ;
[ expression : state_exp ; ] ...
ENDCASE ;

The CASE statement is used to list a sequence of mutually-exclusive transition conditions and corresponding next states. Example:

STATE S0:
   CASE (sel == 0): S0 ;
        (sel == 1): S1 ;
   ENDCASE

CASE statement conditions must be mutually exclusive. No two transition conditions can be true at the same time, or the resulting next state is unpredictable.

IF-THEN-ELSE Syntax

IF expression THEN state_exp
[ ELSE state_exp ] ;

IF-THEN-ELSE statements specify mutually-exclusive transition conditions. Example:

STATE S0:
   IF (address > ^hE100) THEN S1 ELSE S2;

You can use blocks in IF-THEN-ELSE statements, for example,

IF (Hold)  THEN State1 WITH {o1 := o1.fb;  o2 := o2.fb;}
ELSE State2;

The ELSE clause is optional. A sequence of IF-THEN statements with no ELSE clauses is equivalent to a sequence of CASE statements. IF-THEN-ELSE statements can be chained and nested. See IF-THEN-ELSE for more information.

WITH Syntax

state_exp WITH equation ;
[equation  ; ]

You can use the WITH statement in any of the above transition statements (the GOTO, IF-THEN-ELSE, or CASE statements) in place of a simple state expression. For example, to specify that a set of registered outputs are to contain a specific value after one particular transition, specify the equation using a WITH statement similar to the one shown below:

STATE S0:
   IF (reset)
        THEN S9 WITH {
                  ErrorFlag := 1;
                  ErrorAddress := address;
                }
   ELSE
   IF (address <= ^hE100)
        THEN S2
   ELSE
        S0;

The WITH statement is also useful when you describe output behavior for registered outputs (since registered outputs written only for a current state would lag by one clock cycle).

SYNC_RESET and ASYNC_RESET Syntax

In symbolic state descriptions the SYNC_RESET and ASYNC_RESET statements are used to specify synchronous or asynchronous state machine reset logic in terms of symbolic states. For example, to specify that a state machine must asynchronously reset to state Start when the Reset input is true, you would write

ASYNC_RESET Start : Reset ;

See Symbolic State Declarations and State Machines in Chapter 4, "ABEL-HDL Design."

See Also

Async_reset	State
Case	Sync_reset
@Dcset	Truth_table
Equations	With
Goto	State_register
If-The-Else	Symbolic State Declarations in Chapter 4
Module


State Descriptions and Pin-to-Pin Descriptions

State Descriptions and Pin-to-Pin Descriptions

Sequential circuits described with ABEL-HDL's state diagram language are normally written with a pin-to-pin behavior in mind, regardless of the flip-flop type specified.

The state machine shown below operates the same (in terms of the behavior seen on its outputs) no matter what type of register is substituted for 'reg' in the signal declarations. To allow this flexibility, the specification of 'buffer' or 'invert' is required when a state diagram is written for a register type other than 'reg.

 Figure G-12: Architecture-independent State Machine

See Also

Async_reset	State
Case	Sync_reset
@Dcset	Truth_table
Equations	With
Goto	State_register
If-The-Else
Module


Truth Table Format

The truth table is specified according to the form described within the parentheses in the header. The truth table is a list of input combinations and resulting outputs. All or some of the possible input combinations may be listed.

All values specified in the table must be constants, either declared, numeric, or the special constant .X. Each line of the table (each input/output listing) must end with a semicolon.

The header defines the names of the inputs and outputs. The table defines the values of inputs and the resulting output values.

Examples

This example shows a truth table description of a simple state machine with four states and one output. The current state is described by signals A and B, which are put into a set. The next state is described by the registered outputs C and D, which are also collected into a set. The single combinational output is signal E. The machine simply counts through the different states, driving the output E low when A equals 1 and B equals 0.

TRUTH_TABLE ( [A,B] :> [C,D] -> E )
                0   :>   1   -> 1 ;
                1   :>   2   -> 0 ;
                2   :>   3   -> 1 ;
                3   :>   0   -> 1 ;

Note that the input and output combinations are specified by a single constant value rather than by set notation. This is equivalent to:

[0,0] :> [0,1] -> 1 ;
[0,1] :> [1,0] -> 0 ;
[1,0] :> [1,1] -> 1 ;
[1,1] :> [0,0] -> 1 ;

When writing truth tables in ABEL-HDL (particularly when describing registered circuits) follow the same rules for dot extensions, attributes, and pin-to-pin/detailed descriptions described earlier for writing equations. The only difference between equations and truth tables is the ordering of the inputs and outputs.

The following two fragments of source code, for example, are functionally equivalent:

Fragment 1:

equations

   q := a & load # !q.fb & !load;

Fragment 2:

truth_table   (  [a ,q.fb,load] :> q)
                 [0 ,  0 ,  0 ] :> 1;
                 [0 ,  1 ,  0 ] :> 0;
                 [1 ,  0 ,  0 ] :> 1;
                 [1 ,  1 ,  0 ] :> 0;
                 [0 ,  0 ,  1 ] :> 0;
                 [1 ,  0 ,  1 ] :> 1;
                 [0 ,  1 ,  1 ] :> 0;
                 [1 ,  1 ,  1 ] :> 1;

As an example, the following truth table defines an exclusive-OR function with two inputs (A and B), one enable (en), and one output (C):

TRUTH_TABLE ( [en, A , B ] ->  C )
              [ 0,.X.,.X.] -> .X.;" don't care w/enab off
              [ 1, 0 , 0 ] ->  0 ;
              [ 1, 0 , 1 ] ->  1 ;
              [ 1, 1 , 0 ] ->  1 ;
              [ 1, 1 , 1 ] ->  0 ;

See Also

Module

Equations

State_diagrams

@Dcset


Table 1

Table G-1: Dot Extensions

Dot Ext.	Pin-to-pin	Description
.ACLR3,4		A device-independent asynchronous register reset, equivalent to .AR with ISTYPE 'buffer' (or .AP with ISTYPE 'invert').
.AP		Asynchronous register preset
.AR		Asynchronous register reset
.ASET2,3		A device-independent asynchronous register preset, equivalent to .AP with ISTYPE 'buffer' (or .AR with ISTYPE 'invert').
.CE		Clock-enable input to a gated-clock flip-flop
.CLK1		Clock input to an edge-triggered flip-flop
.CLR2,3		A device-independent synchronous register reset, equivalent to .SR with ISTYPE 'buffer' (or .SP with ISTYPE 'invert').
.COM3		A combinational feedback from the flip-flop data input, normalized to the pin value and used to distinguish between pin (.PIN) and internal logic array (.COM) feedback.
.D1		When on the left side of an equation, .D is the data input to a D-type flip-flop; on the right side, .D is combinational feedback.
.FB		Register feedback
.FC		Flip-flop mode control
.J		J input to a JK-type flip-flop
.K		K input to a JK-type flip-flop
.LD		Register load input
.LE		Latch-enable input to a latch
.LH		Latch-enable (high) to a latch
.OE1		Output enable
Dot Ext.	Pin-to-pin	Description
.PIN		Pin feedback
.PR1		Register preset (synchronous or asynchronous)
.Q		Register feedback
.R		R input to an SR-type flip-flop
.RE1		Register reset (synchronous or asynchronous)
.S		S input to an SR-type flip-flop
.SET2,3		A device-independent synchronous register preset, equivalent to .SP with ISTYPE 'buffer' (or .SR with ISTYPE 'invert').
.SP		Synchronous register preset
.SR		Synchronous register reset
.T		T input to a T-type (toggle) flip flop
1.	Example follows.

2.	If ISTYPE 'buffer' or 'invert' is specified, the compiler converts these dot extensions to the equivalent detailed dot extension.

3.	Some fitters do not support these dot extensions.


Table 2

Dot Extensions for Device-specific (detailed) Designs

Register Type	Extension Required	Supported Extensions	Definition
combinational (no register)		.oe  .pin  .com	output enable  pin feedback  combinational feedback
D-type flip-flop		.clk  .d  .fc  .oe  .q  .sp  .sr  .ap  .ar  .pin	clock  data input  flip-flop mode control  output enable  flip-flop feedback  synchronous preset  synchronous reset  asynchronous preset  asynchronous reset  pin
JK-type flip-flop		.clk  .j  .k  .fc  .oe  .q  .sp  .sr  .ap  .ar  .pin	clock  j input  k input  flip-flop mode control  output enable  flip-flop feedback  synchronous reset  synchronous reset  asynchronous preset  asynchronous reset  pin feedback
Register Type	Extension Required	Supported Extensions	Definition
SR-type flip-flop		.clk  .s  .r  .oe  .q  .sp  .sr  .ap  .ar  .pin	clock  set input  reset input  output enable  flip-flop feedback  synchronous preset  synchronous reset  asynchronous preset  asynchronous preset  pin feedback
T-type flip-flop		.clk  .t  .oe  .q  .sp  .sr  .ap  .ar  .pin	clock  toggle input  output enable  flip-flop feedback  synchronous preset  synchronous reset  asynchronous preset  asynchronous reset  pin feedback
L-type latch		.d  .le  .lh  .oe  .q  .pin	data input  latch enable input to a latch  latch enable (high) input to a latch  output enable  flip-flop feedback  pin feedback
Gated clock D flip-flop		.clk or .ce  .d  .oe  .q  .pin	clock or clock enable  data input  output enable  flip-flop feedback  pin feedback


Table 3

Attributes

Dot  Ext.	Arch.  Indep.	Description
'buffer'		No Inverter in Target Device
'collapse'		Collapse (remove) this signal.1
'com'		Combinational output
'dc'		Unspecified logic is don't care.2
'invert'		Inverter in Target Device
'keep'		Do not collapse this signal from equations.1
'neg'		Unspecified logic is 1.2
'pos'		Unspecified logic is 0.2
'retain'		Do not minimize this output. Preserve redundant product terms.3
'reg'		Clocked Memory Element.
'reg_d'		D Flip-flop Clocked Memory Element
'reg_g'		D Flip-flop Gated Clock Memory Element
'reg_jk'		JK Flip-flop Clocked Memory Element
'reg_sr'		SR Flip-flop Clocked Memory Element
'reg_t'		T Flip-flop Clocked Memory Element
'xor'		XOR Gate in Target Device
1If neither 'keep' nor 'collapse' is specified, the optimization or fitter programs can keep or collapse the signal as needed to optimize the circuit.

2The 'dc,' 'neg,' and 'pos' attributes are mutually exclusive.

3The 'retain' attribute only controls optimization performed by ABEL-HDL Compile Logic.  To preserve redundant product terms, you must also specify no reduction for the Reduce Logic and fitting (place and route) programs.


Example 9

Differences Between MACRO and Declared Equations

module mac
title 'Demonstrates difference between MACRO and declared equations'
        mac       device 'P16H8';
        A,B,C,    pin 1,2,3;
        X1,X2,X3  pin 14,15,16 istype 'com';
        Y1  macro {B # C};
        Y2 = B # C;

equations
        X1 = A & Y1;
        X2 = A & (Y1);
        X3 = A & Y2;

" Note: Because Y1 is a text replacement macro the equation
" for X1 will expand to  A & B # C. If the desired function
" was A & (B # C) use parentheses around the macro or use
" a subexpression (Y1=B#C) instead of the macro in the declarations.

" The macro could also be written       Y1 macro {(B # C)};

test_vectors   ([A,B,C] -> [X1,X2,X3])
                [0,0,0] -> [ 0, 0, 0];
                [0,0,1] -> [ 1, 0, 0];
                [0,1,0] -> [ 0, 0, 0];
                [0,1,1] -> [ 1, 0, 0];
                [1,0,0] -> [ 0, 0, 0];
                [1,0,1] -> [ 1, 1, 1];
                [1,1,0] -> [ 1, 1, 1];
                [1,1,1] -> [ 1, 1, 1];
end


Example 10

Architecture-independent State Machine

module statema
title 'State machine example';
  clock,hold,reset    pin;
  P1,P0     pin  istype 'reg,buffer';
  C = .c.;

equations
  [P1,P0].clk   = clock;
  [P1,P0].ar    = reset;

" state declarations...
declarations
  statema = [P1,P0]
  stateA  = [0,0];
  stateB  = [1,0];
  stateC  = [1,1];
  stateD  = [0,1];

state_diagram statema
  state stateA:
       goto stateB;
  state stateB:
       goto stateC;
  state stateC:
       goto stateD;
  state stateD:
       goto stateA;
"test_vectors edited
end


Lattice Constraint File Description

The VCI file is used to specify optimization options and hardware-specific parameters and is read by the ispDesignEXPERT software.


About the VCI File Format

The VCI file is a flat ASCII file.  The order of sections within the file does not make a difference.

A sample VCI file might look like this:

//Comments

[Device]	//This is the section label

Family=M4;

PartNumber=M4-32/32-7JC;

Package=44PLCC;	//This is a section member

PartType=M4-32/32;

Speed=-7;

Operating_condition=COM;

[Revision]

DATE=08/26/98;

TIME=16:10:51;

Traitor


Rules for Writing VCI Files

Comments.  A comment is any text that follows a double forward slash (//).  The double-slash can appear anywhere on a line.  The comment ends with that line of text.

•	Blank lines are ignored.

•	Maximum line length = 255 characters.

•	You can only specify one section-member per line i.e. Family = M4;.

•	All constructs are case insensitive except for the package specification.  For example

•	PartNumber=m4-32/32-7JC;	//This is correct

•	PartNumber=m4-32/32-7jc;	//This is incorrect. The package and temperature specifications must be upper case.

•	Blank spaces in the Section labels are considered part of the labels. For example, you cannot have blank spaces in the Section Labels between the left and right brackets “[“ and “]”. For example:

•	Good:       [LOCATION ASSIGNMENTS]
Bad:        [  LOCATION ASSIGNMENTS  ]


Command Line Requirement

See Running from the Command Line.


Layer Command

Use the Layer command to indicate whether a Sub-body has reserved keywords in the section.  For example in the Pin Reservation section, Layer must be turned off because individual signals are described without any keywords.

Example:

layer = OFF;	   // layer is turned off because

input_1 = INPUT,3,A,-;	   // input_1 is not a keyword but a signal

input_2 = INPUT,2,A,-;

Clk = INPUT,11,-,-;

output_q = OUTPUT,9,A,-;


VCI File Constructs

This document only covers the important VCI constructs.  There are others that this document does not cover.  The VCI file calls a parent vci file in the /config directory.  If you do not specify any constructs, they default to the values in the parent file.  The VCO file contains all possible constructs.

This document is split into 4 sections.

[DEVICE]

[REVISION]

[IGNORE ASSIGNMENTS]

[CLEAR ASSIGNMENTS]

Each has an example for a typical design.  Each section is split into constructs, for example:

Family=

A description and other important information are given about these constructs.  Some of the information requires the use of a data book to obtain the exact specification.


[DEVICE]

This section specifies the physical characteristics of the device

Example:

[DEVICE]

Family = M4;

PartType = M4-32/32;

Package = 44PLCC;

PartNumber = M4-32/32-7JC;

Speed = -7;

Operating_condition = COM;

Voltage = 5.0;

Family

Description: Specifies the family of device targeted.

Mandatory: No

Options: MACH1 | MACH2 | M4 | M4A | M4LV | M5 | M5A | M5LV | PLD | PLDLV

Example: Family = M4;

PartNumber

Description: Specifies the full part name, number and speed.

Mandatory: Yes

Options: For the full device name, please consult the Data book.

Example: PartNumber = M4A-32/32-7JC;

PartType

Description: Specifies the part name and number.

Mandatory: No

Options: For the part type, please consult the Data book.

Example: PartType = M4A-32/32;

Required for: Timing Analysis and sdf Generator.

Speed

Description: Specifies the speed of the target device.

Mandatory: No

Options: -5 | -7 | -10 | -12 | -14 | -15 | -18 | -20

Example: Speed = -7

Required for: Timing Analysis and sdf Generator.

Package

Description: Specifies the package and pin count of the target device.

Mandatory: No

Options: For device package availability, please consult the Data Book

Example: Package = 44TQFP;

Required for: This data is required by the fitter report.

Operating_condition

Description: Specifies the operating environment of the target device.

Mandatory: No (Defaults to COM)

Options: COM=commercial, IND=industrial

Example: Operating_condition = COM;.

Required for: Timing Analysis and sdf generator.

Voltage

Description: Specifies the voltage for the target device

Mandatory: No (Defaults to device selected)

Options: 5.0 | 3.0

Example: Voltage = 5.0V

Required for: Timing Analysis and sdf generator


[REVISION]

Example:

[Revision]

Design=;

Parent=M4.vci;

DATE=08/26/98;

TIME=16:10:51;

Design

Description: Specifies the working design

Mandatory: No

Options: Insert current working design

Example: Design = almclk;

Required for: Project Navigator

Date

Description: Specifies Data of last project save

Mandatory: No

Options: <Month>/<day>/<year>

Example: Date = 5/14/1999

Required for: Used in fitter report

Time

Description: Specifies time of last project save

Mandatory: No

Options: <hours>:<minutes>:<seconds>;

Example: Time = 17:00:00;

Required for: Used in fitter report

Parent

Description: Calls the parent vci file

Mandatory: Yes

Options:

Target Device	Parent vci file
MACH1 family	Mach1.vci
MACH2 family	Mach2.vci
PAL 5V family	Pld.vci
PAL 3V family	Pldvl.vci
M4 family	M4.vci
M4A family	M4A.vci
M4LV family	M4LV.vci
M5 128 family	m5128.vci (5v) | m5a128.vci (‘A’ device) | m5l128.vci (3v)
M5 192 family	m5192.vci (5v) | m5a192.vci (‘A’ device) | m5l192.vci (3v)
M5 256 family	m5256.vci (5v) | m5a256.vci (‘A’ device) | m5l256.vci (3v)
M5 384 family	m5384.vci (5v) | m5a384.vci (‘A’ device) | m5l384.vci (3v)
M5 512 family	M5512.vci (5v) | m5a512.vci (‘A’ device) | m5l512.vci (3v)
Example: Parent = m5a512.vci


[IGNORE ASSIGNMENTS]

This section defines the constraints, which are ignored for the fit.  The constraints are not deleted.

Example:

[IGNORE ASSIGNMENTS]

Pin_Assignments = NO;

Pin_Keep_Block = NO;

Pin_Keep_Segment = NO;

Group_Assignments = NO;

Macrocell_Assignment = NO;

Macrocell_Keep_Block = NO;

Macrocell_Keep_Segment = NO;

Pin_Reservation = NO;

Layer

Description: Keep ‘ON’ for this section.

Mandatory: No (Defaults to ON)

Options: ON

Example: Layer = ON;

Required for: Communicating with parent vci file.

Pin_Assignments

Description: Ignore pin assignments.

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Pin_Assignments = No;

Pin_Keep_Block

Description: If pin assignments is yes, keep signals in the same block

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Pin_Keep_Block = No;

Required for: Fitter

Pin_Keep_Segment

Description: If pin assignments = yes, keep signals in same segment (M5 Only)

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Pin_Keep_Segment = No;

Group_Assignments

Description: Ignore Group Assignments

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Group_Assignments = Yes;

Required for:

Macrocell_Assignment

Description: Ignore Macrocell Assignments

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Macrocell_Assignments = Yes;

Required for:

Macrocell_Keep_Block

Description: Keep block constraints.  Ignore everything else

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Macrocell_Keep_Block = Yes;

Required for:

Macrocell_Keep_Segment

Description: Keep segment constraints.

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Macrocell_Keep_Segment = Yes;

Required for:


[CLEAR ASSIGNMENTS]

This section defines the constraints, which are deleted for the fit.

Example:

[CLEAR ASSIGNMENTS]

Pin_Assignments = NO;

Pin_Keep_Block = NO;

Pin_Keep_Segment = NO;

Group_Assignments = NO;

Macrocell_Assignment = NO;

Macrocell_Keep_Block = NO;

Macrocell_Keep_Segment = NO;

Pin_Assignments

Description: Deletes the Pin assignments

Mandatory: No (Defaults to No)

Options: YES | NO

Example: Pin_Assignment = NO;

Pin_Keep_Block

Description: Deletes the Pin assignments but keeps the Block assignments

Mandatory: No (Defaults to No)

Options: YES | NO

Example: Pin_Keep_Block = NO;

Pin_Keep_Segment

Description: Deletes the pin assignments but keeps the segment assignments (M5 Only)

Mandatory: No (Defaults to No)

Options: YES | NO

Example: Pin_Keep_Segment = NO;


[BACKANNOTATE NETLIST]

This section defines the options for netlist generation for simulation purposes

Example:

[BACKANNOTATE NETLIST]

Netlist = VHDL;

Delay_File = SDF;

VCC_Ground = Cell;

Netlist

Description: Type of Netlist, VHDL, Verilog or EDIF

Mandatory: No

Options: VERILOG | VHDL | EDIF

Example: Netlist = VHDL

Delay_File

Description: Describes the delay file type

Mandatory: No

Options: DTB | SDF

Example: Delay_File = SDF;

VCC_Ground

Description: Describes VCC and Ground as either a net or Primitive Cell

Mandatory: No

Options: NET | CELL

Example: VCC_Ground = Cell;


[BACKANNOTATE ASSIGNMENTS]

This section defines whether pin placement, macrocell placement or Block placement is backannotated to the original vci file.

Example:

[BACKANNOTATE ASSIGNMENTS]

Pin_Assignment = NO;

Pin_Block = NO;

Pin_Macrocell_Block = NO;

Pin_Assignment

Description: Only Backannotate the pin assignments

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Pin_Assignment = Yes;

Required for:

Pin_Block

Description: Backannotate the pin and block assignments

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Pin_Block = Yes;

Required for:

Pin_Macrocell_Block

Description: Back annotate the pin, macrocell and block assignments

Mandatory: No (Defaults to No)

Options: Yes | No

Example: Pin_Macrocell_Block = Yes;

Required for:


[LOCATION ASSIGNMENT]

Example:

[LOCATION ASSIGNMENT]

layer = OFF;

input_1 = INPUT,3,A,-;

input_2 = INPUT,2,A,-;

Clk = INPUT,11,-,-;

output_q = OUTPUT,9,A,-;

layer

Description: Always ‘OFF’ for this section

Format: -

Pin Name = <DIRECTION>, <PIN NUMBER>, <PAL BLOCK>, <SEGMENT>;

A ‘-‘ or ‘*’ can appear in any of the above.  ‘-‘ means not applicable.  ‘*’ means any.


[GLOBAL PROJECT OPTIMIZATION]

Example:

[GLOBAL PROJECT OPTIMIZATION]

Balanced_Partitioning = YES;

Spread_Placement = YES;

Max_Macrocell_Percent = 100;

Max_Inter_Seg_Percent = 100;

Max_Seg_In_Percent = 100;

Max_Blk_In_Percent = 100;

Balanced_Partitioning

Description: Balances logic throughout the device

Mandatory: No

Options: Yes | No

Example: Balanced_Partitioning = Yes

Required for: Fitter

Spread_Placement

Description: Spreads logic throughout each block

Mandatory: No

Options: Yes | No

Example: Spread_Placement = Yes

Required for: Fitter

Max_Macrocell_Percent

Description: Maximum % of Macrocells per block used

Mandatory: No (Defaults to 100)

Options: Integer 0 to 100

Example: Max_Macrocell_Percent = 80;

Required for: Fitter

Max_Inter_Seg_Percent

Description: Declares the Maximum percent of intersegment lines for M5

Mandatory: No

Options: 0 - 100

Example: Max_Inter_Seg_Percent = 90;

Max_Seg_In_Percent

Description: Declares the Maximum percent of Segment inputs for M5

Mandatory: No

Options: 0 - 100

Example: Max_Seg_In_Percent = 90;

Max_Blk_In_Percent

Description: Maximum % of PAL block inputs used

Mandatory: No (Defaults to 100)

Options: Integer 0 to 100

Example: Max_Blk_In_Percent = 80;

Required for: Fitter


[OPTIMIZATION OPTIONS]

Defines the global optimization for all equations.

Example

[OPTIMIZATION OPTIONS]

Logic_Reduction = YES;

Max_PTerm_Split = 16;

Max_PTerm_Collapse = 16;

XOR_Synthesis = YES;

Node_Collapse = Yes;

DT_Synthesis = Yes;

Max_Symbols = 30;

Logic_Reduction

Description: Turns on Boolean Logic Reduction

Mandatory: No (defaults to Yes)

Options: Yes | No

Example: Logic_Reduction = Yes;

Required for: Optimiser

Max_PTerm_Split

Description: Sets the Maximum Product Term limit.  If equation has more Product Terms than limit, then a node is created and feedback to the original equation.

Mandatory: No (Default is dependent upon device)

Options: Integer

Example: Max_PTerm_Split = 16;

Required for: Optimiser

Max_PTerm_Collapse

Description: Sets the Maximum Product term collapsing limit

Mandatory: No (Default is dependent upon device)

Options: Integer

Example: Max_PTerm_Collapse = 16

Required for: Optimiser

DT_Synthesis

Description: Turns on D type | T type flip flop Synthesis.  If ‘NO’ then use user specified FF type.

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: DT_Synthesis = Yes

Required for: Optimiser

Speed

Description: Node Collapsing for Speed or Area

Mandatory: No (

Options: Yes (for Speed) | No (for Area)

Example: Speed = Yes

Required for: Optimiser

Max_Symbols

Description:

Mandatory:

Options:

Example:

Required for:

XOR_Synthesis

Description: Turns on XOR Synthesis M4 and M5 only

Mandatory: No (Defaults to ‘Yes’)

Options: Yes | No

Example: XOR_Synthesis = Yes;

Node_Collapse

Description: Turns on Node collapsing

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Node_Collapse = Yes;


[FITTER GLOBAL OPTIONS]

Settings for the Place & Route tool

Example:

[FITTER GLOBAL OPTIONS]

Set_Reset_Dont_Care = NO;

Routing Attempts = 2;

Set_Reset_Dont_Care

Description: Turns on set reset don’t care.  Allows Registered equations without any set or reset logic controls to be partitioned into a block with registered equations that have set and/or reset logic.

Mandatory: No (defaults to Yes)

Options: Yes | No

Example: Set_Reset_Dont_Care = Yes

Required for: Fitter

Routing_Attempts

Description: Specifies the number of routing iterations per placement (M4 Only).  We do not recommend changing this value.

Mandatory: No (defaults to 2)

Options: Integer (0 – 255)

Example: Routing_Attempts = 10;

Required for: Fitter

Global_Clock_As_Pterm

Description: Allows both global clock and asynchronous clock to be used in a macrocell, hence a global clock with an asynchronous macrocell.

Mandatory: No (defaults to ‘NO’).  We do not recommend changing this switch.

Options: YES | NO

Example: Global_Clock_As_Pterm = NO;

Required for: Fitter


[FITTER_REPORT_FORMAT]

Description: Select the information supplied in the fitter report

Example:

[FITTER_REPORT_FORMAT]

Set_Reset_Summary = YES;

Fitter_Options = YES;

Pinout_Diagram = NO;

Pinout_Listing = YES;

Detailed_Block_Segment_Summary = YES;

Input_Signal_List = YES;

Output_Signal_List = YES;

Bidir_Signal_List = YES;

Node_Signal_List = YES;

Signal_Fanout_List = YES;

Block_Segment_Fanin_List = YES;

Prefit_Eqn = YES;

Postfit_Eqn = YES;

Page_Break = YES;

Set_Reset_Summary

Description: Displays the Set / Reset section in the Fitter report

Mandatory: No (defaults to ‘YES’)

Options: YES | NO

Example: Set_Reset_Summary = YES;

Fitter_Options

Description: Displays the switch options selected for the fit.

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Fitter_Options = YES;

Pinout_Diagram

Description: Displays a graphical display of the pin-out for the design

Mandatory: No ( Defaults to No)

Options: Yes | No

Example: Pinout_Diagram = Yes;

Pinout_Listing

Description: Displays the pin-out in list form

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Pinout_Listing = Yes;

Detailed_Block_Segment_Summary

Description:

Mandatory:

Options:

Example:

Input_Signal_List

Description: Lists the input signals

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Input_Signal_List = Yes;

Output_Signal_List

Description: Lists the output signals

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Output_Signal_List = Yes;

Bidir_Signal_List

Description: Lists all bi-directional signals

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Bidir_Signal_List = Yes;

Node_Signal_List

Description: Lists all internal nodes

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Node_Signal_List = Yes

Signal_Fanout_List

Description: Lists the fanouts from all nodes

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Signal_Fanout_List = Yes;

Block_Segment_Fanin_List

Description: Lists the location of the fan-in signals

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Block_Segment_Fanin_List = Yes;

Prefit_Eqn

Description: Displays the pre-optimised equations

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Prefit_Eqn = Yes;

Postfit_Eqn

Description: Displays the post-optimised equations

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Postfit_Eqn = Yes;

Page_Break

Description: Inserts a Page Break for printing

Mandatory: No (Defaults to Yes)

Options: Yes | No

Example: Page_Break = Yes;


[SOURCE CONSTRAINT OPTION]

Allows source constraints to be imported and honoured

Example

[SOURCE CONSTRAINT OPTION]

Import_Source_Constraint = YES;

Import_Source_Constraint

Description: Allows source constraints to be imported and honoured.

Mandatory: No (defaults to No)

Options: Yes | No

Example: Import_Source_Constraint = YES;


[HARDWARE DEVICE OPTIONS]

Specifies the Electrical properties of the device.

Example

[HARDWARE DEVICE OPTIONS]

Out_Slew_Rate = Fast,Slow,1,output_q;

Zero_Hold_Time = YES;

Signature_Word = des1;

Pull_up = NO;

Out_Slew_Rate

Description: Sets the default and individual slew rates for the device

Mandatory: No (defaults to Fast)

Options: Yes | No

Format: Out_Slew_Rate = <Default>, <None Default>,<Number of None Default>, <Signal list of none default>

Example: Out_Slew_Rate = Slow,Fast,3,output1,output2,output3

Zero_Hold_Time

Description: Sets the Zero Hold Time fuse for input registers in M4

Mandatory: No

Options: YES | NO

Example: Zero_Hold_Time = YES;

Signature_Word

Description: Sets the Signature Word in M4 Devices (i.e. usercode)

Mandatory: No

Options: 4 ASCII Characters or 32 Bit Binary

Example: Signature_Word = DSN1;

Pull_up

Description: Selects Global pull-ups or bus-friendly option for I/O pins on M4A devices

Mandatory: No

Options: YES | NO

Example: Pull_up = YES


[POWER]

Specifies the power configuration for the macrocell or block in the device.

Example

[POWER]

Default = High;

Low = 0;

High = 1,A

Format: <Power level> = <# of blocks at this power level>,<Block Names>

Default

Description: Sets the default power for the device

Mandatory: No (Defaults to HIGH)

Options: HIGH | LOW

Example: default = LOW;

Low

Description: Sets Power level low in defined blocks

Mandatory: No (Defaults to HIGH)

Options: <Power level>=<# of blocks at this power level>,<Block Names>

Example: Low = 2,C,D;

High

Description: Sets Power level High in defined blocks

Mandatory: No (Defaults to HIGH)

Options: <Power level>=<# of blocks at this power level>,<Block Names>

Example: High = 3,A,B,E;


[PIN RESERVATION]

Reserve pins for future design additions, reserving a pin as an output will reserve at least 1 Product Term for the pin

Example:

[PIN RESERVATIONS]

layer = OFF;

IO = 2, Input, -;

IO = 14, Input, -;

Layer

Description: Turn Layer ‘OFF’ for this section

Format: <Pin type> = <Pin #>, <Direction>, -;

Example: IO = 9, Output, -;

A ‘-‘ or ‘*’ can appear in any of the above.  ‘-‘ means not applicable.  ‘*’ means any.


[GROUP ASSIGNMENT]

Create groups of signals that will be placed as a group into Blocks

Example:

[GROUP ASSIGNMENT]

layer = OFF;

test_group = A, -, 3, input_1, input_2, output_q;

Layer

Description: Turn Layer ‘OFF’ for this section

Format: <group name> = <Block letter>, <segment number>, <# of signals>, <signal listing>;

Example: test_group = C,2, 4, sig1, sig2, sig3, sig4;

A ‘-‘ or ‘*’ can appear in any of the above.  ‘-‘ means not applicable.  ‘*’ means any.


Importing Constraints from Design Sources

By default, the Import constraints from design source option is disabled. This means that the software will ignore constraints from source files; all existing constraints in the project constraint file are left untouched. However, when you enable this option the constraints from the source files are written into the project constraint file.


Assigning Pins and Nodes

Pre-assigning pins and/or nodes allow designs to be fit with resources assigned to the same physical locations. This ability becomes important when the pin-out of a design has been established either before the design was created or as the design goes through iterations.

Assigning pins and nodes may also help the fitter to properly place signals to allow faster signal propagation since signals that rely on other signals can be placed in close proximity. In addition, assignment can sometimes help the fitter to decide which resources can be placed onto nodes that allow efficient product steering for signals that require additional product terms.

However, pins and nodes that are preassigned may also restrict the fitter from efficiently placing pins and nodes. Assigning pins and/or nodes to macrocells prohibits the fitter from using algorithms to optimize the placement of the design signals.

When possible, you should let the fitter make initial assignments to pins and nodes. After it has finished, you can then take the design and make the appropriate modifications or lock down the assignments the fitter has produced by adding these results to your source files.

Another general tip would be to allow the fitter to use iterations when assigning most of the nodes, unless there is a specific constraint that forces manual assignments to nodes to be made.

The following examples illustrate how to assign pins using each of the design entry methods (Schematic, ABEL-HDL and VHDL)


Assigning Signals to Groups

A programmable central switch matrix makes up each of the MACH devices of multiple PAL blocks that are interconnected. Often times it is advantageous to group signals that have a logic association into the same PLA block. In that case, “grouping” the signals together to a specific block without assigning the signals to a specific macrocell is possible. "Grouping" allows the fitter to maintain control of where the signals get placed inside the block, but assures that the signals are efficiently located. This method of assigning groups is recommended over assigning the signals to specific macrocells.

The following examples illustrate how assignments to groups can be made in each of the source types. (Schematic, ABEL-HDL and VHDL)


Preserving Nodes

Through the processing of a MACH design, the pre-fitters will perform optimization on each of the sources, as well as the linked design, to try to minimize the logic needed. Many times, logic has been manually partitioned in order to achieve certain results such as speed and/or area requirements. There are a few methods that ensure that nodes are not removed or collapsed into others when the optimizers are run.

If you set the Node Collapse Mode on the source-level reduction process and design-level fit process to Explicit or None, the optimizers will not remove any nodes unless you specifically assign the appropriate properties to collapse the nodes. This selection has drawbacks because no node collapsing will be performed on the design to remove unneeded nodes. Therefore, the design may require more logic to be implemented. This is particularly a problem for hierarchical designs, because buffers are inserted between the interfaces of the modules. If these buffers are not removed, the design will have unwanted logic that will introduce delays and lower efficiency.

A better approach is to explicitly specify which nodes are not to be removed or collapsed during optimization. This specification requires the source file to contain specific attributes on all of the signals that are to be preserved, but it ensures that no reduction will be performed to remove the nodes.

The following examples illustrate how to specify that a node is not to be collapsed during processing.


Pin Reservations

How Do I Reserve Pins?

You can reserve pins for future use. This feature ensures that the optimizers do not use the pin assignment while checking for unused ports, and that the Fitter does not use it when fitting the rest of the resources.

You can verify in the Fitter Report file that the assignments have been made to the correct pin type (either an I/O pin or a dedicated input/clock pin).

Syntax

MACH_RESERVE (Type,Pin#,OutputState);

Type: Type can be: Input, Output, or Bidir.

Pin#: The number of the pin that you want to reserve.

OutputState: This can be out_z, out_low, or out_high.

Example

MODULE inreg

…

LIBRARY ‘mach’;

…

MACH_RESERVE (Output,8,out_low);

…

D1,D2	pin;

N1,N2	node;

…

END


Slew Rate

You can assign Slew Rate for MACH4 and MACH5 products.

Syntax

MACH_SLEW (Type,#ofSignals,SignalList);

Type: Type can be either: SLOW (default for all unlisted signals is FAST), FAST (default for all unlisted signals is SLOW).

#ofSignals: The number of signals you want to list.

SignalList: List of signals, separated by colons.

Example

MODULE inreg

…

LIBRARY ‘mach’;

…

MACH_SLEW (SLOW,2,D1:D2);

…

D1,D2	pin;

N1,N2	node;

…

END


Adding Constraints to Source Files

By default, ispDesignEXPERT ignores constraints from source files; all existing constraints in the project constraint file are left untouched. However, you can tell ispDesignEXPERT to write constraints from source files into the project constraints.


Enabling the Import Source Constraints Options

1.	In the Project Manager, choose Tools > Import Source Constraints Option to open the dialog.

The Import Source Constraint Option dialog lets you import constraints, such as Location (pin/node) Assignments, Group Assignments, and Output Slew Rate, from source files (ABEL-HDL, schematic, or EDIF).

2.	Select Import constraints from design sources.

3.	Click OK.

Existing project constraints (only Location Assignments, Group Assignments, and Output Slew Rate are affected) are cleared, even if there are no constraints in the source file. If there are constraints in the source file, then the new constraints are written into the project constraint file.

Note: If you import constraints and then decide to change them using the Constraint Editor, remember to go back and turn this option off. Otherwise, any changes you make will be overwritten with the constraints in the source files.


ABEL-HDL Pin/Node Assignments

This example shows how to assign pins using the pin declarations and the MACH_LOCATION macro.

Syntax

MACH_LOCATION(signalname,type,pin/MC#,block#,segment#);

Signal name: Name of the signal that you want to position.

Type: Type of signal you want to set. Valid types are: Input, Output, and Node.

Pin/Macrocell/Block/Segment#: These describe the location of where you want to position the signal.

(star) *: Means Any.

(dash) -: Means not applicable. For example, segment number is not used for MACH 1-4 devices.

Example

MODULE passign

…

LIBRARY ‘mach’;

…

MACH_LOCATION(D,Input,6,-,-);	// assigned using macro

MACH_LOCATION(N1,Node,0,A,-);	// assigned using macro

A,B,C	pin 3,4,5;	// assigned in declarations

D,E,F	pin;

N1	node istype ‘com’;

…

END


VHDL Pin Assignments

This example shows how to assign pins using the VHDL attribute PINNUM for std_logic and std_logic_vector types.

entity PASSIGN

port	(A,B,C	: in  std_logic;

 D	: in  std_logic_vector(3 downto 0);

 Q	: out std_logic);

attribute LOC: string;

attribute LOC of A: signal is “P3”;

end PASSIGN;


Verilog Pin Assignments

This example shows how to assign signals using the Verilog attribute LOC.  Because Verilog does not have a specific keyword for attribute, attributes are located in comment lines.  (Note:  For a bus attribute, no space is needed between pin numbers)

module pin_assign (A,B,C,DataIn,Z,DataOut);

input A,B,C;

input [3:0] DataIn;

output Z;

output [3:0] DataOut;

// exemplar attribute Z loc P3

// exemplar attribute DataOut loc P24P25P26P27

assign Z = (A & B) | C;

assign DataOut = DataIn;

endmodule


Schematic Pin Assignments

To assign pins in a schematic, you must use the generic symbols in the IOPADS library.


Making Pin Assignments in Schematics

1.	In the Schematic Editor, choose Edit > Attribute > Symbol Attribute to open the Symbol Attribute Editor.

2.	Select the I/O Pad that is connected to the I/O signal you want to assign. The Symbol Attribute Editor should now contain information about the selected symbol.

3.	In the Symbol Attribute Editor, click in the DevicePin attribute and enter the desired pin location into the DevicePin field.

4.	Close the dialog. This attribute displays in an attribute window of the selected symbol, giving a clear indication that an assignment was made.


ABEL-HDL Group Assignments

The following example fragment illustrates how group assignments can be made in ABEL-HDL using either property statements or pre-defined macros. This specific example will place pins D1 and D2 into PAL block A along with nodes N1 and N2.

Syntax

MACH_GROUP (GroupName,Block,Segment,#ofSignals,SignalList);

GroupName: Name of the group.

Block/Segment: Location of where you want to place the group.

#ofSignals: The number of signals in the group.

SignalList: List of signals, separated by colons.

Example

MODULE inreg

…

LIBRARY ‘mach’;

…

MACH_GROUP (GrpA,A,-,4,D1:D2:N1:N2);

…

D1,D2	pin;

N1,N2	node;

…

END


VHDL Group Assignments

The following examples illustrate how you can make group assignments in VHDL using either property statements or pre-defined macros. The first example places pins D1 and D2 into block A by placing the constraint in the entity section of the code. The second example places pins D1 and D2 into the same group, along with nodes N1 and N2 (defined in architecture).

Example (in the entity)

entity IREG

port	(D1,D2	: in  std_logic;

 Q	: out std_logic);

attribute GROUPING: string;

attribute of IREG: entity is

“mygroup =  A, -, 2, D1,D2”;

end IREG;

Note: For multiple group assignments, you must combine the assignments with a semicolon, as shown below.

"mygroup1=A, 1, 4, A, B, C, D; mygroup2=B, 1, 2, X, Y"

Example (in the architecture)

architecture struc of IREG is

signal N1, N2: std_logic;

attribute GROUPING: string;

attribute LOC: string;

attribute GROUPING of D1: signal is”GRP1”;

attribute LOC of D1: signal is ”A,*”;

attribute GROUPING of D2: signal is”GRP1”;

attribute LOC of D2: signal is”A,*”;

attribute GROUPING of N1: signal is”GRP1”;

attribute LOC of N1: signal is ”A,*”;

attribute GROUPING of N2: signal is”GRP1”;

attribute LOC of N2: signal is”A,*”;

end struc;


Verilog Group Assignments

Syntax

<group_name>=<pal_block>,<segment>,<# of signals in group>,<listing of group signals>;

‘-‘ indicates ‘not applicable’

‘*’ indicates ‘any’

Example

module group_assign (A,B,C,Z);

input A,B,C;

output Z;

//exemplar attribute attr_v grouping group1=*,-,3,A,B,C

assign Z = (A & B) | C;

endmodule


Assigning Pins to Groups

Pins that are assigned to a group will be placed into one of the I/O cells associated with the specified PAL block.


Assigning Nodes to Groups

Nodes that are assigned to a group will be placed into one of the macrocells contained in the specified PAL block.


ABEL-HDL Node Preservation

ABEL-HDL Node Preservation

The following example places an ABEL-HDL istype ‘keep’ onto node N in order to ensure it is not collapsed away during processing.

MODULE keeper

A,B,C	pin;

Y	pin;

N	node istype ‘keep’;

EQUATIONS

Y	= N;

N	= A & B & C;

END

If the istype ‘keep’ was not specified, node N would be collapsed away, resulting in the Y equation being Y = A & B & C;


Verilog Node Preservation

Using node preservation in Verilog is the same as VHDL in the respect that two declarations must be made.  The example shown below will preserve the signal ‘N’ and prevent the node from being collapsed.

module node_keep (A,B,C,Y);

input A,B,C;

output Y;

wire N;

//exemplar attribute N preserve_signal true

//exemplar attribute N opt keep

assign Y = N;

assign N = A & B & C;

endmodule


Schematic Node Preservation

The following example places a Schematic attribute ‘Keep’ onto node N in order to ensure it is not collapsed away during processing.

If the net attribute ‘keep’ is not set, the extra buffer will be collapsed away.

Note: Specifying that a signal is to be preserved does not ensure that it will not be merged with other signals that can be collapsed into it. It simply ensures that it will retain the same name and functionality.

For example:

N	= A & B & C;

K	= N & D;

P	= K & E;

If signal K has been assigned a keep attribute, the reduction of these equations may result in the following equation (depending on the rest of the circuit)

K	= A & B & C & D;

P	= K & E;

Notice that node N has been merged into K, but K has not been merged into P, even though the resulting equation would have been more efficient in terms of nodes needed and levels of delay.

Also note that if a node is declared and assigned an attribute keep but is not used in the design, it will be removed. Placing the attribute keep on a node does not reserve a resource. For information on preserving nodes, refer to the Reserving Macrocells section.


VHDL Slew Assignments

The following example fragment illustrates how Slew assignments can be made in VHDL using attribute statements. This specific example places pin Q into SLOW slew rate.

Example

architecture struc of IREG

attribute SLEW: string;

attribute SLOW of Q: signal is”SLOW”;

end struc;


Verilog Slew Assignments

In the following Verilog example code, the output pin ‘Y’ is assigned a slow slew rate.

Example

module slew (A,B,C,Y);

input A,B,C;

output Y;

assign Y = A & B & C;

//exemplar attribute Y slew slow

endmodule


CAE Design Guides

For the most recent information about interfacing ispDesignEXPERT with various CAE vendors, visit the Lattice web site.


Running from the Command Line

You can run ispDesignEXPERT from the command line using a C-shell script. This feature works only on MACH devices.

Using the C-shell Script

To run ispDesignEXPERT from the command line, use the C-shell script provided with the product. When you run this command, ispDesignEXPERT will attempt to fit the design to the specified part.

Command Format

The format of the command is as follows:

ISPflow <design name> [-d <device partnumber>]

where [ ] denotes optional parameters. For example, ISPflow <alarmclk> -d

For the script to run, you must set the ispDesignEXPERT environment variable to point to the directory with the ispDesignEXPERT executables.

Specifying Options and Pin Assignments

To specify optimization options and pin assignments, you must create or modify a <design name> VCI file. See Lattice Constraint File Description for more information on the VCI file format. If there is no VCI file, ispDesignEXPERT creates a default file for the specified device. In this case, the –d option is required.

Note: The VCI file as case sensitive. Once a VCI file is created, the –d option can be omitted from the command line because the device information will be obtained from the VCI file. The –d option takes precedence over the VCI file. If the –d option is used again with a different device part number, the device information part of the VCI file will be updated to reflect the changes.

Note: Pin assignments and certain optimization options in the VCI file could be incorrect if the device is changed on the Command Line.

The ispDesignEXPERT script runs through the complete flow, including timing analysis.

Input Formats

Acceptable input formats are non-hierarchical ABEL or EDIF source files. The source files must be named with the .abl or .edf extensions respectively. If you omit the extension, ispDesignEXPERT assumes to be .edf.

Log Files

The script keeps a log of its execution in the automake.log file.


Running in Batch Mode

You can run ispDesignEXPERT in batch mode by executing the command ISPflow. The usage of this command follows.

ISPflow [-i <design>] [-d <device>]

[-r <none\pin\pinblk\pinblkmcr>] [-imp <yes\no>]

[-sdf <vhdl\verilog\edif>] [-h] [-v]

where:

-i <design>	The name of the Input Source file. Only EDIF and ABEL files are supported.

-d <device>	Specifies the Device Part Number the design will be fitted to. This potion is required if the <design name>.vci  file does not exist. The part name must be exact and all upper case.

-r <none>	Refit with no backannotation

     <pin>	Refit with pins only backannotation

     <pinblk>	Refit with pins and blocks only backannotation

     <pinblkmcr>	Refit with pins, blocks, and macrocells backannotation

-imp <yes\no>	Import source constraints

-sdf <vhdl>	Generate Backannotated netlist type

         <verilog>

         <edif>

-h	Displays the Help message

-v	Displays the version message

The input source file switch ( -i )  is mandatory. All other switches are not. ISPflow will not error-out if an input file is not selected.

If refit ( -r ) is selected, you can specify the device either through the command line, or using the vci or .vco files. If a device name is ( -d ) specified from the command line, and a .vci or .vco file exists, the device specified from the command line takes precedence. ISPflow will error-out if a device name is not specified from either the command line or in a .vci file.


VCI Files

The VCI file contains the constraints for Part selection as well as the Optimization and Placing and Routing processes. For more information on the VCI file constraints, see Lattice Constraint File Description.

You do not need to generate a VCI file on the first fit. If you specify a device ( -d ) with ISPflow, this will generate a .vci file.


Batch Mode Example

To fit a new design:

1.	Create a new directory and copy the input files needed.

<isptools>/ispsys/examples/abel/and_ff2/and_ff2.abl

<isptools>/ispsys/examples/abel/and_ff2/and_ff2.vci

2.	Run ISPflow -i and_ff2.abl.

The executable will get the device from the .vci file and fit the design. The .vci file can be varied to an optimizer setting that you prefer. See the Lattice Constraints File Description for additional information.

3.	Run ISPflow -i and_ff2.abl -d M4A3-128/64-7VI.

The software fits the design into the specified MACH device.

To refit the design:

1.	Run ISPflow -i and_ff2.abl -r pin.

The executable will get the device from the .vco (Output Constraints file) file and refit the design. The .vct file will have only I/O pin location assignments backannotated into it.

2.	Run ISPflow -i and_ff2.abl -r pinblk.

The executable will get the device from the .vco file and attempt to refit the design. The .vct file will have only I/O pin location assignments backannotated into it.

3.	Run ISPflow -i and_ff2.abl -r pinblkmcr.

The executable will get the device from the .vco file and attempt to refit the design. The .vct file will have only I/O pin location assignments backannotated into it.

4.	Run ISPflow -i and_ff2.abl -r pinblkmcr -d M4A3-128/64-14VI.

The executable will refit the design into the M4A3-128/64-14VI device. Even though this will fit correctly, it is dangerous to attempt to place location assignments on a different device. However, it will prove useful to compare timing results with the sane part using different speed grades.


ispDesignEXPERT 8.1 ispLSI Device List

This section is a listing of all ispLSI devices supported by ispDesignEXPERT. The devices in this list are sorted alphabetically by template name (page heading). The columns in the list consist of Lattice's abbreviation, followed by the device's part number, and the footprint name.

Important: Devices with the note "Migration to…" in the right margin are not recommended for new designs. Instead, use the recommended device included in the note.


ispLSI 1000 Device Family Part Numbers

ispLSI1048EA-170LT128

ispLSI1048EA-125LT128

ispLSI1048EA-100LT128

ispLSI1048EA-170LQ128

ispLSI1048EA-125LQ128

ispLSI1048EA-100LQ128

ispLSI1048E-125LQ128

ispLSI1048E-100LQ128

ispLSI1048E-70LQ128

ispLSI1048E-70LQ128I

ispLSI1048E-125LT128

ispLSI1048E-100LT128

ispLSI1048E-70LT128

ispLSI1048C-50LG133/883

ispLSI1032EA-200LT100

ispLSI1032EA-125LT100

ispLSI1032EA-100LT100

ispLSI1032E-125LT100

ispLSI1032E-100LT100

ispLSI1032E-70LT100

ispLSI1032E-70LT100I

ispLSI1032E-125LJ84

ispLSI1032E-100LJ84

ispLSI1032E-70LJ84

ispLSI1032E-70LJ84I

ispLSI1032-60LG84/883

ispLSI1024-90LT100

ispLSI1024-80LT100

ispLSI1024-60LT100

ispLSI1024-60LT100I

ispLSI1024-90LJ68

ispLSI1024-80LJ68

ispLSI1024-60LJ68

ispLSI1024-60LJ68I

ispLSI1024-60LH68/883

ispLSI1016E-125LT44

ispLSI1016E-100LT44

ispLSI1016E-80LT44

ispLSI1016E-80LT44I

ispLSI1016E-125LJ44

ispLSI1016E-100LJ44

ispLSI1016E-80LJ44

ispLSI1016E-80LJ44I

ispLSI1016-90LT44	Migration to ispLSI1016E-100LT44

ispLSI1016-80LT44	Migration to ispLSI1016E-80LT44

ispLSI1016-60LT44	Migration to ispLSI1016E-80LT44

ispLSI1016-60LT44I	Migration to ispLSI1016E-80LT44I

ispLSI1016-90LJ44	Migration to ispLSI1016E-100LJ44

ispLSI1016-80LJ44	Migration to ispLSI1016E-80LJ44

ispLSI1016-60LJ44	Migration to ispLSI1016E-80LJ44

ispLSI1016-60LJ44I	Migration to ispLSI1016E-80LJ44I

ispLSI1016-60LH44/883


ispLSI 2000 Device Family Part Numbers

ispLSI2128E-180LT176

ispLSI2128E-135LT176

ispLSI2128E-100LT176

ispLSI2128-100LT176	Migration to ispLSI2128E-100LT176

ispLSI2128-80LT176	Migration to ispLSI2128E-100LT176

ispLSI2128-80LT176I	Migration to ispLSI2128A-80LT176I

ispLSI2128-100LQ160	Migration to ispLSI2128E-100LT176

ispLSI2128-80LQ160	Migration to ispLSI2128E-100LT176

ispLSI2096E-180LT128

ispLSI2096E-135LT128

ispLSI2096E-100LT128

ispLSI2096E-180LQ128

ispLSI2096E-135LQ128

ispLSI2096E-100LQ128

ispLSI2096-125LT128	Migration to ispLSI2096E-135LT128

ispLSI2096-100LT128	Migration to ispLSI2096E-100LT128

ispLSI2096-80LT128	Migration to ispLSI2096E-100LT128

ispLSI2096-80LT128I	Migration to ispLSI2096A-80LT128I

ispLSI2096-125LQ128	Migration to ispLSI2096E-135LQ128

ispLSI2096-100LQ128	Migration to ispLSI2096E-100LQ128

ispLSI2096-80LQ128	Migration to ispLSI2096E-100LQ128

ispLSI2096-80LQ128I	Migration to ispLSI2096A-80LQ128I

ispLSI2064E-200LT100

ispLSI2064E-135LT100

ispLSI2064E-100LT100

ispLSI2064-125LT100	Migration to ispLSI2064E-200LT100

ispLSI2064-100LT100	Migration to ispLSI2064E-135LT100

ispLSI2064-80LT100	Migration to ispLSI2064E-100LT100

ispLSI2064-80LT100I	Migration to ispLSI2064A-80LT100I

ispLSI2064-125LJ84	Migration to ispLSI2064E-135LT100

ispLSI2064-100LJ84	Migration to ispLSI2064E-100LT100

ispLSI2064-80LJ84	Migration to ispLSI2064E-100LT100

ispLSI2064-80LJ84I	Migration to ispLSI2064A-80LT100I

ispLSI2032E-225LT48

ispLSI2032E-180LT48

ispLSI2032E-135LT48

ispLSI2032E-110LT48

ispLSI2032E-225LT44

ispLSI2032E-180LT44

ispLSI2032E-135LT44

ispLSI2032E-110LT44

ispLSI2032E-225LJ44

ispLSI2032E-180LJ44

ispLSI2032E-135LJ44

ispLSI2032E-110LJ44

ispLSI2032-180LT48	Migration to ispLSI2032E-180LT48

ispLSI2032-150LT48	Migration to ispLSI2032E-180LT48

ispLSI2032-135LT48	Migration to ispLSI2032E-135LT48

ispLSI2032-110LT48	Migration to ispLSI2032E-110LT48

ispLSI2032-80LT48	Migration to ispLSI2032E-110LT48

ispLSI2032-80LT48I	Migration to ispLSI2032A-80LT48I

ispLSI2032-180LT44	Migration to ispLSI2032E-180LT44

ispLSI2032-150LT44	Migration to ispLSI2032E-180LT44

ispLSI2032-135LT44	Migration to ispLSI2032E-135LT44

ispLSI2032-110LT44	Migration to ispLSI2032E-110LT44

ispLSI2032-80LT44	Migration to ispLSI2032E-110LT44

ispLSI2032-80LT44I	Migration to ispLSI2032A-80LT44I

ispLSI2032-180LJ44	Migration to ispLSI2032E-180LJ44

ispLSI2032-150LJ44	Migration to ispLSI2032E-180LJ44

ispLSI2032-135LJ44	Migration to ispLSI2032E-135LJ44

ispLSI2032-110LJ44	Migration to ispLSI2032E-110LJ44

ispLSI2032-80LJ44	Migration to ispLSI2032E-110LJ44

ispLSI2032-80LJ44I	Migration to ispLSI2032A-80LJ44I

ispLSI2128A-100LT176 	Migration to ispLSI2128E-100LT176

ispLSI2128A-80LT176 	Migration to ispLSI2128E-100LT176

ispLSI2128A-80LT176I

ispLSI2128A-100LQ160 	Migration to ispLSI2128E-100LT176

ispLSI2128A-80LQ160 	Migration to ispLSI2128E-100LT176

ispLSI2096A-125LT128  	Migration to ispLSI2096E-135LT128

ispLSI2096A-100LT128  	Migration to ispLSI2096E-100LT128

ispLSI2096A-80LT128  	Migration to ispLSI2096E-100LT128

ispLSI2096A-80LT128I

ispLSI2096A-125LQ128  	Migration to ispLSI2096E-135LQ128

ispLSI2096A-100LQ128  	Migration to ispLSI2096E-100LQ128

ispLSI2096A-80LQ128 	Migration to ispLSI2096E-100LQ128

ispLSI2096A-80LQ128I

ispLSI2064A-125LT100 	Migration to ispLSI2064E-200LT100

ispLSI2064A-100LT100 	Migration to ispLSI2064E-135LT100

ispLSI2064A-80LT100 	Migration to ispLSI2064E-100LT100

ispLSI2064A-80LT100I

ispLSI2064A-125LJ84 	Migration to ispLSI2064E-135LT100

ispLSI2064A-100LJ84 	Migration to ispLSI2064E-100LT100

ispLSI2064A-80LJ84 	Migration to ispLSI2064E-100LT100

ispLSI2064A-80LJ84I

ispLSI2032A-180LT48  	Migration to ispLSI2032E-180LT48

ispLSI2032A-150LT48  	Migration to ispLSI2032E-180LT48

ispLSI2032A-135LT48  	Migration to ispLSI2032E-135LT48

ispLSI2032A-110LT48  	Migration to ispLSI2032E-110LT48

ispLSI2032A-80LT48  	Migration to ispLSI2032E-110LT48

ispLSI2032A-80LT48I

ispLSI2032A-180LT44  	Migration to ispLSI2032E-180LT44

ispLSI2032A-150LT44  	Migration to ispLSI2032E-180LT44

ispLSI2032A-135LT44  	Migration to ispLSI2032E-135LT44

ispLSI2032A-110LT44  	Migration to ispLSI2032E-110LT44

ispLSI2032A-80LT44  	Migration to ispLSI2032E-110LT44

ispLSI2032A-80LT44I

ispLSI2032A-180LJ44  	Migration to ispLSI2032E-180LJ44

ispLSI2032A-150LJ44  	Migration to ispLSI2032E-180LJ44

ispLSI2032A-135LJ44  	Migration to ispLSI2032E-135LJ44

ispLSI2032A-110LJ44  	Migration to ispLSI2032E-110LJ44

ispLSI2032A-80LJ44  	Migration to ispLSI2032E-110LJ44

ispLSI2032A-80LJ44I


ispLSI 2000V Device Family Part Numbers

ispLSI2192VE-180LB144

ispLSI2192VE-135LB144

ispLSI2192VE-100LB144

ispLSI2192VE-180LT128

ispLSI2192VE-135LT128

ispLSI2192VE-100LT128

ispLSI2128VE-180LB208

ispLSI2128VE-135LB208

ispLSI2128VE-100LB208

ispLSI2128VE-180LT176

ispLSI2128VE-135LT176

ispLSI2128VE-135LT176I

ispLSI2128VE-100LT176

ispLSI2128VE-180LQ160

ispLSI2128VE-135LQ160

ispLSI2128VE-100LQ160

ispLSI2128VE-180LB100

ispLSI2128VE-135LB100

ispLSI2128VE-100LB100

ispLSI2128VE-180LT100

ispLSI2128VE-135LT100

ispLSI2128VE-135LT100I

ispLSI2128VE-100LT100

ispLSI2128V-80LT176	Migration to ispLSI2128VE-100LT176

ispLSI2128V-60LT176	Migration to ispLSI2128VE-100LT176

ispLSI2128V-60LT176I	Migration to ispLSI2128VE-135LT176I

ispLSI2128V-80LQ160	Migration to ispLSI2128VE-100LQ160

ispLSI2128V-60LQ160	Migration to ispLSI2128VE-100LQ160

ispLSI2128V-80LT100	Migration to ispLSI2128VE-100LT100

ispLSI2128V-60LT100	Migration to ispLSI2128VE-100LT100

ispLSI2128V-60LT100I	Migration to ispLSI2128VE-135LT100I

ispLSI2096VE-200LT128

ispLSI2096VE-135LT128

ispLSI2096VE-135LT128I

ispLSI2096VE-100LT128

ispLSI2096V-80LT128	Migration to ispLSI2096VE-100LT128

ispLSI2096V-60LT128	Migration to ispLSI2096VE-100LT128

ispLSI2096V-60LT128I	Migration to ispLSI2096VE-135LT128I

ispLSI2096V-80LQ128	Migration to ispLSI2096VE-100LT128

ispLSI2096V-60LQ128	Migration to ispLSI2096VE-100LT128

ispLSI2064VE-200LB100

ispLSI2064VE-135LB100

ispLSI2064VE-100LB100

ispLSI2064VE-200LT100

ispLSI2064VE-135LT100

ispLSI2064VE-135LT100I

ispLSI2064VE-100LT100

ispLSI2064VE-200LT44

ispLSI2064VE-135LT44

ispLSI2064VE-135LT44I

ispLSI2064VE-100LT44

ispLSI2064VE-200LJ44

ispLSI2064VE-135LJ44

ispLSI2064VE-100LJ44

ispLSI2064V-100LT100	Migration to ispLSI2064VE-100LT100

ispLSI2064V-80LT100	Migration to ispLSI2064VE-100LT100

ispLSI2064V-60LT100	Migration to ispLSI2064VE-100LT100

ispLSI2064V-60LT100I	Migration to ispLSI2064VE-135LT100I

ispLSI2064V-100LJ84	Migration to ispLSI2064VE-100LT100

ispLSI2064V-80LJ84	Migration to ispLSI2064VE-100LT100

ispLSI2064V-60LJ84	Migration to ispLSI2064VE-100LT100

ispLSI2064V-100LT44	Migration to ispLSI2064VE-100LT44

ispLSI2064V-80LT44	Migration to ispLSI2064VE-100LT44

ispLSI2064V-60LT44	Migration to ispLSI2064VE-100LT44

ispLSI2064V-60LT44I	Migration to ispLSI2064VE-135LT44I

ispLSI2064V-100LJ44	Migration to ispLSI2064VE-100LJ44

ispLSI2064V-80LJ44	Migration to ispLSI2064VE-100LJ44

ispLSI2064V-60LJ44	Migration to ispLSI2064VE-100LJ44

ispLSI2032VE-225LB49

ispLSI2032VE-180LB49

ispLSI2032VE-135LB49

ispLSI2032VE-110LB49

ispLSI2032VE-225LT48

ispLSI2032VE-180LT48

ispLSI2032VE-135LT48

ispLSI2032VE-110LT48

ispLSI2032VE-225LT44

ispLSI2032VE-180LT44

ispLSI2032VE-180LT44I

ispLSI2032VE-135LT44

ispLSI2032VE-110LT44

ispLSI2032VE-225LJ44

ispLSI2032VE-180LJ44

ispLSI2032VE-135LJ44

ispLSI2032VE-110LJ44

ispLSI2032V-100LT44	Migration to ispLSI2032VE-110LT44

ispLSI2032V-80LT44	Migration to ispLSI2032VE-110LT44

ispLSI2032V-60LT44	Migration to ispLSI2032VE-110LT44

ispLSI2032V-60LT44I	Migration to ispLSI2032VE-180LT44I

ispLSI2032V-100LJ44	Migration to ispLSI2032VE-110LJ44

ispLSI2032V-80LJ44	Migration to ispLSI2032VE-110LJ44

ispLSI2032V-60LJ44	Migration to ispLSI2032VE-110LJ44

ispLSI2032V-60LJ44I	Migration to ispLSI2032VE-180LT44I


ispLSI 2000VL Device Family Part Numbers

ispLSI2192VL-150LT128

ispLSI2192VL-135LT128

ispLSI2192VL-100LT128

ispLSI2192VL-150LB144

ispLSI2192VL-135LB144

ispLSI2192VL-100LB144

ispLSI2128VL-150LB208

ispLSI2128VL-135LB208

ispLSI2128VL-100LB208

ispLSI2128VL-150LT176

ispLSI2128VL-135LT176

ispLSI2128VL-135LT176I

ispLSI2128VL-100LT176

ispLSI2128VL-150LQ160

ispLSI2128VL-135LQ160

ispLSI2128VL-100LQ160

ispLSI2128VL-150LB100

ispLSI2128VL-135LB100

ispLSI2128VL-100LB100

ispLSI2128VL-150LT100

ispLSI2128VL-135LT100

ispLSI2128VL-135LT100I

ispLSI2128VL-100LT100

ispLSI2096VL-165LT128

ispLSI2096VL-135LT128

ispLSI2096VL-135LT128I

ispLSI2096VL-100LT128

ispLSI2064VL-165LB100

ispLSI2064VL-135LB100

ispLSI2064VL-100LB100

ispLSI2064VL-165LT100

ispLSI2064VL-135LT100

ispLSI2064VL-135LT100I

ispLSI2064VL-100LT100

ispLSI2064VL-165LT44

ispLSI2064VL-135LT44

ispLSI2064VL-135LT44I

ispLSI2064VL-100LT44

ispLSI2064VL-165LJ44

ispLSI2064VL-135LJ44

ispLSI2064VL-100LJ44

ispLSI2032VL-180LB49

ispLSI2032VL-135LB49

ispLSI2032VL-110LB49

ispLSI2032VL-180LT48

ispLSI2032VL-135LT48

ispLSI2032VL-110LT48

ispLSI2032VL-180LT44

ispLSI2032VL-135LT44

ispLSI2032VL-135LT44I

ispLSI2032VL-110LT44

ispLSI2032VL-180LJ44

ispLSI2032VL-135LJ44

ispLSI2032VL-110LJ44


ispLSI 3000 Device Family Part Numbers

ispLSI3448-90LB432

ispLSI3448-70LB432

ispLSI3320-100LB320

ispLSI3320-70LB320

ispLSI3320-100LQ208

ispLSI3320-70LQ208

ispLSI3256E-100LB320

ispLSI3256E-70LB320

ispLSI3256E-100LM304

ispLSI3256E-70LM304

ispLSI3256A-90LQ160

ispLSI3256A-70LQ160

ispLSI3256A-70LQ160I

ispLSI3192-100LB272

ispLSI3192-70LB272

ispLSI3192-100LM240

ispLSI3192-70LM240

ispLSI3192-70LM240I

ispLSI3160-125LB272

ispLSI3160-100LB272

ispLSI3160-70LB272

ispLSI3160-125LQ208

ispLSI3160-100LQ208

ispLSI3160-70LQ208


ispLSI 5000V Device Family Part Numbers

ispLSI5512VA-110LB388

ispLSI5512VA-100LB388

ispLSI5512VA-70LB388

ispLSI5512VA-70LB388I

ispLSI5512VA-110LB272

ispLSI5512VA-100LB272

ispLSI5512VA-70LB272

ispLSI5512VA-110LQ208

ispLSI5512VA-100LQ208

ispLSI5512VA-70LQ208

ispLSI5384VA-125LB388

ispLSI5384VA-100LB388

ispLSI5384VA-70LB388

ispLSI5384VA-125LB272

ispLSI5384VA-100LB272

ispLSI5384VA-70LB272

ispLSI5384VA-70LB272I

ispLSI5384VA-125LB208

ispLSI5384VA-100LB208

ispLSI5384VA-70LB208

ispLSI5384VA-125LQ208

ispLSI5384VA-100LQ208

ispLSI5384VA-70LQ208

ispLSI5256VA-125LB272

ispLSI5256VA-100LB272

ispLSI5256VA-70LB272

ispLSI5256VA-70LB272I

ispLSI5256VA-125LB208

ispLSI5256VA-100LB208

ispLSI5256VA-70LB208

ispLSI5256VA-125LQ208

ispLSI5256VA-100LQ208

ispLSI5256VA-70LQ208


ispLSI 6000 Device Family Part Numbers

ispLSI6192SM-70LM208

ispLSI6192SM-50LM208

ispLSI6192DM-70LM208

ispLSI6192DM-50LM208

ispLSI6192FF-70LM208

ispLSI6192FF-50LM208


ispLSI 8000 Device Family Part Numbers

ispLSI8840-110LB432

ispLSI8840-90LB432

ispLSI8840-60LB432

ispLSI81080V-125LB492

ispLSI81080V-90LB492

ispLSI81080V-60LB492

ispLSI81080V-125LB272

ispLSI81080V-90LB272

ispLSI81080V-60LB272

ispLSI8840V-125LB492

ispLSI8840V-90LB492

ispLSI8840V-60LB492

ispLSI8840V-125LB272

ispLSI8840V-90LB272

ispLSI8840V-60LB272

ispLSI8600V-125LB492

ispLSI8600V-90LB492

ispLSI8600V-60LB492

ispLSI8600V-125LB272

ispLSI8600V-90LB272

ispLSI8600V-60LB272


ispDesignEXPERT 8.1 MACH Device List
ispDesignEXPERT 8.1 MACH Production Device List

This section is a listing of all MACH devices supported by ispDesignEXPERT. The devices in this list are sorted alphabetically by template name (page heading). The columns in the list consist of Lattice's abbreviation, followed by the device's part number, and the footprint name.

Important: Devices with the note "Migration to…" in the right margin are not recommended for new designs. Instead, use the recommended device included in the note.


MACH4A3 Device Family Part Numbers

M4A3-32/32-5JC

M4A3-32/32-7JC

M4A3-32/32-10JC

M4A3-32/32-7JI

M4A3-32/32-10JI

M4A3-32/32-12JI

M4A3-32/32-5VC

M4A3-32/32-7VC

M4A3-32/32-10VC

M4A3-32/32-7VI

M4A3-32/32-10VI

M4A3-32/32-12VI

M4A3-32/32-5VC48

M4A3-32/32-7VC48

M4A3-32/32-10VC48

M4A3-32/32-7VI48

M4A3-32/32-10VI48

M4A3-32/32-12VI48

M4A3-64/32-55JC

M4A3-64/32-7JC

M4A3-64/32-10JC

M4A3-64/32-7JI

M4A3-64/32-10JI

M4A3-64/32-12JI

M4A3-64/32-55VC

M4A3-64/32-7VC

M4A3-64/32-10VC

M4A3-64/32-7VI

M4A3-64/32-10VI

M4A3-64/32-12VI

M4A3-64/32-55VC48

M4A3-64/32-7VC48

M4A3-64/32-10VC48

M4A3-64/32-7VI48

M4A3-64/32-10VI48

M4A3-64/32-12VI48

M4A3-128/64-55YC

M4A3-128/64-7YC

M4A3-128/64-10YC

M4A3-128/64-7YI

M4A3-128/64-10YI

M4A3-128/64-12YI

M4A3-128/64-55VC

M4A3-128/64-7VC

M4A3-128/64-10VC

M4A3-128/64-7VI

M4A3-128/64-10VI

M4A3-128/64-12VI

M4A3-256/128-65YC

M4A3-256/128-7YC

M4A3-256/128-10YC

M4A3-256/128-10YI

M4A3-256/128-12YI

M4A3-256/128-65AC

M4A3-256/128-7AC

M4A3-256/128-10AC

M4A3-256/128-10AI

M4A3-256/128-12AI


MACH4A5 Device Family Part Numbers

M4A5-32/32-5JC

M4A5-32/32-7JC

M4A5-32/32-10JC

M4A5-32/32-7JI

M4A5-32/32-10JI

M4A5-32/32-12JI

M4A5-32/32-5VC

M4A5-32/32-7VC

M4A5-32/32-10VC

M4A5-32/32-7VI

M4A5-32/32-10VI

M4A5-32/32-12VI

M4A5-32/32-5VC48

M4A5-32/32-7VC48

M4A5-32/32-10VC48

M4A5-32/32-7VI48

M4A5-32/32-10VI48

M4A5-32/32-12VI48

M4A5-64/32-55JC

M4A5-64/32-7JC

M4A5-64/32-10JC

M4A5-64/32-7JI

M4A5-64/32-10JI

M4A5-64/32-12JI

M4A5-64/32-55VC

M4A5-64/32-7VC

M4A5-64/32-10VC

M4A5-64/32-7VI

M4A5-64/32-10VI

M4A5-64/32-12VI

M4A5-64/32-55VC48

M4A5-64/32-7VC48

M4A5-64/32-10VC48

M4A5-64/32-7VI48

M4A5-64/32-10VI48

M4A5-64/32-12VI48

M4A5-128/64-55YC

M4A5-128/64-7YC

M4A5-128/64-10YC

M4A5-128/64-7YI

M4A5-128/64-10YI

M4A5-128/64-12YI

M4A5-128/64-55VC

M4A5-128/64-7VC

M4A5-128/64-10VC

M4A5-128/64-7VI

M4A5-128/64-10VI

M4A5-128/64-12VI


MACH4LV Device Family Part Numbers

M4LV-32/32-7JC	Migration to M4A3-32/32-7JC

M4LV-32/32-10JC	Migration to M4A3-32/32-10JC

M4LV-32/32-12JC	Migration to M4A3-32/32-10JC

M4LV-32/32-15JC	Migration to M4A3-32/32-10JC

M4LV-32/32-10JI	Migration to M4A3-32/32-10JI

M4LV-32/32-12JI	Migration to M4A3-32/32-12JI

M4LV-32/32-14JI	Migration to M4A3-32/32-12JI

M4LV-32/32-18JI	Migration to M4A3-32/32-12JI

M4LV-32/32-7VC	Migration to M4A3-32/32-7VC

M4LV-32/32-10VC	Migration to M4A3-32/32-10VC

M4LV-32/32-12VC	Migration to M4A3-32/32-10VC

M4LV-32/32-15VC	Migration to M4A3-32/32-10VC

M4LV-32/32-10VI	Migration to M4A3-32/32-10VI

M4LV-32/32-12VI	Migration to M4A3-32/32-12VI

M4LV-32/32-14VI	Migration to M4A3-32/32-12VI

M4LV-32/32-18VI	Migration to M4A3-32/32-12VI

M4LV-32/32-7VC48	Migration to M4A3-32/32-7VC48

M4LV-32/32-10VC48	Migration to M4A3-32/32-10VC48

M4LV-32/32-12VC48	Migration to M4A3-32/32-10VC48

M4LV-32/32-15VC48	Migration to M4A3-32/32-10VC48

M4LV-32/32-10VI48	Migration to M4A3-32/32-10VI48

M4LV-32/32-12VI48	Migration to M4A3-32/32-12VI48

M4LV-32/32-14VI48	Migration to M4A3-32/32-12VI48

M4LV-32/32-18VI48	Migration to M4A3-32/32-12VI48

M4LV-64/32-7JC	Migration to M4A3-64/32-7JC

M4LV-64/32-10JC	Migration to M4A3-64/32-10JC

M4LV-64/32-12JC	Migration to M4A3-64/32-10JC

M4LV-64/32-15JC	Migration to M4A3-64/32-10JC

M4LV-64/32-10JI	Migration to M4A3-64/32-10JI

M4LV-64/32-12JI	Migration to M4A3-64/32-12JI

M4LV-64/32-14JI	Migration to M4A3-64/32-12JI

M4LV-64/32-18JI	Migration to M4A3-64/32-12JI

M4LV-64/32-7VC	Migration to M4A3-64/32-7VC

M4LV-64/32-10VC	Migration to M4A3-64/32-10VC

M4LV-64/32-12VC	Migration to M4A3-64/32-10VC

M4LV-64/32-15VC	Migration to M4A3-64/32-10VC

M4LV-64/32-10VI	Migration to M4A3-64/32-10VI

M4LV-64/32-12VI	Migration to M4A3-64/32-12VI

M4LV-64/32-14VI	Migration to M4A3-64/32-12VI

M4LV-64/32-18VI	Migration to M4A3-64/32-12VI

M4LV-64/32-7VC48	Migration to M4A3-64/32-7VC48

M4LV-64/32-10VC48	Migration to M4A3-64/32-10VC48

M4LV-64/32-12VC48	Migration to M4A3-64/32-10VC48

M4LV-64/32-15VC48	Migration to M4A3-64/32-10VC48

M4LV-64/32-10VI48	Migration to M4A3-64/32-10VI48

M4LV-64/32-12VI48	Migration to M4A3-64/32-12VI48

M4LV-64/32-14VI48	Migration to M4A3-64/32-12VI48

M4LV-64/32-18VI48	Migration to M4A3-64/32-12VI48

M4LV-96/48-7VC

M4LV-96/48-10VC

M4LV-96/48-12VC

M4LV-96/48-15VC

M4LV-96/48-10VI

M4LV-96/48-12VI

M4LV-96/48-14VI

M4LV-96/48-18VI

M4LV-128/64-7YC	Migration to M4A3-128/64-7YC

M4LV-128/64-10YC	Migration to M4A3-128/64-10YC

M4LV-128/64-12YC	Migration to M4A3-128/64-10YC

M4LV-128/64-15YC	Migration to M4A3-128/64-10YC

M4LV-128/64-10YI	Migration to M4A3-128/64-10YI

M4LV-128/64-12YI	Migration to M4A3-128/64-12YI

M4LV-128/64-14YI	Migration to M4A3-128/64-12YI

M4LV-128/64-18YI	Migration to M4A3-128/64-12YI

M4LV-128/64-7VC	Migration to M4A3-128/64-7VC

M4LV-128/64-10VC	Migration to M4A3-128/64-10VC

M4LV-128/64-12VC	Migration to M4A3-128/64-10VC

M4LV-128/64-15VC	Migration to M4A3-128/64-10VC

M4LV-128/64-10VI	Migration to M4A3-128/64-10VI

M4LV-128/64-12VI	Migration to M4A3-128/64-12VI

M4LV-128/64-14VI	Migration to M4A3-128/64-12VI

M4LV-128/64-18VI	Migration to M4A3-128/64-12VI

M4LV-128N/64-7JC

M4LV-128N/64-10JC

M4LV-128N/64-12JC

M4LV-128N/64-15JC

M4LV-128N/64-10JI

M4LV-128N/64-12JI

M4LV-128N/64-14JI

M4LV-128N/64-18JI

M4LV-192/96-7VC

M4LV-192/96-10VC

M4LV-192/96-12VC

M4LV-192/96-15VC

M4LV-192/96-10VI

M4LV-192/96-12VI

M4LV-192/96-14VI

M4LV-192/96-18VI

M4LV-256/128-7YC	Migration to M4A3-256/128-7YC

M4LV-256/128-10YC	Migration to M4A3-256/128-10YC

M4LV-256/128-12YC	Migration to M4A3-256/128-10YC

M4LV-256/128-15YC	Migration to M4A3-256/128-10YC

M4LV-256/128-10YI	Migration to M4A3-256/128-10YI

M4LV-256/128-12YI	Migration to M4A3-256/128-12YI

M4LV-256/128-14YI	Migration to M4A3-256/128-12YI

M4LV-256/128-18YI	Migration to M4A3-256/128-12YI

M4LV-256/128-7AC	Migration to M4A3-256/128-7AC

M4LV-256/128-10AC	Migration to M4A3-256/128-10AC

M4LV-256/128-12AC	Migration to M4A3-256/128-10AC

M4LV-256/128-15AC	Migration to M4A3-256/128-10AC

M4LV-256/128-10AI	Migration to M4A3-256/128-10AI

M4LV-256/128-12AI	Migration to M4A3-256/128-12AI

M4LV-256/128-14AI	Migration to M4A3-256/128-12AI

M4LV-256/128-18AI	Migration to M4A3-256/128-12AI


MACH4 Device Family Part Numbers

M4-32/32-7JC	Migration to M4A5-32/32-7JC

M4-32/32-10JC	Migration to M4A5-32/32-10JC

M4-32/32-12JC	Migration to M4A5-32/32-10JC

M4-32/32-15JC	Migration to M4A5-32/32-10JC

M4-32/32-10JI	Migration to M4A5-32/32-10JI

M4-32/32-12JI	Migration to M4A5-32/32-12JI

M4-32/32-14JI	Migration to M4A5-32/32-12JI

M4-32/32-18JI	Migration to M4A5-32/32-12JI

M4-32/32-7VC	Migration to M4A5-32/32-7VC

M4-32/32-10VC	Migration to M4A5-32/32-10VC

M4-32/32-12VC	Migration to M4A5-32/32-10VC

M4-32/32-15VC	Migration to M4A5-32/32-10VC

M4-32/32-10VI	Migration to M4A5-32/32-10VI

M4-32/32-12VI	Migration to M4A5-32/32-12VI

M4-32/32-14VI	Migration to M4A5-32/32-12VI

M4-32/32-18VI	Migration to M4A5-32/32-12VI

M4-32/32-7VC48	Migration to M4A5-32/32-7VC48

M4-32/32-10VC48	Migration to M4A5-32/32-10VC48

M4-32/32-12VC48	Migration to M4A5-32/32-10VC48

M4-32/32-15VC48	Migration to M4A5-32/32-10VC48

M4-32/32-10VI48	Migration to M4A5-32/32-10VI48

M4-32/32-12VI48	Migration to M4A5-32/32-12VI48

M4-32/32-14VI48	Migration to M4A5-32/32-12VI48

M4-32/32-18VI48	Migration to M4A5-32/32-12VI48

M4-64/32-7JC	Migration to M4A5-64/32-7JC

M4-64/32-10JC	Migration to M4A5-64/32-10JC

M4-64/32-12JC	Migration to M4A5-64/32-10JC

M4-64/32-15JC	Migration to M4A5-64/32-10JC

M4-64/32-10JI	Migration to M4A5-64/32-10JI

M4-64/32-12JI	Migration to M4A5-64/32-12JI

M4-64/32-14JI	Migration to M4A5-64/32-12JI

M4-64/32-18JI	Migration to M4A5-64/32-12JI

M4-64/32-7VC	Migration to M4A5-64/32-7VC

M4-64/32-10VC	Migration to M4A5-64/32-10VC

M4-64/32-12VC	Migration to M4A5-64/32-10VC

M4-64/32-15VC	Migration to M4A5-64/32-10VC

M4-64/32-10VI	Migration to M4A5-64/32-10VI

M4-64/32-12VI	Migration to M4A5-64/32-12VI

M4-64/32-14VI	Migration to M4A5-64/32-12VI

M4-64/32-18VI	Migration to M4A5-64/32-12VI

M4-64/32-7VC48	Migration to M4A5-64/32-7VC48

M4-64/32-10VC48	Migration to M4A5-64/32-10VC48

M4-64/32-12VC48	Migration to M4A5-64/32-10VC48

M4-64/32-15VC48	Migration to M4A5-64/32-10VC48

M4-64/32-10VI48	Migration to M4A5-64/32-10VI48

M4-64/32-12VI48	Migration to M4A5-64/32-12VI48

M4-64/32-14VI48	Migration to M4A5-64/32-12VI48

M4-64/32-18VI48	Migration to M4A5-64/32-12VI48

M4-96/48-7VC

M4-96/48-10VC

M4-96/48-12VC

M4-96/48-15VC

M4-96/48-10VI

M4-96/48-12VI

M4-96/48-14VI

M4-96/48-18VI

M4-128/64-7YC	Migration to M4A5-128/64-7YC

M4-128/64-10YC	Migration to M4A5-128/64-10YC

M4-128/64-12YC	Migration to M4A5-128/64-10YC

M4-128/64-15YC	Migration to M4A5-128/64-10YC

M4-128/64-10YI	Migration to M4A5-128/64-10YI

M4-128/64-12YI	Migration to M4A5-128/64-12YI

M4-128/64-14YI	Migration to M4A5-128/64-12YI

M4-128/64-18YI	Migration to M4A5-128/64-12YI

M4-128/64-7VC	Migration to M4A5-128/64-7VC

M4-128/64-10VC	Migration to M4A5-128/64-10VC

M4-128/64-12VC	Migration to M4A5-128/64-10VC

M4-128/64-15VC	Migration to M4A5-128/64-10VC

M4-128/64-10VI	Migration to M4A5-128/64-10VI

M4-128/64-12VI	Migration to M4A5-128/64-12VI

M4-128/64-14VI	Migration to M4A5-128/64-12VI

M4-128/64-18VI	Migration to M4A5-128/64-12VI

M4-128N/64-7JC

M4-128N/64-10JC

M4-128N/64-12JC

M4-128N/64-15JC

M4-128N/64-10JI

M4-128N/64-12JI

M4-128N/64-14JI

M4-128N/64-18JI

M4-192/96-7VC

M4-192/96-10VC

M4-192/96-12VC

M4-192/96-15VC

M4-192/96-10VI

M4-192/96-12VI

M4-192/96-14VI

M4-192/96-18VI

M4-256/128-7YC

M4-256/128-10YC

M4-256/128-12YC

M4-256/128-15YC

M4-256/128-10YI

M4-256/128-12YI

M4-256/128-14YI

M4-256/128-18YI

M4-256/128-7AC

M4-256/128-10AC

M4-256/128-12AC

M4-256/128-15AC

M4-256/128-10AI

M4-256/128-12AI

M4-256/128-14AI

M4-256/128-18AI


MACH5LV Device Family Part Numbers

M5LV-128/68-5YC	Migration to M5A3-128/68-5YC

M5LV-128/68-7YC	Migration to M5A3-128/68-7YC

M5LV-128/68-10YC	Migration to M5A3-128/68-10YC

M5LV-128/68-12YC	Migration to M5A3-128/68-10YC

M5LV-128/68-7YI	Migration to M5A3-128/68-7YI

M5LV-128/68-10YI	Migration to M5A3-128/68-10YI

M5LV-128/68-12YI	Migration to M5A3-128/68-12YI

M5LV-128/68-15YI	Migration to M5A3-128/68-12YI

M5LV-128/68-5VC	Migration to M5A3-128/68-5YC

M5LV-128/68-7VC	Migration to M5A3-128/68-7YC

M5LV-128/68-10VC	Migration to M5A3-128/68-10YC

M5LV-128/68-12VC	Migration to M5A3-128/68-10YC

M5LV-128/68-7VI	Migration to M5A3-128/68-7YI

M5LV-128/68-10VI	Migration to M5A3-128/68-10YI

M5LV-128/68-12VI	Migration to M5A3-128/68-12YI

M5LV-128/68-15VI	Migration to M5A3-128/68-12YI

M5LV-128/74-5VC	Migration to M5A3-128/74-5VC

M5LV-128/74-7VC	Migration to M5A3-128/74-7VC

M5LV-128/74-10VC	Migration to M5A3-128/74-10VC

M5LV-128/74-12VC	Migration to M5A3-128/74-10VC

M5LV-128/74-7VI	Migration to M5A3-128/74-7VI

M5LV-128/74-10VI	Migration to M5A3-128/74-10VI

M5LV-128/74-12VI	Migration to M5A3-128/74-12VI

M5LV-128/74-15VI	Migration to M5A3-128/74-12VI

M5LV-128/104-5VC	Migration to M5A3-128/104-5VC

M5LV-128/104-7VC	Migration to M5A3-128/104-7VC

M5LV-128/104-10VC	Migration to M5A3-128/104-10VC

M5LV-128/104-12VC	Migration to M5A3-128/104-10VC

M5LV-128/104-7VI	Migration to M5A3-128/104-7VI

M5LV-128/104-10VI	Migration to M5A3-128/104-10VI

M5LV-128/104-12VI	Migration to M5A3-128/104-12VI

M5LV-128/104-15VI	Migration to M5A3-128/104-12VI

M5LV-128/120-5YC	Migration to M5A3-128/120-5YC

M5LV-128/120-7YC	Migration to M5A3-128/120-7YC

M5LV-128/120-10YC	Migration to M5A3-128/120-10YC

M5LV-128/120-12YC	Migration to M5A3-128/120-10YC

M5LV-128/120-7YI	Migration to M5A3-128/120-7YI

M5LV-128/120-10YI	Migration to M5A3-128/120-10YI

M5LV-128/120-12YI	Migration to M5A3-128/120-12YI

M5LV-128/120-15YI	Migration to M5A3-128/120-12YI

M5LV-256/68-5YC	Migration to M5A3-256/68-5YC

M5LV-256/68-7YC	Migration to M5A3-256/68-7YC

M5LV-256/68-10YC	Migration to M5A3-256/68-10YC

M5LV-256/68-12YC	Migration to M5A3-256/68-10YC

M5LV-256/68-7YI	Migration to M5A3-256/68-7YI

M5LV-256/68-10YI	Migration to M5A3-256/68-10YI

M5LV-256/68-12YI	Migration to M5A3-256/68-12YI

M5LV-256/68-15YI	Migration to M5A3-256/68-12YI

M5LV-256/68-5VC	Migration to M5A3-256/68-5YC

M5LV-256/68-7VC	Migration to M5A3-256/68-7YC

M5LV-256/68-10VC	Migration to M5A3-256/68-10YC

M5LV-256/68-12VC	Migration to M5A3-256/68-10YC

M5LV-256/68-7VI	Migration to M5A3-256/68-7YI

M5LV-256/68-10VI	Migration to M5A3-256/68-10YI

M5LV-256/68-12VI	Migration to M5A3-256/68-12YI

M5LV-256/68-15VI	Migration to M5A3-256/68-12YI

M5LV-256/74-5VC	Migration to M5A3-256/74-5VC

M5LV-256/74-7VC	Migration to M5A3-256/74-7VC

M5LV-256/74-10VC	Migration to M5A3-256/74-10VC

M5LV-256/74-12VC	Migration to M5A3-256/74-10VC

M5LV-256/74-7VI	Migration to M5A3-256/74-7VI

M5LV-256/74-10VI	Migration to M5A3-256/74-10VI

M5LV-256/74-12VI	Migration to M5A3-256/74-12VI

M5LV-256/74-15VI	Migration to M5A3-256/74-12VI

M5LV-256/104-5VC	Migration to M5A3-256/104-5VC

M5LV-256/104-7VC	Migration to M5A3-256/104-7VC

M5LV-256/104-10VC	Migration to M5A3-256/104-10VC

M5LV-256/104-12VC	Migration to M5A3-256/104-10VC

M5LV-256/104-7VI	Migration to M5A3-256/104-7VI

M5LV-256/104-10VI	Migration to M5A3-256/104-10VI

M5LV-256/104-12VI	Migration to M5A3-256/104-12VI

M5LV-256/104-15VI	Migration to M5A3-256/104-12VI

M5LV-256/120-5YC	Migration to M5A3-256/120-5YC

M5LV-256/120-7YC	Migration to M5A3-256/120-7YC

M5LV-256/120-10YC	Migration to M5A3-256/120-10YC

M5LV-256/120-12YC	Migration to M5A3-256/120-10YC

M5LV-256/120-7YI	Migration to M5A3-256/120-7YI

M5LV-256/120-10YI	Migration to M5A3-256/120-10YI

M5LV-256/120-12YI	Migration to M5A3-256/120-12YI

M5LV-256/120-15YI	Migration to M5A3-256/120-12YI

M5LV-256/160-5YC	Migration to M5A3-256/160-5YC

M5LV-256/160-7YC	Migration to M5A3-256/160-7YC

M5LV-256/160-10YC	Migration to M5A3-256/160-10YC

M5LV-256/160-12YC	Migration to M5A3-256/160-10YC

M5LV-256/160-7YI	Migration to M5A3-256/160-7YI

M5LV-256/160-10YI	Migration to M5A3-256/160-10YI

M5LV-256/160-12YI	Migration to M5A3-256/160-12YI

M5LV-256/160-15YI	Migration to M5A3-256/160-12YI

M5LV-320/120-7HC

M5LV-320/120-10HC

M5LV-320/120-12HC

M5LV-320/120-15HC

M5LV-320/120-10HI

M5LV-320/120-12HI

M5LV-320/120-15HI

M5LV-320/120-20HI

M5LV-320/160-7HC

M5LV-320/160-10HC

M5LV-320/160-12HC

M5LV-320/160-15HC

M5LV-320/160-10HI

M5LV-320/160-12HI

M5LV-320/160-15HI

M5LV-320/160-20HI

M5LV-320/184-7HC

M5LV-320/184-10HC

M5LV-320/184-12HC

M5LV-320/184-15HC

M5LV-320/184-10HI

M5LV-320/184-12HI

M5LV-320/184-15HI

M5LV-320/184-20HI

M5LV-320/192-7AC

M5LV-320/192-10AC

M5LV-320/192-12AC

M5LV-320/192-15AC

M5LV-320/192-10AI

M5LV-320/192-12AI

M5LV-320/192-15AI

M5LV-320/192-20AI

M5LV-384/120-7HC

M5LV-384/120-10HC

M5LV-384/120-12HC

M5LV-384/120-15HC

M5LV-384/120-10HI

M5LV-384/120-12HI

M5LV-384/120-15HI

M5LV-384/120-20HI

M5LV-384/160-7HC

M5LV-384/160-10HC

M5LV-384/160-12HC

M5LV-384/160-15HC

M5LV-384/160-10HI

M5LV-384/160-12HI

M5LV-384/160-15HI

M5LV-384/160-20HI

M5LV-384/192-7AC

M5LV-384/192-10AC

M5LV-384/192-12AC

M5LV-384/192-15AC

M5LV-384/192-10AI

M5LV-384/192-12AI

M5LV-384/192-15AI

M5LV-384/192-20AI

M5LV-512/120-7HC

M5LV-512/120-10HC

M5LV-512/120-12HC

M5LV-512/120-15HC

M5LV-512/120-10HI

M5LV-512/120-12HI

M5LV-512/120-15HI

M5LV-512/120-20HI

M5LV-512/160-7HC

M5LV-512/160-10HC

M5LV-512/160-12HC

M5LV-512/160-15HC

M5LV-512/160-10HI

M5LV-512/160-12HI

M5LV-512/160-15HI

M5LV-512/160-20HI

M5LV-512/192-7AC

M5LV-512/192-10AC

M5LV-512/192-12AC

M5LV-512/192-15AC

M5LV-512/192-10AI

M5LV-512/192-12AI

M5LV-512/192-15AI

M5LV-512/192-20AI

M5LV-512/256-7AC

M5LV-512/256-10AC

M5LV-512/256-12AC

M5LV-512/256-15AC

M5LV-512/256-10AI

M5LV-512/256-12AI

M5LV-512/256-15AI

M5LV-512/256-20AI


MACH5 Device Family Part Numbers

M5-128/68-7YC	Migration to M5A5-128/68-7YC

M5-128/68-10YC	Migration to M5A5-128/68-10YC

M5-128/68-12YC	Migration to M5A5-128/68-10YC

M5-128/68-15YC	Migration to M5A5-128/68-10YC

M5-128/68-10YI	Migration to M5A5-128/68-10YI

M5-128/68-12YI	Migration to M5A5-128/68-10YI

M5-128/68-15YI	Migration to M5A5-128/68-10YI

M5-128/68-20YI	Migration to M5A5-128/68-10YI

M5-128/68-7VC	Migration to M5A5-128/68-7YC

M5-128/68-10VC	Migration to M5A5-128/68-10YC

M5-128/68-12VC	Migration to M5A5-128/68-10YC

M5-128/68-15VC	Migration to M5A5-128/68-10YC

M5-128/68-10VI	Migration to M5A5-128/68-10YI

M5-128/68-12VI	Migration to M5A5-128/68-10YI

M5-128/68-15VI	Migration to M5A5-128/68-10YI

M5-128/68-20VI	Migration to M5A5-128/68-10YI

M5-128/104-7YC	Migration to M5A5-128/104-7VC

M5-128/104-10YC	Migration to M5A5-128/104-10VC

M5-128/104-12YC	Migration to M5A5-128/104-10VC

M5-128/104-15YC	Migration to M5A5-128/104-10VC

M5-128/104-10YI	Migration to M5A5-128/104-10VI

M5-128/104-12YI	Migration to M5A5-128/104-10VI

M5-128/104-15YI	Migration to M5A5-128/104-10VI

M5-128/104-20YI	Migration to M5A5-128/104-10VI

M5-128/120-7YC	Migration to M5A5-128/120-7YC

M5-128/120-10YC	Migration to M5A5-128/120-10YC

M5-128/120-12YC	Migration to M5A5-128/120-10YC

M5-128/120-15YC	Migration to M5A5-128/120-10YC

M5-128/120-10YI	Migration to M5A5-128/120-10YI

M5-128/120-12YI	Migration to M5A5-128/120-10YI

M5-128/120-15YI	Migration to M5A5-128/120-10YI

M5-128/120-20YI	Migration to M5A5-128/120-10YI

M5-192/68-7YC

M5-192/68-10YC

M5-192/68-12YC

M5-192/68-15YC

M5-192/68-10YI

M5-192/68-12YI

M5-192/68-15YI

M5-192/68-20YI

M5-192/68-7VC

M5-192/68-10VC

M5-192/68-12VC

M5-192/68-15VC

M5-192/68-10VI

M5-192/68-12VI

M5-192/68-15VI

M5-192/68-20VI

M5-192/104-7YC

M5-192/104-10YC

M5-192/104-12YC

M5-192/104-15YC

M5-192/104-10YI

M5-192/104-12YI

M5-192/104-15YI

M5-192/104-20YI

M5-192/120-7YC

M5-192/120-10YC

M5-192/120-12YC

M5-192/120-15YC

M5-192/120-10YI

M5-192/120-12YI

M5-192/120-15YI

M5-192/120-20YI

M5-192/160-7YC

M5-192/160-10YC

M5-192/160-12YC

M5-192/160-15YC

M5-192/160-10YI

M5-192/160-12YI

M5-192/160-15YI

M5-192/160-20YI

M5-256/68-7YC	Migration to M5A5-256/68-7YC

M5-256/68-10YC	Migration to M5A5-256/68-10YC

M5-256/68-12YC	Migration to M5A5-256/68-10YC

M5-256/68-15YC	Migration to M5A5-256/68-10YC

M5-256/68-10YI	Migration to M5A5-256/68-10YI

M5-256/68-12YI	Migration to M5A5-256/68-10YI

M5-256/68-15YI	Migration to M5A5-256/68-10YI

M5-256/68-20YI	Migration to M5A5-256/68-10YI

M5-256/68-7VC	Migration to M5A5-256/68-7YC

M5-256/68-10VC	Migration to M5A5-256/68-10YC

M5-256/68-12VC	Migration to M5A5-256/68-10YC

M5-256/68-15VC	Migration to M5A5-256/68-10YC

M5-256/68-10VI	Migration to M5A5-256/68-10YI

M5-256/68-12VI	Migration to M5A5-256/68-10YI

M5-256/68-15VI	Migration to M5A5-256/68-10YI

M5-256/68-20VI	Migration to M5A5-256/68-10YI

M5-256/104-7YC	Migration to M5A5-256/104-7VC

M5-256/104-10YC	Migration to M5A5-256/104-10VC

M5-256/104-12YC	Migration to M5A5-256/104-10VC

M5-256/104-15YC	Migration to M5A5-256/104-10VC

M5-256/104-10YI	Migration to M5A5-256/104-10VI

M5-256/104-12YI	Migration to M5A5-256/104-10VI

M5-256/104-15YI	Migration to M5A5-256/104-10VI

M5-256/104-20YI	Migration to M5A5-256/104-10VI

M5-256/120-7YC	Migration to M5A5-256/120-7YC

M5-256/120-10YC	Migration to M5A5-256/120-10YC

M5-256/120-12YC	Migration to M5A5-256/120-10YC

M5-256/120-15YC	Migration to M5A5-256/120-10YC

M5-256/120-10YI	Migration to M5A5-256/120-10YI

M5-256/120-12YI	Migration to M5A5-256/120-10YI

M5-256/120-15YI	Migration to M5A5-256/120-10YI

M5-256/120-20YI	Migration to M5A5-256/120-10YI

M5-256/160-7YC	Migration to M5A5-256/160-7YC

M5-256/160-10YC	Migration to M5A5-256/160-10YC

M5-256/160-12YC	Migration to M5A5-256/160-10YC

M5-256/160-15YC	Migration to M5A5-256/160-10YC

M5-256/160-10YI	Migration to M5A5-256/160-10YI

M5-256/160-12YI	Migration to M5A5-256/160-10YI

M5-256/160-15YI	Migration to M5A5-256/160-10YI

M5-256/160-20YI	Migration to M5A5-256/160-10YI

M5-320/120-7HC

M5-320/120-10HC

M5-320/120-12HC

M5-320/120-15HC

M5-320/120-10HI

M5-320/120-12HI

M5-320/120-15HI

M5-320/120-20HI

M5-320/160-7HC

M5-320/160-10HC

M5-320/160-12HC

M5-320/160-15HC

M5-320/160-10HI

M5-320/160-12HI

M5-320/160-15HI

M5-320/160-20HI

M5-320/184-7HC

M5-320/184-10HC

M5-320/184-12HC

M5-320/184-15HC

M5-320/184-10HI

M5-320/184-12HI

M5-320/184-15HI

M5-320/184-20HI

M5-320/192-7AC

M5-320/192-10AC

M5-320/192-12AC

M5-320/192-15AC

M5-320/192-10AI

M5-320/192-12AI

M5-320/192-15AI

M5-320/192-20AI

M5-384/120-7HC

M5-384/120-10HC

M5-384/120-12HC

M5-384/120-15HC

M5-384/120-10HI

M5-384/120-12HI

M5-384/120-15HI

M5-384/120-20HI

M5-384/160-7HC

M5-384/160-10HC

M5-384/160-12HC

M5-384/160-15HC

M5-384/160-10HI

M5-384/160-12HI

M5-384/160-15HI

M5-384/160-20HI

M5-512/120-7HC

M5-512/120-10HC

M5-512/120-12HC

M5-512/120-15HC

M5-512/120-10HI

M5-512/120-12HI

M5-512/120-15HI

M5-512/120-20HI

M5-512/160-7HC

M5-512/160-10HC

M5-512/160-12HC

M5-512/160-15HC

M5-512/160-10HI

M5-512/160-12HI

M5-512/160-15HI

M5-512/160-20HI

M5-512/184-7HC

M5-512/184-10HC

M5-512/184-12HC

M5-512/184-15HC

M5-512/184-10HI

M5-512/184-12HI

M5-512/184-15HI

M5-512/184-20HI

M5-512/256-7AC

M5-512/256-10AC

M5-512/256-12AC

M5-512/256-15AC

M5-512/256-10AI

M5-512/256-12AI

M5-512/256-15AI

M5-512/256-20AI


MACH 1 Device Family Part Numbers

MACH111-5JC

MACH111-7JC

MACH111-10JC

MACH111-12JC

MACH111-15JC

MACH111-7JI

MACH111-10JI

MACH111-12JI

MACH111-14JI

MACH111-18JI

MACH111-5VC

MACH111-7VC

MACH111-10VC

MACH111-12VC

MACH111-15VC

MACH111SP-5JC

MACH111SP-7JC

MACH111SP-10JC

MACH111SP-12JC

MACH111SP-15JC

MACH111SP-7JI

MACH111SP-10JI

MACH111SP-12JI

MACH111SP-14JI

MACH111SP-18JI

MACH111SP-5VC

MACH111SP-7VC

MACH111SP-10VC

MACH111SP-12VC

MACH111SP-15VC

MACH131-5JC/1

MACH131-7JC/1

MACH131-10JC/1

MACH131-12JC/1

MACH131-15JC/1

MACH131-7JI/1

MACH131-10JI/1

MACH131-12JI/1

MACH131-14JI/1

MACH131-18JI/1

MACH131SP-5VC

MACH131SP-7VC

MACH131SP-10VC

MACH131SP-12VC

MACH131SP-15VC

MACH131SP-5YC

MACH131SP-7YC

MACH131SP-10YC

MACH131SP-12YC

MACH131SP-15YC

MACH131SP-7YI

MACH131SP-10YI

MACH131SP-12YI

MACH131SP-14YI

MACH131SP-18YI


MACH 2 Device Family Part Numbers

MACH211-7JC

MACH211-10JC

MACH211-12JC

MACH211-15JC

MACH211-10JI

MACH211-12JI

MACH211-14JI

MACH211-18JI

MACH211-7VC

MACH211-10VC

MACH211-12VC

MACH211-15VC

MACH211SP-6JC

MACH211SP-7JC

MACH211SP-10JC

MACH211SP-12JC

MACH211SP-15JC

MACH211SP-10JI

MACH211SP-12JI

MACH211SP-14JI

MACH211SP-18JI

MACH211SP-6VC

MACH211SP-7VC

MACH211SP-10VC

MACH211SP-12VC

MACH211SP-15VC

MACH221-7JC

MACH221-10JC

MACH221-12JC

MACH221-15JC

MACH221-10JI

MACH221-12JI

MACH221-14JI

MACH221-18JI

MACH221SP-7YC

MACH221SP-10YC

MACH221SP-12YC

MACH221SP-15YC

MACH221SP-10YI

MACH221SP-12YI

MACH221SP-14YI

MACH221SP-18YI

MACH231-6JC

MACH231-7JC

MACH231-10JC/1

MACH231-12JC/1

MACH231-15JC/1

MACH231-12JI/1

MACH231-14JI/1

MACH231-18JI/1

MACH231SP-10VC

MACH231SP-12VC

MACH231SP-15VC

MACH231SP-10YC

MACH231SP-12YC

MACH231SP-15YC

MACH231SP-12YI

MACH231SP-14YI

MACH231SP-18YI


ispDesignEXPERT 8.1 GAL Production Device List
ispDesignEXPERT 8.1 GAL Device List

This section is a listing of all GAL devices supported by ispDesignEXPERT. The devices in this list are sorted alphabetically by template name (page heading). The columns in the list consist of Lattice's abbreviation, followed by the device's part number, and the footprint name.


GAL16 Device Family Part Numbers

GAL16LV8D-3LJ

GAL16LV8D5LJ

GAL16LV8C7LJ

GAL16LV8C10LJ

GAL16LV8C15LJ

GAL16LV8ZD15QJ

GAL16LV8ZD25QJ

GAL16V8Z-12QP

GAL16V8Z-15QP

GAL16V8Z-12QJ

GAL16V8Z-15QJ

GAL16V8Z-12QS

GAL16V8Z-15QS

GAL16V8ZD-12QP

GAL16V8ZD-15QP

GAL16V8ZD-12QJ

GAL16V8ZD-15QJ

GAL16V8D-3LJ

GAL16V8D5LJ

GAL16V8D7LJ

GAL16V8D-7LJI

GAL16V8D10LJI

GAL16V8D15LJI

GAL16V8D25LJI

GAL16V8D7LP

GAL16V8D10LP

GAL16V8D15LP

GAL16V8D25LP

GAL16V8D7LPI

GAL16V8D10LPI

GAL16V8D15LPI

GAL16V8D25LPI

GAL16V8D10QP

GAL16V8D15QP

GAL16V8D25QP

GAL16V8D20QPI

GAL16V8D25QPI

GAL16V8D-10QJ

GAL16V8D-15QJ

GAL16V8D-25QJ

GAL16V8D-20QJI

GAL16V8D-25QJI

GAL16VP8B-15LP

GAL16VP8B-25LP

GAL16VP8B-15LJ

GAL16VP8B-25LJ


GAL18 Device Family Part Numbers

GAL18V10B-7LP

GAL18V10B-10LP

GAL18V10B-15LP

GAL18V10B-20LP

GAL18V10B-7LJ

GAL18V10B-10LJ

GAL18V10B-15LJ

GAL18V10B-20LJ

GAL18V10-15LP

GAL18V10-20LP

GAL18V10-15LJ

GAL18V10-20LJ


GAL20 Device Family Part Numbers

GAL20LV8D-3LJ

GAL20LV8D-5LJ

GAL20LV8D-7LJ

GAL20LV8ZD-15QJ

GAL20LV8ZD-25QJ

GAL20V8Z-12QP

GAL20V8Z-15QP

GAL20V8Z-12QJ

GAL20V8Z-15QJ

GAL20V8ZD-12QP

GAL20V8ZD-15QP

GAL20V8ZD-12QJ

GAL20V8ZD-15QJ

GAL20V8C-5LJ

GAL20V8C-7LJ

GAL20V8C-10LJ

GAL20V8C-10LJI

GAL20V8B-7LP

GAL20V8B-10LP

GAL20V8B-15LP

GAL20V8B-25LP

GAL20V8B-10LPI

GAL20V8B-15LPI

GAL20V8B-25LPI

GAL20V8B-7LJ

GAL20V8B-10LJ

GAL20V8B-15LJ

GAL20V8B-25LJ

GAL20V8B-10LJI

GAL20V8B-15LJI

GAL20V8B-25LJI

GAL20V8B-15QP

GAL20V8B-25QP

GAL20V8B-20QPI

GAL20V8B-25QPI

GAL20V8B-15QJ

GAL20V8B-25QJ

GAL20V8B-20QJI

GAL20V8B-25QJI

GAL20VP8B-15LP

GAL20VP8B-25LP

GAL20VP8B-15LJ

GAL20VP8B-25LJ

GAL20XV10B-10LP

GAL20XV10B-15LP

GAL20XV10B-20LP

GAL20XV10B-10LJ

GAL20XV10B-15LJ

GAL20XV10B-20LJ

GAL20RA10B-7LJ

GAL20RA10B-10LJ

GAL20RA10B-15LJ

GAL20RA10B-20LJ

GAL20RA10B-20LJI

GAL20RA10B-30LJ

GAL20RA10B-10LP

GAL20RA10B-15LP

GAL20RA10B-20LP

GAL20RA10B-20LPI

GAL20RA10B-30LP


GAL22 Device Family Part Numbers

GAL22LV10D-4LJ

GAL22LV10D-5LJ

GAL22LV10D-7LJ

GAL22LV10D-10LJ

GAL22LV10D-15LJ

GAL22LV10Z-15QJ

GAL22LV10Z-25QJ

GAL22LV10ZD-15QJ

GAL22LV10ZD-25QJ

GAL22V10D-4LJ

GAL22V10D-5LJ

GAL22V10D-7LJ

GAL22V10D-10LJ

GAL22V10D-15LJ

GAL22V10D-25LJ

GAL22V10D-7LJI

GAL22V10D-10LJI

GAL22V10D-15LJI

GAL22V10D-20LJI

GAL22V10D-25LJI

GAL22V10C-5LJ

GAL22V10C-7LJ

GAL22V10C-10LJ

GAL22V10C-7LJI

GAL22V10C-10LJI

GAL22V10B-7LJ

GAL22V10B-10LJ

GAL22V10B-15LJ

GAL22V10B-25LJ

GAL22V10B-15LJI

GAL22V10B-20LJI

GAL22V10B-25LJI

GAL22V10D-7LP

GAL22V10D-10LP

GAL22V10D-15LP

GAL22V10D-25LP

GAL22V10D-7LPI

GAL22V10D-10LPI

GAL22V10D-15LPI

GAL22V10D-20LPI

GAL22V10D-25LPI

GAL22V10C-7LP

GAL22V10C-10LP

GAL22V10C-7LPI

GAL22V10C-10LPI

GAL22V10B-7LP

GAL22V10B-10LP

GAL22V10B-15LP

GAL22V10B-25LP

GAL22V10B-15LPI

GAL22V10B-20LPI

GAL22V10B-25LPI

GAL22V10D-10QJ

GAL22V10D-15QJ

GAL22V10D-25QJ

GAL22V10D-10QP

GAL22V10D-15QP

GAL22V10D-25QP

ispGAL22LV10-4LJ

ispGAL22LV10-5LJ

ispGAL22LV10-7LJ

ispGAL22LV10-10LJ

ispGAL22LV10-15LJ

ispGAL22LV10-7LJI

ispGAL22LV10-10LJI

ispGAL22LV10-15LJI

ispGAL22LV10-4LK

ispGAL22LV10-5LK

ispGAL22LV10-7LK

ispGAL22LV10-10LK

ispGAL22LV10-15LK

ispGAL22LV10-7LKI

ispGAL22LV10-10LKI

ispGAL22LV10-15LKI

ispGAL22V10C-7LJ

ispGAL22V10C-10LJ

ispGAL22V10C-15LJ

ispGAL22V10C-15LJI

ispGAL22V10B-7LJ

ispGAL22V10B-10LJ

ispGAL22V10B-15LJ

ispGAL22V10C-7LK

ispGAL22V10C-10LK

ispGAL22V10C-15LK

ispGAL22V10C-15LKI


GAL26 Device Family Part Numbers

GAL26CLV12D-5LJ

GAL26CLV12D-7LJ

GAL26CV12C-7LP

GAL26CV12C-10LP

GAL26CV12C-10LPI

GAL26CV12B-10LP

GAL26CV12B-15LP

GAL26CV12B-20LP

GAL26CV12B-15LPI

GAL26CV12B-20LPI

GAL26CV12C-7LJ

GAL26CV12C-10LJ

GAL26CV12C-10LJI

GAL26CV12B-10LJ

GAL26CV12B-15LJ

GAL26CV12B-20LJ

GAL26CV12B-15LJI

GAL26CV12B-20LJI


GAL600 Device Family Part Numbers

GAL6001B-30LP

GAL6001B-30LJ

GAL6002B-15LP

GAL6002B-20LP

GAL6002B-15LJ

GAL6002B-20LJ


ispDesignEXPERT 8.1 PAL Device List

This section is a listing of all PAL devices supported by ispDesignEXPERT. The devices in this list are sorted alphabetically by template name (page heading). The columns in the list consist of Lattice's abbreviation, followed by the device's part number, and the footprint name.


PAL16 Device Family Part Numbers

PALCE16V8H-7SC/5

PALCE16V8H-10SC/4

PALCE16V8H-15SC/4

PALCE16V8H-25SC/4

PALCE16V8H-5JC/5

PALCE16V8H-7JC/5

PALCE16V8H-10JC/4

PALCE16V8H-15JC/4

PALCE16V8H-25JC/4

PALCE16V8H-10JI/4

PALCE16V8H-15JI/4

PALCE16V8H-25JI/4

PALCE16V8H-7PC/5

PALCE16V8H-10PC/4

PALCE16V8H-15PC/4

PALCE16V8H-25PC/4

PALCE16V8H-10PI/4

PALCE16V8H-15PI/4

PALCE16V8H-25PI/4

PALCE16V8Q-10JC/5

PALCE16V8Q-15JC/4

PALCE16V8Q-25JC/4

PALCE16V8Q-20JI/4

PALCE16V8Q-25JI/4

PALCE16V8Q-15PC/4

PALCE16V8Q-25PC/4

PALCE16V8Q-20PI/4

PALCE16V8Q-25PI/4

PALCE16V8Z-25SC

PALCE16V8Z-25SI

PALCE16V8Z-25JC

PALCE16V8Z-12JI

PALCE16V8Z-15JI

PALCE16V8Z-25JI

PALCE16V8Z-25PC

PALCE16V8Z-12PI

PALCE16V8Z-15PI

PALCE16V8Z-25PI

PALLV16V8-10SC

PALLV16V8-10JC

PALLV16V8Z-20JI

PALLV16V8-10PC

PALLV16V8Z-20PI


PAL20 Device Family Part Numbers

PALCE20V8H-5JC/5

PALCE20V8H-7JC/5

PALCE20V8H-10JC/4

PALCE20V8H-15JC/4

PALCE20V8H-25JC/4

PALCE20V8H-15JI/4

PALCE20V8H-25JI/4

PALCE20V8H-7PC/5

PALCE20V8H-10PC/4

PALCE20V8H-15PC/4

PALCE20V8H-25PC/4

PALCE20V8H-15PI/4

PALCE20V8H-25PI/4

PALCE20V8Q-15JC/4

PALCE20V8Q-25JC/4

PALCE20V8Q-20JI/4

PALCE20V8Q-25JI/4

PALCE20V8Q-15PC/4

PALCE20V8Q-25PC/4

PALCE20V8Q-20PI/4

PALCE20V8Q-25PI/4

PALCE20RA10H-7JC

PALCE20RA10H-10JC

PALCE20RA10H-15JC

PALCE20RA10H-20JC

PALCE20RA10H-7JI

PALCE20RA10H-10JI

PALCE20RA10H-15JI

PALCE20RA10H-20JI

PALCE20RA10H-10PC

PALCE20RA10H-15PC

PALCE20RA10H-20PC

PALCE20RA10H-10PI

PALCE20RA10H-15PI

PALCE20RA10H-20PI


PAL22 Device Family Part Numbers

PALCE22V10H-10SC/5

PALCE22V10H-15SC/4

PALCE22V10H-25SC/4

PALCE22V10H-5JC/5

PALCE22V10H-7JC/5

PALCE22V10H-10JC/5

PALCE22V10H-15JC/4

PALCE22V10H-25JC/4

PALCE22V10H-10JI/5

PALCE22V10H-15JI/5

PALCE22V10H-20JI/4

PALCE22V10H-25JI/4

PALCE22V10H-7PC/5

PALCE22V10H-10PC/5

PALCE22V10H-15PC/4

PALCE22V10H-25PC/4

PALCE22V10H-10PI/5

PALCE22V10H-15PI/5

PALCE22V10H-20PI/4

PALCE22V10H-25PI/4

PALCE22V10Q-10JC/5

PALCE22V10Q-15JC/5

PALCE22V10Q-25JC/4

PALCE22V10Q-10PC/5

PALCE22V10Q-15PC/5

PALCE22V10Q-25PC/4

PALCE22V10Z-25SC

PALCE22V10Z-25SI

PALCE22V10Z-25JC

PALCE22V10Z-15JI

PALCE22V10Z-25JI

PALCE22V10Z-25PC

PALCE22V10Z-15PI

PALCE22V10Z-25PI

PALLV22V10-7JC

PALLV22V10-10JC

PALLV22V10-15JC

PALLV22V10-15JI

PALLV22V10-25JI

PALLV22V10-10PC

PALLV22V10-15PC

PALLV22V10-25PI


PAL24 Device Family Part Numbers

PALCE24V10H-15JC

PALCE24V10H-25JC

PALCE24V10H-15PC

PALCE24V10H-25PC


PAL26 Device Family Part Numbers

PALCE26V12H-7JC/4

PALCE26V12H-10JC/4

PALCE26V12H-15JC/4

PALCE26V12H-20JC/4

PALCE26V12H-10JI/4

PALCE26V12H-15JI/4

PALCE26V12H-20JI/4

PALCE26V12H-10PC/4

PALCE26V12H-15PC/4

PALCE26V12H-20PC/4

PALCE26V12H-10PI/4

PALCE26V12H-15PI/4

PALCE26V12H-20PI/4


PAL29 Device Family Part Numbers

PALCE29M16H-25JC/4

PALCE29M16H-25PC/4

PALCE29MA16H-25JC/4

PALCE29MA16H-25PC/4


PAL610 Device Family Part Numbers

PALCE610H-15JC

PALCE610H-25JC

PALCE610H-15PC

PALCE610H-25PC