完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
我正在使用带有Spartan-6 150T FG484的ISE 14.2嵌入式版本。
我的设计包含一个MicroBlaze处理器。 我从SP605板开始使用原型设计,并使用更大的设备转换为我的真实设计。 我小心更新所有设备引用以使用更大的150T设备。 SP605使用LVCMOS25,而我的电路板使用LVCMOS33。 我用我的所有信号填写了我的UCF文件,但只有一些导致了错误。 这是我从Map获得的错误: 信息:位置:834 - 仅锁定IO的子集。 在92个IO中,89个被锁定,3个未被锁定。 以下是未锁定的组件列表。 OA_o_SYS_OK未锁定OA_o_HP_INHIBIT未锁定OA_o_ATTENUAtiON_EN未锁定其余IO已锁定错误:放置:866 - 没有足够的有效站点放置以下IOB:IO标准:名称= LVCMOS25,VREF = NR,VCCO = 2.50,TERM = NONE, DIR = OUTPUT,DRIVE_STR = 12 OA_o_SYS_OK OA_o_HP_INHIBIT OA_o_ATTENUATION_EN这可能是由于设备上可用站点数量不足,禁止站点过多,或者I / O标准不兼容,或者范围受限于具有有效站点的I / O Bank。 这种情况可以通过以下一个(或全部)动作来解决:a)通过使用LOC或范围约束将类似标准的IOB分组到最小量的I / O Bank中。 b)如果可能,通过选择较低容量的I / O Bank,为特殊IOB最大化可用的I / O Bank资源。 c)如果适用,减少用户禁止站点的数量或使用更大的设备。 以下是我的UCF文件中的相应条目: NET OA_o_SYS_OK LOC =“B20”| IOSTANDARD =“LVCMOS33”; NET OA_o_HP_INHIBIT LOC =“F22”| IOSTANDARD =“LVCMOS33”; NET OA_o_ATTENUATION_EN LOC =“J20”| IOSTANDARD =“LVCMOS33”; 你可以看到我确实有这些LOCKED。 在我的MHS文件中: 端点OA_o_ATTENUATION_EN = OA_o_ATTENUATION_EN,DIR = OPORT OA_o_HP_INHIBIT = OA_o_HP_INHIBIT,DIR = OPORT OA_o_SYS_OK = OA_o_SYS_OK,DIR = O,SIGIS = NONE 我已经尝试将SYS_OK的IO引脚从B20交换到A20,其中A20位于不会出错的引脚上,但它仍然说SYS_OK没有锁定并给出完全相同的错误。 我甚至尝试删除SYS_OK,它名为OK,并用新名称SYS_OK添加回来,但我仍然得到同样的错误。 我还清理了设计文件并重新设计了干净的设计。 没有运气。 我从阅读中知道LVCMOS25是默认的,因此如果引脚被锁定,为什么它们会转到LVCMOS25。 我不明白的是为什么他们没有锁定。 知道这里发生了什么吗? 谢谢。 以上来自于谷歌翻译 以下为原文 I am using ISE 14.2 Embedded Edition with a Spartan-6 150T FG484. My design contains a single MicroBlaze processor. I started with a prototype design from an SP605 board and converted to my real design using the larger device. I was careful to update all device references to use the larger 150T device. The SP605 uses LVCMOS25 whereas my board with use LVCMOS33. I filled in my UCF file with all my signals, but only some caused errors. Here is the error I get from Map: INFO:Place:834 - Only a subset of IOs are locked. Out of 92 IOs, 89 are locked and 3 are not locked. The following is the list of components that are not locked. OA_o_SYS_OK NOT LOCKED OA_o_HP_INHIBIT NOT LOCKED OA_o_ATTENUATION_EN NOT LOCKED Rest of the IOs are LOCKED ERROR:Place:866 - Not enough valid sites to place the following IOBs: IO Standard: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE, DIR = OUTPUT, DRIVE_STR = 12 OA_o_SYS_OK OA_o_HP_INHIBIT OA_o_ATTENUATION_EN This may be due to either an insufficient number of sites available on the device, too many prohibited sites, or incompatible I/O Standards locked or range constrained to I/O Banks with valid sites. This situation could possibly be resolved by one (or all) of the following actions: a) Grouping IOBs of similar standards into a minimum amount of I/O Banks by using LOC or range constraints. b) Maximizing available I/O Banks resources for special IOBs by choosing lower capacity I/O Banks if possible. c) If applicable, decreasing the number of user prohibited sites or using a larger device. And here are the corresponding entries in my UCF file: NET OA_o_SYS_OK LOC = "B20" | IOSTANDARD = "LVCMOS33"; NET OA_o_HP_INHIBIT LOC = "F22" | IOSTANDARD = "LVCMOS33"; NET OA_o_ATTENUATION_EN LOC = "J20" | IOSTANDARD = "LVCMOS33"; You can see that I do in fact have these LOCKED. And in my MHS file: PORT OA_o_ATTENUATION_EN = OA_o_ATTENUATION_EN, DIR = O PORT OA_o_HP_INHIBIT = OA_o_HP_INHIBIT, DIR = O PORT OA_o_SYS_OK = OA_o_SYS_OK, DIR = O, SIGIS = NONE I have tried swapping IO pins for SYS_OK from B20 to A20 where A20 is on a pin that does not give errors, but it still says SYS_OK is not LOCKED and gives the exact same error. I even tried removing SYS_OK which was orginally name OK and adding it back in with a new name SYS_OK and still I have get the same error. I have also cleaned design files and rebuilt the design clean. No luck. I know from reading around that LVCMOS25 is the default so that makes sense as to why if the pins are LOCKED they go to LVCMOS25. What I don't understand is why are they not LOCKED. Any idea what is going on here? Thanks. |
|
相关推荐
11个回答
|
|
事实证明,这是ISE / EDK整合中处理约束的错误。
在一个相关的主题中,我发布了一个针对此问题的解决方法,这是我从Xilinx Webcase收到的。 另一个线程的解决方法 在原帖中查看解决方案 以上来自于谷歌翻译 以下为原文 It turns out this is a bug in ISE/EDK intergration dealing with contraints. In a related thread I have posted a workaround for this issue I received from a Xilinx Webcase. Workaround on Another Thread View solution in original post |
|
|
|
通常这是写作的问题。
这些工具混淆了资本和非资本命名。 也许你成功地将信号重命名为总资本拼写 - 特别是在ucf中。 以上来自于谷歌翻译 以下为原文 Usually this is a problem of writing. The tools mix up capital and non capital naming. Maybe you succeed in rename the signals to total capital spelling - espacially in the ucf. |
|
|
|
为“未锁定”网络列出的属性都是默认值。
这似乎表明了这一点 ISE实际上并没有使用您的.ucf文件。 我要做的第一件事是尝试有意添加 .ucf文件的语法错误,以查看它是否被标记为错误。 如果没有,那么尝试删除 来自项目的.ucf文件并将其重新添加。 我见过.ucf文件在项目中但没有出现在层次结构中的情况 在顶级实例下。 通常只从项目中删除.ucf然后 添加它可以解决问题。 大多数情况下,如果您更改顶级问题,则会出现问题 模块。 - Gabor - Gabor 以上来自于谷歌翻译 以下为原文 The attributes listed for the "un-locked" nets are all defaults. This seems to indicate that ISE is not actually using your .ucf file. The first thing I would do is try to intentionally add a syntax error to the .ucf file to see if it gets flagged as an error. If not, then try to remove the .ucf file from the project and add it back in. I have seen cases where a .ucf file is in the project but does not show up in the hierarchy under the top level instance. Usually only removing the .ucf from the project and then adding it back fixes the issue. Most often the issue happens if you change the top-level module. -- Gabor -- Gabor |
|
|
|
我在SYS_OK之前的NET上删除了一个分号,如下所示:
NET OA_o_HS_TX LOC =“A20”| IOSTANDARD =“LVCMOS33”NET OA_o_SYS_OK LOC =“B20”| IOSTANDARD =“LVCMOS33”; 它给了我以下翻译错误: 错误:ConstraintSystem:300 - 在文件中:C: Projects Processor HW / microblaze_pss.n cf(54):语法错误。 确保先前的约束规范以';'终止。 所以看起来它正在读取我的文件。 奇怪的是它在SYS_OK之后出现的HS_TX或NET没有问题,只有SYS_OK和我文件中的其他两个问题。 还有其他想法吗? 我接下来会尝试全部大写。 以上来自于谷歌翻译 以下为原文 I removed a semicolon on the NET right before the SYS_OK one as follows: NET OA_o_HS_TX LOC = "A20" | IOSTANDARD = "LVCMOS33" NET OA_o_SYS_OK LOC = "B20" | IOSTANDARD = "LVCMOS33"; It gave me the following Translate Error: ERROR:ConstraintSystem:300 - In file: C:ProjectsProcessorHW/microblaze_pss.n cf(54): Syntax error. Ensure that the previous constraint specification was terminated with ';'. So it looks like it is reading my file. It is just strange that it does not have a problem with the HS_TX or the NET that comes after SYS_OK, just SYS_OK and the other two further down in my file. Any other thoughts? I will try ALL CAPS next. |
|
|
|
我尝试了你对所有大写的建议并得到了相同的结果。
NFO:位置:834 - 仅锁定IO的子集。 在92个IO中,89个被锁定,3个未被锁定。 以下是未锁定的组件列表。 SYS_OK未锁定ATTENUATION_EN未锁定HP_INHIBIT未锁定其余IO已锁定错误:放置:866 - 没有足够的有效站点放置以下IOB:IO标准:名称= LVCMOS25,VREF = NR,VCCO = 2.50,TERM = NONE, DIR = OUTPUT,DRIVE_STR = 12 SYS_OK ATTENUATION_EN HP_INHIBIT NET SYS_OK LOC =“B20”| IOSTANDARD =“LVCMOS33”; NET HP_INHIBIT LOC =“F22”| IOSTANDARD =“LVCMOS33”; NET ATTENUATION_EN LOC =“J20”| IOSTANDARD =“LVCMOS33”; 注意:我只在这里展示违规的NET。 总共有92个,其他所有其他工作正常。 还有其他建议吗? 谢谢。 以上来自于谷歌翻译 以下为原文 I tried your suggestion of all caps and got the same result. NFO:Place:834 - Only a subset of IOs are locked. Out of 92 IOs, 89 are locked and 3 are not locked. The following is the list of components that are not locked. SYS_OK NOT LOCKED ATTENUATION_EN NOT LOCKED HP_INHIBIT NOT LOCKED Rest of the IOs are LOCKED ERROR:Place:866 - Not enough valid sites to place the following IOBs: IO Standard: Name = LVCMOS25, VREF = NR, VCCO = 2.50, TERM = NONE, DIR = OUTPUT, DRIVE_STR = 12 SYS_OK ATTENUATION_EN HP_INHIBIT NET SYS_OK LOC = "B20" | IOSTANDARD = "LVCMOS33"; NET HP_INHIBIT LOC = "F22" | IOSTANDARD = "LVCMOS33"; NET ATTENUATION_EN LOC = "J20" | IOSTANDARD = "LVCMOS33"; Note: I am only showing the offending NETs here. There are a total of 92 and all ther others work fine. Any other suggestions? Thanks. |
|
|
|
我可以建议的另一件事是ISE正在使用一些历史数据而不是
最新代码。 您可以尝试从ISE“清理项目文件”或从XPS“清理硬件”。 - Gabor - Gabor 以上来自于谷歌翻译 以下为原文 The only other thing I can suggest is that ISE is using some historical data rather than the latest code. You could try to "cleanup project files" from ISE or "clean hardware" from XPS. -- Gabor -- Gabor |
|
|
|
是的,这是一个好主意,但我已经这样做了。
我在SCM中有我的代码所以我删除了旧文件夹,从SCM中获取了我的代码(它不包含所有构建结果),然后执行“清理项目文件”。 我正在考虑在核心中移动一些东西我也在连接信号。 是否有编辑器我可以加载UCF文件,这将提供下拉列表? 我一直在XPS的文本编辑器中编辑它。 以上来自于谷歌翻译 以下为原文 Yes that is a good idea, but I already did that. I have my code in SCM so I deleted the old folder, got my code back from SCM (which doesn't contain all the build results) and then did "Cleanup Project Files". I am thinking of moving some things around in the core I am connecting the signals too. Is there and editor I can load the UCF file in that would provide dropdowns? I have been editing it in the text editor in XPS. |
|
|
|
我的核心有几个信号。
给我带来麻烦的两个信号是: ATTENUATION_EN HP_INHIBIT 我决定用我的核心上的两个其他信号交换NET名称,这些信号没有给我带来麻烦。 OA_o_ST_EN OA_o_ST_SIG 我离开了我的UCF文件,但现在我的核心连接如下: ATTENUATION_EN = OA_o_ST_EN HP_INHIBIT = OA_o_ST_SIG 和 OA_o_ST_EN = ATTENUATION_EN OA_o_ST_SIG = HP_INHIBIT 有趣的是现在我收到有关OA_o_ST_EN和OA_o_ST_SIG没有被锁定的错误。 因此看起来我连接到ATTENUATION_EN的任何内容和我核心上的HP_INHIBIT信号都不会被锁定,无论我命名它们。 如果我将旧的NET名称放在其他核心信号上,它们就能正常工作。 什么可能导致这个? 以上来自于谷歌翻译 以下为原文 My core has several signals on it. Two of the signals giving me trouble are: ATTENUATION_EN HP_INHIBIT I decided to swap NET names with two other signals on my core that are not giving me trouble. OA_o_ST_EN OA_o_ST_SIG I left my UCF file the same but now I have my core connected as follows: ATTENUATION_EN = OA_o_ST_EN HP_INHIBIT = OA_o_ST_SIG and OA_o_ST_EN = ATTENUATION_EN OA_o_ST_SIG = HP_INHIBIT The interesting thing is now I am getting errors about OA_o_ST_EN and OA_o_ST_SIG not being LOCKED. So it looks like whatever I connect to the ATTENUATION_EN and HP_INHIBIT signals on my core will never be LOCKED no matter what I name them. And if I put the old NET names on other core signals they work fine. What could cause this? |
|
|
|
我首先看看非工作端口可能有什么共同点。
而且当然 这些和工作端口之间可能有什么不同。 你有没有得到任何警告 关于合成设计时的非工作端口? 他们似乎是投入 到你的核心。 所有核心投入都是否存在问题? 是否添加了这些端口 在其他工作端口之后到你的核心? 可能会有一些历史用法 构建数据导致“新”端口断开连接... - Gabor - Gabor 以上来自于谷歌翻译 以下为原文 I would start by looking at what the non-working ports might have in common. And of course what might be different between these and the working ports. Did you get any warnings about the non-working ports when you synthesized the design? They seem to be inputs to your core. Are all of the core inputs exhibiting the problem? Were these ports added to your core after the other working ports? Again there may be some usage of historical build data causing "new" ports to become disconnected... -- Gabor -- Gabor |
|
|
|
我回到原来的SP605项目并试了一些东西,发现我的LED指示灯也在做奇怪的事情。
例如,LED显示LOCKED,即使它根本不在UCF文件中。 然后我看了我的VHDL。 所有信号都给我带来了麻烦,它也连接到核心内部的LED信号。 当我注释掉SYS_OK到LED的分配时,SYS_OK的问题就消失了。 最终的解决方案是创建一个进程和s_led信号,并在每个时钟上分配我的SYS_OK和其他信号,从而注册它们。 然后我做了批量分配LED SYS_OK:out std_logic; ATTENUATION_EN:out std_logic; HP_INHIBIT:out std_logic; LED:输出std_logic_vector(7 downto 0); - 注意:许多其他信号未显示 ------------------------------------原始代码 LED(0) LED(1) LED(2) LED(3) LED(4) LED(5) LED(6) LED(7) ------------------------------------原始代码 ------------------------------------新代码修复 - 注册 signal s_led:std_logic_vector(7 downto 0):=(其他=>'0'); - LED工艺 LED_REG:进程(Bus2IP_Clk)是 开始 如果Bus2IP_Clk'event和Bus2IP_Clk ='1'那么 如果Bus2IP_Resetn ='0'那么 s_led'0'); 其他 s_led(0) s_led(1) s_led(2) s_led(3) s_led(4) s_led(5) s_led(6) s_led(7) 万一; 万一; 结束过程LED_REG; LED ------------------------------------新代码修复 因此,似乎将信号从我的核心路由到两个不同的名称(例如SYS_OK和LED)。 造成了这个问题。 看起来似乎没有将控制信号分配给额外的引脚来点亮LED应该会引起问题,但确实如此。 解决方法是注册信号并将寄存器的输出分配给LED总线,这会使问题消失。 唯一剩下的问题是:这是一个ISE / XPS错误还是我不太了解的功能? Xilinx员工是否知道我上一个问题的答案? 谢谢大家的帮助。 以上来自于谷歌翻译 以下为原文 I went back to my original SP605 project and tried some things and noticed my LED signals where doing strange things as well. For example LED<1> was showing LOCKED even though it was not in the UCF file at all. I then looked at my VHDL. All the signals giving me trouble where also connected to the LED signals inside the core. When I commented out the assignment of SYS_OK to LED<1> the issue for SYS_OK went away. The final solution was to create a process and s_led signals and assign my SYS_OK and others on each clock thus registering them. I then did a bulk assignment LED <= s_led; outside the process and everything works now. See below. -- External Signals SYS_OK : out std_logic; ATTENUATION_EN : out std_logic; HP_INHIBIT : out std_logic; LED : out std_logic_vector (7 downto 0); -- Note: Many other signals not show ------------------------------------ORIGINAL CODE LED(0) <= '1'; LED(1) <= SYS_OK; LED(2) <= s_x_ok; LED(3) <= s_y_ok; LED(4) <= ATTENUATION_EN; LED(5) <= HP_INHIBIT; LED(6) <= s_z_en; LED(7) <= s_a_en; ------------------------------------ORIGINAL CODE ------------------------------------NEW CODE FIX -- Register signal s_led : std_logic_vector (7 downto 0) := (others => '0'); -- LED Process LED_REG : process(Bus2IP_Clk) is begin if Bus2IP_Clk'event and Bus2IP_Clk = '1' then if Bus2IP_Resetn = '0' then s_led <= (others=>'0'); else s_led(0) <= '1'; s_led(1) <= SYS_OK; s_led(2) <= s_x_ok; s_led(3) <= s_y_ok; s_led(4) <= ATTENUATION_EN; s_led(5) <= HP_INHIBIT; s_led(6) <= s_x_en; s_led(7) <= s_a_en; end if; end if; end process LED_REG; LED <= s_led; ------------------------------------NEW CODE FIX So it seems having the signals routed out of my core basically under two different names (i.e. SYS_OK and LED<1> for example). Caused the problem. It doesn't seem like assigning a control signal to an additional pin to light an LED should cause an issue but it did. The fix was to register the signals and assign the output of the registers to the LED bus which made the problem go away. The only remaining question is: Is this an ISE/XPS bug or a feature that I just didn't understand well enough? Does a Xilinx Employee know the answer to my last question? Thanks for everyone's help. |
|
|
|
事实证明这是处理约束的ISE / EDK集成中的一个错误。
在一个相关的主题中,我发布了一个针对此问题的解决方法,这是我从Xilinx网络广播中收到的。 另一个线程的解决方法 以上来自于谷歌翻译 以下为原文 It turns out this is a bug in ISE/EDK intergration dealing with contraints. In a related thread I have posted a workaround for this issue I received from a Xilinx Webcase. Workaround on Another Thread |
|
|
|
只有小组成员才能发言,加入小组>>
2429 浏览 7 评论
2831 浏览 4 评论
Spartan 3-AN时钟和VHDL让ISE合成时出现错误该怎么办?
2298 浏览 9 评论
3378 浏览 0 评论
如何在RTL或xilinx spartan fpga的约束文件中插入1.56ns延迟缓冲区?
2468 浏览 15 评论
有输入,但是LVDS_25的FPGA内部接收不到数据,为什么?
1391浏览 1评论
请问vc707的电源线是如何连接的,我这边可能出现了缺失元件的情况导致无法供电
597浏览 1评论
求一块XILINX开发板KC705,VC707,KC105和KCU1500
462浏览 1评论
2015浏览 0评论
739浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-29 20:24 , Processed in 1.986046 second(s), Total 98, Slave 81 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号