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

Графическое представление мне нужно исключително для личного понимания - не могу удержать в голове слишком много информации. А схему переходов печатаю на бумаге - да хоть А1 формата, если она большая, и она всегда перед глазами. Зато ее графический вид я могу выполнить как мне угодно. Не знаю, как у Вас, а у меня основное время уходит не на рисование и не на набор текста, а на придумывание. Если схема выглядит некрасиво, "страдает мое эстетическое восприятие" (с) не помню, кто, кажется ReAl.

Что касается машины на 74 состояния, то графическое представление такого автомата для удобства и оперативности работы вряд ли лучше, чем case(State) ... Что касается запрещенных состояний, то для этого есть всякие default. Кроме того я для каждого состояния завожу именованную константу и присвоение состояния делается только этим. При уделения состояния в первую очередь удалается эта констатнта (компилятор сразу выдаст ошибку, если где-то будет ее использование), т.ч. это еще и в известной степени вопрос стиля.

Кстати, еще про 74 состояния. Количество состояний - не мера сложности. Это мера объема. А сложность - это не объем, а количество перекресных связей. И автомат на дюжину состояний но с морем связей между состояниями может оказаться куда сложнее, чем здоровенный автомат, но с простыми цепочными переходами. Кстати, большие КА, как правило, от того и большие, что в них много цепочных переходов... Ладно, это уже совсем в сторону...

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

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

Я имел ввиду, что текстовое описание сгенереное из графики будет стандартное. Связка генератор из графики -> синтезатор в пределе одно пакета, по логике, должна быть оптимизирована => синтезатору будет проще разложить сгенерированое текстовое описание в "стандартные" блоки.

А вот текст не всегда можно так идеально написать (идеально в смысле для конкретного синтезатора)

Теперь понятно. Хм, не знаю, не встречался с такой проблемой. КА всегда оформляю в виде case(...) ..., синтезатор (Синплифай) всегда обнаруживает в этом КА, о чем радостно сообщает, что, дескать, обнаружена FSM. Тем более, что я там еще обычно encoding задаю (чаще всего onehot). Не знаю, как надо написать, чтобы синтезатор это не распознал.

Я писал более обще по Идее:
В veriog можно так описать КА, что синтезатор, может, просто так, не развести на макс частоту/мин ресурсы.
А вот в описав в графике - скомпилированое текстовое описание будет всегда высококачественное для данного пакета (быть может при этом в графике в жертву качественности текстового описания урезаны "лишние" возможности Verilog'a, при сразу текстовом описании).

Согласитесь?
Ведь можно так описать в тексте КА, что, как Вы сказали, синтезатор его поймет, но вот у синтезатора не получется его качественно оптимизировать.

Ну, не знаю. Не сталкивался с трудностями. Смотрел, в частности, как генерит КА Альдек, примерно также. Несколько более многословно, но это нормально для машинносгенерированого текста. С имплементацией тоже все в порядке - с Синплифаем полное понимание. Во всяком случае трудности с времянками возникали совсем не здесь. Я даже запрещал ему FSM Explorer включать (достаточно было FSM Compiler'а), потому что тот занимался излишними оптимизациями, я потом испытывал дополнительные трудности при отладке (в SignalTap'е), когда искал триггеры, описывающие состояния. Да и откуда взяться траблам, когда мой текст по сути и смыслу мало отличается от сгененернного прогой?

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

[quote name='dxp' date='May 19 2006, 08:34' post='114684']
[quote name='CaPpuCcino' post='114542' date='May 18 2006, 21:49']
п 2: вы наверное пока не сталкивались, но на самом деле V2к1 поддерживается на уровне V95 плюс половина из того что есть в 2001 для синтеза. [/quote]
А что из синтезируемого подмножества V2001 Синплифай не поддерживает?

первое что приходит на ум - это ужасная поддержка generate - она здесь на самом базовом уровне, второе - поддержание иерархии проекта на уровне синтаксиса языка, третье кошмарная работа с параметрами функции, ещё можно добавить индексирование полей регистров по переменной вычисляемой на этапе компиляции- это только то что сразу пришло на ум, а если подумать то много ещё нюансов всплывёт
из СВ вообще поддерживается только новое связывание портов и уточнение always блоков - из того что действительно полезно не поддерживается ничего - даже такая простая вещь как перечисляемые типы удобные для state machines - которые поддерживаются тем же симплифаем в синтаксисе ВХДЛ

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

Вы вообще-то делали БОЛЬШИЕ проекты? Вы пробовали понять почему схематик почти вымер? В схематике сидит одно тупое старичьё с второстепенными проектами, у них всегда на готове обоснование почему надо сидеть в схематике третьего фоундейшена.
Когда я что-то проектирую, я придумываю КАК что-либо должно работать и пишу это на верилоге.
Если бы я сидел на схематике, тоя должен был бы: 1) придумать КАК должно работать нечто, 2) понимание КАК должно работать перевести в примитивы схематика, то есть сделать лишнее действие.

Речь вообще-то шла не о схематике, а о графическом представлении конечных автоматов.
Насчет схематики полностью согласен - геморрой с ней еще тот.

Большие это какие?
А что, синтезаторы все делают как надо?
Кстати писание на HDL, IMHO, тоже можно приравнять к переводу понимания "как должно работать" в примитивы.

А как иначе-то? Что написано, то и делают(работа у них такая).

Пример большого проекта - в одном кристаллле пара микроконтроллеров, развитый алгоритм управления, примерно 1Кслов команд. Управление на десяток ЦАПов, на АЦП, на полсотни реле и силовые ключи.
Примерно описан в статье "Микропроцессор своими руками - 3".
Кто хочет попробовать в "картинках" - напишите, когда нарисуете хотя бы четверть.

Объем чипа не всегда определяет сложность проекта. Можно сделать фильтр обалденной разрядности и порядка и забить им большой кристалл. А бывает что и не очень большой кристалл, но в проекте много логических связей и сложный алгоритм. Вот тогда и приходится все "крутить" по месту.
Так что для сравнения могу сказать, что либо микроконтроллеры, либо автомат на более чем 200 состояний. Вот как Вы это будете все рисовать в "картинках"?
А для текстового описания я сделал свой программный инструмент, который в вериложный файл вставлял куски кода в зависимости от того, что я запрограммировал для микроконтроллера. Например 1 кликом можно выбрать объем памяти команд. Ну и добавлял "прошивку" и дату версии. И это очень удобно.
А еще посмотрите мою статью "Между ISE и ViewDraw". Там тоже описан программный инструмент, которым из нет-листа я сразу генерил вериложный файл с пинами, портами, буферами и т.д.
Очень полезно, когда пинов 400 и более.
Удачи!