KWIer

Intel рекомендовала добавить дополнительные назначения в проект. С ними всё ок по таймингам. Осталось только узнать как и откуда они взяли эти числа? И почему фиттер сам не может до этого догадаться?

Так, похоже всё дело в PLL. В новых версих при использовании Source Compensation Mode появляется Warning Warning (176441): The I/O pin RX_DATA[7] cannot meet the timing constraints due to conflicting requirements. The I/O pin is a PLL compensated I/O, but the setup/hold requirements are in conflict with the source PLL mode(source synchronous or ZDB). Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[6] since it's a PLL compensated pin Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[5] since it's a PLL compensated pin Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[4] since it's a PLL compensated pin Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[3] since it's a PLL compensated pin Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[2] since it's a PLL compensated pin Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[1] since it's a PLL compensated pin Warning (176441): The I/O pin RX_DATA[0] cannot meet the timing constraints due to conflicting requirements. The I/O pin is a PLL compensated I/O, but the setup/hold requirements are in conflict with the source PLL mode(source synchronous or ZDB). 1) Я всегда считал, PLL в этом режиме наоборот должен улучшать времянки, за счет подстройки по входной частоте. 2) Если PLL вообще исключить, то запас по слакам ~0,7 ns и по Setup и по Hold

Я тоже это заметил, но чип специально выбирал одинаковый в обоих случаях - EP4CE6E22A7. Подскажите, есть ли способ в ручную заставить quartus использовать LCCOMB_X1_Y18_N28 вместо LCCOMB_X1_Y18_N4? Где можно почитать как это сделать? Хочу проверить, уложится ли в тайминги если вручную прописать путь. Никогда раньше этого не делал, полностью доверял фиттеру, видимо зря.

Для интереса скомпилировал проект в Quartus 18.1 под Linux, менял корпуса на BGA (они по задержкам на выводах отличаются от QFP), уменьшил ширину шины данных до 1 разряда, жестко задавал pin placement, прогнал 15 итераций исходного проекта с разными сидами в Design Space Explorer II (18.0). Ни одна из итераций так и не уложилась в тайминги.

Сравнил по размещению PLL - используются одинаковые входные PINы в обоих случаях, теже IOBUF, PLL, CLKCTRL, а вот дальше Фиттер зачем-то развел на разные FF. 2) Запас по Setup был, сдвинул фазу на -500ps - тайминги в норме, по 300ps в запасе по Setup и Hold. Но вопрос почему фиттер в новых версиях не смог сделать то что делал без проблем в ранних версиях, остается открытый!

Спасибо за интерес к данному вопросу! Подробности - пример взят из руководства Rysc - Source Syncronous Timing (Case 2: The FPGA is the receiver and does not phase-shift the clock). Pll в режиме Source-synchronous compensation, сдвига по фазе в pll нет. Непонятно почему в новых версиях Квартус не уладывается в тайминги, а в старых все хорошо? Назначения выводов данных и тактов не определено, фиттеру развязаны руки. Вот несколько репортов.150 МГц - Quartus 11 - Слаки положительные. EP4CE6E22A7. Как в архиве в 1 посте. Отчет по Hold: Отчет по Setup: ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Тот же проект, в Quartus 16.1. Обновил ALTDDIO_IN,ALTPLL -перекомпилировал проект. Слаки отрицательные по Hold.

В том то и дело, по документации, LVDS должен работать на прием с частотой до 402.5 МГц Файл с констрейнами подцепляется нормально, видно по отчетам в Timequest. Но всё в слаках по Hold

Привет. Я пытаюсь описать временные ограничения для проекта с 8-разрядной шиной DDR. Я взял образец документа из вики и сопроводительную документацию, предоставленную пользователем Rysc (https://fpgawiki.intel.com/wiki/File:Source_Synchronous_Timing_Projects.zip). Пример № 2 - приемник, тактовые импульсы по центру данных, скомпилировал в Quartus v11 как есть - тайминги выполняются. Я заменил FPGA на Cyclone IV (speedgrade 7), увеличил частоту pll до 150 МГц, скорректировал sdc-файл - времянки все еще в порядке. Затем я открываю тот же проект в новых версиях quartus 13.1, 16.1, 18.0 - обновляю мегафункции PLL/ALTDDIO_IN и перекомпилирую - тайминги терпят неудачу! Что может быть причиной этого? Несколько вариантов: 1. В версиях выше 11, фиттер был переписан, и он не оптимизирует размещение так тщательно. 2. Добавлены дополнительные проверки по времени, которые просто не выполнялись в более ранних версиях. 3. Специально ухудшили ip-core / fitter, поэтому мы должны покупать более скоростные FPGA. Я не могу поверить, что Cyclone IV не может получать данные с частотой 150 МГц / 300 МBPs с помощью altddio_in. Прикрепить архив с отредактированным проектом для тактовых импульсов 150 МГц не получилось. Ссылка на него https://cloud.mail.ru/public/ACnv/NpTj4rEGk Всем заранее спасибо за идеи!

Понятно что переделывать... В Altiume все время так, из коробки ничего не работает, все надо переделывать! Тут больше вопрос политический, почему приобретя продукт, причем не дешевый, приходится править шаблоны, которые изначально некорректно сделаны? Я вот допустим Excel знаю на уровне ввел значения в таблицу, написал простенькую формулу, нарисовал график. У меня нет желания тратить время и разбираться как работают шаблоны, макросы и рисуются примитивы в режиме разработчика, но ведь придется, задачи-то надо решать...

Скажите, а почему в этих шаблонах в рамке 6 полей (как в форме 1), хотя в гост 2.701-2008 написано, что рамки в перечне выполняют по форме 2, 2а (исключается строка Т.контр)? Может кто дорабатывал шаблон с учетом этой особенности?

Ах, если бы открылся файл.. Посмотреть содержимое AD после ошибки не дает.. Но Вы натолкнули меня на верное решение: поискал по содержимому .SchDoc-файлы строчки FONTNAME и сравнил с уже установленными в системе - оказалось виноват шрифт Arial Narrow. Прикреплю во вложение. NB. После установки шрифта обязательно перезагрузить Altium. arrial_narrow.rar

Шрифт был установлен. Обновил для надежности - ошибка осталась!

Кстати, в догонку, к предыдущему посту. У меня в версиях 16.0.5 и 16.0.8 при импорте многослойных ПП из P-CAD (.Pcb-файлы) отображаются только наружние слои. Внутренние видны только в Layer Stack Manager. pl_sensor_1.pcb

Хотел разобраться с генерацией перечней из AD, скачал проект-пример с офф вики http://wiki.altium.com/pages/viewpage.action?pageId=52864505 (в самом низу) При открытии SchDoc-файла проекта пишет "FontStyleNotFound". У кого есть возможность, проверьте у себя, пожалуйста, чтоб знать куда копать. Altium 16.0.8 build 354 Win7 x64 Максимальная Шрифты GOST установлены в системе. плагин GOST установлен в AD

Заинтересовала модель энкодера F3653 фирмы Kubler (см. вложение). После изучения даташита и прочтения форума остались вопросы. Подскажите, пожалуйста, по однооборотным абсолютным оптическим энкодерам: 1) Разрешение на выходе (напр. 17 бит) однозначно говорит о том, что с помощью этого энкодера можно мерить 131к положений на круг и получить точность 10" ??? или это просто параметры выходного интерфейса? Например, в одной серии энкодеров по заказу можно получить 13-17 бит. т.е. скорей всего на точность больше 13 бит рассчитывать не стоит? Тогда где узнать реальную погрешность измерения угла поворота для этой серии? Например, у энкодеров GBA2S фирмы Baumer при разрешении 18 бит, есть параметр Absolute Accuracy = ±0.01°. 2) реально ли на оптических энкодерах получить абсолютную точность измерения в 10 секунд?? При диаметре в 58мм (лучше - меньше). 3) какие ньюансы стоит учитывать при использовании оптических энкодеров? F3653_F3673_en.pdf