Мой коллега на работе мучается с Xilinx WEBpack 11 версии. Столкнулся с проблемой. Для теста нарисовал делитель входной частоты, выход которого подается на pin FPGA, объявленный как выход. Все ОК! Но если он этот же сигнал в параллель пробует вывести на соседний pin - там тишина. Он уже тихо звереет. Может кто подскажет, в какую сторону двигаться, чтобы победить такой bug (программы или своей головы)?

11-я версия вообще очень чувствительна к таким моментам, как
сигнал с комбинационной логики на тактовый вход синхронного элемента,
Если ваш коллега собрал стандартную делилку с помощью триггеров с инверсной обратной связью,
и убрал пунк об остановке синтеза при ошибке, то есть вероятность, что эта схема не синтезировалась вообще.
Используйте ДЦМ для операций с таковым сигналом. Ну и посмотрите даташит, может ваш вывод питательный или
позетивное плече диф пары.

Вообще говоря, пробовали и на 8 и на 10 версиях. Делитель работает, т.к. на первый pinxx1, описанный как выход, сигнал выводится. Соседний pinxx2 ничем от первого не отличается по своим свойствам. Тем не менее, если на схеме соединить pinxx1 и pinxx2 на выходе pinxx1 сигнал есть, а втором - нет. Может тут что-то с оптимизацией соединений не то?

Ну не может быть такого, сами понимаете.
Сделайте поиск в отсчетах синтезатора, транслятора и мапера по имени ваших выходных цепей.
Хоть какой-то варнинг должен быть, который подскажет, что не так с этими цепями.

Может, конечно, несколько банальное предложение: посмотрите FPGA Editor'ом, что же именно у Вас получается в обоих случаях - обычно эта процедура помогала.

Спасибо за советы. Сами понимаем, что бред какой-то и быть такого не может. Но тем не менее. Завтра посмотрим еще повнимательнее.

простите, а на схеме вы соединяете не означает ли то что вы соединяете в схемном редакторе все?
Если так, нужно посмотреть в сторону использования выходных буферов - OBUF (OBUFT) и соединять не их выходы а входы.
Если соединить выходные пины ISE обязан ругнуться и либо прекратить синтез либо что-то отрубить.

Поясню, что имеет место быть. Есть некоторый блок, реализованный на Verilog. Он отображается на схеме. Теперь мой коллега тянет от выхода этого модуля wire до выходного пира. Над эти wire устанавливает LOC=P77 (к примеру). С другой стороны, я нашел в inet'e, что если блок реализован в Verilog, то надо вызывать PACE и в открывшемся окне прописывать какие цепи на какие pin'ы выводятся. Может в этом кроется отгадка?
Еще. Таблица constrait'ов не заполнялась (т.е. все по умолчанию). Может из за этого оптимизатор все разводит как ему вздумается?

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

Хотя бы Pad report (файл с расширением pad или вида xxx_pad.txt) посмотрите - там будет написано на какой пин отправлен Ваш сигнал - там его и ищите. А вообще, конечно желательно в .ucf - файле назначения пинов задавать.

Спасибо, все проверим и попробуем.

А для второго пина он туда дописал еще один LOC?
Маппер, при упаковке схемы атоматически вставляет выходные буфера в разрыв проводов, идущих наружу кристала. При этом он им приписывает атрибуты, которые были у самого провода (именно так попадает LOC на выход).
Если надо подсоединить wire к 2м выходным пинам, то надо ЯВНО вставить 2 выходных буфера (OBUF, если не ошибаюсь), и прописать им (а не проводам) атрибуты LOC

PACE сделает из этого красивую табличку и вставит ее в UCF файл. Так что результат будет одинаковый - фитеру всеравно откуда брать констрейны - из UCF файла или наследовать из атрибутов в сорцах
Нет
Если где то LOC был прописанн, то значит, что таблица констрейнов все же не совсем пустая

После перерыва вернулись к разбирательству с WebISE. Чтобы понять почему у нас проблемы начали все с начала. Самый простой проект. Только schematic. Один pin - входной clk. Дальше нарисовали делитель. С выхода 0 делителя - D-триггер. Его выход - на выходной pin, на который повесили LED. Скомпилировали, зашили, запустили - OK! Моргает.

Расширяем проект. Добавляем на 1-выход делителя все аналогично. Второй LED вместе в первым в два раза медленее. OK.
Добавляем еще на 2 выход. Все OK!
Добавляем на 3-выход - крах проекта. Все диоды перестали нормально моргать. Последний D-триггер, отсоединяем от выходного pin'a - три первых работают. Убираем 1, возвращаем 3. Работают. Все четыре вместе - ни в какую.

Прозвонили все используемые выводы FPGA. Коротышей нет. Ума не приложу, что за мистика.

Есть ли какие соображения?

Попробуйте поставить OBUF перед каждым выходом (по штуке на выход)

OK! Попробуем после праздников.

Помнится в схематике просто так проводом выходы ПЛИС соединять нельзя - надо (как вам уже сказали) OBUFы ставить.

Но почему именно ISEшный схематик? В нём же не возможно работать, символы какие-то кривые, текст непропорционально маленький, проблемы постоянные. Наши эксперименты с ним закончились после первого же проекта - проще книжку прочитать по VHDL чем бороться с ним.
Попробуйте тоже самое написать на HDL и посмотрите что будет с глюками на практике и схемой в FPGA editore.

P.S. Если уж и использовать схематик, то лучше юзать ActiveHDL, там всё красиво и удобно сделано, проблем поменьше и есть бесплатная студенческая версия (ограничение числу элементов в схеме - не более 20 - что легко снимается построением иерархического проекта).

правильно говорят 1 сигнал один пин напишите строки в уцф наоборот и получете всё наоборот. вро де так

Нельзя ли прояснить. Что скрывается за фразой "напишите строки в ucf наооборот и получите наоборот".

Второй вопрос. Что, schematic настолько по-идиотски написан, что прямое соединение одного выхода триггера с одним выходным pin'ом не гарантируют однозначного поведения схемы?

ActivHDL можно с 3-spartan'ом скрестить?

Schematic, как и всю GUI ISE писали не сильно умные индусы - поэтому они глючат.
А так как очень мало разработчиков пользуются Schematicом, то его глюки никто не исправляет.
Вот самые важные "утилитки" Xilinx, которые в ISE вызываются из командной строки: синтезатор (XST), маппер (MAP), пласе&роутер (PAR) писали люди поумнее, и они работают достаточно хорошо.

Поэтому если использовать чистый ISE, то лучше использовать текстовый ввод данных на HDL. В 9-10 ISE даже текстовый редактор кривовато сделан, но текст можно и в блокноте набивать + имеется куча удобных редакторов HDL.

ActiveHDL легко скрестить с ПЛИС Xilinx, хоть с виртексом хоть со спартаном. Нужно только установить ISE и указать в свойствах проекта путь к ISE и его версию, для того чтобы он смог вызывать из командной строки те самые "утилитки". А схематик, редактор HDL и симулятор у него свои и очень удобные (правда в студенческой версии симулятор сильно замедлен).

P.S. Кстати в старых версиях ISE, что то типа 3й или 4й, был нормальный Схематик, как в ActiveHDL и делали его теже самые люди из Aldeca. Потом из-за денег они разошлись и пришлось Ксилинку нанимать индусов и срочно приделывать вместо него костыль для галочки. Вот этот костыль до сих пор и живёт в неизменном виде.

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

Может я невнятно написал. Дело то в том, с каждого триггера в тестовом проекте его (триггера) выход соединяется исключительно с одним пином. То есть один выход триггера - один выходной пин. Ничего в параллель не соединяется. Вот в чем загвоздка.

Месяца полтора назад я Вам предлагал воспользоваться DCM. для генерации
тактового сигнала, Вы пробывали? Скорее всего дело не в этом, но все равно это порочная
практика заводить на тактовый вход сигнал с комбинационной логики.
В ИСЕ в схематике сидят только самоубийцы. Вам тут уже советовали перейти на ActiveHDL
если так хочется работать со схемным редактором. Все кристаллы ActiveHDL поддерживает,
тем более древний spartan3, и DCM там есть библиотечным элементом.
Пробуйти и отпишитесь, если опять ничего не получится, то я Вам лично напишу эти несчастные три строчки кода,
отлажу благо spartan3e лежит на столе, откоменчу и вышлю Вам на почту,
не дело это по полтора месяца чертей ловить.

Действительно, при ручной установке ibuf/obuf все заработало.

За предлагаемую помощь отдельное спасибо. Но я уже какт-то писал ранее, что не я fpga'шным проектом занимаюсь, а мой коллега. Меня просто достало, что он нас всех тормозит по-черному.

Еще раз всем спасибо за советы.