Перейти к содержанию
    

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Напомнило..

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

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

Вот беда.

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

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

Ерунда.

 

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

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

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

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

 

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

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

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

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

И тем живешь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

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

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

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Изменено пользователем x736C

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

 

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

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

 

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

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

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

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

 

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

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

 

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

 

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

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

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

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

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

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

 

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

post-9118-1507243463_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...