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

TRILLER

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Местный
    Местный
  • День рождения 26.07.1987

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

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

2 803 просмотра профиля
  1. Не-не, точно то смотрю. В логике проекта вылезла ошибка, потом проверял тестом - приложил же скрин чипскопа.. Хм, 14 -> 18 - ошибка есть, 18 -> 22 - исчезла? Надо действительно скачать последнюю версию тогда уж.
  2. Ну "квалификатор приведения типов" очевидно /= понятию "системная функция". Да и в ряд ли бы вводили сущность с теми же функциями, но немного другим названием и синтаксисом.. 🤔 Ладно, придётся "покурить." Я её не использую для работы. Так, только поэкспериментировать.. Такие вещи должны работать и там. А уж если с 14-го года до 18 не исправились, то и дальше скорей всего ситуация не изменится.
  3. Проверил - действительно работает! Аж полегчало, благодарю! Осталось только нормально разобраться, в чём между ними разница, и можно жить дальше)) Может можете сходу объяснить разницу?
  4. Чтобы не плодить темы.. Столкнулся с совсему уж, на мой взгляд, непристойным поведением на этот раз синтезатора Vivado18.3. Он игнорирует signed'() bit [2:0] l_shift = 0; bit [1:0] counter = 0; bit [3:0] result[3]; bit signed [3:0] counter_sign; always_ff @(posedge clk_100) begin if (rst) begin l_shift <= 7; counter <= 2; end end always_comb begin result[0] = signed'(counter) <<< l_shift[0]; result[1] = (signed'(counter)) <<< l_shift[1]; result[2] = counter_sign <<< l_shift[2]; end assign counter_sign = signed'(counter); По стандарту разницы между этими записями не должно быть никакой. Моделсим моделирует верно, но ошибка вылазит на железе! Смотрю чипскопом. Очевидно, что знаковое расширение происходит только для counter_sign: Поправьте, если ошибаюсь. Это уже ни в какие ворота не лезет! Уж синтез-то должен работать.. Да, 18.3 версия старая, но ведь и не одна из первых - получается, эта жестокая ошибка присутствует там много лет. И ведь большинство разработчиков пользуется как раз-таки встроенным синтезатором! 🥴
  5. Вам правильно подсказал des00. Не допускается переменное значение ширины, а в записи REG[8*i +: 8] ширина постоянна. Да, в стандарте об этом написано - читайте внимательнее.
  6. Следующий кусок кода вызывает непонятное мне поведение симулятора Vivado, которое отличается от поведение Modelsim: module top ( input bit clk, input bit i_uno[0:0], input bit i_due[1:0] ); bit a[1:0], b[1:0]; always_ff @(posedge clk) begin for (int i=0; i<2; i++) begin a[i] <= i_due[0]; b[i] <= i_uno[0]; end end Cимулятор Vivado(17.4, 18.3) для неупакованного массива присваивает в такой записи не нулевой элемент входного порта, а весь массив - как будто передаёт по адресу! Т.е. в a[1] будет записано i_due[1], а b[1] и вовсе остаётся равным нулю! Я читал стандарт, но не нашёл подтверждение некорректности своей записи. Ведь согласно определению неупакованный массив отличается только тем, что весь массив нельзя использовать для арифметических операций. Тем более, моделсим данную запись моделирует корректно. Может кто-нибудь сталкивался с подобным и может пояснить, кто в данном случае не прав? Одно дело, если sim Vivado ведёт себя не по стандарту и совсем другое, если и синтезатор позволяет себе вольности! Поведение симуляторов: файл и тестбенч: top.sv top_tb.sv
  7. В этом случае я бы Вам рекомендовал сгруппировать BRAM в компактные Pblocks руководствуясь простейшей логикой и здравым смыслом - ведь наверняка есть базовое понимание устройства ядра - и применил EarlyBlockPlacement стратегию. Плэйсер без хотя бы базовых инструкций часто бессмысленно дробит дизайн.
  8. Надеюсь, что Вы по большей части работали не с xilinx. На моей памяти никогда не было "внутреннего" интерконнекта между триггерами у них. Альтера же имеет внутренние линии в некоторых семействах?
  9. Это с чего вдруг? На картинке же ясно нарисовано, что совпадают фазы в точках 2, 3 и 5. Т.е. в приведенной схеме PLL компенсирует лишь задержку от CLKIN1 до выхода BUFG. Путь данных: i_port -> IDDR Путь клока: (i_clk_port -> CLKIN1(через IBUFG)) + (BUFG -> IDDR) Но длины всех этих путей известны, поэтому остаётся только правильно задать ограничения на входных пинах. Кстати, можно компенсировать ещё и кусок от входного буфера, если добавить его в цепь обратной связи.
  10. Здравствуйте! Ситуация такая: есть некая модель(не hdl), результатом работы которой является иерархия папок+файлов. Папки представляют собой модули, а файлы - значения переменных на каждом такте моделирования. Столкнулся с тем, что иногда всё же необходимо по этим данным сформировать "вэйформы" для визуальной отладки. Может ли кто-нибудь посоветовать удобный инструмент для визуализации вэйформ? Я себе представляют процесс так(на примере xsim): по имеющейся информации формирую .wdb файл, который потом радостно загружаю для просмотра. Но встаёт вопрос реверса формата .wdb(или, возможно, он открыт?). Да и вообще, подозреваю, что для подобных целей могут быть более подходящие инструменты, нежели поделия xilinx. Буду признателен за любую информацию!
  11. Вполне уверенно водится проект на 2 такта и 150МГц, если умножения делать не на dsp, а на логике. Только ресурсов жрёт прилично. src.rar Обязательно запретить использование дсп атрибутом (* use_dsp = "no" *), ну и триггер поставить после попарных сумм 8 элементов. Если Вас устроят 3 такта, то и dsp можно использовать без проблем на эту частоту. То, что Вы хотели бы получить - это очень плохо: Основная проблема использования dsp - это большие времянки на входе и выходе. Сюда ещё добавляется строгая локализация в кристалле. До них банально долго тянуть данные! Поэтому, то, что уже попало в ДСП должно как можно дольше там и оставаться, а после вывода - не заходить снова. Т.е. желательно максималное использование внутренних возможностей и линий ускоренного переноса между блоками. Из моего опыта, оптимальный вариант описания dsp - это отдельный, иерархически изолированный(* keep_hierarchy = "yes" *) модуль, в котором полностью описываются операции 1 или нескольких dsp и их взаимодействие по выделенным линиям. Обязательно, как уже говорилось выше, использование атрибута use_dsp. Ещё вполне рабочий вариант, как уже предлагали, это переход на удвоенную частоту. Но там могут возникнуть проблемы с холдом(хоть и в ряд ли в Вашем случае).. Умножая без знаковые операнды 16 и 8 бит - в результате получаем 24 значащих бита. В случае знаковых операндов - результат умещается в 23.
  12. Несколько вопросов: 1. Входные триггеры, от которых такты считать, можно расположить в ДСП? А выходные? 2. Сколько ДСП можно использовать и какую частоту(150?) нужно получить? 3. Операнды знаковые или без знаковые?
  13. Довольно беспредметный разговор получается. Это как рассуждать, на какой передаче тот или иной вело-любитель ездит - 3-й или 4-ой.. Любая стратегия, это всего лишь последовательность конкретных настроек оптимизации(пример для 17.4): Советую разобраться, какие конкретно оптимизации позволяют Вам достигать результата, ибо в новой версии вивады "стратегия" может просто исчезнуть! Лично для меня наиболее полезной настройкой является "раннее расположение BRAM и DSP"(в таблице выше их нет - старая версия). Ну и Pblocks - само собой.. Сбой в дизайне - это всё же вероятностный процесс. А ввиду этого, между слаком -1пс и + 1пс разницы никакой. Лично систематически наблюдал, когда 17.4 на большом и быстром проекте постоянно не сводила 1-2 пути на единицы пик. Эти пути всегда были разные и объективных причин его не свести у роутера не было. Для себя сделал вывод, что как-раз из-за многопоточности завершение P&R происходило немного раньше, чем было нужно. И разработчики вивады не посчитали это значимой проблемой.. Поэтому, озвученный fguy подход, на мой взгляд, имеет право на жизнь. Насчёт многопоточности.. Как сейчас - не знаю(нет жирных проектов), но лет несколько назад она ничего, кроме проблем, не давала. Выигрыш по скорости, как уже говорили, был незначительный, но при это разводился проект не так, как при 1 потоке. Думаю, допустимо сказать - хуже.
×
×
  • Создать...