demidrol 0 19 сентября, 2020 Опубликовано 19 сентября, 2020 · Жалоба Как известно, tcl-шелл Synopsys DC имеет свое мнение по поводу обработок ошибок. А именно: произошла или нет ошибка в результате исполнения команды можно понять, проанализировав то, что эта самая команда выдала (0 -- ошибка, 1 -- успех). Обработку такого рода ошибок писать очень накладно (это считай каждую команду надо во что-то оборачивать, типа такого proc try {cmd} { set r [uplevel $cmd] if { $r != 1 } { error "Error in $cmd" } } и вызывать уже команды так: try {connect_net netname portname}) А вот нельзя ли как-то указать интерпретатору, что надо останавливать выполнение при первой возникшей ошибке? Иными словами, чтобы команды синопсиса не выделывались, а использовали стандартные тиклевские исключения (error -- catch). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 19 сентября, 2020 Опубликовано 19 сентября, 2020 · Жалоба foreach id [get_message_ids -type Error] { set_message_info -stop_on -id $id } Это из мануала dc А так, мне тоже было бы интересно сделать обработчик ошибок, но ничего лучше парсера лога я пока не придумал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demidrol 0 19 сентября, 2020 Опубликовано 19 сентября, 2020 · Жалоба о, спасибо! Действительно, видел же, но напрочь забыл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 20 сентября, 2020 Опубликовано 20 сентября, 2020 · Жалоба Мы делаем с помощью команды catch, не уверен в поддержке оной в Синопсисе, на Кейденсе работает нормально. Головной скрипт задаёт конфигурацию и вызывает основной скрипт выполнения команд ... if { [catch { sourse main_script.tcl } error_code error_detail ] } { puts "Error occure" foreach error_detail $ed { puts $ed } exit 1 } else { puts "File sourced OK" exit 0 } А сама команда catch ловит любые Error'ы и прекращает работу основного скрипта. Экситы поставлены, чтобы сразу вывалится из оболочки, но можно убрать и продолжить работать в консоли. З.Ы. Такое поведение не покрывает специфические внутренние ошибки. Например у меня в инструменте Modus напрочь отсутствовало прекращение и скрипты выполнялись до конца с кучей эрроров. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demidrol 0 20 сентября, 2020 Опубликовано 20 сентября, 2020 · Жалоба нет, для synopsys не подойдет. Их команды по умолчанию не бросают исключения в случае ошибок, а просто выдают 0. Вообще, у меня какая-то иррациональная нелюбовь к скриптам, которые при source-е что-то делают. Обычно в таких внешних скриптах я объявляю функции, переменные, неймспейсы и уж их из основного скрипта дергаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Avex 1 21 сентября, 2020 Опубликовано 21 сентября, 2020 · Жалоба Мне бы хотелось не просто получать код 1 или 0 от операции, но еще и парсить вывод на предмет слов Error, Warning и т.д. Это не то же самое, что играть с Severity level, поскольку severity не всегда можно менять, и потому что хочется большей гибкости - ставить триггер на определенные слова или фразы в выводе. Пока ничего лучше не придумал, чем редиректить вывод в файл и его уже парсить. При этом замечено, что редирект у кэденса иногда работает криво - часть вывода некоторых команд может не редиректиться (пример привести не могу, нет доступа к тулам. я - безработный :-) ). В идеале -сделать систему сбора и обработки всех ошибок и сообщений. Эдакий QA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demidrol 0 22 сентября, 2020 Опубликовано 22 сентября, 2020 · Жалоба @Alex, в этом смысле у Xilinx ISE прикольно был сделан вывод утилит в режиме интеграции с IDE: оно плевалось XML-м. Очень удобно именно для машинной обработки, сортировки и QA. Увы, вендоры "серьезоного" софта не хотят или не могут осилить такое. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Nick_K 0 22 сентября, 2020 Опубликовано 22 сентября, 2020 · Жалоба У вендоров "серьёзного" софта абсолютно иные приоритеты, чем сделать жизнь разработчика легче и нарисовать красивый интерфейс. И им не нужно завлекать людей и делать низкий порог вхождения в отрасль, так как там уже работают тёртые калачи, знающие очень многое. Для всех остальных случаев есть саппорт (если конечно у Вас официальная версия софта). Как говорит мой начальник: "Напиши тикет, там в саппорте сидят люди и им нечем заняться, они страдают от скуки, помоги им делать свою работу" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
topor_topor 0 5 ноября, 2020 Опубликовано 5 ноября, 2020 · Жалоба Зачем так заморачиваться? У меня все и всегда тулзи сами по умолчанию останавливаются и печатаеют Warning/Error в логе... Дальше баг фиксится и можно продолжать скрипт. Да есть опция, включив которую тулза попитается игнорировать Error и пойдет дальше, но смисл имеет если рантайм скрипта больше чем полдня. Чтоби словить побольше багов за один раз и пофиксить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться