Xilinx文档的数量非常多即使全职从倳FPGA相关工作，没有几年时间不可能对器件特性、应用、注意事项等等有较为全面的了解本文记录了我自使用Xilinx系列FPGA以来或精读、或翻阅、戓查询过的文档，及其主要内容如果有新的会随时补录进来。以下按照个人理解对文档进行了分类不一定恰当，也会有重叠的情况歡迎提出意见。

ds180：7系列器件概述介绍不同器件的资源、IO分布、工作频率、收发器数量、DSP类型、IO电压等等。

ug472：该手册详细描述了7系列器件嘚时钟资源如时钟架构、时钟布线资源、时钟管理等等。

ug474：详细介绍7系列器件的可配置逻辑块（CLB）的结构、特点、应用、分布等等

ug475：詳细介绍7系列器件的封装、尺寸、管脚分布、热特性等等。

ug479：7系列器件中DSP单元的架构、使用方法、应用等

ug480：7系列器件内置XADC的详细介绍。

ug953：7系列器件设计库包含7系列器件几乎所有的Macro和Primitive。

ug572：该手册详细描述了UltraScale系列器件的时钟资源如时钟架构、时钟布线资源、时钟管理等等。

ug574：详细介绍UltraScale系列器件的可配置逻辑块（CLB）的结构、特点、应用、分布等等和7系列的区别挺大。

ug575：详细介绍UltraScale系列器件的封装、尺寸、管腳分布、热特性等等

ds181、ds182、ds183、ds187：分别详细介绍A7、K7、V7和Zynq-7000系列器件的电气特性，如直流电平、交流特性、上电顺序、收发器电气特性、eFUSE编程等等

ug470：详细介绍7系列器件的多种配置方法和电路。

ug570：详细介绍UltraScale系列器件的多种配置方法和电路

ug896：介绍Vivado中IP的使用，以及基于IP的设计方法

ug900：介绍在Vivado中如何进行逻辑仿真。

ug908：介绍在Vivado中如何进行编程和调试主要讲Vivado IDE的使用。

ug911：介绍如何将设计向Vivado迁移

ug936：一个使用Vivado进行编程和调试嘚手把手的教程。

ug947：一个使用Vivado进行PR设计的手把手的教程

ug949：UltraFast设计方法指南。这是一个非常全面的文档部分内容比较深入，部分内容只是介绍主要是一些方法、流程、工具、概念的介绍。比如HLS设计、基于IP的设计方法、仿真、Project和Non-Project比较、板级设计、PCB设计、编码风格等等

ug905：Hierarchical Design设計方法。Hierarchical设计要用好不容易对FPGA器件、设计方法学、架构要有非常深入的了解。曾经用过但是对我参与的项目不适用（主要是没见过世媔），所以放弃

ug901：介绍如何进行设计综合，内容包括综合策略选择、综合技巧、设计原则等等

ug903：介绍如何使用约束，包括IO位置约束、延时约束、时序约束、物理约束、CDC约束等等

ug906：介绍如何对自己的工程进行分析和改进，进而实现时序收敛

ug761：AXI Reference Guide用户手册，介绍AXI协议的关鍵概念、概述AXI的使用、如何将现有设计迁移到AXI下

pg054：7系列FPGA的PCIe接口IP说明文档，内容包括PCIe接口概述、电气特性、使用方法、设计步骤、仿真调試等等

pg054：7系列器件PCIe接口产品手册。

AR# 65444：XDMA驱动和软件使用（数字签名真烦人）。

ug476：7系列器件收发器的用户手册内容涵盖收发器内部资源嘚详细描述和使用方法，硬件电路设计注意事项收发器应用等等。

pg196：UltraScale系列GTY Ibert的产品手册在收发器调试中非常有用，值得拥有！

ug429：介绍如哬将设计从Virtex6移植到7系列器件

本人新书上市请多多关照：

这幾天我一直在跟进公司的一个性能问题，里面涉及到聚集列存储索引的问题跟微软的技术支持讨论了一下，他们的建议可以考虑转成非聚集的列存储索引那我到底怎么做好呢？我觉得有必要研究一下这两者的差异说不定可以得出一个“不用列存储索引”的结论呢。
为叻感觉记录下处理过程在本系列中先缓一下分区的内容，插播一篇关于列存储的文章

??在选择之前，首先要想一下下面的问题：

• 我們到底要不要用列存储索引
• 如果要用，用在哪些表上用哪种？
• 如果是非聚集的列存储索引建在哪些列上？

??在SQL 2012的时候只有非聚集的列存储索引，同时它不允许创建后更新所以如果选择列存储，就只有非聚集可选且只适合不怎么更新的表这种限制使得非聚集列存储索引很难被推广。其中不允许更新的限制成了绝大部分企业不使用该功能的最重要因素虽然可以用一些方式来实现，不过确实不够唍美

??SQL Server 2014是一个开拓性的版本，不仅引入了内存技术（这是这个版本最大的亮点）还增强了列存储技术和其他比如AlwaysOn方面的高可用技术。在这个版本中引入了聚集列存储索引且可更新，但是此时非聚集的列存储索引依旧是不可更新可更新的聚集列存储索引的出现，一時间使得很多人认为DW只需要聚集的列存储所有不过当然还没有什么技术是可以面面俱到的。

??SQL Server 2016列存储索引发展成3个独立的体系：

1. 基於磁盘的聚集列存储索引：主要针对DW，基于磁盘（disk-based）是相对于基于内存而言即从SQL 2014出现的内存技术。
2. 基于磁盘的可更新的非聚集列存储索引：主要针对混合场景OLTP+实时报表终于可以更新非聚集列存储了。
3. In-Memory 聚集列存储索引：主要针对基于内存技术的混合场景
   ??到了这个时候，列存储索引基本上就能应对所有常规场景了聚集列存储索引已经可以应对绝大部分的需求，不过也还有一些场景不适合比如索引視图，事务复制CDC等，还有一些数据类型并不支持聚集列存储索引

??SQL Server 2017正式以兼容Linux和Windows平台为主要卖点来发布，针对列存储索引2017引入了聚集列存储索引对LOBs的支持，对非持久的计算列支持还有非聚集列存储索引对联机重建的支持。

??Azure SQL DB本质上跟当前最新的数据库版本（本攵发布时是SQL 2019）相同并且由于云平台的特性，它具有更快的新功能发布几乎所有技术都在Auzre上先运用然后才会更新到本地版。

??首先要紸意我这里没讨论用哪种只是考虑用列存储还是行存储（也就是常规索引）。
??有几个关键因素会影响是否使用：

1. 查询绝大部分表数據时：比如10亿数据的表经常需要查询9亿数据，那么这个时候列存储索引会很高效
2. 资源比如内存/CPU/磁盘空间是查询性能的瓶颈时：因为列存储索引带有高度压缩的特性，所以对资源有大量要求的查询可以通过列存储索引的方式来减少数据集
3. 列里面包含大量相似的数据或者鈳以实现高度压缩的数据时。可以大幅度节省空间消耗
4. 针对ETL过程，对于归档所有数据时聚集列存储索引可以节省大量空间。

??如果昰考虑聚集列存储索引首先要考虑是否有不支持的数据类型，其次就是单纯测试性能时可能需要其他技术来做辅助，比如内存表

??上面的内容也意味着如果你只需要查询少量数据或者高度唯一的数据时，列存储索引并不一定是最好的选择

??假设我们现在确实需偠用到列存储索引，那么本文打算介绍一下如何去选择

??影响加载速度的关键因素就是尽量减少对基础结构的额外负担。说白了就是沒有索引和没有压缩但是在SQL 2014中，聚集列存储索引的Delta-Stores使用页压缩进行压缩一开始的设计应该时为了把Delta-Stores占用的空间释放出来，但是从实践來看不见得是有效的因为不管加载多快，都会被压缩操作拖延总体时间
??从SQL 2016开始，对如并行插入进行了改进特别是对于具有大量攵本列的宽表。它主要的做法是移除Delta-Stores上的压缩

??说太多好像没什么意义，要不还是直接来看实验吧首先创建一个表，然后通过循环插入100万随机数看一下在CCITable中使用聚集列存储索引和聚集及非聚集行存储索引的差异。
??下面的代码需要单独执行按照Step来执行，在Step 4和Step 7 时咑开实际执行计划其他时候可以关闭，减少运行时间不过不关闭也没关系。
??第一步创建一个表，都是BIGINT类型此时表是堆表。
??第二步循环100万次插入随机数据。并检查表大小
??第三步创建两个非聚集索引。并检查表大小
??第四步打开执行计划并包含SET STATISTICS IO命囹，进行全表的扫描（实际上就是索引扫描）及聚合计算可以得到执行计划和IO信息。
??第五步移除表上的所有索引
??第六步，创建聚集列存储索引聚集列存储索引不需要指定列，实际上就是把整个表转换成一个列存储格式同时检查表大小。
??第七步按照四步的方式再次执行并查看结果。

??在上面可以看到我并没有对很多列加索引，因为对于ETL环境很多表都具有上百个列（我刚处理的公司的情况就是有600列），这样不仅使得索引低效也使得存储开销明显增大。

如果要查询数百列的表的几乎所有数据对所有列加索引并使鼡索引扫描在大多数情况下都没有明显的用处。

??上面代码的结果如下可以看出列存储索引在这种特定情况下更加有效。
??堆表导叺速度36分钟：
??堆表占据空间33.45MB

??非聚集索引在扫描过程中的I/O情况：

??非聚集索引扫描的执行计划：

??另外我们在这个过程中也檢查了表的体积，可以看到聚集列存储索引对空间消耗更小

??非聚集索引化后表大小：

??只有聚集列存储索引时的表大小：

??现茬我们来试一下相同环境下(换一个表)，变成聚集列存储索引后对导入的影响要注意列存储索引有一个Delta-Store的特性，这个特性会影响性能一般建议是一次导入刚好超过102400行数据。这样可以不经过Delta-Store否则数据先进入Delta-Store然后再转换成列存储，这一步会有明显的开销

??时间对比相差無几，也可以初步判断影响不大不过这个可能会有很多因素影响结果，所以最好还是在实际环境测一下：

??从实验看到列存储索引，虽然这里没有演示非聚集列存储索引但是对于特定情况的ETL甚至DW环境，比普通行存储更有用
??当然，所有的决定都依赖于特定环境如果你的I/O很好，可以考虑直接把表建成聚集列存储索引然后导入
??另外有个非常重要的影响因素就是ETL过程的方式，对于现今的大数據生态系统中各种可以实现ETL过程的软件和其他传统软件在导入过程的行为都会影响最终的性能。