[Escorial 0]

При цифровом моделировании netlist'a (RTL к нему увы отсутствует) симулятор ncverilog уходит в себя, начиная со скоростью мысли накручивать delta-циклы, но время моделирования при этом не продвигается. При этом место, на котором он повис почему-то не показывает. Подозреваю combinational loop'ы, можно ли их как-нибудь отследить? Другой симулятор, специальные lint-инструменты (какие именно)?

[lexx 0]

При цифровом моделировании netlist'a (RTL к нему увы отсутствует) симулятор ncverilog уходит в себя, начиная со скоростью мысли накручивать delta-циклы, но время моделирования при этом не продвигается. При этом место, на котором он повис почему-то не показывает. Подозреваю combinational loop'ы, можно ли их как-нибудь отследить? Другой симулятор, специальные lint-инструменты (какие именно)?

 

Spyglass, да думаю все lint должны это показывать, n-lint например.

[SM 0]

STA их всех как на блюдечке выдает. PrimeTime, TimeQuest, и т.п.

Либо Вы просто забыли про SDF, и получили пути с нулевым временем.

[Escorial 0]

Спасибо, попробую покопать в этом направлении.

SM,

SDF'a нет - netlist с нулевыми задержками, задача подтвердить работу логической модели (схема на транзисторном уровне). Более того, в симуляторе стоит ключ notimingcheck. Но я не вижу как это может влиять на зависание в конкретной точке моделирования (первый фронт синхросигнала) - даже если все пути с нулевым временем распространения, верхний уровень с тестбенчем, формирующим воздействия все равно никуда не деется и время будет тикать, как это нужно тестбенчу.

 

P.S. Кстати, если забыть подключить SDF задержки все же не будут нулевые, т.к. по умолчанию в либах в specify-блоках пишут значения для typical-случая.

[SM 0]

SDF'a нет - netlist с нулевыми задержками, задача подтвердить работу логической модели (схема на транзисторном уровне).

Схемы на транзисторном уровне моделируются отнюдь не ncsim-ом, а всякими там hspice, spectre, nanosim и т.п. У вас наверное все таки уровень ячеек технологической библиотеки.

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

Вопрос не в путях, а в сходимости решения для текущего интервала времени. Наличие путя с нулевой задержкой может вызвать несходимость, если есть официально присутствующий combinatorial loop, или триггер с нулевам сетапом и холдом, и петлей с его выхода на вход с нулевым временем. Что и выльется как раз в такой глюк-зависание. Можно, кстати, попробовать отсимулироваться чем-то другим, например verilog-XL, vcs, возможно у них решалка другая.

P.S. Кстати, если забыть подключить SDF задержки все же не будут нулевые, т.к. по умолчанию в либах в specify-блоках пишут значения для typical-случая.

ну это как когда....

[CaPpuCcino 0]

При этом место, на котором он повис почему-то не показывает. Подозреваю combinational loop'ы, можно ли их как-нибудь отследить?

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

[id_gene 0]

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

Пользуюсь таким же способом в менторе. У НЦ почему-то не срабатывает. Escorial: если вы с ГУИ запускаете, то должна кнопка паузы срабатывать или ctrl-c для остановки. А дальше можно попытаться найти, в какой точке когда крутится симулятор. В консоли ctrl-c должен также сработать.

[yes 5]

у нцсима есть одна неприятная особеннасть (которая отсутствует по недоразумению :) у квесты/vcs и полностью соответствует стандарту) : он реально выполняет блоки паралельно - то есть если какая-то переменная используется в тестбенче в нескольких for-ах (ну или каких-то других операциях внутри "мгновенного" begin-end, то этот begin-end может прерываться), то ее изменеие может В НЕКОТОРЫХ случаях отличаться от ожидаемого (ну или от того, что происходит в квесте)

также очень аккуратно нужно с edge-ами быть в тестбенче - они как-то очень вольно с дельтациклами обращаются и тоже может быть, что клок и событие по клоку происходят одновременно (это я так сразу повторить/объяснить не могу, но бывало)

 

то при моделировании RTL, или аннотированного нетлиста все может быть хорошо, а на нетлисте с 0 задержкой подвиснет

 

может у Вас и не этот случай, но у нас постоянно такие ошибки встречаются... (я даже не знаю, как такие грабли назвать - типа наступаем и наступаем)

 

--------------

 

смотрите петли синтезом или PT - они об этом пишут в логах, но может дело и не в петле

[CaPpuCcino 0]

клок и событие по клоку происходят одновременно

как-то это подозрительно. зря что-ли в модели есть всевозможные active, pre-active, postponded и т.д. регионы

он реально выполняет блоки паралельно

параллельно-то параллельно, но дельтациклы специально и введены, чтобы изменение комбинаторного сигнала, запускала зависимый комбинаторный процесс. здесь его параллельность бъет только по тому коду, где действительно есть неопределённость или петля

смотрите петли синтезом

это хорошая идея. тоже так делаю

[yes 5]

как-то это подозрительно. зря что-ли в модели есть всевозможные active, pre-active, postponded и т.д. регионы

 

а я то как удивился, когда впервый раз увидел :)

 

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

я не нашел примеров (давно копался), ну и это версион/енвиромент депендент, то есть когда надо не найдешь, а когда не надо вылазит

 

UPD:

вот нашел обсуждение

http://www.telesys.ru/wwwboards/fpga/281/m...ges/35403.shtml

http://www.telesys.ru/wwwboards/fpga/286/m...ges/39308.shtml

 

а с событиями труднее воспроизвести...

[CaPpuCcino 0]

проблема в том, что при оптимизации

а, при оптимизации охотно верю. я вот при моделировании уровня РТЛ оптимизацию не вкл, баловство это :)

[Escorial 0]

Ого, сколько Вы тут без меня написали. Спасибо за участие. :)

 

Докладываю:

SM

Netlist самый что ни на есть транзисторный (tranif0 и т.д. в netlist'e), естественно без реальных значений задержек/параметров транзисторов.

 

ALL

Проще всего loop оказалось отследить в IUS 5.7 - там добавилась опция +gateloopwarn (или что-то в этом роде, из дома пишу не могу точное название проверить), с этой опцией симулятор спотыкается через небольшое время и позволяет посмотреть зацикленные сигналы командой а-ля "drivers active" (будет возможность, поправлю пост на точные варианты команд).