CPLD Applications Handbook

Xilinx CPLD Applications
Handbook
Featuring CoolRunner-II and

XC9500XL CPLDs
R
R
Xilinx is disclosing this Document and Intellectual Property (hereinafter “the Design”) to you for use in the development of designs to operate
on, or interface with Xilinx FPGAs. Except as stated herein, none of the Design may be copied, reproduced, distributed, republished,
downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical,
photocopying, recording, or otherwise, without the prior written consent of Xilinx. Any unauthorized use of the Design may violate copyright
laws, trademark laws, the laws of privacy and publicity, and communications regulations and statutes.
Xilinx does not assume any liability arising out of the application or use of the Design; nor does Xilinx convey any license under its patents,
copyrights, or any rights of others. You are responsible for obtaining any rights you may require for your use or implementation of the
Design. Xilinx reserves the right to make changes, at any time, to the Design as deemed desirable in the sole discretion of Xilinx. Xilinx
assumes no obligation to correct any errors contained herein or to advise you of any correction if such be made. Xilinx will not assume any
liability for the accuracy or correctness of any engineering or technical support or assistance provided to you in connection with the Design.
THE DESIGN IS PROVIDED “AS IS” WITH ALL FAULTS, AND THE ENTIRE RISK AS TO ITS FUNCTION AND IMPLEMENTATION IS
WITH YOU. YOU ACKNOWLEDGE AND AGREE THAT YOU HAVE NOT RELIED ON ANY ORAL OR WRITTEN INFORMATION OR
ADVICE, WHETHER GIVEN BY XILINX, OR ITS AGENTS OR EMPLOYEES. XILINX MAKES NO OTHER WARRANTIES, WHETHER
EXPRESS, IMPLIED, OR STATUTORY, REGARDING THE DESIGN, INCLUDING ANY WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NONINFRINGEMENT OF THIRD-PARTY RIGHTS.
IN NO EVENT WILL XILINX BE LIABLE FOR ANY CONSEQUENTIAL, INDIRECT, EXEMPLARY, SPECIAL, OR INCIDENTAL DAMAGES,
INCLUDING ANY LOST DATA AND LOST PROFITS, ARISING FROM OR RELATING TO YOUR USE OF THE DESIGN, EVEN IF YOU
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE TOTAL CUMULATIVE LIABILITY OF XILINX IN CONNECTION
WITH YOUR USE OF THE DESIGN, WHETHER IN CONTRACT OR TORT OR OTHERWISE, WILL IN NO EVENT EXCEED THE
AMOUNT OF FEES PAID BY YOU TO XILINX HEREUNDER FOR USE OF THE DESIGN. YOU ACKNOWLEDGE THAT THE FEES, IF
ANY, REFLECT THE ALLOCATION OF RISK SET FORTH IN THIS AGREEMENT AND THAT XILINX WOULD NOT MAKE AVAILABLE
THE DESIGN TO YOU WITHOUT THESE LIMITATIONS OF LIABILITY.
The Design is not designed or intended for use in the development of on-line control equipment in hazardous environments requiring fail-
safe controls, such as in the operation of nuclear facilities, aircraft navigation or communications systems, air traffic control, life support, or
weapons systems (“High-Risk Applications”). Xilinx specifically disclaims any express or implied warranties of fitness for such High-Risk
Applications. You represent that use of the Design in such High-Risk Applications is fully at your risk.
© 2005 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc. All
other trademarks are the property of their respective owners.
ii www.xilinx.com June 26, 2006

Table of Contents
Preface: About This Handbook

Guide Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1: Introduction to Digital Applications
IrDA and UART Design in a CoolRunner CPLD

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
IrDA System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
UART and IrDA Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
UART Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
IrDA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
CoolRunner Implementation! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Serial ADC Interface Using a CoolRunner CPLD

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
TI ADS7870. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
CPLD Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Allowing the Visor to Read Conversion Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Hardware Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Wireless Transceiver for the CoolRunner CPLD

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CoolRunner CPLD Transceiver Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
CoolRunner CPLD Transceiver Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
CPLD Transmit Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Receive Module Edge Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Hardware Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Keyboard Entry Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
CoolRunner XPLA3 CPLD Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
CoolRunner-II Smart Card Reader

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Smart Card Reader Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Digital Applications Handbook www.xilinx.com iii

June 26, 2006
R
CoolRunner-II CPLD Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

External Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Smart Card Standard ISO 7816 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Operating Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
CoolRunner-II Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
CoolRunner-II CPLD I2C Bus Controller Implementation

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
I2C Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
CoolRunner-II I2C Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Microprocessor Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
I2C Interface Logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Operational Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
CoolRunner-II CPLD Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
CoolRunner-II Serial Peripheral Interface Master

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
SPI Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
CoolRunner-II SPI Master Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
μC Interface Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
SPI Interface Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Operational Flow Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
CoolRunner-II CPLD Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Design of a Digital Camera with CoolRunner-II CPLDs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
CoolRunner-II Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
CoolRunner-II Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
CompactFlash Card Interface for CoolRunner-II CPLDs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Electrical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
CF+ Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
iv www.xilinx.com Digital Applications Handbook

June 26, 2006
R
Attribute Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Common Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
I/O Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Interfacing to Mobile SDRAM with CoolRunner-II CPLDs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Signal Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Mobile SDRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
CPLD Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
An SMBus/I2C-Compatible Port Expander

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
CoolRunner-II Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Using the CoolRunner-II SMBus/I2C Port Expander Design . . . . . . . . . . . . . . . . . . 155
Customizing the Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Driving LEDs with Xilinx CPLDs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Using Xilinx CPLDs to Drive LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Guidelines for Driving Multiple LEDs with the Same CPLD . . . . . . . . . . . . . . . . . . . . . . . 165
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
CoolRunner-II CPLDs in Cell Phone Handsets/Terminals

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Quick look at a Handset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Cell Phone Chipsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Picking the Right Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MediPhone--A Speculative Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Power and Packaging are Key! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Implementing Keypad Scanners with CoolRunner-II

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Expanding I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Scanning and Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
CPLD Design Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Implementation and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Digital Applications Handbook www.xilinx.com v

June 26, 2006
R
Level Translation Using Xilinx CoolRunner-II CPLDs

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Configuring I/O to Use I/O Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Using the CPLD as a Level Shifter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
CoolRunner-II Character LCD Module Interface

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
CPLD Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Resource Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
NAND Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
CPLD Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
CPLD Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Design Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Cell Phone Security Demoboard

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Demonstration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Design Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Using CoolRunner-II with OMAP, XScale, i.MX & Other Chipsets

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Level Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Pin Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Pin Swizzling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Power Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Logic Consolidation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Conclusion--The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Connecting Intel PXA27x Processors to Hard-Disk Drives

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
PXA27x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
vi www.xilinx.com Digital Applications Handbook

June 26, 2006
R
A Low-Power IDE Controller Design Using a CoolRunner-II CPLD

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
CoolRunner-II IDE Controller Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Operational Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Verilog Test Bench and Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
CoolRunner-II CPLD Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Post-Fit Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Using a Xilinx CoolRunner-II CPLD as a Data Stream Switch

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
MPEG-2 Data Sources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
CPLD Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
MPEG-2 Multiplexer Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Performance and Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Supporting Multiple SD Devices with CoolRunner-II CPLDs

Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
CPLD Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Device Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Voltage and Current Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Chapter 2: Introduction to Low Power Design
The Real Value of CoolRunner-II DataGATE

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
VCCINT Current Savings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
What About VCCIO Current? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Power Evaluation Equation for CoolRunner-II CPLDs

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
The Equation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Low Power Design with CoolRunner-II CPLDs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Power Saving Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Digital Applications Handbook www.xilinx.com vii

June 26, 2006
R
Power Saving Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Chapter 3: Xilinx Design Software

Design Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Schematic Capture Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
HDL Design Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
HDL Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
ISE Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
Device Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Downloading or Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
System Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Advanced Design Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Embedded SW Design Tools Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
ISE WebPACK Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Registration and Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Module Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Chapter 4: WebPACK ISE Design Entry

Design Entry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
HDL Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Functional Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
State Machine Editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Top-Level VHDL Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Simulate the Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Top-Level Schematic Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Creating a Top Level Schematic Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
I/O Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Simulating the Top Level Schematic Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Chapter 5: Implementing CPLD Designs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Synthesis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Constraints Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
CPLD Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Timing Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Design Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
viii www.xilinx.com Digital Applications Handbook

June 26, 2006
R
Chapter 6: Introduction to Logic Consolidation
The Advantages of Migrating from Discrete 7400 Logic Devices to

CPLDs
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
CPLD: The Clear Discrete Logic Replacement Choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Discrete Logic versus CPLD Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Time-to-Market Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Programmability: The Real Advantage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Electromagnetic Interference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Design Security Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Xilinx CPLD Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
TTL “Burn Rate” for Xilinx CPLDs

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Basics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Burn Rate Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Appendix A: Xilinx CPLD Data Sheets
CoolRunner-II CPLD Family

Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Family Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
CoolRunner-II CPLD Family Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Architecture Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Macrocell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Advanced Interconnect Matrix (AIM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
I/O Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Output Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
DataGATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Global Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Additional Clock Options: Division, DualEDGE, and CoolCLOCK. . . . . . . . . . . . . . . . . . 385
Design Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Digital Applications Handbook www.xilinx.com ix

June 26, 2006
R
Programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Power-Up Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
I/O Banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Mixed Voltage, Power Sequencing, and Hot Plugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Development System Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
ATE Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
XC9500XL High-Performance CPLD Family Data Sheet

Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Family Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Architecture Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Macrocell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Function Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Product Term Allocator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
FastCONNECT II Switch Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
I/O Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
5V Tolerant I/Os . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Pin-Locking Capability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
In-System Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
External Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Reliability and Endurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
IEEE ii49.1 Boundary-Scan (JTAG). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Design Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Low Power Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Timing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Power-Up Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Development System Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
FastFLASH Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
x www.xilinx.com Digital Applications Handbook

June 26, 2006
R
Preface
About This Handbook

We wrote this handbook to share many of the solutions Xilinx has created supporting
digital designers over the last few years. To that end, we have included many of the basic
functions that you will find in digital designs, like keyboard and display interfaces; but, we
also include solutions to extend beyond basic functionality. For instance, we include a
compact flash interface that easily modifies to an IDE disk interface.
Xilinx has become a high volume supplier of products into the consumer electronics arena,
with worldwide manufacturing, advanced product planning logistics and world class
customer support – in local time zones with local languages. We ship tens of millions of
CPLDs each quarter, all over the world.
Although many digital designs are well served by chipset solutions from Texas
Instruments, Intel, Freescale and others, these chipsets take time to develop and get
“right”. In that time, evolving applications arise making it impossible to deliver to the
world wide customer base in real time. Some developers have time horizons of nine
months to a year, whereas others develop within two to four months. Being able to respond
to the latest application requirements can only be done with programmable logic.
Programmable logic gives you fastest time-to-market and flexible product life cycle
management available in the silicon world. There is no other equivalent solution for
reducing design time, and nothing that gives you this level of flexibility to respond to
changing market requirements.
Incidentally, much of the information we provide was “discovered” by ASIC designers
needing to fix their gate array solutions with small, low power CPLDs. This occurred so
often that they extended the idea into their product development cycle, to account for late
arriving, last minute market requirements. You might say: “there’s always room for
CoolRunnerTM-II.”
Please scan the table of contents to find the applications you need today, or work your way
through the handbook following the capabilities of CoolRunner-II CPLDs, delivering low
power, inexpensive solutions in tiny packages.
You will find full explanations of CoolRunner-II advanced features like clock dividing and
DataGATE. Explanations will show how adding a CoolRunner-II to a design can actually
reduce the power being used on the whole board. The application notes are backed up
with full designs you can download and use today. The designs are fully documented,
allowing you to expand or collapse functionality as required.
We have included the CoolRunner-II family and individual data sheets – the XC2C32A,
XC2C64A, XC2C128, XC2C256, XC2C384, and the XC2C512 CoolRunner-II CPLDs. We
have also included the XC9500XL (3.3V) family data sheet. You can find all the Xilinx
CPLD products on the Xilinx website, including the low power CoolRunnerTM XPLA3
3.3V CPLD family, the high performance XC9500XLTM 3.3V CPLD family, and the
XC9500TM 5.0V family.
June 26, 2006 www.xilinx.com xi

R
Preface: About This Handbook
Acknowledgements
This book would not have been possible without the efforts and cooperation of several
applications engineers, and at least one FAE. I would like to thank them for their
contributions to the ideas, designs, and hard work performed in the creation of application
notes and white papers for the digital consumer marketplace. They are:
• Nick Mehta • Frank Wirtz

• Jesse Jenkins • John Hubbard
• Mark Ng • Jennifer Jenkins
• Scott Lien • Mike Gulotta
Additional appreciation goes to the Xilinx CPLD Marketing team for guidance and the
creation of collateral marketing material to support the efforts of the digital consumer
initiative. They are:
• Tony Grant • Betsy Thibault

• Roger Seaman • LaToya Parker
Additional Resources
To find additional documentation, see the Xilinx website at:
http://www.xilinx.com/literature/index.htm.
To search the Answer Database of silicon, software, and IP questions and answers, or to
create a technical support WebCase, see the Xilinx website at:
http://www.xilinx.com/support.
xii www.xilinx.com
June 26, 2006
R
Chapter 1
Introduction to Digital Applications

The chapter contains topics for the implementation of common digital functions, such as
smart card readers. You will find white papers and application notes written to assist a
digital designer in the creation of new products. The topics listed are among the design
applications our CPLDs are fully capable of performing. In most cases, Xilinx provides free
reference designs to help speed up your design process. The reference designs can be
found at:
http://www.xilinx.com/products/silicon_solutions/cplds/coolrunner_series/index.htm
This Chapter contains the following topics:
• IrDA and UART Design in a CoolRunner CPLD
• Serial ADC Interface Using a CoolRunner CPLD
• Wireless Transceiver for the CoolRunner CPLD
• CoolRunner-II Smart Card Reader
• CoolRunner-II CPLD I2C Bus Controller Implementation
• CoolRunner-II Serial Peripheral Interface Master
• Design of a Digital Camera with CoolRunner-II CPLDs
• CompactFlash Card Interface for CoolRunner-II CPLDs
• Interfacing to Mobile SDRAM with CoolRunner-II CPLDs
• An SMBus/I2C-Compatible Port Expander
• Driving LEDs with Xilinx CPLDs
• CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
• Implementing Keypad Scanners with CoolRunner-II
• Level Translation Using Xilinx CoolRunner-II CPLDs
• CoolRunner-II Character LCD Module Interface
• Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
• Cell Phone Security Demoboard On The Fly Reconfiguration Technique
• Using CoolRunner-II with OMAP, XScale, i.MX & Other Chipsets
• Connecting Intel PXA27x Processors to Hard-Disk Drives with a CoolRunner-II CPLD
• A Low-Power IDE Controller Design Using a CoolRunner-II CPLD
• Using a Xilinx CoolRunner-II CPLD as a Data Stream Switch
• Supporting Multiple SD Devices with CoolRunner-II CPLDs
Digital Consumer Applications www.xilinx.com 1

June 26, 2006
R
Chapter 1
2 www.xilinx.com Digital Consumer Applications

June 26, 2006
Application Note: CoolRunner CPLD
R
IrDA and UART Design in a CoolRunner
CPLD
XAPP345 (v1.3) December 23, 2003
Summary This application note illustrates the implementation of an IrDA and UART system using a
CoolRunner™ CPLD. The fundamental building blocks required to create a half-duplex IrDA and
full-duplex UART interface design is described. The source code for this design is available and
can be found in the section HDL Code, page 11. This design fits an XC2C128 CoolRunner-II or
XCR3128XL CPLD.
Introduction IrDA devices provide a walk-up, point-to-point method of data transfer that is adaptable to a
broad range of computing and communicating devices. The first version of the IrDA
specification (version 1.0) provides communication at data rates up to 115.2 Kbps. Later
versions (version 1.1) extended the data rate to 4 Mbps, while maintaining backward
compatibility with version 1.0 interfaces. The protocol described in this application note is only
for 115.2 Kbps. The 4 Mbps interface uses a pulse position modulation scheme which sends
two bits per light pulse.
The IrDA standard contains three specifications. These relate to the Physical Layer, the Link
Access Protocol, and the Link Management Protocol. This document provides information on
the Physical Layer and does not provide a detailed explanation of the requirements for full IrDA
conformity. For more information on IrDA see "References" on page 12.
IrDA System Figure 1 illustrates the basic hardware building blocks for IrDA communication. The selection of
UART interface, RS232, and microcontroller or microprocessor, depends upon the
communication speed required. Data rates above 115.2 Kbps require a direct interface to the
address and data lines of the microprocessor or microcontroller. Data rates below 115.2 Kbps
can be implemented over a UART or RS232 port
Serial Out Infrared
UART Transmit
RS232 Modulation/
μP Demodulation
μC
Infrared
Serial In Receive
X345_01_080601
Figure 1: IrDA Block Diagram
A UART interface is implemented in this design for data rates up to 115.2 Kbps. The IrDA
specification is intended for use with a serial communications controller such as a conventional
UART. The data is first encoded before being transmitted as IR pulses. As shown in Figure 2,
the serial encoding of the UART is NRZ (non return to zero) encoding. NRZ encoded outputs do
not transition during the bit period, and may remain High or Low for consecutive bit periods.
This is not an efficient method for IR data transmission with LEDs. To limit the power
consumption of the LED, IrDA requires pulsing the LED in a RZI (return to zero, inverted)
modulation scheme so that the peak power to average power ratio can be increased. IrDA
© 2002 Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and further disclaimers are as listed at http://www.xilinx.com/legal.htm. All other
trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice.
NOTICE OF DISCLAIMER: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this feature,
application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may
require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warranties
or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose.
XAPP345 (v1.3) December 23, 2003 www.xilinx.com 3

1-800-255-7778
R
requires the maximum pulse width to be 3/16th of the bit period. A 16x clock is required, and
counting three clock cycles can easily be done to encode the transmitted data.
Start Data Bits Stop

Bit Bit
0 1 0 1 0 0 1 1 0 1
UART
TXD
(NRZ)
IR_TXD
(RZI)
Bit
Time
3/16
X345_02_080601
Figure 2: IrDA 3/16 Data Modulation
Half Duplex and Latency

The IrDA link cannot send and receive data at the same time. The IrDA link is a half-duplex
interface and a time delay must be allowed from when a link stops transmitting until it can
receive data again. A time period with a duration of 10 ms must be allowed between
transmitting and receiving data. The UART interface design is full-duplex, supporting
simultaneous read and write operations from the microprocessor or microcontroller interface.
UART and IrDA Figure 3 illustrates the system architecture for implementing a UART serial port interface with
Design an IrDA module in a CoolRunner CPLD. The UART or a discrete device must provide a 16x
clock for the IrDA 3/16 modulation scheme.
UART IrDA
TXD
TRANSMIT IR_ENCODE IR_TXD
Parallel
Data
Byte
RCV
RECEIVE IR_DECODE IR_RCV
16XCLK X345_03_080601
Figure 3: UART and IrDA Block Diagram
The Verilog code provided in this design for the UART interface consists of two HDL modules,
TRANSMIT and RECEIVE. Data is written to the transmitter and data is read from the receiver
through an 8-bit parallel data bus.
The Verilog code provided in this design for the IrDA emulates the operation of the Agilent
Technologies HSDL-7000. The IrDA HSDL-7000 consists of logic for both encoding and
decoding the transmit and receive data. Each encode and decode operation is driven by the
clock, derived from the UART, or supplied from a discrete source. This clock must be initially
configured to cope with the IrDA specified startup data rate of 9.6 Kbps, then adjusted to 16
times the desired baud rate.
4 www.xilinx.com XAPP345 (v1.3) December 23, 2003

1-800-255-7778
R
UART Interface Figure 4 illustrates the functionality of the UART interface. The data bus interface to the UART
module is 8-bits. Even or odd parity can be selected on the serial data out, SOUT.
UART
16XCLK RECEIVE
Hold Register
Shift Register
RESET
Mux
Parallel Control SIN
Data Byte Logic
Parity Error
READ
Framing Error TRANSMIT
Hold Register
Shift Register
Overrun Error
RX_RDY Control SOUT

Logic
TX_RDY
WRITE
X345_04_080701
Figure 4: UART Main Interface Logic
The serial data out, SOUT follows the format shown in Figure 5.
LSB MSB
8 Data Bits Stop

Bit
Start Parity
Bit Bit
X345_05_080701
Figure 5: UART Data Out Format
UART Transmit Logic

Data transfer in this design is controlled by the system microprocessor or microcontroller. The
UART design must interface with the parallel processor bus and necessary control lines. The
UART transmit logic consists of interpreting processor write commands, generating the
transmit clock, TXCLK, at the desired baud rate, and shifting out data on SOUT. The UART
logic must interpret the active Low write signal from the processor and read in data from the
data bus. The data is read into the transmit hold register. Once the write signal is de-asserted,
a flag is asserted to start shifting data out on SOUT. Figure 6 illustrates the logic of interpreting
the write signal.
IDLE write = '1'
write = '0'
ASSIGN
write = '1'
DATA_RDY
X345_06_080701
Figure 6: Assigning Transmit Data

1-800-255-7778
R
The second part of control logic for the UART transmitter is dividing the 16x clock to transmit
data at the desired baud rate. The transmit clock, TXCLK, is generated using a 3-bit counter
that increments on the rising edge of the 16x input clock. TXCLK controls when data changes
on the serial data output of the UART. Figure 7 illustrates this logic, TXCLK changes value
when the 3-bit counter is equal to zero.
START reset = '0'
reset = '1'
IDLE
cnt = 8 cnt = 0
INCR cnt < 8
X345_07_080701
Figure 7: TXCLK Generate Logic
The last main portion of the UART transmit logic is shifting out data on SOUT. Figure 8
illustrates the control logic to send data out according to the data format shown in Figure 5. The
START TRANSMIT logic sends the start signal out on SOUT. The SHIFT OUT logic shifts the
transmit shift register and sends data out on SOUT. When the paritycycle signal is asserted, the
parity bit is transmitted. Once the data and parity has been transmitted, the done bit is sent by
the STOP OUT logic.
START reset = '0'
reset = '1'
IDLE reset = '1'
reset = '0' and txdone = '1'

and txdatardy = '0'
START
TRANSMIT
txdone = '0' or
txdatardy = '0'
SHIFT txdone ='0' and

OUT paritycycle = '0'
paritycycle = '1'
PARITY
OUT
txdone = '1'
STOP
OUT
X345_08_080701
Figure 8: SOUT Control Logic
UART Receive Logic

The UART receive logic must interpret the incoming data from the IrDA module on SIN, as well
as present a parallel byte of data to the microprocessor or microcontroller in the system. To
interpret the incoming SIN data, the receive logic must search for the start bit in the data

1-800-255-7778
R
stream. The start bit is indicated by an active Low signal for eight clock cycles after a falling
edge on SIN.
START reset = '0'
reset = '1'
IDLE sin = '1'
sin = '1' sin = '0'
DETECT sin = '0'

EDGE
rxclk = '1'
SHIFT IN
DATA
GENERATE
PARITY
Stop Bit
No Detected
?
Yes
SET ERROR
FLAGS
X345_09_080701
Figure 9: UART Receive Logic
A falling edge on SIN is read by the DETECT EDGE logic as shown in Figure 9. To receive data,
the receive clock must be centered on the low leading start bit. The receive clock, RXCLK is
generated by dividing the 16x clock using a 4-bit counter.
Once a valid start bit is detected, the data is sampled on SIN at each RXCLK rising edge. The
receive shift register is shifted with the incoming SIN data. Running parity is generated with
each incoming data bit. When a stop bit is detected, any error flags are set. This includes parity,
overrun, and framing error flags.
A main function of the UART receive logic is interfacing with the processor. The CPLD detects
a valid edge on the READ signal asserted by the processor. The CPLD then places the
received parallel data on the system data bus.

1-800-255-7778
R
IrDA Interface Figure 10 illustrates the input and output requirements of the IrDA module in this design. RXD
and TXD are the serial connections to the UART SIN and SOUT data lines respectively. IRRXD
and TXRXD are the IrDA 3/16th pulse signals that are fed into the LED driver/receiver circuitry
as shown in Figure 10.
IRTXD
TXD
IR Module LED
RXD (HSDL-7000) LED Driver
16XCLK
IRRXD
PIN
Post Pre-
Amplifier Amplifier
X345_10_080701
Figure 10: IR HDL Block Diagram
The encoding scheme shown in Figure 2 sends a pulse for every space or "0" that is sent on the
TXD line. On a High-to-Low transition of the TXD line, the generation of the pulse is delayed for
seven clock cycles of the 16XCLK before the pulse is set High for three clock cycles (or 3/16th
of a bit time) and then subsequently pulled low.
The decoding scheme shown in Figure 11 seeks a High-to-Low transition of the IRRXD line
which signifies a 3/16th pulse. This pulse is stretched to accommodate one bit time (16 clock
cycles). Every pulse that is received is translated into a "0" on the RXD line equal to one bit
period.
16
Clock
Cycles
16XCLK
IRRXD
3/16
RXD
1 0 1 1 1 0 1 1
Start Data Bits Stop

Bit Bit
X345_11_080701
Figure 11: IrDA Decoding Scheme
CoolRunner The UART and IrDA design was implemented in Verilog as described above. Xilinx Project
Implementation Navigator was used for compilation, fitting, and simulation of the design in a CoolRunner CPLD.
Xilinx Project Navigator, which includes the ModelTech simulation tool, is available free-of-
charge from the Xilinx website at www.xilinx.com/products/software/webpowered.htm. The
design was targeted for a 3.3V, 128 macrocell CoolRunner XPLA3 CPLD (XCR3128XL-
VQ100). The UART and IrDA design utilization is shown in Table 1. These utilizations were

1-800-255-7778
R
Ir DA an d UA RT D es ig n in a C o o lR u n n er C PL D
achieved using certain fitting parameters, actual results may vary. As shown, there is area
remaining in the CPLD for the implementation of other logic in the system.
Table 1: UART and IrDA XPLA3 128-Macrocell Utilization

Resource Available Used Utilization
Function Blocks 8 6 75.0%
Macrocells 128 88 68.75%
Product Terms 384 129 33.60%
Foldback NANDs 64 0 0%
I/O Pins 80 17 21.25%
The Verilog IrDA design can also be targeted as a stand alone module in a 3.3V 32-macrocell
CoolRunner XPLA3 CPLD (XCR3032XL). CPLD utilization for implementing the IrDA design is
shown in Table 2.
Table 2: Standalone IrDA XPLA3 32-Macrocell Utilization

Function Blocks 2 1 50.0%
I/O Pins 32 4 12.50%
Design Verification
The UART/IrDA transmit and receive Verilog design verification has been done through
simulation using ModelSim XE in Project Navigator. The design has been verified both
functionally and with the timing model generated when fitting in a CoolRunner CPLD. The
implemented test bench drove the data, control, and timing necessary to test a transmit
operation from the UART to the IrDA output and test the received data from the IrDA and UART
modules. Implementation in an actual system may require modification of the control signals
used in the source code and test benches provided.
ModelSim Implementation
Notes:
Please refer to XAPP338: Using Xilinx WebPack and ModelTech ModelSim Xilinx Edition as a guide
to using ModelSim with Project Navigator. The ModelSim Quick Start demo provides a good first step
for getting familiar with ModelSim.
Figure 12 illustrates the test environment for transmitting a data byte using the UART and IrDA
modules. Upon receiving an active WRITE signal, the UART TXRDY signal is asserted. Data is
sent to the UART module and transmitted as shown on the SOUT signal. TXCLK is the internal
divided clock signal for the UART module. IRTXD is the data transmitted from the IrDA module.

1-800-255-7778
R
The IR transmitted data is in the form as shown in Figure 2 and includes the start bit, eight data
bits, a parity bit, and a stop bit in each data transmission.
Figure 12: UART and IrDA Transmit Simulation
Figure 13 illustrates receiving data on the IrDA IRRXD input and presenting the parallel data
byte from the UART to the system. The IrDA receive module recognizes the format of incoming
data and sends the translated serial stream to the UART, as illustrated in Figure 11 on the SIN

1-800-255-7778
R
signal. The UART module shifts the incoming serial data into a holding register. Upon the UART
receiving an active READ signal, the UART places the parallel data onto the data bus.
Figure 13: Transmit and Receive Simulation
HDL Code THIRD PARTIES MAY HAVE PATENTS ON IRDA. BY PROVIDING THIS HDL CODE AS ONE
POSSIBLE IMPLEMENTATION OF THIS DESIGN, XILINX IS MAKING NO
REPRESENTATION THAT THE PROVIDED IMPLEMENTATION OF THIS DESIGN IS FREE
FROM ANY CLAIMS OF INFRINGEMENT BY ANY THIRD PARTY. XILINX EXPRESSLY
DISCLAIMS ANY WARRANTY OR CONDITIONS, EXPRESS, IMPLIED, STATUTORY OR
OTHERWISE, AND XILINX SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE,
THE ADEQUACY OF THE IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY OR REPRESENTATION THAT THE IMPLEMENTATION IS FREE FROM
CLAIMS OF ANY THIRD PARTY. FURTHERMORE, XILINX IS PROVIDING THIS
REFERENCE DESIGNS "AS IS" AS A COURTESY TO YOU.
XAPP345 - http://www.xilinx.com/products/xaw/coolvhdlq.htm

1-800-255-7778
R
Conclusion IrDA is a low cost, walk-up, point-to-point method of IR communication protocol used in
applications ranging from laptops to phones to fax machines. This design is an example
implementation of an IrDA interface for data ranges less than 115.2 Kbps connected to a UART
interface. Version 1.1 extends the IrDA specification to 4 Mbps and can be implemented using
pulse position modulation.
References 1. Infrared Data Association (IrDA).

2. Hewlett Packard IrDA Data Link Design Guide.
3. Agilent HSDL-7000 Data Sheet: IR 3/16 Encode/Decode IC.
4. Agilent Application Note 1119: IrDA Physical Layer Implementation for Agilent
Technologies’ Infrared Products.
5. Xilinx Application Note XAPP341: UARTs in Xilinx CPLDs.
6. QuickLogic Application Note: QAN20. Digital UART Design in HDL.
7. Faulkner, Lawrence. IrDA "More than Wireless".
8. Evans, David James. IrDA Applications in CoolRunner CPLDs.
Revision The following table shows the revision history for this document.
History
Date Version Revision
08/08/01 1.0 Initial Xilinx release.
09/30/02 1.1 Minor edits.
05/15/03 1.2 Minor corrections.
12/23/03 1.3 Updated links.

1-800-255-7778
R
Serial ADC Interface Using a CoolRunner
CPLD
XAPP355 (v1.1) January 3, 2002
Summary This document describes the design implementation for controlling a Texas Instruments
ADS7870 Analog to Digital Converter (ADC) in a Xilinx CoolRunner™ XPLA3™ CPLD.
CoolRunner CPLDs are the lowest power CPLDs available and the ideal target device for
controlling a serial ADC in a portable handheld application. This document provides an
explanation of the VHDL code for the CoolRunner CPLD.
All related source code is provided for download. To obtain the VHDL code described in this
document, go to section VHDL Code Download, page 39 for instructions.
Overview Figure 1 illustrates the high-level block diagram for the data aquisiton system. The system
includes an XPLA3 CoolRunner CPLD, a Texas Instruments ADS7870 ADC, and a Toshiba
SRAM. The Texas Instrument ADS7870 ADC is initialized and controlled by the CoolRunner
CPLD. The CoolRunner CPLD takes conversion data from the ADC and writes the data to
SRAM. The SRAM used in the Insight Handspring Springboard development board is a 4 Mbit
Toshiba SRAM, TC55V400AFT. The Toshiba SRAM is a 16-bit word size SRAM, and is used for
storing data in a conversion cycle. Once conversion data is written into SRAM, the CoolRunner
CPLD allows the system processor to access the data.
Analog Shift Data In

Inputs
Texas Shift Data Out
8 Ch Instruments CoolRunner XPLA3
(4 Ch Diff.) A/D Converter CPLD
A/D Control
ADS7870
SClk
2.5 MHz CClk

Address
Control
Data
Toshiba
4Mbit SRAM
Figure 1: High Level Block Diagram
© 2002 Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and disclaimers are as listed at http://www.xilinx.com/legal.htm.
All other trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice.
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 13

1-800-255-7778
R
Usage The VHDL code distributed with this document is designed such that minimal knowledge of
VHDL language is required. A designated "constants" section of the VHDL code can be edited
to specify various aspects of the ADS7870 which include:
• Initialization of internal registers
• Specification of the number of conversions for any (or all) of the eight single-ended
channels
• Specification of SRAM locations where conversion results should be written
Designers who do not wish to understand the VHDL code in detail can simply edit this
designated VHDL "constants" section, compile the design and program the CoolRunner CPLD.
For more information, refer to section High Level Control Logic, page 18.
The following sections will detail the ADS7870 interface for those who wish to understand the
VHDL implementation of the CPLD ADC interface.
For a complete Handspring design example, refer to "XAPP146: Designing an 8 Channel
Digital Volt Meter with the Insight Springboard Kit".
TI ADS7870 Introduction
The ADS7870 ADC is a low power 12-bit, serial, 8-channel analog to digital converter. The
ADS7870 ADC is ideal for portable and handheld applications. The ADS7870 contains an
integrated PGA (Programmable Gain Amplifier) as well as a 2.5 MHz clock source (CCLK) that
is used internally and can be divided for conversion cycles. The CCLK can be configured as an
output for use with multiple ADCs and other system devices. The CoolRunner CPLD uses the
CCLK from the ADC as its system clock.
The information presented in this section is provided for convenience. For more information on
the Texas Instruments ADC, see References, page 38.
Figure 2 shows a detailed block diagram of the ADS7870.
VREF BUF IN BUFOUT /REF IN
ADS7870
BUF
Clock CCLK
REF Divider
Oscillator OSC ENABLE
Analog
Inputs + BUSY
MUX PGA 12-Bit
A/D
- CONVERT
8 Ch
(4 Ch Diff.) RESET
RISE/FALL
CS
I/O 0
I/O 1 Registers Serial SCLK
Digital and
I/O 2 I/O Interface DIN
Control
I/O 3
DOUT
X9499
Figure 2: ADS7870 Block Diagram
14 www.xilinx.com XAPP355 (v1.1) January 3, 2002

1-800-255-7778
R
Functional Description
Each functional block shown in Figure 2 in the ADS7870 is described in detail in Table 1.
Table 1: ADS7870 Functional Blocks

Block Description
MUX The ADS7870 has eight analog-signal input pins, LN0 through LN7.
These input pins are connected to a multiplexer (a network of analog
switches). This multiplexer is controlled by four bits in the Gain/Mux
register.
LN0 through LN7 can each be configured as a single ended input or as
a differential input. The M2 bit in the MUX address will enable the user
to choose the polarity of the input.
The input signal at any of the LN0 through LN7 pins can range between
–0.2V and 3.5V.
Clock CCLK, the conversion clock, is used by the A/D. CCLK can either
Divider/Oscillator function as an input pin (the user supplies an external clock) or an
output pin (the ADS7870 will output a 2.5 MHz clock on the CCLK pin
and use this signal as its conversion clock).
The OSC ENABLE pin controls whether CCLK is an input or an output.
When pulled high, CCLK is an output. When OSC ENABLE = "0", the
user may supply an external clock.
REF The Voltage Reference block can generate an output voltage of 1.15V,
(Voltage Reference) 2.048V, or 2.5V on the VREF pin.
In single-ended operation, the Voltage Reference will determine the
maximum positive full scale input. For instance if VREF = 2.5V, an input
of 2.5V will yield a result of +2047.
In differential mode, VREF will determine the center point. Register 7
controls whether the reference is turned on or off. On the Insight
Springboard, the VREF pin is tied to the BUFIN pin.
BUF The Buffer Amplifier takes the internally generated Voltage Reference
(Buffer Amplifier) as an input and outputs it to the A/D block. A Buffer is used in order to
increase the output current capability of the VREF pin.
The BUFE bit in Register 7 can turn the Buffer on or off. When the
buffer is on, the ADS7870 will use the internal reference. If the Buffer is
turned off, the ADS7870 will accept an external reference.
PGA The PGA is a Programmable Gain Amplifier that can amplify the input
(Programmable signal before it is applied to the A/D Block. This is useful if the dynamic
Gain Amplifier) range of the input signal is small.
The PGA is capable of providing gains of 1, 2, 4, 5, 8, 10, 16, and 20
V/V.
The PGA gain is set by bits G2 through G0 of Register 4.
Serial Interface The ADS7870 communicates with the CoolRunner though this digital
serial port interface. The serial interface is comprised of four pins:
SCLK (Serial Data Clock), DIN (Serial Data Input), DOUT (Serial Data
Output), and CS (Chip Select).
The RISE/FALL pin, also controlled by the CoolRunner, determines
whether the ADS7870 will latch serial data on the rising or falling edge
of SCLK. In this design, SCLK is active on the rising edge (the
CoolRunner device always drives the RISE/FALL pin High).

1-800-255-7778
R
Table 1: ADS7870 Functional Blocks (Continued)

Block Description
Registers and The ADS7870 has a total of 10 user addressable registers. These
Control registers control various aspects of the ADS7870. For example, the
registers can control operation of the A/D, set the PGA gain, or control
the Digital I/O pins. A complete list of registers is available on page 16
of the ADS7870 Datasheet.
On the Insight Springboard, the CoolRunner A/D Interface will drive the
serial port and will configure and/or read these registers.
Digital I/O The ADS7870 provides four Digital I/O pins that can independently
function as an input or output. All four of these I/O pins are connected
to the CoolRunner device.
These Digital I/O pins are configured through the Serial Interface.
A write to Register 6 will configure the Digital I/O pins as inputs or
outputs. If any of the pins are configured as outputs, a write to Register
5 will determine whether the pin will output a "1" or a "0". Alternately, if
configured as an input, a read from Register 5 will reveal the state of
the pin.
12-bit A/D The serial interface configures and controls operation of the 12-bit A/D
Converter. The output of the converter is 2’s complement format. This
result is stored in registers 0 and 1. These registers are read through
the serial interface.
For a plot of Output Codes vs. Input Voltage, refer to Figure 2 on page
10 of the Texas Instruments ADS7870 Data Sheet.
ADS7870 Interface
The ADS7870 has four conventional serial interface pins: SCLK (serial data clock), DOUT
(serial data out), DIN (serial data in), and CS (chip select function) as shown in Figure 3. A wide
variety of microcontrollers can interface to this conventional serial port.
SCLK
ADC Serial DIN

CPLD
Interface CS
DOUT
Figure 3: ADC and CPLD Serial Interface
In this particular design, the CoolRunner CPLD is used to handle the serial interface. The
condition of the SCLK pin (active level logic "1" or logic "0") is explicitly controlled. The ADC is
configured to latch data on the active edge of SCLK by holding a logic "1" to the RISE/FALL*

1-800-255-7778
R
pin. Thus, the ADC interface ensures that data is available on the DIN pin when SCLK is "0" and
holds it when SCLK is "1". Figure 4 illustrates this timing.
SCLK
DIN data(7) data(6) data(1) data(0)
Figure 4: ADC Serial Timing Diagram
Control and configuration of the ADS7870 is accomplished by command bytes written to

internal registers through the serial port. Command register device control includes MUX
channel selection, PGA gain, and Reference Input control. One must use the “register mode” in
order to configure a register.
Register Mode
In register mode, the first eight bits transmitted to the ADC specify the address of a particular
register, whether to perform a read or a write operation and whether the data will be sixteen bits
or eight bits. Immediately after these eight bits are sent, eight or 16 more bits (depending upon
what was specified) are sent or received. For a write, data is sent through DIN. For a read, data
will appear on the DOUT pin. For a complete list of available registers please refer to the
ADS7870 datasheet. The VHDL code in this design allows the user to customize the register
usage.
CS must remain Low in order to activate the serial interface. Once CS is brought Low, an
internal counter residing in the ADS7870 begins counting the number of active SCLK edges.
Raising the CS pin will put the DOUT pin in high impedance and will resynchronize the internal
counter. It is possible to keep CS Low throughout an entire chain of serial commands (i.e., write
to all address registers), but doing so will require careful management of the serial interface
pins. One must be extremely careful when attempting to do so, as one error will cascade
throughout the entire sequence.
Therefore, in this design, and in future designs, the CoolRunner CPLD briefly pulls the CS pin
High after the completion of every serial command. This ensures that errors will not cascade.
Direct Mode
A conversion can be initiated on the ADS7870 by issuing a direct mode command. In this
mode, a single 8-bit instruction byte is sent. The direct mode command will specify the input
channel and the PGA gain. Immediately after this 8-bit instruction is sent, the ADS7870 will
perform a conversion on the specified channel, with the specified PGA gain. The results will be
written to Registers 0 and 1 and can be retrieved using a register mode read. However, in this
design, the ADC is configured to use Read Back Mode 1. In this mode, the conversion result
will automatically clock out on the next active edge of SCLK, after the last bit of the direct mode
command is sent. Configuring the ADS7870 for Read Back Mode 1 will increase throughput
since a separate read instruction is not required to read the result in registers 0 and 1.
CPLD Design Operational Flow

The CoolRunner CPLD controls the initialization of the ADC and the reading of conversion
results. The CoolRunner CPLD then writes the conversion results of each conversion cycle to
SRAM. This interface is implemented using two state machines. The state machines control
the sending and receiving of parallel data and the configuring of internal ADC registers. After

1-800-255-7778
R
the CPLD initializes the ADC, it sends multiple "direct mode" instructions to initiate consecutive
conversion cycles. The 12-bit serial data in a conversion cycle is read in by the CPLD and
deserialized for a 16-bit word write to SRAM.
Figure 5 illustrates at a high level the operational flow for the ADC interface. The CPLD must
initialize the ADS7870 registers that are pertinent to the design. This includes specifying each
address register and the corresponding data to write. The CPLD then initializes the ADC for
performing a "direct mode" conversion cycle for a specific input channel. The CPLD must send
the direct mode command before reading out the ADC conversion data. The CPLD brings in the
serial data and presents the deserialized data word to SRAM. The CPLD continues to issue the
same direct mode command while reading the same input channel on the ADC. To read
another input channel on the ADC a different direct mode instruction must be sent. The direct
mode instruction includes control bits to specify the input channel on the ADC.
START
Write to necessary
ADC register
More
Yes Registers
?
No
Start new conversion by

issuing a direct mode command
for specified input channel
Read back conversion data
Write conversion data to SRAM
More
Yes Channels
?
No
END
X355_05_080801
Figure 5: ADC Interface Operational Flow
High Level Control Logic

The high level control logic for the ADC interface is implemented through the MAIN state
machine. The state machine is responsible for sequencing through the following steps:
1. Specify the address of the register to be written.
2. Send the appropriate address over the serial interface.

1-800-255-7778
R
3. Specify the data to write to the specified register.

4. Send the data via the serial interface to write.
5. Continue steps 1–4 until all registers have been initialized.
6. Specify direct mode instruction for a conversion on a specific input channel.
7. Read data in and deserialize for the conversion cycle.
8. Continue steps 6–7 until all data is read from the specific input channel.
9. Repeat steps 6–8 to read from all input channels that are specified and enabled.
To implement this functionality, the MAIN state machine as shown in Figure 6 has been
designed and implemented. During the register mode states, the MAIN state machine specifies
the parallel 8-bit data word to write to the ADC. The MAIN state machine loads the 8-bit data
register and initiates the go_shift command. The SHIFT state machine, described in Shift
Control Logic, page 23, takes the parallel data word and sends data out the serial interface to
the ADC. The mode_flag signal is specified in the MAIN state machine for use by the SHIFT
state machine.

1-800-255-7778
R
IDLE
Register Mode
Assert go_shift <= "1" WRITE_ADDR
& mode_flag = "0"
Assert go_shift <= "0" WAIT_ADDR shift_done = "0"
shift_done = "1"
Assert go_shift <= "1" ADDR_DATA
Assert go_shift <= "0" WAIT_DATA shift_done = "0"
shift_done = "1"
More
Registers Yes
?
No
Direct Mode
Assert go_shift <= "1" DIRECT_MODE
Assert go_shift <= "0" WAIT_DM shift_done = "0"
shift_done = "1"
Assert go_shift <= "1"

& mode_flag = "1" ASSIGN_DATA
Assert go_shift <= "0" READ_DATA shift_done = "0"
shift_done = "1"
More
Conversion
Cycles? No
Yes
DONE
X355_06_080801
Figure 6: MAIN State Machine Control Logic
Table 2 describes the functionality of each state in the MAIN state machine control logic shown
in Figure 6. Note the mode_flag = "0" for the SHIFT control logic to designate the shift size for
data. When mode_flag = "0", an 8-bit data value is shifted out. This is either a register address,

1-800-255-7778
R
data to write to an address register, or the direct mode command. When mode_flag = "1", a
16-bit data value is shifted in from the ADC. This is for capturing the conversion data which
consists of 12 bits of data, three zero bits, and the overflow bit.
Table 2: MAIN State Machine Description

State Functionality
IDLE Initializes specific combinatorial signals.
WRITE_ADDR Specifies the address of the register to write to. Loads the 8-bit shift
register with this address. Asserts the go_shift signal to the SHIFT
control logic to start shifting the address out. This state assigns
wr_reg_num which specifies the address currently being written to for
use in later states. State also deasserts the enable flag (which is
TRUE for a write) for a specific register. Once the flag is disabled, the
state machine will not write to that register again.
WAIT_ADDR Waits for SHIFT control logic to complete shifting out data to ADC on
DIN. The signal shift_done will be asserted to represent this event.
ADDR_DATA Checks the value of wr_reg_num to compare which address was
specified earlier to the ADC. The data to write to that register is loaded
into the 8-bit shift register. Asserts the go_shift signal to the SHIFT
control logic to start shifting data out.
WAIT_DATA Waits for SHIFT control logic to complete shifting out data to ADC on
DIN. The signal shift_done will be asserted to represent this event.
Checks to see if any remaining flags are set to TRUE, which indicates
more registers need to be written to. The state machine then loops
back to the WRITE_ADDR state. If all flags are set to FALSE, the state
machine proceeds to the direct mode sequence.
DIRECT_MODE Specified the direct mode command to send to the ADC. Loads the
8-bit shift register with this direct mode command. Asserts the go_shift
signal to the SHIFT control logic to start shifting the direct command
out on DIN to the ADC. Based on direct mode command that is sent
(which represents which input channel to read from), the SRAM
address pointer is updated.
WAIT_DM Waits for SHIFT control logic to complete shifting out the direct mode
command to ADC on DIN. The signal shift_done will be asserted to
represent when the entire data word has been shifted out.
ASSIGN_DATA Sets mode_flag = "1". This signals the SHIFT control logic to count for
16 SCLK cycles to bring in the conversion data on DOUT. Asserts the
go_shift signal to the SHIFT control logic to start counting the
incoming data.
READ_DATA Waits for SHIFT control logic to assert shift_done to represent when
the 16-bit conversion data is done being shifted into the system.
Conversion data is written into SRAM at the specified location
represented in sram_address. Checks if the sram_address is at the
max address space for the specified ADC input channel. If so, then
loops back to DIRECT_MODE for the next input channel. If not, then
it loops back to DIRECT_MODE for the same input channel. If there
remains no ADC input channels to read from, the state machine
proceeds to the DONE state.
DONE End of state machine. Release control of bus to Handspring Visor.

1-800-255-7778
R
Customizing the MAIN State Machine

The following is a description for customizing the MAIN state machine VHDL code for a specific
application. The designation of register mode is for initializing the ADC registers. This allows
the CPLD to configure the ADC. After, the ADS7870 has been configured, the MAIN state
machine sends the "direct mode" command. Direct mode represents when the ADC is
executing conversion cycles. The ADC will issue a direct mode command and then wait to
receive the conversion data for the next 16 clock cycles.
Register Mode
The MAIN state machine continues to remain in the register mode, for initialization, until all
registers have been set up and written to. The VHDL code enables the user to specify which
registers to write to and the data to write to each register. The following VHDL code illustrates
how to specify a write to ADDR3 in the ADC interface VHDL code.
constant WR_ADDR3_EN: BOOLEAN := TRUE;
-- Write/Read to Control Register

constant ADDR3: STD_LOGIC_VECTOR(7 downto 0) := ’00000011’;
-- Data to be written
constant DATA_WR_ADDR3: STD_LOGIC_VECTOR(7 downto 0) := ’00000100’;
Note the variable WR_ADDR3_EN can be set to either TRUE or FALSE, enabling or disabling
a write to ADDR3. If WR_ADDR3_EN is set to TRUE, then the data to write to that register must
also be specified. This is done in the DATA_WR_ADDR3 constant. In this example, we are
writing "0000 0100" to ADDR3, which specifies Read Back Mode 1 (MSB read back first) and
sets CCLK division factor = 1. For more information on the data that can be written to each
register, refer to References, page 38.
When writing to a register, not only is the register address specified, but additionally a read or
write operation and the data word size can be specified.
The data written to the control registers allows the ADC to set up features such as: reading
MSB or LSB first, the division factor of CCLK, PGA gain for a specific input channel, enabling
the use of the digital I/O, and many more features that can be found in the ADC data sheet.
Direct Mode
Once all the control registers have been initialized in the ADC in the register mode, the ADC
can now operate in the direct mode. The direct mode allows the external ADC controller to
specify the input channel and read the conversion data. The VHDL code in this design has
been constructed to ease the implementation for any application. The VHDL code enables the
designer to specify which input channels to read from and how many conversions are
requested on each input. The VHDL code for enabling/disabling register mode conversions is
similar to the set up for register mode initialization. The following VHDL code illustrates how to
perform eight conversions from the ADC single-ended input channel 0 and read eight
conversions from the ADC single-ended input channel 1.
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 0 ***************

constant DM_SNG_LN0_EN : BOOLEAN := TRUE;
constant DM_SNG_LN0 : STD_LOGIC_VECTOR(7 downto 0) := ’10001000’;
constant SRAM_OFFSET0 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000000000’;
constant SRAM_HIGH0 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000000111’;
-- *********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 1 ************


1-800-255-7778
R

’00000000000000000001000’;
’00000000000000000001111’;
The number of conversions in this particular example is controlled by counting each conversion
write to SRAM. Therefore, once the address counter for the SRAM reaches the SRAM_HIGH
offset, the specified number of conversions are counted. To enable a conversion from a specific
input channel, the VHDL constant DM_SNG_LN0_EN set to TRUE will enable multiple
conversions from LN0 in the ADC. Note that for only reading from one single-ended input
channel, all other input channel enable constants must be set to FALSE. The constant
DM_SNG_LN0 stores the value to send a direct mode command for a conversion on LN0.
Refer to the ADS7870 data sheet for more information on sending a direct mode command.
Shift Control Logic

The shift control logic is initiated by the main control logic state machine. The SHIFT state
machine is used for shifting out and shifting in data to/from the ADC. The SHIFT state machine
is responsible for sending out data for a register address write, a register data write, and a
direct mode instruction write. The shift state machine also shifts in data during the direct mode
conversion cycles. For all register and direct mode instructions to the ADC, the data word to
write is eight bits. For shifting in the 12-bit conversion data, a 16-bit shift register is used. The
data format in a conversion cycle is specified in ADDR3, and includes 12 data bits, three zero
bits, and an overflow bit.
The SHIFT control logic is shown in Figure 7. The SHIFT state machine is activated on the
rising edge of go_shift. The go_shift signal is asserted from the MAIN state machine and
initiates a write or read to/from the ADC. The mode_flag is used to interpret whether the CPLD
is writing to a register, sending a direct mode command, or reading in a conversion cycle. The
mode_flag signal is equal to "0" during a register or direct mode command and mode_flag = "1"
when reading in a conversion cycle.
IDLE go_shift = "0"
go_shift = "1"
SC0
(CNT<8 & mode_flag = "0") or
(CNT<16 & mode_flag = "1")
shift_done <= "1" SC1
(CNT = 8 & mode_flag = "0") or

(CNT = 16 & mode_flag = "1")
X355_07_080801
Figure 7: SHIFT State Machine Control Logic
The SHIFT state machine is responsible for generating the shift clock, SCLK, and setting up the
appropriate data to send out. As previously described, the data to send must be on the DIN line
before the active edge of SCLK. In the SHIFT state machine, the data register holding the word
to send is enabled in the SC0 state (SCLK = "0"). Then in the SC1 state, SCLK = "1" and the
data bit is shifted out on DIN.
During a direct mode conversion cycle, the SHIFT state machine controls SCLK. The SHIFT
state machine reads in data on the DOUT line at the active edge of SCLK, in the SC1 state.
For more information on implementing these state machines to initialize and read conversion
data from the ADC, see section Hardware Implementation, page 28.

1-800-255-7778
R
Allowing the After conversion results have been written to SRAM, the Handspring Visor must be given
Visor to Read access to read the conversion result from SRAM. This transfer of control occurs once the MAIN
state machine has written all conversion results to SRAM. This is specified in the DONE state
Conversion of the MAIN state machine.
Results This section will detail how the CoolRunner CPLD releases control of the bus to the Handspring
Visor.
On the Insight Springboard Development Kit, all address, data and control signals originating
from the Springboard expansion area are routed into the CoolRunner CPLD. These signals are
then internally routed to a brand new set of pins, which are then externally connected to the
SRAM, A/D, and Flash. XAPP147: "Low Power Handspring Springboard Module Design
with CoolRunner CPLDs", illustrates this routing scheme. In the most basic case, the
CoolRunner would simply act as a buffer for all signals, all signals would go directly into and
then out of the CPLD, without being manipulated.
In this case, however, the functionality of the CoolRunner has increased because it has the
added task of controlling the ADS7870. The CoolRunner must allow both the Visor and the A/D
to be able to write (and read) to SRAM. Therefore, the simple interface shown in XAPP147
must be slightly modified to include multiplexers. These multiplexers are controlled by the
ADS7870 interface. When the interface is active, the multiplexers allow for the CPLD to write
conversion results to SRAM. When conversions are finished, the Visor is allowed to read these
conversions from SRAM, or alternately write new values to SRAM.
Data[15:0]
Figure 8 below shows the functionality that would allow for data to be passed to/from the Visor,
through the CoolRunner CPLD.
Figure 8: Data Bus Multiplexing in CoolRunner CPLD
In Figure 8, “SP_D[15:0]” is the name given to the data lines originating from the Visor.
"D[15:0]” is the name of the buffered signal. These buffered data lines are routed to the data
lines of the SRAM and Flash.
A multiplexer is inserted between the input buffer of “SP_D[15:0]” and the output buffer for
“D[15:0]”. The multiplexer’s inputs are “SRAM_Write_Data” and “AD_DATA”.
SRAM_Write_Data is a 16-bit signal that represents the data value present on the Springboard
Data lines. AD_DATA, is a-16 bit signal that is output from the A/D Interface. AD_DATA is the
value of a conversion result.
Mux_Sel, the select line for the multiplexer, controls which of the two inputs will be potentially
applied to SRAM and/or Flash. The output value of the multiplexer is not guaranteed to be
applied since the output of the MUX is tied to the input of a tri-state buffer. Therefore, the value
of the tri-state control signal, “SRAM_Write_Enable” will determine if data will be output.

1-800-255-7778
R
When Mux_Sel is "0" the Handspring Visor will have control of the data lines. Alternately, when
Mux_Sel is "1", the A/D Interface is allowed to write data to SRAM. The A/D Interface controls
the value of Mux_Sel so that when it is active, the value of Mux_Sel will be "1" and when it is
complete, the value will be set to "0".
SRAM_Write_Enable is a tri-state control signal that determines if the “D[15:0]” pins will
function as an input or as an output. D[15:0] will function as outputs if the value of
SRAM_Write_Enable is a "1". On the other hand, the D[15:0] pins will be inputs if the tri-state
control signal is "0".
The SRAM_Write_Enable equation is equal to:
(SM_WE) + (SM_WE) & [ WE & (CS0 + CS1) ]
Table 3 describes each literal in the SRAM_Write_Enable equation.
Table 3: Literal Description

Literal Description Function
SM_WE Write Enable generated by A/D Interface "0" when A/D Interface is inactive
"1" when A/D Interface is active
WE Write Enable signal generated by Visor "0" when Visor executes a write
"1" when others
CS0 Chip Select 0 signal generated by Visor "0" when Visor writes or reads to CS0
memory region
"1" when others
CS1 Chip Select 1 signal generated by Visor "0" when Visor writes or reads to CS1
memory region
"1" when others
Notes:
1. By default, the CS0 memory region is mapped to address locations 0x28000000 to 0x28FFFFFF.
This region corresponds to the Flash address locations.
2. By default, the CS1 memory region is mapped to address locations 0x29000000 to 0x29FFFFFF.
This region corresponds to the SRAM address locations.
In the SRAM_Write_Enable equation, the SM_WE literal is generated by the A/D Interface.
SM_WE is declared to be "1" when the A/D interface is running, thereby making the entire
equation equal to "1". This enables the output buffer and since MUX_Sel is "1" when the A/D
Interface is active, the A/D conversion results can be written to SRAM.
When the conversions are complete, the A/D Interface declares SM_WE to be "0" and Mux_Sel
to be "0" so that the Handspring can either read the conversion results stored in SRAM or write
new data to SRAM.
Once the Visor is given control of the bus (i.e., SM_WE becomes "0"), the Visor can enable the
output buffer by executing a write to SRAM. A write operation to an address between
0x29000000 and 0x29FFFFFF (the default memory mapped region for CS1) will cause CS1
and WE to become "0", making the SRAM_Write_Enable equation true.
If needed, the Visor may also write to the Flash memory region that corresponds to CS0
(address 0x28000000 to 0x28FFFFFF). Doing this will create a falling edge on CS0 and WE.
The Visor can retrieve contents in SRAM by executing a read operation. Once again, an output
buffer will determine if the SP_D[15:0] pins will provide data to the Visor or if these pins will
send data to external components. This output buffer is controlled by the SRAM_Read_Enable
signal.
The equation for SRAM_Read_Enable is equal to:
OE & (CS0 + CS1)
If the Visor executes a read operation from SRAM, the CS1 and OE signals will go Low. The
SP_D[15:0] pins will then be allowed to output data to the Visor.

1-800-255-7778
R
Address Lines
The address lines originating from the Springboard Expansion Connector, “SP_A[23:1]”, are
routed through the CoolRunner. The SP_A[23:1] pins are connected internally to one input of
the address multiplexer, as shown in Figure 9. This Multiplexer has two inputs, one of which is
SP_A[23:1] and the other which is ADDR_COUNT. MUX_SEL, the same select signal for the
other multiplexers in this design, is used for the select line of this multiplexer.
A[23:1] is the output of this switch. This output bus is tied to external pins which are then routed
to the address lines of Flash and SRAM. Figure 9 illustrates this.
When the A/D Interface is active, MUX_SEL is set to "1". This allows the value of
SM_ADDRESS to determine the value of A[23:1].
The VHDL signal SM_ADDRESS is assigned for each write to SRAM. The value of
SM_ADDRESS is initialized for a specific input channel as specified in the VHDL "constants"
section discussed in section, Direct Mode, page 22. This address counter, SM_ADDRESS is
increment for each subsequent write to SRAM. The ADC will stop reading from the current
input channel once the SM_ADDRESS counter reaches the max address space for the current
input channel.
The Digital Volt Meter design shown in Hardware Implementation, page 28 writes to address
locations 0, 1, and 2 of SRAM for the ADC input channel 0.
23
SP_A[23:1] 0 23
23 A[23:1]
SM_ADDRESS 1
MUX_SEL
Figure 9: Address MUX
Chip Select 1
Figure 10 shows the Chip Select 1 multiplexer. A switch is needed in order to give the A/D
Interface the ability to control the CS pin of the SRAM. The SRAM CS pin is an active Low
signal that enables the SRAM chip. When CS is Low and RW (Write Enable) is Low, data will be
written to SRAM. When CS is Low and OE (Output Enable) is Low, the SRAM will output data
so a read operation can occur.
SPRING_CHIP1_ENn is the CS1 pin originating from the Visor’s expansion area.
STATE_MACHINE_SRAM_ENn is an internal signal that is controlled by the A/D Interface. The
SRAM_CHIP1_ENn signal is externally routed to the CS pin of the SRAM.
When the A/D Interface is active, MUX_SEL is "1" and hence the value of
STATE_MACHINE_SRAM_EN determines the value of the CS pin on the SRAM. When the A/D
Interface writes a conversion result to SRAM, it pulls the STATE_MACHINE_SRAM_EN signal
and the STATE_MACHINE_WE (see next page) signal Low.

1-800-255-7778
R
After the conversions are complete, MUX_SEL is set to "0" and the Handspring Visor can once
again perform its own read and write operations.
SPRING_CHIP1_ENn 0
SRAM_CHIP1_ENn
STATE_MACHINE_SRAM_ENn 1
MUX_SEL
X9504
Figure 10: Chip Select 1 MUX
Write Enable
Figure 11 shows the Write Enable Multiplexer. This multiplexer is needed in order to give the
A/D Interface the ability to control the RW (Write Enable) pin of SRAM. The RW pin is an active
low signal that, when used in conjunction with the CS pin, will enable a write operation to occur.
SPRING_WRITE_ENn is the Write Enable pin originating from the Visor’s expansion area.
STATE_MACHINE_WE is an internal signal that is controlled by the A/D Interface. The output
of the multiplexer, READ_WRITEn is externally routed to the RW pin of the SRAM.
When the A/D Interface is active, MUX_SEL is "1" and the value of STATE_MACHINE_WE will
determine the value of the SRAM RW pin. When the A/D Interface writes a conversion result to
SRAM, it pulls the STATE_MACHINE_WE signal Low and the STATE_MACHINE_SRAM_ENn
signal low. (See Chip Select 1, page 26 for an explanation of the
STATE_MACHINE_SRAM_ENn signal.
SPRING_WRITE_ENn 0
READ_WRITEn
STATE_MACHINE_WE 1
MUX_SEL
X9505
Figure 11: Write Enable MUX
Output Enable
Figure 12 shows the Output Enable multiplexer. This multiplexer is needed in order to give the
A/D Interface the ability to control the OE (Output Enable) pin of SRAM. The OE pin is an active
low signal that, when used in conjunction with the CS pin, will allow a read operation to occur.
SPRING_OUTPUT_ENn is the Output Enable pin originating from the Visor’s expansion area.
STATE_MACHINE_OE is an internal signal that is controlled by the A/D Interface. The output of
the multiplexer, OUTPUT_ENn is externally routed to the OE pin of the SRAM.
When the A/D Interface is active, MUX_SEL is "1" and the value of STATE_MACHINE_OE will
determine the value of the SRAM OE pin. When the A/D Interface writes a conversion result to
SRAM, it pulls the STATE_MACHINE_OE signal Low and the STATE_MACHINE_SRAM_ENn
signal Low. (See previous page for an explanation of the STATE_MACHINE_SRAM_ENn
signal.)

1-800-255-7778
R
SPRING_OUTPUT_ENn 0
OUTPUT_ENn
STATE_MACHINE_OE 1
MUX_SEL
X9506
Figure 12: Output Enable MUX
Hardware Usage Example

Implementation The following section is provided as an example for modifying the VHDL code to target a
specific application. Assume that in this application, the user wants to configure ADDR3,
ADDR5, ADDR6, and ADDR7 and that the ADS7870 must perform a conversion on all eight
input channels.
The following VHDL register "constants" have been edited for the following hardware
implementation. Note we are writing "0000 0100" to ADDR3, "0000 0101" to ADDR5, "0000
1111" to ADDR6, and "0011 1100" to ADDR7.
In the VHDL direct mode "constants" section, flags can be set to enable a single ended
conversion on a specific input channel of the ADC. For example, the DM_SNG_LN0_EN
constant is set to TRUE to enable a single ended conversion on input channel 0. To specify the
SRAM address space for each input channel, the SRAM_OFFSET0 constant is set to
"00000000000000000000000". SRAM_HIGH0 is set to "00000000000000000000111". This
represents that eight samples of channel 0 will be written to SRAM. Due to the pipelined nature
of the ADC, the conversion data stored at address 0 should be discarded. Therefore, SRAM
address 1 will store the first sample of channel 0. Also note, the SRAM address specified in the
VHDL code is 23 bits wide. This is because the Springboard address 0 (A0) is set to 0. This
means that A0 is appended to the SRAM address, and data is written to SRAM locations 0, 2,
4, etc.
--***************** ADDR0 (ADC OUTPUT REGISTER) ******************

-- Description: ADDR0 stores the LS Byte of the conversion result.
-- R/W : READ ONLY
constant RD_ADDR0_EN: BOOLEAN := FALSE;
constant ADDR0 : STD_LOGIC_VECTOR(7 downto 0) := ’01000000’; -- Read ADDR 0
--******************** ADDR1 (ADC OUTPUT REGISTER) ****************

-- Description: ADDR1 stores the MS Byte of the converstion result
-- R/W : READ ONLY
constant ADDR1 : STD_LOGIC_VECTOR(7 downto 0) := ’01000001’; -- Read ADDR 1
--********************* ADDR2 (PGA VALID REGISTER) ***************

-- Description: ADDR2 reveals if PGA has exceeded allowable values
-- R/W : READ ONLY
constant ADDR2 : STD_LOGIC_VECTOR(7 downto 0) := ’01000010’; -- Read ADDR2
--******************** ADDR3 (A/D CONTROL REGISTER) ***************

-- Description: ADDR3 configures CCLK Divider and read back mode operation
-- R/W : R/W

1-800-255-7778
R
-- Write/Read to Control Register

constant ADDR3 : STD_LOGIC_VECTOR(7 downto 0) := ’00000011’;
--********************* ADDR4 (GAIN/MUX REGISTER) ****************

-- Description: ADDR4 configures the PGA gain and the input channel
-- selection. (A direct mode operation will accomplish this as well)
-- R/W : R/W
constant WR_ADDR4_EN: BOOLEAN := FALSE;
-- Write/Read to Gain/Mux Register

--****************** ADDR5 (DIGITAL I/O STATE REGISTER) ***************

-- Description: ADDR5 sets/reveals the state of the digital IO pins.
-- R/W : R/W
-- Write/Read Digital I/O State Reg

--**************** ADDR6 (DIGITAL I/O CONTROL REGISTER) ***************

-- Description: ADDR6 determines whether each of the four IO pins will be
-- an output or and output
-- R/W : R/W
--**************** ADDR7 (REF/OSCILLATOR CONTROL REGISTER)************

-- Description: ADDR7 determines:
-- a) Whether the internal oscillator is used for the conversion clock
-- b) Whether the internal voltage reference and buffer are ON or OFF
-- c) Whether the voltage reference is 2.5V, 2.048V or 1.15V
-- R/W : R/W

--*************** ADDR24 (SERIAL INTERFACE CONTROL REGISTER) **********

-- Description: ADDR24 allows certain aspects of the serial interface to be
-- changed by the user
-- R/W : R/W
-- Serial Interface Control

--******************** ADDR31 (ID REGISTER) **********************

-- Description: ADDR31 reveals which version of ADS7870 is being used
-- R/W : READ ONLY

1-800-255-7778
R
-- ID Register
-- ********* DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 0 ************

’00000000000000000000000’;
’00000000000000000000111’;
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 1 *************

’00000000000000000001000’;
’00000000000000000001111’;

’00000000000000000010000’;
’00000000000000000010111’;

’00000000000000000011000’;
"00000000000000000011111";
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 4 **************

’00000000000000000100000’;
’00000000000000000100111’;
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 5 **************

’00000000000000000101000’;
"00000000000000000101111’;

’00000000000000000110000’;
’00000000000000000110111’;
-- ********* DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 7 **************

1-800-255-7778
R

’00000000000000000111000’;
’00000000000000000111111’;
ADC Initialization (Register Mode)

Using these VHDL "constants", the following ADC interface will be implemented:
1. Write data to Address 3, the “ADC Control Register” (ends with first rising edge of CS).
2. Write data to Address 6, the “Digital I/O Control Register” (ends with second rising edge of
CS).
3. Write data to Address 5, the “Digital I/O State Register” (ends with third rising edge of CS).
4. Write data to Address 7, the “Reference Oscillator Register” (ends with fourth rising edge
of CS).
5. Initiate three consecutive conversions on ADC input channel 0.
Note that CS goes High and SCLK temporarily stops in between commands (i.e., whenever
data has been written to ADDR3, ADDR6, and ADDR5). This is done because a rising edge on
CS will resynchronize the serial interface.
Note that in the beginning, DOUT tends to follow the CS pin. This is expected because of two
factors: first, the DOUT pin enters high impedance when CS is held High and second, the
DOUT pin is externally pulled up.
Step 1: Writing to ADDR3

Upon reset, the state machine will execute a register mode write to Address 3, the ADC Control
Register (See ADS7870 Datasheet). A value of DIN = “0000 0100” written to ADDR3 will
configure the A/D for Read Back Mode 1. In this mode, the serial interface configures itself to
clock out a conversion result as soon as a conversion is started. A read instruction is not
required to retrieve the result, thereby increasing the throughput rate by saving eight SCLK
cycles. The very first data read back will be discarded, but subsequent values pipeline the
conversion and readback activities.
This sequence requires a total of 16 SCLK cycles — eight bits to specify the Address, and eight
more to write data to that address. After these 16 bits are sent, the state machine will enter a

1-800-255-7778
R
wait state to resynchronize the serial interface. In this wait state, SCLK remains Low, and CS
is momentarily raised High. Figure 13 shows a logic analyzer trace of this sequence.
Figure 13: Writing to ADDR3

After exiting a wait state, the state machine executes a register mode write to Address 6, the
Digital I/O Control Register (See page 19 of A/D Datasheet). The ADS7870 configures all four
digital I/O pins as outputs by writing a data value of “0000 1111”.
As above,16 more SCLK cycles are required, followed by a wait state, to resynchronize the
serial port. Figure 14 shows a logic analyzer trace of this sequence.

1-800-255-7778
R

Next, the value of each I/O pin is configured to output a "1" or a "0". A pattern of DIN = “0000
0110” is transmitted to initiate an 8-bit write to Address 5, the Digital I/O State Register. The
ADS7870 will then output a "0" on I/O1, a "1" on I/O2, a "0" on I/O3, and a "1" on I/O4 by
sending “0000 0101” on the next sequence on DIN.
In this example, this test case is used with the Insight Handspring Development Board. Since
all four Digital I/O pins are routed into the CoolRunner CPLD, they are used to control the four
LEDs on the Insight Springboard Development Card. If the serial interface is working properly,
the LEDs should read On, Off, On, Off.
Writing to this register requires another sixteen SCLK cycles and a wait state. Note that it is not
absolutely necessary to write to ADDR6 and ADDR5. These two registers do not affect the
conversion result. However, these registers have been configured to illustrate how to use the
serial interface. In addition, they provide a convenient way to check the serial interface through
the LEDs. A logic analyzer trace of this sequence is provided below in Figure 15.

1-800-255-7778
R

The Reference/Oscillator Register, ADDR7, configures the reference and the buffer (page 19 of
ADS7870 Datasheet). After a pattern of “0000 0111” is sent to specify an 8-bit write to
ADDR7, a sequence of “0011 1100” is written to this register.
The OSCR and OSCE bits are now set to "1". Enabling the OSCE bit will power the internal
oscillator, and CCLK will output a 2.5 MHz signal. Setting the OSCR bit configures the
ADS7870 to use this 2.5 MHz internal clock for the reference. The REFE and BUFE bits are
also enabled. This turns on the Reference and the Buffer. And finally, by setting R2V and RBG
bits to "0", VREF is set to 2.5V. This sets the maximum full-scale input to 2.5V in single ended

1-800-255-7778
R
mode. Sixteen more SCLK cycles and a wait state are needed, and a logic analyzer trace of this
sequence is shown in Figure 16.
Direct Mode Conversions

Direct Mode Command 1
At this point, all registers have been properly configured, and the state machine is ready to
send the first direct mode command to initiate a single conversion. Assuming that the LN0
input (an analog input of the ADS7870) is tied to the voltage site (test point), eight bits, “1000
1000” are sent through the DIN pin. This commands the A/D to start a conversion on input
channel LN0, which has been configured as single ended, with the PGA (Programmable Gain
Amplifier) gain set to "1".
Since Address 3 is configured for Read Back Mode 1, the ADS7870 will begin clocking out the
result of the previous conversion immediately after the 8-bit direct mode command. Therefore,
16 more SCLK cycles are sent to the ADS7870. Thus, for this entire sequence, a total of 24
SCLK cycles are needed, eight for the direct mode command, and 16 for the result.
Note however, that on the last 16 clock cycles, DOUT remains Low. This is expected.
Remember that the first result coming out of the ADS7870 is always invalid, due to the fact that
the result is from the previous conversion.
Figure 17 actually shows more than 24 SCLK cycles instead of the 16 SCLK cycles that have
been shown in the previous figures. This is done in order to show BUSY going High and then
Low after the first direct mode command.

1-800-255-7778
R
In reality, when we are chaining several conversions together, the CoolRunner does not need to
monitor the BUSY pin. BUSY is shown just to confirm that a conversion is taking place.
Figure 17: Direct Mode Command 1

The second direct mode command is issued on the next rising edge of SCLK (i.e., on the 25th
clock edge starting from when the first direct mode command sequence was issued).
Again, 24 SCLK cycles are needed for this second frame. The same 8-bit direct mode
command of “1000 1000” is sent, but this time, notice that DOUT is driving data. This data is

1-800-255-7778
R
the result of the first conversion. The result of this second conversion is returned in the next
frame as shown in Figure 18. .
Within the frame of this example, DOUT reads “0000 1001 1011 0000”. Since the ADS7870 is
set for Read Back Mode 1, the MS Byte of the conversion result is returned first. In other words,
ADDR1 will clock out first, followed by ADDR0. (The Texas Instruments ADS7870 datasheet
provides details of ADDR1 and ADDR0).
Table 4: Contents of ADDR1, the MS Byte

D7 D6 D5 D4 D3 D2 D1 D0
ADC11 ADC10 ADC9 ADC8 ADC7 ADC6 ADC5 ADC4
0 0 0 0 1 0 0 1
Table 5: Contents of ADDR2, the LS Byte

D7 D6 D5 D4 D3 D2 D1 D0
ADC3 ADC2 ADC1 ADC0 0 0 0 OVR
1 0 1 1 0 0 0 0
The 12-bit output code in this example is “0000 1001 1011”. This is equal to +155. The
corresponding measured voltage would then equal:
(155 / 2047) * 2.5 = 0.189 Volts
It may also be of interest to see that this second direct mode command was issued when the
first conversion was still in progress (Note the BUSY pin). The ADS7870 places this next

1-800-255-7778
R
conversion in queue and allows the current conversion to finish. Maximum throughput is
obtained through this method, as the next conversion will begin immediately after the previous
one finished. Again, note how the BUSY pin goes low then high during the conversion cycle.

Figure 19 shows the third direct mode command. Like the previous direct mode command, this
frame initiates a third consecutive conversion and retrieves the result of the second conversion.
Note, only three direct mode conversion cycles are shown for single ended input channel LN0.
The implemented design allows for eight direct mode conversion cycles on each input channel
of the ADC.
Conclusion The ADS7870 interface presented in this document is an easy to use reference design that will
allow for quick customizing of the Insight Springboard Development Card. Regardless of
whether a designer understands the VHDL language, the designated "constants" section of the
VHDL code can be modified to configure the ADS7870 in a way that best complements a
specific Springboard design. After modification, simply implement the design and program the
CoolRunner CPLD. The inherent low power characteristics of the CoolRunner CPLD will come
at no cost, and users will recognize the advantages of programmable logic.
References Texas Instruments ADS7870 Data Sheet located at http://www.ti.com/

1-800-255-7778
R
VHDL Code VHDL source code and test benches are available for this design. THE DESIGN IS PROVIDED
Download TO YOU "AS IS". XILINX MAKES AND YOU RECEIVE NO WARRANTIES OR CONDITIONS,
EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, AND XILINX SPECIFICALLY
DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT,
OR FITNESS FOR A PARTICULAR PURPOSE. While this design has been verified on
hardware, it should be used only as an example design, not as a fully functional core. XILINX
does not warrant the performance, functionality, or operation of this design will meet your
requirements, or that the operation of the design will be uninterrupted or error free, or that
defects in the design will be corrected. Furthermore, XILINX does not warrant or make any
representations regarding use or the results of the use of the design in terms of correctness,
accuracy, reliability or otherwise.
History
01/03/02 1.1 Minor revisions.

1-800-255-7778
R

1-800-255-7778
Application Note: CoolRunner™ CPLD
R
Wireless Transceiver for the CoolRunner
CPLD
XAPP358 (v1.0) June 25, 2001
Summary This document focuses on the design of a wireless transceiver using an XPLA3™
CoolRunner™ CPLD. The wireless transceiver is implemented using the CoolRunner XPLA3
demo board from Insight Electronics. The wireless transceiver is the perfect application of the
low power capabilities of a CoolRunner CPLD. To obtain the VHDL code described below go to
the section titled “VHDL Disclaimer and Download Instructions” on page 11.
Introduction A wireless transceiver consists of two modules; receive, and transmit. One CoolRunner demo
board comprises the receive portion while the second demo board comprises the transmit
portion. The design transmits the text string "CooLrunnEr," which is displayed on both the
transmit and receive demo boards. The wireless communication is controlled by an RF module
designed by RF Monothilics, Inc. (RFM®).
The protocol designed for the wireless transceiver obeys a custom wireless communication
protocol. A designer could change the protocol has needed to meet the needs of a specific
application.
The addition of keyboard control is also covered in this document. The VHDL code is not
provided for this portion of the design. With keyboard control, a user can enter a text string into
the transmitter and the string would be display on the receive side of the transceiver. The
keyboard described is manufactured by Fujitsu Takamisawa America, Inc. (FBK7603)
(www. fujitsu.takmisawa.com/pdf/EvalKits.pdf).
Figure 1: CoolRunner Wireless Transceiver
CoolRunner This section describes the operation of the transceiver. The communication protocol is a
CPLD custom transmit and receive scheme, using Manchester encoding and Bit-Oriented Protocol
(BOP) theory.
Transceiver
Operation Communication Protocol
The communication protocol is show in Figure 2. The preamble and postamble are used to
contain the data to be transmitted. The total transmission is 36 bits. For error checking, the data
is transmitted four times and compared to insure the proper data was received.
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 41

1-800-255-7778
R
Data [11:0]
PREAMBLE POSTAMBLE
LSB
010101010101 111100001111
Start Flag [11:0] End Flag [11:0]
X358_02_062001
Figure 2: Communication Protocol
Transmit
A Manchester encoding scheme is used between the transmit and receive modules.
Manchester coding ensures that each bit of the data is D.C. balanced. Also, this coding scheme
provides an edge within each bit period that can be used to align the receiver’s clock if needed.
However, Manchester coding requires twice the bandwidth as compared to NRZ (Non-Return-
to-Zero) codes. To decrease bandwidth, a symbol table is used. It consist of sixteen different
symbols that can be generated using six bits which guarantees that no more than four
consecutive bits are the same. This scheme requires only 1.5 times the bandwidth when
compared with NRZ coding. For more information on Manchester and NRZ coding schemes,
refer to the application note XAPP339 “Manchester Encoder-Decoder for Xilinx CPLDs”
(http://www.xilinx.com/xapp/xapp339.pdf).
Receive
BOP is utilized on the receive side of the transceiver. BOP takes advantage of opening and
closing flag insertion and deletion and zero bit insertion and deletion. Once an edge is
detected, the incoming data is sampled and stored in a shift register. Once the most significant
bits are equal to the postamble, the 12-bit data is stored in a register. This process occurs four
times. This insures the data has time to be displayed on the LCD of the CPLD demo board and
allows for more accurate error checking.
CoolRunner Transmit
CPLD The transmit block diagram is shown in Figure 3. Transmission comprises of three VHDL
Transceiver entities; DISPLAY_COUNT, SHIFT_ENABLE, and SHIFT_OUT. These three logic modules are
controlled by the top level module, TX_MODULE. DISPLAY_COUNT controls the LCD
Block Diagram common line, LCDCOM, which minimizes charging in the LCD. DISPLAY_COUNT also
controls the time between display states. Each state determines which two digits are displayed
on the LCD. It pulses the SWITCH_EN_H signal when it is time to change to the next state. This
control line tells the SHIFT_ENABLE module to output the next state number, CUR_STATE, to
the CHANGE_STATE look up table. When this is completed, it pulses the LOAD_DATA_H
signal to tell the SHIFT_OUT module to load the current state data, CUR_STATE_DATA, output
by the CHANGE_STATE look up table. This module also keeps track of how many
transmissions have been sent. It pulses the LOAD_DATA_H signal four times for each state,
controlling the time between transmissions. The data is sent four times to provide error
checking on the receive side (See Receive). When SHIFT_OUT observes that LOAD_DATA_H
has been pulsed, it loads the current state data, and begins to send the data, with a preamble
and postamble, one bit at a time, to the RF module.
42 www.xilinx.com XAPP358 (v1.0) June 25, 2001

1-800-255-7778
R
The CONTROL signal is controlled by the TX MODULE which enables the RF MODULE to be
in transmit mode. SYS_CLK_H and SYS_RST_L are external signals that are used as the
system clock and the global system reset.
LCD
LCDCOM
DIGIT1 [8:0] DIGIT2 [8:0]
TX MODULE
SYS_CLK_H
SYS_RST_L SWITCH_EN_H
DISPLAY_COUNT SHIFT_ENABLE
LOAD_DATA_H CUR_STATE
[8:0]
CUR_STATE_DATA
DISPLAY_COUNT CHANGE_STATE
[8:0]
CONTROL
TX
RF MODULE
X358_03_062001
Figure 3: Transmit Module Block Diagram
Receive
The receive block diagram is shown in Figure 4. The data is read on the RX pin and shifted into
a 3-bit shift register, RXIN, on every clock cycle. When an edge is detected (a logic 1) in the
least significant bits of RXIN, a counter is enabled. This counter counts to approximately 3/4 of
the bit period (due to non-ideal conditions, see Figure 5), samples the data, and shifts the bit
into a 36-bit data register, SHIFT_DATA (see Figure 10). If there are consecutive bits in the
stream, the counter continues to count 3/4 into the next bit period and samples the data again.
If there is another edge detected, it restarts the counter, to keep the possibility of error due to
drift to a minimum. Once the postamble is seen in the most significant 12 bits of the 36-bit shift
register, the 12 bits of data are stored into a temporary register, REG1 through REG4, and the
module gets ready for the next transmission. After the fourth transmission, if any two of the
temporary registers are equal, the data is symbolized using the RX_SYMBOLIZE function, and
the data is sent to the LCD.
LCDCOM minimizes charging in the LCD. The CONTROL signal is controlled by the receive
MODULE which enables the RF MODULE to be in receive mode. SYS_CLK_H and
SYS_RST_L are external signals that are used as the system clock and the global system
reset.

1-800-255-7778
R
LCD
LCDCOM
RX MODULE
SYS_CLK_H
REG1 [12:0]
SYS_RST_L REG2 [12:0]
CHANGE_STATE
REG3 [12:0]
REG4 [12:0]
SHIFT_DATA [35:0]
RXIN [3:0]
CONTROL
RX
SHIFT OUT ONCE EDGE

DETECTED
RF MODULE
X358_04_062001
Figure 4: Receive Module Block Diagram

Ideal Sampling Illustration
New Bit
Sample Period (1/2 Bit Period)
Non-Ideal Sampling Illustration
New Bit
Sample Period (~3/4 Bit Period)

X358_05_062001
Figure 5: Receive Module Block Diagram

1-800-255-7778
R
CPLD Transmit Transmit module contains the look up tables: CHANGE_STATE, RX_SYMBOLIZE, BIN7SEG.
Design The latter two are used to display the letters being transmitted. CHANGE_STATE changes the
current state of TX_MODULE (the data to be transmitted), which is sent from the
SHIFT_ENABLE logic module. The logic function RX_SYMBOLIZE is a look up table to convert
6-bits of each digit of data into a 4-bit number. BIN7SEG is a lookup table that takes the 4-bit
symbolized number from the RX_SYMBOLIZE function and converts it into an 8-bit number
sent to the LCD digits. The block diagram for TX_MODULE is shown in Figure 6.
SYS_RST_L SYS_CLK_H
TX MODULE
SHIFTENABLE
CUR_STATE [3:0]
SHIFT_OUT
RX_SYMBOLIZE
TX_DATA [35:0]
[5:0] [11:6]
[3:0]
TX_DATA
DISPLAY_COUNT
RX_SYMBOLIZE [3:0] BIN7SEG

LCDCOM LCDCOM
LCD
X358_06_062001
Figure 6: TX_MODULE Block Diagram
Display Count
The DISPLAY_COUNT block diagram is shown in Figure 7. This logic module controls the time
between each state and the LCDCOM signal. STATE_COUNT is incremented and then
enables SWITCH_EN_H. SWITCH_EN_H then enables the logic module SHIFT_ENABLE to
change state (transmit new data).
DISPLAY_COUNT
SHIFT_ENABLE
SWITCH_EN_H
STATE_COUNT
TX_MODULE
COUNT
SYS_CLK_H
SYS_RST_L
X358_07_062001
Figure 7: Display Count Block Diagram

1-800-255-7778
R
Shift Enable
The SHIFT_ENABLE logic module increments the state variable to change states, and sends
an edge to an enable signal (LOAD_DATA_H) to update a register in the SHIFT_OUT module
with the new state value. The block diagram is shown in Figure 8.
TRANS_BETWEEN_COUNT determines the time between each state. TRANS_COUNT
controls the number of transmissions between states.
SHIFT_ENABLE
CUR_STATE [3:0]
TX_MODULE
LOAD_DATA_H
SHIFT_OUT TRANS_COUNT
DISPLAY_COUNT
TRANS_BETWEEN_COUNT
SWITCH_EN_H
SYS_CLK_H
SYS_RST_L
X358_08_062001
Figure 8: SHIFT_ENABLE Block Diagram
Shift Out
The SHIFT_OUT logic module sends the TX_DATA to TX_MODULE for transmission.
LOAD_DATA_H enables the SHIFT_OUT module to load the current data. The block diagram is
shown in Figure 9.
SHIFT_OUT
TX_DATA[35:0]
SHIFT_ENABLE
TX_MODULE
PREAMBLE[11:0]
LOAD_DATA_H
CUR_STATE_DATA[11:0]
POSTABLE[11:0] CUR_STATE_DATA[11:0]
SYS_CLK_H
SYS_RST_L
X358_09_062001
Figure 9: SHIFT_OUT Block Diagram
Receive Module Receive

Edge Detection The receiver operation is included in one receive VHDL entity shown in Figure 4. Figure 10
shows the edge detection and sampling scheme of the ideal sampling model. Once an edge is
detected, a counter insures the correct sampling and thus the storing of transmitted data. If
non-ideal conditions exist, the location of sampling may need to be changed (see Figure 5).

1-800-255-7778
R
The counter size and value used to sample the incoming bits is determined by the system clock
and the baud rate. The RF module allows for a baud rate between 2.4 Kbps to 19.2 Kbps. With
a 32.7 KHz clock, a 2.4 Kbps can be accurately modeled with a 5-bit counter. If the user wishes
to change the baud rate, the value of the sampling counter must also be changed.
Further, the counter is re-initialized when a edge is detected. As previously discussed, this
allows drift to be reduced to a minimum. Therefore, it is recommended that an encoding
scheme which does not allow for long lengths of consecutive bits in the stream be used.
SHIFT_DATA [35:0]
Initialize 0000000000000000000000000000000000000
0101 Edge Detected
Edge
Pulse Width Enable Counter
Based on baud rate

Increment counter on rising
edge of system clock
Sample at 1/2 pulse width.

Bit Stored Determine where to sample based
on value of counter
SHIFT_DATA [35:0]
1000000000000000000000000000000000000 Store Data
X358_10_062001
Figure 10: Receive Edge Detection
Hardware The following describes the hardware used to develop the CoolRunner CPLD wireless
Description transceiver.
RF Hardware
The RF transmission was preformed by the DR3000 module, manufactured RFM. The DR3000
is designed for short-range and low power applications with a carrier frequency of 916.5 MHz.
Both On-Off Keyed (OOK) and Amplitude-Shift Keyed (ASK) modulation schemes are
supported by the DR3000 module. The transceiver utilizes an Amplifier-Sequenced Hybrid
(ASH) architecture and supports 2.4 to 19.2 Kbps baud rates. The baud rates can be controlled
with additional hardware changes to the RF module. The CoolRunner transceiver utilizes the
2.4 Kbps transmission. The 2.4 baud rate was chosen due to the clock frequency available on
the CPLD demo board.
CPLD Hardware
The CoolRunner XPLA3 demo board from Insight Electronics is used for the CoolRunner
wireless transceiver. The demo board contains a two-digit LCD, 32.768 KHz clock, prototyping
area and the Xilinx CoolRunner XPLA3 XCR3256XL TQ144 CPLD.

1-800-255-7778
R
Hardware Setup
If using the AC adapter provided with the CoolRunner demo board, ensure that the resister, R7
(refer to the DR300 data sheet), is removed from the DR3000. If R7 is not removed, the
DR3000 will heat up and no longer function properly. Also, ensure the RF module is attached to
a proper power/ground plane to minimize ground loops.
The DR3000 requires a level shifter to correctly drive the CPLD I/O pin (see Figure 11). The RF
module can not drive loads stronger than 500k ohms.
R=100K
RF DMOS FET
CPLD
Data Out
I/O Pin 99
(XPLA3 TQ144 Pin 122)
X358_11_062001
Figure 11: Additional MOSFET Circuitry
Keyboard Entry The following is a design implementation option for using keyboard entry with the CoolRunner
Option wireless transceiver. CPLD design implementation is left to the user to develop.
PS/2® Protocol
The keyboard interfaces with the CPLD using the PS/2 protocol. The PS/2 protocol works on
serial communication between a host and a peripheral device. The bus can be in three states:
idle, inhibit, and request to send. The device can transmit a byte to the host only when the bus
is idle. In order for the bus to be idle, both the CLK and DATA pins must be high (logic 1). Table 1
is the pin layout for the PS/2 cable.
Table 1: PS/2 Cable Pin Configuration

Pin 1 PS/2 DATA
Pin 2 N/C
Pin 3 GROUND (0V)
Pin 4 POWER (+5V)
Pin 5 PS/2 CLK
Pin 6 N/C
The byte transmission includes a start bit (logic 0), eight data bits (LSB first), a parity bit (odd
parity), and a stop bit (logic 1). The transmission occurs by having the device transmit a byte of

1-800-255-7778
R
data by pulsing the CLK low and high 11 times, sampling the DATA line. Figure 12 depicts the
waveform for one PS/2 transmission.
CLK CLK CLK CLK CLK CLK

1 2 3 9 10 11
START
BIT 0 BIT 1 BIT 7 PARITY STOP
BIT
BIT
X358_12_062001
Figure 12: PS/2 Transmission Waveform
Hardware Description
In order to use a keyboard, a keyboard encoder must be used to manipulate data. The
keyboard encoder used for this implementation is the Semtech Greencoder™ (UR5HCFJL)
Zero Power™ Keyboard Encoder for Portable Systems. This keyboard encoder is the device
used between the keyboard and the peripheral device. It works on a matrix (8 X 16) format with
the capability to support a 128 key keyboard. The keyboard encoder has three states that it
operates in: sleep, stand by, and active. These states are used to efficiently manage power
consumption, making this device a good fit for use with CoolRunner. The keyboard encoder
used for this design implementation can function using 3V, 3.3V, or 5V and uses the PS/2
protocol to receive data from the keyboard.
CoolRunner The CoolRunner transceiver is built using the CoolRunner XPLA3 Development Kit from Insight
XPLA3 CPLD Electronics. Table 2 details the I/O pins on the demo board to the pins used on the XPLA3 256
macrocell part in the TQ144 package.
Implementation
Table 2: Prototyping Area I/O Cross Reference
Transceiver Signal Prototyping Area I/O XPLA3 Pin Number
RX I/O 99 119
TX I/O 106 138
CONTROL I/O 104 136
The wireless transceiver Receive module utilization in an XPLA3 256-macrocell device is

shown in Table 3. The total utilization for the Receive Module allows room for additions and/or
improvements to the design.
Table 3: CoolRunner XPLA3 256-Macrocell Utilization for Receive

Resource Available Used Utilization (%)
Macrocells 256 168 65.63
P-terms 768 465 60.55
I/O Pins 116 20 17.25

1-800-255-7778
R
The Transmit module utilization in an XPLA 256-macrocell device is shown in Table 4. Again,
the total utilization for the transmit portion of the design allows room for addition and/or
improvements to the design.
Table 4: CoolRunner XPLA3-256 Macrocell Utilization for Transmit

Resource Available Used Utilization (%)
Macrocells 256 118 46.10
P-terms 768 202 26.31
I/O Pins 116 20 17.25
Design Verification
The design was verified in simulation and hardware implementation described previously in this
document.
VHDL VHDL source code and test benches are available for this design. THE DESIGN IS PROVIDED
Disclaimer and TO YOU “AS IS”. XILINX MAKES AND YOU RECEIVE NO WARRANTIES OR CONDITIONS,
EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, AND XILINX SPECIFICALLY
Download DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGMENT,
Instructions OR FITNESS FOR A PARTICULAR PURPOSE. XILINX DOES NOT WARRANT THE
PERFORMANCE, FUNCTIONALITY, OR OPERATION OF THIS DESIGN WILL MEET YOUR
REQUIREMENTS, OR THAT THE OPERATION OF THE DESIGN WILL BE
UNINTERRUPTED OR ERROR FREE, OR THAT DEFECTS IN THE DESIGN WILL BE
CORRECTED. FURTHERMORE, XILINX DOES NOT WARRANT OR MAKE ANY
REPRESENTATIONS REGARDING USE OR THE RESULTS OF THE USE OF THE DESIGN
IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY OR OTHERWISE.
XAPP358 - http://www.xilinx.com/products/xaw/XAPP358.htm
Conclusion This document has detailed the design of the CoolRunner CPLD logic for a wireless
transceiver. The design is targeted for a 3.3V, 256 macrocell CoolRunner CPLD (XCR3256XL
TQ144). This device, as well as the RF module discussed in this paper, has extremely low static
and dynamic power dissipation and therefore is ideally suited for this application. The design of
the CoolRunner wireless transceiver is also provided as an example of using a CoolRunner
CPLD in a portable application and can be extended to many other types of portable
applications
References 1. Zetez Semiconductors Data Sheet - ZVNL110A N-Channel Enhancement Mode Vertical
D(Double Diffused) MOS FET
2. USAR GreenCoderTM Evaluation Board Data Sheet - EVK5-FJL-7603-200
3. Anthes, John. "Unique Considerations for Data Radio UARTs." RF Monolithics, Inc.
4. RF Monolithics Data Sheet - DR3000 916.5 MHz Transceiver Module
Acknowled- The CoolRunner wireless transceiver was development with the senior design team (May 01) of
gements the University of New Mexico (UNM), Electrical and Computer Engineering Department.
Design team included: Erin Isaacson (Xilinx), Lisa Burckel (UNM), Jeremy Dencklau (UNM),
Kristina MIller (UNM), Parveen Sidu (UNM).
Additional thanks to Jim Beneke, Dennis Schlaht, and Lara Kieltyka of Insight Electronics and
Bruce DeVisser of Fujitsu Takamisawa who donated time and equipment to the transceiver
project.

1-800-255-7778
R
History Date Version Revision

1-800-255-7778
R

1-800-255-7778
Application Note: CoolRunner-II CPLDs

Summary This application note describes the implementation of a Smart Card Reader design with a
CoolRunner™-II CPLD. Different from most of the software-based smart card reader computer
systems, this CoolRunner-II CPLD implementation is a hardware solution. There is no software
development needed in this design. This application note explains the low-level protocol of the
Smart Card Reader and its hardware implementation.
CoolRunner-II devices are the latest CPLDs from Xilinx that offer both low power and high-
speed. A VHDL code for Smart Card Reader design is available with this application note: see
Source Code, page 67
Introduction A smart card is a credit card sized plastic card with an embedded microprocessor and memory
and is used for identification, access, and conducting financial transactions.
Figure 1: Smart Card Reader

1-800-255-7778
R
Acting like a mini-computer, smart cards allow money and information to be electronically
stored and transferred in a secure but portable medium. When inserted into a reader or passed
over a scanner, the smart card transfers data to and from a central computer. Overall, it is a
replacement for old means of retaining data and transacting business.
There are two fundamental sides of development for any smart card application: the host-side
and card-side. Software programming tends to comprise most of the effort involved in smart
card development. The host software runs on a computer connected to a smart card, and the
card software runs on the card as a counterpart to the host software.
In this application note we use a CoolRunner-II CPLD to build a smart card reader, creating a
host-side design to replace a host computer system. The function of a smart card reader is to
read the card content and display the decoded information on a character LCD display. Unlike
standard smart card readers, though, this CoolRunner-II reader relies on hardware design
rather than software programming to perform these tasks.
Smart Card The block diagram of the CoolRunner-II smart card reader is shown in Figure 2. The dashed
Reader Block area shows the logic that is contained in the CoolRunner-II CPLD. All the other blocks are
external devices that can be obtained commercially. The CPLD logic blocks and the external
Diagram devices in this diagram are briefly described in the following section.
Smart Card Acceptor

Level Shifter
Smart Card Control
SRAM
SRAM Interface
Main Control Logic
LCD Control LCD Display
CoolRunner-II CPLD
X372_02_090803
Figure 2: Smart Card Reader Block Diagram
CoolRunner-II Main Control Logic

CPLD Modules The Main Control Logic block provides the system flow control. It reads data from smart card
control, writes to SRAM, activates LCD control and sends decoded information to the LCD
control.
Smart Card Control

Smart Card Control logic communicates with the smart card through the external level shifter.
It uses a predefined communication protocol and commands. The data length for each field is
also hard coded in this design.

1-800-255-7778
R
SRAM Interface
SRAM Interface logic interfaces to the external SRAM. This logic block controls the SRAM
read/write addressing. Smart card data is saved in SRAM and later fetched and decoded for the
LCD display.
LCD Control
LCD control logic interfaces to the LCD Display. This logic block accepts the decoded data and
writes to the LCD Display.
External Level Shifter

Devices The On semiconductor NCN6011 is a level shifter (analog device) to translate the voltages
between a smart card and CoolRunner-II CPLD. This device handles all the 5V signals needed
for the smart card and 1.8V signals for the CoolRunner-II CPLD. It is transparent to the smart
card control logic in the CPLD.
LCD Display
The OKAYA RC1602ARS is a 16-character x 2-line, dot matrix, liquid crystal display module. It
has an on-board controller and LSI drivers, which display alpha numerics, Japanese KATA
KANA characters and a wide variety of other symbols in 5 x 7 dot matrix.
SRAM
A low power, 32k x 8 ISSI IS61LV256 SRAM is used in the module memory. The functionality of
the SRAM does not require additional explanation. For more in-depth SRAM information refer
to the ISSI SRAM data sheet.
Smart Card Acceptor

The Amphenol C702 10M008 2834 is a low cost smart card acceptor. It provides a direct sliding
contact between the acceptor and the smart card. This acceptor has a “NC closed card present
switch” which opens when the card is fully inserted. The switch activates the smart card reader
operation.
Smart Card Smart Card is defined by the international standard ISO 7816. The first two parts cover smart
Standard ISO card’s physical dimensions and locations of the chip contacts. A smart card image and its
contacts are shown in Figure 3.
7816
10.25mm
19.23mm
53.98mm
VCC GND
RST VPP
CLK I/O 85.6mm
RFU RFU
X372_03_090803
Figure 3: Smart Card Image and Contacts

1-800-255-7778
R
ISO 7816-3 & -4 govern the electronic signals, transmission protocols and inter-industry
commands for interchange. In this application note we limit the discussion to its transmission
protocols and some basic commands.
ISO 7816-5 to –8 cover the number system, data elements, card SQL and security commands.
These parts are not used by this reference design and will not be discussed in this application
note.
Operating This section details the ISO 7816-3 inter-operation between the smart card and the host
Procedure device.
• Connection and activation of the contacts
• Reset of the card
• Answer to Reset
• The T=0 communication protocol
Connection and activation of the contacts

The activation of the contacts by the host device consists of the consecutive operations:
• RST is L
• VCC is powered
• I/O in the interface device is in reception mode
• VPP is raised to idle state
• CLK is provided with a suitable, stable clock
Reset of the card

The host device initiates a reset to smart card and the card responds with an Answer to Reset
within 40000 clock cycles with Reset in state H. If an Answer to Reset does not occur, the Reset
returns to state L and the smart card contacts are deactivated by the host.
Answer to Reset
There are two types of transmission defined in ISO 8616-3 for answer to reset: asynchronous
and synchronous transmission. In this application note we only discuss asynchronous
transmission.
In asynchronous transmission, characters are transmitted on the I/O line in an asynchronous
half-duplex mode. The normal bit duration used on I/O is defined as one Elementary Time Unit
(etu). The initial etu is 372/fi second where fi is in Hertz. All are initially operated with fi in the
range of 1 MHz to 5 MHz.
A character consists of ten consecutive bits plus a guard time as follows:
• Start bit, used for character frame synchronization
• 8 data bits of information
• Parity bit, even parity for error detection
The guard time is separation between characters. Figure 4 is a diagram for asynchronous
character frame.

1-800-255-7778
R
Start Bit Parity Bit Next Start

8 Data Bits
Bit
Z
I/O ba bb bc bd be bf bg bh bi Guardtime
X372_04_090803
Figure 4: Asynchronous Character Frame
The Answer to Reset is at most 33 characters and consists of 5 fields,

• The initial character (TS)
• The format character (TO)
• The interface characters (TAji, TBji, TCji, TDji)
• The historical characters (T1, T2 ... TK)
• The check character (TCK)
Each of these fields is sent in order as shown in Figure 5.

1-800-255-7778
R
TS The Initial Character
TO The Format Character ... codes Y1 and IC
TA1 _ _ _ _ The Interface Characters Global, codes F1 and D1
TB1 _ _ _ _ Global, codes F1 and D1
TC1 _ _ _ _ Global, codes N
TD1 _ _ _ _ codes Y and T
TA2 _ _ _ _ Specific, codes modes features
TB2 _ _ _ _ Global, codes F12
TC2 _ _ _ _ Specific
TD2 _ _ _ _ codes Y1 and T
TA3 _ _ _ _ TA, TB, TC, are specific TD, code Y1-1 and T
T1 The Historical Characters

(maximum of 15 characters)
TK
TCK The Check Character
X372_05_090803
Figure 5: Answer to Reset Configuration
The initial character TS determines the data transmission rate and also determines the sense
of the logic. The format of the TS character is shown in Figure 6. This shows the two
possibilities of the direct and inverse convention, where logic level one is A, Ba is MSB for
inverse and logic level one is Z, and Ba is LSB for the direct convention.

1-800-255-7778
R
Start
Z
ba bb bc bd be bf bg bh bi
Inverse Convention
Start
Z
ba bb bc bd be bf bg bh bi
Direct Convention
X372_06_090803
Figure 6: Initial Character TS
The format character TO provides information necessary to interpret the remaining answer to
reset characters. See TO in Figure 7. the most significant half byte, b8 to b5, indicates the
presence of TA1 to TD1. The least significant half byte, b4 to b1, indicates the number of
historical characters.
TA1 defines the basic characters of the serial transmission. F1 is the clock rate conversion
factor and D1 is the bit-rate adjustment factor. F1 and D1 are compared against a table in the
ISO 7816-3 standard to achieve actual values of F and D in the table to define the actual work
etu.
TB1 is used to define the EPROM programming voltage and current. TC1 provides the value of
N, which defines the extra guard time to be used between successive characters. The first half
byte of TD1 indicates the presence of TA2 to TD2. The second half byte of TD1 indicates the
protocol type T=0 to T=15.

1-800-255-7778
R
Bit Map No. of Historical Bytes
T0 8 5 4 1
(format character)
F1 D1
TA1 8 5 4 1
I1 PI1
TB1 0 7 6 5 1
TC1 8 1
Bit Map Protocol Type
TD1 8 5 4 1
X372_07_090803
Figure 7: Format and Interface Characters
The historical characters may be used to convey information relating to the life cycle of the card.
The check character should not be sent when only the T=0 protocol is indicated in the answer
to reset. In all other cases TCK is sent as the last character of the answer to reset. The value
of TCK is such that the exclusive-or of all bytes from T0 to TCK included is equal to zero.
The T=0 Communication Protocol

The interface device always initiates the command for the T=0 protocol. Interaction between the
interface device and the card results in successive commands and responses. The message
flow for the T=0 protocol is shown in Figure 8.

1-800-255-7778
R
A: DATA sent from Interface Device [IFD] to ICC
ICC IFD
CLA INS P1 P2 P3
Procedure
Byte
DATA
Status Bytes
SW1 SW2
B: DATA sent from ICC to IFD
ICC IFD
CLA INS P1 P2 P3
Procedure
Byte
DATA
Status Bytes
SW1 SW2
X372_08_090803
Figure 8: The T=0 Protocol
In Figure 8. IFD is the smart card controller and ICC is the smart card. The command header
consists of the following 5 bytes,
• CLA, the instruction class
• NS, the instruction code
• P1, instruction code qualifier (e.g. memory address)
• P2, additional INS code qualifier
• P3, the length of the data block
The response from the card has two status bytes, SW1 and SW2, to indicate the current card
status. The normal response is SW1, SW2 = 90, 00 hex. When SW1 = 6x or 9x various error
conditions are reported by the card.
Table 1 and Table 2 show some of the CPA classes and INS commands. In this design we use
ISO 7816-4 instruction class 80 and some basic INS codes such as A4, Select File, B2, Read
Record and C0, and Get Response to read all the information we need.

1-800-255-7778
R
Table 1: CLA Instruction Set

CLA Type Instruction Set
0X ISO 7816-4 instructions
10 to 7F Reserved for future use
8X or 9X ISO 7816-4 instructions
AX Application/Vender specific instructions
B0 to CF ISO 7816-4 instructions
D0 to FE Application/Vender specific instructions
FF Reserved for protocol type selection
Table 2: INS Commands

INS Value Command Name
0E Erase Binary
20 Verify
82 External Authentication
88 Internal Authentication
A4 Select File
B0 Read Binary
B2 Read Record
C0 Get Response
C2 Envelope
D0 Write Binary
CoolRunner-II The CoolRunner-II smart card reader design uses the Advanced Card System ACOS1
Implementation microprocessor-based card. The information read from the card includes name, gender, status,
age, and bank balance. gender, status and age are encoded in the same data record.
The initial character TS was programmed to direct convention, and format character and
interface characters are predefined. T=0 protocol is used so there is no TCK in answer to reset.
There are 19 bytes, including historical characters transmitted for answer to reset. To simplify
the design, we count bytes received from the smart card with the CoolRunner-II to determine
the valid data to be used.
There will be no parity check for each character frame and no branch operations to handle
different protocol or bytes received. In this situation only the ACOS1 card can be used for this
smart card reader.
Smart Card Control

A smart card control block diagram and state machine are shown in Figure 9 and Figure 10.
When the card is inserted into the card acceptor, the switch turns on to enable the smart card
state machine. By following the ISO 7816-3 standard sequence to activate smart card contacts,

1-800-255-7778
R
the CoolRunner-II device sets Reset to high, goes to the Wait state, and waits for a low signal
from the card, the start bit of the TS for Answer to Reset.
8 Data_out
Card_io Data_ready
Shift Register Byte Encoder
lo_rw
Card_clk
State Machine Control

Card_rst
Bitcounter() Bytecounter()
Baud Rate
Bit Counter Byte Counter
Counter
X372_09_090803
Figure 9: Smart Card Control Block Diagram
Idle
Enable = 1
Init
Wait
Command_end = 1 I/O = 0
Send command Read char
Process
Command_ready = 1
Done = 1
End
X372_10_090803
Figure 10: Smart Card Control State Machine

1-800-255-7778
R
There is a baud rate counter counting to 372 for every bit received or sent to synchronize the
data transmission. The received bits are sampled at the 186th count, which is in the center of
each bit received.
Two other counters are used, one to count bits for each character and one to count bytes
received or sent. The byte number is also used to determine the end of the read data cycle or
the send command cycle.
For this preprogrammed ACOS1 smart card, the state machine will set to the send command
state after 19 Answer to Reset characters are received. The smart card controller is now ready
to send commands and receive responses based on the T=0 protocol. There is decoder logic
to check the character counts to determine when to send a command, what command to send,
and how many characters will be received by the request.
The first command sent to the smart card contains 5 bytes: 80, A4, 00, 00 and 02. After one
procedure byte (A4) is echoed from the smart card, the controller sends two data bytes (F0, 00)
and the smart card responds with two status bytes (91, 00). As is clear from the T=0 command
table, A4 selects the file address and F0, 00 is the selected file address.
The subsequent commands are to select data records and to retrieve data. All the commands
and data lengths are already defined and fixed. In this design, io_rw controls the shift register
to read data from card_io or shift data from data encoder to card_io. All operations are based
on the byte count.
In this design, the name record is between bytes 38 and 69. gender, status and age records are
bytes 92, 93 and 94. The bank balance record are bytes 126 and 127. A data_ready signal is
enabled for these bytes to filter out unused data. This signal is used for the SRAM interface to
write the smart card data to the SRAM.
Main Control Logic

A main state machine in this block controls the ordering of the functions. It also reads the SRAM
data and decodes it before sending it to the LCD control logic. There is also a delay counter to
separate the data sent to the LCD display, so there will be 1 to 2 seconds between each piece
of information displayed on the LCD.
A block diagram is shown in Figure 11 and its flow chart is shown in Figure 12. The state
machine powers up in an idle state and waits for the smart card controller to read the data and
save it to SRAM. When the smartcard_done bit goes high it will go to the standby state and wait
for the lcd_ready.
The card name has the same ASCII format as the LCD display so there is no need to decode
the characters. All characters read from SRAM will be dumped to the LCD Display.

1-800-255-7778
R
Data Decoder
SRAM SRAM Interface
Logic
Sram_rw
Data
Lcd_w
Done
Smart Card Main Control LCD To LCD
Control State Machine Control
Lcd_ready
Counter_enable Counter()
Delay Counter
Main Control Logic

X372_11_090803
Figure 11: Main Control Logic Block Diagram

1-800-255-7778
R
Idle
Smartcard_done = 1
Standby
Lcd_ready = 1
Write_name
Char = 2 Delay_loop Char = 1
Write_female Write_male
Char = 2 Delay_loop Char = 1
Write_married Write_single
Delay_loop
Write_age
End
X372_12_090803
Figure 12: Main Control Logic Flow Chart
The next data record is decoded gender information. The data value is one for male, two for
female. After gender comes status information, also decoded as one and two (one for single,
two for married).
The age information is saved as binary value in the smart card. It has to be converted to ASCII
digits before getting sent to the LCD controller. A binary-to-digital module is separated from the
top module, which is for the ASCII coding function.
SRAM Interface
The SRAM interface is controlled by the main control logic. The signal sram_w is always kept
high as write enable during smart card reading. The address counter will be reset when the
main control state machine enters the standby state for writing data to the LCD display. The
data is then retrieved in the order it was saved.

1-800-255-7778
R
LCD Control
LCD control logic is used to initialize and pass decoded data to the LCD display. This module
uses simplified timing to control the LCD display. Every character write cycle is set to 30000
clock periods and is much higher than the few hundred microsecond LCD controller
specification.
Source Code THIRD PARTIES MAY HAVE PATENTS ON THE CODE PROVIDED. BY PROVIDING THIS
CODE AS ONE POSSIBLE IMPLEMENTATION OF THIS DESIGN, XILINX IS MAKING NO
REFERENCE DESIGN "AS IS" AS A COURTESY TO YOU.
XAPP372 –http://www.xilinx.com/products/xaw/coolvhdlq.htm
Conclusion This document has explained outlined some of the smart card protocol and has explained how
to implement it using a CoolRunner-II, hardware-based solution. Although this Smart Card
Reader design is a simplified version with no error checking or frills, it is a good reference for
users needing to approach for smart card applications with minimal software development.
References 1. International Standards Organization, ISO 7816

2. Scott B. Guthery & Timothy M. Jurgensen, Smart Card Developer’s Kit
3. David B Everett, Smart Card Tutorial
4. Advanced card systems Ltd., ACS software development kit
Further Reading Application Notes

http://direct.xilinx.com/bvdocs/appnotes/xapp371.pdf (Galois Field GF (2m) Multiplier)
http://direct.xilinx.com/bvdocs/appnotes/xapp374.pdf (CryptoBlaze)
http://direct.xilinx.com/bvdocs/appnotes/xapp375.pdf (Timing Model)
http://direct.xilinx.com/bvdocs/appnotes/xapp376.pdf (Logic Engine)
http://direct.xilinx.com/bvdocs/appnotes/xapp377.pdf (Low Power Design)
http://direct.xilinx.com/bvdocs/appnotes/xapp378.pdf (Advanced Features)
http://direct.xilinx.com/bvdocs/appnotes/xapp379.pdf (High Speed Design)
http://direct.xilinx.com/bvdocs/appnotes/xapp380.pdf (Cross Point Switch)
http://direct.xilinx.com/bvdocs/appnotes/xapp381.pdf (Demo Board)
http://direct.xilinx.com/bvdocs/appnotes/xapp382.pdf (I/O Characteristics)
http://direct.xilinx.com/bvdocs/appnotes/xapp383.pdf (Single Error Correction Double
Error Detection)
http://direct.xilinx.com/bvdocs/appnotes/xapp384.pdf (DDR SDRAM Interface)
http://direct.xilinx.com/bvdocs/appnotes/xapp387.pdf (PicoBlaze Microcontroller)
http://direct.xilinx.com/bvdocs/appnotes/xapp388.pdf (On the Fly Reconfiguration)
http://direct.xilinx.com/bvdocs/appnotes/xapp389.pdf (Powering CoolRunner-II CPLDs)

1-800-255-7778
R
http://direct.xilinx.com/bvdocs/appnotes/xapp393.pdf (8051 Microcontroller Interface)

http://direct.xilinx.com/bvdocs/appnotes/xapp394.pdf (Interfacing with Mobile SDRAM)
http://direct.xilinx.com/bvdocs/appnotes/xapp395.pdf (Using DataGATE)
http://direct.xilinx.com/bvdocs/appnotes/xapp398.pdf (CompactFlash Card Interface)
CoolRunner-II Data Sheets

http://direct.xilinx.com/bvdocs/publications/ds090.pdf (CoolRunner-II Family Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds091.pdf (XC2C32 Datasheet)
CoolRunner-II White Papers

http://direct.xilinx.com/bvdocs/whitepapers/wp165.pdf (Chip Scale Packaging)
http://direct.xilinx.com/bvdocs/whitepapers/wp170.pdf (Security)
http://direct.xilinx.com/bvdocs/whitepapers/wp197.pdf (Cipher Stream Protocol)
http://direct.xilinx.com/bvdocs/whitepapers/wp198.pdf (Cell Phone Handsets)
History
12/18/03 1.1 Minor errata.

1-800-255-7778
Application Note: CoolRunner-II CPLD
R
CoolRunner-II CPLD I2C Bus Controller
Implementation
Summary This document details the VHDL implementation of an I2C controller in a Xilinx CoolRunner™-
II 256-macrocell CPLD. CoolRunner-II CPLDs are the lowest power CPLDs available, making
this the perfect target device for an I2C controller. To obtain the VHDL code described in this
document, go to section VHDL Code Download, page 87 for instructions. This design fits both
XPLA3 and CoolRunner-II CPLDs. For the CoolRunner XPLA3 CPLD version, please refer to
XAPP333, CoolRunner CPLD I2C Bus Controller Implementation.
Introduction The I2C bus is a popular serial, two-wire interface used in many systems because of its low
overhead. The two-wire interface minimizes interconnections so ICs have fewer pins, and the
number of traces required on printed circuit boards is reduced. Capable of 100 KHz operation,
each device connected to the bus is software addressable by a unique address with a simple
Master/Slave protocol.
The CoolRunner-II I2C Controller design contains an asynchronous microcontroller (μC)
interface and provides I2C Master/Slave capability. It is intended to be used with a
microcontroller (μC) or microprocessor (μP) as shown in Figure 1.
SDA
CoolRunner-II I2C Bus Controller SCL
Address
Data I2C Master/
Microcontroller Microcontroller Slave
Control Interface Interface
X385_01_111902
Figure 1: CoolRunner-II I2C Bus Controller
I2C Background This section will describe the main protocol of the I2C bus. For more details and timing
diagrams, please refer to the I2C specification.
The I2C bus consists of two wires, serial data (SDA) and serial clock (SCL), which carry
information between the devices connected to the bus. The number of devices connected to the
same bus is limited only by a maximum bus capacitance of 400 pF. Both the SDA and SCL lines
are bidirectional lines, connected to a positive supply voltage via a pull-up resistor. When the

1-800-255-7778
R
bus is free, both lines are High. The output stages of devices connected to the bus must have
an open-drain or open-collector in order to perform the wired-AND function.
Each device on the bus has a unique address and can operate as either a transmitter or
receiver. In addition, devices can also be configured as Masters or Slaves. A Master is the
device which initiates a data transfer on the bus and generates the clock signals to permit that
transfer. Any other device that is being addressed is considered a Slave. The I2C protocol
defines an arbitration procedure that insures that if more than one Master simultaneously tries
to control the bus, only one is allowed to do so and the message is not corrupted. The
arbitration and clock synchronization procedures defined in the I2C specification are supported
by the CoolRunner-II I2C Controller.
Data transfers on the I2C bus are initiated with a START condition and are terminated with a
STOP condition. Normal data on the SDA line must be stable during the High period of the
clock. The High or Low state of the data line can only change when SCL is Low. The START
condition is a unique case and is defined by a High-to-Low transition on the SDA line while SCL
is High. Likewise, the STOP condition is a unique case and is defined by a Low-to-High
transition on the SDA line while SCL is High. The definitions of data, START, and STOP insure
that the START and STOP conditions will never be confused as data. This is shown in Figure 2.
SDA MSB
SCL 1 2 3 7 8 9
S P
Start ACK Stop
Condition Condition
x385_10_111902
Figure 2: Data Transfer on the I2C Bus
Each data packet on the I2C bus consists of eight bits of data followed by an acknowledge bit
so one complete data byte transfer requires nine clock pulses. Data is transferred with the most
significant bit first (MSB). The transmitter releases the SDA line during the acknowledge bit and
the receiver of the data transfer must drive the SDA line low during the acknowledge bit to
acknowledge receipt of the data. If a Slave-receiver does not drive the SDA line Low during the
acknowledge bit, this indicates that the Slave-receiver was unable to accept the data and the
Master can then generate a STOP condition to abort the transfer. If the Master-receiver does
not generate an acknowledge, this indicates to the Slave-transmitter that this byte was the last
byte of the transfer.
Standard communication on the bus between a Master and a Slave is composed of four parts:
START, Slave address, data transfer, and STOP. The I2C protocol defines a data transfer format
for both 7-bit and 10-bit addressing. The implementation of the I2C controller in the Xilinx
CoolRunner-II CPLD supports the seven-bit address format. After the START condition, a Slave
address is sent. This address is seven bits long followed by an eighth-bit which is the read/write
bit. A "1" indicates a request for data (read) and a "0" indicates a data transmission (write). Only
the Slave with the calling address that matches the address transmitted by the Master
responds by sending back an acknowledge bit by pulling the SDA line Low on the ninth clock.
Once successful Slave addressing is achieved, the data transfer can proceed byte-by-byte as
specified by the read/write bit. The Master can terminate the communication by generating a
STOP signal to free the bus. However, the Master may generate a START signal without
generating a STOP signal first. This is called a repeated START.

1-800-255-7778
R
CoolRunner-II The CoolRunner-II CPLD implementation of the I2C Controller supports the following features:
I2C Controller • Microcontroller interface
• Master or Slave operation
• Multi-master operation
• Software selectable acknowledge bit
• Arbitration lost interrupt with automatic mode switching from Master to Slave
• Calling address identification interrupt with automatic mode switching from Master to
Slave
• START and STOP signal generation/detection
• Repeated START signal generation
• Acknowledge bit generation/detection
• Bus busy detection
• 100 KHz operation
Signal The I/O signals of the CoolRunner-II I2C controller are described in Table 1. Pin numbers have
Descriptions not been assigned to this design, this can be done to meet the system requirements of the
designer.
Table 1: CoolRunner-II I2C Controller Signal Description

Name Direction Description
SDA Bidirectional I2C Serial Data.
SCL Bidirectional I2C Serial Clock.
ADDR_BUS[23:0] Input μC Address Bus.
DATA_BUS[7:0] Bidirectional μC Data Bus.
AS Input Address Strobe. Active Low μC handshake signal
indicating that the address present on the address
bus is valid.
DS Input Data Strobe. Active Low μC handshake signal
indicating that the data present on the data bus is
valid or that the μC is no longer driving the data bus
and the I2C Controller can place data on the data
bus.
R_W Input Read/Write. "1" indicates a read, "0" indicates a
write.
DTACK Output Data Transfer Acknowledge. Active Low μC
handshake signal indicating that the I2C Controller
has placed valid data on the data bus for a read cycle
or that the I2C Controller has received the data on
the bus for a write cycle.

1-800-255-7778
R
Table 1: CoolRunner-II I2C Controller Signal Description

IRQ Output Interrupt Request. Active Low.
MCF Output Data Transferring Bit. While one byte of data is
being transferred, this bit is cleared. It is set by the
falling edge of the ninth clock of a byte transfer. This
bit is used to signal the completion of a byte transfer
to the μC.
CLK Input Clock. This clock is input from the system. The
constants used in generating a 100 KHz SCL signal
assumes the frequency to be 1.832 MHz. Different
clock frequencies can be used, but the constants in
the VHDL source code must be recalculated.
Block Diagram The block diagram of the CoolRunner-II I2C Controller, shown in Figure 3 was broken into two
major blocks, the μC interface and the I2C interface.
ADDR_BUS[23:0]
DATA_BUS[7:0]
DTACK
R_W
MCF
IRQ
DS
AS
μC Interface
ADDR_DECODE/Bus Interface
RESET
Status Register Control Register Address Register Data Register

MBSR MBCR MADR MBDR
SYS_CLK
I2C Status Address I2C Header I2C Data

Register Compare Register Register
START/
STOP
Arbitration and Main State Machine SCL
START/STOP Generation
Detection
I2C Interface
SDA
SCL
X385_02_111902
Figure 3: CoolRunner-II I2C Controller

1-800-255-7778
R
Microcontroller The μC interface for the I2C controller design supports an asynchronous byte-wide bus
Logic protocol. This protocol is the method in which the μC reads and writes the registers in the
design and is shown in Figure 4.
Microcontroller I2C Controller

Address the Device
1. Set R/W to indicate direction of data transfer
2. Place Address on A23:A1
3. Assert Address Strobe (AS)
4. Place data on D7:D0 (if Write)
5. Assert Data Strobe (DS) Input the Data
1. Decode Address
2. Latch data on D7:D0 (if Write)
or place data on D7:D0 (if Read)
Terminate Transfer 3. Assert Data Transfer Acknowledge (DTACK)
1. Latch data (if Read)

2. Negate DS
3. Negate AS
4. Remove data from bus (if Write) Terminates the Cycle
1. Remove data from D7:D0 (if Read)
Start Next Cycle 2. Negate DTACK
X385_11_111902
Figure 4: μC Read/Write Protocol
Address Decode/Bus Interface Logic

The μC bus protocol is implemented in the CoolRunner-II I2C Controller in the state machine
shown in Figure 5.
RESET
Asserted
IDLE
AS Asserted
RESET Negated
ADDRESS_MATCH DS
Negated Negated
ADDR
DS Asserted
ADDRESS_MATCH Asserted
AS Negated
DS Negated DATA_TRS
AS Asserted
DS Asserted
ASSERT_DTACK
X385_03_111902
Figure 5: μC Bus Interface State Machine

1-800-255-7778
R
In the first cycle, the μC places the address on the address bus, sets the read/write line to the
correct state, and asserts address strobe (AS) and data strobe (DS). Address strobe indicates
that the address present on the address bus is valid. If this is a write cycle, the μC also places
the data on the data bus and DS indicates that valid data is present on the data bus. If this is a
read cycle, the μC 3-states the data bus and DS indicates that the CoolRunner-II I2C Controller
can place data on the data bus.
Upon the assertion of AS, the CoolRunner-II I2C Controller transitions to the ADDR state to
decode the address and determine if it is the device being addressed. The enables for the
internal registers are set in this state. If the CoolRunner-II I2C Controller is being addressed
and DS is asserted, the CoolRunner-II I2C controller progresses to the DATA_TRS state. If this
is a read cycle, the requested data is placed on the bus and if this is a write cycle, the data from
the data bus is latched in the addressed register. The CoolRunner-II I2C Controller
automatically progresses to the ASSERT_DTACK state and asserts DTACK indicating that the
data requested is ready if a read cycle or that the data has been received if a write cycle.
Upon the assertion of DTACK, the μC either removes data from the bus if this is a write cycle,
or latches the data present on the bus if this is a read cycle. The read/write line is set to read
and AS and DS are negated to indicate that the data transfer is complete. The negation of AS
and DS causes the CoolRunner-II I2C Controller to negate DTACK and transition to the IDLE
state.
CoolRunner-II I2C Controller Registers

The base address used for address decoding is set in the VHDL code via the constant
BASE_ADDRESS. The base address is the upper 16 bits of the address bus. The lower
address bits determine which register is being accessed.
The registers supported in the CoolRunner-II I2C Controller are described in the Table 2. The
μC interface logic of the CoolRunner-II I2C Controller handles the reading and writing of these
registers by the μC and supplies and/or retrieves these bits to/from the I2C interface logic.
Table 2: I2C Controller Registers

Address Register Description
MBASE + $8Dh MADR I2C Address Register
MBASE + $91h MBCR I2C Control Register
MBASE + $93h MBSR I2C Status Register
MBASE + $95h MBDR I2C Data I/O Register
Address Register (MADR)

This field contains the specific Slave address to be used by the I2C Controller. This register is
read/write. (Table 3).
Table 3: Address Register Bits

Bit
Location Name μC Access Description
7-1 Slave Address Read/Write Address used by the I2C controller when
in Slave mode.
0 - - Unused

1-800-255-7778
R
Control Register (MBCR)

This register contains the bits to configure the I2C controller. (Table 4).
Table 4: Control Register Bits

Bit
7 MEN Read/Write I2C Controller Enable. This bit must be set before
any other MBCR bits have any effect
"1" enables the I2C controller
"0" resets and disables the I2C controller
6 MIEN Read/Write Interrupt Enable.
"1" enables interrupts. An interrupt occurs if MIF bit
in the status register is also set
"0" disable interrupts but does not clear any
currently pending interrupts
5 MSTA Read/Write Master/Slave Mode Select. When the μC changes
this bit from "0" to "1", the I2C controller generates
a START condition in Master mode. When this bit is
cleared, a STOP condition is generated and the I2C
controller switches to Slave mode. If this bit is
cleared, however, because arbitration for the bus
has been lost, a STOP condition is not generated.
4 MTX Read/Write Transmit/Receive Mode Select. This bit selects
the direction of Master/Slave transfers.
"1" selects an I2C Master transmit
"0" selects an I2C Master receive
3 TXAK Read/Write Transmit Acknowledge Enable. This bit specifies
the value driven onto the SDA line during
acknowledge cycles for both Master and Slave
receivers
"1" - ACK bit = "1" - no acknowledge
"0" - ACK bit = "0" - acknowledge
Since Master receivers indicate the end of data
reception by not acknowledging the last byte of the
transfer, this bit is the means for the μC to end a
Master receiver transfer.
2 RSTA Read/Write Repeated Start. Writing a "1" to this bit generates
a repeated START condition on the bus if the I2C
controller is the current bus Master. This bit is
always read as "0". Attempting a repeated START
at the wrong time if the bus is owned by another
Master results in a loss of arbitration.
1-0 Reserved

1-800-255-7778
R
Status Register (MBSR)

This register contains the status of the I2C controller. This status register is read-only with the
exception of the MIF and MAL bits, which are software clearable. All bits are cleared upon reset
except the MCF and RXAK bits. (Table 5).
Table 5: Status Register Bits

Bit
7 MCF Read Data Transferring Bit. While one byte of data is
being transferred, this bit is cleared. It is set by the
rising edge of SCL during the acknowledge cycle of
the transfer and is only High for this SCL clock
period.
"1" transfer is complete
"0" transfer in progress
Note that in the CoolRunner-II I2C controller, this bit
is also an output pin so that a register read cycle is
not required to determine that a transfer is complete.
6 MAAS Read Addressed as Slave Bit. When the address on the
I2C bus matches the Slave address in the MADR
register, the I2C controller is being addressed as a
Slave and switches to Slave mode.
5 MBB Read Bus Busy Bit. This bit indicates the status of the I2C
bus. This bit is set when a START condition is
detected and cleared when a STOP condition is
detected.
"1" indicates the bus is busy
"0" indicates the bus is idle
4 MAL Read Arbitration Lost Bit. This bit is set by hardware
Software when arbitration for the I2C bus is lost. This bit must
Clearable be cleared by the μC software writing a "0" to this bit.
3 Reserved

1-800-255-7778
R
Table 5: Status Register Bits (Continued)

Bit
2 SRW Read Slave Read/Write Bit. When the I2C controller has
been addressed as a Slave (MAAS is set), this bit
indicates the value of the read/write bit sent by the
Master. This bit is only valid when a complete
transfer has occurred and no other transfers have
been initiated.
"1" indicates Master reading from Slave
"0" indicates Master writing to Slave
1 MIF Read Interrupt Bit. This bit is set when an interrupt is
Software pending, which causes a processor interrupt request
Clearable if MIEN is set. This bit must be cleared by the μC
software writing a "0" to this bit in the interrupt
service routine.
0 RXAK Read Received Acknowledge Bit. This bit reflects the
value of the SDA signal during the acknowledge
cycle of the transfer.
"1" indicates that no acknowledge was received
"0" indicates that an acknowledge was received
Data Register (MBDR)

This register contains data to/from the I2C bus. Physically, this register is implemented by two
byte-wide registers at the same address, one for the I2C transmit data and one for the I2C
received data. This eliminates any possible contention between the μC and the CoolRunner-II
I2C Controller. Since these registers are at the same address they appear as the same register
to the μC and will continue to be described as such. In transmit mode, data written into this
register is output on the I2C bus, in receive mode, this register contains the data received from
the I2C bus. Note that in receive mode, it is assumed that the μC will be able to read this register
during the next I2C transfer. The received I2C data is placed in this register after each complete
transfer, the I2C interface logic does not wait for an indication from the μC that this register has
been read before proceeding with the next transfer. (Table 6)
Table 6: I2C Data Register Bit

Bit
7-0 D7:D0 Read/Write I2C Data
I2C Interface The I2C bus interface logic consists of several different processes as seen in Figure 3. Control
Logic bits from the μC interface registers determine the behavior of these processes.
Arbitration
Arbitration of the I2C bus is lost in the following circumstances:
• The SDA signal is sampled as a "0" when the Master outputs a "1" during an address or
data transmit cycle
• The SDA signal is sampled as a "0" when the Master outputs a "1" during the
acknowledge bit of a data receive cycle
• A start cycle is attempted when the bus is busy

1-800-255-7778
R
• A repeated start cycle is requested in Slave mode

• A STOP condition is detected when the Master did not request it
If the CoolRunner-II I2C Controller is in Master mode, the outgoing SDA signal is compared with
the incoming SDA signal to determine if control of the bus has been lost. The SDA signal is
checked only when SCL is High during all cycles of the data transfer except for acknowledge
cycles to insure that START and STOP conditions are not generated at the wrong time. If the
outgoing SDA signal and the incoming SDA signals differ, then arbitration is lost and the MAL
bit is set. At this point, the CoolRunner-II I2C Controller switches to Slave mode and resets the
MSTA bit.
The CoolRunner-II I2C design will not generate a START condition while the bus is busy,
however, the MAL bit will be set if the μC requests a START or repeated START while the bus
is busy. The MAL bit is also set if a STOP condition is detected when this Master did not
generate it.
If arbitration is lost during a byte transfer, SCL continues to be generated until the byte transfer
is complete.
START/STOP Detection
This process monitors the SDA and SCL signals on the I2C bus for START and STOP
conditions. When a START condition is detected, the Bus Busy bit is set. This bit stays set until
a STOP condition is detected. The signals, DETECT_START and DETECT_STOP are
generated by this process for use by other processes in the logic. Note that this logic detects
the START and STOP conditions even when the CoolRunner-II I2C Controller is the generator
of these conditions.
Generation of SCL, SDA, START and STOP Conditions

This process generates the SCL and SDA signals output on the I2C bus when in Master mode.
The clock frequency of the SCL signal is ~100 KHz and is determined by dividing down the
input clock. The number of input clock cycles required for generation of a 100 KHz SCL signal
is set by the constant CNT_100 KHZ and is currently calculated for a system clock of 1.832
MHz. This constant can easily be modified by a designer based on the clock available in the
target system. Likewise, the constants START_HOLD and DATA_HOLD contain the number of
system clock cycles required to meet the I2C requirements on hold time for the SDA lines after
generating a START condition and after outputting data.

1-800-255-7778
R
The state machine that generates SCL and SDA when in Master mode is shown in Figure 6.
Note that SCL and SDA are held at the default levels if the bus is busy. This state machine
generates the controls for the system clock counter.
RST
GEN_START = 0
IDLE
GEN_START = 1
CLK_CNT < START_HOLD
REP_START = 1 START
CLK_CNT = HIGH_CNT/2
CLK_CNT = START_HOLD
ARB_LOST = 1
BIT_CNT > 7
CLK_CNT = TBUF
SCL_LOW_EDGE
CLK_CNT < LOW_CNT
SCL_LOW
CLK_CNT = LOW_CNT
CLK_CNT < TBUF
CLK_CNT = HIGH_CNT
STOP_WAIT
SCL_INT = 0
SCL_HI_EDGE
GEN_STOP = 1
CLK_CNT = HIGH_CNT/2 SCL_INT = 1
CLK_CNT < HIGH_CNT
SCL_HI
X385_04_111902
Figure 6: SCL, SDA, START, and STOP Generation State Machine
The internal SDA signal output from this design is either the SDA signal generated by this state
machine for START and STOP conditions or the data from the MBDR register when the
CoolRunner-II I2C Controller is in transmit mode. Note that both SCL and SDA are open-
collector outputs, therefore, they are only driven to a "0". When a "1" is to be output on these
signals, the CoolRunner-II I2C Controller 3-states their output buffers. The logic in the design
will set internal SDA and SCL signals to "1" or "0". These internal signals actually control the
output enable of the 3-state buffer for these outputs.
In the IDLE state, SCL and SDA are 3-stated, allowing any Master to control the bus. Once a
request has entered to generate a start condition, the CoolRunner-II I2C Controller is in Master
mode, and the bus is not busy, the state machine transitions to the START state.
The START state holds SCL High, but drives SDA Low to generate a START condition. The
system clock counter is started and the state machine stays in this state until the required hold
time is met. At this point, the next state is SCL_LOW_EDGE.
The SCL_LOW_EDGE state simply creates a falling edge on SCL and resets the system clock
counter. On the next clock edge, the state machine moves to state SCL_LOW. In this state, the
SCL line is held Low and the system clock counter begins counting. If the REP_START signal

1-800-255-7778
R
is asserted then the SDA signal will be set High, if the GEN_STOP signal is asserted, SDA will
be set Low.
When the SCL low time has been reached, the state machine will transition to the IDLE state if
arbitration has been lost and the byte transfer is complete to insure that SCL continues until the
end of the transfer. Otherwise the next state is the SCL_HI_EDGE state.
The SCL_HI_EDGE state generates a rising edge on SCL by setting SCL to "1". Note, however,
that the state machine will not transition to the SCL_HI state until the sampled SCL signal is
also High to obey the clock synchronization protocol of the I2C specification. Clock
synchronization is performed using the wired-AND connection of the SCL line. The SCL line will
be held Low by the device with the longest low period. Devices with shorter low periods enter
a high wait state until all devices have released the SCL line and it goes High. Therefore the
SCL_HI_EDGE state operates as the high wait state as the SCL clock is synchronized.
The SCL_HI state then starts the system clock counter to count the high time for the SCL
signal. If a repeated START or a STOP condition has been requested, the state machine will
transition to the appropriate state after half of the SCL high time so that the SDA line can
transition as required. If neither of these conditions has been requested, then the state machine
transitions to the SCL_LOW_EDGE state when the SCL high time has been achieved.
The STOP_WAIT state is used to insure that the hold time requirement after a STOP condition
is met.
I 2C Interface Main State Machine

The main state machine for the I2C Interface logic is shown in Figure 7. This state machine is
the same for both Slave and Master modes. In each state, the mode is checked to determine
the proper output values and next state conditions. This allows for immediate switching from

1-800-255-7778
R
Master to Slave mode if arbitration is lost or if the CoolRunner-II I2C Controller is addressed as
a Slave.
RESET
Asserted
IDLE
DETECT_START = 1
BIT_CNT < 8
HEADER
DETECT_START = 1 BIT_CNT = 8 DETECT_START = 1
Master Rcv
SDA = 0 ACK_HEADER Master Xmit
SDA = 0
Slave Rcv
Slave Xmit
ADDR_MATCH = 1
ADDR_MATCH = 1
RCV_DATA XMIT_DATA
Master
DETECT_STOP = 1 SDA = 1 DETECT_STOP = 1 SDA = 0
BIT_CNT = 8 BIT_CNT = 8
ACK_DATA WAIT_ACK
SDA = 1
STOP
X385_05_111902
Figure 7: I2C Interface Main State Machine
This state machine utilizes and controls a counter that counts the I2C bits that have been
received. This count is stored in the signal BIT_CNT. This state machine also controls two shift
registers, one that stores the I2C header that has been received and another that stores the I2C
data that has been received or is to be transmitted.
Note:
This state machine and the associated counters and shift registers are clocked on the falling edge of
the incoming SCL clock. If the load is heavy on the SCL line, the rise time of the SCL signal may be
very slow which can cause susceptibility to noise for some systems. This can be particularly
dangerous on a clock signal. The designer is strongly encouraged to investigate the signal integrity of
the SCL line and if necessary, use external buffers for the SCL signal.
When a START signal has been detected, the state machine transitions from the IDLE state to
the HEADER state. The START signal detection circuit monitors the incoming SDA and SCL
lines to detect the START condition. The START condition can be generated by the
CoolRunner-II I2C controller or another Master—either source will transition the state machine
to the HEADER state.
The HEADER state is the state where the I2C header is transmitted on the I2C bus from the
MBDR register if in Master mode. In this state, the incoming I2C data is captured in the I2C
Header shift register. In Master mode, the I2C Header shift register will contain the data that
was just transmitted by this design. When all eight bits of the I2C header have been shifted in,
the state machine transitions to the ACK_HEADER state.

1-800-255-7778
R
In the ACK_HEADER state, the CoolRunner-II I2C design samples the SDA line if in Master
mode to determine whether the addressed I2C Slave acknowledged the header. If the
addressed Slave does not acknowledge the header, the state machine will transition to the
STOP state which signals the SCL/START/STOP generator to generate a STOP. If the
addressed Slave has acknowledged the address, then the LSB of the I2C header is used to
determine if this is a transmit or receive operation and the state machine transitions to the
appropriate state to either receive data, RCV_DATA, or to transmit data, XMIT_DATA.
The I2C Header shift register is constantly compared with the I2C address set in the MADR
register. If these values match in the ACK_HEADER state, the CoolRunner-II I2C Controller has
been addressed as a Slave and the mode immediately switches to Slave mode. The MAAS bit
is then set in the MBSR status register. The SDA line will be driven as set in the TXAK register
to acknowledge the header to the current I2C bus Master. Again, the LSB of the I2C header is
used to determine the direction of the data transfer and the appropriate state is chosen.
The RCV_DATA state shifts the incoming I2C data into the I2C shift register for transfer to the
μC. When the whole data byte has been received, the state machine transitions to the
ACK_DATA state and the value of the TXAK register is output on the SDA line to acknowledge
the data transfer. Note that in Master mode, the indication that the Slave has transmitted the
required number of data bytes is to not acknowledge the last byte of data. The μC must negate
the TXAK bit to prohibit the ACK of the last data byte. The state machine exits this pair of states
when a STOP condition has been detected, otherwise, the transition between these two states
continues. In Master mode, the μC requests a STOP condition by negating the MSTA bit.
The XMIT_DATA state shifts the data from the I2C data register to the SDA line. When the entire
byte has been output, the state machine transitions to the WAIT_ACK state. If an acknowledge
is received, the state machine goes back to the XMIT_DATA to transmit the next byte of data.
This pattern continues until either a STOP condition is detected, or an acknowledge is not
received for a data byte.
Note that the data transfer states of this state machine assume that the μC can keep up with the
rate at which data is received or transmitted. If interrupts are enabled, an interrupt is generated
at the completion of each byte transfer. The MCF bit is set as well providing the same
indication. Data is transferred to/from the I2C data register to/from the μC data register during
the acknowledge cycle of the data transfer. The state machine does not wait for an indication
that the μC has read the received data or that new data has been written for transmission. The
designer should be aware of the effective data rate of the μC to insure that this is not an issue.
The STOP state signals the SCL/START/STOP generator to generate a STOP condition if the
CoolRunner-II I2C design is in Master mode. The next state is always the IDLE state and the
I2C activity is completed.

1-800-255-7778
R
Operational The flow of the interface between the μC and the CoolRunner-II I2C Controller is detailed in the
Flow Diagrams following flow charts. These flow charts are meant to be a guide for utilizing the CoolRunner-II
I2C Controller in a μC system.
Initialization
Before the CoolRunner-II I2C Controller can be utilized, certain bits and registers must be
initialized as shown in Figure 8.
BEGIN
Enable I2C Interface

Logic by Setting MEN
Define I2C Slave

Address to Respond
to in MADR
Modify MBCR to
Enable Interrupts
END
X385_06_111902
Figure 8: CoolRunner-II I 2C Controller Initialization Flow Chart
Master Transmit/Receive
The flow charts for transmitting data and receiving data while I2C bus Master are shown in
Figure 9 and Figure 10. The major difference between transmitting and receiving is the
additional step in the Master Receive flow chart of turning off the acknowledge bit on the
second to last data word.

1-800-255-7778
R
BEGIN
Bus Busy? Yes

(MBB = 1)
No
Write I2C Header
in MBDR
Set MSTA in MBCR

to Generate START
Transfer
No
Complete?
(MCF = 1)
Yes
Write Data
to MBDR
Transfer
No
Complete?
(MCF = 1)
Yes
No
Last Word?
Yes
Negate MSTA in MBCR
to Generate STOP
END
X385_07_111902
Figure 9: Master Transmit Flow Chart

1-800-255-7778
R
BEGIN
Bus Busy? Yes

(MBB = 1)
No
Write I2C Header
in MBDR
Set MSTA in MBCR

to Generate START
Transfer
No
Complete?
(MCF = 1)
Yes
Read Data
from MBDR
Transfer
No
Complete?
(MCF = 1)
Yes
No
Last Word - 1?
Yes
Set TXAK in MBCR
to Turn Off ACK
Yes
Read Data from
MBDR
Transfer
No
Complete?
(MCF = 1)
Yes
Negate MSTA in MBCR
to Generate STOP
END
X385_08_111902
Figure 10: Master Receive Flow Chart

1-800-255-7778
R
Slave Flow Chart

The flow chart for receiving or transmitting data in Slave mode is shown in Figure 11. If in
receive mode, the first read from the MBDR register is a dummy read because data has not yet
been received. Since the CoolRunner-II I2C Controller is in Slave mode, the only way to know
that the transaction is complete is to check that the bus is busy and that the Addressed as Slave
bit is still set.
BEGIN
Addressed No
as Slave?
Yes
Check SRW Bit in
MSBR for Xmit/Rcv
Read/Write Data
in MBDR
Transfer
No
Complete?
(MCF = 1)
Yes
Yes
Bus Busy?
MAAS = 1?
No
END
X385_09_111902
Figure 11: Slave/Transmitter Flow Chart
CoolRunner-II The design of the CoolRunner-II I2C Controller was implemented in VHDL and targeted to a
CPLD 256 macrocell CoolRunner-II CPLD in a 144-pin TQFP package (XC2C256-5TQ144) using
Xilinx Project Navigator. (Xilinx Project Navigator software is available free-of-charge from the
Implementation Xilinx website: www.xilinx.com/products/software/webpowered.htm.).
Note:
Since the system clock frequency was 1.832 MHz, the speed of the design was not critical and any
speed grade part could have been used.
Note:
The I2C SCL line is used as a clock input into the CoolRunner-II I2C Controller. If there are many
loads on the I2C bus, the rise time of the SCL line can be quite slow. The CoolRunner-II CPLD for this
design requires a rise time no greater than 20ns, therefore, the designer is strongly encouraged to
examine the characteristics of the SCL signal in the I2C system. If the rise time of the I2C signals are
greater than 20 ns, the inputs can be configured as Schmitt Triggers providing for input hysteresis and
noise immunity. Schmitt Trigger inputs will prevent adverse effects of slow rising/falling input signals.
The I2C design utilization in a CoolRunner-II 256-macrocell device is shown in Table 7. This
utilization was achieved using certain fitter parameters, actual results may vary. As shown,

1-800-255-7778
R
there is plenty of room remaining in the device for the implementation of other logic in the
system.
Table 7: CoolRunner-II CPLD 256-Macrocell Utilization

Macrocells 256 127 50%
P-terms 896 352 39%
Registers Used 256 110 43%
I/O Pins 118 42 36%
Function Block 640 305 48%
Inputs Used
Design Verification
The Xilinx Project Navigator software package outputs a timing VHDL model of the fitted
design. This post-fit VHDL was simulated with the original VHDL test benches to insure design
functionality. Also, the CoolRunner-II I2C Controller design was simulated with an
independently generated VHDL model of an I2C Slave design to verify that the interface
specifications were implemented correctly. Please note that all verification of this design has
been done through simulations.
VHDL Code VHDL source code and test benches are available for this design. THE DESIGN IS PROVIDED
Download TO YOU "AS IS". XILINX MAKES AND YOU RECEIVE NO WARRANTIES OR CONDITIONS,
EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, AND XILINX SPECIFICALLY
DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT,
OR FITNESS FOR A PARTICULAR PURPOSE. This design has not been verified on hardware
(as opposed to simulations), and it should be used only as an example design, not as a fully
functional core. XILINX does not warrant the performance, functionality, or operation of this
Design will meet your requirements, or that the operation of the Design will be uninterrupted or
error free, or that defects in the Design will be corrected. Furthermore, XILINX does not warrant
or make any representations regarding use or the results of the use of the Design in terms of
correctness, accuracy, reliability or otherwise.
VHDL - ftp://ftp.xilinx.com/pub/applications/refdes/xapp333.zip
Verilog - ftp://ftp.xilinx.com/pub/applications/refdes/xapp333_ver.zip
Disclaimer I2C is a registered trademark of Philips Electronics N.V.. Xilinx provides this reference design
as one possible implementation of this standard and claims no rights to this interface. To use
this reference design, you must contact Philips to obtain any necessary rights associated with
this interface.
Conclusion This document has detailed the design of an I2C Controller design for a CoolRunner-II CPLD.
Though the design has been extensively verified in simulations, Xilinx assumes no
responsibility for the accuracy or the functionality of this design.

1-800-255-7778
R
History
12/30/03 1.1 Change to control register address.

1-800-255-7778
R
CoolRunner-II Serial Peripheral Interface
Master
Summary This document details the VHDL implementation of a Serial Peripheral Interface (SPI) master in
a Xilinx CoolRunner™-II CPLD. CoolRunner-II CPLDs are the lowest power CPLDs available,
making this the perfect target device for an SPI Master. To obtain the VHDL code described in
this document, go to section VHDL Code Download and Disclaimer, page 107 for
instructions. This design fits XC2C256 CoolRunner-II or XCR3256XL CoolRunner XPLA3
CPLDs.
Introduction The Serial Peripheral Interface (SPI) is a full-duplex, synchronous, serial data link that is
standard across many microprocessors, microcontrollers, and peripherals. It enables
communication between microprocessors and peripherals and/or inter-processor
communication. The SPI system is flexible enough to interface directly with numerous
commercially available peripherals.
A SPI Master design has been implemented in a CoolRunner-II CPLD. The CoolRunner-II SPI
Master design can be used to provide a SPI controller to those microcontrollers or
microprocessors that do not contain a SPI interface. A high-level block diagram is shown in
Figure 1. The microcontroller (μC) interface chosen in this SPI Master implementation is based
on the popular 8051 microcontroller bus cycles, but can easily be modified to other
microcontroller interfaces. For more information on the 8051 microcontroller interface, please
refer to XAPP388, CoolRunner-II CPLD 8051 Microcontroller Interface.
SCK
CoolRunner-II SPI Master MOSI
MISO
SS_N[7:0]
Address
Data SPI Master
Microcontroller Microcontroller Interface
Control Interface
SS_IN_N
X386_01_121202
Figure 1: CoolRunner-II SPI Master

1-800-255-7778
R
SPI Background This section will describe the main protocol of the SPI bus. For more details and timing
diagrams, please refer to the description of the SPI bus in the Motorola 68HC11 Reference
Manual.
The SPI bus consists of four wires, Serial Clock (SCK), Master Out Slave In (MOSI), Master In
Slave Out (MISO), and Slave Select (SS_N), which carry information between the devices
connected to the bus.
The SCK control line is driven by the SPI Master and regulates the flow of data bits. The master
may transmit data at a variety of baud rates; the SCK line transitions once for each bit in the
transmitted data. The SPI specification allows a selection of clock polarity and a choice of two
fundamentally different clocking protocols on an 8-bit oriented data transfer. The master selects
one of four different bit rates for SCK. Data is shifted on one edge of SCK and is sampled on the
opposite edge when the data is stable.
The MOSI data line carries the output data from the master which is shifted as the input data to
the selected slave. The MISO data line carries the output data from the selected slave to the
input of the master. There may be no more than one slave transmitting data during a particular
transfer.
All SCK, MOSI, and MISO pins are tied together. A single SPI device is configured as a master;
all other SPI devices on the SPI bus are configured as slaves. The single master drives data out
its SCK and MOSI pins to the SCK and MOSI pins of the slaves. One selected slave device can
drive data out its MISO pin to the MISO master pin.
The SS_N control line selects a particular slave via hardware control. This control line allows
individual selection of a slave SPI device. Slave devices that are not selected do not interfere
with SPI bus activities. Slave devices ignore the SCK signal and keeps the MISO output pin in
a high impedance state unless the slave select pin is active low.
The SS_IN_N control line can be used as an input to the SPI Master indicating a multiple-
master bus contention (SS_IN_N). If the SS_IN_N signal to the master is asserted, it indicates
that some other device on the bus is attempting to be a master and address this device as a
slave. Assertion of SS_IN_N automatically disables SPI output drivers in the master device if
more than one device attempts to become master.
The clock phase and polarity can be modified for SPI data transfers. The clock polarity (CPOL)
selects an active high or active low clock and has no significant effect on the transfer format. If
CPOL = "0", then the idle state of SCK is low. If CPOL = "1", then the idle state of SCK is high.
The clock phase (CPHA) can be modified to select one of two fundamentally different transfer
formats. If CPHA = "0", data is valid on the first SCK edge (rising or falling) after SS_N has
asserted. If CPHA = "1", data is valid on the second SCK edge (rising or falling) after SS_N has
asserted. The clock phase and polarity should be identical for the master SPI device and the
communicating slave device.
Figure 2 shows the timing diagram for a SPI data transfer when the clock phase, CPHA, is set
to "0". The waveform is shown for both positive and negative clock polarities of SCK. The SCK
signal remains inactive for the first half of the first SCK cycle (SCK Cycle 1). In this transfer
format, the falling edge of SS_N indicates the beginning of a data transfer. Therefore, the SS_N

1-800-255-7778
R
line must be negated and reasserted between each successive serial byte. If the slave writes
data to the SPI data register while SS_N is active low, a write-collision error results.
SCK Cycle 1 SCK Cycle 2 SCK Cycle 3 SCK Cycle 4-6 SCK Cycle 7 SCK Cycle 8
SCK (CPOL=1)
SCK (CPOL=0)
MOSI MSB 6 5 1 LSB
MISO MSB 6 5 1 LSB **
SS
** Not defined, but normally MSB of character just received. X386_02_121202
Figure 2: Data Transfer on the SPI Bus with CPHA=0
Figure 3 shows the timing diagram for a SPI transfer when the clock phase, CPHA, is set to "1".
The waveform is shown for both positive and negative clock polarities of SCK. The first SCK
cycle begins with an edge on the SCK line from its inactive to its active level. The first edge of
SCK indicates the start of the data transfer in this format. The SS_N line may remain active low
between successive transfers. This format is useful in systems with a single master and single
slave.
Cycle 1 Cycle 2 Cycle 3 Cycle 4-6 Cycle 7 Cycle 8
SCK (CPOL=1)
SCK (CPOL=0)
MOSI MSB 6 5 1 LSB
MISO ** MSB 6 5 1 LSB
SS
** Not defined, but normally LSB of previously transmitted character. X386_03_121202
Figure 3: Data Transfer on SPI Bus with CPHA=1
When an SPI transfer occurs, an 8-bit data word is shifted out one interface pin while a different
8-bit data word is being shifted in on another interface pin. This can be viewed as an 8-bit shift
register in the SPI Master device and another 8-bit shift register in a SPI slave device that are
connected as a circular 16-bit shift register. When a transfer occurs, this 16-bit shift register is
shifted 8 positions, thus exchanging the 8-bit data between the master and slave devices.
The SPI specification details the timing and wave forms for byte transfers on the SPI bus, but
does not dictate the data protocol used in these transfers, i.e., the interface specification does

1-800-255-7778
R
not specify that the first byte contain an address or a read/write line. When communicating to
devices over the SPI bus, it is important to review the specifications of these devices to
determine the required communication protocol so that commands, addresses and the data
direction (read/write) can be set correctly. The CoolRunner-II CPLD SPI Master implementation
will not enforce a particular data protocol. It is expected that the μC will specify the data bytes
to be transferred on the SPI bus in the correct order. All data received on the SPI bus will be
stored in a receive register for the user logic to interpret. All data written to the transmit register
will be transmitted on the SPI bus.
CoolRunner-II The CoolRunner-II CPLD implementation of an SPI Master supports the following features:
SPI Master • Microcontroller interface
Implementation • Multi-master bus contention detection and interrupt
• Eight external slave selects
• Four transfer protocols available with selectable clock polarity and clock phase
• SPI transfer complete microcontroller interrupt
• Four different bit rates available for SCK
Signal The 36 I/O signals of the CoolRunner-II CPLD SPI Master are described in Table 1. Pin
Descriptions numbers have not been assigned to this design, this can be done to meet the system
requirements of the designer.
Table 1: CoolRunner-II SPI Master Signal Description

MOSI Output SPI Serial Data Output. Serial data output from the
SPI Master to a SPI slave.
MISO Input SPI Serial Data Input. Serial data input from a SPI
slave to the SPI Master.
SS_IN_N Input SPI Slave Select Input. Active Low slave select
input to the SPI Master. If this line is asserted, it
indicates that another master on the bus was trying
to select this SPI Master as a SPI slave and thus bus
contention can occur. Assertion of this line causes
the CoolRunner-II CPLD SPI Master to reset all
communication and interrupt the μC.
SS_N[7:0] Output SPI Slave Selects. Active Low slave select signals
to eight SPI slaves in the system.
SCK Output SPI Serial Clock. Clock output selectable as 1/2,
1/4, 1/8, or 1/16 of the system clock.
ADDR[15:8] Input μC Address Bus. High byte address bus.
ADDR_DATA[7:0] Bidirectional μC Multiplexed Address/Data Bus.
ALE_N Input Address Latch Enable. Active Low μC control
signal indicating that the data present on the
multiplexed address/data bus is a valid address.
PSEN_N Input Program Store Enable. Active Low μC control
signal indicating that the current bus cycle is an
access to the external program memory.
RD_N Input Read Strobe. Active Low μC control signal
indicating that the current bus cycle is a read cycle.

1-800-255-7778
R
Table 1: CoolRunner-II SPI Master Signal Description

WR_N Input Write Strobe. Active Low μC control signal
indicating that the current bus cycle is a write cycle.
INT_N Output Interrupt Request. Active Low signal to generate an
interrupt to the μC. This signal is asserted when
interrupts are enabled and there is SPI bus
contention as indicated by SS_IN_N or when the
transmit register is empty (SPITR) during a
transaction, or when the receive register is full and
the transaction is complete.
XMIT_EMPTY Output Transmit Register Empty. Active High signal
indicating that the transmit register (SPITR) is empty.
This bit is used to signal the loading of data from the
SPITR to the SPI transmit shift register indicating
that the μC can load another byte of data into the
SPITR. This signal could be connected to an μC
interrupt or to an I/O port. This signal causes INT_N
to assert during data transfers but does not cause an
interrupt after the transfer is complete (i.e. START =
0). This signal is brought out of the CPLD as a
separate I/O pin for systems that do not want to use
interrupts.
RCV_FULL Output Receive Register Full. Active High signal indicating
that the receive register (SPIRR) is full. This bit is
used to signal the loading of data from the SPI
receive shift register to the SPIRR. This signal could
be connected to an μC interrupt or to an I/O port.
This signal causes INT_N to assert only for the last
word received from the transfer (i.e., START = 0).
This signal is brought out of the CPLD as a separate
I/O pin for systems that do not want to use interrupts.
CLK Input Clock. This clock is input from the system and is
used to generate the SCK signal.
RESET Input Reset. Active High reset from the system. When
asserted, all logic in the CoolRunner-II CPLD is
reset.

1-800-255-7778
R
Block Diagram The block diagram of the CoolRunner-II CPLD SPI Master, shown in Figure 4 was broken into
two major blocks, the μC interface and the SPI interface.
ADDR_DATA[7:0]
XMIT_EMPTY
ADDR[15:8]
RCV_FULL
PSEN_N
ALE_N
WR_N
INT_N
RD_N
Microcontroller
Interface
Address Decode/Bus Interface
RESET
Status Register Control Register Slave Select Receive Register Transmit Register
SPISR SPICR Register - SPISSR SPIRR SPITR
SYS_CLK
SCK Clock SPI Shift Registers

Logic
Input
Registers
SPI Control
State Machine
SPI Interface
SCK
SS_IN_N
SS_N[7:0]
MOSI
MISO
X386_04_121202
Figure 4: SPI Master Block Diagram

1-800-255-7778
R
μC Interface The μC interface for the SPI Master design supports a byte-wide, multiplexed address/data bus
Logic protocol found in the popular 8051 μC. This protocol is the method in which the μC reads and
writes the registers in the CoolRunner-II CPLD and is shown in Figure 5.
Microcontroller SPI Master

Address the Device
1. Place high byte of address on ADDR[15:8]
2. Place low byte of address on ADDR_DATA[7:0]
3. Assert Address Latch Enable (ALE_N) Decode the Address
4. Negate Program Store Enable (PSEN_N)
1. Latch the address
2. Decode the address and determine if the
Transfer Data CPLD is being addressed
1. Remove data from ADDR_DATA{7:0]

2. If write cycle, place data on ADDR_DATA[7:0] Transfer Data
and assert Write Strobe (WR_N)
3. If read cycle, assert Read Strobe (RD_N) 1. If write cycle, latch data on ADDR_DATA[7:0]
into addressed register
2. If read cycle, output data from addressed
Terminate Transfer register on ADDR_DATA[7:0]
1. If write cycle, negate Write Strobe (WR_N) then

remove data from ADDR_DATA[7:0]
2. If read cycle, latch data from ADDR_DATA[7:0] Terminate Transfer
then negate Read Strobe (RD_N)
1. If read cycle, remove data from
ADDR_DATA[7:0]
Terminate the Cycle
1. Remove Address Latch Enable (ALE_N)
Start Next Cycle

X386_05_121202
Figure 5: μC Read/Write Protocol
Note that the code to interface to the 8051 μC is a separate VHDL module which interfaces to
the SPI interface logic via a set of registers. Therefore, this code can easily be replaced with the
μC interface of your choice.

1-800-255-7778
R
Address Decode/Bus Interface Logic

The μC bus protocol is implemented in the CoolRunner-II SPI Master in the state machine
shown in Figure 6.
IDLE
ale_n=0
psen_n=1 addr_match=0
ADDR_DECODE
rd_n=0 or wr_n=0
addr_match=1
rd_n=0 or wr_n=0
DATA_TRS
rd_n=1 or wr_n=1
END_CYCLE
X386_06_121202
Figure 6: μC Bus Interface State Machine
In the first cycle, the μC places the address on the address bus and asserts address latch
enable (ALE_N). ALE_N indicates that the data on the multiplexed address/data bus is a valid
address and that the address on ADDR[15:0] is also valid.
Upon the assertion of ALE_N, the CoolRunner-II SPI Master transitions to the
ADDR_DECODE state to decode the address and determine if it is the device being
addressed. The enables for the internal registers are set in this state. ALE_N is also used to
register the lower address bits from the multiplexed ADDR_DATA bus.
If this is a write cycle, the μC removes the address from the multiplexed address/data bus and
places the data to be written onto these signals. The write strobe (WR_N) is then asserted. If
this a read cycle, the μC 3-states the multiplexed address/data bus and asserts the read strobe
(RD_N) indicating that the CoolRunner-II SPI Master can place data from the addressed
register on the data bus.
If the CoolRunner-II SPI Master is being addressed and either RD_N or WR_N are asserted,
the CoolRunner-II SPI Master progresses to the DATA_TRS state. If this is a read cycle, the
requested data is placed on the bus and if this is a write cycle, the data from the data bus is
latched in the addressed register.
The μC latches the data present on the bus if this is a read cycle and then negates the read
strobe (RD_N). If this is a write cycle, the μC removes data from the bus and then negates the
write strobe (WR_N). The negation of either RD_N or WR_N causes the CoolRunner-II SPI
Master to progress to the END_CYCLE state. The CoolRunner-II CPLD will 3-state the
multiplexed address/data bus in this state, removing the data if it is a read cycle.
At this point, the μC ends the cycle by negating address latch enable (ALE_N), which causes
the CoolRunner-II CPLD to return to the IDLE state.
CoolRunner-II SPI Master Registers

The base address used for address decoding is set in the VHDL code via the constant
BASE_ADDRESS. The lower four address bits determine which register inside the CPLD is
being accessed. Each register address is set by a constant in the μC interface VHDL code that
can easily be modified to meet the addressing scheme of the system.

1-800-255-7778
R
The registers supported in the CoolRunner-II SPI Master are described in the Table 2. The μC
interface logic of the CoolRunner-II SPI Master handles the reading and writing of these
registers by the μC and supplies and/or retrieves these bits to/from the SPI interface logic.
Table 2: SPI Master Registers

Address Register VHDL Constant Description
BASE + $80\h SPISR SPISR_ADDR SPI Status Register
BASE + $84\h SPICR SPICR_ADDR SPI Control Register
BASE + $88\h SPISSR SPISSR_ADDR SPI Slave Select Register
BASE + $8A\h SPITR SPITR_ADDR SPI Transmit Data Register
BASE + $8E\h SPIRR SPIRR_ADDR SPI Receive Data Register
SPI Status Register (SPISR)

This register contains the status of the SPI controller. This status register is read-only with the
exception of certain bits which are software clearable as described in Table 3.
Table 3: Status Register Bits

Bit
7 Done Read Done Bit. While one byte of data is being transferred, this bit is cleared. It is
set during the eighth SCK clock period of a byte transfer.
• “1” transfer is complete
• “0” transfer in progress
6 SPIERR Read SPI Error Bit. When the SS_IN_N input pin is asserted, this bit is set
Software indicating an SPI error condition. The SPI interface resets and 3-states all
Clearable signals on the SPI bus. An interrupt will be asserted to the μC when this bit
is set if interrupts are enabled. This bit must be cleared by the μC writing a
"0" to this bit in the interrupt service routine. See Figure 11 for details on how
to handle an SPI error.
5 BB Read Bus Busy Bit. This bit indicates the status of the SPI bus. This bit is set when
a slave select line (SS_N) is asserted and cleared when a slave select line
(SS_N) is negated.
• “1” indicates the bus is busy
• “0” indicates the bus is idle
The μC should examine this bit to insure that the bus is not busy before
configuring the SPI interface for an SPI transaction.
4 INT_N Read Interrupt Bit. This bit is asserted (active low) when an interrupt is pending
Software which causes a processor interrupt request if INTEN is set. An interrupt is
Clearable asserted if any of the following conditions occur:
• The transmit register (SPITR) is empty and there are more data words
to transmit (START = 1)
• The receive register (SPIRR) is full and there are no more data words to
transmit (START = 0)
• An SPI error has occurred
This bit is negated whenever the μC writes data to the SPITR, reads data
from the SPIRR, or resets the SPIERR bit.

1-800-255-7778
R
Table 3: Status Register Bits (Continued)

Bit
3 XMIT_EMPTY Read Transmit Register Empty. This bit is set when the transmit register (SPITR)
is empty. It is cleared when the μC writes data into this register. An interrupt
will be asserted to the μC when this bit is set if interrupts are enabled and
there are more data words to transmit (START = 1). Note that this bit is also
an output pin.
2 RCV_FULL Read Receive Register Full. This bit is set whenever the receive register (SPIRR)
is full. It is cleared when the μC reads from this register. An interrupt will be
asserted to the μC when this bit is set if interrupts are enabled and there are
no more data words to transmit (START =0). Note that this bit is also an
output pin.
1-0 Unused Unused Bits. These bits will read as "0" when the status register is read.
SPI Control Register (SPICR)

This register contains the bits to configure the SPI Master. (Table 4)
Table 4: Control Register Bits

Bit
7 SPIEN Read/Write SPI Master Enable. This bit must be set before any other SPICR bits have
any effect
• “1” enables the SPI Master
• “0” resets and disables the SPI Master
6 INTEN Read/Write Interrupt Enable.
• “1” enables interrupts. An interrupt occurs if the INT_N bit in the status
register is also set
• “0” disables interrupts but does not clear the cause of any currently
pending interrupts
5 START Read/Write SPI Transfer Start. When the μC changes this bit from “0” to “1”, the SPI
Master begins to transfer the data in the SPI Transfer data register (SPITR)
on the SPI bus if XMIT_EMPTY is negated. All data received from the SPI
bus is captured in the SPI Receive data register (SPIRR). As long as this bit
stays asserted, SPI transfers will occur. After the μC has written the last data
word to be transferred in SPITR and XMIT_EMPTY asserts, the μC must
negate this bit to indicate that this is the last word in the SPI transfer.
4-3 CLKDIV Read/Write Clock Divider Bits. These bits determine the frequency of SCK by selecting
a divide by 4, 8,16, or 32 of the system clock.
• "00" - SCK is 1/4 of the system clock

1-800-255-7778
R
Table 4: Control Register Bits (Continued)

Bit
2 CPHA(1) Read/Write Clock Phase Bit. This bit determines the clock phase of SCK in relationship
to the serial data.
• "0" - data is valid on first SCK edge (rising or falling) after slave select
has asserted
• "1" - data is valid on second SCK edge (rising or falling) after slave
select has asserted
1 CPOL(1) Read/Write Clock Polarity Bit. This bit determines the polarity of SCK.
• "0" - SCK is low when idle
• "1" - SCK is high when idle
0 RCV_CPOL(1) Read/Write Receive Clock Polarity. This bit determines whether the MISO data is
sampled on the rising or falling edge of the outgoing SCK.
• "0" - MISO data is sampled on the falling edge of SCK
• "1" - MISO data is sampled on the rising edge of SCK
Note that in most cases, RCV_CPOL = "1" when CPHA is the same value
as CPOL and is "0" otherwise. However, this bit should be set according to
the slave that is being accessed.
Notes:
1. CPHA, CPOL, RCV_CPOL should be set to match the protocol expected by the SPI slave that is the target of the SPI bus cycle.
SPI Slave Select Register (SPISSR)

This register contains bits which indicate which slave select line should be asserted. A "1" in a
bit position indicates that the corresponding bit in the slave select output bus is asserted
according to the SPI timing specifications. A "0" in a bit position indicates that the
corresponding bit in the slave select output bus stays negated. This allows the μC to specify
which slave select line is asserted during a SPI data transfer. Note that only one slave select
line can be asserted during a SPI data transfer. This must be adhered to by the μC, the
hardware implementation of this specification does not enforce this requirement, in other
words, if the μC sets multiple bits in this register, multiple slave select lines will be asserted for
the SPI transfer. (Table 5)
Table 5: SPI Slave Select Register

Bit
7-0 SS_N7 - SS_N0 Read/Write SPI Slave Selects
SPI Transfer Data Register (SPITR)

This register contains data to be transmitted on the SPI bus on the MOSI pin (Table 6). Data
written into this register is output on the SPI bus once the START bit in the control register
(SPICR) has been asserted. As long as the START bit in the SPICR is asserted, additional
bytes of data in this register will continue to be transmitted on the SPI bus.
Once this data has been loaded into the SPI transmit shift register, XMIT_EMPTY asserts and
the μC can place the next data byte for transmission on the SPI bus into this register. Writing
data into this register resets the XMIT_EMPTY flag. Note that XMIT_EMPTY must be negated

1-800-255-7778
R
and START must be asserted before the SPI state machine will begin transmission of data on
the SPI bus.
Table 6: SPI Transmit Data Register

Bit
7-0 D7 - D0 Read/Write SPI Transmit Data
SPI Receive Data Register (SPIRR)

This register contains the data received from the SPI bus on the MISO pin. When a byte of data
has been received from the SPI bus and transferred to the SPIRR, the RCV_FULL flag asserts.
The μC then reads data from the SPIRR which resets the RCV_FULL flag. Because data is
loaded from the SPI receive shift register to the SPIRR, the μC has an entire 8-bit SPI transfer
to read the data from the SPIRR. (Table 7)
Table 7: SPI Receive Data Register

Bit
7-0 D7 - D0 Read/Write SPI Receive Data
SPI Interface The SPI bus interface logic consists of several different processes as seen in Figure 4. Control
Logic bits from the μC interface registers determine the behavior of these processes.
SPI Control State Machine

This process generates the slave select signals and controls the shift and load operations of the
SPI transmit shift register. It also monitors the SPI bus and determines when a byte transfer is
complete. This process also generates clock mask signals that control when the clock is output
to the SPI bus. If the START signal stays asserted after a byte has been transferred, the state
machine will continue to output the next byte and the SCK signal continues to transition. Note
that if CPHA = 0, the slave select signal will negate and then re-assert between consecutive
byte transfers as stated in the SPI specification. If the START signal is negated after a byte has
been transferred, then the state machine first insures that the current transfer has been
completed and the SCK output is placed in its inactive state as determined by CPOL. The slave

1-800-255-7778
R
select is then negated after the required hold time. The SPI control state machine is shown in
Figure 7.
IDLE
start=1
xmit_empty=0
ASSERT_SSN1
sck_int_re=1
ASSERT_SSN2
sck_int_fe=1
UNMASK_SCK
sck_int_re=1
bit_cnt < > 8
XFER_BIT
bit_cnt=8
cpha=1 ASSERT_DONE
start=1
xmit_empty=0
sck_int_fe=1
CHK_START
start=0 or
cpha=0 and ((cpol=0 and sck_fe=1) or
(cpol=1 and sck_re=1))
MASK_SCK
sck_int_fe=1
HOLD_SSN1
sck_int_fe=1
sck_int_fe=1 HOLD_SSN2
sck_int_fe=1
NEGATE_SSN
X386_07_121202
Figure 7: SPI Control State Machine
The SPI Control state machine remains in the IDLE state until the START bit in the SPI Control
register is asserted and the XMIT_EMPTY signal is negated. At this point, the state machine
moves to the ASSERT_SSN1 state to assert the internal SS_N signal. This signal is then
masked with the SPI Slave Select Register (SPISSR) to generate the slave select signals
output to the system. After a rising edge of the internal SCK (SCK_INT_RE=1), the state
machine transitions to the ASSERT_SSN2 state, keeping SS_N asserted until the falling edge
of the internal SCK. This state machine will insure that SS_N will assert ~1 SCK period before
the first SCK edge, meeting the SS_N setup time requirement of most SPI slave devices. This
timing parameter should be verified by the designer for the target system as the SS_N setup
time requirement may vary between different SPI slaves.
After SS_N has been asserted for both the ASSERT_SSN1 and ASSERT_SSN2 states, the
state machine transitions to the UNMASK_SCK state. The first edge of the phase 1 (CPHA=1)
version of SCK occurs before the first data is output, therefore, this state unmasks the phase1
version of SCK. The SPI transmit shift register is loaded with data from the SPITR in this state.
The SPI transmit shift register is clocked by the rising edge of the internal SCK signal. The state

1-800-255-7778
R
machine waits for a rising edge of the internal SCK signal (SCK_INT_RE) to leave this state to
insure that the SPI transmit shift register has been loaded.
The state machine then moves to the XFER_BIT state. The first edge of the phase 0 (CPHA=0)
version of SCK occurs after data has been output, therefore, this state unmasks the phase 0
version of SCK. This state shifts data from the SPI transmit shift register and the state machine
remains in this state until the byte transfer is complete. Once the byte transfer has completed,
the state machine transitions to the ASSERT_DONE state where the DONE signal in the SPI
Status Register (SPISR) is asserted. The state machine will not transition to the CHK_START
state until the next falling edge of the internal SCK to synchronize this state machine to the
internal SCK.
The SPI specification requires that SS_N be negated and re-asserted between consecutive
byte transfers when CPHA=0. If CPHA=1, SS_N can remain asserted during consecutive byte
transfers. Therefore, if START is still asserted in the CHK_START state and CPHA=1 and
XMIT_EMPTY is negated, the state machine transitions back to the UNMASK_SCK state and
continues SPI transfers. If START is negated or CPHA=0, the state machine transitions to the
MASK_SCK state which masks both the phase 0 and the phase1 versions of SCK. Note,
however, that the state machine waits for either the rising edge (if CPOL=1) or the falling edge
(if CPOL=0) of the external SCK before transitioning to this state to insure that the transmission
has been completed before masking the external clock.
At the next falling edge of the internal SCK (SCK_INT_FE), the state machine transitions to the
HOLD_SSN1 state. SS_N must stay asserted for some time period after the last SCK edge.To
insure that the SS_N hold time is at least 2 SCK periods, the state machine transitions to
HOLD_SSN2 after the next falling edge of the internal SCK (SCK_INT_FE) and remains in this
state until another falling edge of the internal SCK has occurred. This will meet the SS_N hold
time requirement of most SPI slave devices. This timing parameter should be verified by the
designer for the target system as the SS_N hold time requirement may vary between different
SPI slaves.
At this point, the state machine transitions to the NEGATE_SSN state and remains in this state
until the next falling edge of the internal SCK. This insures that the pulse width of SS_N
between SPI transfers is at least one SCK period. This will meet the SS_N pulse width
requirement of most SPI slave devices. This timing parameter should be verified by the
designer for the target system as the SS_N pulse width requirement may vary between different
SPI slaves.
The state machine then transitions to the IDLE state. If START is asserted and XMIT_EMPTY
is negated, the SPI transfer and state machine operation will repeat.
Note that if no further SPI transfers are required, the μC must negate the START signal after
writing the last data word of the transmission to the SPITR as shown in Figure 11.
Also note that at any time, the assertion of SS_IN_N will cause the SPI Control state machine
to return to the IDLE state and the MOSI, SS_N, and SCK outputs will be 3-stated. The SPI
Master will remain in this state until the SS_IN_N signal is negated and the START signal is
asserted. When a SPI error occurs, the system must be examined to determine the cause of
the error. The μC can reset the bit in the SPI status register (SPISR) and then continue to read
the SPI status register (SPISR) to determine if the system error has been corrected. Once the
error has been fixed at the system level, the SPI interface should be reset to guarantee correct
operation as shown in Figure 11. The μC can reset the SPI Master by negating the SPIEN bit
in the SPI control register (SPICR).
Transmit Empty and Receive Full Flags

The transmit empty flag (XMIT_EMPTY) is set whenever data is loaded from the SPITR to the
SPI transmit shift register. This signal is clocked from the internal SCK and is reset whenever
the μC writes data into the SPITR or when the system reset signal is asserted.

1-800-255-7778
R
The receive full flag (RCV_FULL) is set whenever data is loaded from the SPI receive shift
register to the SPIRR. This signal is clocked from the system clock and is reset whenever the
μC reads data from the SPIRR.
SCK Clock Logic

This process generates the SCK output based on the CLKDIV, CPHA, and CPOL settings in
the SPI control register. The clock frequency of the SCK signal is determined by dividing down
the input clock based on the entries in the control register. The signal, SCK_INT is the internal
SCK used to clock serial data out of the device and is continually generated. The SPI Control
state machine is synchronized to this internal signal. The signal SCK_1 represents SCK when
CPHA = 1 and the signal SCK_0 represents SCK when CPHA = 0. The SPI control state
machine generates the masks for these clocks (CLK0_MASK, CLK1_MASK) so that the output
SCK has the correct phase relationship with the data and is held in its inactive state when there
is no data to be transferred. A representation of the logic required to generate the SCK signal
output to the SPI bus is shown in Figure 8.
clk_cnt(1) clk0_mask
sck_0
clk_cnt(2)
sck_int
Clock clk_cnt(3) Mux/Reg sck_out
Mux/Reg
Counter clk_cnt(4) sck_1
clk1_mask
clkdiv(0)
cpha
sys_clk
clkdiv(1)
cpol
sys_clk
sys_clk
X386_08_121202
Figure 8: SCK Clock Generation Logic
SPI Shift Registers

SPI Transmit Shift Register
The SPI transmit shift register is an 8-bit loadable shift register containing SPI data. This shift
register is loaded from the SPI Transmit Register (SPITR) via a load signal generated by the
SPI Control state machine and is clocked by the rising edge of SCK_INT. The data shifting out
is the MOSI data. Note that in Figure 8, SCK_OUT is one SYS_CLK delay from SCK_INT.
Therefore, it is necessary to delay the data being shifted out from the SPI transmit shift register
by one SYS_CLK as well so that the relationship between MOSI and SCK_OUT is maintained.

1-800-255-7778
R
This is accomplished by a single register clocked from SYS_CLK which simply clocks the data
output from the shift register as shown in Figure 9..
data from
SPI Transmit
Register 8
MOSI
8-bit SPI Xmit Shift Register MOSI
Register
load sys_clk
shift
sck_int
X386_09_121202
Figure 9: SPI Transmit Shift Register
SPI Receive Shift Register

A separate shift register is used to receive the MISO data since the clock phase and polarity of
the SCK output can vary based on each transaction. The SPI receive shift register is clocked on
the rising edge of the external SCK. The RCV_CPOL bit set in the control register allows the μC
to specify which edge of the external SCK incoming MISO data is sampled on. This allows for
flexibility in dealing with all types of different SPI slave devices as some SPI slaves will clock
data out on the rising edge of SCK while others will clock data out on the falling edge of SCK.
If a slave clocks data out on the falling edge of SCK, then RCV_CPOL should be set to "1" so
that the CoolRunner-II SPI Master will clock data in on the rising edge of SCK. If a slave clocks
data out on the rising edge of SCK, then RCV_CPOL should be set to "0" so that the
CoolRunner-II SPI Master clocks data in on the falling edge of SCK. This eliminates any setup
and hold timing issues. If slaves behave according to the SPI specification for CPHA and
CPOL, RCV_CPOL will equal "1" whenever CPHA and CPOL are equal and "0" otherwise.
In the actual implementation, two input registers are used to sample MISO, one clocked on the
rising edge of SCK, the other clocked on the falling edge of SCK. The outputs of these two
registers are then multiplexed with the RCV_CPOL bit used as the select line. The output of this
multiplexor then becomes the input to the SPI receive shift register which is clocked on the
rising edge of the external SCK. Using this implementation method eliminates multiplexing
clocks inside the CPLD. Multiplexing clocks within the CPLD places a delay between SCK and
the actual data input to the shift register. This delay on SCK could impose an additional data
hold time requirement on the slave device which is undesirable. Therefore, it was decided to
multiplex the data instead, thus eliminating the need to specify a holdtime requirement on the
slave device.
A counter, clocked off the rising edge of the external SCK, is used to count the bits shifted into
the SPI receive shift register and to indicate when a byte transfer is complete. When the byte
transfer is complete, the data in the SPI receive shift register is loaded into the SPI Receive

1-800-255-7778
R
Register for use by the μC. The SPI receive shift register, MISO input registers, and receive bit
counter are shown in Figure 10.
data to
SPI Receive
Register rcv_load
8
MISO
MISO
SCK Register
MUX 8-bit SPI Receive Shift Register
MISO
Register
shift
rcv_cpol Receive
sck_int
Bit Counter
X386_10_121202
Figure 10: SPI Receive Shift Register and MISO Input Data Registers
Operational The flow of the interface between the μC and the CoolRunner-II SPI Master is detailed in the
Flow Diagrams following flow charts. These flow charts are meant to be a guide for utilizing the CoolRunner-II
SPI Master in a μC system.
SPI Transaction Flow Chart

The flow chart for configuring and performing a SPI transaction for the CoolRunner-II SPI
Master is shown in Figure 11. Since SPI is a full duplex communication protocol, data is
received while data is transmitted.
Note that if an SPI error occurs indicating that another master has taken control over the bus,
the system operation should be verified. The flow chart shows continually polling SPIERR in
the status register to determine when the SPI error has been corrected. Since an SPI error also
asserts an interrupt (if interrupts have been enabled), an alternative to polling the SPI status
register (SPISR) is to service the interrupt to determine if the SPI error has been corrected.
Note that either of these flows may not be the operational flow required by a system when an

1-800-255-7778
R
SPI error has occurred; the designer should determine the correct operations to execute when
an SPI error occurs based on the system requirements.
BEGIN
No
Read SPI Bus
XMIT_EMPTY
Status from SPISR =1?
Yes
Yes
Bus Busy= 1? Yes
Last Word?
No
Negate START bit
No in SPICR
Configure SPI Master
by writing to SPICR: Write SPI Transmit
SPIEN, INTEN, Data in SPITR
CLKDIV, CPHA
CPOL, RCV_CPOL
Configure Slave Select

in Slave Select Register
(SPISSR)
No
Write SPI Transmit RCV_FULL
Data in SPITR =1?
Yes
Set START bit in SPITR
Read SPI Receive
Data in SPIRR
No Interrupt
(INT_N=0)?
No
Last Word?
Yes
Read SPI Bus Status Yes
from SPISR
No
SPIERR = 1?
Yes
Reset SPIERR in SPISR
Read SPI Bus Status

from SPISR
Yes END
SPIERR = 1?
No
Reset SPIEN in SPICR

to reset SPI Master
X386_11_121202
Figure 11: CoolRunner-II SPI Master Transaction Flow Chart

1-800-255-7778
R
VHDL A VHDL testbench has been developed that verifies the CoolRunner-II SPI Master
Testbench and implementation through all the possible combinations of CLKDIV, CPHA, CPOL, and
RCV_CPOL. This testbench contains a process that emulates the bus cycles of the 8051 μC.
Functional Constants are provided at the top of the testbench file to set up the base address of the SPI
Simulation Master device and all of the registers contained within the device. These constants should be
modified to match the addressing scheme of the designer’s system.
The VHDL testbench also provides a model of a simple SPI slave. The slave first transmits the
hex value "CE" and then simply transmits the value that was received. The clock phase and
polarity of the slave are dynamically set in the test bench based on the CPHA and CPOL values
currently being tested.
To test the SPI Master reaction to an SPI error, the test bench contains the constant
SS_IN_ASSERT_TIME which specifies the delay from the beginning of the simulation until
SS_IN_N is asserted and also specifies the amount of time that SS_IN_N is asserted. Setting
this constant to "0" disables assertion of SS_IN_N.
The test bench contains a signal, ERROR, which indicates that the data received did not match
the expected data. The simulation has run correctly if ERROR stays "0" throughout all SPI
transfers. Note, however, that ERROR may assert some time during the simulation if the
testbench is set up to test SS_IN_N assertion. This is due to the fact that the data received may
be out of alignment with the expected data value.
The ModelSim command file, func_sim.do, can be used to open the correct waveform window
and run the simulation.
CoolRunner-II The CoolRunner-II SPI Master design has been targeted to a CoolRunner-II 256 macrocell
CPLD device. The speed grade chosen is dependent on the system clock frequencies and should be
analyzed by the designer to determine which speed grade is required.
Implementation
The CoolRunner-II SPI Master utilizes 128 of the 256 macrocells available in the device,
leaving 50% of the device resources for user logic.
The top level file for the SPI Master has been entered as a heirarchical VHDL file showing the
connection between the uc_interface block and the spi_interface block. The spi_interface block
is also a hierarchical VHDL fileshowing the inter connectivity between the spi_control_sm
block, the sck_logic block, the spi_rcv_shift_reg block and the spi_xmit_shift_reg block. The
structural VHDL models are found in the files spi_master.vhd and spi_interface.vhd.
Post-fit Timing The Xilinx Project Navigator software package outputs a timing VHDL model of the fitted
Simulation design. This post-fit VHDL was simulated with the original VHDL test benches to insure design
functionality using ModelTech Xilinx Edition (MXE). Please note that all verification of this
design has been done through simulations.
The user of this design is strongly encouraged to thoroughly inspect the timing report for this
design to insure that the design meets the timing specification of the system. The user is also
strongly encouraged to perform post-fit timing simulations as well. The ModelSim command
file, post_sim.do, can be used to open the correct waveform window and run the simulation.
VHDL Code All VHDL source code, VHDL testbenches, and software files associated with this design are
Download and available. THE DESIGN IS PROVIDED TO YOU "AS IS". XILINX MAKES AND YOU RECEIVE
NO WARRANTIES OR CONDITIONS, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE,
Disclaimer AND XILINX SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.
This design should be used only as an example design, not as a fully functional core. XILINX
does not warrant the performance, functionality, or operation of this Design will meet your
requirements, or that the operation of the Design will be uninterrupted or error free, or that
defects in the Design will be corrected. Furthermore, XILINX does not warrant or make any

1-800-255-7778
R
representations regarding use or the results of the use of the Design in terms of correctness,
accuracy, reliability or otherwise.
THIRD PARTIES INCLUDING MOTOROLA MAY HAVE PATENTS ON THE SERIAL
PERIPHERAL INTERFACE (SPI) BUS. BY PROVIDING THIS HDL CODE AS ONE POSSIBLE
IMPLEMENTATION OF THIS STANDARD, XILINX IS MAKING NO REPRESENTATION THAT
THE PROVIDED IMPLEMENTATION OF THE SPI BUS IS FREE FROM ANY CLAIMS OF
INFRINGEMENT BY ANY THIRD PARTY. XILINX EXPRESSLY DISCLAIMS ANY
WARRANTY OR CONDITIONS, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, AND
XILINX SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE, THE ADEQUACY OF
THE IMPLEMENTATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OR
REPRESENTATION THAT THE IMPLEMENTATION IS FREE FROM CLAIMS OF ANY THIRD
PARTY. FURTHERMORE, XILINX IS PROVIDING THIS REFERENCE DESIGNS "AS IS" AS A
COURTESY TO YOU.
XAPP386 - ftp://ftp.xilinx.com/pub/applications/refdes/xapp386.zip
Conclusion This document has detailed the design of a Serial Peripheral Interface Master design for a
CoolRunner-II CPLD. Though the design has been extensively verified in simulations, Xilinx
assumes no responsibility for the accuracy or the functionality of this design.
History

1-800-255-7778
R
Design of a Digital Camera with
CoolRunner-II CPLDs
XAPP390 (v1.1) September 27, 2005
Summary This document describes a digital camera reference design using a CoolRunner-II™ CPLD.
The low power capabilities of CoolRunner-II CPLD devices make them the ideal target for
portable, handheld applications such as digital cameras. The complete reference design is
available for download in “VHDL Code,” page 126.
Introduction Digital cameras have become increasingly popular over the last few years. Digital imaging
technology has grown to new markets including cellular phones and PDA devices. With the
diverse marketplace, a variety of imaging technology must be available. Imaging technology
has expanded to include both charge-coupled device (CCD) and CMOS image sensors.
One of the leaders today in digital imaging technology is Micron Technology, Inc. The products
available from Micron include CMOS image sensors that range from CIF-size to 1.3 megapixel
sensors that achieve CCD quality images. For more information on Micron Technology refer to
“References,” page 127.
Video Formats
Until recently, most video equipment was designed for analog video. Today, digital video has
become increasingly available in consumer applications. The most common digital video
formats include RGB and YCrCb. RGB is the digital version of the analog RGB signal, while
YCrCb is the digital version of analog YUV and YPbPr video signals.
The structure of a video stream is actually a series of still images or frames. Video is measured
by frames per second or fps. Typical video is about 60-70 fps. Each frame is composed of lines
of data. The size of an image is determined by the number of lines per frame and the number
of data pixels in each line. For instance, a VGA size image is 480 lines of data that contain 640
pixels of data in each line. So the corresponding VGA image size is 640 x 480 = 307,200 pixels.
For more information on digital video formats refer to “References,” page 127.
Digital Imaging
CMOS vs. CCD
A CMOS or CCD image sensor provides the technology to digitally capture an image and/or
streaming video. CCD image sensors are used in many high end applications, such as high-
resolution digital cameras. CCD image sensors provide a better picture in low-light
environments over CMOS image sensors, but can be costly to manufacturer and integrate into
a system.
CMOS image sensors draw much less power than CCDs. The digital camera system is able to
run longer on batteries, a major advantage in handheld products. Since CMOS sensors use the
same manufacturing platform as most microprocessors and memory chips, they are easier to
produce and more cost effective than CCDs. CMOS image sensors require a single power
supply for operation and only 20-50 milliwatts per pixel output.
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 109

R
Introduction
Micron MI-SOC-0343
The image sensor utilized in this digital camera reference design was manufactured by Micron
Technology, Inc. The MI-SOC-0343 is a complete CMOS image sensor camera-on-chip
solution. The MI-SOC-0343 incorporates an "active pixel" sensor architecture core, plus a
digital image processor or IFP. The MI-SOC-0343 can output digitally processed RGB or
YCrCb data. This CMOS image sensor is a 640 x 480 VGA size sensor and has over 100
programmable registers for customizing. Figure 1 illustrates a block diagram of the MI-SOC-
0343 image sensor.
Imager Core Image Flow Processor
Color Correction Data Output

Active Pixel Array Image Core and Timing
Gamma Control
(640 x 480) Register Set
Sharpening Control
Saturation Control
Auto White Balance
Auto Exposure IFP
Analog 10-bit Defect Correction Register Set
Processing ADC Lens Detection
Serial Interface
(SCLK, SDATA) X390_01_090303
Figure 1: MI-SOC-0343 Block Diagram
Active Pixel Architecture

The "active pixel" architecture is shown in Figure 2. The "active pixel" architecture consists of
an amplifier dedicated to each photodiode in the image array. The sensor photodiode is the
area of the silicon that detects light. In a CMOS image sensor, the photosite area is about 75%
(or commonly referred to as the sensor fill factor). The active amplifier circuitry consumes
110 www.xilinx.com XAPP390 (v1.1) September 27, 2005

R
Introduction
approximately 25% of the die area. The "active pixel" architecture developed by Micron
eliminates background noise and prevents image effects such as "line streaking".
Photodiode Active-Pixel Architecture Photogate Active-Pixel Architecture

Images courtesy of Micron
Figure 2: Active Pixel Architecture
Bayer CFA
Each photosite in the "active pixel" sensor array can detect light. It is necessary, however, to
distinguish between colors. The Bayer Color Filter Array (or CFA) was invented to
independently measure red, green, and blue photons. The Bayer CFA is an repeating 2x2
matrix in the image array to measure each color. Diagrams in Figure 3 illustrate aspects of the
Bayer CFA.
G R G R G R G R
B G B G B G B G
G R G R G R G R
B G B G B G B G
G R G R G R G R
B G B G B G B G
Images courtesy of Micron
Figure 3: Bayer CFA

R
Introduction
Image Flow Processor

The imager core outputs a raw RGB data stream to the image flow processor (or IFP) of the MI-
SOC-0343. The IFP is responsible for interpolating one color per pixel into three colors per pixel
by filling in missing data based on adjacent pixels.
The IFP is responsible for the following functions:
• Color Correction: Corrects or enhances the color of an image by accounting for
differences between the image sensor and human eye observations.
• Gamma Control: Corrects the image for observation on an LCD.
• Sharpening Control
• Saturation Control: Controls the amount of gray in a color.
• Auto White Balance
• Auto Exposure
• Defect Correction: Substitutes pixel defects (single dark or bright pixels) with neighboring
pixel data.
• Lens Detection
• Zoom Features: Allows the image size to be larger or smaller.
Digital Video Capture

The IFP can output either 4:2:2 YCrCb (CCIR656) or 4:4:4 565RGB data. Data is sampled out
of the IFP according to the vertical and horizontal control signals as shown in Figure 4. The
signal, PIX_CLK, is the sample clock from the MI-SOC-0343. The signal, FRAME_VALID, is the
vertical synchronization control and the signal, LINE_VALID, is the horizontal synchronization
control from the MI-SOC-0343. Both data output formats, YCrCb and RGB are shown for an 8-
bit data bus from the image sensor.
Start Start End End End

of of first of first of last of
frame line line line frame
PIX_CLK
FRAME_VALID
LINE_VALID
DOUT (7:0) (YCrCb) Cb0 Y0 Cr0 Y1 Ylast
DOUT (7:0) (RGB)
R[4:0] G[5:0] B[4:0]

X390_04_090203
Figure 4: Video Capture Timing
LCD Technology
In a digital camera design, the captured image from the sensor may be stored in a memory
component. It is necessary to send this image data to either a peripheral device or a display. In
a digital camera application, an LCD or liquid crystal display is the desired solution. The best
display for video applications is a color active matrix TFT (or thin film transistor). Most TFT
modules offer display resolution with sub-pixels. This allows each pixel to individually display
three colors per pixel or each red, green, and blue color.
The two main types of LCD polarization include: transmissive or transflective. Transmissive
LCDs require a backlight that allows light to shine through the back of the LCD and activate

R
CoolRunner-II Design
pixels in the display. Transflective LCDs have a specific type of backing that allows light to
shine through the back of the LCD as well as reflect light from the front of the LCD.
Most TFT LCDs have integrated IC drivers that connect in a grid pattern to access all pixels in
the display. With this type of integration, the LCD can be driven through a digital parallel data
interface.
The LCD selected in this CoolRunner-II digital camera reference design is manufactured by
Optrex of America, Inc. For more information on Optrex refer to “References,” page 127. The
display in this reference design is part # T-51382D064J-FW-P-AA. This display is an 6.4"
transmissive color active matrix TFT. The display has an integrated driver and is accessible
through a parallel 6-bit RGB data interface. The display resolution is VGA size or 640 x (RGB)
x 480. This Optrex display is a dual CCT or cold cathode tube display. A block diagram of the
Optrex 51382 device is shown in Figure 5.
Timing CCT
Logic
Vertical IC Driver
Horizontal IC Driver
LCD Panel
(640 x 480)
CCT
X390_05_090303
Figure 5: Optrex Block Diagram
CoolRunner-II The complete CoolRunner-II digital camera reference design is shown in Figure 6. The
Design CoolRunner-II CPLD is the central controller for the camera design. The CPLD is responsible
for capturing data from the Micron image sensor, storing the image data in SRAM, and sending
the image data to the Optrex display. The CPLD is also responsible for initializing the Micron
image sensor through a configurable register set. The CPLD is also responsible for generating
the PWM pulse that controls the brightness of the Optrex LCD. An inverter controls the voltage
applied to the CCT of the Optrex display.
CoolRunner-II CPLD
SHIP Main LCD

CMOS Interface Control Interface LCD
Image Control Logic Logic Control Panel
Sensor Logic
Image SRAM
Grabber Interface PWM
Logic Inverter
Control Logic Logic
SRAM
X390_06_090303
Figure 6: Digital Camera Block Diagram

R
Main Control Logic

The Main Control Logic block shown in Figure 6 is responsible for the high level operation of the
digital camera. This module starts the initialization of the image sensor by releasing control of
the SHIP Interface Logic. After initialization is complete, the Main Control Logic starts capturing
image data by asserting a get_frame_data flag. Once the Image Grabber Logic has captured
an image and stored the image data in SRAM, a get_data_done flag is asserted. The Main
Control Logic then gives control to the LCD Interface module that reads data from SRAM and
send the image data to the LCD module. These steps are shown in Figure 7, an illustration of
the Main Control Logic state machine. The current implementation of the Main Control Logic
state machine is setup for streaming video. Future implementation includes adding user inputs
to capture still images.
IDLE
ship_init_done = '0'
WAIT_SHIP_INIT
ship_init_done = '1'
GET_DATA
get_data_done= '0'
WAIT_IMAGE_DATA
get_data_done= '1'
LCD_DATA
lcd_done = '0'
DONE
lcd_done = '1'
X390_07_090303
Figure 7: Main Control Logic State Machine
SHIP Interface Control Logic

The SHIP Interface Control Logic is responsible for writing all the necessary registers of the
Micron image sensor upon power up of the camera module. This includes both imager core
registers and IFP registers. Communication to registers on the MI-SOC-0343 is done via a
serial link with two signals, SCLK and SDATA. This Serial Host Interface Protocol, or SHIP is
similar to the I2C standard. In this implementation, the MI-SOC-0343 is the slave device while
the CoolRunner-II CPLD is the master device.
The SCLK and SDATA serial lines are externally terminated to 3.3V with a 1.5 K ohm resistor.
Either the master or slave device can pull the line down for communication. The clock frequency
of SCLK is approximately 100 KHz.
The SHIP protocol for writing a specific register of the MI-SOC-0343 is as follows (shown in
Figure 8):
1. Start condition.
2. Send slave device 8-bit address (Value = B8 (hex) for a MI-SOC-0343 write condition).
3. An acknowledge bit is sent by slave device.
4. Master sends the 8-bit register address.
5. An acknowledge bit is sent by the slave device.

R
6. Master sends upper 8-bits of data.

8. Master sends lower 8-bits of data.
10. Master stops operation with a stop condition.
A start condition is defined as a HIGH to LOW transition on SDATA, while SCLK is HIGH. A stop
condition is defined as a LOW to HIGH transition on SDATA, while SCLK is HIGH. Figure 8
illustrates the timing for a write sequence to IFP register 01 (hex) with a value of 0004 (hex).
SCLK
SDATA
Send register Send upper Send lower

Send slave address ACK ACK ACK ACK
address data byte data byte
Value = B8 (hex)
Value = 01 (hex) Value = 00 (hex) Value = 04 (hex)
Start Stop
Condition Condition
X390_08_090303
Figure 8: SHIP Write Sequence
Refer to the MI-SOC-0343 data sheet for a detailed description of all available registers on the
image sensor. Table 1 lists a few of the registers that were utilized in this CoolRunner-II digital
camera implementation.
Table 1: Sample CPLD Register Set

Register (hex) Value (hex) Purpose
IFP 01 0004 Controls register address space for SHIP communication.
IFP 08 DD00 Specifies output timing and format (selects RGB output).
IFP 48 0040 Enables color bar test-pattern generation.
IC 06 000A Select vertical blanking time (10 rows).
IC 3B 02B0 Sets the on-chip voltage reference.
IC 5F 8984 Used for black level calibration.
Figure 9 illustrates the main components that generate the SHIP interface logic. Upon a system
reset, the SHIP interface logic starts to configure the desired registers in the MI-SOC-0343
device. The registers to write in the MI-SOC-0343 are determined at configuration time of the
CPLD. All register addresses and data are stored in the CPLD by building a ROM type structure
in the PLA (or programmable logic array) of the CoolRunner-II architecture. The SHIP_TOP
state machine shown in Figure 9 will sequence through each register write. The

R
SHIP_INTERFACE block shown in Figure 9 controls the generation of SCLK and SDATA on the
SHIP serial communication.
ship_init_done
mi_pixclk
sys_reset
MI-SOC-0343
SHIP_INTERFACE
SCLK ship_addr (7:0)
Imager Core SHIP ship_data (15:0) SHIP_TOP
Register Set State Machine State Machine
SDATA ship_start
ship_done
IFP Register Set SHIFT8
UPCNT4
UPCNT8
X390_09_090303
Figure 9: SHIP Interface Block Diagram
SHIP Top Level Logic

Figure 10 illustrates the state machine logic for the top level SHIP logic. The top level SHIP
logic is responsible for sequencing through the list of desired register writes. This state machine
controls which registers of the MI-SOC-0343 are written to upon start up. The top level SHIP
logic creates and assigns the register address and data, ship_addr (7:0) and ship_data (15:0)
to the SHIP_INTERFACE logic. A register write sequence is initiated with the assertion of

R
ship_start control signal. When the SHIP_INTERFACE logic has completed the single register
write, the ship_done flag is asserted.
sys_reset = RESET_ACTIVE
IDLE
sys_reset \= RESET_ACTIVE
ship_done = '1'
WR_IFPn
ship_done = '0'
WAIT_WR_IFPn ship_done = '0'

Loop for number
of IFP registers
to write ship_done = '1'
ship_done = '1'
WR_IFP01
ship_done = '0'
WAIT_WR_IFP01 ship_done = '0'
ship_done = '1'
ship_done = '1'
WR_ICn
ship_done = '0'
WAIT_WR_ICn ship_done = '0'

Loop for number
of IC registers
to write ship_done = '1'
DONE
X390_10_090403
Figure 10: SHIP Top Level State Machine
SHIP Interface Logic

Figure 11 illustrates the state machine logic for the SHIP_INTERFACE component. The
SHIP_INTERFACE state machine is responsible for loading an 8-bit shift register, SHIFT8
component, with the data to shift out on SDATA. The state machine loads an 8-bit shift register
with the MI-SOC-0343 slave address, followed by the register address, followed by the upper
data byte, and then concluding with the lower data byte. This sequence is illustrated in Figure 8.
The SHIP_INTERFACE state machine will be repeated for the number of registers being
written to initialize the MI-SOC-0343 device. This state machine receives the register address
and register data to write on the SHIP serial communication link. The register address is stored
in the signal, ship_addr (7:0), provided by the top level SHIP control logic. The register data is
stored in the signal, ship_data (15:0), provided by the top level SHIP control logic. The

R
SHIP_INTERFACE block starts each register write with the assertion of ship_start. When
complete, the ship_done flag is asserted back to the SHIP top level logic.
detect_start = '0'
IDLE
detect_start = '1'
bit_qout < BIT_COUNT

SHIFT_MI_ADDR
bit_qout = BIT_COUNT
WAIT_ACK_MI_ADDR

SHIFT_REG_ADDR
WAIT_ACK_REG_ADDR

SHIFT_UDATA
WAIT_ACK_UDATA

SHIFT_LDATA
WAIT_ACK_LDATA
DONE
X390_11_090403
Figure 11: SHIP Interface State Machine
When the SHIP Control Logic has completed writing all necessary registers, the ship_init_done
flag is asserted back to the Main Control Logic state machine.
SCLK & SDATA Generation

To complete the SHIP Interface Logic, one more state machine is needed. This state machine,
SCLK_GEN is responsible for generating the SCLK and SDATA control signals. This state
machine provides the required setup and hold times on SDATA with respect to SCLK. This state
machine will also generate the start and stop conditions as specified in the SHIP interface. This

R
state machine will generate the necessary 100 KHz SCLK based on the 13 MHz frequency of
the image sensor pixel clock. Figure 12 illustrates the SCLK_GEN state machine.
gen_start = '0'
IDLE
gen_start = '1'
clk_qout < START_HOLD

START
clk_qout = START_HOLD
SCLK_LOW_EDGE
clk_qout < LOW_SCLK

SCLK_LOW
clk_qout = LOW_SCLK
SCLK_HIGH_EDGE
clk_qout < HI_SCLK

SCLK_HIGH
clk_qout = HI_SCLK
clk_qout < TBUF

DONE
clk_qout = TBUF
X390_12_090403
Figure 12: SCLK_GEN State Machine
Image Grabber Control Logic

Once the MI-SOC-0343 image sensor is initialized, valid frames can be captured. A single
frame can be captured at a time and stored into memory. The defined interface between the
CoolRunner-II CPLD and the MI-SOC-0343 device is shown in Figure 13.
mi_pixclk Image Grabber sys_reset

mi_frame_valid Control Logic get_frame_data
MI-SOC-0343 get_frame_done to/from Main
mi_line_valid
Image Grabber pixel_data (15:0) Control Logic
mi_data (7:0)
State Machine sram_addr_clr
sram_addr_cnt_en
X390_13_090403
Figure 13: MI-SOC-0343 Interface
The Main Control Logic asserts the get_frame_data control signal to the Image Grabber
Control Logic to capture a single image from the sensor and store the data in SRAM. The timing

R
for capturing an image is shown in Figure 4, page 112. The state machine logic for capturing an
image is shown in Figure 14.
get_frame_data = '0'
IDLE
get_frame_data = '1'
fv_edge_detect = '0'
WAIT_FV
fv_edge_detect = '1'
mi_line_valid = '0'
CAP_FV
mi_frame_valid = '0'
mi_line_valid = '1'
DONE
CAP_LDATA
CAP_UDATA
mi_line_valid = '1'
mi_line_valid = '0' &

mi_frame_valid = '1'
X390_14_090403
Figure 14: Image Grabber State Machine
Table 2 below describes the functionality of each state in the Image Grabber state machine.
Table 2: Image Grabber State Description

State Name Purpose
IDLE Wait for assertion of get_frame_data control signal.
WAIT_FV Wait for assertion on rising edge flag of mi_frame_valid signal.
CAP_FV Wait for rising edge of mi_line_valid. If mi_frame_valid signal is
negated, go to DONE state.
CAP_LDATA Capture lower byte of image data on rising edge of mi_pixclk. If
mi_line_valid is still asserted, go to CAP_UDATA state. If
mi_line_valid is negated, go to CAP_FV to start data capture for next
line of frame. In this state, the pixel data word is written to SRAM by
asserting the WEn signal (sram_wen).
CAP_UDATA Capture upper byte of image data on rising edge of mi_pixclk.
DONE Assert get_data_done flag.
LCD Interface Control Logic

The CoolRunner-II digital camera reference design uses an LCD to display images captured by
the image sensor and stored into memory. The LCD interface in this reference design is a pure
digital interface. The data bus is 18-bits wide with 6-bits dedicated to each red, green, and blue
color. Special attention must be given to the timing of control signals to the LCD. Incorrect

R
timing on control signals could create image flicker, image scrolling, or partial image display.
The control signals for the Optrex LCD are shown in Table 3.
Table 3: Optrex LCD Control Signals

Optrex Signal CPLD VHDL
Purpose
Name Name
CLK lcd_clk Clock signal for capturing image data.
VSYNC lcd_vsync Vertical synchronous signal.
HSYNC lcd_hsync Horizontal synchronous signal.
DENB lcd_denb Data enable.
R (5:0) lcd_red (5:0) Red image data signal.
G (5:0) lcd_green (5:0) Green image data signal.
B (5:0) lcd_blue (5:0) Blue image data signal.
R/L lcd_r_l Horizontal image shift-direction select signal.
U/D lcd_u_d Vertical image shift-direction select signal.
The Optrex LCD TFT is compatible with four types of VGA timing. The various modes are VGA-
480, VGA-400, VGA-350, and freedom mode. The polarization of HSYNC and VSYNC
determine the VGA timing. In this reference design, the VGA-480 mode is utilized. Table 4
indicates the LCD mode based on polarization of VSYNC and HSYNC.
Table 4: LCD Mode Select

Polarization VGA-480 VGA-400 VGA-350 Freedom Mode
HSYNC Low Low High High
VSYNC Low High Low High
The sample clock, CLK, frequency for the Optrex LCD is typically 25 Mhz. In this CoolRunner-
II reference design, the LCD clock frequency is 6.6 MHz or 150 ns clock period. The timing
parameters shown below in Table 5 and Table 6 will vary based on LCD clock frequency. The
values shown correspond to a clock frequency of 6.6 MHz.
The horizontal (or HSYNC) and vertical (or VSYNC) timing for the LCD must be given special
consideration. If the timing parameters shown below are not met, the image will not display
correctly on the LCD. Effects such as image scrolling or partial image display will occur.
Horizontal Timing
Table 5 and Figure 15 illustrate the horizontal timing specifications for HSYNC. The back porch
and front porch times are with respect to the assertion of DENB. When DENB is asserted, data
is shifted into the LCD at each rising edge of the LCD CLK.
Table 5: Horizontal Timing

Indicator Description Parameter Clock Cycles Actual Value
A Horizontal Width tHPW 96 14 μs
B Horizontal Back Porch tHBP 48 7 μs
C Horizontal Display tHD 640 96 μs

R
Table 5: Horizontal Timing

Indicator Description Parameter Clock Cycles Actual Value
D Horizontal Front Porch tHFP 16 2.4 μs
E Horizontal Total tHP 800 120 μs
For clarification, each timing parameter in Table 5 is assigned a letter shown in Figure 15.
HSYNC
(active low)
DENB
A B C D
tHPW tHBP tHD tHFP

E
tHP
X390_15_090403
Figure 15: Horizontal Timing Diagram
Vertical Timing
Table 6 and Figure 16 below describe the vertical timing parameters for VSYNC. The VSYNC
back porch time is with respect to the rising edge of DENB for the first line of image data. The
VSYNC front porch parameter is with respect to the falling edge of DENB on the last line of
image data. Note the assertion time of DENB in Figure 16 is for shifting data on all lines to the
LCD.
Table 6: Vertical Timing

Indicator Description Parameter Lines Actual Value
A Vertical Width tVPW 2 240 μs
B Vertical Back Porch tVBP 33 3.96 ms
C Vertical Display tVD 480 57.6 ms
D Vertical Front Porch tVFP 10 1.2 ms
E Vertical Total tVP 525 63 ms
The letters in Table 6 correspond to each timing parameter shown in Figure 16.
VSYNC
(active low)
DENB
A B C D
tVPW tVBP tVD tVFP

E
tVP
X390_16_090403
Figure 16: Vertical Timing Diagram
Another critical timing parameter on the LCD is the phase difference between active edges of
VSYNC and HSYNC. This timing parameter is indicated as tVH and shown in Figure 17. The

R
minimum value of tVH is one clock cycle. The maximum value of tVH is (tHP - 1) clock cycles,
where tHP is the number of clock cycles to shift in an entire line of data.
VSYNC
(active low)
HSYNC
(active low)
tVH X390_17_090403
Figure 17: VSYNC & HSYNC Phase Difference Timing
LCD Control Logic

Figure 18 below illustrates the logic components necessary to use the CoolRunner-II CPLD to
interface to the Optrex LCD. The lcd_start flag is generated by the Main Control Logic of the
CPLD that released control of the memory to the LCD Control Logic. Once the LCD Control
Logic has read an image from memory and sent the image data to the LCD, the lcd_done flag
is asserted for the Main Control Logic.
The counters shown in Figure 18 are used for creating the timing specifications of the LCD
display. VBP_CNT is a 17-bit counter for calculating the vertical back porch specification.
HBP_CNT is a 6-bit counter that calculates the horizontal back porch specification. The vertical
and horizontal back porch counters are separate counters, because they must both increment
simultaneously. LINE_CNT is a 10-bit counter that keeps track of the number of lines for the
LCD display. CLK_CNT is a general purpose 17-bit counter that is used for calculating HSYNC
& VSYNC phase difference, HSYNC pulse width, VSYNC pulse width, HSYNC front porch,
VSYNC front porch, and the number of pixels per line.
lcd_done
mi_pixclk
sys_reset
lcd_start
lcd_clk
VBP_CNT CCT
(UPCNT17) lcd_vsync
LCD Interface lcd_hsync
State Machine
CLK_CNT lcd_denb Optrex 51382
(UPCNT17) lcd_red (5:0)
led_green (5:0)
LINE_CNT lcd_blue (5:0) CCT
PWM
(UPCNT10) Control Logic
Period Width pwm_out
HBP_CNT K2607 Inverter
Counter Counter
(UPCNT6)
X390_18_090403
Figure 18: LCD Interface Block Diagram

R
The LCD state machine logic is shown below in Figure 19. The LCD state machine generates
all the control signals to the Optrex LCD.
lcd_start = '0'
IDLE
lcd_start = '1'
clk_cnt_qout < T_VPW

VSYNC_HIGH
clk_cnt_qout = T_VPW
VSYNC_LOW_EDGE
clk_cnt_qout < T_VH

VSYNC_LOW
clk_cnt_qout = T_VH
HSYNC_LOW_EDGE
vbp_cnt_qout < T_VBP or

HSYNC_LOW hbp_cnt_qout < T_HBP
vbp_cnt_qout = T_VBP &

hbp_cnt_qout = T_HBP
hbp_cnt_qout = T_HBP clk_cnt_qout < NUM_COL
ASSERT_DENB
clk_cnt_qout = NUM_COL
WAIT_THBP
hbp_cnt_qout < T_HBP LINE_DONE
clk_cnt_qout = T_HPW
HSYNC_PW HFP_WAIT clk_cnt_qout < T_HFP

clk_cnt_qout < T_HPW
clk_cnt_qout = T_HFP
HSYNC_HIGH
line_cnt_qout < NUM_LINES
line_cnt_qout = NUM_LINES
clk_cnt_qout < T_VFP

VFP_WAIT
clk_cnt_qout = T_VFP
DONE
X390_19_090403
Figure 19: LCD Interface State Machine
A description of each state in the LCD state machine is provided in Table 7.
Table 7: LCD State Machine Description

State Name State Purpose
IDLE Wait for the assertion of lcd_start.
VSYNC_HIGH De-assert lcd_vsync. Wait for tVPW (VSYNC pulse width).
Use CLK_CNT and wait for T_VPW. Also reset
ADDR_CNT (SRAM address counter).

R
Table 7: LCD State Machine Description

State Name State Purpose
VSYNC_LOW_EDGE Assert lcd_vsync. Enable VBP_CNT (VSYNC back porch
counter).
VSYNC_LOW Wait for tVH (VSYNC to HSYNC phase difference). See
Figure 17. Use CLK_CNT and wait for T_VH.
HSYNC_LOW_EDGE Assert lcd_hsync. Enable HBP_CNT (HSYNC back porch
counter).
HSYNC_LOW Wait for both VBP_CNT and HBP_CNT (VSYNC and
HSYNC back porch counters) to reach T_VBP and
T_HBP, respectively. Meet both tVBP and tHBP
requirements.
ASSERT_DENB Assert lcd_denb. Send data to LCD. Assign lcd_red,
lcd_green, and lcd_blue signals. Enable CLK_CNT and
wait for number of data pixels per row. Wait for CLK_CNT
to reach NUM_COL.
LINE_DONE This state is reached when all the pixel data has been
shifted to LCD for the current line. Increment LINE_CNT
(line counter).
HFP_WAIT Wait for HSYNC front porch (tHFP). Use CLK_CNT and
wait until T_HFP is reached.
HSYNC_HIGH De-assert lcd_hsync. Compare LINE_CNT to
NUM_LINES. If max number of lines for LCD is reached
proceed to VFP_WAIT state, else repeat sending line
data to LCD.
HSYNC_PW Wait for tHPW (HSYNC pulse width). Use CLK_CNT and
wait for T_HPW.
WAIT_THBP Assert lcd_hsync. Wait for tHBP (HSYNC back porch). Use
HBP_CNT and wait for T_HBP.
VFP_WAIT Wait tVFP (VSYNC front porch). Use CLK_CNT and wait
for T_VFP.
DONE De-assert lcd_vsync. Assert lcd_done flag.
PWM Logic
The PWM Logic of the CPLD is responsible for generating a pulse width modulated (or PWM)
signal. The PWM signal controls the brightness of the LCD as an input to a DC to AC inverter.
The PWM signal is an input to the ERG K2607 low profile DC to AC inverter that is designed
specifically for the Optrex T51382 LCD. The overall period of the PWM signal should be
approximately 5 ms, while the width (or active high time) can vary from 5% to 100% of the
signal period. The K2607 inverter powers the dual cold cathode tubes (or CCT) of the Optrex
LCD.
The PWM Logic in the CPLD mainly consists of two counters, a PERIOD counter and a WIDTH
counter. The PERIOD counter counts the full cycle length of the PWM signal, while the WIDTH

R
CoolRunner-II Implementation
counter controls the active high time of the PWM signal. Figure 20 illustrates the PWM signal
generation.
+ Vin
PWM
signal
0V
WIDTH
counter
PERIOD counter
(app. 5 ms) X390_20_090403
Figure 20: PWM Signal Generation
CoolRunner-II Device Utilization

Implementation The current digital camera reference design is targeted to a CoolRunner-II XC2C256 TQ144
device. Table 8 below describes the utilization numbers for the digital camera reference design.
Table 8: CoolRunner-II Design Utilization

Parameter Used Available % Utilization
I/O Pins 76 118 64 %
Macrocells 235 256 92 %
Product Terms 633 896 71 %
Registers 217 256 85 %
Function Block Inputs 501 640 78 %
Verification
The digital camera design functionality has been verified in functional simulation, post route
timing simulation, and in hardware implementation. Test benches are provided in the VHDL
code download pack.
VHDL Code THIRD PARTIES MAY HAVE PATENTS ON THE CODE PROVIDED. BY PROVIDING THIS
Conclusion CoolRunner-II CPLDs are low power devices targeted to portable, handheld electronics such
as digital cameras. This reference design illustrates the complexity of logic that can be fit into a
CPLD. This digital camera solution using CoolRunner-II CPLD to provide seamless integration
between an image sensor, memory, and a LCD.

R
References
References • Micron Technology, Inc. http://www.micron.com

• Video Demystified 3rd Edition. Keith Jack. 2001. Elsevier Science.
• Optrex of America, Inc. http://www.optrex.com
Glossary AE - Auto Exposure

AWB - Auto White Balance
Back Porch - The portion of a video signal that occurs during blanking from the end of
horizontal sync to the beginning of active video. The blanking signal portion which lies between
the trailing edge of a horizontal sync pulse and the trailing edge of the corresponding blanking
pulse. Color burst is located on the back porch
CCD - (Charge Coupled Device) An image sensor that reads the charges from the sensor's
photosites one row at a time.
CCT- Cold Cathode Tube
CFA - (Color Filter Array) The filter dyes placed directly over each pixel on the chip surface.
CIF - (Common Interchange Format) 352x288 pixels; often used for H.261 and H.263 video
codecs.
Color Correction - The process of correcting or enhancing the color of an image.
CMOS - (Complementary Metal Oxide Semiconductor) An imaging system used by digital
cameras.
Digital Zoom - A digital magnification of the center 50% of an image. Digital zooms increase
the apparent image size by interpolation. They do not increase the amount of image
information.
Frame - One of the still pictures that make up a video.
Frame Grabber - A device that lets you capture individual frames out of a video camera or off
a video tape.
Frame Rate - The number of frames that are shown or sent each second. Live action relates to
a frame rate of 30 frames per second.
Front Porch - The blanking signal portion which lies between the end of the active picture
information and the leading edge of horizontal sync.
Gamma - The light output of a CRT is not linear with respect to the voltage input. This non-
linearity follows an exponential function that is known as gamma. The camera has the inverse
gamma of the CRT so that the resulting stage light input to CRT light output transfer will be
somewhat linear, given the restrictions of the video system.
IC - Integrated circuit.
IFP - Image flow processor.
Image Sensor - A solid-state device containing a photosite for each pixel in the image. Each
photosite records the brightness of the light that strikes it during an exposure.
LCD - (Liquid Crystal Display) Two types: (1) a high-resolution color display device used in
handheld televisions and digital photography viewfinders. (2) A monochrome information
display using black alphanumeric characters on a gray/green background.
Photosite - A small area on the surface of an image sensor that captures the brightness for a
single pixel in the image. There is one photosite for every pixel in the image.
Pixel - An individual element of either a CCD sensor or a digital image.

R
Additional Information
Resolution - Expressed as the number of pixels counted horizontally by the number of pixels
counted vertically. It can be expressed as one of the following formats: QVGA (320 x 240), VGA
(640 x 480), SVGA (800 x 600), XGA (1024 x 768) UXGA (1600 x 1200).
RGB - (Red, Green and Blue) The color system used in most digital cameras in which the
image is separated by capturing the red, green, and blue light separately and then are re-
combined to create a full color image.
Saturation - The degree to which a color is undiluted by white light. If a color is 100 percent
saturated, it contains no white light. If a color has no saturation, it is a shade of gray.
TFT - (Thin Film Transistor) The type of hi-resolution color LCD screen used in many digital
photography cameras.
VGA - An image resolution of 640 x 480 pixels.
Y,U,V - PAL luminance & color difference components. U and V are the names of the B-Y and
R-Y color differences signals (respectively) when they are modulated onto subcarrier.
YPbPr - YPbPr represents component video connections, where luminance (Y) is represented
by a green jack, separate from the color components blue (Pb) and red (Pr). Most high-
definition sets today support this format. These colors should not be confused as RGB output.
Additional CoolRunner-II Datasheets and Application Notes

Information Device Packages
History
09/27/05 1.1 Fixed links in Additional Information

R
CompactFlash Card Interface for
CoolRunner-II CPLDs
Summary This application note describes the card-side implementation of an 16-bit CompactFlash (CF+)
card interface using a CoolRunner™-II CPLD. Included in this implementation are the CIS,
Attribute Memory Control and Status Registers, 16-bit Common Memory, and 8-bit I/O
Interface. This design can be easily modified to interface to any memory, DSP or
microcontroller. This application note does not describe the Host Bus Adapter (HBA) side of the
CompactFlash interface, which is resident on a host system such as a Personal Computer or
PDA.
Introduction There are two types of CompactFlash devices: CompactFlash Storage Cards (CF), and CF+
Cards. CF consists only of common memory data storage whereas CF+ is expanded to include
I/O devices or magnetic disk data storage, depending on the specific application. This
application note targets the CF+ type of device. There are three basic modes of operation
called for in the CF specification. Typically, CF+ devices operate in two of the three basic
modes: PC Card ATA using I/O Mode, and PC Card ATA using Memory Mode. The third,
optional mode is True IDE Mode. CF cards are required to operate in all three modes. This
application note implements the CF+ card side interface utilizing PC Card ATA using I/O Mode
and PC Card ATA using Memory Mode. True IDE Mode is not addressed in this application
note, but can be implemented by the designer using the CoolRunner-II CPLD and this
reference design.
The CompactFlash interface consists of two main components: the Host Bus Adapter (HBA)
and the card side interface. The former resides on the host side of the interface, which typically
is built into the socket of a personal computer or Personal Digital Assistant (PDA). The card side
interface resides on the CF card itself. Described in this application note is the implementation
of a controller which resides in the card side of the interface.
Within the card, there is Attribute Memory, Common Memory, and I/O Interface. Attribute
memory consists of the Card Information Structure (CIS) and the Configuration and Control
Registers. Common Memory, in this reference design, interfaces to the Intel StrataFlash
28F320J3 memory. The I/O logic interfaces to the Analog Devices, Inc. ADSP-218xN Series
DSP using the 8 bit I/O Space of the DSP.
In this implementation, the CF+ interface is a 16-bit data bus. The I/O interface within the card
consists of an 8-bit bus to the DSP.
It is necessary to refer to the CompactFlash Specification and the PCMCIA Specification to fully
understand the discussion in this application note.
A free downloadable zip file containing the VHDL source code and a testbench for this
reference design is available as described below in Source Code Download, page 147.
Electrical Power Considerations

Interface CoolRunner-II CPLDs are 1.8V core voltage devices with I/O banking features that allow for
various I/O voltages and tolerances up to 3.3V. The CF+ specification calls for either 3.3V or

1-800-255-7778
R
5.0V operation. The core power supply to the CPLD, therefore, must be regulated on the CF+
card to 1.8V while the I/Os must be configured to operate at 3.3V as described in the following
section. For the specific application, if 1.8V regulation is not available or the I/Os will be
subjected to 5.0V, consider using the CoolRunner XPLA3 CPLD, which is a 5V tolerant 3.3V
device and therefore will not require the additional power regulation. I/O considerations for the
CoolRunner-II CPLD are discussed in the following section.
To indicate to the host that the CF+ card is expecting 3.3V signaling, -VS1 must be held at
GND. The signal -VS2 is reserved by PCMCIA for a secondary voltage and therefore must be
left open. These two signals are not implemented in this application note and therefore must be
electrically considered external to the CPLD on the PCB by the designer.
CF+ devices that are configured for 3.3V operation are limited to 75mA max (Power Level 0) or
500mA max. (Power Level 1). Further, during power up and after reset, the CF+ card is limited
to Power Level 0. To assist the designer with more efficiently utilizing the CF+ power budget,
CoolRunner-II CPLDs are the perfect choice since these devices exhibit very low static and
dynamic current consumption.
I/O Considerations
Inputs
The CompactFlash specification calls for three basic types of input configurations in the Pin
Assignments and Pin Type description: IxZ, IxU and IxD. "I" represents the pin is an input, "Z"
represents an input with no resistive termination, "U" represents a weak pullup termination, and
"D" represents a weak pulldown termination. These three configurations are also specified with
one of three electrical characteristics which is denoted by a number 1, 2 or 3 in the "x" position
of the designation. The three numbers correspond to various input threshold levels for the type
of input required. Details of these values and configurations can be found in the CompactFlash
specification.
Outputs
Similarly, the CF+ specification calls for three basic types of output configurations: OTx, OZx,
OPx, and ONx. "O" designates the signal to be an output, "T" represents a totem pole type
output, "Z" a CMOS P-channel/N-channel output with 3-state capabilities, "P" a PMOS only
output, and "N" an NMOS only output. These also have three electrical characteristics denoted
by 1, 2, or 3 in the "x" position of the designation. These three values represent VOH and VOL
levels under certain test conditions. All output types also have a 3-state characteristic and,
together with the voltage levels, are described in the CompactFlash Specification.
Implementation
The CF specification calls for 3.3V or 5.0V for the card power supply and I/O signals.
CoolRunner-II devices are 1.8V devices, but have I/O banking capabilities. To implement the
CF+ interface, the CoolRunner-II CPLD I/Os should be configured as 3.3V LVCMOS.
CoolRunner-II CPLDs are not 5V tolerant. However, external circuitry can be used to interface
to 5V systems. See XAPP364. Alternately, CoolRunner XPLA3 CPLDs are 3.3V devices with
5.0V tolerance. If these voltage requirements are an issue for the application, the CF+
implementation can target the CoolRunner XPLA3 CPLD. Since the CF+ card tells the HBA
what voltage it expects, 5.0V is not present on the I/O pins until the HBA determines the
required voltage. CoolRunner-II CPLDs are therefore acceptable for CF+ applications since
5.0V will never be applied to its I/Os, as long as -VS1 and -VS2 are configured correctly.
Since this application note describes the implementation of the two modes PC Card ATA using
I/O Mode and Memory Mode, the I/Os are required to be configured as I1Z, I2Z, I1U, I3U, OZ3,
OT1, and OT3. The CoolRunner-II CPLD can be configured to support all I/O modes with the
following caveats.
I/O configuration I2Z requires that VIH be at a lower voltage than the CoolRunner-II CPLD is
specified in the data sheet. The signal of interest is RESET whose VIH should be analyzed for
the particular application of this CF+ design. If it is determined that the supplied signal is always

1-800-255-7778
R
high enough to meet the VIH value of CoolRunner-II devices, then this CPLD should be
sufficient. If not, an external buffer with these characteristics must be supplied to satisfy the
system requirements.
I/O configurations OT1 and OT3 require a totem pole type of driver. CoolRunner CPLDs only
provide CMOS type output buffers and therefore cannot explicitly meet these requirements.
Therefore, an external buffer of totem pole type should be implemented to satisfy the CF+
specification. However, CoolRunner-II CPLDs can meet the I/O drive requirements of VOH and
VOL at the specified IOH and IOL test conditions respectively, regardless of CMOS or totem pole
type configuration. Analysis of the particular application is necessary to determine if
CoolRunner-II CPLD I/Os can be used without the use of external totem pole buffers.
Fixed Level and Unused I/Os

Nomenclature of all signals in the VHDL source code matches that of the CF+ specification for
PC Card I/O Mode.
The signals -CD1 and -CD2 are card detect pins which indicate to the host that the card is fully
inserted when it detects both signals are low. This application note does not implement these
signals within the CPLD, but instead relies on the system designer to hold these two signals at
GND external to the CPLD.
The signal -CSEL is not used by this application as described by the CF+ specification.
-SPKR, binary audio, is not used in this reference design, but can be added if required.
-VS1 and -VS2, voltage sense signals, are also not used in this implementation, but must be
hardwired on the PCB so the host system can correctly determine the card’s required voltage
levels. For this reference design, it is assumed that -VS1 is held LOW while -VS2 is left floating.
These two signals are held HIGH by the host system, thereby allowing -VS2 to be read as a
logic HIGH when the card leaves it in a floating state.
Block Diagram CF+ Card

Figure 1 shows a block diagram of the CF+ card where the major components are the
CoolRunner-II CPLD, Intel StrataFlash and the Analog Devices DSP.
The CoolRunner-II CPLD implements the direct interface to the CF+ slot, an interface to the
Common Memory space and an interface to the I/O Space. Control logic is included to
synchronize data between the three interfaces. The Attribute memory as a whole is realized in
the CPLD which includes control and status registers as well as the CIS. External ROM is not
needed for the CIS since it has been compactly implemented in the CPLD as a lookup table
constructed of product terms.
The Intel StrataFlash is used for the Common Memory space and is limited to 2 kB due to the
11 available address lines of the CF+ interface. To access further memory space, the CF+ card
must be configured to utilize the I/O Space or redesigned to implement the True IDE mode. The
Common Memory space is configured with a 16-bit data bus.
The I/O Space, for this implementation, consists of an Analog Devices DSP. In Figure 1, there
is a reference to Additional Functions. This is included for illustrative purposes and can be any
function, such as a GPS device. An 8-bit data bus is used to interface to the DSP.

1-800-255-7778
R
Control Bus CM Control Bus
CM A10:A0 Common
Memory
(Intel StrataFlash)
Host Bus Adapter (HBA)
A10:A0 CM D15:D0
Expansion Bus CoolRunner-II

CPLD
I/O Control Bus
D15:D8 CF+Interface
DSP Control Bus
I/O A10:A0
I/O Space DSP A10:A0 Additional
I/O D7:D0 (Analog Devices
Functions
D7:D0 DSP)
DSP D7:D0
80MHz clock
40MHz
Clock
Compact Flash Card
X398_01_092203
Figure 1: CompactFlash Card General Block Diagram
CPLD Implementation
Figure 2 represents an overview of the CF+ controller reference design contained in the CPLD
(as described in this application note). There are two controllers for the three interfaces: CF+
Address Decode and Control Logic (CF+ Card Controller), and I/O Space Address Decode and
I/O Control Logic (I/O Space Controller).
The former controls transactions with the CompactFlash interface and directs data to the
correct locations—more specifically, the Attribute Memory, Common Memory, and the I/O
Space Controller. It also provides the necessary status and control signals required by the HBA
to effectively communicate with the card.
The I/O Space controller interfaces the CF+ card controller with the devices connected to the
I/O Space bus, which is in this case the DSP. To interface more effectively and synchronously
with the DSP, there are three I/O register banks: Address Register, Data Register, and Status
Register.
As mentioned earlier, the Attribute memory is included in the CPLD reference design. The
Attribute Memory, in this case includes the CIS, COR, CSR and PRR, whose functionality is
described later in this document.

1-800-255-7778
R
80MHz Clock
Attribute Memory I/O Space

Control Register
0x204
PRR 0x402 0x003
Data Register
0x202
CSR 0x401 0x002
COR Address Register

0x200 0x400 0x001
Address Bus
Control Bus
Data Bus
Control Bus
CIS
0x000
CF+ Interface
CF+ I/O D7:D0

A10:A0 Address Decode
I/O Interface
and I/O Space
Control Logic Address Decode I/O A10:A0
(CF+ Controller) and
I/O Control Logic
D15:D8 (I/O Space Controller) I/O Control Bus
D7:D0
Address Bus 10:0 CM A10:A0
Common Memory
Memory Data Bus 15:0 CM D15:D0
I/O Space Data Bus 7:0
Control Bus CM Control Bus
CPLD
X398_02_042403
Figure 2: CPLD Controller General Block Diagram
Signal Table 1 displays the pin descriptions of the CoolRunner-II CF+ Interface. Note that according to
Descriptions the CompactFlash specification, some pin names change depending on the card configuration
mode. For these signals, the I/O Mode nomenclature is used in the table, throughout this
document, and in the VHDL source code.
Table 2 describes the pins of the Common Memory Interface to the Intel StrataFlash device.
Similarly, Table 3 indicates pin names and their functions for the I/O Space Interface to the
Analog Devices DSP.

1-800-255-7778
R
No pin assignments have been forced, leaving it up to the user to custom fit the design per their
requirements.
Table 1: CF+ Interface Pin Descriptions

host_addr(10:0) Input A10:A0 in the Compact Flash Specification which
are address lines from the HBA.
ce1_n Input Active LOW card select signal. Together with
ce2_n and host_addr(0), selects between 16/8-bit
data transfers and odd/even byte transfers. See
Table 4 for details.
ce2_n Input Active LOW card select signal. When ce1_n is
LOW, selects the odd or even byte of the data word
depending on host_addr(0). See Table 4 for
details.
iord_n Input Used in I/O Mode, this is an active LOW I/O read
strobe from the host. Data is placed on the CF+
bus by the CF+ card.
iowr_n Input Also used in I/O Mode, this signal clocks data into
the CF+ card when the host has placed valid data
on the data bus of the CF+ interface. iowr_n is
active LOW.
oe_n Input In Memory mode, this signal is used as a strobe by
the host to read data from Common Memory or
Attribute Memory including the CIS. In I/O Mode,
this signal is used to read data from the Attribute
Memory and CIS. oe_n is active LOW.
reg_n Input Active LOW signal that distinguishes between
Common Memory (HIGH) and Attribute Memory
(LOW). When in I/O Mode, this signal must be
LOW to access I/O Space.
reset Input This is an active HIGH signal to initialize and reset
all registers in the CF+ card.
we_n Input Active LOW signal to strobe data into the Attribute
memory and the Common Memory.
stschg_n Output If enabled in the CSR, this active LOW pin
indicates the status of the rdy/-bsy pin. When in I/O
Mode, rdy/-bsy is renamed to ireq_n and its
functionality no longer reflects the ready/busy
condition. For the host to see ready/busy
conditions, stschg_n is available. When in Memory
Mode, stschg_n is always HIGH.
inpack_n Output When configured in I/O Mode, the CF+ card uses
this active LOW signal to indicate the card is
responding to an I/O Space read cycle at the
address present on the host_addr bus.

1-800-255-7778
R
Table 1: CF+ Interface Pin Descriptions (Continued)

ireq_n Output ireq_n is active LOW.
In Memory Mode, this signal indicates a
ready/busy state (rdy/-bsy) where a LOW signal
indicates a busy state. The CompactFlash
specification requires this signal to be LOW during
power up. During power up/configuration, the
CoolRunner-II 3-states the I/Os with weak pullup,
making it impossible to meet this requirement.
However, the specification requires the HBA not
access the card until >1ms after power has
stabilized after which the HBA must assert the
reset signal for 10μs. Since configuration times for
CoolRunner-II CPLDs is much less than 1ms, this
allows the card to have a HIGH rdy/-bsy signal
during power up without adverse effects.
The rdy/-bsy signal in Memory Mode is LOW
during a reset, either a reset directed by the reset
pin or a soft reset when the SRESET bit has been
written in the COR. This signal also reflects the
status of the Common Memory pin, cm_sts.
During I/O Mode, this pin takes on the ireq_n
functionality and masks the rdy/-bsy functionality.
This active LOW signal now indicates that data is
ready to be read from the I/O Space (DSP)
Address or Data registers.
To obtain the status of rdy/-bsy, the PRR bit 1 must
be read. A change in status of this bit is reflected
on the stschg_n pin, if enabled.

1-800-255-7778
R
Table 1: CF+ Interface Pin Descriptions (Continued)

wait_n Output As an active LOW signal, wait_n tells the HBA to
extend the current memory or I/O cycle. This
signal has been implemented such that the I/O
Space and Common Memory have control over
this signal.
The dsp_ioms_n signal is sampled when
accessing the I/O Space and indicates the DSP is
reading or writing to the I/O Space. As
implemented with the Analog Devices DSP, the
signal ioms_n is used to drive dsp_ioms_n. Since
the DSP has configured with three wait states, this
assists the HBA to wait the appropriate length of
time during an I/O Space access.
The Common Memory uses cm_wait to drive
wait_n during this type of memory access.
However, as implemented with the Intel
StrataFlash, this memory has no wait signal and
therefore cm_wait must be driven HIGH external to
the CPLD or removed from the source code.
host_data_low(7:0) Bidirectional D7:D0 in the CompactFlash specification. These
are the lower data signals to/from the HBA. This
corresponds to the even byte described in the
CompactFlash specification.
host_data_high(7:0) Bidirectional D15:D8 in the CompactFlash specification. These
are the upper data signals to/from the HBA.This
corresponds to the odd byte described in the

1-800-255-7778
R
Table 2: Common Memory Interface Pin Descriptions

cm_sts Input Effectively a ready/busy signal for the Intel
StrataFlash. This implementation assumes the
memory is configured with level mode sts
signalling and therefore supplies the CF+ rdy/-bsy
logic (named ireq_n) a busy state (LOW) when the
memory is busy performing a lengthy operation.
cm_sts is active LOW.
cm_wait Input Available for Common Memory wait type status
inputs. As the Intel StrataFlash memory used in
this implementation does not contain a wait signal,
cm_wait is unused and driven high in the test
bench. The user must either permanently drive
this signal HIGH or remove it from the source code
so as to allow proper functionality of wait_n.
cm_wait is active LOW.
cm_byte_n Output Active LOW, cm_byte_n selects the 8-bit or 16-bit
data bus access modes of the Intel StrataFlash as
requested by the HBA. When in 8-bit mode,
cm_addr(0) selects the high or low byte of the
addressed memory location. When in 16-bit mode,
cm_addr(0) is ignored and cm_addr(1) becomes
the LSB of the Common Memory address bus.
cm_addr(0) Output Byte-select address for the Intel StrataFlash. This
signal selects the high or low byte of the
addressed memory location. A high byte from
Common Memory corresponds to an odd byte with
respect to the CF+ interface. Similarly, a low byte
from Common Memory corresponds to an even
byte on the CF+ interface. High bytes are
accessed when cm_addr(0) is HIGH and low bytes
are accessed when cm_addr(0) is LOW.
cm_addr(10:1) Output Address bus for the Common Memory.
cm_reset Output Active LOW reset for the Common Memory
cm_read_n Bidirectional Active LOW output enable signal to read data from
the Common Memory.
cm_data(15:0) Bidirectional Data bus for the Common Memory.
cm_ce_n Bidirectional Active LOW chip enable signal for the Common
Memory.
cm_write_n Bidirectional Active LOW write enable signal for the Common
Memory.

1-800-255-7778
R
Table 3: I/O Space Interface Pin Descriptions

dsp_clk Input This clock input to the CPLD must be 80MHz
dsp_addr(10:0) Input 11-bit address bus from the DSP. Most of these
pins can be removed from the design to obtain
more I/Os as needed. This implementation only
utilizes the two LSBs since there are only three
registers accessed by the DSP.
dsp_ioms_n Input I/O memory select from the DSP. This active LOW
signal enables the I/O Space from the DSP side of
the CF+ interface. The CF+ interface signal wait_n
samples this signal, and when low, indicates the
DSP is either reading or writing to the I/O Space
interface.
dsp_rd_n Input Active low-read strobe from the DSP which
accesses data contained in the I/O Space
registers.
dsp_wr_n Input Active low-write strobe from the DSP which
accesses data contained in the I/O Space
registers.
dsp_data(7:0) Bidirectional 8-bit bidirectional data bus from the DSP.
CF+ Controller All primary control functions for the CF+ interface are contained in the CF+ controller
(cf_plus_control.vhd). The following subsections describe the CF+ controller’s functionality.
Addressing Modes
This CF+ interface consists of a 16-bit data bus, which may or may not be used to its fullest
capabilities, depending on the architecture of the HBA and the host system. Some host
systems can only support 8-bit transfers which therefore requires the HBA to request 8-bit data
bytes from the CF+ card. It is the card controller’s responsibility to provide 8 bits of data to the
HBA. In the case of the 8-bit host, it is the HBAs responsibility to request the upper or lower byte
of a 16-bit data word from the CF card using specific control signals and then sending that data
to the host over the 8-bit data bus in the correct order.
The CF+ implementation in the CPLD reads the control signals (host_addr(0), ce1_n and
ce2_n) from the interface and interprets them in the correct order for providing data over the 8-
bit or 16-bit data bus as required by the HBA. Table 4 describes in detail this interpretation,
which is compliant to the CompactFlash specification. This table references Odd and Even
bytes as described in the CompactFlash specification. The Intel StrataFlash maintains a
nomenclature of High and Low bytes. Table 4 conveniently shows the correlation between
Odd/Even and High/Low nomenclatures.

1-800-255-7778
R
Currently, I/O Space access is limited to 8-bit in this implementation. If-16 bit I/O Space access
is required, comments have been added throughout the source code to assist the user to this
end. However, 16-bit I/O Space access has not been tested.
Table 4: Addressing Even and Odd Bytes from CF+ Interface

Addressing Mode ce1_n ce2_n host_addr(0) host_data_high host_data_low
No access 1 1 X 3-State 3-State
8/16-bit Mode 0 1 0 3-State Even Byte
(even byte) (Low Byte)
8-bit Mode 0 1 1 3-State Odd Byte
(odd byte) (High Byte)
16-bit Mode 1 0 X Odd Byte High-Z
(odd byte only) (High Byte)
16-bit Mode 0 0 X Odd Byte Even Byte
(even & odd bytes) (High Byte) (Low Byte)
Memory and I/O Space Access

The HBA gains access to the different memory spaces via a few control pins. The signal reg_n
allows the HBA to write or read from Common Memory when this signal is HIGH. Note that
when reg_n is LOW, the HBA has access to either the Attribute Memory or the I/O Space,
dictated by the state of iord_n, iowr_n and, of course, the address.
When reg_n is LOW, the HBA can perform read and write operations on the I/O Space
registers. To perform a read, iord_n is held LOW. Similarly, holding iowr_n LOW will access the
I/O space registers in a write mode.
All memory spaces (Attribute Memory, Common Memory and I/O Space) are read and write
capable. There are two exceptions: The CIS is read-only, and the I/O Space Status Register,
which is read-only as well.
Interrupt Request and Ready/Busy

A CF+ card can be configured for several modes of operation, as mentioned earlier. Two of
these modes are supported in this implementation: Memory Mode and I/O Mode. Each mode
has unique I/O signal descriptions as described in the CompactFlash specification. In other
words, when the card is configured in Memory Mode, the I/Os are defined to have a specific set
of I/O functions and names. But when the card has been reconfigured for I/O Mode, some of
these pins take on a new name and functionality. Of interest is the rdy/–-bsy pin named ireq_n
in this implementation. The CompactFlash specification names this pin rdy/–bsy for Memory
Mode and changes it to –ireq in I/O Mode. See Table 1, page 134.
In Memory Mode, this signal indicates a ready/busy state (rdy/-bsy) where a LOW signal
indicates a busy state. The CompactFlash specification requires this signal to be LOW during
power up. During power up/configuration, the CoolRunner-II 3-states the I/Os with weak pullup,
making it impossible to meet this requirement. However, the specification requires the HBA not
access the card until >1ms after power has stabilized, after which the HBA must assert the reset
signal for 10μs. Since the configuration time for CoolRunner-II CPLDs is much less than 1ms,
this allows the card to have a HIGH rdy/-bsy signal during power up without adverse effects.
The rdy/–bsy signal in Memory Mode is LOW during a reset, either a reset directed by the reset
pin or a soft reset when the SRESET bit has been written in the COR. This signal also reflects
the status of the Common Memory pin, cm_sts. The Intel StrataFlash provides a signal named
STS which, in level mode, acts as a ready/busy signal. This CF+ implementation uses this STS
signal to reflect the ready/’busy status of the Common Memory when it is being accessed.

1-800-255-7778
R
During I/O Mode, this pin takes on the ireq_n functionality and masks the rdy/–bsy functionality.
This active LOW signal now indicates that data is ready to be read from the I/O Space (DSP)
Address or Data registers. When new data is placed in the Address or Data registers by the
DSP, ireq_n goes LOW. Once data has been read from these registers by the HBA, ireq_n
returns to its inactive HIGH state.
Since rdy/–bsy status is masked during I/O Mode, the PRR bit 1 must be read to determine the
status of the Common Memory. A change in status of this PRR bit is reflected on the stschg_n
pin, if enabled.
Attribute The Attribute Memory is divided into two basic sections: The CIS and the Configuration
Memory Registers. There are at least six optional Configuration Registers, but this implementation
integrates three of these registers. The CIS may be found in the reference design source file
named cis.vhd. The Attribute Memory may be found in attribute_memory.vhd, but some
associated control signals for this memory space are found in cf_plus_control.vhd.
Addressing Attribute Memory

The CIS is found at memory location 000h per the CompactFlash specification and is read-only.
The CompactFlash specification states that for CompactFlash and other cards with data
storage, the configuration registers must reside at a base offset (BASE) of 200h. Conversely,
non-data storage cards BASE can be located anywhere and is found by parsing the CIS tuples.
This implementation, since data storage is used, sets BASE to 200h. Table 5 describes the
addressing scheme of the Attribute Memory.
Table 5: Attribute Memory Registers

Address Register Description
000h CIS Card Information Structure
BASE + 00h COR Configuration Option Register
BASE + 02h CSR Card Configuration and Status Register
BASE + 04h PRR Pin Replacement Register
Card Information Structure

The Card Information Structure (CIS) is maintained in the Attribute Memory as a read-only
memory space and is intended as nonvolatile memory. In this CoolRunner-II implementation,
the CIS is built using product terms and therefore retains its nonvolatile properties without using
external memory.
This data structure is comprised of tuples which tell the software driver of the host system what
characteristics the CF+ card contains, such as size, speed and resources required. The host
then configures the card and the HBA to efficiently take advantage of the card’s features. The
structure of the tuples and the definitions of the values within the tuples is not described here.
It is up to the user to investigate this information as found in the CompactFlash specification
and the PCMCIA specification.
Included in this implementation is an example CIS which must be modified to the user’s
application. To modify the CIS, edit the source file cis.vhd.
Configuration Option Register

The Configuration Option Register (COR) is one of the registers included in the Attribute
Memory and is used to configure the card. Configuration options include soft reset, interrupt
types and address decoding.

1-800-255-7778
R
The COR is comprised of 8 bits as shown in Table 6.
Table 6: Configuration Option Register

Operation D7 D6 D5 D4 D3 D2 D1 D0
R/W SRESET LevelReq Conf5 Conf4 Conf3 Conf2 Conf1 Conf0
SRESET - Soft Reset

When this bit is written by the HBA, a soft reset of the card will occur. To obtain this functionality,
the HBA must write a HIGH then a LOW where the reset is performed during the HIGH cycle.
A soft reset differs from a hard reset in that this bit is not cleared by a soft reset. Otherwise, both
types of reset have the same functionality. All registers and state machines in the card will be
reset to zero upon hard or soft reset, including registers in the I/O space. A reset condition is
also presented to the Common Memory. This bit is initially set LOW by a hardware reset
condition when driven by the reset pin.
LevelReq
ireq_n can be set to indicate interrupts on a level or pulse mode basis. Setting this bit HIGH
enables level mode interrupts, whereas setting this bit LOW enables pulse mode interrupts.
Pulse mode is set to 0.5μs per the CompactFlash specification and uses a 6-bit binary up
counter (upcnt6.vhd) to implement the pulse width. This bit is set to zero by reset.
Conf
These 6 bits select the operation mode of the card. The specification states that for
CompactFlash Cards these bits are used for Memory Mapping or I/O Mapping, depending on
the application. But since this implementation is of a CF+ card, the specification states that
these bits specify either Memory Mapping where I/O cycles are ignored (all bits zero), or the
bits are user-defined. The specification also states that multiple function CF+ cards bits 0
through 2 have specific functionality and bits 3 through 5 are reserved for user implementation.
This CF+ implementation handles the Conf bit functionality where an all zeros condition
disables the I/O space and effectively allows for memory mapping only. Also, since single
function CF+ cards use these bits optionally, and since this implementation is of a single
function CF+ card, these bits are not required. However, they have been included for
convenience. All Conf bits are set to zero when a reset condition occurs.
Conf0 enables the I/O space when set HIGH, and disables the I/O function if LOW.
Conf1 is used for Base and Limit Registers, but since these registers are not used in this
implementation, Conf1 is non-functional.
Conf2 enables ireq_n routing. Its functionality depends on the state of Conf0. If Conf0 is HIGH
and Conf2 is HIGH, interrupts from the I/O Space are routed to the ireq_n pin. If Conf0 is HIGH
and Conf2 is LOW, interrupts are disabled. If Conf0 is LOW, Conf2 is undefined.
Conf3 through Conf5 are reserved for user implementation.
Card Configuration and Status Register

Another register in the Attribute Memory, the Card Configuration and Status Register (CSR)
contains information regarding the card’s condition.
The CSR is comprised of 8 bits as described in Table 7.
Table 7: Card Configuration and Status Register

Read Changed SigChg IOis8 XE_n Audio PwrDwn Int 0
Write 0 SigChg IOis8 XE_n Audio PwrDwn 0 0

1-800-255-7778
R
Changed
This bit reflects the status of CRdy_Bsy_n and CWProt in the PRR. Note that the functionality
of CWProt is not implemented since WProt (Write Protect) is not supported by the
When CRdy_Bsy_n is HIGH, indicating Rdy_Bsy_n has changed state, the Changed bit goes
HIGH. Additionally, this bit will drive the stschg_n pin LOW indicating Rdy_Bsy_n has changed
states, but only if the SigChg bit is HIGH and the card is configured to function in the I/O mode.
The Changed bit is reset to zero by a reset condition. Note that this bit is read-only.
SigChg
As a readable and writable bit, SigChg controls whether the stschg_n pin reflects the Changed
bit status. If SigChg is HIGH, the stschg_n pin indicates the status of the Changed bit when the
card is configured with I/O Space. If SigChg is LOW, the stschg_n pin will be held HIGH when
the card is configured with I/O Space.
This bit is reset LOW during a reset condition.
IOis8, XE_N, Audio, and PwrDwn

These bits are unused in this implementation of the CF+ card. If the user desires to enable the
functionality of these bits, code must be added to the source files. If a read is performed on the
CSR, all of these bits will be LOW with the exception of IOis8, which will be HIGH.
A reset has no effect on these bits.
Int
The Int bit reflects the status of an interrupt request from the I/O Space, regardless of the
setting of Conf2, the interrupt enable/disable bit. When HIGH, this bit indicates an interrupt is
pending. The bit will clear when the interrupt has been serviced. This bit is read only and is
reset to zero during a reset condition.
Pin Replacement Register

Located in the Attribute Memory space, this is an optional register that indicates the status of
pins that have been remapped during I/O Space configuration. Some pins lose their
functionality during I/O Space configuration, compared to Memory Mode configuration.
Specifically, the rdy/–bsy pin from Memory Mode becomes ireq_n during I/O Mode. This
register is 8 bits wide and is described in Table 8.
Table 8: Pin Replacement Register

Read 0 0 CRdy_Bsy_n CWProt 1 1 Rdy_Bsy_n WProt
Write 0 0 Host_CRdy_Bsy_n CWProt 0 0 MRdy_Bsy_n MWProt
Bits D2, D3, D6 and D7 are not writable. Bits D2 and D3 will be read as logic HIGH, whereas
bits D6 and D7 will be read as a logic LOW.
CRdy_Bsy_n
When Rdy_Bsy_n changes state, this bit is set to a logic HIGH. This bit may also be written to
by the host and is designated as Host_CRdy_Bsy_n in the source files. This bit is set LOW
during a reset.
CWProt
Since write protect is not used as detailed in the CompactFlash specification, CWProt is
unused in the source files and will read logic LOW.

1-800-255-7778
R
Rdy_Bsy_n
This bit represents the internal state of the rdy/–bsy pin when it has been reallocated as ireq_n
when the card has been configured for I/O Mode. When rdy/–bsy changes states (due to the
cm_sts pin in this implementation), this bit reflects that state. When written HIGH by the host,
this bit acts as a mask so that Host_CRdy_Bsy_n may be written by the Host. Writing to this bit
is by using the MRdy_Bsy_n bit in the source code. This bit is set LOW during a reset condition.
WProt
Since write protect is not used as specified by the CompactFlash specification, this bit and
MWProt are unused in this implementation. This bit is read as a logic LOW.
Common The functionality for the Common Memory space may be found in the reference design source
Memory file named cf_plus_control.vhd.
Common Memory has been implemented assuming an Intel StrataFlash 28F320J3 flash
memory is used. Since there are only 11 address lines on the CF+ interface, there are only 2 kB
of addressable common memory for the card. Common Memory is typically used as a working
memory space which contains mapping of the larger memory arrays found in the I/O Space
using True IDE Mode. Larger memory arrays are not included in this implementation, but can be
added by the user.
The CF+ controller implements all functionality when interfacing the Common Memory. This
includes addressing, byte mode select, reset, memory status, chip select and reset.
Addressing
The Intel StrataFlash memory can be accessed in either 16-bit or 8-bit modes. This works well
with the CompactFlash specification since the interface is accessed by the HBA in either 16-bit
or 8-bit modes. To access the Common Memory, reg_n must be HIGH. By using ce1_n and
ce2_n the 16-bit or 8-bit modes can be selected as required. When in 16-bit mode, cm_addr(0)
is driven HIGH or LOW depending on host_addr(0). When in 8-bit mode with cm_addr(0) HIGH,
the high (odd) byte is accessed from Common Memory. Conversely, when in 8-bit mode,
cm_addr(0) is LOW accessing the low (even) byte of Common Memory. When in 16-bit mode,
cm_addr(0) is ignored by the flash memory. Addresses cm_addr(10:1) are used to specify the
location of the byte or word in memory. Table 9 describes this relationship.
Table 9: Common Memory Addressing Modes

Addressing Mode cm_addr(10:1) cm_addr(0) cm_byte_n
8-bit host_addr(10:1) host_addr(0) 0
16-bit host_addr(10:1) 1 1
The signal cm_byte_n is used to indicate to the memory that byte mode is selected and is
active LOW.
Memory status is reflected on the ireq_n pin, acting as rdy/–bsy in Memory Mode. This status
is also available in the Rdy_Bsy_n bit of the PRR. The state of rdy/–bsy is directly related to the
cm_sts pin of the Common Memory Interface.
I/O Space Most I/O Space functionality is found in the reference design source file named
dsp_interface.dsp. The interface state machine is located in this file. Some control signals are
located in cf_plus_control.vhd. The pulse mode IRQ requires use of the counter found in
upcnt6.vhd.
For the I/O Space, the CF+ specification states that either 8-bit or 16-bit I/O access is allowable.
This application note describes the implementation of an 8-bit I/O Space as provided in the
reference design. If 16-bit access is required, the reference design can easily be modified to

1-800-255-7778
R
support this requirement. There are comments placed throughout the source files (VHDL) to
convert the I/O Space to 16-bit access, although 16-bit I/O Space access has not been tested.
Clock
This Compact Flash implementation requires an 80 MHz clock signal to be supplied to the
CPLD. This particular implementation with the Analog Devices ADSP-218xN series DSP, uses
the CLKOUT signal found on the DSP as the clock source. CLKOUT is a signal provided by the
DSP and is double the input clock signal to the DSP found on pin CLKIN. This implementation
assumes a 40 MHz clock on CLKIN of the DSP which subsequently becomes 80 MHz on
CLKOUT. The CPLD requires this 80 MHz signal on the dsp_clk pin to function correctly. If a
different clock speed is required for another implementation, it is recommended that a functional
and post-route simulation be performed to ensure correct functionality is retained.
Although the CF+ interface itself contains no clock, this 80 MHz clock can be used to ensure
proper timing of the interface signals.
Addressing I/O Space Registers

Three registers are provided as the communications venue to/from the I/O Space interface:
Address Register, Data Register, and Status Register. There is no direct communication with
the I/O Space—the communication is instead provided indirectly through these three registers.
Their functionality is described in the following sections.
To gain access to these registers, there are two sets of addresses: one for the DSP and one for
the HBA. This is intended to provide access to the same registers using two different memory
maps. Table 10 describes this addressing scheme.
Table 10: Addressing I/O Space Registers

DSP Address HBA Address Register Description
001h 400h io_addr_reg Address Register
002h 401h io_data_reg Data Register
003h 402h io_status_reg Status Register
Address Register
An 8-bit register is provided to pass address data to the DSP from the HBA, or in the reverse
direction, from the DSP to the HBA.
Data Register
Similarly, the Data Register is an 8-bit register that is used to pass data to/from the I/O Space.
It is read/write capable from both the DSP and the HBA.
Status Register
As a read-only register, Status Register contains information regarding the current Data
Register and Address Register transactions. Table 11 describes the relationship of the bits in
the register. All unused bits (D5:D2) are available for user implementation, as in the case of
inserting additional I/O Space registers.
Table 11: I/O Space Status Register

Read IRQ_CF IRQ_DSP 0 0 0 0 DataReg AddrReg
Write 0 0 0 0 0 0 0 0

1-800-255-7778
R
IRQ_CF
When new data is available in the Data Register or the Address Register given by the DSP, this
bit supplies an interrupt request to the HBA. A HIGH condition triggers an active LOW interrupt
on ireq_n, provided interrupts are enabled in Conf(0) of the COR. An interrupt condition is
recorded in the Int bit of the CSR regardless of the Conf(0) bit state.
To safeguard data in the Address and Data Registers prior to the HBA reading the new data,
the HBA is not permitted to write to these registers until the IRQ_CF bit has cleared. This bit is
cleared when the HBA reads data from either the Address or Data Registers or a card reset has
been performed.
The IRQ_CF bit is found in the reference design source files as io_status_reg(7).
IRQ_DSP
When new data is available in the Data Register or the Address Register given by the HBA, this
bit, in a HIGH state, indicates an interrupt request is pending to the DSP. This reference design
does not utilize an interrupt request pin for the DSP, and therefore, this bit is unused throughout
this implementation. This bit is available only for the purposes of the user if an interrupt request
pin is desired to be added for a specific application.
To safeguard data in the Address and Data Registers prior to the DSP reading the new data,
the DSP is not permitted to write to these registers until the IRQ_DSP bit has cleared. This bit
is cleared when the DSP reads data from either the Address or Data Registers or a card reset
has been performed.
This bit is found in the reference design source files as io_status_reg(6).
DataReg
When the Data Register has been written by either the DSP or the HBA, this bit is set HIGH.
This bit is used to indicate the Data Register has been written when an interrupt has been
detected by the system monitoring interrupts. This bit is cleared when the Data Register has
been read by the target system, or a card reset has been issued.
AddrReg
When the Address Register has been written by either the DSP or the HBA, this bit is set HIGH.
This bit is used to indicate the Address Register has been written when an interrupt has been
detected by the system monitoring interrupts. This bit is cleared when the Address Register has
been read by the target system, or a card reset has been issued.
State Machine
The I/O Space interface state machine synchronizes the communication between the DSP and
the HBA and relies on the 80MHz clock provided to the CPLD. This state machine consists of
seven states, including the IDLE state. Two basic paths in the state machine are available:
communication initiated by the DSP and communication initiated by the HBA. Figure 3 displays
the flow as described in the following paragraphs.

1-800-255-7778
R
io_write_n_sync = 0 IDLE dsp_address_match = 1

or dsp_ioms_n = 0
io_read_n_sync = 0 dsp_ioms_n = 0 dsp_wr_n = 1
dsp_rd_n = 1
CF_ADDR DSP_ADDR
io_address_match = 1 dsp_address_match = 1
and dsp_ioms_n = 0
io_read_n_sync = 0 dsp_rd_n = 0
io_address_match = 1
and CF_DATA_READ DSP_DATA_READ dsp_address_match = 1
io_write_n_sync = 0 dsp_ioms_n = 0
dsp_wr_n = 0
io_read_n_sync = 1 dsp_data_done = 1
or
dsp_ioms_n = 1
CF_DATA_WRITE DSP_DATA_WRITE
io_write_n_sync = 1 dsp_data_done = 1
or
X398_03_062003
dsp_wr_n = 1
Figure 3: I/O Space State Machine
IDLE State
The default state upon reset, is the IDLE state. In this state, the machine waits for either the
DSP or the HBA to initiate communications with the I/O Space registers. For a DSP initiated
data transfer, the state machine follows the right hand branch shown in Figure 3, whereas an
HBA data transfer is contained in the left hand path of Figure 3. The signal dsp_ioms_n
represents the ioms_n pin as it is driven by the DSP. The signals io_write_n_sync and
io_read_n_sync are the active low write and read request conditions as driven by the HBA. The
latter two are synchronized to the state machine using the 80 MHz clock.
DSP Read/Write
When a chip select condition has been detected as found on the ioms_n pin, the state machine
transitions to the DSP_ADDR state. During this branch of the machine, no HBA transactions
can occur with the I/O Space registers. The DSP_ADDR state waits for a valid address for one
of the registers in the I/O space. Once a valid address has been detected, the state machine
transitions to the DSP_DATA_READ or DSP_DATA_WRITE state, depending on the status of
the dsp_rd_n and dsp_wr_n pins.
The DSP_DATA_READ state allows data from the I/O space registers to be placed on the DSP
data bus. Once the data has been transferred to the DSP, the state machine transitions to the
IDLE state.
The DSP_DATA_WRITE state permits the DSP to transfer data from the data bus to the register
being addressed. Once data has been captured in these registers, the state machine
transitions to the IDLE state.

1-800-255-7778
R
HBA Read/Write
When the HBA issues a request for data from the I/O space, as indicated using the
io_write_n_sync and io_read_n_sync signals, and the state machine is in the IDLE state, the
machine branches to the CF_ADDR state. It is in this state that the machine waits for a valid
address from the HBA to access the I/O space registers. Once a valid address has been
detected from the HBA as indicated with io_address_match at a HIGH level, the state machine
transitions to either the CF_DATA_READ_STATE or CF_DATA_WRITE_STATE state. The
signals io_read_n_sync and io_write_n_sync direct the state machine to the respective state
when one of these signals is LOW.
Once in the CF_DATA_READ_STATE state, data is placed from the addressed I/O Space
register to the HBA data bus. Once the HBA has received the data and removed the read
condition from the CF+ interface, the state machine transitions to the IDLE state.
The CF_DATA_WRITE_STATE state allows data to be written to the addressed I/O Space
register from the HBA data bus. After the HBA has written the data and removed the write
condition from the CF+ interface, the state machine moves to the IDLE state.
Source Code The VHDL source code and test benches are available for this design. THE DESIGN IS
Download PROVIDED TO YOU "AS IS". XILINX MAKES AND YOU RECEIVE NO WARRANTIES OR
CONDITIONS, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, AND XILINX
SPECIFICALLY DISCLAIMS ANY IMPLIED WARRANTIES OF MERCHANTABILITY, NON-
INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE. This design has not been
verified on hardware (as opposed to simulations), and it should be used only as an example
design, not as a fully functional core. XILINX does not warrant the performance, functionality, or
operation of this Design will meet your requirements, or that the operation of the Design will be
uninterrupted or error free, or that defects in the Design will be corrected. Furthermore, XILINX
does not warrant or make any representations regarding use or the results of the use of the
Design in terms of correctness, accuracy, reliability or otherwise.
To simulate the files included in the download, it is necessary to obtain the VHDL model of the
Intel StrataFlash 28F320J3 memory from the Intel website. To obtain this VHDL model, visit
http://appzone.intel.com/toolcatalog/listtools.asp?pid=5319&cid=683&pfamily=
Disclaimer CompactFlash and CF+ are registered trademarks of CompactFlash Association. Xilinx
provides this reference design as one possible implementation of this standard and claims no
rights to this interface. To use this reference design, you must contact the CompactFlash
Association to obtain any necessary rights associated with this interface.
Conclusion The CoolRunner-II CPLD is the perfect device to use as an interface to a CompactFlash host.
These CPLDs exhibit low power consumption as well as other features that are beneficial to
these cards. Features such as 3.3V I/Os, Schmitt Triggers and DualEDGE clocking allow easy
integration to this type of system as well as provide flexibility to other functions on a
CompactFlash card.
Further Reading CoolRunner-II Data Sheets, Application Notes, and White Papers

1-800-255-7778
R
History

1-800-255-7778
R
Interfacing to Mobile SDRAM with
CoolRunner-II CPLDs
Summary This document describes the VHDL design for interfacing CoolRunner™-II CPLDs with low
power Mobile SDRAM memory devices. Mobile SDRAM is the ideal memory solution for
wireless, handheld, and mobile computing applications, making this a perfect match with the
Xilinx CoolRunner-II low power CPLD family. The VHDL code described here can be found in
VHDL Code, page 154.
Introduction CoolRunner-II CPLDs are the latest CPLD product offering from Xilinx. CoolRunner-II CPLDs
combine high performance with low power operation. Standby current on CoolRunner-II CPLD
devices is less than 100μA. More information on the CoolRunner-II CPLD family can be found
at http://www.xilinx.com/cr2.
Key features of the CoolRunner-II CPLD family include DualEDGE triggered registers, a global
clock divider, and voltage referenced I/O standards. These features provide the capability to
interface a CoolRunner-II CPLD with low power memory devices such as Mobile SDRAM.
Mobile SDRAM manufacturers include Micron and Samsung with data sheets available in
References, page 154.
Signal It is important to define the connections in this design before describing the CPLD logic to
Definitions interface with the Mobile SDRAM. Table 1 defines the Mobile SDRAM interface signals
described in this document.
Table 1: Mobile SDRAM Signal Definitions

Manufacturer Xilinx CPLD
Specification VHDL Code Description
CLK sdram_clk Clock input to SDRAM. All input signals are
referenced to positive edge of CLK.
CKE sdram_cke Clock enable.
CS# sdram_cs
RAS# sdram_ras
Command signals that define current operation.
CAS# sdram_cas
WE# sdram_we
LDQM, sdram_udqm, Mask signal for write data operations (LDQM
UDQM sdram_ldqm corresponds to DQ[7:0], while UDQM corresponds
to DQ[15:8]).

1-800-255-7778
R
Table 1: Mobile SDRAM Signal Definitions

Manufacturer Xilinx CPLD
Specification VHDL Code Description
BA[1:0] sdram_ba[1:0] 2-bit bank address bus.
A[12:0] sdram_a[11:0] 13-bit row and column address bus.
DQ[15:0] sdram_dq[7:0] Bidirectional 16-bit data bus.
Mobile SDRAM Mobile SDRAM devices feature low power technology to meet the needs of handheld
electronics. Additional power savings are achieved with two self-refresh features, temperature-
compensated self-refresh (TCSR) and partial-array self-refresh (PASR).
Read and write accesses to the Mobile SDRAM are burst-oriented, starting at a specific
address. SDRAM is organized in banks, where each data location can be represented with a
row and column address. Each access must begin with an ACTIVE command followed by the
READ or WRITE operation. The ACTIVE command selects the bank and row address, while
the individual READ or WRITE command select the column address. The Mobile SDRAM
features AUTO PRECHARGE, in which the row being accessed is initiated with a
PRECHARGE command at the end of the burst sequence.
The operation of the Mobile SDRAM device can be customized by writing different values to the
mode register and extended mode register. Each register allows the designer to set parameters
for interfacing with the memory device.
The following commands are available to execute with Mobile SDRAM devices:
• NOP (Deselect SDRAM device)
• ACTIVE (Opens row in specified bank for access)
• READ (Select bank and column, and start READ burst)
• WRITE (Select bank and column, and start WRITE burst)
• DEEP POWER DOWN (Maximum power savings, data is not retained)
• PRECHARGE (Deactivates open row in specified bank or all banks)
• AUTO REFRESH or SELF REFRESH (Retains data in SDRAM)
• LOAD MODE REGISTER (Defines operating mode of SDRAM)
More information on the Mobile SDRAM devices targeted in this design can be found in
References, page 154.
CPLD Design A CoolRunner-II CPLD is utilized as the controller for interfacing to the Mobile SDRAM memory
device. The CPLD is responsible for interpreting the system level commands and creating the

1-800-255-7778
R
interface requirements to the Mobile SDRAM. Figure 1 illustrates the main control logic in the
CoolRunner-II CPLD.
CoolRunner-II CPLD
sys_clk sdram_clk
sdram_cke
SDRAM State Machine sdram_csn
sdram_casn
sys_reset
CAS_CNT sdram_rasn
sys_addr [23:0] Mode Register
(UPCNT2) sdram_wen
sys_cmd [3:0]
WR_BRST_CNT RD_BRST_CNT
sdram_ba [1:0]
(UPCNT4) (UPCNT4)
sdram_a [12:0]
sdram_read_en
sdram_write_en
sys_data [15:0] sdram_ldqm
Data Control Logic sdram_udqm
sdram_dq [15:0]
X394_01_021003
Figure 1: CPLD Block Diagram
The system level interface is illustrated in this design as an example interface. This system
interface example is an asynchronous communication, with the signals registered in the CPLD.
The SDRAM state machine is the main controller in this design and is responsible for
generating the control, data, and address signals to the Mobile SDRAM device. The SDRAM
state machine also asserts control signals that are used internally by the CPLD for
reading/writing data and generating the SDRAM address signals. The SDRAM state machine
in this design utilizes a 2-bit counter for waiting the CAS latency in a READ cycle, and two 4-bit
counters, one for the length of a WRITE cycle burst and one for the length of a READ cycle
burst.
A detailed description of the SDRAM state machine is illustrated in Figure 2. The SDRAM state
machine remains in the IDLE state waiting for the next instruction to execute. The next
instruction to execute is interpreted from the system command bus, sys_cmd. In this design,

1-800-255-7778
R
AUTO PRECHARGE is utilized, where an ACTIVE command must be issued prior to any READ
or WRITE operation.
PRECHRG_ST
DPD_ST sys_cmd = DEEP_PD
sys_cmd = WAKE_UP sys_cmd = PRECHARGE
sys_cmd = AUTO_RFS IDLE LOAD_MR_ST

AUTO_RFS_ST sys_cmd = LOAD_MR
sys_cmd = READ
or WRITE
ACTIVE_ST
sys_cmd = READ sys_cmd = WRITE
WAIT_READ_ST WAIT_WRITE_ST
READ_ST WRITE_ST
cas_qout < CAS_LAT wr_brst_qout < BURST_LEN
WRITE_DATA_ST
CAS_DELAY_ST
wr_brst_qout = BURST_LEN
cas_qout = CAS_LAT
rd_brst_qout < BURST_LEN WAIT_TWR

READ_DATA_ST
rd_brst_qout = BURST_LEN
WAIT_TRP
X394_02_021003
Figure 2: SDRAM State Machine
The function of each state in the SDRAM state machine is described in Table 2.
Table 2: SDRAM State Machine State Description

State Name Function
IDLE Assert NOP instruction control signals to SDRAM. Determines
next operation to execute based on the value of sys_cmd signal.
AUTO_RFS_ST Assign SDRAM command values to execute AUTO REFRESH
instruction. Auto refresh retains data in SDRAM.
PRECHRG_ST Assign SDRAM command values to execute PRECHARGE
instruction. Precharge command deactivates specified row in
one bank or all banks.
LOAD_MR_ST Assign SDRAM command to execute LOAD MODE REGISTER.
The mode register or extended mode register can be written to in
this state, determined by bank address, sdram_ba signal.
DPD_ST Executes DEEP POWER DOWN command. Data in SDRAM
device is not retained in this state. Waits WAKE_UP for system
command to return to IDLE state.

1-800-255-7778
R
Table 2: SDRAM State Machine State Description

State Name Function
ACTIVE_ST Assign SDRAM command value to execute an ACTIVE
command. Assign row address to SDRAM address bus.
WAIT_READ_ST Execute NOP instruction. Necessary to meet timing specification
for tRCD.
READ_ST Issue READ instruction by assigning SDRAM signals. Assign
column address to address bus.
CAS_DELAY_ST Wait for specified CAS latency of READ operation. Enable CAS
latency counter, cas_cnt_en, is asserted.
READ_DATA_ST Read data from SDRAM. Assert sdram_read_en signal to data
control logic block. Enable rd_brst_qout counter. Remain in this
state for length of specified burst to capture all data.
WAIT_WRITE_ST Execute NOP instruction. Necessary to meet timing specification
for tRCD.
WRITE_ST Assign WRITE command values to SDRAM to issue WRITE
instruction. Assign column address to address bus.
WRITE_DATA_ST Enable data write to SDRAM by asserting sdram_write_en signal
to data control logic block. Enable wr_brst_qout counter. Wait for
end of write burst length.
WAIT_TWR Execute NOP instruction. Necessary to meet timing specification
for write recovery, tWR.
WAIT_TRP Execute NOP instruction. Necessary to meet timing specification
for precharge command period, tRP.
Device Utilization
The SDRAM interface design utilizes a CoolRunner-II XC2C128-4TQ144 device. The system
interface, SDRAM state machine, and SDRAM interface logic fits into this device with the
utilization results shown in Table 3.
Table 3: CoolRunner-II Design Utilization

Parameter Used Available % Utilization
I/O Pins 86 100 86%
Product Terms 180 448 40%
Registers 100 128 78%
Function Block Inputs 126 320 39%
System Interface
The SDRAM design described in this document includes a generic system interface. The
system interface illustrates the basic control signals needed for the SDRAM logic block. These
signals include a system clock, reset, 24-bit address bus, 16-bit data bus, and 4-bit command
bus. Excluding the system clock, all signals are asynchronous and registered in the CPLD.
Modeling of the system interface in this design is done with testbench logic. The testbench is
responsible for generating the address, data and command signals for any operation with the

1-800-255-7778
R
Mobile SDRAM device. The testbench controls the initialization requirements, single read/write
operations, and tests the power down modes of the SDRAM.
VHDL Code THIRD PARTIES MAY HAVE PATENTS ON THE CODE PROVIDED. BY PROVIDING THIS
XAPP394 -ftp://ftp.xilinx.com/pub/applications/refdes/xapp394.zip
Conclusion CoolRunner-II CPLD devices are the perfect compliment to low power Mobile SDRAM memory.
These two low power devices are targeted for handheld, mobile computing applications.
CoolRunner-II CPLD devices feature low power consumption and create a seamless interface
to Mobile SDRAM memory.
References 1. Micron Data Sheet. MT48V16M16LFFG 256Mb: x16 Mobile SDRAM. Micron Technology,
Inc. 2002.
2. Micron Technical Note. TN-48-10. Mobile SDRAM Power-Saving Features. Micron
Technology, Inc. 2002.
3. Samsung Data Sheet. K4S64163LF-RG/S 4Mx16 Mobile SDRAM. Rev 1.0. Samsung
Electronics 2002.
Additional CoolRunner-II Data Sheets, Application Notes, and White Papers

Information
History
12/01/03 1.1 Errata

1-800-255-7778
Application Note: CPLD
An SMBus/I2C-Compatible Port Expander

XAPP799 (v1.1) August 2, 2005
Summary Today’s microcontrollers and microprocessors often limit the number of General Purpose I/O
(GPIO) ports in order to conserve pin count and to reduce package sizes. Unfortunately, for
many designs, the number of I/O ports required exceeds the number of available I/O ports on
a microprocessor. Hence, Complex Programmable Logic Devices (CPLDs) can often be found
in a system alongside a microcontroller functioning as a port expander. This Application Note
presents a design of a port expander that fits into a CoolRunner™-II XC2C32A device -- A port
expander that is SMBus and I2C compatible.
CoolRunner-II A key advantage of using any Xilinx CPLD as a port expander is the integration of logic
Advantages functions across the entire board. The flexibility of programmable fabric allows for a variety of
dissimilar functions to be implemented on one chip. A CPLD can be used as a port expander,
an LED driver, an address decoder and a memory controller, all at once.
CoolRunner-II devices add further value being the lowest cost and lowest power CPLDs on the
market. These CoolRunner-II parts also provide I/O Banking capability, allowing for level
translation between the microcontroller and its external peripherals. Both features are favorable
for an SMBus or I2C design, as these environments are typically multi-voltage environments
requiring low power.
Table 1 summarizes the level translation abilities of the CoolRunner-II family.
Table 1: I/O Standards for the CoolRunner-II XC2C32A

Board
IOSTANDARD Output
Input VCCIO Input VREF Termination
Attribute VCCIO
Voltage VT
LVTTL 3.3 3.3 N/A N/A
LVCMOS33 3.3 3.3 N/A N/A
LVCMOS15(1) 1.5 1.5 N/A N/A
(1) LVCMOS15 requires the use of Schmitt Trigger
Using the The port expansion reference design shown in Figure 1 provides 8 output ports and 8 input
CoolRunner-II ports controlled through an I2C compatible serial interface. This design is scalable. The code
can be modified to increase or decrease the number of desired output ports and input ports.
SMBus/I2C Port This section describes the default code implementing 8 outputs and 8 inputs. The fully working
Expander
Design
© 2005 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc.
All other trademarks are the property of their respective owners.
XAPP799 (v1.1) August 2, 2005 www.xilinx.com 155

R
Using the CoolRunner-II SMBus/I2C Port Expander Design
project, with source code, is available for download at

http://www.xilinx.com/bvdocs/publications/XAPP799_designfiles.zip.
CoolRunner-II
top.v
XC2C32A
i2c_module_mod.v
sda_in
8-bit Shift Register
shift_data_in
data_in[7:0]
ack_out
out_en external
pull_up
sda_out
i2c pld_sda_out
INDEX Start START
STATE DECODE
COUNTER
MACHINE LOGIC
scl
pld_i2c_scl
latch_data_out
gpio_input[1:0]
latch_data_in
data_in[7:0]
8 2
GP10_OUTPUT GP10_INPUT
(8 BITS) (2 BITS)
reset goes 8 2
to all
blocks
i2c_rst
pld_i2c_rst
GPIO_OUTPUT_PINS[7:0] GPIO_INPUT_PINS[2:0]
x799_01_071305
Figure 1: I2C Port Expander Block Diagram
Table 2: Pin Descriptions

Name Function
pld_i2c_scl Serial Clock Line
pld_i2c_sda Serial Data Line
pld_i2c_rst Active High Reset
GPIO_Output_Pins Port Expansion Outputs
GPIO_Input_Pins Port Expansion Inputs
Serial Interface
This port expander design uses a serial data line (SDA) and a serial clock line (SCL) to achieve
bidirectional communication with a master. The master, typically a microcontroller or
microprocessor, initiates all data transfers to and from the CPLD. The master is also
responsible for generating the SCL clock that synchronizes the data transfer.
Each transaction consists of a start condition sent by a master, followed by the CPLD’s
predefined 7-bit slave address plus an R/W bit, and one data byte that is either transmitted from
the master to the CPLD (for a write operation) or one data byte that is transmitted by the CPLD
to the master (for a read operation). An Acknowledge bit is used at the end of each data byte,
and data is transferred on every rising clock pulse.
156 www.xilinx.com XAPP799 (v1.1) August 2, 2005

R
Start Condition
Both SCL and SDA remain high when the interface is inactive. The master signals the start
condition by transitioning SDA from high to low while SCL is high (Figure 2). Once a start
condition is recognized by the CPLD, an internal ‘start’ pulse is generated, and the state
machine will begin.
Figure 2: Start Condition Initiated
Acknowledge
The acknowledge bit is sent every 9th bit, indicating receipt of each data byte. Each byte
transferred effectively requires 9 bits. The master generates the 9th clock pulse, and the
recipient pulls down SDA during the acknowledge pulse. This means that when the master is
transmitting to the CPLD, the CPLD generates the acknowledge bit. When the CPLD is
transmitting to the master, the master generates the acknowledge bit.
I2C Slave Address

The CPLD has a 7-bit long I2C slave address that can be preprogrammed into the device
through the source code. Edit the top level Verilog source file (top.v) and define your desired 7-
bit binary value for the “my_i2c_addr” parameter. The 8th bit following the 7-bit slave address is
the R/W bit. Set this bit low for a write command and high for a read command.
Performing a Write Command

After a slave address with a write command has been sent, one final data byte must be sent
from the master to complete the transaction. This data byte defines the state of each of the 8
I/O’s. The MSB of the data byte defines the value on ‘GPIO_OUTPUT_PINS[7]’ and the LSB of
the data byte defines the value on ‘GPIO_OUTPUT_PINS[0]’. The outputs assume their
defined values during the 9th clock cycle, together with the acknowledge pulse.
Figure 3 shows a full Write Command transaction. The master initiates a start command, then
sends a write request to the CPLD, located at slave address 0x56. The CPLD acknowledges
the write request on the 9th clock edge, and the master continues delivering data to the CPLD

R
dictating the values on the GPIO output ports. On the 9th clock cycle, the CPLD acknowledges
this second data byte, and sets the GPIO output pins accordingly.
Figure 3: Write Command Transaction
Performing a Read Command

If a slave address with a read command has been sent, one final data byte is sent from the
CPLD to the master. The data byte relays the values present on the ‘GPIO_INPUT_PINS’ bus.
Figure 4 shows a full Read Command transaction. The master initiates a start command, then
sends a read request to the CPLD located at slave address 0x56. The CPLD acknowledges the
read request on the 9th clock edge. On the next data byte, the CPLD returns the value on the
GPIO input pins. In this example, since there are only 2 GPIO input pins in the design, only the
data on the 7th and 8th clock are valid. The first 6 data bits are high by default, and are ignored
by the master. On the 9th clock cycle, the master acknowledges this second data byte, and the
read transaction completes.
Figure 4: Read Command Transaction
Standby
The CoolRunner-II family of CPLDs automatically enters "standby" when all pins are set to Vcc
or GND. Standby current is specified in the individual device data sheets. This design fits into
an XC2C32A device, which has a typical standby number of 22 uA -- ideal for SMBus and I2C
applications.

R
Customizing the Design
Utilization
The following are the utilization statistics:
Table 3: Device Utilization

Macrocells Product Terms Function Block Registers
Pins Used/Total
Used/Total Used/Total Inputs Used/Total Used/Total
32/32 (100%) 71/112 (63%) 36/80 (45%) 32/32 (100%) 13/33 (39%)
Customizing This reference design can be customized to fit any specific design target. If the design requires
the Design more GPIOs, the state machine in the source code can be modified accordingly. Should
bidirectional I/O’s be required, the design can be modified to use the R/W bit as a signal to
decode whether the I/O pin should function as an input or output. There are many possibilities,
and the source code has been written for the most general case.
Conclusion This port expander design can be used as a complete turnkey design that fits readily into a
CoolRunner-II XC2C32A device. You can easily edit the port expansion module to fit your
needs, and additional functionality can be integrated into the CPLD. The CoolRunner-II family
of CPLDs is unique in that it is the only low cost, easy to use, low power device available today.
History
08/02/05 1.1 Fixed broken link to design files.

R
Revision History

Application Note: CPLD
Driving LEDs with Xilinx CPLDs

XAPP805 (v1.0) April 8, 2005
Summary Light-Emitting Diodes (LEDs) are commonplace on the modern day Printed Circuit Board
(PCB). Whether they are indicating status, activity or some other function, they need to be
driven by a device that can provide sufficient current to illuminate them. Traditionally, LED driver
devices have been used for this purpose, but this application note aims to demonstrate how
that functionality can be incorporated into Xilinx CPLDs to save both cost and valuable board
space.
Introduction Specific driver devices are commonly used to drive common-anode LEDs, including seven
segment displays. Figure 1 shows a typical configuration. The output pin of the driver device
connects to the cathode of the LED, and the anode is connected to VCC. When a low signal is
applied to the output, the driver sinks current and the LED illuminates. Each LED will require a
different threshold current to illuminate, but some common examples are found in Table 1
below. As discrete LED Driver ICs integrate more features, their costs rise.
Vcc
LED
LED
Driver
Series
Resistor
Figure 1: Traditional LED Driver Setup
Table 1: Partial List of Available LED Drivers

LED Driver Chip Features
AD8240 Automotive LED Driver with Lamp Failure Detection and PWM Input
ADM8846 LED Driver for White LED LCD Backlights (Cell Phone)
FAN5609 LED Driver with DC/DC Converter
LT1932 Constant Current DC/DC LED Driver
MAX6956 LED Static Display Driver
ICM7218C 8-digit 7-segment Display Driver
TB62701 16-digit LED Driver with SIPO Shifter
TB62705 8-digit LED Driver with SIPO Shifter
XAPP805 (v1.0) April 8, 2005 www.xilinx.com 161

R
Using Xilinx CPLDs to Drive LEDs
Using Xilinx Typical Circuit

CPLDs to Drive Xilinx CPLDs can be used instead of traditional LED driver devices to save both cost and board
LEDs space. Figure 2 shows a typical circuit diagram. A current limiting resistor is typically placed
between the output of the CPLD and the cathode of the LED. When the CPLD drives low, the
LED illuminates.
Vcc
LED
Xilinx
CPLD Series
Resistor
Figure 2: Xilinx CPLD Driving an LED
CPLD Output Drive

Table 2 shows the current that can be delivered by a single output of a Xilinx CPLD when
driving low. The values are taken from the individual data sheets of each Xilinx CPLD family.
You will find the information under the DC Electrical Characteristics sections.
Table 2: Xilinx CPLD Drive Strengths

Xilinx CPLD Family Current Drive Strength
XC9500 (5V) 24 mA
XC9500 (3.3V) 10 mA
XC9500XL 8 mA
XC9500XV 8 mA
CoolRunner™ XPLA3 8 mA
CoolRunner™-II 8 mA
From Table 2, it is clear that Xilinx CPLDs are ideal for driving LEDs that require up to 8-10 mA
to illuminate.
162 www.xilinx.com XAPP805 (v1.0) April 8, 2005

R
Ganged Output Circuits

In cases where 8 mA is insufficient to illuminate an LED, multiple outputs can be tied together
to offer double or triple the current sink of a single output. See Figure 3.
Vcc
LED
Series
Xilinx Resistor
CPLD Series
Resistor
Figure 3: Gang Multiple Outputs Together for Greater Drive Strength
Display Drivers
Using the example of an 8-digit 7-segment display driver, we can see a typical circuit design in
Figure 4.
Segment Select
8
Digit Select
8
Figure 4: 8-digit 7-segment Display Driver with Data Interface
Figure 5 shows how a Xilinx CPLD can be used instead of a discrete display driver. It is very
likely that a Xilinx CPLD will have spare capacity after implementing an LED display driver; this
capacity can be used for other board functions. For example, the functions of other discrete
components on the board can be incorporated into the CPLD. The logic that fills the remaining
capacity of the CPLD does not have to interface at the same level. Because of the split rail
VCCIO available on all CoolRunner-II devices, the CPLD can interface with components of at

R
least two voltages simultaneously (1.5V, 1.8V, 2.5V or 3.3V). For more information on how to
incorporate discrete components, see White Paper 202. For more information on the use of
split rail I/O banking, see the CoolRunner-II Family Data Sheet.
Discrete Logic
Absorption
VCCIO1 VCCIO2
3.3V 2.5V
I/O Bank 2
I/O Bank 1 Level Shifting
Xilinx CPLD
8 Digit Select
Segment Select
Figure 5: Xilinx CPLD Used as an 8-digit 7-segment Display Driver with Remaining
Capacity Used to Incorporate Discrete Logic and Interface to Different Voltage Levels
Typical Versus Worst Case Drive Values

The values of VOL for the different Xilinx CPLD devices are mentioned in the data sheets in a
format similar to Table 3.
Table 3: Output Low Voltage for the XC2C64A (LVCMOS 3.3V and LVTTL 3.3V DC Voltage Specifications Shown)
Symbol Parameter Test Conditions Min. Max. Units
VOL Low Level Output Voltage IOL = 8 mA, VCCIO = 3V - 0.4 V
IOL= 0.1 mA, VCCIO =3V - 0.2 V
These numbers are taken under worst case conditions and, therefore, we can guarantee that
the devices will be able to meet this specification. However, it should also be noted that the
output buffers can probably drive significantly more current than worst case conditions.
To find out how much current the output buffers can typically supply, the I/V curves for the
devices are needed. They can be found in XAPP150 for the XC9500/, XC9500XL, XC9500XV

R
Guidelines for Driving Multiple LEDs with the Same CPLD
and CoolRunner XPLA3 families. For CoolRunner-II device I/V curves, look in the individual
CoolRunner-II datasheets. They appear as shown in Figure 6.
Figure 6: I/V Curve for the XC9500XL Family
Under the typical conditions shown above, it is evident that at 0.4V the output low current (IOL)
is as high as 20 mA. Of course, these numbers are typical and cannot be guaranteed under
all circumstances.
Guidelines for As mentioned earlier, it is possible to tie two or more outputs together to double or triple (and et
Driving Multiple cetera) the drive strength for power hungry LEDs.
LEDs with the If multiple LEDs are to be driven by individual pins on the same CPLD, there are a few
guidelines that may be helpful. These help to reduce the effect of ground bounce due to
Same CPLD multiple outputs switching simultaneously, and hence avoid corrupting the operation of other
devices driven by the CPLD.
• Try to stagger the switching of the outputs. LEDs are almost always used for indicating
status to a human. Human reactions are sufficiently slow that delaying the output
switching by a small amount of time will not be noticable
• Try to skew the switching of the LEDs slightly using the adjustable fast/slow slew rate of
the outputs
• If using an XC9500, XC9500XL, or XC9500XV device, try putting some of the macrocells
into low power mode, and leave others in high frequency mode. This will have the effect of
skewing the switching outputs slightly
• Try to distribute the pins driving LEDs evenly around the device package so as to locate
them next to Ground pins. The individual device datasheet has a listing of the pin locations
on each package.
Conclusion Xilinx CPLDs can easily take the place of discrete LED driver devices. They can deliver
sufficient current to illuminate most LEDs, but if more current is required, multiple outputs can
be tied together. The current drive strength of the different Xilinx CPLDs can be found in the
device data sheets available on the Xilinx website. However, under typical conditions, the Xilinx
CPLDs can output more current.

R

Information Other CPLD Data Sheets, Application Notes and White Papers
Device Packages
History

White Paper: CoolRunner-II CPLDs
WP198 (v1.1) July 4, 2005
CoolRunner-II CPLDs in Cell

Phone Handsets/Terminals
Cell phone handsets (or “terminals,” as they’re called in

Europe) are among the most dynamic products in the
electronics market today. From their original analog roots,
they have evolved into nearly pure digital devices with as
much functionality as complex PDAs. Consumers who
once evaluated handsets based on their ability to make
high-quality local calls now take call clarity as a given.
Their choices instead rest on characteristics ranging from a
handset’s "skin" color to its ability to support streaming
video. Buyers, even those shopping for low-cost handsets,
increasingly demand these kinds of features: "extras" are
well on their way to becoming standards. This shift puts
manufacturers in a bind as they try to balance low cost
with the ever-increasing consumer insistence on new
features. Should customers pay for these features outright,
or should their monthly payments subsidize the handset
cost?
Each country has adopted an individual economic model

to resolve this question. Common to all of these models,
however, is a need to financially cope with increasing
numbers of new features. Our goal in this white paper is to
show how using CoolRunner™-II CPLDs in handsets will
make it easier for handset developers to make these future
changes—as well as baseline handset capability—
financially viable.
WP198 (v1.1) July 4, 2005 www.xilinx.com 167

R
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
Quick Look at a Figure 1 shows a fairly straightforward block diagram of a digital-type handset.
Handset
A/D SPEECH CHANNEL CHANNEL RF RF

AMP
CODER CODER SPREAD MOD
SRAM DRAM
DISPLAY
μproc dsp
Application DUPLEXER
Space
CoolRunner-II EPROM
KEYBOARD
CPLD
SPEECH CHANNEL RAKE RF RF

D/A DECODER DEMOD RCV/AMP
DECODE RCVR
Figure 1: Functional Components of a Digital Handset/Terminal
In this diagram, we don’t show specific connections between the microprocessor, the
DSP, and the various boxes within the handset. Typically, they are all interconnected.
In fact, some functions may be implemented by either processor. This saves board area
at the expense of processor bandwidth. Let’s assume the microprocessor handles
baseline tasks like managing the display and the keyboard, but the DSP does channel
coding/decoding and other signal processing tasks in the phone. The microprocessor
handles dialing.
Let’s simply look at sending and receiving audio. The microphone delivers audio
signal to the A/D converter, creating a bit-stream. Fidelity and efficiency require
redundancy elimination and compression. This is done in the speech coder (typically
adaptive multirate). Forward Error Correction (FEC) occurs in the channel coder
(Viterbi today, Turbo tomorrow). Coding adds back redundancy, but dropped bits can
be recovered. CDMA channel spreading has been introduced in the U.S. and Korea,
but others may use TDMA, SCDMA or WCDMA. The digital signal finally gets to the
RF modulator and RF amplifier where it becomes one of several signal types (again,
depending on the phone standard). At this point, it is analog. Today, these are in the
gigahertz range and focused on octal phase shift keying. The duplexer is inserted to
switch between receiving and sending at the antenna.
On the receiving end, the signal hits the antenna, slides through the duplexer and is
amplified and demodulated, becoming digital. The Rake Receiver “despreads” the
received bits and forwards the signal to the channel decoder, which reconstructs the
possibly corrupted digital signal and passes it on to the speech decoder. The speech
decoder corrects bit-dropout and should resemble the digital version of the original
analog signal. This forwards to the D/A converter, which, when filtered and
amplified (not shown), drives the earphone.
168 www.xilinx.com WP198 (v1.1) July 4, 2005

R
If the phone is going to support 3G capability, typically it must handle other standards
(2G, 2.5G and GPRS) because different countries are at different levels of deployment.
Why pay for a high-end phone and be able to only use it on the high end systems?
Would you want to carry multiple phones, or should the manufacturer make sure
your super handset just works wherever you are? Given that the latter is the case,
your handset is basically three or four phones, depending on what communication
link you are connecting to. It’s a lot to ask, but 3G isn’t about signaling, quality and
compatibility, as much as it is about applications.
Applications By now, you should have noticed the big box on the right hand side of Figure 1. That
is reserved for advanced applications—things that go beyond making a call. Let's
revise Figure 1 to set the stage for the kinds of things we will need to add applications.
For starters, cell phone standards committees categorize applications according to
parameters like guaranteed bit rate, variable/fixed delay, asymmetric/symmetric
traffic and whether or not buffering is allowed. In terms of words we can relate to,
those categories translate into conversational class, streaming class, interactive class
and background class. These designations are based on the properties of those classes
of applications. For instance, an ordinary conversation cannot tolerate long delays and
echoes, as such things upset users. Lots of image dropout on a video data-stream also
upsets users. So, by thinking through the needs of whole classes of applications,
developers arrive at important quality factors. Listed below are some of potential cell
phone applications; some may cross over more than one of the classes listed above.
1. MP3 music 21. Business kiosks

2. Distance Learning 22. Secure monitoring
3. Online Retail 23. telemedecine
4. Travel booking 24. Mobile clinics
5. E-books 25. Email
6. Distance Learning 26. Secure monitoring
7. Online Retail 27. Targeted advertising
8. Travel booking 28. Free trials
9. M-commerce 29. Remote metering
10. Online trading 30. Remote control
11. Mobile banking 31. Mobile speed cameras
12. Gambling 32. Remote surveillance
13. Games Interactive toys 33. Ticket purchases
14. Video movie rental 34. Showtime information
15. Virtual radio station 35. Vending machines
16. Virtual TV station 36. Parking meters
17. Newspapers 37. Buying Crossword puzzles
18. Photo album 38. Navigation
19. Video Conferencing 39. Finding ATM money machines
20. Field service 40. And many more . . .

R
Each application has its own particular needs, so it might be appropriate to consider a
few of them individually. For instance, music via MP3 files could be done entirely in
software, the same way that PCs can play files. If the processors are burdened with
channel coding/decoding and possibly with decryption, it might be more feasible to
include an MP3 decoder chip within the phone, or as an add-on. Video movie rental
would probably have the files being downloaded via GPRS and linked through the
Internet. Clearly, vendors renting the files would want to assure their MPEG-4 files
weren’t being delivered to pirates. Vendors would insist on encryption as well as
compression. Adding these to the channel decoding exhausts today’s processors and
drains batteries. There would also be a need for buffering frames, to support dropout
in the Internet protocol. Some applications might require JPEG, MPEG-4, MP3,
encryption and channel coding. This suggests the need for additional offloading logic.
Let’s look at a commercial chipset for doing all of this, and then discuss offloading.
Cell Phone Figure 2 shows an Intel PXA 800F block diagram. Note that this multifaceted chipset is
Chipsets designed to integrate all the key functionality for the baseline, base-band operations,
with a clear focus on using software to handle a broad range of other applications.
PXA800F
JTAG JTAG Intel® Xscale TM Cellular Processor
CTRL Core
External
Memory Interrupt Controller GSM IRQCtrl
Bus I-Cache D-Cache
4MB Flash 512 KB SRAM
Memory Controller
Xscale TM Core Peripherals Intel® MSA Core

Bridge DMA Controller
Keypad IF PWM 512 KB Flash
Rotary Encoders One Wire I/F 32 KB SRAM A 32 KB SRAM B
Reserved 3x Timers/WDT MSA DMA Ctrl GSM IRQ Ctrl
GPIOs M/N Clock Out Viterbi Accelerator Cipher Accelerator
UART 1,2,3 TCU Voiceband DSSP1 Rx Band DSSP2
CSSP USB Tx Band DSSP1 Auxiliary DSSP4
I2C GSM SIM RF Control DSSP5 DAI DSSP6
MMC/SD UICC HSL I2S
GSM SlowCLK
Clocks, Power Mgmt, RTC/VXO/PLL
Figure 2: Intel PXA 800F Cellular Chipset

Manufacturers such as Motorola, Qualcomm and Texas Instruments offer their
versions of chipsets that attempt do deliver the maximum capability in the minimum
number of chips. Each is somewhat different in functional partitioning. The thing that
is difficult for them to do is add enough flexible functionality to adapt to arbitrary
future applications. We frequently see pins referring to keyboard interfaces, or display
interfaces, which is great, but they are all different. Some of the European UMTS
terminals resemble pocket computers with wide screen displays and full computer
keyboards as opposed to 12-16 keys on a simple cell phone. Adaptation logic is needed
to use these chipsets with broader applications.

R
Picking the Figure 3 shows an application that is not on the list—Global Positioning Satellite (GPS)
Right Mix service. It can use the same antenna as the phone receiver/transmitter, but it will drag
the satellite signals into the chip, collect the data and deliver the co-ordinates of your
location to the DSP. Emergency police/ambulance calls need this.

AMP
SRAM DRAM
DISPLAY
CoolRunner-II
μproc dsp CPLD GPS DUPLEXER
CoolRunner-II
KEYBOARD EPROM
CPLD
SPEECH CHANNEL RAKE RF RF

DECODE RCVR
Figure 3: GPS Added into a Phone

In this case, it is impossible for the DSP or the microprocessor to “grow another radio
chip.” As long as the standard RF demodulator is being used, a second will be needed
to support the GPS. The GPS will need to be interfaced to the processor buses to get
data. The CoolRunner-II CPLD easily creates bus interfaces, interrupts and control
operations for the processors, tying peripherals in.
Another example would be a camera. Adding a CMOS imaging chip requires
interfacing it to the processor buses, along with additional memory to buffer images.
Cameras come with either parallel or serial interfaces. Why be constrained to THEIR
choice of peripherals in YOUR product?
For some time to come, applications will consist of adding in special application
circuitry and interfacing it into the processor buses. Given that, how can a designer
select the right application-specific circuits to add in, so that one ASIC could be built to
interface them all? Basically, they can’t. Below is an array of application modules that
might be added into the phone:
- MP3
- MPEG-4
- Compact Flash +
- Video Camera
- GPS
- MMC/SDI
- More SRAM
- More DRAM
- More EPROM

R
But what about new applications that are not in this group? There are applications yet
to come that we can envision, but whose exact specifications we cannot wholly
anticipate. Designing for their arrival is sometimes called “future proofing.”
It is true that some applications are better served by microprocessor code dropped into
on board EPROM, but that can only happen as long as the processor bandwidth is
available for the application. If this cannot be done, either more processors or
additional silicon needs to be added. Either way, the application will need to interface
into the phone bus network, and that will require programmable logic, very low
power programmable logic.
MediPhone—A To drive home some of these ideas, consider an idea for a product that probably does
Speculative not exist today, but easily could in the near future. It will be marketed under the name
Example “MediPhone” and will target segments of the population that require quick medical
support. This would include the growing population of elderly citizens (frequently
with enough money to buy these) as well as handicapped people needing close
monitoring. See Figure 4 for an “artist” conception of this futuristic phone.

AMP
SRAM DRAM EKG EEG SRAM
DISPLAY
μproc dsp A/Ds CoolRunner-II

CPLD
GPS DUPLEXER
CoolRunner-II
KEYBOARD EPROM Camera
CPLD MPEG 4 DRAM
Chip
SPEECH CHANNEL RAKE RF Rf

DECODE RCVR
Figure 4: MediPhone Block Diagram
MediPhone works like this:

1. A heart attack (or other medical emergency occurs)
2. The victim or friend dials Emergency (911 in the U.S.)
3. Personnel receiving the call at a medical facility recognize the phone is
“MediPhone” equipped and extract the geographic location of the emergency
using GPS
4. The medic directs the friend to place the cell phone on the victim’s face
5. A video camera scans the Iris for dilation to determine shock level
6. The friend is directed to attach small electrodes to the forehead/ear and chest of
the victim, where pulse is taken and EEG/EKG measurements are driven into the
Internet. Everything is attached to the phone.

R
7. Temperature is measured by physical contact of the forehead with the victim off
the back of the phone
8. Microphone gain is adjusted to listen to the victim’s breathing
9. It is determined that a heart attack has occurred and the friend is directed to
elevate the feet and is given directions for CPR from the medic while an
ambulance is dispatched
10. Ten minutes later, the ambulance team takes over and the MediPhone medic is
released. For insurance reasons, all transaction data are encrypted, compressed
and stored on CD for future reference.
11. The victim is saved and lives happily ever after . . .
In order to do this, MediPhone requires greater application functionality than
discussed so far. Adding instrumentation amplifiers, A/Ds, transducers and support
circuitry go beyond just having video and GPS as mentioned earlier. CoolRunner-II
CPLDs would interface the various items needed to support MediPhone. The
associated processor buses and memory interfaces are needed to support the capture
of the information taken. Other ideas quickly come to mind (WeatherPhone, ToxicGas
Phone, etc.)
Power and We have not yet mentioned power in this discussion, but it may be a key element in
Packaging are figuring out a solution, at least at the outset. Power management requires a careful
Key! balance of dynamic operations within a cell phone. Do we add in specialty silicon, or
do we just use a bigger EPROM and do it in software? As mentioned earlier, some
choices are made for us. It would be ideal to just do it in the software, unless the
bandwidth requirement on the processor(s) exceeds what could be done with a
separate chip interfaced into the phone bus. Nonetheless, adding power consuming
chips must be balanced against adding incremental code space, which also increases
the power consumption. Whether you are interfacing more EPROM or additional
ASSP silicon, CoolRunner-II is the ideal low power interface, with standby currents as
low as 14 microamps. For power management, CoolRunner-II CPLDs are frequently
used to enable/disable the power delivery to other chips within a system. So, if you
are not using your camera or GPS capability, they can be automatically shut down to
minimize power draw.
In addition to the unsurpassed power savings at high performance (clocking in the
300+ MHz range) provided by CoolRunner-II RealDigital technology, it is also critical
to note that CoolRunner-II devices are offered in a wide range of very small packages.
Table 1 shows part densities, available packages and other key features of
CoolRunner-II CPLDs.
Table 1: CoolRunner-II CPLD Family Parameters
XC2C32A XC2C64A XC2C128 XC2C256 XC2C384 XC2C512
Macrocells 32 64 128 256 384 512
Max I/O 33 64 100 184 240 270
TPD (ns) 3.8 4.6 5.7 5.7 7.1 7.1
TSU (ns) 1.9 2.0 2.4 2.4 2.9 2.6
TCO (ns) 3.7 3.9 4.2 4.5 5.8 5.8
FSYSTEM1 323 263 244 256 217 179
(MHz)

R
Looking The fourth generation cell phones are already being referred to as Software Defined
Forward to 4G Radio (SDR), because so many things can be more easily (in theory) changed with
software. Processor speeds in the gigahertz range result in swift, agile flexibility.
However, as mentioned earlier, software cannot “grow” a camera. Software cannot
add in a bus interface to Compact Flash +. Software cannot grow another radio
channel. Only hardware can do some things, and when developers know neither
when nor what the next new "thing" will be, only programmable logic can solve their
development quandary. CoolRunner-II CPLDs provide the future proofing to help
drive 4G cell phones.
Conclusion We have focused, at a high level, on requirements of cell phones and on the capabilities
of CoolRunner-II CPLDs for meeting those requirements. Given the current trend
toward packing as much functionality as possible into handsets without increasing
their power consumption, CoolRunner-II is an ideal choice for building phones that
need to quickly adapt to new applications still on the horizon.
Product differentiation will ultimately result in winning designs. If developers want to
cinch their winning positions, they must ensure that their designs have distinctive,
useful applications that outdo those of their competitors. Using CoolRunner-II CPLDs
to plan for future feature changes can contribute enormously to speedy and cost-
effective introduction of such applications.
References 1. UMTS Networks, Architecture, Mobility and Services, H. Kaaranen, A. Ahtiainen, L.

Laitinen, S. Naghian, V. Niemi, 2001, John Wiley & Sons, Ltd.
2. Services for UMTS (Creating Killer Applications in 3G), T. Ahonen, J. Barrett, editors,
2002, John Wiley & Sons, Ltd.
3. 3G Wireless Demystified, L. Harte, R. Levine, R. Kikta, 2002, McGraw-Hill
4. "The Mobile Phone Meets the Internet," M. W. Oliphant, August 1999, I.E.E.E.
Spectrum
5. "Evolving Cellular Handset Architectures but a Continuing, Insatiable Desire for
DSP MIPs," M. L. McMahan, March 2000, Texas Instruments Application Report
SPRA650
Further Reading The following links provide information useful for handset and CoolRunner-II design.
CoolRunner-II Design Kit

http://www.xilinx.com/products/cr2/design_kit.htm
Application Notes
Select the link below for a complete list of links to over 75 CoolRunner-II Application
Notes. The list includes notes on the PicoBlaze Microcontroller, Keypad Scanners,
Level Translation, Bus Controllers, Memory Interfaces, and Handheld Designs.
CoolRunner-II Application Notes
If you are looking at a printed copy of this document, go to www.xilinx.com and go to
the documentation link.

R
CoolRunner-II Data Sheets

http://direct.xilinx.com/bvdocs/publications/ds090.pdf (CoolRunner-II Family Data Sheet)
http://direct.xilinx.com/bvdocs/publications/ds091.pdf (XC2C32 Data Sheet)

The following link takes you to the CoolRunner-II White Papers. If you are looking at
a printed copy of this document, go to www.xilinx.com and go to the documentation
link.
History
07/04/05 1.1 Update of specifications in Table 1.

R

R
Implementing Keypad Scanners with
CoolRunner-II
XAPP512 (v1.1) May 6, 2005
Summary This application note provides a functional description of Verilog source code for a keypad
scanner. The code is used to target the lowest density, 32-macrocell CoolRunnerTM-II
XC2C32A CPLD device in a CP56 package (6 mm x 6 mm). The keypad accommodated in this
design has 8 rows and 8 columns. The design can easily be scaled to target keypads with more
or less rows/columns. For instance, a keypad with 7 rows and 7 columns would allow the design
to fit in the smallest QFG32 package (5 mm x 5 mm). To obtain the Verilog source code
described in this document, see “Verilog Code,” page 174, for instructions.
Introduction As handheld devices such as cell phones pack more and more features into them, they require
more effective ways of entering data. Most cell phones, for example, use the standard DTMF
style keypad and a multi-tap process to enter alphanumeric data; however, for larger amounts
of data multi-tapping becomes cumbersome. More and more high-end phones are therefore
employing QWERTY keypads that make entering data easier and quicker.
Going from a DTMF to a QWERTY keypad requires more I/O. For instance, a DTMF keypad
might have 4 rows and 3 columns, where a QWERTY keypad might have 8 rows and 8
columns. This can vary depending on the requirements.
Typically, a processor (or ASIC) is used to interface to the keypad’s rows and columns. The
processor scans the rows and monitors the columns for a logic change. When a change occurs,
it indicates that one of the buttons in that column was pressed. By knowing which row was
being scanned, and which column changed state, the processor can deduce which specific
button was pushed. Additional functions such as debounce are also typically employed.
Figure 1 shows how a simple 4 x 4 keypad uses 8 GPIO of a processor.
Figure 1: Simple 4 x 4 Keypad Connected to a Processor Requiring 8 GPIO

XAPP512 (v1.1) May 6, 2005 www.xilinx.com 177

R
Expanding I/O
Expanding I/O Designers faced with accommodating a keypad requiring more I/O might find their existing
processor (or ASIC) does not have enough GPIO ports. One solution is to use a CPLD as an
I/O expander that reduces the I/O requirement of the processor.
Figure 2 shows a CPLD interfacing to the keypad rows/columns on one side, and the
processor’s available GPIO on the other. In this example, an 8 x 8 keypad requires the same
number of processor GPIO ports as the 4 x 4 keypad (actually one less) when a CPLD is used.
Without a CPLD, the processor would require 16 GPIO ports instead of 7.
Figure 2: CPLD Expands I/O and Reduces the Processor’s GPIO
Scanning and Besides reducing the processor’s GPIO requirements, the CPLD also scans the rows and
Encoding monitors the columns for a change in state. When a key is pressed, the CPLD stops scanning
and immediately sends an encoded word out to the processor. The encoded word indicates
which key was pressed.
In the example shown in Figure 2, there are six bits used to represent the encoded word. Six
bits provides 26 or 64 different values each representing a different key. However, one value
needs to be used to represent the state when no keys are pressed. Therefore, only 63 keys can
be represented in this example.
All 64 keys most likely would not be needed in a typical application. If they were, there are many
options with a programmable CPLD. For instance, a CPLD could generate an enable signal to
the processor that would indicate when a key is being pressed (that is, when the encoded value
was valid). This would require one more GPIO on the processor.
The processor is still required to monitor for changes on its GPIO, only it would not have to
deduce which key was pressed since this information is encoded in the six bit word. Debounce
will also be required. This can be performed in the CPLD or the processor. Performing this in
the processor would keep the size of the CPLD to a minimum.
178 www.xilinx.com XAPP512 (v1.1) May 6, 2005

R
CPLD Design Details
CPLD Design Note: The following details describe how the available Verilog reference design is implemented. The
concept and design are relatively simple. Additional functionality can be added depending on specific
Details design requirements.
To scan the keypad rows, a barrel shift register is initialized with all ones except for one bit
preset to a zero. Each bit of the shift register drives a CPLD output pin that is connected to a
row of the keypad. As the shift register is clocked the zero shifts through the barrel shifter and
scans the rows by driving them low one at a time.
The columns are inputs to the CPLD. Each input is pulled up with an internal pull up resistor.
When no keys are pushed, all column inputs to the CPLD are passively pulled up to a logic high
state. All column inputs are AND’d together. A logic one at the output of the AND gate indicates
no keys are pressed. The output of the AND is used as an enable to the shift register.
When a key is pressed, a connection between a row and column is made. The column with the
key being pressed will be driven low by the row associated with that key. The output of the AND
will go low and disable the shift register for how ever long the key is pressed.
At this point the shift register is driving the row of the key being pressed to a low, and the
column of that key is also at a low. Two encoders are used, one for the row bits (outputs of the
shift register), and another for the column inputs. The outputs of the two encoders are grouped
together to form the resulting encoded word that is presented to the processor. Figure 3 shows
a block diagram of these functions.
Figure 3: Block Diagram

R
Implementation and Verification
Implementation The reference design is implemented in Verilog. A Xilinx ISETM software project is zipped up,
and Verification including the Verilog source file, Verilog testbench, and UCF file. If you do not have Xilinx
software, you can obtain ISE WebPACKTM for free from the Xilinx website. WebPACK will give
you all the tools you need to complete any CPLD project.
The UCF file shows how to initialize the barrel shifter with a pattern of ones and a zero. It also
shows how to program the column inputs with internal pull up resistors.
The testbench can be evoked from within Project Navigator, which will automatically run a
custom ModelSim .do file. The .do file will compile the source code, open a waveform window
to view signals, and run the simulation.
The testbench generates a clock for stimulus and also simulates the pressing of buttons by
periodically connecting a row with a column. This is done until all possible combinations of rows
and columns are simulated, and then repeats.
Verilog Code THIRD PARTIES MAY HAVE PATENTS ON THE CODE PROVIDED. BY PROVIDING THIS
XAPP512 - http://www.xilinx.com/bvdocs/appnotes/xapp512__verilog.zip
Conclusion Since the CPLD is reprogrammable, adding a control line, changing the mapping of the
encoded word, or accommodating different keypads is possible with the same device.
Additionally, other “glue” functions can be absorbed into the CPLD, such as voltage translators.
A specific CPLD device (i.e., part number) can be used to accommodate different keypads and
even different applications because it's programmable. This helps boost the volume (lowers
cost), and reduces risk since changes can be made even after it's soldered down.
Coolrunner-II also is designed for low power, making it a good choice for battery powered
applications, such as cell phones, PDAs, and other portable devices. They also have additional
features that augment its low power. Multiple I/O banks can be used for voltage translation,
which is another typical application in devices with a mixture of technologies.

Information Access to all Xilinx Data Sheets, Application Notes, and White Papers
Device Packages
History
05/06/05 1.1 NAND gate references on page 3 changed to AND gates.

Application Note: CoolRunner-II
R
Level Translation Using Xilinx
CoolRunner-II CPLDs
XAPP785 (v1.0) June 22, 2005
Summary As electronic design has advanced over the years, more and more I/O standards have been
created. Since the days when the 5V CMOS and TTL standards were the prevalent standards
with which to design logic circuits, there have been a lot of changes. Today, there are many
voltage standards operating at different voltages with different thresholds. This application note
explains how to use a Xilinx CoolRunnerTM-II CPLD to translate between different voltage
levels.
Introduction A typical electronic system will no longer operate at only one voltage. The most popular
voltages used to interface between components on a board are 3.3V, 2.5V and 1.8V. However,
more frequently, devices need to interface to ’unusual’ voltages.
Since the introduction of the CoolRunner-IIA parts (XC2C32A and XC2C64A), all Xilinx
CoolRunner-II devices have multiple I/O banks. The XC2C32A, XC2C64A, XC2C128, and
XC2C256 have two banks each, and the XC2C384 and XC2C512 have four banks each. This
means that the VCCIO rail (the power supply for the device I/O) is split, enabling I/O in different
banks to be powered at different voltage levels. Each I/O bank can support one VCCIO voltage
at a time. The supported I/O standards for the CoolRunner-II device can be seen in Table 1
below.
Table 1: Supported I/O Standards in CoolRunner-II Family
Board
IOSTANDARD Input(1) TerminationVoltage
Attribute Output VCCIO Input VCCIO VREF VTT
LVCMOS15(2) 1.5 1.5 N/A N/A
HSTL_1(3) 1.5 1.5 0.75 0.75
SSTL2_1(3) 2.5 2.5 1.25 1.25
SSTL3_1(3) 3.3 3.3 1.5 1.5
1. For information on assigning Vref pins, see XAPP399
2. LVCMOS15 requires use of Schmitt-trigger inputs.
3. HSTL_1, SSTL2_1 and SSTL3_1 are supported on XC2C128 and larger
The I/O characteristics of each standard can be found in the device specific CoolRunner-II
Datasheets, for example XC2C128. More information about each of the I/O standards can be
found in XAPP382. For information about interfacing to 5V, see XAPP429.

R
Configuring I/O to Use I/O Standards
Configuring I/O The designer specifies which I/O standard to use at the time of design entry. I/Os can be
to Use I/O configured to operate at different I/O standards in a number of ways.
Standards Default
The default I/O Standard can be set in the process properties for the Fit process in the ISE
software. The use of the default I/O Standard will set all I/O used in the design to the I/O
standard specified. This is useful if all the I/O are powered at the same voltage. However, this
application note is discussing interfacing between different voltages, so another I/O standard
assignment method is required.
PACE
The Xilinx Pinout Area and Constraints Editor (PACE) tool can be used to assign a variety of
constraints, including pin locations, slew rate, Schmitt trigger and I/O standard. The package
diagram distinguishes between I/O banks by using different colors.
The Design Object List then enables you to assign I/O standards to the I/O pins in the design.
If the banking rules are broken, then PACE will issue a message that the I/O standard is not
VCCIO compatible.
UCF
The final method of assigning I/O standards in the software is to enter them directly into the
User Constraint File (UCF). The syntax for entering I/O standard constraints into the UCF is as
follows:
NET "user_net" IOSTANDARD = xx ;
Where xx is one of the permissible values: LVCMOS33, LVCMOS25, LVCMOS18,
LVCMOS15, LVTTL, and for devices of 128 macrocells and above, HSTL_1, SSTL2_1 and
SSTL3_1.
Xilinx recommends the use of the Default assignment in co-operation with PACE to get the
optimum results, since PACE has the design rules check that the UCF entry method lacks.
Using the CPLD In addition to knowing of how to configure the I/O of the CPLD at different voltages, it is also
as a Level necessary to have an understanding of how to use the device as a level shifter. It is possible to
have this device act as a route-through to simply shift, for example, 1.8V inputs to 3.3V outputs.
Shifter This would simply require a logical assignment of the input bus to the output bus, and would
use one pin per input/output, and one product term and one macrocell per output.
Even in the smallest device in the CoolRunner-II family, the XC2C32A, performing this
translation on an 8-bit bus would utilize less than one quarter of the resources. As the input
signals must go through the central interconnect switch, they can be assigned to any output pin
required by user. This makes the CPLD perfect for performing additional functions such as bit-
swapping of the input bus, or changing from little-endian to big-endian format. CoolRunner-II
CPLDs have a very fast TPD (propagation delay), as fast as 3.8 ns in the XC2C32A -4, so very
little delay will be incurred by using a CPLD in this situation. It is also important to note that, due
to the uniform nature of the architecture, all signals going through a similar path in the device
will incur a similar delay and will, therefore, have minimal skew from each other.
While this is a perfectly legitimate use for a CPLD, there are a lot of other resources available
that can be used to perform operations on the incoming data.
Incorporating the Level Shifter into a Common Interface

It is common for devices on a board to operate at different I/O voltages. The information above
explained how to use the CPLD as a simple level shifter, but all too often, the data coming into
the device will need some operation performed upon it. There are many communication

R
Using the CPLD as a Level Shifter
interfaces for use in electronic systems (USB, SPI, I2C), several of which can fit into a Xilinx
CPLD. Figure 1 shows a generic example that builds on the previous example. Here the 1.8V
input bus goes into the device, has a few operations performed on it, such as shifting left or
right, checksum calculation, parallelization, serialization, interrupt handling, and so on, and
emerges from the device at 3.3V.
Vccio1 = 1.8V Vccio2 = 3.3V
CoolRunner-II CPLD
Figure 1: Using CoolRunner-II as a Level Shifter Interface
A few examples of common interfaces can be found in other application notes on the Xilinx
website.
• XAPP341 UARTs in Xilinx CPLDs
• XAPP354 Using Xilinx CPLDs tp Interface to a NAND Flash Memory Device
• XAPP384 Interfacing to DDR SDRAM with Xilinx CoolRunner-II CPLDs
CPLDs Can be Used to Supply Current

An added advantage of using a CPLD in this situation is if the device providing the 1.8V signals
to the CPLD cannot supply sufficient current. The CPLD can be used to supply the current
required. To ascertain how much current the I/O of the CPLD can provide under typical

R
Conclusion
conditions, the I-V plots for the I/O are needed. These can be seen in the device specific
CoolRunner-II datasheets. Figure 2 is taken from the XC2C32A datasheet.
Figure 2: IV Curves for the CoolRunner-II I/O Standards

Powering VCCIO Between Specifications
The CoolRunner-II architecture supports 1.5V, 1.8V, 2.5V and 3.3V I/O. However, 2.85V, 2.8V
and 2.7V are also commonly used I/O voltages in certain applications. Can CoolRunner-II
support 2.85V?
The input buffer and output buffer are the same when using a 2.5V I/O standard (LVCMOS25)
as when using a 3.3V I/O standard (LVCMOS33 or LVTTL). The permissible VCCIO range for
LVCMOS25 is 2.3V to 2.7V, and the permissible VCCIO range for LVCMOS33 is 3.0V to 3.6V.
So, there is a clear gap from 2.7V up to 3.0V that is "out of spec." Due to the linear scaling
nature of the input and output buffers, it is safe to assume that the VIH min and VOH min
specifications for a pseudo-2.85V I/O standard can be interpolated from these specifications.
VIH will be in the region of 1.85V and VOH will be VCCIO minus 0.4V at (maximum) 8 mA loading.
Conclusion Xilinx CoolRunner-II CPLDs are perfectly suited to perform level translation operations on
signals. They offer split VCCIO rails on all devices providing at least two I/O banks. Signals can
enter the device at one voltage and be output from the device at another voltage without
introducing any skew on the signals. This application, which previously required a dedicated IC,
can now be incorporated into the CoolRunner-II, which can also be performing other system
functions.

Information Access to all Xilinx Data Sheets, Application Notes, and White Papers
Device Packages
History

Application Note: CoolRunner-II
R
CoolRunner-II Character LCD Module
Interface
XAPP904 (v1.0) August 22, 2005
Summary CoolRunnerTM-II CPLDs can be used to control dot-matrix liquid crystal display (LCD)
modules. The low-power characteristics of LCD modules make them an ideal complement to
the CoolRunner-II family. These displays typically require 3.3V signals. However, this is not of
concern because CoolRunner-II devices are 3.3V tolerant. Thus, it is possible to achieve ultra-
low power at a 1.8V core voltage while using 3.3V at the I/O.
Introduction Character LCD Module Background

There are many manufacturers of dot matrix LCD modules. However, most of these displays
are similar. They all have on-board controllers and drivers capable of displaying alpha numerics
and a wide variety of other symbols (including Japanese "Katakana" characters). The internal
operation of LCD controller devices is determined by signals sent from a central processing unit
(in this case, a CoolRunner-II CPLD).
These signals include:
1. Register Select (RS)
2. Read/Write (R/W)
3. Data Bus (DB7~DB0)
4. Enable Strobe (E)
Character LCD Instructions

Figure 1 shows the timing requirements for writing data to the LCD (this design does not
perform read operations for the sake of simplicity). Notice that data is written with respect to the
falling edge of the Enable Strobe (E) signal. The CoolRunner-II CPLD is responsible for making
sure that LCD Module timing requirements are met. More specific timing requirements can be
found in the LCD data sheets.
Figures 1 and 3 originated at Seiko, and were found at:
http://www.seiko-usa-ecd.com/lcd/products/char_mods/pdf/instructions.pdf
© 2000-2003, 2005 Xilinx, Inc. All rights reserved. XILINX, the Xilinx logo, and other designated brands included herein are trademarks of Xilinx, Inc.

R
CPLD Implementation
(})
Figure 1: Data Write from CPLD to LCD
CPLD Figure 2 shows a block diagram of an LCD Controller on a CoolRunner-II CPLD.

Implementation
8 8
db
8 8
lcd_db
C0
Data
C
N
T Power_up
R `0' lcd_rw
ready
counter
done
16
ready
lcd_rs
C
N
Main State Machine
T
W R lcd_e
clk
reset
CoolRunner-II CPLD
Figure 2: LCD Controller Block Diagram

R
CPLD Implementation
The LCD Controller implementation is comprised of two state machines - a Power_Up State
Machine, and an LCD Controller Main State Machine. These two blocks are discussed in the
following sections.
Table 1 defines the primary inputs/outputs of this LCD Controller design.
Table 1: Signal Descriptions

Port
Signal Name Description
Specification
Reset input Reset Signal (Active High)
DB[7:0] input 8-bit Data bus.
W input Write strobe (Active High)
Ready output Ready Signal - Asserted by CPLD to signal when
more data can be sent (Active High)
Clk input Clock input (This design assumes 1.8MHz clock)
LCD_RS output LCD Register Select
LCD_RW output LCD Read/Write
LCD_E output LCD Enable Strobe
LCD_DB[7:0] output 8-bit LCD Data Bus
Power-Up State Machine

LCDs require an initialization procedure to be executed each time the module is turned on or
reset. The Power-Up State Machine is designed to automatically take care of this procedure by
sending a sequence of hex codes from the CPLD to the LCD module. Upon completion, the
LCD cursor will be enabled, the display will be cleared and the LCD module will be set for auto-
increment mode. (See Figure 3)
During this sequence, the CPLD waits for 15 ms to allow the LCD to power up, then sends
0x38, 0x06, 0x0E and 0x01. This initialization sequence is automatic, and will also occur upon

R
CPLD Implementation
every power-up or reset. All timing requirements will be met, assuming a 1.8 MHz external
clock frequency.
Figure 3: LCD Module Initialization Sequence
8
Reset Data
15
Counter_Enable Count
Clk Done
Figure 4: Power_Up Module Block Diagram
Figure 4 shows a block diagram of the Power_Up module. This Power_Up module utilizes a
terminal counter to insure that data is held for the appropriate amount of time, as specified in
Figure 3. As shown, the largest wait time required by the LCD is 15 ms (during the Power_ON
sequence). Thus, to simplify the design, data is held for 16 ms in every subsequent block.
Since this design assumes a 560 ns clock period (1.8 MHz), a terminal count value of 30,000
is used. Alter this terminal count if a different clock frequency will be used.
An internal ’Done’ signal is output by this Power_Up module to let the main LCD State Machine
know when the Power_Up sequence has completed.

R
Resource Summary
LCD Controller Main State Machine

After the LCD has been initialized, control is released to the LCD Controller Main State
Machine. The CPLD will drive the ’Ready’ line high in order to signify that the power up state
machine has completed and that it is ready to accept data to be written to the CPLD. Hence, a
CPU, or some other upstream device, sends a data byte corresponding to a specific LCD
character to the CPLD along with a Write strobe. The CPLD will latch the data byte on the
falling edge of the Write strobe, drive the ’Ready’ signal low, and drive the appropriate LCD
signals in order to make the character appear. Input Data will be ignored by the CPLD until the
’Ready’ signal is high again.
Figure 5 shows the complete sequence of events, starting from the power up initialization
process. As can be seen, the CPLD first sends the initialization codes 0x00, 0x38, 0x06, 0x01
followed by 0x80. Immediately after, the ’Ready’ line is asserted, and the CPU begins sending
data on ’DB’ on every edge of the ’W’ line. The CPLD latches the data on every rising edge of
W, and drives the ’LCD_DB’, ’LCD_RW’, ’LCD_RS’ and ’LCD_E’ pins accordingly in order to
make the character appear. The CPU continuously monitors the ’Ready’ line and sends data
only when Ready is high.
Figure 5: Signal Sequence of Events
Table 2: CPLD Resource Use Summary
Resource This design uses a total of only 40 macorcells, allowing it to fit into an XC2C64A device.
Summary ************************* Mapped Resource Summary ********************
Macrocells Product Terms Function Block Registers Pins
Used/Tot Used/Tot Inps Used/Tot Used/Tot Used/Tot
40/64(62%) 64/224(29%) 61/160(38%) 26/64(41%) 23/33(70%)
Additional CoolRunner-II Data Sheets and Application Notes

Information
Conclusion The LCD Interface presented in this application note is simple and straightforward. Additionally,
CoolRunner-II devices are ideal candidates for driving LCDs due to their low cost, low power
and ease of use.

R
Revision History
History

R
Using Xilinx CPLDs to Interface to a
NAND Flash Memory Device
Summary This application note describes the use of a Xilinx CoolRunner™ CPLD to implement a NAND
Flash memory interface. CoolRunner CPLDs are the lowest power CPLD available and the
ideal target device for memory interface applications. The code for this design may be
downloaded from the Xilinx web site, refer to section HDL Code, page 204. This design fits
XCR3032XL CooRunner or XC2C32 CoolRunner-II CPLDs.
Introduction The flash memory market has been rapidly growing over the past several years due in part to
increasing demands of portable and embedded devices. This market is driven by embedded
code storage and bulk data storage applications. Flash technology has been optimized to meet
the needs of these two target applications.
NAND Flash is a sequential access device appropriate for mass storage applications, while
NOR Flash is a random access device appropriate for code storage applications. NAND
technology organizes cells serially to achieve higher densities. This reduces the number of
contacts needed in the memory array. The trade-off between the two technologies is NAND
Flash data must be accessed sequentially compared with NOR Flash which offers fast random
access.
NAND Flash memory offers low cost per bit, high performance, and the highest density non-
volatile memory available. NAND Flash is ideal for applications ranging from MP3 players and
digital cameras to applications requiring mass storage of data, especially when the data is
packetized, or sequentially arranged.
This application note describes the design of a basic NAND Flash interface. The NAND devices
used for testing this interface include the AMD UltraNAND™ Flash and the Samsung NAND
Flash memory.
The AMD UltraNAND flash memory (AM30LV0064D) is a 64 Mbit storage device. This memory
device utilizes a multiplexed command/data/address bus as well as other control signals for
read, erase and program commands. This memory device has an initial page read access time
of 7 μs, with subsequent byte access times of less than 50 ns per byte.
The Samsung K9F4008W0A is a 512K x 8-bit NAND Flash memory device. The command,
data, and address are multiplexed through an 8-bit I/O port. This memory device supports a 32-
byte frame read, with random access times of 15 μs and sequential access times of 120 ns.
NAND Interface The NAND interface described here is implemented in a CoolRunner CPLD. The NAND
interface design can interact with both AMD and Samsung NAND memory devices.
Figure 1 shows the overall system diagram for a single AMD UltraNAND Flash or Samsung
memory device. The CoolRunner CPLD reads the 4 least significant bits in the system address
NOTICE OF DISCLAIMER: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this fea-
ture, application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may
require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warran-
ties or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose.

1-800-255-7778
R
in order to decode the flash interface commands. The interface signals to the Flash device are
asserted by writing to a specific port of the CPLD.
CE#
RE#
ADDR[3:0] I/O[7:0]
WE# AMD UltraNAND
WRITE# (AM30LV0064D)
CoolRunner SE#
READ# or
XPLA3 CPLD ALE
CE# Samsung
CLE (K9F4008W0A)
RESET
WP#
RY/BY# RY/BY#
X354_02_082701
Figure 1: System Block Diagram
The NAND Flash interface signals and functionality is shown in Table 1.
Table 1: UltraNAND Pin Descriptions

Pin Name Function
I/O[7:0] I/O pins used to send commands, address, and data to the
device, and receive data during read operations.
CLE Command Latch Enable. The CLE input controls writing to the
command register. When CLE is high, the command is loaded on
the rising edge of WE#.
ALE Address Latch Enable. The ALE input controls writing to the
address register. When ALE is high, the address is loaded on the
rising edge of WE#. ALE must remain high during the entire
address sequence.
CE# Chip Enable. The CE# input controls the active vs. standby
mode of the device. During a command or address load
sequence, CE# must be low prior to the falling edge of WE#.
RE# Read Enable. The RE# input controls the data and status output
on the I/O lines. The data output is triggered on the falling edge
of RE#.
WE# Write Enable. The WE# input controls the data and command on
the I/O lines during a write sequence. The I/O lines are latched
on the rising edge of the WE# signal.
WP# Write Protect. The WP# input provides protection when
programming or erasing the device. The internal voltage
regulator is reset when WP# is low, preventing any program or
erase operations.
SE# Spare Area Enable. The SE# input controls access to the 16
bytes of spare area on each page. When SE# is not asserted
(high), the spare area for the selected page is not enabled. When
SE# is asserted (low), access to the spare area is enabled.
RY/BY# Ready/Busy Output. The RY/BY# output indicates the operation
status of the device. When RY/BY# is high, the device is ready
for the next operation. When RY/BY# is low, an internal program,
erase, or random read operation is in progress.

1-800-255-7778
R
AMD UltraNAND Memory Device

The AM30LV0064D is organized as 8 kB (+ 256 byte spare area) blocks (1,024 blocks total).
Each block has 16 pages of 512 bytes (+ 16 bytes spare area) or 16,384 pages total. Figure 2
is a block diagram of the AMD UltraNAND device.
RY/BY#
ALE CLE SE# WP#

Y-Decoder
Data Register & S/A
High Voltage Pumps
CE#
X Decoder
RE# State Machine
WE# Memory Array
Data Register & S/A

Y-Decoder
Command Register
Address Register
Status Register
I/O Register & Buffer I/O 7-0
VCC
VCCQ
VSS
X354_03_082701
Figure 2: AMD UltraNAND Block Diagram
Table 2 describes the AMD UltraNAND command set and functionality. The command register
does not occupy any addressable memory location. This register holds the command, along
with any address and data information needed to execute the command. Programming data
into the Flash array is a two step process. The data to be programmed is loaded into the data

1-800-255-7778
R
registers using the "Input Data" command. After the data is loaded, the "Page Program"
command is performed to write data from the data registers to the Flash array.
Table 2: AMD UltraNAND Command Set

Operation Cycle (Hex) Functionality
Read Data 00h or 01h Reads out flash array starting with First Half Page
(00h) or reads out data starting with the Second Half
Page (01h).
Gapless Read 02h Allows reading from multiple pages with only one 7
μs latency occurring on the first page transfer
Read Spare Area 50h Only reads data from the 16 byte spare area in each
page (address locations 512 through 527).
Read ID 90h Read the manufacturer and device ID.
Read Status 70h Checks the device status to determine if the device
is ready, in the write protect mode, erase suspended,
or if the previous program/erase operation
completed without error.
Input Data 80h First command that allows the device to be
programmed. This command loads the data
registers from the I/O lines to program the device.
Page Program 10h Issued after the "Input Data" operation has loaded
the proper data. The command transfers information
from the data registers to the Flash array in 200 μs
or less, and the Flash device will appear busy during
the data transfer operation.
Block Erase 60h & D0h In the first command (60h), two address cycles are
used to input the address of the block to erase. Once
the second command (D0h) is issued, the Flash
device will begin the "Block Erase" operation.
Erase Suspend B0h Only valid during a "Block Erase" command
sequence. On the rising edge of WE#, the erase
operation will be suspended.
Erase Resume D0h Only valid during an "Erase Suspend" command
sequence. On the rising edge of WE#, the Flash
device will resume the "Block Erase" operation.
Reset FFh Used to initialize the Flash device.
Samsung NAND Memory Device

The K9F4008W0A is a 512K x 8-bit NAND Flash memory. A Program operation programs a 32-
byte frame in typically 500 μs and an Erase operation erase a 4 kB block in typically 6 ms. Data
in a frame can be read out at a burst cycle rate of 120 ns/byte. The array organization of the
Samsung device is such that 32 bytes are equal to one accessible frame. A row consists of four
frames (or 128 bytes) and one block consists of 32 rows (or 4 kB). The total size of the device

1-800-255-7778
R
is 128 blocks (or 4 MB). Data is programmed via the Frame Register which holds 32 bytes of
data. Figure 3 is a block diagram of the Samsung K9F4008W0A.
A7 - A18 X-Buffers Latches

& Decoders
4M Bit
NAND Flash ARRAY
A0 - A6 Y-Buffers Latches 32Byte x 4Frames x 4096Rows
& Decoders
Page Register & S/A

Command
Y-Gating
Command
Register I/O Buffers & Latches
CE Control Logic
RE & High Voltage
Generator I/O0
WE Global Buffers
I/O7
CLE ALE WP
X354_04_082701
Figure 3: Samsung Block Diagram
All address and command instructions are multiplexed through the 8 I/O lines. Similar to the
AMD UltraNAND, data is latched on the rising edge of WE# when CE# is low. The address is
latched in when ALE = ’1’ and CLE = ’0’ and the command is latched when ALE = ’0’ and CLE
= ’1’. Table 3 describes the Samsung NAND Flash memory command set.
Table 3: Samsung Command Set

Command Cycle Data Description
Read 00h Device default mode. After the frame address is
changed, 32 bytes of data are transferred to the data
registers in less than 15 μs. Each data byte in the
frame can be read on the high to low transition of the
RE# signal.
Reset FFh Reset operation can abort a read, program, or erase
operation. The device enters the Read mode after a
Reset command.
Frame Program 80h & 10h Frame Program consists of loading the 32 byte Frame
Register and a nonvolatile programming period when
the data is programmed into the appropriate cells.

1-800-255-7778
R
Table 3: Samsung Command Set

Command Cycle Data Description
Block Erase 60h & D0h The Erase operation is done 4K bytes (or 1 block) at
a time. Requires a 2 cycle address load to specify
block address (A18 to A12).
Status Read 70h The device contains a Status Register which may be
read to determine if a program or erase operation is
complete and successful. See the Samsung data
sheet (refer to References, page 205) for a complete
definition of each bit in the Status Register.
Read ID 90h The device contains product identification, which can
be read during a Read ID command. Two read cycles
are required to read the manufacturer code and
device code.
CPLD Design
For more information on the ABEL implementation of the CoolRunner CPLD design, refer to
AMD Application Note # 22363 (see References, page 205). The design described here and
available on the web is implemented in both VHDL and Verilog (see "HDL Code" on page 204
for more information).
The CPLD design decodes system address commands to interface with the AMD UltraNAND
and Samsung Flash memory devices. The CPLD is responsible for the following functions:
• Decode read or write from address bus
• Interpret system address bus commands
• Assert interface signals to UltraNAND Flash device
• Monitor RY/BY# output from Flash memory device
The CPLD is configured to decode address 00h through 0Fh from a base address. The CPLD
logic outputs are determined by the system writing to each port address. The port addresses for
the CPLD are shown in Table 4 with a functional description of each.
Table 4: CPLD Port Address Definition

Port Operation Function
0 Read Data/ID/Status Read information from previous command loaded.
or Write Address/Data Write address (ALE high) or data (ALE low).
1 Command All commands are written through this port with ALE low.
2 Set ALE Set ALE (high) to allow addresses to be written.
3 Clear ALE Clear ALE (low) to allow commands or data to be written.
4 Set SE# Set SE# (low) to allow access to the spare area on each
page.
5 Clear SE# Clear SE# (high) to prevent access to the spare area on
each page.
6 Set WP# Set WP# (low) to prevent program/erase cycles.
7 Clear WP# Clear WP# (high) to allow program/erase cycles.
8 Set CE# Set CE# (low) to enable the UltraNAND device.
9 Clear CE# Clear CE# (high) to disable the UltraNAND device.
A N/A Not used in this design.

1-800-255-7778
R
Table 4: CPLD Port Address Definition

Port Operation Function
B N/A Not used in this design.
C N/A Not used in this design.
D N/A Not used in this design.
E N/A Not used in this design.
F RY/BY# Status Read the state of all RY/BY# pins through this port.
Table 4 is described in more detail in the AMD Application Note #22363 for the design
implementation in ABEL. Refer to References, page 205 for more information.
Figure 4 is a block diagram of the VHDL/Verilog implementation of the NAND interface. All port
signals (shown in Table 4) are decoded from the system address when CE# is asserted.
The ALE_SIG process asserts the ALE signal on a write to PORT2 and clears ALE on a write
to PORT3. The SEN_SIG process asserts the SE# signal upon a write to PORT4 and clears
SE# upon a write to PORT5. The OUTCE_SIG process asserts the OUTCE# signal upon a
write to PORT8 and clears OUTCE# upon a write to PORT9. The WPN_SIG process asserts
the WP# signal upon a write to PORT6 and clears WP# upon a write to PORT7. The
READY_SIG process assigns the RY/BY# signal from the Flash device to the ready output
signal. Otherwise, the ready signal is 3-stated.
RESET
SE_N_INT
SEN_SIG
PORT4
PORT5
WRITE_N
OUTCE_N_INT
OUTCE_SIG
PORT5
PORT9
PORT2
LE_SIG
PORT3
ALE_INT
WP_N_INT
WPN_SIG
PORT5
PORT7
B1
WP_N
ALE
READY
PORT0
READY_SIG
PORT1 PORT1
READ_N OUTCE_N
RY_BYN PORTA
SE_N
B5 CLE
PORT_ADDR[3:0]
PORTB
CE_N
PORTC
COM_LAT_N
PORTE
WE_N
PORTD
RE_N
X354_05_082701
Figure 4: CPLD Block Diagram
The CLE signal is asserted on any access to PORT1. The RE# signal is asserted to the Flash
device when a read is performed on PORT0. The WE# signal is asserted to the Flash device
when a write is performed on PORT0 or PORT1.
CPLD The NAND flash interface was implemented in VHDL and Verilog as described above; and in
Implementation ABEL as described by AMD. Xilinx Project Navigator was used for design compilation, fitting,

1-800-255-7778
R
and simulation in a CoolRunner XPLA3 CPLD. Xilinx Project Navigator, which includes the
ModelTech simulation tool, is available free-of-charge from the Xilinx website at
www.xilinx.com/products/software/webpowered.htm. The design was targeted for a 3.3V, 32
macrocell CoolRunner XPLA3 CPLD (XCR3032XL-VQ44). The design utilization is shown in
Table 5. This utilization was achieved using certain fitting parameters, actual results may vary.
Table 5: NAND Interface XPLA3 32-Macrocell Utilization

Function Blocks 2 2 100%
I/O Pins 32 21 65.63%
Design Verification of the NAND interface was performed using the Xilinx WebPACK Project Navigator
Verification VHDL output timing model. The timing model was imported and compiled by Model Technology
ModelSim. A test bench was utilized to instantiate the memory device (AMD UltraNAND or
Samsung Flash) and the CPLD interface design as shown in Figure 5. The AMD UltraNAND
and Samsung devices were instantiated using Denali Memory Maker.
NAND_FLASH_TB
FAIL_FLAG
I/O[7:0]
PORT_ADDR[3:0]
CE_N
WRITE_N
RE_N
READ_N
NAND_INTERFACE WE_N AM30LV0064D or
RESET
SE_N K9F4008W0A
CPLD_CEN XPLA3 Flash
Interface ALE Denali Memory
COM_LAT_N
CLE Model
WP_N
RY_BYN
X354_06_082701
Figure 5: Test Bench Diagram
Figure 5 illustrates the operational flow used to test the Denali memory model. Figure 6
describes the test flow for the AMD UltraNAND device. The test flow for the Samsung Flash
memory model was modified slightly to match Samsung command cycles.

1-800-255-7778
R
START
Enable Flash Device: Assert OUTCE# (low) Issue a "Read Status" Command:
Write 00h to PORTADDR8 Write 70h to PORTADDR1
Issue Command: Clear ALE (low) Read Device Status:

Write 00h to PORTADDR3 Read from PORTADDR0
Issue "Read First Half Page" Command:

Write 00h to PORTADDR0 Device No
Ready?
Yes
Enable Spare Area: Assert SE# (low)
Write 00h to PORTADDR4
Protect Flash Device: Set WP# (low)
Allow Flash Program: Clear WP# (high)

Read Device Status:
Read from PORTADDR0
Issue "Input Data" Command:

Program No
Operation Return Program
Passed? Failed
Write Address: Set ALE (high)
Yes
Return Program
Load Page Address: Successful
Write ADDR to PORTADDR0
Write Data to Flash Buffer:

Write DATA to PORTADDR0
Flash No
Buffer
Full?
Yes
Issue a "Page Program" Command:

X354_07_082701
Figure 6: Memory Operational Test Flow

1-800-255-7778
R
Denali Memory Maker

The Denali Memory Maker tool is used to simulate the AMD UltraNAND and Samsung devices.
The Denali tool allows a VHDL or Verilog model to be instantiated in a test bench environment.
In this simulation, Model Technology ModelSim is the target simulator. For a given memory
device, a SOMA file (Specification Of Memory Architecture) represents unique timing, features,
and functionality. The SOMA file is then imported to the Denali MemMaker tool. The SOMA file
can be edited to meet the design signal names and timing requirements. Figure 7 illustrates
how to bring a SOMA file into the MemMaker tool.
Figure 7: Opening a SOMA File in MemMaker
Figure 8 illustrates how to change any signal name requirements in the MemMaker tool.
Figure 8: MemMaker Functional View
Once all signal name and timing requirements have been specified, the VHDL or Verilog
source code can be generated. To generate VHDL source code, select Options | Simulation

1-800-255-7778
R
Environment | VHDL | Model Technology ModelSim (Windows). The VHDL code can then be
saved for use in a test environment as shown in Figure 9.
Figure 9: MemMaker Source Code View
ModelSim Implementation
Note:
Please refer to XAPP338: Using Xilinx WebPack and ModelTech ModelSim Xilinx Edition as a guide
to using ModelSim with Project Navigator. The ModelSim Quick Start demo provides a good first step
for getting familiar with ModelSim.
Model Technology ModelSim was the target simulator in this design. The test bench created for
the CPLD design generates the necessary system address cycles. A separate test bench
environment was used to test the AMD UltraNAND device and the Samsung Flash memory.
This is due to the data buffer size during a program cycle and differences in command codes.
The Denali MemMaker model is loaded in ModelSim as illustrated by the ModelSim script.
vcom -reportprogress 300 -work work{../amd_flash_tb.vhd}
# Model Technology ModelSim XE vcom 5.3d Compiler 2000.03 Mar 30 2000
# -- Loading package standard
# -- Loading package std_logic_1164
# -- Loading package numeric_std
# -- Loading package pkg_convert
# -- Compiling entity amd_flash_tb
# -- Compiling architecture behavior of amd_flash_tb
# -- Loading entity am30lv0064d
# -- Loading package pxa_pkg
# -- Loading entity nand_int
vsim work.amd_flash_tb

1-800-255-7778
R
# vsim work.amd_flash_tb
# Loading C:/Modeltech_xe/win32xoem/../std.standard
# Loading C:/Modeltech_xe/win32xoem/../ieee.std_logic_1164(body)
# Loading C:/Modeltech_xe/win32xoem/../ieee.numeric_std(body)
# Loading work.pkg_convert(body)
# Loading work.pxa_pkg
# Loading work.amd_flash_tb(behavior)
# Loading work.am30lv0064d(behavior)
# Loading C:\Denali\denali.dll
# *Denali* History enabled for Denali Memory Modeler.
# *Denali* Debug information will also be saved.
# *Denali* Trace function enabled for Denali Memory Modeler.
# *Denali* Denali Memory Model Version 2.900-0005
# *Denali* Copyright (c) Denali Software, Inc., 1996-2001, All Rights
Reserved.
# *Denali* Class: flash_nand Instance: "/den_model" Size: 8192Kx8
# *Denali* Class: internal Instance: "/den_model(spare)" Size: 256Kx8
# Loading work.nand_int(structure)
# Loading work.pxa_bufif2(behavioral)
AMD UltraNAND Flash Memory

The test bench for the AMD UltraNAND Flash memory executes the following commands:
"Page Program", "Read Status", "Read First Half Page", and "Input Data" as described in
Figure 6. In executing these commands, the test bench fills a 528 byte buffer and programs the
target page in the UltraNAND device. The status of the operations are checked through the
"Read Status" operation.

1-800-255-7778
R
Figure 10 illustrates loading the page address to the UltraNAND. Notice the ALE signal is high
and WE# is asserted for each portion of the address write.
Figure 10: Memory Address Load
Figure 11 illustrates the completion of the "Page Program" command. Notice the RY/BY#
signal is asserted, representing that the flash device is busy with an operation. After the "Page
Program" command is sent to the flash, a "Read Status" command is sent. The "Read Status"
command is used to read the device status. When I/O6 is equal to ’1’, the device is ready for the
next command. To check if an operation is successful, reading I/O0 will determine the pass/fail
status. When I/O0 is equal to ’0’, the operation passed and when equal to ’1’, the operation

1-800-255-7778
R
failed. Notice where the simulation is highlighted in Figure 11, the program operation was
successful.
Figure 11: Program Status: "Ready"
Samsung Flash Memory

Testing the NAND interface with the Samsung K9F4008W0A model was performed similar to
the AMD UltraNAND device. The following commands were executed with the Denali model (in
ModelSim) with the test bench provided: "Frame Program" and "Status Read". To program a
frame, the Frame Register must be loaded with data prior to executing the "Frame Program"
command. The test bench provided loads the Frame Register with 32 bytes of data. The status
of the device is checked with the "Status Read" command.
HDL Code THIRD PARTIES MAY HAVE PATENTS ON THE CODE PROVIDED. BY PROVIDING THIS

1-800-255-7778
R
MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR

PURPOSE, THE ADEQUACY OF THE IMPLEMENTATION, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY OR REPRESENTATION THAT THE IMPLEMENTATION IS FREE
FROM CLAIMS OF ANY THIRD PARTY. FURTHERMORE, XILINX IS PROVIDING THIS
ABEL - ftp://ftp.xilinx.com/pub/applications/refdes/xapp354_abel.zip
VHDL - ftp://ftp.xilinx.com/pub/applications/refdes/xapp354_vhdl.zip
Verilog - ftp://ftp.xilinx.com/pub/applications/refdes/xapp354_verilog.zip
Conclusion Xilinx CoolRunner XPLA3 CPLDs are the perfect target device for interfacing with system
memory devices. This NAND Flash interface can be modified to support multiple memory
banks and suit any application requirements. CoolRunner CPLDs are ideal for any memory
interface needs in portable and handheld devices. CoolRunner CPLDs are low power and easy
to design with using the WebPOWERED software tools.
References The web sites shown here are valid as of the publication date of this note.
1. Samsung Flash Memory Devices
(http://samsungelectronics.com/semiconductors/Flash/Flash.htm)
2. Denali Software, Inc. (http://www.denalisoft.com/)
3. eMemory (http://www.ememory.com/)
History
09/30/02 1.1 Minor changes.

1-800-255-7778
R

1-800-255-7778
R
Cell Phone Security Demoboard
On The Fly Reconfiguration Technique
XAPP430 (v1.0) July 8, 2003
Summary This document describes the operation of the cell phone demo board, and provides a simple
example of OTF operability of CoolRunner™-II CPLDs.
Introduction This demo board was created specifically to demonstrate the unique ability of the CoolRunner-
II device's capability of performing On The Fly (OTF) operations. This particular application
illustrates a cell phone that utilizes a SIM card identification system.
In some parts of the world, cell phones are mated with SIM cards for operation. The SIM card
contains the account information for the user. A user may insert their card into any phone to
make a call. While this allows for a high degree of flexibility in terms of ease of hardware
interchangeability, it also opens the cell phone up to a high risk in terms of theft. Unfortunately,
an intelligent, resourceful and dedicated thief typically is successful. However, if the cost of
stealing and modifying the phone is increased such that it is more expensive than just
purchasing a phone outright, the economics of the theft should result in a reduction of this
particular crime.
This demo board is not meant to be a solution to cell phone theft. It is a proof of concept to
illustrate to engineers how the advanced features of the CoolRunner-II CPLDs might assist in
cell phone security. Obviously additional techniques would need to be used in conjunction with
this demo, such as package selection (ball grid), mounting techniques, PCB layout (such as
burying JTAG lines), or even "chip on board" technology. The cell phone security issue is a
complex one, and this demo illustrates how Xilinx CPLDs can add some margin of flexibility to
the solution.
Demonstration Important: Read all instructions carefully on the following pages before use in order to avoid
Overview damaging the cell phone.
The demo board comes with two small 'SIM' cards that can be inserted into the reverse side of
the 'phone'.
1) Program the CPLD using Impact and a download cable.
2) Insert one of the SIM cards.
3) The front display will either show a circular 'chasing' pattern, or will scroll out CodE? The
chasing pattern is indicative of the normal operation of the phone. This is just a simple 'I am
alive' pattern, indicating that the SIM card that is in the phone is mated to the phone.
4) If the front display shows CodE? Enter in the user code, which is 5,7,9,3. It will ask for the
code again. Enter in 5,7,9,3. This will program the onboard EE to accept the new SIM card.
The phone should now show the chasing pattern on the LCD.
5) Once the phone has been reprogrammed to accept the new SIM, put in the other SIM, so
that the CodE? Starts again. Enter in a four digit code that is not the master code. Enter this
code in again. The display should turn off. At this point the CPLD has erased itself and the
XAPP430 (v1.0) July 8, 2003 www.xilinx.com 207

1-800-255-7778
R
phone is useless. Attach the phone to the Impact tool, and perform a 'Blank Check' to illus-
trate that the phone is completely dead.
6) If two dissimilar codes are entered, such as 2345, and then 2346, the phone will keep
requesting CodE? Until two matching codes are entered. It will then either accept the new
SIM (if the codes were both 5,7,9,3) or erase the CPLD if the codes were something else.
Setup Batteries
The phone runs on two lithium coin cell batteries. Any 20mm 3V cell will work. I have run about
30 demos so far on one set of batteries, and they are still working fine, but keep some spares
on hand, as the lithium cells do droop fairly quickly. Important! The phone does not have
reverse polarity protection. Make sure that the batteries are stacked so that the + side of the
batteries are 'up'. Refer to Figure 1 for an illustration.
Figure 1: Coin Cell Holder
On / Off:
Turning on power is accomplished by moving the jumper next to the battery to the lower two
pins. The upper two pins provide an 'off' position jumper holder. This below picture indicates
the phone is in the 'off' position. Refer to Figure 2.
208 www.xilinx.com XAPP430 (v1.0) July 8, 2003

1-800-255-7778
R
Figure 2: Power Jumper
JTAG Cable:
The board is not marked for the JTAG cable. The header on the board is in the order of the
flying lead cable that is provided with the Xilinx download cables. In order from the top of the
phone: VCC, GND, TCK, TDO, TDI, TMS. See the below picture, Figure 3, for details.
Figure 3: JTAG Cable connections
Caution
The mounting of the board to the faceplate is fragile. When removing the leads from the board,
make sure that you hold onto the PCB and not the faceplate when disconnecting the cable.
Refer to Figure 4.

1-800-255-7778
R
Figure 4: Care When Disconnecting JTAG
Insert Sim Card:

The SIM card slides in from below the phone into the socket. Copper side down. Use extreme
care when inserting the card! This is not the normal operating mode of this type of socket, and
it may be damaged easily. When inserting the card, make an attempt to keep the card going in
'square' with the socket, and do not over insert. Refer to the below pictures for additional detail.
Figure 5: SIM Card Insertion

1-800-255-7778
R
Operation: Initial Operation

A mated SIM card inserted into a programmed phone will result in a 'chasing' pattern on the
LCD. ’Mated’ means that the phone has been programmed to accept that particular SIM card.
The demo comes with two independent cards with unique addresses. The chasing pattern
indicates that the phone is in its normal operating condition. Refer to Figure 6
Figure 6: Initial ’Chasing’ Pattern
A foreign (non-mated) SIM card will result in the phone requesting a code and then the
confirmation of that code to be entered as shown in Figure 7.
Figure 7: Invalid SIM Requires User Code
Enter User Code

Entering in the appropriate code (5,7,9,3) and then a confirmation of that code will result in the
new SIM card being mated to the phone.

1-800-255-7778
R
Figure 8: Entering User Code
Miscellaneous Details
The only buttons that have impact on the operation of the phone are the number keys and the
* buttons. The asterisk is a system reset button and may be pushed if the phone exhibits
unusual behavior.
Do not push in any of the other buttons as it may result in the rubber keypad becoming
dislodged.
Always put the power jumper in the 'off' position when not being used.
Design Demonstration State Diagram

Information This demonstration utilizes a few simple state machines that can be represented by a top level
diagram as seen in Figure 9.
Phone operable
Perform Scroll
Y N
Phone operable
SIM Match?
Perform Scroll
Y N
Accept New Perform Self
Code Match?
SIM Erase
X_09_062603
Figure 9: Demonstration State Machine

1-800-255-7778
R
The phone idles in a small loop that operates the display in a chasing pattern. Once every loop
cycle, it accesses the SIM card address and compares it to an onboard EE memory device to
ensure that the correct card is inserted. As long as the phone recognizes the card, it stays in
this normal operation loop.
If the card is not recognized, the phone breaks from the idle loop and queries the user with a
user code request. The phone reads the keyboard for 4 key presses, and stores this value. It
then queries for a confirmation of the user code, and compares it to the first 4 digits. If the user
codes match, then the entered user code is compared against the known user code stored in
memory. If the user codes mismatch, then the user is asked to re-enter the user codes again.
Upon receipt of two matching user codes, the phone compares this value to an internal stored
user code value. If the user codes match the internal value, the new SIM card is programmed
into EE and the phone enters the normal operation idle loop.
If the user codes do not match the master user code, then the phone enters into a state
machine that performs an OTF erase of the CPLD.
OTF Erase Capability

The erase capability of the CPLD is facilitated through the capability of the CPLD to do On The
Fly (OTF ) operations. This means that the CPLD can have its non-volatile memory
reprogrammed while it is fully functional with a different pattern. This is done by issuing an
’Enable OTF’ command early in the JTAG sequence.
The erase algorithm itself is very easy to implement. In order to do any JTAG operation, TDI
and TMS are assigned and then a rising edge on TCK is given. A single thread state machine
was implemented to step through the different TDI / TMS pairs and present a TCK at the
appropriate time. Additionally, at certain points during the program / erase operations, a delay
is required for cell discharge and erase burn time. The state machine also accesses a timer for
delay at the needed times.
Refer to Figure 1 for detailed instructions on OTF Erase.
Table 1: OTF ERase JTAG Sequence

Step Transition Programmer
Conditions TAP State Event Description Action
0 TMS = 1 Test-Logic/Reset Begin Begin
Loop 0 TMS = 1 Test-Logic/Reset Ensure device in Test Loop 5 times
TCK = rise Logic Reset State
1 TMS = 0 Run-Test/Idle
TCK = rise
2 TMS = 1 Select DR-Scan
TCK = rise
3 TMS = 1 Select IR Scan
TCK = rise
4 TMS = 0 Capture IR
TCK = rise
5 TMS = 0 Shift IR
TCK = rise
Loop1 TMS = 0 Shift IR Shift in Instruction Bits TDI = 0010011
TCK = rise (0-6) (Enable OTF)

1-800-255-7778
R
Table 1: OTF ERase JTAG Sequence (Continued)

Step Transition Programmer
Conditions TAP State Event Description Action
6 TMS = 1 Exit1-IR Shift in Instruction Bit 7 TDI = 1
TCK = rise Enable_OTF
(MSB)
7 TMS = 1 Update-IR Load the Instruction
TCK = rise Register, Set enable flip
flop
TCK = rise
9 TMS = 1 Select IR-Scan
TCK = rise
10 TMS = 0 Capture-IR
TCK = rise
11 TMS = 0 Shift-IR
TCK = rise
Loop2 TMS = 0 Shift-IR Shift in Instruction Bits TDI = 1011011
TCK = rise (0-6) (Erase)
12 TMS = 1 Exit1-IR Shift in Instruction Bit 7 TDI = 1
TCK = rise
Erase (MSB)
13 TMS = 0 Update-IR Load the instruction
TCK = rise Register
14 TMS = 0 Run-Test Idle Execute: Erase the Loop here for
TCK = rise Device 100ms
TCK = rise
16 TMS = 1 Select IR-Scan
TCK = rise
17 TMS = 0 Capture-IR
TCK = rise
18 TMS = 0 Shift-IR
TCK = rise
Conclusion This demoboard provides an illustration of the power of OTF operations by applying simple
OTF reconfiguration techniques in a Cell Phone security demonstration. Requiring only 27
macrocells to implement the self erase algorithm portion of the design, this function will fit into
any Xilinx CoolRunner-II CPLD
History
07/08/03 1.0 Initial Xilinx release

1-800-255-7778
R
Using CoolRunner-II with OMAP, XScale,
i.MX & Other Chipsets
XAPP905 (v1.0) August 25, 2005
Introduction Getting it Right Every Time

Consumer electronics product designs, such as cell phone handsets and MP3 players, typically
are very high volume products. To that end, most product designers choose ASIC or ASSP
methodologies to pack the greatest functionality into tiny, portable packages. This “hits the
mark” for dense functionality, and usually has acceptable power consumption. But the
consumer world is rapidly changing, so features envisioned at one point in time become quickly
obsolete, as competitors must deliver differentiated solutions to seek greater market success.
The term cutthroat is frequently used to describe this level of competition! Mistakes are not
tolerated, and mistakes are expensive. Choosing the correct ASSP, or designing an ASIC
correctly every time is nearly impossible. Mitigating these circumstances is crucial to sustaining
market share, and that is where CoolRunner™-II CPLDs enter the picture.
CoolRunner-II CPLDs are the leading, low power, low price programmable solution for digital
consumer designs today.
This discussion will show you ways to expand beyond the limitations of today’s ASIC/ASSP
solutions, with simple, cost effective, low power programmable logic using CoolRunner-II
CPLDs. As well, we will show solutions to some of the problems mentioned here, with links to
application notes that give in-depth details.
Level Interfacing two chips of different voltage standards is a common problem. Every type of
Translation memory is not made at every voltage standard, and microprocessors are offered at many
voltages. Matching standards can be as simple as introducing level translators, but they are
expensive and take more area than might be desired. Using a CPLD is a better solution, and
offers substantially greater flexibility. All Xilinx CoolRunner-II CPLDs are capable of translating
between two voltages, and some can handle as many as four.
CoolRunner-II CPLD I/O banks easily translate between voltages ranging from 1.5 to 3.6V, in a
single chip. But, this totally disregards the programmability of the devices. You get the
translation as part of the whole package, which means you get a bundle of logic, flip flops,
power reduction resources, and I/O buffers frequently priced below level translator chips!
XAPP785 explains the details on how you can take advantage of this powerful feature, to
expand the capabilities of your OMAP, XScale or i.MX designs.
VCC1 VCC2
Bank1
Bank2
TI Fabric
OMAP
CoolRunner-II CPLD
Figure 1: CoolRunner-II Level Translation of TI OMAP Signals

R
Pin Expansion
Pin Expansion High pin count ASICs are more expensive than low pin count ASICs, in general. If your logic
needs dictate a low capacity, but your I/O requirements dictate a high capacity, you may be
paying for logic you will never use, to gain the pins. One solution to this is adding a
CoolRunner-II CPLD to operate as a “pin expander”. The basic idea is to identify GPIO pins that
typically operate at a slow speed. Then, rather than assign ASIC pins to them, attach
CoolRunner-II CPLD pins to the slow moving GPIO signals, serialize the signals and import
them to the ASIC on fewer net pins.
Serializing/deserializing is done through simple, efficient shifting, and can drop the pin counts
dramatically on expensive ASICs. XAPP799 shows how to do this through an I2C port, but
other methods can be used.
As an alternate viewpoint, OMAP, XScale and i.MX processors provide specific pin mixes to
support the applications their vendors deem appropriate. This doesn’t mean that you must
agree, as a designer. CoolRunner-II pin expansion permits you to create your own GPIO pins,
of assorted voltages and additional capabilities (pulsing, PWM, individually 3-stated).
Increasing the effectiveness of your solution is our goal.
INTEL
Logic
PXA 850 Fabric
XScale
CoolRunner-II CPLD
Figure 2: CoolRunner-II Pin Expansion of XScale Processor
Pin Swizzling CPLDs offer the ability to rearrange your pinouts when PCB layout errors occur. This valuable
quality is key to keeping you on schedule and within financial and power budgets.
Correcting misconnections on a board, without having to re-spin the PCB can shave weeks to
months out of product schedules. CoolRunner-II CPLDs are built from powerful logic blocks
using Programmable Logic Arrays, that can reassign pin logic “at will.” You will be amazed at
how well these devices retain pinouts through multiple edits, yet permit re-assigning a design
onto different pins as needed. The CoolRunner-II Family data sheet explains the architecture
and points you to application notes that give all the detail you will need to understand the value
of PLAs.
Power Control Quick power up is one of the strengths of CPLDs. Containing their own configuration cells
permits CoolRunner-II CPLDs to power up and direct the activities of other chips, as they
subsequently arise. This includes some power regulators, which may be sequenced by the
Coolrunner-II CPLDs, as well as other controlling signals that need to be well defined early in
board operation. XAPP436 describes some of these capabilities.
Power XScale, OMAP and i.MX based chipsets all include some version of the ARM microprocessor.
Reduction This is not a surprise. Advanced RISC Machines started early with developing low power
methods to operate microprocessors, and subsequently, the licensing vendors have all added
their own methods to further reduce processor power. Typical power reduction operations are:
clock gating, voltage throttling and on board memory management to reduce transfers within
the device. These are sometimes referred to as run, wait, doze, sleep, hibernate, and so on.
Also, operating systems like Symbian have added “power awareness” to the mix, so that

R
Logic Consolidation
unused resources can be parked in the lowest power mode possible for the current tasks being
executed. This all works well and lowers processor power. However, lowering power in the rest
of the system exceeds the scope of these methods. Enter CoolRunner-II CPLDs.
CoolRunner-II CPLDs are designed to be inherently low power parts. That is important, but
alone is not enough. CoolRunner-II special features also can be used to lower the power in
other devices. Using clock dividers and Xilinx’s patented DataGATETM technology can reduce
power in many (if not all) of the chips on your design. XAPP378 shows how to do this, and
WP227 shows just how much power you can save with DataGATE. Blocking power to other
chips can also reduce electromagnetic fields being propagated on your board and emanating
from your system. This powerful signal blocking technique can pay off in many ways!
EPROM SRAM
i.MX
Processor CoolRunner-II DRAM
I/O
DataGATE Blocking
Figure 3: DataGATE Blocking Extraneous Switching to Various Devices
Logic Having three, two input AND gates, two three input OR gates and a Schmitt buffer package on
Consolidation your board can burden your bill of materials (BOM), eat away at your power and cost budgets,
and lower your reliability. Collecting all that stray logic into a consolidated, low power
CoolRunner-II not only solves these problems, but stores additional unused logic right there, on
your board – ready to use with future improvements/edits. WP214 shows what you can expect
from collecting logic gates/flip flops into CoolRunner-II CPLDs. Table 1 summarizes the “burn
rate” for logic.
Table 1: Macrocell “Burn Rate” for Common TTL Functions

Function Macrocells P-terms Flip-Flops
Shift register (simple) 1 per bit 1 per bit 1 per bit
Counter (simple) 1 per bit 1 per bit 1 per bit
2:1 Mux 1 2 0
4:1 Mux 1 4 0
8:1 Mux 1 8 0
8 bit loadable shifter 8 16 8
8 bit loadable/SL/SR shifter 8 24 8
8 bit loadable counter 8 16 8
8 bit load/up/dn counter 8 24 8

R

Full Adder / bit 2 7 0/1 (optional)
2:4 Decoder 4 4 0
3:8 Decoder 8 8 0
4:16 Decoder 16 16 0
8 bit Equality Comparator 1 16 0
And/Nand gate (1-40 inputs) 1 1 0
Or/Nor gate (1-40 inputs) 1 11 0
Ex-or/Ex-nor (2-3 inputs) 1 2-3 0
Level translator (per bit) 1 1 0

Information
Conclusion - CoolRunner-II CPLDs are quickly becoming the standard for low power, low cost, high volume,
The Future handheld consumer products. This application note has focused on how these powerful
products can make life easier when building systems with OMAP, XScale and i.MX processors,
but CoolRunner-II works just as well with many other processors, to add functionality, save
power and get products to market fast.
History

R
Connecting Intel PXA27x Processors to
Hard-Disk Drives with a CoolRunner-II
XAPP914 (v1.0) January 15, 2006 CPLD
Summary With the increasing functionality of modern handheld devices, greater storage capacity
requirements become very important. The Intel PXA27x Processor Family is very popular and
is used in many high end cell phones and PDAs. In order to support the higher storage capacity
associated with hard-disk drives (HDD), Intel published the application note, Connecting the
Intel PXA27x Processor Family to a Hard-Disk Drive via the VLIO Memory Interface.
The Variable Latency I/O (VLIO) interface solution only requires a small number of additional
components and produces low-cost and efficient Direct Memory Access (DMA) performance.
The Xilinx CoolRunner-IITM CPLD is the ideal solution to bridge the Intel processor to an HDD
without the need of other components.
Introduction The Intel application note provides detailed suggestions for connecting a CompactFlash, true
IDE mode, parallel ATA, HDD to a PXA27x processor using a VLIO memory interface.
Configurations using Programmed I/O (PIO) and flow-through DMA are presented. The HDD in
this application note is assumed to be using 3.3V logic. The PXA27x processor is assumed to
be running a 1.8V memory bus, so level shifting is used to buffer logic to and from the HDD
interface logic.
With the introduction of the XC2C32A and XC2C64A CPLDs, the Xilinx CoolRunner-II Family
becomes the ideal solution to address the need of the level shifting for this application. The
XC2C32A, XC2C64A, XC2C128, and XC2C256 CPLD devices have two banks each, and the
XC2C384 and XC2C512 devices have four banks each. This means that the VCCIO can be
powered at 3.3V on one bank to interface to the HDD, and at 1.8V on the other bank to interface
to PXA27x processor. The supported I/O standards for the CoolRunner-II device can be seen
in Table 1 below. More information about level translation using Xilinx CoolRunner-II CPLDs
can be found in XAPP785.
Table 1: Supported I/O Standards in CoolRunner-II Family

IOSTANDARD Output Input Input(1) Board Termination Voltage
Attribute VCCIO VCCIO VREF (VTT)
LVCMOS15(2) 1.5 1.5 N/A N/A
HSTL_1(2)(3) 1.5 1.5 0.75 0.75
SSTL2_1(2)(3) 2.5 2.5 1.25 1.25
SSTL3_1(2)(3) 3.3 3.3 1.5 1.5
1. Input VREF details given in individual data sheets.
2. Requires the use of Schmitt-trigger inputs.
3. HSTL_1, SSTL2_1, and SSTL3_1 on devices of 128 macrocells and above.
NOTICE OF DISCLAIMER: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this
feature, application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you
may require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any
warranties or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose.

R
PXA27x
PXA27x Mapping Intel PXA27x Processors to True IDE CompactFlash Interfaces

Figure 1 shows a block diagram of a CompactFlash connection to the PXA27x processor VLIO
interface in true IDE PIO mode. This diagram describes the mapping of the CompactFlash true
IDE signals to the PXA27x processor.
CompactFlash
PXA27x CoolRunner-II XC2C64A Connector
#ATASEL GND
#CSEL
D[15..0] Level D[15..0] GND
Shifter A[10..3]
VCC HDD_VCC
A[3..1] A[2..0]
#WE
nOE #IORD
nPWE #IOWR
Level #DMACK
Shifter
A4 Glue DMARQ
#CS0 #IOCS16
Logic
nCS5 #CD2
#CD1
Glue #VS1
Logic #CS1
A5 #VS2
#DASP
nRESET_OUT #RESET #PDIAG
IORDY
GPIOx INTRQ
Figure 1: True IDE PIO Block Diagram
This design uses two address lines and nCS5 of the PXA27x to get the two chip select signals
the HDD needs. Table 2 shows the relationship of the PXA27x processor nCS5 memory
mapping to the HDD CS0# and CS1# signals.
Table 2: Memory Mapping
nCS5 A4 A5 CS0# CS1# R/W Field Address
0 0 1 0 1 Task File Register 0x1400_0020
0 1 0 1 0 CTL Register 0x1400_0010
0 1 1 1 1 DMA 0x1400_0030
1 x x 1 1 N/A N/A
Timing Considerations
The PXA27x VLIO interface is designed to interface to high speed memory devices, such as
Flash and SRAM. This capability requires attention to timing parameters. Analysis of HDD
vendor devices shows that the “CS Valid to IIORD/IOWR” is close to the specified limits of the
PXA27x processor. It may be necessary to perform timing analysis and use glue logic to adjust
the timing to meet the HDD timing requirements.
As you can see from Figure 1, the glue logic for memory mapping and level shifting functions
can be easily integrated into a single XC2C64A CPLD. And the CoolRunner-II family’s

R
Conclusion
programmable logic array can be flexibly designed and programmed to meet the timing
requirements for this application.
Conclusion Xilinx CoolRunner-II CPLDs are the ideal solution for applications requiring level translation.
This application connects Intel’s PXA27x processor to a hard disk drive. integrating level
shifting and glue logic for memory mapping into a single XC2C64A CPLD.
History

R
Revision History

R
A Low-Power IDE Controller Design
Using a CoolRunner-II CPLD
XAPP939 (v1.0) May 30, 2006
Summary This document details a Verilog implementation of an IDE controller using a Xilinx
CoolRunner-II CPLD. CoolRunner-II CPLDs are the lowest power CPLDs available, making
them the perfect target device for handheld applications. This design fits in an XC2C256-
CP132 CPLD.
Introduction IDE controllers are asynchronous parallel data links that are standard across many CPUs. This
IDE controller design has been implemented on a CoolRunner-II CPLD. A high level block
diagram is shown in Figure 3. The CPU chosen for this IDE controller implementation is the
Intel PXA270 CPU, but the code can be easily modified for other CPUs by changing the CPU
interface block in the IDE controller.
IDE Background
There are two modes of operation of an IDE controller, PIO mode and DMA mode. Data is
transferred in blocks using either PIO or DMA protocols. For more details and timing diagrams,
please refer to the ATA/ATAPI5 specification document.
PIO data transfers occur when the BSY bit is cleared to zero and the DRQ bit is set to one in the
device status register of an IDE device. These transfers are usually 16-bit. Data is transferred
in blocks of one or more bytes known as a DRQ blocks. Chip select signals CS0- and CS1- are
used to select the device command or control block registers. Device address signals DA [2:0]
access the device registers or data port. DIOR- or DIOW- determine the direction of the data
transfer. Read Cycle and Write Cycle waveforms for the PIO mode are shown in Figure 1.
Figure 1: Read Cycle and Write Cycle Waveforms for the PIO Mode
DMA transfers are always 16-bit. Each assertion of DMACK- by the host defines a DMA data
burst. A DMA data burst is two or more bytes. The DMARQ and DMACK- signals are used to
© 2006 Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and further disclaimers are as listed at http://www.xilinx.com/legal.htm. PowerPC is
a trademark of IBM Inc. All other trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice.

R
CoolRunner-II IDE Controller Implementation
signify when a multi-word DMA transfer is to be executed. The DMARQ and DMACK- signals
are also used to control the data flow of a multi-word DMA data transfer.
When a device is ready to transfer data associated with a multi-word DMA transfer, the device
shall assert DMARQ. The host shall then respond by negating CS0- and CS1-, asserting
DMACK-, and beginning the data transfer by asserting, then negating, DIOW- or DIOR- for
each word transferred. CS0- and CS1- shall remain negated as long as DMACK- is asserted.
The host shall not assert DMACK- until the device has asserted DMARQ. The host shall initiate
DMA read or write cycles only when both DMARQ and DMACK- are asserted. Having asserted
DMARQ and DMACK-, these signals shall remain asserted until at least one word of data has
been transferred.
The device may pause the transfer for flow control purposes by negating DMARQ. The host
shall negate DMACK- in response to the negation of DMARQ. The device may then reassert
DMARQ to continue the data transfer when the device is ready to transfer more data and
DMACK- has been negated by the host.
The host may pause the transfer for flow control purposes by either pausing the assertion of
DIOW- or DIOR-pulses ,or by negating DMACK-. The device may leave DMARQ asserted if
DMACK- is negated. The host may then reassert DMACK- when DMARQ is asserted and
begin asserting DIOW- or DIOR- pulses to continue the data transfer.
When the multi-word DMA data transfer is complete, the device shall negate DMARQ and the
host shall negate DMACK- in response.
DMARQ shall be driven from the first assertion at the beginning of a DMA transfer until the
negation after the last word is transferred. This signal shall be released at all other times.
DMA Read Cycle and Write Cycle waveforms are shown in the Figure 2.
Figure 2: Read Cycle and Write Cycle waveform for the DMA mode of transfer
CoolRunner-II CoolRunner-II CPLD implementation of the IDE Controller supports the following features:
IDE Controller • Intel PXA270 CPU Static Memory Interface in 16-bit VLIO mode
Implementation • ATA PIO mode 0
• ATA Multi Word DMA mode 0, 1 and 2
• External SRAM interface for data buffering
• Data throughput
♦ Maximum data throughput achieved with 16-bit CPU interface and SRAM access time
of 55 ns is 6.4 Mbytes/sec

R
♦ Maximum data throughput achieved with 16-bit CPU interface and SRAM access time
of 10 ns is 7.4 Mbytes/sec
♦ Maximum data throughput possible with 32-bit CPU interface and SRAM access time
of 10 ns is 10 Mbytes/sec
• Only one hard disk interface
Signal Descriptions
The I/O signals of the CPLD IDE controller are described in the following tables
Table 1: CPU Interface Signals
Name Input/Output Description
104 MHz clock input to CPLD; connected to SDCKx
CPU_CLK_I I
line of the PXA270 CPU
Active Low asynchronous reset signal; connected to
CPU_RST_N_I I
the nRESETOUT line of the PXA270 CPU
Active Low chip select signal; connected to the nCSx
CPU_CS_N_I I
Address signals from CPU, which are used to decode
CPU_ADDR_I [9:0] I the device register access and the SRAM access;
connected to the MA[10:1] lines of the PXA 270 CPU
Data bus between the PXA270 CPU and the core;
CPU_D_IO [15:0] I/O
connected to the MD [15:0] lines of the PXA 270 CPU
Active Low write enable input; connected to the nPWE
CPU_WE_N_I I
Active Low read enable input; connected to the nOE
CPU_OE_N_I I
Interrupt from the CPLD to CPU; connected to the
CPU_INTR_O O
GPIOx line of the PXA 270 CPU
Ready signal to insert the wait state; connected to
CPU_RDY_O O
RDY line of the PXA270 CPU
Table 2: SRAM Interface Signals

SRAM_ADDR_O Address signal to access the memory connected to
O
[13:0] the A13-A0 lines of the memory
Data bus between the SRAM and the core. I/O15 to
SRAM_DD_IO [15:0] I/O
I/O0 lines of the memory
Active Low SRAM write enable output connected to
SRAM_WE_N_O O
the WEn line of the memory
Active Low SRAM read enable output connected to
SRAM_OE_N_O O
the OEn line of the memory
Active Low SRAM Chip Select Signal connected to
SRAM_CS_N_O O
the CEn line of the memory

R
Table 3: IDE Interface Signals

Used by host to reset the device; connected to the
ATA_RESET_N_O O
RESET- of the hard disk
Chip select signals used to select device command or
ATA_CS_N_O [1:0] O control block registers; connected to the CS1- and CS0-
line of the hard disk
Address signals to access device registers or data port;
ATA_DA_O [2:0] O
connected to the DA2-DA0 lines of the hard disk
Bi-directional data bus between device and host;
ATA_DD_IO [15:0] I/O
connected to the DD15-DD0 lines of the hard disk
Active Low host response to DMARQ to initiate DMA
ATA_DMACK_N_O O
transfer; connected to the DMACK- line of the hard disk
Asserted by device to initiate DMA transfer; connected
ATA_DMARQ_I I
to the DMARQ line of the hard disk
Active Low read strobe to read the device registers or
ATA_DIOR_N_O O
data port; connected DIOR- line of the hard disk
Active Low write strobe to write device registers or data
ATA_DIOW_N_O O
port; connected to the DIOW- line of the hard disk
Used by device to interrupt the host; connected to the
ATA_INTRQ_I I
INTRQ line of the hard disk

R
Block Diagram
The block diagram of the IDE controller as shown in Figure 3 is broken into four major blocks:
CPU interface and register,SRAM controller, PIO state machine, and the DMA state machine.
CPU Interface IDE Interface
CPU_CLK_I
CPU_RST_N_I
CPU_ADDR_I[9:0] ATA_RESET_N_O
PIO
CPU_D_IO[15:0] STATE ATA_CS_N_O[1:0]
CPU MACHINE
INTERFACE ATA_DA_O[2:0]
CPU_WE_N_I
AND
CPU_OE_N_I REGISTER ATA_DD_IO[15:0]
BLOCK DMA
CPU_CS_N_I STATE ATA_DIOR_N_O
MACHINE
CPU_INTR_O
IDE ATA_DIOW_N_O
INTERFACE
CPU_RDY_O
ATA_INTRQ_I
SRAM Interface
ATA_DMACK_N_O
SRAM_ADDR_O[13:0]
ATA_DMARQ_I
SRAM_DD_IO[15:0]
SRAM
SRAM_WE_N_O CONTROLLER
SRAM_OE_N_O
SRAM_CS_N_O
Figure 3: IDE Controller System Level Block Diagram
CPU Interface and Register Block

This interface is used to access the CPLD registers from the CPU. The CPLD will be connected
to the PXA270 external static memory interface operating in 16-bit VLIO mode. This interface
will be working at the CPU clock, which is 104 MHz. CPU chip select, write enable and read
enable signals will be used to decode the CPU cycles. Address inputs are decoded and
respective registers are read/written accordingly. CPU address bit A9 is used to decode the
CPLD registers access. If A9 is Low, access to CPLD registers will be enabled. If A9 is High, the
access will be for SRAM

R
CPLD Register Details

Table 4: Register LIst
SI Number Register Name Width Read/Write Address
Mode Select
1 3 R/W IDE Base + 0x000
Register
PIO Command,
Address Register
PIO Read, Write
Data Register
4 Command Register 2 R/W IDE Base + 0x006
Interrupt Enable
Register
Interrupt Status
6 5 R/W IDE Base + 0x00A
Register
IDE Base + 0x400 to
7 SRAM Buffer 1 16 R/W
IDE Base + 0x5FE
IDE Base + 0x600 to
8 SRAM Buffer 2 16 R/W
IDE Base + 0x7FE
(1) IDE Base indicates the base address for the IDE Controller, which will be decided from the memory
map of the microcontroller being used.
Mode Select Register

Mode Select Register is used to select the mode of operation on the IDE interface.
Table 5:
Mode Select Register Address Offset: [3:1] = b000
Bit Bit Name R/W Default Description
15:3 - - 0 Reserved
2:1 Timing Mode R/W 00 Selects the timing mode for the DMA
mode of transfer
00--Mode 0 (Cycle Time--480 ns)
0 Transfer Mode R/W 0 Selects the mode of transfer on the

interface
0--PIO Mode
1--DMA Mode

R
PIO Command Address Register

PIO Command Address Register is used select the device control and command block
registers.
Table 6: PIO Command Address Register
PIO Command Address
Address Offset: [3:1] = b001
Write Data Register
15:5 - - 0 Reserved
These two bits select the command block and
control block registers of the device. Data
written to these bits will be driven on the CS0
and CS1 lines of the IDE interface on the
4:3 Chip Select R/W 00
read/write cycle in PIO mode.
Bit 4 is driven to the CS1 line, bit 3 is driven to
the CS0 line of the IDE interface on the
read/write cycle in PIO mode.
These three bits are used to access the
device register and data port. Data written to
these bits will be driven on the DA [2:0] lines
2:0 Device Address R/W 000 of the IDE interface on the read/write cycle in
PIO mode.
Bit 2 is driven to the DA[0] line of the IDE
interface on the read/write cycle in PIO mode.
PIO Read/Write Data Register

PIO Read/Write Data Register is used to read and write data from IDE device.
Table 7: PIO Read/Write Data Register
PIO Read, Write Data
Address offset: [3:1] = b010
Register
15:0 Read, Write R/W 0000 Hold the read/write data from/to IDE device.
Data User can write the data to this register only if
the Transmit Empty bit is set in the Interrupt
Status Register.
User can read valid data from this register only
if the Receive Full bit is set in Interrupt Status
Register.

R
Command Register
Command Register is used to select between read and write operation on IDE interface.
Table 8: Command Register
Command Register Address offset: [3:1] = b011
15:2 - - 0 Reserved
1 Write Command R/W 0 When set initiates a write to IDE device. In

DMA mode, the Write Command has to be
cleared by the user after the completion of the
write cycle.
0 Read Command R/W 0 When set, this bit initiates a read from IDE
device. In DMA mode, the Read Command
has to be cleared by the user after the
completion of the read cycle.
0--No command
1--Read from IDE device
Interrupt Enable Register

The Interrupt Enable Register is used to update the status of SRAM.
Table 9: Interrupt Enable Register
Interrupt Enable
Register
15:4 - - 0 Reserved
3 SRAM Status Bit This register is used to enable the SRAM Status
Interrupt Enable bit interrupt towards the CPU.
0- SRAM Status bit interrupt is not enabled
1- SRAM Status bit interrupt is enabled
2 Device Interrupt R/W 0 This register is used to enable the Device

Request Enable Interrupt towards the CPU.
0 - Interrupt request bit is not enabled
1 – Interrupt request bit is enabled
1 Receive Full R/W 0 This register is used to enable Receive Full

Enable interrupt towards the CPU.
0 - Receive Full interrupt is not enabled
1 - Receive Full interrupt is enabled
0 Transmit Empty R/W 0 This register is used to enable Transmit Empty
Enable interrupt towards the CPU.
0 - Transmit Empty interrupt is not enabled
1 - Transmit Empty interrupt is enabled

R
Interrupt Status Register

Interrupt Status Register is used to report the different source of interrupt.
Table 10: Interrupt Status Register
Interrupt Status
Register
15:5 - - 0 Reserved
4 SRAM Status R/W 0 If mode is set to DMA Mode, indicates whether

Bit1 buffer2 contains valid data. On an IDE write cycle
the CPU should check this bit and if this bit is zero
the CPU can fill buffer2 with data. The CPU should
set this bit on completion of write.
On an IDE read cycle, the CPU will check for this
bit and, if set, can read data from buffer2. The CPU
should clear this bit after reading data from
buffer2.
0 – Buffer2 is not filled with valid data
1 – Buffer2 is filled with valid data
3 SRAM Status R/W 0 If mode is set to DMA Mode, indicates whether

Bit0 buffer1 contains valid data. On an IDE write cycle
the CPU should check this bit and if the bit is zero,
the CPU can fill buffer1 with data. CPU should set
this bit on completion of write.
On an IDE read cycle, the CPU will check for this
bit and if set can read buffer1. The CPU should
clear this bit after reading buffer1 data.
0 – Buffer1 is not filled with valid data
1 – Buffer1 is filled with valid data
2 Device Interrupt R 0 This register is used to update the interrupt from

IDE device to CPU.
0 – IDE device has not asserted the INTRQ line
1 – IDE device has asserted the INTRQ line
1 Receive Full R 0 If mode is set to PIO Mode, this register is used to

interrupt the CPU when the PIO Read/Write Data
Register contains the read data from IDE device.
This interrupt gets cleared when the CPU reads
data from PIO Read/Write Data Register.
0 – PIO Read/Write Data Register does not have
the read data from IDE device
1 - PIO Read/Write Data Register has the read
data from IDE device
0 Transmit Empty R 1 If mode is set to PIO Mode, this register is used to

interrupt the CPU so that it can write new data to
the PIO Read/Write Data Register. This interrupt
gets cleared when CPU writes data to PIO
Read/Write Data Register.
0 – Data cannot be written to PIO Read/Write Data
Register
1 – Data can be written to PIO Read/Write Data
Register

R
SRAM Controller
A 16-bit asynchronous SRAM will be used to store the data from the CPU/IDE device for the
DMA Transfer. The SRAM is broken into 2 blocks, buffer1 and buffer2. SRAM location 0 to 255
is called buffer1. SRAM location 256 to 511 is called buffer2.
rst_n ==1’b0
IDLE
cpu_oe or
cpu_we or
dma_oe
dma_we
Count == 3’h05 Count == 3’h05
READ WRITE
Count < 3’h05 Count < 3’h05
Figure 4: SRAM Controller State Machine
Writing or reading data to/from the SRAM will be performed by the state machine, which has
three states. The states are explained below.
When the DMA State Machine is accessing the SRAM, if the CPU requests an SRAM access,
the ready signal to the CPU will be held Low to extend the CPU cycle. After the DMA access is
completed, asserting the READY signal completes CPU access. DMA is given higher priority to
access the SRAM than the CPU.
IDLE:
Default state when there is no read or write operation to SRAM. In this state ,write enable, read
enable, and chip select signals to the SRAM are de-asserted. A 3-bit counter is used for SRAM
read/write cycle access time. The counter is reset to 0.
READ:
The state machine jumps from IDLE state to this state when there is read request from either
the CPU or the DMA state machine. In this state, the Count value is incremented by one on the
positive edge of the clock. SRAM Read Enable and SRAM Chip Select are asserted. Stable
SRAM Address is driven for the full SRAM read cycle. Read data from SRAM will be latched
when the Count value becomes 5 and the state machine moves to IDLE state.
WRITE:
The state machine jumps from the IDLE state to this state when there is a write request from
the DMA state machine or CPU. In this state the Count value is incremented by one on the

R
positive edge of the clock pulse. Write Enable and Chip Select to SRAM are asserted, and data
to be written will be driven on the SRAM data bus. Once the Count value becomes 5, the state
machine will jump to the IDLE state.
PIO State Machine and DMA State Machine

PIO State Machine and DMA State Machine handle the data transfer between the CPU and the
IDE device.
rst_n ==1’b0
Wr_cmd/Rd_cmd
IDLE SETUP_START
Count>0
END SETUP
Count ==0 Count==0
HOLD PULSE_START
Count>0
HOLD_START PULSE
Count>0
Count==0
Figure 5: PIO State Machine
This mode transacts with the register block to perform data read and write operations with the
IDE device. It has only one mode of operation. In this mode, the cycle time is 614 ns.
The state machine has eight states. The function performed in the each state is explained
below.
IDLE:
Default state when there is no data transfer between the CPU and the device. On reset the
state machine will be in this state. In this state the DIOW_N and DIOR_N signals will be in the
High state. If a read or write command is issued from the CPU by setting the Command
Register, then the state machine will jump to the SETUP_START state.
SETUP_START:
In this state, Count is loaded with 0x8 for address valid to the DIOR_N/DIOW_N Setup value
(77ns). In this state DIOR_N and DIOW_N will be in High state. This state is maintained for only
one clock cycle.
SETUP:
This state is maintained until the address to DIOR_N/DIOW_N Setup is valid. In this state,
every positive edge of the clock count value is decremented. Once the count value becomes

R
zero, it will jump to the PULSE_START state. In this state ,DIOR_N and DIOW_N will be in High
state.
PULSE_START:
In this state, Count is loaded with 0x1D for DIOR_N/DIOW_N pulse width (297 ns). If the Write
command bit in the Command Register is set, DIOW_N is asserted Low; else, if the Read
command in the Command Register is set, DIOR_N will be asserted. The state machine will be
in this state for only one clock cycle before it jumps to the PULSE state.
PULSE:
This state is maintained until the DIOR_N/DIOW_N pulse width value is valid. In this state, for
each clock cycle the Count value is decremented. Once the Count value becomes zero, it will
jump to the HOLD_START state.
In this state, during the Write cycle, write data from the processor will be driven on the IDE data
bus; during the Read cycle, when DIOR_N goes High, data from the IDE bus will be latched and
written to the PIO Read/Write Data Register.
HOLD_START:
In this state, Count is loaded with 0x15 for DIOR_N/DIOW_N to address a valid hold (144ns).
In this state ,DIOR_N and DIOW_N is driven High. The state machine will be in this state for
only one clock cycle, and then jumps to HOLD state. In this state DIOR_N and DIOW_N will be
in High state.
HOLD:
This state is maintained until DIOR_N/DIOW_N to address a valid hold. For each clock cycle,
the Count value is decremented by one. Once the Count value becomes zero, it will jump to the
END state. In this state, DIOR_N and DIOW_N will be in High state.

R
END:
In this state DIOR_N and DIOW_N will be in High state. The next state will be the IDLE state
((Wr_cmd) &&( (sram status bit1==1’b0)||
(sram status bit0==1’b0)))| |((Rd_cmd)
&&( (sram status bit1==1’b1)|| (sram
status bit0==1’b1)))&&DMA_req SETUP_START
Count>0
rst_n ==1’b0
SETUP
IDLE
count == 0
PULSE_START
Count>0
PULSE
count == 0 count == 0
HOLD_START
Mode0 || Mode 2
END Mode1 DELAY
HOLD Count>0
HOLD_LAST
Mode1||
Mode2
((Wr_cmd) &&( (sram status bit1==1’b0)||
(sram status bit0==1’b0))) ||((Rd_cmd)
&&( (sram status bit1==1’b1)|| (sram Mode 0
status bit0==1’b1)))&&DMA_req
DELAY_LAST
Figure 6: DMA State Machine
DMA mode has a DMA timing module that will give different timing performance according to
the user configuration. This DMA mode state machine will transact with the register block and
SRAM controller to perform data read and write operations with the IDE device.
The DMA state machine has three modes of operation. They are Mode 0, Mode1, and Mode2.
The state machine has 11 states. The function performed in the each state is explained below.

R
IDLE:
This is the default state when there is no data transfer between the CPU and the device. On
reset, the state machine will be in this state. In this state, DIOR_N and DIOW_N and
DMACK_N signals will be in the High state.
In this state, if the device asserts DMARQ, and DMA mode is enabled, the state machine
checks whether the read or write command is set in the Command Register. If the write
command bit in the Command Register is set, and the SRAM status bit is set, a read enable is
sent to the SRAM controller. Once data is available, the SRAM state machine will move to the
SETUP_START state. If a read command bit in the Command Register is set, and the SRAM
status bit is zero, the state machine moves to the SETUP_START state.
SETUP_START:
In this state, Count is loaded for the DMACK_N to DIOR_N/DIOW_N Setup with a value
corresponding to each mode of transfer. The DMACK_N signal is asserted in this state. If the
write command bit is set and the SRAM status bit is High, a read enable is sent to the SRAM
controller. If read address is the last location of buffer1, SRAM status bit0 is reset to zero. If the
read address is the last location of buffer2 , the SRAM Status bit1 is reset to zero. The state
machine will be in this state for only one clock cycle and will then move to SETUP state.
SETUP:
This state is maintained until the address to DMACK_N to DIOR_N/DIOW_N Setup time is
valid. In this state, each clock cycle count value is decremented. Once the count value
becomes zero, the state machine will jump to the PULSE_START state.
PULSE_START:
In this state, Count is loaded for DIOR_N/DIOW_N pulse width with the value corresponding to
each mode of transfer. If the write command bit in the Command Register is set, DIOW_N will
be asserted; else, if the read command bit in the Command Register is set, DIOR_N will be
asserted. The state machine will be in this state for only one clock cycle and then jump to the
PULSE state.
PULSE:
This state is maintained until the DIOR_N/DIOW_N pulse width value is valid. In this state, each
clock cycle count value is decremented. Once the count value becomes zero, the state
machine will jump to the HOLD_START state.
In this state, during the write cycle, write data will be placed in the IDE data bus; during the read
cycle, when DIOR_N goes High, data on the IDE data bus will be latched, and write enable to
SRAM controller will be asserted. If the write location in SRAM is the 256th location the SRAM,
status bit0 in Register will be set. If the write location in SRAM is the 512th location the SRAM,
status bit1 in Register will be set.
HOLD_START:
This state will be valid for one clock cycle. The DIOW_N and DIOR_N signals will be pulled
High in this state. For Mode2, the next state will be the HOLD_LAST state; for other modes of
transfer the next state will be the HOLD state.
HOLD:
This state is also maintained for one clock cycle. In this state, DIOR_N and DIOW_N will be in
the High state. The next state will be HOLD_LAST.
HOLD_LAST:
In this state, the state machine checks whether DMARQ from the device is still asserted. If
DMARQ is asserted and the write command bit in the Command Register is set, and an SRAM

R
status bit is High, the state machine will move to DELAY_START. If DMARQ is asserted and the
read command bit in the Command Register is set, and an SRAM status is Low, the state
machine will move to DELAY_ START. If any of the above conditions are not true, the state
machine will move to the END state. In this state, DIOR_N and DIOW_N will be in High state.
DELAY_START:
For DMA mode 0 transfer, the next state will be the DELAY state. For all other DMA modes, the
next state will be the SETUP_START state. In this state, the count will be loaded with the value
0x15 (144ns) for mode 0. In this state, DIOR_N and DIOW_N will be in High state.
DELAY:
This state is maintained until the count value becomes zero. Once the count value becomes
zero, it will jump to the SETUP_START state. In this state, DIOR_N and DIOW_N will be in High
state.
END:
The DMACK_N signal will be de-asserted in this state. This state is maintained for only one
clock cycle. The next state will be the IDLE state. In this state, DIOR_N and DIOW_N will be in
High state.

R
Operational Flow Diagram
Operational The flow of the interface between the CPU and the IDE Controller is detailed in the following
Flow Diagram flow charts. These flow charts are meant to be a guide for using the IDE Controller.
Begin
Configure the PIO mode

by writing
to the Mode Select Register
Write the Chip Select Signals

and the IDE device
register address in the
PIO command address register
Set the Transmit Empty Enable bit

and device interrupt enable bit
in the Interrupt Enable Register
Wait for interrupt ,when

interrupt arrives, read the
Interrupt Status register
NO Is
Transmit Empty bit
is set
Yes
Write the data in the

PIO Read, Write register
Write the write command

in the Command Register
Read the Transmit Empty bit

of Interrupt Status register
Is NO
Transmit Empty bit
is Set
Yes
END
Figure 7: PIO Write Transaction Flow Chart

R
Begin
Configure the PIO mode

by writing
Write the Chip Select Signals

and the IDE device
register address in the
PIO command address register
Set the Receive Full Enable bit

and Device Interrupt enable bit
Write the Read command


NO Is
Receive Full bit
is set
Yes
Read the data in the

PIO Read, Write register
END
Figure 8: PIO Read Transaction Flowchart

R
Begin
Configure the DMA mode

by writing
Set the Sram Status Bit Enable

Write the write command


No
Is
Sram status bit0 No
Sram status bit1
is clear
is clear
Yes Yes
Write the data to the Write the data to the
Buffer1 of the sram Buffer2 of the sram
No Last word Last word No

of Buffer1 of Buffer2
Yes
Yes
Set the sram status bit0 of the Set the sram status bit1 of the
interrupt status register interrupt status register
No Was it the
Last Sector
Yes
Read the sram status bit0 &

sram status bit1 of the
Interrupt Status Register
No
Sram status bit0
& sram status bit1
are cleared
Yes
Clear the write command

END
Figure 9: DMA Write Transaction Flowchart

R
Verilog Test Bench and Functional Simulation
Begin
Configure the DMA mode

by writing
Set the Sram Status Bit Enable

Write the Read Command


No
Sram status bit0 No Sram status bit1

is set is set
Yes Yes
Read the data from the Read the data from the
Buffer1 of the sram Buffer2 of the sram
No Last word Last word No

of Buffer1 of Buffer2
Yes Yes
clear the sram status bit0 of Clear the sram status bit1 of
the interrupt status register the interrupt status register
No Was it the
Last Sector
Yes
Clear the Read Command

END
Figure 10: DMA Read Transaction Flow Chart
Verilog Test A Verilog test bench has been developed that verifies the IDE Controller implementation. This
Bench and test bench contains a CPU BFM that emulates the bus cycles of the PXA270 CPU, has a BFM
of a IDE device, and an SRAM model, and will provide a user-friendly environment which can
Functional be used to run test cases so as to test the IDE Controller.
Simulation The details of the test bench and BFM implementation are explained in a test plan document.
Each test case is supported, and the way of running each test case is explained in the test case
document.

R
Cool Runner II CPLD Implementation
The test environment for the IDE Controller with SRAM of 55 ns is available in the IDE-
Simulation-55ns.zip file. You can unzip this file for functional simulation purposes. The
test environment for the IDE Controller with SRAM of 10 ns is available in IDE-Simulation-
10ns.zip file. You can unzip this file for functional simulation purposes.
The ModelSim command file, func_sim.do, can be used to open the correct waveform
window and run the simulation.
The test bench files are:
1. ATA_tb.v is the top module which will instantiate the Processor BFM, Sram BFM , IDE
device BFM and ATA Top module
2. cpu_mem_cntrl.v is the CPU BFM.
3. cpu_task.v is task file for CPU read and CPU write operations.
4. cy62126dv.v is the SRAM BFM.
5. ata_device.v is an ide device BFM
6. define.v will contain the define statements used in BFMs.
Cool Runner II The top level file for the IDE Controller is ATA Block, which has been entered as a hierarchical
CPLD Verilog file showing the interconnection between the ata_cpu_if block, the ata_sram_interface
block, the ata_pio_sm block and the ata_dma_sm block. The codes for the IDE Controller with
Implementation SRAM access time of 55ns, along with the full project is available in the IDE-Synthesis-
55ns.zip file. You can unzip this file to get the Verilog files of the various modules of the IDE
Controller. The codes for the IDE Controller with SRAM access time of 10 ns, along with the full
project is available in the IDE-Synthesis-10ns.zip file. You can unzip this file to get the
Verilog files of the various modules of the IDE Controller.
The IDE Controller design has been targeted to a CoolRunner-II 256 macrocell device using
the Xilinx Project Navigator. The speed grade chosen is dependent on the system clock
frequencies and should be analyzed by the designer to determine which speed grade is
required.
The Verilog Files are: -
1. ATA.v is the top module of the IDE Controller module
2. ata_cpu_if.v is the CPU Interface module
3. ata_sram_interface is the SRAM Interface module
4. ata_pio_sm is the PIO State Machine module
5. ata_dma_sm is the DMA State Machine module
An IDE Controller with SRAM access time of 55 ns utilizes 227 of the 256 macrocells available
in the device.
Table 11: CoolRunner-II CPLD 256-Macrocell Utilization for IDE Controller with SRAM
Access Time of 55 ns
P-terms 896 747 84%
I/O Pins 106 93 88%

R
Post-Fit Timing Simulation
IDE Controller with SRAM access time of 10ns utilizes 233 of the 256 macrocells available in
the device.
Table 12: CoolRunner-II CPLD 256-Macrocell Utilization for IDE Controller with SRAM
Access Time of 10 ns
P-terms 896 705 78%
I/O Pins 106 93 88%
Note: The following properties have to be selected, in order, as shown below, before running synthesis
in Xilinx Project Navigator. All other properties should be set to their default values.
Synthesis Properties: - Set advanced
Synthesis Options: -
Optimization Goal: Speed
Fitting Properties: - Set Advanced
Fitting: -
Implementation Template: Optimize Balance
I/O Voltage Standard: LVTTL
Collapsing Input Limit: 20
Collapsing P-term Limit: 30
Function block Input Limit: 40
Timing Report:
Make sure the UCF (User Constraint File) file is attached to the project. The name of the UCF
file is ATA.ucf.
The implementation details for the IDE Controller with SRAM access time of 55 ns are available
in the IDE-Synthesis-55ns.zip file.
The implementation details for the IDE Controller with SRAM access time of 10ns are available
in the IDE-Synthesis-10 ns.zip file.
Post-Fit Timing The Xilinx Project Navigator software package outputs a timing Verilog model of the fitted
Simulation design. This post-fit Verilog was simulated with the original Verilog test bench to ensure design
functionality using ModelSim. Please note that all verification of this design has been done
through simulations.
The user of this design is strongly encouraged to thoroughly inspect the timing report for this
design to insure that the design meets the timing specification of the system. The user is also
strongly encouraged to perform post-fit timing simulations as well.
The details of test bench and BFM implementation are explained in the test plan document.
Each test case is supported, and the way of running each test case is explained in the test case
document.
The test environment for the IDE Controller with SRAM 55 ns is available in the IDE-
Simulation-55ns.zip file. You can unzip this file for timing simulation purposes. The test
environment for the IDE Controller with SRAM 55 ns is available in the IDE-Simulation-
10ns.zip file. You can unzip this file for timing simulation purposes.

R
Limitations
The ModelSim command file, time_sim.do, can be used to open the correct waveform
window and run the simulation.
Limitations • PIO Mode1, Mode2, Mode3, Mode4 are not supported.

• UDMA mode is not supported. UDMA support needs more macrocells; it cannot be fit on
an XC2C256CP132 CPLD
• Processor interface is 16 bits
Source Code To obtain the Verilog source code for the IDE Controller, and all the accompanying modules,
please
Conclusion This document details the design of an IDE Controller using a CoolRunner-II CPLD.
History

R
Using a Xilinx CoolRunner-II CPLD as a
Data Stream Switch
XAPP944 v1.0 June 14, 2006
Summary This application note shows how a Xilinx CoolRunnerTM-II CPLD can be used as a simple
logical switch that can quickly and reliably select between different MPEG video sources. The
source code for the design is available on the Xilinx website, and is linked from the “VHDL
Code” section. The code can be expanded by the user to perform additional operations using
the remaining CPLD resources.
Introductions As consumer electronics become more complex, we are seeing a significant increase in the
number of formats used to transfer data. Video and audio both come in a multitude of different
formats, and often from different sources. Managing this data and ensuring the right data
arrives at the right destination at the right time is a challenge.
In our example, we use a CoolRunner-II CPLD to select between three MPEG-2 video sources;
these could be Satellite, Cable and Terrestrial television. The selected data source can then be
sent to a decoder to be streamed to a display, stored on a Hard Disk Drive (HDD), as would
happen in a Digital Video Recorder (DVR), or sent over a serial link to another piece of
equipment.
MPEG-2 Data The MPEG-2 encoded data from the different sources arrives in Transport Streams (TS). The
Sources Transport Stream consists of 8 bits of data (TS_DATA) and 3 control bits (TS_CLK, TS_SYNC
and TS_VAL). This example requires that each data source can be selected with a physical
input, so three select inputs are required. If you want to have an electronically generated select
signal, only two select signals will be necessary. Finally, the example also requires that the
outputs of the multiplexer can be put into a 3-state condition to isolate them from the system.
This is easy to achieve in the CoolRunner-II architecture.
CPLD Before implementing even a simple design inside a Xilinx CoolRunner-II CPLD, it is important
Background to understand the architecture. CPLDs are rich in logical resources. The logical array in the
CoolRunner-II architecture is a 40x56 PLA – 40 input signals to the logical array can be used to
create up to 56 Product (AND) Terms. Product Terms can then be used in any of the 16
Macrocells, containing registers, which are associated with each logical array. The I/O of the
CoolRunner-II CPLD can operate at 1.5V, 1.8V, 2.5V and 3.3V by simply changing an attribute
when coding the design.
More information on the CoolRunner-II architecture can be found in data sheets and application
notes on the www.xilinx.com website.
XAPP944 v1.0 June 14, 2006 www.xilinx.com 245

R
MPEG-2 Multiplexer Design
The design requires 37 input pins and 11 output pins. Using Table 1 below, you can see that
the appropriate device/package is the XC2C64A-VQ100.
Table 1: CoolRunner-II Package/I/O Matrix
I/O Banks 2 2 2 2 4 4
QFG32 (21)
QFG48 (33)
VQ44 (33) VQ44 (33)
PC44 (33) PC44 (37)
CP56 (33) CP56 (45)
Packages and
VQ100 (64) VQ100 (80) VQ100 (80)
User I/O
CP132 (100) CP132 (106)
TQ144 (100) TQ144 (118) TQ144 (118)
PQ208 (173) PQ208 (173) PQ208 (173)
FT256 (184) FT256 (212) FT256 (212)
FG324 (240) FG324 (270)
MPEG-2 Figure 1 shows the block diagram of the multiplexer system.

Multiplexer
Design
TS1_DATA,, TS1_CLK, TS1_VAL, TS1_SYNC
XC2C64A CPLD
TS2_DATA,, TS2_CLK, TS2_VAL, TS2_SYNC Output Transport Stream
MPEG Multiplexer
TS3_DATA,, TS3_CLK, TS3_VAL, TS3_SYNC
Select Enable
3 bits
Figure 1: MPEG Multiplexer
246 www.xilinx.com XAPP944 v1.0 June 14, 2006

R
Performance and Utilization
All the I/O pins in this design are configured to the LVCMOS33 3.3V I/O standard. Depending
on the state of the select lines, one of the three Transport Streams, TS1, TS2 and TS3, will be
directed to the output of the device. When a logic 0 is applied to the enable signal, the outputs
of the CPLD will be put into 3-state mode regardless of the condition of the select signals. This
example is intended to supply data to an MPEG-2 receiver and decoder, and then directly to a
display. The MPEG-2 Transport Stream uses short (188 byte) packet lengths. As broadcast
environments can be prone to error and the loss of one or more packets, receiver devices are
usually able to correct small errors. Hence losing one or two bits of data while changing
between sources will not matter. If the MPEG-2 sources were to be stored, such as when used
in a DVR, the user could use the remaining resources in the CPLD to register the data to
ensure that no bits are lost.
Performance This is a simple design that only passes through a small amount of logic. Hence, if implemented
and Utilization in the slowest speed grade, the XC2C64A-7, the pin to pin combinatorial delay is only 14.8ns.
As the MPEG-2 standard often has clock and data speeds of 27 MHz, this is easily handled. All
similar signals travel through the same path in the CPLD, so they will emerge from the other
side with negligible skew, because of to the deterministic nature of the timing model and
architecture.
Table 2 shows the resource utilization of the implemented design. It is clear that the limiting
factor in choice of device is the number of I/O. It is also evident that there are plenty of logic and
register resources available if the user wants to expand the functionality of the design.
Table 2: Device Utilization
Function Block
Macrocells Product Terms Inputs Registers Pins
Used/Total Used/Total Used/Total Used/Total Used/Total
12/64 (19%) 35/224 (16%) 37/160 (23%) 0/64 (0%) 48/64 (75%)
For the sake of simplicity, we ran the simulation with randomly generated data rather than
properly formatted MPEG-2 data.
VHDL Code To obtain the VHDL code for this application note, please use the following link:
Conclusion Due to their flexibility, Xilinx CoolRunner-II CPLDs are found in a variety of digital consumer
products. Multiplexing of MPEG-2 Transport Streams can easily be performed by a
CoolRunner-II CPLD with resources to spare for performing further operations. The VHDL
design supplied with this application note shows the simplest form of multiplexing between
such data sources. If the user requires further functionality, there are many resources available
in the CPLD in which to create it.
History
XAPP944 v1.0 June 14, 2006 www.xilinx.com 247

R
Revision History
248 www.xilinx.com XAPP944 v1.0 June 14, 2006

R
Supporting Multiple SD Devices with
CoolRunner-II CPLDs
XAPP906 (v1.0) June 10, 2006
Summary There has been an increasing demand to add multiple Secure Digital (SD) devices in a single
system. Whether the system application calls for a combination of SD memory ports, 802.11
SDIO cards or any other SDIO expansion cards, there is no question that the SD protocol is
currently hitting its stride. The problem, however, is that most host devices (i.e. Intel PXA270, TI
OMAP, or Qualcomm MSM processors) only provide a single SD interface. Fortunately,
CoolRunner-II CPLDs can be used to allow host devices to support any number of SD devices.
This application note details a scalable, auto-sensing bidirectional multiplexer based design.
Introduction Creating an SD Multiplexer Using CoolRunner-II

Figure 2 shows a generalized CoolRunner-II usage model to incorporate any number of SD
ports for a given host device that only has a single native SD interface. The CoolRunner-II
CPLD is placed between the host controller and the SD devices. As such, the CoolRunner-II
part performs a bidirectional multiplexing function, allowing the host to communicate with any
selected SD Device. More importantly, this design has no directional control pins, which means
that the CoolRunner-II automatically detects the direction of data flow.
SD
Device
1.8V 3.3V
Host Controller CoolRunner-II
(ASIC or μP) CPLD
SD
Device
Select Lines
Figure 2: Using CoolRunner-II CPLDs to provide additional SD ports
This implementation is extremely flexible and scalable, meaning that the number of SD ports
can be increased or decreased as desired. The design also supports any of the defined SD
card modes -- SPI, 1-bit, or 4-bit data modes.
While the primary purpose of using a CoolRunner-II device in this type of application is to
provide additional SD ports to the host controller, secondary benefits include level translation
and logic isolation between the host and the SD card. Figure 2 shows the case where the host
is 1.8V, but the SD Devices are 3.3V. CoolRunner-II CPLDs provide negligible standby current
and ultra low dynamic power consumption. Hence, incorporating a CoolRunner-II CPLD will not
have a significant impact upon your power budget.

R
CPLD Design
Compliance With the SDA Specification

The SDA specification states that one SD bus can only support one SD device. The clock pin
can be shared, but DAT[3:0] and CMD lines must be unique for every SD device. See Figure 3
for additional details.
Host
CLK
CLK
VDD
VDD
VSS SD Memory
VSS Card (A)
D0-3(A) D0-3, CMD
CMD(A)
CLK
VDD
VSS SD Memory
Card (B)
D0-3(B) D0-3, CMD
CMD(B)
Figure 3: SD System Bus Topology
This reference design is fully compliant with the SDA Specification. The following section will
show you how to satisfy the above requirements while supporting any number of SD devices
using a controller with a single bus.
CPLD Design Block Diagram

A block diagram showing typical use of this design for two SD devices sharing the same SD
host interface can be seen in Figure 4. Conceptually, the design can be viewed and used as a
bidirectional multiplexer. The host device controls the CoolRunner-II CPLD via the ’Select’
signals, thereby dictating which SD device to communicate with. Once an SD device has been
selected, the logic in the CoolRunner-II device automatically detects the direction of data flow,

R
CPLD Design
and allows data to flow accordingly (either from the host to the SD card or from the SD card to
the host). A directional control pin is not required, thereby making this design easy to use.
SD Select 1
SD Select 2
SD Bus 1
CMD
DAT0
DAT
A 0
SD 1
SD Host Controller
DAT1
DAT
A 1
Bidirectional MUX
CLK
DAT2
DAT
A 2
SD Bus DAT3
DAT
A 3
CMD
DAT0
DAT1
DAT2
DAT3 SD Bus 2
CMD
DAT
A 0
DAT0
CLK DAT
A 1
DAT1 SD 2
DAT
A 2
DAT2 CLK
DAT
A 3
DAT3
CoolRunner-II
Figure 4: Block Level Diagram: A Bidirectional Multiplexer
The host can access each SD device individually without affecting the state of the other when
the multiplexer is switched accordingly. If neither the host nor the SD is driving data, the
CoolRunner-II CPLD allows the system to be in the default high impedance with weak pull-up
state. The primary purpose of this circuit is to provide additional SD capability to the host, but
this circuit can also be used to provide level translation and/or logic isolation.
Implementation Details
Figure 5 shows the actual logic circuit for a 1:2 bidirectional multiplexer design, which can be
found described using VHDL (see “VHDL Download”). In the initial condition or idle state, the
Host and SD Cards should be high impedance with a weak pull-up. Hence, the circuit in
Figure 5 is designed to tristate the CoolRunner-II device’s output buffers, thereby allowing the
external pull-up resistors to take effect. Register A (A_REG) and Register B (B_REG) are both
designed to be initialized to logic ’0’ upon power-up.
The SD Cards are selected via the ’Select’ inputs to the CPLD. When ’Select’ is logic ’0’, SD1
is chosen and when ’Select’ is logic ’1’, the SD1 device is chosen. For simplicity while
describing this circuit, let us assume in the following discussion that the Host is only choosing
to communicate with SD1.
The autodirectional control aspect of this design is implemented in the following manner -- A
transaction is initiated when either the host or SD1 drives low. For example, if the host wants to
send data to the SD1 device, the host would begin by driving the A side low. Upon driving low,
the logic in the circuit detects the low going edge and responds by enabling the ’B’ output buffer,
but continues to keep the ’A’ output buffer disabled. Specifically, when A is driven low, a rising
edge is delivered to the clock input of A_REG. After clocking, A_REG’s Q output becomes logic
’1’ and therefor prevents B_REG from receiving a clocking event. In parallel with the A_REG
clocking and triggering, gate B1 outputs a logic ’1’ when A goes low. This enables the ’B’ Output
Buffer and, ultimately, B will follow A and drive low.

R
Design Verification
Conversely, when it is driven from low to high, gate B1 outputs a low and tristates the B output
buffer. This forces B to go high (via the external pull-up resistor). Once the A and B sides are
both high, A_REG and B_REG are reset to 0. This process is repeated indefinitely. The reverse
happens when SD1 attempts to drive data toward the host. Additionally, if the host wishes to
communicate with the SD2 device, the ’Select’ inputs to the circuit are set to a logic ’1’ and the
sequence of events are similar to the above.
B1
SD1
D Q
SEL
A
R
Q D
R SEL
B2
SEL
SD2
D Q
SEL
Figure 5: SD Multiplexer Circuit for Two SD Devices
Design Simulation Results

Verification Functional and timing simulations have been extensively performed on this circuit using
ModelSim, and test stimuli have been included with the VHDL download. Due to the timing

R
Device Utilization
critical nature of this circuit, a -4 speed grade CoolRunner-II device is required (See Table 3).
Figure 6 shows some simulation results.
Figure 6: Simulation Results
In the first part of Figure 6, the Select input is held low. A dotted white line denotes a "Weak 1"
condition, or, in other words, represents a pulled up state. In the first transaction, the host
attempts to drive data toward SD1, and SD1 follows accordingly. Immediately after, the SD1
device attempts to drive data toward the host, and the host follows. Similar events happen when
the Select input is driven low. The host drives data toward the SD2 device, then the SD2 device
drives data toward the host.
Device Table 3 shows device utilization statistics for various implementations. As stated in the SDA
Utilization specification, there are three signaling modes defined for SD cards: SPI Mode, 1-bit SD Data
Transfer Mode, and 4-bit SD Data Transfer Mode. This design can be easily adapted for any
chosen mode. The design can also accommodate any number of SD expansion ports. A -4
speed grade is required, due to certain timing critical paths in the design.
Table 3: Device Utilization Statistics for Various Implementations

Number of SD Expansion Macrocell Utilization Macrocell Utilization
Ports (SPI or 1-Bit Data Mode) (4-Bit Data Transfer Mode)
1 13 Macrocells 19 Macrocells
Voltage and The SDA Specification contains stringent voltage and current requirements for SD cards.
Current CoolRunner-II devices are ideal for this application because they are extremely low power and
have features such as I/O Banking. The CoolRunner-II I/O’s can be configured as 1.5V, 1.8V,
Considerations 2.5V or 3.3V allowing them to interface to any SD device. CoolRunner-II CPLDs also contain
I/O Banks, which allow for voltage translation capabilities between the processor and SD card.
The extremely low power nature of the CoolRunner-II family allows for standby operation as low
as 15 μA. The addition of a CoolRunner-II device in a system will minimally impact the current
budget.
VHDL The VHDL files to compile and simulate these designs are located at:
Download http://www.xilinx.com/products/xaw/coolvhdlq.htm

R
Conclusion
Conclusion As SD devices gain in popularity, the need will increase for ways to support more than one SD
device with host controllers. This application note provides a verified solution to the problem at
hand. This solution will give designers the flexibility to implement two or more SD devices into
a system.
History

R
Chapter 2
Introduction to Low Power Design

This chapter contains information to get you started on low power design with Xilinx
CoolRunner-II Devices. We have other documents as well that can be found on the Xilinx
website, including XAPP436, Managing Power with CoolRunner-II CPLDs, and XAPP395,
Using DataGATE in CoolRunner-II CPLDs. To obtain the aforementioned documents, visit
www.xilinx.com.
• The Real Value of CoolRunner-II DataGATE
• Power Evaluation Equation for CoolRunner-II CPLDs
• Low Power Design with CoolRunner-II CPLDs

June 26, 2006
R
Chapter 2

June 26, 2006
WP227 (v1.1) June 29, 2005
The Real Value of CoolRunner-II

DataGATE
By: Mark Ng
DataGATE™ is a CoolRunner™-II CPLD feature that

permits input signal blocking, stops input switching,
and reduces power. DataGATE can block any input
pins you select. Low power design can be attained
without using DataGATE, but even greater results
are possible for your entire design using it. With
DataGATE, CoolRunner-II devices are the only
CPLDs on the market that can quote a low standby
current and have it actually mean something. This
white paper will demonstrate the dramatic results
that can be obtained for your design using
DataGATE.
WP227 (v1.1) June 29, 2005 www.xilinx.com 257

R
White Paper: The Real Value of CoolRunner-II DataGATE
Introduction No other CPLD approaches specified standby current without using external logic to
block switching inputs. Adding external logic increases system power and cost. Data
sheet statements about static current are simply incomplete, and potentially useless or
dangerous. You cannot measure static current without external modification. This has
little value, in real world circuits, except to state: If all inputs were stopped, then current
drawn would be X microamps.
Unfortunately, for real world designs this statement has little meaning. To gain the
benefits of low static current may require massive design changes. DataGATE gives
you additional power reduction using no external resources.
How Good is DataGATE?

It’s excellent! The results you get will depend on the design and how DataGATE is
used. To clarify, we will provide guidelines for best results. Table 1 shows how much
VCCINT current is saved under various input blocking conditions. As shown in the
first row of Table 1, the standby current (defined as the total amount of current drawn
at 0 MHz) of this particular XC2C128 unit under test is 0.02 mA. Without DataGATE,
current increases linearly as the number of inputs switching increase.
However, with DataGATE the CPLD can approach standby current without forcing all
inputs to stop switching. DataGATE allows up to 99% power savings. Other CPLDs
can try to specify a meaningless standby current, but CoolRunner-II is the only CPLD
that can actually save power in a real world design, one that has actual inputs and out-
puts, and interacts with other devices.
VCCINT Current The current savings on VCCINT are substantial, as shown in Table 1.
Savings
Table 1: Current Drawn on VCCINT from Switching Inputs with/without DataGATE at 50
MHz.
Current Drawn on VCCINT (mA)
Inputs Switching No DataGATE With DataGATE Savings
0 0.02 0.02 0%
1 0.82 0.02 97%
2 1.62 0.02 98%
3 3.09 0.02 99%
4 5.40 0.02 99%
258 www.xilinx.com WP227 (v1.1) June 29, 2005

R
Figure 1, Figure 2, Figure 3, and Figure 4 graphically show how VCCINT current
savings increase versus input signal frequency.
1 Input Switching: Vccint Current Savings w/ Datagate
0.9
0.8
Vccint Current (mA)

0.7
0.6
0.5 Iccint (Datagate)
0.4 97% Iccint (No Datagate)
0.3
0.2
0.1
0
0 20 40 60
Frequency (MHz)
Figure 1: VCCINT Current Savings, Single Input Switching
2 Inputs Switching: Vccint Current Savings w/ Datagate
1.8
1.6
1.4
Iccint (mA)
1.2
1 Iccint (Datagate)
0.6
0.4
0.2
0
0 20 40 60
Frequency (MHz)
Figure 2: VCCINT Current Savings, Two Inputs Switching

R
3.5
3
2.5
Iccint (mA)
2 Iccint (Datagate)
1
0.5
0
0 20 40 60
Frequency (MHz)
Figure 3: VCCINT Current Savings, Four Inputs Switching
5
Iccint (mA)
4
Iccint (Datagate)
3
99% Iccint (No Datagate)
2
0
0 20 40 60
Frequency (MHz)
Figure 4: VCCINT Current Savings, Eight Inputs Switching
What about At this point, we have established that a ‘Standby Current’ specification is relatively
VCCIO Current? useless. No real design can operate with zero inputs toggling. We have also
established that CoolRunner-II is the only CPLD in the world that allows a user to
approach standby current without physically disconnecting all inputs. But all
discussion thus far has concentrated on current drawn through the VCCINT rail. What
about current drawn through VCCIO?
The entire industry avoids discussing current drawn through VCCIO. No PLD
manufacturer provides any specification whatsoever regarding how much current the
I/Os will draw. Examine any CPLD data sheet. You will find that all ICC versus
Frequency graphs are specific to VCCINT current. No reference is ever made to VCCIO.

R
Why? This is primarily because current drawn through the I/Os is difficult for
manufacturers to determine because it is dependent upon too many external variables
(capacitive loading, frequency, current requirements, input rise time, and so on). In
addition, as VCCIO current can be significant (so significant that it can invalidate a
device’s low power message), most manufacturers have tended to avoid it.
Let’s examine the effect of simply switching a few inputs. This time, instead of looking
at VCCINT, let’s look at VCCIO. How much current does that draw, and, can DataGATE
do anything to reduce VCCIO current?
Table 2: Current Drawn on VCCIO from Switching Inputs with/without DataGATE at 50

MHz
Current Drawn on VCCIO (mA)
Inputs Switching No DataGATE With DataGATE Savings
0 0 0 0%
1 8.58 0.05 99%
2 14.86 0.11 99%
4 25.95 0.22 99%
8 43.82 0.44 99%
As can be seen in Table 2, this VCCIO current can be quite large. However, with
DataGATE asserted, the CoolRunner XC2C128 device can essentially shut down the
internal I/O buffers and accomplish 99% power savings on the VCCIO rail. Figure 5,
Figure 6, Figure 7, and Figure 8 show VCCIO current savings versus input switching
frequency.
1 Input Switching: Vccio Current Savings w/ Datagate
10
9
Vccio Current (mA)
8
7
6 Iccio (Datagate)
5
4 99% Iccio (No Datagate)
3
2
1
0
0 20 40 60
Frequency (MHz
Figure 5: VCCIO Current Savings, Single Input Switching

R
2 Inputs Switching: Vccio Current Savings w/ Datagate
16
14
Vccio Current (mA)

12
10
Iccio (Datagate)
8
99% Iccio (No Datagate)
6
4
2
0
0 20 40 60
Frequency (MHz)
Figure 6: VCCIO Current Savings, Two Inputs Switching
30
25
Vccio Current (mA)
20
Iccio (Datagate)
15
10
0
0 20 40 60
Frequency (MHz)
Figure 7: VCCIO Current Savings, Four Inputs Switching

R
40
35
Vccio Current (mA)

30
25
Iccio (Datagate)
20
15
10
5
0
0 5 10 15 20 25
Frequency (MHz)
Figure 8: VCCIO Current Savings, Eight Inputs Switching
We have already demonstrated one of the greatest kept secrets in the CPLD world --
although VCCINT dynamic current can be quite low, VCCIO current can exceed VCCINT
current by as much as 4x! It is no wonder that manufacturers do not specify VCCIO
current. Instead, they focus on what appears to be an extremely low standby current,
which is basically useless. They focus on dynamic VCCINT current, which is
substantially less than VCCIO current.
Other devices may appear to be low power, but only one device actually is low power.
CoolRunner-II devices are the only CPLDs providing 99% savings on VCCINT and 99%
power savings on VCCIO.
Conclusion Table 1 and Table 2 understate the problem. Data was taken with simple buffers,
showing the effect of blocking inputs into the chip. If those inputs connected to
multiple sites within the CPLD, additional power would be drawn, driving the
capacitance of the additional connections. Hence, the more complex the design, the
more power is saved by blocking inputs. Because we cannot anticipate how much
logic your inputs will drive, it is difficult to estimate how much current will be saved
for a particular design. However, one thing is certain: CoolRunner-II is the leading low
power device not only because it has low dynamic power consumption, but also
because it is the only CPLD that allows a design to approach standby current during
full operation.

R
Additional Xilinx has invested considerable time in developing the best ways to reduce power in
Resources digital systems that use our parts. The following documents give an idea of the many
ways to approach the problem, so please become familiar with them as you select the
methods that work best for you.
XAPP 395 describes how DataGATE works and outlines a general approach for
reducing your power. Briefly, you simply create your design as you wish and measure
your power (typically ICC). Then, you identify signals that may be blocked, and
redefine your design to block them with the DataGATE signal. You then measure your
current and see if enough reduction occurs. If it works correctly and you wish to
remove more current, block some more signals. Keep blocking and measuring to
reduce current. If you block signals to the extent that the design no longer works,
simply go back one step to the last point that worked. There are other approaches, but
this one works well.
XAPP378 shows how to drive the design software to take advantage of the
CoolRunner-II advanced features. DataGATE is one of many such features, as are
advanced clocking (division, DualEDGE), Schmitt trigger inputs, and slew rate
control.
XAPP436 shows how a CoolRunner-II CPLD can reduce power in other chips, along
with the CPLD itself. This approach uses DataGATE to block switching signals that are
not needed in the other chip, and contributes to the overall system power usage. If you
are using CoolRunner-II as a level translator, you get DataGATE power management
for free on devices of 128 macrocells and above. This application note explains how.
XAPP 377 shows a set of low power design practices, including DataGATE. There are
many ways to reduce power, and Xilinx CPLDs show more ways to do that than any
other competitor.
If you are not interested in measuring power, XAPP 317 shows how to apply the
CoolRunner-II power equation to arrive at a reasonable estimate of your application’s
power usage. Just working with the equation factors can provide insight into ways to
reduce it, as well.
Finally, if you want to understand the deeper workings, U.S. Patent #6,172,518 goes
through the original approach for DataGATE. It was originally invented for the Xilinx
XC9500/XL/XV family of CPLDs, but was only used in the CoolRunner-II Family,
where dramatic power reduction would be most appreciated.
History
06/29/05 1.1 Web Publication

R
Power Evaluation Equation for
CoolRunner-II CPLDs
Summary This application note provides a quick and simple method for estimating power consumption of
CoolRunner-II CPLDs. As an alternative to XPower, power can be quickly and easily computed
using the provided equation and coefficients as described in this application note.
Introduction Many times, users wish to evaluate the potential value of using a low power device such as the
CoolRunner-II CPLD prior to designing the system. This precludes using XPower as a power
evaluation tool since the system design is usually not a point that is useful to XPower. It is often
that design engineers are simply evaluating devices early in the design cycle to determine
which is best regarding not only power, but pricing, density, features, etc. It is in these cases
that a simple method of evaluating power consumption can be useful. The designer does not
often have time early in the design cycle to complete a full power evaluation. Using a simple
equation, as described below, will greatly assist the designer during this evaluation period.
CoolRunner-II CPLDs are supported in XPower starting with FISE 6.1i or ISE WebPACK 6.1i.
Derivation The equation given in this application note was derived first by breaking down the capacitive
elements of the device. All CMOS logic devices consume power in two basic ways: Static
current, and dynamic current.
Static Current
Static current is the current which exists as current flows through the PMOS and NMOS
transistors in a logic element when either of these transistors is turned off. This is an artifact of
CMOS structures since these devices leak small amounts of current when one of these
transistors is in the off state. Summing these leakages over the complete structure of the device
will yield static current for the entire device. The equation represents this current as ICCSB.
In addition, static current in CoolRunner-II CPLDs contains a component due to other circuitry
active in the background that is not accessible to the user.
In CoolRunner-II CPLDs, static current is consistent regardless of design and therefore is not a
calculated value.
Dynamic Current
Dynamic current is realized when the logic gates change states. Current flows momentarily
through the P and N channel transistor in a logic gate when both are turned on at the same
time. Figure 1 shows a non-inverting buffer where through current is denoted as Transition
Current, commonly known as crowbar current. Transition current is a minor portion of dynamic
current due to fast edge rates within the CoolRunner-II CPLD and is therefore considered
negligible.
In addition, dynamic current is comprised of other effects of a switching logic gate. Specifically,
charge must enter or leave the gate of the next logic element in the chain and is supplied using

1-800-255-7778
R
Derivation
the P channel transistor or is removed using the N channel transistor of the first logic gate, as
shown in Figure 1. Similarly, the routing between gates consists of a capacitive element that
must also be charged or discharged in a similar manner.
If the logic gate is the last in the chain of logic and is driving an external load, this load will also
have a capacitive element to its structure. For example, this external load can be the printed
circuit board (PCB) trace capacitance and the input capacitance of subsequent devices.
Charge
Transition
Discharge
X317_01_092203
Figure 1: Non-Inverting Buffer
Using this method, CMOS logic elements can therefore be modeled as simple capacitors. The
basic equation to calculate dynamic current consumed in a capacitor is:
I = C⋅ V⋅ f
where:
• I = current, in Amperes
• C = capacitance, in Farads
• V = voltage, in Volts
• f = frequency, in Hz
Summing these capacitive elements over the entire structure of the CMOS device, total
dynamic current can be calculated. In the simple equation given below, total capacitance is
assumed to be lumped as one capacitive element to simplify the task of deriving the equation.
Over the entire device, dynamic current can further be broken down into several categories to
attempt to gain granularity in the calculation: core, I/O and load currents. The core current is
comprised of the logic gates which make up the total user functional design. I/O current is
derived from I/O logic switching, which is simply the I/O buffer. Load current is found when the
I/Os must charge and discharge the external load capacitive elements. These three elements
will toggle based on the user/system supplied frequency.
Data Source
The equation in this application note requires the user to insert numbers for some coefficients.
These coefficients are included in Table 1 below and are derived in the laboratory.
Core Current Coefficient

Using a 16 bit binary up/down resettable counter, each CoolRunner-II CPLD is filled with one
16 bit counter per Function Block, utilizing the entire device. These counters are clocked from
the same clock but have no outputs enabled. The clock frequency is swept from 0Hz up to the
maximum frequency the device can sustain. This data is then used to determine the coefficient
for core current, A.

1-800-255-7778
R
The Equation
16 bit up/down binary counters only have 2 product terms per macrocell, and half of these
product terms do not toggle when using the counter in either direction. Also, all product terms
and macrocells do not toggle at the same time, reducing the amount of total logic that changes
states at any one time. Effectively, 12.5% of macrocells in each counter toggles over time where
the MSBs toggle very infrequently with respect to the clock. This type of characterization
method is, therefore, not a good benchmark for programmable logic devices. Unfortunately, the
PLD industry has selected the 16 bit binary counter as the prime design for comparison.
With this in mind, it is important to understand that the equation and coefficients given below
will yield a "ball park" estimate, and are by no means to be considered accurate or a prime
standard. XPower was designed to provide a much more accurate representation of power
consumption in CoolRunner-II CPLDs. Again, this equation is intended to provide the system
designer with an early taste of power consumption in CoolRunner-II CPLDs during the device
selection phase of the design process.
I/O Current Coefficient

Similarly, the I/O Current Coefficient is obtained by measurement in the lab. This number is
derived from the same data used in XPower which is obtained from more than one type of test.
I/O Current is calculated in the equation using the coefficient, B.
Load Current Capacitance

It is up to the user to determine the correct value of load capacitance. This may not be an easy
task since determining PCB trace capacitance is not straight forward. A network analyzer may
be used where a Smith Chart is used to determine impedance of the trace. Extracting the
capacitive element from the Smith Chart is the only component of the impedance that is
needed for the equations.
Alternatively, since PCBs are not yet manufactured early in the design process, the PCB layout
engineers may be able to estimate capacitance of the trace based on line width, length, and
board type. It is relatively easy to determine input capacitance of other devices on the PCB
trace since these numbers are usually described in the respective data sheets. All of these
capacitive elements must be summed by the user and then added into the equation as the
coefficient, CL.
The Equation Below is the equation for calculating total current in the CoolRunner-II CPLD. Again, this
equation is intended to provide an evaluation value for current consumption and is simply a "ball
park" estimate.
C L ⋅ V L⎞
I CC = I CCSB + MC TOG ⋅ f MC ⋅ MC ⋅ A + IO TOG ⋅ f IO ⋅ IO ⋅ ⎛ B ⋅ V CCIO + -------------------
-
⎝ 1000 ⎠
where:
ICC = total device current, in mA
ICCSB = quiescent current, in mA
MC = total number of non-I/O macrocells used in design
IO = total number of bi-directional or output macrocells used in design
fMC = maximum clock frequency of non-I/O macrocells, in MHz
fIO = maximum clock frequency of I/O macrocells, in MHz
MCTOG = average non-I/O macrocell toggle rate, usually 12.5% (as a fraction, e.g. 0.125)
IOTOG = average I/O macrocell toggle rate, usually 12.5% (as a fraction, e.g. 0.125)
VCCIO = I/O power supply voltage, in V

1-800-255-7778
R
Conclusion
VL = external load voltage, in V, usually the same as VCCIO

CL = external load capacitance, in pF
A = core capacitive coefficient, as given in Table 1
B = I/O capacitive coefficient, as given in Table 1
Table 1: Power Equation Coefficients for CoolRunner-II CPLDs

Device ICCSB A B
xc2c32 0.016 0.0085 0.0152
xc2c64 0.017 0.0091 0.0152
xc2c128 0.019 0.0105 0.0152
xc2c256 0.021 0.0119 0.0152
xc2c384 0.023 0.0128 0.0152
xc2c512 0.025 0.0136 0.0152
For CoolRunner-II CPLDs where the I/Os are operated in SSTL or HSTL modes, add 2mA per
I/O configured in this manner.
Toggle rate is based on the percentage of edges the average macrocell toggles with respect to
the clock active edge. It is typical to specify a number of 12.5% which is derived from the 16 bit
binary counter example. In this example, the LSB toggles on 100% of the rising edges of the
clock, yielding 1/2 the frequency of the clock at the output of the register. The next significant bit
toggles at 50% of the rising clock edges resulting in 1/4 the clock frequency at the register
output. Evaluating all 16 bits in this manner yields an average of 12.5% toggle rate for all
registers in the counter. It is up to the user to determine the average toggle rate of the
macrocells or I/Os based on the intended design. As a quick reference 12.5% may be useful,
but toggle rate will vary with different designs.
To obtain power in mW, use the above equation as modified below:
2
⎛ 2 C L ⋅ VL
P = V CC ⋅ ( I CCSB + MC TOG ⋅ f MC ⋅ MC ⋅ A ) + IO TOG ⋅ f IO ⋅ IO ⋅ ⎜ B ⋅ V CCIO + -------------------
-
⎝ 1000
where:
P = total device power, in mW
Vcc = core voltage, in V
For CoolRunner-II CPLDs where the I/Os are operated in SSTL or HSTL modes, there is 2mA
adder per I/O configured in this manner. Therefore, add to the results VCCIO times 2mA per pin
with this configuration.
Conclusion The equation given in this application note provides the designer with an easy method for
evaluating the future use of CoolRunner-II CPLDs in a proposed system. This equation
provides a value that is reasonable compared to the actual characteristics of the device, but
should not be considered an accurate number. XPower should be used to obtain more accurate
numbers if this is desirable.

1-800-255-7778
R
Revision History
History

1-800-255-7778
R
Revision History

1-800-255-7778
R
Low Power Design with CoolRunner-II
CPLDs
XAPP377 (v1.0) May 8, 2002
Summary CoolRunner™-II CPLDs are the only CPLD to combine both high performance and low power
to form the next generation CPLD. This application note describes the design methodologies
that can be employed to obtain the lowest power possible using the CoolRunner-II CPLD by
utilizing its unique power saving features.
Introduction CoolRunner-II CPLDs continue to employ the features of Fast Zero Power™ (FZP) technology
as found in the earlier CoolRunner CPLD generations. But due to unique Xilinx design
techniques, smaller geometries, and state of the art process technology, FZP technology has
further advanced CoolRunner-II CPLDs as the low power standard. Other CPLD
manufacturers have attempted to reproduce the FZP true CMOS technology of the CoolRunner
CPLDs, but have not been able to meet the CoolRunner benchmark. For the first time in the
CPLD industry, CoolRunner-II devices deliver both true high performance and low power at the
same time, along with the lowest standby current in the industry without the use of power down
modes. In addition, these devices offer unique power saving features such as CoolCLOCK,
DataGATE, and DualEDGE flip-flops.
Traditional CPLDs use sense amp type product terms to provide fast propagation delay times.
Sense amp product terms are biased in a manner to detect a small change in voltage levels on
the word line which indicates a change in the logic state of the product term. The transistor
biasing constantly draws current, even at standby. With this in mind, these types of CPLDs
cannot provide a low power solution, as can CoolRunner-II CPLDs. As sense amp type device
sizes become larger in macrocell count, power grows significantly since there are many more
product terms to consume power.
As process technology shrinks, sense amp type CPLDs will inherently consume more power to
maintain performance. Smaller process technology demands lower power supply voltages
thereby reducing the gain of the sense amp. Further, product term transistors leak more with
the smaller geometries. To maintain performance, a sense amp CPLD will need to be designed
such that its biasing compensates for the leakage and boosts gain to detect the smaller voltage
swing of the word line. Higher biasing will cause more current to flow through the bias network,
thereby increasing total power consumption. Other CPLD manufacturers that use sense amp
based technology will inevitably go through a learning process to re-design their current
products to compensate for the effect of ever shrinking process technology.
CMOS product terms, as used in the FZP technology, inherently consume less power when not
switching states. Since CMOS logic exhibits low standby current, CoolRunner-II CPLDs use
this technology to reap the benefits of low power. Additionally, CMOS technology benefits from
smaller geometries where the device consumes less power and becomes faster.
Power Saving New architectural features have been added to the CoolRunner-II product line to enhance the
Features power saving capabilities of the FZP technology. This section describes these features and
how they can be used to save power.

1-800-255-7778
R
All new features described below are available with the XC2C128 and larger devices. The
smaller devices, XC2C32 and XC2C64, do not include some features, specifically DataGATE,
Clock Divider, and CoolCLOCK.
DataGATE
Many times devices are connected to a data bus which are not being addressed by the master
device. When a CPLD is in this situation, it will use more power than necessary since the data
on the bus is not useful to the CPLD, but the data lines continue to toggle, which subsequently
toggles the internal logic of the CPLD. Any logic that changes state within the CPLD will
consume power. Therefore, it follows that disconnecting the CPLD from the data bus when the
device is not addressed conserves power, as highlighted in this example.
DataGATE solves this issue by disconnecting external signal activity from the internal logic,
consequently reducing power consumption of the device. This is achieved by using a unique,
software enabled, CoolRunner-II pass gate at the I/O pin (when configured as an input) which
is controlled by the DataGATE global net. This control net originates from a specific
pin/macrocell and can be driven by either an external signal or an internally developed signal
using logic elements. When the pass gate on the input pin is disabled by the DataGATE control
net, an internal latch drives the CPLD logic network maintaining the same logic level that was
present on the input pin just prior to asserting the DataGATE control net. This preserves the
current logic state internal to the CPLD while external data changes states.
For example, a CoolRunner-II CPLD that shares a data bus with other devices will most likely
have its own address and typically will not be addressed continuously. Two options exist to
disconnect the data bus from the CoolRunner-II CPLD when not addressed. First, if the device
is addressed using a chip select signal, this signal can be assigned to the DataGATE control
pin and used to isolate the inputs from the data bus. Second, if using an address bus, the
address of the device can be decoded internally to the CPLD which can then be used to enable,
via DataGATE, the data bus inputs to receive data when addressed. When the CPLD is not
addressed, DataGATE would disconnect the external data bus signals using address decoding
internally to the CPLD. In this case, the result of the internal decoding is routed to the
DataGATE pin to disconnect the toggling bus.
DataGATE can be configured to affect any or all I/O pins, with the exception of JTAG pins and
the DataGATE pin itself. The above example discusses DataGATE configured to affect a few
macrocell I/O pins. It may be beneficial in other applications to disconnect the system clock or
clocks from the CPLD. The two elements that consume the most power are output buffers and
the clock tree. If the CPLD is not needed for a specific amount of time, the DataGATE feature
could be used to gate the clock. Doing so will dramatically reduce power consumption.
However, caution must be exercised when gating a clock since undesired logic transitions may
occur.
There are other cases where the unique CoolRunner-II DataGATE feature is useful to reduce
power. Also, DataGATE is flexible such that the entire device or only parts of the device can be
isolated from external signals, depending on the application. For example, it can be used in
CoolRunner-II CPLDs to enhance board troubleshooting procedures.
Schmitt Trigger
CoolRunner-II Schmitt trigger inputs are useful for applications that require hysteresis on the
inputs. A useful application might be where noise is an issue on specific pins. Hysteresis
provides added noise immunity. Another application could implement an oscillator circuit which
is constructed external to the CPLD, but CPLD logic is used to implement portions of the
oscillator circuit.
To ensure the lowest power consumption in the CoolRunner-II CPLDs, disable the Schmitt
trigger inputs since these types of buffers consume more power than the regular input buffer. It
is important to design and operate the system in a low noise environment when Schmitt triggers
are disabled to prevent inadvertent transitions on the CPLD inputs.

1-800-255-7778
R
Clock Divider
Global clock networks tend to be the largest power consuming elements in CPLDs. Any effort
to reduce the frequency of the global clock network greatly benefits the system with respect to
power consumption. Therefore, CoolRunner-II devices have been designed to include a clock
divider network on global clock, GCK2. Without introducing additional clock delays, the clock
divider has the capability of dividing the system clock by even integers ranging from 2 to 16, as
shown in Figure 1.
¸2
¸4
¸6
GCK2 Clock ¸8
¸10
In
¸12
¸14
¸16
Synch Rst
CDRST X377_01_041102
Figure 1: Clock Division Circuitry for GCK2
Some systems use state machines, for example, that do not require the full speed of the
external system clock. A clock divider is the perfect tool to reduce system power in this case.
The clock divider provides an excellent alternative to adding a user defined clock divider built
from logic, which would waste logic otherwise usable for more features in the design. A lower
frequency on the global clock network, provided by the clock divider, will reduce the power
consumed by the CoolRunner-II CPLD.
Generally speaking, designing with the slowest system clock possible will reduce power
consumption. To this end, the clock divider provided in the CoolRunner-II architecture will
greatly assist the designer.
DualEDGE Registers
By utilizing both edges of the clock signal, the macrocell can do twice the work when configured
as a DualEDGE flip-flop. Figure 2 displays the macrocell configured as a DualEDGE flip-flop. A
system without the aid of the DualEDGE flip-flop would need to provide a clock at twice the
frequency to obtain the same work output at the macrocell. Since the macrocells with
DualEDGE flip-flops operate on both the rising and falling edges of the clock, the clock network
is used more efficiently. Consequently, power consumption is reduced when the global clock
net is operating at a lower frequency.
D/T Q
PTC CE FIF
Latch
CK ✓DualEDGE
GCK0
GCK1
CTC GCK2
PTC
x377_02_041102
Figure 2: Macrocell Clock Chain with DualEDGE Option Shown
DualEDGE flip-flops further enhance the functional possibilities of the clock divider and
therefore improve power savings. The global clock can be effectively divided by odd integers of
3, 5, and 7 if used with the DualEDGE flip-flop. For example, if a divide by 3 clock is desired for

1-800-255-7778
R
the design, the Clock Divider can be set to a divide by 6 and then effectively doubled by the
DualEDGE flip-flop resulting in a divide by 3 characteristic. This is important to note since,
again, lower clock frequencies always save power. The DualEDGE flip-flop effectively adds
more functionality to the clock divider network.
Perhaps the design contains two state machines. One state machine can efficiently operate at
1/4th the system clock frequency, yet the other state machine can much more efficiently
operate at 1/8th the system clock frequency. DualEDGE flip-flops can be employed in
conjunction with the clock divider to obtain such a scenario. The state machine running at 1/8th
the system clock frequency can simply use the clock divider configured as divide by 8. Enabling
the DualEDGE flip-flop on macrocells assigned to the other state machine and assigning the
divide by 8 clock divider to those macrocells as well will yield an effective clock frequency that
is 1/4th the system clock frequency. This means that the single clock divider can obtain virtual
dual functionality of a divide by 8 and a divide by 4 counter. Notice that both clocks are
synchronized with each other and the system clock so that the two state machines operate
concurrently.
Summarizing the previous discussion, when utilizing the CoolRunner-II clock divider and/or the
DualEDGE flip-flops, it is possible to obtain clock divisors of 2, 3, 4, 5, 6, 7, 8, 10, 12, 14 and 16.
Additionally, when a group of macrocells use the clock divider and some of those macrocells
use DualEDGE flip-flops, the clock divider network can effectively deliver two clock frequencies
of divisors 1-2 (using CoolCLOCK described later), 2-4, 3-6, 4-8, 5-10, 6-12, 7-14, and 8-16.
When DualEDGE flip-flops are used with the clock divider, lower power is achieved while more
efficiently operating the design.
CoolCLOCK
CoolRunner-II CPLDs are equipped with a unique feature, CoolCLOCK, to further reduce the
power consumption of the global clock network without affecting the speed of the clock. Note
that CoolCLOCK does not impose additional clock delays. As explained earlier, any efforts to
reduce the clock frequency of the global clock net will significantly reduce power consumption.
CoolCLOCK reduces power consumed by the global clock net by dividing the external clock
frequency by 2 before it is applied to the global clock network. This clock division occurs early
in the clock tree near the clock input buffer so that the divided clock affects the majority of the
clock network. Since the global clock network contains a relatively large amount of internal
capacitance, a slower frequency will significantly reduce power consumed by this net, GCK2.
This divided clock signal is then effectively doubled at the macrocell using the DualEDGE
clocking feature of the flip-flops in the macrocell, shown in Figure 3. This ensures that the
original clock frequency is applied to the macrocell as intended by the external system. Only
macrocells that require the original clock frequency will be configured to utilize the DualEDGE

1-800-255-7778
R
flip-flop feature. Other macrocells can be configured to use the divided clock frequency to
further reduce power when those macrocells don’t require clocking at full speed.
D/T Q
PTC CE FIF
Latch
GCK0 CK ✓ DualEDGE
GCK1
CTC GCK2
PTC
÷2
÷4
÷6
GCK2 Clock ÷8
÷10
In
÷12
÷14
÷16
Synch Rst
Synch Reset
X377_03_041102
Figure 3: CoolCLOCK Created by Cascading Clock Divider and DualEDGE Option
Weak Pull-up and Bus Hold

All CoolRunner-II CPLDs include I/O termination options to reduce power consumption of the
I/O due to externally 3-stated busses. The I/O termination circuitry can be configured in three
ways: weak pull-up, bus hold, and no termination. Pull-up and bus hold are selected on a global
basis and are mutually exclusive. Subsequently, the use or absence of the selected termination
is specified on a per pin basis. Weak pull-up connects a high-impedance resistive load onto the
I/O pin to prevent a floating situation on the pin. Bus hold is essentially a full latch on the I/O pin
which drives the last state present on the I/O, either High or Low, prior to the bus going to the
high impedance state. Bus hold is referred to in the software as "Keeper".
Floating inputs, an input which is not driven to a High or Low logic state, can use excessive
power since the voltage on the gate of the input buffer may wander to a voltage level between
standard logic levels. In this case, the input buffer is driven into the linear region where the P
and N channel transistors are both switched on. Therefore, to avoid this situation, I/Os can be
configured to use internal pull-ups or bus hold circuitry. I/Os configured as inputs or
bidirectional should utilize this feature if it is known that the bus to which the I/O is attached will
float at some point in its regular operation.
There are some cases where weak pull-up is undesirable. If the bus is pulled down the majority
of time, current will flow through the weak pull-up to ground via the buffer, pulling the bus Low.
A design such as this would benefit by using the bus hold circuitry.
A rule of thumb for any CMOS device is to not allow inputs to float. These two features of
CoolRunner-II CPLDs, weak pull-up and bus hold, will minimize the chance of consuming
excessive power on input pins.
I/O termination should be considered for each application and each I/O to determine the best
combination to reduce power consumption. Again, avoid floating inputs whenever possible.
Slew Rate
This is a feature of the I/O structure that regulates the rate at which the output buffer changes
states. There are two modes: FAST and SLOW. Designers concerned with reducing reflections

1-800-255-7778
R
on circuit board traces, minimizing RFI or minimizing EMI should specify a SLOW slew rate.
Most design engineers considering low power designs will usually be designing slower speed
systems and therefore will not be as concerned with reflections. In a case such as this, the
system will benefit from a lower power perspective when slew rate is specified to be FAST.
Although an I/O is configured as an output, the input buffer is still connected to the pin and
therefore senses changes in voltage on that pin. If the output is configured with a SLOW slew
rate, the output voltage switches states less quickly, thereby lingering longer between standard
logic levels. The input buffer will therefore be driven in the linear region (the input voltage
between standard logic levels) for a longer period of time than if the output was configured in
the FAST slew rate mode. Current will flow through the input buffer P and N channel transistors
for a longer period of time resulting in higher power consumption. It is therefore recommended
to configure the output with a FAST slew rate whenever reflections are not a concern.
Power Saving Several rules of thumb should be followed when designing any circuit with CMOS devices to
Techniques reduce power consumption. A basic understanding of power consumption must be reached
prior to discussing these rules of thumb. Therefore, a derivation of the current equation for
CMOS devices is necessary. Once the mathematical model of current is understood, it
becomes easy to follow the theory of the rules of thumb. To maximize power savings, the
designer should apply these concepts when implementing any CMOS device.
Derivation of Current Equation in CMOS Devices

Since the CMOS device is constructed of PMOS and NMOS transistors, the dynamic model is
simply a capacitive structure for each transistor. Of course, the basic structure of a capacitor is
the dielectric between two plates. In this case, the dielectric of the capacitor is the oxide layer
on the silicon wafer and the plates are the poly or metal gate together with the inversion layer
in the channel. The interconnecting metal/poly routing is also modeled as a capacitor where the
plates are the routing itself together with any underlying routing or conductive material and the
dielectric is any non-conductive structure between the plates. With these capacitive structures,
the CMOS device is largely modeled as a collection of capacitors. Recall the basic equation for
current through a capacitor:
dV
I = C⋅
dt
Breaking the derivative into its components we can extract the basic equation for frequency,
which is the inverted value of a change in time, and simplify the equation:
1
I = C ⋅ dV ⋅ ----
dt
I = C ⋅ dV ⋅ f
Since the voltage for capacitive structures in CMOS devices changes as a square wave with
discontinuities between logic HighHigh and Low and is ideally rail to rail, we can further simplify
the equation. For example, in a system of supply voltage, V, the change in voltage, dV, is V to
0V as shown and reduced here:
dV = V 2 – V 1
dV = V – 0

1-800-255-7778
R
dV = V
Therefore the current equation for each capacitive structure becomes:
I = C⋅ V⋅ f
where:
• I = current in Amperes
• C = the capacitance of the capacitive structure in Farads
• V = the system voltage in Volts
• f = the toggle frequency of the capacitive structure in Hz
Dynamic device current is the summation of all capacitive structures toggling over time. Voltage
remains the same for all equations and can be assumed to be a constant. A device of n
capacitive structures can be represented as follows:
n
I Dynamic = V ⋅ ∑ Ci ⋅ fi
i=1
To obtain total device current, static current must be added to the dynamic current:
n
I Total = I Static + V ⋅ ∑ Ci ⋅ fi
i=1
For illustrational purposes, it may be easier to discuss total current using a simplified version of
this equation:
I CC = I CCQ + C ⋅ V ⋅ f
where:
• ICC = total device current in Amperes
• ICCQ = quiescent device current in Amperes
• C = the lumped capacitance of the device in Farads
• V = the system voltage in Volts
• f = the average device toggle frequency in Hz
Recall that to obtain power, multiply current by voltage to yield Watts.
Reduce System Speed

It becomes obvious from the equation that for a fixed device capacitance and voltage, reducing
the average device toggle rate will reduce power consumption.
Limiting the system clock speed as well as the data bus speed to slower values will reduce
power consumption since average device toggle rate will become smaller. Careful analysis of
the required CPLD clock speed is essential for low power design. Over-clocking the CPLD
design beyond the needs of the logic unnecessarily consumes extra power. Evaluating the
minimum required speed of the CPLD logic will ensure that the system clock will have a
minimal effect on power consumption.

1-800-255-7778
R
Drive Inputs to Standard Logic Levels

Power consumption will rise dramatically when a CMOS input buffer is not driven to known,
standard logic levels, otherwise known as allowing the input to "float". A voltage level between
standard logic levels causes the input buffer transistors, typically P and N channel, to be biased
in a manner where both are in the ON state. When biased in this way, a large amount of current
will flow between the power and ground supplies of the device via this channel. It is therefore
imperative to drive the input buffer to a known logic level High or Low state to turn off one of
these two transistors and avoid this situation.
The beauty of CMOS logic is that power consumption is nearly zero when logic gates are held
at a known logic input level. FZP technology found in CoolRunner-II CPLDs uses this principle
to provide dramatic power savings over other CPLDs.
Further, it is advised to drive the input to the full voltage rail on a High logic level and fully to
ground on a logic Low level. Even though the voltage level is within the acceptable logic levels,
i.e., VIH and VIL, the closer the voltage is to the absolute voltage rails, the less current will be
consumed in the input buffer. This effect is much less than the scenario where the input voltage
floats between logic levels, but nevertheless can have a significant impact on total power
consumption when summed across several I/Os.
Increase Input Edge Speed

CMOS device inputs that are driven by a slowly switching source will consume more power
since the input spends more time biased in the linear region. Again, the linear region is found
when an input is biased at a voltage between standard logic High or Low levels. When the
CMOS input buffer is biased in this manner, both the P and N channel transistors are turned on,
allowing a relatively large amount of current to pass to ground. The longer the buffer is biased
in this fashion, the more power will be consumed by the device. Therefore, it is recommended
to quickly switch the signal as it is applied to the inputs of the CMOS device. This applies to all
clock pins, dedicated input pins, or I/Os configured as inputs or bidirectional.
Eliminate Bus Conflicts

Occasionally, bus conflicts occur where two output buffers are driving a line at the same time in
opposite directions. This adversely affects logic performance as well as power consumption.
Two drivers attempting to swing the bus at opposite voltage levels will draw excessive current.
A similar situation occurs when a bus is pulled High via a pull-up resistor, for example, and the
output buffer is driving the bus Low. In this example, current will flow from the power source,
through the pull-up resistor, the N channel transistor in the output buffer, and to ground.
Current, in this case, is a function of the value of the pull-up resistor and the N channel
impedance. A weak pull-up resistor, on the order of 10k ohms or more, is a good place to start
if it is desired to use such a component. The larger the resistor, the less power will be
consumed, but this will slow down the bus response time when the resistor is required to
charge the bus to the High level if the bus is in the 3-state condition.
It is recommended to continuously drive a bus line High or Low with one device at a time and
remove pull-up resistors whenever possible to obtain the lowest power condition. In some
situations, this may not be possible. For example, an SMBus or I2C SDA line is required to be
released by all components but be at a High level when released. In this case, a pull-up resistor
is required.
Bus Terminations
A different case where pull down resistors are necessary is when shunt bus termination is
required to reduce reflections in high speed designs. These terminations are usually designed
to be pull down resistors whose value equals the equivalent impedance of the data bus
transmission line and are positioned as close to the load pin as possible. Whenever the output
buffer is driving a transmission line with shunt resistors, the P channel transistor will source
current into the load and therefore will raise power consumption.

1-800-255-7778
R
It may be possible to avoid using shunt termination resistors by using a very short transmission
line. The rule of thumb for a short transmission line is one whose length is less than one-sixth
the electrical length of the rise time, and is described using the following equation:
1 Trise
Length « --- ⋅ ------------
6 LC
where:
• Length = maximum line length in inches
• Trise = rise time in seconds
• L = the line inductance in Henries/inch
• C = the line capacitance in Farads/inch
By using the CoolRunner-II CPLD slew rate feature configured to SLOW, the rise time becomes
longer. Using the above equation, it can be determined if the length of the transmission line can
be effectively long enough to avoid reflections altogether. If by using the SLOW slew rate
feature, the length of the transmission line is short by the above rule of thumb, shunt bus
termination resistors can be avoided thereby saving power.
If either method is not an option, insert a series termination resistor positioned at the source pin
with the same value as the transmission line impedance. This option will avoid excessive power
consumption (since there is no shunt load) and eliminate reflections at the source. However, a
series termination resistor will allow one reflection at the load (since the load impedance does
not match the transmission line impedance) which implies that any component mid way
between the source and the load will see two transitions: the incident wave and the single
reflected wave created at the load.
Reduce System Voltage

Using the total current equation with fixed capacitance and average frequency, it becomes
readily apparent that reducing system voltage will reduce power consumption, provided the
system voltage remains within recommended operating specifications. Therefore, it makes
sense to use a 1.8V device in lieu of a 3.3V or 2.5V device. CoolRunner-II CPLDs are 1.8V
devices and therefore utilize this concept. Further, a device made with a smaller process
technology, such as CoolRunner-II CPLDs, will generally have lower lumped internal
capacitance values thereby reaching additional power savings. Combining these two factors
with reducing average system frequency will also cut power consumption.
With any voltage device, there is a recommended operating range, and it may be
advantageous to operate low in that voltage range to further reduce power consumption.
Voltages that are outside the recommended operating range may cause excessive power
consumption including adverse functional performance.
Reduce Bus Loading

Connecting an external bus to a CMOS device will increase power consumption due to the
loading effects of the bus on the device. The primary factor from loading is given by capacitive
or resistive bus components as seen by the output buffer looking into the bus.
Capacitive loading comes in two forms: lumped and distributed. Lumped capacitance is
typically found from the gate of the input buffer of other connected CMOS devices. It is also
developed from any capacitive element that is attached to the bus. Distributed capacitance is
present due to the routing of the trace on the PCB. Both types will charge and discharge during
logic transitions based on the previous logic state of the bus. Capacitive loading will draw
current from the CMOS device whose output buffer is driving the bus, thereby increasing
apparent power consumption of that device as seen at its power pins. To minimize power
consumption based on this capacitive loading effect, it is necessary to reduce the size of the
lumped capacitance found in attached devices, and to shorten the PCB traces. Doing so will
also increase potential system speed since reflections are less likely.

1-800-255-7778
R
Resistive loading is usually found when devices with a resistive element to their impedance is
attached to the bus. For example, a pull down resistor attached to a PCB trace will allow for
current to flow from the CMOS device power rail, through the P channel of the output buffer
transistor, through the resistor, and to ground, increasing observed power consumption at the
CMOS device power pins. Reducing resistive loads will reduce power consumption.
Keep in mind that many components are comprised of more than one type of impedance
element. For example, capacitors also have resistive and inductive elements, albeit small.
Further Power Saving Techniques

For further discussions regarding power saving techniques, particularly those involving logic
design, review XAPP346 - Low Power Tips for CoolRunner Design found at
http://direct.xilinx.com/bvdocs/appnotes/xapp346.pdf. Although the referenced application
note discusses CoolRunner XPLA3 CPLDs, the basic principles apply to CoolRunner-II
CPLDs.
Conclusion For the first time in the CPLD industry, CoolRunner-II products combine true high speed logic
with ultra low power. Unique features of the CoolRunner-II CPLD, such as CoolCLOCK and
DataGATE, allow the designer to further reduce power consumption. By using these features
combined with good design practice, as outlined in this document, designers can be assured
that their design will experience optimal low power benefits without sacrificing high speed.
References 1. Johnson H. and Martin G. (1993): High-Speed Digital Design: A Handbook of Black Magic
Prentice Hall PTR
History

1-800-255-7778
R
Chapter 3
Xilinx Design Software

Design Tools
Programmable logic design has entered an era in which device densities are measured in
the millions of gates, and system performance is measured in hundreds of megahertz.
Given these system complexities, the critical success factor in the creation of a design is
your productivity.
Xilinx offers complete electronic design tools that enable the implementation of designs in
Xilinx PLDs. These development solutions combine powerful technology with a flexible,
easy-to-use graphical interface to help you achieve the best possible designs within your
project schedule – regardless of your experience level.
The availability of products such as WebPACK ISE software has made it much easier to
design with programmable logic. Designs can be described easily and quickly using a
description language such as ABEL, VHDL, Verilog™, or with a schematic capture
package.
Schematic Capture Process

Schematic capture is the traditional method that designers have used to specify gate arrays
and programmable logic devices. It is a graphical tool that allows you to specify the exact
gates required and how you want them connected. There are four basic steps to using
schematic capture:
1. After selecting a specific schematic capture tool and device library, begin building the
circuit by loading the desired gates from the selected library. You can use any
combination of gates that you need. You must choose a specific vendor and device
family library at this time, but you don’t yet have to know what device within that
family you will ultimately use with respect to package and speed.
2. Connect the gates together using nets or wires. You have complete control and can
connect the gates in any configuration required by your application.
3. Add and label the input and output buffers. These will define the I/O package pins for
the device.
Programmable Logic Design www.xilinx.com 281

June 26, 2006
R
4. Generate a netlist.
Figure 3-1: PLD Design Flow
A netlist is a text equivalent of the circuit. It is generated by design tools such as a

schematic capture program. The netlist is a compact way for other programs to understand
what gates are in the circuit, how they are connected, and the names of the I/O pins. In the
example below, the netlist reflects the actual syntax of the circuit in the schematic. There is
one line for each of the components and one line for each of the nets. Note that the
computer assigns names to components (G1 to G4) and to the nets (N1 to N8). When
implementing this design, it will have input package pins A, B, C, and D, and output pins
Q, R, and S.
282 www.xilinx.com Programmable Logic Design

June 26, 2006
R
HDL Design Process
EDIF is the industry-wide standard for netlists; many others exist, including vendor-
specific ones such as the Xilinx Netlist Format (XNF). Once you have the design netlist, you
have all you need to determine what the circuit does.
Design Flow
STAT_MAC
Specification
clock CLK AUG amber_light
reset RESET GRN green_light
TIME (3.0) RG red_light
Libraries Counter
CLOCK COUNT (3.0)
RESET
Schematic
Capture Design Schematic
Netlist
101010101001110101010101
010101011110001110100111
101010101001110101010101
010101011110001110100111
101010101001110101010101
010101011110001110100111
101010101001110101010101
010101011110001110100111
Design Netlist
Figure 3-2: Design Specification – Netlist
The example on the previous pages is obviously very simplistic. Let’s describe a more
realistic design of 10,000 equivalent gates. The typical schematic page contains about 200
gates, contained with soft macros. Therefore, it would require 50 schematic pages to create
a 10,000-gate design! Each page needs to go through all the steps mentioned previously:
adding components, interconnecting the gates, adding I/Os, and generating a netlist. This
is rather time-consuming, especially if you want to have a 20,000, 50,000, or even larger
design.
Another inherent problem with using schematic capture is the difficulty in migrating
between vendors and technologies. If you initially create your 10,000- gate design with
FPGA vendor X and then want to migrate to a gate array, you would have to modify every
one of those 50 pages using the gate array vendor’s component library.
HDL Design Process

There has to be a better way, and, of course, there is. It is called high-level design (HLD),
behavioral, or hardware description language (HDL). For our purposes, these three terms
are essentially the same thing. The idea is to use a high-level language to describe the
circuit in a text file rather than a graphical low-level gate description. The term behavioral is
used because in this powerful language you describe the function or behavior of the circuit
in words rather than figuring out the appropriate gates needed to create the application.
There are two major flavors of HDL: VHDL and Verilog.
As an example, consider the design work needed specifying a 16 x 16 multiplier with
schematic capture or an HDL file. A multiplier is a regular but complex arrangement of
adders and registers that requires quite a few gates. Our example has two 16-bit inputs (A
and B) and a 32-bit product output (Y = A x B) – for a total of 64 I/Os. This circuit requires
approximately 6,000 equivalent gates. In the schematic implementation, the required gates

June 26, 2006
R
would have to be loaded, positioned on the page, and interconnected, with I/O buffers
added. That would be about three days of work.
The HDL implementation, which is also 6,000 gates, requires eight lines of text and can be
done in three minutes. This file contains all the information necessary to define our 16 x 16
multiplier. So, as a designer, which method would you choose? In addition to the
tremendous time savings, the HDL method is completely vendor-independent. This opens
up tremendous design possibilities for engineers.
$ESIGN&LOW
3PECIFICATION
,IBRARIES
3CHEMATIC
#APTURE
.ETLIST
$ESIGN3CHEMATICS
/2
ENTITY-5,4IS
PORT!"INSTD?LOGICDOWNTO
9OUTSTD?LOGICDOWNTO
END-5,4
ARCHITECTURE"%(!6%OF-5,4IS
BEGIN
9!
"
END"%(!6%

$ESIGN7RITTENIN($,
Figure 3-3: Design Specification – Multiplier
To create a 32 x 32 multiplier, you could simply modify the work you’d already done for
the smaller multiplier. For the schematic approach, this would entail making three copies
of the 30 pages, then figuring out where to edit the 90 pages so that they addressed the
larger bus widths. This would probably require four hours of graphical editing. For the
HDL specification, it would be a matter of changing the bus references from 15 to 31 in line
2, and 31 to 63 in line 3. This would probably require about four seconds.
HDL File Change Example

Before (16 x 16 multiplier):
entity MULT is
port(A,B:in std_logic(15 downto 0);
Y:out std_logic(31 downto 0));
end MULT;

June 26, 2006
R
HDL Design Process
architecture BEHAVE of MULT is

begin
Y <= A * B;
end BEHAVE;
After (32 x 32 multiplier):

entity MULT is
port(A,B:in std_logic(31 downto 0);
Y:out std_logic(63 downto 0));
end MULT;
architecture BEHAVE of MULT is

begin
Y <= A * B;
end BEHAVE;
HDL is also ideal for design re-use. You can share your “library” of parts with other
designers at your company, therefore saving and avoiding duplication of effort.
HDL Synthesis
Once we have specified the design in a behavioral description we can convert it into gates
using the process of synthesis. The synthesis tool does the intensive work of figuring out
what gates to use, based on the high-level description file you provide (using schematic
capture, you would have to do this manually.) Because the resulting netlist is vendor and
device family-specific, you must use the appropriate vendor library. Most synthesis tools
support a large range of gate array, FPGA, and CPLD device vendors.
In addition, you can specify optimization criteria that the synthesis tool will take into
account when making the gate-level selections, also called mapping. Some of these options
include: optimizing the complete design for the least number of gates, optimizing a certain
section of the design for fastest speed, using the best gate configuration to minimize power,
and using the FPGA-friendly, register-rich configuration for state machines.
You can easily experiment with different vendors, device families, and optimization
constraints, thus exploring many different solutions instead of just one with the schematic
approach.
To recap, the advantages of high level design and synthesis are many. It is much simpler
and faster to specify your design using HDL, and much easier to make changes to the
design because of the self-documenting nature of the language. You are relieved from the
tedium of selecting and interconnecting at the gate level. You merely select the library and
optimization criteria (e.g., speed, area) and the synthesis tool will determine the results.
You can also try different design alternatives and select the best one for your application. In
fact, there is no real practical alternative for designs exceeding 10,000 gates.
ISE Software
ISE advanced HDL synthesis engines produce optimized results for PLD synthesis, one of
the most essential steps in your design methodology. It takes your conceptual HDL design
definition and generates a logical or physical representation for the targeted silicon device.
A state-of-the-art synthesis engine is required to produce highly optimized results with a
fast compile and turnaround time. To meet this requirement, the synthesis engine must be
tightly integrated with the physical implementation tool and proactively meet design

June 26, 2006
R
timing requirements by driving the placement in the physical device. In addition, cross
probing between the physical design report and the HDL design code further enhances the
turnaround time.
Xilinx ISE software provides seamless integration with leading synthesis engines from
Mentor Graphics, Synopsys and Synplicity. The ISE product also includes Xilinx
proprietary synthesis technology, or XST. With just the push of a button, you can start any
leading synthesis engine within ISE. You can even use multiple synthesis engines to obtain
the most optimized result of your programmable logic design.
Design Verification
Programmable logic designs are verified by using a simulator, which is a software program
that confirms the functionality or timing of a circuit. The industry-standard formats used
ensure that designs can be reused. If a vendors changes its libraries, only a synthesis
recompile is necessary. Even if you decide to move to a different vendor and/or
technology, you are just a compile away after selecting the new library. It is even design-
tool independent, so you can try synthesis tools from different vendors and pick the best
results. IP cores are commonly available in HDL format, since that makes them easier to
modify and use with different device vendors.
After completing the design specification, you’ll need to know if the circuit actually works
as it’s supposed to. That is the purpose of design verification. A simulator simulates the
circuit. You’ll need to provide the design information (via the netlist after schematic

June 26, 2006
R
HDL Design Process
capture or synthesis) and the specific input pattern, or test vectors, that you want checked.
The simulator takes this information and determines the outputs of the circuit.
Specification
Libraries
HDL
Schematic Synthesis
Capture
Netlist
Verification
Simulation
Test
Vectors
Implementation
Translate
Fitting Timing Analyzer

Place & Route Back-Annotation
Download Device
Program
System Debug
Printed
Circuit Board
Figure 3-4: The PLD Design Flow
Functional Simulation
At this point in the design flow, a functional simulation only checks that the circuits give the
right combinations of ones and zeros. You should conduct a timing simulation a little later in
the design flow. If there are any problems, you can go back to the schematic or HDL file,
make changes, regenerate the netlist, and then rerun the simulation. Designers typically

June 26, 2006
R
spend 50% of their development time going through this loop until the design works as
required.
Using HDL offers an additional advantage when verifying the design: You can simulate
directly from the HDL source file. This bypasses the time-consuming synthesis process
that would normally be required for every design change iteration. Once the circuit works
correctly, running the synthesis tool generates the netlist for the next step in the design
flow – device implementation.
Device Implementation
A design netlist completely describes the design using the gates for a specific
vendor/device family. Once your design is fully verified, it is time to place it on a chip, a
process referred to as device implementation.
Translate comprises various programs used to import the design netlist and prepare it for
layout. The programs will vary among vendors. Some of the more common programs
during translate include: optimization, translation to the physical device elements, and
device-specific design rule checking (for example, does the design exceed the number of
clock buffers available in this device?). During this stage of the design flow, you will be
asked to select the target device, package, speed grade, and any other device-specific
options. The translate step usually ends with a comprehensive report of the results of all
the programs executed. In addition to warnings and errors is usually a listing of device and
I/O utilization, which helps you to determine if you have selected the best device.
Fitting
For CPLDs, this design step is called fitting, meaning to “fit” the design to the target device.
In the diagram above, a section of the design is fit to the CPLD. CPLDs are a fixed
architecture, so the software needs to pick the gates and interconnect paths that match the
circuit. This is usually a fast process.
The biggest potential problem is if you had previously assigned the exact locations of the
I/O pins, commonly referred to as pin locking. Most often, this occurs when using a legacy
design iteration that has been committed to the printed circuit board layout. Architectures
that support I/O pin locking (such as the Xilinx XC9500 and CoolRunner CPLDs) have a
very big advantage. They allow you to keep the original I/O pin placements regardless of
the number of design changes, utilization, or required performance. Pin locking is very
important when using ISP. If you layout your PCB to accept a specific pin out, and then
change the design, you can re-program confident that you pin out will stay the same.
Place and Route

For FPGAs, place and route programs are run after compile. “Place” is the process of
selecting specific modules, or logic blocks, in the FPGAs where design gates will reside.
“Route,” as the name implies, is the physical routing of the interconnect between the logic
blocks. Most vendors provide automatic place and route tools so that you don’t have to
worry about the intricate details of the device architecture. Some vendors offer tools that
allow expert users to manually place and/or route the most critical parts of their designs to
achieve better performance than with the automatic tools. Floorplanner is a type of manual
tool.
Place and route programs require the longest time to complete successfully because it’s a
complex task to determine the location of large designs, ensure that they all get connected
correctly, and meet the desired performance. These programs however, can only work well
if the target architecture has sufficient routing for the design. No amount of fancy coding

June 26, 2006
R
HDL Design Process
can compensate for an ill-conceived architecture, especially if there are not enough routing
tracks. If you were to encounter this problem, the most common solution would be to use
a larger device. And you would likely remember the experience the next time you selected
a vendor.
A related program is called timing-driven place and route (TDPR). This allows you to specify
timing criteria that will be used during device layout. A static timing analyzer is usually part
of the vendor’s implementation software. It provides timing information about paths in
the design. This information is very accurate and can be viewed in many different ways,
such as displaying all paths in the design and ranking them from longest to shortest delay.
In addition, at this point you can use the detailed layout information after reformatting
and go back to your chosen simulator with detailed timing information. This process is
called back-annotation and has the advantage of providing the accurate timing as well as the
zeros and ones operation of your design. In both cases, the timing reflects delays of the
logic blocks as well as the interconnect. The final implementation step is the download or
program.
Downloading or Programming
Download generally refers to volatile devices such as SRAM FPGAs. As the name implies,
you download the device configuration information into the device memory. The
bitstream that is transferred contains all the information to define the logic and
interconnect of the design and is different for every design. Because SRAM devices lose
their configuration when the power is turned off, the bitstream must be stored somewhere
for a production solution. A common such place is a serial PROM. There is an associated
piece of hardware that connects from the computer to a board containing the target device.
Program is used to program all non-volatile programmable logic devices, including serial
PROMs. Programming performs the same function as download, except that the
configuration information is retained after the power is removed from the device. For
antifuse devices, programming can only be done once per device – hence the term one-
time programmable. Programming of Xilinx CPLDs can be done in-system via JTAG or
with a conventional device programmer such as Data I/O. JTAG Boundary Scan –
formally known as IEEE/ANSI standard 1149.1_1190 – is a set of design rules that facilitate
testing, device programming, and debugging at the chip, board, and system levels.

June 26, 2006
R
In-system programming has an added advantage in that devices can be soldered directly
to the PCB (such as TQFP surface-mount-type devices). If the design changes, the devices
do not need to be removed from the board but simply re-programmed in-system.
ISP – In System Programming and Downloading
Libraries Download
Cable
HDL
Schematic Synthesis
Capture
Netlist
Verification
Simulation Target Device

on PCB
Test
Vectors
Conventional Programming
Implementation Target
Device
Translate
Fitting Timing Analyzer

Place & Route Back-Annotation
Download Device
Program
Programmer
Figure 3-5: Device Implementation – Download/Program
System Debug
The device is now working, but you still need to verify that the device works in the actual
board, a process called system debug. Any major problems here mean that you have made
an assumption on the device specification that is incorrect, or have not considered some
aspect of the signal required to/from the programmable logic device. If so, you can collect
data on the problem and go back to the drawing (or behavioral) board. The “Design Tools
Center” web pages cover both the Xilinx ISE tools suite as well as design tools from our
software partners. It is arranged by the following topics:
Dynamic Verification
You can save time by using dynamic verification to intercept logical or HDL-based errors
early in the design cycle. By exposing a design to realistic and extensive stimuli, you can
find many functional problems at this stage. The following dynamic verification tools are
supported:

June 26, 2006
R
Advanced Design Techniques
• HDL Bencher™
• ISE Simulator
• ModelSim XE
• StateBench
• HDL Simulation Libraries
Debug Verification
Debug verification tools speed up the process of viewing, identifying, and correcting
design problems at different stages of the design cycle. Debug verification includes the
ability to view, “live,” all internal signals and nodes within an FPGA. These tools can also
assist in HDL-based designs by checking coding style for optimum performance. The
following debug verification tools are supported:
• FPGA Editor Probe
• ChipScope ILA
• ChipScope Pro
Board-Level Verification
Using board-level verification tools ensures that your design performs as intended once
integrated with the rest of the system. The Xilinx ISE environment supports the following
board-level verification tools:
• IBIS Models
• Tau
• BLAST
• Stamp Models
• iMPACT
Advanced Design Techniques

As your FPGA requirements grow, your design problems can change. High-density design
environments mean multiple teams working through distributed nodes on the same
project, across the aisle or in different parts of the world. ISE software’s advanced design
options are targeted at making high-density designs as easy to realize as the smallest glue
logic.
Floorplanner – The Xilinx high-level floorplanner is a graphic planning tool that lets you
map your design onto the target chip. Floorplanning can efficiently drive your high-
density design process.
Modular Design – This gives you the ability to partition a large design into individual
modules. Each module can then be floorplanned, designed, implemented, and locked until
the remaining modules are finished.
Partial Reconfigurability – Useful for applications requiring the loading of different
designs into the same area of the device, partial reconfiguration allows you to flexibly
change portions of a design without having to reset or completely reconfigure the entire
device.
Internet Team Design – This allows managers to drive each team and its design module
from a standard Internet browser using the corporate intranet structure.

June 26, 2006
R
High-Level Languages – As design densities increase, the need for a higher level of
abstraction becomes more important. Xilinx is driving and supporting industry standards
and their respective support tools.
Embedded SW Design Tools Center

Embedded Software Tools are for Virtex-II Pro and Virtex-4 Platform FPGAs. The term
"embedded software tools" most often applies to the tools required to create, edit, compile,
link, load, and debug high-level language code, usually C or C++, for execution on a
processor engine. With the Virtex-4 and Virtex-II Pro Platform FPGAs, you will be able to
target design modules for either silicon hardware (FPGA gates) or as software
applications, running on process engines like the embedded PowerPC hard core.
When it comes to embedded software development, Xilinx offers multiple levels of
support. Xilinx supports the embedded processors with the Embedded Development Kit
(EDK) for both low-cost and high-performance markets. More details on EDK can be
found in the Design Tools Centre on the Xilinx website.
For hardware-centric engineers who want to move design modules into software running
on the PowerPC core, Xilinx provides a simple and low-cost solution. Alternatively, if
software-centric engineers want a feature-rich environment in which to develop more
complex applications, Xilinx supplies access to specialized best-of-class tools from the
embedded industry leader. This prevents you from having to embrace completely new
development methodologies. You will be able to port existing legacy designs more easily
to the Xilinx Platform FPGAs.
ISE WebPACK Software

The ISE WebPACK software, the only free downloadable design environment supported
on Linux, is a reduced feature set version of the complete ISE tool suite. The full version of
the ISE software, known as ISE Foundation, has all the tools necessary to complete a design
targeting any architecture available from Xilinx. The ISE WebPACK tool set comprises all
the tools necessary to complete designs targeted to Xilinx CPLDs and some Xilinx FPGAs.

June 26, 2006
R
This chapter explains what is available in ISE WebPACK and gives details on how to go
about registering and installing the software.
Table 3-1: WebPACK Operating System and Device Support
Feature ISE WebPACK
Microsoft Windows 2000/XP
Operating Systems
Redhat Enterprise Linux 3 (32-bit)
Virtex: XCV50 - XCV600
Virtex-E: XCV50E - XCV600E
Virtex-II: XC2V40 - XC2V500
Virtex-II Pro: XC2VP2 - XC2VP7
Virtex-4:
Virtex Series LX: XC4VLX15, XC4VLX25
SX: XC4VSX25
FX: XC4VFX12
Virtex Q: XQV100 - XVQ600
Virtex QR: XQVR300 - XVQR600
Virtex-EQ: XQV600E
Spartan-II/IIE: All
Spartan-3: XC3S50 - XC3S1500
Spartan Series Spartan-3E: All
Spartan-3L: XC3S1000L, XC3S1500L
XA (Xilinx Automotive) Spartan-3: All
CoolRunner-II/A
All
CoolRunner XPLA3
XC9500/XL/XV All
Registration and Installation

The ISE WebPACK software is available from two sources, on CD and as a download from
the internet. If this book was received as part of a CoolRunner-II or Spartan-3 Design Kit, it
will have been accompanied by a copy of ISE WebPACK on CD. That CD will have a
Product ID that will need to be registered to generate a registration key that will enable
installation. This registration process and the downloading of the software can both be
done from the ISE WebPACK main page for which visitors need to register. This page can
be found by navigating as follows:
www.xilinx.com → Products and Services → Design Tools → ISE WebPACK
To register a CD, click on the button. After completion of a short

survey, there will be an option to register the software. The web page asks for a Product ID.
This is usually on a sticker on the CD pack and takes the form ABC123456789. Once this
has been entered, the 16 digit registration ID will be displayed on the following web page
as well as emailed to the email address of the user.

June 26, 2006
R
To download the software, click the button. This will offer the
option to download the complete ISE WebPACK tool suite, only the tools required for
CPLD designs or only the programming tools. Xilinx recommends that, if the space is
available, the entire tool suite is downloaded. Once the appropriate design tools have been
downloaded, the software can be installed by simply double clicking on the self-extracting
zip file.
Module Descriptions
In general, the design flow for FPGAs and CPLDs is very similar. Design Entry can be done
in Schematic or HDL, such as VHDL, Verilog or, for CPLDs only, ABEL. The design can
also comprise of a mixture of schematic diagrams and embedded HDL symbols. There is
also a facility to create state machines in a diagrammatic form and let the software tools
generate optimized code from a state diagram. All these steps will be seen in Chapter 4, ISE
WebPACK Design Entry.
WebPACK ISE software incorporates the ISE Simulator Lite – Xilinx’ new simulation tool.
This tool will be used in the tutorial section of this book. The full version of the ISE
Simulator is available in the full feature set ISE Foundation software. There is also the
option to download the ModelSim Xilinx Edition (MXE) software. This is a version of
Mentor Graphics’ ModelSim simulator with the Xilinx libraries precompiled. For more
information on the MXE software, refer to:
www.xilinx.com > Products and Services →Design Tools → Verification

June 26, 2006
R
The flow diagram below shows the similarities and differences between CPLD and FPGA
software flows.
Schematic HDL Design State Machine

Entry
ECS HDL Editor StateCad
Synthesis
Xilinx Synthesis Technology (XST)
Translate
NGDBuild
CPLD FPGA
Fit Implement
CPLD Fitter MAP/PAR
Estimate Power
XPower
Program
IMPACT Programmer
Testbench Simulate
HDL Bencher ModelSim XE
Figure 3-6: WebPACK Software Design Flow
When your design is complete and you are happy with the simulation results, you can then
download the design to the required device.

June 26, 2006
R
Getting Started
Licenses
The MXE Simulator is the only tool that requires a license. MXE Simulator is licensed via
the FlexLM product from Macrovision. It requires you to situate a starter license file on
your hard drive, pointed to by a set lm_license_file environment setting. The license
is free and you apply for it online after installation, after which you will receive a
license.dat file via email.
From the Start menu, go to Programs → ModelSimXE → Submit License Request
Projects
When starting a project the default location of the project will be:
c:\Xilinx_WebPACK\bin\nt
You can create a unique directory on your hard drive for working on projects, for example:
c:\my_projects.
Should you need to uninstall and reinstall WebPACK ISE software due to problems on
your system, we recommend that you delete the entire WebPACK ISE directory structure.
Updating Software
Between major releases of software, Service Packs are released to keep the software fully
up to date. Service Packs often include new device features, updated characterization data
and minor improvements to the tools. Xilinx recommends that, if a Service Pack is
available for a version of the ISE WebPACK software, you install it at the earliest possible
convenience.
Summary
In this chapter, we demonstrated how to access and install the ISE WebPACK software, and
listed the devices it supports.
The next section will show how to embark upon a PLD design for the first time using the
powerful features of WebPACK ISE software. The example design is a simple traffic light
controller that uses a VHDL counter and a state machine. The design entry process is
identical for CPLDs and FPGAs.

June 26, 2006
R
Chapter 4
WebPACK ISE Design Entry

This chapter describes a step-by-step approach to a simple design. The following pages are
intended to demonstrate the basic PLD design entry and implementation process. In this
example tutorial, you’ll design a simple traffic light controller in VHDL. Our design is
initially targeted at the CoolRunner-II CPLD that is on the board in the CPLD Design Kit.
If you received this manual as part of the design kit, you can try to populate the board to
build a working hardware design. If you received this manual alone, you can purchase a
Design Kit from www.xilinx.com →Buy Online. We also show how you can convert the
project to target a Spartan-3E FPGA.
Design Entry
To start WebPACK ISE software, select in Windows:
Start → Programs → Xilinx ISE 8 → Project Navigator
To create a new project:
1. Select in Project Navigator: File → New Project.
Figure 4-1: New Project Window – Project Name
2. Call the project “Traffic” and put it in your Designs directory. For this tutorial, we will
be using an HDL top level.
3. Click the Next> button.
4. Enter the following into the New Project dialog box:

June 26, 2006
R
Device Family: CoolRunner-II

Device: xc2c256
Package: TQ144
Speed Grade:- -7
Synthesis Tool: XST (VHDL/Verilog)
Simulator:I ISE Simulator (VHDL/Verilog)
Figure 4-2: New Project Window – Device and Design Flow

6. Add a new source to the project by clicking on the New Source button.
7. Add a VHDL module and call it “Counter.”
Figure 4-3: New Source Window

June 26, 2006
R
Design Entry
9. Create a 4-Bit Counter Module
Figure 4-4: Define VHDL Source Window
10. Declare three ports: “clock,” “reset,” and “count.” The clock and reset ports should
both be of direction “in”. Count should be direction “inout” and should be a 4-bit
vector with MSB 3, LSB 0.
11. Click the Next> button and the Finish button as many times as needed to get to the
design summary window. Review the contents of the final window and click the
Finish button.
This has automatically generated the entity in the counter VHDL module. Notice that a file
called “counter.vhd” has been added to the project in the Sources in Project window of the
Project Navigator.
Figure 4-5: Source in Project Window

June 26, 2006
R
The source code will open automatically but if you do not see it, you can double-click on
this source (highlighted in Figure 4-5) to open it in the WebPACK ISE Editor window.
Figure 4-6: Counter Window
You can remove the source files from the WebPACK ISE GUI by clicking
Window → Float in the ISE Menu. As the project builds, you will notice how the
WebPACK ISE tool manages hierarchy and associated files in the Sources window.
HDL Editor
Double-clicking on any file name in the Sources window allows that file to be edited in the
main Text Editor.
The Language Template

The language template is an excellent tool to assist you in creating HDL code. It has a range
of popular functions such as counters, multiplexers, decoders, and shift registers. It also
has templates for creating common operators (such as “IF/THEN” and “FOR” loops) often
associated with software languages.
Language templates are used as a reference. They can be copied and pasted into the design,
then customized for their intended purpose. Usually, you must change the bus width or
signal names, and sometimes modify the functionality.

June 26, 2006
R
Design Entry
In this tutorial, the template uses the signal name “clk.” The design requires the signal to
be called “clock.” The counter in the template is too complex for this particular
requirement, so some sections are deleted. To use the language template:
1. In the HDL Editor place the cursor between begin and end Behavioral.
2. Open the language templates by clicking the button
You can also access the language template from the Edit →Language Template
menu.
3. Navigate to the Simple Counter in the Language Templates as follows:
VHDL → Synthesis Constructs → Coding Examples → Counters →
Binary →Up Counters → Simple Counter
4. With Simple Counter highlighted select:
Edit → Use in File
5. Select the Counter tab on the HDL Editor. This will switch you back to the HDL
Editor while leaving the Language Template open in another tab.
You will see the simple counter code has been entered into file.
Notice the color-coding used in the HDL Editor. The green text indicates a comment. The
commented text in this template shows which libraries are required in the VHDL header.
The port definitions are required if this counter was used in its entirety. As you have
already created the entity, this information is not required. You can delete the green
comments if you wish.
The counter from the template shows a loadable bidirectional counter. For this design, only
a 4-bit up counter is required.
Edit the Counter Module

1. Remove the brackets <> around the words “clock” and “count” in the code you have
just pasted into the Counter.vhd file.
The next step is to edit the code to include a reset. Currently, the code looks like this:
process (clock)
begin
if clock='1' and clock'event then
count <= count + 1;
end if;
end process;
2. To add in a reset line is simple. You will need to edit the code to look like this:
process (clock, reset)
begin
if reset='1' then
count <= "0000";
elsif clock='1' and clock'event then
count <= count + 1;
end if;
end process;
Note the changes are:
a. Addition of if reset='1' then

June 26, 2006
R
b. Addition of the line count <= "0000";

c. Addition of reset in the process sensitivity list
d. Changing if to elsif before clock='1'
The counter module should now look like Figure 4-7. For the purposes of debugging code,
several new features are available in the Source Editor window. A right-click in the gray
bar on the left side of the Source Editor window will bring up a menu of these features. You
can toggle the line numbers in the side bar on or off and place bookmarks to mark lines of
interest in the source file.
Figure 4-7: Counter in VHDL Window
A typical VHDL module consists of library declarations, an entity, and an architecture. The
library declarations are needed to tell the compiler which packages are required. The entity
declares all ports associated with the design. Count (3 down to 0) means that count is a 4-
bit logic vector.
This design has two inputs – clock and reset – and one output, a 4-bit bus called “count.”
The actual functional description of the design appears after the begin statement in the
architecture. The function of this design is to increment a signal “count” when clock = 1
and there is an event on the clock. This is resolved into a positive edge. The reset is
asynchronous as is evaluated before the clock action.
The area still within the architecture – but before the begin statement – is where
declarations reside. We’ll give some examples of component and signal declarations later
in this chapter.
Save the Counter Module

You can now simulate the counter module of the design. With “counter.vhd” highlighted
in the Source window, the Process window will give all the available operations for that
particular module. A VHDL file can be synthesized and then implemented through to a

June 26, 2006
R
bitstream. Normally, a design consists of several lower-level modules wired together by a

top-level file. This design currently only has one module that can be simulated.
To simulate a VHDL file, you must first create a testbench.
1. From the Project menu, select “New Source” as before.
2. Select “Test Bench Waveform” as the source type and give it the name “counter_tb.”

4. The testbench is going to simulate the counter module, so when asked which source
you want to associate the source with, select “Counter” and click the Next> button.
5. Review the information and click the Finish button.
6. The HDL Bencher tool now reads in the design. The “Initialize Timing” box sets the
frequency of the system clock, setup requirements, and output delays. The demoboard
in the CPLD Design Kit has a 1.842MHz oscillator on the board. So, we shall enter a

June 26, 2006
R
540ns clock period or a Clock High and Clock Low time of 270ns, Input Setup and
Output Valid times of 50ns and an Initial Testbench Length of 10000ns.
Figure 4-9: Initial Timing and Clock Wizard
7. Click Finish
Figure 4-10: HDL Bencher Window
Note that the blue cells are for entering input stimulus and the yellow cells are for
entering expected response.
8. When entering a stimulus, clicking the left mouse button on the cell will cycle through
the available values for that cell. Click on the first blue box in the reset line. This will

June 26, 2006
R
change its value from 0 to 1. Click the third blue box in the reset line and it will change
from 1 to 0. You have now entered a reset pulse two clock cycles in length. Save the file.
The ISE Sources in Project window should look like image below.
Figure 4-11: Sources For Behavioral Simulation
9. To simulate the test bench in the ISE Simulator, you first need to change the sources
you are viewing away from those for Synthesis/Implementation to those for
Behavioral Simulation. Select Behavioral Simulation from the Sources drop-
down menu.
Figure 4-12: Selecting Behavioral Process Trees

June 26, 2006
R
10. Check that the Counter source is still highlighted and with the Processes tab selected,
double click Simulate Behavioral Model in the Process window (you may need
to click the plus sign next to Xilinx ISE Simulator).
Figure 4-13: Simulate Behavioral Model
11. The simulation is automatically compiled by the ISE WebPACK software and when it
is complete, the ISE Simulator Waveform window opens showing the result of the
simulation. Click on the plus sign next to the COUNT bus so that it is possible to see all
four signals that make up the bus individually.
Figure 4-14: Behavioral Simulation Results
12. The behavior of this circuit is as we expected. It increments the count signal by one on
every rising edge of the clock. So, as this section works, we can continue to build our
design. First we will take a snapshot so that we can refer back to this stage in the design

June 26, 2006
R
State Machine Editor
process if necessary. To take a snapshot of your design select Project → Take

Snapshot.
Figure 4-15: Project Snapshot Window
Taking a snapshot of your project saves the current state of your project in a
subdirectory (with the same name as the snapshot) so that you can go back to it in the
future. You can view project snapshots by selecting the Sources window snapshot tab
in the Project Navigator. If the design had only one module (one level of hierarchy), the
implementation phase would be the next step. This design, however, has a further
module to represent a more typical VHDL design.

For our traffic light design, the counter acts as a timer that determines the transitions of a
state machine. The state machine will run through four states, each state controlling a
combination of the three lights.
State 1: Red Light
State 2: Red and Amber Light
State 3: Green Light
State 4: Amber Light
To invoke the state machine editor:
1. Select New Source from the project menu.
2. Highlight State Diagram and give it the name “stat_mac”

June 26, 2006
R
3. Click the Next> button, then the Finish button.
The State Machine will appear.

4. Open the State Machine Wizard by clicking on the button in the main toolbar.
The State Machine Wizard will appear.
Figure 4-17: State Machine Wizard Window

June 26, 2006
R
5. Set the number of states to “4” and hit the Next> button.
Figure 4-18: Reset Mode Dialog Box
6. You will see a dialog box for selecting Reset Mode. Check to see that Synchronous
is selected, then click the Next> button to build a synchronous state machine.
7. Next, you will see the Setup Transitions dialog box. Type “TIMER” in the Next
field (shown in Figure 4-19).
Figure 4-19: Setup Transitions Window
8. Click on the Finish button and drop the state machine on the page by clicking
anywhere on the page.
Double-click on Reset State 0 (yellow oval). Rename the state name “RED.”
Figure 4-20: Edit State

June 26, 2006
R
9. Hit the Output Wizard button.

This design will have three outputs named RD, AMB, and GRN.
10. In the DOUT field, type “RD” to declare an output. Set RD to a constant “1” with a
registered output, as shown below.
Figure 4-21: Logic Wizard Window
11. Click on OK and then OK the Edit State box.

12. In a similar fashion, edit the other states.
a. Rename State 1 to “REDAMB” and use the output wizard to set RD = 1, and a new
output AMB equal to “1” with a registered output. You will have to cycle twice
through the Output Wizard to create the two outputs.
b. Rename State 2 to “GREEN” and use the output wizard to set a new output GRN
equal to “1” with a registered output.
c. Rename State 3 to “AMBER” and use the output wizard to set AMB = 1.
The state machine should look like Figure 4-22 below. (If you set a signal as registered
in the Output Wizard and then select Signal and re-open the wizard, it is no longer
ticked as registered.)
Figure 4-22: State Diagram
13. Click on the transition line between state “RED” and state “REDAMB.”

June 26, 2006
R
14. The Edit Condition dialog will appear. In the Edit Condition window, set a
transition to occur when timer is 1111 by editing the Condition field to TIMER =
“1111.” (Don’t forget the double quotes (“), as these are part of VHDL syntax.).
Figure 4-23: Edit Conditions Window
15. Repeat for the other transitions:

a. Transition REDAMB to GREEN, TIMER = “0100”
b. Transition GREEN to AMBER, TIMER = “0011”
c. Transition AMBER to RED, TIMER = “0000”
Hence, the traffic light completes a RED, REDAMB, GREEN, AMBER once every three
cycles of the counter.
16. Finally, declare the vector TIMER by clicking on the button on the left-hand side of the
toolbar.
17. Drop the marker on the page, double-click on it, and enter the name “TIMER” with a
width of 4 bits (Range 3:0).
Figure 4-24: Edit Vector Window

June 26, 2006
R
18. Click OK. Your completed state machine should look like this.
Figure 4-25: State Machine Drawing
19. Click on the Generate HDL button on the top toolbar.
20. The Results window should read “Compiled Perfectly.” Close the dialog box and the
generated HDL Browser window.
Figure 4-26: Compiled Results

June 26, 2006
R
Top-Level VHDL Designs
21. When you click the Close button a VHDL listed for the State Machine will open in the
StateCAD HDL Browser.
Figure 4-27: StateCAD Browser
22. Save and close StateCAD. Use menu items File → Save and File → Exit.
The state diagram will be added to the top of the Sources window. (Double- clicking on
this file will open up the state diagram in StateCAD.)
Figure 4-28: Source in Project Window Showing Model View

At this point in the flow, two modules in the design are connected together by a top-level
file. Some designers like to create a top-level schematic diagram, while others like to keep
the design entirely code-based. Because this section discusses the latter, the counter and
state machine will be connected using a top.vhd file. If you prefer the former, jump directly
to the next section, “Top-Level Schematic Designs,” page 321.
To create a top-level VHDL file:

June 26, 2006
R
1. Back up what you have done so far by taking a snapshot of the project. Use the menu
bar and click Project → Take Snapshot. Select a snapshot name and click OK.
Figure 4-29: Project Snapshot
2. From the Project menu, select New Source and create a VHDL module called
“top.”
Figure 4-30: New Source Window Showing VHDL Module
3. Click on the Next> button and fill out the Define VHDL Source dialog box, as
shown in Figure 4-31.
Figure 4-31: Define VHDL Source Window

June 26, 2006
R
4. Click on the Next> button, then the Finish button.

Your new file, “top.vhd,” should look like Figure 4-32.
Figure 4-32: New VHDL File
5. In the Sources window, highlight the “counter.vhd” module.”In the Processes

window, double-click View VHDL Instantiation Template from the Design
Utilities section.
6. Highlight and copy the component declaration and instantiation.
Figure 4-33: Instantiation Template
7. Paste the component declaration and instantiation into “top.vhd.”

June 26, 2006
R
8. Rearrange the component declaration so that it lies before the begin statement in the
architecture. Rearrange the instantiation so that it lies between the begin and end
statement (see Figure 4-34 for reference).
Figure 4-34: Instantiation Template Code Added to Top File
9. Now we need to manually enter the component declaration and instantiation for the
state machine as follows. Beneath the Counter component declaration enter the
following:
COMPONENT stat_mac
PORT(
timer : IN std_logic_vector(3 downto 0);
clk : IN std_logic;
reset : IN std_logic;
amb : OUT std_logic;
rd : OUT std_logic;
grn : OUT std_logic
);
END COMPONENT;
10. Next is the instantiation of the state machine module. Enter the following text under
the Counter instantiation.
Inst_stat_mac: stat_mac PORT MAP(
timer => ,
clk => ,
reset => ,
amb => ,
grn => ,
rd =>
);
11. Declare a signal called “timer” by adding the following line above the component
declarations inside the architecture:
signal timer : std_logic_vector(3 downto 0);

June 26, 2006
R
12. Connect the counter and state machine instantiated modules so that your “top.vhd”
file looks like the code below.
Figure 4-35: top.vhd File

June 26, 2006
R
13. Connect the signals by adding their names to the PORT MAP as follows:
Figure 4-36: Top Level Signal Connections
14. When you save “top.vhd” (File → Save), notice how the Sources window
automatically manages the hierarchy of the whole design, with “counter.vhd” and
“stat_mac.dia” becoming sub-modules of “top.vhd” the latter of which automatically
displays the top level icon.
15. It is now necessary to add in the generated VHDL into the project so that it can be
implemented and simulated. Click the Libraries tab at the bottom of the sources
window, expand the “work” tree, right click the file “STAT_MAC.vhd” and select
properties (Source →Properties). Change the association of the two files

June 26, 2006
R
Simulate the Design
STAT_MAC Behavior and SHELL_STAT_MAC BEHAVIOR from “None” to

“Synthesis/Imp + Simulation” as shown below.
Figure 4-37: Source Libraries and Properties
16. Click OK to accept the changes and, when you return to the Sources tab, it should look
like this:
Figure 4-38: Project Sources Tree
17. Take a snapshot of the design as before (using Project → Take Snapshot…) only
this time, call it “snap3” and type “VHDL top” in the comments window.
Simulate the Design

You can now simulate the entire design.

June 26, 2006
R
1. Add a new testbench waveform source as before, but this time, associate it with the
module “top.” Use Project → New Source, select Testbench Waveform and
name it “Simulate_Top.”
Figure 4-39: New Source Wizard
2. The Associate Source dialog box will appear. Make sure “Top” is highlighted and
click the Next> button. Then click Finish on the next dialog box.
3. In the Initialize Timing dialog box, set a clock high and low time of 270ns each,
as before and change the testbench length to 10000 cycles. Click OK.
Figure 4-40: Settings for Initialize Timing
4. In the waveform diagram, enter the input stimulus as follows:

June 26, 2006
R
Top-Level Schematic Designs
a. Set the RESET cell below CLK cycle 1 to a value of “1.”

b. Click the RESET cell below CLK cycle 3 to a value of “0”.
Figure 4-41: Waveform Diagram
Note: In Figure 4-41 the End Time of 100000 ns will create a more compressed diagram. To scale
as shown above, right click on one of the time intervals (for instance, 2430 ns) and select Rescale
Timing. Set the timing to 10000 ns to get a scale similar to above. You may have to rescale the
timing again to get the scaling shown in Figure 4-42.
5. Click the save icon.
The “top_tb.tbw” file will now be associated with the top-level VHDL module when
viewing files in the Behavioral Simulation view.
6. Double-click on Simulate Behavioral Model in the Process window.
Figure 4-42: Waveform Window
If the simulation works correctly, you will get a display as shown in Figure 4-42. If you
would like to learn how to create schematic top level files, please carry on reading. If you
are not interested in schematic top level files, please go straight to the next chapter of this
handbook.

Sometimes, it’s easier to visualize designs when they have a schematic top level that
instantiates the individual blocks of HDL. The blocks can then be wired together in the
traditional method. For designs in the WebPACK ISE tool, the entire project can be
schematic- based.
This section discusses the method of connecting VHDL modules via the ECS schematic
tool. If you worked through the previous section, you will first need to remove the top
level VHDL file top.vhd from the project. To do this, highlight the file in the sources for
Synthesis/Implementation View, right click and select Remove then click the Yes button

June 26, 2006
R
in the dialog box. Then remove it from the Window view by selecting the Top tab and
Window → Close. You can remove the simulation tabs in the same manner.
This action will take you back to the stage in the flow with only the “counter.vhd” and the
“stat_mac.vhd” files. The Sources window module view should look like Figure 4-43
below.
Figure 4-43: Sources in Project Window
ECS Hints
The ECS schematic capture program is designed around you selecting the action you wish
to perform, followed by the object on which the action will be performed. In general, most
Windows applications currently operate by selecting the object and then the action to be
performed on that object. Understanding this fundamental philosophy of operation makes
learning ECS a much more enjoyable experience.
Creating a Top Level Schematic Design

1. From the Project menu, select New Source → Schematic and give it the name
“top_sch.”
Figure 4-44: New Source Window Showing top_sch
2. Click the Next> button, then the Finish button. The ECS Schematic Editor
window will now appear. There will also be an Options tab in the Processes
window.

June 26, 2006
R
3. In the Sources window, highlight “counter.vhd.” If you do not see “counter.vhd’”

check to see that the Synthesis/Implementation view and the Source tab have been
selected as shown in Figure 4-43.
4. In the Process window, select the Processes tab and double-click on Create
Schematic Symbol from the Design Utilities sub-section (you may need to
click on the plus sign to see it). This will create a schematic symbol and add it to the
library in the Schematic Editor.
5. Create another symbol – this time for the state machine – by highlighting
“stat_mac.vhd” and double-clicking on Create Schematic Symbol.
6. Returning to the Schematic editor, the symbol libraries can be found under the Symbol
tab on the right hand tab in the Sources window (you may need to expand the
window to get a better view).
Figure 4-45: Symbols
7. Add the counter and state machine by clicking on the new library (C/Designs/Traffic)
in the Categories window then selecting “Counter.” Move the cursor over the sheet
and drop the counter symbol by clicking where it should be placed. Move the cursor
back into the Categories window and place the “stat_mac” symbol on the sheet.

June 26, 2006
R
8. Zoom in using the button so your zoom button and the window looks like Figure 4-46.
Figure 4-46: Close-up of Counter and State Machine Symbols
9. Select the Add Wire tool from the Drawing toolbar.
10. To add a wire between two pins, click once on the symbol pin and once on the
destination pin. ECS will let you decide whether to use the Autorouter or manually
place the signals on the page. To add a hanging wire, click on the symbol pin to start
the wire once at each vertex. Then double-click at the location where you want the wire
to terminate.
11. Wire up the counter and state machine as shown below:
Figure 4-47: Counter and State Machine Symbols with Wire

June 26, 2006
R
12. Select the Add Net Names tool from the Drawing toolbar.
13. Type “clock” in the Name bar of the Options tab (Processes window) and then click on
the net in the schematic editor.
Figure 4-48: Add Net Name
14. To add net names to wires that will be connected to your FPGA/CPLD I/Os, place the
net name on the end of the hanging wire. Finish adding the net names “reset”,
“amber_light”, “green_light” and “red_light”. ECS recognizes that count(3:0) and
TIMER(3:0) are buses, and so connects them together with a bus rather than a single
net.
I/O Markers
15. Select the Add I/O Marker tool from the Drawing toolbar.
16. With the Input type selected, click and drag around all the inputs to which you want to
add input markers. Repeat for the outputs but select Output type.

June 26, 2006
R
Your completed schematic should look like Figure 4-49. Note that when the Add I/O
Marker icon is selected, the Options change. You select Add an input marker for
the inputs and Add and output marker for the outputs.
Figure 4-49: Adding I/O Markers
17. Save the design (File → Save). Check the Sources window, Sources tab (expand
the plus sign if necessary) and you will notice that the ISE software automatically
recognizes that the schematic file is the top level file and reorganizes the design
accordingly. Highlight “top_sch.sch” and right-click, then select Set as top
module. In the Design Utilities process tree you can view the VHDL created

June 26, 2006
R
from the schematic when “top_sch” is selected in the Sources window. Simple double-
click on View HDL Functional Model. The synthesis tool actually works from this file.
Figure 4-50: Generated HDL
Note: If you want to see how the fitter does before simulation, go ahead and double-click on
Implement Design in the Processes window. This will run synthesis, translation, fit the design,
generate a programming file, and create translation reports, timing reports, and synthesis reports. If
everything has been done correctly, green check marks will appear next to all these processes.
Simulating the Top Level Schematic Design

You can now simulate the entire design.
1. Highlight “top_sch.sch” in the Sources window.

June 26, 2006
R
2. Add a new testbench waveform source by right-clicking on “top_sch.sch” and

selecting New Source. Select Test Bench Waveform and name this source
“top_sch_tb.
Figure 4-51: New Test Bench
3. Click Next> and then associate it with “top.” Click Finish.

4. Initialize the timing as before, using a Clock High Time and Clock Low Time of
270ns and an Input Setup Time and Output Valid Delay of 50ns. Set the
Initial Length of Test Bench to 100000 ns.
Figure 4-52: Simulation Timing
5. In the waveform diagram, enter the input stimulus as follows:

June 26, 2006
R
a. Set the RESET cell below CLK cycle 1 to a value of “1.”

b. Click the RESET cell below CLK cycle 3 to reset it low.
Figure 4-53: Waveform Diagram
Note: In the Figure 4-53 the End Time of 100000 ns will create a more compressed diagram. To
scale as shown above, right click on one of the time intervals (for instance, 2430 ns) and select
Rescale Timing. Set the timing to 10000 ns to get a scale similar to above. You may have to
rescale the timing again to get the scaling shown in Figure 4-55.
6. Click File → Save to save the waveform.
7. With “top_sch_tb.tbw” selected in the Sources window (make sure Behavior
Simulation view is showing),double-click Simulate Behavioral Model in the
Process window.
Figure 4-54: Sources and Processes

June 26, 2006
R
The Simulation will appear as follows:
Figure 4-55: Simulation Window
You are now ready to go to the implementation stage.

June 26, 2006
R
Chapter 5
Implementing CPLD Designs

Introduction
After you have successfully simulated your design, the synthesis stage converts the code-
based or schematic-based design into an NGC netlist file. The netlist is a non-readable file
that describes the actual circuit to be implemented at a very low level. The implementation
phase uses the netlist and a constraints file to recreate the design using the available
resources within the CPLD. Constraints may be physical or timing and are commonly used
for setting the required frequency of the design or declaring the required pinout.
The first step is Translate, also known as NGD Build because it is building an NGD file.
This step checks the design and ensures that the netlist is consistent with the chosen
architecture. Translate also checks the UCF for any inconsistencies. In effect, this stage
prepares the synthesized design for use within a CPLD.
The fit stage distributes the design to the resources in the CPLD and places those resources
according to the constraints specified. Obviously, if the design is too big for the chosen
device, the fit process will not be able to complete its job. The fitter uses the constraints that
were present in the UCF file to understand timing and may sometimes decide to change
the design to meet timing specifications. For example, sometimes the fitter will change the
D-Type flip-flops in the design to Toggle Type or T-Type registers. It all depends on how
well the design converts into product terms.
Note: Once the fitter has completed, it is good practice to re-simulate. As all the logic delays added
by the macrocells, switch matrix, and flip-flops are known, the chosen simulator can use information
for timing simulation.
The fitter creates a JEDEC file, which is used to program the device on the board either
using a parallel cable or programming equipment.
The steps of implementation must be carried out in this order. WebPACK ISE software will
automatically perform the steps required if a particular step is selected. For example, if the
design has only just been functionally simulated and you decide to do a timing simulation,
the software will automatically synthesize, translate, and fit the design. It will then
generate the timing information before it opens the simulator and gives the timing
simulation results.
The rest of this chapter demonstrates the steps required to successfully implement our
traffic light design.
Synthesis
The XST synthesis tool will only attempt to synthesize the file highlighted in the Sources
window. In our traffic light design, “top.vhd” (for VHDL designs) or “top_sch” (for
schematic designs) instantiates two lower level blocks, “stat_mac” and “counter.” The

June 26, 2006
R
synthesis tool recognizes all the lower level blocks used in the top-level code and
synthesizes them together to create a single bitstream.
1. In the Sources window, ensure that “top.vhd” (or “top_sch” for schematic flows) is
highlighted.
2. In the Process window, expand the Synthesis subsection by clicking on the plus sign
(+) next to Synthesize.
3. You can now check your design by double-clicking on Check Syntax.
Note: If you have just finished the schematic module, you will need to highlight the VHDL
submodules to check syntax. To check the schematic file, run Check Design Rules, found under
the Design Utilities process.
Ensure that any errors in your code are corrected before you continue. If the syntax
check succeeds, a green check mark will appear as shown inFigure 5-1 . The design
should be correct because both the HDL Bencher tool and ISE Simulator have already
checked for syntax errors. (When writing code, it is good practice to periodically check
your design for any mistakes using this feature.)
Figure 5-1: Process Window Showing Check Syntax for Counter.vhd
After you have checked all the modules, highlight the top level module, then go down to
the process tree and right-click on Synthesize (under Implement Design) and select
Properties.
Figure 5-2: Selecting Synthesis Properties

June 26, 2006
R
Constraints Editor
A window appears allowing you to influence the way in which your design is
interpreted. The Help feature will explain each of the options in each tab.
4. Highlight the Xilinx Specific Options category.
5. In the Xilinx Specific Options tab, ensure that the Add IO Buffers box is ticked. The
I/O buffers will be attached to all the port names in the top-level entity of the design.
Figure 5-3: Process Properties for Xilinx Specific Options
Clicking on Help in each tab demonstrates the complex issue of synthesis and how the
final result could change. The synthesis tool will never alter the function of the design,
but it has a huge influence on how the design will perform in the targeted device.
6. Click OK in the Process Properties window and double-click on Synthesize.
7. When the synthesis is complete, a green tick will appear next to Synthesize. Double-
click on View Synthesis Report. The report file (.syr) will appear in ISE.
Constraints Editor
To get the performance you need from a device, you must tell the implementation tools
what and where performance is required. This design is particularly slow and timing
constraints are unnecessary. Constraints can also be physical; pin locking is a physical
constraint. For this design, assume that the specification for clock frequency is 100 MHz
and that the placement of pins will be suitable for a CoolRunner-II on a pre-designed
board.
1. In the Process window, expand the User Constraints tree and double-click
Assign Package Pins. As there is no constraints file present in the design, the

June 26, 2006
R
software will create a constraints file and call it “top.ucf.” It will be associated with
your top level source file.
Figure 5-4: Assign Package Pins
Notice that the Translate step in the Implement Design section runs
automatically. This is because the implementation stage must see the netlist before it
can offer you the chance to constrain sections of the design. When translate has
completed, the Xilinx PACE (Pinout Area and Constraints Editor) tool opens. If there
are already constraints in the UCF file, these will be imported by PACE and displayed.
As we have an empty UCF file, nothing exists for PACE to import. In the Design Object
List, you can enter a variety of constraints on the I/O pins used in the design. PACE
recognizes the five pins in the design and displays them in the list.
2. Click in the Loc area next to each signal and enter the following location constraints:
clock p38
reset p143
red_light p11
green_light p13
amber_light p12
While these pin locations are specific to the board in the CPLD Design Kit, this alone is not
enough to get the design working on the board. For a challenge and to get this design
working on the board in the CPLD Design Kit, please refer to the end of this chapter.
Figure 5-5: Enter Location Constraints

June 26, 2006
R
Constraints Editor
3. When a pin is highlighted in the Design Object List, the pin to which it is
“Locked” is highlighted in the Package Pins view. If you roll the cursor over the pin, it
will display information about it.
Figure 5-6: Section of Pace Display
4. Save the PACE session and exit the PACE tool. It is now possible to see the constraints
in the UCF file.
5. Now, under the User Constraints tab, double-click Edit Constraints (Text)
in the Process window. The UCF file will open in the main window of the ISE Project
Navigator. The constraints entered into PACE can be seen in Figure 5-7.
Note: If you do not see the UCF file in the Sources window, add it by using Project → Add
Source.
Figure 5-7: Text Constraints Imported from PACE
6. To force a signal onto a global resource, you can apply the BUFG constraint. In this
case, we will apply the BUFG constraint to the clock signal. Enter the following syntax
in the text file:
NET "clock" BUFG=CLK;
7. Save and the text file.
8. The next step is to create timing constraints. With the UCF highlighted in the Source
window, double-click on Create Timing Constraints in the Process window.

June 26, 2006
R
9. The Constraints Editor will open. This tool can be used to set location constraints, but
for this tutorial it will only be used to create timing constraints.
Figure 5-8: Pace with Global Tab Selected

June 26, 2006
R
Constraints Editor
10. The Constraints Editor recognizes the one global signal in the design. Double-
click in the Period window of the global clock signal.
Figure 5-9: Clock Period Editor Window
11. In the Clock Period definition window, change the Time value to 10 ns. The duty
cycle should stay at 50% high, 50% low.
12. Click OK. The period constraint is now written into the UCF file and can be seen in the
constraints list at the bottom of the Constraints Editor. A period constraint
ensures that the internal paths starting and ending at synchronous points (flip-flop,
latch) have a logic delay less than 10 ns.
13. Click the Ports tab in the Constraints Editor. As there were already constraints
in the UCF, they have been imported.

June 26, 2006
R
Highlight the three outputs “red_light,” “green_light,” and “amber_light” using ctrl select.
Figure 5-10: Constraints Editor – Create Group
14. In the Group Name field, type “lights” and then click the Create Group button.
15. In the Select Group box, select “lights” and click the Clock to Pad button.
16. In the Clock to Pad dialog box, set the Time Requirement to 15 ns relative to
Clock Pad Net. (There is only one clock, but in some designs there may be more).
Figure 5-11: Clock to Pad Dialog Box

June 26, 2006
R
Constraints Editor
17. Click OK.

Notice that the Clock to Pad fields have been filled in automatically and that the UCF
generated has appeared in the UCF constraints tab at the bottom of the screen.
The UCF file should look similar to Figure 5-12.
Figure 5-12: Complete Constraints List
18. Save the Constraints Editor session (File → Save) and exit the Constraints
Editor.
CoolRunner-II architecture supports the use of non 50:50 duty cycle clocks by
implementing input hysteresis. This can be selected on a pin-by-pin basis. For example, if
the clock used in this design is an RC oscillator, the input hysteresis can be used to clean up
the clock using the following constraint syntax:
NET “clock” schmitt_trigger;
The CoolRunner-II CPLD also supports different I/O standards. If the three light signals
had to go to a downstream device that required the signals to conform to a certain I/O
standard, you could use the following constraint syntax:
NET “red_light” IOSTANDARD=LVTTL;
The permissible standards are LVTTL, LVCMOS15, LVCMOS18, LVCMOS25, LVCMOS33.
On larger devices (128 macrocell and larger), the permissible standards are HSTL_I,
SSTL2_I, and SSTL3_I. However, you can use only one I/O standard per bank, so take care
when assigning different I/O standards in a design.
The CoolRunner-II family has several features that are aimed at reducing power
consumption in the device. One of these features is known as CoolClock. The clock signal
on Global Clock Input 2 (GCK2) is divided by 2 as soon as it enters the device. All of the
registers clocked by this clock are then automatically configured as dual-edge triggered
flip-flops. The highest toggling net in the design will now be toggling at half the frequency,
which will reduce the power consumption of that net without compromising the
performance of the design. The CoolClock attribute can be applied by right-clicking on
GCK2 in PACE or by adding the following line in the UCF:
NET “clock” COOL_CLK;

June 26, 2006
R
However, we will not use these features in this tutorial. For more information on the use of
CoolRunner-II CPLDs, and their advanced features, visit www.xilinx.com/apps/cpld.htm for
a number of application notes, often including free code examples.
Implementation
To implement the design, you must re-run Translate so the new constraints can be read.
1. Click on the “+” next to Implement Design in the Process window.
The implementation steps are now visible. An orange question mark indicates that
translate is now out of date and should be re-run.
2. A right-click on Implement Design allows you to edit the Properties for each
particular step. Notice that the Fitting category is selected in Figure 5-13
Figure 5-13: Process Properties – Implement Design
The Help button will explain the operation of each field. You can set the default I/O
standard under the Fitting category of the Process Properties window, as
shown in Figure 5-13.
3. In this case, we will set the I/O Voltage Standard to LVCMOS18 so that all of our
pins are configured to be compliant with the LVCMOS 1.8V standard. If this is all you
want to change, click OK. If you would like to examine the options of the other
Categories, click through them.
4. You can implement your design by double-clicking on Implement Design. When
there is a green check mark next to Implement Design, the design has completed the
implementation stage.
5. The timing analysis is performed by default on the design. To look at the Timing
Report, expand the Optional Implementation Tools branch in the Process

June 26, 2006
R
CPLD Reports
window. Then expand the Generate Timing branch and double-click on Timing
Report.
CPLD Reports
Two reports are available that detail the fitting results and associated timing of the design.
These are:
• The Translation Report shows any errors in the design or the UCF.
• The CPLD Fitter Report shows the results of the fit. The fitter report can be presented
in two different ways. The first is a text file, the second is HTML reports, which gives
you a lot of advanced browsing options.
1. To select which format to open, go to:
Edit → Preferences → ISE General → CPLD Fitter Report
and choose between Text and HTML under CPLD Reports.
Figure 5-14: ISE Preferences
2. Click the Apply and OK buttons.

June 26, 2006
R
3. To open the CPLD Fitter Report, expand the Fit branch and double-click on the
Fitter Report process.
Figure 5-15: CPLD HTML Fitter Report
The same information is contained in both the HTML and text reports, but the HTML
report has been designed to make the information more readable and easier to find. You
can browse through several sections of the HTML Fitter Report by using the menu on the
left-hand side of the page. The Summary section of the report gives a summary of the total
resources available in the device (256 macrocells, 118 I/O pins, etc.), and how much is used
by the design. The errors and warnings generated during fitting can be seen in the Errors
and Warnings section.
The Inputs and Logic sections give information about signals, macrocells, and pins in
the fitted design. The key to the meaning of the abbreviations is available by pressing the
legend button.
The Function Block summary looks into each function block and shows which
macrocell is used to generate the signals on the external pins. By clicking on a specific

June 26, 2006
R
Timing Simulation
function block (e.g., FB1) in the Function Blocks section, all of the macrocells in that
function block will be shown. Clicking on a specific macrocell will bring up a diagram of
how that macrocell is configured. An XC2C256 device has 16 function blocks, of which
only two have been used for logic functions in this design. The design could be packed into
a single function block, but the chosen I/O pins dictate which macrocells (and hence which
function blocks) are used.
A great feature of CPLDs is the deterministic timing, as a fixed delay exists per macrocell.
The Timing Report is able to give the exact propagation delays and setup times and clock-
to-out times. These values are displayed in the first section of the report you will have
created. The next section lists the longest setup time, cycle time (logic delay between
synchronous points as constrained by the period constraint), and clock-to-out time.
The setup and clock-to-out times don’t strictly affect the design’s performance. These
parameter limitations are dependent on the upstream and downstream devices on the
board. The cycle time is the maximum period of the internal system clock. The report
shows that this design has a minimum cycle time of 7.1 ns, or 140 MHz.
The next section shows all the inputs and outputs of the design and their timing
relationship with the system clock. Three lights will have a 6.0 ns delay with respect to the
clock input. The clock to setup section details the internal nets to and from a synchronous
point. The maximum delay in this section dictates the maximum system frequency.
“amber_light”, “red_light” and “green_light” are the D-Type flip-flops used to register the
outputs.
The last section details all the path type definitions, explaining the difference between the
types mentioned previously in the report.
To generate a detailed timing report, right-click on Generate Timing in the Process
window and select Properties → Timing Report Format → Detail.
Timing Simulation
The process of timing simulation is very similar to the functional method. Change the view
to show sources for Post-Fit Simulation. This is done in the drop-down menu at the
top of the Sources window.
Figure 5-16: Selecting the Post-Fit Simulation View

June 26, 2006
R
4. With “top_tb.vhd” (or “top_sch_tb.vhd” for schematic flow) selected in the Sources
window, expand the Xilinx ISE Simulator tree in the Process window and double-
click on Simulate Post Fit Model.
ISE Simulator will open, but this time implementing a different script file and
compiling a post-route VHDL file (time_sim.vhd). “Time_sim.vhd” is a very low-level
VHDL file generated by the implementation tools. It references the resources within
the CPLD and takes timing information from a separate file.
5. Use the zoom features and cursors to measure the added timing delays.
Figure 5-17: Post-Fit Simulation Waveform
Configuration
The CPLD Design Kit comes with its own JTAG cable which is required to configure the
device from the iMPACT programmer.
1. Make sure the cable is plugged into the computer and the board. Also ensure that the
board is powered up with the batteries or a suitable power supply.

June 26, 2006
R
Design Challenge
2. With sources for Synthesis/Implementation displayed in the Source window,

double-click on Configure Device (iMPACT) in the Process window (you may
have to click the plus sign adjacent to Generate Programming File).
Figure 5-18: iMPACT Programmer Main Window
3. Right-click on the Xilinx XC2C256 icon that appears in the iMPACT window and select
Program.
The design will now download into the device.
You have now successfully programmed your first CoolRunner-II CPLD.
Design Challenge
The challenge is to get the design working on the board so that the changing sequence of
lights can be viewed. The design in the CPLD has the correct pinout but ,unfortunately,
there are two problems. The oscillator on the board is running way too fast for the human
eye to see, and there are not enough LEDs on the board to display the lighting sequence.
There are several ways to solve the problem and you are at liberty to choose any method
you prefer. Maybe you want to divide the oscillator frequency, maybe you want to source
a slower oscillator. You are free to move the signals to different pins using the method
shown in this chapter.
Enjoy!

June 26, 2006
R

June 26, 2006
R
Chapter 6
Introduction to Logic Consolidation

This chapter contains two topics on using Xilinx CPLDs to consolidate the logic of your
design. Using this chapter you can reduce the number of components in your design,
expand the features, lower your overall power profile, and save money in both design cost
and component inventory.
This Chapter contains two white papers on logic consolidation. In addition, Xilinx has a
free logic consolidator tool available on our website. The logic consolidator tool will
calculate the amount of logic that can be transferred to a CPLD. The methodology behind
the logic consolidator is discussed in the second of the two white papers found in this
chapter. To download the free logic consolidator tool, go to
www.xilinx.com/products/silicon_solutions/cplds/cpld_logic_consolidator.htm.
• The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
• TTL “Burn Rate” for Xilinx CPLDs

June 26, 2006
R
Chapter 3

June 26, 2006
White Paper: CPLD
WP202 (v1.3) January 10, 2005
The Advantages of Migrating

from Discrete 7400 Logic Devices
to CPLDs
How often do you hear that the typical PC system is

more powerful than the supercomputer of only two
decades ago? While this is an amazing testament to
the advances of computing technology over the last
20 years, you hear very little about another less
visible, yet equally remarkable trend: one complex
programmable logic device (CPLD) and a little code
can replace literally hundreds of discrete logic
components.
Discrete logic devices, long considered the

workhorses of the semiconductor industry, held a
unit cost advantage over programmable logic
devices for several decades. However, times have
changed significantly. Advances in semiconductor
process technology for CPLDs have driven the costs
of these devices down to a point where they now
offer a highly compelling discrete logic replacement
alternative.
Background Driven by greatly compressed product development cycles, rapidly changing

standards, and feature explosion, the prevailing trend in digital design over the last
WP202 (v1.3) January 10, 2005 www.xilinx.com 349

1-800-255-7778
R
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
decade has been to continue to move away from discrete logic devices in favor of
CPLDs. Not only will this trend continue, but also it will accelerate.
The purpose of this paper is to bring to light the reasons why it makes sense today—
both cost-wise and strategically—to migrate from discrete logic devices to CPLDs. To
accomplish this, we provide a side-by-side comparison of discrete logic devices with
CPLDs. Our comparison considers production costs, board area savings, operating
performance, reliability, time to market, programmability, electromagnetic
interference, and design security. We also provide a brief overview of how Xilinx
programmable logic device technology addresses these issues.
TTL Logic Comes of Age

Discrete TTL logic technology gained almost universal acceptance after Texas
Instruments introduced their TTL 74XX family of integrated circuits in 1962 to support
NASA’s lunar-landing and space exploration programs. That family included logic
gates, such as the 7400 quad NAND, flip-flops, the 7474 twin D-type flops, the 74160
decade counter, binary adders, and other simple subfunctions, all of which were
available in 14- or 16-pin integrated circuit packages.
Advances in discrete logic component packaging and the introduction of devices with
ever-increasing levels of integration enabled designers to minimize board space and
the number of components while providing them with almost “Lego Block” like
simplicity. New families were continually introduced to address the need for higher
performance, lower power, and reduced cost. The result is more than 33 different 7400
families, each offering its own unique permutation of power, performance, price, and
features.
Through the 1970s, TTL variations came rapidly. However, along with the rampant
proliferation of multiple 7400 series came complexity. By the early '80s, a veritable
alphabet soup of logic family variants had been released—TTL, S, LS, AS, F, ALS,
CD4000, HC, HCT, BCT, AC, ACT, FCT, ABT, LVT-A, AHC, AHCT—forcing designers
to require a scorecard to keep track of which family best fit each application.
Not only were there many different types of 7400 families to choose from, but the
number of members within a family and the different speed grades, plus the package
and feature options proliferated to the point where today there are well over 500,000
unique 7400 devices.
The Emergence of CPLDs

While there were many 7400 devices to choose from—perhaps far too many—a
revolutionary trend began to appear in the form of programmable logic devices
(PLDs). Delivering user programmability, the first generations of these chips replaced
five to ten logic devices. As logic integration improved, PLDs were able to replace
more and more standard logic functions. Today, the highest-density CPLDs contain
10,000 gates and are capable of integrating large numbers of 7400-series logic devices.
However, consistent with higher levels of integration, first-generation CPLDs came at
a higher price. The culprit: the die costs associated with the inherent overhead
associated with CPLD programmability. Calculating cost is fairly straightforward: the
device price is directly proportional to the number of devices (or dice) that can be
yielded from a single silicon wafer. As the example in Figure 1 shows, if you were to
350 www.xilinx.com WP202 (v1.3) January 10, 2005

1-800-255-7778
R
assume a wafer cost of $3000 and a yield of 300 dice per wafer, the cost of each device
is $10.
$3000/wafer
3000 devices/wafer
$1/device
WP202_01_110403
Figure 1: Basic Semiconductor Cost Model
For larger die sizes, cost becomes a major concern based on the fact that silicon wafers
are not perfect, and, in fact, they have defects. The probability that a die will not yield
due to a defect on the die increases exponentially as the die size increases. Thus, the
cost of a larger die increases exponentially beyond a certain point. These factors, in the
past, led to higher CPLD product costs when compared to discrete TTL devices.
Die Size vs. Cost

Cost
Die Size
Die cost as a function of die size WP202_02_110403
Figure 2: Die Cost As a Function of Die Size

1-800-255-7778
R
In addition to die cost, other costs, including device packaging and product testing
add together to form the total product cost as shown in the chart in Figure 3.
1985 CPLD Total Product Cost

100%
Percent of Total Cost

80%
60%
40% Package Cost

20% Test Cost
Die Cost
0%
I
Total product cost = die cost + test cost + package cost
WP202_03_110403
Figure 3: IC Total Product Cost
Traditionally, this high cost structure restricted the use of CPLDs primarily for pre-
production prototyping or other limited-volume applications. Today, this situation
has changed dramatically.
CPLD: The When the 7400 series was first introduced, there was a significant premium to be paid
Clear Discrete for integration. In 1963, the average price for a single 7400 device was $1000 (in 1963
Logic dollars!). While the situation improved over the years, in 1968 the average price for a
7400 device had dropped to only $25 (in 1968 dollars). The concept that an integrated
Replacement circuit would eventually be cheaper than the same circuit constructed from discrete
Choice transistors and resistors would have been thought highly unlikely.
Through the years, however, improvements in semiconductor process and packaging
technologies leveled the playing field to where it was actually cheaper to use the
highly integrated 7400 series device over the discrete transistor implementation. In
effect, integration was free!
Historically, 7400-series devices had low unit costs relative to CPLDs. However, once
again, technology improvements have rewritten the cost equation, allowing CPLDs to
gain equal, if not better, footing against TTL devices. That is, the unit costs of CPLDs
have been driven down to the point where they are equal to or even below those of
discrete logic devices. In addition, as the diagram in Figure 4 shows, if you compare

1-800-255-7778
R
the cost of a logic circuit implemented using discrete 7400 devices to one using CPLDs,
time and again the CPLD wins, hands down.
Equivalent to > 8
Discrete TTL
Package Cost
Test Cost
CPLD Discrete
Die Cost
2004
WP202_04_110403
Figure 4: 7400 vs. CPLD Device Cost Comparison
Further, factoring in the high hidden costs underlying discrete logic devices—which
include increased inventory, low reliability, high power consumption and EMI,
prolonged time to market, and higher maintenance—makes CPLDs the clear, superior
alternative to discrete 7400 series devices.
Device Cost Comparison 7400 vs. CPLD

Total Device Cost
7400 Cost
CoolRunner Cost
1 4 7 10 13 16 19 22 25 28 31 34
Number of Discrete Devices
Cost comparison: 7400 discrete pricing versus CPLDs WP202_05_110403
Figure 5: Basic Discrete 7400 vs. CPLD Comparison
The remainder of this paper presents a comparison of discrete logic devices to CPLDs,
based on the following:
• Total system costs
• Time to market
• Programmability
• Reliability
• Electromagnetic interference

1-800-255-7778
R
• Design security capabilities
Discrete Logic Closing the Cost/Performance Gap

versus CPLD To support the premise that CPLDs provide a lower total cost alternative, in this
Devices section we compare the costs of a discrete logic component-based circuit with those of
a Xilinx CPLD. The discrete logic circuit used for comparison (shown in Figure 6) is a
straightforward memory controller that provides equal functionality as one Xilinx 32-
macrocell XC2C32 CoolRunner-II CPLD. To make the comparison as complete as
possible, we cover both DIP and SMT packaging for the discrete circuit, and compare
these against the Xilinx CPLD in a VQ44 package.
D e vi c e N um ber M c e lls To ta l
7400 1 4 4
74163 4 4 16
74147 1 4 4
74373 1 8 8
G ra n d T o t a l 32
Figure 6: Sample Circuit for Cost Analysis
When comparing costs between technology alternatives, it is important to consider the

total system costs, that is, the real cost of the solution. Accordingly, our analysis
provides a detailed breakdown of all costs, starting with production costs, and then
comparing the costs associated with total PC board area, power consumption, and the
number of board layers.
Production Costs
Production costs are broken down by logic component unit costs, discrete
resistor/capacitor costs, PCB board area cost, assembly/insertion, and inventory.
Table 1: Production Cost Comparison

Discrete Circuit Xilinx CPLD, XC2C32
Cost/Packaging DIP SMT VQ44
Logic component costs $1.36 $1.93 $0.90
Discrete resistors & capacitors $0.66 $0.66 $0.18
PCB material(1) $3.62 $3.77 $2.12
Assembly/Insertion(2) $0.72 $0.75 $0.42

1-800-255-7778
R
Table 1: Production Cost Comparison (Continued)

Discrete Circuit Xilinx CPLD, XC2C32
Cost/Packaging DIP SMT VQ44
Inventory(3) $1.75 $1.93 $0.75
TOTAL $8.11 $9.04 $4.37
1. Cost derived from quotes from multiple PCB vendors for 4-layer discrete boards and 2-layer CPLD
boards. Size of board: 3 x 3 inches. Quantity: 1,000/month, 2-week lead time.
2. Assembly/insertion costs are 20 percent of PCB material costs.
3. Inventory costs are 25 percent of total material costs.
As Table 1 shows, for the circuit used in this analysis, the total cost for one Xilinx
CPLD is much less than one-half of the cost of the same circuit using 7400 series
devices. Besides lower unit production costs, additional savings for CPLD-based
designs are realized through reduced component count, including interfacing
resistors, decoupling capacitors, additional PCB real estate, and assembly/insertion
costs.
Although not quantified in this analysis, CPLDs gain an additional cost advantage
through:
• Ability to inventory one line of CPLDs for multiple applications. This reduces the
number of individual part numbers to be traced and handled.
• Lower availability risks and low minimum order quantities (MOQ)
• Reduced expediting costs and production delays incurred by parts shortages.
• Avoiding lost revenues because of lack of component availability or down
production lines
Board Area Savings

When compared with discrete logic components, CPLDs require fewer components
and thus less board area and fewer layers. As the Table 2 shows, the total board area
costs alone are a fraction of those for the discrete circuit. Further, the fewer devices
required for the CPLD leads to lower power consumption and improved reliability. In
addition, lower heat dissipation avoids the need for cooling fans and heat sinks. The
table provides the details behind these factors, comparing and quantifying the cost
impact.
Table 2: Board Area Comparison

Discrete Circuit Xilinx CPLD
Function/Pkg DIP SMT VQ44
Component area (in2) 1.298 0.760 0.150
PCB area (in2) consumed
1.6874 0.988 0.195
by components(1)
Cost of board area(2) 1.6874 in2 x $0.40/ in2 = 0.988 in2 x $0.42/ in2 = 0.195 in2 x $0.24/ in2 =
$0.67 $0.41 $0.05
Cost/layer differential 4 layers x $0.75 = $3.00 4 layers x $0.75 = $3.00 2 layers x $0.75 = $1.50
($0.75 per layer) total total total

1-800-255-7778
R
Table 2: Board Area Comparison (Continued)

Discrete Circuit Xilinx CPLD
Function/Pkg DIP SMT VQ44
Power consumption
150mW 1750mW 150mW 1750mW .029 mW 1.6 mW
(Quiescent vs. Active)
Total cost of power usage
$0.06 $0.07 $0.06 $0.07 $1.16x10-5 $6.4x10-4
(@ $0.40/watt)(3)
Reliability 29.951 FIT 29.951 FIT 1.000 FIT
1. This is the total PC board area consumed by only the components, which was calculated to be equal to the total component area plus
30 percent.
2. Cost derived by dividing board unit costs (from Production Cost chart) by 9 square inches (3x3 board): $3.62/9 for DIP,
$3.77/9 for SMT, and $2.12/9for CPLD.
3. The power cost of $0.40 per watt is considered by experts to be an industry standard cost.
Other CPLD Cost Advantages

As discussed in the remainder of this document, CPLDs further drive down the total
cost of ownership and deliver key advantages through:
• Fast time-to-market – Being first to market counts. In fact, every four weeks of
delay results in 14 percent loss of market share.1 7400 device availability and
design changes that occur late in the product development or manufacturing
cycle can significantly impact market share.
• Reprogrammability – CPLDs cannot only get to market faster, they stay in the
market longer, enabling an expanded revenue stream. In addition they enable:
- Remote bug fixes and feature upgrades that avoid costly hardware changes
- Shorter development cycles thus avoiding board re-spins resulting from
“features creep” or unnoticed bugs
- Reduced development time being spent on reworking and maintaining old
designs
• Reliability – By employing a lower number of devices over the discrete TTL
equivalent circuits, CPLDs provide a significantly improved FIT rate, indicating a
remarkable high level of reliability.
• Electromagnetic interference – CPLDs lower EMI levels, thus reducing the high
cost and high risk of meeting EMI compliance.
• Design security – CPLDs offer a significant security advantage over TTL devices
as they can employ bit-stream protection, preventing design read-back and
reverse engineering.
1. John Chambers, Cisco
Additional assumptions:
- Logic density: 32 macrocell
- Discrete circuit consists of:
(1) electrolytic capacitor (power)
(7) ceramic capacitors (decouple)
(6) ¼-watt pull-up resistors
- Standard commercial operating environment
- Power consumption data assumes frequency of 25 MHz

1-800-255-7778
R
Time-to-Market The proliferation of electronic wireless, industrial and communication devices, as well
Benefits as ever-shrinking product life cycles continue to put pressure on companies to get
their designs from concept to production as soon as possible. When you look at the
cost of being late, it’s easy to see the motivation behind being first on the market.
As the graph in Figure 7 illustrates, late market entry has a larger affect on profits than
development cost overruns or a product price that is too high. This is especially true in
highly competitive markets and those that have short market windows. According to
Mckinsey & Co., even if within budget, products that are six months late earn 33
percent less profit over five years.
Time-to-market
Profit for first

to market
Reduced profit
for late comers
Product Availability
WP202_07_110403
Figure 7: Xilinx CPLD Time-to-Market Benefits
Unfortunately, designs that employ discrete 7400 devices are at the mercy of several
barriers that not only prolong time to market, but add complexity and costs, and
reduce reliability. These barriers include:
• A long manufacturing, assembly, test, and debug cycle that is susceptible to
delays and multiple design decisions that can directly impact board layout.
• The lack of easy-to-use design tools makes debugging and maintenance tedious
chores.
• The high number of TTL components required in discrete designs introduces
availability risk. In many cases, components might be out of stock or even
obsolete.
CPLDs, on the other hand, provide designers with numerous advantages that enable
designers to react to last-minute design changes and compress time to market. These
include component inventory reduction, faster production cycles, efficient device and
board testability, and the ability to modify designs during all phases of design and
production.
Programmability: While time to market is a major benefit, the ability to program and reprogram devices
The Real as designs change is equally important. Unlike CPLDs, once a PCB using discrete TTL
Advantage devices is laid out and goes into production, typically it cannot be altered or upgraded
without ripping out components and going through board re-spins.
Another major advantage of CPLDs is quick system upgrades and bug fixes in the
field. As a result, designers can easily integrate exactly the logic functionality needed

1-800-255-7778
R
without adding “cuts and jumps” on the PCB. For example, imagine a scenario where
automobile manufacturers can add new functions to in-car systems by allowing
consumers to dial up and purchase upgrades over the phone to reconfigure the
system. In addition, CPLDs help avoid board redesigns and scrapped parts when
specific programs are cancelled.
The reconfigurable nature of CPLDs also enables a single product footprint to
implement multiple product personalities. That means manufacturers can standardize
on a single PCB footprint and package, and thus quickly leverage economies of scale
through reduced inventory overhead. Further, reprogrammability reduces the
deployment of design resources for maintaining old designs, which allows engineers
to focus on introducing new products and features.
Reliability Reliability is another area that should not be overlooked when analyzing total system
costs, especially since 7400-based systems introduce higher complexity with more
components, interconnects, layers, handling—and thus, lower overall reliability. In
addition, because discrete components are typically larger and require more board
real estate, and have a significant number of external chip-to-chip interconnects, they
increase power consumption and EMI which further heightens failure risks.
In contrast, CPLD-based systems require fewer components and layers. The reduction
in components and layers reduces PC board layout density, lowers heat dissipation,
reduces EMI levels, and thus greatly decreases Failures In Time (FIT).
Electromagnetic Electromagnetic interference (EMI) refers to any type of interference that can
Interference potentially disrupt, degrade, or otherwise interfere with authorized electronic
emissions over approved portions of the electromagnetic spectrum. EMI problems are
often complex, and their solutions illusive. Ideally, EMI compliance should be an
integral part of the board design. Unfortunately, resolution of EMI problems is often
ignored until it’s too late.
EMI Causes
EMI originates from the switching of digital circuits. Two factors are necessary for EMI
to exist: a noise source or transmitter, and a propagation path or antenna. On a PCB,
noise can come from frequency-generating circuits, component radiation, ground
bounce, poor impedance control, or cable interconnects. The propagation path is the
medium that carries the energy, such as free space or metallic interconnects. Antennae
are the elements that both transmit and receive unwanted interference.
Impact of EMI
Concern over EMI continues to grow as the FCC and international compliance
regulations clamp down harder on pollution of the electromagnetic spectrum, thus
making it is an issue that requires system designers’ attention.
To system designers, EMI compliance carries a cost and high risk, as it can easily
prolong the product introduction. Typically, various techniques are employed to
minimize radiated emissions, including use of ferrite beads, shielded enclosures, or
series-terminating resistors—all of which drive up costs and reduce board yield and
reliability. EMI analysis is tedious and involves numerous variables, making problems
difficult and expensive to fix once the board is moved into production (FCC
compliance testing alone is $400 per hour). The effectiveness of EMI emissions
reduction strategies can be determined only once the product is in the lab. In addition,

1-800-255-7778
R
what might appear to be a good solution to one problem may cause a new problem to
occur. In fact, it’s not uncommon to take several passes to achieve EMI compliance.
Given the large number of components, traces, and board layers, TTL-based designs
are more susceptible to high EMI, compared to CPLDs. By contrast, CPLDs
significantly reduce EMI through fewer external components, and other “free”
features including: programmable I/O slew rate, programmable ground,
programmable I/O signaling, and phase-locked loops. These free features provide a
marked improvement in reducing EMI emissions.
Design Security Given the explosion of new applications in the competitive electronics market, the
Issues need to protect designs from unscrupulous competitors has never been greater.
CPLDs offer several unique advantages that safeguard system designers against code
theft.
Unlike discrete logic devices which are extremely susceptible to reverse engineering—
which is as simple as reading the part number directly from the device—CPLDs
inherently require a user-defined bit stream which easily prevents customer read-
back.
More elaborate security schemes that exploit reprogrammable capabilities of CPLDs
to keep attackers at bay are also possible. For example, the CPLD design or password
can be altered on a regular basis—hourly, if necessary—to seriously hamper an
attacker’s ability to reverse engineer the design. Exploiting the reprogramming
features of CPLDs is thus a logical and efficient way to defend against design theft.
Xilinx CPLD The Xilinx CoolRunner-II CPLD family utilizes second-generation RealDigital™
Advantages technology to provide high performance, advanced features, and low power
consumption, all at a very low price. Featuring a 100 percent digital core, up to 385
MHz performance, and low standby current, CoolRunner-II CPLDs offer a wide range
of densities, as well as abundant I/O, the flexibility to move from one density to
another in the same package, and the lowest cost per I/O pin in the industry.
The advanced system features in CoolRunner-II devices allow you to integrate
multiple discrete functions, reduce costs, lower power consumption, increase
reliability, reduce EMI, and shrink your time to market through:
• Advanced I/O technology – Support for multiple I/O standards allows you to
easily create standard chip-to-chip and chip-to-memory interfaces and thus
remove discrete devices from your system, saving you money and increasing
system reliability.
• Superior clock management – the Clock Doubler enhances performance by
doubling the internal clock speed up to 400 MHz. The Clock Divider improves
power savings by providing clock division at standard values. CoolCLOCK
combines the Clock Divider and Clock Doubler and is a key feature in reducing
EMI.
• Comprehensive design security – Designs can be secured during programming
to prevent either overwriting or pattern theft via readback. Electrical or visual
detection of configuration patterns is eliminated with four levels of on-chip
security. Electrical or laser tampering causes the device to lock down
automatically. Protection is buried deep within the device, making it virtually
undetectable.
• DataGATE – DataGATE reduces power consumption by eliminating unnecessary
toggling during times of irrelevant data on the input pin.

1-800-255-7778
R
• Advanced packaging – The small footprint Chip Scale Package (CSP) is ideal for
space-constrained applications. For cost sensitive applications, the TQFP, PQFP,
VQFP, and PLCC packages offer the ultimate packing solution. Fine line BGA
packages are optimal for applications that demand high performance.
The combination of advanced I/Os, superior clock management, comprehensive
security options, and advanced packing choices provides real world interfaces at 7400
price points that allow designers to meet any challenge.
Summary Since their introduction in the late ’70s, programmable logic devices have proven to be
very popular. In fact, they are now one of the fastest growing sectors in the
semiconductor industry. The migration to PLDs, and eventually CPLDs, has been an
intriguing, four-decade evolution, starting with discrete logic circuits that were
constructed from transistors and resistors to the introduction of the 7400 series first-
generation TTL technology.
However, just as the 7400 series replaced early generation discrete transistor-based
logic designs, advances in semiconductor process technology are enabling CPLDs to
offer a clear, cost-effective alternative to 7400-based logic systems. No longer held
hostage to low densities and high die costs, CPLDs pack more functionality into ever-
shrinking die geometries, offering compelling benefits of low-cost on-the-spot
reprogrammability, short lead times, higher performance, expanded densities, and
unmatched flexibility.
Xilinx CoolRunner CPLDs consume less power and offer reprogrammable flexibility
with unprecedented design security – without a price premium. The result is a
scalable technology that gives you a superior solution for a wide range of high-volume
applications, such as PDAs, cell phones, routers, and high-speed Internet modems.
For more information about CPLDs as well as the programmable devices solutions
from Xilinx, visit www.xilinx.com.
Additional For information on how much 7400 logic can be placed on a Xilinx CPLD, see White
Information Paper 214, TTL "Burn Rate" for Xilinx CPLDs.
History
1/5/04 1.1 Updates to Table 1 on page 7.
9/1/04 1.2 Addition of appendix clarifying macrocell usage.
01/10/05 1.3 Added link to White Paper 214.

1-800-255-7778
WP214 (v1.0) January 10, 2005
TTL “Burn Rate” for Xilinx

CPLDs
By: Jesse Jenkins
The goal of this document is to familiarize logic

designers that have previously not used
programmable logic with the benefits of Xilinx
CPLDs, and show how to go about translating
existing TTL type logic into similar CPLD solutions.
You might want to skip this whole discussion and go
right to the TTL “Burn Rate” table at the end of this
document, but for clarity, we will explain how it was
derived. The basis of the discussion begins with a
familiarity of 7400 style logic, which is actually
comprised of many different variations (7400,
74LS00, 74S00, 74C00, 74HC00, 74HCT00, 74ABT00,
74F00, etc.) These families were phenomenally
successful, and many designers still use them.
However, greater integration, lower power, faster
solutions and in general, less noisy designs can now
be had with a substantial price reduction by using
Xilinx CPLDs. But, first, some basics need to be
covered.

1-800-255-7778
R
White Paper: TTL “Burn Rate” for Xilinx CPLDs
Basics CPLDs are constructed from a building block called a “macrocell”, which is a logic
function that can be manipulated to form various different functions, suiting the needs
of the designer. The macrocells are clustered in groups and called “Function Blocks”
Figure 1 shows a macrocell for the Xilinx CoolRunner-II family of CPLDs. This is a
very compressed diagram, which does not immediately expose its true strengths. For
instance, on the left side of the diagram, there are a series of what appear to be “one
input AND” gates. This is shorthand, which is necessary to show the relationship of
these gates to the other gates in the picture. The “one input ANDs” are in fact 40 input
ANDs, like that shown in Figure 2. We also annotate on Figure 1, the number of “p-
terms” existing at a specific site. The top left p-term states “49 p-terms” when we show
only one. This can be confusing, but a diagram that shows all 56 p-terms available
(add up the p-terms in the diagram), each with 40 inputs, would be more confusing!
We will not go into too much detail on the diagram. Suffice it to say that the building
block we call a CoolRunner-II macrocell contains some gates built up with very large
input ANDs, and has a flip-flop in it, that can be used to build up logic designs.
Most designers do not want to build up logic by manually connecting a part’s basic
gates, so Xilinx provides free software that does it for you. You still have work to do –
define your design in the software, but much of the process is automatically done for
you.
Figure 1: CoolRunner-II Macrocell Diagram

1-800-255-7778
R
Your main task will be to figure out which logic chips you want to replace with
CPLDs, then describe it for the design software, and let it optimize and enhance the
design for you, creating a superior overall solution.
Figure 2: CoolRunner-II AND Gate (Showing All Possible Inputs)
An early task – which we show later – is to select an appropriate part for the logic. In
theory, you will want to purchase the smallest, slowest part possible to solve your
problem. In some cases, you might be unsure about whether you will want to make
future changes, so you might wish to select a slightly larger part, to accommodate
future, unforeseen changes. Let us look a little deeper at the Figure 1 macrocell, by
identifying a very important place in the macrocell. See Figure 3.
Figure 3: “Trimmed down” Macrocell

1-800-255-7778
R
Figure 3 has removed most of the p-terms, the flip-flop and some of the multiplexers
in the macrocell, and specifically identifies the OR gate output. This is the site where
most combinational logic forms a function. As we learned in logic design classes, all
combinational functions can be created from two level “sum of product” (SOP) logic.
This is literally creating ANDed terms and ORing them up. Pretty basic. In Figure 3,
we see that the SOP point attaches to the bottom leg of an EX-OR gate, and it is that site
which actually becomes usable. The mux tied to the other leg serves a number of
functions, but one is simply polarity control for the output of the EX-OR gate. For
instance, if the mux VCC input is chosen, it will present a logic one to the mux output,
driving one leg of the EX-OR. Recalling that if the two inputs of an EX-OR are A and
B, then the output becomes A*/B + /A*B. If A is the top leg of the EX-OR and it is set
to A=VCC =1, this expression becomes /B. That means the value attached to the other
EX-OR leg inverts as it passes through the EX-OR. If the mux selects GND =0, then the
EX-OR will simply pass the SOP site on the bottom leg directly through the EX-OR to
its output. One way of looking at the mux, is that it can make the SOP invert, or simply
pass through the EXOR gate. Although the OR gate is connectable to all 56 p-terms
available to it, it can be configured to select any number from 0 to 56 p-terms, so lets
consider the case where a single p-term is chosen. That means a 40 input AND gate
passes through the SOP OR gate, and can then be passed as an AND, or inverted into
a NAND.
We now see that one macrocell is capable of at least building up AND gates, or NAND
gates, up to 40 inputs wide. That means specifically, that a 2 input NAND gate
(sn7400) could occupy a macrocell. But, so could a 2 input AND gate (sn7408). It could
also create an sn7430 (8 input AND), or an sn74133 (13 input NAND). All of these
functions would only occupy a single macrocell, and have logic left over available to
other macrocells for creating even more logic. As you might have guessed, you could
also build up a 40 input AND/NAND gate, which has never had a 7400 equivalent!
This function is particularly useful for decoding a whole microprocessor’s address bus
with a single gate.
The main idea here is that individual gates can easily be made with a single macrocell,
for a large number of inputs. EX-OR gates are not quite as efficient in this architecture.
By using two p-terms at a macrocell, you can form A*/B + /A*B on the sum of
products OR gate output, then attach another operand – say C, through the mux in
Figure 3, and achieve a three input EX-OR function coming out of the EX-OR gate.
This is not as good as the other gates, but good enough to form the SUM bit of an
adder. It still needs the carry created (another macrocell), but you can quickly see that
adders will “burn through” two macrocells per bit for addition.
Figure 1 is Xilinx CoolRunner-II CPLD family, that operates with a core voltage of
1.8V, but can translate input signals from as high as 3.3V down to 1.5V, if
appropriately connected to various power supplies and batteries. Figure 4 shows a
similar macrocell – the XC9500XL, which is designed to have a core voltage of 3.3V,
but can accept input signals as high as 5V, and deliver signals out as low as 2.5V.
Xilinx actually makes two key CPLD families, the XC9500, XC9500XL, and XC9500XV
products, and the CoolRunner XPLA3 and CoolRunner-II products. The XC9500 parts
focus on standard, low cost, high speed applications, where the CoolRunner families
focus on low cost, low power, high speed applications. Selection among them is

1-800-255-7778
R
usually done based on package needs, I/O pins, power consumption, speed and price,
with those factors prioritized by the end designer.
Figure 4: XC9500XL Macrocell
The XC9500XL macrocell is very similar in its capabilities to that of CoolRunner-II. P-

terms on the left, OR gate, EX-OR gate and flip-flop. The way that it manages
assigning p-terms to the OR gate is a bit different, but in general, similar. The next few
diagrams expose underlying detail on how the product terms at one macrocell site can
be forwarded to a neighboring macrocell. This is important, because as we saw earlier,
when building up a single gate at a macrocell, we are not using everything at each

1-800-255-7778
R
macrocell, so we need to re-allocate it to a neighbor that might better use the left over
logic.
Figure 5: XC9500/XL/XV Product Term Allocator
Figure 6 shows how the product terms from adjacent macrocells within the part can be
re-assigned (or re-allocated) to another macrocell. In Figure 6, the problem being
solved is creating a sum of products function that has 15 AND terms in it, which is
fairly rare, but occasionally happens. Collecting neighbor AND gates within the
Function Blocks comes with a tiny time penalty in this architecture, but it needs to be
understood. Xilinx design software keeps track of the p-term allocation time delays
automatically for you, and summarizes them in a timing report.
Just to show the flexibility, Figure 7 shows an 18 product term SOP being built up,
which involves collecting AND gates from neighbors within the Function Block that
are not directly adjacent, but involve skipping over a macrocell. The architecture is

1-800-255-7778
R
quite flexible. Figure 5, Figure 6 and Figure 7 are all trimmed down versions of the
larger picture of Figure 4, just focusing on the p-term allocation and re-distribution.
Figure 6: Collecting Neighboring Product Terms & Providing 15 to a SOP

1-800-255-7778
R
Product Term
Allocator
Macrocell Logic
With 2
Product Terms
Product Term
Allocator
Skipped Macrocell
Product Term
Allocator
Macrocell Logic
With 18
Product Terms
Product Term
Allocator
Figure 7: Taking the SOP Up to 18 P-terms

1-800-255-7778
R
We have seen how the macrocells can build up logic functions for small gates and
sums of products, but our goal is to have a more systematic process. So, for starters, we
will need to know how “big” the parts are. Xilinx CoolRunner-II devices, as a family,
are all built from macrocells as shown in Figure 1. They occur in groups called
Function Blocks, with 16 macrocells in each FB. The smallest part has 32 macrocells
and is called the XC2C32A. The next part has 64 macrocells and is called the XC2C64A.
It then goes up to the XC2C128, XC2C256, XC2C384 and XC2C512. In each case, the
number of macrocells are the digits to the right of the right most C. The XC9500,
XC9500XL, and XC9500XV parts are very similar, having macrocells grouped into 18
macrocell Function Blocks, and the parts typically increase in multiples of 18, starting
at say the XC9536. The largest XC9500, XC9500XL, and XC9500XV parts only go up to
288 macrocells, which is smaller than CoolRunner CPLDs.
With this in mind, the approach will be to examine the target 7400 logic and figure
how many macrocells get burned through creating an equivalent design. More
examples are in order.
Examples We described simple gates earlier, and found macrocells easily handle small to large
gates in a single macrocell. They also handle combinational sum of products chunks,
as shown in Figure 6 and Figure 7, in a single macrocell per function.
Registers
Flip-flops – both D and T – are available at the rate of one per macrocell. If you deliver
data directly from an input pin to the flip-flop, you do not even burn any p-terms
making the delivery. If you deliver data from within the part, then the method of
delivery is through an AND gate, which burns a p-term, in doing it. Clocking is
usually done with a global clock pin, which burns no AND gates, but the macrocells
also let you build logic onto the clock for a flip-flop, using an AND gate, if so needed.
So, how much logic you burn making flops depends on what you are doing. Note that
transparent D latches can be automatically built from the D/T flip-flops, so basically,
you get sn7474 or sn7475 structures inside every macrocell.
Simple State Machines

We cannot really anticipate how you might be making state machines, but usually if its
encoded well, you will burn one macrocell per bit of your state machine. To illustrate
some basic ones, lets look at a couple of standard shifters and a standard counter.
Shifters
Figure 8 shows a SN74164N Shift register. Usually, this function is delivered in a 14 pin
DIP, but modern packaging might also offer it in various SOP packages. It consists of
eight consecutively connected flip-flops, which in this case are configured as
Set/Reset flip-flops, where the Q of the flop to the left, feeds the Set of the flop to the
right, and /Q on the left feeds Reset to the flop on the right. This is equivalent to a

1-800-255-7778
R
single left flip-flop Q feeding a right flip-flop’s D, if you have synchronous D flip-
flops, which is the case with CPLDs.
Figure 8: SN74164 Shifter
Figure 9 shows how equivalent circuitry would be built up in the CoolRunner-II

macrocells, where some of the relevant connection circuitry is shown. In Figure 9, the
bottom flip-flop would correspond to the “left” flip-flop in Figure 8. Figure 9 only
shows two bits, of the set of eight, but you should get the idea. The additional logic to
the left of Figure 8, handling the serial inputs, clocks and asynchronous inputs, are
included. Figure 8 would take 8 macrocells to create, but remaining logic would exist.
Figure 9: Building Up Shift Register Bits in Macrocells
Figure 10 shows another shift register from the 7400 catalog. In this case the data is
loaded in parallel, then serialized to a single bit going to the outside world. This would
be created on the CPLD with Q feeding D for consecutive flip-flops; but, rather than
using the Set and Reset inputs for initializing the contents, the CPLD uses a simple
sum of products configuration with a single data value ORed with the neighboring

1-800-255-7778
R
flip-flop’s Q output, then applied to the D input of each flip-flop. The burn rate would
be one macrocell per bit.
Figure 10: SN74165 Shifter
Figure 11 shows a standard SN74161 4 bit cascadable counter.
Figure 11: SN74161 4 Bit Cascadable Counter

1-800-255-7778
R
In Figure 11, the chip can be loaded in parallel, and can count up, using the various
control signals. Because CoolRunner and XC9500 parts have flip-flops that are D or T,
the design software translating this function would save logic by converting the flip-
flop to the T configuration. The logic and flip-flop from each cell would build up the
bits of the counter. Depending on the desired length, the RCO cascade output would
be implemented or not. Typically, it would fold that logic into the next higher bit (fifth)
when cascading.
These examples are selected to give a rough feel for how to account for the logic
needed to build up 7400 parts. It is part “art”, part “science” and part intuition.
Experience in transforming logic frequently shows that many logic functions easily fit
into a CPLD. A key point is to not force the design software to “pinout” every gate
output. Be sure to only pinout the functions needed, as intermediate sites can defeat
the ability to pack the CPLDs for your best interests.
Burn Rate Table A burn rate table is presented in Table 1, which identifies how many macrocells would
get used to create various functions.

Shift register (simple) 1 per bit 1 per bit 1 per bit
Counter (simple) 1 per bit 1 per bit 1 per bit
2:1 Mux 1 2 0
4:1 Mux 1 4 0
8:1 Mux 1 8 0
8 bit loadable shifter 8 16 8
8 bit loadable/SL/SR shifter 8 24 8
8 bit loadable counter 8 16 8
8 bit load/up/dn counter 8 24 8
Full Adder / bit 2 7 0/1 (optional)
2:4 Decoder 4 4 0
3:8 Decoder 8 8 0
4:16 Decoder 16 16 0
8 bit Equality Comparator 1 16 0
And/Nand gate (1-40 inputs) 1 1 0
Or/Nor gate (1-40 inputs) 1 11 0
Ex-or/Ex-nor (2-3 inputs) 1 2-3 0
Level translator (per bit) 1 1 0
A new tool, the CPLD Logic Consolidator is designed to approximate the macrocell
count for you. In theory, you should be able to identify various functions on your PCB,
then, knowing what they do, look them up in this table and calculate how many

1-800-255-7778
R
macrocells you would use. Go through your design tallying them up. Then, knowing
the various CPLD part numbers, you can identify a part by the number of needed
macrocells. It is sometimes cheaper to use multiple small CPLDs versus few larger
ones, but depending on your target – cheapest price, smallest power consumption, or
minimum board area, will dictate the choice. The Logic Consolidator is available from
Xilinx for free at http://www.xilinx.com/products/cpldsolutions/logic_tool.htm.
Conclusion It is hoped that the ideas presented have encouraged you to start on your adventure of
consolidating outdated 7400 logic into modern Xilinx CPLDs. The cost savings,
improved performance and lower power should make it worth your while. Xilinx
WebPack ISE software is freely available on the Xilinx Web site to aid you in your task.
Many Xilinx application notes, white papers and tutorials are available at the same
site.

Information XC9500XL Data Sheets and Application Notes
Online Store
History

1-800-255-7778
R

1-800-255-7778
R
Appendix A
Xilinx CPLD Data Sheets

This appendix contains the following data sheets:
♦ CoolRunner™-II Family Data Sheet
♦ XC9500XL Family Data Sheet
There are individual data sheets for all devices in both families. For individual data sheets,
and any other Xilinx CPLD data sheet, please visit the Xilinx website at www.xilinx.com.

June 26, 2006
R
Xilinx CPLD Data Sheets

June 26, 2006
0
R
DS090 (v2.7) June 21, 2006 0 0 Product Specification
Features - Mixed I/O voltages compatible with 1.5V, 1.8V,

• Optimized for 1.8V systems 2.5V, and 3.3V logic levels on all parts
- Industry’s fastest low power CPLD - SSTL2_1,SSTL3_1, and HSTL_1 on 128
- Densities from 32 to 512 macrocells macrocell and denser devices
- Hot pluggable
• Industry’s best 0.18 micron CMOS CPLD
• PLA architecture
- Optimized architecture for effective logic synthesis
- Superior pinout retention
- Multi-voltage I/O operation — 1.5V to 3.3V
- 100% product term routability across function block
• Advanced system features
• Wide package availability including fine pitch:
- Fastest in system programming
· 1.8V ISP using IEEE 1532 (JTAG) interface - Chip Scale Package (CSP) BGA, Fine Line BGA,
- On-The-Fly Reconfiguration (OTF) TQFP, PQFP, VQFP, PLCC, and QFN packages
- IEEE1149.1 JTAG Boundary Scan Test - Pb-free available for all packages
- Optional Schmitt trigger input (per pin) • Design entry/verification using Xilinx and industry
- Multiple I/O banks on all devices standard CAE tools
- Unsurpassed low power management • Free software support for all densities using Xilinx
· DataGATE external signal control WebPACK™
- Flexible clocking modes • Industry leading nonvolatile 0.18 micron CMOS
· Optional DualEDGE triggered registers process
· Clock divider (÷ 2,4,6,8,10,12,14,16) - Guaranteed 1,000 program/erase cycles
· CoolCLOCK - Guaranteed 20 year data retention
- Global signal options with macrocell control
· Multiple global clocks with phase selection per Family Overview
macrocell Xilinx CoolRunner™-II CPLDs deliver the high speed and
· Multiple global output enables
ease of use associated with the XC9500/XL/XV CPLD fam-
· Global set/reset
ily with the extremely low power versatility of the XPLA3™
- Abundant product term clocks, output enables and
family in a single CPLD. This means that the exact same
set/resets
parts can be used for high-speed data communications/
- Efficient control term clocks, output enables and
computing systems and leading edge portable products,
set/resets for each macrocell and shared across
with the added benefit of In System Programming. Low
function blocks
power consumption and high-speed operation are com-
- Advanced design security
bined into a single family that is easy to use and cost effec-
- Open-drain output option for Wired-OR and LED
tive. Clocking techniques and other power saving features
drive
extend the users’ power budget. The design features are
- Optional bus-hold, 3-state or weak pullup on select
supported starting with Xilinx ISE 4.1i ISE WebPACK. Addi-
I/O pins
tional details can be found in Further Reading, page 390.
- Optional configurable grounds on unused I/Os
Table 1 shows the macrocell capacity and key timing
parameters for the CoolRunner-II CPLD family.
Table 1: CoolRunner-II CPLD Family Parameters
Macrocells 32 64 128 256 384 512
Max I/O 33 64 100 184 240 270
TPD (ns) 3.8 4.6 5.7 5.7 7.1 7.1
TSU (ns) 1.9 2.0 2.4 2.4 2.9 2.6
TCO (ns) 3.7 3.9 4.2 4.5 5.8 5.8
FSYSTEM1 (MHz) 323 263 244 256 217 179
DS090 (v2.7) June 21, 2006 www.xilinx.com 377

Product Specification
R
Table 2: CoolRunner-II CPLD DC Characteristics

ICC (μA), 0 MHz, 25°C (typical) 16 17 19 21 23 25
ICC (mA), 50 MHz, 70°C (max) 2.5 5 10 27 45 55
ICC is dynamic current.
Table 2 shows key DC characteristics for the CoolRunner-II With the exception of the new Pb-free QF packages, there
family. are at least two densities present in each package with
Table 3 shows the CoolRunner-II CPLD package offering three in the VQ100 (100-pin 1.0mm QFP) and TQ144
with corresponding I/O count. All packages are surface (144-pin 1.4mm QFP), and in the FT256 (256-ball 1.0mm
mount, with over half of them being ball-grid technologies. spacing FLBGA). The FT256 is particularly important for
The ultra tiny packages permit maximum functional capacity slim dimensioned portable products with mid- to high-den-
in the smallest possible area. The CMOS technology used sity logic requirements.
in CoolRunner-II CPLDs generates minimal heat, allowing
the use of tiny packages during high-speed operation.
Table 3: CoolRunner-II CPLD Family Packages and I/O Count

XC2C32(2) XC2C32A XC2C64(2) XC2C64A XC2C128 XC2C256 XC2C384 XC2C512
QFG32(1) 21 - - - - - -
PC44 33 33 33 33 - - - -
PCG44(1) 33 33 - - - -
VQ44 33 33 33 33 - - - -
VQG44(1) 33 33 - - - -
QFG48(1) - - - 37 - - - -
CP56 33 33 45 45 - - - -
CPG56(1) 33 45 - - - -
VQ100 - - 64 64 80 80 - -
VQG100(1) - - 64 80 80 - -
CP132 - - - - 100 106 - -
CPG132(1) - - - - 100 106 - -
TQ144 - - - - 100 118 118 -
TQG144(1) - - - - 100 118 118 -
PQ208 - - - - - 173 173 173
PQG208(1) - - - - - 173 173 173
FT256 - - - - - 184 212 212
FTG256(1) - - - - - 184 212 212
FG324 - - - - - - 240 270
FGG324(1) - - - - - - 240 270
Notes:
1. The letter "G" as the third character indicates a Pb-free package.
2. The XC2C32 and XC2C64 are not recommended for new designs. Use the XC2C32A and XC2C64A.
Table 4 details the distribution of advanced features across that four I/O banks are needed on 32 and 64 macrocell
the CoolRunner-II CPLD family. The family has uniform parts, but very likely they are for 384 and 512 macrocell
basic features with advanced features included in densities parts. The I/O banks are groupings of I/O pins using any
where they are most useful. For example, it is very unlikely one of a subset of compatible voltage standards that share
378 www.xilinx.com DS090 (v2.7) June 21, 2006

R
the same VCCIO level. (See Table 5 for a summary of

CoolRunner-II I/O standards.)
Table 4: CoolRunner-II CPLD Family Features
XC2C32(2) XC2C32A XC2C64(2) XC2C64A XC2C128 XC2C256 XC2C384 XC2C512

IEEE 1532 ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
I/O banks 1 2 1 2 2 2 4 4
Clock division - - - - ✓ ✓ ✓ ✓
DualEDGE ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Registers
DataGATE - - - - ✓ ✓ ✓ ✓
LVTTL ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
LVCMOS33, 25, ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
18, and 15(1)
SSTL2_1 - - - - ✓ ✓ ✓ ✓
SSTL3_1 - - - - ✓ ✓ ✓ ✓
HSTL_1 - - - - ✓ ✓ ✓ ✓
Configurable ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
ground
Quadruple data ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
security
Open drain outputs ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Hot plugging ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
Schmitt Inputs ✓ ✓ ✓ ✓ ✓ ✓ ✓ ✓
1. LVCMOS15 requires the use of Schmitt-trigger inputs.
2. The XC2C32 and XC2C64 are not recommended for new designs. Use the XC2C32A and XC2C64A.
Architecture Description building block delivers the industry’s highest pinout reten-
tion, under very broad design conditions. The architecture
CoolRunner-II CPLD is a highly uniform family of fast, low
will be explained by expanding the detail as we discuss the
power CPLDs. The underlying architecture is a traditional
underlying Function Blocks, logic and interconnect.
CPLD architecture combining macrocells into Function
Blocks (FBs) interconnected with a global routing matrix, The design software automatically manages these device
the Xilinx Advanced Interconnect Matrix (AIM). The Func- resources so that users can express their designs using
tion Blocks use a Programmable Logic Array (PLA) configu- completely generic constructs without knowledge of these
ration which allows all product terms to be routed and architectural details. More advanced users can take advan-
shared among any of the macrocells of the FB. Design soft- tage of these details to more thoroughly understand the
ware can efficiently synthesize and optimize logic that is software’s choices and direct its results.
subsequently fit to the FBs and connected with the ability to Figure 1 shows the high-level architecture whereby Func-
utilize a very high percentage of device resources. Design tion Blocks attach to pins and interconnect to each other
changes are easily and automatically managed by the soft- within the internal interconnect matrix. Each FB contains 16
ware, which exploits the 100% routability of the Programma- macrocells. The BSC path is the JTAG Boundary Scan Con-
ble Logic Array within each FB. This extremely robust

R
trol path. The BSC and ISP block has the JTAG controller
and In-System Programming Circuits.
BSC Path
Clock and Control Signals
Function Function
Block 1 Block n
I/O Pin MC1 MC1 I/O Pin
16 FB 16 FB
I/O Blocks
I/O Blocks
16 PLA PLA 16
40
AIM 40

Direct Inputs Direct Inputs
16 16
JTAG BSC and ISP
DS090_01_121201
Figure 1: CoolRunner-II CPLD Architecture
Function Block extremely flexible, and very robust when compared to fixed
or cascaded product term function blocks.
The CoolRunner-II CPLD Function Blocks contain 16 mac-
rocells, with 40 entry sites for signals to arrive for logic cre- Classic CPLDs typically have a few product terms available
ation and connection. The internal logic engine is a 56 for a high-speed path to a given macrocell. They rely on
product term PLA. All Function Blocks, regardless of the capturing unused p-terms from neighboring macrocells to
number contained in the device, are identical. For a expand their product term tally, when needed. The result of
high-level view of the Function Block, see Figure 2. this architecture is a variable timing model and the possibil-
ity of stranding unusable logic within the FB.
MC1 The PLA is different — and better. First, any product term
MC2
can be attached to any OR gate inside the FB macrocell(s).
Second, any logic function can have as many p-terms as
needed attached to it within the FB, to an upper limit of 56.
Third, product terms can be re-used at multiple macrocell
40 PLA 16
Out
OR functions so that within a FB, a particular logical product
need only be created once, but can be re-used up to 16
To AIM
times within the FB. Naturally, this plays well with the fitting
software, which identifies product terms that can be shared.
The software places as many of those functions as it can
into FBs, so it happens for free. There is no need to force
MC16
macrocell functions to be adjacent or any other restriction
3 save residing in the same FB, which is handled by the soft-
ware. Functions need not share a common clock, common
Global Global
Set/Reset Clocks
set/reset or common output enable to take full advantage of
the PLA. Also, every product term arrives with the same
DS090_02_101001
time delay incurred. There are no cascade time adders for
Figure 2: CoolRunner-II CPLD Function Block putting more product terms in the FB. When the FB product
term budget is reached, there is a small interconnect timing
At the high level, it is seen that the product terms (p-terms) penalty to route signals to another FB to continue creating
reside in a programmable logic array (PLA). This structure is logic. Xilinx design software handles all this automatically.

R
Macrocell resets, and output enables. Each macrocell flip-flop is con-

figurable for either single edge or DualEDGE clocking, pro-
The CoolRunner-II CPLD macrocell is extremely efficient
viding either double data rate capability or the ability to
and streamlined for logic creation. Users can develop sum
distribute a slower clock (thereby saving power). For single
of product (SOP) logic expressions that comprise up to 40
edge clocking or latching, either clock polarity may be
inputs and span 56 product terms within a single function
selected per macrocell. CoolRunner-II macrocell details are
block. The macrocell can further combine the SOP expres-
shown in Figure 3. Note that in Figure 4, standard logic
sion into an XOR gate with another single p-term expres-
symbols are used except the trapezoidal multiplexers have
sion. The resulting logic expression’s polarity is also
input selection from statically programmed configuration
selectable. As well, the logic function can be pure combina-
select lines (not shown). Xilinx application note XAPP376
torial or registered, with the storage element operating
gives a detailed explanation of how logic is created in the
selectably as a D or T flip-flop, or transparent latch. Avail-
CoolRunner-II CPLD family.
able at each macrocell are independent selections of global,
function block level or local p-term derived clocks, sets,
From AIM
40
49 P-terms
To PTA, PTB, PTC of
other macrocells
4 P-terms Direct Input
from Feedback
CTC, CTR, I/O Block to AIM
CTS, CTE
PTA
PTA
PTB CTS
GSR
VCC
GND
PTC
GND To I/O Block

S
D/T Q
PLA OR Term PTC CE FIF

Latch
CK DualEDGE
GCK0
GCK1 R
CTC GCK2
PTA
PTC
CTR
GSR
GND
DS090_03_121201
Figure 3: CoolRunner-II CPLD Macrocell
When configured as a D-type flip-flop, each macrocell has tional functionality is retained for use as a buried logic node
an optional clock enable signal permitting state hold while a if needed. FToggle is the maximum clock frequency to which
clock runs freely. Note that Control Terms (CT) are available a T flip-flop can reliably toggle.
to be shared for key functions within the FB, and are gener-
ally used whenever the exact same logic function would be Advanced Interconnect Matrix (AIM)
repeatedly created at multiple macrocells. The CT product The Advanced Interconnect Matrix is a highly connected
terms are available for FB clocking (CTC), FB asynchro- low power rapid switch. The AIM is directed by the software
nous set (CTS), FB asynchronous reset (CTR), and FB out- to deliver up to a set of 40 signals to each FB for the cre-
put enable (CTE). ation of logic. Results from all FB macrocells, as well as, all
Any macrocell flip-flop can be configured as an input regis- pin inputs circulate back through the AIM for additional con-
ter or latch, which takes in the signal from the macrocell’s nection available to all other FBs as dictated by the design
I/O pin, and directly drives the AIM. The macrocell combina-

R
software. The AIM minimizes both propagation delay and also available. Table 5 summarizes various supported volt-
power as it makes attachments to the various FBs. age standards associated with specific part capacities. All
inputs and disabled outputs are voltage tolerant up to 3.3V.
I/O Block The CoolRunner-II family supports SSTL2-1, SSTL3-1 and
I/O blocks are primarily transceivers. However, each I/O is HSTL-1 high-speed I/O standards in the 128-macrocell and
either automatically compliant with standard voltage ranges larger devices. Figure 4 details the I/O pin, where it is noted
or can be programmed to become so. See XAPP382 for that the inputs requiring comparison to an external refer-
detailed information on CoolRunner-II I/Os. ence voltage are available. These I/O standards all require
In addition to voltage levels, each input can selectively VREF pins for proper operation. The CoolRunner-II CPLD
arrive through Schmitt-trigger inputs. This adds a small time allows any I/O pin to act as a VREF pin, granting the board
delay, but substantially reduces noise on that input pin. layout engineer extra freedom when laying out the
Approximately 500 mV of hysteresis will be added when pins.However, if VREF pin placement is not done properly,
Schmitt-trigger inputs are selected. All LVCMOS inputs can additional VREF pins may be required, resulting in a loss of
have hysteresis input. Hysteresis also allows easy genera- potential I/O pins or board re-work. See XAPP399 for
tion of external clock circuits. The Schmitt-trigger path is details regarding VREF pins and their placement.
best seen in Figure 4. See Table 5 for Schmitt-trigger com- VREF has pin-range requirements that must be observed.
patibility with I/O standards. The Xilinx software aids designers in remaining within the
Outputs can be directly driven, 3-stated or open-drain con- proper pin range.
figured. A choice of slow or fast slew rate output signal is
Available on 128 Macrocell Devices and Larger

To AIM
VREF Global termination
Hysteresis Pullup/Bus-Hold
To Macrocell
Direct Input
Enabled
CTE
PTB VCCIO
4
GTS[0:3]
CGND
Open Drain From Macrocell
Disabled DS090_04_121201
Figure 4: CoolRunner-II CPLD I/O Block Diagram
Table 5 summarizes the single ended I/O standard support

and shows which standards require VREF values and board
termination. VREF detail is given in specific data sheets.
Table 5: CoolRunner-II CPLD I/O Standard Summary

IOSTANDARD Board Termination Voltage
Attribute VCCIO Input VREF (VTT) Schmitt-trigger Support
LVTTL 3.3 N/A N/A Optional
LVCMOS33 3.3 N/A N/A Optional
LVCMOS15 1.5 N/A N/A Not optional
HSTL_1 1.5 0.75 0.75 Not optional
SSTL2_1 2.5 1.25 1.25 Not optional
SSTL3_1 3.3 1.5 1.5 Not optional

R
Output Banking effectively blocking controlled switching signals so they do

not drive internal chip capacitances. Output signals that do
CPLDs are widely used as voltage interface translators. To
not switch, are held by the bus hold feature. Any set of input
that end, the output pins are grouped in large banks. The
pins can be chosen to participate in the DataGATE function.
XC2C32 and XC2C64 devices are not banked, but the new
Figure 5 shows the familiar CMOS ICC versus switching fre-
XC2C32A and XC2C64A devices have two banks. The
quency graph. With DataGATE, designers can approach
medium parts (128 and 256 macrocell) support two output
zero power, should they choose to, in their designs
banks. With two, the outputs will switch to one of two
selected output voltage levels, unless both banks are set to Figure 6 shows how DataGATE basically works. One I/O
the same voltage. The larger parts (384 and 512 macrocell) pin drives the DataGATE Assertion Rail. It can have any
support four output banks split evenly. They can support desired logic function on it. It can be as simple as mapping
groupings of one, two, three or four separate output voltage an input pin to the DataGATE function or as complex as a
levels. This kind of flexibility permits easy interfacing to 3.3V, counter or state machine output driving the DataGATE I/O
2.5V, 1.8V, and 1.5V in a single part. pin through a macrocell. When the DataGATE rail is
asserted high, any pass transistor switch attached to it is
DataGATE blocked. Note that each pin has the ability to attach to the
AIM through a DataGATE pass transistor, and thus be
Low power is the hallmark of CMOS technology. Other
blocked. A latch automatically captures the state of the pin
CPLD families use a sense amplifier approach to creating
when it becomes blocked. The DataGATE Assertion Rail
product terms, which always has a residual current compo-
threads throughout all possible I/Os, so each can partici-
nent being drawn. This residual current can be several hun-
pate if chosen. Note that one macrocell is singled out to
dred milliamps, making them unusable in portable systems.
drive the rail, and that macrocell is exposed to the outside
CoolRunner-II CPLDs use standard CMOS methods to cre-
world through a pin, for inspection. If DataGATE is not
ate the CPLD architecture and deliver the corresponding
needed, this pin is an ordinary I/O.
low current consumption, without doing any special tricks.
However, sometimes designers would like to reduce their
system current even more by selectively disabling circuitry
not being used.
The patented DataGATE technology was developed to per-
mit a straightforward approach to additional power reduc-
tion. Each I/O pin has a series switch that can block the ICC
arrival of free running signals that are not of interest. Sig-
nals that serve no use may increase power consumption,
0 Frequency
and can be disabled. Users are free to do their design, then
choose sections to participate in the DataGATE function.
DataGATE is a logic function that drives an assertion rail DS090_05_101001
threaded through the medium and high-density Figure 5: CMOS ICC vs. Switching Frequency Curve
CoolRunner-II CPLD parts. Designers can select inputs to
be blocked under the control of the DataGATE function,

R
DataGATE Assertion Rail
MC1 MC1
MC2 MC2
Latch
To AIM
PLA PLA
Latch Latch
To AIM To AIM
MC16 MC16
AIM
MC1 MC1
MC2 MC2
PLA PLA
Latch Latch
To AIM To AIM
MC16 MC16
DS090_06_111201
Figure 6: DataGATE Architecture (output drivers not shown)
Global Signals purpose I/O if they are not needed as global signals. The
DataGATE assertion rail is also a global signal.
Global signals, clocks (GCK), sets/resets (GSR) and output
enables (GTS), are designed to strongly resemble each
other. This approach enables design software to make the
best utilization of their capabilities. Each global capability is
supplemented by a corresponding product term version.
Figure 7 shows the common structure of the global signal
trees. The pin input is buffered, then drives multiple internal
global signal traces to deliver low skew and reduce loading
delays. GCK, GSR, and GTS can also be used as general
DS090_07_101001
Figure 7: Global Clocks (GCK), Sets/Resets (GSR) and

Output Enables (GTS)

R
Additional Clock Options: Division, cell. The source to double can be a control term clock, a
DualEDGE, and CoolCLOCK product term clock or one of the available global clocks. The
ability to switch on both clock edges is vital for a number of
Division synchronous memory interface applications as well as cer-
Circuitry has been included in the CoolRunner-II CPLD tain double data rate I/O applications.
architecture to divide one externally supplied global clock by CoolCLOCK
standard values. Division by 2,4,6,8,10, 12, 14 and 16 are
the options (see Figure 8). This capability is supplied on the In addition to the DualEDGE flip-flop, additional power sav-
GCK2 pin. The resulting clock produced will be 50% duty ings can be had by combining the clock division circuitry
cycle for all possible divisions. Note that a Synchronous with the DualEDGE circuitry. This capability is called Cool-
Reset (CDRST) is included to guarantee no runt clocks can CLOCK and is designed to reduce clocking power within the
get through to the global clock nets. Note that again, the sig- CPLD. Because the clock net can be an appreciable power
nal is buffered and driven to multiple traces with minimal drain, the clock power can be reduced by driving the net at
loading and skew. half frequency, then doubling the clock rate using
DualEDGE triggering at the macrocells. Figure 10 shows
DualEDGE how CoolCLOCK is created by internal clock cascading with
Each macrocell has the ability to double its input clock the divider and DualEDGE flip-flop working together. See
switching frequency. Figure 9 shows the macrocell flip-flop XAPP378 for more detail.
with the DualEDGE option (doubled clock) at each macro-
÷2
÷4
÷6
GCK2 Clock ÷8
÷10
In
÷12
÷14
÷16
CDRST
CDRST DS090_08_121201
Figure 8: Clock Division Circuitry for GCK2
D/T Q
PTC CE FIF
Latch
GCK0 CK ✓DualEDGE
GCK1
CLK_CT GCK2
PTC
DS090_09_121201
Figure 9: Macrocell Clock Chain with DualEDGE Option Shown

R
D/T Q
PTC CE FIF
Latch
GCK0 CK ✓DualEDGE
GCK1
CTC GCK2
PTC
÷2
÷4
÷6
GCK2 Clock ÷8
÷10
In
÷12
÷14
÷16
Synch Rst
Synch Reset
Figure 10: CoolCLOCK Created by Cascading Clock Divider and DualEDGE Option
Design Security eliminating any electrical or visual detection of configuration

patterns. These security bits can be reset only by erasing
Designs can be secured during programming to prevent
the entire device. See WP170 for more detail.
either accidental overwriting or pattern theft via readback.
Four independent levels of security are provided on-chip,

R
Timing Model onto the specific part, and knows the specific delay values
for a given speed grade. Equations for the higher level tim-
Figure 11 shows the CoolRunner-II CPLD timing model. It
ing values (i.e., TPD and FSYSTEM) are available. Table 6
represents one aspect of the overall architecture from a tim-
summarizes the individual parameters and provides a brief
ing viewpoint. Each little block is a time delay that a signal
definition of their associated functions. Xilinx application
will incur if the signal passes through such a resource. Tim-
note XAPP375 details the CoolRunner-II CPLD family tim-
ing reports are created by tallying the incremental signal
ing with several examples.
delays as signals progress within the CPLD. Software cre-
ates the timing reports after a design has been mapped
TF
TLOGI2 TPDI
TIN TLOGI1 D/T TCOI

TSUI THI
THYS TSLEW
TECSU
TDIN
TECHO TOUT
THYS TCT CE TAOI
TGCK TEN
S/R
THYS
TOEM
TGSR
THYS
TGTS
THYS XAPP375_03_010303
Figure 11: CoolRunner-II CPLD Timing Model

Note: Always refer to the timing report in ISE Software for accurate timing values for paths.
Table 6: Timing Parameter Definitions Table 6: Timing Parameter Definitions (Continued)

Symbol Parameter Symbol Parameter
Buffer Delays Macrocell Delays
TlN Input Buffer Delay TPDI Macro cell input to output valid
TDIN Direct data register input delay TSUI Macro register setup before clock
TGCK Global clock (GCK) buffer delay THI Macro register hold after clock
TGSR Global set/reset (GSR) buffer delay TECSU Macro register enable clock setup time
TGTS Global output enable (GTS) buffer delay TECHO Macro register enable clock hold time
TOUT Output buffer delay TCOI Macro register clock to output valid
TEN Output buffer enable/disable delay TAOI Macro register set/reset to output valid
TSLEW Output buffer slew rate control delay THYS Hysteresis selection delay adder
P-term Delays Feedback Delays
TCT Control Term delay (single PT or FB-CT) TF Feedback delay
TLOGI1 Single P-term logic delay TOEM Macrocell to Global OE delay
TLOGI2 Multiple P-term logic delay adder

R
Programming as well. The internal controllers can operate as fast as 66

MHz.
The programming data sequence is delivered to the device
using either Xilinx iMPACT software and a Xilinx download Table 7: JTAG Instructions
cable, a third-party JTAG development system, a
JTAG-compatible board tester, or a simple microprocessor Code Instruction Description
interface that emulates the JTAG instruction sequence. The 00000000 EXTEST Force boundary scan data onto
iMPACT software also outputs serial vector format (SVF) outputs
files for use with any tools that accept SVF format, including
00000011 PRELOAD Latch macrocell data into
automatic test equipment. See CoolRunner-II Application
boundary scan cells
Notes for more information on how to program.
11111111 BYPASS Insert bypass register between
In System Programming TDI and TDO
All CoolRunner-II CPLD parts are 1.8V in system program- 00000010 INTEST Force boundary scan data onto
mable. This means they derive their programming voltage inputs and feedbacks
and currents from the 1.8V VCC (internal supply voltage) 00000001 IDCODE Read IDCODE
pins on the part. The VCCIO pins do not participate in this
11111101 USERCODE Read USERCODE
operation, as they may assume another voltage ranging as
high as 3.3V down to 1.5V. A 1.8V VCC is required to prop- 11111100 HIGHZ Force output into high
erly operate the internal state machines and charge pumps impedance state
that reside within the CPLD to do the nonvolatile program- 11111010 CLAMP Latch present output state
ming operations. The JTAG interface buffers are powered by
a dedicated power pin, VCCAUX, which is independent of all
other supply pins. VCCAUX must be connected. Xilinx soft- Power-Up Characteristics
ware is provided to deliver the bit-stream to the CPLD and CoolRunner-II CPLD parts must operate under the
drive the appropriate IEEE 1532 protocol. To that end, there demands of both the high-speed and the portable market
is a set of IEEE 1532 commands that are supported in the places, therefore, they must support hot plugging for the
CoolRunner-II CPLD parts. Programming times are less high-speed world and tolerate most any power sequence to
than one second for 32 to 256 macrocell parts. Program- its various voltage pins. They must also not draw excessive
ming times are less than four seconds for 384 and 512 mac- current during power-up initialization. To those ends, the
rocell parts. Programming of CoolRunner-II CPLDs is only general behavior is summarized as follows:
guaranteed when operating in the commercial temperature
and voltage ranges as defined in the device-specific data 1. I/O pins are disabled until the end of power-up.
sheets. 2. As supply rises, configuration bits transfer from
nonvolatile memory to SRAM cells.
On-The-Fly Reconfiguration (OTF) 3. As power up completes, the outputs become as
Xilinx ISE 5.2i supports OTF for CoolRunner-II CPLDs. This configured (input, output, or I/O).
permits programming a new nonvolatile pattern into the part 4. For specific configuration times and power up
while another pattern is currently in use. OTF has the same requirements, see the device specific data sheet.
voltage and temperature specifications as system program- CoolRunner-II CPLD I/O pins are well behaved under all
ming. During pattern transition I/O pins are in high imped- operating conditions. During power-up, CoolRunner-II
ance with weak pullup to VCCIO. Transition time typically devices employ internal circuitry which keeps the devices in
lasts between 50 and 300 μs, depending on density. See the quiescent state until the VCCINT supply voltage is at a
XAPP388 for more information. safe level (approximately 1.3V). In the quiescent state,
JTAG pins are disabled, and all device outputs are disabled
JTAG Instructions with the pins weakly pulled high, as shown in Table 8. When
Table 7 shows the commands available to users. These the supply voltage reaches a safe level, all user registers
same commands may be used by third party ATE products, become initialized, and the device is immediately available
for operation, as shown in Figure 12. Best results are
obtained with a smooth VCC rise in less than 4 ms. Final
VCC value should occur within 1 second.
If the device is in the erased state (before any user pattern
is programmed), the device outputs remain disabled with a
weak pull-up. The JTAG pins are enabled to allow the device

R
to be programmed at any time. All devices are shipped in

the erased state from the factory. VCCINT
Applying power to a blank part may result in a higher current

flow as the part initializes. This behavior is normal and may
persist for approximately 2 seconds, depending on the 1.3V
3.8 V
(Typ)
(Typ)
power supply ramp.
If the device is programmed, the device inputs and outputs 1.0V
take on their configured states for normal operation. The
JTAG pins are enabled to allow device erasure or
boundary-scan tests at any time. 0V
No Quiescent No
User Operation
Power State Power
Subthreshold Initialization of User Registers

State Quiescent DS090_12_061406
State
Figure 12: Device Behavior During Power Up
Table 8: I/O Power-Up Characteristics

Erased Device
Device Circuitry Subthreshold State Quiescent State Operation Valid User Operation
IOB Bus-Hold/Weak Undetermined Weak Pull-up Weak Pull-up Bus-Hold/Weak
Pullup Pullup
Device Outputs Undetermined Disabled Disabled As Configured
Device Inputs and Undetermined Disabled Disabled As Configured
Clocks
Function Block Undetermined Disabled Disabled As Configured
JTAG Controller Undetermined Disabled Enabled Enabled
I/O Banking applied to the VCCIO and VCC pins can occur in any order
and the CoolRunner-II CPLD will not be damaged. For best
CoolRunner-II CPLD XC2C32 and XC2C64 macrocell parts
results, we recommend that VCCINT be applied before
support a single VCCIO rail that can range from 3.3V down to
VCCIO. This will ensure that the internal logic is correct
1.5V operation. Two VCCIO rails are supported on the
before the I/Os are active. CoolRunner-II CPLDs can reside
XC2C32A, XC2C64A, 128 and 256 macrocell parts where
on boards where the board is inserted into a “live” connector
outputs on each rail can independently range from 3.3V
(hot plugged) and the parts will be well-behaved as if pow-
down to 1.5V operation. Four VCCIO rails are supported on
ering up in a standard way.
the 384 and 512 macrocell parts. Any of the VCCIO rails can
assume any one of the VCCIO values of 1.5V, 1.8V, 2.5V, or
3.3V. Designers should assign input and output voltages to
Development System Support
a bank with VCCIO set at the voltage range of that input or Xilinx CoolRunner-II CPLDs are supported by all configura-
output voltage. The VCC (internal supply voltage) for a Cool- tions of Xilinx standard release development software as
Runner-II CPLD must be maintained within 1.8V ±5% for well as the freely available ISE WebPACK software avail-
correct speed operation and proper in system program- able from www.xilinx.com. Third party development tools
ming. include synthesis tools from Cadence, Exemplar, Mentor
Graphics, Synplicity, and Synopsys.
Mixed Voltage, Power Sequencing, and
Hot Plugging ATE Support
As mentioned in I/O Banking, CoolRunner-II CPLD parts Third party ATE development support is available for both
support mixed voltage I/O signals. It is important to assign programming and board/chip level testing. Vendors provid-
signals to an I/O bank with the appropriate I/O voltage. Driv- ing this support include Agilent, GenRad, and Teradyne.
ing a high voltage into a low voltage bank can result in neg- Other third party providers are expected to deliver solutions
ative current flow through the power supply pins. The power in the future.

R
Absolute Maximum Ratings(1)
Symbol Parameter Min. Max. Unit

VCC(2) Supply voltage relative to GND –0.5 2.0 V
VI(3) Input voltage relative to GND –0.5 4.0 V
TJ(4) Maximum junction temperature –40 150 °C
TSTR Storage temperature –65 150 °C
Notes:
1. Stresses above those listed may cause malfunction or permanent damage to the device. This is a stress rating only. Functional
operation at these or any other condition above those indicated in the operational and programming specification is not implied.
2. The chip supply voltage should rise monotonically.
3. Maximum DC undershoot below GND must be limited to either 0.5V or 10 mA, whichever is easier to achieve. During transitions, the
device pins may undershoot to –2.0V or overshoot to 4.5 V, provided this over- or undershoot lasts less than 10 ns and with the
forcing current being limited to 200 mA. The I/O voltage may never exceed 4.0V.
4. For soldering guidelines and thermal considerations, see the Device Packaging information on the Xilinx website. For Pb-free
packages, see XAPP427.
Quality and Reliability Parameters
Symbol Parameter Min Max Units

TDR Data retention 20 - Years
NPE Program/erase cycles (Endurance) 1,000 - Cycles
VESD Electrostatic discharge(1) 2,000 - Volts
Notes:
1. ESD is measured to 2000V using the human body model. Pins exposed to this limit can incur additional leakage current to
a maximum of 10 μA when driven to 3.9V.
Warranty Disclaimer
THESE PRODUCTS ARE SUBJECT TO THE TERMS OF THE XILINX LIMITED WARRANTY WHICH CAN BE VIEWED
AT http://www.xilinx.com/warranty.htm. THIS LIMITED WARRANTY DOES NOT EXTEND TO ANY USE OF THE
PRODUCTS IN AN APPLICATION OR ENVIRONMENT THAT IS NOT WITHIN THE SPECIFICATIONS STATED ON THE
THEN-CURRENT XILINX DATA SHEET FOR THE PRODUCTS. PRODUCTS ARE NOT DESIGNED TO BE FAIL-SAFE
AND ARE NOT WARRANTED FOR USE IN APPLICATIONS THAT POSE A RISK OF PHYSICAL HARM OR LOSS OF
LIFE. USE OF PRODUCTS IN SUCH APPLICATIONS IS FULLY AT THE RISK OF CUSTOMER SUBJECT TO
APPLICABLE LAWS AND REGULATIONS.
Further Reading http://direct.xilinx.com/bvdocs/appnotes/xapp379.pdf

(High Speed Design)
Application Notes http://direct.xilinx.com/bvdocs/appnotes/xapp380.pdf
http://direct.xilinx.com/bvdocs/appnotes/xapp784.pdf (Cross Point Switch)
(Bulletproof Design Practices) http://direct.xilinx.com/bvdocs/appnotes/xapp381.pdf
http://direct.xilinx.com/bvdocs/appnotes/xapp375.pdf (Demo Board)
(Timing Model) http://direct.xilinx.com/bvdocs/appnotes/xapp382.pdf
http://direct.xilinx.com/bvdocs/appnotes/xapp376.pdf (I/O Characteristics)
(Logic Engine) http://direct.xilinx.com/bvdocs/appnotes/xapp383.pdf
http://direct.xilinx.com/bvdocs/appnotes/xapp377.pdf (Single Error Correction Double Error Detection)
(Low Power Design) http://direct.xilinx.com/bvdocs/appnotes/xapp384.pdf
http://direct.xilinx.com/bvdocs/appnotes/xapp378.pdf (DDR SDRAM Interface)
(Advanced Features) http://direct.xilinx.com/bvdocs/appnotes/xapp387.pdf
(PicoBlaze Microcontroller)

R
http://direct.xilinx.com/bvdocs/appnotes/xapp388.pdf http://direct.xilinx.com/bvdocs/publications/ds311.pdf
(On the Fly Reconfiguration) (XC2C64A Datasheet)
(Powering CoolRunner-II) (XC2C128 Datasheet)
(8051 Microcontroller Interface) (XC2C256 Datasheet)
(Interfacing with Mobile SDRAM) (XC2C384 Datasheet)
(Assigning CoolRunner-II VREF Pins) (XC2C512 Datasheet)
CoolRunner-II Data Sheets CoolRunner-II White Papers

http://direct.xilinx.com/bvdocs/publications/ds090.pdf http://direct.xilinx.com/bvdocs/whitepapers/wp170.pdf
(CoolRunner-II Family Datasheet) (Security)
http://direct.xilinx.com/bvdocs/publications/ds310.pdf Packages
(XC2C32A Datasheet)
Package Drawings
Revision History
The following table shows the revision history for this document.

07/04/02 1.1 Revisions and updates
07/24/02 1.2 Revisions and updates
09/24/02 1.3 Additions to "Power Characteristics" section
01/28/03 1.4 Addition of the "Further Reading" section
02/26/03 1.5 Multiple minor revisions
03/12/03 1.6 Minor revision to "Quality and Reliability Parameters"
10/09/03 1.7 Update Hewlett-Packard to Agilent, OFR to OTF, and other revisions
01/26/04 1.8 Incorporate links to Data Sheets, Application Notes, and Device Packages
02/26/04 1.9 Change to Power-Up Characteristics, page 11. Change TFIN to TDIN. Add Schmitt-trigger
I/O compatibility information. Added TSOL specification.
05/21/04 2.0 Add XC2C32A and XC2C64A devices.
07/30/04 2.1 Pb-free documentation. Changes to TSU and Fsystem to match individual data sheets.
01/10/05 2.2 Added information about programming options, page 11.
03/07/05 2.3 Changes to Table 1, TPD, TSU, TCO, and FSYSTEM1. Removed link to obsolete White Paper.
Modifications to Table 5, IOSTANDARDs. Added Table 2, DC Characteristics.
04/15/05 2.4 Change to FSYSTEM1 for XC2C128.

R

06/28/05 2.5 Move to Product Specification
03/20/06 2.6 Add Warranty Disclaimer; modified Global Signals section to say that GCK, GSR and GTS
can be used as general purpose I/O.
06/21/06 2.7 Change to Hot Plugging recommendations, page 13 (VCCINT before VCCIO power
sequencing). Changed Figure 12 and Table 8, page 13, to add Subthreshold State.

k
R XC9500XL High-Performance CPLD

Family Data Sheet
DS054 (v2.2) June 21, 2006 0 0 Product Specification
Features - Local clock inversion with three global and one

product-term clocks
• Optimized for high-performance 3.3V systems
- Individual output enable per output pin with local
- 5 ns pin-to-pin logic delays, with internal system
inversion
frequency up to 208 MHz
- Input hysteresis on all user and boundary-scan pin
- Small footprint packages including VQFPs, TQFPs
inputs
and CSPs (Chip Scale Package)
- Bus-hold circuitry on all user pin inputs
- Pb-free available for all packages
- Supports hot-plugging capability
- Lower power operation
- Full IEEE Standard 1149.1 boundary-scan (JTAG)
- 5V tolerant I/O pins accept 5V, 3.3V, and 2.5V
support on all devices
signals
• Four pin-compatible device densities
- 3.3V or 2.5V output capability
- 36 to 288 macrocells, with 800 to 6400 usable
- Advanced 0.35 micron feature size CMOS
gates
FastFLASH technology
• Fast concurrent programming
• Advanced system features
• Slew rate control on individual outputs
- In-system programmable
• Enhanced data security features
- Superior pin-locking and routability with
FastCONNECT II™ switch matrix • Excellent quality and reliability
- Extra wide 54-input Function Blocks - 10,000 program/erase cycles endurance rating
- Up to 90 product-terms per macrocell with - 20 year data retention
individual product-term allocation • Pin-compatible with 5V core XC9500 family in common
package footprints
Table 1: XC9500XL Device Family
XC9536XL XC9572XL XC95144XL XC95288XL
Macrocells 36 72 144 288
Usable Gates 800 1,600 3,200 6,400
Registers 36 72 144 288
TPD (ns) 5 5 5 6
TSU (ns) 3.7 3.7 3.7 4.0
TCO (ns) 3.5 3.5 3.5 3.8
fSYSTEM (MHz) 178 178 178 208

R
Table 2: XC9500XL Packages and User I/O Pins (not including 4 dedicated JTAG pins)
Package(1) XC9536XL XC9572XL XC95144XL XC95288XL
PC44 34 34 - -
PCG44 34 34
VQ44 34 34 - -
VQG44 34 34
CS48 36 38 - -
CSG48 36 38
VQ64 36 52 - -
VQG64 36 52
TQ100 - 72 81 -
TQG100 72 81
CS144 - - 117 -
CSG144 117
TQ144 - - 117 117
TQG144 117 117
PQ208 - - - 168
PQG208 168
BG256 - - - 192
BGG256 192
FG256 - - - 192
FGG256 192
CS280 - - - 192
CSG280 192
Notes:
(1) The letter "G" as the third character indicates a Pb-free package.

R
3
JTAG
JTAG Port In-System Programming Controller
Controller
54
Function
I/O 18 Block 1
Macrocells
I/O 1 to 18
I/O
FastCONNECT II Switch Matrix

I/O 54
Function
18 Block 2
Macrocells
I/O 1 to 18
Blocks
I/O
54
Function
I/O
18 Block 3
I/O Macrocells
1 to 18
I/O
3
I/O/GCK 54
1 Function
I/O/GSR 18 Block N
2 or 4 Macrocells
I/O/GTS 1 to 18
DS054_01_042001
Figure 1: XC9500XL Architecture

Note: Function block outputs (indicated by the bold lines) drive the I/O blocks directly.
Family Overview capacity are shown in Table 2. The XC9500XL family mem-
bers are fully pin-compatible, allowing easy design migra-
The FastFLASH XC9500XL family is a 3.3V CPLD family tion across multiple density options in a given package
targeted for high-performance, low-voltage applications in footprint.
leading-edge communications and computing systems,
where high device reliability and low power dissipation is The XC9500XL architectural features address the require-
important. Each XC9500XL device supports in-system pro- ments of in-system programmability. Enhanced pin-locking
gramming (ISP) and the full IEEE 1149.1 (JTAG) bound- capability avoids costly board rework. In-system program-
ary-scan, allowing superior debug and design iteration ming throughout the full commercial operating range and a
capability for small form-factor packages. The XC9500XL high programming endurance rating provide worry-free
family is designed to work closely with the Xilinx Virtex, reconfigurations of system field upgrades. Extended data
Spartan-XL and XC4000XL FPGA families, allowing system retention supports longer and more reliable system operat-
designers to partition logic optimally between fast interface ing life.
circuitry and high-density general purpose logic. As shown Advanced system features include output slew rate control
in Table 1, logic density of the XC9500XL devices ranges and user-programmable ground pins to help reduce system
from 800 to 6400 usable gates with 36 to 288 registers, noise. Each user pin is compatible with 5V, 3.3V, and 2.5V
respectively. Multiple package options and associated I/O inputs, and the outputs may be configured for 3.3V or 2.5V

R
operation. The XC9500XL device exhibits symmetric full Function Block

3.3V output voltage swing to allow balanced rise and fall
times. Additional details can be found in the application Each Function Block, as shown in Figure 2 is comprised of
notes listed in "Further Reading" on page 403. 18 independent macrocells, each capable of implementing
a combinatorial or registered function. The FB also receives
global clock, output enable, and set/reset signals. The FB
Architecture Description generates 18 outputs that drive the FastCONNECT switch
Each XC9500XL device is a subsystem consisting of multi- matrix. These 18 outputs and their corresponding output
ple Function Blocks (FBs) and I/O Blocks (IOBs) fully inter- enable signals also drive the IOB.
connected by the FastCONNECT II switch matrix. The IOB
Logic within the FB is implemented using a sum-of-products
provides buffering for device inputs and outputs. Each FB
representation. Fifty-four inputs provide 108 true and com-
provides programmable logic capability with extra wide
plement signals into the programmable AND-array to form
54inputs and 18 outputs. The FastCONNECT II switch
90 product terms. Any number of these product terms, up to
matrix connects all FB outputs and input signals to the FB
the 90 available, can be allocated to each macrocell by the
inputs. For each FB, up to 18 outputs (depending on pack-
product term allocator.
age pin-count) and associated output enable signals drive
directly to the IOBs. See Figure 1
Macrocell 1
Programmable Product
AND-Array Term
Allocators 18 To FastCONNECT II
From 54 Switch Matrix
FastCONNECT II 18
Switch Matrix OUT
To I/O Blocks
18
PTOE
Macrocell 18
1 3
Global Global
Set/Reset Clocks
DS054_02_042101
Figure 2: XC9500XL Function Block
Macrocell including clock, clock enable, set/reset, and output enable.

The product term allocator associated with each macrocell
Each XC9500XL macrocell may be individually configured
selects how the five direct terms are used.
for a combinatorial or registered function. The macrocell
and associated FB logic is shown in Figure 3. The macrocell register can be configured as a D-type or
T-type flip-flop, or it may be bypassed for combinatorial
Five direct product terms from the AND-array are available
operation. Each register supports both asynchronous set
for use as primary data inputs (to the OR and XOR gates) to
and reset operations. During power-up, all user registers
implement combinatorial functions, or as control inputs

R
are initialized to the user-defined preload state (default to 0

if unspecified).
54 Global Global
Set/Reset Clocks
Additional
Product
Terms
(from other
macrocells)
Product Term Set
0
To
S FastCONNECTII
Switch Matrix
D/T Q
CE
Product
Term
Product Term Clock Enable R
Allocator
Product Term Clock
Product Term Reset

OUT
To
Product Term OE PTOE I/O Blocks
Additional
Product
Terms
(from other
macrocells)
DS054_03_042101
Figure 3: XC9500XL Macrocell Within Function Block
All global control signals are available to each individual term clock. Both true and complement polarities of the
macrocell, including clock, set/reset, and output enable sig- selected clock source can be used within each macrocell. A
nals. As shown in Figure 4, the macrocell register clock GSR input is also provided to allow user registers to be set
originates from either of three global clocks or a product to a user-defined state.

R
Macrocell
Product Term Set
S
D/T
Product Term Clock
CE
R
Product Term Reset
I/O/GSR
Global Set/Reset
I/O/GCK1 Global Clock 1
DS05404_042101
Figure 4: Macrocell Clock and Set/Reset Capability

R
Product Term Allocator Note that the incremental delay affects only the product
terms in other macrocells. The timing of the direct product
The product term allocator controls how the five direct prod- terms is not changed.
uct terms are assigned to each macrocell. For example, all
five direct terms can drive the OR function as shown in
Figure 5. Product Term
Allocator
Product Term
Allocator
Macrocell
Product Term
Logic
Product Term
Allocator
DS054_05_042101
Figure 5: Macrocell Logic Using Direct Product Term
The product term allocator can re-assign other product Macrocell Logic
terms within the FB to increase the logic capacity of a mac- With 15
rocell beyond five direct terms. Any macrocell requiring Product Terms
additional product terms can access uncommitted product
terms in other macrocells within the FB. Up to 15 product
terms can be available to a single macrocell with only a
small incremental delay of tPTA, as shown in Figure 6.
Product Term
Allocator
DS054_06_042101
Figure 6: Product Term Allocation With 15 Product

Terms

R
The product term allocator can re-assign product terms

from any macrocell within the FB by combining partial sums Product Term
of products over several macrocells, as shown in Figure 7. Allocator
In this example, the incremental delay is only 2*TPTA. All 90
product terms are available to any macrocell, with a maxi-
mum incremental delay of 8*TPTA.
Macrocell Logic
With 2
Product Terms
Product Term
Allocator
Product Term
Allocator
Macrocell Logic
With 18
Product Terms
Product Term
Allocator
DS054_07 _042101
Figure 7: Product Term Allocation Over Several

Macrocells

R
The internal logic of the product term allocator is shown in

Figure 8.
From Upper To Upper

Macrocell Macrocell
Product Term
Allocator
Product Term Set
Global Set/Reset
S
D/T Q
CE
Global Clocks R
Product Term Clock
Product Term Reset
Global Set/Reset
Product Term OE
From Lower To Lower

Macrocell Macrocell
DS054_08_042101
Figure 8: Product Term Allocator Logic

R
FastCONNECT II Switch Matrix sponding to user pin inputs) and all FB outputs drive the
FastCONNECT II matrix. Any of these (up to a fan-in limit of
The FastCONNECT II Switch Matrix connects signals to the 54) may be selected to drive each FB with a uniform delay.
FB inputs, as shown in Figure 9. All IOB outputs (corre-
FastCONNECT II
Switch Matrix
Function Block
I/O Block
(54) 18
D/T Q
I/O
Function Block
I/O Block
(54)
18
D/T Q
I/O
DS054_09_042101
Figure 9: FastCONNECT II Switch Matrix

R
I/O Block buffer, output driver, output enable selection multiplexer,

and user programmable ground control. See Figure 10 for
The I/O Block (IOB) interfaces between the internal logic details.
and the device user I/O pins. Each IOB includes an input
To other
Macrocells
I/O Block
To FastCONNECT
Switch Matrix
Macrocell Bus-Hold
OUT I/O
(Inversion in
AND-array) 1 User-
Product Term OE PTOE Programmable
Ground
0
Slew Rate
Control
I/O/GTS1 Global OE 1
Available in XC95144XL
I/O/GTS3 Global OE 3 and XC95288XL
DS054_10_042101
Figure 10: I/O Block and Output Enable Capability
The input buffer is compatible with 5V CMOS, 5V TTL, 3.3V (50 mV typical) to help reduce system noise for input signals
CMOS, and 2.5V CMOS signals. The input buffer uses the with slow rise or fall edges.
internal 3.3V voltage supply (VCCINT) to ensure that the
Each output driver is designed to provide fast switching with
input thresholds are constant and do not vary with the
minimal power noise. All output drivers in the device may be
VCCIO voltage. Each input buffer provides input hysteresis

R
configured for driving either 3.3V CMOS levels (which are grounding capability. This grounding of the pin is achieved
compatible with 5V TTL levels as well) or 2.5V CMOS levels by internal logic that forces a logic low output regardless of
by connecting the device output voltage supply (VCCIO) to a the internal macrocell signal, so the internal macrocell logic
3.3V or 2.5V voltage supply. Figure 11 shows how the is unaffected by the programmable ground pin capability.
XC9500XL device can be used in 3.3V only systems and
Each IOB also provides for bus-hold circuitry (also called a
mixed voltage systems with any combination of 5V, 3.3V
“keeper”)that is active during valid user operation. The
and 2.5V power supplies.
bus-hold feature eliminates the need to tie unused pins
Each output driver can also be configured for slew-rate lim- either high or low by holding the last known state of the input
ited operation. Output edge rates may be slowed down to until the next input signal is present. The bus-hold circuit
reduce system noise (with an additional time delay of tSLEW) drives back the same state via a nominal resistance (RBH)
under user control. See Figure 12. of 50k ohms. See Figure 13. Note the bus-hold output will
drive no higher than VCCIO to prevent overdriving signals
The output enable may be generated from one of four
when interfacing to 2.5V components.
options: a product term signal from the macrocell, any of the
global output enable signals (GTS), always “1,” or always When the device is not in valid user operation, the bus-hold
“0.” There are two global output enables for devices with 72 circuit defaults to an equivalent 50k ohm pull-up resistor in
or fewer macrocells, and four global output enables for order to provide a known repeatable device state. This
devices with 144 or more macrocells. Any selected output occurs when the device is in the erased state, in program-
enable signal may be inverted locally at each pin output to ming mode, in JTAG INTEST mode, or during initial
provide maximal design flexibility. power-up. A pull-down resistor (1k ohm) may be externally
added to any pin to override the default RBH resistance to
Each IOB provides user programmable ground pin capabil-
force a low state during power-up or any of these other
ity. This allows device I/O pins to be configured as additional
modes.
ground pins in order to force otherwise unused pins to a low
voltage state, as well as provide for additional device
5V CMOS 5V CMOS
5V 5V
3.3V
3.3V 2.5V
0V 0V
5V TTL or VCCINT VCCIO 5V TTL or VCCINT VCCIO

5V 5V
3.3V CMOS, 5V TTL 2.5V CMOS
0V XC9500XL 0V XC9500XL
3.3V 2.5V
CPLD CPLD OUT
3.3V CMOS or IN OUT 3.3V CMOS or IN
0V 0V
3.3V 3.3V
0V 0V
GND GND
2.5V CMOS 2.5V CMOS
2.5V 2.5V
0V (a) 0V (b)
DS054_11_042101
Figure 11: XC9500XL Devices in (a) 3.3V only and (b) Mixed 5V/3.3V/2.5V Systems
5V Tolerant I/Os Xilinx proprietary ESD circuitry and high impedance initial
state permit hot plugging cards using these devices.
The I/Os on each XC9500XL device are fully 5V tolerant
even though the core power supply is 3.3 volts. This allows Pin-Locking Capability
5V CMOS signals to connect directly to the XC9500XL
inputs without damage. In addition, the 3.3V VCCINT power The capability to lock the user defined pin assignments dur-
supply can be applied before or after 5V signals are applied ing design iteration depends on the ability of the architec-
to the I/Os. In mixed 5V/3.3V/2.5V systems, the user pins, ture to adapt to unexpected changes. The XC9500XL
the core power supply (VCCINT), and the output power sup- devices incorporate architectural features that enhance the
ply (VCCIO) may have power applied in any order. This ability to accept design changes while maintaining the same
makes the XC9500XL devices immune to power supply pinout.
sequencing problems.

R
The XC9500XL architecture provides for superior pin-lock- For extensive design changes requiring higher logic capac-
ing characteristics with a combination of large number of ity than is available in the initially chosen device, the new
routing switches in the FastCONNECT II switch matrix, a design may be able to fit into a larger pin-compatible device
54-wide input Function Block, and flexible, bi-directional using the same pin assignments. The same board may be
product term allocation within each macrocell. These fea- used with a higher density device without the expense of
tures address design changes that require adding or chang- board rework.
ing internal routing, including additional signals into existing
equations, or increasing equation complexity, respectively.
Output Output
Voltage Voltage
VCCIO
Standard
Slew-Rate Limited
Slew-Rate Limited
TSLEW TSLEW
1.5V 1.5V
Standard
Time Time
0 0
(a) (b)
DS054_12_042101
Figure 12: Output Slew-Rate Control For (a) Rising and (b) Falling Outputs
All I/Os are 3-stated and pulled high by the bus-hold cir-
Set to PIN cuitry during in-system programming. If a particular signal
during valid user must remain low during this time, then a pulldown resistor
operation Drive to may be added to the pin.
VCCIO Level
0 External Programming
PIN XC9500XL devices can also be programmed by the Xilinx
RBH HW-130 device programmer as well as third-party program-
mers. This provides the added flexibility of using pre-pro-
grammed devices during manufacturing, with an in-system
programmable option for future enhancements and design
changes.
I/O
Reliability and Endurance
DS054_13_042101 All XC9500XL CPLDs provide a minimum endurance level
of 10,000 in-system program/erase cycles and a minimum
Figure 13: Bus-Hold Logic data retention of 20 years. Each device meets all functional,
performance, and data retention specifications within this
In-System Programming endurance limit.
One or more XC9500XL devices can be daisy chained
together and programmed in-system via a standard 4-pin IEEE 1149.1 Boundary-Scan (JTAG)
JTAG protocol, as shown in Figure 14. In-system program- XC9500XL devices fully support IEEE 1149.1 bound-
ming offers quick and efficient design iterations and elimi- ary-scan (JTAG). EXTEST, SAMPLE/PRELOAD, BYPASS,
nates package handling. The Xilinx development system USERCODE, INTEST, IDCODE, HIGHZ and CLAMP
provides the programming data sequence using a Xilinx instructions are supported in each device. Additional
download cable, a third-party JTAG development system, instructions are included for in-system programming opera-
JTAG-compatible board tester, or a simple microprocessor tions.
interface that emulates the JTAG instruction sequence.

R
Design Security vated when the device needs to be reprogrammed with a

valid pattern with a specific sequence of JTAG instructions.
XC9500XL devices incorporate advanced data security fea-
tures which fully protect the programming data against Table 3: Data Security Options
unauthorized reading or inadvertent device erasure/repro-
Read Security
gramming. Table 3 shows the four different security settings
available. Default Set
The read security bits can be set by the user to prevent the Read Allowed Read Inhibited
internal programming pattern from being read or copied.
Write Security
Default Program/Erase Program Inhibited
When set, they also inhibit further program operations but
allow device erase. Erasing the entire device is the only way Allowed Erase Allowed
to reset the read security bit. Read Allowed Read Inhibited
The write security bits provide added protection against Set Program/Erase Program/Erase
accidental device erasure or reprogramming when the Allowed Inhibited
JTAG pins are subject to noise, such as during system
power-up. Once set, the write-protection may be deacti-
V CC
GND
(a) (b) X5902
Figure 14: System Programming Operation (a) Solder Device to PCB and (b) Program Using Download Cable
Low Power Mode Timing Model

All XC9500XL devices offer a low-power mode for individual The uniformity of the XC9500XL architecture allows a sim-
macrocells or across all macrocells. This feature allows the plified timing model for the entire device. The basic timing
device power to be significantly reduced. model, shown in Figure 15, is valid for macrocell functions
that use the direct product terms only, with standard power
Each individual macrocell may be programmed in
setting, and standard slew rate setting. Table 4 shows how
low-power mode by the user. Performance-critical parts of
each of the key timing parameters is affected by the product
the application can remain in standard power mode, while
term allocator (if needed), low-power setting, and slew-lim-
other parts of the application may be programmed for
ited setting.
low-power operation to reduce the overall power dissipation.
Macrocells programmed for low-power mode incur addi- The product term allocation time depends on the logic span
tional delay (tLP) in pin-to-pin combinatorial delay as well as of the macrocell function, which is defined as one less than
register setup time. Product term clock to output and prod- the maximum number of allocators in the product term path.
uct term output enable delays are unaffected by the macro- If only direct product terms are used, then the logic span is
cell power-setting. Signals switching at rates less than 50 ns 0. The example in Figure 6 shows that up to 15 product
rise/fall time should be assigned to the macrocells config- terms are available with a span of 1. In the case of Figure 7,
ured in low power mode. the 18 product term function has a span of 2.

R
Detailed timing information may be derived from the full tim- for each parameter are given in the individual device data
ing model shown in Figure 16. The values and explanations sheets.
Combinatorial Combinatorial
Logic Logic D/T Q
TCO
Propagation Delay = TPD Setup Time = TSU Clock to Out Time = TCO
(a) (b)
TPSU
Combinatorial
Logic D/T Q
Combinatorial
P-Term Clock Logic D/T Q
Path
TPCO
Setup Time = TPSU Clock to Out Time = TPCO Internal System Cycle Time = TSYSTEM
(c) (d)
DS054_15_042101
Figure 15: Basic Timing Model
TF
TLOGILP S*TPTA TSLEW

TPDI
TIN TLOGI D/T Q TOUT
TSUI TCOI
THI
TPTCK
CE TAOI
TGCK TRAI TEN
TPTSR SR
TGSR
TPTTS
Macrocell
TGTS
DS054_16_042101
Figure 16: Detailed Timing Model

R
Power-Up Characteristics XC9500XL family as well as other CPLD and FPGA fami-
lies.
The XC9500XL devices are well behaved under all operat-
ing conditions. During power-up each XC9500XL device The Alliance Series includes CPLD and FPGA implementa-
employs internal circuitry which keeps the device in the qui- tion technology as well as all necessary libraries and inter-
escent state until the VCCINT supply voltage is at a safe level faces for Alliance partner EDA solutions.
(approximately 2.5V). During this time, all device pins and
JTAG pins are disabled and all device outputs are disabled FastFLASH Technology
with the pins weakly pulled high, as shown in Table 5. When An advanced 0.35 micron feature size CMOS Flash process is
the supply voltage reaches a safe level, all user registers used to fabricate all XC9500XL devices. The FastFLASH pro-
become initialized (typically within 200 μs), and the device is cess provides high performance logic capability, fast pro-
immediately available for operation, as shown in Figure 17. gramming times, and superior reliability and endurance
If the device is in the erased state (before any user pattern ratings.
is programmed), the device outputs remain disabled with
weak pull-up. The JTAG pins are enabled to allow the device VCCINT
to be programmed at any time. All devices are shipped in
the erased state from the factory.
If the device is programmed, the device inputs and outputs 2.5V
3.8 V
(Typ)
(Typ)
take on their configured states for normal operation. The
JTAG pins are enabled to allow device erasure or bound-
ary-scan tests at any time. 1.0V
Development System Support 0V

No Quiescent No
User Operation
The XC9500XL family and associated in-system program- Power State Power
ming capabilities are fully supported in either software solu- Subthreshold Initialization of User Registers
State Quiescent
tions available from Xilinx. State
DS054_17_042101
The Foundation Series is an all-in-one development system

containing schematic entry, HDL (VHDL, Verilog, and Figure 17: Device Behavior During Power-up
ABEL), and simulation capabilities. It supports the
Table 4: Timing Model Parameters

Product Term Macrocell Output Slew-Limited
Parameter Description Allocator(1) Low-Power Setting Setting
TPD Propagation Delay + TPTA * S + TLP + TSLEW
TSU Global Clock Setup Time + TPTA * S + TLP –
TCO Global Clock-to-output - - + TSLEW
TPSU Product Term Clock Setup Time + TPTA * S + TLP -
TPCO Product Term Clock-to-output - - + TSLEW
TSYSTEM Internal System Cycle Period + TPTA * S + TLP -
Notes:
1. S = the logic span of the function, as defined in the text.
Table 5: XC9500XL Pin Characteristics

Erased Device
Device Circuitry Subthreshold State Quiescent State Operation Valid User Operation
IOB Bus-Hold Undetermined Pull-up Pull-up Bus-Hold
Device I/O and Clocks Undetermined Disabled Disabled As Configured
JTAG Controller Undetermined Disabled Enabled Enabled

R
Warranty Disclaimer
THESE PRODUCTS ARE SUBJECT TO THE TERMS OF THE XILINX LIMITED WARRANTY WHICH CAN BE VIEWED
AT http://www.xilinx.com/warranty.htm. THIS LIMITED WARRANTY DOES NOT EXTEND TO ANY USE OF THE
PRODUCTS IN AN APPLICATION OR ENVIRONMENT THAT IS NOT WITHIN THE SPECIFICATIONS STATED ON THE
THEN-CURRENT XILINX DATA SHEET FOR THE PRODUCTS. PRODUCTS ARE NOT DESIGNED TO BE FAIL-SAFE
AND ARE NOT WARRANTED FOR USE IN APPLICATIONS THAT POSE A RISK OF PHYSICAL HARM OR LOSS OF
LIFE. USE OF PRODUCTS IN SUCH APPLICATIONS IS FULLY AT THE RISK OF CUSTOMER SUBJECT TO
APPLICABLE LAWS AND REGULATIONS.
Further Reading
The following Xilinx links go to relevant XC9500XL CPLD documentation, including XAPP111, Using the XC9500XL Timing
Model, and XAPP784, Bulletproof CPLD Design Practices. Simply click on the link and scroll down.
Data Sheets, Application Notes, and White Papers. Packaging
Revision History
The following table shows the revision history for this document.

10/02/98 1.1 Figure 1 correction
02/03/99 1.2 Included hot socket reference; revised layout; BGA package change for XC95288XL
04/02/99 1.3 Minor typesetting corrections.
06/07/99 1.4 Minor typesetting corrections.
06/07/99 1.5 Added CS280 package
01/25/02 1.6 Added DS054 data sheet number. Added 44-pin VQFP package. Updated Device Family
table.
02/07/03 1.7 Added "Further Reading" section
08/02/04 1.8 Added Pb-free documentation
11/11/04 1.9 Changes to package designations in Table 2 on page 2.
07/15/05 2.0 Move to Product Specification
03/22/06 2.1 Add Warranty Disclaimer
06/21/06 2.2 Added Subthreshold State to Figure 17 and Table 5, page 16.

R


CPLD Applications Handbook

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CPLD Applications Handbook

Uploaded by

Copyright:

Available Formats

Xilinx CPLD Applications

Featuring CoolRunner-II and

ii www.xilinx.com June 26, 2006

Preface: About This Handbook

Chapter 1: Introduction to Digital Applications

IrDA and UART Design in a CoolRunner CPLD

Serial ADC Interface Using a CoolRunner CPLD

Wireless Transceiver for the CoolRunner CPLD

CoolRunner-II Smart Card Reader

Digital Applications Handbook www.xilinx.com iii

CoolRunner-II CPLD Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

CoolRunner-II CPLD I2C Bus Controller Implementation

CoolRunner-II Serial Peripheral Interface Master

Design of a Digital Camera with CoolRunner-II CPLDs

CompactFlash Card Interface for CoolRunner-II CPLDs

iv www.xilinx.com Digital Applications Handbook

Attribute Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Interfacing to Mobile SDRAM with CoolRunner-II CPLDs

An SMBus/I2C-Compatible Port Expander

Driving LEDs with Xilinx CPLDs

CoolRunner-II CPLDs in Cell Phone Handsets/Terminals

Implementing Keypad Scanners with CoolRunner-II

Digital Applications Handbook www.xilinx.com v

Level Translation Using Xilinx CoolRunner-II CPLDs

CoolRunner-II Character LCD Module Interface

Using Xilinx CPLDs to Interface to a NAND Flash Memory Device

Cell Phone Security Demoboard

Using CoolRunner-II with OMAP, XScale, i.MX & Other Chipsets

Connecting Intel PXA27x Processors to Hard-Disk Drives

vi www.xilinx.com Digital Applications Handbook

A Low-Power IDE Controller Design Using a CoolRunner-II CPLD

Using a Xilinx CoolRunner-II CPLD as a Data Stream Switch

Supporting Multiple SD Devices with CoolRunner-II CPLDs

Chapter 2: Introduction to Low Power Design

The Real Value of CoolRunner-II DataGATE

Power Evaluation Equation for CoolRunner-II CPLDs

Low Power Design with CoolRunner-II CPLDs

Digital Applications Handbook www.xilinx.com vii

Power Saving Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Chapter 3: Xilinx Design Software

Chapter 4: WebPACK ISE Design Entry

Chapter 5: Implementing CPLD Designs

viii www.xilinx.com Digital Applications Handbook

Chapter 6: Introduction to Logic Consolidation

The Advantages of Migrating from Discrete 7400 Logic Devices to

TTL “Burn Rate” for Xilinx CPLDs

Appendix A: Xilinx CPLD Data Sheets

CoolRunner-II CPLD Family

Digital Applications Handbook www.xilinx.com ix

XC9500XL High-Performance CPLD Family Data Sheet

x www.xilinx.com Digital Applications Handbook

About This Handbook

June 26, 2006 www.xilinx.com xi

Preface: About This Handbook

• Nick Mehta • Frank Wirtz

• Tony Grant • Betsy Thibault

Introduction to Digital Applications

Digital Consumer Applications www.xilinx.com 1

2 www.xilinx.com Digital Consumer Applications

Figure 1: IrDA Block Diagram

XAPP345 (v1.3) December 23, 2003 www.xilinx.com 3

IrDA and UART Design in a CoolRunner CPLD