The ABEL HDL was made for PLD circuit design by DATA I/O and with other hardware descriptor languages come to easy the PLD design. Modern computer languages are almost invariably composed of declarative and executable statements, and HDL languages are particularly rich in the former. Comparing the result of a High level programming language (as C++) the result of a HDL program will be a hardware and not an executable program.
ABEL hardware description language allows to one to describe digital designs with equations, truth tables, state diagrams, or any combinations of the three, optimize and simulate the design without specifying a device or assigning pins. The output files produced by the ABEL environment are in standard formats to interface with other tools (in our case with the Xilinx™ design environment) JEDEC format output files download directly the PLD programmers and PROM format files to allow PROM programming. ABEL hardware description language like behavioral description languages describe the hardware structure on its functional run ( the output signals are function of the variation of the input signals). The ABEL HDL permit to write hardware independent programs, and after program verification and optimization one can choose the PLD device. In this operation the so called SmartPart help the user to choose the best PLD in which the program fit in with optimal parameters.
a - z (lowercase alphabet)
A - Z (uppercase alphabet)
0 - 9 (digits)
<space>
<tab>
! @ # $ ? + & * ( )- _ = +
[ { } ] ; : ` " ` ~ \ | , < > . / ^ %
The rules and restrictions for identifiers are the same regardless of what the identifier describes. The rules governing identifiers are:
DECLARATIONS IF STATE_DIAGRAM DEVICE IN (obs) TEST_VECTORS ELSE ISTYPE THEN ENABLE (obs) LIBRARY TITLE END MACRO TRACE ENDCASE MODULE TRUTH_TABLE ENDWITH NODE WHEN FUSES OPTIONS WITH EQUATIONS PIN FLAG (obs) PROPERTY
56 decimal 56Characters could have also a value, for example `d'=100^h56 hexadecimal 56 (its decimal value is 86)
^b1001 binary 1001 (its decimal value is 9)
^o56 octal 56 (its decimal value is 46)
^h0E hexadecimal 0E (its decimal value is 14)
.C. Clocked input (low-high-low transition).K. Clocked input (high-low-high transition)
.U. Clock up edge (low-high transition)
.D. Clock down edge (high-low transition)
.F. Floating input or output signal
.P. Register preload
.SVn. n = 2 .. 9. Drive the input to super voltage 2 through 9V.
.X. Don't care condition
.Z. Tristate value
`Hello this is a string!'A single quote can be included in a string by preceding it with a backslash, "\."`Punctuation? is even allowed !!'
`It\'s easy to use ABEL'Backslashes can be put in a string by using two of them in succession.
`He\\she can use backslashes in a string'
You can use the set operator (..) in expressions and equations.
ABEL-HDL operators are divided into four basic types: logical, arithmetic, relational, and assignment.
Logical Operators: Logical operators are used in expressions and operations are performed bit by bit.
| ! | !A | NOT: ones complement |
| & | A & B | AND |
| # | A # B | OR |
| $ | A $ B | XOR: exclusive OR |
| !$ | A !& B | XNOR exclusive NOR |
Arithmetic Operators: Arithmetic operators define arithmetic relationships between items in an expression. The shift operators are included in this class because each left shift of one bit is equivalent to multiplication by 2 and a right shift of one bit is the same as division by 2.
- -A Twos complement (negation) - A - B Subtraction + A + B Addition
* A*B Multiplication / A/B Unsigned integer division % A%B Modulus remainder from division << A<<B Shift A left by B bits >> A>>B Shift A right by B bits
== A == B Equal != A != B Not equal < A < B Less than <= A <= B Less than or equal > A > B Greater than >= A >= B Greater than or equal
Assignment operators are special class of operators used in equations rather than in expressions. Equations assign the value of an expression to output signals. There are four assignment operators, two combinatorial and two registered. Combinatorial or immediate assignment occurs without any delay as soon as the equation is evaluated. Registered assignment occurs at the next clock pulse from the clock associated with the output. These assignment operators allow you to fully specify outputs in equations
= ON(1) Combinatorial assignment or detailed equation ?= DC(X) Combinatorial assignment or detailed equation := ON(1) Implied registered assignment ?:= DC(X) Registered assignment
Expressions are combinations of identifiers and operators that produce one result when evaluated. Any logical, arithmetic or relational operators may be used in expressions. Expressions are evaluated according to the particular operators involved. Some operators take precedence over others, and their operation is performed first. Each operator has been assigned a priority that determines the order of evaluation. Priority 1 is the highest priority, and priority 4 is the lowest. Operations of the same priority are performed from left to right. Use parentheses to change the order operations are performed. The operation in the innermost set of parentheses performed first.
address =[A8, A7, A6, A5, A4, A3, A2, A1, A0]
or
address =[A8..A0]
Operations like multiplication, division, modulus, shift are not allowed between sets.
Some examples of blocks follow:
{ this is a block }
{this is also a block, and it
spans more than one line.}
{ A = B # C;
D = [0, 1] + [l, 0];
}
"You can use comments to write observation in your program."
EXP MACRO (a, b, c, d){?a & ?b # ?c & ?d};
`This was the macro declaration'
`The call of the defined macro:'
F = EXP (x, y, z, w);
`The evaluation of the macro will be:'
F= x & y # z & w;
Some directives take arguments that determine how the directive is processed. These arguments can be actual arguments or dummy arguments preceded by a question mark.
Some of the available directives are presented below.
@ALTERNATE (Alternate operator Set)
The @ALTERNATE directive enables alternate set of operators:
| Standard | Alternate | Description |
|---|---|---|
| ! | / | NOT |
| & | * | AND |
| # | + | OR |
| $ | :+: | XOR |
| !$ | :*: | XNOR |
Standard operators still work when @ALTERNATE is in effect. Directive @STANDARD resets standard set of operators. Naturally you should switch back to standard operator set when using arithmetical operations.
@STANDARD (Standard operator Set):
The @STANDARD directive resets the operators to the ABEL standard.
@CONST (Constant Declaration)
The @CONST directive allows new constant declaration to be made in a source file outside normal (and required) declaration sections. It is used to define internal constants inside macros.
Syntax:
@CONST identifier = expression;
Example:
@CONST OK = 1;@DCSET (Don't Care Set)@CONST count = count + 1;
The @DCSET directive allows the optimization to use don't cares to optimize partially-specified logic functions. This directive overrides attributes `dc', `neg' and `pos'.
The @ONSET directive neutralize it's effect.
@IF
The @IF directive includes or excludes sections of source code based on the value of an expression. If the expression is true, the block of code is included.
Syntax:
@IF expression {block}
Example:
@IF (A>B) {C = D # E}
@INCLUDEThe @INCLUDE directive causes the contents of the specified file to be placed in the ABEL source file. The inclusion begins at the location of the directive.
Syntax: @INCLUDE `file_name.abl` (DOS path require two slashes in the string)
Example:
@INCLUDE `macros.abl`@PAGE@INCLUDE `C:\\ABEL\\INCLUDE\\CONVERT.ABL`
The @PAGE directive sends a form feed to the listing file.
@RADIX (Default Base Numbering Directive)
The @RADIX directive changes the default base. The default base before the first @RADIX directive is 10. The radix value can be an expression.
Syntax:
@ RADIX expressionExample:
A = 10; `A is 10 (decimally)'@REPEAT@RADIX 2; `changes default base to 2'
A = 10; `now A is 2 (decimally)
@RADIX 10000; `changes default base to 16'
A = 10; `now A is 16 (decimally)'
@RADIX 0A; `changes default base to 10'
A = 10; `now A is 10 (decimally) again
The @REPEAT directive causes the block to be repeated n times, where n is specified by the constant expression.
Syntax:
@REPEAT expression { block };
@IRP (Indefinite Repeat Directive)The @IRP (Indefinite Repeat) directive 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.
Syntax:
@IRP dummy_argument ( argument [,argument] . ) { block }
The ABEL have other directives, which permit other `tricks', but is not the
case to present all the directives.
@EXPR (Expression Directive)@IFB (If Blank Directive)
@IFDEF (If Defined Directive)
@IFIDEN (If Identical Directive)
@IFNB (If Not Blank Directive)
@IFNDEF (If Not Defined Directive)
@IFNIDEN (If Not Identical Directive)
A module consist of the following sections:
HeaderThe following three rules apply to module structure:Declarations
Logic Description
Test Vectors
End
The Header Section can consist of the following elements:
One or more of the following elements can be used to describe your design:
If the signal identifiers used in the test vector header were declared as active-low in the declaration section, then constant values specified in the test vectors will be inverted accordingly.
A Test Vectors Section can consist of the following elements:
The Header Section can consist of the following elements:
MODULE name (The identifier is the beginning of module statement (required))
OPTIONS (Optional element that can influence the run of the program)
TITLE `string' (Optional element that it is written in the header of JEDEC file)
The order of the identifiers must be the order presented
The device it is declared with the following syntax:
device_identifier DEVICE real_deviceThe device declaration is optional. It associates the device name used in a module with an actual programmable logic device on which designs are implemented. Device identifiers used in device declarations should be valid filenames since JEDEC files are created by appending the extension .jed to the identifier. The ending semicolon is required.
modulename DEVICE;In an included file(s) the device statement should not appear.
D1 device `P22V10' ;module UART; "Xilinx™ XEPLD design"
UART device;
ATTRIBUTE CONSTANT LIBRARY MACRO NODE PINThe PIN and NODE declarations are made to declare signals used in the design, and optionally to associate pin and/or node numbers with those signals. Actual pin and node numbers do not have to be assigned until you want to map the design into a device. Attributes can be assigned to signals within pin and node declarations with the Istype statement. Dot extensions can also be used in equations to precisely describe the signals;
Note that 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 in the process by a fitter.
Pin and Node Declarations
[!] pin_id [,[!] pin_id. . .] PIN (pin# [, pin#]] [ISTYPE ` attributes'][!] node_id [[!] node_id. .] NODE [node# [, node#]] [ISTYPE `attributes']
where pin# and node# are the pin number on the real device, and attributes a string that specifies pin attributes for devices with programmable pinsAttributes may be centered in uppercase, lowercase or mixed-case letters.
Signal Attributes:
If the signals are pine numbers of real device then this declaration will define the signal type and it is not necessary to use attributes for their definition.
signal_name, [signal_name] ISTYPE `attr'
General or Architecture Independent Attributes:
`com' The signal is combinatorial. Implies pin-to-pin equations. the signal is not registered output
`reg' A clocked memory element (generic flip-flop). Implies pin-to-pin syntax. If `invert' or `buffer' is specified, the compiler converts .D and .Q to .reg and .fb.
`neg' The input/output signal is inverted, the reduced-fixed option will optimize to this attribute. Unspecified logic is l.
`pos' The input/output signal isn't inverted, the reduced-fixed option will optimize to this attribute. Unspecified logic is 0.
Architecture Dependent Attributes
`buffer' The target architecture does not have an inverter between the associated flip-flop (if any) and the actual output pin.
`dc' Unspecified logic is don't care.
`invert' The target architecture has an inverter between the associated flip-flop (if any) and the actual output pin.
`reg_D' A clocked memory element (D-type flip-flop). Implies detailed syntax. If `invert' or `buffer' is specified, the compiler converts := equations (and .fb) to .D and .Q.
`reg_T' A clocked memory element (T-type flip-flop). Implies detailed syntax.
`reg_SR' A clocked memory element (SR-type flip-flop). Implies detailed syntax.
`reg_JK' A clocked memory element (JK-type flip-flop). Implies detailed syntax.
`reg_G' A memory element (D-type flip-flop with a gated clock). Implies detailed syntax.
`retain' Do not minimize this output. Preserve redundant product terms for the signal. Must be used with the reduce none option in PLAOpt.
`xor' The target architecture has an XOR gate, so one top-level exclusive-OR operator is retained in the design equations.
The ISTYPE statement defines attributes (characteristics) of signals for devices with programmable characteristics or when no device and pin/node number has been specified for a signal. Even when a device has been specified, using attributes makes it more likely that the design operates consistently if the device is changed later. ISTYPE can be used after pin, node or state register declarations.
Constant Declarations
Syntax:identifier [, identifier]. .= expression [, expression]. . ,
A constant is an identifier that retains a constant value throughout a module. The identifiers listed on the left side of the equals sign are assigned the values on the right side. There is a one-to-one correspondence between the identifiers and the expressions listed and there must be one expression for each identifier. The ending semicolon is required.
Symbolic State Declarations
The State register and State declarations are made to declare a symbolic state machine name, and to declare symbolic state names.
Syntax:
state_identifier [, state_identifier.] STATE state_value [,state_value, ..];
Macro Declarations
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.
Syntax:
macro_identifier MACRO [(dummy_argument[, dummy_argument])] {block};
Library Declarations
The LIBRARY statement extracts the contents of the indicated file from the abel5lib.inc library and inserts it into the ABEL-HDL source file at the location of the LIBRARY statment
Syntax:
LIBRARY `library_name'
Logic Description
The following elements can be used to describe your design:Equations Keyword which is compulsory.
Boolean Logic Equations
Truth Tables
State Descriptions
Fuses
XOR Factors
Dot extensions:
Signal dot extensions describe more precisely the behavior of a circuit in a logic description that may be targeted to a variety of different architectures.Syntax:
signal_name.dot_extension
Dot extensions can be architecture independent and can be specific for certain devices. Device specific dot extensions are used with detailed syntax and architecture independent dot extensions are used with pin-to-pin syntax.
Architecture independent extensions:
.CLK Clock input to an edge triggered flip-flop
.OE Output enable
.PIN Pin feedback
.FB Register feedback
Architecture specific dot extensions:
.D On the right side of an equation .D is combinatorial feedback from the D input to a flip-flop. On the left side of an equation is data input to the D-type flip-flop
.J J input to an JK-type flip-flop
.K K input to an JK-type flip-flop
.R R input to an SR-type flip-flop
.S S input to an SR-type flip-flop
.T T input to an T (toggle)-type flip-flop
.Q Register output feedback
.PR Register preset (synchronous or asynchronous)
.RE Register reset (synchronous or asynchronous)
.ACLR Asynchronous register reset
.ASET Asynchronous register preset
.CLR Synchronous register reset
.SET Synchronous register preset
.AR Asynchronous register reset
.AP Asynchronous register preset
.SR Synchronous register reset
.SP Synchronous register preset
.LE Active low latch enable input
.LH Active high latch enable input
.CE Clock enable input
.OE Output enable
.FC Flip-flop mode control
.COM A combinatorial 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
Note that he .CLR, .ACLR, .SET, .ASET, and .COM dot extensions are not recognized by device fitters released prior to ABEL 5.0. If you are using a fitter that does not support these reset/preset dot extensions, specify istype `invert' or istype `buffer', and the compiler converts the new dot extensions to .SP, .AP, .SR, AR and .D, respectively.
Equations
Syntax:EQUATIONS
The EQUATIONS statment defines the beginning of the section which describe the logic function of the device.
Description of Combinatorial Logic Design
The combinatorial logic can be described with Boolean logic equations, and truth tables. The description of the functional design it is introduced as was stated before with the keyword EQUATIONS and then follows the logic equations or truth tables:[WHEN condition THEN] equation;
[ELSE equation];
Example:
EQUATIONS
@ALTERNATE
A = B + C + /D;
ADDR = AB + 5;
WHEN X THEN A =B; ELSE A = C;
The syntax of truth tables:
TRUTH_TABEL ([input_signals] -> [output_signals])
[input_values] -> [output_values];
[input_values] -> [output_values];
...
Example:
TRUTH_TABELS ([bcd_code] -> [ga, gb, gc, gd])
[0] [1, 1, 1, 1];
[1] [1, 1, 1, 0];
[2] [1, 1, 0, 0];
[3] [1, 0, 0, 0];
[4] [1, 0, 0, 0];
[..];
In the example the input bcd_code and the output [ga, gb, gc, gd] are sets
Description of Sequential Logic Design
The functional description of sequential logic design can be described with Boolean logic equations, state diagrams, and transitions tables.Boolean Logic Equations
The syntax of Boolean logic equations at the sequential logic design is the same as the combinatorial logic design, but instead of the `=` operator, we use `:=` operator. In this case the left side of the equation takes the value of the evaluated right side of the equation after the clock the clock impulse.
EQUATIONS
@ALTERNATE
Q := (A + B) * /RST;
COUNT := COUNT + 1;
Truth tables
The syntax of truth tables is the same as combinatorial logic truth tables, but here we will use the operator `:>`.
Syntax:
TRUTH_TABLE ([IN_SIGNALS] :> [REG_SIGNALS] -> [OUTPUTS]
[IN_VALUES] :> [REG_VALUES] -> [OUT_VALUES;]
[IN_VALUES] :> [REG_VALUES] -> [OUT_VALUES;]
[IN_VALUES] :> [REG_VALUES] -> [OUT_VALUES;]
[...];
State Diagrams
The State Diagram section contains state descriptions that describe the logic design implemented with programmable logic. 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, and GOTO statements which determine the operation of the state machine. An alternative to describing logic with Boolean equations or truth tables is to use a state description.
Symbolic state machines (machines for which the actual state registers and state values are unspecified) require additional declarations for the symbolic state register (state_register) and state names (state) in declarations section.
Syntax:
STATE_DIAGRAM state_reg [-> state_out]
[state state_expression: [equations];
transition_statments; .]
[state state_expression: [equations];
transition_statments; .]
[state state_expression: [equations];
transition_statments; .]
where: state_reg is an identifier or set of identifiers specifying the signals that determine the current state of the machine
state_out is an identifier or set of identifiers that determine the next state of the machine (for designs with external registers)
state_expression is an expression giving the current state equation and is a valid equation that defines the state machine outputs
transition_statment is a condition (IF-THEN-ELSE, CASE or GOTO statement, optionally followed by WITH-ENDWITH transition equations) which force the transition to another statement
Transition statements
Transition statements are: IF-THEN-ELSE, CASE or GOTO, with the well known means from the high level languages. This statements can be followed optionally by the WITH-ENDWITH transition statements.
Syntax:
TRANSITION_STATMENTS next_statment WITH EQUATION;
[EQUATIONS];
ENDWITH
Examples:
EQUATIONS
@ALTERNATE
STATE_DIAGRAM [Q1, Q2]
STATE S0: O = /Q1 * /Q2;
IF A THEN S1
ELSE S0;
STATE S1: O = Q1 * /Q2;
CASE (A == 0): S0;
(A == 1): S1;
ENDCASE
STATE S2: O = /Q1 * Q2;
GOTO S3;
STATE S3
IF A==0 THEN S0 WITH O = Q1 * Q2;
ENDWITH
Not totally specified functions
In the case of not-totally specified functions we can use the directive @DCSET. The @DCSET directive allows the optimization to use don't cares to optimize partially-specified logic functions. NOTE: This directive overrides attributes 'dc', 'neg' and 'pos'. If we don't use the directive the ABEL program will translate the don't care sets with value 0Multiple Assignment
If a variable it is assigned more then on time in the left side of the equation descriptions, then the translation procedure will connect the assignments each to other with the OR function.Example:
D = A;
D = B;
D = C;
The compilation will translate the module in the following equation:
D = A + B + C;
The inverted assignment will be translated in the same way:
Example:
/D = A;
/D = B;
/D = C;
Translated:
/D = A + B + C;
which is not quite OR function. What signal is taken inverted it depends on the declaration section. The example presented above we presume the declaration of the `true' D signal declaration. From this results that the compiler will translate the equations with errors. So we advise to not use multiple assignments in your function description.
Test Vectors Section
Test vectors, which are optional, verify that the logic design functions as intended. Test vectors specify the expected operation of a logic device by defining its outputs as a function of its inputs. Design test vectors can be used in conjunction with test vectors generated by PLDtest Plus, which functionally test the programmed device.The translation procedure will write the test vectors in the .JED JEDEC file, and they will help the simulation of the JEDEC file.
Syntax:
TEST_VECTORS [note ] ([inputs] -> [outputs])
[in_values] -> [out_values];
[in_values] -> [out_values];
[in_values] -> [out_values];
.
Example:
TEST_VECTORS ([A, B] -> [O1, O2]
[0, 0] -> [ 1, 0];
[0, 1] -> [ 0, 1];
[1, 0] -> [ 0 1];
[1, 1] -> [ 1, 0];
Test vectors can be specified in multiple assignment procedure and the output value can take don't care values (.X)
TRACE
The Trace statement limits which inputs and outputs are displayed in the simulation report. The TRACE statement is used to control the display features. TRACE statements can be placed before a test vector section, or imbedded within a sequence of test vectors.
TRACE (inputs -> outputs);
Examples:
TRACE [A, B] -> [C]);
TEST_VECTORS ([A, B] -> [CAD])
[0] -> [3];
[1] -> [2];
TRACE ([A, B] -> [D]);
[2] -> [1];
[3] -> [0];
End Statement
The End statement ends the module, and is required.Syntax:
END module_name
Design considerations
Design of Sequential Circuits
Synchron Versus Asyncron Design: most of PLD Designer suggest and also the Xilinx™ data-book recommend that one should design its sequential circuits as synchron circuits instead of asyncron. Our experience said that designing with asyncron circuits could be problematical as the PLD circuits propagation time could vary by type and family and the ABEL environment do not support asyncron designs. Also could be a problem when translating an ABEL source program into Xilinx™ XNF format, when one should allow asyncron feedback, otherwise you may get translation error. Of course some simple exception can be made when the design is simple and it is recommended to design an asyncron circuit.The Mealy-Model Versus Moore-Model: Most of PLD designers recommend to use the Moore type sequential circuits, when the outputs are the register's of the PLD circuit. In the case of not registered sequential outputs one have to consider the hazards what could appear in the design.
State Codification: In ABEL HDL state codification is up to the designer, but the code optimization is function of the state codification. So the realized circuits is function of the number of variables used in the state codification. When fitting the design, one get error message because of the number of product terms used, then you should try with a better state codification using the well known methods like `neighbor terms' or to use the strategy proposed by the ABEL Handbook: try to use a better state codification where the variable which has been changed many times in the former codification to change its state as few as possible. The state codification can be made easier if you give symbolic names for each state, and the codes corresponding to this symbolic names are declared separately.
Illegal and Power-Up States: At power-up the output of a flip-flop is undefined, could be L or H. For this reason on power-up the output of the sequential registers can be fixed only by reset signal, which force the register outputs on initial state. Most of PLDs have internal Reset logic, which force the register's output on initial state, so when design you should take this considerations. Can happen that the sequential circuit have illegal states which are not defined in the state specification. This illegal combinations could be source of errors and bugs after power-up, when the output of the sequential circuit appear such an illegal state. So better you should consider this states when designing and to guide this illegal states in legal states after one or two clock cycles.
Architecture Independent versus Detailed Description
The Device keyword is an optional feature in ABEL-HDL, so you do not need to specify a particular PLD architecture in your ABEL-HDL source file. You can also omit pin numbers from signal declarations. When you do not specify a device or pin numbers, you need to specify pin-to-pin attributes about declared signals, since the ABEL-HDL compiler cannot imply signal attributes from pre-determined device attributes. If you do not specify signal attributes or other detailed information (such as the dot extensions, which are described later), your design might not operate consistently if you later transfer it to a different target device.The requirement for signal attributes does not mean that a complex design must always be specified with a particular device in mind. The attributes and dot extensions provided in ABEL-HDL help you to redefine your design to work consistently when moving from one class of device architecture to another.
By using attributes and dot extensions carefully, you can avoid specifying a particular device type, and instead target your design to a more general class of device architectures.
Signal Attributes Signal Attributes: remove ambiguities that occur when no specific device architecture is declared. If your design does not use device-related attributes (either implied by a DEVICE statement or expressed in an ISTYPE statement), it may not operate the same way when targeted to different device architectures.
Signal Dot Extensions like attributes, are a way you can more precisely describe the behavior of a circuit that may be targeted to different architectures. Dot extensions are applied to signals, and remove the ambiguities in equations.
ABEL HDL assignment operator can be used when writing high-level equations. The = operator specifies a combinatorial assignment where the design is written with only the circuit's inputs and outputs in mind.
The := operator specifies a registered assignment, where you must consider the internal circuit elements (such as output inverters, resets and sets) related to the flip-flops.
The := implies a memory element is associated with the output defined by the equation. For example, the equation
QA := /QA + PRESET;
implies that QA will hold its current value until the memory element associated with that signal is clocked (or unlatched, depending on the register type).
This equation is a pin-to-pin description of the output signal QA. The equation describes the signal's behavior in terms of desired output pin values for various input conditions. Pin-to-pin descriptions are useful when describing a circuit that is completely architecture-independent. Language elements that are useful for pin-to-pin descriptions are the := operator, and the .CLK, .OE, .FB, .CLR, .ACLR, .SET, .ASET and .COM dot extensions. These dot extensions help to resolve circuit ambiguities when describing architecture-independent circuits.
Resolving Ambiguities In the equation above (QA := /QA + PRESET;), there is an ambiguous feedback condition. The signal QA appears on the right side of the equation, but there is no indication of whether that fed-back signal should originate at the register, should come directly from the combinatorial logic that forms the input to the register, or should come from the I/O pin associated with QA. There is also no indication of what type of register should be used (although register synthesis algorithms could, theoretically, map this equation into virtually any register type). The equation could be more completely specified by writing:
QA.CLK = CLOCK; `Register clocked from input'
QA = /QA.FB + PRESET; `Register feedback'
This set of equations describes the circuit completely, and specifies enough information that the circuit will operate identically in virtually any PLD in which it can be fit. The feedback path is specified to be from the register itself, and the .CLK equation specifies that the memory element is clocked, rather than latched.
Detailed Circuit Descriptions: In contrast to a pin-to-pin description, the same circuit can be specified in a detailed form of design description, as follows:
QA.CLK = CLOCK; `Register clocked from input
QA.D = /QA.Q + PRESET; `D-type flip-flop used for register
In this form of the design, specifying the D input to a D-type flip-flop and specifying feedback directly from the register restricts the device architectures the design can be implemented in. Furthermore, the equations only describe the inputs to and feedback from the flip-flop, and do not provide any information regarding the configuration of the actual output pin. This means the design will operate quite differently when implemented in a device with inverted outputs (like P16R4 PAL device, for example), versus in a device with non-inverting outputs (such as an EP600).
To maintain the correct pin behavior using detailed equations, one additional language element, a 'buffer' (or its complement, 'invert') attribute, is required. The 'buffer' attribute ensures that the final implementation in a device has no inversion between the specified D-type flip-flop and the output pin associated with QA. For example, add the following to the declarations section:
QA pin istype 'buffer';
One way to understand the difference between pin-to-pin and detailed. description methods is to think of detailed descriptions as macrocell
Macrocells Specifications: A macrocell is a block of circuitry normally (but not always) associated with a PLD's I/O pin. Figure 1 illustrates a typical macrocell associated with signal QA:
Figure 1 Detail Macrocell
Detailed descriptions are written for the various input ports (shown in Figure 1 with dot extension labels) of the macrocell. Note that the macrocell shown features a configurable inversion between the Q output of the flip-flop and the output pin labeled QA. If this inverter is used (or if a device is selected that features a fixed inversion), then the behavior seen on the QA output pin will be inverted from the logic applied to or observed on the various macrocell ports, including the feedback port QA.Q.
Pin-to-pin descriptions, on the other hand, allow you to describe your circuit in terms of the behavior expected on an actual output pin, regardless of the architecture of the underlying macrocell. Figure 2 illustrates the pin-to-pin concept:
Figure 2. Pin-to-pin Macrocell
When pin-to-pin descriptions are written in ABEL-HDL, the "generic macrocell" shown above is synthesized from whatever type of macrocell actually exists in the target device.
Two equivalent module descriptions, one pin-to-pin and one detailed, are shown below for comparison:
module QA_1
title `Pin-to-pin description'
declarations
qa pin istype 'reg';
clock, preset pin;
equations
qa.clk = clock;
qa = /qa.fb + preset;
test vectors ([clock, preset] -> QA)
[ .c. , 1 ] -> 1;
[. c. , 0 ] -> 0;
[ .c. , 0 ] -> 1;
[ . c. , 0 ] -> 0;
[ .c. , 1 ] -> 1;
[ .c. , 1 ] -> 1;
end QA_1
module QA_2
title `Detailed description'
declarations
clock, preset pin;
equations
qa.clk = clock;
qa.d = /qa.q + preset;
test vectors ([clock, preset]) -> qa)
[ .c. , 1 ] -> 1;
[ . c. , 0 ] -> 0;
[ .c. , 0 ] -> 1;
[ .c. , 0 ] -> 0;
[ .c. , 1 ] -> 1;
[ .c. , 1 ] -> 1;
end QA_2
The pin-to-pin description shown if the `generic macrocell' is synthesized from whatever type of macrocell actually exists in the target device.
The first description can be targeted into virtually any PLD (if register synthesis and device fitting features are available) while the second one can be targeted only to devices featuring D-type flip-flops and non-inverting outputs.
Using Dot Extensions: The source of feedback is normally set by the architecture of the target PLD. If you don't specify a specific feedback path, the design may operate differently in different device types. Specifying feedback paths with the .FB, .Q or .PIN dot extensions, you can eliminate architectural ambiguities. Specifying feedback paths also allows you to use the architecture-independent simulation.
The following rules should be kept in mind when you are using feedback:
To be architecture-independent, you must think of your design in terms of its pin-to-pin behavior rather than in terms of specific device features (such as flip-flop configurations or output inversions).
The following simple ABEL-HDL design describes a simple one-bit synchronous circuit. The design description uses architecture-independent dot extensions to describe the circuit in terms of its behavior as observed on the output pin of the PLD device. Since this design is architecture-independent, it will operate the same (disregarding initial powerup state) regardless of the type of device specified.
module pin2pin
title `Pin-to-Pin Architecture independent One Bit Synchronous Circuit' declarations
clk, toggle, ena pin 1, 2; 11;
qout pin 19 istype 'reg';
c = .c.;
z = .z.;
equations
@alternate
qout =. /qout.fb & toggle;
qout.clk = clk;
qout.oe = /ena;
test vectors([clk, ena, toggle] -> [qout]
[c, 0, 0 ] -> 0;
[c, 0, 1] -> 1;
[c, 0, 1] -> 0;
[c, 0, 1] -> 1;
[c, 0, 1] -> 0;
[c, 1, 1] -> z;
[0, 0, 1] -> 1;
[c, 1, 1] -> z;
[0, 0, 1] -> 0;
end
If this circuit is implemented in a simple P16R8 PAL device (either by adding a device declaration statement or by specifying the P16R8 in the FuseAsm process), the result would be a circuit like the one illustrated in Figure 3. This circuit is somewhat different from the specified circuit; since the P16R8 features inverted outputs, the design equation has been automatically modified by FuseAsm to fit the P16R8's architecture.
Figure 3. Architecture Independent Implementation of Pin2Pin program in a P16R8
A single logic function may be expressed with many different equations. For example, all three equations below for FX are equivalent.
F1 = (A & B);
/F2 = /(A & B);
/F3 = /A + /B;
In the example above, equation F3 uses two product terms, while equation F1 requires only one. This logic function will use fewer product terms in a non-inverting device such as the P10L8 than in an inverting device such as the P10L8. The logic function performed from input pins to output pins will be the same for both polarities.
Not all logic functions are best optimized to positive polarity. In the following example, the inverted form of FX, equation F3, uses fewer product terms than equation F2.
F1 = (A + B) * (C + D);
F2 = A * C + A * D + B * C + B * D;
/F3 = /A * /B + /C * /D; `equation resulted from F1 by negation
Programmable polarity devices are popular because they can provide a mix of non-inverting and inverting outputs to achieve the best fit.
In ABEL-HDL, the polarity of the design equations and target device (in the case of programmable polarity devices) can be controlled in two ways:
The `pos' and `neg' attributes specify optimization for the polarity specified:
An optional method for specifying the desired state of a programmable polarity output is to use the 'invert' or 'buffer' attributes. These attributes ensure that an inverter gate either does or doesn't exist between the output of a flip-flop and its corresponding output pin.
When you use the 'invert' and 'buffer' attributes, you can still use automatic polarity selection if the target architecture features programmable inverters located before the associated flip-flop.
These attributes are particularly useful for devices such as the P22V10, where the reset and preset behavior is affected by the programmable inverter.
The polarity of devices that feature a fixed inverter in this location and a programmable inverter before the register cannot be specified using 'invert' and 'buffer'.
y = F1(Xi, u);
u = F2(Xj);
With logical decomposition introducing simpler logical equations with fewer number of product terms the function can be implemented in simpler PLDs. In the above example by declaring the variable y, u as PIN/NODE the number of product terms in each logical function decrease dramatically and the function can be implemented.
The reason why we have to introduce logical decomposition is that the number of AND functions what are OR-ed together in simple PLD structures is 8 and if we do not consider this than in the translation process may occur errors.
The disadvantage of the decomposition is that you loose output pins as the decomposition level increase and with the increasing decomposition the signal time response will increase.
ABEL-HDL contains language elements that allow you to take advantage of features specific to particular FPGAs. For example, if a device directly supports clock enables, you can specify clock enables in your ABEL-HDL source file equations.
The following design strategies are helpful when designing for FPGAs.
Declaring Signals: The first step in creating a logic module for an FPGA is to declare the signals in your design. In ABEL-HDL, you do this with pin and node statements.
Figure 4 Hypothetical state machine as a Functional Block
The CLOCK, RESET, input, and output signals must connect with circuitry outside the functional block, so they are declared as pins. The state bits are not used outside the functional block, so they are declared as nodes:
declarations
CLOCK, RESET PIN;
I0, l1, I2, I3 PIN;
01, 02 Pin;
S7, S6, S5, S4, S3, S2, S1 NODE;
Using Intermediate Signals: An intermediate signal is a combinatorial signal that is declared as a node and used as a component of other more complex signals in a design. Intermediate signals minimize logic by forcing it to be factored. Creating intermediate signals in an ABEL-HDL logic description has the following benefits:
Figure 5 shows a schematic of combinatorial logic. Signals A, B, C, D, and E are inputs; X and Y are outputs. There are no intermediate signals; every declared signal is an input or output to the sub-circuit. The following ABEL sequence shows the ABEL-HDL declarations and equations that would generate the logic shown in Figure 5.
module no_intermediate
declarations
A, B, C, D, E pin;
X, Y pin;
equations
@alternate
X = A * B * C + B :+: C;
Y = A * D + A * E) + A * B * C);
end no_intermediate
Figure 5 Schematic without intermediate signals
Figure 6 Schematic with Intermediate Signals
Figure 6 shows the same logic using an intermediate signal, M, which is declared as a node and named, but is used only inside the sub-circuit as a component of other, more complex signals. The declarations and equations that would generate the logic are the following:
module intermediate
declarations
A, B, C, D, E pin;
X, Y pin;
M node;
equations
@alternate
"intermediate signal equations
M = A * B * C;
X = M + B :+: C;
Y = A * D + A * E + M;
end intermediate
Both design descriptions are functionally the same. Without the intermediate signal, ABEL generates the AND gate associated with (A * B * C) twice, and the device fitter must filter out the common term. With the intermediate signal, this sub-signal is generated only once as the intermediate signal, M, and the fitter has less to do.
Using intermediate signals in a large design targeted for a complex PLD or FPGA can save fitter optimization effort and time. It also makes the design description easier to interpret. For large designs, using intermediate signals can be essential. An expression such as
IF (input == code_1)....
generates a product term (AND gate). If the input is 8 bits wide, so is the AND gate. If the expression above is used 10 times, the amount of logic generated will cause long run times during compilation and fitting, or may cause fitting to fail.
If you write the expression as an intermediate equation,
code_1_found node;
equations
code_1_found = (input == code_1);
you can use the intermediate signal many times without creating an excessive amount of circuitry.
IF code_1_found. . .
An alternative method of creating intermediate equations is to use the @CARRY directive. This directive causes comparators and adders to be generated using intermediate equations for carry logic, resulting in an efficient multi-level implementation.
In general, you should design for multi-level FPGAs in a multi-level fashion, using intermediate signals as much as possible. An FPGA device fitter is capable of transforming two-level PLD designs into multi-level FPGA designs, but it takes a lot of time and sometimes fails. Rewriting your PLD designs to reflect the multi-level nature of the FPGA architecture often reduces the time for fitting, increases the chance of a fit, and simplifies your design descriptions.
Simulate Equation (plasim): Makes a functional simulation of the logical description conform of the test vectors given in the HDL file.
Optimize (PLAOpt): Makes a logical minimization
PartMap (FuseAsm): The FuseAsm generate the JEDEC file ready to be programmed in the PLD device and also generate a document file. Before this operation you have to define the PLD device, if this is not made, then the Fitter (fit) makes a device for you.
Simulate JEDEC (jedsim): Simulate the JEDEC file, corresponding to the PLD device structure and the given test vectors.
Starting from DOS - type:
abel4
You will run in this way the DataIO easyABEL environment. In this way you can edit, test your programs and prepare your homework and then in the laboratory you can implement your project in the Xilinx™ Demonstration Board XC3000 series or XC4000 series depending on your project.
Starting from Foundation Project Manager:
This possibility is accessible only in the departments laboratories, and under Windows™ you have to do the following steps:
Help is available by pressing the ALT+H or clicking with the mouse on the menu HELP command.