UM0045 Reference manual
PSDabel-HDLTM
Introduction
PSDabel-HDL is a hierarchical logic description language. PSDabel-HDL design descriptions are contained in an ASCII text file in the PSDabel Hardware Description Language, PSDabelHDL. The requirements for PSDabel-HDL are described in the following chapters.
Section 1: Language structure-- provides the basic syntax and structure of a PSDabelHDL design description. For information on specific elements, refer to Section 4: Language reference Section 2: Design considerations-- discusses issues to consider when creating an PSDabel-HDL module, such as architecture-independent language features, active low declarations, flip-flop equations, feedback considerations, and polarity control. Section 3: Source file examples-- contains PSDabel-HDL module examples. These examples are representative of programmable logic applications and illustrate significant PSDabel features. They also help you create your own source files. Section 4: Language reference-- gives detailed information about PSDabel-HDL language elements. This chapter assumes you are familiar with the basic syntax discussed in Section 1: Language structure
January 2007
Rev 3
1/162
1
UM0045
Contents
1 Language structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 1.2 1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Introduction to PSDabel-HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Basic syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.3.9 Suppor ted ASCII characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Operators, expressions, and equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.10 Arguments and argument substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4 1.5
Basic structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.5.1 1.5.2 1.5.3 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6
Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 1.6.6 1.6.7 1.6.8 Declarations keyword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Device declaration (not supported) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Hierarchy declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Signal declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Constant declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Symbolic state declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Macro declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Librar y declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7
Logic description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7.1 1.7.2 1.7.3 1.7.4 Dot extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Truth tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 State descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1/162
UM0045
1.7.5 1.7.6 Fuse declarations (not supported) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 XOR factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.8
Test vectors section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.8.1 1.8.2 Test vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Trace statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.9 1.10
End statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Other elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.10.1 Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2
Design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1 Hierarchy in PSDabel-HDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.1 2.1.2 2.1.3 Instantiating a lower-level module in an PSDabel-HDL source . . . . . . . . . . . 38 Hierarchy and retargeting and fitting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Hierarchy and test vectors (PLD JEDEC simulation - not supported feature) 40
2.2 2.3
Node collapsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.2.1 Selective collapsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Pin-to-pin language features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1 2.3.2 2.3.3 Device-independence Vs. architecture-independence . . . . . . . . . . . . . . . . . 41 Signal attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Signal dot extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4
Pin-to-pin vs. detailed descriptions for registered designs 42
2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 Using := for pin-to-pin descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Detailed circuit descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Examples of pin-to-pin and detailed descriptions . . . . . . . . . . . . . . . . . . . . . 44 Detailed module with inverted outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 When to use detailed descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Using := for alternative flip-flop types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.5 2.6 2.7 2.8
Using active-low declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Polarity control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6.1 Polarity control with istype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Flip-flop equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Feedback considerations -- using dot extensions . . . . . . . . . . . . . . . . . . . . 50
2.8.1 2.8.2 Dot extensions and architecture-independence . . . . . . . . . . . . . . . . . . . . . . 50 Dot extensions and detail design descriptions . . . . . . . . . . . . . . . . . . . . . . . 52
2.9
Using Don't Care optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2/162
UM0045 2.10 Exclusive OR equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.10.1 Optimizing XOR devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.10.2 Using XOR operators in equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.10.3 Using implied XORs in equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.10.4 Using XORs for flip-flop emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.11
State Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.11.1 Use Identifiers Rather Than Numbers for States . . . . . . . . . . . . . . . . . . . . . . 58 2.11.2 Powerup register states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 2.11.3 Unsatisfied transition conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.11.4 Precautions for using don't care optimization . . . . . . . . . . . . . . . . . . . . . . . . 60 2.11.5 Number adjacent states for one-bit change . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.11.6 Use state register outputs to identify states . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.11.7 Using symbolic state descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.12
Using complement arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3
Source file examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1 Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 Memor y address decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 12-to-4 multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4-Bit universal counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Bidirectional three-state buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4-Bit comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2 3.3 3.4 3.5 3.6
Truth table examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.2.1 Seven-segment display decoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
State diagram examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.3.1 Three-state sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Combined logic descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Hierarchy examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 PSDabel-HDL projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.6.1 Lower-level sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4
Language reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.1 4.2 4.3 . ext -- dot extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.1.1 Detailed design dot extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
= -- constant declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 attr' -- Signal attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3/162
UM0045 4.4 @directive -- Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 4.4.9 @Alternate -- alternate operator set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 @Carr y -- Maximum bit-width for arithmetic functions . . . . . . . . . . . . . . . . 114 @Const -- Constant declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 @Dcset -- Don't Care set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 @Dcstate -- State output Don't Cares . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 @Exit -- Exit directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 @Expr -- Expression directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 @If -- If directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 @Ifb -- If blank directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.4.10 @Ifdef -- If defined directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.4.11 @Ifiden -- If identical directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.4.12 @Ifnb -- If not blank directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.4.13 @Ifndef -- If not defined directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 4.4.14 @Ifniden -- If not identical directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.4.15 @Include -- Include directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.4.16 @Ir p -- Indefinite repeat directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.4.17 @Ir pc -- Indefinite repeat, character directive . . . . . . . . . . . . . . . . . . . . . . 120 4.4.18 @Message -- Message directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.19 @Onset -- No Don't Care's . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.20 @Page -- Page directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.21 @Radix -- Default base numbering directive . . . . . . . . . . . . . . . . . . . . . . . 121 4.4.22 @Repeat -- Repeat directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.4.23 @Setsize -- Set indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 4.4.24 @Standard -- Standard operators directive . . . . . . . . . . . . . . . . . . . . . . . . 123
4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15
Async_reset and Sync_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Constant declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Device (not supported) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Equations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Functional_block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Fuses (not supported) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Goto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 If-Then-Else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4/162
UM0045 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34 4.35 4.36 Interface (top-level) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Interface (lower-level) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Istype _ Attribute declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Librar y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 Proper ty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 State (declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 State (in State_diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 State_diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 State_register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Sync_reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Test_vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Truth_table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 When-Then-Else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 With . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 XOR_Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5/162
UM0045
1 Language structure
1
Language structure
This chapter provides the basic syntax and structure of a design description in PSDabel-HDL. For information on specific elements, refer to Section 4: Language reference. You can write a source file using any editor that produces ASCII files.
1.1
Summary
This chapter contains the following sections: Introduction to PSDabel-HDL and to the idea of architecture-independent and architecturespecific logic descriptions. Basic syntax of a source file, including
Suppor ted ASCII characters Identifiers and keywords Constants Blocks Comments Numbers Str ings Operators, expressions and equations Logical operators Arithmetic operators Relational operators Assignment operators Expressions Equations
Sets and set operation Arguments and argument substitution Header Module Interface (lower-level) T itle Declarations keyword Interface and Functional_block declarations Constant declarations Signal declarations Device declarations (not supported) Equations
Basic Structure of a design description, including
Declarations
Logic description
6/162
1 Language structure
UM0045
Truth tables State descriptions Fuses (not supported) XOR factors
Test vectors (for PLD simulation only) End
1.2
Introduction to PSDabel-HDL
PSDabel-HDL is a hardware description language that supports a variety of behavioral input forms, including high-level equations, state diagrams, and truth tables. The PSDabel-HDL compiler functionally verifies PSDabel-HDL designs through simulation. The compiler then implements the designs in PLDs or FPGAs. PSDabel-HDL designs can also be transferred to other design environments through standard-format design transfer files. You can enter designs in PSDabel-HDL and verify them with little or no concern for the architecture of the target device. Architecture-independent design descriptions (those that do not include device declarations and pin number declarations) require more comprehensive descriptions than their architecturespecific counterparts. Assumptions that can be made when a particular device is specified are not possible when no device is specified. See the section "Architecture-independent Language Features" in Section 2: Design considerations.
1.3
Basic syntax
Each line in an PSDabel-HDL source file must conform to the following syntax rules and restrictions:
A line can be up to 150 characters long. Lines are ended by a line feed (hex 0A), by a vertical tab (hex 0B), or by a form feed (hex 0C). Carriage returns in a line are ignored, so common end-of-line sequences, such as carriage return/line feed, are interpreted as line feeds. In most cases, you can end a line by pressing Return. Keywords, identifiers, and numbers must be separated by at least one space. Exceptions to this rule are lists of identifiers separated by commas, expressions where identifiers or numbers are separated by operators, or where parentheses provide the separation. Neither spaces nor periods can be embedded in the middle of keywords, numbers, operators, or identifiers. Spaces can appear in strings, comments, blocks, and actual arguments. For example, if the keyword MODULE is entered as MOD ULE, it is interpreted as two identifiers, MOD and ULE. Similarly, if you enter 102 05 (instead of 10205), it is interpreted as two numbers, 102 and 5. Keywords can be uppercase, lowercase or mixed-case. Identifiers (user-supplied names and labels) can be uppercase, lowercase or mixed-case, but are case sensitive: the identifier, output, typed in all lowercase letters, is not the same as the identifier, Output.
7/162
UM0045
1 Language structure
1.3.1
Supported ASCII characters
All uppercase and lowercase alphabetic characters and most other characters on common keyboards are supported. Valid characters are listed or shown below.
a - z (lowercase alphabet) A - Z (uppercase alphabet) 0 - 9 (digits) ! @#$?+&*()_=+[]{} `\|,<>. ; / :' ^% "
1.3.2
Identifiers
Identifiers are names that identify the following items:
devices device pins or nodes functional blocks sets input or output signals constants macros dummy arguments
All of these items are discussed later in this chapter. The rules and restrictions for identifiers are the same regardless of what the identifier describes. The rules governing identifiers are listed below:
Identifiers can be up to 31 characters. Longer names are flagged as an error. Identifiers must begin with an alphabetic character or with an underscore. Other than the first character, identifiers can contain upper- and lowercase characters, digits, tildes (~), and underscores. You cannot use spaces in an identifier. Use underscores or uppercase letters to separate words. Except for Reserved Identifiers (Keywords), identifiers are case sensitive: uppercase letters and lowercase letters are not the same. You cannot use periods in an identifier, except with a supported dot extension.
Some supported identifiers are listed below:
HELLO hello _K5input P_h This_is_a_long_identifier AnotherLongIdentifier
Some unsupported identifiers are listed below:
8/162
1 Language structure
UM0045
7_ $4 HEL.LO b6 kj
Does not begin with a letter or underscore Does not begin with a letter or underscore Contains a period (.LO is not a valid dot extension) Contains a space
The last of these identifiers is interpreted as two identifiers, b6 and kj.
Reserved identifiers (keywords)
The keywords listed below are reserved identifiers. Keywords cannot be used to name devices, pins, nodes, constants, sets, macros, or signals. If a keyword is used in the wrong context, an error is flagged.
async_reset case declarations device else enable (obsolete) end endcase endwith equations external flag (obsolete) functional_block fuses goto if in interface istype library macro module node options pin proper ty state state_diagram state_register sync_reset test_vectors then title trace truth_table when with
Choosing identifiers
Choosing the right identifiers can make a source file easy to read and understand. The following suggestions can help make your logic descriptions self-explanatory, eliminating the need for extensive documentation.
Choose identifiers that match their function. For example, the pin you're going to use as the carry-in on an adder could be named Carry_In. For a simple OR gate, the two input pins might be given the identifiers IN1 and IN2, and the output might be named OR. Avoid large numbers of similar identifiers. For example, do not name the outputs of a 16 bit adder: ADDER_OUTPUT_BIT_1 ADDER_OUTPUT_BIT_2 and so on. Use underscores or mixed-case characters to separate words in your identifier.
THIS_IS_AN_IDENTIFIER ThisIsAnIdentifier
is much easier to read than
THISISANIDENTIFIER
1.3.3
Constants
You can use constant values in assignment statements, truth tables, and test vectors. You can assign a constant to an identifier, and then use the identifier to specify that value throughout a module (see "Section 1.6: Declarations" and "Section 1.5.1: Module" later in this chapter). Constant values can be either numeric or one of the non-numeric special constant values. The special constant values are listed in Table 1.
9/162
UM0045
Table 1.
Constant .C. .D .F. .K. .P. .Svn. .U. .X. .Z.
1 Language structure
Special constants
Description Clocked input (low-high-low transition) Clock down edge (high-low transition) Floating input or output signal Clocked input (high-low-high transition) Register preload n = 2 through 9. Drive the input to super voltage 2 through 9. Clock up edge (low-high transition) Don't care condition. Tristate value
When you use a special constant, it must be entered as shown in Table 1. Without the periods, .C. is an identifier named C. You can enter special constants in upper- or lowercase.
1.3.4
Blocks
Blocks are sections of text enclosed in braces, { and }. Blocks are used in equations, state diagrams, macros, and directives. The text in a block can be on one line or it can span many lines. Some examples of blocks are shown below:
{ this is a block } { this is also a block, and it spans more than one line. } { A = B # C; D = [0, 1] + [1, 0]; }
Blocks can be nested within other blocks, as shown below, where the block { D = A } is nested within a larger block:
{ A = B $ C; { D = A; } E = C;
}
Blocks and nested blocks can be useful in macros and when used with directives. (See "Section 1.6.7: Macro declarations" later in this chapter and in Section 4: Language reference) If you need a brace as a character in a block, precede it with a backslash. For example, to specify a block containing the characters { }, write
{ \{ \} }
Using blocks in logic descriptions
Using blocks can simplify the description of output logic in equations and state diagrams and allow more-complex functions than possible without blocks. Blocks can improve the readability of your design. Blocks are supported anywhere a single equation is supported. You can use blocks in simple equations, When-then-else, If-then-else, Case, and With statements When you use equation blocks within a conditional expression (such as If-then, Case, or When-then), the logic functions are logically ANDed with the conditional expression.
10/162
1 Language structure
UM0045
Blocks in equations
The following expressions, written without blocks, are limited by the inability to specify more than one output in a When-then expression without using set notation: Without Blocks:
WHEN ELSE WHEN WHEN ELSE WHEN (Mode (Mode (Mode (Mode == == == == S_Data) T_Data) S_Data) T_Data) THEN THEN THEN THEN Out_data Out_data S_Valid T_Valid := := := := S_in; T_in; 1; 1;
With blocks (delimited with braces { } ), the syntax above can be simplified. The logic specified for Out_data is logically ANDed with the WHEN clause: With Blocks:
WHEN ELSE WHEN (Mode == S_Data) THEN { Out_data := S_in; S_Valid := 1; } (Mode == T_Data) THEN { Out_data := T_in; T_Valid := 1;
}
Blocks in state diagrams
Blocks also provide a simpler way to write state diagram output equations. For example, the following two state transition statements are equivalent: Without Blocks:
IF (Hold) THEN State1 WITH o1 := o1.fb; ENDWITH ELSE State2; o2 := o2.fb;
With Blocks:
IF (Hold) THEN State1 WITH {o1 := o1.fb; ELSE State2; o2 := o2.fb;}
Using blocks for state diagram transitions
Blocks can be used to nest IF-THEN and IF-THEN-ELSE statements in state diagram descriptions, simplifying the description of complex transition logic.
Blocks for transition logic
Without blocks:
IF (Hold & !Reset) THEN State1; If (Hold & Error) THEN State2; If (!Hold) THEN State3;
With blocks:
If (Hold) THEN { IF (!Reset) THEN State1; IF (Error) THEN State2; } ELSE State3;
1.3.5
Comments
Comments are another way to make a source file easy to understand. Comments explain what is not readily apparent from the source code itself, and do not affect the code. Comments cannot be embedded within keywords.
11/162
UM0045
You can enter comments two ways:
1 Language structure
Begin with a double quotation mark (") and end with either another double quotation mark or the end of line. Begin with a double forward slash (//) and end with the end of the line. This is useful for commenting out lines of PSDabel source that contain quote-delineated comments.
Examples of comments are shown in boldface below:
MODULE Basic_Logic; "gives the module a name TITLE 'PSDabel-HDL design example: simple gates'; "title "declaration section" IC4 device 'P10L8'; "declare IC4 to be a P10L8 IC5 "decoder PAL" device 'P10H8'; //IC5 "decoder PAL" device 'p10h8';
The information inside single quotation marks (apostrophes) are required strings, not comments, and are part of the statement.
1.3.6
Numbers
All numeric operations in PSDabel-HDL are performed to 128-bit accuracy, which means the supported numeric values are in the range 0 to 2128 minus 1. Numbers are represented in any of five forms. The four most common forms represent numbers in different bases. The fifth form uses alphabetic characters to represent a numeric value. When one of the four bases other than the default base is chosen to represent a number, the base used is indicated by a symbol preceding the number. Table 2 lists the four bases supported by PSDabel-HDL and their accompanying symbols. The base symbols can be upper- or lowercase Table 2.
Base Name Binar y Octal Decimal Hexadecimal
Number Representation in Different Bases
Base 2 8 10 16 Symbol ^b ^o ^d (default) ^h
When a number is specified and is not preceded by a base symbol, it is assumed to be in the default base numbering system. The normal default base is base 10. Therefore, numbers are represented in decimal form unless they are preceded by a symbol indicating that another base is to be used. You can change the default number base. See @Radix -- Default base numbering directive in Section 4: Language reference for more information. Examples of supported number specifications are shown below. The default base is base ten (decimal).
Specification T4 = 75 ^h75 ^b101 ^o17 ^h0F Decimal Value 75 117 5 15 15
12/162
1 Language structure
UM0045
Note:
The carat (^) is a keyboard character. It is not part of a control-key sequence. You can also specify numbers by strings of one or more alphabetic characters, using the numeric ASCII code of the letter as the value. For example, the character "a" is decimal 97 and hexadecimal 61 in ASCII coding. The decimal value 97 is used if "a" is specified as a number. Sequences of alphabetic characters are first converted to their binary ASCII values and then concatenated to form numbers. Some examples are shown below:
Specification a b abc Hex Value ^h61 ^h62 ^h616263 Decimal Value 97 98 6382203
1.3.7
Strings
Strings are series of ASCII characters, including spaces, enclosed by apostrophes. Strings are used in the TITLE, MODULE, and OPTIONS statements, and in pin, node, and attribute declarations, as shown below:
'Hello' ' Text with a space in front' '' 'The preceding line is an empty string' 'Punctuation? is allowed !!'
You can include a single quote in a string by preceding the quote with a backslash, (\).
'It\'s easy to use PSDabel-HDL'
You can include backslashes in a string by using two of them in succession.
'He\\she can use backslashes in a string'
Note:
The grave accent (`) is also accepted as a string delimiter and can be used interchangeably with the apostrophe (').
1.3.8
Operators, expressions, and equations
Items such as constants and signal names can be brought together in expressions. Expressions combine, compare, or perform operations on the items they include to produce a single result. The operations to be performed (addition and logical AND are two examples) are indicated by operators within the expression. You can use the set operator (..) in expressions and equations. PSDabel-HDL operators are divided into four basic types: logical, arithmetic, relational, and assignment. Each of these types are discussed separately below, followed by a description of how they are combined into expressions. Following the descriptions is a summary of all the operators and the rules governing them and an explanation of how equations use expressions.
Logical operators
Logical operators are used in expressions. PSDabel-HDL incorporates the standard logical operators listed in Table 3. Logical operations are performed bit by bit. For alternate operators, refer to the @Alternate -- alternate operator set in Section 4: Language reference.
13/162
UM0045
Table 3.
Operator ! & # $ !$
1 Language structure
Logical Operators
Description NOT: ones complement AND OR XOR: exclusive OR 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. Table 4 lists the arithmetic operators. Table 4.
Operator + Not Supported for Sets: * / % << >> A*B A/B A%B A<>B multiplication unsigned integer division modulus: remainder from / shift A left by B bits shift A right by B bits
Arithmetic operators
Example -A A-B A+B Description twos complement (negation) subtraction addition
Note:
A minus sign has a different significance, depending on its usage. When used with one operand, it indicates that the twos complement of the operand is to be formed. When the minus sign is found between two operands, the twos complements of the second operand are added to the first. Division is unsigned integer division: the result of division is a positive integer. Use the modulus operator (%) to get the remainder of a division. The shift operators perform logical unsigned shifts. Zeros are shifted in from the left during right shifts and in from the right during left shifts.
Relational operators
Relational operators compare two items in an expression. Expressions formed with relational operators produce a Boolean true or false value. Table 5 lists the relational operators. Table 5.
Operator == != < <=
Relational operators
Description equal not equal less than less than or equal
14/162
1 Language structure
UM0045
Description greater than greater than or equal
Operator > >=
All relational operations are unsigned. For example, the expression !0 > 4 is true since the complement of !0 is 1111 (assuming 4 bits of data), which is 15 in unsigned binary, and 15 is greater than 4. In this example, a four-bit representation was assumed; in actual use, !0, the complement of 0, is 128 bits all set to 1. Some examples of relational operators in expressions are listed below:
Expression 2 == 3 2 != 3 3<5 -1 > 2 Value False True True True False
The logical values true and false are represented by numbers. Logical true is -1 in twos complement, so all 128 bits are set to 1. Logical false is 0 in twos complement, so all 128 bits are set to 0. This means that an expression producing a true or false value (a relational expression) can be used anywhere a number or numeric expression could be used and -1 or 0 will be substituted in the expression depending on the logical result. For example,
A = D $ (B == C);
means that
A equals the complement of D if B equals C A equals D if B does not equal C.
When using relational operators, always use parentheses to ensure the expression is evaluated in the order you expect. The logical operators & and # have a higher priority than the relational operators (see the priority table later in this chapter). The following equation
Select = [A15..A0] == ^hD000 # [A15..A0] == ^h1000;
needs parentheses to obtain the desired result:
Select = ([A15..A0] == ^hD000) # ([A15..A0] == ^h1000);
Without the parentheses, the equation would have the default grouping
Select = [A15..A0] == (^hD000 # [A15..A0]) == ^h1000;
which is not the intended equation.
Assignment operators
Assignment operators are used in equations rather than in expressions. Equations assign the value of an expression to output signals. For more information, see the "Section 1.7.2: Equations" later in this chapter.
15/162
UM0045
1 Language structure
There are four assignment operators (two combinational and two registered). Combinational 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. Refer to Section 2: Design considerations Table 6 shows the assignment operators. Table 6.
Operator = := ?= ?:=
Assignment operators
Set ON (1) ON (1) DC (X) DC (X) Description Combinational or detailed assignment Implied registered assignment Combinational or detailed assignment Implied registered assignment
Caution:
The := and ?:= assignment operators are used only when writing pin-to-pin registered equations. Use the = and ?= assignment operators for registered equations using detailed dot extensions. These assignment operators allow you to fully specify outputs in equations. For example, in the following truth table, the output F is fully specified:
TRUTH_TABLE ([A,B]->[F]); [1,1]-> 0 ; "off-set [1,0]-> 1 ; "on-set [0,1]-> 1 ; "on-set
The equivalent functionality can be expressed in equations:
@DCSET F = A & !B # !A & B; "on-set F ?= !A & !B; "dc-set
Note: Caution:
Specifying both the on-set and the don't-care set conditions enhances optimization. With equations, @DCSET or ISTYPE 'dc' must be specified or the ?= equations are ignored.
Expressions
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. Table 7 summarizes the logical, arithmetic and relational operators, presented in groups according to their priority. Table 7.
Priority 1 1 2 2 2 2
Operator priority
Operator ! & << >> * Description negate NOT AND shift left shift right multiply
16/162
1 Language structure
UM0045
Operator / % ++ # $ !$ == != < <= > >= Description unsigned division modulus add subtract OR XOR: exclusive OR XNOR: exclusive NOR equal not equal less than less than or equal greater than greater than or equal
Priority 2 2 3 3 3 3 3 4 4 4 4 4 4
Operations of the same priority are performed from left to right. Use parentheses to change the order in which operations are performed. The operation in the innermost set of parentheses is performed first. The following examples of supported expressions show how the order of operations and the use of parentheses affect the evaluated result.
Expression 2 * 3/2 2*3/2 2 * (3/2) 2+3*4 (2 + 3) * 4 2#4$2 2#(4$2) 2 == ^hA 14 == ^hE Result 3 3 2 14 20 4 6 0 -1 Comments operators with same priority spaces are OK fraction is truncated multiply first add first OR first XOR first
Equations
Equations assign the value of an expression to a signal or set of signals in a logic description. The identifier and expression must follow the rules for those elements. Equations use the assignment operators =, ?= (combinational) and := ?:=, (registered) described above. You can use the complement operator (!) to express 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. Use of the complement operator on the left side of equations is provided as an option; equations for negative logic parts can just as easily be expressed by complementing the expression on the right side of the equation. See also: Section 4.11: Equations and "Section 4.34: When-Then-Else" in Section 4: Language reference.
17/162
UM0045 Equation blocks
1 Language structure
Equation blocks let you specify more complex functions and improve the readability of your equations. An equation block is enclosed in braces { }, and is supported wherever a single equation is supported. When used within a conditional expression, such as IF-THEN, CASE, or WHEN-THEN, the logic functions are logically ANDed with the conditional expression that is in effect. See also: Section 4.15: If-Then-Else, Section 4.34: When-Then-Else, and Section 4.6: Case in Section 4: Language reference.
Multiple Assignments to the Same Identifier
When an identifier appears on the left side of more than one equation, the expressions assigned to the identifier are first ORed together, and then the assignment is made. If the identifier on the left side of the equation is complemented, the complement is performed after all the expressions have been ORed.
Equations Found A = B; A = C; A = B; A = C & D; A = !B; A = !C; !A = B; !A = C; !A = B; A = !C; !A = B; !A = C; A = !D; A = !E; Equivalent Equation A = B # C; A = B # ( C & D ); A = !B # !C; A = !(B # C); A = !C #!B;
A = !D # !E # !(B # C);
Note:
When the complement operator appears on the left side of multiple assignment equations, the right sides are ORed first, and then the complement is applied.
1.3.9
Sets
A set is a collection of signals and constants. Any operation applied to a set is applied to each element in the set. Sets simplify PSDabel-HDL logic descriptions and test vectors by allowing groups of signals to be referenced with one name. For example, you could collect the outputs (B0-B7) of an eight-bit multiplexer into a set named MULTOUT, and the three selection lines into a set named SELECT. You could then define the multiplexer in terms of MULTOUT and SELECT rather than individual input and output bits. A set is represented by a list of constants and signals separated by commas or the range operator (..) and surrounded by brackets. The sets MULTOUT and SELECT would be defined as follows:
MULTOUT = [B0,B1,B2,B3,B4,B5,B6,B7] SELECT = [S2,S1,S0]
18/162
1 Language structure
UM0045
The above sets could also be expressed by using the range operator; for example,
MULTOUT = [B0..B7] SELECT = [S2..S0]
Identifiers used to delimit a range must have compatible names: they must begin with the same alphabetical prefix and have a numerical suffix. Range identifiers can also delimit a decrementing range or a range which appears as one element of a larger set as shown below:
[A7..A0] "decrementing range [Q1,Q2,.X.,A10..A7] "range within a larger set
The brackets are required to delimit the set. PSDabel-HDL source file sets are not mathematical sets.
Set indexing
Set indexing allows you to access elements within a set. The following example uses set indexing to assign four elements of a 16-bit set to a smaller set.
declarations Set1 = [f15..f0]; Set2 = [q3..q0]; equations Set2 := Set1[7..4];
The numeric values used for defining a set index refer to the bit positions of the set, with 0 being the least significant (left-most) element in the set. So Set1[7..4] is Set1, values f8 to f11. If you are indexing into a set to access a single element, then you can use the following syntax:
declarations out1 pin istype 'com'; Set1 = [f15..f0]; equations out1 = Set1[4] == 1;
In this example, a comparator operator (==) was used to convert the single-element set (Set1[4]) into a bit value (equivalent to f4). See multiply.abl for more examples of set indexing. See also the @Setsize directive.
Set operations
Most operators can be applied to sets, with the operation performed on each element of the set, sometimes individually and sometimes according to the rules of Boolean algebra. Table 8 lists the operators you can use with sets. "Set operations," found later in this chapter, describes how these operators are applied to sets.
Two-set operations
For operations involving two or more sets, the sets must have the same number of elements. The expression "[a,b]+[c,d,e]" is not supported because the sets have different numbers of elements. For example, the Boolean equation
Chip_Sel = A15 & !A14 & A13;
represents an address decoder where A15, A14 and A13 are the three high-order bits of a 16bit address. The decoder can easily be implemented with set operations. First, a constant set
19/162
UM0045
1 Language structure
that holds the address lines is defined so the set can be referenced by name. This definition is done in the constant declaration section of a module. The declaration is
Addr = [A15,A14,A13];
which declares the constant set Addr. The equation
Chip_Sel = Addr == [1,0,1];
is functionally equivalent to
Chip_Sel = A15 & !A14 & A13;
If Addr is equal to [1,0,1], meaning that A15 = 1, A14 = 0 and A13 = 1, then Chip_Sel is set to true. The set equation could also have been written as
Chip_Sel = Addr == 5;
because 101 binary equals 5 decimal. In the example above, a special set with the high-order bits of the 16-bit address was declared and used in the set operation. The full address could be used and the same function arrived at in other ways, as shown below: Example 1
" declare some constants in declaration section Addr = [a15..a0]; X = .X.; "simplify notation for don't care constant Chip_Sel = Addr == [1,0,1,X,X,X,X,X,X,X,X,X,X,X,X];
Example 2
" declare some constants in declaration section Addr = [a15..a0]; X =.X.; Chip_Sel = (Addr >= ^HA000) & (Addr <= ^HBFFF);
Both solutions presented in these two examples are functionally equivalent to the original Boolean equation and to the first solution in which only the high order bits are specified as elements of the set
(Addr = [a15, a14, a13]).
Set assignment and comparison
Values and sets of values can be assigned and compared to a set. Supported set operations are given in Table 8. For example,
sigset = [1,1,0] & [0,1,1];
results in sigset being assigned the value, [0,1,0]. The set assignment
[a,b] = c & d;
is the same as the two assignments
a = c & d; b = c & d;
Numbers in any representation can be assigned or compared to a set. The preceding set equation could have been written as
sigset = 6 & 3;
20/162
1 Language structure
UM0045
When numbers are used for set assignment or comparison, the number is converted to its binary representation and the following rules apply:
If the number of significant bits in the binary representation of a number is greater than the number of elements in a set, the bits are truncated on the left. If the number of significant bits in the binary representation of a number is less than the number of elements in a set, the number is padded on the left with leading zeroes.
Thus, the following two assignments are equivalent:
[a,b] = ^B101011; [a,b] = ^B11; "bits truncated to the left
And so are these two:
[d,c] = ^B01; [d,c] = ^B1; "compiler will add leading zero
Table 8.
Operator = := ! & # $ !$ ++ == != < <= > >=
Supported set operations
Example A=5 A := [1,0,1] !A A&B A#B A$B A!$ B -A A-B A+B A == B A != B AB A >= B Description combinational assignment registered assignment NOT: ones complement AND OR XOR: exclusive OR XNOR: exclusive NOR negate subtraction addition equal not equal less than less than or equal greater than greater than or equal
Set evaluation
How an operator is performed with a set may depend on the types of arguments the operator uses. When a set is written [a , b , c , d ], a is the MOST significant bit and d is the LEAST significant bit. The result, when most operators are applied to a set, is another set. The result of the relational operators (==, !=, >, >=, <, <=) is a value: TRUE (all ones) or FALSE (all zeros), which is truncated or padded to as many bits as needed. The width of the result is determined by the context of the relational operator, not by the width of the arguments. The different contexts of the AND (&) operator and the semantics of each usage are described below.
signal & signal
21/162
UM0045
1 Language structure
a&b signal & number a&4 signal & set a & [x, y, z] set & set [a, b] & [x, y] set & number
This is the most straightforward use. The expression is TRUE if both signals are TRUE. The number is converted to binary and the least significant bit is used. The expression becomes a & 0, then is reduced to 0 (FALSE). The signal is distributed over the elements of the set to become [a & x, a & y, a & z] The sets are ANDed bit-wise resulting in: [a & x, b & y]. An error is displayed if the set widths do not match. The number is converted to binary and truncated or padded with zeros to match the width of the set. The sequence of transformations is [a, b, c] & [1, 0, 1] [a & 1, b & 0, c & 1] [a, 0, c] The numbers are converted to binary, ANDed together, then truncated or padded.
[a, b, c] & 5
number & number 9&5
Example equations
select = [a15..a0] == ^H80FF
select (signal) is TRUE when the 16-bit address bus has the hex value 80FF. Relational operators always result in a single bit.
[sel1, sel0] = [a3..a0] > 2
The width of sel and a are different, so the 2 is expanded to four bits (of binary) to match the size of the a set. Both sel1 and sel2 are true when the value of the four a lines (taken as a binary number) is greater than 2. The result of the comparison is a single-bit result which is distributed to both members of the set on the output side of the equation.
[out3..out0] = [in3..in0] & enab
If enab is TRUE, then the values on in0 through in3 are seen on the out0 through out3 outputs. If enab is FALSE, then the outputs are all FALSE.
Set operation rules
Set operations are applied according to Boolean algebra rules. Uppercase letters are set names, and lowercase letters are elements of a set. The letters k and n are subscripts to the elements and to the sets. A subscript following a set name (uppercase letter) indicates how many elements the set contains. So Ak indicates that set A contains k elements. ak-1 is the (k-1)th element of set A. a1 is the first element of set A.
Expression !Ak -Ak Ak.OE Is Evaluated As... [!ak, !ak-1, ..., !a1] !Ak + 1 [ak.OE, ak-1.OE, ..., a1.OE]
22/162
1 Language structure
UM0045
Is Evaluated As... [ak & bk, ak-1 & bk-1, ..., a1 & b1] [ak # bk, ak-1 # bk-1, ..., a1 # b1] [ak $ bk, ak-1 $ bk-1, ..., a1 $ b1] [ak !$ bk, ak-1 !$ bk-1, ..., a1 !$ b1] (ak == bk) & (ak-1 == bk-1) & ... & (a1 == b1) (ak != bk) # (ak-1 != bk-1) # ... # (a1 != b1) Dk where: dn is evaluated as an $ bn $ cn-1 cn is evaluated as (an $ bn) # (an & cn-1) # (bn & cn-1) c0 is evaluated as 0 Ak + (-Bk) ck where: cn is evaluated as (!an & (bn # cn-1) # an & bn & cn-1) != 0 c0 is evaluated as 0
Expression Ak & Bk Ak # Bk Ak $ Bk Ak !$ Bk Ak == Bk Ak != Bk
Ak + Bk
Ak - Bk
Ak + (-Bk)
Limitations/restrictions on sets
If you have a set assigned to a single value, the value will be padded with 0s and then applied to the set. For example,
[A1,A2,A3] = 1
is equivalent to
A1 = 0 A2 = 0 A3 = 1
which may not be the intended result. If you want 1 assigned to each member of the set, you'd need binary 111 or decimal 7. The results of using an operator depend on the sequence of evaluation. Without parentheses, operations are performed from left to right. Consider the following two equations. In the first, the constant 1 is converted to a set; in the second, the 1 is treated as a single bit. Equation 1: The first operation is [a, b] & 1, so 1 is converted to a set [0, 1].
[x1, y1] = = = = = = [a, b] & 1 & d ([a, b] & 1) ([a, b] & [0, 1]) ([a & 0, b & 1]) [0, b] [0 & d, b & d] = [0, b & d] & & & & d d d d
x1 = 0 y1 = b & d
Equation 2: The first operation is 1 & d, so 1 is treated as a single bit.
23/162
UM0045
[x2,y2] = 1 & d & [a, b] = (1 & d) & [a, b] = d & [a, b] = [d & a, d & b] x2 = a & d y2 = b & d
1 Language structure
If you are unsure about the interpretation of an equation, try the following:
Fully parenthesize your equation. Errors can occur if you are not familiar with the precedence rules in Table 7. Write out numbers as sets of 1s and 0s instead of as decimal numbers. If the width is not what you expected, you will get an error message.
1.3.10 Arguments and argument substitution
Variable values can be used in macros, modules, and directives. These values are called the arguments of the construct that uses them. In PSDabel-HDL, a distinction must be made between two types of arguments: actual and dummy. Their definitions are
Dummy argument An identifier used to indicate where an actual argument is to be substituted in the macro, module, or directive. The argument (value) used in the macro, directive, or module. The actual argument is substituted for the dummy argument. An actual argument can be any text, including identifiers, numbers, strings, operators, sets, or any other element of PSDabel-HDL.
Actual argument
Dummy arguments are specified in macro declarations and in the bodies of macros, modules, and directives. The dummy argument is preceded by a question mark in the places where an actual argument is to be substituted. The question mark distinguishes the dummy arguments from other PSDabel-HDL identifiers occurring in the source file. Take for example, the following macro declaration arguments (see "Macro declarations" later in this chapter):
OR_EM MACRO (a,b,c) { ?a # ?b # ?c };
This defines a macro named OR_EM that is the logical OR of three arguments. These arguments are represented in the definition of the macro by the dummy arguments, a, b, and c. In the body of the macro, which is surrounded by braces, the dummy arguments are preceded by question marks to indicate that an actual argument is substituted. The equation
D = OR_EM (x,y,z&1);
invokes the OR_EM macro with the actual arguments, x, y, and z&1. This results in the equation:
D = x # y # z&1;
Arguments are substituted into the source file before checking syntax and logic, so if an actual argument contains unsupported syntax or logic, the compiler detects and reports the error only after the substitution.
Spaces in arguments
Actual arguments are substituted exactly as they appear, so any spaces (blanks) in actual arguments are passed to the expression. In most cases, spaces do not affect the interpretation
24/162
1 Language structure
UM0045
of the macro. The exception is in functions that compare character strings, such as @IFIDEN and IFNIDEN. For example, the macro
iden macro(a,b) {@ifiden(?a,?b) {@message 'they are the same';};};
compares the actual arguments and prints the message if they are identical. If you enter the macro with spaces in the actual arguments:
iden(Q1, Q1);
The value is false because the space is passed to the macro.
Argument guidelines
Dummy arguments are place holders for actual arguments. A question mark preceding the dummy argument indicates that an actual argument is to be substituted. Actual arguments replace dummy arguments before the source file is checked for correctness. Spaces in actual arguments are retained.
Fur ther discussion and examples of argument use are given in Section 4: Language reference under "Section 4.21: Module," "Macros and declared equations," and "Section 4.4: @directive -- Directives."
1.4
Basic structure
PSDabel-HDL source files can contain independent modules. Each module contains a complete logic description of a circuit or subcircuit. Any number of modules can be combined into one source file and processed at the same time. This section covers the basic elements that make up a PSDabel-HDL source file module. A module can be divided into five sections:
Header Declarations Logic Description Test Vectors End
The elements of the source file are shown in the template in Figure 1. There are also directives that can be included in any of the middle three sections. The sections are presented briefly below, then each element is introduced. You can find complete information in Section 4: Language reference. The following rules apply to module structure:
A module must contain only one header (composed of the Module statement and optional Title and Options statements). All other sections of a source file can be repeated in any order. Declarations must immediately follow either the header or the Declarations keyword. No symbol (identifier) can be referenced before it is declared.
25/162
UM0045 Header
The Header Section can consist of the following elements:
1 Language structure
Module (required) Interface (lower level, optional) Title
Declarations
A Declarations Section can consist of the following elements:
Declarations Keyword Interface and Functional Block Declarations Signal Declarations (pin and node numbers optional) Constant Declarations Macro Declarations Library Declarations Device Declaration (one per module) (not supported)
26/162
1 Language structure
UM0045
PSDabel-HDL module structure
Figure 1.
Header: Module: The module statement names the module and indicates if dummy arguments are used. In lower-level modules, it can be followed by an inter fa ce declaration. Title: The title statement can be used to give a title or description for the module.
PSDabel-HDL Module
Declaratio ns: Declarations declare lower-level modules, and associate names with functional block insta nces devices, pins, nodes, constants, ma cros and sets. They also assign attributes with istype.
Module source3 Title `Example of a Source File' Declarations in1, in2, in3, clk PIN ; all, none, other PIN ISTYPE `reg'; in = [in1..in3 ] ; out = [all,none,other] ; Equations out.clk = clk ; all := in1 & in2 & in3 ; none := !in1 & !in2 & !in3 ; other := (!in1 # !in2 # !in3) & ( in1 # in2 # in3) Test_Vectors ([in,clk ] -> [out] ([ 7, c ] -> 4 ; ([ 3, C ] -> 1 ; End source3
Logic Description: You can use Equations, a State_diagram, or a Truth_table to descr ibe your logic design. This design uses Equations.
Test Vectors: Test_vectors are used in JEDEC simulation for designs mapped to PLDs.
End: The end statement ends the module.
Boldface type denotes PSDabel-HDL keywords.
Logic description
You can use one or more of the following elements to describe your design.
Equations Truth Tables State Diagrams Fuses (not supported) XOR Factors
Test vectors section
Test vectors are only used for Equation Simulation. A Test Vectors section can consist of the following elements:
Test Vectors
27/162
UM0045
1 Language structure
Trace Statement Test Script
End statement
A module is closed with the end statement:
End Statement
Other elements
Directives can be placed anywhere you need them:
Directives
1.5
1.5.1
Header
Module
Keyword: module The Module statement is required. It defines the beginning of the module and must be paired with an End statement. The Module statement also indicates whether any module arguments are used.
1.5.2
Interface
Keyword: interface The interface statement is used in lower-level sources to indicate signals used in upper-level files. The interface statement is optional.
1.5.3
Title
Keyword: title The title is optional. The title appears as a header in some output files.
1.6
Declarations
The declarations section of a module specifies the names and attributes of signals used in the design, defines constants macros and states, declares lower-level modules and schematics, and optionally declares a device. Each module must have at least one declarations section, and declarations affect only the module in which they are defined. There are several types of declaration statements:
Constant (see =) Device (not supported) Hierarchy Library Macro Signal (see Pin, Node and Istype) State
28/162
1 Language structure
UM0045
State register
The syntax and use of each of these types is presented in Section 4: Language reference. Some are discussed briefly below.
1.6.1
Declarations keyword
Keyword: declarations This keyword allows declarations (such as sets or other constants) in any part of the source file.
1.6.2
Device declaration (not supported)
Keyword: device
device_id DEVICE real_device ;
The Device declaration is optional, and only one can be made per module. It associates a device identifier with a specific programmable logic device.
1.6.3
Hierarchy declarations
Interface declarations Top-level interface declarations
Keyword: interface
low-level module_name INTERFACE (inputs[=value] -> outputs :> bidirs ...)
The interface keyword declares lower-level modules that are used by the current module. This declaration is used in conjunction with a functional_block declaration for each instantiation of a module. When you instantiate a functional block, you must map port names to signal names with equations. See functional_block for more information.
Lower-level interface declarations
Keyword: interface
MODULE module_name INTERFACE (input/set=value . . .-> output/set :> bidir/set ) ;
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 PSDabel-HDL sources. In the higherlevel source, you must declare signals and sets in the same order and grouping as given in the interface statement in the instantiated module. The -> and :> delimiters are used to indicate the direction of each port of a functional block. 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 PSDabel-HDL module in which the signal is defined. No references to that signal's dot extensions can be made outside of the PSDabel-HDL module.
29/162
UM0045 Functional_block statement
Keyword: functional_block
DECLARATIONS instance_name FUNCTIONAL_BLOCK module_name ; EQUATIONS instance_name.port_name = signal_name;
1 Language structure
Use a functional_block declaration to instantiate a declared source within a higher-level PSDabel-HDL source. You must declare a source with an interface declaration before instantiating it with functional_block.
Example of functional block instantiation
To declare the two PSDabel-HDL sources shown in Figure 2 would require the following syntax:
module FUNC ; mod1 INTERFACE (i1 -> o1); A FUNCTIONAL_BLOCK mod1; mod2 INTERFACE (i1 -> o1); B FUNCTIONAL_BLOCK mod2; I pin ; O pin istype 'com';
Equations O = B.o1; B.i1 = A.o1; A.i1 = I; end Func
Figure 2.
Functional block instantiation
MODULE MOD 1 MODULE MOD 2
A I
i1 o1 i1
B
o1
O
1808-1
Note that the output of an equation must always be on the left side of the equations. See Also: "Section 2.1: Hierarchy in PSDabel-HDL" in Section 2: Design considerations.
1.6.4
Signal declarations
The 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; see "Section 1.7.1: Dot extensions" under "Section 1.7: Logic description" later in this chapter.
30/162
1 Language structure
UM0045
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.
Pin declarations
Keyword: pin
[ ! ]pin_id [,[ ! ]pin_id...] PIN [pin# [,pin# ] ] [ISTYPE 'attributes' ] ;
See "Attribute assignment" below, and "Section 2.5: Using active-low declarations" in Section 2: Design considerations.
Node declarations
Keyword: node
[ ! ]node_id [, [ ! ]node_id...] NODE [node# [,node# ] ] [ISTYPE 'attributes' ] ;
See "Attribute assignment" below, and "Section 2.5: Using active-low declarations" in Section 2: Design considerations.
Attribute assignment
Keyword: istype
signal [,signal]... ISTYPE 'attributes';
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 will make it more likely that the design operates consistently if the device is changed later. ISTYPE can be used after pin or node declarations. Attributes may be entered in uppercase, lowercase, or mixed-case letters. Table 9 summarizes the attributes. Each attribute is discussed in more detail in Section 4: Language reference under Section 4.18: Istype _ Attribute declarations. Table 9.
Dot Ext. 'buffer' 'collapse' 'com' 'dc' 'inver t' 'keep' 'neg'
1 2 3
Attributes
Arch.Indep. Description No Inverter in Target Device. Collapse (remove) this signal. 1 3 3 Combinational output. Unspecified logic is don't care. 2 Inver ter in Target Device. Do not collapse this signal from equations. 1 3 Unspecified logic is 1. 2
If neither 'keep' nor 'collapse' is specified, the optimization or fitter programs can keep or collapse the signal, as needed, to optimize the circuit. The 'dc,' 'neg,' and 'pos' attributes are mutually exclusive. The 'retain' attribute only controls optimization performed by PSDabel-HDL Compile Logic. To preserve redundant product terms, you must also specify no reduction for the Reduce Logic and fitting (place and route) programs.
31/162
UM0045
Dot Ext. 'pos' 'retain' 'reg' 'reg_d' 'reg_g' 'reg_jk' 'reg_sr' 'reg_t' 'xor'
1 2 3
1 Language structure
Arch.Indep. 3 3 3
Description Unspecified logic is 0. 2 Do not minimize this output. Preserve redundant product terms.
3
Clocked Memory Element. D Flip-flop Clocked Memory Element. D Flip-flop Gated Clock Memory Element. JK Flip-flop Clocked Memory Element. SR Flip-flop Clocked Memory Element. T Flip-flop Clocked Memory Element. XOR Gate in Target Device.
If neither 'keep' nor 'collapse' is specified, the optimization or fitter programs can keep or collapse the signal, as needed, to optimize the circuit. The 'dc,' 'neg,' and 'pos' attributes are mutually exclusive. The 'retain' attribute only controls optimization performed by PSDabel-HDL Compile Logic. To preserve redundant product terms, you must also specify no reduction for the Reduce Logic and fitting (place and route) programs.
1.6.5
Constant declarations
Keyword: =
id [, id]... = expr [, expr]... ;
A constant is an identifier that retains a constant value in a module, and is specified with the = sign. Constant declarations must be in a declarations section or after a @CONST directive. See also: "Special Constants" in this chapter.
1.6.6
Symbolic state declarations
The State_register and State declarations are made to declare a symbolic state machine name, and to declare symbolic state names. See also: "Section 1.7.4: State descriptions" under "Section 1.7: Logic description" later in this chapter.
State_register declarations
Keyword: state_register
statereg_id STATE_REGISTER [ISTYPE 'attributes'];
State declarations
Keyword: state
state_id [, state_id...] STATE [state_value [, state_value...]];
32/162
1 Language structure
UM0045
1.6.7
Macro declarations
Keyword: macro
macro_id MACRO [(dummy_arg [,dummy_arg]... )] {block} ;
The macro declaration statement defines a macro. Use macros to include functions in a source file without repeating the code.
1.6.8
Library declaration
Keyword: library
LIBRARY 'name' ;
The LIBRARY statement extracts the contents of the indicated file from the PSDabel-HDL library and inserts it into your file.
1.7
Logic description
One or more of the following elements can be used to describe your design.
Equations Truth Tables State Descriptions Fuses (not supported) XOR Factors
In addition, dot extensions (like ISTYPE attributes in the Declarations section) enable you to more precisely describe the behavior of a circuit in a logic description that may be targeted to a variety of different devices.
1.7.1
Dot extensions
Syntax
signal_name.ext
Dot extensions can be specific for certain devices (device-specific) or generalized for all devices (architecture-independent). Device-specific dot extensions are used with detailed syntax; architecture-independent dot extensions are used with pin-to-pin syntax. Detailed and pin-to-pin syntax is described in more detail in Section 2: Design considerations. Dot extensions can be applied in complex language constructs such as nested sets or complex expressions. The PSDabel-HDL dot extensions are listed in Table 10. Table 10. Dot extensions
Description
Dot Extension
Pin-to-Pin Syntax, Architecture-independent .ACLR
*
*Asynchronous clear
The .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.
33/162
UM0045
Dot Extension .ASET .CLK .CLR .COM .FB .OE .PIN .SET .AP .AR .CE .D .FC .J .K .LD .LE .LH .PR .Q .R .RE .S .SP .SR .T
*
1 Language structure
Description *Asynchronous set Clock input to an edge-triggered flip-flop *Synchronous clear *Combinational feedback normalized to the pin value Register feedback Output enable Pin feedback *Synchronous set Asynchronous register preset Asynchronous register reset Clock-enable input to a gated-clock flip-flop Data input to a D-type flip-flop Flip-flop mode control J input to a JK-type flip-flop K input to a JK-type flip-flop Register load input Latch-enable input to a latch Latch-enable (high) to a latch Register preset Register feedback R input to an SR-type flip-flop Register reset S input to an SR-type flip-flop Synchronous register preset Synchronous register reset T input to a T-type (toggle) flip-flop
Detailed Syntax, Device-specific
The .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.
1.7.2
Equations
Keyword: equations
Equations [ WHEN condition or [ WHEN condition THEN ] [ ! ] element=expression; [ ELSE equation]; [ ELSE equation ];
THEN ] equation;
The EQUATIONS statement defines the beginning of a group of equations that specify the logic functions of a device. See "Section 1.3.8: Operators, expressions, and equations" earlier in this chapter and "Section 4.34: When-Then-Else" in Section 4: Language reference.
34/162
1 Language structure
UM0045
1.7.3
Truth tables
Keyword: truth_table
TRUTH_TABLE (inputs -> outputs ) inputs -> outputs ; : or TRUTH_TABLE (inputs [:> registered outputs] [-> outputs ] )
Truth tables specify outputs as functions of input combinations in tabular form. See also "@Dcset -- Don't Care set" under "Section 4.4: @directive -- Directives" in Section 4: Language reference.
1.7.4
State descriptions
Keyword: state_diagram
STATE_DIAGRAM state_reg [-> state_out] [STATE state_exp : [equation] [equation] : : : trans_stmt ...]
The State_Diagram section contains state descriptions that describe the logic design. 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 that determine the operation of the state machine. See also: "Section 4.35: With" in Section 4: Language reference.
1.7.5
Fuse declarations (not supported)
Keyword: fuses
FUSES fuse_number = fuse value ; or fuse_number_set = fuse value ;
The FUSES section explicitly declares the state of fuses in the associated device. A device must be declared before a fuses declaration.
1.7.6
XOR factors
Keyword: XOR_Factors
XOR_Factors signal name = xor_factors
The XOR_Factors section allows you to specify a Boolean expression that is to be factored out of and XORed with the sum-of-products reduced equations. This factoring can result in smaller reduced equations when the design is implemented in a device featuring XOR gates.
35/162
UM0045
1 Language structure
1.8
Note:
Test vectors section
Test vectors are supported only for Equation simulation.
1.8.1
Test vectors
Keyword: test_vector
Test_vectors [note ] (inputs -> outputs) [invalues -> outvalues ; ] ...
Test vectors specify the expected operation of a logic device by defining its outputs as a function of its inputs.
1.8.2
Trace statement
Keyword: trace
trace (inputs -> outputs) ;
The Trace statement limits which inputs and outputs are displayed in the simulation report.
1.9
End statement
Keyword: end
end module_name
The End statement ends the module, and is required.
1.10
Other elements
1.10.1 Directives
Keyword: @directive
@directive [options ]
Directives provide options that control the contents or processing of a source file. Sections of PSDabel-HDL source code can be included conditionally, code can be brought in from another file, and messages can be printed during processing. 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. The rules applying to actual and dummy arguments are presented under "Arguments and Argument Substitution" earlier in this chapter.
36/162
1 Language structure
UM0045
Available directives are listed below. See @ in Section 4: Language reference for complete information.
@ALTERNATE @CARRY @CONST @DCSET @DCSTATE @EXPR @EXIT @IF @IFB @IFDEF @IFIDEN @IFNB @IFNDEF @IFNIDEN @INCLUDE @IRP @IRPC @MESSAGE @ONSET @PAGE @RADIX @REPEAT @SETSIZE @STANDARD
37/162
UM0045
2 Design considerations
2
Design considerations
This chapter discusses issues you need to consider when you create a design with PSDabelHDL. The topics covered are listed below:
Hierarchy in PSDabel-HDL Pin-to-Pin Architecture-independent Language Features Pin-to-Pin Vs. Detailed Descriptions for Registered Designs Using Active-low Declarations Polarity Control Istypes and Attributes Flip-flop Equations Feedback Considerations -- Using Dot Extensions Considerations and Precautions Exclusive OR Equations State Machines Using Complement Arrays Accessing Device-specific and Complex Architectural Elements
2.1
Hierarchy in PSDabel-HDL
You use hierarchy declarations in an upper-level PSDabel-HDL source to refer to (instantiate) an PSDabel-HDL module. To instantiate an PSDabel-HDL module:
In the lower-level module: (optional)
Identify lower-level I/O Ports (signals) with an Interface statement.
In the top-level source:
1. 2. Note: Declare the lower-level module with an Interface declaration. Instantiate the lower-level module with Functional_block declarations.
Hierarchy declarations are not required when instantiating an PSDabel-HDL module in a schematic. For instructions on instantiating lower-level modules in schematics, refer to your schematic reference.
2.1.1
Instantiating a lower-level module in an PSDabel-HDL source
Identifying I/O ports in the lower-level module
The way to identify an PSDabel-HDL module's input and output ports is to place an Interface statement immediately following the Module statement. The Interface statement defines the ports in the lower-level module that are used by the top-level source. You must declare all input pins in the PSDabel-HDL module as ports, and you can specify default values of 0, 1, or Don't-care.
38/162
2 Design considerations
UM0045
You do not have to declare all output pins as ports. Any undeclared outputs become No Connects or redundant nodes. Redundant nodes can later be removed from the designs during post-link optimization. The following source fragment is an example of a lower-level interface statement.
module lower interface (a=0, [d3..d0]=7 -> [z0..z7]) ; title 'example of lower-level interface statement ' ...
This statement identifies input a, d3, d2, d1 and d0 with default values, and outputs z0 through z7. For more information, see Section 4.17: Interface (lower-level) in Section 4: Language reference.
Specifying signal attributes
Attributes specified for pins in a lower-level module are propagated to the higher-level source. For example, a lower-level pin with an 'invert' attribute affects the higher-level signal wired to that pin (it affects the pin's preset, reset, preload, and power-up value).
Output enables (OE)
Connecting a lower-level tristate output to a higher-level pin results in the output enable being specified for the higher-level pin. If another OE is specified for the higher-level pin, it is flagged as an error. Since most tristate outputs are used as bidirectionals, it might be important to keep the lower-level OE.
Buried nodes
Buried nodes in lower-level sources are handled as follows:
Dangling Nodes Combinational nodes Registered nodes Lower-level nodes that do not fanout are propagated to the higherlevel module and become dangling nodes. Optimization may remove dangling nodes. Combinational nodes in a lower-level module become collapsible nodes in the higher-level module. Registered nodes are preserved with hierarchical names assigned to them.
Declaring lower-level modules in the top-level source
To declare a lower-level module, you match the lower-level module's interface statement with an interface declaration. For example, to declare the lower-level module given above, you would add the following declaration to your upper-level source declarations:
lower interface (a, [d3..d0] -> [z0..z7]) ;
You could specify different default values if you want to override the values given in the instantiated module, otherwise the instantiated module must exactly match the lower-level interface statement. See Section 4.16: Interface (top-level) in Section 4: Language reference for more information.
Instantiating lower-level modules in top-level source
Use a functional_block declaration in an top-level PSDabel-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 sources with an interface declaration before you instantiate them.
39/162
UM0045
2 Design considerations
To instantiate the module declared above, add an interface declaration and signal declarations to your top-level declarations, and add port connection equations to your top-level equations, as shown in the source fragment below:
DECLARATIONS low1 FUNCTIONAL_BLOCK lower ; zed0..zed7 pin ; atop pin istype 'reg,buffer'; d3..d0 pin istype 'reg,buffer'; EQUATIONS atop = low1.a; [d3..d0] = low1.[d3..d0] ; low1.[z0..z7] = [zed0..zed7];
"upper-level inputs "upper-level output "upper-level ouputs "wire this source's outputs " to lower-level inputs "wire this source's inputs to " lower-level outputs
See Table 4.12: Functional_block in Section 4: Language reference for more information.
2.1.2
Hierarchy and retargeting and fitting
Redundant nodes
When you link multiple sources, some unreferenced nodes may be generated. These nodes usually originate from lower-level outputs that are not being used in the top-level source. For example, when you use a 4-bit counter as a 3-bit counter. The most significant bit of the counter is unused and can be removed from the design to save device resources. This step also removes trivial connections. In the following example, if out1 is a pin and t1 is a node:
out1 = t1; t1 = a86;
would be mapped to
out1 = a86;
Merging feedbacks
Linking multiple modules can produce signals with one or more feedback types, such as .FB and .Q. You can tell the optimizer to combine these feedbacks to help the fitting process.
Post-linked optimization
If your design has a constant tied to an input, you can re-optimize the design. Re-optimizing may further reduce the product terms count. For example, if you have the equation
out = i0 & i1 || !i0 & i2;
and i0 is tied to 1, the resulting equation would be simplified to
out = i1;
2.1.3
Hierarchy and test vectors (PLD JEDEC simulation - not supported feature)
If you are targeting a PLD device and want to do JEDEC simulation of your project, you must specify your test vectors in the top-level source. If you have existing test vectors in lower-level sources, you can merge the inputs stimulus of blocks that are connected to the top-level pins with the expected values of blocks that are connected to the top-level outputs. The test vectors in the lower-level modules can still be used for individual JEDEC simulation.
40/162
2 Design considerations
UM0045
2.2
Node collapsing
All combinational nodes are collapsible by default . Nodes that are to be collapsed (or nodes that are to be preserved) are flagged through the use of signal attributes in the language. The signal attributes are:
Istype 'keep' 'collapse' Do not collapse this node. Collapse this node.
Collapsing provides multi-level optimization for combinational logic. Designs with arithmetic and comparator circuits generally generate a large number of product terms that will not fit to any programmable logic device. Node collapsing allows you to describe equations in terms of multilevel combinational nodes, then collapse the nodes into the output until it reaches the product term you specify. The result is an equation that is optimized to fit the device constraints.
2.2.1
Selective collapsing
In some instances you may want to prevent the collapsing of certain nodes. For example, some nodes may help in the simulation process. You can specify nodes you do not want collapsed as Istype 'keep' and the optimizer will not collapse them.
2.3
Pin-to-pin language features
PSDabel-HDL is a device-independent language. You do not have to declare a device or assign pin numbers to your signals until you are ready to implement the design into a device. However, when you do not specify a device or pin numbers, you need to specify pin-to-pin attributes for declared signals. Because the language is device-independent, the PSDabel-HDL compiler does not have predetermined device attributes to imply signal attributes. If you do not specify signal attributes or other 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.
2.3.1
Device-independence Vs. architecture-independence
The requirement for signal attributes does not mean that a complex design must always be specified with a particular device in mind. You may still have to understand the differences between device families but you do not have to specify a particular device when describing your design. Attributes and dot extensions help you refine your design to work consistently when moving from one class of device architecture to another; for example from devices having inverted outputs to those with a particular kind of reset/preset circuitry. However, the more you refine your design, using these language features, the more restrictive your design becomes in terms of the number of device architectures for which it is appropriate.
2.3.2
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. See "Section 4.23: Pin," "Section 4.22: Node" and "Section 4.18: Istype _ Attribute declarations" in Section 4: Language reference.
41/162
UM0045
2 Design considerations
2.3.3
Signal dot extensions
Signal dot extensions, like attributes, enable you to more precisely describe the behavior of a circuit that may be targeted to different architectures. Dot extensions remove the ambiguities in equations. Refer to Section 2.8: Feedback considerations -- using dot extensions later in this chapter and in Section 1: Language structure or Section 4.1: . ext -- dot extensions in Section 4: Language reference for more information.
2.4
Pin-to-pin vs. detailed descriptions for registered designs
You can use PSDabel-HDL assignment operators when you write high-level equations. The = operator specifies a combinational assignment, where the design is written with only the circuit's inputs and outputs in mind. The := assignment operator specifies a registered assignment, where you must consider the internal circuit elements (such as output inverters, presets and resets) related to the memory elements (typically flip-flops). The semantics of these two assignment operators are discussed below.
2.4.1
Using := for pin-to-pin descriptions
The := implies that a memory element is associated with the output defined by the equation. For example, the equation
Q1 := !Q1 # Preset;
implies that Q1 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 Q1. 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 ":=" assignment operator, and the .CLK, .OE, .FB, .CLR, .ACLR, .SET, .ASET and .COM dot extensions described in Section 4: Language reference These dot extensions help resolve circuit ambiguities when describing architecture-independent circuits.
Resolving ambiguities
In the equation above (Q1 := !Q1 # Preset;), there is an ambiguous feedback condition. The signal Q1 appears on the right side of the equation, but there is no indication of whether that fed-back signal should originate at the register, come directly from the combinational logic that forms the input to the register, or come from the I/O pin associated with Q1. 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 in the following manner:
Q1.CLK = Clock; "Register clocked from input Q1 := !Q1.FB # Preset; "Reg. feedback normalized to pin value
This set of equations describes the circuit completely and specifies enough information that the circuit will operate identically in virtually any device in which you can fit it. 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.
42/162
2 Design considerations
UM0045
2.4.2
Detailed circuit descriptions
In contrast to a pin-to-pin description, the same circuit can be specified in a detailed form of design description in the following manner:
Q1.CLK = Q1.D = Clock; !Q1.Q # Preset; "Register clocked from input "D-type f/f 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 in which the design can be implemented. Furthermore, the equations describe only 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, versus a device with non-inverting outputs. To maintain the correct pin behavior, using detailed equations, one additional language element is required: a 'buffer' attribute (or its complement, an 'invert' attribute). 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 Q1. For example, add the following to the declarations section:
Q1 pin istype 'buffer';
Detailed descriptions: designing for macrocells
One way to understand the difference between pin-to-pin and detailed description methods is to think of detailed descriptions as macrocell specifications. A macrocell is a block of circuitry normally (but not always) associated with a device's I/O pin. Figure 3 illustrates a typical macrocell associated with signal Q1. Detailed descriptions are written for the various input ports of the macrocell (shown in Figure 3 with dot extension labels). Note that the macrocell features a configurable inversion between the Q output of the flip-flop and the output pin labeled Q1. If you use this inverter (or select a device that features a fixed inversion), the behavior you observe on the Q1 output pin will be inverted from the logic applied to (or observed on) the various macrocell ports, including the feedback port Q1.q. Figure 3. Detail macrocell
Q1.ap AP Q1.d D Q O Fuse Mux 1 Q1 Q1.oe
Q1.clk
Clk AR
Q1.ar Q1.q Q1.pin !Q1.pin
0665-3
Pin-to-pin descriptions, on the other hand, allow you to describe your circuit in terms of the expected behavior on an actual output pin, regardless of the architecture of the underlying macrocell. Figure 4 illustrates the pin-to-pin concept:
43/162
UM0045
Figure 4. Pin-to-pin macrocell
a Q1 b OR a Q1 b
2 Design considerations
1748-1
When pin-to-pin descriptions are written in PSDabel-HDL, the "generic macrocell" shown above is synthesized from whatever type of macrocell actually exists in the target device.
2.4.3
Examples of pin-to-pin and detailed descriptions
Two equivalent module descriptions, one pin-to-pin and one detailed, are shown below for comparison:
Pin-to-pin module description
module Q1_1 Q1 Clock,Preset pin pin; istype 'reg';
equations Q1.clk = Clock; Q1 := !Q1.fb # Preset; test_vectors ([Clock,Preset] [ .c. , 1] [ .c. , 0] [ .c. , 0] [ .c. , 0] [ .c. , 1] [ .c. , 1] end -> -> -> -> -> -> -> Q1) 1; 0; 1; 0; 1; 1;
Detailed module description
module Q1_2 Q1 Clock,Preset equations Q1.CLK Q1.D pin pin; istype 'reg_D,buffer';
= Clock; = !Q1.Q # Preset; -> -> -> -> -> -> -> Q1) 1; 0; 1; 0; 1; 1;
test_vectors ([Clock,Preset] [ .c. , 1] [ .c. , 0] [ .c. , 0] [ .c. , 0] [ .c. , 1] [ .c. , 1] end
The first description can be targeted into virtually any device (if register synthesis and device fitting features are available), while the second description can be targeted only to devices featuring D-type flip-flops and non-inverting outputs.
44/162
2 Design considerations
UM0045
To implement the second (detailed) module in a device with inverting outputs, the source file would need to be modified in the following manner:
2.4.4
Detailed module with inverted outputs
module Q1_3 Q1 Clock,Preset equations Q1.CLK !Q1.D pin pin; istype 'reg_D,invert';
= =
Clock; Q1.Q # Preset; -> -> -> -> -> -> -> Q1) 1; 0; 1; 0; 1; 1;
test_vectors ([Clock,Preset] [ .c. , 1] [ .c. , 0] [ .c. , 0] [ .c. , 0] [ .c. , 1] [ .c. , 1] end
In this version of the module, the existence of an inverter between the output of the D-type flipflop and the output pin (specified with the 'invert' attribute) has necessitated a change in the equation for Q1.D. As this example shows, device-independence and pin-to-pin description methods are preferable, since you can describe a circuit completely for any implementation. Using pin-to-pin descriptions and generalized dot extensions (such as .FB, .CLK and .OE) as much as possible allows you to implement your PSDabel-HDL module into any one of a particular class of devices. (For example, any device that features enough flip-flops and appropriately configured I/O resources.) However, the need for particular types of device features (such as register preset or reset) might limit your ability to describe your design in a completely architectureindependent way. If, for example, a built-in register preset feature is used in a simple design, the target architectures are limited. Consider this version of the design:
module Q1_5 Q1 Clock,Preset equations Q1.CLK = Q1.AP = Q1 := pin pin; istype 'reg,buffer';
Clock; Preset; !Q1.fb ; -> -> -> -> -> -> -> Q1) 1; 0; 1; 0; 1; 1;
test_vectors ([Clock,Preset] [ .c. , 1] [ .c. , 0] [ .c. , 0] [ .c. , 0] [ .c. , 1] [ .c. , 1] end
The equation for Q1 still uses the := assignment operator and .FB for a pin-to-pin description of Q1's behavior, but the use of .AP to describe the reset function requires consideration of different device architectures. The .AP extension, like the .D and .Q extensions, is associated with a flip-flop input, not with a device output pin. If the target device has inverted outputs, the
45/162
UM0045
2 Design considerations
design will not reset properly, so this ambiguous reset behavior is removed by using the 'buffer' attribute, which reduces the range of target devices to those with non-inverted outputs. Using .ASET instead of .AP can solve this problem if the fitter being used supports the .ASET dot extension. Versions 5 and 7 of the design above and below are unambiguous, but each is restricted to certain device classes:
module Q1_7 Q1 Clock,Preset equations Q1.CLK = Q1.AR = Q1 := pin pin; istype 'reg,invert';
Clock; Preset; !Q1.fb ; -> -> -> -> -> -> -> Q1) 1; 0; 1; 0; 1; 1;
test_vectors ([Clock,Preset] [ .c. , 1] [ .c. , 0] [ .c. , 0] [ .c. , 0] [ .c. , 1] [ .c. , 1] end
2.4.5
When to use detailed descriptions
Although the pin-to-pin description is preferable, there will frequently be situations when you must use a more detailed description. If you are unsure about which method to use for various parts of your design, examine the design's requirements. If your design requires specific features of a device (such as register preset or unusual flip-flop configurations), detailed descriptions are probably necessary. If your design is a simple combinational function, or if it matches the "generic" macrocell in its requirements, you can probably use simple pin-to-pin descriptions.
2.4.6
Using := for alternative flip-flop types
In PSDabel-HDL you can specify a variety of flip-flop types using attributes such as istype 'reg_D' and 'reg_JK'. However, these attributes do not enforce the use of a specific type of flipflop when a device is selected, and they do not affect the meaning of the := assignment operator. You can think of the := assignment operator as a memory operator. The type of register that most closely matches the := assignment operator's behavior is the D-type flip-flop. The primary use for attributes such as istype 'reg_D', 'reg_JK' and 'reg_SR' is to control the generation of logic. Specifying one of the 'reg_' attributes (for example, istype 'reg_D') instructs the AHDL compiler to generate equations using the.D extension regardless of whether the design was written using .D, := or some other method (for example, state diagrams).
Note:
You also need to specify istype 'invert' or 'buffer' when you use detailed syntax. Using := for flip-flop types other than D-type is only possible if register synthesis features are available to convert the generated equations into equations appropriate for the alternative flipflop type specified. Since the use of register synthesis to convert D-type flip-flop stimulus into JK or SR-type stimulus usually results in inefficient circuitry, the use of := for these flip-flop types is discouraged. Instead, you should use the .J and .K extensions (for JK-type flip-flops) or
46/162
2 Design considerations
UM0045
the .S and .R extensions (for SR-type flip-flops) and use a detailed description method (including 'invert' or 'buffer' attributes) to describe designs for these register types. There is no provision in the language for directly writing pin-to-pin equations for registers other than D-type. State diagrams, however, may be used to describe pin-to-pin behavior for any register type.
2.5
Using active-low declarations
In PSDabel-HDL you can write pin-to-pin design descriptions using implied active-low signals. Active-low signals are declared with a '!' operator, as shown below:
!Q1 pin istype 'reg';
If a signal is declared active-low, it is automatically complemented when you use it in the subsequent design description. This complementing is performed for any use of the signal itself, including as an input, as an output, and in test vectors. Complementing is also performed if you use the .fb dot extension on an active-low signal. The following three designs, for example, operate identically:
Design 1 -- implied pin-to-pin active-low
module act_low2 !q0,!q1 clock reset pin istype 'reg'; pin; pin;
equations [q1,q0].clk = clock; [q1,q0] := ([q1,q0].FB + 1) & !reset; test_vectors ([clock,reset] [ .c. , 1 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 1 ] end -> -> -> -> -> -> -> -> [ [ [ [ [ [ [ [ q1, 0, 0, 1, 1, 0, 0, 0, q0]) 0 ]; 1 ]; 0 ]; 1 ]; 0 ]; 1 ]; 0 ];
Design 2 -- explicit pin-to-pin active-low
module act_low1 q0,q1 clock reset pin istype 'reg'; pin; pin;
equations [q1,q0].clk = clock; ![q1,q0] := (![q1,q0].FB + 1) & !reset; test_vectors ([clock,reset] [ .c. , 1 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] -> -> -> -> -> -> [!q1,!q0]) [ 0 , 0 ]; [ 0 , 1 ]; [ 1 , 0 ]; [ 1 , 1 ]; [ 0 , 0 ];
47/162
UM0045
[ .c. , [ .c. , end 0 1 ] -> [ 0 , 1 ]; ] -> [ 0 , 0 ];
2 Design considerations
Design 3 -- explicit detailed active-low
module act_low3 q0,q1 clock reset pin istype 'reg_d,buffer'; pin; pin;
equations [q1,q0].clk = clock; ![q1,q0].D := (![q1,q0].Q + 1) & !reset; test_vectors ([clock,reset] [ .c. , 1 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 0 ] [ .c. , 1 ] end -> -> -> -> -> -> -> -> [!q1,!q0]) [ 0 , 0 ]; [ 0 , 1 ]; [ 1 , 0 ]; [ 1 , 1 ]; [ 0 , 0 ]; [ 0 , 1 ]; [ 0 , 0 ];
Both of these designs describe an up counter with active-low outputs. The first example inverts the signals explicitly (in the equations and in the test vector header), while the second example uses an active-low declaration to accomplish the same thing.
2.6
Polarity control
Automatic polarity control is a powerful feature in PSDabel-HDL where a logic function is converted for both non-inverting and inverting devices. A single logic function may be expressed with many different equations. For example, all three equations below for F1 are equivalent.
(1)F1 = (A & B); (2)!F1 = !(A & B); (3)!F1 = !A # !B;
In the example above, equation (3) uses two product terms, while equation (1) requires only one. This logic function will use fewer product terms in a non-inverting device than in an inverting device. 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. For example, the inverted form of F2, equation (3), uses fewer product terms than equation (2).
(1)F2 = (A # B) & (C # D); (2)F2 = (A & C) # (A & D) # (B & C) # (B & D); (3)!F2 = (!A & !B) # (!C & !D);
Programmable polarity devices are popular because they can provide a mix of non-inverting and inverting outputs to achieve the best fit.
2.6.1
Polarity control with istype
In PSDabel-HDL, you control the polarity of the design equations and target device (in the case of programmable polarity devices) in two ways:
48/162
2 Design considerations
UM0045
~Using Istype 'neg', 'pos' and 'dc' ~Using Istype 'invert' and 'buffer'
Using istype 'neg', 'pos', and 'dc' to control equation and device polarity
The 'neg', 'pos', and 'dc' attributes specify types of optimization for the polarity as follows:
'neg' 'pos' 'dc' Istype 'neg' optimizes the circuit for negative polarity. Unspecified logic in truth tables and state diagrams becomes a 0. Istype 'pos' optimizes the circuit for positive polarity. Unspecified logic in truth tables and state diagrams becomes a 1. Istype 'dc' uses polarity for best optimization. Unspecified logic in truth tables and state diagrams becomes don't care (X).
Using 'invert' and 'buffer' to control programmable inversion
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 does not 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, where the reset and preset behavior is affected by the programmable inverter. Note: The 'invert' and 'buffer' attributes do not actually control device or equation polarity -- they only enforce the existence or nonexistence of an inverter between a flip-flop and its output pin. 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'.
2.7
Flip-flop equations
Pin-to-pin equations (using the := assignment operator) are only supported for D flip-flops. PSDabel-HDL does not support the := assignment operator for T, SR, or JK flip-flops and has no provision for specifying a particular output pin value for these types. If you write an equation of the form:
Q1 := 1;
and the output, Q1, has been declared as a T-type flip-flop, the PSDabel-HDL compiler will give a warning and convert the equation to
Q1.T = 1;
Since the T input to a T-type flip-flop does not directly correspond to the value you observed on the associated output pin, this equation will not result in the pin-to-pin behavior you want. To produce specific pin-to-pin behavior for alternate flip-flop types, you must consider the behavior of the flip-flop you used and write detailed equations that stimulate the inputs of that flip-flop. A detailed equation to set and hold a T-type flip-flop is shown below:
Q1.T = !Q1.Q;
49/162
UM0045
2 Design considerations
2.8
Feedback considerations -- using dot extensions
The source of feedback is normally set by the architecture of the target device. If you don't specify a particular feedback path, the design may operate differently in different device types. Specifying feedback paths (with the .FB, .Q or .PIN dot extensions) eliminates architectural ambiguities. Specifying feedback paths also allows you to use architecture-independent simulation. The following rules should be kept in mind when you are using feedback:
No Dot Extension -- A feedback signal with no dot extension (for example, count := count+1;) results in pin feedback if it exists in the target device. If there is no pin feedback, register feedback is used, with the value of the register contents complemented (normalized) if needed to match the value observed on the pin. .FB Extension -- A signal specified with the .FB extension (for example, count := count.fb+1;) results in register feedback normalized to the pin value if a register feedback path exists. If no register feedback is available, pin feedback is used, and the fuse mapper checks that the output enable does not conflict with the pin feedback path. If there is a conflict, an error is generated if the output enable is not constantly enabled. .COM Extension -- A signal specified with the .COM extension (for example, count := count.com+1;) results in OR-array (pre-register) feedback, normalized to the pin value if an OR-array feedback path exists. If no OR-array feedback is available, pin feedback is used and the fuse mapper checks that the output enable does not conflict with the pin feedback path. If there is a conflict, an error is generated if the output enable is not constantly enabled. .PIN Extension -- If a signal is specified with the .PIN extension (for example, count := count.pin+1;), the pin feedback path will be used. If the specified device does not feature pin feedback, an error will be generated. Output enables frequently affect the operation of fed-back signals that originate at a pin. .Q Extension -- Signals specified with the .Q extension (for example, count.d = count.q + 1;) will originate at the Q output of the associated flip-flop. The fed-back value may or may not correspond to the value you observe on the associated output pin; if an inverter is located between the Q output of the flip-flop and the output pin (as is the case in most registered PAL-type devices), the value of the fed-back signal will be the complement of the value you observe on the pin. .D Extension -- Some devices allow feedback of the input to the register. To select this feedback, use the .D extension. Some device kits also support .COM for this feedback; refer to your device kit manual for detailed information.
2.8.1
Dot extensions and architecture-independence
To be architecture-independent, you must write 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). For example, consider the simple circuit shown in Figure 5. This circuit toggles high when the Toggle input is forced high, and low when the Toggle is low. The circuit also contains a threestate output enable that is controlled by the active-low Enable input.
50/162
2 Design considerations
UM0045
Dot extensions and architecture-independence: circuit 1
Ena
Figure 5.
Toggle Clk
D
Q
Qout
0770-1
The following simple PSDabel-HDL design (Figure 6) describes this 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 target device. Since this design is architecture-independent, it will operate the same (disregarding initial powerup state), irrespective of the device type. Figure 6. Pin to pin one-bit synchronous circuit
module pin2pin Clk Toggle Ena Qout pin 1; pin 2; pin 11; pin 19 istype 'reg';
equations Qout := !Qout.FB & Toggle; Qout.CLK = Clk; Qout.OE = !Ena; test_vectors([Clk,Ena,Toggle] [.c., 0 , 0 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 1 , 1 ] [0,0, 1 ] [.c., 1 , 1 ] [0,0, 1 ] end -> [Qout]) -> 0; -> 1; -> 0; -> 1; -> 0; -> .Z.; -> 1; -> .Z.; -> 0;
If you implement this circuit in a simple P16R8 PAL device (either by adding a device declaration statement or by specifying the P16R8 in the Fuseasm process), the result will be a circuit like the one illustrated in Figure 7. Since the P16R8 features inverted outputs, the design equation is automatically modified to take the feedback from Q-bar instead of Q. Figure 7. Dot extensions and architecture-independence: circuit 2
1 11
D
Q Q
19
2
0768-1
If you implement this design in a device with a different architecture, such as an E0320, the resulting circuit could be quite different. But, because this is a pin-to-pin design description, the
51/162
UM0045
2 Design considerations
circuit behavior is the same. Figure 8 illustrates the circuit that results when you specify an E0320. Figure 8. Dot extensions and architecture-independence: circuit 3
1
D
2880=0 2881=0 2 2882=1 2883=1
Q Q 1 0
0 1
19
0769-1
2.8.2
Dot extensions and detail design descriptions
You may need to be more specific about how you implement a circuit in a target device. Morecomplex device architectures have many configurable features, and you may want to use these features in a particular way. You may want a precise powerup and preset operation or, in some cases, you may need to control internal elements. The circuit previously described (using architecture-independent dot extensions) could be described, for example, using detailed dot extensions in the following PSDabel-HDL source file (Figure 9): Figure 9. Detail one-bit synchronous circuit with inverted qout
module detail1 d1 Clk Toggle Ena Qout equations !Qout.D Qout.CLK Qout.OE device 'P16R8'; pin 1; pin 2; pin 11; pin 19 istype 'reg_D';
= Qout.Q & Toggle; = Clk; = !Ena; -> [Qout]) -> 0; -> 1; -> 0; -> 1; -> 0; -> .Z.; -> 1; -> .Z.; -> 0;
test_vectors([Clk,Ena,Toggle] [.c., 0 , 0 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 1 , 1 ] [0,0, 1 ] [.c., 1 , 1 ] [0,0, 1 ] end
This version of the design will result in exactly the same fuse pattern as indicated in Figure 5. As written, this design assumes the existence of an inverted output for the signal Qout. This is why the Qout.D and Qout.Q signals are reversed from the architecture-independent version of the design presented earlier.
52/162
2 Design considerations
UM0045
Note:
The inversion operator applied to Qout.D does not correspond directly to the inversion found on each output of a P16R8. The equation for Qout.D actually refers to the D input of one of the P16R8's flip-flops; the output inversion found in a P16R8 is located after the register and is assumed rather than specified. To implement this design in a device that does not feature inverted outputs, the design description must be modified. The following example (Figure 10) shows how to write this detailed design for the E0320 device: Figure 10. Detail one-bit synchronous circuit with non-inverted qout
module detail2 d2 Clk Toggle Ena Qout equations Qout.D Qout.CLK Qout.OE device 'E0320'; pin 1; pin 2; pin 11; pin 19 istype 'reg_D';
= !Qout.Q & Toggle; = Clk; = !Ena; -> [Qout]) -> 0; -> 1; -> 0; -> 1; -> 0; -> .Z.; -> 1; -> .Z.; -> 0;
test_vectors([Clk,Ena,Toggle] [.c., 0 , 0 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 0 , 1 ] [.c., 1 , 1 ] [0,0, 1 ] [.c., 1 , 1 ] [0,0, 1 ] end
This design would result in the same circuit and E0320 fuse pattern previously illustrated in Figure 8.
2.9
Using Don't Care optimization
Use Don't Care opt |
