Generic DE HDL Library Development Specification
Cadence Design Systems, Inc.
This document contains information that is proprietary to Cadence Design Systems, Inc. This information
is not to be disclosed, duplicated, or released to any third party without prior written permission from an
authorized representative of Cadence Design Systems, Inc. Any recipient of this document agrees to
make every reasonable effort to prevent the unauthorized use of the information contained in this
document.
DE HDL Library Development Specification
Revision 1.2
10/16/2008
Revision Block
Rev.
Date
Description
Changed by
Draft 0.0
2-15-2007
Cadence Draft.
Frank Winsor
Draft 0.1
5-4-2007
Draft Update
Frank Winsor, Chad
Saathoff
Draft 0.2
5-7-2007
Draft Update
Frank Winsor, Chad
Saathoff
Draft 1.0
8-10-2008
Draft Update
Frank Winsor
Draft 1.1
10-3-2008
Draft Update
Donna Pierce, Chad
Saathoff
Draft 1.2
10-16-2008
Draft Update
Chad Saathoff
Confidential
Page 2 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
TABLE OF CONTENTS
1
Introduction .........................................................................................................................5
1.1
Assumptions .................................................................................................................5
1.2
Reference Documents....................................................................................................5
2
General Description..............................................................................................................6
3
When to create a new symbol ...............................................................................................6
4
Building Concept symbols....................................................................................................6
4.1
Part Developer ..............................................................................................................6
4.2
Copying existing parts...................................................................................................6
5
Symbol and Pin Naming Conventions ..................................................................................7
6
Symbol View (Body Graphics).............................................................................................7
6.1
Grid ..............................................................................................................................7
6.2
Origin ...........................................................................................................................7
6.3
Size...............................................................................................................................7
6.4
Versions........................................................................................................................7
6.5
Recommended Text Sizing............................................................................................8
6.6
Pin Organization ...........................................................................................................9
6.6.1
Pin stubs.................................................................................................................9
6.6.2
Pin text...................................................................................................................9
6.6.3
Pin names............................................................................................................. 10
6.6.4
Power supply pins ................................................................................................ 10
6.6.5
No Connect Pins................................................................................................... 12
6.6.6
Pin number visibility ............................................................................................ 12
6.7 Body properties/attributes .............................................................................................. 13
6.7.1 PACK_SHORT property ........................................................................................... 13
6.8 Property location and syntax ........................................................................................... 13
6.9 Symbol Types and Their Requirements ........................................................................... 16
6.9.1 Multiple function (Gate) symbols (symmetrical) ....................................................... 16
6.9.2 Multiple Function Asymmetrical symbols.................................................................. 16
6.9.3 Schematic symbols (additional issues & requirements).............................................. 17
6.9.4 Single body (all pins shown) ...................................................................................... 18
6.10 Property values .............................................................................................................. 18
7.1 Package types ................................................................................................................. 20
Confidential
Page 3 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
7.2 Pin properties.................................................................................................................. 20
7.2.1 Pin Group property ................................................................................................... 20
7.3 Body properties............................................................................................................... 20
8 Part Table View ..................................................................................................................... 23
8.1 Key properties ................................................................................................................. 23
8.2 Injected properties............................................................................................................ 23
8.3 Identification of Key vs. Injected properties .................................................................... 24
8.4 Additional properties........................................................................................................ 24
Confidential
Page 4 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
1 Introduction
This document provides specifications and guidelines for the development and content of DE
HDL symbols libraries.. DE HDL symbol libraries generated, in accordance with this
specification, will support design verification and printed circuit board layout.
1.1 Assumptions
This guideline document assumes that the audience is familiar with the Cadence Library
development process, and the Cadence tools. This documentation is based upon the SPB16.01
releases of Cadence software. All guidelines have been developed to encourage use of the
standard Cadence applications in the PCB flow.
1.2 Reference Documents
Cadence PCB System Master Help
Cadence Online Documentation
Confidential
Page 5 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
2 General Description
DE HDL library elements consist of multiple views. Each view provides different information
about a library element. The symbol view contains the graphical representation of the element.
The chips view contains the logical to physical pin mapping for each package type of a
component. The part table view contains the physical part table file for a component/s.
3 When to create a new symbol
The librarian typically decides to create a new symbol based on the following criteria:
•
When a component has a different function, or a different number of logical pins from
existing symbols, a new schematic symbol must be created. For example, a voltage
regulator has three logical pins (in, out, ground), however, some voltage regulators
require two physical pins on the output. This type part actually has four logical pins (in,
out1, out2, and ground), and requires a different schematic symbol than the three-pin
version.
•
Components with the same function, and logical pins, but with different physical package
types (e.g., PLCC vs. SOIC) use one schematic symbol, and a chips file that describes
more than one symbol type (i.e. ls04 DIP and ls04 SOIC) or multiple part chips file.
4 Building Concept symbols
4.1 Part Developer
The Cadence Part Developer tool should be used as much as possible to avoid syntax and
formatting errors during the creation of the Symbol View, Chips View, and Part Table File View.
4.2 Copying existing parts
If a part, similar to the new one being built, already exists in a library, it is sometimes preferable
to copy the existing part and rename it as a starting point for the new part. This will save time by
eliminating the task of re-drawing graphic elements that are the same or similar.
Confidential
Page 6 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
5 Symbol and Pin Naming Conventions
Logical symbol names and pin names must follow Cadence naming rules for logical symbols.
The following rules should be used in symbol names and pin names.
•
Names may contain only alphanumeric characters and the underscore characters.
•
Names should not contain consecutive underscore characters or end with an underscore
character.
•
The maximum number of characters in a symbol name is 30.
NOTE: Use lower case letters. Concept will automatically change what is otherwise
acceptable.
6 Symbol View (Body Graphics)
The symbol view is the graphical image of the symbol. All symbols, in the library, have at least
one symbol view. Multiple versions of a symbol may be created. .
6.1 Grid
The default grid for a symbol is 0.100 inch. Pin should be on a grid in reference to origin
6.2 Origin
The symbol origin cannot fall on a pin. The default origin is the center of the part plus or
minus one grid.
6.3 Size
The maximum size of a symbol will be determined by what will comfortably fit on the selected
size schematic sheet, at the librarian’s discretion. The symbol width must be wide enough to
accommodate pin labels, side by side.
The symbol should be drawn to reflect what is shown in the part datasheet. When the datasheet
does not provide a symbol, the librarian’s discretion will take precedence.
Any unique requirements should be specified at the time the part request is made.
6.4 Versions
Symbol versions for different orientations of a cell may be created; these will be multiple symbol
views for certain library components. This eliminates the need to rotate the symbol when
instantiated. Concept can mirror a symbol about the Y-axis, but not the X. Because of this,
certain types of symbols will require more versions. For example, a resistor symbol only needs a
Confidential
Page 7 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
horizontal and vertical version, but a polar capacitor or diode or other discrete component, will
require three orientations: horizontal, vertical (positive pin up), and vertical (positive pin down).
Figure 1: Multiple symbol versions
6.5 Recommended Text Sizing
Sizing for text on the symbol is related to schematic sheet size
In general text should not be smaller than 0.050 inches tall.
$LOCATION and LOCATION properties should be at least 0.050 inches tall.
VALUE properties should be at least 0.050 inches tall.
All other body properties should be at least 0.050 inches tall, minimum.
PIN_NAME property should be at least 0.050 inches tall.
PIN_NUMBER placeholders should be at least 0.050 inches tall.
PACK_TYPE properties should be at least 0.050 inches tall.
Confidential
Page 8 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
6.6 Pin Organization
In the absence of design direction, Cadence recommends organizing pins such that inputs are on
the left, and outputs are on the right side of the symbol. Bi-directional pins may be placed on
either side, but the right side is preferred. Some control pins such as ENABLE, SET, and RESET
may be placed at the top or bottom.
Bit pin-order is MSB to LSB, from the top to bottom, left to right.
Example: Data<7..0> with 7 (highest numeric value) representing the MSB and 0 (lowest
numeric value) representing the LSB.
6.6.1
Pin stubs
Pin stubs are recommended to be 0.100 inches long for rectangular parts using a 0.100 inch
visible grid. Pass through pins are not recommended but are allowed when required for clarity
and ease of routing.
Draw low asserted, and active low, pins with 0.100 inch diameter circles.
Figure 2: Pin stubs
Analog and odd-shaped parts should have reasonable pin stubs based on their appearance. In all
cases pins must land on a grid.
6.6.2
Pin text
Pin text is used for graphical identification of pins. Pin text should be a minimum of 0.050 inches
tall, should be placed inside the symbol outline, and should be placed adjacent to the pin it
represents. Pin text should accurately identify the pin functions, while remaining as brief as
possible. The text size should be consistent within the part and throughout the library. Pin text is
entered in uppercase text and can be placed 0.020 inches in from the symbol borders.
Set the right side and top notes right justified and left side and bottom left justified. At the
librarian’s discretion, vertical pins may be labeled with vertical text. When possible, keep the pin
text horizontal, and right reading.
Confidential
Page 9 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
6.6.3
Pin names
All pin names must begin with an alpha character (to be HDL/VHDL compliant). Where possible,
use the pin function from the data sheet for pin names. Pin names are uppercase text. Pin names
must be unique. Low assertion and active low pins require either an asterisk “*” or a“_N”, at the
end of the pin function text.
Table 1: Example of Pin Names defines an example of pin names for the symbols types listed.
Table 1: Example of Pin Names
6.6.4
Symbol Type
Pin Function
Pin Name
Battery, Polar Capacitor
Positive
Negative
P
N
Diode, Zener, LED, etc.
(the anode is always pin 1)
Anode
Cathode
A
K
Transistor
Emitter
Base
Collector
E
B
C
FET
Gate
Source
Drain
G
S
D
Power supply pins
Power supply pins are defined one of two ways: as implicit pins (not shown on the symbol), and
explicitly shown on the symbol.
6.6.4.1 Implicit power pins
Implicit power pins pins are defined in the global pins section of Part Developer.
Although the preferred method is to specify power pins in the global pins section of Part
Developer, an exception can be made if the part requires additional hardware, (i.e., a shield with
grounded mounting holes used on some connectors). In this case the user may specify the extra
ground pins by using POWER_PINS or MERGE_POWER_PINS as an “additional” property in
the PTF row specifying the hardware.
6.6.4.2 Explicit power pins
If a component uses non-standard power supplies (e.g., an op amp) the librarian may add an
explicit power pin to the symbol, and use the POWER pin type definition in the chips.prt. Scalar
pin names must be unique; append a numeral to the VCC pin name, (e.g., VCC1, VCC2, VCC3,
etc).
See Table 2 for the exact properties of an explicit power pin.
Confidential
Page 10 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
Table 2: Pin type properties
Pin Type
ANALOG
Property and Value
Function
Tool Used By
PIN TYPE=’ANALOG’
Analog Pin
Packager XL
Bi-directional
Packager XL
NO_LOAD_CHECK=BOTH
NO_IO_CHECK=BOTH
ALLOW_CONNECT=TRUE
BIDIR
INPUT_LOAD=(lil, lih)
OUTPUT_LOAD=(lol, loh)
BIDIRECTIONAL=TRUE
INPUT
INPUT_LOAD=(lil, lih)
Input
Packager XL
OUTPUT
OUTPUT_LOAD=(lol, loh)
Output
Packager XL
TS
INPUT_LOAD=(lil, lih)
Tri-state
Packager XL
INPUT_LOAD=(lil, lih)
Tri-State
Packager XL
OUTPUT_LOAD=(lol, loh)
Bi-directional
OUTPUT_LOAD=(lol, loh)
OUTPUT_TYPE=(TS, TS)
TS_BDIR
OUTPUT_TYPE=(TS, TS)
BIDIRECTIONAL=TRUE
OC
OUTPUT_LOAD=(lol, loh)
Open Collector
Packager XL
INPUT_LOAD=(lil, lih)
Open Collector
Packager XL
OUTPUT_LOAD=(lol, loh)
Bi-directional
OUTPUT_TYPE=(OC, AND)
OC_BIDIR
BIDIRECTIONAL=TRUE
OUTPUT_TYPE=(OC, AND)
OE
OUTPUT_LOAD=(lol, loh)
Open Emitter
Packager XL
INPUT_LOAD=(lil, lih)
Open Emitter
Packager XL
OUTPUT_LOAD=(lol,loh)
Bi-directional
OUTPUT_TYPE=(OE, OR)
OE_BIDIR
BIDIRECTIONAL=TRUE
OUTPUT_TYPE=(OE, OR)
POWER
PIN_TYPE=POWER
Not listed on
NO_LOAD_CHECK=BOTH
POWER_PINS line of
NO_IO_CHECK=BOTH
chips.prt file.
Packager XL
ALLOW_CONNECT=TRUE
NC
PIN_TYPE=NC
Not listed on NC_PINS
NO_LOAD_CHECK=BOTH
line of chips.prt file.
Packager XL
NO_IO_CHECK=BOTH
ALLOW_CONNECT=TRUE
UNSPEC
NO_LOAD_CHECK = ‘BOTH’
Recommended for
NO_IO_CHECK = ‘BOTH’
connectors and
ALLOW_CONNECT = ‘TRUE’
discretes
Confidential
Packager XL
Page 11 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
GROUND
If the pin is in the body section
Packager XL
POWER_PINS =
(If the pin is in the
(GND:<pin number>);
body section)
GROUND_NETS = ‘<pin name>’;
GROUND
If the pin is in the pin section
Packager XL
‘<pin name>’:
PIN_NUMBER =
‘(<pin_number>)’
PINUSE = ‘GROUND’;
6.6.5
No Connect Pins
6.6.5.1 Implicit No-Connect pins
Implicit no-connect pins are defined in the global pins section of Part Developer.
If the component requires no-connect pins, based on selection of additional hardware
(MECH_PART) from the part table file (PTF), then the NC_PINS or MERGE_NC_PINS
property must be an “additional” property added to the PTF row corresponding to the selected
component/hardware. Reference: Cadence Online Help.
NOTE: Do not use the PINCOUNT property to define NC_PINS, they must be specified.
6.6.5.2 Explicit No Connect Pins
Explicit no connect pins (shown on the body) that have no electrical connection must not be
named NC. Scalar pin names must be unique; append a numeral to the NC pin name, (e.g., NC1,
NC2, NC3, etc). The appended numeral can be the corresponding pin number of the 'no connect'
pin for clarity.
Use the NC pin type definition in Part Developer.
6.6.6
Pin number visibility
If there is a requirement to manually place pin number in a location other the default location use
the placeholder property $PN=?. Pin-number property placeholder text should be a minimum of
0.050 inches tall. Place pin-number placeholders on pin stubs. Set the position, rotation, and
justification as follows:
Right side pin numbers are left justified.
Top pin numbers are left justified and may be rotated to read from the right side of
the page if space is limited.
Left side pin numbers are right justified.
Top pin numbers are left justified and bottom pin numbers are right justified, and
may be rotated to read from the right side of the page if space is limited.
Confidential
Page 12 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
In the case where component symbols that require no visible pin numbers have the property
$PN=# attached to the pin. Place the property close to the pin. Typically these component
symbols should have invisible pin numbers: resistors, capacitors, diodes, and transistors
(including FETs).
6.7 Body properties/attributes
The property placeholders, listed in Table 3: Global body properties, are common to all schematic
symbols, and must be included, as defined, on each symbol.
In addition to the global properties, component property placeholders may be required based on
the part family. For example, a resistor may require additional properties such as VALUE, TOL,
etc. In addition, in some cases a component symbol may require a DEVICE property and or a
simulation property be attached to the body. See Table 3: Global body properties
Verify Global properies (That are used throughout library)
Property Name
Visibility
Default Value
$LOCATION
Value
‘?’
PATH
None
‘?’
See Section 7.3 for additional body properties.
6.7.1 PACK_SHORT property
The PACK_SHORT property can be used on the body view and/or in the schematic when
multiple pins have the same logical function and the user wants to short them during packaging.
Multiple groups of pins, each group having two or more pins, can be shorted. The user must use
logical schematic pin names with this property. Example: PACK_SHORT = (A, B) (C, D, E) A,
B and C, D, E representing the logical pin names of 5 pins. In this example pins A, B would be
shorted together and pins C, D, E would be shorted together.
(This does not apply to power and ground pins. Specified as POWER_PINS).
6.8 Property location and syntax
Whenever practical, the $LOCATION property should be placed where it will be visible in a
location common to all parts. For example, inside the symbol body, center justified. In cases
where the part is too small to fit the $LOCATION property, the property should be placed at the
top, outside the symbol body, center justified. Use a ‘?’ in the value field. The PATH placeholder
is usually placed above, and to the right of the symbol origin. It is usually invisible.
For other types of components, place $LOCATION property to the right, or top of the symbol.
Keep the placeholders on at least a 0.050 inch grid. All other (visible) placeholder properties
should be placed below the $LOCATION property. Set the text justification for the property:
Right side left justified.
Left side right justified.
Top or bottom center justified.
Confidential
Page 13 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
Properties with no display setting (i.e., invisible) should be placed close to the origin of the
symbol, above the PATH property placeholder.
Figure 3, below, shows the property location and visibility for discrete components. Figure 4, on
the next page, shows the property location and visibility for IC components.
Figure 3: Property location for discrete components
Confidential
Page 14 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
Figure 4: Property location example for IC components
PIN NAME
FEPROM 2MX8
A<20>
A<19>
A<18>
A<17>
A<16>
A<15>
A<14>
A<13>
A<12>
A<11>
A<10>
A<9>
A<8>
A<7>
A<6>
A<5>
A<4>
A<3>
A<2>
A<1>
A<0>
A20
A19
A18
A17
A16
A15
A14
A13
A12
A11
A10
A9
A8
A7
A6
A5
A4
A3
A2
A1
A0
WE*
OE*
CD*
RP*
WE
OE
CD
RP
DQ7
DQ6
DQ5
DQ4
DQ3
DQ2
DQ1
DQ0
x
TEXT (VIS)
DQ<7>
DQ<6>
DQ<5>
DQ<4>
DQ<3>
DQ<2>
DQ<1>
DQ<0>
PATH=?
PACK_TYPE=?
OTHER=?
RY/BY
NC
GND1
GND2
INVISIBLE
PROPERTIES
PLACED NEAR
ORIGIN
RY/BY
NC1
GND1
GND2
PIN_TEXT (VIS)
?
$LOCATION=? (VIS)
Confidential
Page 15 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
6.9 Symbol Types and Their Requirements
Multiple function and asymmetrical symbols have specific requirements.
6.9.1 Multiple function (Gate) symbols (symmetrical)
Versions of symbols that have one logical function repeated multiple times in the package may be
created such that an individual function or the entire package can be instantiated. When multiple
symbols exist, representing single and multiple bit versions, the single bit version will be first,
followed by the increasing bit versions. Versions that represent the entire package or multiple
sections require the HAS_FIXED_SIZE property.
Creation of a whole package version is not recommended unless specifically required; some
components are very seldom instantiated as a whole package (e.g., a quad op amp).
6.9.2 Multiple Function Asymmetrical symbols
An asymmetrical symbol is a part with multiple functions where the sections are not
interchangeable. Asymmetrical symbols are created for large pin-count components, or, for
components with logically dissimilar sections.
Each symbol version contains a portion of the logical pins in the component. For example: a relay
component contains a coil and contacts. To aid the schematic flow, the contacts, and coil should
be separate symbols, but need to package into one part; the sections of the relay are logically
dissimilar. An asymmetrical symbol should be created for the relay.
For asymmetrical symbols where each symbol version represents only one slot, (a split part),
requires the body property SPLIT_INST=TRUE be placed on every version in the symbol view.
Large pin-count devices such as ASICs will have a note placed inside each body version at the
bottom to identify which section it represents of the total sections (e.g., (1 / 4) would identify
section 1 of a 4 section part). See Cadence Online Help.
To create and use split parts, you need to add either the SPLIT_INST and $LOCATION properties
or the SPLIT_INST_NAME property on the symbol/chips. This can be done through Tools > Setup
In the “Split Parts” meu area, select the radio button for “Use SPLIT_INST and $LOCATION.
Confidential
Page 16 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
6.9.3 Schematic symbols (additional issues & requirements)
The following requirements must be met when creating schematic symbols:
•
The reference designator for the component must be displayed.
•
There must be enough room on the schematic to connect wires to all pins of the
symbol, while still allowing room for pin numbers, bus rippers (bit taps), and signal
names
Confidential
Page 17 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
The minimum wire-to-wire spacing on the schematic is 0.100inch.
Wires that are run perpendicular to a pin, must allow room for the pin number
plus 0.050 inch. If the wire is a bus, then additional room must be made for the
bus ripper (bit tap) and the bit number. The bit number and pin number must
have at least 0.100inch between them
•
The component must be selectable from the “parts browser”, for instantiation on the
schematic. This means that there must be a physical part table file (PTF) for each
component.
To solve the problems associated with large pin-count devices, several styles of schematic
symbols will be used. Each has a purpose, and is presented in descending order of preference
(i.e., if the symbol fits the criteria for the first solution, do not use the second, third, etc.).
6.9.4 Single body (all pins shown)
This is the preferred symbol style. However, typically it will only accommodate components with
less than 256 logical pins (the actual pins shown on the symbol). The 2nd requirement listed in
section 6.8.3 will drive the actual maximum number of pins that can be put on a symbol.
The single body symbol may be created with pins on only two sides of the component (left/right,
or top/bottom), or with pins on all four sides. Do not create symbols with more than four sides for
symbol pins.
Pins of related functions should be grouped together when possible, with 0.200 inch gaps between
the groups. Gaps improve readability, but consume space. Consider eliminating some of the gaps
to keep the symbol a single body. If readability becomes an issue, then a single body symbol is
inappropriate for the component. Review the criteria for the other solutions and choose the most
applicable.
6.10 Property values
Property values are strings. They must be entered consistently. The values .01UF and 0.01U may
seem equivalent, but they are not equal.
Add a zero (0) to the beginning of all property values less than one (e.g., 0.01UF not .01UF).
Use a standard set of abbreviations such as those found in Table 3 for electrical property values:
Confidential
Page 18 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
Table 4: Units for Properties
Confidential
Page 19 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
7 Package / Chips View
This chips view data description is for informational purposes only. The chips view is
created by and updated within Part Developer.
The chips view (chips.prt file) contains the physical information for a package. It consists of (at
least) one primitive section. Each primitive contains a pin section and a body section.
Every pin (coinciding with each pin on all body versions) must be listed in the pin section, and
must have a unique pin name along with the corresponding physical pin numbers. Do not use
leading zeros in pin numbers, (e.g., use A1 not A01).
•
Asymmetrical parts are defined in the pin section and have unique pin names and pin
numbers for each different asymmetrical section.
7.1 Package types
The PACK_TYPE property may be used to specify different physical packages, possibly with
different pin mapping or pin numbers, using the same logical symbol and pin names. This is done
by defining multiple primitives in the chips file. Each unique package type (PACK_TYPE)
requires an entry in the chips.prt file, and may require a unique primitive pin and body section for
each different mechanical pin combination.
7.2 Pin properties
Pin location may be defined using the drop down lists in the “Add Pin” window in Part
Developer, based on the pin type information from the vendor data sheet. Include pin loading
information if readily available; substitute an asterisk (*) for unknown values.
NOTE: Input and output load currents are expressed in milliamperes.
7.2.1 Pin Group property
The PIN_GROUP property may be added to swappable pins. Swappable pins are pins that
have identical functionality and are interchangeable. (i.e. the pins of a resistor or non polarized
capacitor). Resistor packs sometimes have swappable pins in them, but are often built as
functions and the functions are swapped instead of the pins.
Example: A sip8, which has a common power pin and 7 resistors in it. The 7 resistors are
not swappable pins but swappable functions each with a common power pin.
7.3 Body properties
The following properties are contained within in the body section of the chips.prt file:
•
PART_NAME (required)
Same as the primitive name. This property specifies the physical name of a logical
part.
• CLASS (required) describes the broad category of the component and has
one of the following values:
DISCRETE - for discrete components such as resistors, capacitors, and
so on;
Confidential
Page 20 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
IC - for semiconductor components;
IO - for passive I/O components such as terminals, connectors, and so
on.
•
PHYS_DES_PREFIX
The value will depend on the reference designator prefix for the part. The single
pin version of a connector will have a hard location property attached to the body
to force manual location assignments in the schematic.
Table 5: Body properties
Property
PART_NAME
CLASS
Value
Use
Same as the
primitive name
This property specifies the physical name of a logical part.
DISCRETE
IC
IO
Describes the broad category of the component
Confidential
Page 21 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
Table 6 : Body Properties – Typical Physical Designator Prefixes
Property
PHYS_DES_PREFIX
Component Type
Prefix
Battery, Battery Holder
Board Standoff
Busbar
Cable
Capacitor, Variable
Choke
Circuit Breaker
Clearance Pad
Coil
Connector
Controlled Rectifier
Converter
Crystal
Delay
Diode
Fence Ground
Ferrite
Fiducial
Filter
Fuse
Ground Point
Inductor
Inductor Pack
Integrated Circuit
IC Socket
Jumper Wire
Lighting Device (LED,
Neon, Etc.)
BT
BS
BB
W
C
L
CB
CP
L
J
CR
MG
Y
DL
D
FG
L
FD
FL
F
GP
L
LP
U
U
W
DS
Confidential
Component Type
Prefix
Loudspeaker
Moire, Target
Motor
Oscillator
Potentiometer
RC Filter Network
Relay
Resistor, Variable
Resistor Pack
Rheostat
Shield
Socket
Solder Bridge
Surge Arrester
Surge Protector
Switch, Contact (including DIP
switch)
Thermistor
Test Point
Tooling & Mounting Holes
(from PCB)
Tooling & Mounting Holes
(from Schematic)
Toroid
Transformer
Transducer
Transistor
Voltage Regulator
Zener Diode
Other (assembly)
LS
ZM
B
G
R
RC
K
R
RP
R
SH
J
W
E
SP
S
R
TP
ZH
ZT
L
T
MT
Q
VR
DZ
Z
Page 22 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
8 Part Table View
Part table view (Part Table File) provides for selecting and annotating key properties to a part in
the schematic, and for passing or injecting additional properties into the net list for Allegro and
other tasks where properties are needed.
8.1 Key properties
Key properties are annotated to the symbol when placed in the schematic. Any changes made to
key properties after placement requires the symbol to be replaced.
Key properties will appear to the left of the equal sign on a part row in the part table file. Key
properties typically represent parameters for component selection (e.g., value, tolerance, type, and
pack_type). Key properties must be chosen carefully. Once a library part is released, multiple
steps are required to make changes without affecting designs in progress. Properties should be
chosen that impart information required on the schematic.
The combined string of all key property values for a part row record must be unique within a
given part table file. It is suggested that Key properties be kept to the minimum required to meet
the above criteria of uniqueness and required schematic annotation.
Key property values may not be blank. A placeholder must be present.
The typical properties that are Key include:
•
PART_NUMBER (Company part number)
•
VALUE (For Capacitance, Resistance, etc)
•
Tolerance ((For Capacitors, Resistors, etc)
8.2 Injected properties
Injected properties further define the unique characteristics of each line definition of a
part. Injected properties appear to the right of the equal sign on a part row in the part table file.
Packager-XL passes these properties to Allegro in the physical netlist, - for example, part
descriptions, manufacturer and manufacturer part numbers, costs, or package types. You may
change, add, or delete injected properties in the part table without affecting the schematic because
when the schematic is packaged, the part table definition of the injected property takes
precedence over the instance definition.
The typical properties that are injected are:
•
DESCRIPTION (Company part description)
•
JEDEC_TYPE (Company footprint name)
•
MFG (Manufacturer)
•
MFG_PN (Manufacturer’s part number)
•
STATUS (A qualification or obsolescence related indicator)
•
ROHS (Environmental complance)
Confidential
Page 23 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
8.3 Identification of Key vs. Injected properties
The identification of which properties should be key and which should be injected must be
considered within the framework of how the Cadence tools utilize these and the time impact to
the library process as additional key properties are selected.
As a core requirement, the set of key property values must form a unique record within the ptf
file. As a result, the use of a company part number as a sole key property is only viable when the
company PN is unique for each record instance. If not unique, additional key properties must be
added to create a unique property value string.
8.4 Additional properties
A few select components will require additional properties to be injected. These properties are
injected . They are added to the PTF as “additional properties.” They are as follows:
• ALT_SYMBOLS indicates additional Allegro symbols available during
placement
• MECH_PART indicates additional mechanical parts are used with this
part
Part table entries for component types will typically contain the following properties:
Table 7 Examples of Part Table Data
Device
Key Properties
Injected Properties
Capacitor
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
VALUE = uF, pF
ROHS = Y/N
VOLTAGE = Voltage Rating,
STATUS =
TOLERANCE = Tolerance
Connector
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
ROHS = Y/N
STATUS =
DESCR= Text description
Diode
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
ROHS = Y/N
STATUS =
DESCR= Text description
or
VOLTAGE = Voltage Rating
CURRENT = Current Rating
Confidential
Page 24 of 25
ConceptHDL Library Development Specification
Revision 1.2
10/16/2008
Device
Key Properties
Injected Properties
Ferrite Bead
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
VALUE = Impedance
ROHS = Y/N
STATUS =
FREQUENCY = Value at Z rated
CURRENT = Current Rating
DCRES = DC resistance Max.
Inductors
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
VALUE = uH
ROHS = Y/N
CURRENT = Current Rating
STATUS =
TOLERANCE = Tolerance
Ics-General
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
STATUS =
ROHS = Y/N
DESCR= Text description
Ics-Memory
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
STATUS =
ROHS = Y/N
DESCR= Text description
or
TYPE
ORGANIZATION
VOLTAGE
Resistor
PART_NUMBER = Company Part Number JEDEC_TYPE = Allegro Footprint
VALUE = Ohms
ROHS = Y/N
WATTAGE= Wattage Rating
STATUS =
TOLERANCE = Tolerance
Confidential
Page 25 of 25