[9.9 0]

Доброго времени суток.

Какой из данных HDL (хотя они оба уже и не HDL по сути, а нечто гораздо большее :) ) наиболее перспективен в ближайшем будущем (3-5 лет)? Просто я наслышан и напробовался SystemC и честно сказать не увидел никаких серьезных преимуществ (кроме явного повышения скорости моделирования) перед SV.

 

В то же время все приблуды языка общего назначения (например, шаблоны или общеязыковая типизация) ИМХО делают ЛОГИЧЕСКИ сложную модель сложной еще и СЕМАНТИЧЕСКИ. Зачем оно надо?

 

Самым "крутым" аргументом SC считается интегрированность процесса функционального моделирования и RTL-моделирования тк код у нас получается единым.

Но опять же, все функциональные модели ИМХО обычно пишутся на C тк нам нужно проверить АЛГОРИТМ, а любой другой язык его усложнит семантикой. C легко переносится в любой Verilog (если это переносом можно назвать) => те же преимущества есть даже у Verilog 1.0 :)

 

Как говорится, я еще только учусь :), поэтому покритикуйте мысли пожалуйста. Чего я недопонимаю?

 

P.S. Я прекрасно понимаю, что специалист должен обладать знанием VHDL/SVerilog/SC/AHDL; но ведь все равно специализация строится на том, на чем ведется разработка по месту работы, а это во-многом зависит от "популярности" языка

[CaPpuCcino 0]

хотя они оба уже и не HDL по сути, а нечто гораздо большее

точно - принятая терминология для обозначения языков этого поколения HVDL (hardware verification and description language)

 

Какой из данных HDL наиболее перспективен в ближайшем будущем (3-5 лет)?

смотря для какой области применения: синтезаторы несколько лет назад практически полностью завернули СЦ (по каким соображениям вопрос достаточно неоднозначный и спорный-> распространяться здесь не буду, но каких-либо противопоказаний к синтезу у СЦ нет) и переключились всей гурьбой на СВ; относительно моделирования, однако, СЦ поднимается несколько выше по уровню абстракции нежели СВ и моделирование комплексных SW/HW систем можно производить оставаясь в едином языковом пространстве (что очевидно не так для СВ, хотя так же возможно)

 

Просто я наслышан и напробовался SystemC и честно сказать не увидел никаких серьезных преимуществ пулярности" языка

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

 

В то же время все приблуды языка общего назначения (например, шаблоны или общеязыковая типизация) ИМХО делают ЛОГИЧЕСКИ сложную модель сложной еще и СЕМАНТИЧЕСКИ. Зачем оно надо?

не согласен - дело привычки и вкуса(какая разница что писать wire[7:0], что sc_bv<8>). однако расширение уровня абстракции даёт, несомненно, большую свободу проектирования.

 

Самым "крутым" аргументом SC считается интегрированность процесса функционального моделирования и RTL-моделирования тк код у нас получается единым.

а это, на мой взгляд, и есть самое(!) важное и ценное(!) в концепции СЦ.

 

Но опять же, все функциональные модели ИМХО обычно пишутся на C тк нам нужно проверить АЛГОРИТМ, а любой другой язык его усложнит семантикой. C легко переносится в любой Verilog (если это переносом можно назвать) => те же преимущества есть даже у Verilog 1.0 :)

а толку то с описания функциональной модели на Си? нет конечно если ваша цель проверить работает ли в принципе алгоритм - то да. но какую полезную информацию даёт такое описание для представления насколько данный алгоритм хорошо ложится на систему с абсолютным параллелизмом. сколько мы выиграем если будем использовать программируемую логику вместо процессора регулярной архитектуры с последовательной интерпретацией комманд(игра с ПЛИС/ASIC вообще стоит свечь? может всё-таки стоит остаться на пентиуме - у него и тактовая побольше и задалбываться поменьше?) так вот чтобы получить достоверный ответ на эти вопросы вам приходится переходить на другой язык

так вот как раз в концепции СЦ перехода вообще не существует потому как СЦ это С++ расширенный понятиями параллелизма, модельного времени и структуры. и это даже не другой язык и вас никто не принуждает описывать алгоритм используя bit-accurate типы и миграция вашего чистого поведения описанного на алгоритмическом языке происходит прозрачно и в рамках единой модели (project refinement) иными словами любая часть вашего проекта может работать внутри общего проекта на любом уровне абстракции (чистый C++ - TLM - BFM - CBA - RTL) и этим вы сртахуететсь от ошибок и ложной интерпритации спецификации при переходе с одного уровня описания (behavioral в случае описания на Си) на другой (РТЛ для Верилога) - то есть вам в принципе не нужно работать "переводчиком"

 

P.S. Я прекрасно понимаю, что специалист должен обладать знанием VHDL/SVerilog/SC/AHDL; но ведь все равно специализация строится на том, на чем ведется разработка по месту работы, а это во-многом зависит от "популярности" языка

PS:хоть речь и получилась как-будто в защиту СЦ сам я сейчас намного больше использую СВ(и делаю ставку на него) - он полностью удовлетворяет мои потребности - уровня абстракции мне хватает. однако опять же всё зависит от поставленной задачи и в концепции СЦ есть бесспорные блага

[9.9 0]

CaPpuCcino

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

[des00 25]

.....

иными словами любая часть вашего проекта может работать внутри общего проекта на любом уровне абстракции (чистый C++ - TLM - BFM - CBA - RTL) и этим вы сртахуететсь от ошибок и ложной интерпритации спецификации при переходе с одного уровня описания (behavioral в случае описания на Си) на другой (РТЛ для Верилога) - то есть вам в принципе не нужно работать "переводчиком"

....

 

не сочтите чайником, может быть я что то не так понимаю :

 

С можно реализовать в VHDL, pVerilog, SV через VHPI, PLI, DPI функции, при этом насколько я понимаю просто и комфортно приделать к этим модулям любые интерфейсы для системной интеграции.

правда для этого придеться освоить эти расширения.

 

TLM, BFM, CBA, RTL тоже достаточно просто описываеться средствами VHDL, SV. (с pV чуть геморнее)

 

поэтому насколько я полагаю, это не являеться прерогативой только SC или я ошибаюсь ?

Заранее спасибо.

 

.... и честно сказать не увидел никаких серьезных преимуществ (кроме явного повышения скорости моделирования) перед SV. ...

 

ИМХО есть возможность поднять скорость моделирования в разы, только непонятно почему производители симуляторов на это не идут. Предистория такова:

 

Когда то на семинаре от аналоговых девиц расказывали про моделирование черных финов в ВижуалДсп и был там режим компиляции кода фина для платформы x86. Код симулировался на порядки быстрее (по словам представителя AD).

 

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

 

ЗЫ. до введения в CADы VHDL 2007, SV рулит, наконец то объединили лучшее из VHDL/pVerilog. могли правда кое что еще взять из VHDL, ну да ладно :)

ЗЗЫ. (не холивар!! )

[CaPpuCcino 0]

С можно реализовать в VHDL, pVerilog, SV через VHPI, PLI, DPI функции, при этом насколько я понимаю просто и комфортно приделать к этим модулям любые интерфейсы для системной интеграции.

правда для этого придеться освоить эти расширения.

 

TLM, BFM, CBA, RTL тоже достаточно просто описываеться средствами VHDL, SV. (с pV чуть геморнее)

 

поэтому насколько я полагаю, это не являеться прерогативой только SC или я ошибаюсь ?

дык, всё точно. одним единственным выдающимся достоинством СЦ является то, что подниматься на системный уровень и спускаться до РТЛ можно в рамках одного языка, а это очень-очень существенно (неспроста слили Верилог, ПСЛ и Веру в единый стандарт СВ)

ну, вот, давайте на примере - "что бы случилось, если бы производители сред разработки начали активно поддерживать СЦ на синтез":

это значит, что в разработку всего целого проекта (даже не включается, а) органично вливается программист.

почему? потому что действительно (очень часто) алгоритмы изначально описываются на Си или Си++, хотя бы потому что сначала хотят проверить эфективность и качество получаемых результатов самого алгоритма. это работа программиста.

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

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

Во втором случае вы просто распараллеливаете уже имеющийся у вас код надстройками СЦ, довешиваете предполагаемые задержки в потоках данных (латентности предполагаемых памятей, шин, интерфейсов) и получаете уже живую динамическую картину вашей системы (первое так сказать приближение от плоского мира Си программы к реальной 3D жизни). При этом вы так же остаётесь на уровне чистого поведения к которому "насмерть" привык ваш программист и поэтому совершенно спокойно продолжаете эксплуатировать его на этом этапе (он не в шоке от того что цикл - это вовсе не цикл как он привык, а макроподстановка - все счастливы).

В первом же случае вам приходится привлекать схематехника который знает один из ХДЛ и он как обезъяна переписывает код программиста на другом языке (здесь вот как раз и рвётся ниточка - это уже не мягкий refinement в рамках одной модели - это уже другая(!) модель. более того схемотехник не моделист и не верификатор он того и гляди наровит перейти на cycle-accurate модели - поведеньческий-то стиль описания ему малопонятен. он громоздит, путается и топчется на месте стараясь описать всё на РТЛ - потому как он живёт в мире РТЛ и не понимает как можно жить по-другому. Т.е. он как программист но только наизнанку. а вам это нужно (РТЛ этот), когда вы просто хотите получить общую(лёгкую) модель, хотите распланировать потоки, посмотреть на загруженность шин и т.п.?) этот перескок приводит ещё к одной серьёзной проблеме: неточная или неверная интерпретация спецификации. последствия и стоимость этих последствий по-моему ясны - это как результат деньги и время и отфутболивание от одного к другому (программист<->схемотехник). а в СЦ этот refinement происходит мягко и естественно (у вас одна часть проекта может работать ещё на чистом поведение а другая часть уже на RTL/прошу заметить я не говорю что это не возможно на HVDL, но главное что детализация проекта происходит в рамках единой(!) модели, единого(!) языка/)

ЗЫ:прошу заметить ещё одно - я в начале примера сказал "если бы", так вот этого "если бы" не произошло. из-за отсутствия нормальной поддержки синтеза этот скачёк с языка на язык приходилось делать на уровне РТЛ - поэтому я предпочитаю СВ (тоже мощная штука)

[des00 25]

дык, всё точно. одним единственным выдающимся достоинством СЦ является то, что подниматься на системный уровень и спускаться до РТЛ можно в рамках одного языка, а это очень-очень существенно (неспроста слили Верилог, ПСЛ и Веру в единый стандарт СВ)

ну, вот, давайте на примере - "что бы случилось, если бы производители сред разработки начали активно поддерживать СЦ на синтез":

это значит, что в разработку всего целого проекта (даже не включается, а) органично вливается программист.

почему? потому что действительно (очень часто) алгоритмы изначально описываются на Си или Си++, хотя бы потому что сначала хотят проверить эфективность и качество получаемых результатов самого алгоритма. это работа программиста.

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

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

Во втором случае вы просто распараллеливаете уже имеющийся у вас код надстройками СЦ, довешиваете предполагаемые задержки в потоках данных (латентности предполагаемых памятей, шин, интерфейсов) и получаете уже живую динамическую картину вашей системы (первое так сказать приближение от плоского мира Си программы к реальной 3D жизни). При этом вы так же остаётесь на уровне чистого поведения к которому "насмерть" привык ваш программист и поэтому совершенно спокойно продолжаете эксплуатировать его на этом этапе (он не в шоке от того что цикл - это вовсе не цикл как он привык, а макроподстановка - все счастливы).

В первом же случае вам приходится привлекать схематехника который знает один из ХДЛ и он как обезъяна переписывает код программиста на другом языке (здесь вот как раз и рвётся ниточка - это уже не мягкий refinement в рамках одной модели - это уже другая(!) модель. более того схемотехник не моделист и не верификатор он того и гляди наровит перейти на cycle-accurate модели - поведеньческий-то стиль описания ему малопонятен. он громоздит, путается и топчется на месте стараясь описать всё на РТЛ - потому как он живёт в мире РТЛ и не понимает как можно жить по-другому. Т.е. он как программист но только наизнанку. а вам это нужно (РТЛ этот), когда вы просто хотите получить общую(лёгкую) модель, хотите распланировать потоки, посмотреть на загруженность шин и т.п.?) этот перескок приводит ещё к одной серьёзной проблеме: неточная или неверная интерпретация спецификации. последствия и стоимость этих последствий по-моему ясны - это как результат деньги и время и отфутболивание от одного к другому (программист<->схемотехник). а в СЦ этот refinement происходит мягко и естественно (у вас одна часть проекта может работать ещё на чистом поведение а другая часть уже на RTL/прошу заметить я не говорю что это не возможно на HVDL, но главное что детализация проекта происходит в рамках единой(!) модели, единого(!) языка/)

ЗЫ:прошу заметить ещё одно - я в начале примера сказал "если бы", так вот этого "если бы" не произошло. из-за отсутствия нормальной поддержки синтеза этот скачёк с языка на язык приходилось делать на уровне РТЛ - поэтому я предпочитаю СВ (тоже мощная штука)

 

да это то как раз понятно, не понятно другое, а именно :

 

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

 

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

 

Да в SC для этого есть простые средства описания, но все равно программисту потребуеться вникать в особености архитектуры, а не свободно его использовать.

 

Не проще ли взять тогда программистов и хдлщиков, обучить их использовать на полную SV и писать полностью систему на нем. Уверен что многие при разработке проектов не пишут все на RTL, а заменяют часть модулей на behaviour модели и только потом подтаскивают под эти модели RTL имея готовую систему.

[CaPpuCcino 0]

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

 

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

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

для пояснения принципа действия транзакторов программистам я всегда привожу следующий пример: "вы же не думаете как действует функция memcopy(); которую вы всё время используете кодируя на Си - для вас она выполняется мгновенно - вызвали и продолжаете исполнение со следующей за ней строчкой. на самом же деле я вам открою страшную тайну: за вызовом этой функции может скрываться столько машинных тактов и шинных операций! представьте к примеру что на самом деле ваша программа работает на распределённой системе и память которую вы собираетесь копировать вообще находиться в Австралии и подглючена она по протоколу TCP/IP (здесь я конечно сильно утрирую) и доступ к ней физически может осуществляться секунды, но вам как программистам ведь это всё равно - вы всё равно видите вызов этой функции как атомарную мгновенную операцию - так и с транзакторами - пишите обычный код и забудьте о шинах и тактах относитесь к вызову функций транзактора так же как к мемкопи всё остальное за вас сделает транзактор"

PS: если всё-таки концепция транзакторов не очень понятна - могу выложить код какого-нить транзактора на СЦ или СВ и пояснить

[des00 25]

PS: если всё-таки концепция транзакторов не очень понятна - могу выложить код какого-нить транзактора на СЦ или СВ и пояснить

 

Спасибо за разьяснение.

 

Концепция транзакторов мне вроде бы понятна, мне не понятно вот что (не сочтите за ламера :) ).

 

Рассмотрим пример : 2 мастера + 1 расширеная память (SDRAM, SRAM, внутренняя память) и т.д.

для работы с ней на начальной стадии описываем SC каналы, в которых задаем параметры доступа.

наружу из мастера и слейва к памяти торчат только интерфейсы - описатели каналов.

 

Отладили поведенчиское поведение мастеров, арбитра. и теперь хотим натянуть реальные интерфейсы.

 

Насколько я понимаю тут потребуеться либо сделать проставку-преобразователь вида "SC канал -> шина", либо переделывать систему.

 

И как я понимаю если делаем проставку, то все равно получим какой то компонент, который потребуеться дополнительно тестировать и тратить на него время, а в итоге при синтезе еще и вырезать его.

 

Или есть какие то техники как на-лету и прозрачно заменить SC канал на какую нить шину не изменяя описания системы? Думаю что такая техника должна быть, достаточно переопределить канал и его методы на свой тип. Но ведь и его нужно будет отлаживать. Еще интересен вопрос как такая "самоделка" при синтезе будет перекладываться в железо?

 

Если такие техники есть и они работают, тогда да признаю что идея очень хорошая. Если же нет, то такой подход ИМХО 5 е колесо в телеге, т.к. все равно требуеться большая переделка и повторная отладка изначально спроектированной системы.

[CaPpuCcino 0]

(не сочтите за ламера :) ).

общаясь с вами достаточно давно, даже и не подумаю ;)

однако ближе к делу

Рассмотрим пример : 2 мастера + 1 расширеная память (SDRAM, SRAM, внутренняя память) и т.д.

для работы с ней на начальной стадии описываем SC каналы, в которых задаем параметры доступа.

наружу из мастера и слейва к памяти торчат только интерфейсы - описатели каналов.

NB: сразу хочу заметить что в СВ и СЦ терминология совершенно различна, так что простите, если буду немного путаться в терминологие, однако постараюсь того не делать (так например интерфейсы в СЦ это класс с набором виртуальных методов, а канал - это класс предоставляющий какие-либо интерфейсы, т.о. если протянуть канал в модуль через порт, канал будет предоставлять(экспортировать) в модуль набор методов (т.е. интерфейс канала); в СВ интерфейс это полноценный класс с методами(экспортируемыми в модули так же через порты) и членами класса т.е. сигналами\NBNB:интерфейсы не задействующие распределённых во времени методов - синтезируемы\).

т.о. интерфейсы, правильней сказать, торчат из каналов т.е. канал экспортирует набор каких-либо методов

Отладили поведенчиское поведение мастеров, арбитра. и теперь хотим натянуть реальные интерфейсы.

 

Насколько я понимаю тут потребуеться либо сделать проставку-преобразователь вида "SC канал -> шина", либо переделывать систему.

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

а зачем переделывать систему, я не понял (?) /вы имели ввиду перепроектировать так что если нас что-то не удовлетворяет в модели - это бы было усовершенствовано? огда подобное может случится и на этапе когда наша система ещё полностью описана на уровне ТЛМ без спуска на BFM&CBA/

И как я понимаю если делаем проставку, то все равно получим какой то компонент, который потребуеться дополнительно тестировать и тратить на него время, а в итоге при синтезе еще и вырезать его.

:) мдя...

действительно транзакторы не синтезируемы(в той стадии когда они ещё недетализированы и поистине ещё являются транзакторами), но дело в том что их никто и не предполагает синтезировать. это мост с одного уровня описания на другой. к примеру у вас есть уже готовый РТЛ контроллер вашей системной шины он соответственно функционирует на CBA уровне, на неё висят агенты часть из которых ещё не успели быть детализированы до РТЛ (не успели ещё разработчики)и работают они на чистом поведение, а часть(как например контроллеры каких-нибудь памятей) уже полностью готовы на синтез(РТЛ) , но засчёт этих самых транзакторов вы видите как будет ваша система работать в цифре, и агенты ваши поведеньческие совершенно спокойно общаются с системной шиной (которая уже в цифре) и с другими агентами, которые тоже уже в цифре. да там вообще такая свобода действий получается! транзактор это переходник - с одной стороны у него цифра с другой поведение когда вы делаете очередной шаг к синтезу вы просто дорабатываете тот конец где у него было поведение до цифры и получаете уже мост цифра-цифра. это на самом деле очень долгий разговор - книжку написать можно, но при построение системы методом top-down а для сложных проектов это единственный возможный подход. время затраченное написание и отладку таких переходников отнюдь не напрасное и выкидывать их отнюдь не придётся потому как может это не последняя ваша система где вы использовали именно эту шину и писали для неё переходник (более того эти транзакторы активно используются при верификации в тестбенчах - но это уже отдельная история)

Или есть какие то техники как на-лету и прозрачно заменить SC канал на какую нить шину не изменяя описания системы? Думаю что такая техника должна быть, достаточно переопределить канал и его методы на свой тип. Но ведь и его нужно будет отлаживать. Еще интересен вопрос как такая "самоделка" при синтезе будет перекладываться в железо?

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

Если такие техники есть и они работают, тогда да признаю что идея очень хорошая. Если же нет, то такой подход ИМХО 5 е колесо в телеге, т.к. все равно требуеться большая переделка и повторная отладка изначально спроектированной системы.

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

можем пофилософствовать, если хотите и какие-то из моих высказываний вызывают сомнения или несогласие?

[v_mirgorodsky 0]

Уважаемый CaPpuCcino,

 

А можно примеры реального инструментария, который все это "тянет"? А еще, какие бы книги вы бы посоветовали для начала?

 

Мы пишем для альтеровских FPGA, для RTL описаний используем VHDL, укладываем готовые устройства во вторые Cyclone. К счастью, наши проекты пока не такие огромные, что описанные вами методики становятся единственным возможным вариантом проектирования, но отголоски тех проблем я начинаю ощущать уже сейчас. Основной проблемой является попробовать нечто "а что будет, если..." На текущем этапе развития приходится городить сложную модель на C++, генерировать из нее даные, кормить ними синтезатор - короче, очень затратно и по времени и по ресурсам. Другой очень существенной проблемой является перевод модулей с одних принципов построения на другие. Просто очень сложно оценить быстродействие пути даных при вариациях функциональности отдельных модулей.

[CaPpuCcino 0]

А можно примеры реального инструментария, который все это "тянет"?

ну что значит "всё это" да ещё и "тянет" - чем выше уровень абстракции тем проще симулятору. я использую обычный МоделСим он поддерживает как СЦ так и СВ. другое дело синтез СВ. я синтезирую менторовским Пресиженом, а вот СЦ... с СЦ то как раз и возникла проблема - с СЦ все ведущие синтезёры переключились мгновенно на СВ как только стандарт появился - напоминает заговор, очень похоже что была какая-то заинтересованость завалить СЦ в пользу СВ. поэтому есть такая проблема нынче с СЦ - нехотят его синтезировать. агитировать вас дружно пересаживаться на СВ не буду. на ВХДЛ можно много чего изящно делать. будем надеятся что мега-консерваторы в комитете по ВХДЛ решатся всёже ввести в язык классы (нынешний protected тип у меня всё-таки классом назвать язык не поворачивается) тогда можно будет делать изящно ещё больше. однако пока нового стандарт нет. что вам делать покамест советовать не берусь. отсюда ответ и на второй вопрос:

А еще, какие бы книги вы бы посоветовали для начала?

в книгах по ВХДЛ особого акцента на абстрактность и системный уровень (т.е. как таковую методологию проектирования сверху-вниз и эволюции модели) я не видел - может не там смотрел. акцент на системный подход и его значимость начали делать именно с появлением СЦ поэтому в принципе книжки по этому языку и нужно смотреть(а за ним и СВ - эти языки собственно и создавались как результат осознания проблемы "Больших Систем"). литература многократно обсуждалась на форуме ищите. где книжки брать знаете. прочтите SystemC: from the ground up и SystemVerilog for design (chapter 10 A complete design modeling with SystemVerilog, chapter 11 Behavioral and Transaction Level Modeling) - думаю этого будет достаточно для понимания концепции. далее на выбор по вкусу - смотрите ветки обсуждения литературы. либо ждать нового стандарта и последующей реакции со стороны писателей. поступить с ВХДЛ также как с СЦ производители не решаться - слишком большой бэкграунд.

 

На текущем этапе развития приходится городить сложную модель на C++, генерировать из нее даные, кормить ними синтезатор - короче, очень затратно и по времени и по ресурсам.

а вы случайно не в Питере автоматизацией организации движения воздушного транспорта занимаетесь? рассказывали мне недавно о таком подходе(на сколько я сразумел) как скриптование ХДЛ проектов на Си++, но на словах представить процесс проектирования при данном подходе мне было трудно. очень интересно ознакомиться с данной методикой.

[v_mirgorodsky 0]

а вы случайно не в Питере автоматизацией организации движения воздушного транспорта занимаетесь? рассказывали мне недавно о таком подходе(на сколько я сразумел) как скриптование ХДЛ проектов на Си++, но на словах представить процесс проектирования при данном подходе мне было трудно. очень интересно ознакомиться с данной методикой.

Нет, у нас все попроще. У нас многоканальные системы сжатия изображений. Для облегчения процесса отладки мы подключили кодек на PCI в качестве таргета и кормим его некими исходными данными - благо есть софтовая реализация того же алгоритма на C++. Для отладки был написан некий специализированный драйвер, были выведены точки обмена информацией и несколько пользовательских функций, которые можно переопределять на этапе компиляции :) Если ошибка не находится сразу, приходится те же данные "гнать" через симулятор, что уже намного дольше и сложнее. Так мы и живем. Такой подход позволяет достаточно легко "ловить" ошибки реализации, однако целостной картины жизни пректа не дает.

 

Вот для этих целей я и пытаюсь найти платформу, которая позволит увидеть всю систему в целом.

[des00 25]

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

можем пофилософствовать, если хотите и какие-то из моих высказываний вызывают сомнения или несогласие?

 

Если вы не против чуть позже. Много работы навалилось + нужно покурить доки по TLM, а то мне кажеться что мы говорим о разных вещах :)

[CaPpuCcino 0]

Если вы не против чуть позже.

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

[9.9 0]

как скриптование ХДЛ проектов на Си++, но на словах представить процесс проектирования при данном подходе мне было трудно. очень интересно ознакомиться с данной методикой.

В перерыве разработал следующую мега концепцию :) (это в ожидании отпуска начало иногда находить). system-modelling производим на C++ с некоторыми алгоритмическими заглушками (если я правильно понял все вышесказанное - транзакторами). Тут ничего принципиального нет, но... что если потом все вызовы транзакторов подменять на код ГЕНЕРИРУЮЩИЙ HDL описание (т.е. фактически программа при моделировании будет генерировать себя на HDL) :)