Re: И почему для успешности "разработчика РЭА"panchulFebruary 21 2011, 06:54:28 UTC
??? Я не очень понял ваш вопрос. Вы спрашиваете про меня? Или про описываемую позицию verification engineer?
Если про меня:
Я не пишу embedded software как такового (хотя писал тулы для девелоперов embedded software) и следовательно не использую in circuit emulator (ICE). В разные периоды жизни я писал кросс-компиляторы, софтверные симуляторы процессоров (от instruction-accurate до cycle-accurate), тулы для высокоуровнего синтеза хардвера (C -> Verilog), модели хардверных устройств, модели on-chip-buses (bus functional models) и verification environments. Ни одно из вышеперечисленного не является "embedded system programming" и не требует ICE.
Также вы уверены, что вы не путаете Embedded Software Tools с Electronic Design Automation? Первое - это тулы для создания софтвера, второе - тулы для создания хардвера.
Если ваш коммент является ответом на какой-то из моих старых комментариев где-то, прошу вас дать мне ссылку, чтобы я вспомнил контекст.
Если про позицию "verification engineer":
Человек этой профессии тоже не пишет embedded software и не использует ICE (хотя ICE можно использовать для нужд верификации в достаточно тонком контексте). Верификационный инженер проверяет, соответствует ли хардверный дизайн, написанный на языке Verilog, своей спецификации. Для этого верификационный инженер делает довольно хитрую программу, которая бомбардирует дизайн на верилоге псевдослучайными транзакциями, пока он его не сломает. Одновременно при этом проверяется покрытие всяких описанных в спецификации сценариев с помощью спецификации на SystemVerilog так называемых coverage bins и подобных штучек. Есть и другие средства в арсенале верификации, но это не embedded software development.
(Вообще мне нужно написать об этом специальный пост).
Я конечный пользовать "всего подряд"dolbonosicFebruary 21 2011, 17:06:16 UTC
Приборостроитель. Проектирую приборы целиком, начиная от "чувствительно элемента" и заканчивая тестовыми программами на ИБМ ПЦ (через мост УСБ-СОМ). Это чтоб программисты не вопили "Это у тебя не работает!"
Правда, очень сильно "дисквалифицировавшийся". До такой степени, что до сих не освоил АВР, не вижу смысла, посколько почему-то мне до сих пор хватает 52-однокристаллки и ЙАР Це-51 1990. Строго ИЦЕ. ИЦЕ мешается. Хотя, последнее время, лет 5, 90% деятельности - "ембеддед программирование на Це".
А "верилогоподобные" штуки - это я на ЕС-1045 проходил, в конце 80-х. Моделирование СБИС. До моделирования "на P-CAD" дело уже не дошло. Потом в 97 была попытка применить C UPL. Но так и не потребовалось, ни 1045, ни C UPL. :))) Верилога даже не касался после такого. Приборчики простые, одного чела - меня, хватает.
А тут на глаз тема про Верилог попалась "любимая мозоль задета" :))) - "захотелось поговорить об этом вообще".
Re: Я конечный пользовать "всего подряд"panchulFebruary 21 2011, 18:18:41 UTC
Ну если вы освоили CUPL, то Verilog (по крайней мере его RTL-подмножество (register transfer level)) вам было бы понять довольно просто. А вот SystemVerilog - это другая история, там больше для верификации, а не для дизайна.
Не, не освоилdolbonosicFebruary 22 2011, 10:16:48 UTC
Задач не нашлось. Даже "на дальнюю перспективу", т.е. с оплатой "может быть когда-нибудь если всё пойдёт хорошо". Распаял колодку на макетку, неделю в микросхему чего-то программировал - так всё и закончилось. А потом 1998 случился. Вообще не до того стало.
Если про меня:
Я не пишу embedded software как такового (хотя писал тулы для девелоперов embedded software) и следовательно не использую in circuit emulator (ICE). В разные периоды жизни я писал кросс-компиляторы, софтверные симуляторы процессоров (от instruction-accurate до cycle-accurate), тулы для высокоуровнего синтеза хардвера (C -> Verilog), модели хардверных устройств, модели on-chip-buses (bus functional models) и verification environments. Ни одно из вышеперечисленного не является "embedded system programming" и не требует ICE.
Также вы уверены, что вы не путаете Embedded Software Tools с Electronic Design Automation? Первое - это тулы для создания софтвера, второе - тулы для создания хардвера.
Если ваш коммент является ответом на какой-то из моих старых комментариев где-то, прошу вас дать мне ссылку, чтобы я вспомнил контекст.
Если про позицию "verification engineer":
Человек этой профессии тоже не пишет embedded software и не использует ICE (хотя ICE можно использовать для нужд верификации в достаточно тонком контексте). Верификационный инженер проверяет, соответствует ли хардверный дизайн, написанный на языке Verilog, своей спецификации. Для этого верификационный инженер делает довольно хитрую программу, которая бомбардирует дизайн на верилоге псевдослучайными транзакциями, пока он его не сломает. Одновременно при этом проверяется покрытие всяких описанных в спецификации сценариев с помощью спецификации на SystemVerilog так называемых coverage bins и подобных штучек. Есть и другие средства в арсенале верификации, но это не embedded software development.
(Вообще мне нужно написать об этом специальный пост).
Reply
Проектирую приборы целиком, начиная от "чувствительно элемента" и заканчивая тестовыми программами на ИБМ ПЦ (через мост УСБ-СОМ).
Это чтоб программисты не вопили "Это у тебя не работает!"
Правда, очень сильно "дисквалифицировавшийся". До такой степени, что до сих не освоил АВР, не вижу смысла, посколько почему-то мне до сих пор хватает 52-однокристаллки и ЙАР Це-51 1990. Строго ИЦЕ. ИЦЕ мешается.
Хотя, последнее время, лет 5, 90% деятельности - "ембеддед программирование на Це".
А "верилогоподобные" штуки - это я на ЕС-1045 проходил, в конце 80-х.
Моделирование СБИС. До моделирования "на P-CAD" дело уже не дошло.
Потом в 97 была попытка применить C UPL.
Но так и не потребовалось, ни 1045, ни C UPL. :))) Верилога даже не касался после такого.
Приборчики простые, одного чела - меня, хватает.
А тут на глаз тема про Верилог попалась "любимая мозоль задета" :))) - "захотелось поговорить об этом вообще".
Reply
Reply
Reply
Даже "на дальнюю перспективу", т.е. с оплатой "может быть когда-нибудь если всё пойдёт хорошо".
Распаял колодку на макетку, неделю в микросхему чего-то программировал - так всё и закончилось. А потом 1998 случился. Вообще не до того стало.
Ненужно.
Reply
Однако, понимания она не встретила.
В "ИТ" и около мейнстримом давно стал лозуг "Быстро и плохо, иначе конкуренты сделают ещё быстрее и ещё хуже!"
"Славы и денег" в "испытаниях" ещё меньше.
Reply
Leave a comment