Nick_K

Мы делаем немного хотрее. Тул поддерживает несколько клоков в цепях по которым и делается анализ. Так в последнем проекте глобально по всему кристаллу проходило 5 клоковб 2 из которых были отличной частоты от основной. Для каждого клока делался констрейн и прописывался по всем нужным критическим точкам. Ну и понятное дело - не все эндпоинты получали одинаковый набор клоков. Отсюда можете попробовать задать несколько частот и констрейнов под них и сделать эксклюзивными (они ведь физически не могут быть в кристалле одновременно). Возможно у тулзы получится сделать нужные рассчёты и подтянуть нужную времянку.

С этим могут быть проблемы, если нет авторизации

Не много работал с DDR, но почему-то напрашивается констрейн для input delay, который сам отодвинет нужные события в положительную сторону, при этом настройки клокинг блока по сути останутся теми же.

Ещё раз - я опечатался, сдвигать нужно вправо (сдвиг в лево - умножение). В право можно достичь нулевого бита и дальше суммирование сдвинутых данных не окажет никакого влияния на результат. Хотя возможно в таком контексте правильнее говорить, что мы ограничены разрядностью выходного слова.

Расширить то можно, но если добить нулями, то в определённый момент любой сдвиг вправо перестанет давать результат. То есть вся математика опирается на количество знАчимых разрядов входного числа. P.S. В приведённой мной ранее сумме N=... сдвиг должен быть вправо. Опечатался)

Попробуйте запустить planAhead и сделать нужные действия вручную. Всё это будет записано в тиклевскую консоль вывода в GUI, откуда можно скопировать в свой скрипт и запустить, немного подтюнив переменные/пути/называния. Не уверен насчёт ISE, но для Vivado поддерживается режим консоли. Фактически происходит запуск среды (IDE) в консоли без открытия проекта, что даёт возможность сорсить все свои скрипты, запускать команды и т.д. Опять же, на форуме Xilinx указано, что с Filter будет значительно быстрее - попробуйте оптимизировать скрипты и свериться с выхлопом planAhead

Ну как получится. В пределах разрядности входного числа) Ибо само деление на 6 подразумевает умножение на 0,16-и-6 в периоде. Отсюда приближение. Опять же зависит от задач. Иногда и 64-х разрядов мало, а иногда и 6-7 с головой

Я не говорил что у него PLL. Присто привёл пример. Такой подход используется во многои схемах. От формирователей импульсов, до частотных преобразователей и ADC/DAC систем. Вы же понимаете, что у ТС и так стоит на выходе счётчик, который и так досчитает до 82. А так придётся ждать 82+3.

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

Тут вопрос действительно в том, где будет использоваться поделённое число. Если задача стоит в чистом делении и математических операциях, тогда с некоторой точностью можно взять сумму 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)

Я не работал с DDR на Альтере, но у Xilinx при подключении RAM во входном "каскаде" нужно использовать частоту, генерируюмую с выхода DDR контроллера, не смотря на то, что он так же питается с внутреннего PLL. А дальше где-то дорисовать CDC или пройти через двухпортовую RAM/FIFO. Насколько я понял там частота (читай фаза) своя со своим клоковым деревом для точной синхронизации.

Если DIVIDER - порт, то конечно нет) Всегда придётся вычитать значение от заданного предела. Пример интересный, но здесь получается один сумматор и один вычитатель (который будет оптимизирован с +1). И всё бы ничего, но по экспериментам функция меньше-равно, занимает меньше места в лутах) Можно в обратную сторону считать - не вопрос. Но тогда сравнивать с нулём придётся, при условии что вычитатель немного сложнее сумматора (или вообще CSA для лутов Xilinx). Либо пересчитывать на 1 такт больше, если использовать сигнал borrow.

На вычетании 2-ки Вы дополнительно городите ещё один сумматор (вычитатель). Насколько я понял ТС нужен минимальный по площади делитель с максимальной гибкостью. Я сейчас занимаюсь потодного рода проектом и могу с уверенностью сказать, что такая схема будет оптимальна по площади и быстродействию. Единственное ограничение - частота работы => коэфф. деления. Для разрядности 6-10 бит вполне свободно на 100МГц можно уместить (в зависимости от чипа). Для большей разрядности нужно уменьшать частоту работы. По поводу буфферов - да желательно использовать BUFG, но иногда можно и BUFH, коих вполне достаточно для Xilinx чипов.

Ясно, лицензионные махинации)

Извиняюсь за непросвещённость, но что такое daemon xilinx?