Jump to content

    

Kopart

Свой
  • Content Count

    595
  • Joined

  • Last visited

Posts posted by Kopart


  1. но вот EMAC не запускается, запускает если только при включении платы я удерживаю сброс в течении 1-3 сек на nRST FPGA (нажатием кнопки сброс)

    Предположение: у многих PHY есть требование на длительность сигнала ресет. Такая задержка есть во всех примерах с использованием ядра TSE.

    Ваш nRST FPGA напрямую подключен к пину PHY reset?

  2. идея использования нескольких частот выглядит не очень

    нельзя ли отказаться от clk, а считать всё на clk_x2 ?

    А где надо получать сигнал разрешения счёта enable/valid локально из clk_x2?

    Этот вариант с одной стороны выглядит проще, но

    1. приведет к лишней дополнительной логике для enable-сигналов. (При работе на основной частоте можно много где обойтись без них, что не увеличит тайминг пути)

    2. нужно будет на все такие пути прописывать кратный multicycle, тк (скорей всего) основная логика и так упирается в основную частоту.

     

    1. Необязательно. Есть три варианта: А) первый клок входной, второй берется с PLL В) Оба клока берутся с PLL С) Первый клок с PLL, а второй получен делением из первого клока.

    А я бы поставил на вариант В. По сравнению с С, в нем задержки двух выходов pll смогут автоматически подстроится оптимальным образом для двух клоков деревьев.

    А в варианте С нет возможности так гибко двигать задержкой клока после делителя (особенно с учетом требования синхронной передачи данных в обе стороны между клоковыми доменами).

  3. Напишите в этой теме, если кто столкнется с подобным или у кого с DDR3 HiLO платой все работает правильно.

     

    Пока нашел такое решение:

    Заменил плату HiLO на DDR4, перенастроил IP Arria10 EMI и пины не меняя остальную логику проекта.

    В итоге сразу заработал правильно на 1066МГЦ с DDR4.

    Мне не принципиален тип внешней памяти и достаточно объема DDR4 на плате HiLO.

     

  4. Arria 10 GX FPGA Development Kit (DevKit Terasic/Intel)

    Quartus 17.0.2

    Проблемное IP в Qsys - Arria 10 EMI (External memory interfaces) при подключении DDR3 HILO

     

    Наблюдаю по факту и в SignalTap (по клоку emif_usr_clk), что если повторять вычитывание 32-битных данных из DDR3-памяти, то может вычитаться неправильное значение из памяти.

    Те просто несколько раз вычитываем данные по одним и тем же адресам и видим в SignalTap на выходе контроллера emi|amm_readdata_0[511..0], что некоторые биты а 512-битном слове могут менятся при чтении. (При этом в памяти данные не меняются, наличие/отсутствие ECC никак не сказывается).

     

    Это наблюдается и при Memory clock 1066.66МГц и при 533.33 МГц (ref clock 133.33МГц).

    Нарушений по таймингам при сборке всего проекта нет.

    Для настройки конфигурации контроллера EMI используется preset для DevKit

     

     

    Уже перепроверил много вариантов, но так и не смог понять по какой причине Hard-контроллер памяти Arria10 может выдавать частично неправильные данные.

    Кто сталкивался?

  5. Позанудствую немного.

    В ряде стандартов и рекомендаций говориться, что для описания комбинаторики не стоит использовать if else конструкцию,

    либо case, либо через ?. Аргумент такой, что можно получить различный результат моделирования RTL описания и netlist.

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

    Это из-за специфики нетлиста ASIC и Х-состояния.

     

    Здесь описано почему такая рекомендация не позволяет "выстрелить себе в ногу" лишний раз

    http://www.verilogpro.com/systemverilog-ve...mism-pessimism/

    A different way to address if…else X optimism is with the conditional operator:

    condition ? expression_if_true : expression_if_false

     

    Но никто не будет всё переписывать только через "condition ?", поэтому в VCS добавлена отдельная опция xprop=tmerge/xmerge.

    Она позволяет избавится от различий при симуляции описании содержащих if else. Но есть глюки и заметно снижает скорость симуляции.

    Здесь подробнее про нее написано: http://www.verilogpro.com/x-propagation-with-vcs-xprop/

  6. Открыть Implemented design и запустить timing report - он его выполнит на базе новых констрэйнов, насколько я помню.

    В этом случае он спрашивает открыть устаревший дизайн. И, по все видимости, открывает со старым файлом, либо предлагает перекомпилировать.

     

  7. В TimeQuest Квартуса есть возможность обновить sdc и применить новые настройки для анализа таймингов.

    Не очень знаком с Vivado, но не нашел такой возможности в GUI, кроме как при пересинтезе.

    Или какой tcl-командой это делается?

  8. Я установил себе quartus 13.1 web edition, не подскажете как сделать прошивку для пзу что бы проект работал без подключения к компу, проект был сделан в nios, я так понимаю для этого нужен кряк, что бы сделать sof файл не time limited, плата на кристале cyclone v gx, может есть ещё какие то пути решения проблемы.

    Либо не использовать версию nios (и возможно другие IP с лицензией), либо "найти" лицензию. Тут есть темы и кто может помочь с этим. А когда будет не time limited sof - можно будет сконвертировать его в jic в квартусе.

  9. Приведите полное наименование микросхем, участвовавших в тесте.

    В примере указана ES микросхема 10AX115N3F40E2SG

     

    Дабы исключить тайминги ES проверил пример с индастриал микросхемой, установленной на поставляемом DevKit'e (10AX115S2F45I1SG).

    Кардинально ситуация не изменилась - улучшение тайминга сопоставимо с более быстрым speedgrade внутри семейства.

    6.134;   1.761; FF; uTco; 2 ; EC_X70_Y88_N1;; g_ram_test_engine[0].ram_test_engine|mem|altsyncram_component|auto_generated|ram_block1a1|portbd
    ataout[0]

     

    Блок памяти можно сделать двух типов: когда задержка на выборку данных входит во входной путь адреса или когда в выходной путь данных.

    Те триггер может защелкивать либо выходные данные, либо входной адрес.

     

    Такая маленькая задержка в этом в пути в StratixV IMHO говорит только об одном, что на выходе стоит триггер, который и разрывает путь чтения данных.

     

    *Для ASIC можно сгенерировать такие блоки памяти в которых будет разные тайминги для разных портов. Один будет ориентирован на записи (уменьшен setup по входам), а другой на чтение (меньше setup по выходу данных)

  10. Вот сейчас и тыкаюсь. Пытаюсь понять с чего начать. Пытаюсь понять как работает инструмент Qusys . Поскольку, как я понял, это основной инструмент для разработки FPGA <==> HPS

    Почитайте статьи des333 на Хабре про SoC Altera (в частности конфигурирование шин между fpga и HPS).

    По шине fpga2hps можно залезть по Avalon в любой IP блок HPS (UART, EMAC, ...) и управлять им напрямую.

    Единственное, что может понадобится "разблокировать внешний доступ к IP-блоку HPS", тк он может после ресета быть залочен "только для HPS" или отключен.

     

  11. Сейчас же суть глюка в том что в версии QuestaSim с 10.4c при симуляции я вижу на входе d_in модуля i_modB Z!!! состояние на всех битах за исключением бита 0. А на шине d_w при этом все как надо. 8-(). Соответственно симуляция не проходит. При этом ни ошибок компиляции ни ошибок elaboration при запуске нет!.

    А вы при компиляции используете один Multiple File Compilation Unit (-mfcu)?

  12. Вроде разобрался. Чтобы изменения вошли в силу, необходим полный перезапуск Modelsim. Правда я так и не понял почему изменения в файле Modelsim.ini, созданного в папке проекта, никак не влияли... После удаления этого файла, и правки "главного" файла Modelsim.ini, расположенного в папке с установленным Modelsim, всё заработало как надо.

    Во-первых он с маленькой буквы (modelsim.ini), хотя в винде это и не важно.

    Не использовал .mpf, но при запуске vsim - используется modelsim.ini из папки запуска, если он там есть. (а иначе копируется туда основной)

    Думаю, что имеет значение из какой папки запускается, а не где лежит .mpf

  13. Phase jump. Не думаю, что не проверяли.

    Это значит заход и выход в пределах дельта-цикла симуляции? (Например через х для полного case)

    Я предположил вариант, который укажет, что этот default невозможен.

  14. Я тут недавно книгу Advanced UVM купил и сейчас пролистав ее решение нашел.

    Сначала сам попробую, потом с народом поделюсь. Это мой первый uvm тестбенч, хочу статью накатать.

    Заинтриговали.

    Напишите, этой свой вариант. Может я такой не проверял...

  15. Для корректировки отчетов Toggle и Branch у Synopsys отдельный инструмент.

    Так вот с этого всё и началось. :smile3009:

    Думал, что через illegal_bins/ignore_bins можно избежать задания exlude правил. :cranky:

    Что задать во сразу всех блоках где используется enum, а не добавляя "портянку" правил для каждого модуля :crying:

  16. Если речь идет о покрытии строк кода (Line Coverage) (1-й скриншот), то тут нет никаких illegal_bins/ignore_bins - есть только строки кода. Этот отчет показывает, какие строки исполнялись в процессе моделирования, а какие - нет.

    Пусть состояние C и неправильное, но оно описано у Вас в коде, а значит должно быть проверено. Или:

    Не совсем правильно привел screenshot из отчета по Line Coverage.

    Тем самым хотел отобразить, что в код добавлена логика и ничего не поменялось.

     

    Меня в частности интересует отчет по Branch Coverage для которого illegal bin должен применяться.

    post-2972-1475497807_thumb.png

    Но как видно он не учитывается и подобно должно исключаться для отчета Toggle Coverage для сигнала sel

     

  17. При таком описании coverpoint конструкция illegal_bins действительно не срабатывает.

    У меня такая версия - для точек покрытия (coverpoint) создаются списки ожидаемых значений (EXPECTED). Если явно не задать диапазон значений, то в этот список попадут все возможные значения без учета illegal_bins/ignore_bins.

    А у вас это исправило проблему?

     

    Проверил с вашими параметрами запуска. (Version K-2015.09-SP2-1).

    У меня ничего не исправилось :smile3046:

     

    Все также ветка С не исключена

    post-2972-1475488403_thumb.png

     

    Хотя должна быть.

    post-2972-1475488406_thumb.png

  18. И вам я напишу то же самое... Вы просто опишите в 2 блоках схему которая работает точно также... и посмотрим что будет:)...

    Нет. Правильней assign присвоить общее условие и его использовать в двух always.

    Не придется два раза менять одной условие, но при этом нет зависимости в коде двух не связанных выходных сигналов.

     

    Для синтеза неприемлемо только то что выпадает из стандарта, ровно как что это не является никаким трюком. Это просто использование блокирующего и не блокирующего присвоения с пониманием особенности их работы. Не рождайте мифических страхов, которых на самом деле нет...

    Пусть будет мифический страх, но все упрется в вопрос поддерживаемости кода. Чем он проще, тем потом будет самому и другим проще его модифицировать.

    Просто такой трюк может потом стоить дополнительного времени на отладку, а может и никогда не сказаться негативно.

  19. always @(posege clk)
       begin
         if(Condition1)
            SymRdy  <= 1'b1;
         if(Condition1 && Condition2)
            ReceiveAck <= 1'b1;
       end

    а можно написать

     

    always @(posege clk)
       begin
         if(Condition1)
            SymRdy  = 1'b1;
         if(SymRdy && Condition2)
            ReceiveAck <= 1'b1;
       end

    Не убедительно, а для синтезируемого кода такой трюк для большинства будет не приемлем и даже опасен при последующей поддержке и модификации кода.

    В этом случае есть более правильное и надежное решение - стараться использовать для каждого сигнала свой always.

    Объединение не улучшает читаемость кода тут и как раз ситуация когда лучше не объединять в одном always, а вынести в два разных always, тк условия для выходов независимы.

     

    PS Пока писал ответ, тоже самое уже написал другой человек :laughing:

  20. и не будьте так категоричны насчет того что можно использовать только = для комбинаторики, ровно как что можно использовать только <= под клоком. Можно всякое, особенно если знаешь что делаешь:)

    Следование этому правилу как я и написал избавляет от потенциальных проблем.

    Но мне вот стало интересно, а есть ли хорошее описание, где смешивание или нарушение этого правила будет оправдано?

     

    Не говоря про синтез, даже в симуляции во всех вариантах, где я это видел и оно было сделано не так (смешивание) приходилось "обнаруживать" ньюнсы при симуляции в некоторых случаях. Тут как раз было "что знали, что делали", но в конечном итоге всё переписывалось по правильному.

    А если говорить про синтез, то сразу вижу потенциальную проблему, что можно не увидеть в симуляции, то что будет синтезировано в таких неоднозначных случаях со смешиванием блокирующего и неблокирующего присваивания, особенно при использовании конструкций SV.

     

     

  21.     always @* begin
            if (ena) begin
                data <= din;

    Плохо написано. Используйте в комбинационных блоках только блокирующее присваивание.

    Это избавит от многих потенциальных проблем в симуляции.

  22. Ну то есть Вы тоже считаете что это просто перенесенный прием без понимания смысла происходящего.

    У кого еще есть какие мнения?

    Такой прием породит уже явный latch для сохранения состояния сигнала при описании в always_comb. Так что это предположение выглядит странным.

     

    Другое дело, если это огрызок от описания, в котором разделяется комбинационное присвоение в always_comb и присвоение в отдельном always_ff

    Но тогда там в always_comb должно быть именно сохранения сигнала с триггера:

    ...
    else reg_comb = reg_ff;

  23. Решил еще раз проверить на простом примере без UVM и с одним DUT - covergroup_exlude.zip

    Результат всё тот же. :smile3046:

    В отчете по covergroups показывает, что и заданный и автосгенеренный bin должны быть исключены, но общем отчете по branches/toggles это не учитывается.

     

    Причем это и в VCS и Questasim так происходит :maniac: .

     

    Кто-то можете перепроверить на VCS?