Cordroy

Спасибо! Список выглядит многообещающе, попробую.

В этом все дело - отсутствии автоматического метода. Речь идет о тысячах констрейнов, руками оччччень не хочется это делать.

Спасибо за ответ. Это первое же над чем думали. Проблема автоматически, в существующем большом коде, найти "нужное место". В начале поста я показал картинку для примера: один и тот же флоп может принимать данные и по multicycle контуру, и по обычному, без задержек (предположите что внутри облака просто mux). Т.е. чтобы поставить на его вход задержку, нужно знать функциональность логики (состояние mux'a). Автоматом (скриптом) пройтись по коду и добавить задержки очень сложно, я пока не представляю как. А метод, подобный тому что вы описали, обязательно будем использовать на стадии написания кода.

Спасибо за ответ. Да, пост-роут с аннотацией делается, конечно, потом. Это и была методолоия до сих пор. Просто из-за сложностях в бэкенде, мы добавляем много "облегчающих" констрейнов, типа multicycle, false path, unbalanced clocks, и т.д. И это иногда на код написанный много лет назад. Проблема - как убедиться что ничего не испортилось, еще ДО синтеза и аннотации (которые занимают массу времени).

Спасибо за совет. К сожалению, совершенно не разбираюсь в SVA. Видимо, придется почитать. Наша среда верификации построена на SV+UVM+coverage collection.

Видимо, мы друг друга не понимаем... 1. Как и писалось, речь идет о коде до синтеза. 2. Имеется в виду заменить всю функциональность RTL его моделями и их проверять? Но тогда теряется сам смысл теста - я должен протестировать именно ТОТ код который потом будет синтезироваться. Добавлено: возможно вы правы, если б это было единичное место и отдельная конкретная функция, которую можно смоделировать и протестировать только управляющие сигналы. Я ищу метод который позволит автоматом / в скрипте находить сотни / тысячи таких мест, "подправлять" их и передавать результат дальше в симулятор. При этом ни имею понятия о функциональности каждого проблемного места (не смогу сам смоделировать, даже вручную).

Спасибо, не знал о таком. Но тут, по-моему, не будет полезным: проблема именно в том что сигнал данных "слишком" стабильный в симуляции. Иллюстрация: P.S. и еще проект на Верилоге...

Именно так оно и произойдет после синтезирования; GLS + SDF аннотации. Вопрос был про симуляцию multicycle на RTL стадии проекта.

Здравствуйте, Подскажите, пожалуйста, статью / методологию / инструмент по теме. Вкратце, есть большой ASIC проект, много клоков, много констрейнов. Проблема в том, чтобы на стадии RTL тестов выявить неправильные multicycle констрейны и/или несоответствие функционирования этим констрейнам. То есть, заставить симулятор вставить соответствующую задержку там где есть m.c. (и только там). Написал туманно, попробую на примере пояснить. Допустим, есть схема: Во время симуляции вся комбинаторная логика работает за 0 сек. И если сигнал enable придет раньше чем нужно (из-за какой-либо ошибки), результат в регистре Flop_B будет все равно валидным. Значит тест ошибку не выявит. Вопрос, как, например в ModelSim, автоматически добавить в такой контур, Flop_A-->Flop_B, задержку эмулирующую multicycle. Или каким-то другим способм такое тестируется?.. Буду благодарен за любой совет :) (на всякий случай отмечу, что знаю о том что это не заменяет GLS и последующие проверки; задача - выявить баги в проекте ДО синтезирования)

Всем здравствуйте, Хотел спросить совета насчет редактора больших файлов (200MB..3GB). Речь идет о просмотре/редактировании нетлистов (Verilog) и SDF аннотаций. Т.е. идеально было бы с подсветкой кода (кастомного тоже). Файлы открываются с сетевого расположения и желательно иметь несколько на виду. Уф. Вообще для кода использую Notepad++, но он ужасно работает с большими файлами. А также, сильно тормозит когда файлы открыты из сети. Пока что брал EditPad Lite для больших файлов. Вроде неплохой, но подстветки кода нет, редактирования колонками нет, часто вылетает и т.п. Посоветуете что-нибудь в альтернативу?.. Заранее спасибо!

Приветствую, Вопрос уже в шапке, собственно. Подозреваю, что можно в лоб сделать полный список объектов в иерархии (все регистры, порты и т.д.), и каждому применить tcheck_set ... ... OFF OFF. Но проект огромен, симуляции еле ползают. Хочется более элегантного и эфективного способа (- не проверять время в одной из трех верхних иерархий). Заранее спасибо ответившим!

Не за что ) Насчет будет ли показывать: если монитор/TV с пометкой FullHD, то будет. Все должно быть точно по стандарту, включая тактовую частоту. (FullHD = родная резолюция LCD матрицы не ниже 1920х1080) Но картинку 1280х1024 нужно будет обрамить черными полосками, например.

Если вы не хотите заниматься интерполяцией кадров во времени, нужно брать такую же кадровую частоту, либо кратную (50 Гц) - и повторять текущий кадр дважды (но это точно потребует буфера). У вас выход именно DVI или HDMI?.. Смысл вопроса - подойдут ли вам видео стандарты HDTV, например, 1920х1080p, 25fps / 50fps? Какой размер исходной картинки? Допускает ли проект ее обрезание / обрамление? Возможно ли все-таки добавление буфера в проект плис? Я прикрепил к ответу спецификации VESA & CEA - поищите какие стандарты вам подходят (1280х1024х25к/с точно нет для цифрового монитора, но решите как вы преобразуете картинку чтобы подогнать к существующему). Если проект легальный / коммерческий - спеки надо будет купить ;) VESA_DMT_v1r11.pdf CEA_861_E.pdf

Если CameraLink источник соответствует по таймингу VESA или EIA/CEA-861 (смотря что вы выдаете на DVI), то - да, можно обойтись без хранения кадра. Но буфер для 2 строчек скорее всего понадобится. Важно полностью соответствовать стандарту, включая все задержки между линиями, кадрами и т.п. И тактовый генератор - тоже максимально точный (есть специальные модели, именно для видео-аппликаций). Приемник DVI (например, монитор) вылетает с ошибкой при малейшем отклонении. Хотя есть и такие которые мелкие неточности допускают и сами исправляют, но это редкий бонус от производителя. В общем случае, вы создаете развертку (счетчики пикселей и линий) которая повторяет выбранный стандарт, генерируя Vsync, Hsync, DataValid. Когда, по стандарту, идет валидный пиксель - вытягиваете оный из буфера.

Как вариант (до установки Вин-64) попробовал бы Quartus 9.1 sp2 - помнится, он был заметно стабильнее 9.0 .