Если в документации на ПЛИС или микросхему указано, что она поддерживает стандарт IEEE1149.xx, тогда этот JTAG-адаптер подойдет для ее тестирования.
JTAG-адаптер для прошивки ни чем не отличается от JTAG-адаптера для тестирования, так как доступ к TAP-порту стандартизирован. Отличие идет только на уровне ПО.
Дым — это да. А вот вовремя обнаружить непропай адресной линии на DDR JTAG-тестирование поможет, или, например, обнаружить неверную NAND, PHY и другие микросхемы с ID, когда заложена одна, а запаяна другая, то тест вычитает ID и позволит узнать, что же запаяно на самом деле.
Для теста светодиодов пишется скрипт на языке python, который зажигает диод и посредством графического интерфейса выводит сообщение, в котором спрашивает пользователя, горит ли светодиод.
Для теста кнопок, как было указано в статье, пишется скрипт на языке python, который просит пользователя нажать на кнопку, затем в течении определенного времени скрипт опрашивает состояние кнопки и выдает результат.
Тоже самое и для диода. Скрипт зажигает светодиод и посредством графического интерфейса выводит Message Box, в котором спрашивает, горит ли светодиод.
В ПО Provision интегрирован скриптовый язык python со всеми вытекающими последствиями. Также для JTAG-тестирование можно применять ПО других фирм, в них будут интегрированы другие языки. Например, в XJTAG интегрирован C подобный язык.
JTAG цепляется к совместимому порту JTAG IEEE1149.x контроллера или микросхемы, который содержит 4 основных сигнала: TDI, TDO, TMS, TCK и один дополнительный TRST. С помощью этих сигналов ПО общается с TAP-контроллером микросхемы.
1. Необходим BSDL-файл для JTAG-совместимого устройства.
2. Нет лист-схемы.
3. Все это закидывается в ПО для генерации тестов, затем генерируются автоматические тесты, при необходимости корректируем цепи, которые нельзя проверять или на которых необходим определенный уровень.
4. Если необходимо, пишем дополнительные тесты на Python.
5. Подключаем адаптер к JTAG-порту.
6. Включаем девайс, запускаем тесты.
7. В результате тест выдаст таблицу, по которой будет видно, как цепь отреагировала на определенное воздействие.
8. По результатам делается вывод о КЗ, обрыве.
Пример
В таблицах воздействии значения расшифровываются так: Z – драйвер в Z состоянии; L, H – состояние выхода; 0,1 – считанные значение со входа; 0, 1 – ошибочные значения (0 означает — считан 0, а ожидалась 1).
Тут видно, что цепь POR_3 имеет КЗ на лог.1, а цепь P0_RX_CTRL видит лог 1., хотя должна была видеть лог.0
Тема данной статьи — осветить применение JTAG на практическом уровне. Сами принципы работы JTAG-тестирования — отдельная тема и статья. В нашем случае тестирование проводилось с использованием адаптера JTAG to USB и ПО от JTAG Technologies. Также использовались собственные алгоритмы написанные на Python, который интегрирован в данное ПО.
Я так понимаю, «капитанский» значит очевидный? В принципе любая тема, в которой разобрался – «капитанская» :). Вот только мне присылают на проверку много проектов, и на эти проекты «больно смотреть». И разработчики этих проектов совсем не начинающие, а очень даже опытные. Собственно стимулом для написания этой статьи стали 2 проекта, которые попали ко мне одновременно. Если вкратце: в одном из них был совершенно не оптимизированный BOM, во втором – какая-то невообразимо сложная структура ПП. Оба эти проекта мне принесли с вопросом: «Почему так дорого? И почему мы не можем это произвести?». Ну очевидно же…
Руководитель проекта – очень важная и ответственная работа, и область ответственности там намного шире, чем просто следить за разработчиками. Действительно, очень часто руководитель проекта, по сути, является разработчиком, а разработчики, как Вы удачно выразились, только интерфейсы к CAD’ам. И это, на мой взгляд, не совсем правильно. Намного лучше организовать процесс разработки так, чтоб каждый ее участник отвечал за свою часть работ.
Вопрос мотивации сотрудников – один из самых сложных и его надо решать. Я не видел, чтобы его «пристегивали» к принципам DFM. Разве что косвенно, при расчете себестоимости. Но идея интересная. Ведь качественно выполнить работу может только тот специалист, который хочет ее выполнить.
Про конкретику. Мне тоже очень хотелось бы получить универсальный набор правил. Выполнил все по пунктам – получил хорошее изделие. Но такого набора нет. И не может быть в принципе. Очень много переменных: разные задачи, разные инструменты, разные пути реализации, разное количество специалистов и т. д. Вопросов слишком много. Поэтому придумали принципы DFM. Принципы. Не правила!
Уважаемый Amarao, предположу, что Вы ошиблись веткой или далеки от темы разработки и последующего производства, раз не увидели смысла. Возможно, Вы эксперт в отрасли, в таком случае, буду рад, если поделитесь своей практикой.
Я не очень понимаю, что такое «классический» тип производства. А вот о граблях – это пожалуйста.
1. Самая первая моя разработка. Я не сделал отступ меди от контура платы. Даже не думал, что это надо делать. На производстве контур фрезеровался. При проходе фрезы по контуру образовалась «медная шуба». И даже в нескольких местах образовались КЗ. Вот так незнание технологий производства привело к не работоспособной плате. Кстати, такие глупые ошибки встречаются постоянно. И, как это ни странно, не только у начинающих разработчиков.
2. Более сложный пример. Разрабатывали сложное устройство. В частности корпус (речь пойдет о нем). По дизайну выходные разъемы устройства располагались по трем сторонам. К моменту разработки уже был накоплен достаточно большой опыт и была сильная команда разработчиков. Когда печатная плата и корпус были спроектированы, мы стали проводить моделирование на собираемость (компьютерное). По результатам редактировали модели деталей корпуса, пока на модели все стало «хорошо собираться». Получив хорошие результаты моделирования, мы сразу отдали устройство на производство. Выпустили пресс-форму (корпус должен был отливаться). Получили готовые детали. И при «живой сборке» не смогли ничего сделать. Там мешало какое-то маленькое ребро жесткости. Этого не заметили на моделировании. Пришлось дорабатывать пресс-форму, избавляться от брака – а ведь это очень дорого. Вот если бы до этапа производства мы отдали наши модели на выращивание и проверили все «вживую», то избежали бы потерь как по времени, так и финансовых.
Под выражением «поверх QT» имелось ввиду, что пользовательский интерфейс и другие пользовательские приложения разрабатывались с использованием библиотек QT. ОС же была на базе ядра Linux. Если Вы подразумевали в данном вопросе что-то иное, тогда, пожалуйста, поясните вопрос. Спасибо.
Большое спасибо за комментарий.
Дело в том, что разработчики embedded устройств очень консервативны. Наверняка, это обусловленно экономическими причинами. Китайские производители, ИМХО, работаю по такому принципу: разработал устройство, портировал ядро — работает — продал. Начал разрабатывать новый девайс.
KbRadar, действительно, вакансии в этой сфере быстро закрыть довольно сложно. Несколько лет назад руководитель Promwad, Roman_Pakholkov, посвятил этому вопросу отдельную статью с рецептами для решения проблемы дефицита кадров и слабой инженерной культуры. Его советы до сих пор актуальны:
Во-первых, малые и средние компании могут создавать свои мини-лаборатории и принимать в них на практику студентов. Так учащиеся еще до окончания ВУЗа смогут обратиться к опыту компаний, осознать их потребности и увидеть реально работающие бизнес-процессы. А сильнейшие и перспективные студенты будут приглашены на работу.
Во-вторых, молодые специалисты должны получать реальный опыт на государственных предприятиях (ВПК и т.п.). Затем, после двух-трех лет работы их нужно возвращать на малые и средние предприятия, где они проходили стажировку в студенческие годы. Главное не упустить тот момент, когда специалист уже вырос в полноценного инженера, но пока не потерял мотивацию к дальнейшему профессиональному росту.
В-третьих, нужно уделять больше внимания активному поиску специалистов, работать с иностранными биржами труда. Прилагать усилия к возврату российских инженеров, работающих за границей, предлагая им лучшие условия и высокую оплату труда.
Хорошо себя зарекомендовала стажировка специалистов за границей. Например, в Южной Корее. В этой стране хорошо развита культура разработки (выше, чем в Китае и Индии). Как показывает практика, в силу различных причин наши инженеры не приживаются в этой стране и по окончании практики ищут новые возможности в Европе, Канаде или на Родине. Важно именно в этот момент сделать хорошее предложение. Это немаловажный факт в условиях риска «утечки мозгов».
У нас любят говорить о преимуществах высшего образования в России. Наши выпускники описываются как «специалисты широкого профиля», обладающие большими преимуществами по сравнению с западными «ограниченными» узкоспециализированными инженерами. На самом деле эта широкопрофильность играет злую шутку с молодыми специалистами.
Предприятиям не нужны «мастера на все руки», им не хватает сотрудников с конкретной узкой специализацией. В итоге каждого выпускника приходится «затачивать» под определенные задачи прямо на предприятиях, причем это обучение ведется чуть ли с нуля, т.к. образовательные программы ВУЗов весьма далеки от реальных потребностей российских электронщиков.
Вот и получается, что свежеиспеченный инженер проходит еще одну школу уже во время работы, причем тратит на это не менее пяти лет.
Спасибо mezastel за хороший вопрос. Мы свое видение рынка изложили в статье, плюс нам хотелось бы больше объективности в комментариях, ведь мы сами разрабатываем электронику, поэтому мы решили не встревать и с интересом ждали ответы хабровчан. Однако один из ответов по поводу того, что «сейчас никакой электроники почти не производится в России» не оставил нас равнодушными, так что мы всё-таки дадим своей ответ.
Действительно, качество и сложность разработок очень разное, нам сложно делать обобщения. Но электронику в России разрабатывают и производят, и эти проекты не ограничиваются ВПК, пожарной автоматикой, банковским оборудованием и т.п. Отдельные компании в СНГ и в России в частности способны проектировать и ставить на производство сложные современные устройства, которые могут успешно конкурировать на мировом рынке. К сожалению, мы не всегда знаем, что то или иное устройство, которое активно продается в ЕС, США или Канаде под известным брендом, на самом деле было разработано в российском дизайн-центре, который реализовал проект как аутсорсер, подписал соглашение о неразглашении и потому не может публично заявить о своём успехе.
Мы знаем, что на Хабре не одобряют саморекламу, но в данном случае мы просто хотим обосновать наш комментарий: российская электроника жива и вот тому доказательство — http://promwad.ru/portfolio.
JTAG-адаптер для прошивки ни чем не отличается от JTAG-адаптера для тестирования, так как доступ к TAP-порту стандартизирован. Отличие идет только на уровне ПО.
Тоже самое и для диода. Скрипт зажигает светодиод и посредством графического интерфейса выводит Message Box, в котором спрашивает, горит ли светодиод.
В ПО Provision интегрирован скриптовый язык python со всеми вытекающими последствиями. Также для JTAG-тестирование можно применять ПО других фирм, в них будут интегрированы другие языки. Например, в XJTAG интегрирован C подобный язык.
По стоимости ответим позже.
Более подробно про JTAG и с чем его едят посмотрите эту статью на Хабре.
1. Необходим BSDL-файл для JTAG-совместимого устройства.
2. Нет лист-схемы.
3. Все это закидывается в ПО для генерации тестов, затем генерируются автоматические тесты, при необходимости корректируем цепи, которые нельзя проверять или на которых необходим определенный уровень.
4. Если необходимо, пишем дополнительные тесты на Python.
5. Подключаем адаптер к JTAG-порту.
6. Включаем девайс, запускаем тесты.
7. В результате тест выдаст таблицу, по которой будет видно, как цепь отреагировала на определенное воздействие.
8. По результатам делается вывод о КЗ, обрыве.
Пример
В таблицах воздействии значения расшифровываются так: Z – драйвер в Z состоянии; L, H – состояние выхода; 0,1 – считанные значение со входа; 0, 1 – ошибочные значения (0 означает — считан 0, а ожидалась 1).
Тут видно, что цепь POR_3 имеет КЗ на лог.1, а цепь P0_RX_CTRL видит лог 1., хотя должна была видеть лог.0
Руководитель проекта – очень важная и ответственная работа, и область ответственности там намного шире, чем просто следить за разработчиками. Действительно, очень часто руководитель проекта, по сути, является разработчиком, а разработчики, как Вы удачно выразились, только интерфейсы к CAD’ам. И это, на мой взгляд, не совсем правильно. Намного лучше организовать процесс разработки так, чтоб каждый ее участник отвечал за свою часть работ.
Вопрос мотивации сотрудников – один из самых сложных и его надо решать. Я не видел, чтобы его «пристегивали» к принципам DFM. Разве что косвенно, при расчете себестоимости. Но идея интересная. Ведь качественно выполнить работу может только тот специалист, который хочет ее выполнить.
Про конкретику. Мне тоже очень хотелось бы получить универсальный набор правил. Выполнил все по пунктам – получил хорошее изделие. Но такого набора нет. И не может быть в принципе. Очень много переменных: разные задачи, разные инструменты, разные пути реализации, разное количество специалистов и т. д. Вопросов слишком много. Поэтому придумали принципы DFM. Принципы. Не правила!
1. Самая первая моя разработка. Я не сделал отступ меди от контура платы. Даже не думал, что это надо делать. На производстве контур фрезеровался. При проходе фрезы по контуру образовалась «медная шуба». И даже в нескольких местах образовались КЗ. Вот так незнание технологий производства привело к не работоспособной плате. Кстати, такие глупые ошибки встречаются постоянно. И, как это ни странно, не только у начинающих разработчиков.
2. Более сложный пример. Разрабатывали сложное устройство. В частности корпус (речь пойдет о нем). По дизайну выходные разъемы устройства располагались по трем сторонам. К моменту разработки уже был накоплен достаточно большой опыт и была сильная команда разработчиков. Когда печатная плата и корпус были спроектированы, мы стали проводить моделирование на собираемость (компьютерное). По результатам редактировали модели деталей корпуса, пока на модели все стало «хорошо собираться». Получив хорошие результаты моделирования, мы сразу отдали устройство на производство. Выпустили пресс-форму (корпус должен был отливаться). Получили готовые детали. И при «живой сборке» не смогли ничего сделать. Там мешало какое-то маленькое ребро жесткости. Этого не заметили на моделировании. Пришлось дорабатывать пресс-форму, избавляться от брака – а ведь это очень дорого. Вот если бы до этапа производства мы отдали наши модели на выращивание и проверили все «вживую», то избежали бы потерь как по времени, так и финансовых.
Да, большой функционал. Клиенты для социальных сетей, плееры, кодеки… но об этом далее)
Дело в том, что разработчики embedded устройств очень консервативны. Наверняка, это обусловленно экономическими причинами. Китайские производители, ИМХО, работаю по такому принципу: разработал устройство, портировал ядро — работает — продал. Начал разрабатывать новый девайс.
У нас любят говорить о преимуществах высшего образования в России. Наши выпускники описываются как «специалисты широкого профиля», обладающие большими преимуществами по сравнению с западными «ограниченными» узкоспециализированными инженерами. На самом деле эта широкопрофильность играет злую шутку с молодыми специалистами.
Предприятиям не нужны «мастера на все руки», им не хватает сотрудников с конкретной узкой специализацией. В итоге каждого выпускника приходится «затачивать» под определенные задачи прямо на предприятиях, причем это обучение ведется чуть ли с нуля, т.к. образовательные программы ВУЗов весьма далеки от реальных потребностей российских электронщиков.
Вот и получается, что свежеиспеченный инженер проходит еще одну школу уже во время работы, причем тратит на это не менее пяти лет.
Действительно, качество и сложность разработок очень разное, нам сложно делать обобщения. Но электронику в России разрабатывают и производят, и эти проекты не ограничиваются ВПК, пожарной автоматикой, банковским оборудованием и т.п. Отдельные компании в СНГ и в России в частности способны проектировать и ставить на производство сложные современные устройства, которые могут успешно конкурировать на мировом рынке. К сожалению, мы не всегда знаем, что то или иное устройство, которое активно продается в ЕС, США или Канаде под известным брендом, на самом деле было разработано в российском дизайн-центре, который реализовал проект как аутсорсер, подписал соглашение о неразглашении и потому не может публично заявить о своём успехе.
Мы знаем, что на Хабре не одобряют саморекламу, но в данном случае мы просто хотим обосновать наш комментарий: российская электроника жива и вот тому доказательство — http://promwad.ru/portfolio.