[Nixon 3]

спор между SystemC, VHDL и, например, ручной трассировкой сводится к тому, что важнее - оптимальность полученного решения или усилия затраченные на разработку

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

(BTW: я ради эксперимента на нем какой-то автомат описал - но супер легкости и простоты не увидел)

Это с непривычки

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

Это уже меня страшит :) У нас целый отдел программеров (OS/2) пересадили на embedded. Вначале брыкались, теперь втянулись. Некоторые даже паять начали :) Нарушается чистота профессии :)

НО! даже в VHDL возникают непонятки - "я написал типа так, а синтезатор сгенерил совсем не так". в systemC их будет еще больше и еще одна сторона - эффективность, то есть VHDL (я уж не говорю про ручную трассировку :) ) по времянке и количеству "вентилей" всегда будет выигрывать у SysemC (лично я знаю про неудачное использование HendelC, который сильно ближе к железке, чем SystemC)

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

 

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

[yes 5]

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

 

а про неудобство SystemC - количество символов (ударов по кнопкам) нужное для описания какого-либо модуля.

хотя при лучшем (имхо) этом показателе у Verilog-a в последнее время пишу на VHDL

 

ну и еще надо учесть стоимость ошибки в софте и железе... если для FPGA они приблизительно равны (хотя можно вызвать конфликт и теоретически пожечь железо), то для АЗИКа проблема верификации - большая проблема. то есть необходимо иметь возможность backannotation - по виду схемы понять, что не так в описании - и чем сложнее тул синтеза, тем труднее это сделать

 

то есть - не думаю, что с SystemC можно будет забыть HDL и понимания схемотехники, не читать описание либы или доки на FPGA

 

вобщем что SystemC, что HDL - те же яйца - вид сбоку

[Oldring 0]

Похоже SystemC начинает понемногу теснить зубров (VHDL,Verilog)!

 

Не верю.

Интуиция.

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

[Cadence-free 0]

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

<{POST_SNAPBACK}>

 

ну вот это как раз и не верно. сложностей в отладке для больших проектов будет не больше чем при использовании verilog

[yes 5]

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

<{POST_SNAPBACK}>

 

это С++ темплэйты и классы

 

но с другой стороны - использовать, например, STL для железной разработки - сегодня некислый маразм, а потом может станет нормой :)