Programmable Logic

On-Chip SRAM Aids ATM Design

FPGAs slice design cycles when standards change and new circuitry is necessary.

by John Tsimaras

It would be nice if standards were truly standard. Alas, it is not always so. Consider standards for asynchronous transfer mode (ATM) local and wide area networking (LAN/WAN) systems. They vary from country to country, and people continue to create new standards and occasionally make changes to existing ones. Such is the case with the recent European E3 34.368 Mbits per second transmission standard.

Until recently, the proposed way of mapping ATM cells to the E3 rate had been to use the physical layer convergence procedure (PLCP) format of mapping ATM cells onto the CCITT G.751 E3 frame. This method offers 9 ATM cells per 125-µs interval. A proposal for a different method of mapping ATM cells into E3 was recognized by the CCITT standards organization as Draft Recommendation G.7xx, in January, 1993. This mapping scheme allows 10 cells, versus 9, to fit into the same 125-µs interval.

Figure 1. Note that the FA1, FA2, EM, TR, NR, and GC are overhead octets.

Service providers (i.e. equipment buyers) naturally gravitated to the new proposal and put pressure on equipment vendors to meet these new standards, since it offered an 11 percent increase in bandwidth for the same cost. In this instance, there were no ready-made silicon solutions to help engineers design in the new circuitry to comply with this 10-cell E3 standard. Given that the ATM network systems business is highly competitive and time-to-market is critical, logic designers must meet short turnaround cycles. An ASIC could offer a cost-effective solution here, but the lengthy development interval suggests that it is an unacceptable option.

FPGAs with on-chip SRAM, on the other hand, provide a better and faster approach for designing in this new E3 transmission format. Devices available with on-chip SRAM include the Xilinx XC4000 series, Altera's FLEXlogic, and AT&T's ORCA.

A two-FPGA solution Two FPGAs are used in this design approach. One device is used to implement the E3 framer circuitry. It operates in a state machine fashion, providing status and receiving control from the other device.

The second chip, referred to as the OA&M (operations, administration, and maintenance) FPGA, serves as a gateway to allow the processor to control the E3 framer. It uses about 17 registers for control, status, interrupts, and a means for reading the received overhead bytes of the E3 frame or writing of the transmitted overhead bytes. It also exploits on-chip SRAM capability to implement a Trail trace (TR) capability (discussed below) that would otherwise consume excessive resources if a more conventional register-oriented approach were used.

Figure 1 shows the CCITT-recommendation G.832 framing for E3. This framer passes and accepts back-to-back ATM cells to and/or from the system. In the egress direction (out towards the facility), the E3 overhead information is added to the ATM cells, and in the ingress direction, the E3 overhead is stripped off, and HEC-delineated cells are passed to the system.

The E3 frame is composed of 537 bytes, or octets, 530 of which are payload with 7 overhead octets mixed in at regular intervals. As shown in the table, 2 are for framing alignment and one each for error monitoring, maintenance and adaptation, network operation, general purpose communications, and Trail trace. FPGA-based circuitry for the E3 frame operates in serial fashion. It conducts search and find functions to locate, compare, match, and decode signal patterns to establish the E3 frame. Once it does that, it works toward identifying each of the 7 overhead octets including the trail trace. The second FPGA is utilized as a controlling device or as a gateway for the microprocessor to control the E3 frame circuitry. The Trail trace octet is used to repetitively transmit a trail access point identifier so that a trail receiving terminal (endpoint) can verify its continued connection to the intended transmitter. The trail access point identifier uses the E.164 numbering format; hence, 16 E3 frames are necessary for transmitting the entire string which is considered static information once it is programmed.

Proper operation of the TR registers requires that the 16 octets be formatted as follows. The first octet, defined as the TR sequence frame start marker, has the most significant bit (MSB) set to 1 , with the remaining bits set to the CRC-7 calculation over the remaining octets. In the second to sixteenth octet, the MSB is set to 0 , while the other bits encode the ASCII character of the E.164 address string. The TR register sets function as: (1) transmitted, (2) expected, and (3) received TR, as in Figure 2. Data content of the transmitted TR registers, which can be read or updated, is encoded into the TR octet in the E3 frame header during transmission. Firmware programs these registers with a valid TR sequence including valid error-checking codes in the sequence according to E3 standard specs. As for the expected trail trace, the E3 framer FPGA extracts the TR octet when receiving E3 frames. Received values are compared with the content of this register set. If the comparison fails, data content of the received TR registers is frozen and the entire TR sequence causing the mismatch condition is held; however, an interrupt may be enabled for this event depending on interrupt register settings (another function of the OA&M FPGA). In this instance, the interrupt may be delayed until all 16 octets of the TR message are received. The receiver locates the first TR octet based on the MSB setting. If a synchronization problem occurs in locating the start of the frame sequence, a TR "out of frame" condition exists which may also generate an interrupt. A two-in-four-out algorithm, like the E3 framing one, determines the conditions for an in-and-out-of-frame. Under normal operating conditions, the received TR register set continuously captures the TR sequence encoded into the E3 frames. When the received TR sequence doesn't match the expected sequence, the actual sequence received is held in these registers. Further updates to these registers are suspended, enabling the firmware to retrieve the offending message. Once the firmware retrieves the message, the received TR register set is released from a held state by the processor.

ATM Header Defined

GFC: Generic Flow Control VPI: Virtual Path Identifier VCI: Virtual Channel Identifier PT: Payload Type CLP: Cell Loss Priority HEC: Header Error Check

An ATM cell is constructed of 53 octets, or bytes. The first 5 octets contain the header while the remaining 48 hold the information field. At the user-network interface, the header is divided into the generic flow control (GFC), the virtual path identifier (VPI), the virtual channel identifier (VCI), the payload type identifier (PTI), the cell lost priority (CLP), and the header error control (HEC).

The first 5 octets are used as follows: the GFC uses the 4 most significant bits of the first octet. The VPI uses the 4 least significant bits of the first octet and the 4 most significant bits of the second octet. The VCI uses the 4 least significant bits of the second octet, the third octet, and the 4 most significant bits of the fourth octet. The next 3 bits of the fourth octet are used by the PTI. The CLP uses the least significant bit on the fourth octet, and the fifth octet is used by the HEC.

The GFC may be used for traffic control within private networks, while the 24 bits containing VPI/VCI route a cell through a private or public ATM network. The PTI is used to indicate the cell user data type and management information. CLP allows the user or the network to set a cell's loss priority. This bit is also set for cells that the network might discard. Finally, HEC is used by the ATM physical layer for cell delineation. It is also used for detection and correction of bit errors in the cell header.

Figure 2. The processor can write or read RAM, but the hardware can only read RAM.

Transmitted, Expected, Received TR Each of the following circuits to be described utilizes a 16 x 8 RAM. Figure 3 shows transmitted TR circuitry with the 16 octet TR message in a on-chip RAM. Output is either to the tri-state buffers and on to the microprocessor data bus or to the framer for parallel to serial conversion. The microprocessor in this instance can read or write to RAM, thereby allowing it access to RAM to determine which specific TR message is to be transmitted by the framer. As the framer FPGA is ready to transmit a byte of the Trail trace message into the E3 frame, circuitry reads the RAM, one byte at a time, and passes it on to the framer. The 2:1 MUX multiplexes addresses from either the microprocessor or from the 4-bit counter. Control arbitration resolves any contention between the microprocessor and the circuitry mentioned above when RAM is accessed. In this case, the microprocessor is more forgiving than in other designs. For example, if the hardware is accessing the RAM, the microprocessor goes into a wait mode.

Figure 3. The processor can only read RAM, while the hardware can only write RAM.

In this application, the control arbitration is designed so that any time contention occurs between the microprocessor and the hardware, the hardware always gets first access. Inputs to the control arbitration block include: microprocessor access request, microprocessor read/write, and framer access. In effect, the framer access signal commands exclusive use of the circuitry so that even if the microprocessor attempts access while the signal is active, it is held off.

Figure 4. The processor can read or write RAM, while hardware can only read RAM.

Control arbitration output signals are select (SE) going to the 2:1 MUX; write strobe (WS) to the RAM; and output enable (OE) to the tri-state buffers. SE lets the 2:1 MUX know whether the microprocessor or the hardware wins arbitration to determine if the microprocessor or the hardware addresses the RAM. Both WS and OE are generated separately only when the microprocessor requests RAM and it gains access through a read or write. A special message recovery counter (MRC) supports both the received and expected TR circuitry (Figures 3 and 4). The recovery mechanism is comprised of about 15 logic blocks used to implement a state machine to lock in and synchronize to the Trail trace message. It keys off the MSB of each byte. Once synchronization is established, a 4-bit counter (one programmable logic block) is used to point to each byte in the received (or expected) Trail trace Message.

As TR octets enter the receiver at initialization, the receiver circuitry needs to identify where the 16 octet message begins. The MSB of every octet in the TR message is used for this purpose. As mentioned earlier, the MSB is 1 in the first octet with 0 being the MSB in the remaining 15 octets.

Therefore, the MRC searches for that particular 1 , finds and locks it as the beginning of the frame, and initializes the receive counter to 0 . Then, every other octet entering it increments the counter, and once per frame, the MRC performs verification.

Received and expected TR circuitry are similar to transmitted TR circuitry with a few exceptions. In received TR, only the microprocessor can read to RAM, while hardware can only write to RAM, as overhead octets are input into the RAM from the framer. In expected TR circuitry, the microprocessor can either read or write to RAM, however, the hardware can only read the RAM.

The on-chip RAM supporting the expected TR has outputs to the tri-state buffers and to a comparator circuit. The simple 8-bit comparator compares each received message byte to the corresponding byte of the expected message. The comparator and the associated circuitry around it is about 3 logic blocks.

In this instance, an octet coming out of expected TR RAM is compared on a bit-by-bit basis with one of the same octet number from the received TR circuit. For example, octet number 3 is written in memory location 3 in received TR RAM. Simultaneously, memory location 3 is read out of expected TR RAM, and both data are sent to the comparator to perform octet matching. However, if there is a mismatch, the error is flagged to the software.

FPGAs aid compliance In today's rapidly evolving communications marketplace, a vendor's product is often judged by its adherence to the latest international standards. The fluid state of these standards, however, presents a challenge to an equipment manufacturer of providing the best compromise between a timely product availability on one hand, and support of the most recent standards on the other. The design flexibility and relative short development intervals that FPGAs offer present a superior solution to the design standards compliance problem.

John Tsimaras is a member of the technical staff, AT&T Platform Division, Red Bank, N.J.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to michael@asic.com.

integrated system design  December/January 1995