AN-730 BSI Device Software Design Guide

DP83265

Literature Number: SNOA198 S eieSfwr einGieAN-730 Guide Design Software Device BSI

TM National Semiconductor BSI Device Software Application Note 730 Design Guide Robert Macomber, Mark Travaglio November 1990

Table of Contents corresponding bits in the CMP register will be actually stored in STAR. With the BSI device in ‘‘Stop Mode’’, and 1.0 INTRODUCTION no intervening accesses to the BSI device Control Bus, it is 2.0 INITIALIZATION guaranteed that all 8 bits will match. 3.0 SERVICING INTERRUPTS Finally, write 0x07 to the STAR. This clears all the error bits and sets all the stop bits (the STAR is automatically loaded 4.0 MEMORY MANAGEMENT SCHEMES with 0x07 upon reset of the BSI device). 5.0 SENDING FRAMES 2.2 Set the Mailbox Address Register 6.0 RECEIVING FRAMES When loading Pointer RAM data into the BSI device, a 7.0 QUEUE MANIPULATION ‘‘mailbox’’ mechanism is used. The mailbox is a 32-bit word 1.0 INTRODUCTION in off-chip memory which the BSI device uses to load or dump the Pointer RAM Registers. This mailbox may be lo- This application note describes how to initialize the National cated anywhere within the 28-bit ABus address space of the Semiconductor BSI device (DP83265) and interact with it. BSI device and accordingly its address must be explicitly Initialization and data service support occur through the defined. This is accomplished via the 8-bit Mailbox Address Control Bus and via memory that is accessible by both the Register (MBAR). BSI device and the host. The host processor must be able to respond to interrupts and have access to both the BSI To load the Mailbox Address Register (MBAR) first load device Control Bus and some mutually accessible memory. 0x00 into the Pointer RAM Control and Address Register This application note should be read in conjunction with the (PCAR). This tells the BSI device to internally point to the BSI datasheet. first byte of the mailbox address. Then execute four succes- sive writes to the MBAR to load the full mailbox address; 2.0 INITIALIZATION writing the most significant bytes first. Each write automati- Before BSI device operation can begin, the device must be cally increments the byte pointer to the next byte. initialized. The BMACTM and PLAYERTM devices must also When the BSI device is reset, the Mailbox Address Register be individually initialized. To initialize the BSI device, the (MBAR) is loaded with a hardware revision code. The host steps shown below should be followed. Each action is ex- may obtain this revision code by sequentially reading four plained further in the subsections that follow. bytes from the MBAR before loading the mailbox address. Put the BSI Device in Stop Mode # 2.3 Load the Pointer RAM # Set the Mailbox Address Register The BSI device maintains pointer registers for accessing # Load the Pointer RAM and manipulating the various queues. Prior to normal opera- # Set the Event Notify Registers tion, some of these pointer registers must be initialized with # Set the Mode Register queue addresses (see Table I). For active Request queues the host software must load the Confirmation Message # Set the Request Configuration Registers (CNF) Queue Pointer Register and the Request (REQ) # Set the Request Expected Frame Status Registers Queue Pointer Register. For Indicate queues the host soft- # Set the Indicate Configuration Register ware must load the Indicate Data Unit Descriptor (IDUD) # Set the Indicate Mode Register Queue Pointer Register and the Pool Space (PSP) Queue Pointer Register. For information about choosing initial # Set the Indicate Threshold Register Pointer RAM values see Section 7 on Queue Manipulation. # Set the Indicate Header Length Register TABLE I. Pointer Registers Used Load the Limit RAM # during Queue Initialization # Clear the Attention Register # Put the BSI Device in Run Mode Pointer Registers Addr 2.1 Put the BSI Device in Stop Mode CNF Queue Pointer Register (RCHN1) 0x02 During initialization the BSI device must be in ‘‘Stop Mode’’. REQ Queue Pointer Register (RCHN1) 0x03 This is necessary to prevent the device from attempting to CNF Queue Pointer Register (RCHN0) 0x06 perform any actions or respond to any external stimulus pri- REQ Queue Pointer Register (RCHN0) 0x07 or to the completion of the initialization sequence. The BSI IDUD Queue Pointer Register (ICHN2) 0x09 device may be placed in Stop Mode by setting three bits in PSP Queue Pointer Register (ICHN2) 0x0a the State Attention Register (STAR). IDUD Queue Pointer Register (ICHN1) 0x0d Since the State Attention Register (STAR) is a conditional PSP Queue Pointer Register (ICHN1) 0x0e write register, it must be read before it is written. By doing so IDUD Queue Pointer Register (ICHN0) 0x11 the original contents of the STAR register are loaded into PSP Queue Pointer Register (ICHN0) 0x12 the Compare Register (CMP). When a subsequent write to the STAR register occurs, only those bits that match the Before loading a Pointer RAM Register, first read the Serv- ice Attention Register (SAR) to verify that the PTOP bit is

BSITM and PLAYERTM are trademarks of National Semiconductor Corporation.

C1995 National Semiconductor Corporation TL/F/11088 RRD-B30M75/Printed in U. S. A. set; signifying that a previous Pointer RAM operation has Indicate breakpoints are instances that generate interrupts. completed. If this bit is not set wait for the previous opera- You may configure the BSI device to interrupt at the end of tion to finish. each service opportunity, at the end of a burst (i.e., channel Write the value one wishes to store in the Pointer RAM change) or after a user defined number of frames have Register (i.e., the base address of the relevant queue) in the been received. Prudent use of Indicate breakpoints can sig- memory location selected as the BSI device Mailbox. nificantly reduce interrupt processing overhead by reducing the number of interrupts generated by the BSI device. Next configure the Pointer RAM Control and Address Regis- ter (PCAR) with the PTRW bit cleared and the address of 2.10 Set the Indicate Threshold Register the Pointer RAM Register placed in the least significant five The Indicate Threshold Register (ITR) specifies how many bits. A zero value in the PTRW bit specifies that the next frames must be received before a threshold breakpoint is Pointer RAM operation will read from the Mailbox and write realized. The value in this register is only used when the to the Pointer RAM Register. The two most significant bits in appropriate bits are set in the IMR. the PCAR (BP0, BP1) are not used in this context and may Loading the ITR with 0x00 specifies a value of 256. This be loaded with 0’s. For example, when loading the PSP value is loaded into an internal working register each time Queue Pointer for Indicate Channel 0, one would write 0x12 the state of any Indicate Channels change. to the PCAR. Finally, clear the PTOP bit in the Service Attention Register 2.11 Set the Indicate Header Length Register (SAR). The SAR is a conditional write register, so it is nec- If the Header/Info frame sorting mode is specified, one essary to read it immediately before writing to it. Clearing must load the Indicate Header Length Register (IHLR) with the PTOP bit causes the BSI device to perform the actual the length (in units of four byte words) of the header portion Pointer RAM operation. The device signals the completion of the frame. The FC field occupies an entire word. For ex- of the operation by setting the PTOP bit in the SAR. ample, to separate an 8 octet header when using long, six- The above steps must be done for all pointers associated octet MAC addresses, one would load a value of 6 (FC e 1, with those channels that will be used. DA/SA e 3, header e 2) into this register. 2.4 Set the Event Notify Registers 2.12 Load the Limit RAM You may specify which events will trigger an interrupt by During normal operation of the BSI device, the CNF and setting the corresponding bit in the Notify Registers; where IDUD queues must be given status space. This may be a 1 enables interrupts from that event and a 0 disables done as part of the initialization procedure. For information those interrupts. The Notify Registers may be written with- about choosing initial Limit RAM values see Section 7 on out being read previously (not conditional write registers). Queue Manipulation. See Section 3, Servicing Interrupts, for a more complete Before loading a Limit RAM Register, first read the Service treatment of this subject. Attention Register (SAR) to verify that the LMOP bit is set (signifying that the previous Limit RAM operation has com- 2.5 Set the Mode Register pleted). If this bit is not set wait for the previous operation to Load the BSI device Mode Register (MR) to configure the finish. BSI device with global bus and queue parameters. For ex- Next load the Limit Address Register (LAR). The top four ample a value of 0x52 causes the BSI device to generate 32 bits of the LAR define the target Limit RAM Register, the byte bursts when accessing the data bus, use 1k (small) LMRW bit specifies what the next Limit RAM operation will queues, operate in a physical memory environment, use be (LMRW e 0 means a write to the Limit RAM) and the ‘‘big-endian’’ data alignment, check parity on access to the MSBD bit contains the most-significant data bit of the 9-bit ABus and Control Bus and optimize operation for clock Limit value. speeds over 12.5 MHz. Next load the Limit Data Register (LDR) with the lower 8 bits 2.6 Set the Request Configuration Registers of the limit value. Load the Request Configuration Registers (R0CR and Finally, write a 0 into the LMOP bit in the Service Attention R1CR) for both Request Channels (RCHN0 and RCHN1) to Register (SAR). The SAR is a conditional write register, establish channel specific operating parameters; such as making it necessary to read it immediately before writing to Source Address and Frame Control Transparency. it. Clearing the LMOP bit causes the BSI device to perform the actual Limit RAM operation. The BSI device signals the 2.7 Set the Request Expected Frame Status Registers completion of the operation by setting the LMOP bit in the Load the Request Expected Frame Status Registers SAR. (R0EFSR and R1EFSR) for both Request Channels Repeat the above steps for all desired limits. (RCHN0 and RCHN1) to set up the expected status for frame confirmation services. A value of 0x00 in these regis- 2.13 Clear the Attention Registers ters means that any frame status is acceptable. Clear the Request Attention (RAR) and Indicate Attention 2.8 Set the Indicate Configuration Register Registers (IAR) by first reading the register, to load the Compare Register (CMP), and then writing a 0x00 value to Load the Indicate Configuration Register (ICR) to establish the register. Both of these registers are automatically initial- copy control parameters for each Indicate Channel. A typi- ized to 0 upon BSI device reset. cal register value is 0x49; which instructs the BSI device to copy frames addressed for the owned MAC address or to The No Space Attention Register (NSAR) should be initial- an externally matched group address. ized to reflect the state of space of all the queues. If space was given to all of the CNF and PSP queues, read and write 2.9 Set the Indicate Mode Register 0x00 into NSAR. Load the Indicate Mode Register (IMR) to set the frame sorting mode, skip option and the desired Indicate breakpoints.

2 2.14 Put the BSI Device in Run Mode TABLE II. Attention Registers

Initialization of the BSI device is now complete. The device Master Attention Register (MAR) may be made fully operational by reading the State Atten- State Attention Register (STAR) tion Register (STAR) and immediately writing 0x00 to it. This will clear the stop bits for the Indicate, Request and Status/ No Space Attention Register (NSAR) Space machines; putting them in ‘‘Run Mode’’. Service Attention Register (SAR) The BSI device should immediately begin fetching PSP De- Request Attention Register (RAR) scriptors for the Indicate Channels to use for frame recep- Indicate Attention Register (IAR) tion. At this point a write to one of the REQ queue Limit The host may control which attention bits will generate an RAM Registers would cause the BSI device to begin fetch- interrupt by configuring the Notify Registers (see Table III). ing REQ Queue Descriptors for frame transmission. TABLE III. Notify Registers 3.0 SERVICING INTERRUPTS The BSI device provides facilities for selecting which events Master Notify Register (MNR) will generate an interrupt and a mechanism for determining State Notify Register (STNR) which events are present after an interrupt has been raised. No Space Notify Register (NSNR) Service Notify Register (SNR) 3.1 Event Registers Request Notify Register (RNR) The BSI device supports a two-level hierarchy of Event Reg- Indicate Notify Register (INR) isters; where the presence of attention signals in lower level attention registers is recorded in a single upper level atten- For each Attention Register a corresponding Notify Register tion register. Attention signals may be disabled at either of exists. Each Attention Register is ANDed with its corre- the two levels. Events may only be cleared by resetting the sponding Notify Register and then all of the resulting signals attention bits in the lower level registers. are ORed together and presented to the next level (see The upper level attention register is called the Master Atten- Figure 1 ). tion Register (MAR). It contains five attention bits that indi- For example, to disable all interrupts caused by service cate the presence or absence of any events recorded in events: clear the Service Attention Register Notify (SVAN) each of the five corresponding attention lower level regis- bit in the Master Notify Register (MNR). To disable only in- ters. Those registers are listed in Table II. terrupts caused by Pointer RAM Operations: set the SVAN bit in the MNR and clear the PTOPN bit in the Service Notify Register (SNR).

TL/F/11088–1 FIGURE 1. BSI Device Event/Notify Registers

3 When checking attention registers for the cause of an inter- # attaching the previous page to a PSP Descriptor of the rupt, one should perform a bit-wise AND operation between same queue the attention and notify registers and examine the result. # incrementing the PSP Limit Register for that queue Just checking the attention registers may be misleading. For The management of space for ODUs (outgoing frame data) example, to disable an Indicate Channel one may wish to and ODU Descriptors (ODUDs) must be done by the host. leave its PSP queue empty and mask off the ‘‘Low Data Space’’ attention bit for that channel; via the Indicate Notify A fully allocated 1k PSP queue consumes 512 kbytes of Register (INR). Under these circumstances the IAR, by it- buffer space. A fully allocated 4k PSP queue uses 2 MB of self, may contain misleading information. buffer space. 3.2 Example Procedure 4.3 Shared Buffer Pool A typical procedure for servicing BSI device interrupts is as To maximize memory utilization, multiple Indicate Channels follows: may share a single pool of data buffers. This does not mean that Indicate Channels can be made to share a Pool Space # disable host interrupts (PSP) queue, but rather that data buffers attached to the # determine the event that triggered the interrupt by check- various PSP queues are allocated and freed from a global ing the Master Attention Register and then querying the buffer pool on an ‘‘as needed’’ basis. When using a shared appropriate lower level attention register buffer pool, the Indicate buffer management becomes the # process the event (or post the event to a service queue) following: # clear the attention bit (or mask the attention bit) # Detecting page boundary crosses; to determine when # enable host interrupts the BSI device is finished filling the previous page # Obtaining confirmation that the host has finished pro- 4.0 MEMORY MANAGEMENT SCHEMES cessing all frames in that page The BSI device may be configured to use memory shared # Returning that page to a shared buffer pool or, upon de- between itself and the host or it may be configured to use termining that the page has been dedicated to a given the host’s memory. In addition, it can be made to operate in channel, reattach the page to the channel’s PSP queue a vitural memory environment. # Responding to interrupts caused by a ‘‘Low Space’’ con- Although the BSI device manages space for incoming data dition by allocating buffer space to one or more PSP De- (from channel specific Pool Space (PSP) queues); the host scriptors and incrementing the PSP Limit Register for must implement a memory management mechanism to re- that queue plenish the PSP queues and manage the space needed to hold output data (ODU) and ODU Descriptors (ODUDs). Again, the management of space for ODUs (outgoing frame data) and ODU Descriptors (ODUDs) must be done by the 4.1 Memory Requirements host. Up to ten distinct queues may be established; two for each One danger with sharing pool space is that a heavily used channel. Depending upon the value of the Small Queue low priority channel may starve a high priority channel by (SMLQ) bit in the Mode Register (MR), these queues will consuming all of the buffer space. This is contrary to the each consume 1k or 4k of memory; collectively occupying idea of priority. It is recommended that some mechanism be either 10k or 40k of memory. implemented for reserving memory for a given channel and A 4 byte word must be allocated as the BSI device Mailbox. that at least four buffer pages be dedicated to Indicate This word is only used when accessing the BSI device Channel 0 (ICHN0). This is to ensure that FDDI-SMT frames Pointer RAM Registers. will not be dropped when there is a greal deal of activity on Space must also be allocated for buffering frames. Any buff- the other Indicate Channels. ers drawn from this space must be no larger than 4 kbytes 5.0 SENDING FRAMES and may not cross a 4 kbyte boundary. At the current time This section describes how to use the BSI device to queue a the Count (CNT) field in the PSP Descriptor is ignored by the frame for transmission on an FDDI ring. It is assumed that BSI device. Pool space is intended to be allocated in the BSI device has been initialized and that the Request 4 kbyte pages. Configuration Registers (R0CR and R1CR) and the Request Space must be allocated for buffering ODU Descriptors Expected Frame Status Registers (R0EFSR and R1EFSR) (ODUDs). As with frame data, buffers drawn from this space have been previously loaded with the desired values. must be no larger than 4 kbytes and may not cross a 4 kbyte The mechanism for sending a frame is as follows: boundary. # Obtain space for data structures 4.2 Dedicated Buffer Pools # Load the ODU(s) To simplify memory management, buffer pages may be ded- # Process previous CNFs (optional) icated to individual PSP queues. When using dedicated buffers, the Indicate buffer management task becomes a matter # Build the ODUD(s) of: # Build the REQ # detecting page boundary crosses; as an indication that # Signal the BSI device the BSI device has finished filling the previous page # obtaining confirmation that the host has finished processing all frames in the previous page

4 Subsection 5.7 describes some special considerations for be set to a value of 1; since, in this case, only a single frame sending multiple frames in a single request object. will be transmitted. 5.1 Obtain Space for Data Structures The Confirmation Class (CNFCLS) field defines the level of request confirmation that the BSI device will use and should BSI device addressable memory must be obtained to: be set as needed. To turn off request confirmation put a hex # hold the frame data value of 0x4 in the CNFCLS field; although, the BSI device # hold the ODU Descriptor(s) will always generate CNF Descriptors whenever an excep- # hold the Request Descriptor tion is encountered. Please note that request processing will halt for a given channel should that channel’s CNF queue It is the responsibility of the host software to manage space become full. Thus, a provision for processing CNF Descrip- for frame data and the ODUDs. Section 4, Memory Manage- tors must be included in all applications; even those applica- ment Schemes, describes two simple memory allocation tions that do not wish to receive confirmation for most re- methods. If multiple ODUDs are required, these must be quests. contiguously allocated in the form of an array of ODUDs. The Request Class (RQCLS) field defines the class of the Space for the Request Descriptor must be located within request (i.e., asynchronous, synchronous, restricted token, the area designated as the Request queue (see Section etc.). The FC field should be loaded with an appropriate 2.3). It must also be allocated in a serially contiguous fash- FDDI Frame Control value. ion; immediately following the previously allocated descriptor. All BSI device queue pointers ‘‘wrap’’ to the first loca- When sending a single frame, both bits in the First and Last tion upon reaching the end of the queue area. bits should be set; indicating that this is the only REQ De- scriptor in this request object. Finally, the address of the first The frame data may need to be divided between multiple ODUD should be put into the LOC field. ODUs. Each ODU may start anywhere within a 4k page, but it must end at or before the next 4k boundary. Multiple 5.6 Signal the BSI Device about the Request ODUs must be generated for frames over 4k in length. The BSI device may be caused to examine either of its REQ For each ODU, space must be allocated for a correspond- queues by writing to the corresponding Limit RAM Register ing ODU Descriptor (ODUD). System configurations in with a value that raises the limit to reference the new REQ which the BSI device directly addresses host memory, may Descriptor. be able to contrive ODU Descriptors (ODUDs) that refer di- 5.7 Sending Multiple Frames in a Single Request Object rectly to host specific memory buffers. The BSI device is capable of transmitting multiple frames in 5.2 Process Confirmation Status Message Descriptors a single service opportunity. This feature becomes impor- (CNF)ÐOptional tant on a heavily loaded FDDI ring, with relatively infrequent When the BSI device processes a request it places confir- service opportunities. The BSI device can be caused to pro- mation messages in the CNF queue for that Request Chan- cess multiple frames by: nel. By examining these messages, the host may determine # building an ODUD list that contains multiple frames when the BSI device has finished using ODU, ODUD and # building a request object that contains multiple REQ De- REQ queue space. scriptors or If the BSI device has been instructed to generate interrupts # a combination of the above two methods. after writing confirmation messages, then an autonomous interrupt handler should be available to asynchronously pro- The first method is extremely simple. Allocate and fill the cess CNFs. Conversely, if these interrupts have been dis- ODU buffers for all of the frames. Build multiple ODU De- abled, then CNFs should be processed when attempting to scriptor objects (demarcated by the First and Last bits in send a frame. each ODUD) and concatenate the ODUDs together into one array of descriptors. Build the REQ Descriptor, as before, 5.3 Copy Frame Data to Buffer except load the frame count into the SIZE field. If the ODU buffers are distinct from the host specific memo- The second method consists of a creating a REQ Descriptor ry buffers, copy the frame data from the host buffer(s) to the marked as being ‘‘first’’, zero or more REQ Descriptors ODU buffer(s). marked as ‘‘middle’’ descriptors and an ending REQ De- 5.4 Build the ODU Descriptor(s) scriptor marked as being ‘‘last’’. The Limit RAM Register, for the given request queue, must be set beyond the last REQ An ODU Descriptor (ODUD) must be written for each ODU. Descriptor. The parameter fields in first REQ Descriptor are The address and size of the ODU must be recorded in the used for the entire request object. ODUD.LOC and ODUD.CNT fields, respectively. When only a single ODUD is needed both the First and Last 5.8 Batching Single Frame Requests bits should be set (only). With multiple ODUDs the first On a heavily loaded FDDI ring service opportunities occur ODUD should has the just First bit set (first) and the last less frequently than on an FDDI ring with only light traffic. ODUD should have the just Last bit set (last). Any interven- On a loaded network it makes sense to send multiple ing ODUDs should have both bits cleared (middle). frames per service opportunity. However, many network communication systems send only a single frame at a time. 5.5 Build the Request Descriptor This subsection tells how one may use the capabilities of A Request Descriptor must be constructed which refer- the BSI device to batch single frame requests into a larger ences the ODUD(s) that were just built. request object. The User Identification (UID) field may be assigned a host The BSI device will only attempt to send a single request defined value. This UID value will reemerge in one or more object in any given service opportunity. A request object is CNFs and may be useful when processing a CNF (i.e., de- defined here to consist of one or more REQ Descriptors allocating ODUD and buffer space). The SIZE field should delimited using the First and Last bits found inside each

5 descriptor. The BSI device interface software needs to build Interrupt Service Routine Logic (Optional) different types of REQ Descriptors when queuing a frame if OpenÐReq e TRUE such that: generate empty REQ.LAST # A single frame request object is generated when the OpenÐReq e FALSE queue is empty ReqÐSize e 0 # The resulting request object is limited to a maximum size endif # Optionally the resulting request object is closed whenev- QueueÐCnt is the number of queued request objects on er a service opportunity is detected. the request queue and is set to 0 queue initialization time. Req Size is the number of frames in the currently open The following pseudo-code may be used to satisfy the Ð request object and is set to 0 at queue initialization time. above requirements. OpenÐReq is a boolean variable indicating the presence or Transmit Logic absence of an open request object and is set to FALSE at queue initialization time. Max Req is a maximum number ReqÐSize e ReqÐSize a 1 Ð of frames per request object defined by the host software. if QueuedÐCnt e 0 mark as REQ.ONLY Please note that the BSI device will not hold the token un- OpenÐReq e FALSE necessarily when processing an open request object. It will QueuedÐCnt e 1 only hold the token when explicitly instructed to do so, via REQÐSize e 0 the RQCLS field in the Request Descriptor (REQ). else 6.0 RECEIVING FRAMES if OpenÐReq e FALSE mark as REQ.FIRST This section describes how to process incoming frames, using the BSI device’s data structures. It is assumed that the OpenÐReq e TRUE Indicate Mode Register (IMR), Indicate Threshold Register QueuedÐCnt e QueuedÐCnt a 1 (ITR), Indicate Configuration Register (ICR) and Indicate ReqÐSize e 1 else Header Length Register (IHLR) have been previously configured. It is also assumed that the host has already select- if ReqÐSize t MaxÐReq mark as REQ.LAST ed a particular Indicate Channel for processing; perhaps by examining the attention register hierarchy. OpenÐReq e FALSE ReqÐSize e 0 The host must maintain a minimum of two variables depict- else ing the state of the Indicate machine: current IDUD queue mark as REQ.MIDDLE pointer and the current buffer page address. To reduce ac- endif cesses to the BSI device Control Bus, the host software endif may wish to also keep its own copy of the channel’s Limit endif RAM Register. For a visual description of the Indicate machine, see Figures 2, 3, and 4.

TL/F/11088–2 FIGURE 2. BSI Device Indicate Memory Structure

6 TL/F/11088–3 FIGURE 3. BSI Device Indicate Memory Structure

TL/F/11088–4 FIGURE 4. BSI Device Indicate Memory Structure Figures 2 through 4 describe the operation of an Indicate Channel when receiving two frames. Key for Figures 2–4 PQPI ÐPSP Queue Pointer IQLI ÐIDUD Queue Limit .O ÐOnly PQLI ÐPSP Queue Limit IPI ÐIDU Pointer .F ÐFirst IQPI ÐIDUD Queue Pointer NPI ÐNext PSP Pointer .L ÐLast

7 6.1 Disable Interrupts for the Indicate Channel 6.4 Process the Frame Data Host manipulation of BSI device queues must be atomic; The Location (IDUD.LOC) and Byte Count (IDUD.CNT) meaning, in this context, that only a single host agent (pro- fields in each IDUD describe the address and length of each cess, task, thread, etc.) may actively dequeue frames from a Indicate Data Unit (IDU). There may be multiple IDUDs in a given Indicate Channel at a given time. In support of atomic- given Indicate object. The frame data referenced by these ity, four different granularities of interrupt masking may be IDUDs must be logically concatenated to construct a single achieved: host level, BSI device level, Indicate service level frame. The method of presenting frame data to upper level or Indicate Channel level. To mask interrupts at the Indicate software is highly host dependent. Channel level, modify the Indicate Notify Register (INR) to 6.5 Reclaim Data Buffer Space clear the breakpoint and exception bits for the target channel. A 4 kbyte data page is available for reuse when the BSI device has filled it with IDUs and the host has finished pro- 6.2 Collect an Indicate Object cessing all the IDUs on the page. The BSI device is guaran- Indicate objects may be represented by one or more IDU teed to consume space on a channel’s PSP queue in a Descriptors (IDUDs) on the given channel’s IDUD queue. serial manner; thus it is possible to tell when the BSI device The host must maintain a queue pointer for the next queue has finished using a page by detecting when the device position. When collecting an Indicate object the host should starts filling a new page. When the host is also done pro- scan forward from this position until an entire Indicate object cessing all of the IDUs on the given page that data space has been found. If a null descriptor is found in the first posi- may be reused. See Section 4 on Memory Management tion, there are no Indicate objects on the queue. The begin- Schemes for ideas on managing buffer space for the BSI ning of an Indicate object is marked by an IDUD with the device. ‘‘First’’ bit set and, conversely, the end is marked by an 6.6 Update IDUD Queue Pointers IDUD with the ‘‘Last’’ bit set. An IDUD with both of these bits set (‘‘Only’’) completely describes an incoming frame. After extracting all of the needed data from an Indicate Note that it is the responsibility of the host to nullify descrip- Channel, that channel’s IDUD queue may be updated to tors after processing the frame. allow reuse of queue space. Three operations should be performed: 6.3 Determine Acceptability of the Frame # Mark the processed IDU Descriptors (IDUDs) as null de- There are three fields defined in the IDU Descriptor (IDUD) scriptors. A safe method is overlaying the eight byte that are of use in determining the acceptability of a given queue slot with binary zeros. frame. These fields are valid in the last IDUD in the Indicate # Update the host resident current IDUD queue pointer to object. point beyond the processed IDUDs. The Frame Status field may be examined to determine valid- # Update the Limit RAM Register for the given channel. If ity of the data length and FDDI FCS fields; as well as the this value is maintained by the host, the value may be values of the E, A, and C Indicators in the FDDI Frame incremented and stored in the channel’s Limit RAM Reg- Status field. ister; otherwise it is necessary to read the register first. The Frame Attribute field can be queried to determine how The Limit RAM Operation (LMOP) is described above in the frame was recognized (MFLAG, AFLAG) and what the Section 2.12. terminating condition was. 6.7 Enable Interrupts for the Indicate Channel The Indicate Status field contains encoded status information (See Table IV). Now that the given channel’s queues have been updated, interrupts may be enabled again. If interrupts were masked TABLE IV. Indicate Status Codes at the Indicate Channel level, the Indicate Notify Register Code Status (INR) should be modified to set the breakpoint and exception bits for the target channel. 0x0 Last IDUD of Queue, Page Cross 0x1 Page Cross 7.0 QUEUE MANIPULATION 0x2 Header End The BSI device has two basic classes of queues: those that 0x3 Page Cross and Header End it uses to consume descriptors (REQ, PSP) and those that it uses to produce descriptors (IDUD, CNF). Conversely, the 0x4 Intermediate Frame host software must consume descriptors (IDUD, CNF) and 0x5 Burst Boundary produce descriptors (REQ, PSP) on the opposite queues. 0x6 Threshold For Request Channel operation the BSI device reads from 0x7 Service Opportunity the channel’s Request Descriptor (REQ) queue and writes to the channel’s Confirmation Message (CNF) queue. For 0x8 Insufficient Data Space Indicate Channel operation the BSI device reads from the 0x9 Insufficient Header Space channel’s Pool Space (PSP) queue and writes to the chan- 0xa Successful Header Copy, No Info Copy nel’s Indicate Data Unit Descriptor (IDUD) queue. 0xb No Info Space It is necessary to understand how the BSI device interacts 0xc FIFO Overrun with each type of queue so that one may design host soft- 0xd Bad Frame ware that interacts with the queues in a complementary fashion. When writing software that interfaces with the BSI 0xe Parity Error device, one minimally needs to understand the following: 0xf Internal Error # How the queues are organized # How to initialize each type of queue

8 # How to handle queue ‘‘wraps’’ # Each active Indicate Channel should have at least two # How to detect boundary conditions (empty queue, full buffers placed on its PSP queue. With only one buffer, queue) the BSI device will immediately raise the Low Data Space attention bit for that channel. 7.1 Queue Organization The host software must maintain its own pointer and limit A BSI device queue consists of a contiguous block of BSI variables for each queue. For REQ and PSP queues, the device addressable memory logically sub-divided into eight limit variable should reference the next available queue slot byte queue slots. Queues sized at 1 kbytes must be aligned for writing a new descriptor; while the pointer variable on 1 kbyte boundaries, while queues sized at 4 kbytes must should correspond to the pointer variable on BSI device. For be aligned on 4 kbytes boundaries. CNF and IDUD queues, the software pointer should refer- The BSI device embodies two indexing variables for each ence the next queue slot to be used when reading a new queue: a pointer to the next available queue position to descriptor. The software limit variable must always reflect read or write (stored in BSI device Pointer RAM) and a the limit variable on the BSI device. The software pointer queue limit (stored in BSI device Limit RAM). The BSI de- variable must be maintained independently from the BSI device increments the pointer variable after reading from a vice queue pointer. queue or writing to a queue. The host software may control 7.2 Queue Initialization channel operation by manipulating the value of the limit variable. With this in mind there are a few simple rules govern- To initialize queues that the BSI device reads (REQ, PSP) ing queue manipulation by the BSI device. simply set the pointer (BSI device and software versions) and software limit to reference the first queue slot. Do not 1. Pointer and limit variables reference a given queue slot by update the queue’s Limit RAM Register until actually queu- pointing to the first word of the descriptor. ing the queue’s first descriptor. 2. The pointer variable always points to the next available To initialize queues that the BSI device writes (IDUD, CNF) position on the queue. one must set the limit variable to reference the penultimate 3. The BSI device always increments the pointer variable available queue slot (required due to pipelining). For exam- after a read or write operation. ple, to make all but one of the queue slots available one 4. The BSI device halts channel processing when the point- could set the pointer variable to reference the first queue er and limit variables are logically equal. slot and the limit variable to reference the ‘‘next to the next 5. The BSI device tests for pointer/limit equality during to the last’’ queue slot. Also, one should clear the queue queue read operations (REQ, PSP) and after queue write area by overwriting it with binary zeroes; effectively marking operations (IDUD, CNF). When detecting pointer/limit all queue slots as ‘‘null descriptors’’. equality during a read operation, the current read opera- See Figure 5 for a pictorial description of initialized queues. tion and no further read operations are made. 7.3 Queue ‘‘Wraps’’ 6. Read operations are triggered by Limit RAM updates. Upon reaching the end of the queue memory block, queue There are also some special considerations caused by the indexing variables ‘‘wrap’’ to the beginning of the queue pipelined processing of CNF, IDUD and PSP Descriptors. memory block. The BSI device automatically performs # The BSI device may generate two additional CNF/IDUD queue ‘‘wraps’’ for pointer variables; while the host software Descriptors after detecting pointer/limit equality. It is must perform queue ‘‘wraps’’ for limit variables and soft- necessary to set the limit value such that it references ware queue pointers. The method for calculating the next the penultimate available queue slot.

TL/F/11088–5 FIGURE 5. Suggested Queue Initialization

9 AN-730 BSI Device Software Design Guide rlmtvral qaiy sntdaoe hsts sdone operations. is write test after and this operations above, read noted point- during for As testing reading) equality. by (when variable writing) er/limit empty (when conditions queue full both queue and detects device BSI The Conditions Boundary Detecting 7.4 oiceettevral seiidwt oeusing code C with new (specified addressable variable queues). method device kbyte following the 4 BSI the use increment into might to pointer software host a the memory variable as limit one the maintained offset example, When queue is arithmetic. For a modulo ). as simple use . variable ad- . could limit . device the offset, BSI representing byte repre- (i.e., when queue data uses pointers, of software form host dressable the the upon that dependent sentation is position queue ainlde o sueayrsosblt o s faycrutydsrbd ocrutptn iessaeipidadNtoa eevstergta n iewtotntc ocag adcrutyadspecifications. and circuitry said change to notice without time any at right the reserves National and implied are licenses patent circuit no described, circuitry any of use for responsibility any assume not does National .Lf upr eie rssesaedvcso .Aciia opnn saycmoeto life a of component any is component critical A 2. or devices are systems NATIONAL or OF SUPPORT PRESIDENT devices LIFE THE support IN OF COMPONENTS APPROVAL Life WRITTEN CRITICAL 1. EXPRESS AS herein: used THE USE As WITHOUT FOR CORPORATION. SEMICONDUCTOR SYSTEMS AUTHORIZED OR NOT DEVICES ARE PRODUCTS NATIONAL’S POLICY SUPPORT LIFE alr oprom hnpoel sdi codnespotdvc rsse,o oafc t aeyor safety its affect to life or the of system, effectiveness. failure or can the perform cause device to to failure support expected whose reasonably injury system be significant or can a device labeling, in support user. result the the to to in accordance expected provided in reasonably use whose be used for and properly life, instructions implant when sustain with or surgical perform, support to for (b) failure or intended body, are the into (a) which, systems e oprto mHJpnLd ogKn t.D rzlLd.(utai)Py Ltd. Pty, (Australia) Park Business Monash Australia 3168 Victoria Melbourne Nottinghill, Ltda. Brazil Do 212-5066 (55-11) Tel: Paulo-SP Sao 05418-000 Brazil Ltd. Kong Hong 2737-1600 (852) Tel: Kowloon Tsimshatsui, 16 Building Franco Lacorda Ltd. Deputado Japan Rue Kong Hong Chiba-City, Mihama-Ku Nakase, 1-7-1, Semiconductor National 7F Bldg. Block, Straight Floor, 13th Semiconductores National 527649 Telex: 35-0 F (81-41) D-82256 Tel: Chemical Sumitomo GmbH Semiconductor National 339-9240 Germany (910) TWX: 272-9959 Semiconductor 10 1(800) National Livry-Gargan-Str. 95052-8090 Tel: CA Clara, Santa 58090 Semiconductor Box National P.O. Drive Semiconductor 2900 Corporation Semiconductor National ((old a ) 0xfff) 8)& a od&0x0ffff000) & (old a:(14)3- iaPeetr 6 a:(5)23-90Tlx 9-113 SRB e:()558-9999 (3) Tel: BR NSBR 391-1131931 Telex: 2736-9960 (852) Fax: 261 Prefecture Ciba 35-1 (81-41) Fax: rtnedrc niern etrOenCnr,5Cno d 2-ABsns akDrive Park Business 120-3A Rd. Canton 5 Centre, Ocean Center Engineering 4urstenfeldbruck IUE6 uu onayConditions Boundary Queue 6. FIGURE e:(4)2920 a:(51)2218 a:()558-9998 (3) Fax: 212-1181 (55-11) Fax: 299-2500 (043) Fax: 299-2300 (043) Tel: uu onayconditions. boundary queue ‘rp’ utb ae noacuti h uu variable queue Queue See the in variable. account pointer into arithmetic. taken software limit be the software must ‘‘wraps’’ the by the ‘‘before’’ when referenced immediately full slot slot queue considered the references be pointer using writing, may When condition device. queue full BSI the a queue as a mechanism basic detect same the can software host descrip- The recommended). ‘‘null available a are as are zeroes slot slots (binary queue queue tion’’ available the each limit mark of the must queue all and set that the never indicate demarcate must to to software variable host descriptor’’ always the will ‘‘null ‘‘null condition; there one a empty that least of ensure at presence To be queue. the the recognize on Instead may descriptor’’ variables. software limit host and pointer the the condition comparing empty by mined queue a reading, When iue6 Figure o rpia ersnaino h various the of representation graphical a for cannot TL/F/11088–6 edeter- be IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are sold subject to TI’s terms and conditions of sale supplied at the time of order acknowledgment. TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI’s standard warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where mandated by government requirements, testing of all parameters of each product is not necessarily performed. TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and applications using TI components. To minimize the risks associated with customer products and applications, customers should provide adequate design and operating safeguards. TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information published by TI regarding third-party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. Reproduction of TI information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for such altered documentation. Information of third parties may be subject to additional restrictions. Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. TI products are not authorized for use in safety-critical applications (such as life support) where a failure of the TI product would reasonably be expected to cause severe personal injury or death, unless officers of the parties have executed an agreement specifically governing such use. Buyers represent that they have all necessary expertise in the safety and regulatory ramifications of their applications, and acknowledge and agree that they are solely responsible for all legal, regulatory and safety-related requirements concerning their products and any use of TI products in such safety-critical applications, notwithstanding any applications-related information or support that may be provided by TI. Further, Buyers must fully indemnify TI and its representatives against any damages arising out of the use of TI products in such safety-critical applications. TI products are neither designed nor intended for use in military/aerospace applications or environments unless the TI products are specifically designated by TI as military-grade or "enhanced plastic." Only products designated by TI as military-grade meet military specifications. Buyers acknowledge and agree that any such use of TI products which TI has not designated as military-grade is solely at the Buyer's risk, and that they are solely responsible for compliance with all legal and regulatory requirements in connection with such use. TI products are neither designed nor intended for use in automotive applications or environments unless the specific TI products are designated by TI as compliant with ISO/TS 16949 requirements. Buyers acknowledge and agree that, if they use any non-designated products in automotive applications, TI will not be responsible for any failure to meet such requirements. Following are URLs where you can obtain information on other Texas Instruments products and application solutions: Products Applications Audio www.ti.com/audio Communications and Telecom www.ti.com/communications Amplifiers amplifier.ti.com Computers and Peripherals www.ti.com/computers Data Converters dataconverter.ti.com Consumer Electronics www.ti.com/consumer-apps DLP® Products www.dlp.com Energy and Lighting www.ti.com/energy DSP dsp.ti.com Industrial www.ti.com/industrial Clocks and Timers www.ti.com/clocks Medical www.ti.com/medical Interface interface.ti.com Security www.ti.com/security Logic logic.ti.com Space, Avionics and Defense www.ti.com/space-avionics-defense Power Mgmt power.ti.com Transportation and Automotive www.ti.com/automotive Microcontrollers microcontroller.ti.com Video and Imaging www.ti.com/video RFID www.ti-rfid.com OMAP Mobile Processors www.ti.com/omap Wireless Connectivity www.ti.com/wirelessconnectivity TI E2E Community Home Page e2e.ti.com