lexus.mephi

Нашел кучу софта 2020 года под этот патчер. Нужен кто-то, кто может качать с https://pan.baidu.com Напишите в личку - скину ссылки и пароли.

Скачал. ОГРОМНОЕ спасибо! =)

Коллеги, у кого есть доступы к https://bbs.eetop.cn/ ? Посмотрите, пожалуйста, есть в этом топике софт для скачивания? : https://bbs.eetop.cn/thread-890275-1-1.html При регистрации требуют какое-то платное приглашение. Оплата через AliPay. Хочу понять, есть смысл дальше заморачиваться.

Если получится, буду очень признателен. Самого vManager'a в доступности сейчас нет, поэтому практическую часть полностью посмотреть не смогу.

Курсы просто бомбические. Спасибо ОГРОМНОЕ! Верификаторов со знанием UVM на рынке труда сейчас немного. С этими курсами можно воспитать новых )) Помимо базовых вещей много инфы из категории advanced. P.S. А такого курса у Вас нет? - Metric Driven Verification Using Cadence vManager =))

Значит на этом пока и остановимся. Вариант с $dumpvars $vcdpluson $vcdplusoff получается напряжным - в системе много кода. Все это фильтровать - что писать, что не писать. Может потом для регрессионных тестов такую работку проведем. Спасибо, коллеги!

Немного не понял про файл, который тормозит. Всякие DDR3 я уже заменил на легковесные модельки. Отключил UVM-ные мониторы, которые мне в этом тесте не нужны. В общем, ряд мер по ускорению симуляции уже предпринял. 10мс я собираю некоторые данные, которые поступают в обработку после 10мс. Т.е. пропусить эти 10 мс и получить интересующую картинку не получится (или получится, но с дикими костылями, которые уведут меня от исходной проверяемой системы).

Есть тест, где самое интересное начинается после 10мс. Как лучше пропустить неинтересующую часть диаграммы, чтобы ускорить симуляцию? Если это делается только с помощью VPD (VCD), то поделитесь примером, пожалуйста. В идеале, хотелось бы просто поставить маркер и сказать VCS'у - рисуй вот отсюда. Пока единственное решение, которое придумал: - запустить симуляцию без вытаскивания сигналов на диаграмму и домоделить до 10мс - после 10мс вытащить интересующие сигналы и продолжить моделирование

Использую стороннее 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 корки какие-то из этих опций включаются по умолчанию. Может мне не хватает именно их. Попробовал скомпилить проект и включить эти настройки - не нашел в репортах, получилось это или нет. Откликнитесь, кто решал подобную задачу. Спасибо!

Тренд как раз - это SystemVerilog в связке с методологиями верификации (UVM, OVM и т.д.). Чтобы быть в чем-то уверенным - надо сначала попробовать. SystemC не используют, как основной инструмент верификации RTL. Это инструмент имитационного моделирования цифровой аппаратуры. Эффективен при развитом рынке IP-ядер, когда вместе с этими самыми IP-ядрами поставляются модели на SystemC. Можно собрать имитационную модель, например, будущей Системы-на-Кристалле. Посмотреть хватает ли памяти, пропускной способности.

Тут по названию темы сразу было ясно, что это будет повод для холивара )) Давненько что-то не было. Я начинал с VHDL, и даже готов согласиться, что для изучения основ схемотехники он будет предпочтительнее Verilog'а. Но если рассматривать не только возможности описания аппаратуры, но и функциональной верификации, то тут Verilog/SystemVerilog гораздо поинтереснее. Перевес в сторону Verilog уже давно бы был, если б не персонажи, которые каждый свой HDL-высер сразу грузят в ПЛИС и отлаживают в железе с помощью логических анализаторов.

Вот еще статистика отдельно для VHDL и Verilog - https://www.fpgarelated.com/showarticle/19.php Статистика 2011 года - видно, что по разным странам статистика различается. И Verilog за счет более стремительного развития нагоняет VHDL.

Имелся ввиду pnysical layer. Есть трансиверная корка, на выходе/входе которой должны быть кодовые символы в соответствии со стандартом PCIе. Остальные уровни (Data, Trancation) пока не интересуют. P.S. Полная корка на Verilog тож подойдет =)

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

Зная, как у альтеры корки зашифрованы, даже не пробовал смотреть. Там прямо читабельный verilog можно получить? ISE нужен?

Стоит задача сделать для оптики протокол на основе PCIe. Пока интересует реализация PHY уровня. Нашел на фтп VHDL-ную корку. Может у кого есть Verilog-ная? Спасибо!

В этом посте (ссылка) расписал процедуру для исключения ветки из отчета Branch Coverage. Аналогичным образом можно скорректировать и покрытие строк.

Для корректировки отчетов 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 и получаем:

Существуют разные метрики покрытия (ссылка). Ваш пример я дополнил, чтобы сделать покрытие комбинационной логики (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 ...

При таком описании 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"

Остается только вариант с option.weight и type_option.weight.

Пробовали поиграться с "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'а из общего отчета по покрытию.

Вопросы, связанные с методологиями верификации, обсуждаются в разделе "Языки проектирования на ПЛИС (FPGA)". VMM уже заброшенная методология: Рекомендую вместо нее использовать UVM - там побольше информации будет. И напишите, какая у Вас среда моделирования?

Про поддержку интерфейсов у Xilinx тут: ug900-vivado-logic-simulation.pdf Страницы 196-197. Если порт B действительно интерфейс: module foo_block #() ( input logic [7:0] port_a, port_b_intf port_b, output logic [7:0] port_c ); //------------------- parameter N = 8; logic [N-1:0][7:0] a_values; logic [N-1:0][7:0] c_rez; port_b_intf port_b_intf_inst[N](); for (i = 0; i<N; i++) begin my_gen foo_block #( ) u_foo_block ( .port_a ( a_values [ i ] ), .port_b ( port_b_intf_inst [ i ] ), .port_c ( c_rez [ i ] ) ); end

Здравствуйте! Появилась в распоряжении NVidia Tesla - возник вопрос, можно ли использовать ее ресурс для EDA-тулов. Последний раз данная тема поднималась на форуме 3 года назад (ссылка). С тех пор что-нибудь изменилось? Удалось кому-нибудь попробовать в действии симулятор RocketSim? Спасибо!