完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
2733
|
开始了。
两个xapp1064 / xapp495都告诉我们在DIFF_PHASE_DETECTOR模式下使用iodelay在接收路径上以高达1050Mbps的速度对齐时钟/数据是多么的好（这里是关于Spartan-6的）。 我喜欢这个想法（特别是xapp495中的一个独立的每通道偏移校正，它只是很棒的东西）但同时iodelay生产勘误表（ar38408）明确指出DIFF_PHASE_DETECTOR应该用于低于400Mbps的速度以防止数据损坏。 我的理解是，我们应该将勘误信息视为最终的智慧，这意味着当使用DIFF_PHASE_DETECTOR作为时钟/数据对齐解决方案时，xapp1064 / xapp495等应该被视为限制在rx路径上的400Mbps。 我想确认一下我的理解是否正确，或者我遗漏了什么。 很高兴看到Xilinx工作人员或使用DIFF_PHASE_DETECTOR idelay模式接收速度为800 + Mbps的Spartan-6串行数据接收的直接硬件经验以及一些真实的BER测量（最后一个可能也是 很多要求:) 问候， 弗拉季斯拉夫· 附： 请注意，我明确声明“rx path”和DIFF_PHASE_DETECTOR用作时钟/数据对齐。 据了解，可以使用variable_from_zero模式和手工制作的inc / dec和训练序列（这是我目前正在工作的）实现专有的反序列化时钟/数据对齐。 以上来自于谷歌翻译 以下为原文 Here we go. Both xapp1064 / xapp495 tell us how great is it to use iodelay in DIFF_PHASE_DETECTOR mode to align clock/data on receive path at speeds up to 1050Mbps (it's about Spartan-6 here). I like the idea (especially an independent per-lane deskew in xapp495, it's just great stuff) but at the same time iodelay production errata (ar38408) clearly states that DIFF_PHASE_DETECTOR should be used for speeds below 400Mbps to prevent data corruption. My understanding is that we should treat errata information as an ultimate wisdom which means xapp1064/xapp495 and alike should be treated as 400Mbps limited on rx path when using DIFF_PHASE_DETECTOR as a clock/data alignment solution. I'd like to confirm if my understanding is correct or am I missing something. It would be great to see some feedback either from Xilinx staff or from those who had a direct hardware experience with Spartan-6 serial data receiving at speeds 800+Mbps using DIFF_PHASE_DETECTOR idelay mode with some real-world BER measurements (the last one is probably a too much to ask for :) Regards, Vladislav p.s. please note that I explicitly stated "rx path" and DIFF_PHASE_DETECTOR use as a clock/data alignment. It's understood that one can implement a proprietary de-serialization clock/data alignment using variable_from_zero mode and hand-crafted inc/dec and training sequence (which is what I am working at the moment). 
0
|
|
相关推荐
8个回答
|
|
|
弗拉季，
是的，根据掩码集（如勘误表中的详细说明），您应该使用适当的指导（文档，答案记录）。 Austin Lesea主要工程师Xilinx San Jose 在原帖中查看解决方案 以上来自于谷歌翻译 以下为原文 Vladislav, Yes, depending on the mask set (as detailed in the errata), you should use the apporpriate guidance (documents, answer records). Austin Lesea Principal Engineer Xilinx San JoseView solution in original post |
|
|
|
|
|
N，
你仔细看过了吗？ “本答复记录描述了先前屏蔽修订设备的行为。有关新屏蔽修订设备的详细信息，请参阅（Xilinx答复41083）” 查看答案41083以获取最新的面具集。 Austin Lesea主要工程师Xilinx San Jose 以上来自于谷歌翻译 以下为原文 n, Did you read this carefully? "This Answer Record describes the behavior of the Previous Mask Revision Devices. See (Xilinx Answer 41083) for details regarding the New Mask Revision Devices" Look at answer 41083 for the latest mask set. Austin Lesea Principal Engineer Xilinx San Jose |
|
|
|
|
|
感谢您的回复，Austin！您引用的答案记录（Xilinx答案41083）提供了无错误数据速率限制的更新，以及有关MTBF和BER的详细信息，当超出无错误限制运行时更新
掩模硅。 即使对于更新的掩模硅，无错误限制低于'广告'950 / 1050Mbps，我们正在读取xapp1064 / xapp495。 例如，在标准vccint中，对于-2C / -3C等级，新的掩模硅限制为667 / 800Mbps。 还有一个机会我不是唯一一个在现有硬件上工作的老面膜硅:) 为了使一切都清楚，我可以要求确认以下内容： 当在DIFF_PHASE_DETECTORmode中使用iodelay2时，我们应该从erratas（较旧的掩码400Mbps，新掩码667 / 800Mbps -2C / -3C）获取无差错数据速率限制，而不是使用xapp1064 / xapp495中引用的950 / 1050Mbps值。 问候， 弗拉季斯拉夫· 以上来自于谷歌翻译 以下为原文 Thanks for your reply, Austin! The answer record you've referenced (Xilinx Answer 41083) gives an update of error-free data-rate limits as well as detailed information on MTBF and BER when operating beyond error-free limits for use with updated mask silicon. Even for updated mask silicon error-free limits are below 'advertised' 950/1050Mbps we're reading in xapp1064 / xapp495. For example, at standard vccint new mask silicon limits are 667/800Mbps for -2C/-3C grades respectfully. There's also a chance I'm not the only one here working on the existing hardware with an older mask silicon :) Just to make everything absolutely clear, may I ask to confirm the following: When iodelay2 is used in DIFF_PHASE_DETECTOR mode we should take error-free data rate limits from erratas (older mask 400Mbps, new mask 667/800Mbps -2C/-3C) instead of using 950/1050Mbps values referenced in xapp1064 / xapp495. Regards, Vladislav |
|
|
|
|
|
弗拉季，
是的，根据掩码集（如勘误表中的详细说明），您应该使用适当的指导（文档，答案记录）。 Austin Lesea主要工程师Xilinx San Jose 以上来自于谷歌翻译 以下为原文 Vladislav, Yes, depending on the mask set (as detailed in the errata), you should use the apporpriate guidance (documents, answer records). Austin Lesea Principal Engineer Xilinx San Jose |
|
|
|
|
|
感谢您确认勘误值优先于应用笔记值，Austin。如果我要求您将此信息转发给负责应用笔记修订更新的人员，那么它是正确的，因此实际的无错误数据速率限制将是
应用笔记中引用的xapp495 xapp1064或对勘误/答案记录的引用将包含在上述应用笔记中？ 这个想法是为了防止进一步的混乱。弗拉迪斯拉夫 以上来自于谷歌翻译 以下为原文 Thanks for confirming that errata values have the priority over application note values, Austin. Would it be correct if I will ask you to forward this information to a person responsible for application note revision updates so the actual error-free data rate limits will be either referenced in application notes xapp495 xapp1064 or a reference to errata/answer record(s) will be include in mentioned application notes? The idea is to prevent further confusion. Regards, Vladislav |
|
|
|
|
|
做完后，
Austin Lesea主要工程师Xilinx San Jose 以上来自于谷歌翻译 以下为原文 Done, Austin Lesea Principal Engineer Xilinx San Jose |
|
|
|
|
|
nicetyproject写道：感谢您确认勘误表值优先于应用程序注释值，Austin。如果我要求您将此信息转发给负责应用程序注释修订更新的人员，那么它是正确的，因此实际的无错误数据速率限制
将在应用笔记xapp495 xapp1064中引用，或者在提及的应用笔记中包含对勘误/答案记录的引用？ 这个想法是为了防止进一步的混乱。弗拉迪斯拉夫 你好弗拉迪斯拉夫， 为了阅读本主题的任何人的利益，我只是想让您知道，将来，如果您在App Notes中发现错误，您可以使用以下方法自行报告问题： 导航至www.xilinx.com>支持>产品支持和文档 单击“应用笔记和白皮书”选项卡 单击“查看所有应用程序说明”链接 HitCtlf-Fand在“查找”框中输入相关的应用程序注释编号 单击问题旁边的“否”，“此文档是否有用？”。 填写退回的表格并提交。 Xilinx的政策是对通过此机制收到的所有意见采取行动。 由于没有与我们的用户社区相关的服务级别或保证，论坛也不能这样说 在这种情况下，作为一次性，我代表您提交了意见（针对XAPP 1064和495）。 问候， 卡罗琳 以上来自于谷歌翻译 以下为原文 nicetyproject wrote: Hello Vladislav, For the benefit of anyone reading this topic, I just wanted to let you know, that in future, if you find errors in App Notes, you can use the following method to report the issue yourself: Navigate to www.xilinx.com > Support > Product Support and Documentation Click on the" App Notes and White Papers" tab Click on the "See All Application Notes" link Hit Ctlf-F and enter the relevant App Note number in the "Find" box Click on the "No" next to the question, "Was this document useful?". Complete the returned form and submit. Xilinx has a policy to act on all the comments received via this mechanism. The same cannot be said for the Forums, as there are no service levels or guarantees associated with our User Community In this case, and as a one-off, I have submitted the comments on your behalf (for XAPPs 1064 and 495). Regards, Caroline |
|
|
|
|
|
感谢您的updateCaroline！
我们非常感谢您提交评论的帮助。 在将来的情况下，我会按照您的指示。 再次感谢大家对此案件的帮助。 问候， 弗拉季斯拉夫· 以上来自于谷歌翻译 以下为原文 Thanks for your update Caroline! Your help with submitting the comments are highly appreciated. In the future cases I will follow your instructions. Thanks again for everyone for help on this case. Regards, Vladislav |
|
|
|
|
只有小组成员才能发言，加入小组>>
2416 浏览 7 评论
2821 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办？
2292 浏览 9 评论
3372 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区？
2459 浏览 15 评论
有输入，但是LVDS_25的FPGA内部接收不到数据，为什么？
1153浏览 1评论
请问vc707的电源线是如何连接的，我这边可能出现了缺失元件的情况导致无法供电
583浏览 1评论
求一块XILINX开发板KC705，VC707，KC105和KCU1500
449浏览 1评论
2004浏览 0评论
728浏览 0评论
/6 
关注我们的微信
下载发烧友APP
德赢Vwin官网 观察
版权所有 © 湖南华秋数字科技有限公司
德赢Vwin官网 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
评论
淘帖
3424
