bogaev_roman

У Вас временные ограничения не выполняются (они вообще заданы?)? Или Вам просто не нравится процентное соотношение задержек? Что за пути - может там по одному регистру на входе/выходе и сигнал тянется через весь кристалл?

Падает на конкретном проекте? Бывало несколько раз - не помогала чистка проекта/небольшие изменения алгоритма, приходилось возвращаться к предыдущим версиям или создавать проект заново, решения найдено не было, было замечено в версии 13.1. ЗЫ. Сложных конструкций на SV не было, ошибка компиляции повторялась на других компах.

Ну, собственно, тогда вернулись к Вашему первому посту - проблемы в трансляции синпливай. С точки зрения RTL-описания все верно, раз квартус синтезирует и разводит все согласно задуманному. Может там отсутствует или не поддерживается библиотека EAB (это же не просто ram/rom, а еще и дополнительные триггеры и мультиплексоры и, как я понял, может быть асинхронной, ну т.е.существенно отличается от привычных M9K или М144К).

:bb-offtopic: Я очень неохотно перехожу на новые версии - только когда они проверены временем и людьми. Сейчас это версия 17.0.2 (все 16 прошли мимо), но и в ней я нашел для себя одну неприятную вещь, хотя жалоб вроде и не было.

Поменял на 50SQ - один EABs (в resource section в fitter report). У Вас точно в проекте больше ничего нет, а то может все EABs сжираются другой логикой?

- Результат работы синтезатора и фиттера Вашего кода для квартуса 9.0 и EPF10K200SRC240 - двухпортовая память 8*128. На post-mapping это 8 сегментов altdpram.

Это уже шаманство, также как и смена seed. Такими вещами занимаются при сложных объемных проектах, а у Вас сумматор 8 разрядный, хоть и на высокой частоте. Может глюк квартуса этой версии, я с подобным сталкивался последний раз в 9 версии - в 17, 13, 14 такого не встречал. Можно еще попробовать перед полной компиляцией удалить содержимое файлов db и incremental_db - там вся информация сохраняется с предыдущих разводок, иногда перед новой полной разводкой сохраняется и используется предыдущий результат.

Вы приведите отчет после ручного размещения ресурсов с отчетом об отсутствии ошибок (для варианта без ограничений на входные/выходные порты или их для анализа пока закройте - set_false_patch), просто кроме слов это тоже пока ничем не подкреплено. assignements->settings, дальше настройки фиттера и синтеза (окна могут меняться в зависимости от версии квартуса). Среди настроек - основное - синтез и оптимизация по скорости/площади/мощности, но самое главное - настройка фиттера - при fast может вообще забить на ограничения, там главное побыстрее все распихать. Но вообще интересный момент - это основные настройки и они должны быть прописаны в .qsf. В этом месте может быть глюк - Вы ограничения на вход в этой версии не задаете, поэтому квартусу пофиг на задержку до триггера, но, с другой стороны, по умолчанию он старается, по возможности, минимизировать длину путей. Я бы посоветовал для начала принудительно закрыть путь для анализа и считать этот путь асинхронным - set_false_patch.

А что Вы хотели увидеть, это отчет из поста 3 с Вашими ограничениями.

Не увидел настроек Fitter_effort и optimization_technique. Не знаю, каким образом может повлиять настройка smart_recompile, если менять только ограничения, по идее - никак. Значит с этим все в порядке. Если речь идет о пути сигнала reg_B->sum1, то есть еще путь от B до reg_B - о нем мне ничего не известно - укорачивая путь описанным образом от reg_B до sum1 Вы удлиняете путь от B до reg_B.

1. Вы не привели настройки для квартуса(синтез/фиттер).Может автофит стоит. 2. Распиновка жесткая? 3. Если входы и выход на разных концах плисины стоят, то может и не вытянуть при заданной частоте. 4. У Вас есть уверенность, что клок пошел по клоковой дорожке, а не обычной линии? Ощущение возникло, что после добавления ограничений на входы/выходы клок пошел обычным путем, отсюда ухудшение разводки, но их в любом случае требуется задать и, возможно, изменить немного архитектуру - входы на fast input/output register по обычному клоку, а логику по частоте с выхода pll, но это уже по документации и примерам. ЗЫ. У меня, к сожалению, нет возможности скачать Ваш проект.

Тогда он будет размещать элементы только в заданной области, но как захочет. Тут скорее подойдет какое-нибудь временное ограничение (типа set_min_delay, но лично у меня были какие-то проблемы с его использованием) ну или гвоздями прибивать, как Вы уже советовали. fast input register, если Вас устроит. to ViKo асинхронщиной решили заняться?

Вы откуда эту схему взяли? Попробуйте проверенную - выходной клок пропускается через DDR-регистр, в качестве клока подается выход pll, на один из входов данных 1, на второй 0. Таким образом, задержки до DDR-регистров по умолчанию компилятор выровняет согласно общим ограничениям, а от выхода DDR до пина разброс будет минимальным между клоком и данными. Вы привели описание временных ограничений, но никак не прокомментировали отчет TQ - применились они или нет, были ошибки (если да, то пути и что квартус попытался сделать). Для того, чтобы комментировать описанную Вами ситуацию, не хватает данных. Для начала откройте отчет и убедитесь, что в списке ignored_constraints отсутствуют описанные выше сигналы. ЗЫ. Еще один момент - для DDR же вроде описываются ограничения и для фронта и для спада отдельно с ключами -rise/fall. ЗЫЫ. Меня одного смутило, что у ТС max отрицательное значение имеет, а min положительное? Вроде как в данном случае описывается нестабильность клока относительно нулевой точки анализа - минимальная задержка слева от нуля, максимальная задержка справа, а тут у меня что-то заклинило...

Это интересно, спасибо. А как нагревали чип, если не секрет, и какова температура чипа была при комнатной температуре (или по умолчанию считается комнатной)? Я то сам только в термокамере грел жирные плисухи с термодатчиками, поэтому интересуюсь.

Тогда их положение лучше зафиксировать с помощью ограничений, причем чем короче будет путь, тем разброс будет меньше (для CPLD понятия не имею как можно и можно ли вообще, для fpga - set_location). Если осознание есть, то все получится - успехов.

У меня нет нелюбви к lcell, просто дополнительная логика лишь добавит временной разброс. Я исключительно против самого подхода использования ресурсов ПЛИС в качестве асинхронной логики, а вещи типа задержать сигнал на столько-то ps или сформировать генератор на логике в 1ГГц очень сложными (хотя и это при определенных условиях возможно). Я с Вами полностью согласен, просто лучше заранее подготовиться к возможным последствиям и оценить степень риска. Плюс не известно, что именно хотел ТС - может просто посмотреть, что задержку можно менять с помощью комбинаторной логики.

Это разброс, общая задержка до 10нс. ЗЫ. Сейчас провел анализ быстрый. К сожалению нет возможности прикрепить файлы. Можете проверить сами. Чип 5AGXFB5K4F40I5, протянул вход на выход по диагонали (пины AL33-G6). На самой медленной модели суммарная задержка 14.249нс, на самой быстрой 13.339нс. Т.е. разброс почти в нс, при этом сигнал идет один в один, т. е. нет дополнительных слоев логики. Ну и код: assign out=inp ЗЗЫ. Одна компиляция, только подставляется другая временная модель, приведенные задержки были SLOW, самая быстрая модель MIN_fast -40C для 1100mV дает задержку 8.025

Сильно будет зависеть от расположения пинов. Если обычная сигнальная линия по горизонтали, пересекая блоки дсп и память, то несколько нс (я для аррии 5 смотрел как-то). Точнее - только отчет TimeQuest для крайних углов анализа - по самой быстрой и медленной модели. :bb-offtopic: Периодически сталкивался с реализациями генераторов высокой частоты на инверторах (точнее lcell) на ПЛИС - в комнатных условиях на одном модуле все хорошо, ради прикола ставил мощный обдув и разработчик начинал впадать в ступор, не понимая что происходит. Я как обычно слона не заметил, извиняюсь. Может с CPLD и прокатит.

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

Ошибаетесь.

Делал недавно на похожей частоте на Воронежской плисине таймер, с времянкой проблемы были. Пришлось бить на несколько последовательных, суть следующая - при достижении максимального значения на первом формируется сигнал CE, записываемый в регистр, который служит разрешением счета для следующего.Таким образом, вместо одного счетчика разрядностью N соединяются последовательно два счетчика разрядностью N/2. Надеюсь суть описал понятно, кода под рукой нет. PS/ Вспомнил - у des00 в статье было :) http://embedders.org/content/timequest-dly...-litsom-k-litsu

Поменяли настройку, добавили строчку кода в любое место - процесс начнется заново и по другому сценарию. Вообще процесс использования партиций (post-fit) примерно следующий - создается проект, не обязательно топовый, в котором реализован алгоритм, создается партиция. Полностью все компилируется и, если получены требуемые характеристики, эта партиция экспортируется. Далее в топовый проект вставляется (импортируется) вместо RTL описания .qxp - файл. Этот вставленный кусок не будет синтезироваться и разводиться заново. Как правильно этим пользоваться расписано в документации. Пост-синтез - это партиция, в которой алгоритм реализован в виде базиса (его трогать компилятор не будет), но ничего не говорится о том, как этот базис ложится в самом кристалле, нет привязки к конкретным элементам, фиттер пойдет заново. ЗЫ. Можете посмотреть перевод на русском - http://www.naliwator.narod.ru/ , инкрементальная компиляция.

Поддерживаю полностью. Замечания ТС - у Вас партиция стоит post-synhteis при этом основное время компиляции тратится на fitter, т.е. выигрыш по времени будет минимальным, если вообще будет - добавляются дополнительные требования на размещение, в отличие от ситуации при отсутствии лоджик рута, Вы приводите скриншот после разводки, но процесс фиттера будет произведен заново и, естественно, картинки будут различаться. На партиции обычно разбивают не для экономии времени, а для впихивания невпихуемого и вытягивания таймингов. Для ускорения времени компиляции обычно оптимизируют сам проект и задают грамотно ограничения. Если хочется просто увидеть уменьшение времени компиляции, наплевав для начала на тайминги, можно ослабить настройки того же фиттера - fast fit :)

Использую контроллер реконфигурации один на все линии в логическом канале - в настройке interface bundles задается кол-во линий, остальное не выделено, т.е. без всякой реконфигурации PLL. Соответственно, подобных предупреждений поиском в своем отчете не нашел. У меня завелось все с ходу, подробно с контроллером не разбирался, ну мне как бы и не требовалось перенастраивать трансиверные каналы - подал сброс, произошла инициализация, совпали паттерны, пошел информационный обмен. Произошел сбой в любой линии (условие ошибки или не выделяется частота из входного потока данных) - все по новой - сбросил внешнюю pll, запустил автомат сбросов, далее инициализация и все заново.

Включен, протокол базовый 10/8. Вы правильно подключили на внешнюю pll клоки? На каждый логический канал (группу) требуется одна pll, внешний клок на специальную клоковую ногу (каждому триплету соответствует собственная нога, если объединение, скажем, по шести линиям, то любую из двух ног. Нельзя из триплета взять две линии под один канал, а оставшуюся под другой (при настройках, которые я выше описал). Что за ошибка? Каким образом Вы объединяете линии, какие настройки трансивера? ЗЫ. Самое главное забыл - тип трансивера - native, в документации было прописано, что только в нем можно заточить внешнюю pll(уже с полгода прошло, так что пишу по памяти, может для некотрых семейств по-другому или версийй).