为国产FPGA正名——国内外知名产品大比拼

　　印象中FPGA市场基本是Altera和Xilinx一统天下，他们的明争暗斗决定着FPGA的未来，甚至他们各自的家族产品都是对着干的。Lattice、Actel、Atmel各有其小众市场，再有别的厂商，基本上是不太叫得上来了。

　　国产FPGA？是不是听错了，没有。记得第一次听说FPGA前面加了个定冠词“国产”应该可以追溯到还和价格堪比年薪的军品纠结的岁月。不过那个“国产”二字总感觉和“盗版”谐音，真的不是损谁，只是实事求是的说。也许这种模式也叫“中国特色”吧，好歹比那天忘了在哪位大侠博客看到的“二次包装”的“中国制造”强上千百倍。Xilinx早期的XC4打头的FPGA，也只有ISE4以前的版本支持，“低端”军品也就这几款了。所以国内的XX所也很牛，居然能够逆向设计将他们的“国产”FPGA做得和它完全兼容，不止是PIN2PIN，甚至连开发工具他们都不用徒手打造了，告诉我们完全替代现有的Xilinx器件。

　　有时候不得不感叹，中国人很牛。外国人可以做到的，基本上没有中国人做不到的。时光荏苒，已不再需要靠那些“可靠”换“性能”的片子干活了。而FPGA的成本却越来越成为产品开发中挥之不去的梦魇，于是乎，老板想尽办法要压榨FPGA的成本，这次找来了又一个“国产”准备在低端低成本的应用中大干一场。不过几番观察下来，特权同学开始对此“君”颇有好感，它也许算不上真正意义上的“国产”，但是多少让人感受到了它走的是一条“正规”有“前途”的路子。

　　其实也只是昨天才开始正式的和这家名为Agate Logic的FPGA厂商有了一些“亲密”接触。它的开发工具，它的开发流程，它的主打芯片结构、特点、性能都有所了解，但要真*实弹的用这个家伙干活，还得有更深入的尝试和验证。对这些尝试做些记录，也许，是一次蛮有意思的尝试。

　　今天先简单的没主题的随便扯谈吧。首先，这家公司是提供了两个系列的产品，其中一个系列工艺先进些，据说性能好一些，只不过年初刚量产，还不是主推产品，姑且不详谈，毕竟特权同学的DEMO板上的主角儿也不是它。另一个低端点的系列叫Astro，别小看它了，先罗列一下参数大家瞧瞧。

　　★ 硬核——可以跑到100MHz的8051硬核，标准外设IIC一个、SPI一个、USART两个、定时器数个。

　　★ 1Mbit一次性可编程存储（OTP）——加密的利器啊。

　　★ 1个PLL——3个可选输出，相位可调。

　　★ 可选的内部4Mbit FLASH。

　　★ 2个9Kbit可配置存储器——虽然对于片内存储要求很高的特权同学有点“巧妇难为无米之炊”了，不过低端应用牺牲一些“性能”还是可以接受的。

　　有这些东西还不算，最主要的还是它保持着传统“中国特色”的“便宜”，基本上3个美金可以拿到有1024个LUT的器件了。若是要和当前的Altera相关解决方案比比，那真得是蛮有竞争力的。MAX II系列CPLD除了逻辑真得没有别的用处了，而逻辑资源逊色不少的EPM570（EPM1270不说了）目前市场上估计是有缺货的因素，居然卖到30好几个RMB了。而如果选择Cyclone系列最便宜的EP1C3好像也只要30多RMB，但是要跑个最经济的NIOS也有点困难。而且有个很有意思的现象，正规代理商会很无奈的告诉你这样的老器件要30的数倍价格才能搞到，而外面的小商小贩卖的就是30的准“白菜价”（当然不排除买到“散新货”的可能）。而Astro却连配置器件和外挂MCU的成本都省了，虽然它也是基于SRAM的结构。（不行，越比发现这东西越好。先申明一下，这里不是推销，只是比较，特权同学是用芯片的，不是卖芯片的。嘿嘿）

　　今天花了一上午把它们的开发工具Primace的Help过了一遍。再说个题外话，昨天到它们的上海办事处，感觉上这般人对版本的管理不是很好，动不动来一个版本，让我们当时一个版本装另一个版本卸的来回折腾好几次才看到Primace的本来面目。还有那个USB下载线，MCU要一个JTAG，FPGA也要一个JTAG，如果能二合一的干活多好啊，就像咱的NIOS2。

　　FPGA开发，确切的说硬件系统的开发都是有赖于Primace的，软件是KEIL，它们提供了一套接口，用上去还算方便。这个Primace整个一ISE或者Quartus II的简化版，毕竟也是刚起步，勉强可以接受，怎么说咱当年在ISE10大行其道的年代也有过被迫无奈“玩转”ISE4的经历。

　　截个图，如图1，它们的开发流程也算是软硬兼施，FPGA的流程很简化，看上去很“清爽”。最终把FPGA配置文件bitgen和KeilC的Hex一起在软件里生成个新文件下载就行。

　　图1

　　开发工具真的很“简陋”。时序约束和分析特权同学还没摸懂怎么回事，就那么两三个GUI选项，只能说是比Classic timing analyzer还Classic，这一点是特权同学最担忧的；提供的板级调试手段也很有限，好像就一个称为Signal monitor的家伙，没有尝试，就不妄下定论，好在本来它的逻辑资源也不多，调试起来有没有在线手段也无关紧要。

　　51硬核性能测试

　　IO口速度测试，使用以下程序测试高电平脉宽。

　　while（1）

　　{

　　P0 = 0xf;

　　P0 = 0x0;

　　}

　　同等条件下与其他MCU比较：

　　　在两次操作之间插入延时函数，分别延时delay（1）、delay（2）、delay（3）、delay（4）。测试延时函数如下：

　　void delay（uchar cnt）

　　{

　　uchar i =0;

　　while（i 《 cnt）

　　{

　　i++;

　　}

　　}

　　由于delay（）函数调用一次会有一些额外开销（如赋初值等），所以我们通过不同延时值的实际延时差来看指令运行的速度。换句话说，对前面的程序，可以通过每次delay（）函数的差值来计算每多执行一次i++和一次i

　　特权同学曾使用相同条件测试了51单片机，通常11.0592MHz下工作的51单片机每多执行一次i++和一次i

　　延时函数ASTRO 8051硬核NIOS II/s 32位软核

　　50MHz100MHz25MHz50MHz

　　Delay（1）5.0us2.5us6.5us4us

　　Delay（2）6.6us3.3us9us6us

　　Delay（3）8.3us4.2us11.5us7.5us

　　Delay（4）9.9us5.0us14us9.5us

　　i++与i约1.63us约0.83us约2.5us约1.25us

　　简单的一些性能测试，发现这个51硬核还是有花头的，至于稳定性和可靠性上还需继续验证和尝试。当然，本文的测试是使用了片内的存储器作为代码和数据存储，实际速度性能和存储器的性能关系非常大，是需要进一步考核的项目。
 

　　存储器

　　有几点关于代码和数据存储区配置的一些疑问，麻烦解答一下：

　　问：代码存储器可以选择OTP或者extension memory，一般在最终软件定型后使用OTP没有问题，而在调试过程中会选择extension memory。extension memory里有三类：EMB、SRAM和Custom，通常代码存储器应该是非易失存储器，而你们这里列出来的EMB和SRAM都是下电易失的，这一点我不是很明白？难道说extension memory只是在KeilC处于debug模式时代码运行的存储区，而非代码下电存储的介质？EMB只有1K（最大可以到2K），如果设置了这个代码存储器，是不是KEILC DEBUG时代码不可以超过1K？

　　FAE：EMB和SRAM都是易失的，用EMB是最大可支持2KB的code空间，EMB初始化的信息与FPGA配置信息一起存储在内嵌SPI Flash中，上电自动加载，用SRAM时，需要使用我们提供的SRAMLoader工程，利用Astro重配置特性进行加载。

　　问：与上面类似的疑问，关于数据存储区，两个选项，on-ship SRAM默认勾选，这个没有疑问。而FP应该是内部扩展的4M Flash，应该是非易失存储器，数据存储器通常没有必要是非易失的吧？我认为按照常规，代码存储是非易失存储器，数据存储是易失存储器，而你们的配置选项让我有点糊涂。

　　FAE：Astro内部为8051提供16KB专用SRAM，用作data空间。

　　问：另外，SPI烧录应该是将FPGA配置数据烧录到4M FLASH中吧？而用Configuration Packer功能应该是要将FPGA配置数据和软件hex文件封装成一个文件烧录到4M flash中吧？我这么尝试过好像下电后系统没有跑起来，那么是不是在系统的存储器配置中有所讲究呢？

　　FAE：Configuration Packer可以让Astro内存储多个配置文件，利用它可以在使用SRAM做code空间时打包SRAMLoader工程进行上电自动加载。附件中是关于Astro的几个应用文档，您先看一下，写的比较详细，相信对您理解Astro用法会很有帮助，谢谢！

　　昨天对Agate Logic负责硬件的FAE狂轰滥炸，对于其开发工具和器件的结构都有更深入的了解和认识，上面的几个问答只是关于51硬核的数据和代码存储器方面的，好一番追问之后，总算逼出了几个像模像样的文档出来，消化后再做了一些实践，然后有一点收获和对后续项目在存储器配置上的一些可行性的想法。另外，关于时序方面的一些疑问也得到了解答，不是很放心，也问出了一些真真确确的“问题”来，并且目前在用软件版本的一些bug也被我问出来了，目前还需要等着厂商给我提供补丁，所以关于时序方面的博文只能暂缓进行。

　　特权同学问题提得比较到位，但不是很有水准。FAE回答得也不是很容易让人明白，最后还是文档给出了比较权威的解答。

　　在讨论Astro系列芯片51硬核的软件运行模式之前，要先看看Astro系列芯片到底已经提供了哪些片内的存储资源，不看不要紧，一看吓一跳——可谓品种齐全，满足各类需求。

　　1. 总共1Mbit的OTP型存储区，其中64KB用于FPGA的配置数据存储，另64KB用于51硬核的最终代码存储器。

　　2. 4Mbit（512KB）的FPGA和8051公用的SPI Flash。

　　3. 2块9Kbit的可配置双端口EMB。

　　4. 16KB的51硬核专用数据存储器。

　　Astro系列芯片51硬核的软件主要运行模式：

　　小模式：

　　不外挂存储器，使用芯片现有资源，FPGA配置数据和8051代码（小于2KB）存储于SPI Flash中。系统上电后，FPGA配置数据先从SPI Flash中导出并配置FPGA，也包括EMB的初始化数据（即软件代码从SPI FLASH搬运到EMB中）；完成后8051代码直接从EMB中开始运行。

　　内嵌8051在无等待周期的状态下，最快时钟频率可到70MHz，性能到47MIPS的性能。主要用于8051代码较少时，调试生产两便，成本也比较低。

　　手记二中的测试就是基于该模式，性能还算可以。

　　调试模式：

　　外挂SRAM存储器，FP Bootloader配置数据、FPGA用户程序配置数据和8051用户代码分段存储于SPI Flash中。系统上电先从SPI Flash中导出FP BootLoder配置数据（内含Loader部分）。配置FP包括EMB的初始化数据，完成后SRAM Loader程序将搬运8051用户代码到外挂SRAM中；之后再从SPI Flash中导入FP用户程序并重新配置FP，8051代码在外挂SRAM中开始运行。

　　内嵌8051在无等待周期的状态下，最快时钟频率可到35MHz，性能到23MIPS的性能。此模式主要用于8051代码超过2KB调试时用。当然也可用于生产。请注意外挂SRAM将增加成本。

　　这种模式由于不太可能使用，所以特权同学不过多研究，但这也是嵌入式系统中比较常见的一种BootLoder方式。

　　最终生产模式：

　　不外挂存储器，8051代码存储于OTP存储器中，FP配置数据存于OTP或SPI FLASH中。因为OTP存储器是一次性的，所以不能用于调试阶段。一般产品最终定型后再使用OTP存储器可以获得最优的性能和最低的成本。

　　而当采用OTP 作为8051 代码内存，最高时钟频率可达100MHz。较理想的方法是用锁相环PLL来产生8051 时钟。CKCON SFR的低4位用来控制数据Memory 的等待周期。如果8051时钟频率高于45MHz，最好将value设置为大于等于2，以防止时钟太快，数据还没准备好。

　　也就是说，OTP方式可以达到51硬核代码运行的最佳性能，甚至于性能的速度瓶颈已经不是代码存取，而是数据存取。

　　以上三种模式是比较推荐的，但是特权同学从实际工程需要来考虑，简单的说，需要一种调试模式和一种生产模式。生产模式无可厚非的选择OTP烧录，而调试模式有点棘手，如果选择小模式，代码运行量太小，顶多不过2K，基本干不了什么事。而选择外扩SRAM，有限的IO资源不会允许的。所以，有点苦恼，但是还好，还有一种最次的选择——性能低下的第四种模式。
 

　　当8051的性能低于1.4MIPS时，可用spi flash作为8051的代码存储器。此模式的运行环境如下：

　　1. 选用片内 SPI FLASH；

　　2. FPGA的配置数据和8051代码存放在同一个SPI FLASH 里；

　　3. 8051 与SPI FLASH 接口大约需要90 个LE cells；

　　4. 8051 的内核时钟最快为30MHz 左右， 8051 最快运行性能大约为1.4MIPS；

　　5. 顺序取指需要 8 个时钟周期，跳转取指需要40 个周期；

　　在尝试SPI FLASH模式的时候，遇到了比较有意思的事。特权同学根据实例做SPI FLASH的运行测试，结果搞不定，也找不到相关的IP核。于是求问FAE，FAE直接告知这个IP核还没有集成到工具中，然后把源代码都发过来了。呵呵，虽然工具不完善，不过服务倒是很周到。

　　由于基于SPI FLASH的模式是在51硬核与SPI FLASH之间使用FPGA逻辑搭建了一个FLASH读取的模块。所以经过测试，确实这个FLASH读取控制的逻辑模块频率不能太高，过高FLASH就要**了，理论值是30M，而特权同学用了25M。然后使用上一篇手记同样的方法改变硬核的频率进行测试。

　　结果证明，51硬核的频率受制于指令的读取速度，那么在SPI FLASH模式下速度性能确实大打折扣。

　　时序工具

　　关于时序工具的一些FAE解答：

　　问：你们的工具是否只提供所有输入输出管脚完全一致的时序约束？如tsu，th，tco，tpd的约束？如果不同管脚可以有不 同约束值，如何设置？

　　FAE：我们的工具提供的是时序分析功能，尚未提供时序约束功能，也就是说可以根据您输入的值作为参考，计算出当前实现的各种时序信息与参考值的差距，但并不会根据输入的值去做优化，所以也就不存在对不同管脚分别设置约束的功能了。

　　问：tco是指reg2pin的延时约束，tpd是指pin2pin的约束。而输入管脚约束tsu和th值，具体含义我不是很 明白？比如说我希望输入管脚的pin2reg延时为0-10ns，那么tsu和th如何设置？

　　FAE：tsu就可以理解为pin2reg的延时，它是信号从pin到FPGA内部第一个reg相对于这个reg的clock的setup time，而th就是相对这个clock的hold time，th一般不会有问题，需要关注的是tsu。

　　问：我尝试用GUI做了一些时序约束，然后每次做时序分析都报错：Error： T2000： （ice_run_sta） Run sta failed. 这是什么问题？

　　FAE：您的这个错误一般是sta设置上有什么问题，得具体分析工程。

　　今天终于拿到了最新3.2版本的软件，安装后，进行编译，长达近10分钟的placement让我眉头紧皱。后来从FAE处得知我拿到的是还未release出来的中间版本，有问题在所难免。不说这个，回到主题上来，其实总感觉有些遗憾。FAE在之前的回答其实已经预示着这个国产FPGA与特权同学缘分已到尽头。

　　WHY？他们提供的时序分析工具根本算不上真正的时序分析工具，或者这么说，这个所谓的时序分析工具只能提供分析，而无法进行时序的约束和优化。即便他们的工程设置中也提供了如图1的恐怕可以称得上是最简单的“时序约束”，但这个所谓的“时序约束”其实并没有任何“约束”的作用。安装“官方”的说法，它不能够对综合乃至布局布线起到任何影响，而不过是给报告中的路径划了一条水平线，报告中确实能够体现出水平线上或下的状态。

　　图1

　　如图2所示，很无奈的只是移植了一个SDRAM控制器外加一些其它逻辑，占去了总共1000个LE中80%的资源，然后只是约束了一个50MHz的工作时钟，结果出来了20条false路径。即便尝试去试试用提供的仅有几个对mapping或palcement&routing设置的优化，结果换来了更多的false。FAE也坦言，目前只能做些简单的逻辑，跑个SDRAM等稍复杂的逻辑也就只能跑个二三十兆的样子。

　　图2

　　几天的试用，虽然以国产FPGA的性能问题而告夭折。虽然还显稚嫩的开发工具、差强人意的器件性能多少让人有些失望，但至少从某种程度上让特权同学改变了对国产的一些偏见。其实，如果Agate Logic能够持续这种开发热情，不断的改进，假以时日，相信他们会成为“中国的Altera”、“中国的Xilinx”。

　　外扩SFR使用

　　本以为这个国产FPGA的就此夭折，没想到权衡之后，在性能打些折扣的情况下还是重新捡起来了。从刚接触这个器件的时候特权同学就很关心它的硬核可扩展性，Avalone接口用上手了，当然很希望这个51硬核也能够提供类似的强大扩展接口。不过话说回来，毕竟是个8位的核，再强大也不到哪去，但在花了点心思琢磨了这个小玩意的扩展方式后，多少觉得还是有点花头的。

　　SFR，即特殊功能寄存器。SFR是8051单片机内部用于访问控制各种片上集成外设的主要寄存器，如常见的IO口（P0/P1/P2/P3）读写、IO中断配置、定时器配置、串口外设等。因此，对一般用户而言，玩转8051就是玩转SFR的过程。一般的单芯片8051单片机的SFR接口不对外开放，除了部分寄存器内部使用外，余下地址空间保留。而Astro器件的这颗8051硬核将空置的SFR地址空间开放给用户，提供了专门的对外接口时序。

　　特权同学将关于Astro器件SFR相关的特性整理如下：

　　● 可寻址空间0x80~0xff。

　　● 部分地址空间已被8051内部使用。

　　● 16个地址空间（能被8整除的地址如0x80、0x88、0x90、…0xf8等）可位寻址。

　　● 最多支持49个8051核外可用SFRs，除核内已占用的地址，余下地址空间均为用户可用的核外SFRs。

　　● 外部SFR接口含有等待状态寄存器（主要由sfack信号控制实现），允许8051内核与较慢的外设连接。

　　● 外部SFR读写时序如图3所示。

　　图3

　　为了简单的评估8051硬核的SFR扩展功能的性能，特权同学做了一些测试。

　　测试1：SFR可用性测试

　　简单的用逻辑模拟一个SFR可访问的外部寄存器，该寄存器只使用低四位，对应控制4个外部LED的亮暗。以此验证核外SFR的可用性。

　　对于8051硬核而言，如果开启核外SFR功能，提供了如下接口（与前面给出的波形图对应）：

　　// External Special Function Registers interface

　　output［7:0］ sfrdatao; //8051写数据

　　output ［6:0］ sfraddr; //8051访问地址

　　input ［7:0］ sfrdatai; //8051读数据

　　output sfrwe; //8051写SFR使能信号，高电平有效

　　output sfroe; //8051读SFR使能信号，高电平有效

　　SFR从机的逻辑接口代码如下：

　　reg［3:0］ ledr; //LED指示灯对应的SFR

　　always @（posedge clk_50m or negedge rst_n） begin

　　if（！rst_n） ledr 《= 4‘h0;

　　else if（sfrwe && （sfraddr == 7’h78）） ledr 《= sfrdatao［3:0］;

　　//8051往地址为0xf8的SFR写数据，将数据锁存到ledr寄存器中

　　end

　　assign {led3，led2，led1，led0} = ledr;

　　软件编程时，需要在工程中做一个新的sfr定义：

　　//自定义SFR

　　sfr LED = 0xf8; //低4bit控制LED亮暗

　　编写函数实现SFR控制的流水灯：

　　void main（void）

　　{

　　while（1）

　　{

　　LED = 0x1;

　　delay（500）;

　　LED = 0x2;

　　delay（500）;

　　LED = 0x4;

　　delay（500）;

　　LED = 0x8;

　　delay（500）;

　　}

　　}

　　实验结果证明功能可行，达到预期。这个SFR功能的使用还是蛮简单的。

　　为了验证写功能，基本思路是想针对板载4个按键做一个SFR寄存器，专供8051内核读取当前按键值，然后把该值分别赋给4个LED（在前面测试的基础上执行）。添加的逻辑代码：

　　reg［3:0］ keyr;

　　always @（posedge clk_50m or negedge rst_n） begin

　　if（！rst_n） keyr 《= 4‘hz;

　　else if（sfroe && （sfraddr == 7’h79）） keyr 《= {key4，key3，key2，key1}; //8051从地址为0xf9的SFR读出数据

　　else keyr 《= 4‘hz;

　　end

　　assign sfrdatai = keyr;

　　读时序这个时钟clkcpu应该是8051工作的指令时钟，即8051外部输入时钟的12分频。这个时序图好像不太准确，实际读或写选通高脉冲不会保持一整个指令周期。特权同学测试下来发现用50MHz时钟做从接口，早一个时钟或是晚一个时钟周期送数据都无法使8051读走数据，只有上面给出的代码下时钟送数据才能正常保证8051锁存数据。也就是说，数据必须在读选通期间都保持稳定，早一个时钟周期撤销或是晚一个时钟周期撤销都不行。因此，为了延长数据有效长度，改进如下：

　　reg［3:0］ keyr;

　　reg keyrden;

　　always @（posedge clk_50m or negedge rst_n） begin

　　if（！rst_n） keyrden 《= 1’b0;

　　else if（sfroe && （sfraddr == 7‘h79）） keyrden 《= 1’b1;

　　else keyrden 《= 1‘b0;

　　end

　　always @（posedge clk_50m or negedge rst_n） begin

　　if（！rst_n） keyr 《= 4’hz;

　　else if（keyrden || （sfroe && （sfraddr == 7‘h79））） keyr 《= {key4，key3，key2，key1}; //8051从地址为0xf9的SFR读出数据

　　else keyr 《= 4’hz;

　　end

　　assign sfrdatai = keyr;

　　软件编程也很简单：

　　//自定义SFR

　　sfr LED = 0xf8; //低4bit控制LED亮暗

　　sfr KEY = 0xf9; //低4bit对应当前按键值

　　void main（void）

　　{

　　while（1）

　　{

　　LED = KEY;

　　}

　　}

　　测试2：SFR性能测试

　　与《国产FPGA试用手记二（51硬核性能测试）》做了类似的测试，验证LED寄存器拉高拉低的速度，和之前的结果一样。也就是说，核外的SFR在不使用等待功能的情况下与核内SFR的操作速度是一样的。

　　测试3：SFR等待功能验证

　　在50MHz的clkcpu下，没有等待时（即assign sfrack = 1‘b1;），不断的对核外SFR写使能情况可以得到如图2所示的使能信号波形。两次上升沿之间240ns即一个指令周期（12个50MHz时钟周期），而读使能信号有效高脉冲为160ns，即8个时钟周期。

　　图4

　　Datasheet中标明的sfrack信号其实无法直接从例化的51硬核中找到接口，于是特权同学干脆直接生成的IP核例化文件中把它手动引出来了，在自定义逻辑中对这个信号做了一些测试，也发现了该信号的使用方法。

　　代码如下：

　　reg［7:0］ sfcnt; //延时等待计数器，以50MHz为时钟单位计数

　　wire sfrack; //SFR 读写等待信号

　　always @（posedge clk_50m or negedge rst_n） begin

　　if（！rst_n） sfcnt 《= 8’d0;

　　else if（sfrwe） sfcnt 《= sfcnt+1‘b1;

　　else sfcnt 《= 8’d0;

　　end

　　assign sfrack = （sfcnt == 0） | （sfcnt 》 8‘d23）;

　　//等待n个指令周期，则sftcnt要大于（n*12-1）

　　该代码实现在sfrwe即SFR寄存器写选通信号到来后，用计数器sfcnt进行计数，然后相应的对需要延时等待的8051指令周期数通过控制sfrack为低电平实现。

　　分别设置了sfcnt》8’d16、sfcnt》8’d24、sfcnt》8’d23得到sfrwe的波形如图5、图6、图7所示。

　　图5

　　图6

　　图7

　　由此可见，这里延时等待的时间必须刚好是指令周期。即系统指令周期为20ns*12=240ns，那么我们外部计数周期也是20ns的情况下，一般取等待时钟数为12的倍数即可。否则就会出现图3和图4的“毛刺”，其中原因不好妄下定论，恐怕和器件本身的内部处理机制有关。

　　两个调试中遇到的小问题，引以为戒。

　　1． 画板子的时候由于没注意结构上的固定边框，不小心把一个旁路电容放在边界上。在外部铁壳将液晶屏固定到电路板上后，出现的症状很有意思。两个不同的屋子（A和B），同样的电源输入，咱的板子在A屋子若是用手触碰铁壳，液晶屏就闪一下；而在B屋子就不会出现同样的问题。问题出现后，做了一些验证和测试，初步将问题定位在液晶屏的外壳和铁壳的接地。当然，回到开始提到的旁路电容，它随算不上是罪魁祸首，但本来铁壳以及液晶屏外壳（这二者应该是固定在一起的）与电路板的地没有连在一起，而这里的电容裸露的焊盘导致了二者连接在一起了。A屋子的供电拖线板的地和大地（由人手来传导）没有连在一起，而B屋子的供电拖线板的地和大地本来就是连在一起的。因此，结论也就浮出水面：在A屋子，大地和电路板的地（也就是铁壳的地）原本没有共在一起，当人手触碰铁壳的时候，两个地连在一起了，因此导致了液晶屏显示的闪烁现象；B屋子相应就不存在此问题，因为大地和铁壳的地原本就是共在一起的，人手触碰铁壳也就不会有什么问题了。

　　2． 这是关于存储器的有效管脚被悬空引发的问题。从大学里上《数字电路》开始，就听说数字芯片不使用的管脚不可以悬空，要么接GND要么接VCC。而在实际工程中，咱可基本是“中规中矩”的照此设计，然而有些问题的出现大都不是设计者可以“算计”到的。先看看出现的问题：如果不小心用手触碰到了存储器，那么液晶屏就会出现花屏闪烁等现象。特权同学的第一感觉是虚焊了，但是多次重新加锡焊过后，问题还是时不时的出现。最终看看存储器的型号，隐约感觉到了问题出在这上面：由于原本128K的存储器由于库存问题被兼容型号的256K替代了，因此就存在一条地址线在电路中处于悬空状态。意识到这个问题后，特权同学试着用手（这是一个不好的习惯，人手的静电很可能引发新的“血案”）靠近那个悬空管脚，根本无需接触到，立马现象复现。问题的解决也很简单，要么接GND要么接VCC，还有一个更简单的办法是把这个悬空管脚和旁边的地址线短路，总之让他处于一个可控的固定状态问题就能解决。

　　接着上图，国产FPGA其实也很“给力”。当然，这和特权同学在性能与功能折中的情况下“绞尽脑汁”最大限度的“扬长避短”不无关系，也难怪芯片销售商看到效果后乐得合不拢嘴。但是后期是否能够经受住新的考验可就要看看它自己是否有真本事了。