alxkon 0 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба А как философы подходят к проблеме универсализма и перфекционизма в дизайне с ПЛИС, принимая во внимание краткие сроки проекта? К примеру в даный момент нужно изваять на VHDL i2c мастер и слейв + memory-mapped registers в слейве + верификация, при этом дизайн со слейвом будет заливатся в однократно програмируемую ПЛИС. Вроде бы ничего сложного, но от осознания важности и спешки + желания сделать решения универсальным для других проектов, пошла уже 3 неделя, а каменный цветок еще не готов... чувствую растроение личности - одна нашептывает "давай сделаем хорошо, надежно и универсально и не будем к этому больше возвращатся", вторая подначивает "ну да, давай еще потратим еще пол-года и сделаем удивительной красы никому ненужную фигню", третья предлагает сделать по минимуму, но надежно с возможностью второго захода на улучшение. Aсинхронность в голове хуже асинхронщины в дизайне.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба А как философы подходят к проблеме универсализма и перфекционизма в дизайне с ПЛИС, принимая во внимание краткие сроки проекта? Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"? Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно... Ответ должен быть такой - "продаю рабочее время и получаю зарплату". А потому - важен только результат, причем в срок, а не "завтра". А это значит, что проект и файлы к нему надо делать так, чтобы не рисковать. Не позволять ошибкам попадать в проект. Для примера - I2C. Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 32 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"? Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно... Ответ должен быть такой - "продаю рабочее время и получаю зарплату". Напомнило.. Просто странно иногда, Как меняют нас года, - Вот беда. Что сказал бы ты тогда, А теперь ты говоришь - Ерунда. И я искал в тебе хоть след Того, что нас держало вместе столько лет. И я искал в тебе хоть слабый свет Того, чего давно в помине нет. Ты раньше денег не считал, Ты всех любил, когда играл и отдавал. Теперь тебя не проведешь, Ты не даешь, а продаешь И тем живешь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
1891ВМ12Я 0 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба как мне это знакомо, по прошлой работе... Я обратил внимание на Ваше место проживания, равно как и у Мур. Не знаю, может так совпало, и на самом деле и там и там встречаются разные подходы. А "у нас" наблюдается нехватка специалистов, потому что все спецы уже давно трудоустроены на сладеньких местах, ну по моим предположениям. И когда встает вопрос нанимать новых сотрудников, видя тех кто приходит на собеседования и их уровень, приходит понимание, что без длительного обучения совершенно никуда. Это мои личные наблюдения, не могу поручиться что везде так. Поэтому начальство лояльно к обучению, потому что либо сотрудник научится, либо некому будет делать работу, на которые заключены контракты... Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда... Лень - двигатель прогресса, но верификацию никто не отменял ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
iosifk 3 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба Лень - двигатель прогресса, но верификацию никто не отменял ;) Так и с этим все проще. Если части уже протестированы, то... А самый верхний автомат можно вообще на программной модели отладить. Потому как там не в проводах дело, а в том, чтобы правильно реагировать на "события". А для меня это проще сделать в самодельной программе с кучей кнопок и окошек... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Мур 1 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба Так и с этим все проще. Если части уже протестированы, то... А самый верхний автомат можно вообще на программной модели отладить. Потому как там не в проводах дело, а в том, чтобы правильно реагировать на "события". А для меня это проще сделать в самодельной программе с кучей кнопок и окошек... Ключевое слово "части уже протестированы". Диапазон критериев огромен. И потом,- уровень иерархии проекта способен сделать среди, казалось бы проверенных кирпичей, новую проблему. Тут в большом выигрыше SV. В таком концепте верификации спокойнее живется... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x736C 0 5 октября, 2017 Опубликовано 5 октября, 2017 (изменено) · Жалоба А как философы подходят к проблеме универсализма и перфекционизма в дизайне с ПЛИС, принимая во внимание краткие сроки проекта? К примеру в даный момент нужно изваять на VHDL i2c мастер и слейв + memory-mapped registers в слейве + верификация, при этом дизайн со слейвом будет заливатся в однократно програмируемую ПЛИС. Существует несколько подходов к разработке. И каждый имеет право на жизнь. Зависит от контекста, в котором выполняется задача. Порекомендовал бы книжку «Совершенный код», в ней эти вопросы освещаются. Полагаю, все перечисленные вами подходы имеют право на жизнь. Достаточно давно в коллективном сознании разработчиков утвердилась мысль, что код должен быть пригодный к повторному использованию (reusable methodology). В этом случае, в будущем происходит экономия человеко-часов, позволяя наращивать сложность разрабатываемых систем. Но в таком случае код должен отвечать определенным критериям. Рекомендую уже ставшую классикой и много раз на форуме упомянутую: Reuse Methodology Manual for System-on-a-Chip Designs. В ней такой подход обосновывается на цифрах и фактах. Если принять советы из первой книги, как полезные и правильные, то еще 3 недели назад все должно было начаться с формирования требований. И сегодня вы бы точно знали, куда двигаетесь. Какой конкретно функционал реализуете, стараясь придерживаться выбранного пути. Исходя из концепции второй книги, стоило бы поискать готовое ядро и стыковать его через стандартный шинный интерфейс. Либо самому писать его так, чтобы можно было использовать повторно в других проектах, учитывая, что новые проекты могут иметь отличия от текущего. Мой личный жизненный опыт говорит о том, что, как правило, в повседневной деятельности российского разработчика, где не очень сильна бюрократия, правильным подходом является сделать как можно быстрее, сохраняя качество кода (документирование, тестбенч и т.п.). То есть не пытаться фаршировать модуль ненужными функциями, единственной причиной для имплементации которых является желание самого разработчика. Был свидетелем и даже участником гибели не одного проекта, который не полетел из-за неверно расставленных приоритетов и попыток сделать всё и в первой итерации. Думаю, многим такое знакомо. Еще отмечу, что идя по такому пути, в 100% случаев происходит закономерная недооценка трудозатрат. вторая подначивает "ну да, давай еще потратим еще пол-года и сделаем удивительной красы никому ненужную фигню"Такой подход гробит не только проект, но и ваш карьерный рост в подавляющем большинстве случаев. Вероятно, это вопрос дискуссионный, но я в этом давно уверился. Столько печальных примеров перед глазами прошло. третья предлагает сделать по минимуму, но надежно с возможностью второго захода на улучшение.Этот подход имеет право на жизнь. Назовем так, инкрементная разработка с возрастающей сложностью. На карьерном росте такой подход сказывается самым благоприятным образом. Так как в глазах начальства и коллег работа делается быстрейшим способом. Уже предполагаю упреки коллег, которые справедливо отметят снижение качества кода. Тут не надо впадать в крайности. Делать быстро, не значит писать говнокод. Всего лишь надо реализовывать то, без чего не будет работать. И то, что полностью удовлетворит требования. Качество кода может быть одним из прочих требований. И даже если качество чуть пострадает, лучше так (код всегда можно доработать), чем полгода разрабатывать качественную хрень, которая в итоге окажется никому не нужна. Это всего лишь мой опыт, которым поделился. Не претендую на истину в последней инстанции. AVR, в Москве точно такая же ситуация с рыком труда. Изменено 5 октября, 2017 пользователем x736C Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alxkon 0 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба Когда читаю ученикам уроки, то задаю в самом начале один вопрос: "с какой целью Вы ходите на работу"? Если ответ - " сделаем удивительной красы никому ненужную фигню", то дальше объяснять верилог бесполезно... Ответ должен быть такой - "продаю рабочее время и получаю зарплату". А потому - важен только результат, причем в срок, а не "завтра". А это значит, что проект и файлы к нему надо делать так, чтобы не рисковать. Не позволять ошибкам попадать в проект. Для примера - I2C. Можно зафигачить "все в одном"... С кучей непонятных названий проводов. А можно сделать 3 автомата на все последовательные передачи кадрами. Один - для обработки битов, один - для слов и верхний - для "сообщений"... Все. Ошибкам просто взяться неоткуда... Я и делаю все в несколько слоев: прием битов > выделение слов > протокол > регистры самого приложения. Ошибок как таковых действительно быть не должно. Дело не в дизайне как таковом, а в компромисе между достаточной функциональностью, заделом на будущее, сроками и перфекционизмом. Перефразирую первоначальное сообщение - у меня одного бывают душевные муки в компромисах или другие тоже испытывают похожее? :) Существует несколько подходов к разработке. И каждый имеет право на жизнь. Зависит от контекста, в котором выполняется задача. Порекомендовал бы книжку «Совершенный код», в ней эти вопросы освещаются. Полагаю, все перечисленные вами подходы имеют право на жизнь. Достаточно давно в коллективном сознании разработчиков утвердилась мысль, что код должен быть пригодный к повторному использованию (reusable methodology). В этом случае, в будущем происходит экономия человеко-часов, позволяя наращивать сложность разрабатываемых систем. Но в таком случае код должен отвечать определенным критериям. Рекомендую уже ставшую классикой и много раз на форуме упомянутую: Reuse Methodology Manual for System-on-a-Chip Designs. В ней такой подход обосновывается на цифрах и фактах. Если принять советы из первой книги, как полезные и правильные, то еще 3 недели назад все должно было начаться с формирования требований. И сегодня вы бы точно знали, куда двигаетесь. Какой конкретно функционал реализуете, стараясь придерживаться выбранного пути. Спасибо за ответ и за наводку на книгу. Я так и начал, преверженец waterfall-а: написал требования, отбросил лишнее - например clock stretching у слейва и арбитрацию у мастера, решил что нижний уровень пишу с точки зрения reusable методологии - интерфейсы к высшему уровню логики делаю так что бы добавив небольшой врапер прикрутить регистры или писать фифо или в блочную память, ну и естественно сигнализировать о начале-конце трансфера и т.д. Прикинул параметризацию, разбил на логические блоки и начал писать vhdl. Дело в том, что пишу и рисую диаграмы я на бумаге, так быстрей, но от этого чувство незаконченности и есть риск, что времени на должное оформление будет в обрез. Коментариев правда пишу достаточно. Исходя из концепции второй книги, стоило бы поискать готовое ядро и стыковать его через стандартный шинный интерфейс. Либо самому писать его так, чтобы можно было использовать повторно в других проектах, учитывая, что новые проекты могут иметь отличия от текущего. Мой личный жизненный опыт говорит о том, что, как правило, в повседневной деятельности российского разработчика, где не очень сильна бюрократия, правильным подходом является сделать как можно быстрее, сохраняя качество кода (документирование, тестбенч и т.п.). То есть не пытаться фаршировать модуль ненужными функциями, единственной причиной для имплементации которых является желание самого разработчика. Был свидетелем и даже участником гибели не одного проекта, который не полетел из-за неверно расставленных приоритетов и попыток сделать всё и в первой итерации. Думаю, многим такое знакомо. Еще отмечу, что идя по такому пути, в 100% случаев происходит закономерная недооценка трудозатрат. Такой подход гробит не только проект, но и ваш карьерный рост в подавляющем большинстве случаев. Вероятно, это вопрос дискуссионный, но я в этом давно уверился. Столько печальных примеров перед глазами прошло. Согласен. Правда скорее всего перфекционизм в одном модуле все не похоронит, а в целом продукте-проекте это скорее всего фиаско. Тут правда палка о двух концах - проекты класса SIL1...3 или мили- авио- и с другой стороны продукты без огромной ответственности. Все же я думаю что осознание и обсуждение полной функциональности при разработке все же не вредит. Главное сбалансировать все так что-бы успеть в срок. Из своего опыта скажу, что полюс противоположный перфекционизму, губящему и продукты, и целые конторы, это "главное успеть все в срок, а там посмотрим". Бывает так, что в результате у команды за десяток лет нет ничего реально reusable и каждый новый проект это новая старая боль в пятой точке. Или вылазят баги или упущения уже на стадии валидации всей системы. Что в свою очередь срыв сроков, красные глаза, героический подвиг... и все с начала :) Этот подход имеет право на жизнь. Назовем так, инкрементная разработка с возрастающей сложностью. На карьерном росте такой подход сказывается самым благоприятным образом. Так как в глазах начальства и коллег работа делается быстрейшим способом. Уже предполагаю упреки коллег, которые справедливо отметят снижение качества кода. Тут не надо впадать в крайности. Делать быстро, не значит писать говнокод. Всего лишь надо реализовывать то, без чего не будет работать. И то, что полностью удовлетворит требования. Качество кода может быть одним из прочих требований. И даже если качество чуть пострадает, лучше так (код всегда можно доработать), чем полгода разрабатывать качественную хрень, которая в итоге окажется никому не нужна. Это всего лишь мой опыт, которым поделился. Не претендую на истину в последней инстанции. Очень хорошо сформулировано "инкрементная разработка с возрастающей сложностью". В последнее время приходится идти именно таким путем. Мини-waterfall на каждой итерации, но со спринтами от проекта к проекту. Борьба здравого смысла с идеализацией. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 1 5 октября, 2017 Опубликовано 5 октября, 2017 · Жалоба У меня критерий один, см график - останавливаться в красной точке, но ни в коем случае не в черной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Мур 1 10 октября, 2017 Опубликовано 10 октября, 2017 · Жалоба можете поделиться СТП и CodeStyle по оформлению исходников на VHDL? :) Скоро тест вытрут с файлообменника... Успели? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Maverick_ 15 10 октября, 2017 Опубликовано 10 октября, 2017 · Жалоба Скоро тест вытрут с файлообменника... Успели? спасибо, скачал Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
