реклама на сайте
подробности

 
 
10 страниц V  « < 8 9 10  
Reply to this topicStart new topic
> О философии HDL-дизайнера, Поделитесь мудростью вашего ремесла. Почти пятничное..
alxkon
сообщение Oct 5 2017, 11:24
Сообщение #136


Частый гость
**

Группа: Участник
Сообщений: 76
Регистрация: 16-11-10
Пользователь №: 60 920



А как философы подходят к проблеме универсализма и перфекционизма в дизайне с ПЛИС, принимая во внимание краткие сроки проекта?

К примеру в даный момент нужно изваять на VHDL i2c мастер и слейв + memory-mapped registers в слейве + верификация, при этом дизайн со слейвом будет заливатся в однократно програмируемую ПЛИС.
Вроде бы ничего сложного, но от осознания важности и спешки + желания сделать решения универсальным для других проектов, пошла уже 3 неделя, а каменный цветок еще не готов... чувствую растроение личности - одна нашептывает "давай сделаем хорошо, надежно и универсально и не будем к этому больше возвращатся", вторая подначивает "ну да, давай еще потратим еще пол-года и сделаем удивительной красы никому ненужную фигню", третья предлагает сделать по минимуму, но надежно с возможностью второго захода на улучшение.
Aсинхронность в голове хуже асинхронщины в дизайне....
Go to the top of the page
 
+Quote Post
iosifk
сообщение Oct 5 2017, 11:36
Сообщение #137


Гуру
******

Группа: Модераторы
Сообщений: 3 678
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369



Цитата(alxkon @ Oct 5 2017, 14:24) *
А как философы подходят к проблеме универсализма и перфекционизма в дизайне с ПЛИС, принимая во внимание краткие сроки проекта?


Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"?
Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно...
Ответ должен быть такой - "продаю рабочее время и получаю зарплату". А потому - важен только результат, причем в срок, а не "завтра". А это значит, что проект и файлы к нему надо делать так, чтобы не рисковать. Не позволять ошибкам попадать в проект.
Для примера - I2C.
Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда...


--------------------
www.iosifk.narod.ru
Go to the top of the page
 
+Quote Post
blackfin
сообщение Oct 5 2017, 12:06
Сообщение #138


Гуру
******

Группа: Свой
Сообщений: 2 704
Регистрация: 18-04-05
Пользователь №: 4 261



Цитата(iosifk @ Oct 5 2017, 14:36) *
Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"?
Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно...
Ответ должен быть такой - "продаю рабочее время и получаю зарплату".
Напомнило..
Цитата
Просто странно иногда,
Как меняют нас года, -
Вот беда.
Что сказал бы ты тогда,
А теперь ты говоришь -
Ерунда.

И я искал в тебе хоть след
Того, что нас держало вместе столько лет.
И я искал в тебе хоть слабый свет
Того, чего давно в помине нет.

Ты раньше денег не считал,
Ты всех любил, когда играл и отдавал.
Теперь тебя не проведешь,
Ты не даешь, а продаешь
И тем живешь.
Go to the top of the page
 
+Quote Post
AVR
сообщение Oct 5 2017, 12:49
Сообщение #139


фанат Linux'а
*****

Группа: Свой
Сообщений: 1 098
Регистрация: 23-10-05
Из: SPB.RU
Пользователь №: 10 008



Цитата(Maverick @ Oct 5 2017, 10:23) *
как мне это знакомо, по прошлой работе...

Я обратил внимание на Ваше место проживания, равно как и у Мур. Не знаю, может так совпало, и на самом деле и там и там встречаются разные подходы. А "у нас" наблюдается нехватка специалистов, потому что все спецы уже давно трудоустроены на сладеньких местах, ну по моим предположениям. И когда встает вопрос нанимать новых сотрудников, видя тех кто приходит на собеседования и их уровень, приходит понимание, что без длительного обучения совершенно никуда. Это мои личные наблюдения, не могу поручиться что везде так. Поэтому начальство лояльно к обучению, потому что либо сотрудник научится, либо некому будет делать работу, на которые заключены контракты...

Цитата(iosifk @ Oct 5 2017, 14:36) *
Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда...

Лень - двигатель прогресса, но верификацию никто не отменял wink.gif


--------------------
Go to the top of the page
 
+Quote Post
iosifk
сообщение Oct 5 2017, 13:01
Сообщение #140


Гуру
******

Группа: Модераторы
Сообщений: 3 678
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369



Цитата(AVR @ Oct 5 2017, 15:49) *
Лень - двигатель прогресса, но верификацию никто не отменял wink.gif

Так и с этим все проще. Если части уже протестированы, то...
А самый верхний автомат можно вообще на программной модели отладить. Потому как там не в проводах дело, а в том, чтобы правильно реагировать на "события". А для меня это проще сделать в самодельной программе с кучей кнопок и окошек...


--------------------
www.iosifk.narod.ru
Go to the top of the page
 
+Quote Post
Мур
сообщение Oct 5 2017, 16:30
Сообщение #141


Знающий
****

Группа: Свой
Сообщений: 763
Регистрация: 7-06-06
Из: Харьков
Пользователь №: 17 847



Цитата(iosifk @ Oct 5 2017, 16:01) *
Так и с этим все проще. Если части уже протестированы, то...
А самый верхний автомат можно вообще на программной модели отладить. Потому как там не в проводах дело, а в том, чтобы правильно реагировать на "события". А для меня это проще сделать в самодельной программе с кучей кнопок и окошек...

Ключевое слово "части уже протестированы". Диапазон критериев огромен. И потом,- уровень иерархии проекта способен сделать среди, казалось бы проверенных кирпичей, новую проблему. Тут в большом выигрыше SV. В таком концепте верификации спокойнее живется...
Go to the top of the page
 
+Quote Post
x736C
сообщение Oct 5 2017, 17:20
Сообщение #142


Профессионал
*****

Группа: Участник
Сообщений: 1 162
Регистрация: 3-03-06
Пользователь №: 14 942



Цитата(alxkon @ Oct 5 2017, 14:24) *
А как философы подходят к проблеме универсализма и перфекционизма в дизайне с ПЛИС, принимая во внимание краткие сроки проекта?

К примеру в даный момент нужно изваять на VHDL i2c мастер и слейв + memory-mapped registers в слейве + верификация, при этом дизайн со слейвом будет заливатся в однократно програмируемую ПЛИС.

Существует несколько подходов к разработке. И каждый имеет право на жизнь. Зависит от контекста, в котором выполняется задача. Порекомендовал бы книжку «Совершенный код», в ней эти вопросы освещаются.
Полагаю, все перечисленные вами подходы имеют право на жизнь.

Достаточно давно в коллективном сознании разработчиков утвердилась мысль, что код должен быть пригодный к повторному использованию (reusable methodology). В этом случае, в будущем происходит экономия человеко-часов, позволяя наращивать сложность разрабатываемых систем. Но в таком случае код должен отвечать определенным критериям.
Рекомендую уже ставшую классикой и много раз на форуме упомянутую:
Reuse Methodology Manual for System-on-a-Chip Designs.
В ней такой подход обосновывается на цифрах и фактах.

Если принять советы из первой книги, как полезные и правильные, то еще 3 недели назад все должно было начаться с формирования требований. И сегодня вы бы точно знали, куда двигаетесь. Какой конкретно функционал реализуете, стараясь придерживаться выбранного пути.

Исходя из концепции второй книги, стоило бы поискать готовое ядро и стыковать его через стандартный шинный интерфейс. Либо самому писать его так, чтобы можно было использовать повторно в других проектах, учитывая, что новые проекты могут иметь отличия от текущего.

Мой личный жизненный опыт говорит о том, что, как правило, в повседневной деятельности российского разработчика, где не очень сильна бюрократия, правильным подходом является сделать как можно быстрее, сохраняя качество кода (документирование, тестбенч и т.п.). То есть не пытаться фаршировать модуль ненужными функциями, единственной причиной для имплементации которых является желание самого разработчика. Был свидетелем и даже участником гибели не одного проекта, который не полетел из-за неверно расставленных приоритетов и попыток сделать всё и в первой итерации. Думаю, многим такое знакомо. Еще отмечу, что идя по такому пути, в 100% случаев происходит закономерная недооценка трудозатрат.

Цитата(alxkon @ Oct 5 2017, 14:24) *
вторая подначивает "ну да, давай еще потратим еще пол-года и сделаем удивительной красы никому ненужную фигню"
Такой подход гробит не только проект, но и ваш карьерный рост в подавляющем большинстве случаев. Вероятно, это вопрос дискуссионный, но я в этом давно уверился. Столько печальных примеров перед глазами прошло.

Цитата(alxkon @ Oct 5 2017, 14:24) *
третья предлагает сделать по минимуму, но надежно с возможностью второго захода на улучшение.
Этот подход имеет право на жизнь. Назовем так, инкрементная разработка с возрастающей сложностью. На карьерном росте такой подход сказывается самым благоприятным образом. Так как в глазах начальства и коллег работа делается быстрейшим способом. Уже предполагаю упреки коллег, которые справедливо отметят снижение качества кода. Тут не надо впадать в крайности. Делать быстро, не значит писать говнокод. Всего лишь надо реализовывать то, без чего не будет работать. И то, что полностью удовлетворит требования. Качество кода может быть одним из прочих требований. И даже если качество чуть пострадает, лучше так (код всегда можно доработать), чем полгода разрабатывать качественную хрень, которая в итоге окажется никому не нужна.

Это всего лишь мой опыт, которым поделился. Не претендую на истину в последней инстанции.

AVR, в Москве точно такая же ситуация с рыком труда.

Сообщение отредактировал x736C - Oct 5 2017, 17:53
Go to the top of the page
 
+Quote Post
alxkon
сообщение Oct 5 2017, 19:39
Сообщение #143


Частый гость
**

Группа: Участник
Сообщений: 76
Регистрация: 16-11-10
Пользователь №: 60 920



Цитата(iosifk @ Oct 5 2017, 14:36) *
Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"?
Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно...
Ответ должен быть такой - "продаю рабочее время и получаю зарплату". А потому - важен только результат, причем в срок, а не "завтра". А это значит, что проект и файлы к нему надо делать так, чтобы не рисковать. Не позволять ошибкам попадать в проект.
Для примера - I2C.
Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда...

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

Цитата(x736C @ Oct 5 2017, 20:20) *
Существует несколько подходов к разработке. И каждый имеет право на жизнь. Зависит от контекста, в котором выполняется задача. Порекомендовал бы книжку «Совершенный код», в ней эти вопросы освещаются.
Полагаю, все перечисленные вами подходы имеют право на жизнь.

Достаточно давно в коллективном сознании разработчиков утвердилась мысль, что код должен быть пригодный к повторному использованию (reusable methodology). В этом случае, в будущем происходит экономия человеко-часов, позволяя наращивать сложность разрабатываемых систем. Но в таком случае код должен отвечать определенным критериям.
Рекомендую уже ставшую классикой и много раз на форуме упомянутую:
Reuse Methodology Manual for System-on-a-Chip Designs.
В ней такой подход обосновывается на цифрах и фактах.

Если принять советы из первой книги, как полезные и правильные, то еще 3 недели назад все должно было начаться с формирования требований. И сегодня вы бы точно знали, куда двигаетесь. Какой конкретно функционал реализуете, стараясь придерживаться выбранного пути.

Спасибо за ответ и за наводку на книгу. Я так и начал, преверженец waterfall-а: написал требования, отбросил лишнее - например clock stretching у слейва и арбитрацию у мастера, решил что нижний уровень пишу с точки зрения reusable методологии - интерфейсы к высшему уровню логики делаю так что бы добавив небольшой врапер прикрутить регистры или писать фифо или в блочную память, ну и естественно сигнализировать о начале-конце трансфера и т.д. Прикинул параметризацию, разбил на логические блоки и начал писать vhdl. Дело в том, что пишу и рисую диаграмы я на бумаге, так быстрей, но от этого чувство незаконченности и есть риск, что времени на должное оформление будет в обрез. Коментариев правда пишу достаточно.

Цитата(x736C @ Oct 5 2017, 20:20) *
Исходя из концепции второй книги, стоило бы поискать готовое ядро и стыковать его через стандартный шинный интерфейс. Либо самому писать его так, чтобы можно было использовать повторно в других проектах, учитывая, что новые проекты могут иметь отличия от текущего.

Мой личный жизненный опыт говорит о том, что, как правило, в повседневной деятельности российского разработчика, где не очень сильна бюрократия, правильным подходом является сделать как можно быстрее, сохраняя качество кода (документирование, тестбенч и т.п.). То есть не пытаться фаршировать модуль ненужными функциями, единственной причиной для имплементации которых является желание самого разработчика. Был свидетелем и даже участником гибели не одного проекта, который не полетел из-за неверно расставленных приоритетов и попыток сделать всё и в первой итерации. Думаю, многим такое знакомо. Еще отмечу, что идя по такому пути, в 100% случаев происходит закономерная недооценка трудозатрат.
Такой подход гробит не только проект, но и ваш карьерный рост в подавляющем большинстве случаев. Вероятно, это вопрос дискуссионный, но я в этом давно уверился. Столько печальных примеров перед глазами прошло.

Согласен. Правда скорее всего перфекционизм в одном модуле все не похоронит, а в целом продукте-проекте это скорее всего фиаско.
Тут правда палка о двух концах - проекты класса SIL1...3 или мили- авио- и с другой стороны продукты без огромной ответственности.
Все же я думаю что осознание и обсуждение полной функциональности при разработке все же не вредит. Главное сбалансировать все так что-бы успеть в срок.
Из своего опыта скажу, что полюс противоположный перфекционизму, губящему и продукты, и целые конторы, это "главное успеть все в срок, а там посмотрим". Бывает так, что в результате у команды за десяток лет нет ничего реально reusable и каждый новый проект это новая старая боль в пятой точке. Или вылазят баги или упущения уже на стадии валидации всей системы. Что в свою очередь срыв сроков, красные глаза, героический подвиг... и все с начала sm.gif

Цитата(x736C @ Oct 5 2017, 20:20) *
Этот подход имеет право на жизнь. Назовем так, инкрементная разработка с возрастающей сложностью. На карьерном росте такой подход сказывается самым благоприятным образом. Так как в глазах начальства и коллег работа делается быстрейшим способом. Уже предполагаю упреки коллег, которые справедливо отметят снижение качества кода. Тут не надо впадать в крайности. Делать быстро, не значит писать говнокод. Всего лишь надо реализовывать то, без чего не будет работать. И то, что полностью удовлетворит требования. Качество кода может быть одним из прочих требований. И даже если качество чуть пострадает, лучше так (код всегда можно доработать), чем полгода разрабатывать качественную хрень, которая в итоге окажется никому не нужна.
Это всего лишь мой опыт, которым поделился. Не претендую на истину в последней инстанции.

Очень хорошо сформулировано "инкрементная разработка с возрастающей сложностью". В последнее время приходится идти именно таким путем. Мини-waterfall на каждой итерации, но со спринтами от проекта к проекту. Борьба здравого смысла с идеализацией.
Go to the top of the page
 
+Quote Post
Leka
сообщение Oct 5 2017, 22:44
Сообщение #144


Знающий
****

Группа: Участник
Сообщений: 982
Регистрация: 30-09-05
Пользователь №: 9 118



У меня критерий один, см график - останавливаться в красной точке, но ни в коем случае не в черной.
Эскизы прикрепленных изображений
Прикрепленное изображение
 
Go to the top of the page
 
+Quote Post
Мур
сообщение Oct 10 2017, 05:06
Сообщение #145


Знающий
****

Группа: Свой
Сообщений: 763
Регистрация: 7-06-06
Из: Харьков
Пользователь №: 17 847



Цитата(Maverick @ Oct 5 2017, 11:37) *
можете поделиться СТП и CodeStyle по оформлению исходников на VHDL? sm.gif


Скоро тест вытрут с файлообменника... Успели?
Go to the top of the page
 
+Quote Post
Maverick
сообщение Oct 10 2017, 09:17
Сообщение #146


я только учусь...
******

Группа: Модераторы
Сообщений: 3 394
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839



Цитата(Мур @ Oct 10 2017, 08:06) *
Скоро тест вытрут с файлообменника... Успели?

спасибо, скачал


--------------------
If it doesn't work in simulation, it won't work on the board.

"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
Go to the top of the page
 
+Quote Post

10 страниц V  « < 8 9 10
Reply to this topicStart new topic
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 20th November 2017 - 09:34
Рейтинг@Mail.ru


Страница сгенерированна за 0.01332 секунд с 7
ELECTRONIX ©2004-2016