1. Какой способ разработки Вы используете?

[LV26 0]

Аналогично! Но указал schematic.

 

Когда проект громоздкий, то легко сделать ошибку в коммутации HDL-модулей. Особенно когда исправляешь несколько проблем одновременно.

Со схематиком спокойней. А когда уже результат удовлетворяет,-быстро перевожу его в чистый HDL для переносимости.

 

...А по прошествии времени быстро вспомнить архитектуру можно глядя на отладочный схематик-вариант. Всегда его храню для памятки!

Так мне спокойней при новых(будущих) модификациях....

 

А я в начале проекта делаю документацию (блок диаграммы, временные диаграммы, описание сигналов, модулей и т.п.)

в Visio, TimeGenб т.п., а потом пишу собственно. Кодирование и моделирование заключительный этап. После всего этого, с некоторыми исправлениями,

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

[Гость CuiriousSalome]

А я в начале проекта делаю документацию (блок диаграммы, временные диаграммы, описание сигналов, модулей и т.п.)

в Visio, TimeGenб т.п., а потом пишу собственно. Кодирование и моделирование заключительный этап. После всего этого, с некоторыми исправлениями,

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

 

 

по моему при большой размерности проекта действительно лучше писать код. Тем более,что создание указанной Вами Victor® документации - просто неотъемлемая часть процесса разработки...+ зачем дублировать блок-диаграммы в САПРе?

[Maverick_ 15]

А я в начале проекта делаю документацию (блок диаграммы, временные диаграммы, описание сигналов, модулей и т.п.)

в Visio, TimeGenб т.п., а потом пишу собственно. Кодирование и моделирование заключительный этап. После всего этого, с некоторыми исправлениями,

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

и я примерно также делаю...

 

по моему при большой размерности проекта действительно лучше писать код. Тем более,что создание указанной Вами Victor® документации - просто неотъемлемая часть процесса разработки...+ зачем дублировать блок-диаграммы в САПРе?

Вы скажем через год или через 5 лет - вспомните что хотели какой-то заумной строчкой описать? Или другой разработчик в Вашем описании сможет быстро разобраться?

[Мур 1]

А я в начале проекта делаю документацию (блок диаграммы, временные диаграммы, описание сигналов, модулей и т.п.)

в Visio, TimeGenб т.п., а потом пишу собственно. Кодирование и моделирование заключительный этап. После всего этого, с некоторыми исправлениями,

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

Всё верно...

А я успеваю всё в тестбенчах прописать.... Остаётся просто его запустить. Если что не ясно,-МоделСим под рукой.

Начальство для документации даёт неделю. Рыба, что была в начале, дописывается новыми уточнениями. Временная понятна по схематику, а вот общая идея очень подробно должна быть в тексте. Пусть избыточно.... зато не пропустить все детали.

[Гость CuiriousSalome]

и я примерно также делаю...

 

 

Вы скажем через год или через 5 лет - вспомните что хотели какой-то заумной строчкой описать? Или другой разработчик в Вашем описании сможет быстро разобраться?

 

 

а документация на проект тогда зачем? + пишите комментарии на заумные строчки

[Мур 1]

Вы скажем через год или через 5 лет - вспомните что хотели какой-то заумной строчкой описать? Или другой разработчик в Вашем описании сможет быстро разобраться?

Вот тут схематик незаменим!

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

[Maverick_ 15]

Вот тут схематик незаменим!

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

полностью согласен.

Я например тоже графику лучше воспринимаю...

Из-за этого и трачу кучу времени - зато потом описание воспринимается на раз-два... ;)

 

а документация на проект тогда зачем? + пишите комментарии на заумные строчки

какая? диск с проектом/(файлом для конфигурирования) + инструкция по программированию ПЛИС?

Если не секрет расскажите более подробно про документирование проекта для ПЛИС - интересно.

[Des333 0]

полностью согласен.

Я например тоже графику лучше воспринимаю...

Из-за этого и трачу кучу времени - зато потом описание воспринимается на раз-два... ;)

 

 

какая? диск с проектом/(файлом для конфигурирования) + инструкция по программированию ПЛИС?

Если не секрет расскажите более подробно про документирование проекта для ПЛИС - интересно.

 

Графическая информация лучше воспринимается - это да.

 

Но почему это обязательно должна быть схематика?

 

Блок схемы, Data flow диаграммы и прочие подобные высокоуровневые описания вроде никто не отменял. :)

[Мур 1]

Графическая информация лучше воспринимается - это да.

 

Но почему это обязательно должна быть схематика?

 

Блок схемы, Data flow диаграммы и прочие подобные высокоуровневые описания вроде никто не отменял. :)

 

Речь идёт о встроенных средствах проектирования. Графика, блок схемы и ...потоки, как документ, рождается автоматически.

 

...Что делает посторонний человек, глядя на HDL-ТОРLevel?

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

[Des333 0]

...Что делает посторонний человек, глядя на HDL-ТОРLevel?

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

Так я вот к тому писал, что самый лучший, на мой взгляд, вариант - когда все описано на HDL и при этому есть дока, в которой модули и их взаимное соединения (+ куча дополнительный пояснений) уже изображены. :)

И тогда схематика не нужна в принципе.

 

 

Речь идёт о встроенных средствах проектирования. Графика, блок схемы и ...потоки, как документ, рождается автоматически.

Если мне дадут проект и скажут - "Из всего ПО для разработки и сопровождения использовтаь только Quartus" - то да, тогда, наверное, доку я буду рисовать в схематике.

[Maverick_ 15]

Графическая информация лучше воспринимается - это да.

 

Но почему это обязательно должна быть схематика?

 

Блок схемы, Data flow диаграммы и прочие подобные высокоуровневые описания вроде никто не отменял. :)

я просто хотел сказать что при документировании обязательно пользуюсь графическим описанием (State mashin и соединения блоков) + обязательно Testbench на все режимы работы :)

[Мур 1]

Так я вот к тому писал, что самый лучший, на мой взгляд, вариант - когда все описано на HDL и при этому есть дока, в которой модули и их взаимное соединения (+ куча дополнительный пояснений) уже изображены. :)

И тогда схематика не нужна в принципе.

Что в вашем понимании схематика?

Есть рьяные головы, считающие, что самодокументирование на HDL предел совершенства. Я вам скажу, что копаться в чужом проекте со скудным описанием (на словах)- муторное занятие. Что может быть приятнее видеть дубль проекта в графике от автора?

 

Если мне дадут проект и скажут - "Из всего ПО для разработки и сопровождения использовтаь только Quartus" - то да, тогда, наверное, доку я буду рисовать в схематике.

А если заставить себя не заниматься греховным делом? Визио, *.asf, ..потоки, кодер Matlab. Для удобства ли?

 

...Всё же интересно знать, чем объяснить категоричность поведения при создании проекта? К чему ограничивать себя в инструментах? Мода, опыт, целесообразность, ответственность в конце концов?

 

Вопрос всё-таки о популярности.

[sazh 3]

Что может быть приятнее видеть дубль проекта в графике от автора?

 

А наглядный пример привести можете?

[Мур 1]

А наглядный пример привести можете?

 

Пример одного и того-же в Топе...

obmen_ksumm.sch

crc32core.vhd

[Des333 0]

Что в вашем понимании схематика?

Есть рьяные головы, считающие, что самодокументирование на HDL предел совершенства. Я вам скажу, что копаться в чужом проекте со скудным описанием (на словах)- муторное занятие.

Мои слова "все описано на HDL" означали, что сам синтезируемый проект полностью описан на HDL, без использования схемного ввода, а никак не то, что "самодокументирование на HDL предел совершенства". :)

 

Что может быть приятнее видеть дубль проекта в графике от автора?

А если заставить себя не заниматься греховным делом? Визио, *.asf, ..потоки, кодер Matlab. Для удобства ли?

Графика - это хорошо, я согласен.

Но зачем ограничивать себя в инструменте? Схемный ввод ну никак не удобней, чем тот же Visio. :)

 

 

К чему ограничивать себя в инструментах? Мода, опыт, целесообразность, ответственность в конце концов?

Вот-вот, и я про тоже. :)

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

 

Использования синтезируемой конструкции как документации явно ограничивает свободы.

А что, мне захотелось оформить графику для модуля, который не top-level? Тоже переписать его на схематику? Очень странный вариант.

Или не использовать графику ни для каких модулей, кроме top-level'а? Тогда документация будет не самой хорошей, я полагаю. :)