[Vadim 0]

Извините за, возможно глупый вопрос.

Я сделал так:

В .UCF - файле:

NET "CLOCK" LOC = "P181"; (вывод 181 - CLK0 в XCR3512XL-6PQ208C согласно datasheet).

Проект работал в два раза быстрее, чем надо. Стал работать как положено только после назначения сигнала CLOCK на неглобальный вывод. Что я сделал не так? Может еще что-то/где-то указать надо?

Спасибо.

[makc 213]

Что Вы подразумеваете под словами "Проект работал в два раза быстрее, чем надо."?

[Vadim 0]

Что Вы подразумеваете под словами "Проект работал в два раза быстрее, чем надо."?

Тактовая частота - 10 МГц. По замыслу проектируемое устройство должно выполнять цикл за 2мин 13с и выдать результат типа годен-негоден. Поведенческое моделирование дает расчетное время цикла. "Проект работал в два раза быстрее, чем надо " означает, что реально устройство выполняло цикл за 1мин 6.5с. И результат, естественно, всегда был "негоден". Такое ощущение, что устройство срабатывало по фронту и по срезу клока, а по замыслу(и моделирование это подтвердило) оно должно срабатывать только по срезу.

[Aleks17 0]

Сдается мне глобальные выводы тут ни при чём - ищите кривости в проекте.

[oval 0]

Извините за, возможно глупый вопрос.

Я сделал так:

В .UCF - файле:

NET "CLOCK" LOC = "P181"; (вывод 181 - CLK0 в XCR3512XL-6PQ208C согласно datasheet).

Проект работал в два раза быстрее, чем надо. Стал работать как положено только после назначения сигнала CLOCK на неглобальный вывод. Что я сделал не так? Может еще что-то/где-то указать надо?

Спасибо.

Здесь Вы зделали все правильно. CLOCK лучше и правильнее заводить на глобальный вход. Скорее всего у Вас глобальная ошибка в самом проекте. Проект должен вести себя логически одинаково независимо от того, на какой вход подается CLOCK (10МГц). Возможно стоит убедиться в том, что на входах XCR присутствует то, что должно быть (в частности правильная частота CLOCK). Еще, как вариант, но с меньшей вероятностью, в версиях САПР Xilinx более ранних чем 7.1SP1, если я не ошибаюсь, была проблема при работе с CPLD, но опять же в данном случае вряд ли.

 

Тактовая частота - 10 МГц. По замыслу проектируемое устройство должно выполнять цикл за 2мин 13с и выдать результат типа годен-негоден. Поведенческое моделирование дает расчетное время цикла. "Проект работал в два раза быстрее, чем надо " означает, что реально устройство выполняло цикл за 1мин 6.5с. И результат, естественно, всегда был "негоден". Такое ощущение, что устройство срабатывало по фронту и по срезу клока, а по замыслу(и моделирование это подтвердило) оно должно срабатывать только по срезу.

Возможно, что имеет место очень серьезное нарушение по временам. Очень похоже на присутствие элемента асинхронности (концептуальная ошибка) в проекте.

[iosifk 3]

Сдается мне глобальные выводы тут ни при чём - ищите кривости в проекте.

 

Сделайте так - уменьшите тактовую в симуляторе на 2-3 порядка. Если проект синхронный, то ему будет примерно все равно. А вот если асинхронный, то при понижении частоты он "вдруг" начнет работать "правильно"....

[sazh 5]

Стандартный метод проверки качества проекта: результаты при функциональном моделировании должны соответсвовать результатам временного в пределах дельта T

[Vadim 0]

Всем спасибо за участие. Ребята, проект асинхронный!!! Там куча латчей!!! Стояла задача без схемы перевести устройство из 6 плат в ПЛИС. Схем не было. Назначение устройства задано. Логика функционирования изначально непонятна. Прозванивали платы и рисовали схемы. Я разбирался как они работают. Там изначально куча латчей!!! Все платы собраны на 133 серии (ЛА3, ТМ2 и прочее. Даже транзисторы). Были там даже RS -триггера на двух элементах И-НЕ. И на все про все(+ документация, изготовление, испытания) - 5 месяцев. В непонятных местах я был просто вынужден применять латчи (как в прототипе), чтобы ускорить разработку, т.к. ошибки дорого стоили.

И вот что интересно - раньше латчи применяли повсеместно, а сейчас, видите-ли, это моветон и концептуальная ошибка. А прототип, между прочим, жив и здоров и дай бог всем устройствам без латчей работать так же долго и надежно, как он. Только не подумайте, что я поклонник латчей. В своих проектах с "нуля" я не допускаю их появления. Но в данном случае считаю, что они тут не при чем. В проекте есть модуль синхронизации, вырабатывающий несколько больших промежутков времени. В сумме эти промежутки и составляют 2мин 13с. А в нем латчей нет.

Проект успешно завершен еще в прошлом году, поэтому всем спасибо за помощь, но вопрос, видимо, мне нужно было ставить по-другому:

 

Грамотно ли использовавать для назначения сигнала CLOCK проекта на вывод глобального клока кристала только конструкцию в UCF-файле типа -NET "CLOCK" LOC = "P181";-? Или требуются еще какие-либо указания в UCF или в модулях исходного описания?

[andrew_b 16]

Грамотноли использовавать для назначения сигнала CLOCK проекта на выводглобального клока кристала только конструкцию в UCF-файле типа -NET"CLOCK" LOC = "P181";-? Или требуются еще какие-либо указания в UCF илив модулях исходного описания?

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

Изменено 28 февраля, 2006 пользователем andrew_b

[Vadim 0]

Грамотноли использовавать для назначения сигнала CLOCK проекта на выводглобального клока кристала только конструкцию в UCF-файле типа -NET"CLOCK" LOC = "P181";-? Или требуются еще какие-либо указания в UCF илив модулях исходного описания?

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

Извините за назойливость, но в даташитах сказано примерно так: "глобальные выводы могут быть запрограммированы и как обычные". И у меня возникают сомнения, что фраза типа NET"CLOCK" LOC = "P181" в UCF гарантирует, что вывод 181 будет запрограммирован как глобальный клок. Ведь действительно, откуда ISE знает, что я сигнал CLOCK считаю тактовым? А вдруг это обычный сигнал и вывод должен быть запрограммирован как обычный? Системы проектирования ведь мыслей не читают.

[oval 0]

Грамотноли использовавать для назначения сигнала CLOCK проекта на выводглобального клока кристала только конструкцию в UCF-файле типа -NET"CLOCK" LOC = "P181";-? Или требуются еще какие-либо указания в UCF илив модулях исходного описания?

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

Извините за назойливость, но в даташитах сказано примерно так: "глобальные выводы могут быть запрограммированы и как обычные". И у меня возникают сомнения, что фраза типа NET"CLOCK" LOC = "P181" в UCF гарантирует, что вывод 181 будет запрограммирован как глобальный клок. Ведь действительно, откуда ISE знает, что я сигнал CLOCK считаю тактовым? А вдруг это обычный сигнал и вывод должен быть запрограммирован как обычный? Системы проектирования ведь мыслей не читают.

Обычно САПР типа ISE определяют автоматически "потенциальных кандитатов" на использование глобальных цепей основываясь на коэффициенте разветвления цепи, заданных пользователем ограничениях, на том подключена ли цепь к тактовому входу триггеров и т. п. В Вашем случае в логах ISE можно все это выяснить. То есть, под какие сигналы задействованы глобальные цепи кристалла.

[Vadim 0]

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