R

Xilinx CPLD Applications
Handbook
Featuring CoolRunner-II and
XC9500XL CPLDs
ii www.xilinx.com June 26, 2006
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.
R
Digital Applications Handbook www.xilinx.com iii
June 26, 2006
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
Table of Contents
iv www.xilinx.com Digital Applications Handbook
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 I
2
C Bus Controller Implementation
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
I
2
C Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
CoolRunner-II I
2
C Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Signal Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Microprocessor Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
I
2
C 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
Digital Applications Handbook www.xilinx.com v
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/I
2
C-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
vi www.xilinx.com Digital Applications Handbook
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
Digital Applications Handbook www.xilinx.com vii
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
Design Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
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
V
CCINT
Current Savings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
What About V
CCIO
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
viii www.xilinx.com Digital Applications Handbook
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
Design Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
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
Digital Applications Handbook www.xilinx.com ix
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
x www.xilinx.com Digital Applications Handbook
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
June 26, 2006 www.xilinx.com xi
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
CoolRunner
TM
-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 CoolRunner
TM
XPLA3
3.3V CPLD family, the high performance XC9500XL
TM
3.3V CPLD family, and the
XC9500
TM
5.0V family.
xii www.xilinx.com
June 26, 2006
Preface: About This Handbook
R
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:
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:
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.
• Nick Mehta • Frank Wirtz
• Jesse Jenkins • John Hubbard
• Mark Ng • Jennifer Jenkins
• Scott Lien • Mike Gulotta
• Tony Grant • Betsy Thibault
• Roger Seaman • LaToya Parker
Digital Consumer Applications www.xilinx.com 1
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 I
2
C 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/I
2
C-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
2 www.xilinx.com Digital Consumer Applications
June 26, 2006
Chapter 1
R
XAPP345 (v1.3) December 23, 2003 www.xilinx.com 3
1-800-255-7778
© 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.
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
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
Application Note: CoolRunner CPLD
XAPP345 (v1.3) December 23, 2003
IrDA and UART Design in a CoolRunner
CPLD
R
Figure 1: IrDA Block Diagram
UART
RS232
μP
μC
X345_01_080601
Modulation/
Demodulation
Serial Out
Serial In
Infrared
Receive
Infrared
Transmit
4 www.xilinx.com XAPP345 (v1.3) December 23, 2003
1-800-255-7778
IrDA and UART Design in a CoolRunner CPLD
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.
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
Design
Figure 3 illustrates the system architecture for implementing a UART serial port interface with
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.
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.
Figure 2: IrDA 3/16 Data Modulation
UART
TXD
(NRZ)
Start
Bit
0 1 0 1 0 0 1 1 0 1
Data Bits
Bit
Time
Stop
Bit
IR_TXD
(RZI)
X345_02_080601
3/16
Figure 3: UART and IrDA Block Diagram
TRANSMIT
TXD
Parallel
Data
Byte
16XCLK
RCV
UART
X345_03_080601
RECEIVE
IR_ENCODE
IrDA
IR_DECODE
IR_TXD
IR_RCV
IrDA and UART Design in a CoolRunner CPLD
XAPP345 (v1.3) December 23, 2003 www.xilinx.com 5
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.
The serial data out, SOUT follows the format shown in Figure 5.
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.
Figure 4: UART Main Interface Logic
Figure 5: UART Data Out Format
Figure 6: Assigning Transmit Data
RECEIVE
SIN
16XCLK
UART
X345_04_080701
RESET
Parity Error
Parallel
Data Byte
READ
Framing Error
Overrun Error
RX_RDY
TX_RDY
WRITE
M
u
x
H
o
l
d

R
e
g
i
s
t
e
r
S
h
i
f
t

R
e
g
i
s
t
e
r
Control
Logic
TRANSMIT
SOUT
H
o
l
d

R
e
g
i
s
t
e
r
S
h
i
f
t

R
e
g
i
s
t
e
r
Control
Logic
Start
Bit
LSB MSB
8 Data Bits
Parity
Bit
X345_05_080701
Stop
Bit
IDLE
write = '1'
write = '0'
ASSIGN
write = '1'
DATA_RDY
X345_06_080701
6 www.xilinx.com XAPP345 (v1.3) December 23, 2003
1-800-255-7778
IrDA and UART Design in a CoolRunner CPLD
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.
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.
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
Figure 7: TXCLK Generate Logic
Figure 8: SOUT Control Logic
START
reset = '0'
cnt < 8
reset = '1'
IDLE
cnt = 0 cnt = 8
INCR
X345_07_080701
START
reset = '0'
reset = '1'
IDLE
reset = '1'
reset = '0' and txdone = '1'
and txdatardy = '0'
START
TRANSMIT
txdone = '0' or
txdatardy = '0'
SHIFT
OUT
txdone ='0' and
paritycycle = '0'
paritycycle = '1'
PARITY
OUT
txdone = '1'
STOP
OUT
X345_08_080701
IrDA and UART Design in a CoolRunner CPLD
XAPP345 (v1.3) December 23, 2003 www.xilinx.com 7
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.
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.
Figure 9: UART Receive Logic
START
reset = '0'
reset = '1'
IDLE
sin = '1'
sin = '0' sin = '1'
DETECT
EDGE
sin = '0'
rxclk = '1'
SHIFT IN
DATA
GENERATE
PARITY
Stop Bit
Detected
?
Yes
No
SET ERROR
FLAGS
X345_09_080701
8 www.xilinx.com XAPP345 (v1.3) December 23, 2003
1-800-255-7778
IrDA and UART Design in a CoolRunner CPLD
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.
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.
CoolRunner
Implementation
The UART and IrDA design was implemented in Verilog as described above. Xilinx Project
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
Figure 10: IR HDL Block Diagram
Figure 11: IrDA Decoding Scheme
IR Module
(HSDL-7000)
X345_10_080701
LED Driver
IRTXD
IRRXD
Post
Amplifier
Pre-
Amplifier
LED
PIN
TXD
RXD
16XCLK
16XCLK
Start
Bit
1 0 1 1 1 0 1 1
Data Bits
16
Clock
Cycles
Stop
Bit
RXD
IRRXD
X345_11_080701
3/16
Ir DA and UART Desi gn i n a Cool Runner CPLD
XAPP345 (v1.3) December 23, 2003 www.xilinx.com 9
1-800-255-7778
R
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.
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.
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.
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%
Table 2: Standalone IrDA XPLA3 32-Macrocell Utilization
Resource Available Used Utilization
Function Blocks 2 1 50.0%
Macrocells 32 14 43.75%
Product Terms 96 26 27.10%
I/O Pins 32 4 12.50%
10 www.xilinx.com XAPP345 (v1.3) December 23, 2003
1-800-255-7778
IrDA and UART Design in a CoolRunner CPLD
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 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
Figure 12: UART and IrDA Transmit Simulation
IrDA and UART Design in a CoolRunner CPLD
XAPP345 (v1.3) December 23, 2003 www.xilinx.com 11
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.
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
Figure 13: Transmit and Receive Simulation
12 www.xilinx.com XAPP345 (v1.3) December 23, 2003
1-800-255-7778
IrDA and UART Design in a CoolRunner CPLD
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
History
The following table shows the revision history for this document.
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.
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 13
1-800-255-7778
© 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.
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.
Application Note: CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002
Serial ADC Interface Using a CoolRunner
CPLD
R
Figure 1: High Level Block Diagram
Texas
ADS7870
Instruments
A/D Converter
CoolRunner XPLA3
CPLD
Shift Data In
Shift Data Out
2.5 MHz CClk
SClk
A/D Control
Analog
Inputs
8 Ch
(4 Ch Diff.)
D
a
t
a
A
d
d
r
e
s
s
Toshiba
4Mbit SRAM
C
o
n
t
r
o
l
14 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
Figure 2: ADS7870 Block Diagram
X9499
Digital
I/O
REF
V
REF
BUF
IN
BUF
OUT
/REF
IN
ADS7870
Registers
and
Control
Serial
Interface
MUX PGA
BUF
12-Bit
A/D
I/O 0
CS
CONVERT
RESET
BUSY
RISE/FALL
SCLK
DIN
Clock
Divider
Oscillator
CCLK
OSC ENABLE
DOUT
+
-
Analog
Inputs
8 Ch
(4 Ch Diff.)
I/O 1
I/O 2
I/O 3
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 15
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
Divider/Oscillator
CCLK, the conversion clock, is used by the A/D. CCLK can either
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
(Voltage Reference)
The Voltage Reference block can generate an output voltage of 1.15V,
2.048V, or 2.5V on the V
REF
pin.
In single-ended operation, the Voltage Reference will determine the
maximum positive full scale input. For instance if V
REF
= 2.5V, an input
of 2.5V will yield a result of +2047.
In differential mode, V
REF
will determine the center point. Register 7
controls whether the reference is turned on or off. On the Insight
Springboard, the V
REF
pin is tied to the BUF
IN
pin.
BUF
(Buffer Amplifier)
The Buffer Amplifier takes the internally generated Voltage Reference
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 V
REF
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
(Programmable
Gain Amplifier)
The PGA is a Programmable Gain Amplifier that can amplify the input
signal before it is applied to the A/D Block. This is useful if the dynamic
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).
16 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
R
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.
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*
Registers and
Control
The ADS7870 has a total of 10 user addressable registers. These
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.
Figure 3: ADC and CPLD Serial Interface
Table 1: ADS7870 Functional Blocks (Continued)
Block Description
SCLK
DIN
DOUT
CS
ADC Serial
Interface
CPLD
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 17
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.
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
Figure 4: ADC Serial Timing Diagram
SCLK
DIN
data(7) data(6) data(1) data(0)
18 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
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.
Figure 5: ADC Interface Operational Flow
More
Channels
?
No
Yes
END
START
Write to necessary
ADC register
X355_05_080801
More
Registers
?
No
Yes
Start new conversion by
issuing a direct mode command
for specified input channel
Read back conversion data
Write conversion data to SRAM
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 19
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.
20 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
R
.
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,
Figure 6: MAIN State Machine Control Logic
IDLE
WRITE_ADDR
Register Mode
Assert go_shift <= "1"
& mode_flag = "0"
Assert go_shift <= "0"
Assert go_shift <= "1"
Assert go_shift <= "0"
WAIT_ADDR
shift_done = "0"
shift_done = "1"
shift_done = "0"
shift_done = "1"
ADDR_DATA
WAIT_DATA
More
Registers
?
No
Yes
X355_06_080801
DIRECT_MODE
Direct Mode
Assert go_shift <= "1"
Assert go_shift <= "0"
Assert go_shift <= "1"
& mode_flag = "1"
Assert go_shift <= "0"
WAIT_DM
shift_done = "0"
shift_done = "1"
shift_done = "0"
shift_done = "1"
ASSIGN_DATA
READ_DATA
More
Conversion
Cycles?
Yes
No
DONE
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 21
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.
22 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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 ************
constant DM_SNG_LN1_EN : BOOLEAN := TRUE;
constant DM_SNG_LN1 : STD_LOGIC_VECTOR(7 downto 0) := ’10001001’;
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 23
1-800-255-7778
R
constant SRAM_OFFSET1 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000001000’;
constant SRAM_HIGH1 : STD_LOGIC_VECTOR (22 downto 0) :=
’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.
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.
Figure 7: SHIFT State Machine Control Logic
IDLE
go_shift = "0"
go_shift = "1"
shift_done <= "1"
SC0
(CNT<8 & mode_flag = "0") or
(CNT<16 & mode_flag = "1")
(CNT = 8 & mode_flag = "0") or
(CNT = 16 & mode_flag = "1")
SC1
X355_07_080801
24 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
R
Allowing the
Visor to Read
Conversion
Results
After conversion results have been written to SRAM, the Handspring Visor must be given
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
of the MAIN state machine.
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.
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.
Figure 8: Data Bus Multiplexing in CoolRunner CPLD
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 25
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.
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.
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.
26 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
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.
MUX_SEL
0
1
SP_A[23:1]
23
A[23:1]
23
SM_ADDRESS
23
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 27
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.
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.
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.
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.)
Figure 10: Chip Select 1 MUX
Figure 11: Write Enable MUX
X9504
MUX_SEL
0
1
SPRING_CHIP1_ENn
SRAM_CHIP1_ENn
STATE_MACHINE_SRAM_ENn
X9505
MUX_SEL
0
1
SPRING_WRITE_ENn
READ_WRITEn
STATE_MACHINE_WE
28 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
Hardware
Implementation
Usage Example
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 RD_ADDR1_EN: BOOLEAN := FALSE;
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 RD_ADDR2_EN: BOOLEAN := FALSE;
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
constant WR_ADDR3_EN: BOOLEAN := TRUE;
Figure 12: Output Enable MUX
X9506
MUX_SEL
0
1
STATE_MACHINE_OE
OUTPUT_ENn
SPRING_OUTPUT_ENn
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 29
1-800-255-7778
R
-- 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’;
--********************* 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
constant ADDR4 : STD_LOGIC_VECTOR(7 downto 0) := ’00000100’;
-- Data to be written
constant DATA_WR_ADDR4: STD_LOGIC_VECTOR(7 downto 0) := ’00000000’;
--****************** ADDR5 (DIGITAL I/O STATE REGISTER) ***************
-- Description: ADDR5 sets/reveals the state of the digital IO pins.
-- R/W : R/W
constant WR_ADDR5_EN: BOOLEAN := TRUE;
-- Write/Read Digital I/O State Reg
constant ADDR5 : STD_LOGIC_VECTOR(7 downto 0) := ’00000101’;
-- Data to be written
constant DATA_WR_ADDR5: STD_LOGIC_VECTOR(7 downto 0) := ’00000101’;
--**************** 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
constant WR_ADDR6_EN: BOOLEAN := TRUE;
constant ADDR6 : STD_LOGIC_VECTOR(7 downto 0) := ’00000110’;
constant DATA_WR_ADDR6: STD_LOGIC_VECTOR(7 downto 0) := ’00001111’;
--**************** 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
constant WR_ADDR7_EN: BOOLEAN := TRUE;
constant ADDR7 : STD_LOGIC_VECTOR(7 downto 0) := ’00000111’;
constant DATA_WR_ADDR7: STD_LOGIC_VECTOR(7 downto 0) := ’00111100’;
--*************** ADDR24 (SERIAL INTERFACE CONTROL REGISTER) **********
-- Description: ADDR24 allows certain aspects of the serial interface to be
-- changed by the user
-- R/W : R/W
constant WR_ADDR24_EN: BOOLEAN := FALSE;
-- Serial Interface Control
constant ADDR24 : STD_LOGIC_VECTOR(7 downto 0) := ’00011000’;
constant DATA_WR_ADDR24: STD_LOGIC_VECTOR(7 downto 0) := ’00000000’;
--******************** ADDR31 (ID REGISTER) **********************
-- Description: ADDR31 reveals which version of ADS7870 is being used
-- R/W : READ ONLY
30 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
R
constant WR_ADDR31_EN: BOOLEAN := FALSE;
-- ID Register
constant ADDR31 : STD_LOGIC_VECTOR(7 downto 0) := ’00011111’;
-- ********* 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 *************
constant DM_SNG_LN1_EN : BOOLEAN := TRUE;
constant DM_SNG_LN1 : STD_LOGIC_VECTOR(7 downto 0) := ’10001001’;
constant SRAM_OFFSET1 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000001000’;
constant SRAM_HIGH1 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000001111’;
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 2 *************
constant DM_SNG_LN2_EN : BOOLEAN := TRUE;
constant DM_SNG_LN2 : STD_LOGIC_VECTOR(7 downto 0) := ’10001010’;
constant SRAM_OFFSET2 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000010000’;
constant SRAM_HIGH2 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000010111’;
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 3 *************
constant DM_SNG_LN3_EN : BOOLEAN := TRUE;
constant DM_SNG_LN3 : STD_LOGIC_VECTOR(7 downto 0) := ’10001011’;
constant SRAM_OFFSET3 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000011000’;
constant SRAM_HIGH3 : STD_LOGIC_VECTOR (22 downto 0) :=
"00000000000000000011111";
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 4 **************
constant DM_SNG_LN4_EN : BOOLEAN := TRUE;
constant DM_SNG_LN4 : STD_LOGIC_VECTOR(7 downto 0) := ’10001100’;
constant SRAM_OFFSET4 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000100000’;
constant SRAM_HIGH4 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000100111’;
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 5 **************
constant DM_SNG_LN5_EN : BOOLEAN := TRUE;
constant DM_SNG_LN5 : STD_LOGIC_VECTOR(7 downto 0) := ’10001101’;
constant SRAM_OFFSET5 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000101000’;
constant SRAM_HIGH5 : STD_LOGIC_VECTOR (22 downto 0) :=
"00000000000000000101111’;
-- ********** DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 6 *************
constant DM_SNG_LN6_EN : BOOLEAN := TRUE;
constant DM_SNG_LN6 : STD_LOGIC_VECTOR(7 downto 0) := ’10001110’;
constant SRAM_OFFSET6 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000110000’;
constant SRAM_HIGH6 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000110111’;
-- ********* DIRECT MODE CONVERSION SINGLE ENDED CHANNEL 7 **************
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 31
1-800-255-7778
R
constant DM_SNG_LN7_EN : BOOLEAN := TRUE;
constant DM_SNG_LN7 : STD_LOGIC_VECTOR(7 downto 0) := ’10001111’;
constant SRAM_OFFSET7 : STD_LOGIC_VECTOR (22 downto 0) :=
’00000000000000000111000’;
constant SRAM_HIGH7 : STD_LOGIC_VECTOR (22 downto 0) :=
’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
32 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
Step 2: Writing to ADDR6
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.
Figure 13: Writing to ADDR3
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 33
1-800-255-7778
R
Step 3: Writing to ADDR5
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.
Figure 14: Writing to ADDR6
34 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
R
Step 4: Writing to ADDR7
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", V
REF
is set to 2.5V. This sets the maximum full-scale input to 2.5V in single ended
Figure 15: Writing to ADDR5
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 35
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.
Figure 16: Writing to ADDR7
36 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
Direct Mode Command 2
The second direct mode command is issued on the next rising edge of SCLK (i.e., on the 25
th

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
Figure 17: Direct Mode Command 1
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 37
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).
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
Figure 18: Direct Mode Command 2
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
38 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
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.
Direct Mode Command 3
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/
Figure 19: Direct Mode Command 3
Serial ADC Interface Using a CoolRunner CPLD
XAPP355 (v1.1) January 3, 2002 www.xilinx.com 39
1-800-255-7778
R
VHDL Code
Download
VHDL source code and test benches are available for this design. THE DESIGN IS 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. 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.
XAPP355 - http://www.xilinx.com/products/xaw/coolvhdlq.htm
Revision
History
The following table shows the revision history for this document.
Date Version Revision
09/25/01 1.0 Initial Xilinx release.
01/03/02 1.1 Minor revisions.
40 www.xilinx.com XAPP355 (v1.1) January 3, 2002
1-800-255-7778
Serial ADC Interface Using a CoolRunner CPLD
R
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 41
1-800-255-7778
© 2001 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.
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).
CoolRunner
CPLD
Transceiver
Operation
This section describes the operation of the transceiver. The communication protocol is a
custom transmit and receive scheme, using Manchester encoding and Bit-Oriented Protocol
(BOP) theory.
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.
Application Note: CoolRunner™ CPLD
XAPP358 (v1.0) June 25, 2001
Wireless Transceiver for the CoolRunner
CPLD
R
Figure 1: CoolRunner Wireless Transceiver
42 www.xilinx.com XAPP358 (v1.0) June 25, 2001
1-800-255-7778
Wireless Transceiver for the CoolRunner CPLD
R
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
CPLD
Transceiver
Block Diagram
Transmit
The transmit block diagram is shown in Figure 3. Transmission comprises of three VHDL
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
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.
Figure 2: Communication Protocol
X358_02_062001
PREAMBLE
010101010101
Start Flag [11:0] End Flag [11:0]
Data [11:0]
LSB
POSTAMBLE
111100001111
Wireless Transceiver for the CoolRunner CPLD
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 43
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.
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.
Figure 3: Transmit Module Block Diagram
DISPLAY_COUNT
CHANGE_STATE
DISPLAY_COUNT
SWITCH_EN_H
DIGIT2 [8:0] DIGIT1 [8:0]
L
C
D
C
O
M
CUR_STATE_DATA
CUR_STATE
[8:0]
[8:0]
LOAD_DATA_H
C
O
N
T
R
O
L
T
X
SYS_CLK_H
SHIFT_ENABLE
TX MODULE
LCD
SYS_RST_L
RF MODULE
X358_03_062001
44 www.xilinx.com XAPP358 (v1.0) June 25, 2001
1-800-255-7778
Wireless Transceiver for the CoolRunner CPLD
R

Figure 4: Receive Module Block Diagram
CHANGE_STATE
DIGIT2 [8:0] DIGIT1 [8:0]
L
C
D
C
O
M
C
O
N
T
R
O
L
R
X
SYS_CLK_H
RX MODULE
LCD
SYS_RST_L
REG1 [12:0]
RF MODULE
X358_04_062001
REG2 [12:0]
REG3 [12:0]
REG4 [12:0]
SHIFT_DATA [35:0]
SHIFT OUT ONCE EDGE
DETECTED
RXIN [3:0]
Figure 5: Receive Module Block Diagram
Sample Period (1/2 Bit Period)
Ideal Sampling Illustration
New Bit
Sample Period (~3/4 Bit Period)
Non-Ideal Sampling Illustration
New Bit
X358_05_062001
Wireless Transceiver for the CoolRunner CPLD
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 45
1-800-255-7778
R
CPLD Transmit
Design
Transmit module contains the look up tables: CHANGE_STATE, RX_SYMBOLIZE, BIN7SEG.
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.
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).
Figure 6: TX_MODULE Block Diagram
Figure 7: Display Count Block Diagram
BIN7SEG RX_SYMBOLIZE
SYS_CLK_H SYS_RST_L
L
C
D
C
O
M
TX MODULE
CUR_STATE [3:0]
DIGIT1 [7:0] DIGIT2 [7:0]
TX_DATA [35:0]
[3:0]
[11:6] [5:0]
[3:0]
TX_DATA
S
H
I
F
T
_
O
U
T
RX_SYMBOLIZE
LCD
X358_06_062001
S
H
I
F
T
E
N
A
B
L
E
LCDCOM
D
I
S
P
L
A
Y
_
C
O
U
N
T
X358_07_062001
STATE_COUNT
SWITCH_EN_H
S
Y
S
_
C
L
K
_
H
DISPLAY_COUNT
S
H
I
F
T
_
E
N
A
B
L
E
T
X
_
M
O
D
U
L
E
COUNT
S
Y
S
_
R
S
T
_
L
46 www.xilinx.com XAPP358 (v1.0) June 25, 2001
1-800-255-7778
Wireless Transceiver for the CoolRunner CPLD
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 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.
Receive Module
Edge Detection
Receive
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).
Figure 8: SHIFT_ENABLE Block Diagram
Figure 9: SHIFT_OUT Block Diagram
X358_08_062001
TRANS_COUNT
LOAD_DATA_H
S
Y
S
_
C
L
K
_
H
SHIFT_ENABLE
SHIFT_OUT
D
I
S
P
L
A
Y
_
C
O
U
N
T
T
X
_
M
O
D
U
L
E
TRANS_BETWEEN_COUNT
SWITCH_EN_H
CUR_STATE [3:0]
S
Y
S
_
R
S
T
_
L
X358_09_062001
S
Y
S
_
C
L
K
_
H
SHIFT_OUT
S
H
I
F
T
_
E
N
A
B
L
E
T
X
_
M
O
D
U
L
E
PREAMBLE[11:0]
CUR_STATE_DATA[11:0]
POSTABLE[11:0]
LOAD_DATA_H
TX_DATA[35:0]
S
Y
S
_
R
S
T
_
L
CUR_STATE_DATA[11:0]
Wireless Transceiver for the CoolRunner CPLD
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 47
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.
Hardware
Description
The following describes the hardware used to develop the CoolRunner CPLD wireless
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.
Figure 10: Receive Edge Detection
Edge Detected 0101
Edge
SHIFT_DATA [35:0]
Initialize 0000000000000000000000000000000000000
Store Data
Based on baud rate
Pulse Width
Enable Counter
Increment counter on rising
edge of system clock
Sample at 1/2 pulse width.
Determine where to sample based
on value of counter
SHIFT_DATA [35:0]
Bit Stored
1000000000000000000000000000000000000
X358_10_062001
48 www.xilinx.com XAPP358 (v1.0) June 25, 2001
1-800-255-7778
Wireless Transceiver for the CoolRunner CPLD
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.
Keyboard Entry
Option
The following is a design implementation option for using keyboard entry with the CoolRunner
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.
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
Figure 11: Additional MOSFET Circuitry
RF
CPLD
R=100K
DMOS FET
Data Out
I/O Pin 99
(XPLA3 TQ144 Pin 122)
X358_11_062001
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
Wireless Transceiver for the CoolRunner CPLD
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 49
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.
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
XPLA3 CPLD
Implementation
The CoolRunner transceiver is built using the CoolRunner

XPLA3 Development Kit from Insight
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.
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.
Figure 12: PS/2 Transmission Waveform
CLK
1
START
BIT
BIT 0 BIT 1 BIT 7 PARITY
STOP
BIT
CLK
2
CLK
3
CLK
9
CLK
10
CLK
11
X358_12_062001
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
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
50 www.xilinx.com XAPP358 (v1.0) June 25, 2001
1-800-255-7778
Wireless Transceiver for the CoolRunner CPLD
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.
Design Verification
The design was verified in simulation and hardware implementation described previously in this
document.
VHDL
Disclaimer and
Download
Instructions
VHDL source code and test benches are available for this design. THE DESIGN IS 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-INFRINGMENT,
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 GreenCoder
TM
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-
gements
The CoolRunner wireless transceiver was development with the senior design team (May 01) of
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.
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
Wireless Transceiver for the CoolRunner CPLD
XAPP358 (v1.0) June 25, 2001 www.xilinx.com 51
1-800-255-7778
R
Revision
History
The following table shows the revision history for this document.
Date Version Revision
06/25/01 1.0 Initial Xilinx release.
52 www.xilinx.com XAPP358 (v1.0) June 25, 2001
1-800-255-7778
Wireless Transceiver for the CoolRunner CPLD
R
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 53
1-800-255-7778
© 2003 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.
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.
Application Note: CoolRunner-II CPLDs
XAPP372 (v1.1) December 18, 2003
CoolRunner-II Smart Card Reader
R
Figure 1: Smart Card Reader
54 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
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
Reader Block
Diagram
The block diagram of the CoolRunner-II smart card reader is shown in Figure 2. The dashed
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
devices in this diagram are briefly described in the following section.
CoolRunner-II
CPLD Modules
Main Control Logic
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.
Figure 2: Smart Card Reader Block Diagram
Smart Card Control
Main Control Logic
CoolRunner-II CPLD
Level Shifter
SRAM Interface
LCD Control
SRAM
LCD Display
Smart Card Acceptor
X372_02_090803
CoolRunner-II Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 55
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
Devices
Level Shifter
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
Standard ISO
7816
Smart Card is defined by the international standard ISO 7816. The first two parts cover smart
card’s physical dimensions and locations of the chip contacts. A smart card image and its
contacts are shown in Figure 3.
Figure 3: Smart Card Image and Contacts
X372_03_090803
V
CC
RST
CLK
RFU
GND
VPP
I/O
RFU
85.6mm
1
0
.
2
5
m
m
19.23mm
5
3
.
9
8
m
m
56 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
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
Procedure
This section details the ISO 7816-3 inter-operation between the smart card and the host
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.
CoolRunner-II Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 57
1-800-255-7778
R
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.
Figure 4: Asynchronous Character Frame
X372_04_090803
8 Data Bits
Z
I/O
Start Bit Parity Bit Next Start
Bit
A
ba bb bc bd be bf bg bh bi Guardtime
58 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
R
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.
Figure 5: Answer to Reset Configuration
X372_05_090803
TS
The Initial Character
TO
The Format Character ... codes Y
1
and IC
TA
1 The Interface Characters Global, codes F1 and D1 _ _ _ _
TB
1 Global, codes F1 and D1 _ _ _ _
TC
1 Global, codes N _ _ _ _
TD
1 codes Y and T _ _ _ _
TA
2 Specific, codes modes features _ _ _ _
TB
2 Global, codes F12 _ _ _ _
TC
2 Specific _ _ _ _
TD
2 codes Y
1
and T _ _ _ _
TA
3 _ _ _ _ TA, TB, TC, are specific TD, code Y
1-1
and T
T1
The Historical Characters
(maximum of 15 characters)
TK
TCK
The Check Character
CoolRunner-II Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 59
1-800-255-7778
R
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.
Figure 6: Initial Character TS
X372_06_090803
Inverse Convention
Z
Start
A
ba bb bc bd be bf bg bh bi
Direct Convention
Z
Start
A
ba bb bc bd be bf bg bh bi
60 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
R
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.
Figure 7: Format and Interface Characters
X372_07_090803
Bit Map No. of Historical Bytes
8 T0
(format character)
5 4 1
F1 D1
8 5 4 TA
1
1
I1 PI1
0 TB
1
6 7 5 1
N
8 TC
1
1
Bit Map Protocol Type
8 TD
1
5 4 1
CoolRunner-II Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 61
1-800-255-7778
R
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.
Figure 8: The T=0 Protocol
X372_08_090803
A: DATA sent from Interface Device [IFD] to ICC
DATA
Procedure
Byte
ICC
Status Bytes
IFD
CLA INS P1 P2 P3
SW1 SW2
B: DATA sent from ICC to IFD
DATA
Procedure
Byte
ICC
Status Bytes
IFD
CLA INS P1 P2 P3
SW1 SW2
62 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
R
CoolRunner-II
Implementation
The CoolRunner-II smart card reader design uses the Advanced Card System ACOS1
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,
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 Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 63
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.
Figure 9: Smart Card Control Block Diagram
Figure 10: Smart Card Control State Machine
State Machine Control
Shift Register Byte Encoder
Bit Counter
lo_rw
Card_io
Card_clk
Card_rst
Data_ready
Bitcounter()
Byte Counter
Bytecounter()
Baud Rate
Counter
Data_out
X372_09_090803
8
Idle
Enable = 1
X372_10_090803
Init
I/O = 0
Done = 1
Command_end = 1
Command_ready = 1
Wait
Read char
Process
End
Send command
64 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
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 186
th
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.
CoolRunner-II Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 65
1-800-255-7778
R
Figure 11: Main Control Logic Block Diagram
Main Control
State Machine
SRAM
Smart Card
Control
Decoder
Logic
LCD
Control
SRAM Interface
Delay Counter
Counter_enable
Done
Sram_rw
Data
Data
Lcd_w
To LCD
Lcd_ready
Counter()
Main Control Logic
X372_11_090803
66 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
R
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.
Figure 12: Main Control Logic Flow Chart
Idle
Smartcard_done = 1
X372_12_090803
Standby
Lcd_ready = 1
Write_female
Write_married
Char = 2
Char = 2
Char = 1
Char = 1
Write_male
Write_single
Write_name
Delay_loop
Delay_loop
Delay_loop
Write_age
End
CoolRunner-II Smart Card Reader
XAPP372 (v1.1) December 18, 2003 www.xilinx.com 67
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
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 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 (2
m
) 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)
68 www.xilinx.com XAPP372 (v1.1) December 18, 2003
1-800-255-7778
CoolRunner-II Smart Card Reader
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)
http://direct.xilinx.com/bvdocs/publications/ds092.pdf (XC2C64 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds093.pdf (XC2C128 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds094.pdf (XC2C256 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds095.pdf (XC2C384 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds096.pdf (XC2C512 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)
Revision
History
The following table shows the revision history for this document.
Date Version Revision
11/19/03 1.0 Initial Xilinx release.
12/18/03 1.1 Minor errata.
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 69
1-800-255-7778
© 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.

Summary This document details the VHDL implementation of an I
2
C 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 I
2
C 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 I
2
C Bus Controller Implementation.
Introduction The I
2
C 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 I
2
C Controller design contains an asynchronous microcontroller (μC)
interface and provides I
2
C Master/Slave capability. It is intended to be used with a
microcontroller (μC) or microprocessor (μP) as shown in Figure 1.
I
2
C Background This section will describe the main protocol of the I
2
C bus. For more details and timing
diagrams, please refer to the I
2
C specification.
The I
2
C 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
Application Note: CoolRunner-II CPLD
XAPP385 (v1.1) December 30, 2003
CoolRunner-II CPLD I
2
C Bus Controller
Implementation
R
Figure 1: CoolRunner-II I
2
C Bus Controller
Address
Data
Control
Microcontroller
Microcontroller
Interface
I2C Master/
Slave
Interface
CoolRunner-II I2C Bus Controller SCL
SDA
X385_01_111902
70 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
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 I
2
C 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 I
2
C specification are supported
by the CoolRunner-II I
2
C Controller.
Data transfers on the I
2
C 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.
Each data packet on the I
2
C 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 I
2
C protocol defines a data transfer format
for both 7-bit and 10-bit addressing. The implementation of the I
2
C 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.
Figure 2: Data Transfer on the I
2
C Bus
SDA
MSB
Start
Condition
S
1 2 3 7 8 9
SCL
x385_10_111902
Stop
Condition
P
ACK
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 71
1-800-255-7778
R
CoolRunner-II
I
2
C Controller
The CoolRunner-II CPLD implementation of the I
2
C Controller supports the following features:
• 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
Descriptions
The I/O signals of the CoolRunner-II I
2
C controller are described in Table 1. Pin numbers have
not been assigned to this design, this can be done to meet the system requirements of the
designer.
Table 1: CoolRunner-II I
2
C Controller Signal Description
Name Direction Description
SDA Bidirectional I
2
C Serial Data.
SCL Bidirectional I
2
C 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 I
2
C 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 I
2
C Controller
has placed valid data on the data bus for a read cycle
or that the I
2
C Controller has received the data on
the bus for a write cycle.
72 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
R
Block Diagram The block diagram of the CoolRunner-II I
2
C Controller, shown in Figure 3 was broken into two
major blocks, the μC interface and the I
2
C interface.
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.
Table 1: CoolRunner-II I
2
C Controller Signal Description
Figure 3: CoolRunner-II I
2
C Controller
A
D
D
R
_
B
U
S
[
2
3
:
0
]
I
R
Q
S
C
L
S
D
A
M
C
F
D
A
T
A
_
B
U
S
[
7
:
0
]
D
T
A
C
K
D
S
A
S
R
_
W
RESET
SYS_CLK
ADDR_DECODE/Bus Interface
Control Register
MBCR
X385_02_111902
Status Register
MBSR
Data Register
MBDR
μC Interface
I2C Interface
Address Register
MADR
Address
Compare
I
2
C Header
Register
I
2
C Data
Register
Arbitration and
START/STOP
Detection
Main State Machine
START/
STOP
SCL
Generation
I
2
C Status
Register
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 73
1-800-255-7778
R
Microcontroller
Logic
The μC interface for the I
2
C controller design supports an asynchronous byte-wide bus
protocol. This protocol is the method in which the μC reads and writes the registers in the
design and is shown in Figure 4.
Address Decode/Bus Interface Logic
The μC bus protocol is implemented in the CoolRunner-II I
2
C Controller in the state machine
shown in Figure 5.
Figure 4: μC Read/Write Protocol
Figure 5: μC Bus Interface State Machine
Microcontroller
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)
Address the Device
X385_11_111902
1. Latch data (if Read)
2. Negate DS
3. Negate AS
4. Remove data from bus (if Write)
Terminate Transfer
Start Next Cycle
I
2
C Controller
1. Decode Address
2. Latch data on D7:D0 (if Write)
or place data on D7:D0 (if Read)
3. Assert Data Transfer Acknowledge (DTACK)
Input the Data
1. Remove data from D7:D0 (if Read)
2. Negate DTACK
Terminates the Cycle
IDLE
AS Asserted
RESET Negated
DS Asserted
ADDRESS_MATCH Asserted
ADDR
DATA_TRS
ASSERT_DTACK
X385_03_111902
DS
Negated
RESET
Asserted
AS Asserted
DS Asserted
ADDRESS_MATCH
Negated
AS Negated
DS Negated
74 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
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 I
2
C Controller
can place data on the data bus.
Upon the assertion of AS, the CoolRunner-II I
2
C 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 I
2
C Controller is being addressed
and DS is asserted, the CoolRunner-II I
2
C 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 I
2
C 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 I
2
C Controller to negate DTACK and transition to the IDLE
state.
CoolRunner-II I
2
C 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 I
2
C Controller are described in the Table 2. The
μC interface logic of the CoolRunner-II I
2
C Controller handles the reading and writing of these
registers by the μC and supplies and/or retrieves these bits to/from the I
2
C interface logic.
Address Register (MADR)
This field contains the specific Slave address to be used by the I
2
C Controller. This register is
read/write. (Table 3).
Table 2: I
2
C Controller Registers
Address Register Description
MBASE + $8Dh MADR I
2
C Address Register
MBASE + $91h MBCR I
2
C Control Register
MBASE + $93h MBSR I
2
C Status Register
MBASE + $95h MBDR I
2
C Data I/O Register
Table 3: Address Register Bits
Bit
Location Name μC Access Description
7-1 Slave Address Read/Write Address used by the I
2
C controller when
in Slave mode.
0 - - Unused
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 75
1-800-255-7778
R
Control Register (MBCR)
This register contains the bits to configure the I
2
C controller. (Table 4).
Table 4: Control Register Bits
Bit
Location Name μC Access Description
7 MEN Read/Write I
2
C Controller Enable. This bit must be set before
any other MBCR bits have any effect
"1" enables the I
2
C controller
"0" resets and disables the I
2
C 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 I
2
C controller generates
a START condition in Master mode. When this bit is
cleared, a STOP condition is generated and the I
2
C
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 I
2
C Master transmit
"0" selects an I
2
C 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 I
2
C
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
76 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
R
Status Register (MBSR)
This register contains the status of the I
2
C 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
Location Name μC Access Description
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 I
2
C 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
I
2
C bus matches the Slave address in the MADR
register, the I
2
C 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 I
2
C
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
Software
Clearable
Arbitration Lost Bit. This bit is set by hardware
when arbitration for the I
2
C bus is lost. This bit must
be cleared by the μC software writing a "0" to this bit.
3 Reserved
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 77
1-800-255-7778
R
Data Register (MBDR)
This register contains data to/from the I
2
C bus. Physically, this register is implemented by two
byte-wide registers at the same address, one for the I
2
C transmit data and one for the I
2
C
received data. This eliminates any possible contention between the μC and the CoolRunner-II
I
2
C 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 I
2
C bus, in receive mode, this register contains the data received from
the I
2
C bus. Note that in receive mode, it is assumed that the μC will be able to read this register
during the next I
2
C transfer. The received I
2
C data is placed in this register after each complete
transfer, the I
2
C 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)
I
2
C Interface
Logic
The I
2
C bus interface logic consists of several different processes as seen in Figure 3. Control
bits from the μC interface registers determine the behavior of these processes.
Arbitration
Arbitration of the I
2
C 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
2 SRW Read Slave Read/Write Bit. When the I
2
C 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
Software
Clearable
Interrupt Bit. This bit is set when an interrupt is
pending, which causes a processor interrupt request
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
Table 6: I
2
C Data Register Bit
Bit
Location Name μC Access Description
7-0 D7:D0 Read/Write I
2
C Data
Table 5: Status Register Bits (Continued)
Bit
Location Name μC Access Description
78 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
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 I
2
C 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 I
2
C Controller switches to Slave mode and resets the
MSTA bit.
The CoolRunner-II I
2
C 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 I
2
C 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 I
2
C 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 I
2
C 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 I
2
C requirements on hold time for the SDA lines after
generating a START condition and after outputting data.
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 79
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.
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 I
2
C 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 I
2
C 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 I
2
C 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
Figure 6: SCL, SDA, START, and STOP Generation State Machine
IDLE
GEN_START = 1
CLK_CNT = START_HOLD
CLK_CNT = LOW_CNT
SCL_INT = 1
START
SCL_LOW_EDGE
SCL_LOW
SCL_HI_EDGE
SCL_HI
X385_04_111902
CLK_CNT < START_HOLD
RST
GEN_START = 0
CLK_CNT < LOW_CNT
STOP_WAIT
CLK_CNT < TBUF
CLK_CNT < HIGH_CNT
SCL_INT = 0
GEN_STOP = 1
CLK_CNT = HIGH_CNT/2
CLK_CNT = TBUF
REP_START = 1
CLK_CNT = HIGH_CNT/2
CLK_CNT = HIGH_CNT
ARB_LOST = 1
BIT_CNT > 7
80 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
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 I
2
C 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
2
C Interface Main State Machine
The main state machine for the I
2
C 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
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 81
1-800-255-7778
R
Master to Slave mode if arbitration is lost or if the CoolRunner-II I
2
C Controller is addressed as
a Slave.
This state machine utilizes and controls a counter that counts the I
2
C 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 I
2
C header that has been received and another that stores the I
2
C
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 I
2
C controller or another Master—either source will transition the state machine
to the HEADER state.
The HEADER state is the state where the I
2
C header is transmitted on the I
2
C bus from the
MBDR register if in Master mode. In this state, the incoming I
2
C data is captured in the I
2
C
Header shift register. In Master mode, the I
2
C Header shift register will contain the data that
was just transmitted by this design. When all eight bits of the I
2
C header have been shifted in,
the state machine transitions to the ACK_HEADER state.
Figure 7: I
2
C Interface Main State Machine
IDLE
DETECT_START = 1
Master
SDA = 1
BIT_CNT = 8
HEADER
ACK_HEADER
BIT_CNT = 8
RCV_DATA
ACK_DATA
BIT_CNT = 8
XMIT_DATA
WAIT_ACK
STOP
X385_05_111902
BIT_CNT < 8
RESET
Asserted
SDA = 0
Master Rcv
SDA = 0
Slave Rcv
ADDR_MATCH = 1
Master Xmit
SDA = 0
Slave Xmit
ADDR_MATCH = 1
DETECT_STOP = 1 DETECT_STOP = 1
SDA = 1
DETECT_START = 1 DETECT_START = 1
82 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
R
In the ACK_HEADER state, the CoolRunner-II I
2
C design samples the SDA line if in Master
mode to determine whether the addressed I
2
C 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 I
2
C 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 I
2
C Header shift register is constantly compared with the I
2
C address set in the MADR
register. If these values match in the ACK_HEADER state, the CoolRunner-II I
2
C 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 I
2
C bus Master. Again, the LSB of the I
2
C header is
used to determine the direction of the data transfer and the appropriate state is chosen.
The RCV_DATA state shifts the incoming I
2
C data into the I
2
C 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 I
2
C 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 I
2
C 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 I
2
C design is in Master mode. The next state is always the IDLE state and the
I
2
C activity is completed.
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 83
1-800-255-7778
R
Operational
Flow Diagrams
The flow of the interface between the μC and the CoolRunner-II I
2
C Controller is detailed in the
following flow charts. These flow charts are meant to be a guide for utilizing the CoolRunner-II
I
2
C Controller in a μC system.
Initialization
Before the CoolRunner-II I
2
C Controller can be utilized, certain bits and registers must be
initialized as shown in Figure 8.
Master Transmit/Receive
The flow charts for transmitting data and receiving data while I
2
C 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.
Figure 8: CoolRunner-II I
2
C Controller Initialization Flow Chart
BEGIN
END
Enable I
2
C Interface
Logic by Setting MEN
X385_06_111902
Define I
2
C Slave
Address to Respond
to in MADR
Modify MBCR to
Enable Interrupts
84 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
R

Figure 9: Master Transmit Flow Chart
BEGIN
END
No
Yes
Bus Busy?
(MBB = 1)
Write I2C Header
in MBDR
X385_07_111902
Set MSTA in MBCR
to Generate START
Yes
No
Transfer
Complete?
(MCF = 1)
Write Data
to MBDR
Yes
No
Transfer
Complete?
(MCF = 1)
Yes
No
Last Word?
Negate MSTA in MBCR
to Generate STOP
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 85
1-800-255-7778
R
Figure 10: Master Receive Flow Chart
BEGIN
END
No
Yes
Bus Busy?
(MBB = 1)
Write I2C Header
in MBDR
X385_08_111902
Set MSTA in MBCR
to Generate START
Yes
No
Transfer
Complete?
(MCF = 1)
Read Data
from MBDR
Yes
No
Transfer
Complete?
(MCF = 1)
Yes
No
Last Word - 1?
Set TXAK in MBCR
to Turn Off ACK
Yes
No
Transfer
Complete?
(MCF = 1)
Yes
Read Data from
MBDR
Negate MSTA in MBCR
to Generate STOP
86 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
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 I
2
C 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.
CoolRunner-II
CPLD
Implementation
The design of the CoolRunner-II I
2
C Controller was implemented in VHDL and targeted to a
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
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 I
2
C SCL line is used as a clock input into the CoolRunner-II I
2
C Controller. If there are many
loads on the I
2
C 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 I
2
C system. If the rise time of the I
2
C 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 I
2
C 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,
Figure 11: Slave/Transmitter Flow Chart
BEGIN
END
Yes
No
Addressed
as Slave?
Check SRW Bit in
MSBR for Xmit/Rcv
X385_09_111902
Read/Write Data
in MBDR
Yes
Yes
No
Transfer
Complete?
(MCF = 1)
No
Bus Busy?
MAAS = 1?
CoolRunner-II CPLD I
2
C Bus Controller Implementation
XAPP385 (v1.1) December 30, 2003 www.xilinx.com 87
1-800-255-7778
R
there is plenty of room remaining in the device for the implementation of other logic in the
system.
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 I
2
C Controller design was simulated with an
independently generated VHDL model of an I
2
C 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
Download
VHDL source code and test benches are available for this design. THE DESIGN IS 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.
VHDL - ftp://ftp.xilinx.com/pub/applications/refdes/xapp333.zip
Verilog - ftp://ftp.xilinx.com/pub/applications/refdes/xapp333_ver.zip
Disclaimer I
2
C 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 I
2
C 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.
Table 7: CoolRunner-II CPLD 256-Macrocell Utilization
Resource Available Used Utilization
Macrocells 256 127 50%
P-terms 896 352 39%
Registers Used 256 110 43%
I/O Pins 118 42 36%
Function Block
Inputs Used
640 305 48%
88 www.xilinx.com XAPP385 (v1.1) December 30, 2003
1-800-255-7778
CoolRunner-II CPLD I
2
C Bus Controller Implementation
R
Revision
History
The following table shows the revision history for this document.
Date Version Revision
12/24/02 1.0 Initial Xilinx release.
12/30/03 1.1 Change to control register address.
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 89
1-800-255-7778
© 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.

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.
Application Note: CoolRunner-II CPLD
XAPP386 (v1.0) December 12, 2002
CoolRunner-II Serial Peripheral Interface
Master
R
Figure 1: CoolRunner-II SPI Master
Address
Data
Control
Microcontroller
Microcontroller
Interface
SPI Master
Interface
CoolRunner-II SPI Master
SCK
SS_N[7:0]
SS_IN_N
MOSI
MISO
X386_01_121202
90 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 91
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.
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.
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
Figure 2: Data Transfer on the SPI Bus with CPHA=0
SCK Cycle 1
MSB
SCK (CPOL=1)
SCK (CPOL=0)
MOSI
MISO
SS
6 5 1 LSB
MSB
** Not defined, but normally MSB of character just received.
6 5 1 LSB **
SCK Cycle 2 SCK Cycle 3 SCK Cycle 4-6 SCK Cycle 7 SCK Cycle 8
X386_02_121202
Figure 3: Data Transfer on SPI Bus with CPHA=1
Cycle 1
MSB
SCK (CPOL=1)
SCK (CPOL=0)
MOSI
MISO
SS
6 5 1 LSB
MSB
** Not defined, but normally LSB of previously transmitted character.
6 5 1 LSB **
Cycle 2 Cycle 3 Cycle 4-6 Cycle 7 Cycle 8
X386_03_121202
92 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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
SPI Master
Implementation
The CoolRunner-II CPLD implementation of an SPI Master supports the following features:
• Microcontroller interface
• 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
Descriptions
The 36 I/O signals of the CoolRunner-II CPLD SPI Master are described in Table 1. Pin
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
Name Direction 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.
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 93
1-800-255-7778
R
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.
Table 1: CoolRunner-II SPI Master Signal Description
94 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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.
Figure 4: SPI Master Bl ock Diagram
A
D
D
R
[
1
5
:
8
]
I
N
T
_
N
S
C
K
S
S
_
I
N
_
N
S
S
_
N
[
7
:
0
]
X
M
I
T
_
E
M
P
T
Y
A
D
D
R
_
D
A
T
A
[
7
:
0
]
R
C
V
_
F
U
L
L
A
L
E
_
N
P
S
E
N
_
N
R
D
_
N
W
R
_
N
RESET
SYS_CLK
Address Decode/Bus Interface
X386_04_121202
Transmit Register
SPITR
Receive Register
SPIRR
Slave Select
Register - SPISSR
Control Register
SPICR
Status Register
SPISR
Microcontroller
Interface
SPI Interface
SPI Shift Registers
SPI Control
State Machine
Input
Registers
SCK Clock
Logic
M
O
S
I
M
I
S
O
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 95
1-800-255-7778
R
μC Interface
Logic
The μC interface for the SPI Master design supports a byte-wide, multiplexed address/data bus
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.
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.
Figure 5: μC Read/Write Protocol
Microcontroller
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)
4. Negate Program Store Enable (PSEN_N)
Address the Device
X386_05_121202
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]
then negate Read Strobe (RD_N)
Terminate Transfer
1. Remove data from ADDR_DATA{7:0]
2. If write cycle, place data on ADDR_DATA[7:0]
and assert Write Strobe (WR_N)
3. If read cycle, assert Read Strobe (RD_N)
Transfer Data
1. Remove Address Latch Enable (ALE_N)
Terminate the Cycle
Start Next Cycle
SPI Master
1. Latch the address
2. Decode the address and determine if the
CPLD is being addressed
Decode the Address
1. If write cycle, latch data on ADDR_DATA[7:0]
into addressed register
2. If read cycle, output data from addressed
register on ADDR_DATA[7:0]
Transfer Data
1. If read cycle, remove data from
ADDR_DATA[7:0]
Terminate Transfer
96 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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.
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.
Figure 6: μC Bus Interface State Machi ne
IDLE
ale_n=0
psen_n=1
rd_n=0 or wr_n=0
addr_match=1
rd_n=1 or wr_n=1
ADDR_DECODE
DATA_TRS
END_CYCLE
X386_06_121202
rd_n=0 or wr_n=0
addr_match=0
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 97
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.
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 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
Table 3: Status Register Bits
Bit
Location Name μC Access Description
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
Software
Clearable
SPI Error Bit. When the SS_IN_N input pin is asserted, this bit is set
indicating an SPI error condition. The SPI interface resets and 3-states all
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
Software
Clearable
Interrupt Bit. This bit is asserted (active low) when an interrupt is pending
which causes a processor interrupt request if INTEN is set. An interrupt is
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.
98 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
R
SPI Control Register (SPICR)
This register contains the bits to configure the SPI Master. (Table 4)
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.
Table 3: Status Register Bits (Continued)
Bit
Location Name μC Access Description
Table 4: Control Register Bits
Bit
Location Name μC Access Description
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
• "01" - SCK is 1/8 of the system clock
• "10" - SCK is 1/16 of the system clock
• "11" - SCK is 1/32 of the system clock
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 99
1-800-255-7778
R
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)
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
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.
Table 4: Control Register Bits (Continued)
Bit
Location Name μC Access Description
Table 5: SPI Slave Select Register
Bit
Location Name μC Access Description
7 - 0 SS_N7 - SS_N0 Read/Write SPI Slave Selects
100 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
R
and START must be asserted before the SPI state machine will begin transmission of data on
the SPI bus.
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)
SPI Interface
Logic
The SPI bus interface logic consists of several different processes as seen in Figure 4. Control
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
Table 6: SPI Transmit Data Register
Bit
Location Name μC Access Description
7 - 0 D7 - D0 Read/Write SPI Transmit Data
Table 7: SPI Receive Data Register
Bit
Location Name μC Access Description
7 - 0 D7 - D0 Read/Write SPI Receive Data
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 101
1-800-255-7778
R
select is then negated after the required hold time. The SPI control state machine is shown in
Figure 7.
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
Figure 7: SPI Control State Machine
IDLE
start=1
xmit_empty=0
sck_int_re=1
sck_int_fe=1
sck_int_re=1
ASSERT_SSN1
ASSERT_SSN2
UNMASK_SCK
XFER_BIT
bit_cnt=8
ASSERT_DONE
sck_int_fe=1
CHK_START
sck_int_fe=1
HOLD_SSN1
sck_int_fe=1
HOLD_SSN2
sck_int_fe=1
NEGATE_SSN
start=0 or
cpha=0 and ((cpol=0 and sck_fe=1) or
(cpol=1 and sck_re=1))
MASK_SCK
X386_07_121202
sck_int_fe=1
cpha=1
start=1
xmit_empty=0
bit_cnt < > 8
102 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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.
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 103
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.
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.
Figure 8: SCK Cl ock Generation Logic
clk_cnt(1)
sys_clk
clkdiv(0)
clk1_mask
clkdiv(1)
sys_clk
cpha
cpol
sys_clk
X386_08_121202
clk_cnt(2)
clk_cnt(3)
clk_cnt(4)
Clock
Counter
Mux/Reg
Mux/Reg
clk0_mask
sck_0
sck_1
sck_int
sck_out
104 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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..
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
Figure 9: SPI Transmit Shift Regi ster
load
data from
SPI Transmit
Register
8
sys_clk
shift
sck_int
X386_09_121202
8-bit SPI Xmit Shift Register
MOSI
Register
MOSI
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 105
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.
Operational
Flow Diagrams
The flow of the interface between the μC and the CoolRunner-II SPI Master is detailed in the
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
Figure 10: SPI Receive Shift Regi ster and MISO Input Data Registers
data to
SPI Receive
Register
8
shift
rcv_cpol
SCK
MISO
rcv_load
sck_int
X386_10_121202
8-bit SPI Receive Shift Register
MUX
MISO
Register
MISO
Register
Receive
Bit Counter
106 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
R
SPI error has occurred; the designer should determine the correct operations to execute when
an SPI error occurs based on the system requirements.
Figure 11: CoolRunner-II SPI Master Transaction Flow Chart
BEGIN
END
No
Yes
Yes
Yes
Yes
Yes
Bus Busy= 1?
Configure SPI Master
by writing to SPICR:
SPIEN, INTEN,
CLKDIV, CPHA
CPOL, RCV_CPOL
No
No
No
No
XMIT_EMPTY
=1?
Last Word?
Last Word?
RCV_FULL
=1?
X386_11_121202
Negate START bit
in SPICR
Read SPI Receive
Data in SPIRR
Write SPI Transmit
Data in SPITR
Read SPI Bus
Status from SPISR
Configure Slave Select
in Slave Select Register
(SPISSR)
Yes
No Interrupt
(INT_N=0)?
Yes
Yes
No
SPIERR = 1?
No
SPIERR = 1?
Write SPI Transmit
Data in SPITR
Set START bit in SPITR
Read SPI Bus Status
from SPISR
Reset SPIERR in SPISR
Read SPI Bus Status
from SPISR
Reset SPIEN in SPICR
to reset SPI Master
CoolRunner-II Serial Peripheral Interface Master
XAPP386 (v1.0) December 12, 2002 www.xilinx.com 107
1-800-255-7778
R
VHDL
Testbench and
Functional
Simulation
A VHDL testbench has been developed that verifies the CoolRunner-II SPI Master
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.
Constants are provided at the top of the testbench file to set up the base address of the SPI
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
CPLD
Implementation
The CoolRunner-II SPI Master design has been targeted to a CoolRunner-II 256 macrocell
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.
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
Simulation
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 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
Download and
Disclaimer
All VHDL source code, VHDL testbenches, and software files associated with this design are
available. THE DESIGN IS 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 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
108 www.xilinx.com XAPP386 (v1.0) December 12, 2002
1-800-255-7778
CoolRunner-II Serial Peripheral Interface Master
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.
Revision
History
The following table shows the revision history for this document.
Date Version Revision
12/12/02 1.0 Initial Xilinx release.
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 109
© 2005 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.
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.
Application Note: CoolRunner-II CPLDs
XAPP390 (v1.1) September 27, 2005
Design of a Digital Camera with
CoolRunner-II CPLDs
R
110 www.xilinx.com XAPP390 (v1.1) September 27, 2005
Introduction
R
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.
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
Figure 1: MI-SOC-0343 Block Diagram
Active Pixel Array
(640 x 480)
Image Core
Register Set
Analog
Processing
10-bit
ADC
Serial Interface
(SCLK, SDATA)
Imager Core
Image Flow Processor
Color Correction
Gamma Control
Sharpening Control
Saturation Control
Auto White Balance
Auto Exposure
Defect Correction
Lens Detection
Data Output
and Timing
IFP
Register Set
X390_01_090303
Introduction
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 111
R
approximately 25% of the die area. The "active pixel" architecture developed by Micron
eliminates background noise and prevents image effects such as "line streaking".
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.
Figure 2: Active Pixel Architecture
Figure 3: Bayer CFA
Photodiode Active-Pixel Architecture
Photogate Active-Pixel Architecture
Images courtesy of Micron
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
112 www.xilinx.com XAPP390 (v1.1) September 27, 2005
Introduction
R
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.
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
Figure 4: Video Capture Timing
DOUT (7:0) (RGB)
Cb
0
Y
0
Cr
0
Y
1
R[4:0] G[5:0] B[4:0]
Start
of first
line
Start
of
frame
End
of first
line
End
of last
line
End
of
frame
Y
last
PIX_CLK
FRAME_VALID
LINE_VALID
DOUT (7:0) (YCrCb)
X390_04_090203
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 113
R
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.
CoolRunner-II
Design
The complete CoolRunner-II digital camera reference design is shown in Figure 6. The
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.
Figure 5: Optrex Block Diagram
Timing
Logic
CCT
CCT
Vertical IC Driver
H
o
r
i
z
o
n
t
a
l

I
C

D
r
i
v
e
r
LCD Panel
(640 x 480)
X390_05_090303
Figure 6: Digital Camera Block Diagram
CMOS
Image
Sensor
SHIP
Interface
Control Logic
Image
Grabber
Control Logic
Main
Control
Logic
SRAM
Interface
Logic
SRAM
LCD
Interface
Control
Logic
PWM
Logic
LCD
Panel
Inverter
CoolRunner-II CPLD
X390_06_090303
114 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Design
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.
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.
Figure 7: Main Control Logic State Machine
X390_07_090303
IDLE
WAIT_SHIP_INIT
GET_DATA
WAIT_IMAGE_DATA
ship_init_done = '0'
LCD_DATA
DONE
lcd_done = '0'
ship_init_done = '1'
get_data_done= '0'
get_data_done= '1'
lcd_done = '1'
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 115
R
6. Master sends upper 8-bits of data.
7. An acknowledge bit is sent by the slave device.
8. Master sends lower 8-bits of data.
9. An acknowledge bit is sent by the slave device.
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).
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.
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
Figure 8: SHIP Write Sequence
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.
SCLK
SDATA
Send slave address
Value = B8 (hex)
Send register
address
Value = 01 (hex)
ACK ACK
Start
Condition
Send upper
data byte
Value = 00 (hex)
Send lower
data byte
Value = 04 (hex)
ACK ACK
Stop
Condition
X390_08_090303
116 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Design
R
SHIP_INTERFACE block shown in Figure 9 controls the generation of SCLK and SDATA on the
SHIP serial communication.
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
Figure 9: SHIP Interface Block Diagram
MI-SOC-0343
Imager Core
Register Set
IFP Register Set
SCLK
SDATA
s
y
s
_
r
e
s
e
t
s
h
i
p
_
i
n
i
t
_
d
o
n
e
m
i
_
p
i
x
c
l
k
SHIP_TOP
State Machine
SHIP
State Machine
SHIP_INTERFACE
ship_addr (7:0)
ship_data (15:0)
ship_start
ship_done
SHIFT8
UPCNT8
UPCNT4
X390_09_090303
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 117
R
ship_start control signal. When the SHIP_INTERFACE logic has completed the single register
write, the ship_done flag is asserted.
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
Figure 10: SHIP Top Level State Machine
X390_10_090403
IDLE
WR_IFPn
WAIT_WR_IFPn
sys_reset = RESET_ACTIVE
ship_done = '1'
DONE
sys_reset \= RESET_ACTIVE
ship_done = '0'
ship_done = '1'
ship_done = '0'
Loop for number
of IFP registers
to write
WR_IFP01
WAIT_WR_IFP01
ship_done = '1'
ship_done = '0'
ship_done = '1'
ship_done = '0'
WR_ICn
WAIT_WR_ICn
ship_done = '0'
ship_done = '1'
ship_done = '0'
Loop for number
of IC registers
to write
ship_done = '1'
118 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Design
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.
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
Figure 11: SHIP Interface State Machine
X390_11_090403
IDLE
SHIFT_MI_ADDR
WAIT_ACK_MI_ADDR
detect_start = '0'
bit_qout < BIT_COUNT
DONE
detect_start = '1'
bit_qout = BIT_COUNT
SHIFT_REG_ADDR
WAIT_ACK_REG_ADDR
bit_qout < BIT_COUNT
bit_qout = BIT_COUNT
SHIFT_UDATA
WAIT_ACK_UDATA
bit_qout < BIT_COUNT
bit_qout = BIT_COUNT
SHIFT_LDATA
WAIT_ACK_LDATA
bit_qout < BIT_COUNT
bit_qout = BIT_COUNT
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 119
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.
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.
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
Figure 12: SCLK_GEN State Machine
Figure 13: MI-SOC-0343 Interface
X390_12_090403
IDLE
START
SCLK_LOW_EDGE
gen_start = '0'
clk_qout < START_HOLD
gen_start = '1'
SCLK_LOW
SCLK_HIGH_EDGE
clk_qout < LOW_SCLK
SCLK_HIGH
clk_qout < HI_SCLK
clk_qout = START_HOLD
clk_qout = LOW_SCLK
clk_qout = HI_SCLK
DONE
clk_qout < TBUF
clk_qout = TBUF
MI-SOC-0343
sys_reset
pixel_data (15:0)
Image Grabber
State Machine
X390_13_090403
mi_pixclk
mi_frame_valid
mi_line_valid
mi_data (7:0)
get_frame_data
get_frame_done
sram_addr_clr
sram_addr_cnt_en
Image Grabber
Control Logic
to/from Main
Control Logic
120 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Design
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.
Table 2 below describes the functionality of each state in the Image Grabber state machine.
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
Figure 14: 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.
X390_14_090403
IDLE
WAIT_FV
CAP_FV
CAP_LDATA
get_frame_data = '0'
mi_line_valid = '1'
get_frame_data = '1'
fv_edge_detect = '0'
fv_edge_detect = '1'
mi_line_valid = '0'
mi_line_valid = '1'
CAP_UDATA
mi_line_valid = '0' &
mi_frame_valid = '1'
DONE
mi_frame_valid = '0'
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 121
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.
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.
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 3: Optrex LCD Control Signals
Optrex Signal
Name
CPLD VHDL
Name
Purpose
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.
Table 4: LCD Mode Select
Polarization VGA-480 VGA-400 VGA-350 Freedom Mode
HSYNC Low Low High High
VSYNC Low High Low High
Table 5: Horizontal Timing
Indicator Description Parameter Clock Cycles Actual Value
A Horizontal Width t
HPW
96 14 μs
B Horizontal Back Porch t
HBP
48 7 μs
C Horizontal Display t
HD
640 96 μs
122 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Design
R
For clarification, each timing parameter in Table 5 is assigned a letter shown in Figure 15.
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.
The letters in Table 6 correspond to each timing parameter shown in Figure 16.
Another critical timing parameter on the LCD is the phase difference between active edges of
VSYNC and HSYNC. This timing parameter is indicated as t
VH
and shown in Figure 17. The
D Horizontal Front Porch t
HFP
16 2.4 μs
E Horizontal Total t
HP
800 120 μs
Figure 15: Horizontal Timing Diagram
Table 6: Vertical Timing
Indicator Description Parameter Lines Actual Value
A Vertical Width t
VPW
2 240 μs
B Vertical Back Porch t
VBP
33 3.96 ms
C Vertical Display t
VD
480 57.6 ms
D Vertical Front Porch t
VFP
10 1.2 ms
E Vertical Total t
VP
525 63 ms
Figure 16: Vertical Timing Diagram
Table 5: Horizontal Timing
Indicator Description Parameter Clock Cycles Actual Value
HSYNC
(active low)
DENB
t
HPW
t
HBP
t
HD t
HFP
t
HP
A C
B D
E
X390_15_090403
VSYNC
(active low)
DENB
t
VPW
t
VBP
t
VD t
VFP
t
VP
A C
B D
E
X390_16_090403
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 123
R
minimum value of t
VH
is one clock cycle. The maximum value of t
VH
is (t
HP
- 1) clock cycles,
where t
HP
is the number of clock cycles to shift in an entire line of data.
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.
Figure 17: VSYNC & HSYNC Phase Difference Timing
Figure 18: LCD Interface Block Diagram
VSYNC
(active low)
X390_17_090403
HSYNC
(active low)
t
VH
Optrex 51382
s
y
s
_
r
e
s
e
t
l
c
d
_
d
o
n
e
m
i
_
p
i
x
c
l
k
PWM
Control Logic
LCD Interface
State Machine
Period
Counter
LINE_CNT
(UPCNT10)
X390_18_090403
lcd_clk
lcd_vsync
lcd_hsync
lcd_denb
lcd_red (5:0)
led_green (5:0)
lcd_blue (5:0)
CCT
CCT
Width
Counter
K2607 Inverter
l
c
d
_
s
t
a
r
t
CLK_CNT
(UPCNT17)
VBP_CNT
(UPCNT17)
HBP_CNT
(UPCNT6)
pwm_out
124 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Design
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.
A description of each state in the LCD state machine is provided in Table 7.
Figure 19: LCD Interface State Machine
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 t
VPW
(VSYNC pulse width).
Use CLK_CNT and wait for T_VPW. Also reset
ADDR_CNT (SRAM address counter).
X390_19_090403
IDLE
VSYNC_HIGH
lcd_start = '0'
lcd_start = '1'
clk_cnt_qout < T_VPW
clk_cnt_qout = T_VPW
VSYNC_LOW_EDGE
VSYNC_LOW
clk_cnt_qout < T_VH
clk_cnt_qout = T_VH
HSYNC_LOW_EDGE
HSYNC_LOW
vbp_cnt_qout = T_VBP &
hbp_cnt_qout = T_HBP
vbp_cnt_qout < T_VBP or
hbp_cnt_qout < T_HBP
ASSERT_DENB
clk_cnt_qout < NUM_COL
clk_cnt_qout = NUM_COL
LINE_DONE
HFP_WAIT
clk_cnt_qout < T_HFP
clk_cnt_qout = T_HFP
HSYNC_HIGH
line_cnt_qout < NUM_LINES
line_cnt_qout = NUM_LINES
VFP_WAIT
HSYNC_PW
clk_cnt_qout < T_HPW
WAIT_THBP
clk_cnt_qout = T_HPW
hbp_cnt_qout < T_HBP
hbp_cnt_qout = T_HBP
clk_cnt_qout < T_VFP
clk_cnt_qout = T_VFP
DONE
CoolRunner-II Design
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 125
R
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
VSYNC_LOW_EDGE Assert lcd_vsync. Enable VBP_CNT (VSYNC back porch
counter).
VSYNC_LOW Wait for t
VH
(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 t
VBP
and t
HBP

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 (t
HFP
). 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 t
HPW
(HSYNC pulse width). Use CLK_CNT and
wait for T_HPW.
WAIT_THBP Assert lcd_hsync. Wait for t
HBP
(HSYNC back porch). Use
HBP_CNT and wait for T_HBP.
VFP_WAIT Wait t
VFP
(VSYNC front porch). Use CLK_CNT and wait
for T_VFP.
DONE De-assert lcd_vsync. Assert lcd_done flag.
Table 7: LCD State Machine Description
State Name State Purpose
126 www.xilinx.com XAPP390 (v1.1) September 27, 2005
CoolRunner-II Implementation
R
counter controls the active high time of the PWM signal. Figure 20 illustrates the PWM signal
generation.
CoolRunner-II
Implementation
Device Utilization
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.
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
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 DESIGN "AS IS" AS A COURTESY TO YOU.
XAPP390 - http://www.xilinx.com/products/xaw/coolvhdlq.htm
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.
Figure 20: PWM Signal Generation
PERIOD counter
WIDTH
counter
(app. 5 ms)
0V
+ Vin
PWM
signal
X390_20_090403
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 %
References
XAPP390 (v1.1) September 27, 2005 www.xilinx.com 127
R
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.
128 www.xilinx.com XAPP390 (v1.1) September 27, 2005
Additional Information
R
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
Information
CoolRunner-II Datasheets and Application Notes
Device Packages
Revision
History
The following table shows the revision history for this document.
Date Version Revision
04/27/04 1.0 Initial Xilinx release.
09/27/05 1.1 Fixed links in Additional Information
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 129
1-800-255-7778
© 2003 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.
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
Interface
Power Considerations
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
Application Note: CoolRunner-II CPLD
XAPP398 (v1.0) September 23, 2003
CompactFlash Card Interface for
CoolRunner-II CPLDs
R
130 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
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 V
OH
and V
OL

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 V
IH
be at a lower voltage than the CoolRunner-II CPLD is
specified in the data sheet. The signal of interest is RESET whose V
IH
should be analyzed for
the particular application of this CF+ design. If it is determined that the supplied signal is always
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 131
1-800-255-7778
R
high enough to meet the V
IH
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 V
OH
and
V
OL
at the specified I
OH
and I
OL
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.
132 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
R
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.
Figure 1: CompactFlash Card General Block Diagram
X398_01_092203
H
o
s
t

B
u
s

A
d
a
p
t
e
r

(
H
B
A
)
CM Control Bus
CoolRunner-II
CPLD
CF+Interface
Control Bus
A10:A0
D15:D8
Expansion Bus
D7:D0
CM A10:A0
CM D15:D0
I/O Control Bus
I/O A10:A0
I/O D7:D0
80MHz clock
Compact Flash Card
Common
Memory
(Intel StrataFlash)
DSP Control Bus
DSP A10:A0
DSP D7:D0
Additional
Functions
I/O Space
(Analog Devices
DSP)
40MHz
Clock
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 133
1-800-255-7778
R
Signal
Descriptions
Table 1 displays the pin descriptions of the CoolRunner-II CF+ Interface. Note that according to
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.
Figure 2: CPLD Controller General Block Diagram
CPLD
CIS
Attribute Memory
COR
CSR
PRR
0x000
0x200
0x202
0x204
I/O Space
Address Register
0x400
0x401
0x402
Data Register
Control Register
0x001
0x002
0x003
CF+
Address Decode
and
Control Logic
(CF+ Controller)
I/O Space
Address Decode
and
I/O Control Logic
(I/O Space Controller)
Address Bus 10:0
Memory Data Bus 15:0
Control Bus
I/O Space Data Bus 7:0
C
o
m
m
o
n

M
e
m
o
r
y
A
d
d
r
e
s
s

B
u
s
D
a
t
a

B
u
s
C
o
n
t
r
o
l

B
u
s
I/O A10:A0
I/O D7:D0
I/O Control Bus
I
/
O

I
n
t
e
r
f
a
c
e
CM A10:A0
CM D15:D0
CM Control Bus
D7:D0
D15:D8
A10:A0
Control Bus
C
F
+

I
n
t
e
r
f
a
c
e
80MHz Clock
X398_02_042403
134 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
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
Name Direction Description
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.
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 135
1-800-255-7778
R
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.
Table 1: CF+ Interface Pin Descriptions (Continued)
Name Direction Description
136 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
R
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
CompactFlash specification.
Table 1: CF+ Interface Pin Descriptions (Continued)
Name Direction Description
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 137
1-800-255-7778
R
Table 2: Common Memory Interface Pin Descriptions
Name Direction Description
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.
138 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
R
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.
Table 3: I/O Space Interface Pin Descriptions
Name Direction Description
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.
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 139
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.
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.
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
(even byte)
0 1 0 3-State Even Byte
(Low Byte)
8-bit Mode
(odd byte)
0 1 1 3-State Odd Byte
(High Byte)
16-bit Mode
(odd byte only)
1 0 X Odd Byte
(High Byte)
High-Z
16-bit Mode
(even & odd bytes)
0 0 X Odd Byte
(High Byte)
Even Byte
(Low Byte)
140 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
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
Memory
The Attribute Memory is divided into two basic sections: The CIS and the Configuration
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.
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.
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
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 141
1-800-255-7778
R
The COR is comprised of 8 bits as shown in Table 6.
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 6: Configuration Option Register
Operation D7 D6 D5 D4 D3 D2 D1 D0
R/W SRESET LevelReq Conf5 Conf4 Conf3 Conf2 Conf1 Conf0
Table 7: Card Configuration and Status Register
Operation D7 D6 D5 D4 D3 D2 D1 D0
Read Changed SigChg IOis8 XE_n Audio PwrDwn Int 0
Write 0 SigChg IOis8 XE_n Audio PwrDwn 0 0
142 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
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
CompactFlash specification.
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.
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.
Table 8: Pin Replacement Register
Operation D7 D6 D5 D4 D3 D2 D1 D0
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
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 143
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
Memory
The functionality for the Common Memory space may be found in the reference design source
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.
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
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
144 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
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.
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 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
Table 11: I/O Space Status Register
Operation D7 D6 D5 D4 D3 D2 D1 D0
Read IRQ_CF IRQ_DSP 0 0 0 0 DataReg AddrReg
Write 0 0 0 0 0 0 0 0
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 145
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.
This bit is found in the reference design source files as io_status_reg(1).
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.
This bit is found in the reference design source files as io_status_reg(0).
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.
146 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
R
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.
Figure 3: I/O Space State Machine
DSP_DATA_READ
DSP_DATA_WRITE
CF_ADDR
dsp_address_match = 1
dsp_ioms_n = 0
dsp_rd_n = 0
dsp_address_match = 1
dsp_ioms_n = 0
dsp_wr_n = 1
dsp_rd_n = 1
io_address_match = 1
and
io_write_n_sync = 0
dsp_data_done = 1
or
dsp_wr_n = 1
io_address_match = 1
and
io_read_n_sync = 0
dsp_address_match = 1
dsp_ioms_n = 0
dsp_wr_n = 0
dsp_ioms_n = 0
dsp_data_done = 1
or
dsp_ioms_n = 1
io_write_n_sync = 0
or
io_read_n_sync = 0
io_read_n_sync = 1
io_write_n_sync = 1
DSP_ADDR
CF_DATA_WRITE
CF_DATA_READ
IDLE
X398_03_062003
CompactFlash Card Interface for CoolRunner-II CPLDs
XAPP398 (v1.0) September 23, 2003 www.xilinx.com 147
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
Download
The VHDL source code and test benches are available for this design. THE DESIGN IS
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.
XAPP398 - http://www.xilinx.com/products/xaw/coolvhdlq.htm
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
148 www.xilinx.com XAPP398 (v1.0) September 23, 2003
1-800-255-7778
CompactFlash Card Interface for CoolRunner-II CPLDs
R
Revision
History
The following table shows the revision history for this document.
Date Version Revision
09/23/03 1.0 Initial Xilinx release.
XAPP394 (v1.1) December 1, 2003 www.xilinx.com 149
1-800-255-7778
© 2003 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.
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
Definitions
It is important to define the connections in this design before describing the CPLD logic to
interface with the Mobile SDRAM. Table 1 defines the Mobile SDRAM interface signals
described in this document.
Application Note: CoolRunner-II CPLDs
XAPP394 (v1.1) December 1, 2003
Interfacing to Mobile SDRAM with
CoolRunner-II CPLDs
R
Table 1: Mobile SDRAM Signal Definitions
Manufacturer
Specification
Xilinx CPLD
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
Command signals that define current operation.
RAS# sdram_ras
CAS# sdram_cas
WE# sdram_we
LDQM,
UDQM
sdram_udqm,
sdram_ldqm
Mask signal for write data operations (LDQM
corresponds to DQ[7:0], while UDQM corresponds
to DQ[15:8]).
150 www.xilinx.com XAPP394 (v1.1) December 1, 2003
1-800-255-7778
Interfacing to Mobile SDRAM with CoolRunner-II CPLDs
R
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
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.
Table 1: Mobile SDRAM Signal Definitions
Manufacturer
Specification
Xilinx CPLD
VHDL Code Description
Interfacing to Mobile SDRAM with CoolRunner-II CPLDs
XAPP394 (v1.1) December 1, 2003 www.xilinx.com 151
1-800-255-7778
R
interface requirements to the Mobile SDRAM. Figure 1 illustrates the main control logic in the
CoolRunner-II CPLD.
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,
Figure 1: CPLD Block Diagram
SDRAM State Machine
s
d
r
a
m
_
r
e
a
d
_
e
n
sdram_cke
sdram_csn
sdram_casn
sdram_rasn
sdram_wen
sys_data [15:0]
sys_reset
sys_addr [23:0]
sys_cmd [3:0]
sys_clk sdram_clk
sdram_ldqm
sdram_udqm
sdram_ba [1:0]
sdram_a [12:0]
sdram_dq [15:0]
(UPCNT4)
RD_BRST_CNT
(UPCNT4)
WR_BRST_CNT
(UPCNT2)
CAS_CNT
Data Control Logic
Mode Register
CoolRunner-II CPLD
X394_01_021003
s
d
r
a
m
_
w
r
i
t
e
_
e
n
152 www.xilinx.com XAPP394 (v1.1) December 1, 2003
1-800-255-7778
Interfacing to Mobile SDRAM with CoolRunner-II CPLDs
R
AUTO PRECHARGE is utilized, where an ACTIVE command must be issued prior to any READ
or WRITE operation.
The function of each state in the SDRAM state machine is described in Table 2.
Figure 2: SDRAM State Machine
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.
IDLE
LOAD_MR_ST
PRECHRG_ST
AUTO_RFS_ST
ACTIVE_ST
sys_cmd = PRECHARGE
sys_cmd = LOAD_MR
sys_cmd = AUTO_RFS
sys_cmd = READ
or WRITE
WAIT_WRITE_ST
WRITE_ST
WRITE_DATA_ST
WAIT_TWR
WAIT_TRP
WAIT_READ_ST
READ_ST
CAS_DELAY_ST
READ_DATA_ST
sys_cmd = READ sys_cmd = WRITE
wr_brst_qout < BURST_LEN
cas_qout < CAS_LAT
rd_brst_qout < BURST_LEN
rd_brst_qout = BURST_LEN
cas_qout = CAS_LAT
wr_brst_qout = BURST_LEN
X394_02_021003
DPD_ST
sys_cmd = DEEP_PD
sys_cmd = WAKE_UP
Interfacing to Mobile SDRAM with CoolRunner-II CPLDs
XAPP394 (v1.1) December 1, 2003 www.xilinx.com 153
1-800-255-7778
R
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.
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
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 t
RCD
.
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 t
RCD
.
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, t
WR
.
WAIT_TRP Execute NOP instruction. Necessary to meet timing specification
for precharge command period, t
RP
.
Table 3: CoolRunner-II Design Utilization
Parameter Used Available % Utilization
I/O Pins 86 100 86%
Macrocells 102 128 80%
Product Terms 180 448 40%
Registers 100 128 78%
Function Block Inputs 126 320 39%
Table 2: SDRAM State Machine State Description
State Name Function
154 www.xilinx.com XAPP394 (v1.1) December 1, 2003
1-800-255-7778
Interfacing to Mobile SDRAM with CoolRunner-II CPLDs
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
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 DESIGN "AS IS" AS A COURTESY TO YOU.
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
Information
CoolRunner-II Data Sheets, Application Notes, and White Papers
Revision
History
The following table shows the revision history for this document.
Date Version Revision
09/23/03 1.0 Initial Xilinx release.
12/01/03 1.1 Errata
XAPP799 (v1.1) August 2, 2005 www.xilinx.com 155
© 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.
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 I
2
C compatible.
CoolRunner-II
Advantages
A key advantage of using any Xilinx CPLD as a port expander is the integration of logic
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 I
2
C design, as these environments are typically multi-voltage environments
requiring low power.
Table 1 summarizes the level translation abilities of the CoolRunner-II family.
Using the
CoolRunner-II
SMBus/I
2
C Port
Expander
Design
The port expansion reference design shown in Figure 1 provides 8 output ports and 8 input
ports controlled through an I
2
C 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.
This section describes the default code implementing 8 outputs and 8 inputs. The fully working
Application Note: CPLD
XAPP799 (v1.1) August 2, 2005
An SMBus/I
2
C-Compatible Port Expander
R
Table 1: I/O Standards for the CoolRunner-II XC2C32A
IOSTANDARD
Attribute
Output
V
CCIO
Input V
CCIO
Input V
REF
Board
Termination
Voltage V
T
LVTTL 3.3 3.3 N/A N/A
LVCMOS33 3.3 3.3 N/A N/A
LVCMOS25 2.5 2.5 N/A N/A
LVCMOS18 1.8 1.8 N/A N/A
LVCMOS15
(1)
1.5 1.5 N/A N/A
(1) LVCMOS15 requires the use of Schmitt Trigger
156 www.xilinx.com XAPP799 (v1.1) August 2, 2005
Using the CoolRunner-II SMBus/I2C Port Expander Design
R
project, with source code, is available for download at
http://www.xilinx.com/bvdocs/publications/XAPP799_designfiles.zip.
Figure 1: I
2
C Port Expander Block Diagram
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.
GP10_INPUT
(2 BITS)
GP10_OUTPUT
(8 BITS)
INDEX
COUNTER
i2c
STATE
MACHINE
8-bit Shift Register
START
DECODE
LOGIC
Start
sda_out
sda_in
ack_out
out_en
pld_sda_out
i2c_module_mod.v
GPIO_OUTPUT_PINS[7:0]
GPIO_INPUT_PINS[2:0]
reset goes
to all
blocks
i2c_rst
pld_i2c_scl
pld_i2c_rst
scl
l
a
t
c
h
_
d
a
t
a
_
i
n
l
a
t
c
h
_
d
a
t
a
_
o
u
t
d
a
t
a
_
i
n
[
7
:
0
]
g
p
i
o
_
i
n
p
u
t
[
1
:
0
]
s
h
i
f
t
_
d
a
t
a
_
i
n
d
a
t
a
_
i
n
[
7
:
0
]
2 8
8 2
external
pull_up
x799_01_071305
top.v
CoolRunner-II
XC2C32A
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
Using the CoolRunner-II SMBus/I2C Port Expander Design
XAPP799 (v1.1) August 2, 2005 www.xilinx.com 157
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.
I
2
C Slave Address
The CPLD has a 7-bit long I
2
C 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
158 www.xilinx.com XAPP799 (v1.1) August 2, 2005
Using the CoolRunner-II SMBus/I2C Port Expander Design
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 I
2
C
applications.
Customizing the Design
XAPP799 (v1.1) August 2, 2005 www.xilinx.com 159
R
Utilization
The following are the utilization statistics:
Customizing
the Design
This reference design can be customized to fit any specific design target. If the design requires
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.
Revision
History
The following table shows the revision history for this document.
Table 3: Device Utilization
Macrocells
Used/Total
Product Terms
Used/Total
Function Block
Inputs Used/Total
Registers
Used/Total
Pins Used/Total
32/32 (100%) 71/112 (63%) 36/80 (45%) 32/32 (100%) 13/33 (39%)
Date Version Revision
07/19/05 1.0 Initial Xilinx release.
08/02/05 1.1 Fixed broken link to design files.
160 www.xilinx.com XAPP799 (v1.1) August 2, 2005
Revision History
R
XAPP805 (v1.0) April 8, 2005 www.xilinx.com 161
© 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.
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 V
CC
. 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.
Figure 1: Traditional LED Driver Setup
Application Note: CPLD
XAPP805 (v1.0) April 8, 2005
Driving LEDs with Xilinx CPLDs
R
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
LED
Driver
Series
Resistor
LED
Vcc
162 www.xilinx.com XAPP805 (v1.0) April 8, 2005
Using Xilinx CPLDs to Drive LEDs
R
Using Xilinx
CPLDs to Drive
LEDs
Typical Circuit
Xilinx CPLDs can be used instead of traditional LED driver devices to save both cost and board
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.
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.
From Table 2, it is clear that Xilinx CPLDs are ideal for driving LEDs that require up to 8-10 mA
to illuminate.
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
Xilinx
CPLD Series
Resistor
LED
Vcc
Using Xilinx CPLDs to Drive LEDs
XAPP805 (v1.0) April 8, 2005 www.xilinx.com 163
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.
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
Figure4.
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
V
CCIO
available on all CoolRunner-II devices, the CPLD can interface with components of at
Xilinx
CPLD
Series
Resistor
LED
Vcc
Series
Resistor
Digit Select
8
Segment Select
8
164 www.xilinx.com XAPP805 (v1.0) April 8, 2005
Using Xilinx CPLDs to Drive LEDs
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.
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 V
OL
for the different Xilinx CPLD devices are mentioned in the data sheets in a
format similar to Table 3.
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


8
Segment Select
Digit Select
8
Xilinx CPLD

3.3V
2.5V

VCCIO1 VCCIO2

I
/
O

B
a
n
k

1
I
/
O

B
a
n
k

2
Discrete Logic
Absorption
Level Shifting
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
V
OL
Low Level Output Voltage I
OL
= 8 mA, V
CCIO
= 3V - 0.4 V
I
OL
= 0.1 mA, V
CCIO
=3V - 0.2 V
Guidelines for Driving Multiple LEDs with the Same CPLD
XAPP805 (v1.0) April 8, 2005 www.xilinx.com 165
R
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 (I
OL
)
is as high as 20 mA. Of course, these numbers are typical and cannot be guaranteed under
all circumstances.
Guidelines for
Driving Multiple
LEDs with the
Same CPLD
As mentioned earlier, it is possible to tie two or more outputs together to double or triple (and et
cetera) the drive strength for power hungry LEDs.
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
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.
166 www.xilinx.com XAPP805 (v1.0) April 8, 2005
Additional Information
R
Additional
Information
CoolRunner-II Data Sheets, Application Notes, and White Papers
Other CPLD Data Sheets, Application Notes and White Papers
Device Packages
Revision
History
The following table shows the revision history for this document.
Date Version Revision
04/08/05 1.0 Initial Xilinx release.
WP198 (v1.1) July 4, 2005 www.xilinx.com 167
© 2005 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.
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.
White Paper: CoolRunner-II CPLDs
WP198 (v1.1) July 4, 2005
CoolRunner-II CPLDs in Cell
Phone Handsets/Terminals
R
168 www.xilinx.com WP198 (v1.1) July 4, 2005
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
R
Quick Look at a
Handset
Figure 1 shows a fairly straightforward block diagram of a digital-type handset.
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.
Figure 1: Functional Components of a Digital Handset/Terminal
RF
RCV/AMP

D/A
A/D
SPEECH
CODER
SPEECH
DECODER
CHANNEL
CODER
CHANNEL
DECODE
CHANNEL
SPREAD
RAKE
RCVR
RF
MOD
RF
DEMOD
μproc
KEYBOARD
DISPLAY
DRAM
EPROM
SRAM
DUPLEXER
Application
Space
RF
AMP
CoolRunner-II
CPLD
dsp
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
WP198 (v1.1) July 4, 2005 www.xilinx.com 169
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
2. Distance Learning
3. Online Retail
4. Travel booking
5. E-books
6. Distance Learning
7. Online Retail
8. Travel booking
9. M-commerce
10. Online trading
11. Mobile banking
12. Gambling
13. Games Interactive toys
14. Video movie rental
15. Virtual radio station
16. Virtual TV station
17. Newspapers
18. Photo album
19. Video Conferencing
20. Field service
21. Business kiosks
22. Secure monitoring
23. telemedecine
24. Mobile clinics
25. Email
26. Secure monitoring
27. Targeted advertising
28. Free trials
29. Remote metering
30. Remote control
31. Mobile speed cameras
32. Remote surveillance
33. Ticket purchases
34. Showtime information
35. Vending machines
36. Parking meters
37. Buying Crossword puzzles
38. Navigation
39. Finding ATM money machines
40. And many more . . .
170 www.xilinx.com WP198 (v1.1) July 4, 2005
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
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
Chipsets
Figure 2 shows an Intel PXA 800F block diagram. Note that this multifaceted chipset is
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.
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.
Figure 2: Intel PXA 800F Cellular Chipset
Interrupt Controller GSM IRQCtrl
I-Cache D-Cache
4MB Flash 512 KB SRAM
Memory Controller
JTAG
CTRL
Intel
®
Xscale
TM
Core
Bridge DMA Controller
Keypad IF PWM
Rotary Encoders One Wire I/F
Reserved
GPIOs
UART 1,2,3
CSSP
I2C
MMC/SD
GSM SlowCLK
3x Timers/WDT
M/N Clock Out
TCU
USB
GSM SIM
UICC
Xscale
TM
Core Peripherals
Intel
®
MSA Core

512 KB Flash
32 KB SRAM B
GSM IRQ Ctrl
Cipher Accelerator
Rx Band DSSP2
Auxiliary DSSP4
DAI DSSP6
I2S
32 KB SRAM A
MSA DMA Ctrl
Viterbi Accelerator
Voiceband DSSP1
Tx Band DSSP1
RF Control DSSP5
HSL
JTAG
External
Memory
Bus
Clocks, Power Mgmt, RTC/VXO/PLL
PXA800F
Cellular Processor
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
WP198 (v1.1) July 4, 2005 www.xilinx.com 171
R
Picking the
Right Mix
Figure 3 shows an application that is not on the list—Global Positioning Satellite (GPS)
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.
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
Figure 3: GPS Added into a Phone
RF
RCV/AMP
D/A
A/D SPEECH
CODER
SPEECH
DECODER
CHANNEL
CODER
CHANNEL
DECODE
CHANNEL
SPREAD
RAKE
RCVR
RF
MOD
RF
DEMOD
μproc
KEYBOARD
DISPLAY
DRAM
EPROM
SRAM
DUPLEXER
RF
AMP
CoolRunner-II
CPLD
dsp GPS
CoolRunner-II
CPLD
172 www.xilinx.com WP198 (v1.1) July 4, 2005
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
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
Speculative
Example
To drive home some of these ideas, consider an idea for a product that probably does
not exist today, but easily could in the near future. It will be marketed under the name
“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.
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.
Figure 4: MediPhone Block Diagram
D/A
A/D
SPEECH
CODER
SPEECH
DECODER
CHANNEL
CODER
CHANNEL
DECODE
CHANNEL
SPREAD
RAKE
RCVR
RF
MOD
RF
DEMOD
Rf
RCV/AMP

μproc
KEYBOARD
DISPLAY
DRAM
EPROM
SRAM
DUPLEXER
RF
AMP
CoolRunner-II
CPLD
dsp
EKG
Camera
Chip
EEG
MPEG 4
A/Ds GPS
SRAM
DRAM
CoolRunner-II
CPLD
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
WP198 (v1.1) July 4, 2005 www.xilinx.com 173
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
Packaging are
Key!
We have not yet mentioned power in this discussion, but it may be a key element in
figuring out a solution, at least at the outset. Power management requires a careful
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
T
PD
(ns) 3.8 4.6 5.7 5.7 7.1 7.1
T
SU
(ns) 1.9 2.0 2.4 2.4 2.9 2.6
T
CO
(ns) 3.7 3.9 4.2 4.5 5.8 5.8
F
SYSTEM1
(MHz)
323 263 244 256 217 179
174 www.xilinx.com WP198 (v1.1) July 4, 2005
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
R
Looking
Forward to 4G
The fourth generation cell phones are already being referred to as Software Defined
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.
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
WP198 (v1.1) July 4, 2005 www.xilinx.com 175
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)
http://direct.xilinx.com/bvdocs/publications/ds092.pdf (XC2C64 Data Sheet)
http://direct.xilinx.com/bvdocs/publications/ds093.pdf (XC2C128 Data Sheet)
http://direct.xilinx.com/bvdocs/publications/ds094.pdf (XC2C256 Data Sheet)
http://direct.xilinx.com/bvdocs/publications/ds095.pdf (XC2C384 Data Sheet)
http://direct.xilinx.com/bvdocs/publications/ds096.pdf (XC2C512 Data Sheet)
CoolRunner-II White Papers
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.
CoolRunner-II White Papers
Revision
History
The following table shows the revision history for this document.
Date Version Revision
06/30/03 1.0 Initial Xilinx release.
07/04/05 1.1 Update of specifications in Table 1.
176 www.xilinx.com WP198 (v1.1) July 4, 2005
White Paper: CoolRunner-II CPLDs in Cell Phone Handsets/Terminals
R
XAPP512 (v1.1) May 6, 2005 www.xilinx.com 177
© 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.
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 CoolRunner
TM
-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
Application Note: CoolRunner-II CPLD
XAPP512 (v1.1) May 6, 2005
Implementing Keypad Scanners with
CoolRunner-II
R
178 www.xilinx.com XAPP512 (v1.1) May 6, 2005
Expanding I/O
R
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
Encoding
Besides reducing the processor’s GPIO requirements, the CPLD also scans the rows and
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 2
6
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.
CPLD Design Details
XAPP512 (v1.1) May 6, 2005 www.xilinx.com 179
R
CPLD Design
Details
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
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
180 www.xilinx.com XAPP512 (v1.1) May 6, 2005
Implementation and Verification
R
Implementation
and Verification
The reference design is implemented in Verilog. A Xilinx ISE
TM
software project is zipped up,
including the Verilog source file, Verilog testbench, and UCF file. If you do not have Xilinx
software, you can obtain ISE WebPACK
TM
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
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 DESIGN "AS IS" AS A COURTESY TO YOU.
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.
Additional
Information
CoolRunner-II Data Sheets, Application Notes, and White Papers
Access to all Xilinx Data Sheets, Application Notes, and White Papers
Device Packages
Revision
History
The following table shows the revision history for this document.
Date Version Revision
04/04/05 1.0 Initial Xilinx release.
05/06/05 1.1 NAND gate references on page 3 changed to AND gates.
XAPP785 (v1.0) June 22, 2005 www.xilinx.com 181
© 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.
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 CoolRunner
TM
-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 V
CCIO
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 V
CCIO
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
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.
Application Note: CoolRunner-II
XAPP785 (v1.0) June 22, 2005
Level Translation Using Xilinx
CoolRunner-II CPLDs
R
IOSTANDARD
Attribute Output V
CCIO
Input V
CCIO
Input
(1)

V
REF
Board
TerminationVoltage
V
TT
LVTTL 3.3 3.3 N/A N/A
LVCMOS33 3.3 3.3 N/A N/A
LVCMOS25 2.5 2.5 N/A N/A
LVCMOS18 1.8 1.8 N/A N/A
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
182 www.xilinx.com XAPP785 (v1.0) June 22, 2005
Configuring I/O to Use I/O Standards
R
Configuring I/O
to Use I/O
Standards
The designer specifies which I/O standard to use at the time of design entry. I/Os can be
configured to operate at different I/O standards in a number of ways.
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
V
CCIO
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
as a Level
Shifter
In addition to knowing of how to configure the I/O of the CPLD at different voltages, it is also
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.
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 T
PD
(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
Using the CPLD as a Level Shifter
XAPP785 (v1.0) June 22, 2005 www.xilinx.com 183
R
interfaces for use in electronic systems (USB, SPI, I
2
C), 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.
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


Vccio1 = 1.8V Vccio2 = 3.3V
CoolRunner-II CPLD
184 www.xilinx.com XAPP785 (v1.0) June 22, 2005
Conclusion
R
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 V
CCIO
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 V
CCIO
range for
LVCMOS25 is 2.3V to 2.7V, and the permissible V
CCIO
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 V
IH
min and V
OH
min
specifications for a pseudo-2.85V I/O standard can be interpolated from these specifications.
V
IH
will be in the region of 1.85V and V
OH
will be V
CCIO
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 V
CCIO
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.
Additional
Information
CoolRunner-II Data Sheets, Application Notes, and White Papers
Access to all Xilinx Data Sheets, Application Notes, and White Papers
Device Packages
Revision
History
The following table shows the revision history for this document.
Date Version Revision
06/22/05 1.0 Initial Xilinx release.
XAPP904 (v1.0) August 22, 2005 www.xilinx.com 185
© 2000-2003, 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.
Summary CoolRunner
TM
-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
Application Note: CoolRunner-II
XAPP904 (v1.0) August 22, 2005
CoolRunner-II Character LCD Module
Interface
R
186 www.xilinx.com XAPP904 (v1.0) August 22, 2005
CPLD Implementation
R
CPLD
Implementation
Figure 2 shows a block diagram of an LCD Controller on a CoolRunner-II CPLD.
Figure 2: LCD Controller Block Diagram
(})
Figure 1: Data Write from CPLD to LCD
C
N
T
R
C
N
T
R
Power_up
Main State Machine
8
8
Data
C0
8
lcd_db
`0' lcd_rw
lcd_rs
lcd_e
16
d
o
n
e
c
o
u
n
t
e
r
ready
r
e
a
d
y
W
db
8
clk
reset
CoolRunner-II CPLD
CPLD Implementation
XAPP904 (v1.0) August 22, 2005 www.xilinx.com 187
R
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.
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
Table 1: Signal Descriptions
Signal Name
Port
Specification
Description
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
188 www.xilinx.com XAPP904 (v1.0) August 22, 2005
CPLD Implementation
R
every power-up or reset. All timing requirements will be met, assuming a 1.8 MHz external
clock frequency.
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.
Figure 3: LCD Module Initialization Sequence
Figure 4: Power_Up Module Block Diagram
Reset Data
Counter_Enable Count
Clk Done
8
15
Resource Summary
XAPP904 (v1.0) August 22, 2005 www.xilinx.com 189
R
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
Summary
This design uses a total of only 40 macorcells, allowing it to fit into an XC2C64A device.
************************* 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
Information
CoolRunner-II Data Sheets and Application Notes
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.
190 www.xilinx.com XAPP904 (v1.0) August 22, 2005
Revision History
R
Revision
History
The following table shows the revision history for this document.

Date Version Revision
08/22/05 1.0 Initial Xilinx release.
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 191
1-800-255-7778
© 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 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.
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
Application Note: CoolRunner CPLD
XAPP354 (v1.1) September 30, 2002
Using Xilinx CPLDs to Interface to a
NAND Flash Memory Device
R
192 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
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.
The NAND Flash interface signals and functionality is shown in Table 1.
Figure 1: System Block Diagram
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.
CoolRunner
XPLA3 CPLD
X354_02_082701
AMD UltraNAND
(AM30LV0064D)
or
Samsung
(K9F4008W0A)
CE#
RE#
I/O[7:0]
WE#
SE#
ALE
CLE
WP#
ADDR[3:0]
WRITE#
READ#
CE#
RESET
RY/BY# RY/BY#
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 193
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.
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
Figure 2: AMD UltraNAND Block Diagram
High Voltage Pumps
ALE
Data Register & S/A
Memory Array
X354_03_082701
Command Register
Address Register
Status Register
I/O Register & Buffer I/O 7-0
RY/BY#
State Machine
CLE SE# WP#
CE#
RE#
WE#
VCC
VCCQ
VSS
Y-Decoder
X

D
e
c
o
d
e
r
Y-Decoder
Data Register & S/A
194 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
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.
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
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.
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 195
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.
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.
Figure 3: Samsung Block Diagram
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.
X354_04_082701
X-Buffers Latches
& Decoders
A7 - A18
A0 - A6
Command
Y-Buffers Latches
& Decoders
Command
Register
Control Logic
& High Voltage
Generator
ALE
Global Buffers
I/O0
I/O Buffers & Latches
Y-Gating
Page Register & S/A
4M Bit
NAND Flash ARRAY
32Byte x 4Frames x 4096Rows
CE
RE
CLE WP
I/O7
WE
196 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
R
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.
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 (A
18
to A
12
).
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.
Table 4: CPLD Port Address Definition
Port Operation Function
0 Read Data/ID/Status
or Write Address/Data
Read information from previous command loaded.
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.
Table 3: Samsung Command Set
Command Cycle Data Description
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 197
1-800-255-7778
R
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.
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
Implementation
The NAND flash interface was implemented in VHDL and Verilog as described above; and in
ABEL as described by AMD. Xilinx Project Navigator was used for design compilation, fitting,
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: CPLD Port Address Definition
Port Operation Function
Figure 4: CPLD Block Diagram
B1
X354_05_082701
SEN_SIG
OUTCE_SIG
LE_SIG
PORT2
RESET
WRITE_N
READ_N
RY_BYN
PORT_ADDR[3:0]
CE_N
COM_LAT_N
PORT3
ALE_INT
WPN_SIG
READY_SIG
PORT1
PORT0
PORT7
PORT5
WP_N_INT
PORT9
PORT5
OUTCE_N_INT
PORT5
PORT4
SE_N_INT
PORT1
OUTCE_N
PORTA
SE_N
CLE
PORTB
PORTC
PORTE
WE_N
PORTD
RE_N
READY
ALE
WP_N
B5
198 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
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.
Design
Verification
Verification of the NAND interface was performed using the Xilinx WebPACK Project Navigator
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.
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.
Table 5: NAND Interface XPLA3 32-Macrocell Utilization
Resource Available Used Utilization
Function Blocks 2 2 100%
Macrocells 32 10 31.25%
Product Terms 96 47 48.96%
I/O Pins 32 21 65.63%
Figure 5: Test Bench Diagram
NAND_INTERFACE
XPLA3 Flash
Interface
X354_06_082701
AM30LV0064D or
K9F4008W0A
Denali Memory
Model
PORT_ADDR[3:0]
NAND_FLASH_TB
FAIL_FLAG
WRITE_N
READ_N
RESET
CPLD_CEN
COM_LAT_N
I/O[7:0]
CE_N
RE_N
WE_N
SE_N
ALE
CLE
WP_N
RY_BYN
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 199
1-800-255-7778
R
Figure 6: Memory Operational Test Flow
Flash
Buffer
Full?
Yes
No
START
X354_07_082701
Return Program
Successful
Return Program
Failed
Enable Flash Device: Assert OUTCE# (low)
Write 00h to PORTADDR8
Issue Command: Clear ALE (low)
Write 00h to PORTADDR3
Issue "Read First Half Page" Command:
Write 00h to PORTADDR0
Enable Spare Area: Assert SE# (low)
Write 00h to PORTADDR4
Allow Flash Program: Clear WP# (high)
Write 00h to PORTADDR7
Issue "Input Data" Command:
Write 80h to PORTADDR1
Write Address: Set ALE (high)
Write 00h to PORTADDR2
Load Page Address:
Write ADDR to PORTADDR0
Write Data to Flash Buffer:
Write DATA to PORTADDR0
Issue a "Page Program" Command:
Write 10h to PORTADDR1
Device
Ready?
Yes
No
Issue a "Read Status" Command:
Write 70h to PORTADDR1
Read Device Status:
Read from PORTADDR0
Program
Operation
Passed?
Yes
No
Read Device Status:
Read from PORTADDR0
Protect Flash Device: Set WP# (low)
Write 00h to PORTADDR6
200 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
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 8 illustrates how to change any signal name requirements in the MemMaker tool.
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
Figure 7: Opening a SOMA File in MemMaker
Figure 8: MemMaker Functional View
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 201
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.
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
Figure 9: MemMaker Source Code View
202 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
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.
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 203
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 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
Figure 10: Memory Address Load
204 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
R
failed. Notice where the simulation is highlighted in Figure 11, the program operation was
successful.
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
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
Figure 11: Program Status: "Ready"
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
XAPP354 (v1.1) September 30, 2002 www.xilinx.com 205
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
REFERENCE DESIGN "AS IS" AS A COURTESY TO YOU.
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/)
Revision
History
The following table shows the revision history for this document.
Date Version Revision
08/30/01 1.0 Initial Xilinx release.
09/30/02 1.1 Minor changes.
206 www.xilinx.com XAPP354 (v1.1) September 30, 2002
1-800-255-7778
Using Xilinx CPLDs to Interface to a NAND Flash Memory Device
R
XAPP430 (v1.0) July 8, 2003 www.xilinx.com 207
1-800-255-7778
© 2003 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 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.
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
Overview
Important: Read all instructions carefully on the following pages before use in order to avoid
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
Application Note: CoolRunner-II CPLD
XAPP430 (v1.0) July 8, 2003
Cell Phone Security Demoboard
On The Fly Reconfiguration Technique
R
208 www.xilinx.com XAPP430 (v1.0) July 8, 2003
1-800-255-7778
On The Fly Reconfiguration Technique
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.
On The Fly Reconfiguration Technique
XAPP430 (v1.0) July 8, 2003 www.xilinx.com 209
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.
210 www.xilinx.com XAPP430 (v1.0) July 8, 2003
1-800-255-7778
On The Fly Reconfiguration Technique
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
On The Fly Reconfiguration Technique
XAPP430 (v1.0) July 8, 2003 www.xilinx.com 211
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.
212 www.xilinx.com XAPP430 (v1.0) July 8, 2003
1-800-255-7778
On The Fly Reconfiguration Technique
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
Information
Demonstration State Diagram
This demonstration utilizes a few simple state machines that can be represented by a top level
diagram as seen in Figure 9.
Figure 9: Demonstration State Machine
Phone operable
Perform Scroll
SIM Match?
Accept New
SIM
N Y
Phone operable
Perform Scroll
Code Match?
Y N
Perform Self
Erase
X_09_062603
On The Fly Reconfiguration Technique
XAPP430 (v1.0) July 8, 2003 www.xilinx.com 213
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
Conditions TAP State Event Description
Programmer
Action
0 TMS = 1 Test-Logic/Reset Begin Begin
Loop 0 TMS = 1
TCK = rise
Test-Logic/Reset Ensure device in Test
Logic Reset State
Loop 5 times
1 TMS = 0
TCK = rise
Run-Test/Idle
2 TMS = 1
TCK = rise
Select DR-Scan
3 TMS = 1
TCK = rise
Select IR Scan
4 TMS = 0
TCK = rise
Capture IR
5 TMS = 0
TCK = rise
Shift IR
Loop1 TMS = 0
TCK = rise
Shift IR Shift in Instruction Bits
(0-6)
TDI = 0010011
(Enable OTF)
214 www.xilinx.com XAPP430 (v1.0) July 8, 2003
1-800-255-7778
On The Fly Reconfiguration Technique
R
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
Revision
History
The following table shows the revision history for this document.
6 TMS = 1
TCK = rise
Exit1-IR Shift in Instruction Bit 7 TDI = 1
Enable_OTF
(MSB)
7 TMS = 1
TCK = rise
Update-IR Load the Instruction
Register, Set enable flip
flop
8 TMS = 1
TCK = rise
Select DR-Scan
9 TMS = 1
TCK = rise
Select IR-Scan
10 TMS = 0
TCK = rise
Capture-IR
11 TMS = 0
TCK = rise
Shift-IR
Loop2 TMS = 0
TCK = rise
Shift-IR Shift in Instruction Bits
(0-6)
TDI = 1011011
(Erase)
12 TMS = 1
TCK = rise
Exit1-IR Shift in Instruction Bit 7 TDI = 1
Erase (MSB)
13 TMS = 0
TCK = rise
Update-IR Load the instruction
Register
14 TMS = 0
TCK = rise
Run-Test Idle Execute: Erase the
Device
Loop here for
100ms
15 TMS = 1
TCK = rise
Select DR-Scan
16 TMS = 1
TCK = rise
Select IR-Scan
17 TMS = 0
TCK = rise
Capture-IR
18 TMS = 0
TCK = rise
Shift-IR
Table 1: OTF ERase JTAG Sequence (Continued)
Step Transition
Conditions TAP State Event Description
Programmer
Action
Date Version Revision
07/08/03 1.0 Initial Xilinx release
XAPP905 (v1.0) August 25, 2005 www.xilinx.com 215
© 2000-2003, 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.
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
Translation
Interfacing two chips of different voltage standards is a common problem. Every type of
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.
Figure 1: CoolRunner-II Level Translation of TI OMAP Signals
Application Note: CoolRunner-II CPLD
XAPP905 (v1.0) August 25, 2005
Using CoolRunner-II with OMAP, XScale,
i.MX & Other Chipsets
R
B
a
n
k
1
B
a
n
k
2
Fabric
TI
OMAP
CoolRunner-II CPLD
VCC1 VCC2
216 www.xilinx.com XAPP905 (v1.0) August 25, 2005
Pin Expansion
R
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 I
2
C 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.
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
Reduction
XScale, OMAP and i.MX based chipsets all include some version of the ARM microprocessor.
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
INTEL
PXA 850
XScale
Logic
Fabric
CoolRunner-II CPLD
Logic Consolidation
XAPP905 (v1.0) August 25, 2005 www.xilinx.com 217
R
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 DataGATE
TM
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!
Figure 3: DataGATE Blocking Extraneous Switching to Various Devices
Logic
Consolidation
Having three, two input AND gates, two three input OR gates and a Schmitt buffer package on
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.
CoolRunner-II
i.MX
Processor
DataGATE Blocking
SRAM
DRAM
I/O
EPROM
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
218 www.xilinx.com XAPP905 (v1.0) August 25, 2005
Additional Information
R
Additional
Information
CoolRunner-II Data Sheets and Application Notes
Conclusion -
The Future
CoolRunner-II CPLDs are quickly becoming the standard for low power, low cost, high volume,
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.
Revision
History
The following table shows the revision history for this document.

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
Table 1: Macrocell “Burn Rate” for Common TTL Functions
Function Macrocells P-terms Flip-Flops
Date Version Revision
08/25/05 1.0 Initial Xilinx release.
XAPP914 (v1.0) January 15, 2006 www.xilinx.com 219
© 2000-2003, 2006 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.
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.
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-II
TM
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 V
CCIO
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.
Application Note: CoolRunner-II CPLD
XAPP914 (v1.0) January 15, 2006
Connecting Intel PXA27x Processors to
Hard-Disk Drives with a CoolRunner-II
CPLD
R
Table 1: Supported I/O Standards in CoolRunner-II Family
IOSTANDARD
Attribute
Output
V
CCIO
Input
V
CCIO
Input
(1)

V
REF
Board Termination Voltage
(V
TT
)
LVTTL 3.3 3.3 N/A N/A
LVCMOS33 3.3 3.3 N/A N/A
LVCMOS25 2.5 2.5 N/A N/A
LVCMOS18 1.8 1.8 N/A N/A
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 V
REF
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.
220 www.xilinx.com XAPP914 (v1.0) January 15, 2006
PXA27x
R
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.
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.
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
CoolRunner-II XC2C64A
CompactFlash
Connector
Level
Shifter
Level
Shifter
D[15..0]
A[3..1]
PXA27x
nOE
nPWE
A4
nCS5
A5
nRESET_OUT
GPIOx
Glue
Logic
Glue
Logic
D[15..0]
A[2..0]
#IORD
#IOWR
#CS0
#CS1
#RESET
INTRQ
#ATASEL
#CSEL
GND
A[10..3]
GND
VCC
#WE
HDD_VCC
#DMACK
DMARQ
#IOCS16
#CD2
#CD1
#VS1
#VS2
#DASP
#PDIAG
IORDY
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
Conclusion
XAPP914 (v1.0) January 15, 2006 www.xilinx.com 221
R
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.
Revision
History
The following table shows the revision history for this document.

Date Version Revision
01/15/06 1.0 Initial Xilinx release.
222 www.xilinx.com XAPP914 (v1.0) January 15, 2006
Revision History
R
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 223
© 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.
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.
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
Application Note: CoolRunner-II CPLD
XAPP939 (v1.0) May 30, 2006
A Low-Power IDE Controller Design
Using a CoolRunner-II CPLD
R
224 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
R
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
IDE Controller
Implementation
CoolRunner-II CPLD implementation of the IDE Controller supports the following features:
• Intel PXA270 CPU Static Memory Interface in 16-bit VLIO mode
• 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
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 225
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
CPU_CLK_I I
104 MHz clock input to CPLD; connected to SDCKx
line of the PXA270 CPU
CPU_RST_N_I I
Active Low asynchronous reset signal; connected to
the nRESETOUT line of the PXA270 CPU
CPU_CS_N_I I
Active Low chip select signal; connected to the nCSx
line of the PXA270 CPU
CPU_ADDR_I [9:0] I
Address signals from CPU, which are used to decode
the device register access and the SRAM access;
connected to the MA[10:1] lines of the PXA 270 CPU
CPU_D_IO [15:0] I/O
Data bus between the PXA270 CPU and the core;
connected to the MD [15:0] lines of the PXA 270 CPU
CPU_WE_N_I I
Active Low write enable input; connected to the nPWE
line of the PXA270 CPU
CPU_OE_N_I I
Active Low read enable input; connected to the nOE
line of the PXA270 CPU
CPU_INTR_O O
Interrupt from the CPLD to CPU; connected to the
GPIOx line of the PXA 270 CPU
CPU_RDY_O O
Ready signal to insert the wait state; connected to
RDY line of the PXA270 CPU
Table 2: SRAM Interface Signals
Name Input/Output Description
SRAM_ADDR_O
[13:0]
O
Address signal to access the memory connected to
the A13-A0 lines of the memory
SRAM_DD_IO [15:0] I/O
Data bus between the SRAM and the core. I/O15 to
I/O0 lines of the memory
SRAM_WE_N_O O
Active Low SRAM write enable output connected to
the WEn line of the memory
SRAM_OE_N_O O
Active Low SRAM read enable output connected to
the OEn line of the memory
SRAM_CS_N_O O
Active Low SRAM Chip Select Signal connected to
the CEn line of the memory
226 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
R
Table 3: IDE Interface Signals
Name Input/Output Description
ATA_RESET_N_O O
Used by host to reset the device; connected to the
RESET- of the hard disk
ATA_CS_N_O [1:0] O
Chip select signals used to select device command or
control block registers; connected to the CS1- and CS0-
line of the hard disk
ATA_DA_O [2:0] O
Address signals to access device registers or data port;
connected to the DA2-DA0 lines of the hard disk
ATA_DD_IO [15:0] I/O
Bi-directional data bus between device and host;
connected to the DD15-DD0 lines of the hard disk
ATA_DMACK_N_O O
Active Low host response to DMARQ to initiate DMA
transfer; connected to the DMACK- line of the hard disk
ATA_DMARQ_I I
Asserted by device to initiate DMA transfer; connected
to the DMARQ line of the hard disk
ATA_DIOR_N_O O
Active Low read strobe to read the device registers or
data port; connected DIOR- line of the hard disk
ATA_DIOW_N_O O
Active Low write strobe to write device registers or data
port; connected to the DIOW- line of the hard disk
ATA_INTRQ_I I
Used by device to interrupt the host; connected to the
INTRQ line of the hard disk
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 227
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.
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
CPU_D_IO[15:0]
CPU_ADDR_I[9:0]
CPU_CS_N_I
CPU_WE_N_I
CPU_OE_N_I
CPU_CLK_I
CPU_RST_N_I
CPU_INTR_O
ATA_RESET_N_O
ATA_CS_N_O[1:0]
ATA_DA_O[2:0]
ATA_DD_IO[15:0]
ATA_DIOR_N_O
ATA_DIOW_N_O
ATA_INTRQ_I
ATA_DMACK_N_O
ATA_DMARQ_I
SRAM
CONTROLLER
CPU Interface
IDE Interface
CPU
INTERFACE
AND
REGISTER
BLOCK
IDE
INTERFACE
PIO
STATE
MACHINE
DMA
STATE
MACHINE
SRAM_ADDR_O[13:0]
SRAM_DD_IO[15:0]
SRAM Interface
SRAM_WE_N_O
SRAM_OE_N_O
SRAM_CS_N_O
CPU_RDY_O
228 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
R
CPLD Register Details
Mode Select Register
Mode Select Register is used to select the mode of operation on the IDE interface.
Table 4: Register LIst
SI Number Register Name Width Read/Write Address
1
Mode Select
Register
3 R/W IDE Base + 0x000
2
PIO Command,
Address Register
5 R/W IDE Base + 0x002
3
PIO Read, Write
Data Register
16 R/W IDE Base + 0x004
4 Command Register 2 R/W IDE Base + 0x006
5
Interrupt Enable
Register
3 R/W IDE Base + 0x008
6
Interrupt Status
Register
5 R/W IDE Base + 0x00A
7 SRAM Buffer 1 16 R/W
IDE Base + 0x400 to
IDE Base + 0x5FE
8 SRAM Buffer 2 16 R/W
IDE Base + 0x600 to
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.
Table 5:
Mode Select Register Address Offset: [3:1] = b000
Bit Bit Name R/W Default Description
15:3
2:1
0
-
Timing Mode
Transfer Mode
-
R/W
R/W
0
00
0
Reserved
Selects the timing mode for the DMA
mode of transfer
00--Mode 0 (Cycle Time--480 ns)
01--Mode 1 (Cycle Time--150 ns)
10--Mode 2 (Cycle Time--120 ns)
Selects the mode of transfer on the
interface
0--PIO Mode
1--DMA Mode
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 229
R
PIO Command Address Register
PIO Command Address Register is used select the device control and command block
registers.
PIO Read/Write Data Register
PIO Read/Write Data Register is used to read and write data from IDE device.
Table 6: PIO Command Address Register
PIO Command Address
Write Data Register
Address Offset: [3:1] = b001
Bit Bit Name R/W Default Description
15:5 - - 0 Reserved
4:3 Chip Select R/W 00
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
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.
2:0 Device Address R/W 000
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
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.
Table 7: PIO Read/Write Data Register
PIO Read, Write Data
Register
Address offset: [3:1] = b010
Bit Bit Name R/W Default Description
15:0 Read, Write
Data
R/W 0000
Hold the read/write data from/to IDE device.
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.
230 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
R
Command Register
Command Register is used to select between read and write operation on IDE interface.
Interrupt Enable Register
The Interrupt Enable Register is used to update the status of SRAM.
Table 8: Command Register
Command Register Address offset: [3:1] = b011
Bit Bit Name R/W Default Description
15:2
1
0
-
Write Command
Read Command
-
R/W
R/W
0
0
0
Reserved
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.
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
Table 9: Interrupt Enable Register
Interrupt Enable
Register
Address offset: [3:1] = b100
Bit Bit Name R/W Default Description
15:4
3
2
1
0
-
SRAM Status Bit
Interrupt Enable
Device Interrupt
Request Enable
Receive Full
Enable
Transmit Empty
Enable
-
R/W
R/W
R/W
0
0
0
0
Reserved
This register is used to enable the SRAM Status
bit interrupt towards the CPU.
0- SRAM Status bit interrupt is not enabled
1- SRAM Status bit interrupt is enabled
This register is used to enable the Device
Interrupt towards the CPU.
0 - Interrupt request bit is not enabled
1 – Interrupt request bit is enabled
This register is used to enable Receive Full
interrupt towards the CPU.
0 - Receive Full interrupt is not enabled
1 - Receive Full interrupt is enabled
This register is used to enable Transmit Empty
interrupt towards the CPU.
0 - Transmit Empty interrupt is not enabled
1 - Transmit Empty interrupt is enabled
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 231
R
Interrupt Status Register
Interrupt Status Register is used to report the different source of interrupt.
Table 10: Interrupt Status Register
Interrupt Status
Register
Address offset: [3:1] = b101
Bit Bit Name R/W Default Description
15:5
4
3
2
1
0
-
SRAM Status
Bit1
SRAM Status
Bit0
Device Interrupt
Receive Full
Transmit Empty
-
R/W
R/W
R
R
R
0
0
0
0
0
1
Reserved
If mode is set to DMA Mode, indicates whether
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
If mode is set to DMA Mode, indicates whether
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
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
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
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
232 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
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.
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
IDLE
WRITE
READ
cpu_oe or
dma_oe
cpu_we or
dma_we
Count ==3’h05
Count ==3’h05
rst_n ==1’b0
Count <3’h05
Count <3’h05
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 233
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.
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
IDLE
SETUP_START
END SETUP
PULSE_START HOLD
HOLD_START
PULSE
Wr_cmd/Rd_cmd
Count==0
Count==0
Count ==0
rst_n ==1’b0
Count>0
Count>0
Count>0
234 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
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.
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 235
R
END:
In this state DIOR_N and DIOW_N will be in High state. The next state will be the IDLE state
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.
IDLE
SETUP_START
SETUP
PULSE_START
PULSE
HOLD_START
HOLD
HOLD_LAST
DELAY
END
((Wr_cmd) &&( (sramstatus bit1==1’b0)||
(sramstatus bit0==1’b0)))| |((Rd_cmd)
&&( (sramstatus bit1==1’b1)|| (sram
status bit0==1’b1)))&&DMA_req
Mode 0
count ==0
count ==0
count ==0
DELAY_LAST
Mode 2
Mode1||
Mode2
((Wr_cmd) &&( (sramstatus bit1==1’b0)||
(sramstatus bit0==1’b0))) ||((Rd_cmd)
&&( (sramstatus bit1==1’b1)|| (sram
status bit0==1’b1)))&&DMA_req
Count>0
rst_n ==1’b0
Mode0 ||
Mode1
Count>0
Count>0
236 www.xilinx.com XAPP939 (v1.0) May 30, 2006
CoolRunner-II IDE Controller Implementation
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
CoolRunner-II IDE Controller Implementation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 237
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.
238 www.xilinx.com XAPP939 (v1.0) May 30, 2006
Operational Flow Diagram
R
Operational
Flow Diagram
The flow of the interface between the CPU and the IDE Controller is detailed in the following
flow charts. These flow charts are meant to be a guide for using the IDE Controller.
Figure 7: PIO Write Transaction Flow Chart
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
Write the data in the
PIO Read, Write register
Write the write command
in the Command Register
Is
Transmit Empty bit
is set
Wait for interrupt ,when
interrupt arrives, read the
Interrupt Status register
END
NO
Set the Transmit Empty Enable bit
and device interrupt enable bit
in the Interrupt Enable Register
Yes
Is
Transmit Empty bit
is Set
Read the Transmit Empty bit
of Interrupt Status register
Yes
NO
Operational Flow Diagram
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 239
R
Figure 8: PIO Read Transaction Flowchart
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
Read the data in the
PIO Read, Write register
Is
Receive Full bit
is set
Wait for interrupt ,when
interrupt arrives, read the
Interrupt Status register
END
NO
Yes
Write the Read command
in the Command Register
Set the Receive Full Enable bit
and Device Interrupt enable bit
in the Interrupt Enable Register
240 www.xilinx.com XAPP939 (v1.0) May 30, 2006
Operational Flow Diagram
R
Figure 9: DMA Write Transaction Flowchart
Begin
Write the data to the
Buffer1 of the sram
Writethe writecommand
in theCommand Register
Sramstatus bit0
is clear
Wait for interrupt ,when
interrupt arrives, read the
Interrupt Status register
END
Is
Sramstatus bit1
is clear
Last word
of Buffer1
Set thesramstatus bit0 of the
interrupt status register
Writethedata to the
Buffer2 of thesram
Last word
of Buffer2
Set the sramstatus bit1 of the
interrupt status register
No
No
Configure the DMA mode
by writing
to the ModeSelect Register
Set the SramStatus Bit Enable
in theInterrupt EnableRegister
Clear thewritecommand
in the Command Register
No
No
Yes
Yes
Yes
Yes
Was it the
Last Sector
Yes
No
Read thesramstatus bit0 &
sramstatus bit1 of the
Interrupt Status Register
Sramstatus bit0
& sramstatus bit1
arecleared
Yes
No
Verilog Test Bench and Functional Simulation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 241
R
Figure 10: DMA Read Transaction Flow Chart
Verilog Test
Bench and
Functional
Simulation
A Verilog test bench has been developed that verifies the IDE Controller implementation. This
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
be used to run test cases so as to test the IDE Controller.
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.
Begin
Read the data fromthe
Buffer1 of the sram
Write the Read Command
in the Command Register
Sramstatus bit0
is set
Wait for interrupt ,when
interrupt arrives, read the
Interrupt Status register
END
Sramstatus bit1
is set
Last word
of Buffer1
clear the sramstatus bit0 of
the interrupt status register
Read the data fromthe
Buffer2 of the sram
Last word
of Buffer2
Clear the sramstatus bit1 of
the interrupt status register
No
No
Configure the DMA mode
by writing
to the Mode Select Register
Set the SramStatus Bit Enable
in the Interrupt Enable Register
Clear the Read Command
in the Command Register
No
No
Yes
Yes
Yes
Yes
Was it the
Last Sector
Yes
No
242 www.xilinx.com XAPP939 (v1.0) May 30, 2006
Cool Runner II CPLD Implementation
R
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
CPLD
Implementation
The top level file for the IDE Controller is ATA Block, which has been entered as a hierarchical
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
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
Resource Available Used Utilization
Macrocells 256 227 89%
P-terms 896 747 84%
Registers 256 166 65%
I/O Pins 106 93 88%
Function Block Inputs 640 549 86%
Post-Fit Timing Simulation
XAPP939 (v1.0) May 30, 2006 www.xilinx.com 243
R
IDE Controller with SRAM access time of 10ns utilizes 233 of the 256 macrocells available in
the device.
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
Simulation
The Xilinx Project Navigator software package outputs a timing Verilog model of the fitted
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.
Table 12: CoolRunner-II CPLD 256-Macrocell Utilization for IDE Controller with SRAM
Access Time of 10 ns
Resource Available Used Utilization
Macrocells 256 233 91%
P-terms 896 705 78%
Registers 256 165 64%
I/O Pins 106 93 88%
Function Block Inputs 640 570 89%
244 www.xilinx.com XAPP939 (v1.0) May 30, 2006
Limitations
R
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.
Revision
History
The following table shows the revision history for this document.

Date Version Revision
05/30/06 1.0 Initial Xilinx release.
XAPP944 v1.0 June 14, 2006 www.xilinx.com 245
© 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.
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.
Summary This application note shows how a Xilinx CoolRunner
TM
-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
Sources
The MPEG-2 encoded data from the different sources arrives in Transport Streams (TS). The
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
Background
Before implementing even a simple design inside a Xilinx CoolRunner-II CPLD, it is important
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.
Application Note: CoolRunner-II CPLD
XAPP944 v1.0 June 14, 2006
Using a Xilinx CoolRunner-II CPLD as a
Data Stream Switch
R
246 www.xilinx.com XAPP944 v1.0 June 14, 2006
MPEG-2 Multiplexer Design
R
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.
MPEG-2
Multiplexer
Design
Figure 1 shows the block diagram of the multiplexer system.
Figure 1: MPEG Multiplexer
Table 1: CoolRunner-II Package/I/O Matrix
XC2C32A XC2C64A XC2C128 XC2C256 XC2C384 XC2C512
I/O Banks 2 2 2 2 4 4
Packages and
User I/O
QFG32 (21)
VQ44 (33)
PC44 (33)
CP56 (33)
QFG48 (33)
VQ44 (33)
PC44 (37)
CP56 (45)
VQ100 (64) VQ100 (80)
CP132 (100)
TQ144 (100)
VQ100 (80)
CP132 (106)
TQ144 (118)
PQ208 (173)
FT256 (184)
TQ144 (118)
PQ208 (173)
FT256 (212)
FG324 (240)
PQ208 (173)
FT256 (212)
FG324 (270)
TS1_DATA,, TS1_CLK, TS1_VAL, TS1_SYNC
TS2_DATA,, TS2_CLK, TS2_VAL, TS2_SYNC
TS3_DATA,, TS3_CLK, TS3_VAL, TS3_SYNC
Select
3 bits
Enable
Output Transport Stream
XC2C64A CPLD
MPEG Multiplexer
Performance and Utilization
XAPP944 v1.0 June 14, 2006 www.xilinx.com 247
R
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
and Utilization
This is a simple design that only passes through a small amount of logic. Hence, if implemented
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.
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:
XAPP944 - http://www.xilinx.com/products/xaw/coolvhdlq.htm
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.
Revision
History
The following table shows the revision history for this document.

Table 2: Device Utilization
Macrocells
Used/Total
Product Terms
Used/Total
Function Block
Inputs
Used/Total
Registers
Used/Total
Pins
Used/Total
12/64 (19%) 35/224 (16%) 37/160 (23%) 0/64 (0%) 48/64 (75%)
Date Version Revision
06/14/06 1.0 Initial Xilinx release.
248 www.xilinx.com XAPP944 v1.0 June 14, 2006
Revision History
R
XAPP906 (v1.0) June 10, 2006 www.xilinx.com 249
© 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.
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.
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.
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.
Application Note: CoolRunner-II CPLD
XAPP906 (v1.0) June 10, 2006
Supporting Multiple SD Devices with
CoolRunner-II CPLDs
R
SD
Device
SD
Device
1.8V 3.3V
CoolRunner-II
CPLD
Host Controller
(ASIC or μP)
Select Lines
250 www.xilinx.com XAPP906 (v1.0) June 10, 2006
CPLD Design
R
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.
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,
SD Memory
Card (A)
SD Memory
Card (B)
Host
CLK
VDD
VSS
D0-3(A)
CMD(A)
CLK
VDD
VSS
D0-3, CMD
D0-3, CMD
D0-3(B)
CMD(B)
CLK
VDD
VSS
CPLD Design
XAPP906 (v1.0) June 10, 2006 www.xilinx.com 251
R
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.
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.
CMD
DAT1
DAT2
DAT3
DAT0
CMD
DAT1
DAT2
DAT3
DAT0
CMD
DAT1
DAT2
DAT3
DAT0
S
D
H
o
s
t
C
o
n
t
r
o
l
l
e
r
B
i
d
i
r
e
c
t
i
o
n
a
l
M
U
X
CMD
DAT AA 1
DAT AA 2
DAT AA 3
DAT AA 0
CMD
DAT AA 1
DAT AA 2
DAT AA 3
DAT AA 0
B
i
d
i
r
e
c
t
i
o
n
a
l
M
U
X
CoolRunner-II
SD Select 1
SD Select 2
SD Bus
SD Bus 1
SD Bus 2
SD 1
SD 2
CLK
CLK
CLK
252 www.xilinx.com XAPP906 (v1.0) June 10, 2006
Design Verification
R
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.
Figure 5: SD Multiplexer Circuit for Two SD Devices
Design
Verification
Simulation Results
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
Q D
R
A
D Q
R
D Q
R
B1
SD1
SEL
SD2
SEL
B2
SEL
SEL
Device Utilization
XAPP906 (v1.0) June 10, 2006 www.xilinx.com 253
R
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
Utilization
Table 3 shows device utilization statistics for various implementations. As stated in the SDA
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.
Voltage and
Current
Considerations
The SDA Specification contains stringent voltage and current requirements for SD cards.
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,
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
Download
The VHDL files to compile and simulate these designs are located at:
http://www.xilinx.com/products/xaw/coolvhdlq.htm
Table 3: Device Utilization Statistics for Various Implementations
Number of SD Expansion
Ports
Macrocell Utilization
(SPI or 1-Bit Data Mode)
Macrocell Utilization
(4-Bit Data Transfer Mode)
1 13 Macrocells 19 Macrocells
2 21 Macrocells 30 Macrocells
3 32 Macrocells 45 Macrocells
254 www.xilinx.com XAPP906 (v1.0) June 10, 2006
Conclusion
R
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.
Revision
History
The following table shows the revision history for this document.

Date Version Revision
06/10/06 1.0 Initial Xilinx release.
Digital Consumer Applications www.xilinx.com 255
June 26, 2006
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.
This Chapter contains the following topics:
• The Real Value of CoolRunner-II DataGATE
• Power Evaluation Equation for CoolRunner-II CPLDs
• Low Power Design with CoolRunner-II CPLDs
256 www.xilinx.com Digital Consumer Applications
June 26, 2006
Chapter 2
R
WP227 (v1.1) June 29, 2005 www.xilinx.com 257
© 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.

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.
White Paper: CoolRunner-II CPLDs
WP227 (v1.1) June 29, 2005
The Real Value of CoolRunner-II
DataGATE
By: Mark Ng
R
258 www.xilinx.com WP227 (v1.1) June 29, 2005
White Paper: The Real Value of CoolRunner-II DataGATE
R
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
V
CCINT
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.
V
CCINT
Current
Savings
The current savings on V
CCINT
are substantial, as shown in Table 1.
Table 1: Current Drawn on V
CCINT
from Switching Inputs with/without DataGATE at 50
MHz.
Current Drawn on V
CCINT
(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%
White Paper: The Real Value of CoolRunner-II DataGATE
WP227 (v1.1) June 29, 2005 www.xilinx.com 259
R
Figure 1, Figure 2, Figure 3, and Figure 4 graphically show how V
CCINT
current
savings increase versus input signal frequency.
Figure 1: V
CCINT
Current Savings, Single Input Switching
Figure 2: V
CCINT
Current Savings, Two Inputs Switching
1 Input Swi tchi ng: Vcci nt Current Savi ngs w/ Datagate
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
0 20 40 60
Frequency (MHz)
V
c
c
i
n
t

C
u
r
r
e
n
t


(
m
A
)
Iccint (Datagate)
Iccint (No Datagate)
97%
2 Inputs Swi tchi ng: Vcci nt Current Savi ngs w/ Datagate
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
0 20 40 60
Frequency (MHz)
I
c
c
i
n
t

(
m
A
)
Iccint (Datagate)
Iccint (No Datagate) 98%
260 www.xilinx.com WP227 (v1.1) June 29, 2005
White Paper: The Real Value of CoolRunner-II DataGATE
R
Figure 3: V
CCINT
Current Savings, Four Inputs Switching
Figure 4: V
CCINT
Current Savings, Eight Inputs Switching
What about
V
CCIO
Current?
At this point, we have established that a ‘Standby Current’ specification is relatively
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 V
CCINT
rail. What
about current drawn through V
CCIO
?
The entire industry avoids discussing current drawn through V
CCIO
. 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 I
CC
versus
Frequency graphs are specific to V
CCINT
current. No reference is ever made to V
CCIO
.
4 Inputs Swi tchi ng: Vcci nt Current Savi ngs w/ Datagate
0
0.5
1
1.5
2
2.5
3
3.5
0 20 40 60
Frequency (MHz)
I
c
c
i
n
t

(
m
A
)
Iccint (Datagate)
Iccint (No Datagate)
99%
8 Inputs Swi tchi ng: Vcci nt Current Savi ngs w/ Datagate
0
1
2
3
4
5
6
0 20 40 60
Frequency (MHz)
I
c
c
i
n
t

(
m
A
)
Iccint (Datagate)
Iccint (No Datagate)
99%
White Paper: The Real Value of CoolRunner-II DataGATE
WP227 (v1.1) June 29, 2005 www.xilinx.com 261
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 V
CCIO
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 V
CCINT
, let’s look at V
CCIO
. How much current does that draw, and, can DataGATE
do anything to reduce V
CCIO
current?
As can be seen in Table 2, this V
CCIO
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 V
CCIO
rail. Figure 5,
Figure 6, Figure 7, and Figure 8 show V
CCIO
current savings versus input switching
frequency.
Figure 5: V
CCIO
Current Savings, Single Input Switching
Table 2: Current Drawn on V
CCIO
from Switching Inputs with/without DataGATE at 50
MHz
Current Drawn on V
CCIO
(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%
1 Input Swi tchi ng: Vcci o Current Savi ngs w/ Datagate
0
1
2
3
4
5
6
7
8
9
10
0 20 40 60
Frequency (MHz
V
c
c
i
o

C
u
r
r
e
n
t

(
m
A
)
Iccio (Datagate)
Iccio (No Datagate)
99%
262 www.xilinx.com WP227 (v1.1) June 29, 2005
White Paper: The Real Value of CoolRunner-II DataGATE
R
Figure 6: V
CCIO
Current Savings, Two Inputs Switching
Figure 7: V
CCIO
Current Savings, Four Inputs Switching
2 Inputs Swi tchi ng: Vcci o Current Savi ngs w/ Datagate
0
2
4
6
8
10
12
14
16
0 20 40 60
Frequency (MHz)
V
c
c
i
o

C
u
r
r
e
n
t

(
m
A
)
Iccio (Datagate)
Iccio (No Datagate) 99%
4 Inputs Swi tchi ng: Vcci o Current Savi ngs w/ Datagate
0
5
10
15
20
25
30
0 20 40 60
Frequency (MHz)
V
c
c
i
o

C
u
r
r
e
n
t

(
m
A
)
Iccio (Datagate)
Iccio (No Datagate)
99%
White Paper: The Real Value of CoolRunner-II DataGATE
WP227 (v1.1) June 29, 2005 www.xilinx.com 263
R
Figure 8: V
CCIO
Current Savings, Eight Inputs Switching
We have already demonstrated one of the greatest kept secrets in the CPLD world --
although V
CCINT
dynamic current can be quite low, V
CCIO
current can exceed V
CCINT

current by as much as 4x! It is no wonder that manufacturers do not specify V
CCIO

current. Instead, they focus on what appears to be an extremely low standby current,
which is basically useless. They focus on dynamic V
CCINT
current, which is
substantially less than V
CCIO
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 V
CCINT
and 99%
power savings on V
CCIO
.
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.
8 Inputs Swi tchi ng: Vcci o Current Savi ngs w/ Datagate
0
5
10
15
20
25
30
35
40
0 5 10 15 20 25
Frequency (MHz)
V
c
c
i
o

C
u
r
r
e
n
t

(
m
A
)
Iccio (Datagate)
Iccio (No Datagate) 99%
264 www.xilinx.com WP227 (v1.1) June 29, 2005
White Paper: The Real Value of CoolRunner-II DataGATE
R
Additional
Resources
Xilinx has invested considerable time in developing the best ways to reduce power in
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 I
CC
). 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.
Revision
History
The following table shows the revision history for this document.
Date Version Revision
05/30/05 1.0 Initial Xilinx release.
06/29/05 1.1 Web Publication
XAPP317 (v1.0) September 23, 2003 www.xilinx.com 265
1-800-255-7778
© 2003 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.
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 I
CCSB
.
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
Application Note: CoolRunner-II CPLD
XAPP317 (v1.0) September 23, 2003
Power Evaluation Equation for
CoolRunner-II CPLDs
R
266 www.xilinx.com XAPP317 (v1.0) September 23, 2003
1-800-255-7778
Derivation
R
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.
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:
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.
Figure 1: Non-Inverting Buffer
X317_01_092203
Transition
Discharge
Charge
I C V f ⋅ ⋅ =
The Equation
XAPP317 (v1.0) September 23, 2003 www.xilinx.com 267
1-800-255-7778
R
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, C
L
.
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.
where:
I
CC
= total device current, in mA
I
CCSB
= 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
f
MC
= maximum clock frequency of non-I/O macrocells, in MHz
f
IO
= maximum clock frequency of I/O macrocells, in MHz
MC
TOG
= average non-I/O macrocell toggle rate, usually 12.5% (as a fraction, e.g. 0.125)
IO
TOG
= average I/O macrocell toggle rate, usually 12.5% (as a fraction, e.g. 0.125)
V
CCIO
= I/O power supply voltage, in V
I
CC
I
CCSB
MC
TOG
f
MC
MC A IO
TOG
f
IO
IO B V
CCIO
C
L
V
L

1000
-------------------- + ⋅
⎝ ⎠
⎛ ⎞
⋅ ⋅ ⋅ + ⋅ ⋅ ⋅ + =
268 www.xilinx.com XAPP317 (v1.0) September 23, 2003
1-800-255-7778
Conclusion
R
V
L
= external load voltage, in V, usually the same as V
CCIO
C
L
= external load capacitance, in pF
A = core capacitive coefficient, as given in Table 1
B = I/O capacitive coefficient, as given in Table 1
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:
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 V
CCIO
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.
Table 1: Power Equation Coefficients for CoolRunner-II CPLDs
Device I
CCSB
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
P V
CC
I
CCSB
MC
TOG
f
MC
MC A ⋅ ⋅ ⋅ + ( ) ⋅ IO
TOG
f
IO
IO B V
CCIO
2
C
L
V
L
2

1000
-------------------- + ⋅



⋅ ⋅ ⋅ + =
Revision History
XAPP317 (v1.0) September 23, 2003 www.xilinx.com 269
1-800-255-7778
R
Revision
History
The following table shows the revision history for this document.
Date Version Revision
09/23/03 1.0 Initial Xilinx release.
270 www.xilinx.com XAPP317 (v1.0) September 23, 2003
1-800-255-7778
Revision History
R
XAPP377 (v1.0) May 8, 2002 www.xilinx.com 271
1-800-255-7778
© 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 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.
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
Features
New architectural features have been added to the CoolRunner-II product line to enhance the
power saving capabilities of the FZP technology. This section describes these features and
how they can be used to save power.
Application Note: CoolRunner-II CPLD
XAPP377 (v1.0) May 8, 2002
Low Power Design with CoolRunner-II
CPLDs
R
272 www.xilinx.com XAPP377 (v1.0) May 8, 2002
1-800-255-7778
Low Power Design with CoolRunner-II CPLDs
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.
Low Power Design with CoolRunner-II CPLDs
XAPP377 (v1.0) May 8, 2002 www.xilinx.com 273
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.
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.
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
Figure 1: Clock Division Circuitry for GCK2
Figure 2: Macrocell Clock Chain with DualEDGE Option Shown
X377_01_041102
Clock
In
¸2
¸4
¸6
¸8
¸10
¸12
¸14
¸16
GCK2
CDRST
Synch Rst
GCK0
GCK1
GCK2
CTC
PTC
PTC
x377_02_041102
D/T
CE
CK

FIF
Latch
DualEDGE
Q
274 www.xilinx.com XAPP377 (v1.0) May 8, 2002
1-800-255-7778
Low Power Design with CoolRunner-II CPLDs
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
Low Power Design with CoolRunner-II CPLDs
XAPP377 (v1.0) May 8, 2002 www.xilinx.com 275
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.
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
Figure 3: CoolCLOCK Created by Cascading Clock Divider and DualEDGE Option
GCK0
GCK1
GCK2
CTC
PTC
PTC
X377_03_041102
D/T
CE
CK
FIF
Latch
DualEDGE
Q
Clock
In
÷2
÷4
÷6
÷8
÷10
÷12
÷14
÷16
GCK2
Synch Reset
Synch Rst

276 www.xilinx.com XAPP377 (v1.0) May 8, 2002
1-800-255-7778
Low Power Design with CoolRunner-II CPLDs
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
Techniques
Several rules of thumb should be followed when designing any circuit with CMOS devices to
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:
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:
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:
I C
t d
dV
⋅ =
I C V d
1
t d
----
⋅ ⋅ =
I C V d f ⋅ ⋅ =
V d V
2
V
1
– =
V d V 0 – =
Low Power Design with CoolRunner-II CPLDs
XAPP377 (v1.0) May 8, 2002 www.xilinx.com 277
1-800-255-7778
R
Therefore the current equation for each capacitive structure becomes:
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:
To obtain total device current, static current must be added to the dynamic current:
For illustrational purposes, it may be easier to discuss total current using a simplified version of
this equation:
where:
• I
CC
= total device current in Amperes
• I
CCQ
= 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.
V d V =
I C V f ⋅ ⋅ =
I
Dynamic
V C
i
i 1 =
n

f
i
⋅ ⋅ =
I
Total
I
Static
V + C
i
i 1 =
n

f
i
⋅ ⋅ =
I
CC
I
CCQ
C + V f ⋅ ⋅ =
278 www.xilinx.com XAPP377 (v1.0) May 8, 2002
1-800-255-7778
Low Power Design with CoolRunner-II CPLDs
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., V
IH
and V
IL
, 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 I
2
C 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.
Low Power Design with CoolRunner-II CPLDs
XAPP377 (v1.0) May 8, 2002 www.xilinx.com 279
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:
where:
• Length = maximum line length in inches
• T
rise
= 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.
Length
1
6
---
T
rise
LC
------------ ⋅ «
280 www.xilinx.com XAPP377 (v1.0) May 8, 2002
1-800-255-7778
Low Power Design with CoolRunner-II CPLDs
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
Revision
History
The following table shows the revision history for this document.
Date Version Revision
05/08/02 1.0 Initial Xilinx release.
Programmable Logic Design www.xilinx.com 281
June 26, 2006
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.
282 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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.
Programmable Logic Design www.xilinx.com 283
June 26, 2006
HDL Design Process
R
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.
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
Design Flow
STAT_M AC
Count er
amber_l i ght
green_l i ght
cl ock
reset
red_l i ght
CLK
RESET
TIM E (3.0)
AUG
CLOCK
RESET
COUNT (3.0)
GRN
RG
Design Schematic
101010101001110101010101
010101011110001110100111
101010101001110101010101
010101011110001110100111
101010101001110101010101
010101011110001110100111
101010101001110101010101
010101011110001110100111
Design Netlist
Specification
Libraries
Netlist
Schematic
Capture
284 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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.
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;
Desigh Flow
Desigh SchemaIics
ehIiIy MUL1 is
porI (A, 8: ih sId_logic(15 dowhIo 0),
Y: ouI sId_logic(31 dowhIo 0)),
ehd MUL1,
archiIecIure 8LHAVL o! MUL1 is
begih
Y <= A * 8,
ehd 8LHAVL,

Desigh WriIIeh ih HDL
OR
Speci!icaIioh
Libraries
NeIlisI
SchemaIic
CapIure
Programmable Logic Design www.xilinx.com 285
June 26, 2006
HDL Design Process
R
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
286 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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
Programmable Logic Design www.xilinx.com 287
June 26, 2006
HDL Design Process
R
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.
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
Specification
Verification
System Debug
Libraries
Netlist
HDL
Test
Vectors
Synthesis
Simulation
Translate
Device
Printed
Circuit Board
Timing Analyzer
Back-Annotation
Schematic
Capture
Implementation
Download
Program
Fitting
Place & Route
288 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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
Programmable Logic Design www.xilinx.com 289
June 26, 2006
HDL Design Process
R
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.
290 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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.
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:
ISP – In System Programming and Downloading
Conventional Programming
Programmer
Download
Cable
Target Device
on PCB
Verification
Libraries
Netlist
HDL
Test
Vectors
Synthesis
Simulation
Translate
Device
Timing Analyzer
Back-Annotation
Schematic
Capture
Implementation
Download
Program
Fitting
Place & Route
Target
Device
Programmable Logic Design www.xilinx.com 291
June 26, 2006
Advanced Design Techniques
R
• 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.
292 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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.
Programmable Logic Design www.xilinx.com 293
June 26, 2006
ISE WebPACK Software
R
This chapter explains what is available in ISE WebPACK and gives details on how to go
about registering and installing the software.
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.
Table 3-1: WebPACK Operating System and Device Support
Feature ISE WebPACK
Operating Systems
Microsoft Windows 2000/XP
Redhat Enterprise Linux 3 (32-bit)
Virtex Series
Virtex: XCV50 - XCV600
Virtex-E: XCV50E - XCV600E
Virtex-II: XC2V40 - XC2V500
Virtex-II Pro: XC2VP2 - XC2VP7
Virtex-4:
LX: XC4VLX15, XC4VLX25
SX: XC4VSX25
FX: XC4VFX12
Virtex Q: XQV100 - XVQ600
Virtex QR: XQVR300 - XVQR600
Virtex-EQ: XQV600E
Spartan Series
Spartan-II/IIE: All
Spartan-3: XC3S50 - XC3S1500
Spartan-3E: All
Spartan-3L: XC3S1000L, XC3S1500L
XA (Xilinx Automotive) Spartan-3: All
CoolRunner-II/A
CoolRunner XPLA3
All
XC9500/XL/XV All
294 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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
Programmable Logic Design www.xilinx.com 295
June 26, 2006
ISE WebPACK Software
R
The flow diagram below shows the similarities and differences between CPLD and FPGA
software flows.
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.
CPLD FPGA
Synthesis
Xilinx Synthesis Technology (XST)
Translate
NGDBuild
Testbench
HDL Bencher
Simulate
ModelSim XE
Estimate Power
XPower
Program
IMPACT Programmer
Schematic
ECS
HDL Design
Entry
HDL Editor
State Machine
StateCad
Implement
MAP/PAR
Fit
CPLD Fitter
296 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 3: Xilinx Design Software
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.
Programmable Logic Design www.xilinx.com 297
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:
298 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
5. Click the Next> button.
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
8. Click the Next> button.
Programmable Logic Design www.xilinx.com 299
June 26, 2006
Design Entry
R
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
300 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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.
Programmable Logic Design www.xilinx.com 301
June 26, 2006
Design Entry
R
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
302 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 303
June 26, 2006
Functional Simulation
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.
Functional Simulation
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.”
Figure 4-8: New Source Window
3. Click the Next> button.
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
304 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 305
June 26, 2006
Functional Simulation
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
306 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 307
June 26, 2006
State Machine Editor
R
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.
State Machine Editor
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”
308 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
R
3. Click the Next> button, then the Finish button.
Figure 4-16: New Source Window
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
Programmable Logic Design www.xilinx.com 309
June 26, 2006
State Machine Editor
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
310 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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.”
Programmable Logic Design www.xilinx.com 311
June 26, 2006
State Machine Editor
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
312 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 313
June 26, 2006
Top-Level VHDL Designs
R
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
Top-Level VHDL Designs
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:
314 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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: Defi ne VHDL Source Window
Programmable Logic Design www.xilinx.com 315
June 26, 2006
Top-Level VHDL Designs
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.”
316 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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);
Programmable Logic Design www.xilinx.com 317
June 26, 2006
Top-Level VHDL Designs
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
318 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 319
June 26, 2006
Simulate the Design
R
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.
320 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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:
Programmable Logic Design www.xilinx.com 321
June 26, 2006
Top-Level Schematic Designs
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 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.
Top-Level Schematic Designs
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
322 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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.
Programmable Logic Design www.xilinx.com 323
June 26, 2006
Top-Level Schematic Designs
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.
324 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 325
June 26, 2006
Top-Level Schematic Designs
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.
326 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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
Programmable Logic Design www.xilinx.com 327
June 26, 2006
Top-Level Schematic Designs
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.
328 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
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:
Programmable Logic Design www.xilinx.com 329
June 26, 2006
Top-Level Schematic Designs
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
330 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 4: WebPACK ISE Design Entry
R
The Simulation will appear as follows:
Figure 4-55: Simulation Window
You are now ready to go to the implementation stage.
Programmable Logic Design www.xilinx.com 331
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
332 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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
Programmable Logic Design www.xilinx.com 333
June 26, 2006
Constraints Editor
R
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
334 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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
Programmable Logic Design www.xilinx.com 335
June 26, 2006
Constraints Editor
R
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.
336 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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
Programmable Logic Design www.xilinx.com 337
June 26, 2006
Constraints Editor
R
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.
338 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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
Programmable Logic Design www.xilinx.com 339
June 26, 2006
Constraints Editor
R
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;
340 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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
Programmable Logic Design www.xilinx.com 341
June 26, 2006
CPLD Reports
R
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.
342 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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
Programmable Logic Design www.xilinx.com 343
June 26, 2006
Timing Simulation
R
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
344 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
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.
Programmable Logic Design www.xilinx.com 345
June 26, 2006
Design Challenge
R
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!
346 www.xilinx.com Programmable Logic Design
June 26, 2006
Chapter 5: Implementing CPLD Designs
R
Digital Consumer Applications www.xilinx.com 347
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.
This Chapter contains the following topics:
• The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
• TTL “Burn Rate” for Xilinx CPLDs
348 www.xilinx.com Digital Consumer Applications
June 26, 2006
Chapter 3
R
WP202 (v1.3) January 10, 2005 www.xilinx.com 349
1-800-255-7778
© 2003 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.

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
White Paper: CPLD
WP202 (v1.3) January 10, 2005
The Advantages of Migrating
from Discrete 7400 Logic Devices
to CPLDs
R
350 www.xilinx.com WP202 (v1.3) January 10, 2005
1-800-255-7778
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
R
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
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
WP202 (v1.3) January 10, 2005 www.xilinx.com 351
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.
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.
Figure 1: Basic Semiconductor Cost Model
Figure 2: Die Cost As a Function of Die Size
WP202_01_110403
$3000/wafer
3000 devices/wafer
$1/device
WP202_02_110403
Die Size vs. Cost
Die Size
Die cost as a function of die size
C
o
s
t
352 www.xilinx.com WP202 (v1.3) January 10, 2005
1-800-255-7778
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
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.
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
Clear Discrete
Logic
Replacement
Choice
When the 7400 series was first introduced, there was a significant premium to be paid
for integration. In 1963, the average price for a single 7400 device was $1000 (in 1963
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
circuit would eventually be cheaper than the same circuit constructed from discrete
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
Figure 3: IC Total Product Cost
WP202_03_110403
Total product cost = die cost + test cost + package cost
1985 CPLD Total Product Cost
0%
20%
40%
60%
80%
100%
P
e
r
c
e
n
t

o
f

T
o
t
a
l

C
o
s
t
Package Cost
Test Cost
Die Cost
I
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
WP202 (v1.3) January 10, 2005 www.xilinx.com 353
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.
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.
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
Figure 4: 7400 vs. CPLD Device Cost Comparison
Figure 5: Basic Discrete 7400 vs. CPLD Comparison
WP202_04_110403
Package Cost
Test Cost
Die Cost
CPLD
Equivalent to > 8
Discrete TTL
Discrete
2004
8
WP202_05_110403 Cost comparison: 7400 discrete pricing versus CPLDs
Device Cost Comparison 7400 vs. CPLD
Number of Discrete Devices
T
o
t
a
l

D
e
v
i
c
e

C
o
s
t
7400 Cost
CoolRunner Cost
34 31 28 25 22 19 16 13 10 7 4 1
354 www.xilinx.com WP202 (v1.3) January 10, 2005
1-800-255-7778
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
R
• Design security capabilities
Discrete Logic
versus CPLD
Devices
Closing the Cost/Performance Gap
To support the premise that CPLDs provide a lower total cost alternative, in this
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.
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.
Figure 6: Sample Circuit for Cost Analysis
D e vi c e N u m b e r M c e l l s T o ta l
74 0 0 1 4 4
7 41 6 3 4 4 16
7 41 4 7 1 4 4
7 43 7 3 1 8 8
G ra n d T o ta l 32
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
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
WP202 (v1.3) January 10, 2005 www.xilinx.com 355
1-800-255-7778
R
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.
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.
Table 1: Production Cost Comparison (Continued)
Discrete Circuit Xilinx CPLD, XC2C32
Cost/Packaging DIP SMT VQ44
Table 2: Board Area Comparison
Discrete Circuit Xilinx CPLD
Function/Pkg DIP SMT VQ44
Component area (in
2
) 1.298 0.760 0.150
PCB area (in
2
) consumed
by components
(1)
1.6874 0.988 0.195
Cost of board area
(2)
1.6874 in
2
x $0.40/ in
2
=
$0.67
0.988 in
2
x $0.42/ in
2
=
$0.41
0.195 in
2
x $0.24/ in
2
=
$0.05
Cost/layer differential
($0.75 per layer)
4 layers x $0.75 = $3.00
total
4 layers x $0.75 = $3.00
total
2 layers x $0.75 = $1.50
total
356 www.xilinx.com WP202 (v1.3) January 10, 2005
1-800-255-7778
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
R
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.
Power consumption
(Quiescent vs. Active)
150mW 1750mW 150mW 1750mW .029 mW 1.6 mW
Total cost of power usage
(@ $0.40/watt)
(3)
$0.06 $0.07 $0.06 $0.07 $1.16x10
-5
$6.4x10
-4
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.
Table 2: Board Area Comparison (Continued)
Discrete Circuit Xilinx CPLD
Function/Pkg DIP SMT VQ44
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
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
WP202 (v1.3) January 10, 2005 www.xilinx.com 357
1-800-255-7778
R
Time-to-Market
Benefits
The proliferation of electronic wireless, industrial and communication devices, as well
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.
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:
The Real
Advantage
While time to market is a major benefit, the ability to program and reprogram devices
as designs change is equally important. Unlike CPLDs, once a PCB using discrete TTL
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
Figure 7: Xilinx CPLD Time-to-Market Benefits
WP202_07_110403
Product Availability
Reduced profit
for late comers
Profit for first
to market
Time-to-market
358 www.xilinx.com WP202 (v1.3) January 10, 2005
1-800-255-7778
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
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
Interference
Electromagnetic interference (EMI) refers to any type of interference that can
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,
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
WP202 (v1.3) January 10, 2005 www.xilinx.com 359
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
Issues
Given the explosion of new applications in the competitive electronics market, the
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
Advantages
The Xilinx CoolRunner-II CPLD family utilizes second-generation RealDigital™
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.
360 www.xilinx.com WP202 (v1.3) January 10, 2005
1-800-255-7778
White Paper: The Advantages of Migrating from Discrete 7400 Logic Devices to CPLDs
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
Information
For information on how much 7400 logic can be placed on a Xilinx CPLD, see White
Paper 214, TTL "Burn Rate" for Xilinx CPLDs.
Revision
History
The following table shows the revision history for this document.
Date Version Revision
11/14/03 1.0 Initial Xilinx release.
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.
WP214 (v1.0) January 10, 2005 www.xilinx.com 361
1-800-255-7778
© 2004 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.

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.
White Paper: CoolRunner-II CPLDs
WP214 (v1.0) January 10, 2005
TTL “Burn Rate” for Xilinx
CPLDs
By: Jesse Jenkins
R
362 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
R
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
White Paper: TTL “Burn Rate” for Xilinx CPLDs
WP214 (v1.0) January 10, 2005 www.xilinx.com 363
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
364 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
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
White Paper: TTL “Burn Rate” for Xilinx CPLDs
WP214 (v1.0) January 10, 2005 www.xilinx.com 365
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
366 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
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
White Paper: TTL “Burn Rate” for Xilinx CPLDs
WP214 (v1.0) January 10, 2005 www.xilinx.com 367
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
368 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
R
Figure 7: Taking the SOP Up to 18 P-terms
Macrocell Logic
With 18
Product Terms
Macrocell Logic
With 2
Product Terms
Product Term
Allocator
Product Term
Allocator
Product Term
Allocator
Product Term
Allocator
Skipped Macrocell
White Paper: TTL “Burn Rate” for Xilinx CPLDs
WP214 (v1.0) January 10, 2005 www.xilinx.com 369
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
370 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
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
White Paper: TTL “Burn Rate” for Xilinx CPLDs
WP214 (v1.0) January 10, 2005 www.xilinx.com 371
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
372 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
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.
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
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
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
White Paper: TTL “Burn Rate” for Xilinx CPLDs
WP214 (v1.0) January 10, 2005 www.xilinx.com 373
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.
Additional
Information
CoolRunner-II Data Sheets and Application Notes
XC9500XL Data Sheets and Application Notes
Online Store
Revision
History
The following table shows the revision history for this document.
Date Version Revision
01/10/05 1.0 Initial Xilinx release.
374 www.xilinx.com WP214 (v1.0) January 10, 2005
1-800-255-7778
White Paper: TTL “Burn Rate” for Xilinx CPLDs
R
Digital Consumer Applications www.xilinx.com 375
June 26, 2006
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.
376 www.xilinx.com Digital Consumer Applications
June 26, 2006
Xilinx CPLD Data Sheets
R
DS090 (v2.7) June 21, 2006 www.xilinx.com 377
Product Specification
© 2006 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.
Features
• Optimized for 1.8V systems
- Industry’s fastest low power CPLD
- Densities from 32 to 512 macrocells
• Industry’s best 0.18 micron CMOS CPLD
- Optimized architecture for effective logic synthesis
- Multi-voltage I/O operation — 1.5V to 3.3V
• Advanced system features
- Fastest in system programming
· 1.8V ISP using IEEE 1532 (JTAG) interface
- On-The-Fly Reconfiguration (OTF)
- IEEE1149.1 JTAG Boundary Scan Test
- Optional Schmitt trigger input (per pin)
- Multiple I/O banks on all devices
- Unsurpassed low power management
· DataGATE external signal control
- Flexible clocking modes
· Optional DualEDGE triggered registers
· Clock divider (÷ 2,4,6,8,10,12,14,16)
· CoolCLOCK
- Global signal options with macrocell control
· Multiple global clocks with phase selection per
macrocell
· Multiple global output enables
· Global set/reset
- Abundant product term clocks, output enables and
set/resets
- Efficient control term clocks, output enables and
set/resets for each macrocell and shared across
function blocks
- Advanced design security
- Open-drain output option for Wired-OR and LED
drive
- Optional bus-hold, 3-state or weak pullup on select
I/O pins
- Optional configurable grounds on unused I/Os
- Mixed I/O voltages compatible with 1.5V, 1.8V,
2.5V, and 3.3V logic levels on all parts
- SSTL2_1,SSTL3_1, and HSTL_1 on 128
macrocell and denser devices
- Hot pluggable
• PLA architecture
- Superior pinout retention
- 100% product term routability across function block
• Wide package availability including fine pitch:
- Chip Scale Package (CSP) BGA, Fine Line BGA,
TQFP, PQFP, VQFP, PLCC, and QFN packages
- Pb-free available for all packages
• Design entry/verification using Xilinx and industry
standard CAE tools
• Free software support for all densities using Xilinx
WebPACK™
• Industry leading nonvolatile 0.18 micron CMOS
process
- Guaranteed 1,000 program/erase cycles
- Guaranteed 20 year data retention
Family Overview
Xilinx CoolRunner™-II CPLDs deliver the high speed and
ease of use associated with the XC9500/XL/XV CPLD fam-
ily with the extremely low power versatility of the XPLA3™
family in a single CPLD. This means that the exact same
parts can be used for high-speed data communications/
computing systems and leading edge portable products,
with the added benefit of In System Programming. Low
power consumption and high-speed operation are com-
bined into a single family that is easy to use and cost effec-
tive. Clocking techniques and other power saving features
extend the users’ power budget. The design features are
supported starting with Xilinx ISE 4.1i ISE WebPACK. Addi-
tional details can be found in Further Reading, page 390.
Table 1 shows the macrocell capacity and key timing
parameters for the CoolRunner-II CPLD family.
0
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006
0 0
Product Specification
R
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
T
PD
(ns) 3.8 4.6 5.7 5.7 7.1 7.1
T
SU
(ns) 1.9 2.0 2.4 2.4 2.9 2.6
T
CO
(ns) 3.7 3.9 4.2 4.5 5.8 5.8
F
SYSTEM1
(MHz) 323 263 244 256 217 179
CoolRunner-II CPLD Family
378 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
Table 2 shows key DC characteristics for the CoolRunner-II
family.
Table 3 shows the CoolRunner-II CPLD package offering
with corresponding I/O count. All packages are surface
mount, with over half of them being ball-grid technologies.
The ultra tiny packages permit maximum functional capacity
in the smallest possible area. The CMOS technology used
in CoolRunner-II CPLDs generates minimal heat, allowing
the use of tiny packages during high-speed operation.
With the exception of the new Pb-free QF packages, there
are at least two densities present in each package with
three in the VQ100 (100-pin 1.0mm QFP) and TQ144
(144-pin 1.4mm QFP), and in the FT256 (256-ball 1.0mm
spacing FLBGA). The FT256 is particularly important for
slim dimensioned portable products with mid- to high-den-
sity logic requirements.
Table 4 details the distribution of advanced features across
the CoolRunner-II CPLD family. The family has uniform
basic features with advanced features included in densities
where they are most useful. For example, it is very unlikely
that four I/O banks are needed on 32 and 64 macrocell
parts, but very likely they are for 384 and 512 macrocell
parts. The I/O banks are groupings of I/O pins using any
one of a subset of compatible voltage standards that share
Table 2: CoolRunner-II CPLD DC Characteristics
XC2C32A XC2C64A XC2C128 XC2C256 XC2C384 XC2C512
I
CC
(μA), 0 MHz, 25°C (typical) 16 17 19 21 23 25
I
CC
(mA), 50 MHz, 70°C (max) 2.5 5 10 27 45 55
I
CC
is dynamic current.
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.
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 379
Product Specification
R
the same V
CCIO
level. (See Table 5 for a summary of
CoolRunner-II I/O standards.)
Architecture Description
CoolRunner-II CPLD is a highly uniform family of fast, low
power CPLDs. The underlying architecture is a traditional
CPLD architecture combining macrocells into Function
Blocks (FBs) interconnected with a global routing matrix,
the Xilinx Advanced Interconnect Matrix (AIM). The Func-
tion Blocks use a Programmable Logic Array (PLA) configu-
ration which allows all product terms to be routed and
shared among any of the macrocells of the FB. Design soft-
ware can efficiently synthesize and optimize logic that is
subsequently fit to the FBs and connected with the ability to
utilize a very high percentage of device resources. Design
changes are easily and automatically managed by the soft-
ware, which exploits the 100% routability of the Programma-
ble Logic Array within each FB. This extremely robust
building block delivers the industry’s highest pinout reten-
tion, under very broad design conditions. The architecture
will be explained by expanding the detail as we discuss the
underlying Function Blocks, logic and interconnect.
The design software automatically manages these device
resources so that users can express their designs using
completely generic constructs without knowledge of these
architectural details. More advanced users can take advan-
tage of these details to more thoroughly understand the
software’s choices and direct its results.
Figure 1 shows the high-level architecture whereby Func-
tion Blocks attach to pins and interconnect to each other
within the internal interconnect matrix. Each FB contains 16
macrocells. The BSC path is the JTAG Boundary Scan Con-
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.
CoolRunner-II CPLD Family
380 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
trol path. The BSC and ISP block has the JTAG controller
and In-System Programming Circuits.
Function Block
The CoolRunner-II CPLD Function Blocks contain 16 mac-
rocells, with 40 entry sites for signals to arrive for logic cre-
ation and connection. The internal logic engine is a 56
product term PLA. All Function Blocks, regardless of the
number contained in the device, are identical. For a
high-level view of the Function Block, see Figure 2.
At the high level, it is seen that the product terms (p-terms)
reside in a programmable logic array (PLA). This structure is
extremely flexible, and very robust when compared to fixed
or cascaded product term function blocks.
Classic CPLDs typically have a few product terms available
for a high-speed path to a given macrocell. They rely on
capturing unused p-terms from neighboring macrocells to
expand their product term tally, when needed. The result of
this architecture is a variable timing model and the possibil-
ity of stranding unusable logic within the FB.
The PLA is different — and better. First, any product term
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
OR functions so that within a FB, a particular logical product
need only be created once, but can be re-used up to 16
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
macrocell functions to be adjacent or any other restriction
save residing in the same FB, which is handled by the soft-
ware. Functions need not share a common clock, common
set/reset or common output enable to take full advantage of
the PLA. Also, every product term arrives with the same
time delay incurred. There are no cascade time adders for
putting more product terms in the FB. When the FB product
term budget is reached, there is a small interconnect timing
penalty to route signals to another FB to continue creating
logic. Xilinx design software handles all this automatically.
Figure 1: CoolRunner-II CPLD Architecture
Function
Block 1
Function
Block n
PLA PLA
I
/
O

B
l
o
c
k
s
I
/
O

B
l
o
c
k
s
16 16
40 40
16 FB 16 FB
16 16
I/O Pin MC1
MC2
MC16
MC1
MC2
MC16
DS090_01_121201
AIM
I/O Pin
I/O Pin
Direct Inputs
BSC and ISP
Clock and Control Signals
BSC Path
Direct Inputs
I/O Pin
I/O Pin
I/O Pin
JTAG
Figure 2: CoolRunner-II CPLD Function Block
PLA
16
40
3
MC1
Out
To AIM
Global
Clocks
Global
Set/Reset
MC2
MC16
DS090_02_101001
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 381
Product Specification
R
Macrocell
The CoolRunner-II CPLD macrocell is extremely efficient
and streamlined for logic creation. Users can develop sum
of product (SOP) logic expressions that comprise up to 40
inputs and span 56 product terms within a single function
block. The macrocell can further combine the SOP expres-
sion into an XOR gate with another single p-term expres-
sion. The resulting logic expression’s polarity is also
selectable. As well, the logic function can be pure combina-
torial or registered, with the storage element operating
selectably as a D or T flip-flop, or transparent latch. Avail-
able at each macrocell are independent selections of global,
function block level or local p-term derived clocks, sets,
resets, and output enables. Each macrocell flip-flop is con-
figurable for either single edge or DualEDGE clocking, pro-
viding either double data rate capability or the ability to
distribute a slower clock (thereby saving power). For single
edge clocking or latching, either clock polarity may be
selected per macrocell. CoolRunner-II macrocell details are
shown in Figure 3. Note that in Figure 4, standard logic
symbols are used except the trapezoidal multiplexers have
input selection from statically programmed configuration
select lines (not shown). Xilinx application note XAPP376
gives a detailed explanation of how logic is created in the
CoolRunner-II CPLD family.
When configured as a D-type flip-flop, each macrocell has
an optional clock enable signal permitting state hold while a
clock runs freely. Note that Control Terms (CT) are available
to be shared for key functions within the FB, and are gener-
ally used whenever the exact same logic function would be
repeatedly created at multiple macrocells. The CT product
terms are available for FB clocking (CTC), FB asynchro-
nous set (CTS), FB asynchronous reset (CTR), and FB out-
put enable (CTE).
Any macrocell flip-flop can be configured as an input regis-
ter or latch, which takes in the signal from the macrocell’s
I/O pin, and directly drives the AIM. The macrocell combina-
tional functionality is retained for use as a buried logic node
if needed. F
Toggle
is the maximum clock frequency to which
a T flip-flop can reliably toggle.
Advanced Interconnect Matrix (AIM)
The Advanced Interconnect Matrix is a highly connected
low power rapid switch. The AIM is directed by the software
to deliver up to a set of 40 signals to each FB for the cre-
ation of logic. Results from all FB macrocells, as well as, all
pin inputs circulate back through the AIM for additional con-
nection available to all other FBs as dictated by the design
Figure 3: CoolRunner-II CPLD Macrocell
GCK0
GCK1
GCK2
CTC
PTC
PTC
DS090_03_121201
49 P-terms
To PTA, PTB, PTC of
other macrocells
CTC, CTR,
CTS, CTE
From AIM
4 P-terms
PTA
Direct Input
from
I/O Block
Feedback
to AIM
PTB
PTC
PLA OR Term
PTA
CTS
GSR
GND
GND
V
CC
R
D/T
CE
CK
FIF
Latch
DualEDGE
Q
S
40
To I/O Block
PTA
CTR
GSR
GND
CoolRunner-II CPLD Family
382 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
software. The AIM minimizes both propagation delay and
power as it makes attachments to the various FBs.
I/O Block
I/O blocks are primarily transceivers. However, each I/O is
either automatically compliant with standard voltage ranges
or can be programmed to become so. See XAPP382 for
detailed information on CoolRunner-II I/Os.
In addition to voltage levels, each input can selectively
arrive through Schmitt-trigger inputs. This adds a small time
delay, but substantially reduces noise on that input pin.
Approximately 500 mV of hysteresis will be added when
Schmitt-trigger inputs are selected. All LVCMOS inputs can
have hysteresis input. Hysteresis also allows easy genera-
tion of external clock circuits. The Schmitt-trigger path is
best seen in Figure 4. See Table 5 for Schmitt-trigger com-
patibility with I/O standards.
Outputs can be directly driven, 3-stated or open-drain con-
figured. A choice of slow or fast slew rate output signal is
also available. Table 5 summarizes various supported volt-
age standards associated with specific part capacities. All
inputs and disabled outputs are voltage tolerant up to 3.3V.
The CoolRunner-II family supports SSTL2-1, SSTL3-1 and
HSTL-1 high-speed I/O standards in the 128-macrocell and
larger devices. Figure 4 details the I/O pin, where it is noted
that the inputs requiring comparison to an external refer-
ence voltage are available. These I/O standards all require
VREF pins for proper operation. The CoolRunner-II CPLD
allows any I/O pin to act as a VREF pin, granting the board
layout engineer extra freedom when laying out the
pins.However, if VREF pin placement is not done properly,
additional VREF pins may be required, resulting in a loss of
potential I/O pins or board re-work. See XAPP399 for
details regarding VREF pins and their placement.
V
REF
has pin-range requirements that must be observed.
The Xilinx software aids designers in remaining within the
proper pin range.
Table 5 summarizes the single ended I/O standard support
and shows which standards require V
REF
values and board
termination. V
REF
detail is given in specific data sheets.
Figure 4: CoolRunner-II CPLD I/O Block Diagram
Enabled
To Macrocell
Direct Input
To AIM
4
CTE
PTB
GTS[0:3]
CGND
Open Drain From Macrocell
V
CCIO
V
REF
Disabled
Hysteresis
Available on 128 Macrocell Devices and Larger
Global termination
Pullup/Bus-Hold
DS090_04_121201
Table 5: CoolRunner-II CPLD I/O Standard Summary
IOSTANDARD
Attribute V
CCIO
Input V
REF
Board Termination Voltage
(V
TT
) Schmitt-trigger Support
LVTTL 3.3 N/A N/A Optional
LVCMOS33 3.3 N/A N/A Optional
LVCMOS25 2.5 N/A N/A Optional
LVCMOS18 1.8 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
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 383
Product Specification
R
Output Banking
CPLDs are widely used as voltage interface translators. To
that end, the output pins are grouped in large banks. The
XC2C32 and XC2C64 devices are not banked, but the new
XC2C32A and XC2C64A devices have two banks. The
medium parts (128 and 256 macrocell) support two output
banks. With two, the outputs will switch to one of two
selected output voltage levels, unless both banks are set to
the same voltage. The larger parts (384 and 512 macrocell)
support four output banks split evenly. They can support
groupings of one, two, three or four separate output voltage
levels. This kind of flexibility permits easy interfacing to 3.3V,
2.5V, 1.8V, and 1.5V in a single part.
DataGATE
Low power is the hallmark of CMOS technology. Other
CPLD families use a sense amplifier approach to creating
product terms, which always has a residual current compo-
nent being drawn. This residual current can be several hun-
dred milliamps, making them unusable in portable systems.
CoolRunner-II CPLDs use standard CMOS methods to cre-
ate the CPLD architecture and deliver the corresponding
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
arrival of free running signals that are not of interest. Sig-
nals that serve no use may increase power consumption,
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
threaded through the medium and high-density
CoolRunner-II CPLD parts. Designers can select inputs to
be blocked under the control of the DataGATE function,
effectively blocking controlled switching signals so they do
not drive internal chip capacitances. Output signals that do
not switch, are held by the bus hold feature. Any set of input
pins can be chosen to participate in the DataGATE function.
Figure 5 shows the familiar CMOS I
CC
versus switching fre-
quency graph. With DataGATE, designers can approach
zero power, should they choose to, in their designs
Figure 6 shows how DataGATE basically works. One I/O
pin drives the DataGATE Assertion Rail. It can have any
desired logic function on it. It can be as simple as mapping
an input pin to the DataGATE function or as complex as a
counter or state machine output driving the DataGATE I/O
pin through a macrocell. When the DataGATE rail is
asserted high, any pass transistor switch attached to it is
blocked. Note that each pin has the ability to attach to the
AIM through a DataGATE pass transistor, and thus be
blocked. A latch automatically captures the state of the pin
when it becomes blocked. The DataGATE Assertion Rail
threads throughout all possible I/Os, so each can partici-
pate if chosen. Note that one macrocell is singled out to
drive the rail, and that macrocell is exposed to the outside
world through a pin, for inspection. If DataGATE is not
needed, this pin is an ordinary I/O.
Figure 5: CMOS I
CC
vs. Switching Frequency Curve
DS090_05_101001
I
CC
Frequency
0
CoolRunner-II CPLD Family
384 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
Global Signals
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
purpose I/O if they are not needed as global signals. The
DataGATE assertion rail is also a global signal.
Figure 6: DataGATE Architecture (output drivers not shown)
PLA
MC1
MC2
MC16
DS090_06_111201
PLA
PLA
DataGATE Assertion Rail
PLA
AIM
MC1
MC2
MC16
MC1
MC2
MC16
MC1
MC2
MC16
To AIM
Latch
To AIM
Latch
To AIM To AIM
Latch Latch
To AIM
Latch
Figure 7: Global Clocks (GCK), Sets/Resets (GSR) and
Output Enables (GTS)
DS090_07_101001
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 385
Product Specification
R
Additional Clock Options: Division,
DualEDGE, and CoolCLOCK
Division
Circuitry has been included in the CoolRunner-II CPLD
architecture to divide one externally supplied global clock by
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
GCK2 pin. The resulting clock produced will be 50% duty
cycle for all possible divisions. Note that a Synchronous
Reset (CDRST) is included to guarantee no runt clocks can
get through to the global clock nets. Note that again, the sig-
nal is buffered and driven to multiple traces with minimal
loading and skew.
DualEDGE
Each macrocell has the ability to double its input clock
switching frequency. Figure 9 shows the macrocell flip-flop
with the DualEDGE option (doubled clock) at each macro-
cell. The source to double can be a control term clock, a
product term clock or one of the available global clocks. The
ability to switch on both clock edges is vital for a number of
synchronous memory interface applications as well as cer-
tain double data rate I/O applications.
CoolCLOCK
In addition to the DualEDGE flip-flop, additional power sav-
ings can be had by combining the clock division circuitry
with the DualEDGE circuitry. This capability is called Cool-
CLOCK and is designed to reduce clocking power within the
CPLD. Because the clock net can be an appreciable power
drain, the clock power can be reduced by driving the net at
half frequency, then doubling the clock rate using
DualEDGE triggering at the macrocells. Figure 10 shows
how CoolCLOCK is created by internal clock cascading with
the divider and DualEDGE flip-flop working together. See
XAPP378 for more detail.
Figure 8: Clock Division Circuitry for GCK2
Figure 9: Macrocell Clock Chain with DualEDGE Option Shown
DS090_08_121201
Clock
In
÷2
÷4
÷6
÷8
÷10
÷12
÷14
÷16
GCK2
CDRST
CDRST
GCK0
GCK1
GCK2
CLK_CT
PTC
PTC
DS090_09_121201
D/T
CE
CK
FIF
Latch
DualEDGE
Q

CoolRunner-II CPLD Family
386 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
Design Security
Designs can be secured during programming to prevent
either accidental overwriting or pattern theft via readback.
Four independent levels of security are provided on-chip,
eliminating any electrical or visual detection of configuration
patterns. These security bits can be reset only by erasing
the entire device. See WP170 for more detail.
Figure 10: CoolCLOCK Created by Cascading Clock Divider and DualEDGE Option
GCK0
GCK1
GCK2
CTC
PTC
PTC
D/T
CE
CK
FIF
Latch
DualEDGE
Q
Clock
In
÷2
÷4
÷6
÷8
÷10
÷12
÷14
÷16
GCK2
Synch Reset
Synch Rst

CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 387
Product Specification
R
Timing Model
Figure 11 shows the CoolRunner-II CPLD timing model. It
represents one aspect of the overall architecture from a tim-
ing viewpoint. Each little block is a time delay that a signal
will incur if the signal passes through such a resource. Tim-
ing reports are created by tallying the incremental signal
delays as signals progress within the CPLD. Software cre-
ates the timing reports after a design has been mapped
onto the specific part, and knows the specific delay values
for a given speed grade. Equations for the higher level tim-
ing values (i.e., T
PD
and F
SYSTEM
) are available. Table 6
summarizes the individual parameters and provides a brief
definition of their associated functions. Xilinx application
note XAPP375 details the CoolRunner-II CPLD family tim-
ing with several examples.
Figure 11: CoolRunner-II CPLD Timing Model
Note: Always refer to the timing report in ISE Software for accurate timing values for paths.
D/T
S/R
T
F
T
SUI
T
HI
T
COI
T
AOI
T
ECSU
T
ECHO
T
OUT
T
SLEW
T
EN
XAPP375_03_010303
T
OEM
T
PDI
T
LOGI2
T
LOGI1
T
IN
T
HYS
CE
T
DIN
T
HYS
T
CT
T
GCK
T
HYS
T
GSR
T
HYS
T
GTS
T
HYS
Table 6: Timing Parameter Definitions
Symbol Parameter
Buffer Delays
T
lN
Input Buffer Delay
T
DIN
Direct data register input delay
T
GCK
Global clock (GCK) buffer delay
T
GSR
Global set/reset (GSR) buffer delay
T
GTS
Global output enable (GTS) buffer delay
T
OUT
Output buffer delay
T
EN
Output buffer enable/disable delay
T
SLEW
Output buffer slew rate control delay
P-term Delays
T
CT
Control Term delay (single PT or FB-CT)
T
LOGI1
Single P-term logic delay
T
LOGI2
Multiple P-term logic delay adder
Macrocell Delays
T
PDI
Macro cell input to output valid
T
SUI
Macro register setup before clock
T
HI
Macro register hold after clock
T
ECSU
Macro register enable clock setup time
T
ECHO
Macro register enable clock hold time
T
COI
Macro register clock to output valid
T
AOI
Macro register set/reset to output valid
T
HYS
Hysteresis selection delay adder
Feedback Delays
T
F
Feedback delay
T
OEM
Macrocell to Global OE delay
Table 6: Timing Parameter Definitions (Continued)
Symbol Parameter
CoolRunner-II CPLD Family
388 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
Programming
The programming data sequence is delivered to the device
using either Xilinx iMPACT software and a Xilinx download
cable, a third-party JTAG development system, a
JTAG-compatible board tester, or a simple microprocessor
interface that emulates the JTAG instruction sequence. The
iMPACT software also outputs serial vector format (SVF)
files for use with any tools that accept SVF format, including
automatic test equipment. See CoolRunner-II Application
Notes for more information on how to program.
In System Programming
All CoolRunner-II CPLD parts are 1.8V in system program-
mable. This means they derive their programming voltage
and currents from the 1.8V V
CC
(internal supply voltage)
pins on the part. The V
CCIO
pins do not participate in this
operation, as they may assume another voltage ranging as
high as 3.3V down to 1.5V. A 1.8V V
CC
is required to prop-
erly operate the internal state machines and charge pumps
that reside within the CPLD to do the nonvolatile program-
ming operations. The JTAG interface buffers are powered by
a dedicated power pin, V
CCAUX
, which is independent of all
other supply pins. V
CCAUX
must be connected. Xilinx soft-
ware is provided to deliver the bit-stream to the CPLD and
drive the appropriate IEEE 1532 protocol. To that end, there
is a set of IEEE 1532 commands that are supported in the
CoolRunner-II CPLD parts. Programming times are less
than one second for 32 to 256 macrocell parts. Program-
ming times are less than four seconds for 384 and 512 mac-
rocell parts. Programming of CoolRunner-II CPLDs is only
guaranteed when operating in the commercial temperature
and voltage ranges as defined in the device-specific data
sheets.
On-The-Fly Reconfiguration (OTF)
Xilinx ISE 5.2i supports OTF for CoolRunner-II CPLDs. This
permits programming a new nonvolatile pattern into the part
while another pattern is currently in use. OTF has the same
voltage and temperature specifications as system program-
ming. During pattern transition I/O pins are in high imped-
ance with weak pullup to V
CCIO
. Transition time typically
lasts between 50 and 300 μs, depending on density. See
XAPP388 for more information.
JTAG Instructions
Table 7 shows the commands available to users. These
same commands may be used by third party ATE products,
as well. The internal controllers can operate as fast as 66
MHz.
Power-Up Characteristics
CoolRunner-II CPLD parts must operate under the
demands of both the high-speed and the portable market
places, therefore, they must support hot plugging for the
high-speed world and tolerate most any power sequence to
its various voltage pins. They must also not draw excessive
current during power-up initialization. To those ends, the
general behavior is summarized as follows:
1. I/O pins are disabled until the end of power-up.
2. As supply rises, configuration bits transfer from
nonvolatile memory to SRAM cells.
3. As power up completes, the outputs become as
configured (input, output, or I/O).
4. For specific configuration times and power up
requirements, see the device specific data sheet.
CoolRunner-II CPLD I/O pins are well behaved under all
operating conditions. During power-up, CoolRunner-II
devices employ internal circuitry which keeps the devices in
the quiescent state until the V
CCINT
supply voltage is at a
safe level (approximately 1.3V). In the quiescent state,
JTAG pins are disabled, and all device outputs are disabled
with the pins weakly pulled high, as shown in Table 8. When
the supply voltage reaches a safe level, all user registers
become initialized, and the device is immediately available
for operation, as shown in Figure 12. Best results are
obtained with a smooth V
CC
rise in less than 4 ms. Final
V
CC
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
Table 7: JTAG Instructions
Code Instruction Description
00000000 EXTEST Force boundary scan data onto
outputs
00000011 PRELOAD Latch macrocell data into
boundary scan cells
11111111 BYPASS Insert bypass register between
TDI and TDO
00000010 INTEST Force boundary scan data onto
inputs and feedbacks
00000001 IDCODE Read IDCODE
11111101 USERCODE Read USERCODE
11111100 HIGHZ Force output into high
impedance state
11111010 CLAMP Latch present output state
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 389
Product Specification
R
to be programmed at any time. All devices are shipped in
the erased state from the factory.
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
power supply ramp.
If the device is programmed, the device inputs and outputs
take on their configured states for normal operation. The
JTAG pins are enabled to allow device erasure or
boundary-scan tests at any time.
I/O Banking
CoolRunner-II CPLD XC2C32 and XC2C64 macrocell parts
support a single V
CCIO
rail that can range from 3.3V down to
1.5V operation. Two V
CCIO
rails are supported on the
XC2C32A, XC2C64A, 128 and 256 macrocell parts where
outputs on each rail can independently range from 3.3V
down to 1.5V operation. Four V
CCIO
rails are supported on
the 384 and 512 macrocell parts. Any of the V
CCIO
rails can
assume any one of the V
CCIO
values of 1.5V, 1.8V, 2.5V, or
3.3V. Designers should assign input and output voltages to
a bank with V
CCIO
set at the voltage range of that input or
output voltage. The V
CC
(internal supply voltage) for a Cool-
Runner-II CPLD must be maintained within 1.8V ±5% for
correct speed operation and proper in system program-
ming.
Mixed Voltage, Power Sequencing, and
Hot Plugging
As mentioned in I/O Banking, CoolRunner-II CPLD parts
support mixed voltage I/O signals. It is important to assign
signals to an I/O bank with the appropriate I/O voltage. Driv-
ing a high voltage into a low voltage bank can result in neg-
ative current flow through the power supply pins. The power
applied to the V
CCIO
and V
CC
pins can occur in any order
and the CoolRunner-II CPLD will not be damaged. For best
results, we recommend that V
CCINT
be applied before
V
CCIO
. This will ensure that the internal logic is correct
before the I/Os are active. CoolRunner-II CPLDs can reside
on boards where the board is inserted into a “live” connector
(hot plugged) and the parts will be well-behaved as if pow-
ering up in a standard way.
Development System Support
Xilinx CoolRunner-II CPLDs are supported by all configura-
tions of Xilinx standard release development software as
well as the freely available ISE WebPACK software avail-
able from www.xilinx.com. Third party development tools
include synthesis tools from Cadence, Exemplar, Mentor
Graphics, Synplicity, and Synopsys.
ATE Support
Third party ATE development support is available for both
programming and board/chip level testing. Vendors provid-
ing this support include Agilent, GenRad, and Teradyne.
Other third party providers are expected to deliver solutions
in the future.
Figure 12: Device Behavior During Power Up
V
CCINT
No
Power
3.8 V
(Typ)
0V
No
Power
State
Quiescent
State
User Operation
Initialization of User Registers
DS090_12_061406
1.3V
(Typ)
1.0V
Subthreshold
State
Quiescent
Table 8: I/O Power-Up Characteristics
Device Circuitry Subthreshold State Quiescent State
Erased Device
Operation Valid User Operation
IOB Bus-Hold/Weak
Pullup
Undetermined Weak Pull-up Weak Pull-up Bus-Hold/Weak
Pullup
Device Outputs Undetermined Disabled Disabled As Configured
Device Inputs and
Clocks
Undetermined Disabled Disabled As Configured
Function Block Undetermined Disabled Disabled As Configured
JTAG Controller Undetermined Disabled Enabled Enabled
CoolRunner-II CPLD Family
390 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
R
Absolute Maximum Ratings
(1)
Quality and Reliability Parameters
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
Application Notes
http://direct.xilinx.com/bvdocs/appnotes/xapp784.pdf
(Bulletproof Design Practices)
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)
Symbol Parameter Min. Max. Unit
V
CC
(2)
Supply voltage relative to GND –0.5 2.0 V
V
I
(3)
Input voltage relative to GND –0.5 4.0 V
T
J
(4)
Maximum junction temperature –40 150 °C
T
STR
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.
Symbol Parameter Min Max Units
T
DR
Data retention 20 - Years
N
PE
Program/erase cycles (Endurance) 1,000 - Cycles
V
ESD
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.
CoolRunner-II CPLD Family
DS090 (v2.7) June 21, 2006 www.xilinx.com 391
Product Specification
R
http://direct.xilinx.com/bvdocs/appnotes/xapp388.pdf
(On the Fly Reconfiguration)
http://direct.xilinx.com/bvdocs/appnotes/xapp389.pdf
(Powering CoolRunner-II)
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/xapp399.pdf
(Assigning CoolRunner-II VREF Pins)
CoolRunner-II Data Sheets
http://direct.xilinx.com/bvdocs/publications/ds090.pdf
(CoolRunner-II Family Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds310.pdf
(XC2C32A Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds311.pdf
(XC2C64A Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds093.pdf
(XC2C128 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds094.pdf
(XC2C256 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds095.pdf
(XC2C384 Datasheet)
http://direct.xilinx.com/bvdocs/publications/ds096.pdf
(XC2C512 Datasheet)
CoolRunner-II White Papers
http://direct.xilinx.com/bvdocs/whitepapers/wp170.pdf
(Security)
Packages
Package Drawings
Revision History
The following table shows the revision history for this document.
Date Version Revision
01/03/02 1.0 Initial Xilinx release
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 T
FIN
to T
DIN
. Add Schmitt-trigger
I/O compatibility information. Added T
SOL
specification.
05/21/04 2.0 Add XC2C32A and XC2C64A devices.
07/30/04 2.1 Pb-free documentation. Changes to T
SU
and F
system
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, T
PD
, T
SU
, T
CO
, and F
SYSTEM1.
Removed link to obsolete White Paper.
Modifications to Table 5, IOSTANDARDs. Added Table 2, DC Characteristics.
04/15/05 2.4 Change to F
SYSTEM1
for XC2C128.
CoolRunner-II CPLD Family
392 www.xilinx.com DS090 (v2.7) June 21, 2006
Product Specification
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 (V
CCINT
before V
CCIO
power
sequencing). Changed Figure 12 and Table 8, page 13, to add Subthreshold State.
Date Version Revision
DS054 (v2.2) June 21, 2006 www.xilinx.com 393
Product Specification
© 2006 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.
k
Features
• Optimized for high-performance 3.3V systems
- 5 ns pin-to-pin logic delays, with internal system
frequency up to 208 MHz
- Small footprint packages including VQFPs, TQFPs
and CSPs (Chip Scale Package)
- Pb-free available for all packages
- Lower power operation
- 5V tolerant I/O pins accept 5V, 3.3V, and 2.5V
signals
- 3.3V or 2.5V output capability
- Advanced 0.35 micron feature size CMOS
FastFLASH technology
• Advanced system features
- In-system programmable
- Superior pin-locking and routability with
FastCONNECT II™ switch matrix
- Extra wide 54-input Function Blocks
- Up to 90 product-terms per macrocell with
individual product-term allocation
- Local clock inversion with three global and one
product-term clocks
- Individual output enable per output pin with local
inversion
- Input hysteresis on all user and boundary-scan pin
inputs
- Bus-hold circuitry on all user pin inputs
- Supports hot-plugging capability
- Full IEEE Standard 1149.1 boundary-scan (JTAG)
support on all devices
• Four pin-compatible device densities
- 36 to 288 macrocells, with 800 to 6400 usable
gates
• Fast concurrent programming
• Slew rate control on individual outputs
• Enhanced data security features
• Excellent quality and reliability
- 10,000 program/erase cycles endurance rating
- 20 year data retention
• Pin-compatible with 5V core XC9500 family in common
package footprints
0
XC9500XL High-Performance CPLD
Family Data Sheet
DS054 (v2.2) June 21, 2006
0 0
Product Specification
R
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
T
PD
(ns) 5 5 5 6
T
SU
(ns) 3.7 3.7 3.7 4.0
T
CO
(ns) 3.5 3.5 3.5 3.8
f
SYSTEM
(MHz) 178 178 178 208
XC9500XL High-Performance CPLD Family Data Sheet
394 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
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.
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 395
Product Specification
R
Family Overview
The FastFLASH XC9500XL family is a 3.3V CPLD family
targeted for high-performance, low-voltage applications in
leading-edge communications and computing systems,
where high device reliability and low power dissipation is
important. Each XC9500XL device supports in-system pro-
gramming (ISP) and the full IEEE 1149.1 (JTAG) bound-
ary-scan, allowing superior debug and design iteration
capability for small form-factor packages. The XC9500XL
family is designed to work closely with the Xilinx Virtex,
Spartan-XL and XC4000XL FPGA families, allowing system
designers to partition logic optimally between fast interface
circuitry and high-density general purpose logic. As shown
in Table 1, logic density of the XC9500XL devices ranges
from 800 to 6400 usable gates with 36 to 288 registers,
respectively. Multiple package options and associated I/O
capacity are shown in Table 2. The XC9500XL family mem-
bers are fully pin-compatible, allowing easy design migra-
tion across multiple density options in a given package
footprint.
The XC9500XL architectural features address the require-
ments of in-system programmability. Enhanced pin-locking
capability avoids costly board rework. In-system program-
ming throughout the full commercial operating range and a
high programming endurance rating provide worry-free
reconfigurations of system field upgrades. Extended data
retention supports longer and more reliable system operat-
ing life.
Advanced system features include output slew rate control
and user-programmable ground pins to help reduce system
noise. Each user pin is compatible with 5V, 3.3V, and 2.5V
inputs, and the outputs may be configured for 3.3V or 2.5V
Figure 1: XC9500XL Architecture
Note: Function block outputs (indicated by the bold lines) drive the I/O blocks directly.
In-System Programming Controller
JTAG
Controller
I/O
Blocks
Function
Block 1
Macrocells
1 to 18
Macrocells
1 to 18
Macrocells
1 to 18
Macrocells
1 to 18
JTAG Port
3
54
I/O/GTS
I/O/GSR
I/O/GCK
I/O
I/O
I/O
I/O
2 or 4
1
I/O
I/O
I/O
I/O
3
DS054_01_042001
Function
Block 2
54
Function
Block 3
54
18
18
18
18
Function
Block N
54
F
a
s
t
C
O
N
N
E
C
T

I
I

S
w
i
t
c
h

M
a
t
r
i
x
XC9500XL High-Performance CPLD Family Data Sheet
396 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
operation. The XC9500XL device exhibits symmetric full
3.3V output voltage swing to allow balanced rise and fall
times. Additional details can be found in the application
notes listed in "Further Reading" on page 403.
Architecture Description
Each XC9500XL device is a subsystem consisting of multi-
ple Function Blocks (FBs) and I/O Blocks (IOBs) fully inter-
connected by the FastCONNECT II switch matrix. The IOB
provides buffering for device inputs and outputs. Each FB
provides programmable logic capability with extra wide
54inputs and 18 outputs. The FastCONNECT II switch
matrix connects all FB outputs and input signals to the FB
inputs. For each FB, up to 18 outputs (depending on pack-
age pin-count) and associated output enable signals drive
directly to the IOBs. See Figure 1
Function Block
Each Function Block, as shown in Figure 2 is comprised of
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
generates 18 outputs that drive the FastCONNECT switch
matrix. These 18 outputs and their corresponding output
enable signals also drive the IOB.
Logic within the FB is implemented using a sum-of-products
representation. Fifty-four inputs provide 108 true and com-
plement signals into the programmable AND-array to form
90 product terms. Any number of these product terms, up to
the 90 available, can be allocated to each macrocell by the
product term allocator.
Macrocell
Each XC9500XL macrocell may be individually configured
for a combinatorial or registered function. The macrocell
and associated FB logic is shown in Figure 3.
Five direct product terms from the AND-array are available
for use as primary data inputs (to the OR and XOR gates) to
implement combinatorial functions, or as control inputs
including clock, clock enable, set/reset, and output enable.
The product term allocator associated with each macrocell
selects how the five direct terms are used.
The macrocell register can be configured as a D-type or
T-type flip-flop, or it may be bypassed for combinatorial
operation. Each register supports both asynchronous set
and reset operations. During power-up, all user registers
Figure 2: XC9500XL Function Block
Macrocell 18
Macrocell 1
Programmable
AND-Array
Product
Term
Allocators
From
FastCONNECT II
Switch Matrix
DS054_02_042101
54
1
To FastCONNECT II
Switch Matrix
To I/O Blocks
OUT
Global
Set/Reset
3
18
PTOE
18
18
Global
Clocks
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 397
Product Specification
R
are initialized to the user-defined preload state (default to 0
if unspecified).
All global control signals are available to each individual
macrocell, including clock, set/reset, and output enable sig-
nals. As shown in Figure 4, the macrocell register clock
originates from either of three global clocks or a product
term clock. Both true and complement polarities of the
selected clock source can be used within each macrocell. A
GSR input is also provided to allow user registers to be set
to a user-defined state.
Figure 3: XC9500XL Macrocell Within Function Block
DS054_03_042101
To
FastCONNECTII
Switch Matrix
Additional
Product
Terms
(from other
macrocells)
Global
Set/Reset
Global
Clocks
Additional
Product
Terms
(from other
macrocells)
To
I/O Blocks
OUT
1
0
54
3
PTOE
D/T Q
S
R
Product
Term
Allocator
Product Term Set
Product Term Clock
Product Term Reset
Product Term OE
Product Term Clock Enable
CE
XC9500XL High-Performance CPLD Family Data Sheet
398 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
Figure 4: Macrocell Clock and Set/Reset Capability
D/T
CE
S
R
Macrocell
DS05404_042101
I/O/GSR
Product Term Set
Product Term Clock
Product Term Reset
Global Set/Reset
Global Clock 1
Global Clock 2
Global Clock 3
I/O/GCK3
I/O/GCK2
I/O/GCK1
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 399
Product Specification
R
Product Term Allocator
The product term allocator controls how the five direct prod-
uct terms are assigned to each macrocell. For example, all
five direct terms can drive the OR function as shown in
Figure 5.
The product term allocator can re-assign other product
terms within the FB to increase the logic capacity of a mac-
rocell beyond five direct terms. Any macrocell requiring
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 t
PTA,
as shown in Figure 6.
Note that the incremental delay affects only the product
terms in other macrocells. The timing of the direct product
terms is not changed.
Figure 5: Macrocell Logic Using Direct Product Term
Product Term
Allocator
Macrocell
Product Term
Logic
DS054_05_042101
Figure 6: Product Term Allocation With 15 Product
Terms
Macrocell Logic
With 15
Product Terms
Product Term
Allocator
Product Term
Allocator
DS054_06_042101
Product Term
Allocator
XC9500XL High-Performance CPLD Family Data Sheet
400 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
The product term allocator can re-assign product terms
from any macrocell within the FB by combining partial sums
of products over several macrocells, as shown in Figure 7.
In this example, the incremental delay is only 2*T
PTA
. All 90
product terms are available to any macrocell, with a maxi-
mum incremental delay of 8*T
PTA.
Figure 7: Product Term Allocation Over Several
Macrocells
Macrocell Logic
With 18
Product Terms
Macrocell Logic
With 2
Product Terms
Product Term
Allocator
Product Term
Allocator
DS054_07 _042101
Product Term
Allocator
Product Term
Allocator
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 401
Product Specification
R
The internal logic of the product term allocator is shown in
Figure 8.
Figure 8: Product Term Allocator Logic
D/T
Q
S
R
From Upper
Macrocell
To Upper
Macrocell
Product Term Set
Product Term Clock
Product Term Reset
Global Set/Reset
Global Set/Reset
Global Clocks
Product Term OE
Product Term
Allocator
To Lower
Macrocell
From Lower
Macrocell
DS054_08_042101
1
0
CE
XC9500XL High-Performance CPLD Family Data Sheet
402 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
FastCONNECT II Switch Matrix
The FastCONNECT II Switch Matrix connects signals to the
FB inputs, as shown in Figure 9. All IOB outputs (corre-
sponding to user pin inputs) and all FB outputs drive the
FastCONNECT II matrix. Any of these (up to a fan-in limit of
54) may be selected to drive each FB with a uniform delay.
Figure 9: FastCONNECT II Switch Matrix
DS054_09_042101
Function Block
FastCONNECT II
Switch Matrix
(54)
I/O
Function Block
I/O Block
18
18
I/O Block
(54)
I/O
D/T Q
D/T Q
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 403
Product Specification
R
I/O Block
The I/O Block (IOB) interfaces between the internal logic
and the device user I/O pins. Each IOB includes an input
buffer, output driver, output enable selection multiplexer,
and user programmable ground control. See Figure 10 for
details.
The input buffer is compatible with 5V CMOS, 5V TTL, 3.3V
CMOS, and 2.5V CMOS signals. The input buffer uses the
internal 3.3V voltage supply (V
CCINT
) to ensure that the
input thresholds are constant and do not vary with the
V
CCIO
voltage. Each input buffer provides input hysteresis
(50 mV typical) to help reduce system noise for input signals
with slow rise or fall edges.
Each output driver is designed to provide fast switching with
minimal power noise. All output drivers in the device may be
Figure 10: I/O Block and Output Enable Capability
I/O Block
Macrocell
DS054_10_042101
Product Term OE PTOE
Switch Matrix
OUT
(Inversion in
AND-array)
Global OE 1
1
To other
Macrocells
Slew Rate
Control
0
Global OE 2
Available in XC95144XL
and XC95288XL
Global OE 3
Global OE 4
I/O/GTS1
I/O
I/O/GTS2
I/O/GTS3
I/O/GTS4
To FastCONNECT
User-
Programmable
Ground
Bus-Hold
XC9500XL High-Performance CPLD Family Data Sheet
404 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
configured for driving either 3.3V CMOS levels (which are
compatible with 5V TTL levels as well) or 2.5V CMOS levels
by connecting the device output voltage supply (V
CCIO
) to a
3.3V or 2.5V voltage supply. Figure 11 shows how the
XC9500XL device can be used in 3.3V only systems and
mixed voltage systems with any combination of 5V, 3.3V
and 2.5V power supplies.
Each output driver can also be configured for slew-rate lim-
ited operation. Output edge rates may be slowed down to
reduce system noise (with an additional time delay of t
SLEW
)
under user control. See Figure 12.
The output enable may be generated from one of four
options: a product term signal from the macrocell, any of the
global output enable signals (GTS), always “1,” or always
“0.” There are two global output enables for devices with 72
or fewer macrocells, and four global output enables for
devices with 144 or more macrocells. Any selected output
enable signal may be inverted locally at each pin output to
provide maximal design flexibility.
Each IOB provides user programmable ground pin capabil-
ity. This allows device I/O pins to be configured as additional
ground pins in order to force otherwise unused pins to a low
voltage state, as well as provide for additional device
grounding capability. This grounding of the pin is achieved
by internal logic that forces a logic low output regardless of
the internal macrocell signal, so the internal macrocell logic
is unaffected by the programmable ground pin capability.
Each IOB also provides for bus-hold circuitry (also called a
“keeper”)that is active during valid user operation. The
bus-hold feature eliminates the need to tie unused pins
either high or low by holding the last known state of the input
until the next input signal is present. The bus-hold circuit
drives back the same state via a nominal resistance (R
BH
)
of 50k ohms. See Figure 13. Note the bus-hold output will
drive no higher than V
CCIO
to prevent overdriving signals
when interfacing to 2.5V components.
When the device is not in valid user operation, the bus-hold
circuit defaults to an equivalent 50k ohm pull-up resistor in
order to provide a known repeatable device state. This
occurs when the device is in the erased state, in program-
ming mode, in JTAG INTEST mode, or during initial
power-up. A pull-down resistor (1k ohm) may be externally
added to any pin to override the default R
BH
resistance to
force a low state during power-up or any of these other
modes.
5V Tolerant I/Os
The I/Os on each XC9500XL device are fully 5V tolerant
even though the core power supply is 3.3 volts. This allows
5V CMOS signals to connect directly to the XC9500XL
inputs without damage. In addition, the 3.3V V
CCINT
power
supply can be applied before or after 5V signals are applied
to the I/Os. In mixed 5V/3.3V/2.5V systems, the user pins,
the core power supply (V
CCINT
), and the output power sup-
ply (V
CCIO
) may have power applied in any order. This
makes the XC9500XL devices immune to power supply
sequencing problems.
Xilinx proprietary ESD circuitry and high impedance initial
state permit hot plugging cards using these devices.
Pin-Locking Capability
The capability to lock the user defined pin assignments dur-
ing design iteration depends on the ability of the architec-
ture to adapt to unexpected changes. The XC9500XL
devices incorporate architectural features that enhance the
ability to accept design changes while maintaining the same
pinout.
Figure 11: XC9500XL Devices in (a) 3.3V only and (b) Mixed 5V/3.3V/2.5V Systems
IN
OUT
2.5V 3.3V
GND
(b)
2.5V CMOS
IN
OUT
XC9500XL
CPLD
XC9500XL
CPLD
V
CCINT
V
CCIO
V
CCINT
V
CCIO
3.3V
GND
(a)
3.3V
0V
5V
0V
3.3V
0V
2.5V
0V
2.5V
0V
3.3V CMOS, 5V TTL
DS054_11_042101
2.5V CMOS
3.3V CMOS or
5V TTL or
5V
0V
5V CMOS
5V
0V
3.3V
0V
2.5V
0V
2.5V CMOS
3.3V CMOS or
5V TTL or
5V
0V
5V CMOS
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 405
Product Specification
R
The XC9500XL architecture provides for superior pin-lock-
ing characteristics with a combination of large number of
routing switches in the FastCONNECT II switch matrix, a
54-wide input Function Block, and flexible, bi-directional
product term allocation within each macrocell. These fea-
tures address design changes that require adding or chang-
ing internal routing, including additional signals into existing
equations, or increasing equation complexity, respectively.
For extensive design changes requiring higher logic capac-
ity than is available in the initially chosen device, the new
design may be able to fit into a larger pin-compatible device
using the same pin assignments. The same board may be
used with a higher density device without the expense of
board rework.
In-System Programming
One or more XC9500XL devices can be daisy chained
together and programmed in-system via a standard 4-pin
JTAG protocol, as shown in Figure 14. In-system program-
ming offers quick and efficient design iterations and elimi-
nates package handling. The Xilinx development system
provides the programming data sequence using a Xilinx
download cable, a third-party JTAG development system,
JTAG-compatible board tester, or a simple microprocessor
interface that emulates the JTAG instruction sequence.
All I/Os are 3-stated and pulled high by the bus-hold cir-
cuitry during in-system programming. If a particular signal
must remain low during this time, then a pulldown resistor
may be added to the pin.
External Programming
XC9500XL devices can also be programmed by the Xilinx
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.
Reliability and Endurance
All XC9500XL CPLDs provide a minimum endurance level
of 10,000 in-system program/erase cycles and a minimum
data retention of 20 years. Each device meets all functional,
performance, and data retention specifications within this
endurance limit.
IEEE 1149.1 Boundary-Scan (JTAG)
XC9500XL devices fully support IEEE 1149.1 bound-
ary-scan (JTAG). EXTEST, SAMPLE/PRELOAD, BYPASS,
USERCODE, INTEST, IDCODE, HIGHZ and CLAMP
instructions are supported in each device. Additional
instructions are included for in-system programming opera-
tions.
Figure 12: Output Slew-Rate Control For (a) Rising and (b) Falling Outputs
Time
0 0
1.5V
Standard
Output
Voltage
(a)
Slew-Rate Limited
Time
Output
Voltage
(b)
Standard
Slew-Rate Limited
V
CCIO
T
SLEW
T
SLEW
1.5V
DS054_12_042101
Figure 13: Bus-Hold Logic
R
BH

I/O
Set to PIN
during valid user
operation
Drive to
V
CCIO
Level
PIN
0
DS054_13_042101
XC9500XL High-Performance CPLD Family Data Sheet
406 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
Design Security
XC9500XL devices incorporate advanced data security fea-
tures which fully protect the programming data against
unauthorized reading or inadvertent device erasure/repro-
gramming. Table 3 shows the four different security settings
available.
The read security bits can be set by the user to prevent the
internal programming pattern from being read or copied.
When set, they also inhibit further program operations but
allow device erase. Erasing the entire device is the only way
to reset the read security bit.
The write security bits provide added protection against
accidental device erasure or reprogramming when the
JTAG pins are subject to noise, such as during system
power-up. Once set, the write-protection may be deacti-
vated when the device needs to be reprogrammed with a
valid pattern with a specific sequence of JTAG instructions.
Low Power Mode
All XC9500XL devices offer a low-power mode for individual
macrocells or across all macrocells. This feature allows the
device power to be significantly reduced.
Each individual macrocell may be programmed in
low-power mode by the user. Performance-critical parts of
the application can remain in standard power mode, while
other parts of the application may be programmed for
low-power operation to reduce the overall power dissipation.
Macrocells programmed for low-power mode incur addi-
tional delay (t
LP
) in pin-to-pin combinatorial delay as well as
register setup time. Product term clock to output and prod-
uct term output enable delays are unaffected by the macro-
cell power-setting. Signals switching at rates less than 50 ns
rise/fall time should be assigned to the macrocells config-
ured in low power mode.
Timing Model
The uniformity of the XC9500XL architecture allows a sim-
plified timing model for the entire device. The basic timing
model, shown in Figure 15, is valid for macrocell functions
that use the direct product terms only, with standard power
setting, and standard slew rate setting. Table 4 shows how
each of the key timing parameters is affected by the product
term allocator (if needed), low-power setting, and slew-lim-
ited setting.
The product term allocation time depends on the logic span
of the macrocell function, which is defined as one less than
the maximum number of allocators in the product term path.
If only direct product terms are used, then the logic span is
0. The example in Figure 6 shows that up to 15 product
terms are available with a span of 1. In the case of Figure 7,
the 18 product term function has a span of 2.
Table 3: Data Security Options
Read Security
Default Set
W
r
i
t
e

S
e
c
u
r
i
t
y
Default
Read Allowed
Program/Erase
Allowed
Read Inhibited
Program Inhibited
Erase Allowed
Set
Read Allowed
Program/Erase
Allowed
Read Inhibited
Program/Erase
Inhibited
Figure 14: System Programming Operation (a) Solder Device to PCB and (b) Program Using Download Cable
X5902
G
N
D
VC
C
(a) (b)
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 407
Product Specification
R
Detailed timing information may be derived from the full tim-
ing model shown in Figure 16. The values and explanations
for each parameter are given in the individual device data
sheets.
Figure 15: Basic Timing Model
Figure 16: Detailed Timing Model
Combinatorial
Logic
Propagation Delay = T
PD
(a)
Combinatorial
Logic
Setup Time = T
SU
T
CO
T
PSU
T
PCO
Clock to Out Time = T
CO
(b)
D/T Q
Combinatorial
Logic
Internal System Cycle Time = T
SYSTEM
DS054_15_042101
(d)
D/T Q
Combinatorial
Logic
Setup Time = T
PSU
Clock to Out Time = T
PCO
(c)
P-Term Clock
Path
D/T Q
D/T Q
SR
T
IN
T
LOGILP
S*T
PTA
T
F
T
PDI
T
SUI
T
COI
T
HI
T
AOI
T
RAI
T
OUT
T
SLEW
T
EN
DS054_16_042101
T
LOGI
T
PTCK
T
PTSR
T
PTTS
T
GCK
T
GSR
T
GTS
Macrocell
CE
XC9500XL High-Performance CPLD Family Data Sheet
408 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R
Power-Up Characteristics
The XC9500XL devices are well behaved under all operat-
ing conditions. During power-up each XC9500XL device
employs internal circuitry which keeps the device in the qui-
escent state until the V
CCINT
supply voltage is at a safe level
(approximately 2.5V). During this time, all device pins and
JTAG pins are disabled and all device outputs are disabled
with the pins weakly pulled high, as shown in Table 5. When
the supply voltage reaches a safe level, all user registers
become initialized (typically within 200 μs), and the device is
immediately available for operation, as shown in Figure 17.
If the device is in the erased state (before any user pattern
is programmed), the device outputs remain disabled with
weak pull-up. The JTAG pins are enabled to allow the device
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
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.
Development System Support
The XC9500XL family and associated in-system program-
ming capabilities are fully supported in either software solu-
tions available from Xilinx.
The Foundation Series is an all-in-one development system
containing schematic entry, HDL (VHDL, Verilog, and
ABEL), and simulation capabilities. It supports the
XC9500XL family as well as other CPLD and FPGA fami-
lies.
The Alliance Series includes CPLD and FPGA implementa-
tion technology as well as all necessary libraries and inter-
faces for Alliance partner EDA solutions.
FastFLASH Technology
An advanced 0.35 micron feature size CMOS Flash process is
used to fabricate all XC9500XL devices. The FastFLASH pro-
cess provides high performance logic capability, fast pro-
gramming times, and superior reliability and endurance
ratings.
Figure 17: Device Behavior During Power-up
V
CCINT
No
Power
3.8 V
(Typ)
0V
No
Power
State
Quiescent
State
User Operation
Initialization of User Registers
DS054_17_042101
2.5V
(Typ)
1.0V
Subthreshold
State
Quiescent
Table 4: Timing Model Parameters
Parameter Description
Product Term
Allocator
(1)
Macrocell
Low-Power Setting
Output Slew-Limited
Setting
T
PD
Propagation Delay + T
PTA
* S + T
LP
+ T
SLEW
T
SU
Global Clock Setup Time + T
PTA
*

S + T
LP

T
CO
Global Clock-to-output - - + T
SLEW
T
PSU
Product Term Clock Setup Time + T
PTA
* S + T
LP
-
T
PCO
Product Term Clock-to-output - - + T
SLEW
T
SYSTEM
Internal System Cycle Period + T
PTA
* S + T
LP
-
Notes:
1. S = the logic span of the function, as defined in the text.
Table 5: XC9500XL Pin Characteristics
Device Circuitry Subthreshold State Quiescent State
Erased Device
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
XC9500XL High-Performance CPLD Family Data Sheet
DS054 (v2.2) June 21, 2006 www.xilinx.com 409
Product Specification
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.
Date Version Revision
09/28/98 1.0 Initial Xilinx release
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.
XC9500XL High-Performance CPLD Family Data Sheet
410 www.xilinx.com DS054 (v2.2) June 21, 2006
Product Specification
R

Sign up to vote on this title
UsefulNot useful