Jump to content
    

О философии HDL-дизайнера

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

 

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

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

Aсинхронность в голове хуже асинхронщины в дизайне....

Share this post


Link to post
Share on other sites

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

 

Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"?

Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно...

Ответ должен быть такой - "продаю рабочее время и получаю зарплату". А потому - важен только результат, причем в срок, а не "завтра". А это значит, что проект и файлы к нему надо делать так, чтобы не рисковать. Не позволять ошибкам попадать в проект.

Для примера - I2C.

Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда...

Share this post


Link to post
Share on other sites

Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"?

Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно...

Ответ должен быть такой - "продаю рабочее время и получаю зарплату".

Напомнило..

Просто странно иногда,

Как меняют нас года, -

Вот беда.

Что сказал бы ты тогда,

А теперь ты говоришь -

Ерунда.

 

И я искал в тебе хоть след

Того, что нас держало вместе столько лет.

И я искал в тебе хоть слабый свет

Того, чего давно в помине нет.

 

Ты раньше денег не считал,

Ты всех любил, когда играл и отдавал.

Теперь тебя не проведешь,

Ты не даешь, а продаешь

И тем живешь.

Share this post


Link to post
Share on other sites

как мне это знакомо, по прошлой работе...

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

 

Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда...

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

Share this post


Link to post
Share on other sites

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

Так и с этим все проще. Если части уже протестированы, то...

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

 

Share this post


Link to post
Share on other sites

Так и с этим все проще. Если части уже протестированы, то...

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

Ключевое слово "части уже протестированы". Диапазон критериев огромен. И потом,- уровень иерархии проекта способен сделать среди, казалось бы проверенных кирпичей, новую проблему. Тут в большом выигрыше SV. В таком концепте верификации спокойнее живется...

Share this post


Link to post
Share on other sites

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

 

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

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

Полагаю, все перечисленные вами подходы имеют право на жизнь.

 

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

Рекомендую уже ставшую классикой и много раз на форуме упомянутую:

Reuse Methodology Manual for System-on-a-Chip Designs.

В ней такой подход обосновывается на цифрах и фактах.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Edited by x736C

Share this post


Link to post
Share on other sites

Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"?

Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно...

Ответ должен быть такой - "продаю рабочее время и получаю зарплату". А потому - важен только результат, причем в срок, а не "завтра". А это значит, что проект и файлы к нему надо делать так, чтобы не рисковать. Не позволять ошибкам попадать в проект.

Для примера - I2C.

Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда...

Я и делаю все в несколько слоев: прием битов > выделение слов > протокол > регистры самого приложения. Ошибок как таковых действительно быть не должно.

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

 

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

Полагаю, все перечисленные вами подходы имеют право на жизнь.

 

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

Рекомендую уже ставшую классикой и много раз на форуме упомянутую:

Reuse Methodology Manual for System-on-a-Chip Designs.

В ней такой подход обосновывается на цифрах и фактах.

 

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

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

 

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

 

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

Такой подход гробит не только проект, но и ваш карьерный рост в подавляющем большинстве случаев. Вероятно, это вопрос дискуссионный, но я в этом давно уверился. Столько печальных примеров перед глазами прошло.

Согласен. Правда скорее всего перфекционизм в одном модуле все не похоронит, а в целом продукте-проекте это скорее всего фиаско.

Тут правда палка о двух концах - проекты класса SIL1...3 или мили- авио- и с другой стороны продукты без огромной ответственности.

Все же я думаю что осознание и обсуждение полной функциональности при разработке все же не вредит. Главное сбалансировать все так что-бы успеть в срок.

Из своего опыта скажу, что полюс противоположный перфекционизму, губящему и продукты, и целые конторы, это "главное успеть все в срок, а там посмотрим". Бывает так, что в результате у команды за десяток лет нет ничего реально reusable и каждый новый проект это новая старая боль в пятой точке. Или вылазят баги или упущения уже на стадии валидации всей системы. Что в свою очередь срыв сроков, красные глаза, героический подвиг... и все с начала :)

 

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

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

Очень хорошо сформулировано "инкрементная разработка с возрастающей сложностью". В последнее время приходится идти именно таким путем. Мини-waterfall на каждой итерации, но со спринтами от проекта к проекту. Борьба здравого смысла с идеализацией.

 

Share this post


Link to post
Share on other sites

У меня критерий один, см график - останавливаться в красной точке, но ни в коем случае не в черной.

post-9118-1507243463_thumb.png

Share this post


Link to post
Share on other sites

можете поделиться СТП и CodeStyle по оформлению исходников на VHDL? :)

 

Скоро тест вытрут с файлообменника... Успели?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...