синопсис DC получает отрицательные значения HOLD и RECOVERY - в nc-verilog при аннотации sdf файла они обнуляются, как лечить и откуда это берётся?

Не знаю, так глубоко не копал, но теперь меня тоже интересует этот вопрос

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

1. Verilog-NC c нулевыми числами в SDF не работает (просто игнорирует).
По смыслу проверить на 0 - означает найти такое событие где проверяемые события из
timing violation совпадут. Вероятность этого весьма мала...
2. Я бы посоветовал, наоборот, поставить не нулевые значения и посмотреть.
Это полезно если проект синтезруется не полностью (часть блоков вручную или
экспоритуется как готовые или не все constraints выставлены при синтезе и т.п.)
Это может быть полезно, т. к. топология может дать перекос (0.1-0.5нс легко для современных
быстрых элементов и этого будет достаточно...).
Ещё это существенно, если необходимо как-то заложить запас на разброс
технологий и т. п.

3. Хотя большая часть разработчиков (я этого пока не понимаю) вообще не моделирует и не проверяет схему на timing violation таким образом.
Проверку на это они выполняют с помощью статического временного анализа.
(Synopsys-PrimeTime, Cadence-Pearl и др.). Но в этом случае надо грамотно задать все проверки по путям и constartints, отсечь все ложные пути (проверки). Короче, это своя наука...

обычно рекомендуют фильтровать primetime-ой и после уже подсовывать в nc

а nc не понимает отрицательных сетап/холдов - вот такой замечательный тул

с праймтайм вобще-то тоже беда - я видел несколько фильтрующих скриптов - но обычно это больше проблем вызывает, я предпочитаю gawk-ом самостоятельно чистить нетлист и быстрее и операция контролируема - то есть меньше возможности ошибку внести (смысл то одинаковый - все что меньше 0 заменить на 0)

а вообще самый простой путь - поставить запрет на такой варнинг и запускать nc с тем SDF-ом, который с отрицательными числами

2 soshnev
очень странные советы
и
весьма странная "Большая часть разработчиков", всюду где я видел изготовление АЗИКов - львиная доля трудозатрат идет на поведенческое моделирование (хотя primetime ... и formality ... могут слегка уменьшить)



а вот для сетапа интересно бы обосновать, sorry не успел дописать
в либах бывает setup -0.5 нс, то есть при современной времянке такое ужесточение может привести и к нерабочести

и я не помню в самих timing check-ах $setup, $hold считается величина 0 - игнорировать проверку или сравнение с 0 в описании элемента вставляют (нужно будет проверить!!!), то есть soshnev, возможно, прав, что нужно давать не 0, а небольшое положительное значение, что еще хуже

2 JB_swamp & yes

Из документации:

1. В программах моделирования невозможно "отмотать" время назад в общем случае. Я думаю это корректно в программах моделирования сделать очень сложно...
(сделать "планирование события" назад. События планируются только вперёд).

2. fоrmality - несколько другой тул.

3. Невозможно проверить все timing violation на всех тестах (их ещё написать надо), например для P4.
А если будет использоваться цифро-аналоговая смесь - это ещё сильнее усложнит ситуацию.

Просто есть такой факт (своя школа и методика), которая вычищает timing violation программами типа PrimeTime.
Иначе зачем нужна программа типа PrimeTime , ведь под WinNT 2000г она уже была.

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

вобщем-то теоретически есть возможность -neg_tchk, но в дополнение к этому должно быть кучка дополнительных условий - например SDF3.0 (ни праймтайм ни ДЦ пока не умеют) еще какие-то свойства
я могу нарыть и закачать апликуху с объяснениями
но фактически - проблемно

2) прайм-тайм + формалити это как бы замена моделирования - статическая проверка времянки и функциональности

3) существуют методики и технические средства генерации полного покрытия (coverage), ну и прайм тайм она вроде как для построения sdf-ов по результатам отплэйсеного и отроутеного дизайна,
то есть чистка сдф-а это некая дополнительная функция...

Спасибо за диалог и понимание.

1. В общем, не очень актуально поскольку в любом случае это каждый обходит...
2,3 - всё верно.

Последнее замечание по поводу отрицательных значений (вдруг кто дочитает).
Если до топологии ( т.е до отплэйсеного и отроутеного дизайна) в SDF файле получились
отрицательные задержки (от входа к выходу элемента) (один из вариантов - по причине перегрузки
цепи), возможны "сюрпризы" после топологии (перекос по задержкам для этой цепи и появление ещё большего количества отрицательных задержек).

Можно подправить библиотеку, чтобы в $setuphold были добавлены поля [ delayed_reference ], [ delayed_data ]. Знаю, что так решали аналогичную проблему.

$setuphold_timing_check ::=
$setuphold ( reference_event , data_event , timing_check_limit , timing_check_limit
[ , [ notify_reg ] [ , [ stamptime_condition ] [ , [checktime_condition ]
[ , [ delayed_reference ] [ , [ delayed_data ] ] ] ] ] ] ) ;

P.S. Насчет проверки в Formality. После использования Encounter, Formality не может отследить связь между RTL и конечным netlist'ом. Он не находит соответствия для нескольких тысяч элементов. Может быть есть скрипты или некоторые хитрости в настройках, решающие данную проблему?

толи я не очень понимаю, толи вы часто не о том. Тут кстати видел на логике отрицательные задержки(на триггерах ещё как-то осознаю что это может значить) но IOPATH отрицательный уже непонятно, возможно зависит от типа - на sdf OVI1.0 нашёл.

Если входная цепь элемента перегружена (плохой фронт), а сам элемент нагружен слабо
такое возможно.
Например, подаём на вход (слабонагруженного) инвертора фронт 5нс. Порог переключения будет достигнут раньше 2.5 нс. Инвертор начнёт переключаться и соответственно уровень
половину питания возможно достигнет раньше 2.5нс.
Соответственно расчётная задержка (а они считаются (как правило) по пол питания)
будет отрицательная.

Т.е если считать эту схему , например на Spice - расчёт будет верный
(инвертор действительно переключится раньше).
Если считать средствами использующими SDF - задержка будет нулевая.

Чем хуже входной фронт, тем больше задержка может быть в минусе.

Ещё бывает другая ситуация (но реже) - неправильные цифры в файлах, которые
используются для расчёта SDF ( LIB-файле или TLF, или др.).
В этом случае, надо смотреть там цифры для конкретного типа элемента.