赛灵思
直播中

王敏

7年用户 233经验值
私信 关注
[问答]

BUFGMUX出现错误:地点:1108帮助/原因?

你好,
我一直有BUFGMUX资源的位置有问题,给出了Map错误:ERROR:Place:1108(对不起,我没有确切错误的日志,我现在无法重现...叹息

有点背景:Spartan 6 XC6SLX45T(FGG484),ISE 13.1。我的VHDL设计使用5个单端时钟输入,其中1个是同步逻辑的主时钟,其他4个时钟中的每一个用于为4个数据信号提供时钟
进入移位寄存器。
时钟信号及其相关引脚如下所示:clk_master_in:AB13  -  GCLK0clk_data_1_in:U12  -  GCLK2clk_data_2_in:AB11  -  GCLK28clk_data_3_in:T12  -  GCLK3clk_data_4_in:Y11  -  GCLK29
我使用带有适当参数的tiMESPEC约束约束了所有5个时钟信号,并且Xilinx工具正在使用约束(我过去曾经使用过ucf文件)。
我必须强调一点,clk_data_1 / 2/3 / 4_in仅连接到移位寄存器的时钟端口,即26位的移位寄存器(定制接口)。
该设计还使用位于X0Y0的GTP的单通道PCIe链路。
PCIe信号都被正确约束,并且与先前工作的设计保持不变。
在第一次映射设计时,我得到所有5个时钟输入导致错误:位置:1108。
遗憾的是,我没有记录确切的错误,但它抱怨BUFGMUX的放置并不理想,并且在检查Xilinx文档时,它们位于相关引脚的错误位置。
我检查了我的信号都是使用GCLK引脚,并且Bank 0和2之间没有使用相同BUFGMUX的冲突 - 全部清除。
我做了很多阅读,并认为我可能与PCIe时钟输入和我自己的时钟输入有冲突。
我相信这只有在我的逻辑使用BUFIO2资源时才有效,这似乎是可以想象的,因为4个时钟与移位寄存器一起使用。
我进一步阅读并发现不应该存在冲突,因为与我正在使用的引脚相关联的BUFIO2资源与用于X0Y0的PCIe资源无关。
过了一会儿,我将其中一个输入时钟引脚移到Bank 0 GCLK引脚并获得了相同的错误:放置:1108,尽管BUFGMUX的位置不同。
作为最后一次尝试,我只是在顶级块级别的所有时钟输入上实例化BUFG,我认为这完全是多余的,但是,错误:地点:1108消失了 - 除了clk_data_1_in ...
然后我想,怎么回事,并且为clk_data_1_in实例化了一个IBUFG和一个BUFG(根据没有BUFIO2的SDR时钟输入的文档),错误就消失了......
我有点困惑可能导致错误发生的原因。
我当然不是专家,但在根据Xilinx文档进行检查时,我发现设计没有任何问题。
为了增加更多的混淆,即使在项目清理并使用SVN恢复到原始代码之后,我也无法重现错误。
由于我无法重现错误,我无法发布确切的错误日志 - 抱歉。
我感到非常焦虑,我有一个严重的设计错误,我有点掩饰。
我真的只是想了解我哪里出错了,以及我对时钟资源的理解是完全错误的。
任何人都可以对这种情况有所了解吗?
我想到的一些问题是:显然,我做错了什么?为什么Xilinx工具使用错误的BUFGMUX?为什么实例化所有信号的IBUFG和BUFG可以解决错误?我是否与我的选择有冲突?
引脚/它们的相关资源和PCIe资源?
另外,在BUFGMUX,BUFIO2等位置方面,是否有可能看到Xilinx工具正在使用哪些资源。这本来可以帮助我找到正在发生的事情,因为我可能已经看到了
冲突或者Xilinx工具只是处于奇怪状态并使用了错误的BUFGMUX等。
无论如何,我真的很感激任何建议,我希望我已经给出了我的设计和问题的足够细节。
如果没有,我很抱歉,并会尽快遗漏任何遗漏。
谢谢,-Doug

以上来自于谷歌翻译


以下为原文

Hi There,

I have been having a problem with the placement of BUFGMUX resources which were giving the Map error: ERROR:Place:1108 (Sorry I don't have a log of the exact error, and I can't reproduce it now... sigh)

A bit of background:
Spartan 6 XC6SLX45T (FGG484), ISE 13.1.
My VHDL design uses 5 single ended clock inputs, 1 of which is a master clock for the synchronous logic, each of the 4 other clocks are used to clock 4 data signals into shift registers.
The clock signals and their associated pins are listed below:
clk_master_in: AB13 - GCLK0
clk_data_1_in: U12   - GCLK2
clk_data_2_in: AB11 - GCLK28
clk_data_3_in: T12    - GCLK3
clk_data_4_in: Y11   - GCLK29

I have constrained all 5 clock signals using the TIMESPEC constraint with the appropriate parameters, and the constrains were being used by the Xilinx tools (i've had in the past that the ucf files wasn't being used).
I have to stress here, that the clk_data_1/2/3/4_in are ONLY connected to the clock port of a shift register, a 26-bit one at that (bespoke interface).

The design also uses a single lane PCIe link using GTP located at X0Y0. The PCIe signals are all constrained correctly and have remained unchanged from a previously working design.

Upon mapping the design for the first time, I was getting all 5 clock inputs causing an ERROR:Place:1108. Sadly I don't have the exact error logged, but it complained that the placement of the BUFGMUXs were not ideal, and upon checking the Xilinx documentation, they were in the wrong locations for the relevant pins.

I checked that my signals were all using GCLK pins, and that there were no conflicts between Bank 0 and 2 both using the same BUFGMUX - all clear there.

I did a lot of reading and thought I might have a conflict with the PCIe clock inputs and my own clock inputs. I believe this is only valid if my logic was using BUFIO2 resources, which seemed conceivable as 4 of the clocks are used with shift registers. I read further though and found that there shouldn't be a conflict as the BUFIO2 resources associated with the pins I'm using aren't associated with the PCIe resources used for X0Y0.

After a while I moved one of the input clock pins to Bank 0 GCLK pins and got the same ERROR:Place:1108, albeit with different locations of the BUFGMUXs.

As a final stab, I simply instantiated BUFG's on all the clock inputs at the top-block level, which I thought was completely redundant, but behold, the ERROR:Place:1108 was gone - except for clk_data_1_in...

I then thought, what the hell, and instantiated an IBUFG and a BUFG (as per the documentation for SDR clock inputs without BUFIO2) for clk_data_1_in and the error was gone...

I'm a bit confused what could have been causing the errors to occur. I'm certainly no expert, but I couldn't see any issues with my design when checking it against the Xilinx documentation.

To add more confusion, I can't reproduce the errors, even after a project clean and a revert back to the original code using SVN. Due to the fact I cant reproduce the error, I can't post the exact error logs - sorry about that.

I'm feeling quite anxious that I have a serious design fault, that I have somehow covered up. I'm really just looking for a bit of understanding of where I was going wrong and if my understanding of the clocking resources is completely wrong.

Can anyone shed some light on the situation?

A few questions that come to mind are:
Obviously, what was I doing wrong?
Why were the Xilinx tools using the wrong BUFGMUXs?
Why does instantiating IBUFGs and BUFGs for all the signals cure the errors?
Do I have a conflict with my selection of pins/their associated resources and the PCIe resources?

On a side note, is it possible to see which resources the Xilinx tools are using, in terms of the locations of BUFGMUXs, BUFIO2s etc. This would have really helped me find out what was going on, as I might have been able to see conflicts or if the Xilinx tools were just stuck in an odd state and were utilising the wrong BUFGMUXs etc.

Anyway, I really appreciate any advice at all, and I hope I have given sufficient details of my design and issues. If not, I'm sorry and will put any omissions up as soon as possible.
Thanks,
-Doug

回帖(4)

潘晶燕

2018-10-17 12:19:10
Doug,用fpga_editor检查发生了什么。很明显,一些奇怪的事情正在发生,可能是你认为你使用的是正确的文件,但有些东西仍然指向一些旧文件。
它“消失”的事实非常令人不安,你是正确的,你需要追踪它。回到原来的输入文件,没有错误,表明实际上已经发生了变化。
Austin Lesea主要工程师Xilinx San Jose

以上来自于谷歌翻译


以下为原文

Doug,

Examine what is happening using fpga_editor.

Clearly, something strange was going on, and it may have been that you thought you were using the right files, but something was still pointing to some old files.  The fact that it "went away" is very troubling, and you are correct, you need to track it down.

Reverting back to the original input files, and NOT having the error, is an indication that something actually has changed.
Austin Lesea
Principal Engineer
Xilinx San Jose
举报

李富才

2018-10-17 12:26:52
Place:1108错误将包含有关涉及哪些组件和站点的详细信息。
将此信息与您的UCF文件进行比较,以查看您的约束是否被删除。
检查.bld文件以获取有关UCF约束的警告消息。
还要检查是否有NGDBuild选项(-aul)设置允许不匹配的LOC约束。
我已经看到了使用此选项的情况,然后忽略了失败约束的Info消息。
此外,根据连接性,BUFG放置可能更复杂,只需根据焊盘位置选择一个站点。
时钟布局器可能已经进入没有可满足输入和输出要求的站点的情况。
您可以通过检查FPGA编辑器中的失败位置(在覆盖时钟专用路由错误之后),然后查看输出连接是否使BUFG远离正确的站点来检查。

以上来自于谷歌翻译


以下为原文

The Place:1108 error will have detailed information about which components and sites are involved. Compare this information to your UCF file to see if your constraints are being dropped. Check the .bld file for warning messages regarding the UCF constraints. Also check whether you have the NGDBuild option (-aul) set that allows unmatched LOC constraints. I've seen cases where this option was being used and then the Info messages for failing constraints were ignored.
 
Also, depending on connectivity, the BUFG placement may be more complicated that just picking a site based on the pad location. The clock placer may have gotten into a situation where there was no site available that satisfied both input and out requirements. You can check that by examining  the failed placement in FPGA Editor (after overriding the clock dedicated route error) and then looking at whether the output connectivity drew the BUFG away from the proper site.
举报

李鑫赢

2018-10-17 12:42:04
谢谢你们的快速回复。
有了一个新的头脑,我已经有了更多的戏剧,并第二次阅读我的笔记。
有一些新的信息可能会对正在发生的事情有所了解。
我昨天忘记写的一个细节是错误:地点:1108指的是BUFGMUXs的站点,而不是BUFG。
我相信BUFG通过使用单个输入来生成BUFGMUX,但是映射器不应该将其称为BUFG吗?
我今天做的第一件事是检查时钟输入焊盘都连接到相应的BUFGMUX站点,所有检查都很好。
我希望我昨天在错误发生时这样做了,回想起来我有点愚蠢。
然后,我检查了-aul选项未设置并检查.bld文件,发现根本没有警告。
然后我做了一个干净的实施并得到警告:“警告:MapLib:876  - 找不到基于指南NCD文件名”swifte_45_top.ncd“提供的指南NGM文件。指导只能用指南NCD文件完成,但是
没有指南NGM文件效果不佳。有效的NGM文件名包括以下内容:“,我收集的是由SmartGuide引起的。
几个星期前我打开了SmartGuide并忘记关闭它 - 代表我的另一点愚蠢。
这个奇怪的行为是否可能是SmartGuide持有前一个Map的部分引起的?这让我觉得当我改变端口名称来实例化IBUFG / BUFG时,SmartGuide允许新的映射,因此问题就消失了。
在尝试编辑我的UCF文件时,ISE今天也在播放。
当我试图打开它时,我收到警告“另一个编辑器已经在编辑该项目的约束。运行多个约束编辑器会导致约束数据被覆盖或未正确更新。”
我发现这个特别奇怪,因为PC刚刚启动,ISE是唯一运行的程序,我打开的第一个文件是.ucf文件。
我可能会干净安装ISE并删除所有项目的工作文件夹以尝试更正此问题。
再次感谢你们的帮助。
在FPGA编辑器中检查Map / PAR的结果后,我感觉更有信心了,所有这些都是用Xilinx文档检查的。
如果我只检查了错误的Map / PAR ...
干杯,
-Doug

以上来自于谷歌翻译


以下为原文

Thank you both for your prompt replies.
 
With a fresh head, I've had a bit more of a play and read over my notes for a second time. There's a few new bits of information that might shed some light on what was happening.
 
A detail I forgot to write yesterday was that the Error:Place:1108 was referring to the sites of BUFGMUXs, not BUFGs. I believe that BUFGs are formed of BUFGMUXs with a single input used, but shouldn't the mapper have referred to it as a BUFG?
 
The first thing I did today was checked that the clock input pads were all connected to the appropriate BUFGMUX sites, all checked out fine. I wish I had done this yesterday when the errors were occurring, in retrospect I was being a bit daft.
 
I I then checked that the -aul option was not set and checked the .bld file and found no warnings at all.
 
I then did a clean and Implement and got the warning: "WARNING:MapLib:876 - Cannot find guide NGM file based on the guide NCD file name "swifte_45_top.ncd" supplied. Guiding can be done with only the guide NCD file but is less effective without the guide NGM file. Valid NGM file names include the following:", which I gather is caused by SmartGuide. I turned on SmartGuide a few weeks back and forgot to turn it off - another bit of stupidity on my behalf. Is it possible that the strange behavior was caused by SmartGuide holding parts of a previous Map? It makes me think when I changed the port names to instantiate IBUFG's/BUFG's, SmartGuide allowed a new mapping, hence the issue disappearing.
 
ISE was also playing up today when trying to edit my UCF file. When I tried to open it I got the warning "Another editor is already editing constraints for this project. Running multiple constraint editors can result in constraint data being overwritten or not properly updated.". I found this especially strange since the PC had just been booted, ISE was the only program run and the first file I opened was the .ucf file. I might do a clean install of ISE and delete the working folders for all my projects to try and correct this.
 
Again, thank you both for your help. I'm feeling a bit more confident after checking the results of Map/PAR in FPGA editor, where it all checked out with the Xilinx documentation. If only I had checked what the erroneous Map/PAR...
 
Cheers,
-Doug
举报

李刚

2018-10-17 12:47:13
“这种奇怪的行为是否可能是由SmartGuide持有前一张地图的一部分引起的?”是的。
有许多恼人的工具问题,有时需要对ISE生成的文件和目录进行全面的闪电战。
继续使用这些工具,你将学习......
------------------------------------------“如果它不起作用
模拟,它不会在板上工作。“

以上来自于谷歌翻译


以下为原文

"Is it possible that the strange behavior was caused by SmartGuide holding parts of a previous Map?"

Yes. There are a number of irritating tool problems that sometimes require a total blitz of the ISE-generated files and directories. Keep using the tools and you will learn...

------------------------------------------
"If it don't work in simulation, it won't work on the board."
举报

更多回帖

发帖
×
20
完善资料,
赚取积分