serjj1333

Объясните, зачем подключать std_logic_unsigned, если подключена numeric_std? По приведённой мною ссылке: This article is based on an email conversion I had with one VHDL expert.If you browse through some forums about VHDL then you may see some suggestions such as , use "numeric_std" library instead of "std_logic_arith" and "std_logic_unsigned" std_logic_unsigned это ещё одна библиотека синопсис, которая к ieee имеет весьма опосредованное отношение (собственно их библиотеки вкорячили в пак ieee только по инициативе компании). Если уж использовать VHDL, то тогда ИМХО нужно соблюдать его строжайшую типизацию, которая не допускает signed/unsigned арифметики с типом std_logic_vector. Библиотеки std_logic_signed/std_logic_unsigned нарушают это удтверждение, что противоречит стандарту. Вместо этого numeric_std вводит типы SIGNED/UNSIGNED и арифметические операции для работы с ними (никаких дополнительных стандартных библиотек для арифметики не требуется). Библиотека std_logic_arith может иметь различную реализацию у разных производителей софта, что тоже делает её использование уязвимым. Коротко и ясно это описано здесь.

Не используйте STD_LOGIC_ARITH/STD_LOGIC_UNSIGNED и numeric_std одновременно. Вообще лучше не использовать STD_LOGIC_ARITH/STD_LOGIC_UNSIGNED, вместо этого применять только numeric_std (numeric это библиотека IEEE унифицированная среди всех производителей софта и сделанная строго по стандарту VHDL, arith и unsigned - библиотеки Synopsis). Подробнее можно прочитать, например, тут и тут

Вот тут выкладывал

Решение красивое, но что будет, если а) добавить шум, б) добавить интерференцию Можно привести пример. Из пространственного спектроанализа, но сути это не меняет. В АФАР можно определить направление на цель всего по 2-м сенсорам, оценив задержку сигнала, полученного с одного сенсора относительно другого. Однако эта схема работает с относительно сильными и узкополосными сигналами, не содержащими интерференцию. Если же это условие не выполняется (что происходит довольно часто), то придётся а) наращивать количество сенсоров (т.е. количество сэмплов для анализа) и б) усложнять алгоритм (в отличие от временного спектроанализа, где мы в основном можем увеличить длину выборки, в пространственном размер решётки ограничен, т.е. Фурье с его малым разрешением неприемлим). Давайте рассмотрим аналогичную задачу (но сделаем её ещё сложнее): символьная частота = 100 кГц, ОСШ = 60 дБ, частота сигнала = 80,348 Гц, количество символов для анализа = 1024 + 128 (как видно из картинки - менее одного периода), погрешность ~ 0,001 Гц.

Я эти вопросы привёл не потому что хочу получить на них ответы, а чтобы проиллюстрировать, что нужно держать в голове приступая к задаче выделения сигнала из смеси в случае одномерной задачи. То, что вы написали - прописная истина, я же имел в виду цепь рассуждений - есть смесь из двух или более сигналов, если мы хотим разделить их фильтром, то как выбрать полосу фильтра (знаем ли мы априори соотношение частот или нет) - далее, если с полосой определились, мы можем оценить требуемый порядок для выбранной структуры и подавления за полосой - порядок в свою очередь даст нам latency, по формуле, которую вы представили. Так вот, может оказаться, что а) мы ничего не знаем о соотношении полос, б) полоса слишком узкая, что даст большую latency, в) задача не real time (как у ТС), г) шумами можно пренебречь, поэтому возможно использовать простые численные методы и т.д. В этих случаях КИХ неприменим или избыточен. Только после проработки данных вопросов можно приступить к самому КИХ фильтру (делов на 5 минут). Нужно задачу с головы решать :rolleyes: А у ТС вообще всё просто оказалось.

Пожалуй да, но нужно кое-что прояснить, раз такое дело Вы неправы, вот вам пример: и Господа Марпл, Хайкин и пр. в своё время много сил положили на спектральный анализ коротких выборок и/или разделения близко расположенных по частоте сигналов, а вы говорите, что не существует. Разрешающая способность преобразования Фурье по частоте не является непреодолимым и фундаментальным, она определяет разрешение только для этого метода и производных от него (периодограммы, коррелограммы), а не всего спектрального анализа. Другое дело, что у каждого метода есть свои ограничения и подводные камни, и Фурье самый универсальный и "неприхотливый" по условиям применения и ресурсам. Но когда есть задача по малому количеству отсчётов определить частоты гармоник, входящих в смесь, удтверждать, что задача физически нереализуемая только на основании теории Фурье - неправильно.

не помню как в ISE, в квартусе в Analysis & Synthesis/Optimization Results/Register Statistics/Register Removed During Synthesis есть список "сокращённых" регистров. Для логики такого не нашёл, подозреваю, что она выбрасывается на уровне логической оптимизации, т.е. синтезатор в праве заменить логическую цепь на более простую и короткую при условии совпадении таблиц истинности. При этом никаких сообщений не нужно, т.к. функционально ничего не меняется. Есть подозрение, что и в ISE что-то подобное происходит.

Универсальный метод, да, но позволю себе не согласиться. Метод плох при малом количестве элементов выборки, т.к. для существенного разрешения по частоте требуется довольно большое количество отсчётов.

1 - какую полосу фильтра брать? 2 - какой порядок (и как следствие latency) из этого порядока последуют? Имхо при высоком сигнал-шуме, это из пушки по воробьям.

Ну вот вы б попробовали, а уж если бы не получилось, тогда бы спросили. Какая-то неправильная тенденция пошла - выкладывать текст Error/Warning с просьбой указывать о чём он говорит и что делать. Во первых в нём написано, во вторых у производителей есть всевозможные issues и bug reports, в которых всё разжёвано... Не говоря уже о XAPP от Xilinx, весьма годные доки..

Я бы начал копать с

Он их расценивает именно как некоторую логику, а не как задержку. И пытается её соптимизировать, сокращая все операции, которые в сумме сигнал не изменяют. А для той логики, что останется, будут оценены задержки на этапе sta, при условии, что у вашей цепи есть триггеры на входе и на выходе, т.к. sta умеет анализировать только межтриггерные пути (в логике общего назначения). Как задержку синтезатор умеет отслеживать только триггеры и соответствующие модули точной задержки (например iodelay, но это уже немного другое). Трактовать комбинаторную схему как элемент некоторой задержки неправильно, т.к. комбинаторный элемент выполняет некоторую функцию преобразования, а вносимая задержка это не цель а средство, или т.с. "плата" (применимо к ПЛИС во всяком случае). Зачем же синтезатору выводить идеологически неправильные сообщения?)

да такую задачку можно решать не одним способом, просто перед реализацией надо задать себе вот такие вопросы: 1 - какие сигналы могут присутствовать в смеси? --имеются в виду и всевозможные шумы тоже 2 - при каком минимальном соотношении сигнал-шум и сигнал-помеха алгоритм должен корректно отрабатывать? 3 - какова допустимая ошибка эстиматора? 4 - на чём я буду этот алгоритм реализовывать? -- если это матлаб, то тут все средства хороши, но если это дохлый контроллер без fpu, то уже стоит задуматься 5 - нужен ли real time? 6 - если нужен real time, какой latency я могу себе позволить (это к вопросам о фильтрах) Может быть я что-то забыл, но ИМХО это минимум, на который стоит найти ответы перед тем как сесть и запилить :rolleyes: Ну просто мы сигнальщики и привыкли работать с сигналами, не задаваясь вопросами откуда там взялась помеха или шум, просто берешь и обрабатываешь) Автор нарисовал картинку и сросил как из неё другую картинку получил, вот ему и советуют.

А в чём проблема применять фильтрацию? Медианное сглаживание с окном большим периода гармонического сигнала + скользящее среднее или просто узкополосный ФНЧ, который отрежет гармоническую составляющую? У вас есть априорные данные о соотношении частот НЧ и ВЧ составляющих в сигнале? Если да, то не виже никаких проблем с фильтрацией, т.к. сигналы разесены по частоте. Если же априорных данных нет, то можно посмотреть в сторону BSS (blind signal separation).

в матлабе вот так можно j = 0; for k=2:length(x)-1 if sign(x(k+1)-x(k)) != sign(x(k)-x(k-1)) extr(j) = k; j = j + 1; end end математический принцип вам верно сказали, но т.к. аналитически функция неизвестная, то нужен численный метод. Ну и это не будет работать в случае, если в сигнал добавить шум, нужно его сначала как-то фильтровать, у схемы будет более высокий порядок просто, который будет зависеть от сигнал-шума.

hwlib это песня... :rolleyes: nand запустил на ней только после того, как туда залез. А функция alt_nand_flash_page_read оказалось некорректно работает с массивами произвольной длины и нужно их выравнивать к page size. Например, если page size = 512 слов, а буфер чтения - 16 слов, то вычитать то он вычитает, но всю страницу. Т.е. первые 16 слов поместит в указанный буфер, а остальные 496 - запишет по соседству, поверх всех переменных расположенных в памяти за буфером на чтение... С чуваком пол дня эту "фичу" отлавливали, пока не стало понятно, что происходит, весьма небезопасная и кривая реализация ИМХО. Тоже hwlib исходники иногда почитываю, там в хедерах по сути недостоющая документация находится, которую они не удосужились в pdf собрать :smile3046: А на пингвине вообще как? поприятнее работа идёт или тоже глюк на глюке?

Kuzmi4, спасибо большое! Заработало. Не понял только, почему функция из hwlib для инициализации мостов не отрабатывает как положено. И может подскажите, где бы почитать каких нибудь документов, статей по низкоуровневому запуску разных модулей в HPS? Или вы от карты регистров всегда только отталкивались?

volatile unsigned int *p_brgmodrst = (unsigned int *) 0xFFD0501C; ... if (*p_brgmodrst) *p_brgmodrst = 0x0; вот так, например.. Специальной функции в alt_bridge_manager или alt_reset_manager я что-то не усмотрел, а preloader так вообще какие-то свои либины использует. Полагаю я работаю с регистром неправильно. Хотя из документации следует, что достаточно записать 0/1 в нужную позицию данного регистра для снятия сброса/сброса модуля, с которым он асоциируется. В карте регистров самого модуля (h2f в данном случае) каких-то принципиальных настроек не обнаружил. Да и вообще настройку можно провести так: alt_bridge_init(ALT_BRIDGE_H2F, NULL, NULL); но после снятия резета и вызова функции интерфейс все равно лежит. Не могли бы вы привести пример, как правильно сбрасывать и поднимать контроллер bridge'а в bare metal приложении (через hwlib или же напрямую через регистры)? С L3 (NIC-301) GPV / l3regs не очень понял. Если там нули - то это нормальный режим, когда bridge функционирует или в случае, если что-то пошло не так?

UPD. В тех случаях когда после включения обмена между FPGA и HPS нет, модули управления шины сидят в резете, судя по значению регистра brgmodrst в Reset Manager'е (brgmodrst = 0x7). Соответственно, когда всё ок, там 0x0. Видимо дело в этом, но что делать дальше пока не понятно, т.к. банальный сброс этого регистра ничего не даёт, требуется ещё что-то конфигурировать.

В каком документе можно подробнее об этом почитать? Я пробовал использовать функцию alt_bridge_init из библиотеки hwlib/alt_bridge_manager - функция выполняется, но ничего не изменяется, таже проблема. Обнаружил, что у меня в настройках конфигурации FPGA стоял самый низкоскоростной режим - x1 12.5 MHz, хотя у меня флеш EPCQ128. Поменял на x4 100 MHz - на отладке SoCkit обмен заработал после включения питания, а на нашей плате - всё по прежнему. Сделал вывод, что при работе прелоадера происходит инициализация бриджей и в случае большой разницы в скорости обмена для флешек FPGA и HPS возможна такая ситуация, что FPGA сильно "тормозит" и бридж не поднимается (что-то вроде таймаута ожидания вхождения FPGA в USER MODE). Но тогда почему на одной плате работает, а на другой нет? И почему я не могу проинициализировать бридж своим софтом с помощью той же alt_bridge_init?

Всем доброго Столкнулся с довольно неожиданной проблемой. Планировал использовать независимую загрузку HPS и FPGA (каждая грузится из своей QSPI flash). Оба устройства успешно грузятся после подачи питания, но при попытке чтения процессором регистров из FPGA части по шине h2f_axi_master получаю нули вместо ожидаемых чисел. Пробовал вставлять задрежки или читать в цикле - результат тот же. Если же, не перешивая FPGA, сбросить проц (cold reset) и по JTAG залить теже preloader и приложение, что и зашиты во флеш, то чтение данных из FPGA работает корректно. В итоге в качестве решения придётся перейти на режим FPGA первая - HPS второй, загружая preloader из On-Chip memory FPGA (FPGA boot), а из QSPI выгружая уже саму прогу. В таком случае всё работает нормально. Но всё равно остаётся вопрос - почему при независимом буте возникает такая проблема? И что будет в случае HPS первый - FPGA вторая? Есть идеи в чём дело? ЗЫ. Проверил эту особенность на отладке и на нашей плате - результат одинаков.

Матлаб он такой, клёвый :rolleyes: там можно и в одну строчку написать такого, что потом год можно в железе запиливать :rolleyes: Ну а так, если вы хотите связываться с HLS, то у вас скорее всего большая ПЛИС, т.к. генерируемые коды не оптимизированны и пожирают ресурсы. А если так, то это пойдёт только на этапе прототипирования, потому что когда посмотрят, куда вы ПЛИС тратите такую толстую и дорогую, вам докинут полосы или каналов и всё придётся переписывать, чтоб уложиться. Если у вас ПЛИС не очень большая, то тогда точно ручками придётся оптимизировать. А если у вас много распределённой арифметики, то, как вам тут уже советуют, стоит посмотреть в сторону софт процессоров или даже SoC.

Использую sveditor для эклипса, так-то норм, но функционал очень ограничен если сравнивать с тем же cdt (который тоже бесплатный). Под эклипс есть интересные проекты - sigasi и dvt, но они сильно платные.

Если в ПЛИС есть только LUT и триггеры, то конечно всё будет реализовано на них. Есть разница в использовании. Сравните always@(posedge clock) begin if (a && b) q <= 1'b1; end и always@(*) begin if (a && b) q = 1'b1; end Для реализации этих конструкций синтезатор будет применять одни и теже ресурсы, но функционально это разные схемы (первая - триггер, вторая - латч). Также у них будет разная разводка и разные тайминги. Синтезатор не сможет сделать латч аппаратно, как Shivers сказал, но он попробует его реализовать на тех ресурсах, которые у него есть. Но такая реализация может привести к плохим таймингам. А тот код, который я привёл ранее, реализует защёлку явно на логике и триггерах. Т.о. мы явно говорим синтезатору, что делать.

Дело то дело, но тема всё таки про редакторы, а не про организацию проектов. Не нужно просто постулировать правило - "Навороченный редактор означает плохую организацию проекта".