|
Details, datasheet, quote on part number:XF-HDLC
| |
| Part: | XF-HDLC |
| Category: | FPGAs/PLDs => FPGA (Field Programmable Gate Array) => FPGA/PLD Soft Core |
| Description: | Single Channel Xf-hdlc Controller |
| Company: | Xilinx Corp. |
| Datasheet: | Download XF-HDLC datasheet File size : 87 kB |
| Request For quote: | Find where to buy XF-HDLC
|
| |
Datasheet text preview:
Single-Channel XF-HDLC Controller
February 14, 2000 Product Specification
AllianceCORE
TM
Facts
Core Specifics See Table 1 Provided with Core 7810 South Hardy Drive, Suite 104 Tempe, Arizona 85284 USA Phone: +1 888-845-5585 (USA) +1 480-753-5585 Fax: +1 480-753-5899 E-mail: info@memecdesign.com URL: www.memecdesign.com Documentation User's guide Design File Formats Verilog source RTL1 Constraint Files hdlc.ucf Verification Verilog Testbench, test vectors Instatiation Templates VHDL, Verilog Reference Designs Application Note and Application Notes Additional Items None Simulation Tool Used Silos III Support Support provided by Memec Design Services
Notes: 1. Synplify 5.08A used for synthesis
Features
· Suppor ts 4000X, Spartan, VirtexTM, VirtexTM-E, and SpartanTM-II devices. · Conforms to International Standard ISO/IEC 3309 Specification · Star ting point for a custom design · 16-bit/32-bit CCITT-CRC generation and checking · Flag & Zero insertion and detection · Full Duplex Operation allowed · DC to 53 Mbps (STS-1) data rate · Full synchronous operation · Interface can be customized for user FIFO and DMA requirements
Applications
· Frame Relay, ISDN and X.25 protocols · Logic consolidation
Table 1: Core Implementation Data CLBs2 Core+ Core Ext logic 1832 1832 2 183 1832 2 183 1832 127 127 134 134 Clock IOBs 2 2 2 2 2 IOBs1 Core+ Core Ext logic 32 32 32 32 32 32 32 32 32 32 Performance3 (MHz) 77 90 79 53 57
Supported Family Spartan-II Virtex-E Virtex Spartan 4000X
Device Tested 2S15-5 V50E-6 V50-4 S10-4 4005XL-2
Xilinx Tools M2.1i M2.1i M2.1i M1.5i M1.5i
Special Features None None None None None
Notes: 1. Assuming all core I/Os are routed off-chip. 2. Utilization numbers for Virtex, Virtex-E, and Spartan-II, are in CLB slices. 3. Minimum guaranteed speed
February 14, 2000
3-1
Single-Channel XF-HDLC Controller
External Logic XF-HDLC CORE
Transmitter TX_DATA [7:0]
I Pad 8-bit Parallel to Serial Shift Register 16/32-bit FCS Generator Flag and Abor t Generation
External Logic
Zero Inser tion
TXD
O Pad
IDLE_SEL
I Pad
TX_DATA_VALID
I Pad I IPad Pad
TX_LOAD
TX_EOF TXC
O Pad
I Pad I Pad
BUFG
>
Flag and Abor t Detection
Transmit Control
TX_UNDERRUN
O Pad
TX_CE RXD
I Pad
Zero Detection
16/32-bit FCS Checker
8-bit Serial to Parallel Shift Register and Status
RX_DATA [7:0]
O Pad
FCS16_32
I Pad I Pad
RX_SPACE_AVAIL RXC
BUFG
RX_READY RX_SOF
O Pad O Pad O Pad O Pad
I Pad I IPad Pad I Pad
>
RX_CE
Receive Control
RX_EOF RX_STATUS
GSR STARTUP
RESET
Receiver
X9011
Figure 1: HDLC Controller Block Diagram
General Description
The XF-HDLC performs the most common functions of an HDLC controller. Data bytes are clocked into the device based on a divided version of the transmit clock. This data is then serialized and framed according to the rules of HDLC and sent out the serial transmit data pin. Receive frames are clocked into the receive data pin synchronous to the receive clock. The framing overhead is then stripped off and the data bytes are converted from serial to parallel and passed on through the parallel receive bus. Figure 1 shows the block diagram. MDS cores are designed with the philosophy that no global elements should be embedded within the core itself. Global elements include any of the following components: STARTUP, STARTBUF, BSCAN, READBACK, Global Buffers, Fast Output Primitives, IOB Elements, Clock Delay Components, and any of the Oscillator Macros. MDS cores contain resources present in only the CLB array. This is done to allow flexibility in using the cores with other logic. For instance, if a global clock buffer is embedded within the core, but some external logic also requires that same clock, then an additional global buffer would have to be used. In any instance, where one of our cores generates a clock, that signal is brought out of the core, run through a global buffer, and then brought back into the core. This philosophy
allows external logic to use that clock without using another global buffer. A result of this philosophy is that the cores are not self-contained. External logic must be connected to the core in order to complete it. MDS cores include tested sample designs that add the external logic required to complete the functionality. This datasheet describes both the core and the supplied external logic.
Functional Description
Transmitter
The transmitter portion of the HDLC core will begin to transmit when the user's external logic asserts the TX_DATA_VALID signal. The transmitter will respond by asser ting the TX_LOAD signal to load the first byte of the packet. The timing diagram assumes that IDLE_SEL is tied to a `1' and the transmitter is generating continuous `1' bits between frames. If IDLE_SEL is set to a `0', the number of clocks from the assertion of TX_DATA_VALID to TX_LOAD will vary from 5 to 12. Before the transmitter can begin to send data serially, it must send an opening flag (7E). Immediately after the flag is sent, the first byte is clocked out of the input shift register. Once a transmit frame has begun, the user is required to make sure that data is available for each subsequent requested byte. The transmitter will continue to request data by asserting TX_LOAD until the user February 14, 2000
3-2
supplies a TX_EOF signal. This informs the transmitter that the last byte is on the data bus. The transmitter then appends a 16- or 32-bit Frame Checking Sequence (FCS) to the transmitted data. After the FCS is sent, a closing flag (7E) byte is appended to mark the end of the frame. HDLC Transmitter consists of the following blocks as shown in Figure 1.
Transmit Control
The control state machines and interface timing for the transmitter are driven by the rising edge of TXC.
Receiver
The receiver clocks serial HDLC frames in continuously through the RXD pin. When an opening flag is recognized, the receiver locks to all subsequent octet bytes. The user informs the receiver of the ability to store the frame by asser ting the RX_SPACE_AVAILABLE input. The receiver informs the user that a data byte is available by asserting the RX_READY signal. The receiver indicates the beginning of the frame by asserting the RX_SOF signal. Bytes will continue being passed to the user until the receiver recognizes the closing flag. At this point, the last byte of the FCS sequence will be passed to the user coincident with the RX_EOF signal. It must be stressed that the core does not contain the additional pipeline registers to "swallow" the 2 or 4 bytes of FCS, and these will therefore be passed on to the user. If this is undesirable, the corresponding pipeline should be added externally to keep these bytes from passing on as part of the received frame. After the reception of the frame has completed, the receiver will pass a byte of status information to the user by placing the status on the receive data bus and asserting the RX_STATUS signal. The Receiver consists of the following blocks as shown in Figure 1.
8-bit Parallel-to-Serial Shift Register
This block is responsible for capturing the user's transmit data on the rising edge to TXC when the TX_LOAD signal is asserted. Data is sent to the TXD pin and the FCS Generator at the same time.
16/32-bit FCS Generator
The Frame Checking Sequence (FCS) Generator is used to calculate a CRC across the transmitted message. Two different polynomials can be selected by statically controlling the FCS16_32 pin. The 16-bit FCS uses the polynomial x16 + x12 + x5 + 1 and is selected when the FCS16_32 pin is a logic LOW. The 32-bit FCS uses the polynomial x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 and is selected when the FCS16_32 pin is a logic HIGH. Either type of FCS is complemented before being transmitted.
Zero Insertion
The transmitter is responsible for examining the frame content between the opening and closing flags and checking for 5 consecutive `1' bits, including the FCS bits. If 5 consecutive `1' bits are detected, a `0' bit is inserted into the serial transmission. This will allow the receiver to distinguish between an opening or closing flag and actual data.
Flag and Abort Detection
The receiver begins operation by hunting for an opening flag character. Once the flag has been recognized. the receiver begins to receive the incoming frame, but continues to monitor for a closing flag. Once the closing flag has been detected, the frame is complete. Once the receiver has detected an opening flag, it will monitor the serial data stream to see if 8 consecutive `1' bits are detected. This condition is defined as a receive abort and is reported to the user through a receive status bit. The receiver is capable of handling back-to-back frames where the closing flag of the first frame also acts as the opening flag of the second frame. The receiver will idle on either contiguous `1' bits or repeating flag characters.
Flag and Abort Generation
An opening flag is sent when the user asserts the TX_DATA_VALID signal. As soon as the last byte of the FCS has been transmitted, a closing flag is sent. If a transmission has been started and the TX_DATA_VALID signal is deasserted while the transmitter is requesting another byte, an underrun condition will occur. This condition will be repor ted with the TX_UNDERRUN pin, but will also result in the transmitter sending 8 consecutive `1' bits. This is defined as an "abort" condition. The transmitter will inter-frame fill by driving out a contiguous stream of `1' bits or a repeating flag. If back-to-back frames are available to send (the user continues to assert TX_DATA_VALID), the transmitter will share the closing flag of the first frame with the opening flag of the second frame.
Zero Detection
The receiver checks the incoming data frame to see if 5 consecutive `1' bits are received. If this condition is detected, the following zero is deleted from the incoming frame.
Serial Output
All data exits the transmitter on the TXD pin and transitions on the rising edge of TXC.
16/32-bit FCS Check
The Frame Checking Sequence (FCS) Checker performs the same generator polynomial division as the transmitter across the entire transmitted message including the FCS field. The result of this polynomial division will be a constant remainder indicating the packet integrity. The receiver sup-
February 14, 2000
3-3
|
|
