Читая форум не раз натыкался на упоминания проектов, которые компилятся более получаса. Особо этому значения не придавал, т.к. работал только с "2-х, 3-х минутными проектами" ( с мыслью, что мне до такого расти и расти ).

Сейчас столкнулся с проектом, который компилировался почти 40 минут. На моделировании, конечно, все работает, в железе - кривовато. И как быть с процессом отладки? не компилировать же по новой каждый раз?

Инкрементная компиляция по регионам...

Она экономит до 50% времени. Там просто разводка не происходит, а остается прежняя. Именно в указанных регионах!

всего 40 минут? не так и много для хорошего проекта.
заведите сервер для компелирования, а на рабочей машине долбите файлы. Про инкрементальную компиляцию писать не буду, не работал с ней...
А вот почему же в железе кривовато? можно локализовать и по частям отладить.
Или же сказать себе, что архитектура не верна в принципе и искать другую архитектуру, которую легче отладить. Ну, например, можно сделать автомат на 100 состояний, а можно вместо него 1 или 2 микроконтроллера... И т.д.
Удачи!

Инкрементальная компиляция конечно хорошо, но вот такого при правильных временных ограничениях и верной верификации быть не должно.

Если проект синхронный, то как писалось ранее:


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

Я бы рекомендовал отладить подобные узлы отдельно - при необходимости перекомпилируя столько раз, сколько будет необходимым для обеспечения стабильной работы (подбора правильных constraint’ов для Synthesis/Implementation). А потом интегрировать такие узлы в большой проект.

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

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

Вот как раз подобные узлы я и имел ввиду. А с ними, как всегда, есть сложности, которые многократно обсуждались, в том числе и на этом форуме (надо лишь поискать слово «метастабильность»).

Хорошо вам Кактусоводам, 40 минут это уже много... Эх перевести бы вас всех на какой нибудь старый ISE.

Если вы в моделировании не сильны, а в железе всё равно не работает - для вас же придумали SignalTAP, Chipscope и Identify.

я по 4 часа жду полной компиляции и около часа синтез на стратикс4-230. А что делать?...

Кстати, у меня синтез в один поток идет. Подумал, может AHDL виноват? Или на Verilog и VHDL Quartus тоже в один поток синтезирует?

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

Разъясните кто нибудь, что такое верная верификация, как ее делать в квартусе, например?

Да никак ее в квартусе не сделать для сложных проектов. Я имел ввиду сделать максимальное реальное тестовое покрытие для оборудования - если происходит сбой в железе, то проще написать направленный тест для поведенческого уровня.
Если это какая-нибудь система ЦОС типа цифровых приемо-передатчиков, то тут поможет совместное моделирование matlab/simulink модели из которой этот ЦПП и собирался и HDL-описание. Если это коммутатор с разных концов которого есть только СИшное описание интерфейсов процессоров и оборудования, то это специальные тесты на SV/СИ с полным контролем всех ключевых точек (допустим есть критичная statemachine у которого 100 состояний и требуется проверить, что каждое состояние выполняется правильно - составляется группа тестов, по результатам которых заполняется таблица о том, что такое-то состояние было проверено в таком то тесте, в результате оказывается что проверено 90 состояний чего вроде недостаточно и пишутся направленные тесты на оставшиеся состояния).
Вот у меня лично в последнее время был пример - на моделировании все работает (более 1000 тестов), а реально аппаратура повисала после нескольких минут работы при высокой загрузке - попросил верификаторов написать спецтесты на проверку переполнение буферов - оказалось не рассчитал размер буферов, происходило банальное переполнение. Мой косяк, но локальными тестами проверить было невозможно, т.к. интерфейс взаимодействия находится на системном уровне.

очень похоже на то что в один поток...

можно просто статистику посмотреть в Quartus

( один поток - один процессор? )

Кстати, забыл написать... Если Вы делаете при симуляции чтение данных из файла, а потом эти данные используете для задания например внешних воздействий на DUT, то проект не надо каждый раз компелировать. Просто меняете данные в файле, делаете сброс симуляции и пуск симуляции. Экономит время хорошо! Но, к сожалению все так отладить невозможно...
Кстати и выходные данные тоже полезно выводить в файл или хотя-бы на монитор, а не рыться в прорве сигналов. Ведь блольшинство частей проекта уже считаются отлаженными...
Как я это делаю, написано у меня в "Кратком курсе", в главе про отладку...

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

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

Теперь пишем небольшой модуль, который будет "проигрывать" данные из файла 2 синхронно с выходными сигналами блока 1.
Сравниваем, когда все получилось, блок 1 в проекте можно заменить прогрывателем.

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

Для больших проектов, с огроменными последовательностями данных, когда никакого анализатора не хватит, это реальных выход отладить проект в behavioral.