[Nick_K 0]

Начинаю осваивать прототипирование ASIC'ов. А точнее back-end его часть. Компания использует Cadence тулзы для синтеза, имплементации, маппинга и т.д. Самое первое задание стало разобраться с очень большим количеством TCL скриптов в которых описано workflow принятое компанией.

Отсюда возникает вопрос: каким способом лучше всего заниматься дебагом сложных скриптов с многоуровневыми вложениями? Может кто-то может поделится своими принципами/процессами для дебага. Пытался найти в сети решения, но всё сводится в основном к 2м вариантам: вывод информационных сообщений в брекпоинтах скрипта без остановок или использование стороннего ПО со встроенными высокоуровневыми дебаггерами. Мне же хочется сделать надстройку/процесс который позволит вставать в разрыв скрипта, вручную выполнить набор команд и/или продолжить выполнение скрипта пошагово дальше.

Пинок в ресурсы с хорошими примерами будет тоже уместен. Хотя 2-х дневное чтение TclTk не принесло особого результата 

[topor_topor 0]

В данном случае нужно начать с освоения типичного фло - скачать у каденса соответствующий RAK. Чтоби в принципе представлять что делается. 

Два дня на тикл маловато будет... Да и главное команди тулзи нужно знать. Скачайте command guide. 

Что делает ваш конкретний скрипт смотрите лог файли в рабочей директории. Comnand.log особенно. 

Очень силино помогает спросить у автора скриптов или того кто их часто юзает что там происходит и зачем. 

Учтите, что скрип без багов не гарантирует отсутствие sta/drc ошибок, которие надо уметь понять и пофиксить. 

Лично я думаю что такое самостоятельное изучение бек-енд путь лбом в стену, но пожелаю удачи. 

[one_eight_seven 3]

4 minutes ago, topor_topor said:

Два дня на тикл маловато будет...

Более, чем достаточно.

Там что из Tcl -то используется? if-else, for.
Остальное - внутренние команды тула. Зайдите на support.cadence.com и введите в строке поиска tcl scripting for <toolname>

[topor_topor 0]

 

13 minutes ago, one_eight_seven said:

Более, чем достаточно.

Там что из Tcl -то используется? if-else, for.
Остальное - внутренние команды тула. Зайдите на support.cadence.com и введите в строке поиска tcl scripting for <toolname>

regexp посложнее... Но не в тикле главная проблемма....

Тулзу нужно изучить

[Nick_K 0]

1 hour ago, topor_topor said:

Два дня на тикл маловато будет... Да и главное команди тулзи нужно знать. Скачайте command guide.

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

1 hour ago, topor_topor said:

Да и главное команди тулзи нужно знать. Скачайте command guide.

Это очень хороший совет, спасибо. Я даже как-то не задумался над такой возможностью.

1 hour ago, topor_topor said:

В данном случае нужно начать с освоения типичного фло - скачать у каденса соответствующий RAK. Чтоби в принципе представлять что делается.

Вот тут не уверен. Я точно буду работать с flow компании. Не факт что он очень похож на Каденсовский, на изучение которого придётся потратить уйму времени.

1 hour ago, topor_topor said:

Учтите, что скрип без багов не гарантирует отсутствие sta/drc ошибок, которие надо уметь понять и пофиксить.

Тут тоже относительно просто. Опыт разработки FPGA даёт представление. Да и первый тестовый проект мне выдали рабочий чисто для ознакомления с flow.

1 hour ago, topor_topor said:

Лично я думаю что такое самостоятельное изучение бек-енд путь лбом в стену, но пожелаю удачи.

Меня интересовал глобальный вопрос именно по дебагу скриптов внутренними средствами. Нюансы конечно есть у кого спросить.

1 hour ago, topor_topor said:

regexp посложнее... Но не в тикле главная проблемма...

Ничего там сложного. Всё изложено на одной странице

1 hour ago, one_eight_seven said:

Зайдите на support.cadence.com и введите в строке поиска tcl scripting for <toolname>

Спасибо за наводку 

[topor_topor 0]

1 hour ago, Nick_K said:

Меня интересовал глобальный вопрос именно по дебагу скриптов внутренними средствами. Нюансы конечно есть у кого спросить.

Пожалуй стоит уточнить что ви понимаете под дебагом скриптов? 

Конструкции тикла дебагать? 

Или понять проблемму, почему командм тулзи не то делает что надо? 

В любом случае, для дебага есть следующие инструменти в иулзе:

- командная строка для пошагового виполнения

- команда print

- команда report_, get_

- log file

- встроений хелп на каждую команду

- gui для просмотра схеми, есче кое чего... 

Пошагового дебагера с брейкпоинтами нет :( 

 

[one_eight_seven 3]

3 hours ago, Nick_K said:

Вот тут не уверен. Я точно буду работать с flow компании. Не факт что он очень похож на Каденсовский, на изучение которого придётся потратить уйму времени

Нет, не кучу. По сути их RAK - это самоучитель (tutorial), и позволяет пройти маршрут достаточно скоро.

Изменено 3 мая, 2020 пользователем one_eight_seven

[Nick_K 0]

11 hours ago, topor_topor said:

Конструкции тикла дебагать? 

Или понять проблемму, почему командм тулзи не то делает что надо? 

В основном второе,, но иногда и первое, когда новые/непонятные конструкции. И скорее не "не то делает", а "что вообще оно делает" 

11 hours ago, topor_topor said:

Пошагового дебагера с брейкпоинтами нет :( 

А вот это как раз было бы прикольно. Запринтить я и так могу, а пошагово выполнять каждую команду в консоли - это проще убится. Когда скрипты разделены на почти десять отдельных файлов, там потеряться раз плюнуть.

9 hours ago, one_eight_seven said:

Нет, не кучу. По сути их RAK - это самоучитель (tutorial), и позволяет пройти маршрут достаточно скоро.

Может и вправду залезу гляну. Спасибо.

[baumanets 12]

 

Если не NDA, выкладывайте код, сюда или на гитхаб. И сделайте ссылку на профиль в линкедине.

Так вам не только помогут, но и найдут вас потенциальные HR.

 

После этой книги:

Практическое программирование на TCL И TK.

Джонс К., Уэлш Брент Б., Хоббс Д.

я уже через месяц писал свои инструменты на TCL и фиксил баги в чужом коде.

 

[Nick_K 0]

@baumanets Увы NDA. Так бы я сразу спросил по конкретным моментам.

Книга полезная, но очень объёмная. Мне уже нужно разбирать чужие конструкции, а не через месяц. Но видно выхода нет, придётся идти по Уэлшу...

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

[Losik 1]

Во многих мануалах от кэденса количество страниц за тысячу, привыкайте читать объемные тексты)))

[baumanets 12]

20 часов назад, Nick_K сказал:

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

Вы сами себе верно поставили диагноз, но видно пока не осознали смысл сказанных слов.

Если вы не измените свою жизнь, будете крестьянином, который вынужденно будет пахать сохой,

потому что на изобретение плуга времени (тупо) не будет.

А если вдруг начальники увидели вас занятым самообразованием по tcl, skill, etc., они случайно в это же время вам не дали ещё больше работы?

Это мне уже напоминает кое-какую контору в Зеленограде, тоже, кстати, основанную украинцами.

[Nick_K 0]

20 minutes ago, baumanets said:

потому что на изобретение плуга времени (тупо) не будет.

Ирония немного неуместна  Просто для осознания всего нужно время. Либо действительно достойная задача к которой нужно применить иной подход.

[Avex 1]

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

 

Если все же захочется что то написать, то для этого есть все возможности - сообщения тулов разделяются по severity level, есть коды сообщений, есть возможность маскировать сообщения по этим кодам, каждая команда возвращает статус выполненной операции, а сам тикль имеет возможности аварийного выхода из цикла или скрипта, и может парсить текстовые логи/репорты не хуже перла. Если бы я писал сторонний дебаггер, то использовал бы переменные среды. Через них можно и смотреть что происходит в тикль-консоли, и управлять ей со стороны. Но для работы с таким дебагером придется много добавлять в исследуемый скрипт: всякие брек-поинты, обработчики кодов и т.д. Может быть даже больше, чем было в исходном скрипте. Есть компании, которые используют флоу с автоматическим сбором и обработкой ВСЕХ сообщений, выдаваемых тулом.

 

В целом, как писали выше - начинать надо с изучения тулов, а не тикля и дебага. Потому что азы работы отлично постигаются через работу исключительно с GUI, посредством тех же RAK. А потом уже можно и к скриптам переходить. Если есть готовое флоу, и понимание принципов маршрута, можно зайти с другой стороны - изучать только скрипты: построчно прочитать о каждой команде скрипта, о каждом используемом ключе этой команды, понять что они делают, а затем построчно же эти скрипты выполнить, и изучить логи. Но для новичков это вариант малоэффективен.

[MickeyMouse 0]

В 27.04.2020 в 21:44, Nick_K сказал:

Начинаю осваивать прототипирование ASIC'ов. А точнее back-end его часть. Компания использует Cadence тулзы для синтеза, имплементации, маппинга и т.д. Самое первое задание стало разобраться с очень большим количеством TCL скриптов в которых описано workflow принятое компанией.

Отсюда возникает вопрос: каким способом лучше всего заниматься дебагом сложных скриптов с многоуровневыми вложениями? Может кто-то может поделится своими принципами/процессами для дебага. Пытался найти в сети решения, но всё сводится в основном к 2м вариантам: вывод информационных сообщений в брекпоинтах скрипта без остановок или использование стороннего ПО со встроенными высокоуровневыми дебаггерами. Мне же хочется сделать надстройку/процесс который позволит вставать в разрыв скрипта, вручную выполнить набор команд и/или продолжить выполнение скрипта пошагово дальше.

Пинок в ресурсы с хорошими примерами будет тоже уместен. Хотя 2-х дневное чтение TclTk не принесло особого результата 

Здравствуйте, коллега! 

Если речь идет об отладке нативного тикля, то в начале приведенной книги как-раз есть пара тулов на этот счет(не помню названий к сожалению). Это сгодится для отладки разных процедур сложных. Но, как я понимаю, речь об работе с потоков туловых команд, тут как сам каденс часто делает, можно ставить контрольные точки по ретёрну команды(при необходимости делать над командой обертку). Все-таки, как правило, отлаживать тикль не сложная задача в контексте маршрута. Еще способ немного упростить сложность работы с большими скриптами использовать flowtool(если используете cadence, или make для других). Flowtool, конечно требует доработки, но помогает особенно когда часто ходите по всему маршруту от фронтэдна до бэкэнда.