Отправлено jm 15 июля 2003 г. 15:52 В ответ на: Ж))) Программный код - он по сути своей последователен, и воспиринимается как последовательность строк, а не пространственная структура! отправлено cms 15 июля 2003 г. 15:11

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

(пардон - пробило на банальности)

• не скрою, в VHDL я не гуру, но все же с утверждением что оператор process ... end является последовательным, я не соглашусь — cms   (15.07.2003 16:15, 97 байт)
  • А внутри процесса операторы выполняются последоватьно. Слово sequentional относилось (как мне кажется) имеено к операторам внутри процесса — Pashka   (15.07.2003 16:26, пустое)
    • Да, внутри процесса последовательные операторы выполняются последовательно. Но называть ключевой механизм распараллеливания (оператор process) последовательным на мой взгляд не верно. — cms   (15.07.2003 16:37, 199 байт)
      • Ответ: типа yes yes yes - на слове меня поймали. если есть желание рубиться дальше - вернемся к теме. не будем же мы в самом деле сейчас обсуждать термин "оператор", подкоторым понимается нечто совсем иное? — jm   (15.07.2003 17:08, 657 байт)
    • Ответ: вы правы. пардон - неточно выразился — jm   (15.07.2003 16:36, пустое)
      • Ответ: имелся в виду тип abstruction/environment, который эта структура ограничивает, а не сам "оператор" в целом — jm   (15.07.2003 16:45, пустое)
• Ответ: — SAZH   (15.07.2003 16:00, 126 байт)
  • Ответ: шуер. ай дид. к сожалению, знакомиться с ней пришлось самостоятельно - только через 3 года после выпуска. в смысле сейчас это в программе. — jm   (15.07.2003 16:29, 903 байт)
    • Ответ: — SAZH   (15.07.2003 16:47, 742 байт)
      • Ответ: тоже согласен. — jm   (15.07.2003 17:58, 1362 байт)
        • Ответ: — SAZH   (15.07.2003 18:20, 563 байт)
      • Полностью согласен. Если цель - не освоение абстрактной методики, а получение результата, то тогда работа на уровне библиотек Альтеры + Quartus + MSim для более-менее удобного моделирования. — cms   (15.07.2003 17:05, 430 байт)
        • Ответ:несогласен. могу опирировать только личным опытом - инстантиированы в проекте не более 5% логики - только та, что хардварно выполнена (blockram/eab) или случаи типа генерации шифтеров на одном lut. посему степень технологической развязанности достигает 90-95%. а несли вы идеал искали - так это не насем свете смотреть надо. — jm   (15.07.2003 17:20, пустое)
        • Еще раз повторяю: AHDL может хоть 10 раз быть аккуратным, но это язык одной конторы. Кроме нее и тех, кто пользуется ее продуктами, он никомк не нужен. Велосипедоизобретатели, блин... — andrew_b   (15.07.2003 17:14, пустое)
          • Ответ: — SAZH   (15.07.2003 17:35, 268 байт)
            • умирает тихо тихо — KA   (15.07.2003 18:29, пустое)
              • Ну и б-г сним. Есть же стандарты де-факто и де-юре. — andrew_b   (16.07.2003 09:02, пустое)