Для синтеза используется Synplify Pro E-2010.09-1 на выходе edf файл, далее Xilinx: ngdbuid -> map -> par -> bitgen
В отчете ngdbuid вот такая строчка:
WARNING:ConstraintSystem:204 - A target design object for the Locate constraint
'<INST /DEC/EXPANDED/DEC/gtx/GTP1_0/RIOV6 LOC = GTXE1_X0Y7>' could not be
found and so the Locate constraint will be removed.
откуда этот констрэйн берется?? почему INST = /DEC/EXPANDED/DEC/gtx?
Констрэйн в ucf файле:
INST "gtx/GTP1_0/RIOV6" LOC = "GTXE1_X0Y7";
работает о чем говорится чуть ниже в отчете ngdbuid:
WARNING:NgdBuild:1012 - The constraint <INST /DEC/EXPANDED/DEC/gtx/GTP1_0/RIOV6
LOC = GTXE1_X0Y7> is overridden on the design object gtx/GTP1_0/RIOV6 by the
constraint <INST "gtx/GTP1_0/RIOV6" LOC = "GTXE1_X0Y7";> [dec.ucf(845)].
Как побороть этот warning?
спасибо
Полная версия этой страницы: Борьба с ворнингом Synplify & Xilinx
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Для начала, какое семейство и версия ISE?
Цитата(Koluchiy @ May 12 2011, 17:54) 
Для начала, какое семейство и версия ISE?
ise 13.1
virtex6: 130vlx
GTXE - приемопередатчики. Synplify знает куда какой gtxe ставить и видно в edf файле, что gtxe ставится на конкретное место. но почему edf потом не срастается с ngdbuild'ом не понятно. точнее по ворнигу видно, что констрейн не применяется т.к. констрэйн указывает на несуществующий путь /DEC/EXPANDED/DEC/.
Цитата
Synplify знает куда какой gtxe ставить и видно в edf файле, что gtxe ставится на конкретное место
Бррр...
Откуда Synplify знает, куда его ставить? Вы пишете для него констрейны размещения?
Вообще, по моей практике, "непонятно откуда" берущиеся констрейны обычно берутся из 2-х источников:
1) Файл synplify.ucf, если он не пустой и если не отключить его подсоединение к проекту.
2) Другие ucf и прочие файлы, которые каким-то образом подключились к проекту (но у меня такого давно не было).
Цитата(Koluchiy @ May 13 2011, 19:04)
Бррр...
Откуда Synplify знает, куда его ставить? Вы пишете для него констрейны размещения?
Вообще, по моей практике, "непонятно откуда" берущиеся констрейны обычно берутся из 2-х источников:
1) Файл synplify.ucf, если он не пустой и если не отключить его подсоединение к проекту.
2) Другие ucf и прочие файлы, которые каким-то образом подключились к проекту (но у меня такого давно не было).
Откуда Synplify знает, куда его ставить? Вы пишете для него констрейны размещения?
Вообще, по моей практике, "непонятно откуда" берущиеся констрейны обычно берутся из 2-х источников:
1) Файл synplify.ucf, если он не пустой и если не отключить его подсоединение к проекту.
2) Другие ucf и прочие файлы, которые каким-то образом подключились к проекту (но у меня такого давно не было).
разобрался! подтолкнули еще раз внимательно код проверить
В VHDL коде стоит атрибут
attribute loc of RIOV6 : label is "GTXE1_X0Y7";
где RIOV6 это объявление Xilinx примитива GTXE1.
В edf файле LOC в виде
CODE
(instance RIOV6 (viewRef verilog (cellRef GTXE1 (libraryRef VhdlGenLib0)))
...
(property LOC (string "GTXE1_X0Y7"))
...
(property LOC (string "GTXE1_X0Y7"))
Закоментировал атрибут в коде - ворнинг пропал. Остался неприятный осадок, что ngdbuild не понимает зашитый в edf файле от Synplify LOC констрейн.
Да, третий вариант в копилку ""непонятно откуда" берущиеся констрейны": attribute loc в исходном коде...
Спасибо, считаю тема закрыта!
Мгы...
То есть, назначение расположения GTX определяется не ucf файлом, а EDF...
Вероятно, NGDBuild был неготов к такому развитию событий...
То есть, назначение расположения GTX определяется не ucf файлом, а EDF...
Вероятно, NGDBuild был неготов к такому развитию событий...
2 Koluchiy
Положение GTX определяется UCF-ом, если в EDIF-е от Synplify2009/2010 будет LOC (кроме LOC-а на лапы
) будет ошибка на этапе NGDBuild
Положение GTX определяется UCF-ом, если в EDIF-е от Synplify2009/2010 будет LOC (кроме LOC-а на лапы
) будет ошибка на этапе NGDBuild
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.