nice_vladi

Всем привет, В Simulink собрал схему вейвлет-преобразования. Но есть нюанс: она не работает =) Значения на выходе связки idwt-dwt не соответствуют тому, что подается на вход. Базис: добеши 6го порядка. Сама схема: Графики: Входные данные + два оба выхода DWT: Со снижением базиса вейвлет-преобразования выходные данные становятся более похожими на исходный сигнал. Но почему с базисами бОльшей длины (4-6-8) все ломается? По теории же это преобразование обратимо и не должно зависит от базиса? При подачи константы на вход видно, что после выхода фильтров в режим (20 отсчетов) результат преобразования соответствует входным данным (константе = 1). Тогда почему в первом случае, после 20 отсчетов значения на выходе не соответствуют значениям на входе? Знающие, подскажите, пожалуйста, что я делаю не так? Почему значения по выходу не соответствуют значениям по входу?

Который однозначно не позволит творить хаос, который возникнет при отсутствии захватат PLL =))

Рано или поздно сброс все равно пригодится. Можно завести на сброс сигнал захвата PLL. Нет захвата - сброс, есть захват - сняли сброс.

Посмотрите настройки проекта - раздел языков. Похоже, что нужно включить поддержку VHDL2008. К сожалению, вивады под рукой нет, но в quartus & libero в настройках точно есть переключатели, которые определяют, какую версию языка использовать.

Всем привет, Не понимаю логику квесты: Хочу скрыть варнинг, в скрипт запуска добавляю строку "suppress 8885". При первой компиляции (после открытия проекта) на этой строке ошибка - "неизвестный варнинг". Комментирую строку, запускаю, вижу в консольке варнинг, расскоментирую строку, перезапускаю - варнинг пропадает, ошибок нет. Почему квеста ругается на неизвестный варнинг при первом запуске симуляции - не логично, но понятно. Она его еще не увидела. Но вот как скрыть варнинг и избавиться при этом от постоянного дерганья закомментировать-расскоментировать?

Я имел в виду настройку Conditional (подробнее по ссылке): https://www.intel.com/content/www/us/en/programmable/quartushelp/14.1/mergedProjects/program/ela/ela_about_storqual.htm

Всем здравствуйте, В altera signaltap есть возможность продецимировать считываемые данные сигналом разрешения (спец. настройка storage qualifier? - могу ошибаться в названии). Например, задать в качестве сигнала разрешения однобитовый счетчик и захватывать только каждый второй отчет. Таким образом можно рассматировать долгие сигналы с небольшим буфером (теряя в точности, конечно). Есть ли что-то подобное в synplify/identify? Либо как вообще долгие сигналы можно отлаживать в этом софте - просто огромные буферы ставить?

Вот это прям сильно) Зачем на такую простую операцию столько модулей? На мой взгляд - лишняя писанина... все это можно заменить парой строк: reg [4:0] shft_reg; shft_reg <= shft_reg << 1 | start_pulse; // либо shft_reg <= {shft_reg[3:0], start_pulse}; /*мне так больше нравится*/ И, если сильно хочется, можно этот сдвиговый регистр утащить в отдельный модуль. При таком описании в качестве сигналов разрешения (w_start_pulsе...) будут использоваться биты сдвигового регистра (shft_reg[...]). Не понятно, как компилятор развел умножители - возможно, и не хватает. Я бы попробовал утащить в симуляцию и там посмотреть-отладить. А так же для умножения пользовал бы корки от производителя. Их использование хотя бы гарантирует, что компилятор разведет блоки так, как вы зададите в настройках этой корки (пайплайны и все такое). Я бы описал входные клоки (опорные): create_clock -name clk -period 36.1MHz [get_ports {clk}] И потом командой создаются все клоки PLL: derive_pll_clocks Для удобства и красоты им можно присвоить имена: set clk_216MHz pll_ena_inst1|pll1|altpll_component|auto_generated|pll1|clk[0] set clk_adc pll_ena_inst1|pll1|altpll_component|auto_generated|pll1|clk[1] А еще стоит открыть handbook на вашу модель циклона и посмотреть, сколько максимальная частота работы умножителей. Может быть, они не умеют в 216 МГц.

В симуляторах от Mentor (ModelSim/QuestaSim) есть предопределенный define "MODEL_TECH". Все придумано за нас) Т.о. код, предназначенный только для симуляции выглдит примерно так: `ifndef MODEL_TECH ... pll_eth eth_clk__ ( ); ... `else ... initial #20 forever #20 eth_clk__25 = ~eth_clk__25 ; // 0* .... `endif В этом примере: если не симуляция - описываем PLL; Если симуляция - делаем симуляционные частоты.

На профессионала не потяну, НО :biggrin: assign w_I = Ki*w_err + I_prev_reg; // 32 бита = (16 бит * 16 бит) + 32 бита -- возможно переполнение Всегда дико заморочно следить за разрядностями, но иногда из-за этого все ломается. А вместо машины на два состояния, которая щелкает каждый такт (если я правильно понял) можно сделать простой однобитный счетчик, который будет по какому-то событию перекидываться 0-1-0-1... мне кажется и лаконичнее и писанины меньше (хотя, наверное, дело религии). И вместо кейсов на 2-3 состояния красивше писать if-else. Опять же лаконичнее и писанины меньше (но, наверное, это тоже дела религиозные))). Т.е. получаем вместо: case (F_limits_reg) 2'b01: out <= out_min; 2'b10: out <= out_max; default: out <= F_reg; endcase Что-то вроде: if (F_limits_reg == 2'b01) out <= out_min; else if (F_limits_reg == 2'b10) out <= out_max; else out <= F_reg;

Это modelsim достигает предела итераций моделирования. Из-за того, что в core PLL много подмодулей, и они довольно крупные и для симуляции каждого требуется куча операций. Вот он и наедается. Можно покрутить параметр лимита операций в настройка сабжа, но лучше при моделировании не использовать PLL, а описывать клоки несинтезируемыми конструкциями языка (ИМХО). Т.е.: Для симуляции используете "искусственные" клоки; Для синтеза - корку Альтеры; Совсем хорошо будет отбить дефайнами эти области, что бы вручную не комментить каждый раз.

А почему вы так упорно используете Альтеровские примитивые? Чем вас не устраивает конструкция вроде "a & b" для логических операций? Возможно, я просто не понимаю чего-то, но юзать примитивы для логических операций - это как-то... избыточно? А еще про память: это поптыка самостоятельно создать что-то вроде IP Core альтеры, которое разведется в RAM память? Если так - тогда стоит полистать мануалы по стилям кодинга от Альтеры же - там примеры, как написать, что бы ваш код лег именно в память, а не логику.

Я бы постарался отвязаться от работы на внешней тактовой частоте и завел бы внутри ПЛИС свою, с хорошим перетактированием, допустим, 100 МГц. Работать внутри ПЛИС на внешней частоте, асинхронной внутренним частотам ПЛИС - головная боль. Тем более, когда частоты невысокие и не составляет труда с помощью перетактирования затащить данные под внутреннюю частоту ПЛИС. Тогда можно было бы очень просто продетектировать фронты тактовой частоты SPI и по ним (при условии опущенного CS) укладывать данные с шины данных в сдвиговый регистр. А окончание одной посылки отсчитывать флагом заполнения 3битного счетчика (он как раз 8 тактов насчитает). Что-то вроде: if (~CS) cnt <= cnt + 1'b1; else cnt <= '0; if (front & ~CS) shft_reg <= shft_reg << 1 | dat ; if (&cnt) rdy_dat <= shft_reg; И писанины меньше, и нагляднее. Ну и да: Questa/ModelSim - маст хев. Без них - никуда. Встроенный симулятор Квартуса - боль.

Понятно, как НАДО. Но сделано так. И лезть в немаленький и абсолютно чужой проект не хочется от слова совсем - черт его знает, что там умрет, если я разрядности подкручу.

Спасибо, точно буду пользовать. Думал об этом. НО. В прошивке есть привязка к тактовым частотам (разрядности счетчиков и т.д.). Т.о., если я задеру частоты, скорее всего, что-то сломается. Причем, возможно, я этого даже не увижу (не пойму). Т.к. DUT написан не мной. Думал об этом. Что-то вроде: 1. Проверить "медленную" часть; 2. Сделать слепок конфигурации и, при отладке "быстрой" части, загружать его за 1 такт в симуляторе; Но это значит - лезть в тестируемую прошивку. Чего очень не хочется.

:bb-offtopic: Реально впечатлился. Чувствую, в ближайшие дни, начну очередную попытку перехода с svn на git/mercurial

Всем здравствуйте. Столкнулся с задачей верификации проекта. Схема работы примерно следующая: прогрузка по "медленным" интерфейсам (I2C, SPI) настроек, сбор данных по быстрым интерфейсам (нечто вроде SPI на 40 МГц), форматирование этих данных и передача "наверх" так же по "быстрому" интерфейсу. Для первоначальной прогрузки настроек по "медленным" интерфейсам необходимо порядка нескольких секунд, затем начинается "быстрая" работа, которая занимает ~2-8 ms. Мой компьютер не особо производительный, поэтому полноценно (с отрисовкой waveform) моделировать несколько секунд - это очень долго и печально. Так же первоначальная конфигурация не представляет большого интереса для валидации (прогрузил - увидел, что все правильно загрузилось - забыл про этот интерфейс). Все самое интересное для отладки скрывается за 1-2 секундами модельного времени. Вопросы: 1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки) 2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)? Использую Questa + SystemVerilog. Если подкинете ссылки на какие-то буквари по данной области на русском - буду так же благодарен. Спасибо.

Я думаю, это вполне осуществимая задача, тем более, ДДР полностью одинаковые. Необходимо просто скоммутировать сигналы управления/данных в/на нужную DDR. Что-то вроде: 0. Включили систему; 1. Проверили ДДР1; 1.1. Если она в порядке -> (4), иначе -> (2); 2. Переключились на ДДР2; 3. Проверили ДДР2; 3.1. Если она в порядке -> (4), иначе -> говорим, что работать невозможно и начинаем истерично мигать ласпочками) 4. Если требуется - переключились на нужную ДДР и остались в этом положении до конца работы (отключения питания, например). А для проверки можно рассчитывать контрольную сумму записываемых данных, а при чтении сверять ее правильность. Если не хочется считать длиную КС - то можно чтение/запись побить на блоки и считать КС для каждого отдельно.

Всем привет! В очередной раз пытаюсь пересесть на SlickEdit. В этой попытке столкнулся с раздражающей особенностью: Выделяя слово двойным щелчком (для автоматической подстветки всех одинаковых слов в файле) приходится ждать около секунды перед тем, как SlickEdit подсветит это слово по всему файлу. Искренне не верю, что он так долго тупИт (файл небольшого размера). Осознанный поиск в настройках, а так же неосознанное выкручивание настроек, предположительно могущих влиять на задержку подсветки, результата не дали. Прошу помощи :smile3046:

Всем спасибо) Получил достаточно примеров

Очепятался) для SystemVerilog. И я имел в виду обратную задачу: пачку верёвок упаковать в одну. :laughing:

Всем привет! Вопрос знатокам: Есть несколько шин, допустим, по N бит. Их количество пусть задается параметром pNUM. Эти шины нужно объединить в одну, разрядностью, соответственно pNUM*N бит (конкатенировать). Какой конструкцией SystemVerilog это можно описать? С условием "написать и забыть", не правя вручную каждый раз, при изменении значений N и pNUM.

Всем привет! Добрались руки до нормальной переделки. За исходник взял код arhiv6 и малость допилил. Корректно работает на нескольких мониторах (расширенный рабочий стол). И корректно отрабатывает доступные области (липнет к краям панели задач, а не к краю экрана под ней). Пробовал только под виндой. Если руки дойдут - попробую под линуксом - отпишусь (хочется проверить, не будет ли конфликтов с wm). void MainWindow::moveEvent(QMoveEvent *event) { Q_UNUSED(event); const int magnetDistance = 100; int screenNum = QApplication::desktop()->screenNumber(this); int windowTopBorder = pos().y(); int windowBottomBorder = windowTopBorder + size().height(); int windowLeftBorder = pos().x(); int windowRightBorder = windowLeftBorder + size().width(); qDebug() << "win" << windowLeftBorder << windowRightBorder << windowTopBorder << windowBottomBorder; int screenTopBorder = QApplication::desktop()->availableGeometry(screenNum).top(); int screenBottomBorder = QApplication::desktop()->availableGeometry(screenNum).bottom(); int screenLeftBorder = QApplication::desktop()->availableGeometry(screenNum).left(); int screenRightBorder = QApplication::desktop()->availableGeometry(screenNum).right(); qDebug() << "screen" << screenLeftBorder << screenRightBorder << screenTopBorder << screenBottomBorder; if (abs(windowLeftBorder - screenLeftBorder) < magnetDistance) { move(screenLeftBorder, windowTopBorder); } if (abs(windowRightBorder - screenRightBorder) < magnetDistance) { move(screenRightBorder - size().width(), windowTopBorder); } if (abs(windowTopBorder - screenTopBorder) < magnetDistance) { move(windowLeftBorder, screenTopBorder); } if (abs(windowBottomBorder - screenBottomBorder) < magnetDistance) { move(windowLeftBorder, screenBottomBorder - size().height()); } }

Мне кажется, одним из самых простых способов проверить, зашилось ли ВООБЩЕ что-то в ПЛИС будет подключить к проекту SignalTap и вытащить в него несколько сигналов. Если ваша прошивка зальется в ПЛИС удачно - то сигналтап отобразит состояние сигналов (не важно, каких). Если прошивка зальется неудачно - то сигналтап выбросит ошибку о том, что не обнаружены сигналы (т.к. в ПЛИС вообще не будет ничего, связаного с сигналтапом). Т.о. будет однозначно понятно, что действительно перепрошиваете ПЛИС. А после этого можно будет ковырять вопрос заблоченной прошивки :rolleyes:

Попробуйте внимательно проверить схему подключения дорожек к ПЛИС. Вполне возможно, что по пути какой-то элемент отвалился/не тот/не там. Например, для LVDS клока нужен дополнительный резистор на входе, если я не ошибаюсь. А еще стоит проверить качество монтажа ПЛИС на плату. Возможно, какие-то ноги плохо пропаяны и тупЯт. Такое вполне возможно. Для простейшей проверки можно вытащить на лампочки сигналы захвата ПЛЛ, тактовые частоты и попробовать паЛцами подавить (аккуратно) на плисину в разные углы - если сигналы на лампочках/пинах коррелируют с нажатиями - это повод задуматься))