|============================================================================== | RAIL (Rule Augmented Interconnect Layout) Specification | Version 1.1 July 11, 1996 | | The RAIL Specification defines a standard set of data types useful for the | design of printed circuit boards containing high-speed digital logic. |============================================================================== | Statement of Intent: | | In order to enable an industry standard method to electronically transport | high-performance design guidelines between silicon vendors, PCB layout | software vendors, and hardware design teams, this specification is proposed. | RAIL's goal is to enable automated "Rule Augmented Interconnect Layout". | "Rules" in this case refer to electrical constraints (flight times, skews, | overshoots, etc.) and guidelines essential to proper operation of a | digital design. These rules "Augment" the basic connectivity requirements | of an "Interconnect Layout", providing the missing data needed to derive | a robust high-performance design. | | To properly superimpose electrical constraints onto connectivity | requirements, RAIL assumes some level of integration between PCB layout | software and an analog simulation environment. However, standalone PCB | layout packages (no simulation available) may still find portions of a | RAIL file useful. | | A RAIL file is primarily a container for electrical design guidelines for | a given digital hardware design (schematic). Logical connectivity (netlist) | and mechanical information (placements, footprints) will enter the EDA | environment through other standard, previously defined mediums. RAIL files | may be developed by: | | 1) Silicon Vendors - desiring to communicate suggested use of components | 2) Hardware Design Teams - needing to document their design assumptions | 3) EDA Tool Vendors - seeking to demonstrate or enhance their capabilities | | Whatever its origin, a RAIL file must normally be tailored to a given | hardware design. For example, silicon vendors may release a standard | application design package including a RAIL file. But as this design | is modified/customized, changes must be reflected in the RAIL file. | This concept is illustrated in the following diagram. | | Silicon Vendor's Hardware | typical design development team's | representation unique design | | constraints | | | | V V | +-----------+ +------------+ | | Generic | | Design- | Load | | RAIL |------>| Specific |-------> into | | file | | RAIL | EDA tool | +-----------+ +------------+ | | RAIL file constraints are normally simulated and judged using component | IBIS (I/O Buffer Information Specification) models. IBIS models | conveniently contain sufficient detail both to model PCB net drivers | and receivers, and to measure their performance. RAIL information then | provides sufficient detail to judge the acceptability of that measured | performance. Like IBIS, the RAIL format must be both human readable AND | easily parsed by software. | | It is assumed that a RAIL file is one element of a design database | required to derive a robust physical implementation. Other elements, | mentioned throughout this specification, include the following: | 1) Schematic - original design drawing showing logical connectivity | 2) Netlist - normally compiled from the schematic, it contains a | complete ASCII text file of all logical connections | 3) Footprints - the mechanical representation of components | 4) Placement - orientation of components on a printed circuit board (PCB) | 5) PCB Fab - includes certain materials and mechanical tolerances | 6) Artwork - physical circuit connections, derived by the layout process | 7) Assembly - physical realization of the design | Normally, RAIL is combined through design tools with items 1 through 5 | to derive a manufacturable artwork and assembly (items 6 and 7). | | The RAIL Specification was originally developed at the PCI Components | Division of Intel Corporation for the purpose of clearly communicating | the design guidelines for the Division's line of high-performance | Pentium(R) class platform solutions. It was cooperatively revised | to Version 1.0 RAIL Specification with the help of the EDA | Software vendors. | | Through additional cooperative efforts and formal processes, Version 1.1 is | issued with several minor textual and technical revisions. | |============================================================================== | General syntax rules and guidelines for ASCII RAIL files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. File names must be all lower case. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved name, used with power supply pins, | GND - reserved name, used with ground pins, | NA - used where data not available. | | 3) File names used in the file must only have lower case characters to | enhance compatibility between operating systems and must conform to | UNIX and DOS rules. (The length of a file name must not exceed eight | plus three characters and it must not contain special characters that | are illegal in UNIX and DOS). Also, the exclamation mark "!" | character must not be used in a file name. | | 4) The RAIL file normally has no more than 80 characters per line to aid | its display/readability. However, more than 80 characters per line is | allowed when necessary. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment Char] to any other character. The [Comment Char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. | | 7) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in subparameter names. Spaces can be used on either side | of equal "=" signs when associating values with subparameters. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | If no scaling factors are specified the appropriate base units are | assumed. (These are volts, amperes, ohms, farads, henries, hertz, and | seconds.) Parsers should look at only one alphabetic character after a | numerical entry, therefore it is enough to use only the prefixes to | scale the parameters. However, for clarity, it is allowed to use full | abbreviations for the units, (e.g., pF, nH, mA, mOhm). In addition, | scientific notation IS allowed (e.g., 1.2345e-12). | | 9) Wide signal bundles, such as data buses, will be denoted by the net | name followed by the largest and smallest numerical signals enclosed | in parenthesis and separated by a colon. Using this nomenclature | assumes that all consecutive nets exist and are intended. For | example, HD(7:0) refers to all nets HD7, HD6, HD5, HD4, HD3, HD2, | HD1, HD0. Alphanumerics may be used on either side of the parenthesis, | such as C_BE(3:0)#. Expanded nets that must be bracketed (e.g., HD[7], | HD<7>, or HD(7)) can be denoted. For example: | HD[(7:0)] refers to signals HD[7], HD[6], ..., HD[0] | HD<(7:0)> refers to signals HD<7>, HD<6>, ..., HD<0> | HD((7:0)) refers to signals HD(7), HD(6), ..., HD(0) and so on. | It is the responsibility of the originator of the RAIL file to ensure | that the expanded syntax matches that of the schematic netlist. | |10) Nets With Series Elements. Defined keywords [Group Nets], [Topology], | [Clocks], [Clock Skew], [Edge Sens], and [Budgets] may refer to signal | nets that contain "series elements". Series elements (such as | resistors, inductors, diodes, jumpers, connectors, etc.) | normally cause a single connection or "electrical net" to have two | or more net_names in a schematic or netlist. In these cases, | the RAIL file will seemingly refer to only one section of a net, when | actually the entire "electrical net" is intended. The burden is | placed on the EDA software to recognize these situations, and apply | the data in these keywords to the larger "electrical net". | |11) RAIL file terminology glossary: | RAIL - acronym for Rule Augmented Interconnect Layout | RAIL file - an ASCII file of electrical constraints in RAIL syntax | component - a physical electronic device, used in a digital design | generic_name - the generic name given to components in a RAIL file | group - a group of nets or components that have shared constraints | group_name - the name of a group in a RAIL file | net - a logical connection, that may or may not have a | physical instantiation | net_name - the alphanumeric name given to a net (signal) in both a | RAIL file and a netlist file. In many places in a RAIL | file either net_name or group_name can be used to apply | constraints to one net or a group of nets. | keyword - syntax enclosed in square brackets [], used to mark | the beginning of a new RAIL-defined data type (and, | the end of the last one). | PCB - Printed Circuit Board | EDA - Electronic Design Automation | IBIS - I/O Buffer Information Specification | IBIS Model - a component model written in IBIS syntax | | Portions of this text are similar to the IBIS Specification, and are | reprinted with permission from the Electronic Industries Association. Text | from ANSI/EIA 656 "Input/Output Buffer Information Specification, (C) 1995." |============================================================================== | K E Y W O R D D E S C R I P T I O N S B E G I N H E R E |============================================================================== | Keyword: [RAIL Ver] | Required: Yes | Description: Specifies the RAIL template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [RAIL Ver] must be the first keyword in any RAIL file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |------------------------------------------------------------------------------ [RAIL Ver] 1.1 | Used for template variations | |============================================================================== | Keyword: [Comment Char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment Char] keyword. The following | characters may not be used: A B C D E F G H I J K L M N O P | Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u | v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + - | : { } ( ) ! | Other Notes: The [Comment Char] keyword can be used throughout the file, as | desired. |------------------------------------------------------------------------------ [Comment Char] |_char | |============================================================================== | Keyword: [File Name] | Required: Yes | Description: Specifies the name of the RAIL file, "filename.ral". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ral". |------------------------------------------------------------------------------ [File Name] newdesgn.ral | |============================================================================== | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ral file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x file contains early design cycle targets only | 1.x parameters simulated as accurate in a real design | 2.x parameters sanitized against physical hardware | 3.x mature product, no more changes likely | The revision level is limited to 20 alphanumeric characters, | and must not contain spaces. |------------------------------------------------------------------------------ [File Rev] 1.0.A3 | Used for .ral file variations | |============================================================================== | Keywords: [Date] [Source] [Notes] [Disclaimer] [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: Information following these keywords can contain blanks, and | be of any format. The [Date] keyword argument is limited to a | maximum of 40 characters. | | Because RAIL file writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools must make this information | available. Derivative files must include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative files verbatim. |------------------------------------------------------------------------------ [Date] July 11, 1996 | The latest file revision date | [Source] Put originator and the source of information here. For example: From design package generated at Intel. Internally derived at ACME Hardware. Demonstration file assembled EDAxyz. | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information provides basic design guidelines and is not guaranteed. | May vary by design | [Copyright] Copyright 1996, XYZ Corp., All Rights Reserved | |============================================================================== | P R E A M B L E S E C T I O N E N D S H E R E |============================================================================== | Keyword: [RAIL Title] | Required: Yes | Description: Marks the beginning of the RAIL description of the printed | circuit board design named after the keyword. | Usage Rules: The RAIL Title must be defined by the originator of the | RAIL file, using any appropriate nomenclature. The | length of the RAIL Title must not exceed 60 characters, | and blank characters are allowed. Only one [RAIL Title] | can be used in each RAIL file. | Other Notes: Several keywords that are described below must be positioned | in the following order so that definitions are presented | before usage: | [Unit Length] Required | [Stackup] Optional | [Map Table] Required | [Multiboard] Optional | [Group Nets] Optional | [Group Parts] Optional | [DC Nets] Optional | [Trace Char] Required | The remaining keywords except [End] may be in any order | following [Trace Char]. The final keyword in the file | must be [End]. |------------------------------------------------------------------------------ [RAIL Title] Pentium(R)_Pro_Processor Reference_Design_Kit | |============================================================================== | Keyword: [Unit Length] | Required: Yes | Description: Defines the base unit of length, inch or meter. | Usage Rules: The [Unit Length] must be followed by either "inch" or | "meter" in order to specify the base unit of length. Lengths | described later in the file (for trace length, width, height, | and velocity) will use scale factors that assume the base unit | specified here. Only one [Unit Length] keyword can be used | in a single RAIL file. |------------------------------------------------------------------------------ [Unit Length] inch | base unit of length throughout this file is inches | (e.g., "W=6m" is a 6 milli-inch trace width, or 6 mils) | "[Unit Length] meter" would mean "W=6m" is 6 millimeters | |============================================================================== | Keyword: [Stackup] | Required: No | Description: An ASCII representation of a typical PCB construction | ("stack-up") that could be used for the board's fabrication. | Sub-Params: H (Height), W (Trace Width), ER (Dielectric Constant). The | "H" subparameter is implied only ("H=" does not appear in file) | Usage Rules: List an example board stack up, using height, width, and | dielectric constants as shown. Each line represents a layer | of air, metal, or dielectric. The PCB stackup must be | ordered (top to bottom) to match a view seen by a 2-D | cross-section of the fabrication. Each layer must use one | of the following syntaxes: | (1) "AIR:" - followed by no subparameters | (2) "SIG:" - followed trace height_value and "W="width_value | (3) "DIEL:"- for dielectric, followed by height_value and | "ER="dielectric_constant | (4) "PLANE:"- followed by only metal height_value | Height measurements reference that layer only (i.e., from | bottom of upper layer to top of lower layer, not centerlines). | | Other Notes: If a layer is a PLANE but also may have signals, it should | be listed as a PLANE layer. Simulation software must examine | its physical structure to properly evaluate its electrical | characteristics/behavior. |------------------------------------------------------------------------------ [Stackup] | a typical 6 layer PCB is shown |layer height W/ER AIR: | no entries following "AIR:" SIG: 1.4m W=6m | "[Unit Length] inch" so "W=6m" is 6 mil wide traces DIEL: 6m ER=4.8 | 6 mils between signal layer and power plane PLANE: 1.4m | "PLANE:" layers only have height_value DIEL: 18m ER=4.8 | 18 mils to inner signal layer SIG: 1.4m W=6m | trace height (often called "thickness") is 1.4 mils DIEL: 6m ER=4.8 SIG: 1.4m W=6m DIEL: 18m ER = 4.8 | spaces OK around "=" sign PLANE: 1.4m | dielectric constant (ER) is 4.8 throughout DIEL: 6m ER=4.8 SIG: 1.4m W=6m AIR: | |============================================================================== | Keyword: [Map Table] | Required: Yes | Description: Maps a physical component (reference designator) to the | generic component name used in the RAIL file, its | model file name, and a part name. Though it can contain | an exhaustive Bill Of Materials, it is not required to. | Usage Rules: The Map Table must consist of 4 columns, in this order: | ref_des, generic_name, model_filename, part_name. | The ref_des and generic_name must not exceed 10 characters | each. The model_filename should be less than 17 characters, | but this is not required. The part_name may be | up to 40 characters long, and contain spaces. Consequently, | everything after the first three columns up to the end of the | line, excluding comments, must be taken as the part_name. | | USE OF NA. "NA" can not be used in the ref_des column. "NA" | can be used in any of the other columns, as desired, but it | can not be used in the last three columns of any one line | at the same time. Use "NA" to ensure that there are four | columns of data in each line of the [Map Table]. | | The model_filename may reference any model format understood | by the EDA software in use (e.g., xx.ibs, xx.mod, xx.mdl). | The model_filename column may append one extra defining file | by using the "!" character, without spaces. (For example, | pld22v10.ibs!my_prog1.jed defines both the general model file | and the JEDEC file that defines pins as inputs, outputs, etc.) | | The same model_filename and/or generic_name can be associated | with multiple reference designators. Also, it is acceptable | to use the same ref_des more than one time, provided that the | generic name remains the same. This allows multiple component | models to be applied/tested in a given in a certain location | (ref_des). When this occurs, EDA software will use the model | in the first listing of a ref_des as the default model. | Other Notes: The formation of a Map Table must track a certain schematic | and physical layout, and modified as physical locations | change through back-annotation or other means. Reference | designators must match components called out by the netlist | that the RAIL file is applied to. When EDA software needs to | differentiate between devices (e.g., display waveforms at | various SRAM receivers) unique names should be generated by | appending the ref_des to the generic_name. | | The part_name is normally used to specify a particular | component when the model_filename contains more than one | component. When referencing an IBIS model that contains | multiple components, the part_name column should contain the | text string following the [Component Name] keyword in the | IBIS file. If the model_file contains only one component, | it is acceptable to place "NA" in that column. If any other | item in the table is not available (e.g., no IBIS file | exists), that entry must use the reserved word "NA". |------------------------------------------------------------------------------ [Map Table] |ref_des generic_name model_filename part_name |------- ------------ -------------- ------------ U1 CPU cpu23.ibs NA | 1 comp. in .ibs file U2 SRAM sram_lib.mod m4998fjnp | non-ibis model file U3 SRAM sram_lib.mod m4998fjnp | OK to use names twice U4 TAG_SRAM sram_lib.mod m4925tknm | same model file, dif. part U10 TSC 82434fx.ibs NA U13 TDP 82433fx.ibs NA U24 DRAM_Bfr 74f245.dml NA | U24 has part options | v----------- However, note that generic_name must remain consistent. U24 DRAM_Bfr nat_fast.ibs s74f245jk-a | alternate 245 for U24 U24 DRAM_Bfr nat_fast.ibs s74f1245jk | another one U24 DRAM_Bfr nat_fast.ibs s74f245ts-a | another package option U24 DRAM_Bfr 3v_logic.mdl idt163245nkj | a 3.3V option U48 CTL_PLD pld.ibs!a1.jed mc22v10a-2 | prog file append to .ibs J10 SIMM1 NA NA | just need gen_name here J11 SIMM2 NA NA J12 SIMM3 NA NA U25 DRAM 16m2sx32.ibs jf1644 nk8b | spaces OK in part_name D12 DRAM_Diode 1n4148j.spi NA | |============================================================================== | Keyword: [Multiboard] | Required: No | Description: Allows other PCB assemblies to be connected to the design / | assembly described by the current RAIL file. | Usage Rules: There must be three columns of data following this keyword: | (1) out_going ref_des, 10 characters max, lists the ref_des | of a connector/header that goes off-board. "Out_going" | is from the perspective of the board addressed by the | RAIL file, irrespective of the direction of signals. | (2) in_going ref_des, 10 characters max, lists the ref_des | of the mating connector/header on another module. | "In_going" is from the perspective of another board | described external to the RAIL file, irrespective of the | direction of signal travel. | (3) assembly_name, 50 characters max, could simply be the | RAIL file name of the associated assembly referenced by | the in_going ref_des. Other uses of this 50 character | field are EDA software dependent, and spaces are allowed. |============================================================================== [Multiboard] | out_going in_going assembly | ref_des ref_des name | --------- -------- ------------------------------------------------------- J22 P39 dramdimm.ral J18 J21 coastmod.ral coast2a.job | pointer to an artwork file J31 PA1 pci_card.ral J2 P19 isa_card.ral | |============================================================================== | Keyword: [Group Nets] | Required: No | Description: Used to define a group of nets that will have shared | attributes. | Usage Rules: The [Group Nets] keyword must be followed by the group_name | and a list of group_names and/or net_names in that net group. | Groups within groups are optional, but if they exist they must | be listed immediately following the group_name. Each group in | a group must have its own [Group Nets] keyword elsewhere in the | RAIL file, where it is listed as the group_name (followed | by its own set of group_names and/or net_names). There is no | specified limit to the number of group_names and/or net_names | in a group. Group_names and net_names are separated by white | space (space, tab, linefeed). All group_names and net_names | must be unique within a single RAIL file. | Other Notes: A RAIL file will normally contain numerous net "Groups". | Allowing the nesting of groups provides a simple | mechanism to partition nets. One example use might be | to group nets with similar timings, but break out a small | nested group with unique topology assumptions. |------------------------------------------------------------------------------ [Group Nets] group_name group_name1 group_nameN net_name1 net_name2 net_nameN | [Group Nets] Host_Bus | net group with one nested group listed first Host_Addr HD(63:0) HDP(7:0) BRDY# NA# ADS# | [Group Nets] Host_Addr | nested group is defined here HA(31:0) | [Group Nets] PCI_Bus | net group with two nested groups Arb_sigs Int_sigs AD(31:0) FRAME# TRDY# IRDY# STOP# | |============================================================================== | Keyword: [Group Parts] | Required: No | Description: Used to group components. | Usage Rules: The [Group Parts] keyword must be followed by the group_name | and a list of group_names and/or generic_names in that group. | Groups within groups are optional, but if they exist they must | be listed immediately following the group_name. Each nested | group must have its own [Group Parts] keyword in the RAIL | file, where the nested group is listed as the group_name | (followed by its own group_names and/or generic_names). | There is no specified limit to the number of group_names | and/or generic_names in a part group. Group_names and/or | generic_names are separated by white space (space, tab, | linefeed). All group_names and generic_names must be unique | within a single RAIL file. Generic_names are limited to a | maximum of 10 characters. |------------------------------------------------------------------------------ [Group Parts] DRAM_SIMMs | a group of components (generic_names), not nets SIMM1 SIMM2 SIMM3 SIMM4 | |============================================================================== | Keyword: [DC Nets] | Required: No | Description: Used to define DC voltages of various net_names. | Usage Rules: [DC Nets] must be followed by two columns of data, | net_name and DC_voltage. NA is not allowed in either | column. For DC voltages, "+" should be used for positive | voltage, and "-" must be used for negative. If no sign | is stated, "+" is assumed. The DC_voltage is limited | to a maximum of 20 characters. |------------------------------------------------------------------------------ [DC Nets] |net_name DC_voltage 5V_Power +5V +3.3V 3.3V | DC Voltage = +3.3V, "+" is default V_tt 1.5V Neg_12v -12V | must use "-" sign | |============================================================================== | Keyword: [Trace Char] | Required: Yes | Description: Defines the assumed targets for the PCB trace impedance | and velocity (description of electrical transmission line). | Sub-Params: Zo (Characteristic Impedance, ohms), Td (Propagation delay | per [Unit Length], in seconds). Only Zo and Td values | appear in the file, the strings "Zo" and "Td" are not listed. | Usage Rules: At least one Zo-Td pair must be listed following [Trace Char] | after the word "Default". The Zo-Td pair values must be | listed in the following order: Zo_typ, Zo_min, Zo_max, | Td_typ, Td_min, Td_max. A numerical value must be entered | for typical, but NA can be used for minimum and/or maximum | as desired. The first Zo-Td pair is considered the default | target for all nets in a RAIL file. | | Nets or net groups that have different trace characteristic | targets can be listed after the first (default) Zo-Td | pair by listing a net_name or group_name followed by another | Zo-Td pair. All Zo and Td values are limited to 10 | characters maximum. | | Other Notes: The values stated in [Trace Char] offer a clearer electrical | meaning to length quantities that might be listed in the | [Topology] section. When values are listed in the min/max | columns, the PCB artwork solution should be bounded by these | limits. If values are not listed in min/max, EDA software may | want to allow entry of unique fabrication tolerances and | intelligently test electrical constraints against those | limits. |------------------------------------------------------------------------------ [Trace Char] | due to "[Unit Length] inch" Td is in ps/inch if scaled by "p" |net/group_name Zo_typ Zo_min Zo_max Td_typ Td_min Td_max Default 70 NA 90 175p 150p 200p | all nets/groups GTL_sigs 50 NA NA 140p NA NA | over-ride default | for group "GTL_sigs" | |============================================================================== | Keyword: [Topology] | Required: No | Description: Used to express topological information of nets or net groups. | Usage Rules: The [Topology] keyword must be followed by at most one | group_name or net_name to which the topology applies. | Topologies are described with a simple SPICE-like syntax, | consisting of the following two-node primitives: | | Rxxx node1 node2 resistor_value | for resistors | Lxxx node1 node2 inductance_value | for inductors | Cxxx node1 node2 capacitance_value | for capacitors | Dxxx anode_node cathode_node generic_name | for diodes | Txxx node1 node2 len_typ len_min len_max | for traces | Vxxx pos_node neg_node DC_voltage | voltage source | | Node names can be either reserved words (e.g., GND), | generic_names (e.g., P6), defined [DC Nets], or invented | nodes (e.g., trace "tee" points such as "node_tee1"). | | When using the Vxxx elements, one of the nodes must | be a stable DC reference (such as GND). | | The "T" or "Trace" element nodes must be followed by three | parameters. These will provide the typical, minimum, and | maximum trace lengths, when defined. When lengths | are undefined, it is acceptable to use "NA" in any or all | of the length parameters. Alphabetic variables can also be | used in the length columns in order to express relationships | between trace segments (e.g., stub matching). The same | variable can be used in more than one [Topology] section | in order to express trace length relationships across nets | or net groups (i.e., variables are global to all [Topology] | sections). It is also allowed to include addition or | subtraction of other alphabetic variables or physical | lengths in any length parameter (e.g., stub-3+branch). | When addition/subtraction is used, it must be "close | concatenated" (i.e., no spaces) with variables and/or values. | | Trace parameter's len_xxx syntax should be less than 8 | characters (scaled assuming the previously defined [Unit | Length]), but this is not required. All other Topology | syntax words are limited to 20 characters max, except for | generic_names and Zo values which are limited to 10 | characters. | | When it is desired to specify a particular impedance at the | trace segment or stub level, it is acceptable to add three | impedance (Zo) parameters. If this option is used, three | entries must be used for Zo_typ, Zo_min, Zo_max in that order. | "NA" can be used for min, max, or both. Consequently Txxx | element lines can have either 6 or 9 columns. | | If a generic_name(node) contains more than one connection, | then the generic_name will be appended by an "instance | designator". This designator is appended immediately following | the generic_name with an exclamation mark. The instance | designator can only be either a pin number. (E.g., "DRAM1!34" | means pin thirty four of the component with the generic_name of | "DRAM1".) The pin number can be numeric or alphanumeric | and must not exceed five characters. This allows the generic | name with an instance designator to be up to 16 characters in | length. | | Other Notes: An electrical description of the T elements can be derived | by referencing the [Trace Char] keyword and applying the | lengths. If a diode pack is used on the end of a net, the | [Topology] can simply route up to the device on a Trace | element and stop without using a Dxxx element. Dxxx | elements are primarily provided to allow topologies with | diodes intermediate to the path. | | It is important to note that when "NA" is used in the | Txxx element length parameters, that simply means that | a length constraint is "not available". It does not mean | that any length is acceptable. | Note that if a net or group of nets has guidelines under both [Budgets] and [Topology] the quantities expressed in [Budgets] should take precedence. In these cases, the [Topology] is just listed as a suggested implementation or starting point to derive a layout that will quickly satisfy the stated [Budgets]. |------------------------------------------------------------------------------ | for lengths-> typ min max / Zo \ [Topology] GTL+_sigs | end-terminated daisy chain V_end1 to_v1 GND 1.5V | voltage source as Vxxx element R_end1 to_v1 end_stub1 68 T_end1 end_stub1 P6_1 NA NA 2 | max trace length is 2 inches T_proc P6_1 P6_2 NA 3.5 NA | keep this segment at least 3.5" T_chip P6_2 PMC NA NA NA | any length, constrained by [Budgets] T_end2 PMC end_stub2 NA NA 2 R_end2 end_stub2 V_tt 68 | this voltage from defined [DC Net] | [Topology] RAS_sigs | series res. with diode on end T_res PMC res_pack1 0.5 NA NA | an example of an "electrical net" R_ras res_pack1 res_pack2 33 | (through a resistor) T_todr res_pack2 SIMM1 NA NA 6.5 50 40 60 | lower Zo on this segment T_1_2 SIMM1 SIMM2 0.8 NA NA T_2_3 SIMM2 SIMM3 0.8 NA NA T_3_4 SIMM3 SIMM4 0.8 NA NA T_dio SIMM4 DRAM_Diode 0.8 NA 1.5 | to diode comp. model, no Dxxx needed | [Topology] MOE# | MOE# has matched stubs T_drv CLK_SRC TEE 8 NA NA T_b1 TEE TDP1 A A-.1 A+.1 | OK to use variable "A" and "+", "-" T_b2 TEE TDP2 A A-.1 A+.1 | match these stubs, within 0.2 inches | [Topology] RAS#(3:2) Tpr PMC R1 NA NA 1 R10 R1 R2 10 Tmain R2 Tee1 NA NA 7 Tt1s2_a Tee1 DRAM2!34 2 NA NA Tt1s2_b Tee1 DRAM2!44 2 NA NA Tt1t2 Tee1 Tee2 NA NA 1 Tt2s4_a Tee2 DRAM4!34 2 NA NA Tt2s4_b Tee2 DRAM4!44 2 NA NA | |============================================================================== | Keyword: [Priority] | Required: No |Description: Recommended priority of routing the net groups. |Usage Rules: The [Priority] keyword must be followed by an (unlimited) | list of group_names and/or net_names. |Other Notes: The [Priority] list is simply counsel from the design | originators. A typical design should have greater success | deriving artwork that meets all RAIL and mechanical | guidelines by routing the nets and groups in the order | specified in the [Priority] list. The [Priority] list will | normally list the more critical (difficult to meet guidelines) | nets first. However, as the route proceeds, out of | [Priority] rip-up/retry is acceptable provided new routes | are tested against the various guidelines listed elsewhere | in the RAIL file. |--------------------------------------------------------------------------- [Priority] Host_Bus MOE# L2_Cache Host_Clks Chipset DRAM PCI_Clocks PCI ISA | |============================================================================== | Keyword: [Budgets] | Required: No |Description: Used to express signal flight time budget and signal integrity | (overshoot, crosstalk) targets. |Usage Rules: [Budgets] must be followed by the group_name of the groups/nets | that follow. Electrical targets are listed for each | driver/receiver pair and net group line by line. Each | line consists of the following parameters, in this order, | and separated by white space: | CHAR | PARAMETER PURPOSE MAX | ---------------- --------------------- ---- | drvr generic_name driver, from [Map Table] 10 | - (dash) separate driver & receiver 1 | rcvr generic_name receiver, from [Map Table] 10 | {sig} here come signal net_names 5 | one net/group_name nets that apply no limit | edge designator R=rising, F=falling, B=both 1 | duration simulation high/low time 6 | min flight minimum flight time 6 | max flight maximum flight time 6 | overshoot_high maximum overshoot high 6 | overshoot_low maximum overshoot low 6 | intra-xtalk intra-bundle crosstalk 6 | inter-xtalk inter-bundle crosstalk 6 | | Each line must have eight entries following the group/net_name. | If a certain parameter is unspecified, an "NA" must be used. | However, NA can not be used in the edge designator column. | |Other Notes: The following is the RAIL definition for the various | parameters defined by the [Budgets] keyword. | | FLIGHT TIME - A "flight time", as defined by the RAIL | Specification, can only be determined by an analog simulation | of the signals driven/received on a given net. In addition, | a "reference net" must also be simulated. The goal of the | flight time simulation is to quantify the difference (in | nanoseconds) between the actual PCB environment, and the timing | reference circuit specified in the driver's datasheet. | | A reference net is developed by combining the net driver with | its reference circuit. This can be extracted automatically | by the simulator from the driver's IBIS 2.1 (or greater) file | using the parameters Vref, Rref, and Cref. | | The flight time is calculated by simulating the net's driver | into both the reference net and the actual PCB route in | parallel. The flight time calculation can be automated by | extracting IBIS parameters Vmeas (from the driver model) and | Vinl or Vinh (from the receiver model). | | MINIMUM FLIGHT TIME - The minimum flight time is normally | computed using the strongest (fastest) driver model. | Minimum flight time for a signal's rising edge begins when the | waveform at the driver's output on the reference net reaches | Vmeas and ends when the receiver's input passes Vinl with | increasing voltage for the first time. Similarly, minimum | flight time for a signal's falling edge begins when the | waveform at the driver's output on the reference net reaches | Vmeas and ends when the receiver's input passes Vinh with | decreasing voltage for the first time. | | MAXIMUM FLIGHT TIME - The maximum flight time is normally | computed using the weakest (slowest) driver model. | However, when nets exhibit a lot of ringing, the strongest | driver model may actually yield the maximum flight time. | Maximum flight time for a signal's rising edge begins when the | waveform at the driver's output on the reference net reaches | Vmeas and ends when the receiver's input passes Vinh with | increasing voltage for the last time. Similarly, | the flight time for a signal's falling edge begins when the | waveform at the driver's output on the reference net reaches | Vmeas and ends when the receiver's input passes Vinl with | decreasing voltage for the last time. | | More elaborate definitions of flight time exist and have been | used. The positive points of these definitions are that they | are fairly simple and conservative. The negatives are (1) some | timing "double counting" may exist at the receiver, and (2) | longer flight times may be reported that are actually not | problematic in system operation. Workarounds for these | negatives may be offered by simulation tools in the form of | greater user control (e.g., derate slopes, ringback tolerances, | overdrive rules,...) or built in tolerancing. | | Also note that, according to these definitions, negative flight | times could legitimately be calculated. | | The "duration" column lists the amount of time the signal | should be in either the high or low state during the | simulation in which the flight time is measured (i.e., | "duration" is half the period of the simulated waveform). | | MAXIMUM OVERSHOOT HIGH - This parameter specifies the largest | allowable dynamic overshoot that should be applied to the | receiver's input after a transition to a higher voltage level. | EDA software should flag an error if the simulated voltage | at the receiver(s) becomes higher than the voltage stated. | | MAXIMUM OVERSHOOT LOW - This parameter specifies the largest | allowable dynamic overshoot that should be applied to the | receiver's input after a transition to a lower voltage level. | EDA software should flag an error if the simulated voltage | at the receiver(s) becomes lower than the voltage stated. | | CROSSTALK - Crosstalk is defined as the deviation from a | net's quiescent DC level caused by signals switching on | neighboring traces/structures. | | INTRA-BUNDLE CROSSTALK - Maximum allowable crosstalk induced | onto a quiet net (high or low state) by all signals switching | within the same [Group Nets] keyword. | | INTER-BUNDLE CROSSTALK - Maximum allowable crosstalk induced | onto a quiet net (high or low state) by adjacent switching | signals from other net groups. | | It is recommended that [Budgets] measurements be made at the | component's pins to be consistent with datasheet assumptions. | |--------------------------------------------------------------------------- [Budgets] Host_bus | over- over- |drvr- rcvr {sig} net/group edge dur- min max shoot shoot intra inter |\gen_names/ ation flights high low xtalk xtalk P54C - TXC {sig} HA(31:18) B 30n 0.4n 4.2n 4.8 -1.4 500m 300m P54C - TXC {sig} HA(17:5) B 30n 0.4n 5.1n 4.8 -1.4 500m 300m SRAM - P54C {sig} HD(63:0) B 15n 0.5n 2.7n 5.0 -1.6 600m 300m P54C - TXC {sig} H_ADS# F NA 0 2.3n 4.8 -1.4 NA 200m TXC - SRAM {sig} CADS# R 15n 0 3.9n 5.6 -1.1 NA 200m | |============================================================================== | Keyword: [Clocks] | Required: No | Description: Lists clock assumptions (Frequency, Duty cycle, and Jitter) | and requirements for PCB delivery at receivers. | Sub-Params: Frequency, Duty_cycle, Jitter, High_time, Low_time, Rise_time, | Fall_time, Overshoot_high, Overshoot_low, Crosstalk | Usage Rules: The [Clocks] keyword must be followed by the group/net_name of | the clock(s) to be examined. Following the group/net_name is | a list of subparameters. Each subparameter must be | followed by an equal "=" sign and a value. | Other Notes: The RAIL file provides the clock driver's Frequency, | Duty cycle, and Jitter as inputs to the PCB analog simulation. | EDA software simulates the clock nets, and measures the other | subparameters at all receivers against the value stated. | Subparameter usage is detailed here: | | Frequency - max frequency clocks will run at | Duty_cycle - list larger percentage of cycle that might be high | or low (e.g., use "0.5" for 50%, "0.6" for 60/40) | Jitter - potential single cycle narrowing of clock period | High_time -receiver waveform must stay above Vinh for this time | Low_time - receiver waveform must stay below Vinl for this time | Rise_time - receiver waveform time from Vinl-Vinh must be less | Fall_time - receiver waveform time from Vinh-Vinl must be less | Overshoot_high - same definition as in [Budgets] | Overshoot_low - same definition as in [Budgets] | Crosstalk - maximum acceptable crosstalk from any other source | | It is recommended that [Clocks] measurements be made at the | component's pins to be consistent with datasheet assumptions. |------------------------------------------------------------------------------ [Clocks] HCLKs Frequency = 66MHz | \ Duty_cycle = 0.55 | Duty_cycle is 55/45 >-----> driver characteristics Jitter = 200ps | / High_time = 4.5ns | \ Low_time = 4.5ns | \ Rise_time = 2.2ns | \ Fall_time = 2.2ns | >------> simulate to verify these at receivers Overshoot_high = 4.8V | / Overshoot_low = -1.4V | / Crosstalk = 100mv | / |============================================================================== | Keyword: [Clock Skew] | Required: No | Description: Defines skews between clock groups or nets. | Usage Rules: The Clock Skew keyword is followed by any number of pairs | of clock groups or nets. Pairs are separated by a dash | "-". When the specific receiver in a group or on a net | must be specified, the syntax {part} is used in either | of the pair followed by a generic_name of 10 characters max. | Immediately following the clock pair is the edge | designator: "R" if the skew is to be measured on rising | edges, "F" if the skew is to be measured on falling edges, | or "B" if the skew is to be measured on both edges. | NA is not allowed in the edge designator column. | Min and max skew guidelines are then listed for each pair. | Values must be 8 characters or less. When values are not | specified, "NA" must be used to ensure that there is an | entry in both the min and max column. If the min column | is not "NA", then the second part of the clock pair must | lag the first part of the pair by the amounts specified. | | Other Notes: The method for measuring clock skew is not specified by RAIL, | and must be defined by the hardware design team. Three | options normally used (in order of increasing conservatism) | are listed below. EDA software may elect to make any, or all | of these options available to the user. Assume that skew is | to be determined between rcvr_1 and rcvr_2: | | OPTION 1. Skew measured is the time delta between rcvr_1's | (Vinh-Vinl)/2 to rcvr_2's (Vinh-Vinl)/2. | OPTION 2. Skew is the larger of (1) the quantity determined | in option 1, (2) rcvr_1 @ Vinl to rcvr_2 @ Vinl, | and (3) rcvr_1 @ Vinh to rcvr_2 @ Vinh. | OPTION 3. Skew is the larger of (1) rcvr_1 @ Vinl to rcvr_2 | @ Vinh, or (2) rcvr_1 @ Vinh to rcvr_2 @ Vinl. | | Also note that "NA" must be used in the minimum skew column | when there is no phase relationship implied in the clock | pair maximum skew. | | It is recommended that [Clock Skew] measurements be made at the | component's pins to be consistent with datasheet assumptions. |------------------------------------------------------------------------------ [Clock Skew] |group/net_name {part} generic_name - group/net_name {part} generic_name |rcvr_1 rcvr_2 edge min max HCLKs - HCLKs R NA 500ps | all nets within "HCLKs" Group HCLK0 - HCLK1 R NA 250ps | two specific nets have tighter skew HCLK0 {part} TSC - HCLK0 {part} CPU R NA 150ps | tighter still within net HCLK0 HCLKs - PCLKs R 100ps 500ps | PCLKs Group must lag HCLKs Group PCLKs - PCLKs R NA 2ns | all nets within "PCLKs" Group | |============================================================================== | Keyword: [Edge Sens] | Required: No | Description: Used to list net groups and/or nets with special | monotonicity or crosstalk requirements. | Usage Rules: [Edge Sens] is followed by five columns of data. Entries | must be placed in each column, and NA can be used in | columns four and five as appropriate. The columns are | 1) net_name - name of net, can also be a net group_name | 2) mono_r - "Y" means rising edge must be monotonic | (constantly increasing) through all receiver's | range Vinl to Vinh, "N" means the rising edge | need not be monotonic | 3) mono_f - "Y" means falling edge must be monotonic | (constantly decreasing) through all receiver's | range Vinh to Vinl, "N" means the falling edge | need not be monotonic | 4) intra_xtalk - same definition as under [Budgets] | 5) inter_xtalk - same definition as under [Budgets] | Both intra_xtalk and inter_xtalk values are limited to | 6 characters maximum. | | Other Notes: If a net's crosstalk limits are defined under both | [Budgets] and [Edge Sens], the value under [Edge Sens] | would take precedence. | | It may be advisable to verify monotonicity at the component's | die (i.e., "inside" the package model), but this is not | required. |------------------------------------------------------------------------------ [Edge Sens] |net_name mono_r mono_f intra_xtalk inter_xtalk TC N Y NA 400m IORC# Y Y 300m 300m RESET# Y N NA 300m |============================================================================== | Keyword: [End] | Required: Yes | Description: Defines the end of the .ral file. |------------------------------------------------------------------------------ [End]