Jump to content

    

Nick_K

Свой
  • Content Count

    752
  • Joined

  • Last visited

Everything posted by Nick_K


  1. Я предлагаю создать 2,3-да_сколько_угодно частот на одном порте простым объявлением (или дженерейтед клок). Фактически они будудут -logically_exclusive или -physically_exclusive так как одновременно не могут присутствовать, но в завосомости от настроек, будут переключаться. И далее на эндпоинтах (критических точках) уже заниматься конфигурацией необходимых констрейнов для конкретной частоты. Если нигде нет -stop_propagation то по умолчанию все клоки распространяются по всему клоковому дереву, а уже сама IDE должна разруливать подстройку констрейнов под конкретную частоту. Важный момент, если эти частоты генерируются в ПЛИС и выходят наружу, они должны быть обьявлены как частоты, а не как данные (для понимания тулами). Отсюда появится несколько частот по одним и тем же цепям. И да, с ниг придётся сделать ещё виртуальные, так как input/output delay создаётся только к виртуальным частотам. По вопросу насколько это можно - нужно проверить в конкретном IDE. Каденс тулы работают с такими вещами запросто, остальное нужно пробовать. Заодно по результатам расскажете где поднялось, а где нет.
  2. Мы делаем немного хотрее. Тул поддерживает несколько клоков в цепях по которым и делается анализ. Так в последнем проекте глобально по всему кристаллу проходило 5 клоковб 2 из которых были отличной частоты от основной. Для каждого клока делался констрейн и прописывался по всем нужным критическим точкам. Ну и понятное дело - не все эндпоинты получали одинаковый набор клоков. Отсюда можете попробовать задать несколько частот и констрейнов под них и сделать эксклюзивными (они ведь физически не могут быть в кристалле одновременно). Возможно у тулзы получится сделать нужные рассчёты и подтянуть нужную времянку.
  3. С этим могут быть проблемы, если нет авторизации
  4. Не много работал с DDR, но почему-то напрашивается констрейн для input delay, который сам отодвинет нужные события в положительную сторону, при этом настройки клокинг блока по сути останутся теми же.
  5. Ещё раз - я опечатался, сдвигать нужно вправо (сдвиг в лево - умножение). В право можно достичь нулевого бита и дальше суммирование сдвинутых данных не окажет никакого влияния на результат. Хотя возможно в таком контексте правильнее говорить, что мы ограничены разрядностью выходного слова.
  6. Расширить то можно, но если добить нулями, то в определённый момент любой сдвиг вправо перестанет давать результат. То есть вся математика опирается на количество знАчимых разрядов входного числа. P.S. В приведённой мной ранее сумме N=... сдвиг должен быть вправо. Опечатался)
  7. Попробуйте запустить planAhead и сделать нужные действия вручную. Всё это будет записано в тиклевскую консоль вывода в GUI, откуда можно скопировать в свой скрипт и запустить, немного подтюнив переменные/пути/называния. Не уверен насчёт ISE, но для Vivado поддерживается режим консоли. Фактически происходит запуск среды (IDE) в консоли без открытия проекта, что даёт возможность сорсить все свои скрипты, запускать команды и т.д. Опять же, на форуме Xilinx указано, что с Filter будет значительно быстрее - попробуйте оптимизировать скрипты и свериться с выхлопом planAhead
  8. Ну как получится. В пределах разрядности входного числа) Ибо само деление на 6 подразумевает умножение на 0,16-и-6 в периоде. Отсюда приближение. Опять же зависит от задач. Иногда и 64-х разрядов мало, а иногда и 6-7 с головой
  9. Я не говорил что у него PLL. Присто привёл пример. Такой подход используется во многои схемах. От формирователей импульсов, до частотных преобразователей и ADC/DAC систем. Вы же понимаете, что у ТС и так стоит на выходе счётчик, который и так досчитает до 82. А так придётся ждать 82+3.
  10. Я привёл пример из реального проекта делителя для PLL. Там математика не нужна и безсмысленна, а входное число меняется каждый отсчёт, так как нужно учитывать термодинамику элементов или изменять выходную частоту. А делитель нужен, чтобы сравнить референс с осцилятором. Праавда у меня челая часть за десятки заваливает, но есть и дробная и работает по тому же принципу.
  11. Тут вопрос действительно в том, где будет использоваться поделённое число. Если задача стоит в чистом делении и математических операциях, тогда с некоторой точностью можно взять сумму N=(N<<3)+(N<<5)+(N<<7)+(N<<9)... и далее все нечётные значения. Точного деления на 6 не будет, но максимально приближённое получится. Если же нужно поделить значение счётчика и на выходе есть некий интегратор/аккумулятор, тогда точное деление можно получить через Сигма-Дельта Модулятор (SDM). Суть заключается в том, что при делении на 6 будет происходить попеременное деление на 4 и на 8. А точнее выходной счётчик будет считать 2 отсчёта делённого числа на 8 и один отсчёт делённого на 4, в результате интегрирования будет среднее 6. На пальцах: 487 / 6 = 81,16(6) - из примера в первом посте 1. один осчёт на 1/4: 487 / 4 = 121,75 2. плюс отсчёт на 1/8: 487 / 8 = 60,875 ; Усредняем: (121,75 + 60,875) / 2 = 91,3125 (близко но не совсем) 3. и плюс ещё отсчёт на 1/8: 487 / 8 = 60,875 ; Усредняем всё вместе: (121,75 + 60,875 + 60,875) / 3 = 81,16(6) И снова повторить с п.1. Важным условием является наличие выходного интегратора (для PLL, к примеру, используется Low Pass Filter)
  12. Я не работал с DDR на Альтере, но у Xilinx при подключении RAM во входном "каскаде" нужно использовать частоту, генерируюмую с выхода DDR контроллера, не смотря на то, что он так же питается с внутреннего PLL. А дальше где-то дорисовать CDC или пройти через двухпортовую RAM/FIFO. Насколько я понял там частота (читай фаза) своя со своим клоковым деревом для точной синхронизации.
  13. Если DIVIDER - порт, то конечно нет) Всегда придётся вычитать значение от заданного предела. Пример интересный, но здесь получается один сумматор и один вычитатель (который будет оптимизирован с +1). И всё бы ничего, но по экспериментам функция меньше-равно, занимает меньше места в лутах) Можно в обратную сторону считать - не вопрос. Но тогда сравнивать с нулём придётся, при условии что вычитатель немного сложнее сумматора (или вообще CSA для лутов Xilinx). Либо пересчитывать на 1 такт больше, если использовать сигнал borrow.
  14. На вычетании 2-ки Вы дополнительно городите ещё один сумматор (вычитатель). Насколько я понял ТС нужен минимальный по площади делитель с максимальной гибкостью. Я сейчас занимаюсь потодного рода проектом и могу с уверенностью сказать, что такая схема будет оптимальна по площади и быстродействию. Единственное ограничение - частота работы => коэфф. деления. Для разрядности 6-10 бит вполне свободно на 100МГц можно уместить (в зависимости от чипа). Для большей разрядности нужно уменьшать частоту работы. По поводу буфферов - да желательно использовать BUFG, но иногда можно и BUFH, коих вполне достаточно для Xilinx чипов.
  15. Ясно, лицензионные махинации)
  16. Извиняюсь за непросвещённость, но что такое daemon xilinx?
  17. Многое зависит от технологии (где-то допустимо, где-то нет), но в общем случае да, такое возможно. Если гейт один и вокруг пусто а он сам молотит на бешенных частотах, то он может нагреваться и до 130-150% (по крайней мере я видел такие числа в корнер библиотеках неПЛИСов). И соответственно он будет рассеивать тепло вокруг, что глобально приведёт к меньшей общей температуре. Именно поэтому всё это дело запихивают в печку и нагревают до 85-95-100-130 градусов, чтобы обеспечить равномерное нагревание всех без исключения компонентов и заявить в документации с какой предельной температурой могут работать кристаллы без деградации и с заданными характеристиками. И да, токи утечки и т.п. также оценивают в печках. То есть все компоненты нагревают до +/- одного состояния и меряют затраты. Даже если в данном проекте физически так быть не может, но нужно написать детально в доке, что будет. Вы ведь не хотите, чтобы купленный кристал, с заявленными характеристиками работы на 25 градусов и потреблении условно 1Вт, вдруг в жаркий июньский день резко начал потреблять до 3-4Вт, потому что жарко, а начальник вам зажлобился поставить кондиционер в офис?
  18. Вы не учитываете одну важную деталь - индивидуально элементы могут греться и до большей температуры (флопы/транзисторы), но в слечае маленькой утилизации и относительно большой площади, теплорассеивание приводит к "комнатной температуре" кристалла. И наоборот, если запустить проект при утилизации ресурсов под 95-98%, тогда камень далеко не комнатной температуры, а иногда может обжигать пальцы (по крайней мере на Spartan-6 я так делал). Для этого и делается характеризация в печке и термоиспытания. Ровно как для подтверждения корнеров техпроцесса. P.S. Кстати интересно, можно ли поднять 1ГГц будет. На Виртексах вроде бы можно, и тут спидгрейд вроде бы такой же (техпроцесс с корнерами).
  19. При условии, что ками официальные, то никоим образом термоиспытания не могут повлиять на производительность камня. Может быть нарушено что-то дополнительно, как структура текстолита, пропайка, другие компоненты - но тогда это проблема ассемблеровщика. И конечно если все компоненты имеют поддерживаемые режимы работы по документам, то ничего не должно меняться.
  20. Всё правильно. Данный IP инстанциируется только после синтеза, а во время него присутствует только как black box. О чём также говорят названия портов. На синтезе их нет, вот и синтезатор ругается. По сути всё что касается хард IP также должно относится к имплементационным констрейнам. Но и тут, как водится, есть исключения. К примеру если использовать не IP а макрофункцию для, например, RAM, тогда любые отношения можно задавать через сигналы этого инстанса, но после синтеза он конвертируется в IP и соответственно названия портов могут отличаться (если не сохранятся названия макрофункции как враппера).
  21. Насколько мне известно прямо чёткого разграничения на констрейны нет. Да обьявление частоты, создание генерированной и разные multicycle/false_path нужны для синтеза безусловно. Но вото ситуативные констрейны типа груп виртуальных клоков и т.д. являются именно ситуативными. Ибо если клоковая группа нужна для некого флорплана, тогда в синтезе она бесполезна, а вот если между клок группами обьявлен мультицикл - тогда это влияет на синтез напрямую. Точно так же разные "физические" констрейны относятся только к имплементации, как локация на кристалле или специфические компоненты в схеме. Конечно это можно проанализировать для своего проекта и посортировать, но под глобальное правило это не вписывается. Тут также не стоит забывать про разные настройки синтеза, которые могут переводить некоторые констрейны в "синтезабельные" и как-бы потом не вышло казуса при изменении этих самых настроек. Пусть меня поправят, но для чистоты отчётов я бы посоветовал перевести все констрейны с обращением к физическим обьектам в раздел имплементируемых констрейнов и оставить всё остальное для синтеза.
  22. У меня нет) Да и задачи такой не стояло. Мне нужно запихнуть инициализацию памяти и флопов для SPICE симуляции, но это немножко за пределами этой темы)
  23. А зачем? Там же логики понт) Разве что поиграться энтузиастам, у которых нет денег на нормальный кристалл) Кстати там тоже есть 2 типа памяти по приницпу старших моделей?
  24. Я могу ошибаться, но кажется .mif файл должен содержать только одиницы и нули. Никакого текста или дополнительных словосочетаний от слова совсем. А вот это - это припроетарная структура от вендора. Просто нет проекта старого под рукой, чтобы перепроверить. Попробуйте создать файл типа 0000 0001 0100 1001 ... и т.д. или с запятыми в конце каждой строки. p.s. Ошибся, .mif и вправду указанного выше формата. Тем не менее попробуйте указанный выше формат, иногда помогает.
  25. А Вы уверены, что эти четыре числа именно list? Это может быть collection, кака я указывал ранее. Можно попробовать ввести эти значения вручную. Если ошибка повторяется, значит проблема не в площади. Это из очевидного. Неочевидное не подскажу, возможно есть какие-то детали.