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

lexus.mephi

Свой
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

Информация о lexus.mephi

  • Звание
    Местный
  1. Использую стороннее IP-ядро PCIe на Cyclone V. Наблюдаются регулярные сбои в работе трансивера на RX (встает rx_errdetect, падает rx_syncstatus). - Работоспособность приемопередатчиков проверена - Качество тактового сигнала проверено Нашел специализированные настройки трансивера для протоколов PCIe, SATA, SAS: - Receiver Signal Detection Unit Enable/Disable (XCVR_RX_SD_ENABLE) - Receiver Cycle Count Before Signal Detect Block Declares Presence Of Signal (XCVR_RX_SD_ON) и т.д. Я так понимаю, что при использовании родной альтеровской PCIe корки какие-то из этих опций включаются по умолчанию. Может мне не хватает именно их. Попробовал скомпилить проект и включить эти настройки - не нашел в репортах, получилось это или нет. Откликнитесь, кто решал подобную задачу. Спасибо!
  2. Цитата(krux @ Jul 28 2017, 20:51) При этом я более чем уверен, что верификация RTL в больших и особо больших проектах ушла в SystemC, и ни к Verilog, ни к VHDL отношения уже не имеет. Просто потому что тренд такой. Тренд как раз - это SystemVerilog в связке с методологиями верификации (UVM, OVM и т.д.). Чтобы быть в чем-то уверенным - надо сначала попробовать. SystemC не используют, как основной инструмент верификации RTL. Это инструмент имитационного моделирования цифровой аппаратуры. Эффективен при развитом рынке IP-ядер, когда вместе с этими самыми IP-ядрами поставляются модели на SystemC. Можно собрать имитационную модель, например, будущей Системы-на-Кристалле. Посмотреть хватает ли памяти, пропускной способности.
  3. Цитата(AVR @ Jul 28 2017, 12:13) Судя по подписи пользователя lexus.mephi, счет 2:2 Тут по названию темы сразу было ясно, что это будет повод для холивара )) Давненько что-то не было. Я начинал с VHDL, и даже готов согласиться, что для изучения основ схемотехники он будет предпочтительнее Verilog'а. Но если рассматривать не только возможности описания аппаратуры, но и функциональной верификации, то тут Verilog/SystemVerilog гораздо поинтереснее. Перевес в сторону Verilog уже давно бы был, если б не персонажи, которые каждый свой HDL-высер сразу грузят в ПЛИС и отлаживают в железе с помощью логических анализаторов.
  4. Цитата(Мур @ Jul 28 2017, 08:11) http://spectrum.ieee.org/static/interactiv...-languages-2017 А у нас на форуме наоборот Вот еще статистика отдельно для VHDL и Verilog - https://www.fpgarelated.com/showarticle/19.php Статистика 2011 года - видно, что по разным странам статистика различается. И Verilog за счет более стремительного развития нагоняет VHDL.
  5. Цитата(RobFPGA @ Feb 15 2017, 18:16) Мда... То есть под PHY Вы имели ввиду полную корку PCIe (TLP, DATA, LINK Layers), а не только уровень трансиверов PHY ? Имелся ввиду pnysical layer. Есть трансиверная корка, на выходе/входе которой должны быть кодовые символы в соответствии со стандартом PCIе. Остальные уровни (Data, Trancation) пока не интересуют. P.S. Полная корка на Verilog тож подойдет =)
  6. Цитата(AVR @ Feb 15 2017, 17:41) А в чем смысл именно PCIe как основы? Все наслышаны про оптические "удлинители" для PCIe, тут стоит подобная задача? Не, задача - передать данные по оптике. Для этого нужен какой-то протокол. Решили пока пощупать PCIe, т.к. у начальства был какой-то опыт работы с этим интерфейсом.
  7. Цитата(RobFPGA @ Feb 15 2017, 17:07) ... Что мешает посмотреть как это сделано в Xilinx - там это как раз на Verilog. Зная, как у альтеры корки зашифрованы, даже не пробовал смотреть. Там прямо читабельный verilog можно получить? ISE нужен?
  8. Стоит задача сделать для оптики протокол на основе PCIe. Пока интересует реализация PHY уровня. Нашел на фтп VHDL-ную корку. Может у кого есть Verilog-ная? Спасибо!
  9. Цитата(_Ivan_33 @ Oct 3 2016, 16:24) Хорошо, а еще такой вопрос: есть же default состояние в FSM И в рамках симулятора загнать DUT в это состояние можно только при помощи force release Иначе 100% line coverage не видать. Как с этим поступить? В этом посте (ссылка) расписал процедуру для исключения ветки из отчета Branch Coverage. Аналогичным образом можно скорректировать и покрытие строк.
  10. Цитата(Kopart @ Oct 3 2016, 15:39) ... Но как видно он не учитывается и подобно должно исключаться для отчета Toggle Coverage для сигнала sel Для корректировки отчетов Toggle и Branch у Synopsys отдельный инструмент. 1) Запускаем в графическом режиме DVE для просмотра отчетов: Код$ dve -cov -covdir simv.vdb 2) Там находим ненужную ветку и отключаем: 3) Дальше выгружаем все исключения в файл *.el: testtt.el: КодCHECKSUM: "4091565883 3988933883" MODULE: dut Branch 0 "2970113050" "(~rst_n)" (3) "(~rst_n) 0,C " 4) Генерим отчет с учетом исключений: Код$ urg -lca -dir ./simv.vdb -elfile testtt.el и получаем:
  11. Существуют разные метрики покрытия (ссылка). Ваш пример я дополнил, чтобы сделать покрытие комбинационной логики (Combinational Logic Coverage) - 100%. Если речь идет о покрытии строк кода (Line Coverage) (1-й скриншот), то тут нет никаких illegal_bins/ignore_bins - есть только строки кода. Этот отчет показывает, какие строки исполнялись в процессе моделирования, а какие - нет. Пусть состояние C и неправильное, но оно описано у Вас в коде, а значит должно быть проверено. Или: Код...     case (sel)       A:        out <= 4'h0;       B:        out <= 4'h1; //      C:        out <= 4'h2;       default:  out <= 4'hF;     endcase ...
  12. Цитата(Kopart @ Oct 1 2016, 14:38) ... Кто-то можете перепроверить на VCS? При таком описании coverpoint конструкция illegal_bins действительно не срабатывает. У меня такая версия - для точек покрытия (coverpoint) создаются списки ожидаемых значений (EXPECTED). Если явно не задать диапазон значений, то в этот список попадут все возможные значения без учета illegal_bins/ignore_bins. Добавил в Ваш пример: Код//dut.sv ... covergroup cg ();   option.per_instance = 0;   cvp: coverpoint sel {       bins sel_bin[] = {[A:C]};         illegal_bins exlude_C = {C};   } endgroup ... При таком описании значение C не попадает в список EXPECTED - получаем покрытие 100%. P.S. В примере не хватает скрипта для запуска симуляции. Вот вариант tcl для VCS: vcs_run.tcl: Код#!/usr/bin/tclsh set VLOG_SIM_OPT        {-sverilog -timescale=1ns/1ns} set VLOG_CMD            "exec vlogan ${VLOG_SIM_OPT}" eval ${VLOG_CMD}         dut.sv eval ${VLOG_CMD}         tb.sv eval                     "exec vcs -lca -cm line+cond+fsm+tgl+path+assert -debug_all tb -R -l vcs.log" #eval                     "dve -cov -covdir simv.vdb" eval                    "urg -lca -dir simv.db"
  13. Остается только вариант с option.weight и type_option.weight.
  14. Пробовали поиграться с "covergroup instance specific options" - weight, per_instance? Вот тут есть интересная фраза на 31 стр.: "Illegal bins can be used to remove unused or illegal values from the overall coverage calculation." Походу Вам достаточно заменить ignore_bins на illegal_bins, чтобы убрать ненужные состояния этого enum'а из общего отчета по покрытию.
  15. Вопросы, связанные с методологиями верификации, обсуждаются в разделе "Языки проектирования на ПЛИС (FPGA)". VMM уже заброшенная методология: Рекомендую вместо нее использовать UVM - там побольше информации будет. И напишите, какая у Вас среда моделирования?