鲁达 工作的日报是个小宝藏，我干完一个活之后重新看，就能发现之前没注意的问题，并且有全局的感受。所以今日的文章是把工作日报重新整理编写，留下记录。
这一部分是做一个视频采集老项目的现场调试，没有什么新东西，就是把调通的功能调完备，即和应用软件联调，我向我的内部客户讲明白自己的设计思路，顺便测试硬件有没有问题。还有一个我自己想做的视频采集项目加检测的功能，属于自我的探索，技术储备。两个活属于同一个技术领域，相似度很高。
Day1
调试项目时发现的问题：视频无法关闭后重开。最终定位的问题是逻辑版本不对，逻辑重烧之后，就解决了。并调试成功了1路视频（算是打好了基础，1路通了其他的路数就不远了）。
纠正措施是项目管理的人没有规定板卡编号，无法核对烧录版本，我以后交付前均重新烧录，确保版本对。
Day2-4
从调通1路到调通所有路，这是个艰难的过程，我在其中起的作用是一遍遍地配合，接线、输入指令、看怎么样的环境运行结果是最好。
主要用到脑子的活是说服别人不要瞎改，方案中有一些固有的连接方式、使用方式没法改，他们不知道，我就整理好语言、画上图、标上123的顺序给他们讲明白，这样别人就不会要求我做我做不到事情。我做出了不少让步，不能光我这边调着方便，别人的方便也要照顾到，总之是为了共同的目标，大家各让一步。问题的核心修改不在我这，看着别人去查和定位问题就可以了，最终的解决方案都不是那么完美，规避了最易故障的情形，让性能在可以接受的情况即可。
Day5-6
我抽了一些时间把调试记录整理出来了，抄送给了负责人。这里面有每一次我测或者调的详细记录，如实地记了当时的测试环境，记下了工作量，也是好的一手资料，以后用来写写案例文档，有思路和依据。
之后的时间我回到自己的拓展性的项目，因为需要自己去要活干，而不是只被动地接受任务。和领导聊过感受了领导的需要，加上我自己的感受，新的项目不是那么多，难的活领导也不放心给我们这样的新手干，自己去琢磨和演示个实实在在的功能，就变得尤为重要。
我记录的一个有趣的调试现象：在板卡上用监视功能ila实测抓取信号，加电运行的过程中，拔掉相机Cameralink线,看监视结果的界面报错，就不能运行了。
[Xicom 50-38] xicom: Unable to connect todebug core(s) on the target device. Check cable connectivity and that thetarget board is powered up then use the disconnect_hw_server andconnect_hw_server to re-initialize the hardware target. Use open_hw_target tore-register the hardware device.
我自己分析：可能的原因是我ila用的是CL1_CLK，拔掉cameralink线后时钟就没有了；
但Ila用的时钟改成clk_sys之后，拔掉cameralink线后，还是有同样的问题。
解决的方法是拔掉相机的电源线，ila可以正常运行，不报错。
拔这个线的目的是让相机的数据源没了，因为这是要调试的功能。我通过这样的尝试，达到了结果，就是原因不知道到底是什么。
Day7-9
修改cameralink检测工程代码，生成bit文件2个版本：（1）只看CAMERALINK第一路的场有效、行有效、数据有效，（2）28bit的CAMERALINK接口的每一位都抓取。
上板子调试，观察目前的逻辑采集摄像机视频，不是符合理想视频的场行信号，场有效在数据有效的时候还有不定期的低电平，行有效、数据有效在所以我的短线检测去读取场有效为0的时候就不准。从显示的效果来看，分成了上下两屏，场行信号都在叠加。决定先增加Bayer的功能，把视频显示正确，再去调试检测功能。
这个是个难点，我尝试了很多修改的地方，都没能解决。后来找到了同事以前做过的工程，找到了两个版本，第二个版本里面的下载文件，用同样的相机同样的连线方式，视频显示就是正常的，但我的怎么都不行。
我按第一个版本改过，后来发现第一个版本的下载文件有问题，发现第二个版本下载文件好用，又按照第二个版本改的。其中还穿插别人来参观，我被要求一会儿测一个什么结果，记录一些表格，被打断得比较厉害，只能断断续续地能做我的调试。
直到调试环境被其他的任务征用，我做了做体力活往其他地方搬走设备，在其他地方做演示。我的调试暂停，等有机会，还是要继续试，看我的工程与别人的工程哪里不一样，把出现问题的地方找出来。
视频采集领域总结
视频采集领域，我做过的工作是cameralink协议和sdi协议的视频采集处理，把感受和理解总结如下。
Sdi协议是有SMPTE标准的，串行的一对线就可以传输视频信号，场、行有效和数据信号都是在一对线里面的，做处理的时候要串并转换。
Cameralink协议是定制化的，一些相机厂家联合，但标准也不愿意特别的公开，网上的资料在往下撤。
Cameralink协议是LVDS协议的子集，LVDS协议定义了线缆的电气标准，具体到相机领域，cameralink协议在此基础上增加了一些定义。商用相机基本上都是传感器输出的raw信号，要经过拜耳转换，才能成为RGB协议的像素。如果高度定制化，LVDS协议的相机，传输直接是RGB协议，就不用拜耳转换了。这是性能、价格等的综合考量。
还有一种常见，但我没做过的协议是HDMI,这个一般与SDI会对应着说。HDMI最大的应用特点是消费类的电子设备，它是可以同时传声音，在家用的电视、电视盒子、笔记本电脑等电器上最常用。而且因为和节目源有关，它还能够起到支持版权节目的用途，所以电影电视用它传，各方都愿意推进。
它最大的缺点是传输距离短，一般在家里看到的HDMI线，一两米就很可以了，一旦长了信号就不好，最大传输30米之内，而且HDMI线缆很贵，长距离传输用它质差价贵。
此时就会有SDI登场，广播电视领域几乎都是SDI，传输距离大，最大距离100米，线缆也便宜，就是普通的铜缆。SDI不能传输压缩的信号，但它的带宽不断拓展，应用前景很好。
2015年正式发布了串行数据接口的6G-SDI和12G-SDI。6G-SDI面向2160p30的应用，对应每秒30帧画面的刷新。而12G-SDI面向2160p 60（俗称真4K）的应用，对应着每秒60帧画面的刷新。
扩展屏幕显示问题和讲不清自己设计的问题
（一）扩展屏幕显示问题
电脑硬件上解决的问题：
扩展笔记本的屏幕，笔记本是vga接口，屏幕是hdmi接口，就买了一根vga转hdmi转接线，它还是带个USB口，我发现必须USB口插在电脑上，才可以用。屏幕是一个长比宽大很多的屏，看仿真波形方便。但连上的扩展屏分辨率很奇怪。
屏幕在上电之后会有提示需要2560*1080 60hz，我就查自己的笔记本能不能支持（默认的里面是没有的），结果发现它的显卡是核显（集成到CPU里面的）型号HD Graphics 3000，虽然支持2560*1080，但只能支持DP接口，我的屏幕没有，就怎么也没办法了。我就在默认的分辨率里面选，相对最合适的分辨率是2048*1152。
（二）和不同领域的专家讨论问题，感觉自己能说一些，但无法为自己的话确认，需改进
驱动领域的专家，问我一些他对逻辑和交换测试的问题 我们原来的测试6个sdi摄像头的视频分别放在3个浏览器上，每个浏览器的每个端口接受一路，这个对于交换机来讲没有压力，是A口发C口，B口发D口，都是一一对应。这个交换机处理很轻松，只不过受到最多传输几路的物理限制。如果改为6个摄像头视频发到同一个浏览器上，一对多的端口，这样交换机估计就承担不起了。
他问如果其他部分不动，我的板卡逻辑可以改，能不能实现动态的配置，使3路视频可以通过一路的端口依次发送，这样可能就解决了刚才说的交换机压力的问题。我觉得不行，没办法我的一路视频采集接口分段地让三路视频用，我现在逻辑里没有视频的缓存空间，他的提案在我理解就是加流水级数，我得把逻辑打断，比如调用的通信IP可能就要打断，里面插入流水寄存器，需要的资源不少，且IP我也改不了。或者就是扩充逻辑资源，用三块板卡或者大容量FPGA容纳三个我的逻辑。
他又问能不能动态来复位、改逻辑的配置寄存器，我理解只能是顶层的管脚信号改变，才可以，比如逻辑代码中加开关，绑在拨码开关上，运行中拨动拨码开关，复位重启相应的部分，可以做到切换，但还是要FPGA容量大，可以同时容纳这么多的逻辑。逻辑到底是如何初始化的，这块我不太清楚 K7有多少的bank?什么资源？电路工程师设计板子的时候怎么考虑的？
这一部分的工作日志是做一个高速串并转换模块的动态重配置（drp）的功能的探索，之前我的项目中有提出想用，因为可以节约资源、适配更多的环境，但同事们没有做过的，说也比较麻烦，需要仔细去看器件手册。我想挑战一下，而且高速串并转换模块在fpga领域是很常用也很关键的技术点，我想借此把它吃透。
Day1-3
搜索“如何仿真xilinx gtx”
这个测试挺有意思，gtx ip直接生成example project，生成bit，可以用连接线接上连个serdes的一收一发换回，或者设置内部环回，或者在两片FPGA上做实验。
最后，把vivado lab tools勾上，这样才可以生产example desgin工程可以参考。这个后续用的特别多，因为这是为数不多的能找到源码的资料，全靠它来一边摸索一边猜，drp功能怎么调。
做这个自我探索的项目，是因为我手上还有一个能够实测的电路板及辅助的硬件环境，可以研究drp。
看到网上介绍自适应drp，有人提到sdi gtx的三速率七速率设计，进而找到用Virtex-6 FPGA GTX 收发器实现三倍速率SDI的文档，是xilinx的官方文档ug823_v6_triple_sdi，介绍v6_triple_sdi IP核，我想我可以参考这个，在已有的sdi视频采集的逻辑里加入自适应sdi速率的内容。
在工程中加入drp信号的vio，ila没加成功，待生成好bit后在hardware manager中看波形。结果发现高速信号不能用ila,问了培训班认识的老师，才知道要用IBERT这种调试工具，而且老师强烈建议把example design看明白。我想多提问，也要有基础才行，于是就好好研究example design和gxt的官方手册ug476.
Day4-6
研究drp改变gtx ip线速率的功能，生成了xilinx example design. gtx ip optional ports 可以所有reset相关端口都勾上，这是之前sdi项目没有勾选，所以没有生成这些端口。用仿真来调试gtx ip复位的工作过程，做了四次仿真，cpllreset之后 cpllock信号可以出现，写的用户复位softreset没起到作用，还有pma部分的reset也没起到作用，查阅手册Ug476,对复位的概念和代码编写，继续学习和尝试。
从gtx ip的tx部分入手，把ug476 chapter3的内容与xilinx的example design 对应来看，时钟和复位信号的连接关系、时序、传递捋一遍，重点看gtwizard_0_TX_STARTUP_FSM的模块代码，与我的仿真对应，查找复位时状态机的正确顺序。
学习gtx的示例工程，gtx的tx部分哪些时钟和哪些复位对我想做的线速率动态配置有影响，看到示例工程中调用gtxe2_channel原语，与原来用过的sdi项目的原语（用的gtx rx部分，比tx部分略复杂）对比；看ug476中PCIE的复位例子。
Day 7
1 生成gtx rx的示例工程，因为直接跑仿真报错，因为没有tx部分的源，所以我增加了tx部分作为信号源，也改了部分drp的代码。
2 发现的问题是gtx的rx+tx的仿真特别慢，占满内存，没有跑出结果来，就换到科研网调试机中进行仿真测试，其实早期可以发现问题，直接读目录下的elabora就可以，不用等仿真的结果。
另外drp的读写有一处不明白，xilinx手册中的pcie协议线速率调整的例子，drp读或写，要操作gt0_drpaddr_in和gt0_drpdi_in，这是个引发读或写的操作，与实际每次要通过drp读写的具体数据，是否会冲突，因为也是操作gt0_drpaddr_in和gt0_drpdi_in，它们的时序关系是什么样子的，手册上没有。
Day8
从网上找到一个gtp ip的drp的状态机代码，是很好的参考，我看明白里面的读写步骤之后，写仿真文件对它进行仿真，查看drp接口的读写结果。因为xilinx ug476手册中没有详细的drp操作时序，只有定性的描述，我结合这个代码不断进行实验，看drp的读写结果是否符合预期。难点在于drprdy信号什么时候给，与外接的复位信号的关系不明，手册上没有讲，在继续试验中。