|
|
и может вспомнить, что в ВУЗе про диод рассказывали. Тогда они по-другому совсем воспринимают - и работу, и учебу.
Язык, в котором нельзя сделать неочевидных ошибок - это заведомо бесполезная вещь. Или, "выпендриваясь высоким штилем", "из теоремы Геделя о неполноте следует, что не существует даже эффективного способа задания аксиом арифметики". :)
Про сравнение разработки цифрового железа и программирования имею специфическое мнение - со временем грань между ними сотрется или сильно сузится.
Согласен, что "синтезаторам" в общем смысле (семантика и синтаксис языков описания алгоритмов работы + процесс перевода описания в кремний + проверка соответствия результата заданным ограничениям по времени и объему) еще расти и расти. То, чего Вы хотите, можно было бы ввести элементарно - просто программа-синтезатор будет сразу входную частоту умножать до максимально возможной, используя фронты и срезы, а потом делить для снижения энергопотребления там, где успевается. Вопрос, как это разработчику - сможет ли он работать, "забив" на реальные соотношения тактовой и внутренних сигналов в синтезируемом модуле, как он "привяжет" синтезированную хрень к остальной системе. Реально, скажем, даже простейшее, когда надо сделать синхронный многоразрядный счетчик на предельную частоту (e.g., 64-разрядный на 300МГц), лично мне поначалу как-то спокойнее вручную эту конвейеризацию выписать, чем проверять чей-то скрипт, который это делает. Но переходить на скрипт все равно надо - ибо это есть прогресс и развитие. И сам факт подобного перехода и будет означать, что разработчики в целом (и индустрия, в которой они работают) "доросли" до потребности в автоматизации, очередной "трюк" стал рутиной - и так вечно.
E-mail: 
info@telesys.ru
