Перейти к содержанию

    

nice_vladi

Участник
  • Публикаций

    55
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о nice_vladi

  • Звание
    Участник

Контакты

  • Сайт
    http://
  • ICQ
    673360216

Информация

  • Город
    Томск

Посетители профиля

717 просмотров профиля
  1. Я имел в виду настройку Conditional (подробнее по ссылке): https://www.intel.com/content/www/us/en/programmable/quartushelp/14.1/mergedProjects/program/ela/ela_about_storqual.htm
  2. Всем здравствуйте, В altera signaltap есть возможность продецимировать считываемые данные сигналом разрешения (спец. настройка storage qualifier? - могу ошибаться в названии). Например, задать в качестве сигнала разрешения однобитовый счетчик и захватывать только каждый второй отчет. Таким образом можно рассматировать долгие сигналы с небольшим буфером (теряя в точности, конечно). Есть ли что-то подобное в synplify/identify? Либо как вообще долгие сигналы можно отлаживать в этом софте - просто огромные буферы ставить?
  3. Вот это прям сильно) Зачем на такую простую операцию столько модулей? На мой взгляд - лишняя писанина... все это можно заменить парой строк: 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 МГц.
  4. В симуляторах от 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; Если симуляция - делаем симуляционные частоты.
  5. На профессионала не потяну, НО :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;
  6. Это modelsim достигает предела итераций моделирования. Из-за того, что в core PLL много подмодулей, и они довольно крупные и для симуляции каждого требуется куча операций. Вот он и наедается. Можно покрутить параметр лимита операций в настройка сабжа, но лучше при моделировании не использовать PLL, а описывать клоки несинтезируемыми конструкциями языка (ИМХО). Т.е.: Для симуляции используете "искусственные" клоки; Для синтеза - корку Альтеры; Совсем хорошо будет отбить дефайнами эти области, что бы вручную не комментить каждый раз.
  7. А почему вы так упорно используете Альтеровские примитивые? Чем вас не устраивает конструкция вроде "a & b" для логических операций? Возможно, я просто не понимаю чего-то, но юзать примитивы для логических операций - это как-то... избыточно? А еще про память: это поптыка самостоятельно создать что-то вроде IP Core альтеры, которое разведется в RAM память? Если так - тогда стоит полистать мануалы по стилям кодинга от Альтеры же - там примеры, как написать, что бы ваш код лег именно в память, а не логику.
  8. Цитата(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 - маст хев. Без них - никуда. Встроенный симулятор Квартуса - боль.
  9. Цитата(iosifk @ May 4 2018, 09:04) Добавлю... И когда медленная часть заработает, в общем проекте просто "зафорсить" нужные сигналы, чтобы сразу начиналась симуляция быстрой части... Так надо сразу же все делать параметризируемое - разрядности счетчиков и т.д.... Понятно, как НАДО. Но сделано так. И лезть в немаленький и абсолютно чужой проект не хочется от слова совсем - черт его знает, что там умрет, если я разрядности подкручу.
  10. Цитата(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 такт в симуляторе; Но это значит - лезть в тестируемую прошивку. Чего очень не хочется.
  11. Цитата(dxp @ May 3 2018, 08:38) Добавлю свои 5 коп. на тему svn vs. git .... Реально впечатлился. Чувствую, в ближайшие дни, начну очередную попытку перехода с svn на git/mercurial
  12. Всем здравствуйте. Столкнулся с задачей верификации проекта. Схема работы примерно следующая: прогрузка по "медленным" интерфейсам (I2C, SPI) настроек, сбор данных по быстрым интерфейсам (нечто вроде SPI на 40 МГц), форматирование этих данных и передача "наверх" так же по "быстрому" интерфейсу. Для первоначальной прогрузки настроек по "медленным" интерфейсам необходимо порядка нескольких секунд, затем начинается "быстрая" работа, которая занимает ~2-8 ms. Мой компьютер не особо производительный, поэтому полноценно (с отрисовкой waveform) моделировать несколько секунд - это очень долго и печально. Так же первоначальная конфигурация не представляет большого интереса для валидации (прогрузил - увидел, что все правильно загрузилось - забыл про этот интерфейс). Все самое интересное для отладки скрывается за 1-2 секундами модельного времени. Вопросы: 1. Возможно ли как-то ускорить процесс моделирования первых нескольких секунд? Если да - то как? (очень не хотелось бы лезть внутрь тестируемой прошивки) 2. Возможно ли не отрисовывать в waveform первые несколько секунд моделирования (прогрузку по "медленным" интерфейсам в моем случае)? Использую Questa + SystemVerilog. Если подкинете ссылки на какие-то буквари по данной области на русском - буду так же благодарен. Спасибо.
  13. Цитата(sf9 @ Mar 27 2018, 09:02) Коллеги, возник вопрос, связанный с использованием в проекте с ПЛИС Artix-7 XC7A200TFFG1156-2 двух независимых DDR3 MT41J128M16JT-125. По ТЗ необходимо предусмотреть две отдельные микросхемы DDR для повышения надежности системы. Идея заключается в том, что при старте системы выполняется проверка DDR методом чтения/записи. Если тест пройден успешно, в MicroBlaze запускается основная программа. Если тест закончился неудачно, нужно переключиться на вторую DDR, проверить ее и работать с ней. Иначе - плата признается неисправной. DDR используется MicroBlaze для кеширования. Вопрос состоит в том, можно ли программно выполнить выбор DDR, с которой нужно работать системе? Достаточно ли для этого одной прошивки или нужно организовать хранение 2х прошивок для первой или второй DDR? Я думаю, это вполне осуществимая задача, тем более, ДДР полностью одинаковые. Необходимо просто скоммутировать сигналы управления/данных в/на нужную DDR. Что-то вроде: 0. Включили систему; 1. Проверили ДДР1; 1.1. Если она в порядке -> (4), иначе -> (2); 2. Переключились на ДДР2; 3. Проверили ДДР2; 3.1. Если она в порядке -> (4), иначе -> говорим, что работать невозможно и начинаем истерично мигать ласпочками) 4. Если требуется - переключились на нужную ДДР и остались в этом положении до конца работы (отключения питания, например). А для проверки можно рассчитывать контрольную сумму записываемых данных, а при чтении сверять ее правильность. Если не хочется считать длиную КС - то можно чтение/запись побить на блоки и считать КС для каждого отдельно.
  14. SlickEdit

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