Доброго времени суток.
Я начал вторую итерацию своего обучения ПЛИС (XILINX). И появилось множество вопросов. Вот есть простая VHDL модель, отлаженная в симуляторе.

Какие шаги чтобы ее подконтрольно "залить" в ПЛИС нужно пройти? Просто обозначить контакты и прошить, это опять не то, как я понял.
С чего начинается (какие шаги) создание проекта с целью загрузить прошивку из готовой VHDL модели?

timing constraints как ими пользоваться? Есть ли литература /статьи (документацию начал читать). Как оценить проект по временным параметрам?
Как узнать время hold, setup в проекте? Как узнать возможны нарушения по временам и устранить их?

Как возможно устранить всякие возможные проблемы , которые могут всплыть?

Я пока пользуюсь ISE и ориентируюсь на xilinx spartan 6 серии .
_______________________________________________________
Проект создается через Planahead или ISE profect navigator?
Какую документацию необходимо изучить и держать под рукой включая на софт(документации много для себя пока держу несколько, связанных с DSP, IO.)
В общем хочется научиться так же на базовой уровне пользоваться ПО для ПЛИС, чтобы перед прошивкой быть в проекте уверенным и понимать на что он способен и какие ограничения имеет.

Приму любые толковые ссылки на статьи/литературу/обучалки/советы

PS. чтобы не засорять вторым топиком, еще один вопрос задам тут. Я столкнулся с такой ситуацией. Один и тоже проект на одно и том же кристалле в одной точке дает разные (две платы-два кристалла -одна и та же конфигурация) результаты. Т.к. проект не мой , но я как раз изучаю схожие вопросы, я хочу данный проект проверить на временные параметры. Как вот в таких ситуациях, когда используешь чужие проекты их сопровождаешь и устраняешь неисправности? (проект схемотехнический, в смысле не описан языком. ). И как оформлять свои проекты, чтобы их удобней и самому сопровождать и другим? Тк. кроме vhdl кода еще же нужно прикладывать какие-то данные (насйтроки среды и т.п.)

Начните с простого - назначьте пины и определитесь с тактовой частотой (для начала используйте всего один временной домен). Все ограничения пропишите в .ucf файле (может либо хелпом воспользоваться, либо переводом Зотова), топовый (головной модуль) подключите в ISE. Для проверки рабоспособнтсти используйте ChipScope.
Ну, к примеру, простой проект счетчика(по хорошему синхросигнал требуется пропустить через pll, но в простейшем случае неважно) (verilog):


Для данного случая, требуется назначить вход тактовой частоты и какой-нибудь тестовый выход (исходя из документации). Далее прописываете в UCF-файле ограничения:


Создаете новый модуль Chipscope и выводите необходимые сигналы для проверки работоспособности на железе -задаете опорную частоту, глубину, триггеры и т.д. (project->new_source->chip scope....).

Компилируете все и после окончания проверяете, выполнились ли Ваши временные ограничения (design overview->static timing-> отсутствие временных ошибок, т.е. нет путей, подсвеченных красным цветом). Если временных ошибок нет, проверяете работоспособность с помощью chipscope. Если алгорим работает в соответствии с заданным, проект работоспособен.

Я пока на этом и остановился, перед тем, как написал сюда. Т.е. сделал простой проект назначил Ucf файле тактовую и ножки. Только chipscope не пользовался. Как часто им оперируют? Сяду, попробую ,посмотрю , как им оперировать.



Еще вопрос. Вот есть асинхронный сброс . Но откуда он берется для начальной инициализации (сигнал) ? Обычно я, не думая, в тестбенче делал начальный короткий импульс сброса. А в железе как? кто дает этот начальный короткий импульс для инициализации? ,
Или нужно заранее в архитектуре при объявлении сигналов и т.п. определять начальные значения , а ассинхронный сигнал только для кнопки reset?
Тут мне в общем тоже не понятно немного.

либо от pin какой-то микросхемы, например CPU либо вручную от кнопки ....

С помощью внутреннего анализатора можно посмотреть большинство сигналов, т.е. тоже самое, что Вы делаете с помощью симулятора. Для счетчика, к примеру, вытащить все разряды - сформировать из них шину - сделать тип шины unsignement - вывести на waveform и увидеть пилу в режиме реального времени (ну или почти), т.е. это просто один из способов отладки в железе.


Один из способов следующий - пускать тактовую частоту на pll, в ней задействовать выход locked и его использовать в качестве сброса. В жизни это означает, что после загрузки прошивки в плисину тактовая частота поступает на pll и требуется некоторое минимальное время (указано в документации) для ее стабилизации на выходе, после чего автоматически выставляется сигнал locked, до этого момента все находится под сбросом.
В случае, если Вы, в качестве сброса хотите применить внешнюю кнопку/джампер требуется поставить защиту от дребезга,
В некоторых случаях применяется и софтовый сброс - переданный по какому-либо (uart,ethernet) интерфейсу например с ПК.

Дополню.
Этот locked изменяется асинхронно относительно тактовой частоты выдаваемой с PLL, потому его хорошо бы синхронизировать, пропустив через D-триггер.

А вообще неплохо бы определиться нужен ли вам ресет вообще (тем более асинхронный!). У Кена Чапмана есть хорошая статься на эту тему.

Стиль описания такой привился, везде на VHDL все проекты с асинхронны сбросом, те которые я видел и на которых учился. (статью назовите, ознакомлюсь )

------------------------------------------------------------------------------------------------------------------------------------
Тогда еще вопрос, получается в таких ситуациях, где сброс может не произойти сразу , (счетчик тот же, где сброс на кнопке или т.п.) я должен в определении сигналов сразу задать начальные значения (до этого я в процессе при сбросе задавал их, считая, что сначала происходит некоторый сброс)?


Тогда буду читать и пробовать, а вопросы уже более конкретные кидать
Кроме списка литературы. Если можете и имеется под рукой название хороших статей/книг для начинающего (кроме самой документации ее обязательно прочитаю), то не откажусь

Вот статья. Ищется гуглом кстати за 1 секунду...
Устанавливать началшьные значения сигналов - это хорошая практика. Для FPGA как правило если ничего специального не предпринято, то после загрузки конфигурации все триггера в состоянии 0. Для ASIC всё не так очевидно. Сделать сброс с помощью обычного счётчика - элементарно, однако повторюсь не факт что в вашем конкретном случае сброс нужен, не стОит усложнять конструкции без необходимости.

Так ..
Т.к. мои проекты маленькие и простые с ними проблем пока нету. Я взял проект (не свой (писал выше об этом))
Включил timing constraints на тактовую частоту (хотя там несколько глоб сигналов...на каждый глобальный свой констрайн или минимально необходимо тактовый основной ограничить?)

Подождал пока соберется проект . и Полезли ошибки Static Timing. Как понять и как использовать эту информацию (я пока в общих чертах понимаю)?

Как определить на какой частоте тогда соберется проект? Какими путями возможно решения таких проблем ?

Как найти пути, которые подсвечиваются красным и исправить ситуацию?
вот к примеру,



Каков алгоритм действий в таких ситуациях?

Тут Вы немного поспешили.
Настоятельно рекомендую "простую VHDL модель, отлаженную в симуляторе" имплементировать в ФПГА и прогнать т.н. временнУю симуляцию.
При этом Вы переходите от абстракций VHDL модели к ее конкретной практической реализации в железе. При временнОй симуляции (моделировании)
схема работает "как настоящая", со всеми аппаратными задержками и проч. УзнАете много нового.
Выяснится, что одновременные события на VHDL ни разу не одновременны в реальности.
Из плюсов - если схема заработала во временнОм моделировании, она практически гарантированно заработает в реальности.

То есть вот Вам программа:
- научиться имплементировать проект;
- научиться моделировать его в Моделсиме с подключенным .sdf файлом.

(прошивать пока бессмысленно).

Я создаю проект в VHDL. С начало выполняю behavior симуляцию. Как я понимаю это без учета задержек. Т.е. идеальный случай. И выполняю Post-Route симуляцию. Выполняю с помощью ISIM, кажется так называется
Это достаточно? Правда я файлов sdf не подключаю..он сам цепляется? Просто дело не в прошивке (загрузки конфигурации). Я хочу делать проект и быть уверенным, что завтра, когда я его запущу он заработает и я смогу его отдаить в случае чего. А не написать модель абстрактно, а потом еще сидеть огромное количество времени и думать как средой пользоваться, как выявлять ошибки , исправлять, отлаживать, откуда reset брать.
Я пока дальше симулятора не хожу.

Еще вопрос попутный раз уж про симуляцию. Иногда я вырабатываю в проектах сигнал разрешения, который длиться один такт (от фронта rising до фронта rising)..как его надежней использовать?
Читать в другом процессе тоже по возрастающему фронту.....или есть ситуации когда читать лучше по падающему(тогда по диограмме падающий фронт приходиться ровно по середине импульса разоен\щшения )

Судя по отчёту у вас возможно где-то gated clock используется. Ну и 4 уровня логики для 200МГц многовато - лучше распилить с помощью промежуточных триггеров.
И ещё бесплатный совет - завязывайте со схемами, это - вымирающая тема.Любой HDL пользуйте. VHDL - он построже, но в нём писанины больше. Verilog - лаконичнее, но есть возможность "выстрелить себе в ногу" по неопытности.

Не...я пока на VHDL. Чуть позже для кругозора Verilog и SystemVerilog. Просто мне непонятно пока, что тема с временами. Взял чужой проект, который я заранее знал, что имеет ошибки с распостранениями сигнала и хочу посмотреть какую информацию можно узнать из отчетов об ошибках и как ее использовать.


Т.е. высокий уровень логики лечиться применением конвееров. Где-то читал статью, про расчет скорости проекта, что она состоит из разных состовляющих и одна из них задержка на самый длинный путь комбинированной логики от одного тригера до другого (при условии одной частоты) и там говорилось, что логику следует разбивать (разумно) последовательной схемой.
Ладно вопрос опять новичка.....на схеме понятно, где логика. А в проекте VHDL, синтезатор сам схему составляет (по идее разработчик должен понимать сам во что вльется код), но тем не менее....Получается по данной тематике лучше про конвейер почитать...? подскажите простой проект, чтобы применить данный подход и посмотреть на каком-то примере результаты с конвейером и без: ?

Решайте проблемы по мере их поступления.
Конкретно меня смущает название источника клока - XLXN_9945 - что это? Зайдите в Tools->constraints editor и посмотрите, какие ограничения подчеркнуты красным (это то, что используется в качестве тактового сигнала, но реальные значения в ограничениях не прописаны). Вся логика должна быть синхронна, а это либо гэйтед клок (как уже писали), либо вообще какой-то сигнал, не имеющий к тактовому отношения. Теперь к клоку назначения - Inv_100 - классический переход сигнала от одного тактового домена в другой, т.е. Ваш сигнал зарождается на частоте XLXN_9945 и поступает в домен, работающей на частоте Inv_100. Вы вообще это планировали (если да, то каким образом реализован переход из одного тактового домена в другой)?
to Gorby

За 10 лет практики в области именно fpga ни разу не видел разработчика, который бы занимался симуляцией на уровне выше функционального с пользой для дела (чиста для себя поиграться да, сам gate-моделированием занимался). Для работоспособности достаточно функционального моделирования, правильное описание всех ограничений и отсутствие временных ошибок на анализаторе.
ЗЫ go2winner Для понимания процесса прохода сигнала по критическому пути ниже того, что Вы привели должен быть отчет о прохождении сигнала (следующие строчки). Там будет подробная интересная информация. А так на куске отчета видно только, что сигнал идет от триггера до триггера.

Есть много разных причин "плохих" таймингов. Проще объяснить проблему на конкретном примере, чем рассказывать сразу абстрактно обо всех возможных случаях. Приведите код, приводящий к проблемам а тайминге, тогда можно будет что-то посоветовать.
З Ы Судя по названиям в вашем примере исходник всё-таки - схема, а не VHDL.

Ага, а потом "включаешь - не работает" (с)

Слова Вы говорите правильные.
Но "правильное описание всех ограничений" Вы сделаете ...никогда. Ну или за бесконечное время.

Чисто функциональная симуляция типа
if rising_edge (CLK) then
x <= y;
end if;

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

А я вот никогда не делаю функциональную симуляцию. Только временнУю. Но зато с хорошим тестбенчем, внешней моделью ИС памяти
(с распознаванием ошибок), шина с реальными измеренными задержками и проч - это если делаю контроллер ДДР.
Такого перформанса Вы не достигнете только лишь с функциональной. Тогда зачем?! Быстрее симулирует? Но ведь симулирует НЕ ТО.

Это означает лишь что ни с чем сложнее ДДР контроллера вы ещё не работали.
Многие проекты просто невозможно симулировать с реальными задержками именно из-за их объёма.

Вы делаете всё правильно. Если Post-Route симуляция работает без ошибок, вероятность работающего дизайна в микросхеме приближается к 1.0 ;

Таки читать этот сигнал длительностью в один период клока надо по тому же фронту, по которому он был сформирован (rising). Этим Вы гарантируете максимальную гибкость дизайна.
Например, использовав противополярный, Вы сознательно урезали временной бюджет для возможной логики и соединений ровно вдвое - нехорошо.
Единственное, о чем стоит беспокоиться - это о соблюдении условий setup\hold для всех триггеров дизайна. К счастью, при правильном задании констрейнов ПО делает это автоматически.
Отсюда есть интересное следствие: если дизайн полностью синхронен, то необходимо и достаточно задать один-единственный констрейн - тактовую частоту.

Еще интересные особенности: при использовании PLL достаточно задать его входную частоту. Все цепи, питающиеся его выходным синтезированным клоком, автоматически получат правильные значения констрейнов.

Кстати о симуляторах. Таки Моделсиму и Ментор Графикс доверия больше, чем доморощенному ISIMу.



То есть Вы запускаете Бураны на Альфу Центавра (ну типа сложный проект), причем функционально моделируется, а после разводки - уже нет?
Бред.
И как же Вы докажете Главному Принимающему (мамой клянусь?), что Ваш проект вообще рабочий? Типа смотрите, на столе в течении 10 минут работает?
Всегда можно моделировать по частям, или просто долго (некоторые проекты таки могут симулироваться десятки часов на секунду реального времени,
особенно если привлекается еще и процессор с эмуляцией его же софта).
Ну или голову включать и симулировать отдельные аспекты.

Знавал я одного программиста, который отказался работать с AVR Atmega644 (64кбайт флеш!) по той причине,
что скомпилированная AVR GCC с DEBUG информацией прошивка не влезала в эти 64К. Без отладочной информации - 4кб(!!!).
Оказался беспомощен без отладчика с хождением по строкам исходника.

Функциональной симуляции и грамотного соблюдения временных ограничений более чем достаточно для успеха. Ни разу не встречался с ошибками,
которые можно было поймать только на уровне gate-level симуляции с реальными задержками. Кроме того не забывайте, что никакой тестбенч не
покрывает 100% возможных ситуаций.
Разумеется, я не использую асинхронщину и прочее "шаманство".

Конкретно я писал именно про fpga, а не ASIC. Извиняюсь за оффтоп, но принимал участие в разработке прототипов на протяжении нескольких лет, к примеру, вот этого устройства (это еще не самое сложное) http://www.mcst.ru/server_elbrus-4.4. Так вот сам прототип состоял из нескольких десятков плисин и был предназначен для отработки алгоритмов не только самого процессора, но и всей обвязки (включая DDR3). После настройки и правильного задания всех ограничений сам прототип без сбоев работал очень долго (месяцы), а Вы утверждаете, что все ограничения описать невозможно. Там из временных ограничений было только описание частот, мультициклы и были ошибки по холдам в контроллерах DDR3 - пришлось жестко отодвинуть выходы регистров на приеме от пинов - все. Некоторые элементы Вы вообще не сможете промоделировать на Gate-уровне, к примеру, гигабитные приемопередатчики - производитель функциональную ( ) модель только дает.

Проект не мой, я сам вписал ограничение на глобальную тактовую частоту (там еще пару глобальных сигналов есть, но их пока не трогал)
Сначала о том , как получены вышепредставленые иллюстрации . Я взял проект (не свой, да еще и схемотехнический, но общую логику работы понимаю) внес в него ограничения (до этого их не было)

и откомпилировал (как вы советовали выше)

Потом зашел в пункт Static Timing . Собственно там есть n-ое количество крестиков. Вот пытаюсь осознать, как сначало извлечь оттуда побольше информации , а потом, как ею воспользоваться для устранения минусов.




Огромное спасибо. я даже не заметил (точнее не знал о колонке с путями). На самом деле часть этого проекта неработоспособна (как раз временные задержки), поэтому я его использую. Как раз данный путь показывает неработоспособный кусок (из -за задержек.)....

Как это схемно выглядит...я рисунок приведу этого пути..... (коряво, но суть понятна)


ну и все в таком духе...теперь как интегрпетировать все результаты?

К примеру clock path skew и slack setup...почему значение отрицательное?

Пойду пока почитаю.. в книге была глава динамическая дисциплина...насколько помню я могу влиять только на задержку комбинационной схемы....более ни на что другое.
Получаются данные слишком поздно приходят?

Ну возьмите, например, пятую серию Альтеры и сделайте временную. А я посмотрю.

Да, но проблема не в этом. Каким тактовым сигналом тактируется триггер XLXI_7012/Q0? Вы его не задали в ограничениях и анализатор не знает как это интерпретировать и развести. В результате получаете непонятно что. Проверьте, то о чем я уже писал. Просто такое ощущение, что у Вас несколько частот, несвязанных между собой (триггер источник работает на одной, приемный на другой)

Там по-правде несколько частот глобальных.....на всех нужно получается ввести ограничения (подобно Вашим примерам и тому как я первый задал), а после компилировать?
Там два тригерра , с одной и той же частотой, но разный фронт (инверсный тактовый сигнал)



Сигнал получается путем инверсии входной тактовой.....как быть? его нет в списке на ограничения? Они видны только в разделе Exception-> nets

Те. идет вход тактовой частоты......От нее идет сеть с названием Mhz_100....от этой сети на выходе получается еще одна сеть с другим названием и ивертированным значением.

Вы слишком большой пласт информации пытаетесь поднять. Я советовал начать с синхронного дизайна и одной тактовой. Если частоты формируются не из одной pll, то требуется грамотный переход из одного клокового домена в другой, читайте статьи iosifk. В общем случае все сигналы, которые используются, в качестве тактовых отображаются в окне
Все частоты должны быть описаны. Насчет инверсного клока - зачем его потребовалось инвертировать и каким образом это реализовано (просто инвертор)?

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

У меня простые проекты, там исследовать нечего..там опыт описания нарабатывать сначало(
И тайм анализ показывает правильно, что рекомендуется 5нс (т.е. он понимает, что там 100 мгц, но по один конец пути по заднему второй переднему...если я правильно все понимаю.

А какой путь пройдет тактовая частота сначала до инвертора, потом до глобального буфера (даже если известно его положение), согласно чему будет определено местоположение инвертора? Так обычно не делают, варианта два - сформировать на pll удвоенную частоту и работать по фронту и сформировать управляющий сигнал ce, который фактически и будет говорить о том, работает по фронту или срезу, либо на pll сформировать дополнительную частоту, сдвинутую на 180 (в этом случае во временных ограничениях нужно указать только исходную частоту, остальное анализатор поймет и сделает сам). Вариант 1 проще и лучше.

Две серьёзных ошибки тут уже :
1. Gated clock - нельзя получать инверсный клок таким способом (инверсией на логике). Если нужна инверсия клока (скорее всего не нужна) - заводите на PLL и крутите там фазу клока на 180 градусов.
2 - Работа по падающему фронту - никаких плюсов от такого подхода нет, только ухудшается в 2 раза временной бюджет.
Всё это неоднократно обсуждалось на этом форуме и не только.

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