february 14, 2000 3-1 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 features supports 4000x, spartan, virtex , virtex -e, and spartan -ii devices. conforms to international standard iso/iec 3309 speci?ation starting 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 alliancecore facts core speci?s see table 1 provided with core documentation user? guide design file formats verilog source rtl 1 constraint files hdlc.ucf verification verilog testbench, test vectors instatiation templates vhdl, verilog reference designs and application notes application note additional items none simulation tool used silos iii support support provided by memec design services notes: 1. synplify 5.08a used for synthesis table 1: core implementation data supported family device tested clbs 2 clock iobs iobs 1 performance 3 (mhz) xilinx tools special features core core+ ext logic core core+ ext logic spartan-ii 2s15-5 183 2 183 2 2 32 32 77 m2.1i none virtex-e v50e-6 183 2 183 2 2 32 32 90 m2.1i none virtex v50-4 183 2 183 2 2 32 32 79 m2.1i none spartan s10-4 127 127 2 32 32 53 m1.5i none 4000x 4005xl-2 134 134 2 32 32 57 m1.5i 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 product speci?ation single-channel XF-HDLC controller
single-channel XF-HDLC controller 3-2 february 14, 2000 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: star- tup, startbuf, bscan, readback, global buffers, fast output primitives, iob elements, clock delay compo- nents, and any of the oscillator macros. mds cores contain resources present in only the clb array. this is done to allow ?xibility 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-con- tained. 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 trans- mit when the user s external logic asserts the tx_data_valid signal. the transmitter will respond by asserting the tx_load signal to load the ?st byte of the packet. the timing diagram assumes that idle_sel is tied to a ? and the transmitter is generating continuous ? bits between frames. if idle_sel is set to a ?? 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 ?g (7e). imme- diately after the ?g is sent, the ?st 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 con- tinue to request data by asserting tx_load until the user x9011 i pad external logic external logic XF-HDLC core i pad i pad i pad rxc reset idle_sel tx_data [7:0] o pad rx_data [7:0] txd o pad tx_load o pad tx_underrun o pad rx_status o pad tx_data_valid tx_eof i pad txc i pad rxd i pad fcs16_32 i pad rx_sof o pad rx_ready o pad rx_eof o pad 8-bit parallel to serial shift register zero insertion flag and abort generation 16/32-bit fcs generator 16/32-bit fcs checker 8-bit serial to parallel shift register and status zero detection transmit control receive control flag and abort detection bufg i pad rx_space_avail gsr startup > > receiver transmitter tx_ce i pad bufg i pad i pad i pad rx_ce i pad figure 1: hdlc controller block diagram
february 14, 2000 3-3 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 ag (7e) byte is appended to mark the end of the frame. hdlc transmitter consists of the following blocks as shown in fig- ure 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 gen- erator 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 dif- ferent polynomials can be selected by statically controlling the fcs16_32 pin. the 16-bit fcs uses the polynomial x 16 + x 12 + x 5 + 1 and is selected when the fcs16_32 pin is a logic low. the 32-bit fcs uses the polynomial x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + 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 con- tent between the opening and closing ags and checking for 5 consecutive 1 bits, including the fcs bits. if 5 con- secutive 1 bits are detected, a 0 bit is inserted into the serial transmission. this will allow the receiver to distin- guish between an opening or closing ag and actual data. flag and abort generation an opening ag 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 ag is sent. if a trans- mission 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 reported with the tx_underrun pin, but will also result in the transmitter sending 8 consecutive 1 bits. this is de ned as an "abort" condition. the transmitter will inter-frame ll by driving out a contigu- ous stream of 1 bits or a repeating ag. if back-to-back frames are available to send (the user continues to assert tx_data_valid), the transmitter will share the closing ag of the rst frame with the opening ag of the second frame. serial output all data exits the transmitter on the txd pin and transitions on the rising edge of txc. 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 ag is recognized, the receiver locks to all subsequent octet bytes. the user informs the receiver of the ability to store the frame by asserting 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 begin- ning of the frame by asserting the rx_sof signal. bytes will continue being passed to the user until the receiver rec- ognizes the closing ag. 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 pass- ing 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. flag and abort detection the receiver begins operation by hunting for an opening ag character. once the ag has been recognized. the receiver begins to receive the incoming frame, but contin- ues to monitor for a closing ag. once the closing ag has been detected, the frame is complete. once the receiver has detected an opening ag, it will monitor the serial data stream to see if 8 consecutive 1 bits are detected. this condition is de ned as a receive abort and is reported to the user through a receive status bit. the receiver is capa- ble of handling back-to-back frames where the closing ag of the rst frame also acts as the opening ag of the second frame. the receiver will idle on either contiguous 1 bits or repeating ag characters. 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. 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 eld. the result of this polynomial division will be a constant remainder indicating the packet integrity. the receiver sup-
single-channel XF-HDLC controller 3-4 february 14, 2000 ports the same 16-bit and 32-bit fcs as the transmitter. the version is statically selected using the fcs16_32 pin, the 16-bit version is selected by a logic low and the 32-bit version is selected with a logic high. 8-bit serial shift register as serial data is clocked into the receiver, it is assembled back into bytes through a serial-to-parallel shift register. the receiver informs the user of a valid byte by asserting the rx_ready signal. rx_ready can be further quali ed with additional signals to help the user track the progress of an incoming frame. rx_sof is asserted coincident with rx_ready to indicate reception of the rst octet of a frame. rx_eof is asserted coincident with rx_ready to indicate the last byte of the receive fcs. the rx_status signal is asserted coincident with rx_ready to indicate to the user that the receive data contains a valid byte of status information. status byte the status byte will be presented to the user at the end of the frame or after a receive error is detected. the receiver will inform the user of valid status on the rx_data bus by the coincident assertion of rx_ready and rx_status. the fcs error will be set at the end of the frame if the remainder after polynomial division does not match the proper 16-bit or 32-bit constant. the frame error status bit will be set if a frame is received that is shorter than 32 bits when using the 16-bit fcs, and shorter than 48 bits when using the 32-bit crc. there is no test to check for frame lengths that exceed a certain length. this bit will also be set when the octet error is set. the frame abort status bit will be set if the receiver has detected 8 consecutive 1 bits in a row after frame recep- tion has begun. the octet error status bit is set whenever the closing ag is received on an odd bit boundary. the receiver tests to make sure all frames are an integral number of octets. all remaining status bits are reserved and will be presented as 0 . receive control the control state machines and interface timing for the receiver is driven by the rising edge of rxc. core modi cations customizing is available through memec design services. pinout the pinout of the single-channel XF-HDLC controller core has not been xed to speci c fpga i/o, allowing exibility with a user s application. signal names are provided in table 2. veri cation methods complete functional and timing simulation has been per- formed on the hdlc using silo iii. simulation vectors are provided with the core. the hdlc core has been hardware tested with ttc fireberd 6000a frame relay option. this core has also been used successfully in customer designs. ordering information the single channel XF-HDLC controller core is provided under license from memec design services for use in xilinx programmable logic devices and xilinx hardwire gate arrays. please contact memec for pricing and more infor- mation. information furnished by memec design services is believed to be accurate and reliable. memec design ser- vices reserves the right to change speci cations detailed in this data sheet at any time without notice, in order to improve reliability, function or design, and assumes no responsibility for any errors within this document. memec design services does not make any commitment to update this information. memec design services assumes no obligation to correct any errors contained herein or to advise any user of this text of any correction, if such be made, nor does the com- pany assume responsibility for the functioning of unde- scribed features or parameters. memec design services will not assume any liability for the accuracy or correctness of any support or assistance provided to a user. memec design services does not represent that products described herein are free from patent infringement or from any other third-party right. no license is granted by implica- tion or otherwise under any patent or patent rights of memec design services. memec design services products are not intended for use in life support appliances, devices, or systems. use of a memec design services product in such application with- out the written consent of the appropriate memec design services of cer is prohibited. all trademarks, registered trademarks, or service marks are property of their respec- tive owners. 76 5 4 3 2 1 0 fcs error frame error frame abort octet error overrun error reserved "0" x9012
february 14, 2000 3-5 table 2: core signal pinout signal signal direction description tx_data[7:0] input transmitter parallel data bus: 8-bit transmit data bus loaded synchronously based on tx_load signal and txc clock.this bus is driven by the user s transmit fifo or ram buffer. idle_sel input idle select: selects inter-frame idle fill type. when tied low, device sends con- tinuous flags between frames; when tied high, device sends continuous ones between frames. tx_data_valid input transmit data valid: active high user input, synchronous to txc, to inform transmitter that an external packet is ready to send. tx_eof input transmit end-of-frame: an active high user input pulse, synchronous with txc, to inform transmitter that current data byte is the last byte of a sending packet. this input should coincide with tx_load. txc input serial transmit clock: a user-provided clock for all transmit activity that takes place on the low to high transition of txc. tx_ce input transmit clock enable: an active high user input, synchronous with txc. rxd input serial receive data: an input for serial receive data, sampled on the rising edge of rxc. fcs16_32 input fcs select: selects 16-bit fcs, x 16 + x 12 + x 5 + 1, when tied low. selects 32- bit fcs, x 32 + x 26 + x 23 + x 22 + x 16 + x 12 + x 11 + x 10 + x 8 + x 7 + x 5 + x 4 + x 2 + x + 1, when tied high. rx_space_avail input receive space available: an active high user input, synchronous to rxc, to inform the receiver that external receive fifo or buffer ram can accept more data. rxc input serial receive clock: a user provided clock for all receive activity that takes place on low to high transition of rxc. rx_ce input receive clock enable: an active high user input, synchronous with rxc. reset input global reset: asynchronously resets all internal registers. txd output serial transmit data: provides serial transmit data and transitions on the rising edge of txc clock. tx_load output transmit load: an output pulse from transmitter, synchronous to txc, that acts as a clock enable signal to external transmit buffer to request an input byte. tx_underrun output transmit underrun: an active high output pulse, synchronous to txc, from the transmitter indicating an underrun error. this occurs upon start of frame trans- mission, if tx_data_valid is deasserted when tx_load is asserted. rx_data[7:0] output receive parallel data bus: 8-bit receive data bus providing user output data synchronous to rx_ready and rxc clock. this bus is tied to user s receive fifo or ram buffer and also reports frame status at the end of a receive. rx_ready output receive ready: an active high pulse from receiver, synchronous to rxc, that acts as a clock enable signal to external receive buffer to output a received byte. the status pin distinguishes receive data from frame status. rx_sof output receive start-of-frame: an active high pulse, synchronous to rxc, to inform user that current receive data byte is first byte of a frame. this pulse coincides with rx_ready pulse. rx_eof output receive end-of-frame: an active high pulse, synchronous to rxc, to inform the user that the current receive byte is the last byte (either 2 or 4) of the frame checking sequence. this pulse is coincident with the rx_ready pulse. rx_status output receive status: an active high pulse, synchronous to rxc, to inform the user that receive frame status is being output on the rx_data bus. rx_status is coincident with the rx_ready signal.
single-channel XF-HDLC controller 3-6 february 14, 2000 recommended design experience for the source version, users should be familiar with verilog hdl entry, synthesis, simulation, and xilinx design ows. related information iso/iec 3309 high-level data link control procedures- frame structure iso/iec 4335 high-level data link control procedures- elements of procedures iso/iec 8885 high-level data link control procedures general purpose xid frame information field content and format xilinx programmable logic for information on xilinx programmable logic or develop- ment system software, contact your local xilinx sales of ce, or: xilinx, inc. 2100 logic drive san jose, ca 95124 phone: +1 408-559-7778 fax: +1 408-559-7114 url: www.xilinx.com for general xilinx literature, contact: phone: +1 800-231-3386 (inside the us) +1 408-879-5017 (outside the us) e-mail: literature@xilinx.com for alliancecore speci c information, contact: phone: +1 408-879-5381 e-mail: alliancecore@xilinx.com
|
