有一些风险回复，因为有很多细节需要准确回答这个问题。
我可以提供一个简单的我可以使用的球场计算。
如果此计算的余量变小，则需要实现并验证静态时序并使用IBIS模型模拟IO。源或系统同步，IO标准，布局，抖动，IO延迟，SDR或DDR ......等所有因素都可以
影响时序计算，但这里是一个'在球场'的方程式，可以根据一些假设使用.FPGA中的可用余量=周期 - （DDR IOB的设置时间+ DDR IOB的保持时间+最差 -
案例包偏斜+时钟抖动+占空比失真+系统抖动）参考数据表和应用说明OK和猜测某些事情:-)假设源同步对齐时钟和数据，假设LVCMOS25 IO标准，输入时钟= 300MHz，50ps
抖动，系统抖动= 150ps，Spartan3封装偏斜，我找不到= 200ps，= 3.33 - （1.89 - 0.55 + 0.150 + 0.200 + 0.400 + 0.150）= 3.33 - 2.24 = 1.09假设源同步关系，输出更多
简单。
系统时序不是那么简单，因为您只需从FF输出数据并使用FF重现时钟，因此输出路径是匹配的。
数据边缘在彼此的抖动和封装偏斜内是一致的。
如果输入有效，则假设输出有效是相当安全的。
更多的是模拟缓冲驱动能力，以确保缓冲区可以驱动输出网络....输入时钟@ 300MHz必须在DCM之前使用除以2的能力，然后使用DCM的2X输出返回
到300MHz。
鉴于粗略估计方法，似乎有足够的余量。
数据表和应用说明似乎支持这一点。至于更快的速度，这些假设可能会留下更多。
IOB FF可能很容易达到4个FF，以降低内部频率。
在相对完整的设计中，100MHz应该相当直接。
您可以获得333,350 SDR。要验证数字，创建设计并通过工具运行它。
使用时序分析器查看静态时序。
可能值得对您的IO和系统设计参数进行IBIS仿真，以了解SI如何受到影响以及如何影响时序预算和假设。希望这会有所帮助。
以上来自于谷歌翻译
以下为原文
There is a bit of risk replying as there are many details required to accurately answer this. I can offer a simple am I in the ballpark calculation that can be used. If margin on this calculation gets small, you need to implement and verify static timing and simulate the IO using IBIS models.
Factors like source or system synchronous, IO standard, layout, jitter, IO delay, SDR or DDR....can all affect the timing calculations but here is a 'in the ballpark' equation that can be used based on some assumptions.
Available margin at/in the FPGA = Period – (setup time at the DDR IOB + hold time at the DDR IOB + worst-case package skew + clock jitter + Duty-cycle distortion + system jitter)
Referring to data sheets and appnotes OK and maybe guessing at some things :-)
Assume source synchronous aligned clock and data, assume LVCMOS25 IO std, input clock = 300MHz with 50ps jitter, system jitter = 150ps, Spartan3 package skew that I couldn't find=200ps,
= 3.33 – (1.89 – 0.55 + 0.150 + 0.200 + 0.400 + 0.150)
= 3.33 - 2.24
= 1.09
Assuming source synchronous relationship, the ouput is more simple. The system timing is not as involved as you are simply clocking out data out of a FF and using a FF to reproduce the clock so output paths are matched. The data edges are coincident within jitter and package skew of one another. If the input will work, it is fairly safe to assume the output will work. It is more of a analog buffer drive ability to make sure the buffer can drive the output network....
The input clock @ 300MHz would have to use the divide by 2 capability before the DCM and then use 2X output of DCM to get back to 300MHz.
It appears that is enough margin given the rough estimate approach. Data sheets and appnotes seem to back this.
As for more speed, there is likely more left given these assumptions. The IOB FF could likely reach 4 FFs easily to reduce internal frequencies. 100MHz should be fairly straight forward in a relatively full design. You may be able to get 333, 350 SDR.
To verify the numbers, create a design and run it through the tools. Use Timing Analyzer to look at static timing. May be worth running an IBIS simulation of your IO and system design parameters to see how the SI is affected and how that affects timing budget and assumptions.
Hope this helps.
有一些风险回复，因为有很多细节需要准确回答这个问题。
我可以提供一个简单的我可以使用的球场计算。
如果此计算的余量变小，则需要实现并验证静态时序并使用IBIS模型模拟IO。源或系统同步，IO标准，布局，抖动，IO延迟，SDR或DDR ......等所有因素都可以
影响时序计算，但这里是一个'在球场'的方程式，可以根据一些假设使用.FPGA中的可用余量=周期 - （DDR IOB的设置时间+ DDR IOB的保持时间+最差 -
案例包偏斜+时钟抖动+占空比失真+系统抖动）参考数据表和应用说明OK和猜测某些事情:-)假设源同步对齐时钟和数据，假设LVCMOS25 IO标准，输入时钟= 300MHz，50ps
抖动，系统抖动= 150ps，Spartan3封装偏斜，我找不到= 200ps，= 3.33 - （1.89 - 0.55 + 0.150 + 0.200 + 0.400 + 0.150）= 3.33 - 2.24 = 1.09假设源同步关系，输出更多
简单。
系统时序不是那么简单，因为您只需从FF输出数据并使用FF重现时钟，因此输出路径是匹配的。
数据边缘在彼此的抖动和封装偏斜内是一致的。
如果输入有效，则假设输出有效是相当安全的。
更多的是模拟缓冲驱动能力，以确保缓冲区可以驱动输出网络....输入时钟@ 300MHz必须在DCM之前使用除以2的能力，然后使用DCM的2X输出返回
到300MHz。
鉴于粗略估计方法，似乎有足够的余量。
数据表和应用说明似乎支持这一点。至于更快的速度，这些假设可能会留下更多。
IOB FF可能很容易达到4个FF，以降低内部频率。
在相对完整的设计中，100MHz应该相当直接。
您可以获得333,350 SDR。要验证数字，创建设计并通过工具运行它。
使用时序分析器查看静态时序。
可能值得对您的IO和系统设计参数进行IBIS仿真，以了解SI如何受到影响以及如何影响时序预算和假设。希望这会有所帮助。
以上来自于谷歌翻译
以下为原文
There is a bit of risk replying as there are many details required to accurately answer this. I can offer a simple am I in the ballpark calculation that can be used. If margin on this calculation gets small, you need to implement and verify static timing and simulate the IO using IBIS models.
Factors like source or system synchronous, IO standard, layout, jitter, IO delay, SDR or DDR....can all affect the timing calculations but here is a 'in the ballpark' equation that can be used based on some assumptions.
Available margin at/in the FPGA = Period – (setup time at the DDR IOB + hold time at the DDR IOB + worst-case package skew + clock jitter + Duty-cycle distortion + system jitter)
Referring to data sheets and appnotes OK and maybe guessing at some things :-)
Assume source synchronous aligned clock and data, assume LVCMOS25 IO std, input clock = 300MHz with 50ps jitter, system jitter = 150ps, Spartan3 package skew that I couldn't find=200ps,
= 3.33 – (1.89 – 0.55 + 0.150 + 0.200 + 0.400 + 0.150)
= 3.33 - 2.24
= 1.09
Assuming source synchronous relationship, the ouput is more simple. The system timing is not as involved as you are simply clocking out data out of a FF and using a FF to reproduce the clock so output paths are matched. The data edges are coincident within jitter and package skew of one another. If the input will work, it is fairly safe to assume the output will work. It is more of a analog buffer drive ability to make sure the buffer can drive the output network....
The input clock @ 300MHz would have to use the divide by 2 capability before the DCM and then use 2X output of DCM to get back to 300MHz.
It appears that is enough margin given the rough estimate approach. Data sheets and appnotes seem to back this.
As for more speed, there is likely more left given these assumptions. The IOB FF could likely reach 4 FFs easily to reduce internal frequencies. 100MHz should be fairly straight forward in a relatively full design. You may be able to get 333, 350 SDR.
To verify the numbers, create a design and run it through the tools. Use Timing Analyzer to look at static timing. May be worth running an IBIS simulation of your IO and system design parameters to see how the SI is affected and how that affects timing budget and assumptions.
Hope this helps.
举报
举报
