Всем привет!

Имеется платка со Spartan 6 (XC6SLX9), в 144 ногом корпусе.
В ней есть прошивка полностью рабочая. На ПЛИС идет клок 50 МГц, внутри он поднимается до 100 МГц.

Понадобилось добавить управление внешним ключом, который подключен к 143 ноге. Просто один из сигналов что шел внутри плис с инверсией вывели на ружу на эту ногу, и понеслось....

если пишем на эту ногу 1, 0, инверсию внутренего сигнала, ПЛИС перестает работать. Не загорается диодик подтверждения LOCKED PLL. Более того появляется сообщение о какой-то комбинаторной логике на сигнале получаемом делением основного клока.

в куске кода

вот на этот CLK жалуется синтезатор.

При этом в пустом проекте на эту ногу можно вывести частоту и она будет шевелится

Также если вывести желаемый нам сигнал управления ключом на другую ногу, то опять же все работает.

Если выводит на 143 ногу уровни, они задаются, но плис все равно мертвая....

Пробовали не включать ПЛЛ, подали внешний клок, и результат тот же

143 нога по совместительству еще и VREF 0 банка, но в нем используется уровни по умолчанию, другие сигналы на других ногах VREFE этого банка есть и работают.


Вообщем либо я сделал что-то очень глупое, либо это какая - то магия. И главное что я не представляю что можно еще проверить, что покрутить, как диагностировать в чем косяк... Не резать же из-за такой глупости дорожку, и не паяться же на другие ноги соплей...

Можете проверить код на любой другой плате, где эта нога ни к чему не подключена, или на секунду отключить ее, чтобы висела в воздухе? Как сконфигурирована она в ucf ?
Синтезатор скорее всего жалуется что быстрый клок идет не по клоковому дереву, а по обычной cell fabric. Плюс ручной делитель это gated clock. В промежутке между reset и clk_dev==DEVIDER сигнал CLK не определён никак.

не жаловался до появления в проекте 143 ноги, убираешь ее из ucf все ок, добавляешь пишет

PhysDesignRules:372 - Gated clock. Clock net Unit_inst/CLK
is sourced by a combinatorial pin. This is not good design practice. Use the
CE pin to control the loading of data into the flip-flop.

в ucf файле все обычно
NET "port143" LOC = P143;

нога идет просто на ключ силовой, на 3 платах проверено, везде одна фигня. На простом проекте нога дрыгается без конфликтов.

Перенос на другую ногу работает, синтезится, не жалуется, и запускается.

CLK - регистр, так что он определен, начальное состояние и состояние при ресете, все есть...

Добавьте буфер на вход, а еще лучше синхронизатор с клоком на триггере. Кстати, есть защита от дребезга?

на вход чего!? не можете понять проблему, лучше пропустите....

Просто адское количество детских ошибок. Чтобы не быть голословным приведу примеры:
1. Ваш "как бы счётчик" clk_dev - чисто комбинаторная схема, он не будет работать так как не сможет запомнить своё предыдущее состояние. Посмотрите шаблоны счётчиков и сравните этот с тем, что вы нагородили.
Поглядите RTL schematic - вы увидите какой там АДЪ...
2. Наблюдается gated clock - нельзя ни под каким соусом генерить клок на логике, это чревато тучей различных проблем, вопрос неоднократно обсуждался, поищите на форуме.
3. Слово "dIvider" - по-русски "делитель" пишется именно через "I", от английского глагола "to divide" - делить, язык неплохо бы знать.

Golikov A
Правильно ругается - gated clock это not good design practice, поскольку синтезатору сложно оценить выполнение ограничений, накладываемых на проект.
Сделайте на первом этапе весть проект синхронным и на одной тактовой глобальной частоте.
Потом уже можно оптимизировать.
Кстати, для Spartan 6 есть полезный документ SelectIO Resources (ug381.pdf‎).

Еще раз!

Вы не на том зациклились.

я не могу понять почему добавление выхода сигнала на P143 вызывает зависание плис, отказ работы PLL и данный варнинг.
Повторяю еще раз, до вывода сигнала наружу варнинга НЕ БЫЛО
при выводе ЭТОГО ЖЕ сигнала наружу но не на 143 пин ВСЕ РАБОТАЕТ






пожалуйста относитесь к людям ни как к идиотам, и почитайте еще раз в чем суть проблемы.



Почему до вывода reset на 143 пин не ругается, и также не ругается если reset вывести на 17 пин?

я так понимаю что увидев выдранный кусок кода все потеряли покой и не могут дальше смотреть.
естественное приведенный кусок текста находится под always @(posedge main_clk)

1. Надо смотреть схемотехнику - куда подключен этот пин и какие он вызывавет процессы в вашем устройстве. Может он сбрасывает процессор, который сбрасываетFPGA?
2. Какие функции у пина кроме user i/o. Может с этим что-то завязано.

Может у Вас какая нибудь "сопля" на плате - прозвоните цепь на GND и на питания

проверяли,
идет на ключ через резистор, номиналы правильные.
в пустом проекте дергали этим пином, все работает, дергается.

этот пин VREF банка 0. Но банк в стандартном по умолчанию состоянии, реф не задействован, на других VREF этого же банка идут сигналы, они работают.



проверяли, 3 платы, на всех одинаковая ситуация.
в пустом проекте работает нормально...


Хотя сейчас у меня появилась одна мысль, у меня общий ресет всей схемы просто подтянут к земле

NET "glb_reset" PULLDOWN;

не нашлось ему как то сначала ноги, а потом про него забыли... Может так нельзя?

На всякий случай добавлю - проверьте по документации, не влияет ли на функционирование совмещение функций IO и VREF на ноге 143 (то, что вы имеете при активации этой ноги).

Golikov A
Ещё раз - gated clock это not good design practice.
Этим всё сказано. Я не знаю Ваш проект. Но точно знаю, что в хорошем работоспособном проекте это встречается редко и, как правило, только в случае крайней необходимости.
Сначала разберитесь, почему появляется это сообщение. А затем можно двигаться дальше. Такое бывает если где-то (не факт что в этом месте) выведена тактовая частота на pin напрямую.
Во-вторых, для начала ВСЕ сигналы просечь глобальной тактовой и поместить триггеры в IOB.
После того, как проект заработает, можно будет заняться оптимизацией.

еще раз все перечитал, VREF тут не причем.
синтезатору не нравится именно ваш вывод сигнала reset наружу. Пока вы reset используете внутри, он возможно оптимизируется и в явном виде отсутствует.
ведь если какой-нибудь разряд clk_dev вывести на 143 ножку все работает правильно?

Нет не правильно! Читаете плохо видать.
Вывод сигнала ресет через другой пин не вызывает варнинга и все работает. Вывод константы 1 0 любого сигнала через 143 пин вызывает варнинг и все падает.

ничего этим не сказано... Это варнинг появляется от 143 пина... Внимание не на варнинг а на то что он появляется



Да вот уже все даташиты проглядел. Реально магия какая то. Ща до проекта добирусь проверю не подбрасывается ли глобальный ресет. Это последние что хоть как то рационально объясняет происходящее