模块实例化异常

这类问题最常见的来源是时机。
即使所有的LUTS，触发器，携带链，
等等相同，模块的每个副本都会有不同的路由延迟。
这可以产生
如果设计中存在任何不受约束的路径，并且如果您具有异步，则会出现问题
信号，例如在设计的各部分之间穿过时钟边界。
在一个副本中
异步信号到一个特定端点的路由可能比另一个特定端点短，
在另一个副本中，等效异步信号可能具有到a的较短路径
不同的端点导致不同的行为。
确保你有受限制的输入和
输出时序以及内部时序（周期约束）和任何时钟边界
交叉处理得当，即任何异步信号都不应超过
对于给定时钟，D触发器的一个端点。
如果您的时序差异与输入/输出相关，则可获得最一致的结果
当你将所有输入和输出寄存器推入IOB时。
当然相对位置
对模块的每个副本的IOB都会影响内部时序，所以有一些权衡。
该
设置工具以尝试根据需要放置输入和输出寄存器以满足约束。
这就是为什么OFFSET进出约束如果你离开IOB就特别重要
包装在正常的“AUTO”状态下。
HTH，
的Gabor
-  Gabor



以下为原文

The most common source of this sort of problem is timing.  Even if all of the LUTS, flip-flops, carry chains,
etc. are identical, there will be different routing delays in each copy of your module.  This can produce
problems if there are any unconstrained paths in the design, and also if you have asynchronous
signals, for example crossing clock boundaries between sections of the design.  In one copy
the asynchronous signal may have a shorter route to one particular endpoint than another,
and in the other copy the equivalent asynchronous signal may have the shorter route to a
diffferent endpoint causing different behavior.  Make sure you have constrained input and
output timing as well as internal timing (period constraints) and that any clock boundary
crossings are handled properly, i.e. any asynchronous signal should have no more than
one endpoint at a D flip-flop for a given clock.
 
If your timing differences turn out to be input/output related you get the most consistent results
when you push all of your input and output registers into the IOB's.  Of course the relative location
of IOB's to each copy of the module can affect internal timing, so there is some trade-off.  The
tools are set up to try to place input and output registers as required to meet the constraints.
This is why OFFSET in and out constraints are especially important if you leave the IOB
packing in its normal settins of "AUTO".
 
HTH,
Gabor
-- Gabor

感谢Gabor提供的信息，
我必须承认，我对正确约束我的项目的知识几乎没有。
不幸的是，当我第一次介绍FPGA技术时，在学校里很少提到它，而且我还没有找到一个适当的文档/教程，我可以将其与我正在开发的设计类型联系起来。
目前，我设计中唯一的时序约束是75MHz的全局时序约束，这是我的系统时钟。
我之前提到的8个实例化模块每个都有一个SPI端口接口，用于在外部ADC器件之间发送/传输数据。
模块的SPI接口部分使用带有一些外部逻辑的picoblaze完成。
收集数据后，它将通过由外部微处理器配置的大型多路复用系统，该系统选择是否过滤数据。
使用MAC（乘法和累加），BRAM（块RAM）和另一个picoblaze（我在我的设计中使用大约20个picoblazes ...进行过滤完成了picoblazes）。
然后将最终结果存储在外部微处理器可访问的信号上以进行进一步处理。
目标是将所有劳动密集型处理从微处理器卸载到FPGA。
与系统的其余部分（picoblaze，滤波等）相比，SPI通信非常慢（大约1MHz）。
由于这种时间差异，我不完全确定如何限制设计。
FPGA始终是SPI端口上的主设备，这使我认为设计是同步的（基于相同的时钟）。
此外，外部75MHz FPGA时钟由微处理器生成，这也意味着它们都是同步的。
P.S。：我基于Xilinx应用笔记的SPI通信方法：Spartan-3E入门套件的放大器和A / D转换器控制
http://www.xilinx.com/products/boards/s3estarter/files/s3esk_picoblaze_amplifier_and_adc_control.pdf）
有什么想法吗？
最好的祝福，
涡流



以下为原文

Thank you Gabor for the information,
 
I must admit that my knowledge of properly constraining my project is little to none. Unfortunately it is something that was very little mentioned at school when I was first introduced to FPGA technology and I have still not found a proper document/tutorial that I can associate with the type of design I'm currently developing. At the moment, the only timing constraint I have in my design is a global timing constraint of 75MHz, which is my system clock.
 
The 8 instantiated modules I previously mentioned each have a SPI port interface which is used to send/transmit data between an external ADC device. The SPI interface portion of the module is done using a picoblaze with some external logic. Once data is collected, it goes through a large multiplexing system configured by an external microprocessor that selects if data is filtered or not. Filtering is done  using a MAC (multiply and accumulate), BRAM (block RAM) and another picoblaze (I'm using about a total of 20 picoblazes in my design... got to love does picoblazes). The final result is then stored  on a signal which is accessible to the external microprocessor for further processing. The goal is to offload all labor intensive processing from the microprocessor to the FPGA.
 
The SPI communication is very slow (in the order of 1MHz) compared to the rest of the system (picoblaze, filtering, etc.). Because of this timing difference, I'm not entirely sure how I should constrain the design. The FPGA is always the master on the SPI ports, which makes me think that the design is synchronous (based on the same clock). Furthermore, the external 75MHz FPGA clock is generated by the microprocessor which also means that they are both synchronized.
 
P.S.: I based my SPI communication method on the Xilinx application note: Amplifier and A/D Converter Control for Spartan-3E starter Kit
http://www.xilinx.com/products/boards/s3estarter/files/s3esk_picoblaze_amplifier_and_adc_control.pdf )
 
Any thoughts?
 
Best regards,
 
Eddy

大家好，
有没有人对我的第一篇和最后一篇文章有​​任何意见？
我希望有人指导我正确配置我的项目的时间限制，以消除我看到的gszakacs建议的问题。
问候，
涡流



以下为原文

Hi all,



Does anyone have any comments regarding my first and last post? I would like someone to perhaps guide me to properly configure the timing constraints of my project in order to eliminate the problems I'm seeing as gszakacs suggested.



Regards,



Eddy
 

大家好，
为了澄清我的项目结构，我已经制作了一个非常基本的架构框图。
实际上，设计要复杂得多，但我相信框图清楚地说明了我所处的情况，我不完全确定如何正确配置时序约束。
任何意见/建议将不胜感激。
问候，
涡流



以下为原文

Hi all,
 
in order to clarify my projects structure, I have made a VERY basic block diagram of its architecture. In reality, the design is much more complicated, but I believe that the block diagram clearly illustrates the situation I have where I'm not entirely sure how to properly configure the timing constraints.
 
Any comments/suggestions will be greatly appreciated.
 
Regards,
Eddy
 
 
 
 

eddyfraga写道：
大家好，
我目前正在使用Xilinx ISE 11.x开展一个项目（在此项目完成并正常工作之前不会升级到12）。
该项目包含一个非常大的模块，由几个较小的模块和IP核组成。
大模块在设计中实例化8次。
所有8个模块最终都被路由到顶层的输入/输出引脚。
在评估硬件中的实际设计时，我经常会遇到问题，其中8个实例化模块中的1个或2个不工作或部分工作，尽管所有其他实例化模块都工作正常。
不幸的是，这个问题永远无法在模拟中重现。
我的假设是，当FPGA设计被合成时，并非所有实例化模块都完全相同，这可以解释为什么某些模块正在工作而其他模块不工作（即使它们具有完全相同的HDL代码）。
第一个问题：在设计超大型模块化项目时，这是所有FPGA设计人员面临的常见问题吗？
第二个问题：如果我对模块进行分区，是否会以相同的方式合成所有其他实例化的模块？
如果是这样，这种技术会确保所有实例化的模块都具有恒定的功能吗？
最后一个问题：是否有其他工具/技术可用于减少/消除我所看到的问题类型？
提前感谢您提供相关信息！
涡流
好吧，我的最后三个设计每次都会实例化我的SPI主模块，而且我没有让它们正常工作的问题。
这些设计还实例化了三个Camera Link发射器实体，并且再次出现零问题。
我也没有在约束方面做任何特别的事情。
通过适当的注意 - 意味着模块的所有输入和输出都已注册，并且您已经适当地处理了时钟域交叉（如果需要） - 那么您可以预期合成逻辑在所有情况下都是相同的。
当然路由会有所不同，但你的时间安排应该涵盖这一点。
你说你无法在模拟中复制问题。
所以我假设您没有模拟导致特定模块失败的情况。
您应该返回模拟并在模块中输入无效输入，看看会发生什么。
我会使用ChipScope查看故障模块的输入和输出，并将它们与工作模块进行比较。
我确实相信你的失败是由于没有以合理的方式处理的意外输入引起的。
----------------------------是的，我这样做是为了谋生。



以下为原文

 

eddyfraga wrote:
Hi all,
 
I'm currently working on a project using Xilinx ISE 11.x (will not upgrade to 12 until this project is done and working). The project contains a very large module which is composed of several smaller modules and IP cores. The large module is instantiated 8 times in the design. All 8 modules are finally routed to input/output pins at the top level.
 
When evaluating the actual design in hardware, I often encounter problems where 1 or 2 of the 8 instantiated modules are not working or partially working although all the other instantiated modules are working perfectly. Unfortunately, the problem could never be reproduced in simulation.
 
My hypothesis is that when the FPGA design is synthesized, not all instantiated modules are exactly the same which would explain why certain modules are working and others are not (even if they have exactly the same HDL code).
 
First question: Is this a common problem that all FPGA designers face when designing very large modular projects?
 
Second question: If I partition the module,will all the other instantiated modules be synthesized the same way?  If so, will this technique ensure that all instantiated modules have a constant functionality?
 
Final question: Is there another tool/technique that can be used to reduce/eliminate the types of problems I'm seeing?
 
Thanks in advance for any relevant information!
 
 
Eddy

Well, my last three designs each instantiate my SPI master module a bunch of times, and I've had zero issues getting them to work properly. These designs also instantiate three Camera Link transmitter entities and again, zero issues. I don't do anything special in terms of constraints, either.
 
 
With proper care -- meaning all inputs to and outputs from your module  are registered and you've taken proper care of clock domain crossing (if  necessary) -- then you can expect the synthesized logic to be identical  for all cases. Of course routing will differ, but your timing  constaints should cover this.
 
You say that you can't replicate the problem in simulation. So I assume that you are not simulating the case that causes the specific modules to fail. You should go back to your simulation and throw invalid inputs at your module and see what happens.
 
I would use ChipScope to look at the inputs and outputs of the failing module and compare them to a working module. I really do believe that your failures are caused by unexpected inputs that are not handled in a reasonable way.
----------------------------Yes, I do this for a living.