[andrew_b 17]

Скрипты это хорошо, но при работе хочется иметь среду, работающую по принципу "все включено" :)

Эта среда -- операционная система.

[Builder 1]

Привязывание процесса разработки к конкретному GUI плюс использование рисовалок, имхо, ужас. Интересно, что многие уходят от этого, а многие, как мы видим, приходят :07:

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

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

Гораздо легче въезжать в проект, если понадобится доработка через пол года, сразу видно что куда.

А то конечно, можно понарисовывать что потом сам не разберёшься куда какая связь идёт, и через пору дней забудешь что там и где.

Просто подходить к графике нужно осторожно, без маразма.

[Vadim 0]

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

При чем здесь файл описания?

Читаем :

Основная цель - использование его (Active HDL) возможностей для создания центральной библиотеки готовых узлов, куда их могут размещать разработчики, для того, чтобы дргуие разработчики могли ими пользоваться.

Ну прям как в PCB :) Это и есть привязка. Причем именно жесткая :)

Просто подходить к графике нужно осторожно, без маразма.

А лучше вообще не подходить :)

[kuzis 0]

А лучше вообще не подходить :)

 

Это уже мы проходили. Я вот как говорю своим приверженцам VHDL описаний: "Вы руководству функциональную схему отдайе на проверку в виде структурного описания на VHDL, и посмотрите, что вам скажут"

 

ИМХО, фукнциональные узлы лучше соединять на схеме. Для этого она и придумана. А иначе мы и электрическую схему устройства скоро начнем в текстовом виде описывать.

 

Ну прям как в PCB :) Это и есть привязка. Причем именно жесткая :)

 

Ну в общем-то да, и когда наработок будет много, отвязаться уже будет сложно. Поэтому и нужно серьезно относиться к вопросу о том, на что завязываться.

[Builder 1]

При чем здесь файл описания?

Читаем :

Ну прям как в PCB :) Это и есть привязка. Причем именно жесткая :)

Совсем не как в PCB, не путайте. Какая-такая привязка?

Библиотека в ActiveHDL - не более чем скомпиленные модули xHDL, объединённые в одну логическую единицу (библиотеку).

В чём проблема перекомпилять эти исходнико под другой средой?

 

Всё сделано правильно, если коллектив работает преимущественно в одной среде разработки - должны существовать правила организации результата работы, как вариант - библиотеки.

Можно конечно и просто исходниками, но библиотеки нисколько не ограничевают перенос самих сходников в другие среды.

Захотят перелезть на другую среду - просто перекомпилируют исходники в другой среде.

Проблемы если и возникнут, то не с самими библиотеками, а с исходниками.

Или я что-то не понимаю?

[Vadim 0]

А иначе мы и электрическую схему устройства скоро начнем в текстовом виде описывать.

:a14: С удовольствием!!! Стандарт только нужен :)

 

Я вот как говорю своим приверженцам VHDL описаний: "Вы руководству функциональную схему отдайе на проверку в виде структурного описания на VHDL, и посмотрите, что вам скажут"

Руководству? Функциональную схему? Зачем она ему? На проверку??? Обалдеть :07: И что оно скажет после проверки? Никогда таким образом над руководством не издевался, потому и спрашиваю...

[kuzis 0]

:a14: С удовольствием!!! Стандарт только нужен :)

Руководству? Функциональную схему? Зачем она ему? На проверку??? Обалдеть :07: И что оно скажет после проверки?

Очень многое может сказать. Поскольку наше руководство занимает должность главного конструктора, и определяет идеологию наших устройств...

 

И умудряется найти ошибки, сделанные разрабочтиком... Идеологические, системные.

 

А еще у нас руководство и электрические схемы проверяет, и печатные платы после трассировки :) .

И польза между прочим от этого есть, и существенная.

[des00 25]

я сейчас работаю так : SlickEdit + QuestaSim + Quartus. Все пакетные задания идут скриптами.

на проект ТЗ, функциональная схема в визио(с привязкой имен к rtl модулям), техническая документация. Все это в SVN + Trac, изменения в проекте обязательно сопровождаются изменением в документации.

 

В графике работать не умел, не умею и наверное не буду уметь. Мне редактор с тегами милее

[Vadim 0]

Неслабое у Вас руководство, Михаил :07: Проверяет все. А, например, за функционирование проверенной им платы, собранной по проверенной им схеме оно отвечает?

[kuzis 0]

Неслабое у Вас руководство, Михаил :07: Проверяет все. А, например, за функционирование проверенной им платы, собранной по проверенной им схеме оно отвечает?

 

Ессно. Оно же и деньги платит на его изготовление. Из своего кармана (фирма-то у нас коммерческая). Учитывая что средняя стоимость одной нашей платы составляет несколько штук зеленых рублей.... Руководство пытается построить работу так, чтобы не приходилось перевыпускать платы.

 

Конечно, если находится бага, то разработчика не забудут носом ткнуть. За исключением тех случаев, когда какое-либо решение принимается вопреки мнению разработчика. :)

[Vadim 0]

Ессно.

Ха! Теперь все стало на свои места. И с исходниками, и со схемами :) Руководство у Вас - это разработчик. А те, которые ему схемы и платы на проверку несут - это его помощники. Путаница в терминах :) Схема удобнее для восприятия, вот он и ее и требует. Не будет же он в чужих исходниках разбираться.

[kuzis 0]

Схема удобнее для восприятия.

 

Золотые слова. :)

 

А руководство все-таки не разработчик. Оно им раньше было :)

[sazh 8]

Золотые слова. :)

 

А руководство все-таки не разработчик. Оно им раньше было :)

 

Руководство сидит в ActiveHDL. Библиотеки правит. И в нем подписи ставит.

А был бы в молодости программистом, так и тех бы достал.

Это я к тому, что ничего ведь придумывать не надо. Есть комплект документов.

Вплоть до функциональной схемы, структурной. На этом уровне все видно.

Зачем глубже главному то лезть.

Вот кстати пример подхода. Верхний уровень тоже в тексте (компоненты), да еще и с пинами под конкретный кристалл

-- Attributes declarations --

 

attribute altera_chip_pin_lc : string;

attribute altera_chip_pin_lc of CLK_40M : signal is "@79";

attribute altera_chip_pin_lc of CLK_PLD : signal is "@183";

Вполне наглядно.

[andriyg 0]

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

 

http://electronix.ru/forum/index.php?showforum=116

[kuzis 0]

Руководство сидит в ActiveHDL. Библиотеки правит. И в нем подписи ставит.

А был бы в молодости программистом, так и тех бы достал.

Это я к тому, что ничего ведь придумывать не надо. Есть комплект документов.

Вплоть до функциональной схемы, структурной. На этом уровне все видно.

Зачем глубже главному то лезть.

 

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

А вот на печатной плате исправлять очень и очень сложно. Особенно когда в ней 12 - 16 слоев. Можете мне поверить.

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

 

:a14: С удовольствием!!! Стандарт только нужен :)

 

А это вы не подумавши сказали.

Когда у вас в схеме будет полтыщи конденсаторов, пару сотен резисторов, и тысячи три-четыре выводов микросхем, я бы посмотрел на вас, как вы будете такую схему заводить, а потом проверять.

 

У нас тут библиотекари решили трансформаторы, которые нам на E1, E2, E3 стыки ставяться, прямоугольниками обозначать. Мол. вам не все равно. А нам удобно. Микросхема как микросхема. Ножки пронумерованы. Мне пришлось поднимать бучу и доводить до руководства, чтобы заставить их нормально трансформаторы рисовать.