Kopart

Вот как раз хотелось избежать этого неуниверсального exlude, хоть и с контрольной суммой по исходнику. Пришлось городить ifdef для некоторых состояний типа enum. Еще интересный момент - при указании параметра исключается из coverage константные присвоения. Только это это не работает для десятичного числа с SV приведением разрядности (PARAM'(1)).

Проверил и всё также без изменений. Покрытие по бранчам показывает, что эти case не покрыты. Также проверил нет ли влияния условия семплирования - заменив always_comb на always_ff

Проверял. Всё также. covergroup cg (ref type_enum test); option.per_instance = 0; cvp: coverpoint test { illegal_bins ignore0 = {A}; illegal_bins ignore1 = {B}; } endgroup cg cg_inst = new(enum_input); always @(posedge clk) begin cg_inst.sample(); end в общем отчете по Branches все без изменений 178 unique case (enum_input) -1- 179 A: reg = 0; ==> 180 B: reg = 1; ==> 181 C: reg = 2; ==> 182 default: reg = 3; ==> Branches: -1- Status Tests A Not Covered B Not Covered С Covered T1 default Covered T1 хотя во вкладке groups Excluded/Illegal bins NAME COUNT auto_A 0 Illegal auto_B 0 Illegal ignore1 0 Illegal ignore0 0 Illegal

Есть в модуле enum input в зависимости от состояния которого формируются другие внутренние сигналы. В текущем тесте используются не все состояния этого enum. Поэтому в отчете по покрытию есть непокрытые code lines с неиспользуемыми состояниями этого enum. Попробовал через covergroup-->coverpoint-->ignore_bins переопределить несуществующие состояния enum для исключения их из общего отчета по покрытию. В VCS вижу, что эти состояния исключаются для созданной covergroup (отчет group), но в общем отчете по покрытию все также code lines в этом модуле считаются непокрытыми и неисключенными. У кого-то получалось красиво исключать из покрытия неиспользуемые состояния?

У меня в host Linux везде работают линки (с vcs в том числе). Но в vbox надо их разрешить в настройках виртуалки (они там по-умолчанию отключены по соображениям безопасности).

Может уже за два года это исправили и в host Linux. В VMware, линки не работают только, если host - Windows.

Очень просто в их понимании. При подключенном сигналтапе он предлагает сохранить, когда что-то поменялось. Без проверки это влияет на компиляцию или нет. А тут он просто не может выдать это окошко при включенном анализе в сигналтапе, чтобы ответить сохранить. Всё просто - одно связано со вторым, которое зависит от третьего.

Это я и так знал после раннего совета вам про папки. Я предложил еще вариант убрать предупреждение для эстетики, когда не желательно удалять базу данных в этих папках (например для СигналТап).

Это глюк опции Smart Recompile. Или удалять папки или разово отключить опцию для прочистки мозгов квартусу.

Речь о том, что если написать в коде для начала также как в sdc, то констрейн в коде будет работать в принципе. А дальше проверить, что он не работает именно из-за wildcard, а не из-за неполного/неточного формата записи.

А вы пробовали указать в коде иерархический путь как у вас написан в файле sdc? Те написать без wildcard для конкретных регистров/битов.

Причем именно внешняя быстрая память. Я сравнивал сборку проекта на одинаковых процессорах по архитектуре, но различающимся размером кэша. Двухкратное увеличения размера кэша на уменьшения времени сборки ни как не повлияло.

Давно проверял, что размещение на tmpfs или на обычном HDD тоже сильно не влияет на результат. Разница была в пределах 30сек на 30 минут сборки. Те для квартуса SSD по сравнению с HDD практически не влияет на скорость сборки. Но, как известно, SSD хорошо влияет на "скорость" OS в целом.

Вот не понимаю зачем так сильно обрезать поддерживаемые семейства. У нас StratixIII/CycloneIII уже устарели? С учетом того, что они быстрее чем IV семейство (подтверждение видно в макс частоте NiosII)

Я так понял, что вы писали в предположении, что есть те кто писал этот код и добавлял констрейны multicycle. А если код пришел как есть, то в принципе по самому констрейну, если его перепроверить тоже можно добавить такие задержки руками. Скриптом - не пройдет, тк он не проверит какой путь и где удобней вставить задержку. Как минимум вижу два варианта, даже для случая, который вы описали 1. Внутри есть mux (если он описан не через assign, а через always * - то также можно вставить задержку перед нужным присваиванием в пути (подобно как в регистре). * assign при это надо будет переписать через always * 2. По констрейну multicycle - видно что есть инициирующий триггер. И если он имеет только одно подключение через mux к нужному триггеру - то можно задержку присваивания перенести на инициирующий триггер, как задержку выдачи. Это конечно, не сделать с помощью скрипта, но эти два варианта при ручной проверки частично реализуют задачу проверки multicycle уже на уровне RTL.

А почему не попробовали просто в нужном месте в RTL вставить задержку эквивалентную задержке при multicycle. На синтез это не повлияет, а тесты будут адекватней. Единственное: не проверял, как ваш симмулятор отреагирует на задержку больше периода клока. (по идеи он не должен выйти из always на новое событие фронта пока не выполнил текущий до конца ) В присвоении указать задержку, когда на приемном триггере должно появиться новое значение. always @(posedge clock) ... reg <= #n value //n= (multicycle-1)*clock_period - те задержку эквивалентную задержке при multicycle

Вот тема, там многое обсуждалось. И там приведен мой первый опыт реализации по трем точкам и мажорирование для фильтрации помех. RS-232 + FPGA

Кто-то получал в ModelSim итоговое покрытие кода для нескольких запусков testbench для одного и того же модуля? Попробовал получить итоговое суммированное покрытие кода для двух тестбенчей. Два тестбенча для двух режимов работы простого модуля. Каждый проверят свой режим и дает покрытие по отдельности 70-80%. Сделать общий тесбенч нельзя. Как засуммировать результат в ModelSim? Попробовал сохранить покрытие кода в файл статистики (.usdb). После этого закрыть этот тестбенч, открыть и просиммулировать второй. Но при открытии файла покрытия - нет опции связать с текущим и получить итоговое суммарное покрытие блока. Как правильно действовать в ModelSim?

А у вас появилась новая информация после вашего сообщения про них от 2010 года? Есть понимание стоимости NRE в eASIC? И кто его выполняет? В Тошибе декларируется NRE в среднем $300k и они делают все сами из RTL на входе.

Кто интересовался/смотрел эта реализация FFSA от Toshiba подобна технологии HardCopy от Altera? Fit Fast Structured Arrays Те потребление получается раза в 2-3 больше, чем на ASIC? А цена в те же 2-4 раза меньше, чем FPGA и минимальная партия от 50 тыс. шт. как у HardCopy?

Также как и было на предыдущей. Разницы не заметил.

Есть в этой версии улучшение по скорости работы. По сравнению с предыдущей стал на 7-10% быстрее компилировать проект.

Привезли? А то сейчас Lead Time: 9 Weeks

Соглашусь предлагали и я упоминал, что можно это рассматривать как вариант. На тот момент желательно было автономное устройство. После подробного обсуждения таких вариантов получилось, что сроки их реализации и проблемы в аппаратных платформах делают их неприоритетным и сложными в разработке. Про "всякие извращения" я имел ввиду ваши обсуждения платы с флешками и Офтопик при обсуждении, того что у нас было с PATA. Сейчас приходиться исходить из того, чтобы получить адекватные сроки надо использовать уже готовые дев киты. И в этом плане обозначенный выше вариант имеет явные преимущества.