Jump to content

    

nice_vladi

Участник
  • Content Count

    68
  • Joined

  • Last visited

Everything posted by nice_vladi


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

    Спасибо. Внес задержку между преобразованиями - все восстанавливается, проблема закрыта. Решение, действительно, тривиально.
  3. Здравствуйте, Было дело, нашел на просторах сети вот такой мануал по дуалбуту для макса. К сожалению, сам не пробовал, но, возможно, вам поможет. Будет интересно узнать, получилось что-то или нет. MAX10_Dual_Boot_instruction.doc
  4. IDWT/DWT Simulink

    Действительно, немного поспешил, извиняюсь. Забыл про децимацию, после прямого преобразования. Правильно смотреть вот так: dat = rand(1, 64); res_idwt = idwt(dat(1, 1:2:end), dat(1, 2:2:end), 'db6'); [res_dwt0, res_dwt1] = dwt(res_idwt, 'db6'); hold on; plot(dat(1, 1:2:end), 'x-r'); plot(res_dwt0(1, 1:end), 'o-b'); hold off; Тогда получаем: То, о чем я говорил: есть битые куски данных в начале/конце массива, но центральные элементы восставнавливаются правильно. От симулинка подобного графика добиться не получается. На текущий момент убрал симулинковские idwt-dwt блоки и попробовал Two-Channel Synthesis Subband Filter, прописал ИХ фильтров руками, в соответствии со скриптовыми. Тоже ничего хорошего не увидел. Постепенно спускаюсь ниже - скоро действительно самопальные модельки в симулинке буду делать =))
  5. IDWT/DWT Simulink

    Да, я что-то спутал. Попозже разберусь и выложу правильный кусок.
  6. IDWT/DWT Simulink

    Upd: Приложу кусок скрипта матлаба dat = ones(1, 64); res_idwt = idwt(dat(1, 1:2:end), dat(1, 2:2:end), 'db6'); res_dwt = dwt(res_idwt, 'db6'); hold on; plot(dat(1, 1:end), 'x-r'); plot(res_dwt, 'o-b'); hold off; В результате вижу: По краям есть куски явно битые (выход фильтров в режим, наскольк я понимаю). Центр - восстанавливается верно. Почему это не работает в симулинк? Хочется же просто кубиков набросать - и все работает =)) Во всяком случае, я рассчитывал, что мне не придется собирать из кучи кубиков собственный вариант преобразования. Но, судя по всему, придется. Посмотрим, что выйдет из этого.
  7. IDWT/DWT Simulink

    > А для обычной OFDM так в симулинке уже сделано? Да, IFFT-FFT - без проблем. > Слишком оптимистично, данная статья довольно сомнительная. ИМХО Я просмотрел не одну (не один десяток) статей на подобные темы. В целом, везде структурная схема схожа. Опять же, в матлаб скриптах у меня получилось собрать дерево idwt-dwt, которое работает так, как мне надо.
  8. IDWT/DWT Simulink

    Я пытался изменять sample time источника данных, но пока не пришел к улучшению результата. Ощущение, что недопонимаю какую-то мелочь, которая определяющая =)
  9. IDWT/DWT Simulink

    Спасибо. Действительно, при соединении dwt-idwt - восстановление полное, это понятно. Однако такая штука - анализ сигнала (разложение на ВЧ и НЧ и восстановление по ним). Я же пытаюсь использовать вейвлет немного для других целей. Хочу сделать в симулинк вот так: Для этого хочу примерно вот такую схему: Обе картинки взял отсюда: http://shodhganga.inflibnet.ac.in/bitstream/10603/141313/12/12_chapter 4.pdf Считаю, раз люди публикуют статью - в ней более-менее достоверная информация = я что-то делаю не так. В матлабе (скриптом) такую модель собрал, описал, увидел, что работает. Интересно собрать именно в симулинке. И вот тут столкнулся с непониманием того, как это работает.
  10. Который однозначно не позволит творить хаос, который возникнет при отсутствии захватат PLL =))
  11. Рано или поздно сброс все равно пригодится. Можно завести на сброс сигнал захвата PLL. Нет захвата - сброс, есть захват - сняли сброс.
  12. Посмотрите настройки проекта - раздел языков. Похоже, что нужно включить поддержку VHDL2008. К сожалению, вивады под рукой нет, но в quartus & libero в настройках точно есть переключатели, которые определяют, какую версию языка использовать.
  13. Всем привет, Не понимаю логику квесты: Хочу скрыть варнинг, в скрипт запуска добавляю строку "suppress 8885". При первой компиляции (после открытия проекта) на этой строке ошибка - "неизвестный варнинг". Комментирую строку, запускаю, вижу в консольке варнинг, расскоментирую строку, перезапускаю - варнинг пропадает, ошибок нет. Почему квеста ругается на неизвестный варнинг при первом запуске симуляции - не логично, но понятно. Она его еще не увидела. Но вот как скрыть варнинг и избавиться при этом от постоянного дерганья закомментировать-расскоментировать?
  14. Всем здравствуйте, В altera signaltap есть возможность продецимировать считываемые данные сигналом разрешения (спец. настройка storage qualifier? - могу ошибаться в названии). Например, задать в качестве сигнала разрешения однобитовый счетчик и захватывать только каждый второй отчет. Таким образом можно рассматировать долгие сигналы с небольшим буфером (теряя в точности, конечно). Есть ли что-то подобное в synplify/identify? Либо как вообще долгие сигналы можно отлаживать в этом софте - просто огромные буферы ставить?
  15. Я имел в виду настройку Conditional (подробнее по ссылке): https://www.intel.com/content/www/us/en/programmable/quartushelp/14.1/mergedProjects/program/ela/ela_about_storqual.htm
  16. Вот это прям сильно) Зачем на такую простую операцию столько модулей? На мой взгляд - лишняя писанина... все это можно заменить парой строк: 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 МГц.
  17. В симуляторах от 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; Если симуляция - делаем симуляционные частоты.
  18. На профессионала не потяну, НО :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;
  19. Это modelsim достигает предела итераций моделирования. Из-за того, что в core PLL много подмодулей, и они довольно крупные и для симуляции каждого требуется куча операций. Вот он и наедается. Можно покрутить параметр лимита операций в настройка сабжа, но лучше при моделировании не использовать PLL, а описывать клоки несинтезируемыми конструкциями языка (ИМХО). Т.е.: Для симуляции используете "искусственные" клоки; Для синтеза - корку Альтеры; Совсем хорошо будет отбить дефайнами эти области, что бы вручную не комментить каждый раз.
  20. А почему вы так упорно используете Альтеровские примитивые? Чем вас не устраивает конструкция вроде "a & b" для логических операций? Возможно, я просто не понимаю чего-то, но юзать примитивы для логических операций - это как-то... избыточно? А еще про память: это поптыка самостоятельно создать что-то вроде IP Core альтеры, которое разведется в RAM память? Если так - тогда стоит полистать мануалы по стилям кодинга от Альтеры же - там примеры, как написать, что бы ваш код лег именно в память, а не логику.
  21. Цитата(Sprite @ May 13 2018, 07:48) Добрый день всем и спасибо за конструктивную критику! Вернул свой первоначальный вариант, немного доработав его (добавил сигнал data_ready) ... Я бы постарался отвязаться от работы на внешней тактовой частоте и завел бы внутри ПЛИС свою, с хорошим перетактированием, допустим, 100 МГц. Работать внутри ПЛИС на внешней частоте, асинхронной внутренним частотам ПЛИС - головная боль. Тем более, когда частоты невысокие и не составляет труда с помощью перетактирования затащить данные под внутреннюю частоту ПЛИС. Тогда можно было бы очень просто продетектировать фронты тактовой частоты SPI и по ним (при условии опущенного CS) укладывать данные с шины данных в сдвиговый регистр. А окончание одной посылки отсчитывать флагом заполнения 3битного счетчика (он как раз 8 тактов насчитает). Что-то вроде: CODE 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 - маст хев. Без них - никуда. Встроенный симулятор Квартуса - боль.
  22. Цитата(iosifk @ May 4 2018, 09:04) Добавлю... И когда медленная часть заработает, в общем проекте просто "зафорсить" нужные сигналы, чтобы сразу начиналась симуляция быстрой части... Так надо сразу же все делать параметризируемое - разрядности счетчиков и т.д.... Понятно, как НАДО. Но сделано так. И лезть в немаленький и абсолютно чужой проект не хочется от слова совсем - черт его знает, что там умрет, если я разрядности подкручу.
  23. Всем здравствуйте. Столкнулся с задачей верификации проекта. Схема работы примерно следующая: прогрузка по "медленным" интерфейсам (I2C, SPI) настроек, сбор данных по быстрым интерфейсам (нечто вроде SPI на 40 МГц), форматирование этих данных и передача "наверх" так же по "быстрому" интерфейсу. Для первоначальной прогрузки настроек по "медленным" интерфейсам необходимо порядка нескольких секунд, затем начинается "быстрая" работа, которая занимает ~2-8 ms. Мой компьютер не особо производительный, поэтому полноценно (с отрисовкой waveform) моделировать несколько секунд - это очень долго и печально. Так же первоначальная конфигурация не представляет большого интереса для валидации (прогрузил - увидел, что все правильно загрузилось - забыл про этот интерфейс). Все самое интересное для отладки скрывается за 1-2 секундами модельного времени. Вопросы: 1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки) 2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)? Использую Questa + SystemVerilog. Если подкинете ссылки на какие-то буквари по данной области на русском - буду так же благодарен. Спасибо.
  24. Цитата(des00 @ May 4 2018, 00:54) вроде работало Questa®Questa®SIM User’s Manual -> Chapter 10 Advanced Simulation Techniques -> Checkpointing and Restoring Simulations -> The checkpointand restorecommands allow you to save and restore the simulation state within the same invocation of vsimor between vsimsessions. Спасибо, точно буду пользовать. Цитата(iosifk @ May 4 2018, 07:29) Сделать параметр "дебаг-релиз" и к нему соответственно два набора параметров. В режиме "релиз" тактовые по интерфейсам оставить "как должно быть в железе". А в "дебаг" - сделать тактовые по интерфейсам например в 4 клока... При этом время симулирования значительно сократится... Думал об этом. НО. В прошивке есть привязка к тактовым частотам (разрядности счетчиков и т.д.). Т.о., если я задеру частоты, скорее всего, что-то сломается. Причем, возможно, я этого даже не увижу (не пойму). Т.к. DUT написан не мной. Цитата(lembrix @ May 4 2018, 07:37) Я бы попробовал разбить проект таким образом, чтобы можно было верифицировать "медленную" и "быструю" часть независимо друг от друга. Думал об этом. Что-то вроде: 1. Проверить "медленную" часть; 2. Сделать слепок конфигурации и, при отладке "быстрой" части, загружать его за 1 такт в симуляторе; Но это значит - лезть в тестируемую прошивку. Чего очень не хочется.
  25. Цитата(dxp @ May 3 2018, 08:38) Добавлю свои 5 коп. на тему svn vs. git .... Реально впечатлился. Чувствую, в ближайшие дни, начну очередную попытку перехода с svn на git/mercurial