Krys
-
Постов
2 052 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Krys
-
-
это возможно связано с той самой проблемой 4 слов датамувера, которую мы с Вами уже обсуждали. И тогда кажется Вы куда-то пропали и не отписались, что вышло.
4 слова датамувер принимает всегда, даже если ему не было команды на приём. Это те самые 16 байтов. Ваши 112 байтов + эти 16 и получается 128 байтов. Что конкретно происходит - не берусь судить, конкретно с этим ядром не работал. Но похоже у них у всех одинаковое поведение.
-
Это возможно связано с разными способами представления периодического спектра. Одна функция показывает спектр от 0 до Fs, а вторая - от -Fs/2 до +Fs/2. Хотя вообще-то функция fft в матлабе показывает спектр вторым образом, т.е. должны быть палки и 100кГц и 900кГц. А чтобы было первым образом, в матлабе есть функция fftshift: http://www.mathworks.com/help/matlab/ref/fftshift.htmlИ заодно хочу спросить элементарную вещь: почему в MATLAB при выполнении ОБПФ длиной 1000 выборок при частоте дискретизации 100 кГц, например, в спектре длиной 1000 выборок появляется лишь одна гармоника 100кГц, а при выполнении ОБПФ на C# получается две гармоники - 100кГц и 900 кГц? -
а у меня его нет, он был на прошлой работе, но там запрещено что-то выкладывать )) Сейчас это на новой работе пока не требуется. Почитайте эту тему и найдите ещё поиском похожие темы, они точно были. Возможно, там уже приводили готовые скриптики. В целом, ничего сложного нет - надо потратить денёк, читануть, как пишут тикль скрипты и написать свой )
-
-
Я вообще не обращаю внимание на сообщения синтезатора о тайминге в конце синтеза. Смотрю только после PAR.
А по поводу утилизации: результат может быть достигнут довольно близкий (синтез к PAR), если в PAR выключить все оптимизации типа registers duplication и т.п. Но кому это надо? Лучше просто не смотреть на сообщения синтезатора )))
-
Это всё понятно. Но мой вопрос был в том, что изначально было предположение, что PAR расходует элементы (допустим LUT) на интерконнект там, где по результатам синтеза LUTа быть не должно, а должна быть прямая связь. Вывод из предыдущих Ваших скриншотов такой, что предположение было ошибочным? Там потом ещё ув. jojo написал, что были задействованы лишь статические мультиплексоры, которые не задействованными и не могли быть. Т.е. их задействование неверно относить к аргументу в пользу предположения.Синтез этого не предлагает. Он определяет только количество функциональных элементов.Затем плейсмент размещает все эти элементы в заданной модели FPGA.
Затем роутинг ищет пути соединения этих элементов (возможно перемещает и сами элементы), удовлетворяющие констрейнам.
Да, это тоже всё понятно, не спорю. Особенно бывают всякие схемы оптимизации типа registers duplication и т.п.До окончания роутинга все оценки таймингов и занятых ресурсов - приблизительные. -
Я правильно понял, что всё же причина не в этом, и ячейки под интерконнект не расходуются (по крайней мере сверх того, что предложил синтез)?сколько ячеек будут заняты под интерконнект. -
В том-то и заключается моё удивление, что я такого никогда не видел в схематике после роутинга. А Вам несложно какой-то живой пример, где например вот кусок кода описывающий прямую связь между регистрами, а вот схема, где эта прямая связь - вовсе не прямая, а через допустим LUT?
-
Выделено синей линией:
-
Чот сказки какие-то )) Подикась изначально неоптимально написано. Наверное на сверхвысоком уровне (со взгляда программиста, а не схемотехника). Потом Synplify догадывается, что программист имел в виду, а XST не догадывается. А если бы писал разработчик с мышлением схемотехника, то и XST бы догадался.+Sinplify: проект, который на XST дает 150 Мгц, на Sinplify дает 250МГц. -
Подскажите, пожалуйста, как ячейки бывают занятыми под интерконнект? Если между двумя регистрами надо прокинуть связь накоротко, а ячейка представляет собой например LUT, то PAR будет прокидывать связь через LUT, а не напрямую?сколько ячеек будут заняты под интерконнект. -
Вы бы нарисовали, может так понятнее будет.
-
Для сложения - без разницы. А для умножения - согласен, могут быть нюансы. И то, у Xilinx реализован аппаратный умножитель чисел дополнительного кода, так что это для него нативно.Ничего подобного. При умножении надо указывать $signed иначе будет непредсказуемая ерунда, даже если указана знаковая переменная. -
Спасибо, т.е. изначально в передаваемый сигнал подмешивается некий "пилот"? Тогда в приёмнике, зная все параметры этого "пилота", можно понять, куда весь спектр после переноса уехал?
-
А подскажите, пожалуйста, за счёт чего коэффициенты децимации 2 дают экономию умножителей? За счёт half-band фильтров?Более того, если использовать коэффициенты децимации равные 2 и дециматоры цепочкой, то экономия аппаратных умножителей вообще будет бешеная...
А это уже не вопросы )))4. При использовании БИХ фильтров требуется дикое количество дополнительных разрядов. Фильтр их съедает и не давится. Данные на входе нужно расширять, заполняя младшую часть битами обратным знаку. В старшей части исходное число, разумеется.5. При использовании КИХ фильтров возможны проблемы если результат умножения округляется сразу после умножения, а не на выходе фильтра после суммирования. Плюс, если коэффициенты маленькие относительно выбранной разрядности. Тогда проблемы сходные с п. 4. Что выливается в паразитных лепестках после основной полосы.
-
Либо двухпортовую память ))соответственно, нужно либо 2 такта, либо опять две таблицы. -
Хорошо, допустим с таблицами понятно.
Хотя тоже не очень. Если Вы говорите про линейную поправку, подразумевая кусочно-линейную сплайн-интерполяцию, то почему бы её без таблицы не сделать примерно такой записью:
A[phase[15:8]] + (A[phase[15:8 + 1'b1]] - A[phase[15:8]]) * phase[7:0] / 256
?
Т.е. берутся 2 соседние точки таблицы, между ними проводится прямая, конкретная точка на прямой определяется младшими разрядами фазы.
Остаётся тогда вопрос: что за 4 счётчика?
-
Ааа, тогда вопросов нет, спасибо.
Точнее остаются вопросы к ув. Corner, как пользоваться 2 табличками на 256 и что за 4 счётчика
-
иногда просто под аккумулятором понимается сумматор с регистром хранения предыдущих данных. Без суммирования не накопить.
А здесь похоже под аккумулятором понимается просто регистр. Зачем тогда путать людей и использовать один термин вместо другого...
Начальную фазу fi можно затолкать сразу в регистр аккумулятора как начальное значение. Тогда её не придётся постоянно прибавлять к текущей фазе wt
-
И как пользоваться поправочной табличкой? Может, дадите ссылку, что читануть по этому поводу?
И вот Вы пишете:
"Стандартный DDS это аккумулятор+сумматор фазы+табличка."
непонятно: чем аккумулятор отличается от сумматора фазы?
-
Не очень понятно, про какие 4 счётчика идёт речь?
-
Вам-то хорошо гадать про других людей, сами-то о себе никакой информации в профиле вообще не оставили... Вы из какого города?У вас там в Чебоксарах -
ТС, Вы куда исчезаете так надолго? Потом приходится людей опять в тему созывать через приват...
-
Огромное спасибо! Это самый "кошерный" вариант. Остальные - самодельные костыли ))
PlanAhead - запуск bitgen
в Среды разработки - обсуждаем САПРы
Опубликовано · Пожаловаться
Расширю вопрос. Есть несколько стратегий разводки в планахед, запущенных в параллель на разных ядрах. Хочется, чтобы в конце разводки каждой автоматически запускался битген. Как это настроить, подскажите пожалуйста.