[Edashkin 0]

А почему,собственно HDL - это только текстовый ввод? Есть инструменты, которые позволяют в графике вводить и автоматы и блок-схемы. Гораздо удобнее и нагляднее.

[Dron 0]

Похоже, что говорят об одном и том же, но с разной аргументацией. Какой подход к синтезу схемы? Для людей старой формации привычно оперировать вентилями, триггерами, мультиплексорами т.е. всем тем, что прочно встряло в голову при освоении ТТЛ и ЭСЛ логики. Поэтому и рисовать схемы тянет ;) А если еще была "послеперестроечная" дыра лет эдак в десять когда для прокорма была заброшена основная специяльность ? Какие такие верилоги - виэйчдиэли на СМ-ках или ЕС ЭВМ... Их никто и не нюхал :(

[LeonY 0]

Ну перенос на другое семейство - это только внешне простая задача, поскольку хочеш не хочеш, а при любом проектировании стараешся использовать все особенности того или другого семейства. Не говоря уже при переходе на другого производителя. Хотя согласен подправить - это не перерисовать

Ну сложность переноса зависит от нескольких факторов. Из собственного опыта могу утверждать следующее: при аккуратной разработке и при условии, что знаешь заранее о переносе, мне удавалось добиться программирования FLEX (Altera) и A1280 (Actel) без изменения ЕДИННОЙ строчки в проекте и все работало. Конечно нельзя пользоваться встроенными примитивами типа Алтеровских LPM, хитрыми архитектурами памяти (до некоторой степени) и т.д.

[LeonY 0]

А почему,собственно HDL - это только текстовый ввод? Есть инструменты, которые позволяют в графике вводить и автоматы и блок-схемы. Гораздо удобнее и нагляднее.

А вот тут я абсолютно согласен с автором: есть HDL Designer от Mentor-а, ActivеHDL от Aldec-а, да и Quartus, начиная с 4.0 кое-что в этом же направлении делает. Проблема с этими программами только одна - HDL Designer (особенно) и ActivеHDL сделаны так, чтобы с ними было работать как можно более сложно (как будто специально)

[Nixon 7]

Тоже согласен.

Но проблема не в сложности использования новых способов ввода проекта в указанных продуктах, а в том что правки ручками кода все равно не избежать - и вот тут появляется главная их проблема: слабая связь (точнее, кроме квартуса, совсем никакая) между графическим (и/или иным способом) способом ввода и реальным текстом программы, писаной ручками.

[LeonY 0]

Ага, как будто сопровождение сложного проекта сделанного на HDL не превращается в такой же геморрой при таких же условиях.

....

Все рассуждения на счет того что HDL программы легче документировать неуместны - есть куча ГОСТов ... которые отлично описывают процесс документирования для схемных проектов любой сложности.

....

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

Разбил цитату на 3 и постораюсь ответить (точнее высказать мнение) то всем трем пунктам.

- сопровождение сложного проекта сделанного на HDL превращается в геморрой, конечно же, нов гораздо меньший, чем схемное представление. Возьмите ка "схемку" конечного автомата состояний на 25-30 лет через 5 после того как к ней кто-то прикасался и измените пару-тройку условий переходов. ХИ-ХИ-ХИ

- ГОСТы, как впрочем, и любые другие стандарты (я с ГОСТами уже лет 15 дел не имею - живу в другом конце земного шарика) жизнь никогда и никому еще не облегчали. Практически, если надо делать проект на кристалле в 1,000,000 или более гейтов, то к нему с традиционными схемами лучше и не подходить. А я уж и не говорю о верификации для ASICs или OTP FPGAs

- "переучивать" или "доучивать" - это вопрос терминологии, но при этом нужно четко отдавать себе отчет в том, что, начиная с определенного уровня сложности, требований верификации, переноса проекта, его сопровождения и т.д. и т.п., делать его полность на традиционной схемной основе ПРОСТО НЕВОЗМОЖНО

[Edashkin 0]

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

Дело привычки. Но я ни разу не сталкивался с ситуацией, когда в Менторе надо было править код ручками, да он и не позволяет. В крайнем случае вставляется текстовый блок и в нём пишется HDL-код.

[Nixon 7]

Возьмите ка "схемку" конечного автомата состояний на 25-30 лет через 5 после того как к ней кто-то прикасался и измените пару-тройку условий переходов.

Я еще раз хочу акцентировать Ваше внимание на то, что все зависит от уровня документирования "схемки". Конечно если я найду голую кальку, то по ней вообще невозможно ничего сделать. Но если есть описание работы схемы схемы (вещь как Вам известно совершенно необходимая для документирования) то дальнейшая модификация возможна. Преимущество текстового (программного) ввода в том, что программа, в некотором роде, самодокументируется (конечно при условии "говорящих" переменных, функций, блоков и т.д.).

ГОСТы, как впрочем, и любые другие стандарты жизнь никогда и никому еще не облегчали.

Здесь позвольте не согласиться - слишком уж категоричное утверждение.

ГОСТы (стандарты) как раз (в нашем случае) и создавались для облегчения и унификации процесса создания и документирования продукта. Во всем должен быть порядоки структура. Просто сейчас на них все (за исключением вояк) забили и уже начинают расхлебывать эту ситуацию. Мне, в свое время, мой первый шеф буквально вдолбил к ним уважение и я сейчас нисколько не считаю это лишним.

Практически, если надо делать проект на кристалле в 1,000,000 или более гейтов, то к нему с традиционными схемами лучше и не подходить.

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

 

Не посчитайте меня ретроградом - я сам схемы рисую сейчас только для аналоговых и силовых вещей. Пока...:)

 

Кстати как там погодка у Вас на другом конце шарика - у нас в Киеве - мрак.

[admin 2]

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

Вспоминается фильм "Послезавтра" ...

[LeonY 0]

Кстати как там погодка у Вас на другом конце шарика - у нас в Киеве - мрак.

Зима и холод собачий

[Wukrly 0]

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

Например:

1) Всем понятно, что комбинационную схему значительно легче описать в текстовом виде, оформив ее в виде отдельного файла. При этом может быть использована любая форма (условная, табличная или формульная). Затем оформить этот кусок в виде элемента и вставить в графический файл. Чем разрисовывать этот кусок на логических элементах в графике.

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

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

Попробуйте нарисовать комбинационную схему, например для синусного генератора на 32 - 128 точек. Я думаю, этого никто не делает в графическом виде. Результирующая комбинационная схема получается несложной и минимизируется пакетом элементарно.

Даже если Вы нарисовали схему в графическом виде, она будет реализована внутри кристалла совсем в дркгом виде, чем так, как Вы хотели. Поэтому "гонки комбинационных схем" в ПЛИС устраняют другими методами.

2) Цифровой автомат в текстовом виде - это таблица. Достаточно быстро составляется, легко меняется, в том числе и кодировка. Рекомендуется для выходов МИЛИ не дополнять таблицу переходов колонками, как рекомендуется в литературе, а описывать эти выходы отдельными формулами в том же файле. Результат проектирования одинаков, а таблица переходов получается проще и нагляднее.

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

[Hadgehog 0]

из собствнного опыта плавный переход от графики к тексту:

 

1. Начал осваивать альтеру-в MAXPLUS 9.3 WEB проект простой на МАХ 7128s, всё в графике, только научился проекты создавать. Через два месяца просьба изменить проект, ужас, общие принципы понятны, тонкостей не помню - вывод необходимо грамотно документировать проект, для графики дополнительный носитель информации - файл, необходимость связать разные версии описаний и схемы.

2. Пара подобных проектов в графике + увеличение емкости ПЛИС, переход на FPGA, усложнение проектов потребовало перехода к формальному описанию отделььных модулей, началось освоение AHDL.

3. Усложнение проектов на ПЛИС + ещё большее увеличение емкости кристала, проект разбивается на несколько кусков для совместной параллельной разработки. Тут всё упирается в тестирование отдельных кусков и их взаимодействия, куча проблем по трасировки на кристале временных задержек и.т.д. Главная проблема формализация задания между отдельными людьми -решаема, наверное самое лучшее графическое представление в виде крупных блоков-черных ящиков. Проблема в различном подходе описания разными людьми своих кусков кристала-один графику тянет, другой AHDL, третий осваивает VHDL, собрать и отладить нормально полноценный проект очень сложно.

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

в пользу VHDL - запарились в рукопашную на AHDL уговаривать фитер разводить стабильно, проект почти не меняется (вводится допустим инвертор), а проект вобще не работает, возвращаеш как было, всё равно не работает (шаманство). При заполнении ПЛИС на 70-80% очень нестабильные результаты на смешаных проектах.

в пользу VHDL - после освоения труднее сделать "глупую ошибку"

[tims 0]

Пожалуй да - для небольших кусков схематика хороша.

Для сложных проектов - иерерхическое построение с комбинацией схематики и кода.Но все-же наглядность больше у схематики.Это мое мнение.Я в проектах комбинирую то и другое.Что-то лучше рисовать схемно,что-то на языке.Если нужна переносимость - язык лучше конечно, но гимморой будет все равно.