[JB_swamp 0]

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

[VitalyM4 0]

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

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

[SM 0]

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

[soshnev 0]

синопсис 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, отсечь все ложные пути (проверки). Короче, это своя наука...

[yes 5]

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

 

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

 

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

 

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

 

2 soshnev

очень странные советы

и

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

 

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

 

а вот для сетапа интересно бы обосновать, sorry не успел дописать :)

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

 

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

[id_gene 0]

2 JB_swamp & yes

 

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

The use of negative time specifications in $setuphold or $recrem timing checks is enabled by default.

...

Note: With LDV 3.2 or a previous release, you must use the -neg_tchk option on the command line when you invoke the elaborator in order for the simulator to use the negative limit values. If you do not specify this option, negative limits are set to 0 in the description or annotation.

[soshnev 0]

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

 

весьма странная "Большая часть разработчиков", всюду где я видел изготовление АЗИКов - львиная

(хотя primetime ... и formality ... могут слегка уменьшить)

 

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

(сделать "планирование события" назад. События планируются только вперёд).

 

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

 

3. Невозможно проверить все timing violation на всех тестах (их ещё написать надо), например для P4.

А если будет использоваться цифро-аналоговая смесь - это ещё сильнее усложнит ситуацию.

 

Просто есть такой факт (своя школа и методика), которая вычищает timing violation программами типа PrimeTime.

Иначе зачем нужна программа типа PrimeTime , ведь под WinNT 2000г она уже была.

[yes 5]

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

(сделать "планирование события" назад. События планируются только вперёд).

 

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

 

3. Невозможно проверить все timing violation на всех тестах (их ещё написать надо), например для P4.

А если будет использоваться цифро-аналоговая смесь - это ещё сильнее усложнит ситуацию.

 

Просто есть такой факт (своя школа и методика), которая вычищает timing violation программами типа PrimeTime.

Иначе зачем нужна программа типа PrimeTime , ведь под WinNT 2000г она уже была.

 

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

 

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

я могу нарыть и закачать апликуху с объяснениями

но фактически - проблемно

 

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

 

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

то есть чистка сдф-а это некая дополнительная функция...

[soshnev 0]

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

 

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

я могу нарыть и закачать апликуху с объяснениями

но фактически - проблемно

 

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

 

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

то есть чистка сдф-а это некая дополнительная функция...

 

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

 

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

2,3 - всё верно.

 

Последнее замечание по поводу отрицательных значений (вдруг кто дочитает).

Если до топологии ( т.е до отплэйсеного и отроутеного дизайна) в SDF файле получились

отрицательные задержки (от входа к выходу элемента) (один из вариантов - по причине перегрузки

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

[Escorial 0]

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

 

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'ом. Он не находит соответствия для нескольких тысяч элементов. Может быть есть скрипты или некоторые хитрости в настройках, решающие данную проблему?

[JB_swamp 0]

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

[soshnev 0]

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

Если входная цепь элемента перегружена (плохой фронт), а сам элемент нагружен слабо

такое возможно.

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

половину питания возможно достигнет раньше 2.5нс.

Соответственно расчётная задержка (а они считаются (как правило) по пол питания)

будет отрицательная.

 

Т.е если считать эту схему , например на Spice - расчёт будет верный

(инвертор действительно переключится раньше).

Если считать средствами использующими SDF - задержка будет нулевая.

 

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

 

Ещё бывает другая ситуация (но реже) - неправильные цифры в файлах, которые

используются для расчёта SDF ( LIB-файле или TLF, или др.).

В этом случае, надо смотреть там цифры для конкретного типа элемента.