View 17314_1098196.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

ieee 802.3 repeater technical manual a d v a n c e d m i c r o d e v i c e s
? 1993 advanced micro devices, inc. advanced micro devices reserves the right to make changes in its products without notice in order to improve design or performance characteristics. this publication neither states nor implies any warranty of any kind, including but not limited to implied warrants of merchantability or fitness for a particular application. amd a assumes no responsibility for the use of any circuitry other than the circuitry in an amd product. the information in this publication is believed to be accurate in all respects at the time of publication, but is subject to change without notice. amd assumes no responsibility for any errors or omissions, and disclaims responsibility for any consequences resulting from the use of the information included herein. additionally, amd assumes no responsibility for the functioning of undescribed features or parameters. trademarks amd is a registered trademarks of advanced micro devices, inc. imr, imr+, himib, tpex and tpex+ are trademarks of advanced micro devices, inc. product names used in this publication are for identification purposes only and may be trademarks of their respective companies.
table of contents i table of contents section 1 technology overview 1-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 terminology/definition 1-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 overview of applications 1-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 overview of standards 1-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . section 2 repeater management standards 2-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 ieee 802.3 repeater management 2-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 ieee 802.3 mau management 2-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 novells hub management interface (hmi) 2-8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 ietf managed objects for ieee 802.3 repeaters 2-13 . . . . . . . . . . . . . . . . . . . . . section 3 imr/imr+ overview 3-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 functional description 3-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 imr/imr+ based velcro hub design 3-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 port activity monitor (pam) operation 3-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 link test state machine description 3-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 receive polarity detection/correction algorithm 3-8 . . . . . . . . . . . . . . . . . . . . . . . . 3.6 alternate reconnection algorithm 3-9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 interaction between port disable and port autopartition 3-9 . . . . . . . . . . . . . . . . . . 3.8 imr/imr+ management port 3-10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9 imr+ device repeater state machine description 3-15 . . . . . . . . . . . . . . . . . . . . . 3.10 response to preamble only 3-17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11 response to ipg shrinkage 3-17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12 designing repeaters using multiple imr+ devices 3-18 . . . . . . . . . . . . . . . . . . . . 3.13 expansion port 3-19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 external arbiter 3-20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.15 reset circuitry 3-20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.16 differences between the imr and imr+ devices 3-22 . . . . . . . . . . . . . . . . . . . . . . 3.17 imr/imr+ propagation delays 3-24 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . section 4 himib overview 4-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 architectural overview 4-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 himib/imr+ chip-set management capabilities 4-3 . . . . . . . . . . . . . . . . . . . . . . . . 4.3 himib device hardware design considerations 4-7 . . . . . . . . . . . . . . . . . . . . . . . . 4.4 himib device software design considerations 4-8 . . . . . . . . . . . . . . . . . . . . . . . . . section 5 managed repeater design 5-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 high level design considerations for managed repeaters 5-1 . . . . . . . . . . . . . . . 5.2 fixed port repeater design 5-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 imr+/himib interface 5-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 aui/mac interface 5-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5 expansion bus/mac interface 5-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 himib device microprocessor interface 5-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7 managed repeater status indicators 5-13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 modular repeater collision arbitration 5-14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
amd table of contents ii section 6 layout recommendations 6-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1 the attachment unit interface 6-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 decoupling 6-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 power planes 6-4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 filter modules 6-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . section 7 glossary 7-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . appendix a 10base-t interface filter and transformer modules a-1 . . . . . . . . . . . . . . . . . . . . b aui isolation transformers b-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1-1 technology overview technology overview 1 section 1.1 terminology/definition computer networks allow computer systems or stations to share information. the network consists of the communications medium (typically a cable plant), and network transmission devices to assist in the communication. the physical cable plant is generally configured in either a star or a bus topology. in a bus topology all stations tap into a single cable that runs from one station to the next. in a star topology the stations are all connected to a central point, where a network hub or repeater connects the cable segments together. the star topology offers two major advantages. the first advantage is that the computer network can now be merged with the existing building telephone network. the telephone is traditionally configured in a star topology, and a single integrated cable plant results in lower costs and easier cable management. the second advantage of star networks is that the repeater is a convenient point for monitoring and managing the network. some station failures result in the stations transmitting endlessly on the network. in a bus topology this would disrupt the entire network. in a star topology, the hub or repeater unit can detect the fault and isolate that station from the network. the network remains operational and available for use by the other stations. the access method is the set of rules that stations use to control when they can access the network. in ethernet the access method is carrier sense, multiple access with collision detect, or csma/cd. this means that before a station transmits, it monitors the network for activity. it waits if it detects that another station is already transmitting. once the network is available, the station is free to transmit. while transmitting, stations monitor the network for collisions with other stations, that is more than one station transmitting at the same time. when a station detects a collision it ceases to transmit, then after a variable amount of time it attempts to transmit once again. to a large degree the access method determines the kind of hub needed in a star topology cableplant. csma/cd is based on the concept that station transmissions are broadcast on the complete network, and use that fact to determine when there is a collision. the simplest hub for ethernet networks could have been a passive star, where each segment is passively coupled to the rest of the segments. however this would result in significant loss of signal strength, and high network error rates. for this reason 10base-t network hubs are active repeaters. these repeaters regenerate the received signal and broadcast it on the rest of the network. additionally, an ethernet repeater must perform collision detection for each of its attached links. repeaters perform these essential tasks: n repeaters regenerate the received signal to comply with ieee 802.3 specifications prior to retransmitting it on all links. n repeaters detect and propagate collisions to all stations. n and finally repeaters exclude (partition) stations from the network under certain fault conditions. the repeater market can be broken down into four product categories. the following sections describe the different categories, along with their main functional characteristics.
amd technology overview 1-2 1.2 overview of applications in the few years since the development of the ieee 802.3 10base-t standard, 10base-t repeaters have evolved into diverse classes of products. these products are characterized by different numbers of ports, modularity, reliability, manageability, and different costs. this section describes four categories of ieee 802.3 repeater products, and their essential characteristics. 1.2.1 fixed configuration unmanaged repeaters unmanaged repeaters perform only the basic ieee 802.3 functions. these devices vary in configuration from 8 to 32 ports. they adhere to the strategy of monitor by led, manage by disconnect, in that they provide port status and error information through visual indicators only. they provide no facility for remote monitoring or control, although they may provide a simple local connection (rs232) to connect a computer terminal for basic maintenance. figure 1-1 fixed configuration unmanaged repeater 17314a-1 the advantage of these devices has been their low cost. they achieved this low cost by eliminating two essential capabilities, manageability and modularity. manageability has historically been costly to implement, resulting in significantly higher product cost. modularity allows repeaters to support variable port configurations. however modular repeaters require a higher initial cost for the system chassis, which is then amortized across many more ports.
amd 1-3 technology overview 1.2.2 fixed configuration managed repeaters figure 1-2 shows a network using a managed repeater. this repeater allows a remote management station to monitor and control its operation. figure 1-2 fixed configuration managed repeater 17314a-2 management the term management means that the repeater supports access to information regarding its operation. managed 10base-t repeaters differ in exactly what information is available, and how that information can be accessed. the recently completed ieee 802.3 repeater management standard defines common sets of information required in managed ieee 802.3 repeaters. most managed 10base-t repeaters support two modes of remote access. in-band access allows remote management stations to manage the repeater through the repeater network. out-of-band access allows remote management through a separate interface, such as a serial port. local management capabilities allow access to manage- ment information through a local interface, such as front panel switches, leds, or an attached terminal. remote management uses a management protocol to transmit management information between the repeater and a remote management station. this can be as simple as a serial terminal interface for modem access, to a network management protocol such as the simple network management protocol (snmp). fixed configuration managed repeaters have recently been extended to support system level modularity. known as rack and stack repeaters, these devices combine the flexibility of the modular repeater with the low cost of a fixed configuration repeater. this product is essentially a fixed configuration repeater, with an additional external interface to connect it to other repeaters. the external interface is used to allow these devices to act in concert as a single repeater. some of these products allow a single master unit to manage other slave units through a management interface, resulting in additional cost savings.
amd technology overview 1-4 1.2.3 modular (enterprise) repeaters modular repeaters are used in environments where the potential need exists for a large number of ports. by combining the repeaters into a single system chassis, modular repeaters take advantage of shared costs such as the power supply and network management module. these systems have a high initial cost due to the increased size and power requirements, however they offer easy expansion by installing additional port modules. figure 1-3 modular repeaters 17314a-3 management these systems also support enhanced capabilities, such as redundant power supplies and support for multiple lan segments. multiple lan segment support allows card by card segmentation of the network in busy networks. these modular hubs often provide bridging and routing between the segments, as well as support for different media access protocols (token ring, fddi etc.), and different media types (stp, utp, coax, fiber optics). this class of system is generally deployed in large building and campus networks. in these environments network reliability is a major concern. for that reason this class of repeater almost always includes network management capabilities. that capability is reflected in the higher initial cost for these systems. 1.2.4 server based repeaters server based repeaters are a new class of 10base-t product. these repeaters consist of one or more hub cards designed to be installed in the file server itself. in many cases, file servers are located near 10base-t repeaters. file servers already have a chassis, power supply, and processor capable of managing the repeater. in these environments, where the file server has slots available for use by one or more repeater cards, this provides a low cost option.
amd 1-5 technology overview figure 1-4 unmanaged server-based repeaters 17314a-4 initially server based repeaters provided only unmanaged capabilities. these products are the equivalent of a fixed configuration dumb repeater. newer server based repeaters use the capabilities of the server processor to add management support for these products. novell, inc. recently introduced the hub management interface (hmi) specifi- cation. this specification provides a hardware independent interface between the novell netware server management software and the repeater (hub) card. figure 1-5 managed server-based repeaters management 17314a-5
amd technology overview 1-6 the amd himib and imr+ repeater chipset directly supports the additional manage- ment requirements for server based repeaters. amd offers a design kit called the isa-hub tm -kt for managed server applications. this design kit provides a complete hardware and software solution for server based managed repeater applications. a complete user manual for the isa-hub is available from amd (pid #17642a). 1.3 overview of standards computer networking standards are developed by several different standards bodies with overlapping jurisdiction. ethernet repeaters are defined in the standards of three different organizations. the three organizations are the institute of electrical and electronic engineers (ieee), the international standards organization (iso), and the internet engineering task force (ietf). the ieee 802.3 committee defined the core ethernet standard. this work involved the original coax and repeater specifications, the newer 10base-t specification, and various ieee 802.3 management specifications. the ieee standards are ultimately submitted to the international standards organization (iso) for final approval as an international standard. this was a straight forward process for the basic physical layer and media access specifications. however the network management specification is split between iso and ieee. iso has developed standards for the specification of management information. the ieee 802.3 committee used this as the basis for their work in the specification of repeater management. additionally the ieee 802.1 committee specified management information required for all repeaters in the ieee 802 protocol suite. these standards work together to specify the requirements for ieee 802.3 repeater management. what is not specified in these standards is the protocol to transport network management information over a network. the most widely supported network management protocol is the simple network management protocol (snmp). the internet engineering task force (ietf), an organization responsible for the develop- ment of guidelines for the administration of the u.s. based internet, specified the snmp. the ietf as a organization ties into the world standards organization through the us department of defense, as an entity separate from the ieee or ansi. what is important is that the ietf specifies how management information will be represented when transmitted over the network. specifically the ietf has defined an ieee 802.3 repeater management information base (mib) that is used to transmit repeater information through the network. this mib was based on the work of the ieee 802.3 repeater management task group. a final specification of interest is the hub management interface specification developed by novell, inc. this is an interface specification that describes what management information must be supported by ieee 802.3 hub cards in novell file servers, and how that information is passed to the novell management protocol stack. this specification is based on an early draft version of the ieee 802.3 repeater management standard, and has additional requirements beyond the published ieee 802.3 specification. 1.3.1 ieee 802.3 repeater standard the original ieee 802.3 standards defined the use of coax cable for the transmission of network information between many stations on a single network segment. the distance of the network and the maximum number of stations attached to the network were limited by signal loss on the coax cable. ieee 802.3 then developed section 9 of the standard, detailing the use of a repeater to extend the distance and number of stations that could be attached to a single ieee 802.3 network. the repeater regenerated the electrical signal and retimed the transmitted bits, connecting one coax segment to another. the standard supports an extended network topology where stations can be separated by as many as 4 repeaters.
amd 1-7 technology overview all of the segments attached by repeaters are part of the same collision domain, meaning that the csma/cd access method extends through the repeaters over the entire network. the round trip delay time must be limited to the maximum collision window defined by the core ieee 802.3 standard. the total size of this network is limited by the need to sense collisions between stations on opposite ends of the network. where the ieee 802.3 coax repeater standard allows connection of multiple stations through a coax segment, the ieee 802.3 10base-t standard for transmission of ethernet over unshielded twisted pair (utp) cable requires that a repeater port be attached to each individual 10base-t station. an effective way of implementing this is with a multiport 10base-t repeater, which provides multiple 10base-t station ports. each 10base-t link can be up to 100 meters long, and consists of two twisted pairs (4 conductors total) of utp cable. one pair is used for transmit, and one for receive. the use of 10base-t repeaters in an 802.3 network is still constrained by the ieee 802.3 limitation of at most 4 repeaters between any two end stations. where coax based ieee 802.3 stations are physically attached to the same cable, 10base-t stations are physically attached to individual cables called link segments. however the 10base-t repeater makes them appear to be connected to a single cable. it does this by propagating the incoming frames from any station to all other stations in the network, as well as detecting and signaling when a collision condition is detected. the repeater receives frames from any attached station, and propagates it to the rest of the attached stations. during the propagation of the frame, the repeater regenerates the signal, and retimes the bits. each repeater has a clock recovery circuit that enables it to receive and decode (separate clock from data) the incoming bit stream. when the repeater detects an incoming frame on any port, it connects that port to the clock recovery circuit where the frame is then decoded. the decoded bits are passed into a small fifo, from which they are retransmitted on all ports using the repeaters locally generated clock. this process removes the clock jitter and restores the signal level of the incoming frame. a few of the initial bits in the frame can be lost in this process because the clock recovery circuit requires a few bit times to synchronize with the incoming data. subse- quent frames can come from different stations, each with a different clock source. this means that the repeater clock recovery circuit must be able to synchronize to a different clock source on each frame. the repeater also plays a central role in collision detection and propagation. collision is detected by monitoring activity on all ports. when two or more incoming ports go active simultaneously, or when the repeater detects a receive mode collision on any port, it signals a collision condition by transmitting a jam signal to all ports. this is logically identical to the collision behavior of a coax based ieee 802.3 network, with the excep- tion that collision detection by the repeater is quicker and easier than the dc collision detection method used by stations on coax ieee 802.3 networks. 1.3.2 ieee 802.3 repeater management the ieee 802.3 committee is working to define the management requirements for ieee 802.3 networks. this work initially resulted in the section 5 layer management standard, and more recently the section 19 layer management for 10mb/s baseband repeaters standard. the ieee 802.3 repeater management specification defines what is managed inside a repeater, not how a repeater is managed by a network manager. the individual entities inside a repeater that can be managed are referred to as the management objects. these objects fall into three basic classes. attributes attributes are the accessible pieces of information in the repeater. they provide status information about the operational state of the repeater and the network, such as the
amd technology overview 1-8 health of the repeater, the number of collisions, the total number of received bytes, etc. attributes can be readable, writable, or both. in the case of the ieee 802.3 repeater management standard, all attributes are read only. actions actions are commands that the network manager can direct the repeater to execute. they allow the manager to alter the state or value of a management object, such as resetting the repeater, enabling or disabling ports, etc. notifications notifications are the messages the repeater is required to send to a network manager when a significant event occurs. unlike the attributes and actions that originate at the network manager, notifications originate at the repeater itself. because of their potential impact on the available network bandwidth, these messages are only used to report significant events. ieee 802.3 management objects relate to the repeater in a hierarchical manner. some of the objects support management of the overall repeater. others are used to manage the individual ports in the repeater. an 8 port repeater would then require one of these objects for each port. individual groups of ports are also assigned several objects to support management of a cluster of ports as a single entity. a single repeater could then have 4 groups, each consisting of 24 ports for a total of 96 ports. the ieee 802.3 management objects are grouped into three sets, or packages. packages can each consist of any number of attributes, actions and notifications. the three packages defined for ieee 802.3 repeater management are basic control, performance monitoring, and address tracking. basic control is the required minimum set of objects that must be supported by man- aged ieee repeaters. performance monitoring is the optional set of management objects necessary to monitor the performance of ieee 802.3 repeaters. these objects consist of many real-time port and repeater statistics. support for these objects is provided by the amd himib chip. address tracking provides port level detection of attached station addresses. like the performance monitoring package, the address tracking package requires statistics supported by the himib device. 1.3.3 ieee 802.3 mau management the most recent element in the ieee 802.3 architecture to undergo management standardization is the media attachment unit (mau). the ieee 802.3 mau is the actual physical line interface. using mau management, the network manager can determine status information and initiate control actions on the mau. each port in a managed repeater is subject to support of the ieee 802.3 mau manage- ment requirements. like the ieee 802.3 repeater management suite, the ieee 802.3 mau management standard is organized in several packages. basic control provides the minimum mandantory requirements for managed maus. mau control enables the network manager to control as well as monitor the mau operation. media loss is a conditional attribute that provides optional support for aui attachments. broadband dte mau is the final conditional package, providing optional support for broadband network management. 1.3.4 simple network management protocol the ieee 802.3 suite of management standards specifies the management objects required to support standard interoperable management of ieee 802.3 systems. it does not address the issue of how this information is communicated to a remote manager. the simple network management protocol (snmp) is one of many network manage-
amd 1-9 technology overview ment protocols. because of its origins in the tcp/ip networking community the snmp is widely used in complex heterogeneous corporate networks. the basic function of the snmp is to provide a protocol to get and set management information base (mib) attributes in remote stations, and for the remote station to signal an alarm condition to the network manager. using this capability network managers can monitor (get) and control (set) remote station operation. the ieee 802.3 notification is supported by the snmp alarm message. in an ieee 802.3 repeater, snmp allows network managers to enable and disable ports, as well as to acquire frame error and performance statistics. the snmp protocol is specified in request for comments (rfc) 1157. 1.3.5 mib-i, mib-ii, repeater mib and rmon mib along with a network management protocol (snmp), network management requires a standard way of addressing specific mib attributes. this structure of network objects is referred to as the containment tree, and consists of a hierarchy of management object classes. the ieee 802.3 repeater ports can be addressed individually or as part of a group. the groups are combined into a repeater, which in turn is part of a station. the station could in turn contain additional repeaters and other manageable objects. the ietf defined mib-i (rfc 1156) as the original specification of management objects for stations in an snmp network. these objects dealt primarily with network interfaces and elements of the protocol stack. mib-ii (rfc 1213) modified these object definitions, extending them to cover other related objects. neither mib-i nor mib-ii defined support for repeater management objects. the ietf repeater mib (rfc 1368) was developed based on the ieee 802.3 repeater management standard. it describes the snmp based management attributes required in repeater management objects. these mibs are generally oriented toward management by network management stations within the local campus network. the amount of traffic to actively monitor station operation is not excessive by lan standards, however because of bandwidth limitations remote monitoring is more difficult. because of this a specification for remote manage- ment over a wide area network was defined. this allows a remote network monitoring station to report general network information back to a central management station. only when requested by the central management station would detailed traffic informa- tion be transmitted between the remote monitor and the central manager. the specification for a remote network monitoring management information base is referred to as the rmon mib. this mib specifies a broad selection of optional manage- ment and monitoring capabilities, allowing vendors to craft rmon products which span a broad range of applications and cost. while not directly related to ieee 802.3 repeater management, many of the rmon mib (rfc 1271) attributes mimic those defined in the ieee 802.3 management suite. 10base-t repeaters are often appropriate devices to host the remote management engine, and could have rmon mib capabilities installed as an option.
amd technology overview 1-10
2-1 repeater management standards repeater management standards 2 section 2.1 ieee 802.3 repeater management this section describes the ieee 802.3 repeater management information base (mib). the ieee 802.3 repeater mib consists of several different object types. from an implementation point of view the important ones are the attributes, actions, and notifica- tions. attributes are used to monitor and control device operation. actions force the repeater to execute a management command, while notifications are used by the repeater to signal the network manager that a significant event has occurred. the following sections list the three management packages, and their management objects. the ieee 802.3 mib objects are grouped into three packages, known as the basic control package, the performance monitoring package, and the address tracking package. repeater management objects fall into one of three main classes. the repeater object class contains those objects necessary for overall repeater manage- ment. the group object class contains objects necessary to manage collections of ports. ports can be clustered into groups for easier manageability, and the group mib attributes provide observability into those groups. a group is frequently used to denote the characteristics of a physical implementation, such as a 12 or 16 port card which fits into a modular chassis. the port object class contains objects that are used to manage the operation of individual ports in the repeater group. 2.1.1 basic control package (mandatory) table 2-1 lists the attribute, action, and notification management objects in the ieee 802.3 repeater management basic control package. these management objects are primarily concerned with repeater configuration information and repeater status (health). following the table is a brief description of the management object. because the basic control package objects do not require high speed event tracking, they are typically implemented in software. for the exact specification of these and other objects refer to the actual standard documents.
amd repeater management standards 2-2 table 2-1 ieee 802.3 repeater basic capabilities package repeater class object name object type ref. para repeater repeaterid attribute get 19.2.3.2 repeater repeatergroupcapacity attribute get 19.2.3.2 repeater groupmap attribute get 19.2.3.2 repeater repeaterhealthstate attribute get 19.2.3.2 repeater repeaterhealthtext attribute get 19.2.3.2 repeater repeaterhealthdata attribute get 19.2.3.2 repeater resetrepeater action 19.2.3.3 repeater executenondisruptiveselftest action 19.2.3.3 repeater repeaterhealth notification 19.2.3.4 repeater repeaterreset notification 19.2.3.4 repeater groupmapchange notification 19.2.3.4 resourcetypeid resourcetypeidname attribute get n/a resourcetypeid resourceinfo attribute get n/a group groupid attribute get 19.2.5.2 group groupportcapacity attribute get 19.2.5.2 group portmap attribute get 19.2.5.2 group portmapchange notification 19.2.5.2 port portid attribute get 19.2.6.2 port portadminstate attribute get 19.2.6.2 port autopartitionstate attribute get 19.2.6.2 port portadmincontrol action 19.2.6.3 repeaterid repeaterid is a read-only attribute used to identify the specific instance of the repeater in the system. it consists of an integer value between 1 and 1024. repeatergroupcapacity repeatergroupcapacity is a read-only attribute used to identify the maximum number of groups supported by this repeater. it consists of an integer value between 1 and 1024. repeatergroupcapacity can be larger than the actual number of installed groups. groupmap groupmap is a read-only attribute used to identify the actual installed groups in this repeater. it consists of a-bit string repeatergroupcapacity bits in length. each-bit signals the absence (0) or presence (1) of the group, numbered from lowest to highest. repeaterhealthstate repeaterhealthstate is a read-only attribute used to indicate the general health of the repeater. it consists of a numeric value. the possible values are: 1 other undefined or unknown 2 ok no known failures 3 repeaterfailure known to have a repeater-related failure 4 groupfailure known to have a group-related failure 5 portfailure known to have a port-related failure 6 generalfailure has an unspecified failure type in the event that multiple failures are present, the highest priority failure (lowest num- bered failure) should be reported.
amd 2-3 repeater management standards repeaterhealthtext repeaterhealthtext is a read-only attribute, consisting of a text string that provides relevant information about the operational state of the repeater to a network manager. the contents of this attribute are vendor specific, and can be used to provide detailed failure information or problem resolution instructions. the string must be printable text no longer than 255 characters in length. repeaterhealthdata repeaterhealthdata is a read-only attribute consisting of a block of information related to the operational state of the repeater. the encoding of the information is vendor specific, and must not exceed 255 bytes in length. resetrepeater resetrepeater is an action. when received, the repeater state is reset to start state as defined in the ieee 802.3 section 9 standard. this forces the repeater to execute a disruptive self-test. the exact requirements of the self test are unspecified. the repeater maintains management information throughout the execution of this action, and transmits a repeaterreset notification in response to this action request. during this action the repeater must not inject any packets onto any segment. received packets may or may not be transferred at the implementors discretion. executenondisruptiveselftest executenondisruptiveselftest is an action. when received, the repeater executes a vendor specific test. during the test the state of the repeater is unchanged, and the management information remains intact. this test must not inject any packets onto any segment attached to the repeater. this test does not interfere with the transfer of any packets through the repeater. completion of this test results in a repeaterhealth notification. repeaterhealth repeaterhealth is a notification. it is sent when the health state of a repeater changes, not including initial powering up of the repeater. at a minimum the repeaterhealth notification consists of the repeaterhealthstate attribute. it optionally includes the repeaterhealthtext and repeaterhealthdata attributes. repeaterreset repeaterreset is a notification. it is sent when the repeater is reset at power-up, or upon completion of the resetrepeater action. repeaterreset notification contains repeaterhealthstate, and optionally repeaterhealthtext and repeaterhealthdata attributes. groupmapchange groupmapchange is a notification that a group has been logically inserted or removed from the repeater. this notification is not sent during repeater power up. this notification consists of the new groupmap attribute. resourcetypeidname resourcetypeidname is a read-only attribute. it is used to contain the name of the resourcetypeid managed object, a fixed value of rtid. see 802.1f common definitions and procedures for ieee 802 management information (draft) for additional details. resourceinfo resourceinfo is a read-only attribute provided by repeater manufacturer. it is used to describe the resource. the attribute contains the manufactureroui (organizational unit identifier), manufacturername, manufacturerproductname, and manufacturerproduct- version. see 802.1f common definitions and procedures for ieee 802 management information (draft) for additional details.
amd repeater management standards 2-4 groupid groupid is a read-only attribute used to identify a specific instance of a group class in the repeater. it is an integer value in the range of 1 to 1024. this value cannot exceed repeatergroupcapacity. groupportcapacity groupportcapacity is a read-only attribute used to identify the number of potential ports in this instance of a group. it is an integer value in the range of 1 to 1024. the number of actual ports present may be less than or equal to the groupportcapacity. portmap portmap is a read-only attribute used to identify the actual installed ports in this group. it consists of a-bit string groupportcapacity bits in length. each-bit signals the absence (0) or presence (1) of the port, numbered from lowest to highest. portmapchange portmapchange is a notification that a port has been logically inserted or removed from the group. this notification is not sent during repeater power up. this notification consists of the new portmap attribute. portid portid is a read-only attribute used to identify the specific instance of the port in the group. it consists of an integer value between 1 and 1024. portadminstate portadminstate is a read-only attribute used to indicate whether the port is currently enabled or disabled. a disabled port does not transmit or receive. this attribute is preserved across repeater reset and loss of power. this attribute is not writable, however it is controlled through the portadmincontrol action. this attribute takes precedence over the auto-partition mechanism. a value of 1 means the port is disabled, a value of 2 means it is enabled. autopartitionstate autopartitionstate is a read-only attribute indicating the state of the port autopartition state machine. a value of a 1 means that the port is currently auto partitioned, a value of 2 means that the port is currently not auto partitioned. portadmincontrol portadmincontrol is an action. when received it modifies the portadminstate attribute. a 1 is used to enable the port, while a 0 is used to disable the port. a disabled port does not transmit or receive any information. a transition from disabled to enabled in the portadminstate causes the auto partition state machine to return to the begin state, as defined in section 9 of the ieee 802.3 standard. 2.1.2 performance monitoring package (optional) the performance monitoring package provides additional statistics beyond those provided by the basic control capabilities package. these statistics consist of multiple 32-bit counters on each port, all of which are fully supported by the amd himib. prior to the introduction of the amd himib these management objects required extensive hardware and software support.
amd 2-5 repeater management standards table 2-2 ieee 802.3 performance monitoring package repeater class object name object type ref. para. repeater transmitcollisions attribute get 19.2.3.2 port readableframes attribute get 19.2.6.2 port readableoctets attribute get 19.2.6.2 port framechecksequenceerrors attribute get 19.2.6.2 port alignmenterrors attribute get 19.2.6.2 port framestoolong attribute get 19.2.6.2 port shortevents attribute get 19.2.6.2 port runts attribute get 19.2.6.2 port collisions attribute get 19.2.6.2 port lateevents attribute get 19.2.6.2 port verylongevents attribute get 19.2.6.2 port dataratemismatches attribute get 19.2.6.2 port autopartitions attribute get 19.2.6.2 transmitcollisions transmitcollisions is a read-only attribute that counts the number of transmit collisions this repeater has detected. the value of the transmitcollisions attribute is a 32-bit counter with a minimum rollover time of 16 hours. readableframes readableframes is a read-only attribute that counts the number of valid frames detected by the port. valid frames are from 64 bytes to 1518 bytes in length, have a valid frame crc and are received without a collision. this attribute is a 32-bit counter with a minimum rollover time of 80 hours. readableoctets readableoctets is a read-only attribute that counts the number of total octets received on each port. this number is determined by adding the frame length to this register at the completion of every valid frame. this attribute is a 32-bit counter with a minimum rollover time of 58 minutes. framechecksequenceerrors framechecksequenceerrors is a read-only attribute that counts the number of frames detected on each port with an invalid frame check sequence. this counter is incre- mented on each frame of valid length (64 bytes to 1518 bytes) that does not suffer a collision during the frame. this counter is incremented on each invalid frame, however it is not incremented for frames with both framing errors and frame check sequence errors. this attribute is a 32-bit counter with a minimum rollover time of 80 hours. alignmenterrors alignmenterrors is a read-only attribute that counts the number of frames detected on each port with an fcs error and a framing error. frames that have both framing errors and fcs errors are counted by this attribute, but not by the framechecksequenceerrors attribute. this attribute is a 32-bit counter with a minimum rollover time of 80 hours. framestoolong framestoolong is a read-only attribute that counts the number of frames that exceed the 1518 byte maximum frame size. this attribute is a 32-bit counter with a minimum rollover time of 61 days.
amd repeater management standards 2-6 shortevents shortevents is a read-only attribute that counts the number of instances where activity is detected with a duration less than the shorteventmaxtime (74C82-bit times). this attribute is a 32-bit counter with a minimum rollover time of 16 hours. runts runts is a read-only attribute that counts the number of instances where activity is detected with a duration greater than the shorteventmaxtime (74C82-bit times), but less than the minimum valid frame time (512-bit times, 64 bytes). this attribute is a 32-bit counter with a minimum rollover time of 16 hours. collisions collisions is a read-only attribute that counts the number of instances where a carrier is detected on the port, and a collision is detected. this attribute is a 32-bit counter with a minimum rollover time of 16 hours. lateevents lateevents is a read-only attribute that counts the number of instances where a collision is detected after the lateeventthreshold (480C565-bit times) in the frame. this event will be counted both by the lateevents attribute, as well as the collisions attribute. this attribute is a 32-bit counter with a minimum rollover time of 81 hours. verylongevents verylongevents is a read-only attribute that counts the number of times the transmitter is active for greater than the mau jabber lockup protection timer allows (4 msC7.5 ms). this attribute is a 32-bit counter with a minimum rollover time of 198 days. dataratemismatches dataratemismatches is a read-only attribute that counts the number of occurrences where the frequency, or data rate of the incoming signal is detectably different from the local transmit frequency. this attribute is a 32-bit counter that is incremented on each such event. autopartitions autopartitions is a read-only attribute that counts the number of instances where the repeater has partitioned this port from the network. this attribute is a 32-bit counter that is incremented on each such event. 2.1.3 address tracking package (optional) the address tracking package provides optional information related to the mac address of frames received on each port. this information can be used to monitor attached station addresses on a port by port basis. all objects in the address tracking package are directly supported by the amd himib. table 2-3 ieee 802.3 address tracking package repeater class object name object type ref. para. port lastsourceaddress attribute get 19.2.6.2 port sourceaddresschanges attribute get 19.2.6.2 lastsourceaddress lastsourceaddress is a read-only attribute that saves the value of the source address field in the last frame it received. this attribute is a 6-byte field.
amd 2-7 repeater management standards sourceaddresschanges sourceaddresschanges is a read-only attribute that counts the number of times the source address field of received frames changes. this attribute is a 32-bit counter with a minimum rollover of 81 hours. 2.2 ieee 802.3 mau management section 20 of the ieee 802.3 standard defines the management requirements of a media attachment unit (mau). table 2-4 defines the management objects specified in ieee 802.3 section 20. this standard was in draft form at the time this document was written, so the objects may change. the objects had not yet been assigned numbers at the time this was written. refer to the draft document for detailed descriptions of the mau object definitions. like the ieee 802.3 repeater management standard, the ieee 802.3 mau manage- ment draft consists of several packages. the basic package is the minimum subset required for a managed mau. the mau control package is an optional package that provides management control of mau operation. the media loss tracking package (actually one attribute) is a mandatory package for auis that keeps statistics on the media availability. the media loss tracking package is optional for other maus. finally, the broadband dte mau package is a required set of management objects in broadband maus. table 2-4 ieee 802.3 mau management package object name object type reference basic mauid attribute 20.2.3.2 basic mautype attribute 20.2.3.2 basic maumediaavailable attribute 20.2.3.2 basic jabber attribute 20.2.3.2 basic mauadminstate attribute 20.2.3.2 basic jabber notification 20.2.3.4 mau control resetmau action 20.2.3.3 mau control mauadminctrl action 20.2.3.3 media loss tracking maulosemediacounter attribute 20.2.3.2 broadband dte mau bbandsplittype attribute 20.2.3.2 broadband dte mau bbandfrequencies attribute 20.2.3.2 mauid mauid is a read-only attribute used to identify the specific instance of the mau on the port. it consists of an integer value. mautype mautype is a read-only attribute used to identify the ieee 802.3 mau type. this consists of an integer value, that is the section number where the specific type of mau is specified. maumediaavailable maumediaavailable is a read-only attribute used to signal the status of the media link. for link based maus such as 10base-t this is the link test fail state. for other maus such as the basic aui interface this is the loopback detection status. maulosemediacounter maulosemediacounter is a read-only attribute used to count the number of times the maumediaavailable attribute has gone fromavailable to any other state. this counter must not be allowed to increment at a rate greater than 10 times per second.
amd repeater management standards 2-8 jabber jabber is a two part attribute consisting of a jabberflag, and a jabbercounter. both parts of the attribute are read-only. the jabber counter attribute counts the number of times the jabberflag enters the fault state. this counter must not be allowed to increment at a rate greater than 40 times per second. mauadminstate mauadminstate is a read-only attribute used to indicate the current control status of the mau, that is what state the manager previously commanded the mau to assume. refer to mauadminctrl for the state definitions. bbandsplittype bbandsplittype is a read-only attribute used to monitor the configuration of a broad- band ieee 802.3 mau. this attribute indicates whether the broadband cabling system is a single cable system or a dual cable system. bbandfrequencies bbandfrequencies is a two part integer used for a broadband ieee 802.3 mau consisting of the transmitter carrier frequency and the translation offset frequency. the transmitter carrier frequency part of the attribute is the actual transmitter carrier frequency divided by 250 khz. likewise the translation offset frequency part of the attribute is the translation offset frequency divided by 250 khz. resetmau resetmau is an action that results in the mau performing a reset. this reset must be at least 1/2 second in length, during which the aui di, do, and ci should be idle. this reset should operate the same as a power on reset. mauadminctrl mauadminctrl is an action that controls the operational state of the mau. jabber jabber is a notification that the mau has detected a jabber fault. this is the same condition that determines the state of the jabber attribute (jabberflag). 2.3 novell's hub management interface (hmi) novell inc. has defined the hub management interface (hmi) specification. supporting ieee 802.3 or hub cards in novell file servers, this specification defines the hardware independent driver requirements for managed third party hub card vendors. this document specifically focuses on support for 10base-t repeaters, rather than support- ing ieee 802.3 repeaters in general. the interface consists of two components. the first is a definition of objects accessible through get and set commands from the hub management protocol layers. the second is a specification of the memory structure used to communicate between the hub driver and the hub protocol stack. two different memory structures are defined, the hub interface table (hit), and the group interface table (git). the ieee 802.3 managed objects are split into two groups. part of the objects are managed using the get and set capabilities of hmi. others are accessed through variables in the hit and git. the hmi specification was developed during the draft stages of the ieee 802.3 repeater management specification, and differs in the number of managed objects. note that the following ieee 802.3 repeater management objects have no hmi equivalence: repeaterid, resourceinfo, groupid, portmap, portmapchange, and portid. additionally hmi offers only very limited support for the newly developed mau manage- ment specification.
amd 2-9 repeater management standards 2.3.1 novell hmi/ieee 802.3 repeater mib mapping table 2-5 provides a summary of the hmi management objects, and their ieee 802.3 equivalents. the text following the table provides an overview of the objects not previously described in the 802.3 repeater management section. for more detailed information refer to the novell hmi specification. the novell management attributes are divided into four classes. the first three mimic the ieee 802.3 repeater management definitions, with basic control, performance monitoring, and address tracking packages. the fourth is called novell extensions, and includes additional management attributes. table 2-5 hmi to ieee 802.3 management object equivalencies object package hmi object name hmi # ieee object name basic infotablepointer 0 basic resethubaction 1 resetrepeater basic executesselftest1action 2 executenondisruptive selftestaction basic executesselftest2action 3 basic portadminstate 4 portadminstate basic autopartitionstate 5 autopartitionstate performance transmitcollisions 6 transmitcollisions performance repeaterverylongevents 7 performance portverylongevents 8 verylongevents performance readableframes 9 readableframes performance readableoctets 10 readableoctets performance framechecksequenceerrors 11 framechecksequenceerrors performance alignmenterrors 12 alignmenterrors performance framestoolong 13 framestoolong performance shortevents 14 shortevents performance runts 15 runts performance collisions 16 collisions performance lateevents 17 lateevents performance dataratemismatches 18 dataratemismatches performance autopartitions 19 autopartitions address lastsourceaddress 20 lastsourceaddress address sourceaddresschanges 21 sourceaddresschanges novell portlinkstate 22 amediaavailable (mau mgmt) novell repeatertotaloctets 23 novell porttype 24 infotablepointer infotablepointer is a pointer to the hub information table (hit). this pointer is used to access other hub management information. executeselftest1action executeselftest1action is equivalent to the 802.3 repeater management executenondisruptiveselftest action.
amd repeater management standards 2-10 executeselftest2action executeselftest2action is an action that causes the repeater to perform a disruptive self test. this test may interfere with the transfer of packets through the repeater. portadminstate this hmi management object consists of two ieee 802.3 objects. both set and get operations are available for this object. the set operation corresponds to the ieee 802.3 portadmincontrol action, while the get operation corresponds to the ieee 802.3 portadminstate management attribute. repeaterverylongevents this management attribute tracks the number of verylongevents the repeater has seen on all ports. this attribute is the sum of the ieee 802.3 verylongevents attribute across all ports in the repeater. portlinkstate this management attribute is a novell vendor specific extension to the basic ieee 802.3 management attributes. its purpose is to track on a port by port basis whether the port is receiving link status pulses. this attribute consists of an integer value from 1 to 3, with the following meaning: 1 link up 2 link down 3 not applicable C the port is not a 10base-t port. repeatertotaloctets this management attribute is a novell vendor specific extension to the basic ieee management attributes. this attribute counts the total number of bytes repeated by the hub, whether the frame had a valid fcs or not. this counter adds 8 bytes per frame for the preamble. porttype this management attribute is a novell vendor specific extension to the basic ieee management attributes. this attribute is a number from 1 to 4, with the following meanings: 1 other port type 2 normal port type 3 local host port 4 aui port 2.3.2 hub information table (hit) table 2-6 describes the structure of the hub information table (hit). several of the variables in the table represent ieee 802.3 repeater management attributes, and are passed through the table instead of through managed object requests.
amd 2-11 repeater management standards table 2-6 hmi hub information table hmi object name hit table offset (hex bytes) ieee object name reserved 00 hubtype 10 reserved1 11 majorversion 12 minorversion 13 manufacturerid 14 resourcetypeidname reserved2 17 hubdescriptionpointer 18 hubversionpointer 1c healthstate 20 repeaterhealthstate healthtextpointer 24 repeaterhealthtext healthdatapointer 28 repeaterhealthdata healthdatalength 2c groupssupported 2e repeatergroupcapacity groupinfotablepointer 30 capabilitiesbitmap 34 most of the entries in this table do not have ieee 802.3 equivalents. the following is a brief description of these parameters. refer to the hmi specification for more details. reserved this is a 16-byte reserved field. hubtype this 1-byte field is set to a 1 to signify that this hub is a 10base-t hub. reserved1 this is a 1-byte reserved field. majorversion this field is a hit major version number. the version number of this table is 1. minorversion this field is a hit minor version number. the current number of this table is 0. manufacturerid this is a 3-byte manufacturers id field, as specified in the ieee 802.1f recommended practice draft document. the ieee 802.1f equivalent attribute is the resourceinfo and is typically the three leading bytes of the manufacturers mac address. reserved2 this is a 1-byte reserved field. hubdescriptionpointer this field points to a text string describing this hub. hubversionpointer this field points to a text string that describes the hubs version number. healthdatalength this is the length in bytes of the preceding healthdatapointer. because the healthdata string contains binary information, it cannot be terminated by a 0.
amd repeater management standards 2-12 groupinfotablepointer this is a 4-byte pointer to the group information table (git). capabilitiesbitmap this field is a 1-byte value indicating the level of management capabilities present in this hmi managed hub. these numbers can be in the range from 0 to 3, with the following meanings: 0 basic control 1 performance monitoring 2 address tracking 3 novell extensions 2.3.3 group information table (git) table 2-7 is the group information table. it is used to provide information related to specific groups of ports in the repeater. several of the ieee 802.3 mib attributes are passed through the group information table instead of being transferred as managed objects. table 2-7 hmi group information table git # git object name ieee object name 00 installed groupmap 01 slot 02 ports groupportcapacity 04 description 08 objectidpointer 0c objectidlength 0e installedtime 12 driverworkspace slot this is an optional 1-byte field to indicate the slot number of the selected hub group. description this is a 4-byte pointer to a text string indicating information about this group. objectidpointer this is a 4-byte pointer to the array of 16-bit words, that provides the manufacturers group identification information. the format for this information is documented in the structure and identification of management information for tcp/ip based internets enterprise subtree. this provides an exact specification of the class of group being managed. objectidlength this 2-byte value is the length of the object id array in bytes. installedtime this 4-byte field is the system time when the group was last installed in the hub. driverworkspace this 10-byte field is available for the driver to use as temporary storage during its execution.
amd 2-13 repeater management standards 2.3.4 hmi notifications in addition to hmi managed objects, and attributes passed through the hit and git, the novell hmi document specifies how various events in the repeater can cause a notification message to be passed to the hub manager. table 2-8 lists the notification messages required by the hmi specification. these notifications correspond to their ieee 802.3 equivalents. table 2-8 hmi notifications hmi object name hmi # ieee 802.3 object name healthchange 1 repeaterhealth groupchange 2 groupmapchange hubreset 3 repeaterreset 2.4 ietf managed objects for ieee 802.3 repeaters as the ieee 802.3 committee defined the repeater management objects, the ietf extended the definition to specify a protocol and encoding to use in the remote manage- ment of these objects. the ietf also defined additional objects for use in managing repeaters. the actual definition and syntax of these objects is defined in rfc 1368, definitions of managed objects for ieee 802.3 repeater devices. table 2-9 lists the ietf 802.3 repeater mib get and set attributes, and cross references it to the ieee 802.3 repeater management attributes and actions. refer to rfc 1368 for a detailed description of each management object. many of the snmp managed objects have no corresponding analog in the ieee 802.3 repeater mib. table 2-9 snmp to ieee 802.3 attribute cross-reference ietf 802.3 repeater ieee 802.3 repeater ietf identification code mib reference mib reference snmpdot3rptrmgt.1.1.1 rptrgroupcapacity repeatergroupcapacity snmpdot3rptrmgt.1.1.2 rptroperstatus repeaterhealthstate snmpdot3rptrmgt.1.1.3 rptrhealthtext repeaterhealthtext snmpdot3rptrmgt.1.1.4 rptrreset resetrepeater snmpdot3rptrmgt.1.1.5 rptrnondisrupttest executenondisruptiveself testaction snmpdot3rptrmgt.1.1.6 rptrtotalpartitionedports snmpdot3rptrmgt.1.2.1.1.1 rptrgroupindex groupid snmpdot3rptrmgt.1.2.1.1.2 rptrgroupdescr snmpdot3rptrmgt.1.2.1.1.3 rptrgroupentry snmpdot3rptrmgt.1.2.1.1.4 rptrgroupoperstatus snmpdot3rptrmgt.1.2.1.1.5 rptrgrouplastoperstatuschange snmpdot3rptrmgt.1.2.1.1.6 rptrgroupportcapacity groupportcapacity snmpdot3rptrmgt.1.3.1.1.1 rptrportgroupindex snmpdot3rptrmgt.1.3.1.1.2 rptrportindex portid snmpdot3rptrmgt.1.3.1.1.3 rptrportadminstatus portadminstate portadmincontrol snmpdot3rptrmgt.1.3.1.1.4 rptrportautopartitionstate autopartitionstate snmpdot3rptrmgt.1.3.1.1.5 rptrportoperstatus
amd repeater management standards 2-14 table 2-9 snmp to ieee 802.3 attribute cross-reference (continued) ietf 802.3 repeater ieee 802.3 repeater ietf identification code mib reference mib reference snmpdot3rptrmgt.2.1.1 rptrmonitortransmitcollisions transmitcollisions snmpdot3rptrmgt.2.2.1.1.1 rptrmonitorgroupindex snmpdot3rptrmgt.2.2.1.1.2 rptrmonitorgrouptotalframes snmpdot3rptrmgt.2.2.1.1.3 rptrmonitorgrouptotaloctets snmpdot3rptrmgt.2.2.1.1.4 rptrmonitorgrouptotalerrors snmpdot3rptrmgt.2.3.1.1.1 rptrmonitorportgroupindex snmpdot3rptrmgt.2.3.1.1.2 rptrmonitorportindex portid snmpdot3rptrmgt.2.3.1.1.3 rptrmonitorportreadableframes readableframes snmpdot3rptrmgt.2.3.1.1.4 rptrmonitorportreadableoctets readableoctets snmpdot3rptrmgt.2.3.1.1.5 rptrmonitorportfcserrors framechecksequenceerrors snmpdot3rptrmgt.2.3.1.1.6 rptrmonitorportalignmenterrors alignmenterrors snmpdot3rptrmgt.2.3.1.1.7 rptrmonitorportframetoolongs framestoolong snmpdot3rptrmgt.2.3.1.1.8 rptrmonitorportshortevents shortevents snmpdot3rptrmgt.2.3.1.1.9 rptrmonitorportrunts runts snmpdot3rptrmgt.2.3.1.1.10 rptrmonitorportcollisions collisions snmpdot3rptrmgt.2.3.1.1.11 rptrmonitorportlateevents lateevents snmpdot3rptrmgt.2.3.1.1.12 rptrmonitorportverylongevents verylongevents snmpdot3rptrmgt.2.3.1.1.13 rptrmonitorportdatarate dataratemismatches mismatches snmpdot3rptrmgt.2.3.1.1.14 rptrmonitorportautopartitions autopartitions snmpdot3rptrmgt.2.3.1.1.15 rptrmonitorporttotalerrors snmpdot3rptrmgt.3.1.1.1.1 rptraddrtrackgroupindex snmpdot3rptrmgt.3.1.1.1.2 rptraddrtrackportindex portid snmpdot3rptrmgt.3.1.1.1.3 rptraddrtracklastsourceaddress lastsourceaddress snmpdot3rptrmgt.3.1.1.1.4 rptraddrtracksourceaddrchanges sourceaddresschanges snmpdot3rptrmgt.3.2 rptraddrtrackgroupinfo snmpdot3rptrmgt.3.3 rptraddrtrackportinfo table 2-10 lists the ietf traps, which correspond to the ieee management notifications objects. table 2-10 snmp trap to ieee 802.3 notification cross-reference ietf 802.3 repeater ieee 802.3 repeater ietf identification code mib reference mib reference snmpdot3rptrmgt.1 rptrhealth repeaterhealth snmpdot3rptrmgt.2 rptrgroupchange groupmapchange snmpdot3rptrmgt.3 rptrresetevent repeaterreset
3-1 imr/imr+ overview imr/imr+ overview 3 section 3.1 functional description the am79c981 integrated multiport repeater plus device is a single chip implementa- tion of an ieee 802.3/ethernet repeater (or hub). in addition to the eight integral 10base-t ports plus one aui port comprising the basic repeater, the imr+ chip also provides the hooks necessary for complex network management and diagnostics. the imr+ device is also expandable, enabling the implementation of high port count repeaters based on several imr+ devices. the imr+ device interfaces directly with amds am79c987 hardware implemented management information base (himib) device to allow a fully managed multiport repeater to be implemented as specified by the ieee 802.3 layer management for 10 mb/s baseband repeaters standard. when the imr+ and himib devices are used as a chip set, the himib device maintains complete repeater and per port statistics which can be accessed on demand by a microprocessor through a simple 8-bit parallel port. figure 3-1 imr+ block diagram aui management port expansion port twisted pair port 0 twisted pair port 7 repeater state machine 17314a-6 the imr+ device differs from the original imr chip in only a few minor internal details. the imr+ device is pin, software and timing compatible with the imr device, and may be used as a direct replacement in an existing imr-based design. most of the enhance- ments in the imr+ device relate to the provision of additional internal status information, which is primarily included for use by the companion himib device. the himib device requires this enhanced status information in order to allow implementation of a fully managed repeater, compliant to the ieee 802.3 layer management for 10 mb/s baseband repeaters standard. the implementation of managed repeaters is covered in detail in section 5 of this manual, and the complete definition of all changes between the
amd imr/imr+ overview 3-2 imr and imr+ devices is contained in this section under differences between the imr and imr+ devices. from the perspective of a simple low cost, unmanaged repeater application, the primary additional feature offered by the imr+ device over and above that of the original imr device, is the provision of a minimum mode, designed to minimize the external support logic to provide simple diagnostic and status related indicators (leds). the minimum mode is explained in more detail in this section under minimum mode operation. 3.2 imr/imr+ based velcro tm hub design for low end systems, the imr combined with a power supply, crystal and emi/rfi filter/transformer modules, effectively produces a fully operational 10base-t repeater, with an aui port to allow connection to an existing 10base2/5 coax backbone. figure 3-2 simple velcro tm hub example power supply regulator quad filter/ transformer module imr/imr+ aui isolation quad filter/ transformer module 17314a-7 status leds 3.2.1 imr-based velcro tm hub design a velcro hub application example is shown in figure 3-3. the external pal connects to the management port of the imr device, and implements a simple state machine. this is used to configure the programmable options of the imr device at power up (if the default options need to be changed), and then continuously clocks in management port get requests on the si pin. it also clocks out the results on the so pin to obtain internal status information (such as the link status, partitioning or polarity). the result of the get request, output on the so pin by the imr device, is shifted into the external serial-to-parallel converter, and used to drive led status indicators, using a simple pulse stretch and driver circuit. the state machine can be enhanced to allow external selection (through a front panel mounted switch or other selection mechanism) of different management port get requests, such that the same leds can be used to display various status information. the imr velcro tm hub board is available from amd as an example design kit, which details these concepts.
amd 3-3 imr/imr+ overview figure 3-3 velcro hub design using the imr device ack req jam si so sclk x1 am79c980 imr tp port 0 aui port tp port 7 v dd v dd 8 link test status leds 20 mhz + 0.01% x2 state machine (pal) 8-bit sipo shift register and led driver shift clk serin col dat 10 k 10 k note: unused receiver pairs (di +/-, ci +/-, rxd n +/-) should be shorted together. 100 pf 100 pf 17314a-8 3.2.2 imr+ based velcro hub design the design of a simple repeater using the imr+ device is simplified by use of the minimum mode, which allows status information to be continuously output from the management port of the imr+ device, without the need for an external state machine. figure 3-4 shows an application example employing the imr+ device in minimum mode. figure 3-4 velcro hub design using the imr+ device am79c981 imr+ chip xtal osc ck d q async reset x1 x2 rst str so clr ck q q d 1/2 74 tck ck si sipo ck t p 7 t p 6 t p 5 t p 0 a u i 1/2 74 tck sclk si register test 17314a-9
amd imr/imr+ overview 3-4 in this configuration, the imr+ device will continuously output one of four status conditions on the so pin, dependent on the programming of the test and si pins. the programming of si and test allows any one of the following status indications to be reported on so: aui port loop back status (1-bit) and twisted pair port link status (8-bits) aui/twisted pair port partitioning status (9-bits) aui port sqe test error status (1-bit) and twisted pair polarity status (8-bits) aui/twisted pair port bit rate error status (9-bits) the state of the si and test pins can be changed at any time to select alternative status of the so pin. the data on the so pin is output as a 10-bit serial stream (aui status first, followed by tp0 status, tp1 status, etc.). a blank period of 100 ns will occur after the 9 status bits have been output, during which time the str pin will be active, delineating the start/end of each status window. the so output stream can be directly input to a serial-to- parallel convertor, and used to drive led status indicators using appropriate latches and drivers. the details of the programming and timing of minimum mode are covered in the following section. since the data presented on the so pin may be valid for only one status window (so an individual bit, such as the aui loop back error, may be active for only 100 ns), external pulse stretch circuitry should be included to ensure that the led indicators are visible. note that the normal get and set capabilities of the imr+ management port are unavailable when minimum mode is selected. 3.2.3 minimum mode operation the imr+ minimum mode supports designs of low end, unmanaged repeaters. this mode uses minimal additional support logic to display the following status indicators: n aui port loop back status and twisted pair port link status n aui/twisted pair port partitioning status n aui port sqe test error status and twisted pair port receiver polarity status n aui/twisted pair port bit rate error status additionally the minimum mode of the imr+ chip supports automatic receive polarity detection/correction without the addition of external logic. the imr+ device determines that minimum mode is selected by monitoring the state of the test pin while rst is asserted. if test is high (asserted), while reset is active ( rst low) it enters minimum mode. additionally the state of the si pin during reset determines if the imr+ device is to be programmed for automatic polarity detection/ correction. the test input must be deasserted on the rising edge of reset. a maximum delay of 100 ns is allowed to account for propagation delay. test si function 0 0 normal management mode 0 1 normal management mode 1 0 minimum mode, receive polarity detection/correction disabled. 1 1 minimum mode, receive polarity detection/correction enabled.
amd 3-5 imr/imr+ overview in minimum mode, the so pin is used to serially output the imr+ chips status informa- tion based on the state of the si and sclk pins: sclk si so output 0 0 aui port sqe test error status + tp port receive polarity status 0 1 bit rate error status (all ports) 1 0 aui port loop back status + tp ports link status 1 1 partitioning status (all ports) the output format and timing is identical to that of the crs and str when the imr+ device is used in the stand alone mode (see figure 3-5). figure 3-5 management port minimum mode and port activity monitor signal relationship x1 crs (note 2) str crs aui crs tp0 crs tp1 crs tp2 crs tp3 crs tp4 crs tp5 crs tp6 crs tp7 crs aui tck (note 1) so (note 3) so aui so tp0 so tp1 so tp2 so tp3 so tp4 so tp5 so tp6 so tp7 so aui notes: 1. externally generated signal illustrates internal imr+ chip clock phase relationship. 2. crs timing with the c-bit cleared (imr+ chip programmable options) 3. for minimum mode 17314a-10 when si = 0, so outputs the related aui status bits (loop back error or sqe test error, depending on the value of sclk), followed by the 8 tp status bits (receive polarity or link status, depending on the value of sclk). the tp status bits are output in order from port 0 to port 7. when si = 1, the port partitioning status or port bit rate error status indicators are output (depending on the value of sclk). the aui is output first, followed by the tp port indicators starting with port 0. the timing of the so output matches that of the port activity monitor (pam). the state of the si and sclk pins is checked at the end of every cycle after all port status indicators have been output. the rising edge of the x1 clock, occurring before falling edge of str, is used to strobe in the state of the si and sclk pins. the imr+ device may be programmed into minimum mode only at reset, and cannot be modified until a subsequent reset.
amd imr/imr+ overview 3-6 3.3 port activity monitor (pam) operation two imr+ device pins, crs and str, are used to serially output the state of the internal carrier sense signals from the aui and the eight twisted pair ports. this function together with external hardware or software can be used to monitor repeater receive and collision activity. the accuracy of the crs signals is 10 bit times (bt) (1 m s). a transition to active state by any of the internal carrier sense bits that lasts for less than 10bt is latched internally and is used to set the appropriate bit during the next sample period. see figure 3-5 for an illustration of the timing of the port activity monitor. 3.3.1 stand-alone imr/imr+ device (with str output) figure 3-6 shows how external hardware can be employed to convert the serial crs bit stream into a parallel format suitable for a receive activity display. note that since the data presented on the crs pin may be valid for only a single 100 ns period, and the fact that a maximum ethernet packet length is only ~1.2 ms in duration, external pulse stretch circuitry should be included to ensure that the led indicators are visible. figure 3-6 port activity monitor imr/imr+ xtal osc ck d q async reset x1 x2 rst str crs clr ck q q d 1/2 74 tck ck si sipo ck register t p 7 t p 6 t p 5 t p 0 a u i shift register carrier sense outputs 1/2 74 tck 17314a-11
amd 3-7 imr/imr+ overview figure 3-7 shows one possible hardware implementation of the interface between the imr+ device and some led displays. it should be stressed that this is only an example, and is not intended to represent the most cost-effective method of implementing this function. this implementation may also be used to display the data output on the so pin in minimum mode. figure 3-7 example implementation of port activity monitor registers v cc gnd tck str crs crstp7 crstp6 crstp5 crstp4 crstp3 crstp2 crstp1 crstp0 crsaui 6 7 8 9 10 11 13 14 15 16 17 18 19 20 21 23 22 y 0 ser/q15 y 1 y 2 y 3 y 4 y 5 y 6 y 7 y 8 y 9 y 10 y 11 y 12 y 13 y 14 y 15 74ls673 shclk m/sclk strclr r/ w cs 2 5 4 3 1 17314a-12 3.3.2 imr+ with himib device (no str output) when the imr+ chip is used with the himib device, the str pin of the imr+ chip becomes an input. see section 5 under managed repeater status indicators for details on how to implement the port activity monitor in this case. 3.4 link test state machine description the link test function in the imr and imr+ devices is implemented as specified by the 10base-t standard. during periods of transmit pair inactivity, link test pulses will be sent over the twisted pair medium every 8 msC17 ms, to indicate medium integrity. when the link test function is enabled, the absence of link test pulses and receive data on the rxd pair of an imr+ chips 10base-t port will cause the port to go into a link fail state. in the link fail state, data transmission, data reception and the collision detection functions are disabled, and remain disabled until valid data or 4 consecutive link test pulses appear on the rxd pair. during link fail, issuing the command to get link test status of tp ports using the management port will return the state for the port as zero (cleared). when the link is identified as functional, the corresponding status will be reported as one. note that in the case of the imr device, if a 10base-t port is disabled, its corresponding status will always be returned as link pass. in the case of the imr+ device, the status of the link will be reported accurately even if the port is disabled. in order to inter-operate with systems which do not implement link test pulses, this function can be disabled by issuing the disable link test function command using the
amd imr/imr+ overview 3-8 imr+ management port (with the appropriate individual port identified within the command). with link test disabled, the data driver, receiver and loopback functions as well as collision detection remain enabled irrespective of the presence or absence of data or link test pulses on the rxd pair. note that the imr/imr+ device will continue to transmit link test pulses, regardless of the state of the disable link test function, or whether the port is disabled or auto-partitioned. this ensures that the mau at the opposite end of the link segment will interoperate, regardless of whether it requires link test pulses or not. 3.5 receive polarity detection/correction algorithm the imr/imr+ device receive function includes the ability to invert the polarity of the signals appearing at the rxd pair if the polarity of the received signal is reversed (such as in the case of a wiring error). this feature allows data packets received from a reverse wired rxd input pair to be corrected in the imr/imr+ device prior to re-transmission via the twisted pair, aui or expansion port interfaces. following reset, the polarity detection/correction function must be explicitly enabled for the 10base-t ports. this is accomplished by issuing the set command enable automatic receiver polarity reversal using the imr/imr+ management port, or by programming the imr+ device into the minimum mode. any port with polarity detection/correction enabled which is in the link fail state, will detect the receive polarity based on the polarity of subse- quent packets with a valid end of transmit delimiter (etd). when in the link fail state, the imr+ device will recognize link test pulses of positive polarity. positive link test pulses are defined as received signal with a positive amplitude greater than 520 mv with a pulse width of 60 nsC200 ns. this positive excursion may be followed by a negative excursion. this definition is consistent with the expected received signal at a correctly wired receiver when a link test pulse which fits the template of figure 14-12 in the 10base-t standard is generated at a transmitter and passed through 100 m of twisted pair cable. negative link test pulses are ignored. exit from the link fail state is made due to the reception of four consecutive positive link test pulses, which are spaced not closer than 2.04 msC4.1 ms (nominal) and not greater than 65.5 msC131.1 ms apart. when the imr/imr+ enters the link pass state, the polarity detection/correction algorithm will remain armed until two consecutive packets with valid etd of identical polarity are detected. when armed, the receiver is capable of changing the initial or previous polarity configuration based on the most recent etd polarity. on receipt of the first packet with valid etd following link fail, the imr+ device will utilize the inferred polarity information to configure its rxd input, regardless of its previous state. on receipt of a second packet with a valid etd with correct polarity, the detection/correction algorithm will lock-in the received polarity. if the second (or subsequent) packet is not detected as confirming the previous polarity decision, the most recently detected etd polarity will be used as the default. note that packets with invalid etd have no effect on updating the previous polarity decision. once two consecutive packets with valid etd have been received, the imr+ device will disable the detection/correction algorithm until either a link fail condition occurs or the port is disabled and re-enabled (when the port is forced into link fail) using the management port. if normal (correct) polarity is detected for a port, issuing the command to get receive polarity status of tp ports using the management port will return the state for the port as zero (cleared). if the reversed polarity has been detected/corrected, the correspond- ing status will be reported as one.
amd 3-9 imr/imr+ overview 3.6 alternate reconnection algorithm the aui port and each of the tp ports can be partitioned when experiencing excessive frequency or duration of collisions. excessive frequency of collisions is defined as more than 31 consecutive collisions on a single port. excessive duration of collision is defined as the sqe signal active for more than 1024-bit times. reconnection is the process whereby the port is returned to operational status after partitioning. the imr+ device supports two reconfiguration algorithms. the standard ieee 802.3 algorithm is the default algorithm, and is activated when the imr+ chip is reset. this algorithm allows a partitioned port to be reconnected if it is able to transmit or receive data for a period of 512 bit times without experiencing a collision. the alternate reconnection algorithm will reconnect the partitioned port only if the port is able to transmit data for a period of 512 bit times without a collision. this mode is programmed through the management port. once the alternate reconnection algorithm is programmed, the imr+ chip must be hardware reset to return it to the default (standard 802.3) algorithm. 3.7 interaction between port disable and port autopartition disabling a port forces the autopartition state machine of that port into the idle state (port reconnected). therefore, a partitioned port may be reconnected by first disabling and then re-enabling the port. this is in accordance with the 802.3 repeater manage- ment standard requirements.
amd imr/imr+ overview 3-10 3.8 imr/imr+ management port table 3-1 lists the management port command op-codes for both the imr and imr+ devices. additionally, the table lists the command formats, and the response codes for the management get commands. this section provides a detailed description of the imr+ device command op-codes. table 3-1 imr/imr+ management commands command command response type command description imr/imr+ code (get only) set imr+ chip programmable options imr+ only 0000 1csa set alternate aui port partitioning algorithm imr/imr+ 0001 1111 set alternate tp port partitioning algorithm imr/imr+ 0001 0000 set aui port disable imr/imr+ 0010 1111 set aui port enable imr/imr+ 0011 1111 set tp port disable imr/imr+ 0010 #### set tp port enable imr/imr+ 0011 #### set disable link test function (per tp port) imr/imr+ 0100 0### set enable link test function (per tp port) imr/imr+ 0101 0### set disable auto polarity correction (per tp port) imr/imr+ 0110 0### set enable auto polarity correction (per tp port) imr/imr+ 0111 0### get aui port status (bsl cleared) imr+ only 1000 1111 pbsl 0000 get aui port status (sl cleared) imr+ only 1000 1011 pbsl 0000 get aui port status (b cleared) imr+ only 1000 1101 pbsl 0000 get aui port status (none cleared) imr+ only 1000 1001 pbsl 0000 get tp port partitioning status imr/imr+ 1000 0000 c7 ... c0 get bit rate error status of tp ports imr+ only 1010 0000 e7 ... e0 get link test status of tp ports imr/imr+ 1101 0000 l7 ... l0 get receive polarity status of tp ports imr/imr+ 1110 0000 p7 ... p0 get mjlp status imr+ only 1111 0000 m000 0000 get version imr 1111 1111 xxxx 0000 imr+ 1111 1111 xxxx 0001 get aui port status imr only 1000 1111 p000 0000 3.8.1 management port the imr+ device management functions are enabled when the test pin is tied low. the management commands are byte oriented data and are input serially on the si pin. any responses generated during execution of a management command are output serially in a byte-oriented format by the imr+ device on the so pin. both the input and output data streams are clocked with the rising edge of the sclk pin. the serial command data stream and any associated results data stream are structured in a manner similar to the rs232 serial data format, i.e., one start bit followed by eight data bits. the externally generated clock at the sclk pin can be either a free running clock synchronized to the input bit patterns or a series of individual transitions meeting the
amd 3-11 imr/imr+ overview setup and hold times with respect to the input bit pattern. if the latter method is used, it is to be noted that 20 sclk clock transitions are required for proper execution of management commands that produce so data, and that 14 sclk clock transitions are needed to execute management commands that do not produce so data. 3.8.2 management commands the following section details the operation of each management command available in the imr+ chip. in all cases, the individual bits in each command byte are shown with the msb on the left and the lsb on the right. data bytes are received and transmitted lsb first and msb last. see table 3-1 for a summary of the management commands. set (write) opcodes imr+ chip programmable options si data: 0000 1csa so data: none imr+ chip programmable options can be enabled (disabled) by setting (resetting) the appropriate bit in the command string. the three programmable bits are: c ci reporting; s aui sqe test mask, and a alternative port activity monitor (pam) function. these options can be enabled (disabled) by setting (resetting) the appropriate bit in the command string. when writing to this register through the am79c987 himib device, the a and c bits should not be changed (a=0, c=1). cci reporting setting this bit alters the function of the str pin. in this mode, the str pin becomes an input in response to the amds am79c987 himib device. upon deassertion of rst , the himib automatically sets this bit following imr+ device type detection. when this mode is selected, the crs output bit string format is modified to include ci carrier bit (in addition to aui carrier). this bit occupies the bit position immediately preceding the aui bit in the crs bit string (10 bits) output. note that the aui carrier bit gets asserted if either the ci or di signal pairs are active. saui sqe test mask setting this bit allows the imr+ chip to ignore activity on the ci signal pair, during the sqe test window following a transmission on the aui port. this event occurs when the attached mau has the sqe test option enabled, therefore generating a burst of ci activity following every transmission. this is interpreted by the imr+ device as a collision, causing the imr+ device to generate a full jam pattern. although the mau attached to a repeater is required not to have its sqe test function active, this is a common installation error, causing difficulty in diagnosing network throughput problems. the sqe test window, as defined by the ieee 802.3 (section 7.2.2.2.4), is from 6-bit times to 34-bit times (0.6 m s to 3.4 m s). this includes delay introduced by a 50 m aui. ci activity that occurs outside this window is not ignored and is treated as true collision. note that enabling this function does not prevent the reporting of this condition by the imr+ device (s bit in get aui port status) since the two functions operate independently. aalternative port activity monitor (pam) function setting the alternative port activity monitor function allows the pam function to be altered such that the carrier sense data is presented unmodified. in default operation the pam output (carrier sense bit in the crs bit stream) is masked if the port is either disabled or partitioned. this does not allow the repeater management software to sense activity on all segments at all times. the ability to monitor partitioned or disabled ports allows fault tolerant features to be built into the repeater management software.
amd imr/imr+ overview 3-12 alternate aui port partitioning algorithm si data: 00011111 so data: none the aui port partitioning/reconnection scheme can be programmed for the alternate (transmit only) reconnection algorithm by invoking this command. to return the aui back to the standard (transmit or receive) reconnection algorithm, it is necessary to reset the imr+ device. the standard partitioning algorithm is selected upon reset. alternate tp ports partitioning algorithm si data: 00010000 so data: none the tp ports partitioning/reconnection scheme can be programmed for the alternate (transmit only) reconnection algorithm by invoking this command. all tp ports are affected as a group by this command. to return the tp ports back to the standard (transmit or receive) reconnection algorithm, it is necessary to reset the imr+ device. the standard partitioning algorithm is selected upon reset. aui port disable si data: 00101111 so data: none the aui port will be disabled upon receiving this command. subsequently, the imr+ chip will ignore all inputs (carrier sense and sqe) appearing at the aui port and will not transmit any data or jam sequence on the aui port. issuing this command will also cause the aui port to have its internal partitioning state machine forced to its idle state. therefore, a partitioned port may be reconnected by first disabling and then re-enabling the port. aui port enable si data: 00111111 so data: none this command enables a previously disabled aui port. note that a partitioned aui port may be reconnected by first disabling (aui port disable command) and then re-enabling the port with this command. all ports are enabled upon reset. tp port disable si data: 00100### so data: none (### is tp port number) the tp port designated in the command byte will be disabled upon receiving this command. subsequently, the imr+ device will ignore all inputs appearing at the disabled ports receive pins and will not transmit any data or jam sequence on that ports transmit pins. issuing this command will also cause a tp port to have its partition- ing state machine returned to its idle state (port reconnected). therefore, a partitioned port may be reconnected by first disabling and then re-enabling the port. the disabled port will continue to report correct link test status.
amd 3-13 imr/imr+ overview tp port enable si data: 00110### so data: none (### is tp port number) this command enables a previously disabled tp port. re-enabling a disabled port causes the port to be placed into link test fail state. this ensures that packet frag- ments received on the port are not repeated to the rest of the network. note that to force a tp port into the link fail state and/or to reconnect a partitioned tp port, the port should first be disabled (tp port disable command) and then re-enabled with this command. all ports are enabled upon reset. disable link test function of a tp port si data: 01000### so data: none (### is tp port number) this command disables the link test function at the tp port designated in the com- mand byte, i.e., the tp port will no longer be disconnected due to link fail. a tp port which has its link test function disabled will continue to transmit link test pulses. if a twisted pair port has link test disabled, then reading the link test status indicates it being in link test pass. enable link test function of a tp port si data: 01010### so data: none (### is tp port number) this command re-enables the link test function in the tp port designated in the command byte. this command executes only if the designated tp port has had the link test function disabled by the disable link test function command. otherwise, the command is ignored. link test is enabled upon reset. disable automatic receiver polarity reversal si data: 01100### so data: none (### is tp port number) this command disables the automatic receiver polarity reversal function for the tp port designated in the command byte. if this function is disabled on a tp port with reverse polarity (due to a wiring error), then the tp port will fail link test due to the reversed polarity of the link pulses. if the link test function is also disabled on the tp port, then the received reversed polarity packets would be repeated to all other network ports in the imr+ chip as inverted data. automatic polarity reversal is disabled upon reset. enable automatic receiver polarity reversal si data: 01110### so data: none (### is tp port number) this command enables the automatic receiver polarity reversal function for the tp port designated in the command byte. if enabled in a tp port, the imr+ chip will automatically invert the polarity of that tp ports receiver circuitry if the tp port is detected as having reversed polarity (due to a wiring error). after reversing the receiver polarity, the tp port could then receive subsequent (reverse polarity) packets correctly.
amd imr/imr+ overview 3-14 get (read) opcodes aui port status si data: 10001111 so data: pbsl0000 the combined aui status allows a single instruction to be used for monitoring aui port. the four status bits reported are: p partitioning status. this bit is 0 if the aui port is partitioned and 1 if connected. b bit rate error. this bit is set to 1 if there has been an instance of fifo overflow or underflow, caused by data received at the aui port. this bit is cleared when the status is read. s sqe test status. this bit is set to 1 if sqe test is detected by the imr+ chip. this bit is cleared when the status is read. a mau attached to a repeater must have sqe test disabled. this bit is set even if the aui port is disabled or partitioned. l loop back error. the mau attached to the aui is required to loopback data transmitted to do onto the di circuit. if loopback carrier is not detected by the imr+ device, then this bit is set to 1 to report this condition. this bit is cleared when the status is read. for a repeater this is the only indication of a broken or missing mau. alternate aui port status si data: 10001111 so data: pbsl0000 there are three further variations of the above command, allowing selective clearing of a combination of b, s, and l bits. they are primarily included for use by the himib chip. these are: alternative 1. si data: 10001011 so data: pbsl0000 b is not cleared. s and l are cleared. alternative 2. si data: 10001101 so data: pbsl0000 s and l are not cleared. b is cleared. alternative 3. si data: 10001001 so data: pbsl0000 none of s, b and l are cleared. tp port partitioning status si data: 10000000 so data: p7.................p0 pn = 0 tp port n partitioned pn = 1 tp port n connected the partitioning status of all eight tp ports are accessed by this command. if a port is disabled, reading it partitioning status will indicate that it is connected. bit rate error status of tp ports si data: 10100000 so data: e7...............e0 this allows a single command to be used to report the bit rate error status condition (fifo overflow or underflow) of all twisted pair ports. the 8 bits of the output pattern correspond to each of the 8 tp ports, with least significant bit corresponding to port 0.
amd 3-15 imr/imr+ overview the status bit for a port is set to 1 if there has been an instance when data received from that port has caused a fifo error. all status bits stay set until the status is read. link test status of tp ports si data: 11010000 so data: l7...............l0 ln = 0 tp port n in link test fail ln = 1 tp port n in link test pass the link test status of all eight tp ports are accessed by this command. a disabled port continues to report correct link test status. re-enabling a disabled port causes the port to be placed into link test fail state. this ensures that packet fragments received on the port are not repeated to the rest of the network. receive polarity status of tp ports si data: 11100000 so data: p7...............p0 pn = 0 tp port n polarity correct pn = 1 tp port n polarity reversed the status of all eight tp port polarities are accessed with this command. the imr+ chip has the ability to detect and correct reversed polarity on the tp ports rxd+/- pins. if the polarity is detected as reversed for a tp port, then the imr+ chip will set the appropriate bit in this commands result byte only if the polarity reversal function is enabled for that port. mjlp status si data: 11110000 so data: m00000000 each imr+ chip contains an independent mau jabber lock up protection timer. the timer is designed to inhibit the imr+ device transmit function, if it has been transmitting continuously for more than 65536 bit times. the mjlp status bit (m) is set to 1 if this happens. this bit remains set and is only cleared when the mjlp status is read by using this command. version si data: 11111111 so data: xxxx0001 this command (1111 1111) can be used to determine the device version. the imr+ chip responds by the bit pattern: xxxx 0001 the imr chip (am79c980) responds by the bit pattern: xxxx 0000 3.9 imr+ device repeater state machine description the state diagram in figure 3-8 describes the relationship between the imr+ repeater state machine and the imr+ expansion port. the diagram is similar to the ieee 802.3 repeater unit state diagram (see iso/iec 8802-3: 1990 (e) ansi/ieee std 802.3-1990 edition, figure 9-2). each imr+ device contains an independent implementation of the state machine. when multiple imr+ devices are interconnected to form a single, high port count repeater, it is the expansion port that keeps these state machines synchro- nized with each other.
amd imr/imr+ overview 3-16 figure 3-8 imr+ device state machine out(all_this_imr) = idle req = 1, dat = z, jam = z see notes 4, 5 collin(only1) = sqe * tt(all) 3 96: [m <== port(collin = sqe)] req = 0, dat = data, jam = 0 out(allxn_this_imr) = twoones out(allxn_this_imr) = preamble pattern datain(any_this_imr) = ii *collin(all) = sqe :[n<== port(datain = ii)] power on uct start begin req = x, dat = x, jam = x idle req = 1, dat = z, jam = z send preamble pattern req = 0, dat = 1010..., jam = 0 see note 1 send two ones req = 0, dat = 1..., jam = 0 send data out(allxn_this_imr) = data wait out(all_this_imr) = idle starttw1 req = 1, dat = z, jam = z see note 6 transmit collision out(all_this_imr) = jam if collin(any_this_imr) = sqe req = 0 else req = 1 if collin(all_xthis_imr) = sqe * collin(anyxn_this_imr) = sqe dat = 0, jam = 1 else dat = z, jam = z see notes 1, 3, 6 receive collision out(allxn_this_imr) = jam if collin(any_this_imr) = sqe req = 0 else req = 1 if collin(all_xthis_imr) = sqe * collin(n_this_imr) = sqe dat = 1, jam = 1 else dat = z, jam = z see notes 1, 2, 3, 6 one port left out(allxm_this_imr) = jam if collin(any_this_imr) = sqe req = 0 else req = 1 if collin(all_xthis_imr) = sqe * collin(m_this_imr) = sqe dat = 1, jam = 1 else dat = z, jam = z see notes 1, 6 expansion port receive out(all_this_imr) = dat (from sourcing imr) collin(anyxn) = sqe tt(allxn) > 62 * datardy * collin(all) = sqe * datain(n) = ii twoonessent * collin(all) = sqe * datain(n) = ii collin(anyxn) = sqe collin(anyxn) = sqe collin(anyxn) = sqe datain(any_xthis_imr) = ii * collin(all) = sqe :[n <== port(datain = ii )] collin(anyxn) = sqe collin(only1) = sqe:[n <== port(collin = sqe)] collin(n) = sqe collin(n) = sqe + (datain(n) = ii * collin(all) = sqe ) collin(n) = sqe + (datain(n) = ii * collin(all) = sqe ) collin(n) = sqe + (datain(n) = ii * collin(all) = sqe * alldatasent * tt(anyxn) < 96) + fifo over/underflow datain(n) = ii * collin(all) = sqe * alldatasent datain(n) = ii * collin(all) = sqe * tt(allxn) 3 96 * alldatasent collin(anyxn) = sqe datain(n) = ii * collin(all) = sqe * tt(allxn) 3 96 * tw2done collin(all) = sqe * tt(all) 3 96 * tw2done datain(m) = ii * collin(all) = sqe * tw2done collin(anyxm) = sqe collin(any) = sqe + tw1done 17314a-13
amd 3-17 imr/imr+ overview referring to figure 3-8, the upper box in each block contains the name of the state. the center box refers to the output at the aui and tp ports. the lower box describes the state of the req , dat, and jam output pins for the imr+ device with this state machine embedded. there are several items to keep in mind when interpreting the state diagram: when dat = z, and jam = z, dat and jam are either in high-impedance ( ack = 1) or input ( ack = 0). the meaning of all, any, anyxn, anyxm, etc. refers to the repeater as a unit (a single repeater can be formed by connecting multiple imr+ devices together). the meaning is modified if _this_imr or _xthis_imr are appended. _this_imr refers to the imr+ device serviced by the local state machine. i.e., any_this_imr refers to any aui or tp port on this particular imr+ device. _xthis_imr refers to any imr+ device except the one serviced by the state machine. i.e., all_xthis_imr refers to all aui and tp ports except the ones on this particular imr+ device. col = 0 implies collin(anyxn) = sqe or collin(anyxm) = sqe. ack = 0 && dat = 0 && jam = 1 implies collin(anyxn) = sqe or collin(anyxm) = sqe. ack = 0 && dat = 1 && jam = 1 implies collin(n) = sqe or collin(only1) = sqe. ack = 0 && jam = 0 implies datain(any) = ii or datain(n) = ii . the state diagram would not completely describe the expansion port without the following notes. notes: 1. req is set to 0 one cycle prior to dat, jam being driven. in other words, if req transitions from 1 to 0, dat and jam will not be driven until one cycle after the transition. similarly, if a transition from multiple req lines being driven ( col = 0, ack = 1) to only one req line being driven ( col = 1, ack = 0) dat and jam will not be driven until one cycle after the transition. 2. when entering the receive collision state from any state other than the receive col- lision or the expansion port receive state, the sourcing imr+ device will guarantee req = 0, dat = 1, jam = 1 for one cycle even if collin(all) = sqe or datain(n) = ii. 3. if collin(all) = sqe before tt( ) >= 96, then req = 1, dat = z, jam = z even though out( ) = jam. note 2 supersedes this. 4. the condition to transition from expansion port receive to receive collision state is different than from send preamble pattern, send two ones, and send data to receive collision. collin(n) = sqe is the only way from expansion port receive to receive collision state. this is done by sensing dat = 1, jam = 1, hence this is the rea- son the condition stated in note 2 is necessary. 5. the condition to transition from expansion port receive to wait state is different than from send data to wait. tt(allxn) >= 96 is not needed to transition from expansion port receive to wait state. 6. the wait state, tw1done, and tw2done are implemented in the 10base-t transceivers and not in the repeater state machine. 3.10 response to preamble only a 96-bit preamble only packet will be signaled as a receive collision on the expansion port at the tail end of imr/imr+ device transmission because the packet has no start of frame delimiter (sfd). 3.11 response to ipg shrinkage a packet reception which commences in less than the normal 9.6 m s inter-packet gap (ipg) period (due to ipg shrinkage, or the effect of a carrier drop out at an intermediate point in the transmission path), will still be treated as a new received packet by the imr/imr+ device. however, the pll in the imr/imr+ chip requires 43-bit times of idle
amd imr/imr+ overview 3-18 (maximum) after the end of reception to re-acquire the home frequency and to guaran- tee accurate decoding of received data on a subsequent packet. thus the second packet in this sequence may be garbled by the imr/imr+ device if this ipg spacing is not maintained. normal network components and operation will not cause ipg shrink- age to below 48-bits, and will therefore not be any problem for either the imr or imr+ devices. 3.12 designing repeaters using multiple imr+ devices multiple imr+ devices may be connected together to form large repeaters either with or without the himib device. see section 5 for a discussion of multiple imr+ repeater design using the imr+ and himib devices. figure 3-9 below shows a multiple imr+ chip based design. figure 3-9 multiple imr+ based repeater arbiter am79c981 imr+ chip 1 ack col rst x1 ack col rst x1 dat jam req dat jam ack col rst x1 dat jam d ff ck q d xtal osc. async reset 1/2 74 col ack ack req req req am79c981 imr+ chip 2 am79c981 imr+ chip 3 bus transceivers needed if dat and jam buses exceed 100 pf loading. ab dir note 1 note 1: direction dir b ? a low a ? b high req2 req3 req1 17314a-14
amd 3-19 imr/imr+ overview 3.13 expansion port the imr+ chip expansion port is comprised of five pins; two are bi-directional signals (dat and jam), two are input signals ( ack and col ), and one is an output signal ( req ). these signals are used when a multiple-imr+ device repeater application is employed. in this configuration, all imr+ chips must be clocked synchronously with a common clock connected to the x1 inputs of all imr+ devices. reset needs to be synchronized to the x1 clock. the imr+ device expansion scheme allows the use of multiple imr+ chips in a single board repeater or a modular multiport repeater with a backplane architecture. the dat pin is a bidirectional i/o pin which can be used to transfer data between the imr+ devices in a multiple-imr+ chip design. the data sent over the dat line is in nrz format and is synchronized to the common clock. the jam pin is another bidirectional i/o pin that is used by the active imr+ chip to communicate its internal status to the remaining (inactive) imr+ devices. when jam is asserted high, it indicates that the active imr+ device has detected a collision condition and is generating jam sequence. during this time when jam is asserted high, the dat line is used to indicate whether the active imr+ chip is detecting collision on one port only or on more than one port. when dat is driven high by the imr+ chip (while jam is asserted by the imr+ chip), then the active imr+ device is detecting a collision condition on one port only. this one-port-left signaling is necessary for a multiple-imr+ device repeater to function correctly as a single multiport repeater unit. the imr+ chip also signals the one port left collision condition in the event of a runt packet or collision fragment; this signal will continue for one expansion port bus cycle (100 ns) before deasserting req . the arbitration for access to the bussed bi-directional signals (dat and jam) is provided by one output ( req ) and two inputs ( ack and col ). the imr+ chip asserts the req pin to indicate that it is active and wishes to drive the dat and jam pins. an external arbiter senses the req lines from all the imr+ devices and asserts the ack line when one and only one imr+ chip is asserting its req line. if more than one imr+ chip is asserting its req line, the arbiter must assert the col signal, indicating that more than one imr+ device is active. more than one active imr+ device at a time constitutes a collision condition, and all imr+ devices are notified of this occurence via the col line of the expansion port. note that a transition from multiple imr+ devices arbitrating for the dat and jam pins (with col asserted, ack deasserted) to a condition when only one imr+ chip is arbitrating for the dat and jam pins (with ack asserted, col deasserted) involves one expansion port bus cycle (100 ns). during this transitional bus cycle, col is deasserted, ack is asserted, and the dat and jam pins are not driven. however, each imr+ device will remain in the collision state (transmitting jam sequence) during this transi- tional bus cycle. in subsequent expansion port bus cycles ( req and ack still asserted), the imr+ devices will return to the master and slaves condition where only one imr+ device is active (with collision) and is driving the dat and jam pins. an understanding of this sequence is crucial if non-imr+ devices (such as an ethernet controller) are connected to the expansion bus. specifically, the last device to back off of the expan- sion port after a multi-imr+ chip collision must assert the jam line until it too drops its request for the expansion port.
amd imr/imr+ overview 3-20 3.14 external arbiter a simple arbitration scheme is required when multiple imr+ devices are connected together to increase the total number of repeater ports. the arbiter should have one input ( req1 ... reqn ) for each of the n imr+ devices to be used, and two global outputs ( col and ack ). this function is easily implemented in a pal device, with the following logic equations: ack = req1 & req2 & req3 & .... reqn + req1 & req2 & req3 & .... reqn + req1 & req2 & req3 & .... reqn col = ack & (req1 + req2 + req3 + ... reqn) above equations are in positive logic, i.e., a variable is true when asserted. a single palce16v8 will perform the arbitration function for a repeater based on several imr+ devices. 3.15 reset circuitry if the imr+ device is used without the himib device, is not connected to any other devices via its expansion bus, and the data presented on the so and crs pins is not used, then the rst signal can be asynchronous to the 20 mhz clock. in many cases however the rst signal must be synchronized to this clock. figure 3.4 shows one example where synchronization is necessary, and one possible circuit for accomplishing this function. the asynch reset signal is active low, and may be supplied by a pushbutton, software, or a conventional resistor-capacitor-diode power up reset circuit. the rst signal generated by this circuit should be applied to every imr+ device and associated logic in the system. there is an alternative scheme for synchronizing rst with tck which is useful in systems where different imr+ devices may be powered up or otherwise reset at diiferent times (see figure 3-10). this scheme is used in the design of the imr velcro hub board. the reset curcuitry consists of a push button switch, an rc network, a schmitt-trigger inverter, and a d flip-flop (figure 3-10). the large rc time constant value used [t = (10 k w) (47 m f) = 470 ms) ensures that the reset pulse with is greater than the required minimum value of t rst = 150 ms. however, this also means that the rise and fall times of the signal will be longer than desired. for this reason, the schmitt-trigger inverter is used to buffer, and square up the asynchronous reset signal from the rc network to the input of the synchronizing d flip-flop. this synchronizing d flip-flop is clocked by reset_clk, and the q output is used so that rst is a synchronous, active low, signal. rst is a synchronous signal for two reasons. the first is to prevent any possible problems that might arise from an asnchronous reset signal (i.e., imr/imr+ device and peripheral chips recognizing reset at different times). the second, and more important reason, is that a reset signal synchronized to tck (reset_clk) forces all the imr/ imr+ devices connected to the expansion bus to be synchronized to each other after a reset cycle. the implementation of figure 3-4 recommends that, for generating a tck signal of the same phase as the imr devices internal 10 mhz tck clock signal, the frequency divider d flip-flops clr input should be connected to a reset signal which is synchro- nized to the x1 clock. this design uses, the tck signal for synchronization.
amd 3-21 imr/imr+ overview the reason for this is that, in figure 3-4 the intent is to generate a tck signal which, after a synchronized reset cycle, matches the imr devices internal 10 mhz signal. in contrast, in figure 3-10, the designs tck signal is not affected by reset and is free running. synchronizing reset to tck forces the imr chips internal 10 mhz signal to match the boards tck signal signal after a reset cycle. because of the propagation delay of the d flip-flop (t pd ), the end of the reset cycle is not recognized by the imr+ chip until one x1 clock cycle after the rising edge of tck (reset_clk). the recogni- tion of the end of reset corresponds with the rising edge of tck, and reesults in the same phase relationship between the imr+ devices internal tck and the boards tck, as is the case when the circuit of figure 3-4 is used. the large rc time constant (see above) of the rc network used for the asynchronous reset signal ensures that the imr+ chip will be reset upon powert up. therefore, the imr+ device will be synchronized to the boards tck signal at all times. note that the rst signal is a local signal and is not included on the expansion bus. when two or three units of the imr velcro hub board are connected together over the expansion bus, each board has its own reset signal synchronized by the inverse of the bus 10 mhz tck clock signal. in this way, the expansion bus scheme of the imr velcro hub board demonstrates one way the hot swapping of line cards in an expandable repeater can be accomplished. figure 3-10 reset circuitry d q q clk pre clr d q q clk pre clr in5400 10k w 100 w v cc v cc v cc v cc v cc async_reset async_reset 74hct14 74hct14 reset_clk 20 mhz oscillator module 1/2 74ls74a 1/2 74ls74a tck rst x1 17314a-15 tck 47 m f
amd imr/imr+ overview 3-22 3.16 differences between the imr and imr+ devices the following sections list the functions that have been added to the imr+ device or have been modified from the original imr device. these enhancements address a number of issues, including interfacing to the himib chip, improved timing specifica- tions, and enhanced standards support. for a description of the management port commands available on the imr and imr+ devices, see in this section under imr/imr+ management port. 3.16.1 imr+ chip programmable options this command is not available in the imr device. three additional programming bits are provided in the imr+ device, as follows: s aui port sqe test mask. mask sqe activity on the aui port from being repeated to the 10base-t ports and the expansion port. a alternative port activity monitor (pam) function. provides raw carrier sense activity on the pam, regardless of the enable/disable state or the auto-partition state of the aui and/or 10base-t ports. c ci reporting. provides reporting of ci circuit activity within the pam bit stream. see the imr+ device data sheet (pid# 17306) for additional details. see in this section the management commands, set (write) opcodes under imr/ imr+ management port for additional details. 3.16.2 get aui port status the original get aui port status command available on the imr device, is enhanced in the imr+ chip to provide three additional status bits. hence a single request can be used to monitor all key performance aspects of the aui port. this command uses the same op-code (10001111) as the original get aui port status command of the imr device. the following status is returned from the imr+ device (see table 3-1 for more detail): p partitioning status. reports the auto-partition condition of the aui port. identical in both the imr and imr+ devices. b bit rate error. reports a fifo underrun/overrun due to a frame received on the aui port. this bit is not available in the imr device, and is added to the imr+ device. s sqe test status. reports that the transceiver connected to the aui port has sqe test en- abled. this bit is not available in the imr device, and is added to the imr+ device. l loop back error. reports that the aui port is not exhibiting a do circuit to di circuit loopback path. this bit is not available in the imr device, and is added to the imr+ device. see the imr+ device data sheet (pid# 17306) for additional details. in addition, three further versions (four versions in total) of this command are provided, which allow various combinations of bits to be cleared in the process of reading the status. 3.16.3 get bit rate error (tp ports) this command is not available in the imr device, and is added to the imr+ device. reports a fifo underrun/overrun due to a frame received on any of the 10base-t ports. 3.16.4 get mjlp status this command is not available in the imr device, and is added to the imr+ device. reports that the mau jabber lockup protection (mjlp) timer has activated.
amd 3-23 imr/imr+ overview 3.16.5 get version the get version command is used to determine the device version number. the imr device response to this command is: xxxx 0000 the imr+ device response to this command is: xxxx 0001 3.16.6 minimum mode this function is not available in the imr device, and is added to the imr+ device. see the imr+ based velcro tm hub design and minimum mode sections for additional details. 3.16.7 fifo underflow/overflow in the imr device, a fifo over-run or under-run condition forces the device to enter the transmit collision state, causing transmission of the jam pattern to all ports, including the receiving port. in the case of the imr+ device, the fifo underflow/overflow error is handled using the receive collision state. in this case, the responsible port will not observe a jam pattern returned from the imr+ based repeater (a bit rate error will be reported for the port). since this error is caused by a serious receive error condition (i.e., the station is transmitting at a frequency substantially outside the allowable specification, or the transmission is excessively long), it is treated as a receive collision. 3.16.8 twisted pair link integrity status 3.16.8.1 port disable and link test on the imr device, when a twisted pair port is disabled, its corresponding status is reported as link pass, regardless of the condition of the link test state machine. on the imr+ device, a disabled port continues to report accurate link test status. disabling an enabled twisted pair port on the imr device, causes the port to be forced into the link fail state. re-enabling a disabled port on the imr+ device, causes the port to be forced into the link fail state. this ensures that packet fragments received on the port are not repeated to the rest of the network. 3.16.8.2 interaction between link fail and port autopartition. in the imr device, a twisted pair port which is partitioned and subsequently enters the link fail state, will be reconnected. in the imr+ device, the twisted pair port receive link test state machine is decoupled from the autopartition state machine. entering the link fail state will not cause a partitioned port to be reconnected. 3.16.9 preamble/start of frame delimiter (sfd) detection once receive preamble is detected, the repeater state machine of the imr device will commence the re-transmission of preamble on all permitted output ports, and begin searching for a two ones condition in the preamble. once the 1, 1 synch character has been detected, the packet data which follows is loaded into the internal fifo, to be re-transmitted after the preamble has been completed at the output ports. if the imr device does not detect an sfd, then it will remain in the preamble generation state until the receive carrier has dropped or a collision is detected. in the case of the imr+ device, after receive preamble is detected, the repeater state machine will commence the re-transmission of preamble on all permitted output ports, but will ignore an sfd (start of frame delimiter) which arrives with less than 15 bits of preamble. the imr+ device will not monitor the input bit stream to search for the sfd until it has received 16 bits (1.6 m s) of preamble. the imr+ device will decode the sfd
amd imr/imr+ overview 3-24 fully, and only respond to the valid sfd pattern (10101011). once the valid sfd byte has been detected, the packet data which follows is loaded into the internal fifo, to be re-transmitted after the preamble has been completed at the output ports. if the imr+ device does not detect an sfd, then it will remain in the preamble generation state until the receive carrier has dropped or a collision is detected. 3.16.10 hardware reset the imr chip has a minimum reset pulse requirement of 150 m s. this requirement allows for the receive clock recovery circuitry to stabilize. the imr+ device has the same requirement for a minimum reset pulse width at power on, however if the reset is applied while power stays active the pulse width requirement to reset the imr+ chip decreases to 4 m s. note that both the imr and imr+ devices remain in the reset state for 10 clock cycles (0.5 m s) following the end of the reset pulse. during reset, receive activity on all twisted pair ports is ignored by the repeater if activity was started while the imr/imr+ device is in its internal reset state. this ensures that packet fragments are not propagated onto the network due to a manage- ment software reset (which will occur as a result of a management station action). the reset circuitry in the imr+ device ensures that the chip is internally reset only once, and for sufficient duration. this avoids multiple resets within the device, in the case where a slow rising edge reset signal, crosses the input buffer threshold several times due to ripple on the input waveform. 3.17 imr/imr+ propagation delays since the imr+ device is a general purpose repeater chip, it does not directly interface with a backplane bus from a specific vendor. since there are numerous existing concentrator backplanes that are currently available in the market place, making a part which interfaces to a variety of these is a non trivial problem. if the imr+ device is to be utilized in a new design, where no previous backwards compatibility is required, then the dedicated expansion port can be used as the basis of the backplane, to interconnect individual imr+ chip or groups of imr+ devices, such that a modular concentrator architecture can be accomplished. this concept is dis- cussed in the existing data sheet. in order to provide the maximum flexibility to the installed base, where backwards compatibility with an existing architecture is required, it is necessary to describe the external behavior of the imr+ device, in the form of throughput delays, so that designers can understand the issues and ensure that the critical repeater delays specified in section 9 of 802.3 can be met. below are listed the imr+ propagation delays for key parameters. the values are based on a combination of related empirical data, simulation, and bench/tester measurements. in general, maximum values have assumed theoretical worst case conditions. propaga- tion delays cited below, which do not directly match or correspond to data sheet parameters or ieee 802.3 requirements, are not guaranteed by production testing. in addition, data out delays pertaining to digital pins are considered to be zero in order to avoid double counting of such delays. for paths including a digital output buffer and an input buffer, the data out delays have been accounted for in the input buffer parame- ter in the form of a range of input setup times. 3.17.1 start of packet propagation delays note that for start of packet propagation delays, the input signal is assumed to be a valid manchester encoded signal, with first bit of valid amplitude and pulse width. the input (stimulus) waveform will have a direct effect on the propagation delay. for instance, using a 5 mhz non-manchester input into the tp ports, and measuring the propagation
amd 3-25 imr/imr+ overview delay to the tp output, may yield a delay value 50 ns larger than expected, due to the first bit not being valid manchester. parameter min (ns) max (ns) data on aui to req asserted 100 280 data on aui to data out on any tp port 190 370 data on aui to data out on dat 200 380 data on any tp port to req asserted 250 430 data on any tp port to data out on aui 340 520 data on any tp port to data out on any tp port 340 520 data on any tp port to data out on dat 350 530 data on dat/ ack to data out on aui port 90 190 data on dat/ ack to data out on any tp port 90 190 ack asserted to data out on dat 0 100 3.17.2 start of collision propagation delays parameter min (ns) max (ns) aui ci active to jam sequence on aui 290 470 aui ci active to jam sequence on any tp port 290 470 aui ci active to jam sequence on jam 300 480 aui ci active to req asserted 200 380 tp rx active to jam sequence on aui 340 520 tp rx active to jam sequence on any tp port 340 520 tp rx active to jam sequence on jam 350 530 jam/ ack asserted to jam sequence on aui 90 190 jam/ ack asserted to jam sequence on any tp port 90 190 col asserted to jam sequence on aui 90 190 col asserted to jam sequence on any tp port 90 190 note: propagation delays cited in these tables are not guaranteed by production testing.
amd imr/imr+ overview 3-26 3.17.3 end of collision propagation delays parameter min (ns) max (ns) aui ci carrier sense deasserted to end of jam 140 320 sequence on aui port aui ci/di carrier sense deasserted to end of jam 190 370 sequence on any tp port aui ci/di carrier sense deasserted to end of jam 200 380 sequence on jam aui ci/di carrier sense deasserted to req 200 380 deasserted tp carrier sense deasserted to end of jam 140 320 sequence on aui port tp carrier sense deasserted to end of jam 190 370 sequence on any other tp port tp carrier sense deasserted to end of jam 200 380 sequence on jam tp carrier sense deasserted to req deasserted 200 380 jam/ ack deasserted to end of jam 40 140 sequence on aui port jam/ ack deasserted to end of jam sequence 90 190 on any tp port col deasserted to end of jam sequence 40 140 on aui port col deasserted to end of jam sequence on 90 190 any tp port internal aui/tp carrier sense deassertion 136 200 3.17.4 tp start-up and steady state delays tp start-up delay, from the first edge of a received waveform to the first edge of a transmitted waveform, varies from 400 ns to 550 ns. the path includes propagation delays, smart squelch, synchronization to the transmit clock (x1) and repeater state machine processing time with the variation introduced by propagation delays and synchronization time. tp steady state delay is a function of internal propagation/timing delays as well as the extent to which data is buffered in the internal fifo. the depth of fifo usage required depends on the amount of preamble (including sfd) received as well as the magnitude of frequency mismatch between the extracted receive clock and the transmit clock. the fifo will be nearly empty during transfers involving a received preamble of >64 bits coupled with a fast transmit clock (x1), whereas the fifo will be nearly full during transfers involving a very short received preamble of <36 bits coupled with a slow transmit clock (x1). in total, the steady state delay can vary from 6 to 37 bit times. 3.17.5 tp receive to dat active delay this parameter is identical to the tp start-up delay (see above). 3.17.6 slow ack or col signals a late ack assertion from an external expansion port bus arbiter does not prevent the expansion bus source imr/imr+ device from engaging in its preamble sequence. it will drive preamble on its tp and aui ports while its expansion port remains in the high- impedance state. expansion port destination imr/imr+ devices will be unable to repeat the preamble bits which normally would have been passed from the expansion bus source during the time in which ack is tardy. for a req asserted to ack asserted
amd 3-27 imr/imr+ overview delay which is tardy by up to 100 ns (fails the t caset parameter up to 100 ns), destination imr/imr+ devices will issue a preamble sequence which is shortened by one bit versus the source imr/imr+ device, and that preamble sequence will begin with a manches- ter zero. a late ack deassertion from an external expansion port bus arbiter will induce destina- tion imr/imr+ devices to repeat expansion port data even though the expansion port bus is not being driven with data by the source imr/imr+ device. again an ack destination deassertion delay of 100 ns will result in the transmission of one errant bit by all destination imr/imr+ devices, resulting in an undefined dribbling bit being added to the re-transmitted data. for an ack deassertion which is more than 100 ns tardy (fails the ack t caset by more than 100 ns), the original source imr/imr+ device will perceive itself as an expansion port destination device ( ack asserted, req deasserted) and will issue a minimum 96-bit jam sequence due to receiving a runt packet. supplying ack immediately, followed by a tardy col indication can result in expansion port bus contention if two imr/imr+ devices simultaneously request the bus.
amd imr/imr+ overview 3-28
4-1 himib overview himib overview 4 section the hardware implemented management information base (himib) device provides complete hardware support for the high performance network monitoring requirements of the ieee 802.3 repeater management standard. the himib chip was designed to be used with the integrated multiport repeater (imr+), providing a flexible and complete solution for managed repeater design. it can also be interfaced with any ethernet controller supporting a general purpose serial interface (gpsi). the ieee 802.3 repeater management standard defines three management packages, for basic control, performance monitoring, and address tracking. both performance monitoring and address tracking require real time statistics collection for each repeater port on a per-frame basis. the himib chip, in conjunction with the imr+ device, provides a complete solution for all required and optional statistics. all network activity related statistics will be updated autonomously by the himib device with no host processor involvement. the himib device connects directly to the imr+ expansion bus, management port and port activity monitor (pam), enabling the himib chip to directly track and count critical network events for local and remote management queries. coupled with a processor and simple ieee 802.3 mac, the system can be expanded to support complete remote in-band network management capabilities. additionally the himib chip supports the novell, inc. hub management interface (hmi) extensions to the ieee 802.3 repeater management requirements. the himib chip provides a simple 8-bit asynchronous bus interface, allowing interfacing of a low cost 8-bit microprocessor, to provide an extremely low cost solution for man- aged repeater designs. 4.1 architectural overview the himib device autonomously carries out all statistics accumulation for managed repeater applications. these statistics are accumulated in an array of registers as shown in figure 4-1. the register array is addressed as 32 banks with 32 registers in each bank. the himib device currently only uses 12 banks, with a varying number of registers in each bank. each register is addressed using a port number (bank number) and register number (attribute number) pointer combination. the lower 5 bits of both of these registers effectively address a single attribute register in the himib chips register array.
amd himib overview 4?2 figure 4?1 himib device register array 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 imr+ management port get: write issues get command to imr+ and read returns result 0 rr 1 psr 2 pcr 16 tp0 17 tp1 18 tp2 19 tp3 20 tp4 21 tp5 22 tp6 23 tp7 31 aui holding register data port r4 11 5 r3 r2 r1 r0 1 attribute select register p4 0 0 p3 p2 p1 p0 0 bank select register 5 8 control port himib status register 0 1 imr+ management port set: write issues set command to imr+
amd 4-3 himib overview 4.2 himib/imr+ chip-set management capabilities table 4-1a and 4-1b is a listing of the himib device registers. in table 4-1a, the columns are the register banks, while the rows are individual registers in the banks. table 4-1a himib registers register bank 0 register bank 1 register bank 2 register banks 16-23 register bank 31 reg # repeater registers port status registers port control registers 10base-t ports aui port 0 tp partition tp partition change readable frames readable frames status change interrupt enable 1 aui partition aui partition change readable octets readable octets status change interrupt enable 2 tp link status tp link status change frame check frame check change interrupt enable sequence errors sequence errors 3 aui loop back error aui loop back error alignment errors alignment errors interrupt enable 4 frames too long frames too long 5 aui sqe test error aui sqe test error short events short events interrupt enable 6 tp source address tp source address runts runts change change interrupt enable 7 aui source address aui source address collisions collisions change change interrupt enable 8 tp source address late events late events match status 9 aui source address very long events very long events match status 10 source address match data rate data rate (6 bytes) mismatches mismatches 11 auto partitions auto partitions 12 total octets source address source address changes changes 13 transmit collisions 14 last source last source address (6 bytes) address (6 bytes) 16 configuration register 28 version/device id 30 imr+ management port set register 31 imr+ management port get register
amd himib overview 4-4 table 4-1b himib registers register bytes access status register note: read the c port for status 1 r no need to specify the port or register number port/register bank p[4:0] register r[4:0] bytes access repeater registers 0 source address match 10 6 r/w total octets 12 4 r transmit collisions 13 4 r configuration register 16 1 r/w version/device id 28 1 r imr+ management port set register 30 1 w imr+ management port get register 31 1 r/w port status registers 1 tp partition status change 0 1 r aui partition status change 1 1 r tp link status change 2 1 r aui loop back error 3 1 r reserved 4 aui sqe test error 5 1 r tp source address change 6 1 r aui source address change 7 1 r tp source address match status 8 1 r aui source address match status 9 1 r port control registers 2 tp partition change interrupt enable 0 1 r/w aui partition change interrupt enable 1 1 r/w tp link status change interrupt enable 2 1 r/w aui loop back error interrupt enable 3 1 r/w reserved 4 aui sqe test error interrupt enable 5 1 r/w tp source address change interrupt enable 6 1 r/w aui source address change interrupt enable 7 1 r/w attribute registers 16C23, 31 readable frames 0 4 r readable octets 1 4 r frame check sequence errors 2 4 r alignment errors 3 4 r frames too long 4 4 r short events 5 4 r runts 6 4 r collisions 7 4 r late events 8 4 r very long events 9 4 r data rate mismatches 10 4 r auto partitions 11 4 r source address changes 12 4 r reserved 13 last source address 14 6 r/w note that all register locations listed as reserved and those which might be accessed by values or combinations of p and r which are not listed in the table above should not be accessed by the software. read/write access to reserved registers may cause incorrect operation.
amd 4-5 himib overview the following tables list the implementation requirements for management objects in a repeater based on the imr+/himib devices. they are organized into three tables. the first describes the management attributes that are supported in software. the second describes the management attributes supported directly by the himib device. the third lists the management attributes supported by the imr+ device. table 4-2 is a list of the management objects that would typically be implemented in a managed repeaters resident software. these objects are generally static, or change very infrequently, and hence present minimal overhead to the managed repeater software. table 4-2 software management objects management object name management class object type repeaterid repeater read only attribute repeatergroupcapacity repeater read only attribute groupmap repeater read only attribute repeaterhealthstate repeater read only attribute repeaterhealthtext repeater read only attribute repeaterhealthdata repeater read only attribute resetrepeater repeater action executenondisruptiveselftest repeater action repeaterhealth repeater notification repeaterreset repeater notification groupmapchange repeater notification resourcetypeidname resourcetypeid read only attribute resourceinfo resourcetypeid read only attribute groupid group read only attribute groupportcapacity group read only attribute portmap group read only attribute portmapchange group notification portid port read only attribute portadminstate port read only attribute portadmincontrol port action
amd himib overview 4-6 table 4-3 is a list of the management objects directly supported by the himib, along with the bank and register addresses to access the himib register contents. these objects are updated during any activity on any imr+ devices network port. hence the hardware counters provided by the himib chip alleviates the managed repeater software from all time critical duties. table 4-3 himib management objects management bank register management object name himib register class address address transmitcollisions (note) transmit collisions repeater 0 13 readableframes readable frames port 16-23, 31 0 readableoctets readable octets port 16-23, 31 1 framechecksequenceerrors fcs errors port 16-23, 31 2 alignmenterrors alignment errors port 16-23, 31 3 framestoolong frames too long port 16-23, 31 4 shortevents short events port 16-23, 31 5 runts runts port 16-23, 31 6 collisions (note) collisions port 16-23, 31 7 lateevents late events port 16-23, 31 8 verylongevents very long events port 16-23, 31 9 dataratemismatches (note) data rate port 16-23, 31 10 mismatches autopartitions auto partitions port 16-23, 31 11 lastsourceaddress last source port 16-23, 31 14 address sourceaddresschanges source address port 16-23, 31 12 changes repeaterverylongevents frames too long repeater 0 31 (hmi) (sum all ports together) repeatertotaloctets (hmi) total octets repeater 0 12 note: these attributes are only available to ieee specified accuracy when used with the imr+ device. they are not supported, or inaccurately reported, when the imr (am79c980) device is used. note that using the get bit rate error status of tp ports command through the himib chips imr+ management port get register will destroy the status of any set bits, and may cause the himib to miss a dataratemismatches attribute count. although access to the raw bit rate status is provided, it is recommended that this is only be monitored through the himibs dataratemismatches attribute, and not by directly reading the imr+ chips internal status.
amd 4-7 himib overview table 4-4 lists the ieee 802.3 management objects directly supported by the imr+. these attributes are accessed by performing get operations through the imr+ management port get register. since these objects are accessed infrequently, they present minimal overhead to the managed repeater software. table 4-4 imr+ management objects management management bank register imr+ object name imr+ command class address address code autopartitionstate tp port partitioning port 0 31 1000 0000 status autopartitionstate aui port status port 0 31 1000 1001 (note) portlinkstate (hmi) link test status of port 0 31 1101 0000 tp ports note: an access to get aui port status using any of the four options provided, will not be permitted to destroy the status of bits which the himib chip requires during the update of port attributes. hence, when any of the get aui port status commands is input through the himib chips imr+ management port get register, the himib chip will convert the command op-code prior to sending it serially over the imr+ management port to the version which does not cause the clearing of any status bits (op-code 1000 1001). 4.3 himib device hardware design considerations 4.3.1 himib device reset the imr+ and himib devices are designed to be driven from a common reset signal. the reset signal has the following characteristics. the reset signal must be synchro- nized to the imr+/himib clock source. figure 3-10 shows a typical reset synchroniza- tion circuit. the imr+ chip has a power on reset requirement of 150 m s. both the imr+ and himib devices have a soft (non power-on) reset requirement of 4 m s. 4.3.2 rdy requirements the himib chips processor interface uses asynchronous handshaking. the processor issues a read or write request, and then waits until the himib chip signals it is done with the operation. the himib device requires a variable amount of time to respond to processor read or write cycles. the longest read cycle is when the processor requests that the himib device get an on-chip imr+ register value. this cycle requires that the himib issues a get request using the imr+ management port, following which the imr+ chip will return the desired register contents. the state of the himib chip rdy pin indicates to the processor that the transfer is complete. it is driven low at the start of the read/write cycle, and is released when the himib device is ready to complete the cycle. the rdy pin should be used to drive the processor ready or acknowledge input. 4.3.3 r/w timing on get and set most interaction between a processor and the himib device are simple read and write operations on the internal register array. however the himib chip also acts as a processor interface to the imr+ device internal control and status registers. the processor modifies the imr+ internal control registers by writing to the imr+ chip through the himib chips imr+ management port set register (bank 0, register 30). after the processor writes to this register, the himib chip will serialize the contents of the write data, and transmit the contents of this register over the imr+ management port. the processor is masked from this parallel-to-serial conversion process and the access appears no different than writing to any other internal himib device register, although there is an internal delay before the command is actually inside the imr+ device.
amd himib overview 4-8 however, reading status information from the imr+ chip is a two step operation. first the processor must write an imr+ device get command to the himib chips imr+ management port get register (bank 0, register 31). when this happens the himib device transmits the contents of this register over the imr+ management port. the imr+ chip will interpret this command, and transmit the status information back to the himib device. the himib chip will place the status result returned from the imr+ chip back in the imr+ management port get register. the processor must issue a read of the himib chips imr+ management port get register to retrieve the results of the get operation. as far as the processor is concerned, this is a two cycle operation. first it writes the get command to the himib chip, then it reads the results back. the results are stored in the same register as the command was, so the processor does not need to modify the register array pointer registers to read the result. however, the processor does have to wait until the status information is in the himib device register, or it will be put into a wait state while the read operation is performed. an additional consideration is that the imr+ set and get commands may be delayed. normally the imr+ set and get command are executed as fast as the imr+/himib management port interface allows. however, the imr+ set and get commands may be queued behind other imr+ set or get commands. these commands can come from the processor, or they can be get commands generated internally by the himib device itself. the himib chip will issue get requests at the end of a frame in order to update its statistics. the himib device performs a total of four get commands during the inter- packet gap, two at a time. only after the first two are performed are the second two queued. if the processor has a get/set command queued when the first two commands have completed, it will be serviced. therefore a maximum of two imr+ get commands can be inserted in the imr+ command queue ahead of a processor command, resulting in delay servicing the processor command. the worst case delay under these circumstances is 70 sclk clock cycles. the proces- sor will be forced to wait for this duration if it attempts to read the result of a get command from the himib device before it is complete. this delay period will only affect the processors ability to access the imr+ chip, and in no way delays the processor when accessing other himib device registers. as described, the himib device takes longer to return get command results after a frame. get command results can also be delayed if the processor initiates a set command quickly followed by a get command. the processor will be made to wait until the set command is transmitted over the imr+ management port during which time the get command will be queued up. 4.3.4 read/write recovery time the himib chips processor interface is designed to support fully asynchronous operation. the himib device has a recovery time requirement of 150 ns between successive accesses. this parameter is usually provided by normal processor read and write timing cycles. however an extremely high speed processor could violate this parameter, resulting in unpredictable operation. under these circumstances the designer has two alternatives. either delay the processor between cycles with an additional instruction, or add delay circuitry to the processor hardware interface. 4.4 himib device software design considerations 4.4.1 himib device register access programming of the himib device is performed through two ports, a command port (c port) and a data port (d port). the command port is used to set up the internal register pointers (port/bank select and register/attribute select registers), and to read the himib chips status register. the data port is used to read and write the currently selected himib device register.
amd 4-9 himib overview the himib chips data registers vary in length from 8 bits to 48 bits. because the himib device registers are accessed one byte at a time, several accesses are required to perform a complete read or write. the read or write operation is actually performed on a separate holding register. the content of the actual register is transferred to the holding register on the first cycle of a read operation, or the last cycle of a write operation. the registers are addressed by writing two bytes to the c port. one byte is used to select the desired port or bank, and the other byte selects a specific register or attribute in the bank. the three most significant bits in the command byte select between the bank select register and the attribute select register. a value of 000 in the upper three bits indicates the bank select register, while a value of 111 indicates the attribute select register. valid bank addresses are 0, 1, 2, 16 through 23, and 31. the bank select register and the attribute select register can be written in any order. it is possible to keep the bank select register constant while varying the attribute select register, or vice versa. using this capability the programmer can access different attributes for one port, or step across the same attribute for different ports. 4.4.3 himib device interrupt processing the himib chip is designed to operate in either polling or interrupt driven environments. this section examines the successful use of the himib device in interrupt driven environments. the simplest software possible is a single program running alone, without interrupts. this is often called a polling environment, because the program must continually poll, or interrogate any attached devices to determine what needs to be processed. in the case of a repeater, the processor could poll the himib chip to determine if anything has happened that needs attention, such as partitioning of a port. interrupt driven environments complicate the matter because there are actually two programs operating in the same system. the main program, (often referred to as the background program because it runs when nothing else is going on) runs while there are no interrupts. if an interrupt occurs, the processor stops executing the main pro- gram, and begins to execute the interrupt service routine (isr), which is in effect just another program. this does not cause any problems unless the isr modifies some resource (memory or registers) that the main program was working on. the himib device has three resources that must be protected. they are the holding register, the pointer registers (bank select and attribute select), and the imr+ manage- ment port get register. if the main program is in the process of using any of those registers, the interrupt service routine must not be allowed to use them. as an example, assume that the main program is performing a read on the last source address (lsa) register (bank 16C23, 31, attribute 14). the pointer registers will be pointing to the lsa register, and the contents of the lsa register are in the holding register. the processor may have even read one or more of the 6 bytes from the holding register before the interrupt occurs. now assume that the same himib device generates an interrupt. the processor stops in the middle of reading the bytes from the himib chips holding register, and begins to execute the isr. the isr checks, and determines that the himib device needs servicing. a poorly designed interrupt service routine would then begin to use the himib chips resources that the main program was in the process of using. it would reprogram the address pointer registers to another bank and attribute, and read the contents of that register into the holding register. subsequently, the isr would read the bytes out of the holding register, and then, after changing those registers that the main program was using (bank select, attribute select, and the holding register), return control to the main program.
amd himib overview 4-10 now the main program finishes reading the bytes from the holding register, not knowing that it has been changed by the isr, and no longer holds the contents of the lsa register. under these circumstances the main program will unknowingly use incorrect information. there are several approaches to this problem. the simplest approach is for the main program to disable interrupts when manipulating a resource that might be modified by an isr. this is appropriate if the system allows it (some systems such as unix make disabling interrupts difficult for ordinary programs), and interrupts are disabled for a short period of time relative to the needs of the interrupting device. in this case, the processor must allow interrupts often enough to adequately service the himib devices interrupt events. a second alternative is to write the isr such that is does not modify the resource. in this case, the isr would not be allowed to read any of the himib chips registers, or change the pointer registers. rather, it would determine the source of the interrupt as best it could, then set a flag in memory telling the main program to deal with the situation. the main program then must check that flag periodically, to determine when servicing is required. another alternative is for the isr to restore the state of the resources after it used them, which requires that the isr know what state the resource needs to be returned to. however, the isr cannot read any of the required himib device registers directly (such as the bank/register select). one solution is for the processor to store the pointer values it is using in memory where the isr can retrieve them, and use them to restore the resource. however, even assuming that the pointer register are restored to resume the reading of an attribute (for instance), the state of the holding register cannot be restored to the original value, if the holding resistor was used during the isr, and the attribute changed. a read from an attribute should therefore be completed before the isr is permitted to execute, or repeated in its entirety after the isr has completed. it is possible to implement a mixed solution, where the isr can manipulate some of the resources, while others are protected by having the main program disable interrupts. 4.4.4 counter rollover the himib chips attribute counter registers roll over after they reach the maximum available count. depending on the exact attribute, this can occur at most every hour to every few days. the management processor must periodically read the contents of the registers to determine if a roll-over has occurred to keep accurate statistics. the program must increment a memory based counter to maintain statistics larger than 32 bits. the following equation calculates the current count based on the value in the himib chips attribute register, the initial value in the himib chips attribute register, and the rollover count for that attribute. count = himibval + (rollovercount* 2 32 ) note that the 32-bit counters in the himib device, upon initialization, are set to a random value. thus the counter may overflow from a maximum count of 0xffffffff to 0x0 at any time after power up. the himib device does not provide any indication that this has occurred other than the change in the counter value. note that the fact a rollover occurs, may or may not be of importance to the managing agent process resident within the repeater. this will depend on the network manage- ment protocol (i.e., snmp) and the management philosophy (i.e., frequency of polling of attributes by the management station).
5-1 managed repeater design managed repeater design 5 section 5.1 high level design considerations for managed repeaters this section discusses the design of managed repeaters using the integrated multiport repeater plus (imr+) and hardware implemented management information base (himib) chip-set at a block diagram level. subsequent sections discuss specific aspects of managed repeater design in more detail. 5.1.1 introduction to managed repeater design to perform any kind of remote management on a network device, the network manage- ment system (usually in a centralized location, such as a network operating center, where access can be controlled), needs to communicate with the remotely distributed components on the lan. these remote devices, such as repeaters, as well as bridges, routers, network monitoring stations and other type of lan interconnection devices, gather statistics that are particular to their functionality, location and configuration. the two primary methods to access the locally stored information in these devices is either in-band or out-of-band communications. typically, in-band management is used where the lan itself provides the communica- tions medium to allow the network management system (nms) to request access to, and receive answers from, the remote device. in-band management makes use of the existing lan infrastructure, so that additional communications paths are not required. the primary concerns in using in-band management are that if the lan medium becomes disrupted (such as a cable break), or if the lan becomes congested, it may become difficult to access management data in a timely fashion. note that in the case of congestion, the actual gathering of network management information must be kept to a reasonable overhead, so that the management task itself does not become the cause of undue loading of the network. alternatively, out-of-band management may be used. in this case, any communica- tions mechanism can be employed to access the management information stored in a remote device, such as a simple serial or parallel interface port, or a modem etc.. the principle issue for consideration in this case is that an additional communications channel must exist to the remote device. this may already be a requirement where the physical topology of the lan does not permit direct inter-connection of the nms and the managed device, such as in the case of a satellite office located many miles from the corporate headquarters. typically, out of band management uses a lower speed link than the normal lan connection. in either case, the nms must be able to communicate with the specific device, to request information from its local mib table. this means that each device must be uniquely addressable. in the simplest example, a point-to-point link between the nms and a single network device would be adequate. however, in a more typical network, the need is to monitor numerous remote devices from one central nms, in order to provide management capabilities for preventative maintenance as well as fault diagno- sis purposes. for in-band management, the mechanism to address a device is to give it a unique address (either physical or logical). typically this requires that each device can recog-
amd managed repeater design 5-2 nize a packet addressed to it, a function performed by the mac layer capabilities of a network device. in addition, in order to respond to a request for management data made by the nms, the remote device must be capable of transmitting a network frame. this again requires the capabilities of a mac. specifically in the case of an 802.3 repeater, there is no concept of a mac or any frame based messaging, since the repeater is strictly specified to operate as a bit level device. for instance, neither the imr or imr+ devices inspect frames received (and subsequently repeated) for integrity at the packet level, such as valid fcs, number of bytes, source or destination address etc. note however that in order to maintain the per port statistics required by the 802.3 repeater mib, the himib device does perform frame based error checking and monitor- ing. the himib chip contains a receive-only mac function for this purpose, although no transmit function is provided. this preserves simple modularity when multiple imr+/himib devices are interconnected to build a high port count repeater. in order to construct a managed repeater based on the imr+ and himib devices, it is necessary to include a bi-directional communications port by which the management data is communicated. for in-band management, this requires the addition of an ethernet controller device. for out-of-band management, an alternate communications port, such as serial interface, is required. the block diagram of figure 5-1 shows an example of a typical managed repeater, providing in-band and (optional) out-of-band capabilities. for in-band management services, the ethernet controller shown in the example is the media access controller for ethernet (mace, am79c940) device. the modular approach of the imr+/himib chip-set solution allows the mace device to be connected either to the imr+ expansion port, or to an aui port. to connect to the imr+ expansion port interface requires some additional logic, which can be incorporated within the expansion bus arbitration logic. the details of this scheme are covered later in this chapter. this approach is very flexible, since the nrz data format used on the expansion bus allows the connection of a wide variety of ethernet controllers. a management request, received on any one of the repeater ports (on one port of one imr+ device), will be monitored by the companion himib device. all frames (including frames requesting management data) will be repeated over the expansion bus to all other imr+ devices in the repeater, and hence will be observed and recognized by the ethernet controller. the agent process resident in the repeater (and executed by the cpu) will formulate the response to the request, and queue the reply for transmission by the ethernet controller, which will send the reply using the normal transmit mac function. the disadvantage of this approach is that the himib device does not gather statistics for traffic received on the imr+ expansion port, since it assume that data present on the expansion bus has already been monitored at the receive port of the imr+ chip which is sourcing data to the bus. hence frames generated by the ethernet controller (replies or notifications from the repeater itself) will not be included within the attributes of the repeater. in order to ensure the complete counting of all network traffic, including that generated by the repeater itself, it is recommended that the ethernet controller be connected to one of the repeater ports itself. in a typical repeater consisting of multiple imr+/himib chip-sets, it is unlikely that all of the aui ports are required. by connecting a suitable transceiver (such as the tpex or tpex+ chip) to the aui port of any imr+ device, an additional 10base-t port can be configured. since most high integration ethernet controllers incorporate a 10base-t transceiver function (such as the mace or pcnet -isa devices), the two 10base-t devices can be directly connected, effectively forming a zero length 10base-t link internal to the repeater itself. an example of this interface is detailed later in this section.
amd 5-3 managed repeater design 5.1.2 overview of design example the function of a managed repeater will be described using the block diagram example in figure 5-1. the design goal for this example was to exhibit the lowest cost 24-port stand alone hub with in-band management and a comprehensive led status display. at the core of the design are the three blocks containing the imr+/himib chip-set. each imr+ device is a complete repeater on a chip including eight 10base-t ports and a single aui port the three devices are connected together via their expansion ports, to form a common expansion bus and thereby act as a single logical 24-port repeater. this core design would work as a non-managed repeater without the need for a microproces- sor, but since this design is focused at a managed repeater application, a himib device is partnered with each imr+ chip, to autonomously monitor all nine of the imr+ chip network ports. the himib device gathers data from the management port, expansion port and port activity monitor (pam) port of the imr+ chip, and automatically performs all of the network statistics gathering functions required by the ieee 802.3k mib. the design specifies in-band management, which requires an ethernet media access controller (mac) with a system interface. this design uses the media access controller for ethernet (mace) device because this offers an 8-bit slave interface, allowing the whole cpu and memory system to be 8 bits wide. because the himib devices maintain the mib automatically, an 8-bit cpu such as the 80c188 has more than adequate bandwidth for this application. limiting the design to an 8-bit bus, minimizes component cost and complexity for the cpu, memory etc., as well as the associated manufacturing issues. the mace device may be connected either to the common expansion bus or to a spare aui port of an imr+ device. interfacing to the expansion bus is the lowest cost approach (see section 5.5). this has the drawback that it is not connected to a managed port of any of the imr+ devices, so data generated by the mace device will not be automati- cally included in the mib statistics. this can be overcome to some extent by monitoring the mace devices performance in software. the other approach is to make the design fully managed by adding a tpex or tpex+ device to an unused aui port on one of the imr+ chips, and connecting the twisted pair interface of the mace device directly to the tpex chip. this would make the mace appear to the hub as a mac connected to the aui port and thus provide full management at the expense of adding a tpex device (see section 5.4). porting an snmp agent to the 80c188 processor, with drivers for the himib and mace devices, would complete the design for a fully in-band managed repeater. a network manager at another station would then be able to send an snmp frame to the repeater by setting the source address in the frame directly to the physical address of the mace device. the mace device would detect its unique address, and request attention from the 80188 cpu. the cpu would copy the frame to buffer memory and then process the snmp instruction, which might for example be a request for one of the mib attributes. the cpu would read this attribute from the appropriate himib device(s), then generate an snmp frame encapsulating the response, and send this as a reply using the transmit function of the mace device. out-of-band management could be added very easily by adding the optional uart and serial drivers to the design. this could then interface to a modem allowing management to be performed remotely over telephone lines. because the cpu has considerable unused bandwidth, the led display array can be driven using a very simple multiplexing technique capable of driving up to 128 leds,
amd managed repeater design 5-4 allowing multiple leds per port, as well as general repeater status indicators. the cpu simply writes a value to an 8-bit latch where one bit drives one column, and the write to the latch increments a counter with 16 output pins, one of which is driven active at any one time to drive a row of the matrix. 5.1.3 detailed design notes note that figure 5-1 shows a much simplified block diagram. all of the necessary components are shown, but many connections are omitted for clarity. expansion bus the common expansion bus is formed by the arbitration logic between the expansion port on each imr+ device. see the discussion of expansion bus design in sections 5.2, 5.3 and 5.5. modules these are the transformer/filter modules needed for the 10base-t interface (total 24 needed) and the transformer module needed for the aui interface. 80c188 the amd 80c188 is an excellent choice for this design because of its low cost, 8-bit bus and high integration. it has sufficient integrated chip select signals to control all of the devices on its bus. it handles all transfers between the mace device and buffer ram using either string move instructions or dma transfers, with the mace mapped as a memory slave device. it can also utilize the same 20 mhz clock as the ethernet devices. mace device the mace device has on-chip fifos allowing it to connect directly to the relatively slow 8-bit cpu bus of this example repeater. it does not promiscuously receive all of the frames repeated onto the expansion bus, hence the total bus bandwidth requirements are modest, and dependent only on the volume of management request/response packet activity. figure 5-1 simplified block diagram of 24-port repeater with in-band management uart (optional) 8-bit cpu eprom sram mace serial link mace connected either to tpex or expansion bus tpex (optional) imr+ himib block imr+ himib block imr+ himib block aui address, data & control bus expansion bus module module module 8 10base-t ports module 8 10base-t ports 8 10base-t ports 17314a-17 aui port
amd 5-5 managed repeater design 5.2 fixed port repeater design this section discusses the design of repeaters to support a fixed maximum number of ports using centralized arbitration. figure 5-2 repeater design using multiple imr+/himib chip-sets 17314a-18 20 mhz osc. dat jam arst reset arst 20 mhz reqn req1 arbiter pal col ack req rst rst rst x1 x1 x1 col ack imr+himib block req2 dat jam col ack req dat jam col ack req imr+himib block imr+himib block figure 5-2 shows a block diagram for a repeater based on multiple imr+/himib chip-sets using centralized arbitration. this is the same design as that described in section 3.9 except that the himib device has been added and that the use of buffers on the dat and jam lines is suggested. see the imr+ device repeater state machine description in section 3 for a detailed description of the expansion port operation. see the imr+/himib interface section for a description of the imr+/himib chip-set block. note that the imr+/himib chip-set block includes buffering in figure 5-3. in the case of this specific design (figure 5-2) the buffers may be omitted for a solution based on four
amd managed repeater design 5-6 imr+/himib chip-sets provided the capacitance of the pcb traces for the dat and jam signals does not exceed 28 pf. 5.3 imr+/himib interface figure 5-3 below shows the interconnections between the imr+ and himib devices. it also shows a bi-directional buffer for the dat and jam signals and the direction control logic for this buffer (the buffer is always enabled). the buffer is only necessary if the load to be driven by the imr+ device dat and jam output buffers exceeds 100 pf. if it can be guaranteed that the load will not exceed this figure the dat and jam pins of the imr+ chip can drive the expansion bus directly. the sense of the direction control must be chosen such that the buffers drive the expansion bus when both req and ack are low (asserted). figure 5-3 detail of imr+ himib block ack col rst x1 si so sclk str crs jam dat req imr+ ack col ck si so sclk str crs jam dat himib req rst 8 tp ports 48 6 aui port dat jam bidirectional buffer dir nor gate ack col rst 20 mhz clk microprocessor interface expansion bus interface 17314a-19 note 1: direction dir b ? a low a ? b high b a note 1 5.4 aui/mac interface a mac device may be connected to an imr+ chip as a fully managed port by adding a tpex device to an aui port of one of the imr+ chips, and connecting the twisted pair interface of the mace device directly to the tpex chip. this would make the mac appear to the hub as a mac connected to the aui port and thus provide full manage ment at the expense of adding a tpex device. the imr+ device cannot be connected to an ethernet mac by simply connecting the two aui ports together, since both devices effectively possess a dte implementation of the aui (versus a mau implementation). this is to say that both the imr+ and mace
amd 5-7 managed repeater design devices expect the collision in (ci ) pair of the aui to be a differential input, and collisions to be signaled using a 10 mhz pulse train (as supplied by a mau). hence the simplest way to connect the two devices is to connect a 10base-t mau, such as the tpex device, to the imr+ chips aui port, and effectively construct a zero length 10base-t connection between the tpex and the integrated 10base-t port of the mace device (see figure 5-4), using only pcb traces. the rxd and txd pins of the tpex and mace device are simply connected together, and the txp outputs are left open. figure 5-4 imr+/tpex+ and mace devices connected for in-band management imr+ aui port no connect tpex or tpex+ mace 10base-t interface txd+ txdC rxd+ rxdC txp+ txpC rxd+ rxdC txd+ txdC txp+ txpC do+ doC di+ diC ci+ ciC do+ doC di+ diC ci+ ciC 17314a-20 5.5 expansion bus/mac interface 5.5.1 imr+ expansion port basics using the imr+ expansion port, a design based on the imr+ chip can be cascaded to provide increased port density, whilst only incurring the delay of a single logical repeater. a common expansion bus is formed by implementing a simple arbitration logic circuit between the expansion port on each imr+ device. essentially, each imr+ must request access (using its req output) to the common dat and jam bi-directional lines. providing only one imr+ device asserts req , the arbiter will return a common ack , which signals the requestor it can drive the dat/jam lines as outputs, and signals all non-requesting devices that they should configure dat/jam as inputs. if multiple devices request the bus, the arbiter returns a collision indication ( col ), which causes each imr+ device to output jam on its network ports independently. all repeated data in an imr+ or multi-imr+ device design is available on the expansion bus. data on the dat line of the expansion bus is passed in nrz format, that is already decoded from the manchester encoded data passed over the network. because of this, any media access controller (mac) device with a general purpose serial interface (gpsi) capability can be connected to the expansion bus. most popular lan controllers support a derivative of the gpsi, including the lance (am7990), mace (am79c940) and pcnet-isa (am79c960) devices. in a repeater based on the imr+/himib chip-set, the mac is not used to gather statistics since this function is performed by the himib device(s). the mac provides in-band network addressability that allows a remote network management station (nms) to request access to statistical data that the repeater maintains (in the repeater mib), and to execute specific actions such as enabling and disabling a port.
amd managed repeater design 5-8 figure 5-5 shows how to interface a repeater based on two or more imr+/himib chip-sets to an ethernet controller such as the mace or lance chips, via the gpsi and the common expansion bus. the imr+/himib block is shown in detail in figure 5-3. note that the buffering shown in the example of figure 5-3 may be omitted for a solution based on three imr+/himib chip-sets, providing the capacitance of the pcb traces plus the palce devices on the dat and jam lines does not exceed 46 pf. figure 5-5 ethernet mac interfaced to expansion bus for in-band management 17314a-21 20 mhz osc. dat jam arst reset arst 20 mhz reqn req1 counter palce22v10 col ack req rst rst rst x1 x1 x1 col ack imr+himib block req2 dat jam col ack req dat jam col ack req imr+himib block imr+himib block done_count new96 tck done_count new96 rts cdt rts crs syno data txd rxo arbiter palce16v8 interface palce16v8 lance or mace txc cdt rts rena rxd rxc txd dat jam ack tck tck cdt dat jam tck tck
amd 5-9 managed repeater design 5.5.2 principle of operation the basic function of the three palce devices shown in figure 5-5 is to interface multiple imr+ devices and the mac together to form one logical repeater. a major function of the logic is to make the mac appear to the common expansion bus as if it is another imr+ device. the arbiter device controls the col and ack signals of the expansion bus, asserting ack when one and only one request signal is active. in this design a request signal is the assertion of either a req line from any imr+ device or the rts line from the mac device. if more than two requests are active at once the arbiter will signal a collision to all devices by asserting the col signal to the imr+ devices and the cdt signal to the mac. the arbiter grants access to the dat/jam resources of the expansion bus by asserting ack to all imr+ devices. the imr+ that has asserted its req will see ack asserted and start to repeat data over the expansion bus via the dat signal. the cdt signal sent to the mac is always asserted when col is true, but is also asserted in other cases. these cases (described in the logic equations below) are basically the same as those that occur in the internal logic of each imr+ device. the most complex of these cases is to hold cdt asserted for 96 bit times after any new event occurs on any repeater port. this is necessary because each imr+ chip will ensure that the minimum length event repeated to the network on any of its 10base-t ports or its aui port is 96-bit times long. if the 96-bit counter is not implemented, the solution may generate collisions or unacceptable short ipg times when the mac attempts to transmit a packet, as described below. assuming one imr+ device receives a short event on one of its ports, and successfully arbitrates for the expansion bus. it starts to repeat the incoming data on the bus, but data reception stops before 96 bit times have elapsed. the receiving imr+ device will de-assert its request when the event terminates prematurely, will enter the receive collision state (as will all other imr+ devices connected to the same expansion bus), and extend the received short event to a minimum size fragment (96 bits) on all active transmit ports. the expansion bus will appear to have no activity whilst all req lines are inactive. if the mac has a pending transmit packet, it would commence its ipg timer when the expansion bus appeared to become inactive, and subsequently assert its rts signal and successfully gain control of the bus. in this case, a collision may result, or an extremely short ipg could be generated. despite the expansion bus appearing inactive, each imr+ device will be in the process of extending the short event to 96 bits, by transmitting a jam pattern to all active ports. this example design eliminates this problem by having a 96-bit counter that is reset to the beginning each time a new event is detected on any repeater port. the arbiter detects the events, and passes a signal (new96) to the counter to tell it to restart the count. the arbiter holds cdt to the mac asserted, at least until the counter asserts done_count. the other functions of the arbiter are to generate the synchronous reset signal required by the imr+ and himib devices, and to generate the 10 mhz bit clock. the bit clock is used to generate the transmit and receive clocks of the mac, and is synchronized with reset so that it is in phase with the internal 10 mhz bit clocks of the imr+ devices. the interface device essentially translates the gpsi compatible signals of the mac into the imr+ compatible signals of the expansion bus.
amd managed repeater design 5-10 it multiplexes the unidirectional transmit data (txd) and receive data (rxd) signals of the mac onto the bi-directional dat line of the expansion bus, generates the receive enable (rena) signal to the mac and synchronizes rxd with the receive clock (rxc) 5.5.3 counter logic equations upon reset , the counter is initialized to the terminal value of 60h (96), and remains there until triggered. if (re)triggered by new96, the counter is reset to 00h. the counter will count at 10 mhz until it reaches the terminal value, and will stop there until triggered. tck and reset are also generated here. tck := /tck * /reset * /arst generates tck for mac use reset := arst synchronizes the async reset signal q0 := /q0 * /tck * /done_count * /reset * /new96 toggle if still counting low at reset. low when triggered by new96 + q0 * (tck + done_count) * /reset * /new96 stop at terminal value q1 := /q1 * q0 * /tck * /done_count * /reset * /new96 low at reset, low when (re)triggered by new96 + q1 * (/q0 + tck + done_count) * /reset * /new96 q2 := /q2 * q1 * q0 * /tck * /done_count * low at reset, low when /reset * /new96 (re)triggered by new96 + q2 * (/q1 + /q0 + tck + done_count) * /reset * /new96 q3 := /q3 * q2 * q1 * q0 * /tck * /done_count * /reset * /new96 low at reset, low when (re)triggered by new96 + q3 * (/q2 + /q1 + /q0 + tck + done_count) * /reset * /new96 q4 := /q4 * q3 * q2 * q1 * q0 * /tck * /done_count * low at reset, low when /reset * /new96 (re)triggered by new96 + q4 * (/q3 + /q2 + /q1 + /q0 + tck + done_count) * /reset * /new96 q5 : = /q5 * q4 * q3 * q2 * q1 * q0 * /tck * toggle if all lower bits high /done_count * /new96 and still counting low if (re)triggered by new96 + q5 * (/q4 + /q3 + /q2 + /q1 + /q0 + tck + stay if any lower bit is low or done_count) * /new96 if done counting + reset high at reset q6 := /q6 * q5 * q4 * q3 * q2 * q1 * q0 * /tck * low when (re)triggered by /done_count * /new96 new96 + q6 * (/q5 + /q4 + /q3 + /q2 + /q1 + /q0 + tck + done_count) * /new96 + reset high at reset done_ count = q6 * q5 * /q4 * /q3 * /q2 * /q1 * /q0 terminal count (96) 5.5.4 arbiter logic equations ack = req1 * /req2 * ... /reqn * /rts ack is asserted when one and only one expansion bus request is active + /req1 * req2 * ... /reqn * /rts % % + /req1 * /req2 * ... reqn * /rts + /req1 * /req2 * ... /reqn * rts + /req1 * /req2 * ... /reqn * rtscls * ackclk * /cdt term to extend ack when mac device finishes sourcing data onto expansion bus ackclk := ack clock delayed ack signal (ack * ackclk defines first clock period with valid dat and jam) col = /ack * (req1 + req2 + ... reqn + rts) col is asserted when more than one expansion bus request is active colclk := col clock delayed col signal cdt := cdt causes the mac device to back off/stay off the expansion bus col arbiter detects collision + ack * ackclk * jam single imr collision + colclk * ack holds cdt active during dead clock cycle
amd 5-11 managed repeater design + /done_count * cdt maintains cdt (suppresses new mac requests) until 96 bit time-out xcol := present transmit collision state ack * ackclk * jam * /dat ongoing single imr transmit collision + col ongoing multiple imr transmit collision +colclk * ack ongoing multiple imr transmit collision (dead clock cycle) rtsclk := rts clock delayed rts signal (rts*rtsclk defines first recognized rts from mac) new96 := triggers or re-triggers counter (96 bit times) ack * /ackclk * /cdt new repeater data (start of repeated packet, ack/ with no existing collision) (trigger only) + ack * ackclk * jam * /dat * /xcol new transmit collision (single imr) + col * /xcol new transmit collision (multi-imr) 5.5.5 interface logic equations dat.trst = ack * ackclk * rtsclk enabled if mac request gets arbiter ack (delayed) dat = syncdata * /clk synchronized and latched mac data (if enabled) guarantees hold time for slave imrs + dat * clk + dat * syncdata + cdt overriding high if collision exists (if enabled) jam.trst = ack * ackclk * rtsclk enabled if mac request gets arbiter ack (delayed) jam = cdt high if collision exists ackclk := ack clock delayed ack signal (ack * ackclk defines first clock period with valid dat and jam) crs = ack * ackclk * /jam * /cdt single active imr or mac sourcing data + rcken term to extend crs at end of mac receive syncdata := /rts * dat * ack * ackclk synchronized receive data for the mac + txd * rts synchronized txd data for mac transmit rxc = rcken * /clk inverted clock for synchronized data for mac receive rcken := ack * ackclk * /rts * /rtsclk * /jam rclk enabled if non-mac data transfer (mac is slave device) + ack * rts * /cdt rclk enabled on transmit to allow data loopback to mac rtsclk := rts clock delayed rts signal (rts * rtsclk defines first recognized rts from mac) 5.6 himib device microprocessor interface figure 5-6 shows one example of how the himib device may be interfaced to a popular microprocessor such as the 80c188. this is simply one way that this may be accom- plished, and there are many other possible solutions a 10 mhz 80c188 is employed since this can use the same 20 mhz clock as the himib device. the rdy output of the himib device must be connected to one of the ready inputs of the cpu so that the himib device can insert wait states in the cpu cycle. both
amd managed repeater design 5-12 the ardy and srdy inputs of the 80c188 require some kind of synchronization to the clkout clock of the cpu. in this case srdy was chosen, and a d type flip flop such as half a 74ls74 is used to guarantee that the setup and hold times for this input are met. the 80c188 has several programmable chip select outputs, which may be used to eliminate external address decode logic. in this case pcs0 was used although any of these outputs would work. the himib requires one non-multiplexed address line from the cpu to drive the c/ d pin. this design uses the pcs5/a1 line to provide this signal, thus avoiding the need for an external latch. the interrupt inputs of the 80c188 are positive true, while the int output of the himib device is negative true. an inverter such as an ls04 is thus needed. note that because the rdy and int outputs of the himib device are open drain, pullups are required. figure 5-6 80c188 to himib connection example x1 srdy into clk out rd wr pcso ad0C7 pcs5/a1 ck rdy int himib rd wr cs d0C7 c/ d 80c188 q v cc v cc 20 mhz oscillator 1/2 74 17314a-22 d
amd 5-13 managed repeater design 5.7 managed repeater status indicators when the imr+ and himib devices are used in conjunction, after a hardware reset the himib chip will reprogram the imr+ devices str signal to become an input. applica- tions requiring that the imr+ chips carrier sense status be brought out must externally generate the original str signal. this is done as shown in figure 5-7 by counting the clock cycles from the time the imr+ device is reset. figure 5-7 port activity monitor implementation using externally generated str signal am79c981 imr+ chip xtal osc ck d q async reset x1 x2 rst str crs clr ck q q d 1/2 74 tck ck si sipo ck register t p 7 t p 6 t p 5 t p 0 a u i shift register carrier sense outputs 1/2 74 tck 17314a-23 c i rst clk pal note that once the himib device detects the presence of the imr+ chip, the himib will enable the ci reporting (c bit in the imr+ chip programmable options register) function in the imr+ chip. the imr+ device will therefore report aui ci activity using the bit position immediately after the last twisted pair carrier status (tp7) and prior to the combined aui ci/di status. therefore the aui ci activity is effectively reported during the bit position corresponding to the occurrence of the str signal.
amd managed repeater design 5-14 figure 5-8 shows the timing relationship between the reset, with respect to the clock input, and the carrier sense (crs) output from the imr+ chip. the carrier sense outputs are valid following the tenth xclk after reset becomes inactive, and the crs bits will be clocked out at the rate of one bit every two xclk periods thereafter. figure 5-8 carrier sense (crs) and strobe (str) timing relationship notes: 1. externally generated signal illustrates internal imr+ chip clock phase relationship. 2. imr+ chip standalone, x will be low. when attached to a himib device, x reflects the state of the ci pair. 3. str signal is not available when the imr+ chip is attached to himib device, and must be generated externally. rst x1 tck (note 1) crs str (note 3) 12 91011 aui tp0 tp1 tp7 x aui tp0 (note 2) 17314a-24 5.8 modular repeater collision arbitration the imr+ expansion port allows for modular expansion. an expandable repeater based on modular plug-in cards can be built by sharing the arbitration duties between a backplane bus architecture and several separate repeater modules. each repeater module performs the local arbitration function for the imr+ devices on that module, and provides signals to the backplane for use by a global arbiter. figure 5-9 and figure 5-10 show an expandable repeater based on 3 modules that each use 3 imr+ devices. in this design, each module provides 24 10base-t ports and requires a single palce16v8-15 to perform the local arbitration function. the back- plane portion of the modular repeater consists only of the global arbiter, implemented with a single palce16v8-15. note that in each module care must be taken to ensure that the imr+ devices do not drive a load greater than 100 pf with their dat and jam pins.
amd 5-15 managed repeater design a module similar to that shown in figure 5-10 may be designed with up to four imr+/himib chip-sets provided that the capacitance seen by the dat and jam pins of the imr+ devices does not exceed 28 pf. this capacitance will include the pcb traces and the input capacitance of the buffer device. figure 5-9 modular repeater dat jam globalcol globalack r1 c1 r2 c2 r3 c3 module 1 module 2 module 3 global arbiter palce16v8 17314a-25 figure 5-10 repeater module with three imr+ devices am79c981 imr+ 1 am79c981 imr+ 2 am79c981 imr+ 3 local arbiter palce16v8 globalcol globalack cm rm dir ab dat jam ack req1 req2 req3 module connector note 1 note 1: direction dir b ? a low a ? b high 17314a-26
amd managed repeater design 5-16 local arbiter logic equations (for n imr/imr+ devices per module): rm = req1 * /req2 * /req3 * ... /reqn rm = /req1 * req2 * /req3 * ... /reqn rm = /req1 * /req2 * req3 * ... /reqn % % % rm = /req1 * /req2 * /req3 * ... reqn cm = /rm * (req1 + req2 + req3 + ... reqn) dir = rm * globalack the dir signal is high when the module drives the dat and jam backplane bus signals. a single palce16v8 can support up to eight imr/imr+ devices per module. modularr.cdr global arbiter logic equations (for m modules): globalack = /c1 * /c2 * /c3 * ... /cm * r1 * /r2 * /r3 * ... /rm + /c1 * /c2 * /c3 * ... /cm * /r1 * r2 * /r3 * ... /rm + /c1 * /c2 * /c3 * ... /cm * /r1 * /r2 * r3 * ... /rm % % % + /c1 * /c2 * /c3 * ... /cm * /r1 * /r2 * /r3 * ... rm globalcol = /globalack * (r1 + r2 + ... rm) + (c1 + c2 + c3 + ... cm) a single palce22v10 can perform the global arbitration for up to eight modules. a distributed version of the global arbitration scheme is relatively easily achieved by using the req from each imr+/himib chip-set (or group) to drive a unique signature onto a backplane. this signature can then be used to arbitrate at each module, similar to the arbitration scheme employed in the microchannel architecture. the primary issue in any such design is the req to ack arbitration must resolve in 100 ns. see the slow ack or col signals section for additional detail.
6-1 layout recommendations layout recommendations 6 section the following layout recommendations are based upon the experiences of numerous imr customers and imr+ beta sites. these guidelines are somewhat conservative and are intended to minimize the engineering required to achieve an appropriate emi/rfi emission certification, rather than component count. 6.1 the attachment unit interface the aui port of the imr+ device can drive a full length (50 m) aui cable via an isolation transformer and 15 pin d-type connector. an external transceiver can be connected to the aui for remote mau applications. alternatively, an integrated mau can be incorpo- rated into the repeater, by connecting a suitable transceiver chip (for 10base-t, 10base2 or 10base-f/foirl) to the aui via an isolation transformer. to provide a connection capability to a remote mau requires a 15-pin d connector, 75 m h isolation transformer, termination resistors, and capacitors to reduce common mode noise (figure 6-1). the ieee 802.3 section 7 requirements dictates that the di and ci inputs be terminated with 78.0 5 w . two matched 40.2 w 1% resistors are used in parallel to accomplish this. the 0.1 m f capacitor tying the center point of the resistors to ground is a filter for common mode noise that may be induced from external sources. figure 6-1 imr/imr+ device with external aui connector am79c980 or am79c981 dgtl gnd doC di+ diC ci+ ciC do+ pulse transformer 40.2 w optional anlg gnd 0.1 m f 0.1 m f aui connector 40.2 w 40.2 w 40.2 w 17314a-27 3 10 5 12 2 9 note: 1. compatible aui transformer modules, with a brief description of package type and features are included in the appendix. note 1
amd layout recommendations 6-2 as an example of an integrated mau, a detailed aui to cheapernet attachment is described in the am7996 ieee 802.3 ethernet/cheapernet transceiver data sheet, in the amd ethernet/ieee 802.3 family data book (pid #14287b). note that the sqe test function of any transceiver connected to a repeater must be disabled. in the case of the am7996, the sqe test pin must be connected to the positive logic supply (0 v) for the transceiver. special attention should be observed in order to minimize potential coupling of noise generated by the dc/dc switching convertor, into the transceiver circuit, and hence to the outside world (via the bnc connector). one approach which has been used in conjunction with the am7996, is to modify the termination of the do circuit. figure 6-2 shows a 0.1 m f capacitor connecting the parallel 40.2 w resistors to C9 volts. this capacitor helps to minimize fcc problems associated with noise from the dc/dc power converter. while this capacitor helps filter out common mode noise, the normal bias point of the am7996 do receiver is altered by the ac coupling effect (the recom- mended circuit for the am7996 do circuit normally has the center point of the do termination resistors tied directly to the C9v generated by the dc/dc convertor). to mitigate this, a resistor is added in parallel to provide a dc bias path. the value of the parallel resistor is not critical, but it should be small enough to maintain 78.0 5 w when combined with the 40.2 w resistors, and large enough not to reduce the effect of the common mode filter. a value from 39C150 w is suggested. it may be easiest to use 40.2 w so that a single resistor pack can be used for all terminations. figure 6-2 imr/imr+ device with integrated 10base2 mau am79c980 or am79c981 doC di+ diC ci+ ciC do+ pulse transformer note 1 40.2 w optional anlg gnd 0.1 m f 0.1 m f 10base2 mau coax tap (bnc) see am7996 data sheet for component and implementation details 40.2 w 40.2 w 40.2 w am7996 note: 1. compatible aui transformer modules, with a brief description of package type and features are included in the appendix. 0.1 m f 39C150 w C9 v 17314a-28 40.2 w 40.2 w
amd 6-3 layout recommendations 6.2 decoupling the imr+ chip contains both analog and digital elements. separate power pins are provided for the analog sections, the digital portion of the tp line drivers, and the digital core logic. dv cc pin # dv ss pin # function 19 16 tp ports 0 & 1 drivers 28 31 tp ports 2 & 3 drivers 43, 49 35, 37, 46, 51 core logic & expansion control pins 59 56 tp ports 4 & 5 drivers 68 71 tp ports 6 & 7 drivers care should be taken in the board design to minimize the coupling of noise from the power supply and digital logic to the analog power pins. decoupling capacitors should be placed as close to the appropriate v dd and v ss pins as possible. figure 6-3 shows the recommended decoupling values for the imr+ chip. figure 6-3 imr/imr+ device power supply decoupling recommendations 17314a-29 1.8C2.2 w (or 120z ferrite bead) 0.1 m f 0.01 m f 0.1 m f 0.1 m f 0.01 m f 0.1 m f 0.1 m f 0.01 m f 0.1 m f av dd 82 av ss 5 dv ss 16 dv dd 19 dv dd 28 dv ss 31 71 dv ss 68 dv dd 59 dv dd 56 dv ss 49 dv dd 51 dv ss am79c980 or am79c981 0.1 m f 47 m f 43 dv dd 46 dv ss 35 dv ss 37 dv ss pin 1 (connect to digital planes as close as possible to imr/imr+ tp ports) (connect to digital planes as close as possible to imr/imr+ tp ports)
amd layout recommendations 6-4 the supply pins for the tp ports are directly decoupled with 0.1 m f capacitors. addi- tional 0.01 m f capacitors are connected to the digital planes near the tp ports to increase the effective range of filtering. this combination of 0.01 m f and 0.1 m f capaci- tors are used for the core logic as well. x7r type capacitors are recommended if surface mount technology is used. experience has shown that the x7r is more effective above 5 mhz than the less expensive z5u type. the analog phase locked loop (pll) of the imr/imr+ device is inherently more sensitive to noise in the 50C100 khz range. the imr chip recommended that a 47 m f capacitor be used in parallel with a 0.1 m f capacitor to provide filtering in this range for the pll power pins. the effectiveness of this filter can be significantly improved by isolating dv ss from av ss with a 1.8C2.2 w resistor. some experimentation has also shown that a 120z ferrite bead is effective in place of this resistor. the imr+ chip incorporates additional decoupling capacitance internally. comparative testing indicates that the necessity for the 47 m f capacitor can be removed if the board design is relatively quiet (typically less than 300 mv of power supply noise). however, there will be no adverse technical impact on the imr+ device operation if the 47 m f capacitor is retained. 6.3 power planes the board power planes must be separated into analog and digital portions. the +5v and ground planes can be laid out as shown in figure 6-4. the analog portion should be located under the analog power pins of the imr+ device, and the aui logic. the digital portion should be located under all of the digital logic. the digital ground should be extended close enough to the 10base-t filters to attach a 0.1 m f capacitor to the filters ground pin. extending the digital power plane under the 10base-t filters is not recom- mended. the analog and digital power planes should be tied at a single point with either a 1.8C2.2 w resistor or a 120z ferrite bead. a 47 m f capacitor in parallel with a 0.1 m f capacitor is used for decoupling.
amd 6-5 layout recommendations figure 6-4 imr/imr+ device power plane recommendations 0.1 m f 17314a-30 shielded rjC45 pin 1 frame ground shielded rjC45 filter filter 0.1 m f 0.1 m f 47 m f 0.1 m f 1.8C2.2 w or 120z ferrite digital plane am79c980 or am79c981 dvcc dvss avss av dd 47 m f analog plane shielded rj-45 connectors are recommended. the shield pins should be tied to the frame ground. depending on the characteristics of the 10base-t filters, either the frame ground or a void in the planes should be extended under the filters. consult the filter manufacturer to determine if the frame ground is needed to minimize the effects of crosstalk within the filters. 6.4 filter modules 10base-t ports are by definition unshielded. any noise on these ports will be emitted to the outside world. emi studies of 10base-t designs show that special attention needs to be paid to common mode noise, since this is usually the greatest contributor to emi problems. for this reason, it is recommended that 10base-t filter/transformer modules that incorporate a common mode choke in the transmit (and preferably receive) path are used. a common mode choke in the receive circuit is useful for keeping noise induced anywhere in the receive link from coupling to the transmit path. for a list a representative filter/transformer modules, refer to appendix a. an additional method to further reduce any high frequency common mode noise effects is to add 68 pf capacitors at 2000v to the network side of the filter modules outputs. calculations show that capacitors in this range do not violate the ieee 802.3 require- ments for insertion loss and return loss.
amd layout recommendations 6-6
7-1 glossary glossary 7 section aui attachment unit interface. ieee specification for a node or repeater connection interface to an external medium attachment unit (mau). the aui cable between the dte/repeater and the mau may be up to 50 m in length. in systems where the mau is embedded into the dte or repeater (such as 10base-t or 10base2) a physical implementation of the aui may not be present. defined in section 7 of iso/iec 8802-3: 1990 (ansi/ieee std 802.3). see also pls. ci control in. aui differential pair circuit, operating at pseudo ecl levels. the mau drives a 10 mhz signal on the ci circuit to indicate to the dte or repeater that a collision has been detected on the network, that the mau is the the jabber state, or that an sqe test from the mau to the dte is in progress. see also jabber and sqe test. cmip common management information protocol. the iso defined transport protocol to move management information through the network. defined by iso/iec 9595/6, information processing systems C open systems interconnection C common manage- ment information protocol specification. concentrator a general term frequently used instead of repeater. typically, a concentrator supports more than one network protocol, such as 802.3/ethernet as well as 802.5/token ring. the terms hub, concentrator and intelligent hub are frequently used interchange- ably to reference a multiport, multiprotocol device, capable of statistics gathering, fault monitoring and/or network management activities. crc cyclic redundancy check. a crc is calculated by the mac transmit process, and checked by the mac receive process of a station (dte), to ensure integrity of the frame contents. the mathematical crc is computed on the destination address, source address, length/type and data/pad fields (all the frame except the preamble, sfd and fcs fields). the computed 32-bit crc is appended as the last 4-bytes of every frame. see also fcs. csma/cd carrier sense multiple access/collision detect. the media access control protocol used in ethernet and 802.3 networks, which determines the transmit and receive characteristics of each station. defined in section 4 of iso/iec 8802-3:1990 (ansi/ieee std 802.3). see also mac. da destination address. the 48-bit field within the 802.3/ethernet packet format which identifies the physical address of the intended recipient. the field immediately follows the preamble/start frame delimiter, and precedes the destination address (da) field. the 802.3 protocol supports individual, multicast and broadcast addressing. see also source address. di data in. aui differential pair circuit, operating at pseudo ecl levels. data received by the mau from either the media or the do circuit (or its logical equivalent), is driven onto the di circuit for use by the dte or repeater.
amd glossary 7-2 do data out. aui differential pair circuit, operating at pseudo ecl levels. the dte or repeater drives manchester encoded data out on the do circuit (or its logical equiva- lent), which is transmitted by the mau over the physical media and the di circuit. dte data terminal equipment. communication station (or node) capable of reception and/or transmission of data. generally includes the mac and pls sublayer functions, but may also include an embedded mau. endec encoder/decoder. the manchester encoder/decoder, effectively the physical implemen- tation of the 802.3 pls sublayer. nrz data output by the mac, is passed to the pls function and manchester encoded, and sent over the aui do circuit (or its logical equivalent) to the mau. manchester encoded data from the network (from other mac devices), received on the aui di circuit, is passed to the pls function and decoded to extract clock and nrz data, as well as the indication of receive carrier, which are returned to the mac. foirl fiber optic inter repeater link. ieee specification for inter repeater communications link, primarily aimed at significantly increasing the distance capabilities of an 802.3/ethernet network. defined in section 9.9 of iso/iec 8802-3:1990 (ansi/ieee std 802.3). fcs frame check sequence. a 4-byte field appended to the end of each 802.3/ethernet frame. the field contains a 32-bit crc, mathematically computed on the destination address, source address, length/type and data/pad fields (all the frame except the preamble, sfd and fcs fields). the crc is appended by the mac transmit process and checked by the mac receive process, and used to verify the integrity of the frame contents. see also crc. himib hardware implemented management information base. the himib device (am79c987) effectively acts as a management co-processor to the imr+ device, providing support for all hardware intensive repeater management functions. the himib device incorpo- rates hardware registers which directly support the mandatory and optional attributes required to implement an ieee 802.3 repeater mib. hmi hub management interface. a specification developed by novell, inc., which defines the mib variables for a 10base-t repeater, as well as the driver independent protocol by which the variables are accessed in a novell software environment. hub a general term frequently used instead of repeater. see also concentrator and repeater. iab internet advisory board. the group within the internet community responsible for the administration of protocol standards. ietf internet engineering task force. the group within the internet community responsible for the development of protocol standards. ilacc integrated local area communication controller (am79c900). a general purpose 32-bit bus mastering ethernet controller, with integrated sia function. largely software compatible with the lance device. see also lance.
amd 7-3 glossary imr integrated multiport repeater (am79c980). single chip repeater incorporating 8 10base-t and 1 aui compatible ports, all 802.3 repeater requirements, management, diagnostics and port expansion facilities. imr+ enhanced integrated multiport repeater (am79c981). an enhanced pin, timing and software compatible version of the imr device. the imr+ chip incorporates additional features used by the himib (am79c987) device for managed 802.3 repeater applications. ipg inter packet gap. the minimum time permitted between back-to-back packets on the 802.3 network, specified as 96 bits (9.6 m s) minimum. note that a phenomenon known as ipg shrinkage can cause the ipg to be reduced below 96 bits. jabber a mau is required to interrupt a station which is transmitting for an excessive period of time, to prevent the network from disruption. the mau is required to enter the jabber state if it detects continuous do circuit (or its logical equivalent) activity for 20C150 ms. during the jabber state, transmission to the network is disabled and collision is returned to the dte via the ci circuit (or its logical equivalent). the mau will remain in this state until do circuit activity stops for a period of 0.25C0.75 s. jam a dte that detects a collision, is required to complete the preamble/sfd sequence (if it has not already done so), and subsequently continue to transmit for an additional 32 bit times. the jam sequence can be any arbitrary pattern, providing it is not the calculated crc. on a repeater, if a receive collision is detected, it will ensure that at least 96-bits are sent to all ports except the receiving (colliding) port, if necessary by appending an additional jam sequence to the frame. when a repeater detects entry into the transmit collision state, a new 96-bit jam sequence will be transmitted to all ports. in this case, the jam sequence must start with the first bit as a one and continue with 62-bits of alternating 1, 0, 1, 0......, with the remainder being an arbitrary pattern. lance local area network controller for ethernet (am7990). a general purpose, 24-bit address/16-bit data, bus mastering ethernet controller. the novell ne2100 architecture is based on the lance device. see also pcnet-isa. length a 2-byte field in the 802.3 frame, immediately following the source address field, and preceding the data field, which defines the total number of data bytes contained in the frame. the valid range is 46C1500 bytes. for values less than 46-bytes, pad characters are added to the data field of the transmit frame to ensure that the minimum size frame is observed (64-bytes); these are removed at the receiving station. the field is transmit- ted with the high order byte first, in lsb to msb order. see also type. mac media access control. the mac sublayer defines the medium independent capability for frame transmission and reception using the csma/cd access method. defined in section 4 of iso/iec 8802-3:1990 (ansi/ieee std 802.3). mace media access controller for ethernet (am79c940). a general purpose, 16-bit data bus, slave ethernet controller, incorporating a high speed bus interface, ethernet controller, sia, 10base-t transceiver and aui port.
amd glossary 7-4 manchester encoding manchester encoded data is used for data transmission across the aui (and across all of the common media currently defined for 802.3). each bit of information is converted into a bit-symbol, which in turn is divided into two halves. during the first half of the bit-symbol, the representation is the complement of the data bit being encoded, and during the second half of the bit-symbol, the representation is identical to the data bit value. in this way, a transition is guaranteed in the center of every bit-symbol, hence clock and data information are encoded into a single serial representation. manchester encoding/decoding is performed in the pls sublayer. see also endec and pls. mau medium attachment unit. the physical and electrical interface between a dte or repeater and the actual medium. the mau is connected to the dte by an aui, although this may not be visible if the mau is embedded within the dte or repeater. a different mau is required to support each different type of medium (cable type). mib management information base. network devices which can be managed embed a mib. the mib is effectively an internally located table of variables which an external device can access. several published mib standards exist for various network devices. the work to create a mib for 802.3 repeaters is defined in ieee 802.3 section 19, layer management for 10 mb/s baseband repeaters. this information was also used as the basis of the definition for the repeater mib in rfc 1368, which defines the snmp encoding for an 802.3/ethernet repeater. in addition, many vendors publish their own mibs and/or extensions to an existing mib. mib-i management information base. defines the core set of managed objects for the internet suite of protocols. primarily focussed on monitoring network interfaces and the protocol stack. defined in rfc 1156. see also mib, mib-ii and rmon mib. mib-ii management information base. defines extended capabilities over mib-i, primarily focussed on monitoring the network interfaces and the protocol stack (including snmp). defined in rfc 1213. see also mib, mib-i and rmon mib. pcnet-isa single chip ethernet controller for isa (am79c960). an isa based, 24-bit address/ 16-bit data, bus mastering ethernet controller. basically a single chip implementation of the novell ne2100 adapter card, incorporating a full isa bus interface, ethernet controller, sia, 10base-t transceiver and aui port. driver compatible with the novell ne2100 architecture, and based on the lance software model. see also lance and sia. pls physical signalling. ieee specification which defines the signalling scheme between the mac sublayer, through to the aui, which provides the interface for a medium attach- ment unit (mau). defined in section 7 of iso/iec 8802-3: 1990 (ansi/ieee std 802.3). the pls sublayer is physically implemented by the manchester encoder/decoder function. nrz data output by the mac, is passed to the pls function and manchester encoded, and sent over the aui do circuit (or its logical equivalent) to the mau. manchester encoded data from the network (from other mac devices), received on the aui di circuit (or its logical equivalent), is passed to the pls function and decoded to extract clock and nrz data, as well as the indication of receive carrier and collision, which are returned to the mac sublayer. see also aui and endec. pma physical medium attachment. the portion of the mau which contains the active circuitry responsible for the interface of the aui circuits to the specific network medium.
amd 7-5 glossary preamble an alternating 1, 0, 1, 0..... sequence at the start of each frame transmission. the preamble for 802.3 networks is defined as 7-bytes long, followed by a 1-byte sfd; whereas the preamble for ethernet networks is defined as 62-bits long, with a 2-bit synch character (hence both have an overall preamble/start delimiter length of 64-bits). when manchester encoded, the preamble sequence produces a 5 mhz frequency at the start of each frame, which is used by a receiving station or repeater as a reference to decode the receive clock and data. repeater an 802.3/ethernet repeater in its most generic form is an n port device, which supports the 802.3 protocol only. a repeater is used to extend the physical topology of the network, allowing two or more cable segments to be coupled together. no more than four repeaters are permitted between the end-to-end path of two stations. when data is received on a single port, the repeater retransmits the incoming bit stream to all other ports, performing signal retiming and amplitude restoration. when data appears simultaneously on more than one port, the repeater transmits a collision to all ports, including the receiving ports. in addition, the repealer can isolate a port if it detects faults, such as excessive number or duration of collisions, to prevent disruption of the rest of the network. in a 10base-t network, the repeater provides a central point of connectivity, ideally suited to the incorporation of statistics gathering and network administration functions. defined in section 9 of iso/iec 8802-3:1990 (ansi/ieee std 802.3). repeater management the generic term used to describe the 802.3 supplements layer management for 10 mb/s baseband repeaters (section 19). the repeater management standard defines the mib variables for an 802.3 repeater. defined in ieee std 802.3kC1992 (supplement to iso/iec 8803-3:1992 [ansi/ieee std 802.3, 1992 edition]). see also repeater mib. repeater mib the generic term used to describe rfc 1368, which defines the mib variables and their encoding for use by snmp. see also repeater management. rfc request for comment. a specification administered and developed by the internet community (iab/ietf). the specifications are public domain, and detail the tcp/ip internet protocol suite. rmon mib remote network monitoring management information base. defines the mib attributes for a network monitoring device, with detailed statistic, fault diagnostic, performance monitoring and historical trending capabilities.defined in rfc 1271. see also mib-i and mib-ii. sa source address. the 48-bit field within the 802.3/ethernet packet format which identifies the senders unique physical address. the field immediately follows the destination address (da) field. see also destination address. sfd start of frame delimiter. the sfd immediately follows the alternating 1, 0, 1, 0..... preamble sequence. the sfd for 802.3 networks is defined as a 1-byte field consisting of the pattern 1, 0, 1, 0, 1, 0, 1, 1 whereas for ethernet networks a 2-bit pattern of 1, 1 at the end of preamble signifies the synch character (although the byte contain- ing the sfd/synch character is identical in both cases). the first but of the 802.3 frame (the destination address field) immediately follows the sfd. see also preamble and synch.
amd glossary 7-6 snmp simple network management protocol. the internet specified transport protocol for the movement of management data in a heterogeneous network environment. defined in rfc 1157. sia serial interface adaptor (am7992). a manchester encoder/decoder ic, which performs the physical signalling (pls) sublayer functions of the ieee 802.3 standard. the device encodes data and clock from the mac for transmission over the network, and drives the do circuit of the aui. it receives data from the network via the di circuit of the aui, extracts the data and clock into separate paths, and passes these back to the mac. sqe signal quality error. a 10mb/s pulse train passed from the mau (using the ci circuit) to a dte or repeater to indicate an error condition on the network, such as collision or excessive transmit duration (jabber). sqe test signal quality error test. frequently referred to as heartbeat. an 802.3 mau, when connected to a station (dte), is required to send a brief collision indication back to the dte after the end of each transmission. when the transmission from the dte completes on the do circuit, within 0.6C1.6 m s the mau should start to return a collision indication to the dte using the ci circuit, of duration 10 5 bit times. the test is intended to notify the dte that the mau collision circuitry is operational, and that the aui cable is intact. note that the sqe test function must be disabled when a mau is connected to a repeater. synch synchronization. the synch immediately follows the alternating 1, 0, 1, 0..... pream- ble sequence in an ethernet frame, and indicates that the first bit of the frame (the destination address field) will follow immediately. the synch for ethernet networks is a 2-bit pattern of 1, 1 at the conclusion of the preamble. for 802.3 networks, a 1-byte sfd field is defined, consisting of the pattern 1, 0, 1, 0, 1, 0, 1, 1 (hence the byte containing the synch/sfd character is identical in both cases). see also preamble and sfd. tcp/ip transmission control protocol/internet protocol. the internet protocol suite, which defines a wide range of network services, to allow heterogeneous network system operation. the suite is a layered set of protocols, and covers all aspects of network service and communication. primarily defined in rfc 791 and rfc 793, although many other related rfcs are applicable to the protocol suite. tpex twisted pair ethernet transceiver (am79c98 or am79c100). a transceiver ic that converts the electrical signals of the aui to those of the 10base-t standard. type a 2-byte field in the ethernet frame, immediately following the source address field, and preceding the data field, which defines the protocol type of the frame. the type specification has no meaning at the mac level, and is passed to higher level protocols. in the 802.3 frame, this field defines the length of the data portion of the frame. note that type identifiers fall outside the range for valid packet length values. the field is transmitted with the high order byte first, in lsb to msb order. see also length. 10base-fb 10 mb/s baseband fiber optic backbone. covered by section 17 (draft) of ieee 802.3. uses 802.3 protocol, dual fiber point-to-point cabling with synchronous signalling to provide an inter-repeater backbone link. no defined maximum node count, maximum fiber distance 2 km, depending on system configuration.
amd 7-7 glossary 10base-fl 10 mb/s baseband fiber optic link. covered by section 18 (draft) of ieee 802.3. uses 802.3 protocol, dual fiber point-to-point cabling and repeaters to provide the network architecture. no defined maximum node count, maximum fiber distance 1C2 km, depending on system configuration. 10base-fp 10 mb/s baseband fiber optic passive. covered by section 16 (draft) of ieee 802.3. uses 802.3 protocol, dual fiber point-to-point cabling and passive optical star to provide the network architecture. no defined maximum node count, maximum fiber distance 0.5 km, depending on system configuration. 10base-t 10 mb/s baseband twisted pair. covered by section 14 of ieee 802.3. uses 802.3 protocol, point-to point twisted pair cabling and repeaters to provide network services. no defined maximum node count, maximum cable distance 100 m. defined in sec- tion 13 and 14 of ieee std 802.3iC1990 (supplement to iso/iec 8802-3: 1990 (ansi/ ieee std 802.3)). 10base2 10 mb/s baseband 200 m (cheapernet). a low cost version of 10base5 (frequently referred to as cheapernet), eliminates the external aui requirement, relaxes the network electrical interfaces and allows use of thin 75 w coaxial cable. maximum 30 nodes (or mating connectors) on cable segment, 185 m per segment. defined in section 10 of iso/iec 8802-3: 1990 (ansi/ieee std 802.3). 10base5 10 mb/s baseband 500 m (ethernet). based on the original ethernet specification proposed by dec, intel and xerox, for multi-drop communication scheme using the csma/cd access protocol, over thick 75 w coaxial cable. 802.3 is the corresponding ieee standard which varies in minor electrical and protocol specifications. maximum 100 nodes on cable segment, 500 m per segment. defined in section 8 of iso/iec 8802-3: 1990 (ansi/ieee std 802.3).
amd glossary 7-8
a-1 appendix a appendix 10base-t interface filter and transformer modules a the table below lists the recommended resistor values and filter and transformer modules for the imr+ device. imr+ device compatible 10base-t media interface modules manufacturer part # package description bel fuse a556-2006-de 16-pin 0.3 dil transmit and receive filters and transformers. bel fuse 0556-2006-00 14-pin sip transmit and receive filters and transformers. bel fuse 0556-2006-01 14-pin sip transmit and receive filters, transformers and common mode chokes. bel fuse 0556-6392-00 16-pin 0.5 dil transmit and receive filters, transformers and common mode chokes. halo electronics fd02-101g 16-pin 0.3 dil transmit and receive filters and transformers. halo electronics fd12-101g 16-pin 0.3 dil transmit and receive filters and transformers, transmit common mode choke. halo electronics fd22-101g 16-pin 0.3 dil transmit and receive filters, transformers and common mode chokes. halo electronics fd22-101r2 16-pin 0.3 dil transmit and receive filters, transformers, common mode chokes, plus termination resistors. pca electronics epa1990a 16-pin 0.3 dil transmit and receive filters and transformers. pca electronics epa2013d 16-pin 0.3 dil transmit and receive filters and transformers, transmit common mode choke. pca electronics epa2116 16-pin 0.3 dil transmit and receive filters and transformers, transmit common mode choke, plus termination resistors. pulse engineering pe-65434 10-pin sip transmit and receive filters, transformers, and common mode choke. pulse engineering pe-65445 16-pin 0.3 dil transmit and receive filters and transformers (for smt use pe-65446) pulse engineering pe-65467 16-pin 0.3 dil transmit and receive filters, transformers, common mode chokes, plus termination resistors. pulse engineering pe-65424 16-pin 0.3 dil transmit and receive filters, transformers, and common mode chokes. tdk tla 470 14-pin sip transmit and receive filters and transformers. valor electronics pt3877 16-pin 0.3 dil transmit and receive filters and transformers. valor electronics pt3983 8-pin 0.3 dil transmit and receive common mode chokes. valor electronics fl1012 16-pin 0.3 dil transmit and receive filters and transformers, transmit common mode choke. valor electronics fl1010/17 62-pin 4 channels (quad mod). transmit and receive filters, transformers, common mode chokes, plus termination resistors. valor electronics fl1020 16-pin 0.3 dil transmit and receive filters, transformers and common mode chokes, plus termination resistors. valor electronics fl1003 18-pin sip transmit and receive filters, transformers and common mode chokes.
amd appendix a a-2
b-1 appendix b appendix aui isolation transformers b imr/imr+ device compatible aui isolation transformers manufacturer part # package description bel fuse a553-0506-ab 16-pin 0.3 dil 50 m h halo electronics td01-0756k 16-pin 0.3 dil 75 m h halo electronics tg01-0756w 16-pin smd 75 m h pca electronics ep9531-4 16-pin 0.3 dil 50 m h pulse engineering pe64106 16-pin 0.3 dil 50 m h tdk tla 100-3e 16-pin 0.3 dil 100 m h valor electronics lt6031 16-pin 0.3 dil 50 m h contact the following companies for further information on their products: bel fuse phone: (317) 831-4226 fax: (317) 831-4547 halo electronics phone: (415) 989-7313 fax: (415) 367-7158 pca electronics phone: (408) 954-0400 fax: (408) 954-1440 pulse engineering phone: (619) 674-8218 fax: (619) 675-8262 valor electronics phone: (619) 458-1471 fax: (619) 458-0875 tdk phone: (213) 530-9397 fax: (213) 530-8127
amd appendix b b-2

▲Up To Search▲

Price & Availability of 17314

	To Download 17314 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .