[WARri0r 0]

ВАХ.

СЦ не двигается в сторону синтеза - факт, но ведь есть движение в сторону перехода СЦ/ВХДЛ - чем вам не синтез? Пусть и через ...

Да и на данном этапе не добиться приличных результатов при разработке SOC средствами высокоуровневых языков. А вот для моделирования/верификации - самое ТО.

В прошлый раз меня к албанскому языку отправили, а между тем вопрос и ныне у меня остался: Что же предпочтительнее для верификации компилируемых проектов/прошивок?

Моделсим вроде поддерживает моделирование СистемСи.

А работы выполняются в конторе на лицензионном менторе.

Вот я и пытаюсь узнать - что же лучше сейчас, и что будет предпочтительнее завтра/послезавтра?

[CaPpuCcino 0]

Что же предпочтительнее для верификации компилируемых проектов/прошивок?

Моделсим вроде поддерживает моделирование СистемСи.

А работы выполняются в конторе на лицензионном менторе.

Вот я и пытаюсь узнать - что же лучше сейчас, и что будет предпочтительнее завтра/послезавтра?

мне непонятно, что вы имеете ввиду под компилируемыми проектами. вы имели ввиду синтезируемые проекты?

если так то, очевидно на данный момент наиболее предпочтительным является работа в СВ. объяснюсь: де-факто СЦ не синтезируется => для синтеза приходится брать либо СВ, либо ВХДЛ; по верификационным возможностям СВ многократно превосходит ВХДЛ; использование единого языка более целесообразно, нежле 2 разных для синтеза и верификации, более того совмесная верификация 2ух языков СЦ + СВ/ВХДЛ, замедлит процесс симуляции (преимущества быстроты компилируемого в исполняемый код СЦ сразу же теряются при ко-верификации).

получается что СЦ отвели нишу высокоуровневого моделирования и всё (хотя его потенциал огромен)

[des00 25]

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

 

Я конечно понимаю что высокоуровневное программирование и все такое это крута. но ИМХО мне разработка синтезируемого кода на СЦ показалась не удобной.

 

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

 

Тут ИМХО как раз ХДЛ ная концепция объекта-модуля самое то, она обеспечивает достаточный уровень абстракции и приемлимый уровень прозрачности результирующего описания, да и технологии синтеза уже достаточно разработаны.

 

Хорошую концепцию реализации "синтеза" с СЦ предлагала компания mathstar. набор микропроцев (типа большой LC), щелкающих на 1ГГц, не зависящем от результатов синтеза/разводки. И работа на СЦ на уровне этих объектов. Вот возможно и есть дальнейшее развитие аппаратной платформы СЦ.

 

А вообще с появлением SeaFort24a, чипов от компании Ambric (о 256/512/1024 головах) цена реализации математики на фпга начинает блекнуть.

 

Насчет копи паста я уже сказал, видя простоту СВ DPI и СВХДЛ Direct-C, НЕТ СМЫСЛА его использовать. Там уровень применения тот же что и вызов С++ функций из языка С. Вот вам и возможности для со-верификации.

 

Как будет время я хочу сделать опенсорсик арифметико/логического блока для связки арм7 + спартан3е (дома появилась собственная плата) и обкатать технологию DPI в применении к этому проекту.

 

получается что СЦ отвели нишу высокоуровневого моделирования и всё (хотя его потенциал огромен)

 

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

 

Насчет потенциала : СЦ ИМХО переутяжелен наследием от С++ и смотря на своих коллег, разрабатывающих системы для фпга среднего объема на верилоге (например стм-1 мультиплексоры) и которые не понимают зачем я использую новые возможности СВ, т.к. по их мнению это дает меньшую прозрачность результата, я думаю что чистые языки верилог/вхдл будут жить еще долго.

 

Ибо не всем разработчикам это нужно (СЦ) . чистые языки проще и осваиваются за 1-2 дня. не все разработчики разрабатывают многомилионные фпга/азики.

[yes 8]

Я конечно понимаю что высокоуровневное программирование и все такое это крута. но ИМХО мне разработка синтезируемого кода на СЦ показалась не удобной.

 

----------

 

А вообще с появлением SeaFort24a, чипов от компании Ambric (о 256/512/1024 головах) цена реализации математики на фпга начинает блекнуть.

 

позволю себе не согласится :

 

рассматривая SC как "отдельный" язык для описания RTL - все замечательно выходит описывать (и букав поменьше, чем в аналогичном VHDL коде). при этом если кодировать методом : отдельно описываем логику (с помощью переменных, а не сигналов), а потом пишем регистр - все синтезируется. я потом увидел подобную технику описания на VHDL у Gaisler-а - очень удобно для всяческих сложных устройств - типа АЛУ и т.п. и FSM сложную можно напрямую из С кода взять...

там даже вылазит дополнительная моща за счет синтаксиса С++, сейчас уже не помню - но что-то типа тех же структур, енумов (сравнивал с Verilog-ом)

 

я посинтезировал (DC 2003, если не вру) какие-то самописные примерчики синопсисом - все замечательно было...

 

у них предлагалось два подхода к описанию - один RTL, другой - тул автоматом делает тактирование процесса, я про RTL пишу

 

-----------------

 

то есть никаких дополнительных сущностей не надо выдумывать :)

 

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

[cms 0]

Прочитал ветку, давно не видел таких содержательных дискуссий.

Позволю себе высказать свое ИМХО.

 

Интересно, почему таки разработка синтезируемого подмножества SystemC остановилась в 2006 году (SystemC Synthesizable Subset Draft.1.1.18, 2006-07-12)? Должна быть все-таки причина поправдоподобней всемирного заговора производителей софта. Среди основателей OSCI много силиконовых вендоров (ARM, Intel, NXP, NEC, ST) которые, если бы видели для себя серьезные премущества в прямом синтезе SystemC, без труда нагнули бы Cadence\Mentor и Synopsys на такой синтезатор. Значит либо таких преимуществ нет, либо есть принципиальные трудности получения из SystemC нет-листов. Пошуршу на выходных гуглом и почитаю архив OSCI форума. Может найду ответ.

 

А разработка железа в конце 2007 явно двинулась по пути SV: мало того, что сам по себе SV очень удобный язык, избавившийся от кучи рудиментов верилога, так Cadence с Mentorом в конце года выкатили библиотеку OVM (сильно напоминающую менторовскую AVM, которой теперь придали статус индустриального стандарта ) http://www.ovmworld.org . Ведь язык языком, а определяющим фактором удобства работы является наличие поддерживающих библиотек и инструментария.

 

Видно все-таки наэкспериментировавшись с SystemC народ пришел к выводу, что Цезарю - Цезарево, а Hardware-Hardwareво. Внешние преимущества единого синтаксиса оказались ИМХО недостаточными перед проблемой смешивания парадигм пространственного и временного подхода в одном инструменте. Разные это подходы, и лучше их разделять на уровне разных языков, чем на уровне подмножеств одного языка.

 

Одно беспорное преимущество SystemC (которое я успел прочуствовать) - это удобство работы в мощнейщем GUI VisualStudio, теоретическая возможность дебага штатными средствами и моделирование простым запуском exe-шника без всяких vsim. Просмотр VCD файлов это уже ерунда.

[CaPpuCcino 0]

Интересно, почему таки разработка синтезируемого подмножества SystemC остановилась в 2006 году (SystemC Synthesizable Subset Draft.1.1.18, 2006-07-12)? Должна быть все-таки причина поправдоподобней всемирного заговора производителей софта.

частное мнение в оправдание всемирного заговора:

если будет синтез СистемСи и разработчики устройств пересядут на него из-за выгод описаных выше, целые линии програмных продуктов разработки HW придётся закрыть, а это прошлые инвестиции в технологию от которых должен быть прогнозируемый выхлоп ("это - моя корова, и я её буду доить"). ну например: когда Синопсисы разрабатывали технологию Direct-C для их симуляторов они потратили кучу времени (около пяти лет её развивали) и соответственно средств (а "деньги должны делать деньги", иначе их нужно в кладывать в то что подчиняется этому закону - не зря же их менеджеры бегали месяцами убеждали в гениальности задумки и выкалачивали кредиты на венчурный проект /это художественный образ, как они бегали и у кого просили, я не знаю, но по своему опыту догадываюсь, что это было примерно так/), потом они эту технологию пожертвовали в СистемВерилог. спрашивается, почему? потому что они уже обладали этой технологией, но при этом не все производители HW пользовались симуляторами от Синопсис, а теперь она в стандарте СВ и им нужно минимум затрат для поддержки в своих симуляторах нового стандарта СВ с его встроенным Direct-C. при этом саму технологию можно и ещё кому-нибудь продать. (то же самое и с Vera и Superlog /забавная вещь: выход стандарта 1800-2005 опаздывал почти на год - потому как долгое время в комитете грызлись из-за того какой язык включать в качестве веричикационного в SV - "e" или "Vera", хотя они оба достойных кандидата, думаю столь жаркие дебаты носили не академический характер :) - в итоге Cadence со своим "е" обломался/). ну вот и представте теперь (возвращаясь к Директ-Си), что с приходом СистемСи надобность во всех этих технологиях отпала бы, потому что повился бы язык сквозного проектирования.

на счёт того, почему молчат Intel, NEC и т.д., моё мнение на уровне спекуляции, я об этом не думал, но вот к примеру PSL (он же Sugar) детище IBM (а его(ПСЛ) к тому же до кучи собираются вставлять в новый стандарт ВХДЛ)(((, Intel и NEC тоже крутились где-то около, если вспомню, как они на этом поприще отметились, обязательно докладу (пока можно пропустить мимо ушей))))

это конечно больше похоже на спекуляции, но я когда имел дело с СЦ и возлагал на него надежды никаких противопоказаний к синтезу не находил (совершенно)/были даже документы по типу дополнений к стандартам IEEE (Verilog RTL 2002), которые описывали рекомендации по РТЛ-стилю описания на СЦ, текста действительно немного больше чем для описания на Верилог, но ничего неразбирабельного синтезатором не было - обычные шаблонные конструкции(не имею ввиду шаблоны классов С++)/

[des00 25]

а тем временем тихой сапой :

 

http://www.bluespec.com/products/bsv.htm

 

 

 

пример кода : синтезируемый(!!!) бесплатный декодер h264.

 

http://csg.csail.mit.edu/oshd/index.html

 

 

Прочитав код по диагонали это что-то. Краткий как систем-верилог, функциональный как как си.

 

Тайный замысел врага ? :)

 

 

по описанию с сайта его хотят стандартизировать :

 

http://www.bluespec.com/partnerships/Standardization.htm

 

 

а вот и LRM

 

http://www.bluespec.com/forum/viewtopic.php?t=2

[CaPpuCcino 0]

(((, Intel и NEC тоже крутились где-то около, если вспомню, как они на этом поприще отметились, обязательно докладу (пока можно пропустить мимо ушей))))

да, вот вспомнил: Intel тоже отметился в сфере разработки языков верификации - у них был язык Forspec, а халлоу-Мото (в смысле моторола) двигала средство формальной верификации под названием CBV (cycle-based verilog)

 

а тем временем тихой сапой :

 

http://www.bluespec.com/products/bsv.htm

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

[cms 0]

Спасибо, des00, за напоминание о Bluespec. Они в свое время активно занимались синтезом SystemC (ESEComp synthesizes SystemC designs into highly efficient Verilog RTL.) и их трудно заподозрить в участии в заговоре против SystemC. Им, в отличие от Mentor/Cadence/Synopsys, терять было нечего и успех SystemC их как раз бы и позволил всплыть на поверхность, на что они похоже и расчитывали.

 

Но они все таки поняли, как я и предполагал, что синтезируемый SystemC никому из серьезных людей просто не нужен. Цитата из вашей ссылки на их передовой продукт, Bluespec SystemVerilog:

 

"• The goal is not to generate RTL from C – instead, the goal is to deliver design and verification productivity without the compromises of previous attempts"

 

Т.е. серьезный народ больше интересует качество кода и верификации, нежели получение из С-шного кода FPGA-прошивки нажатием одной кнопки. Потому как этот серьезный народ отлично понимает, что подход, который часто приходит в головы российских руководителей - типа "ну ты программку написал, давай теперь это быстренько в ПЛИС засунь" - в разработке реального продукта ни к чему хорошему не приведет. Если надо получить коммерческий продукт в гарантированные сроки и гарантированного качества, то програмки должен писать программист, а FPGA прошивки - FPGA проектировщик, а отряд тестеров должен сидеть рядом и стучать всем по головам. И у каждого из этих профессионалов должен быть свой инструмент, максимально заточеный именно под его задачу.

 

http://www.bluespec.com/technology/other.htm

 

По этой ссылке Bluespec прямо объясняет, почему по их мнению (а это ребята из MIT) SystemVerilog лучше SystemC, хотя "There are many attempts currently in progress both in research and commercially to develop a "higher-level language" for hardware design and modeling. Many of them are based on C/C++ or some other abstract language definition".

 

Эти причины:

 

1. Attempting to synthesize architecture from a high-level behavioral model is an intractable problem.

 

2. The concurrency models of RTL and SystemC require detailed, nitty-gritty management of shared resources

 

3. The execution model of traditional programming languages like C and C++ are very distant from hardware, making it harder to compile good hardware and making it harder for designers to retain their intuitions about the relationship between source code and good hardware.

 

Вобщем, синтезить С сложно, да и ненужно.

[des00 25]

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

 

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

 

Причем там есть и референсный Си код декодера. Видно что по сути Сишный проект, на структурном уровне переписан один в один. Т.е. отображение структуры декодера осталась то же.

 

В язык введены совершенно новые абстракции описания аппаратуры, самые важные их них ИМХО это синтезируемые методы интерфейсов и набор правил функционирования проекта. По сути код стал похож на обычный ООП код и без каких либо RTL ных заморочек на синтезируемость, синхронизацию процессов (в пределах модуля) и т.д. Даже КА и его действия описывается как программа (!!!)

 

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

 

2 cms

 

спасибо за поддержку.

[CaPpuCcino 0]

спасибо. будем посмотреть

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

ага, сразу туда и тыкнулся, но к сожалению у меня ошибку по ссылке выдаёт (сейчас обошёл через здесь http://csg.csail.mit.edu/oshd/)

самые важные их них ИМХО это синтезируемые методы интерфейсов

это и в обычном СВ было

[CaPpuCcino 0]

Прочитав код по диагонали это что-то. Краткий как систем-верилог, функциональный как как си.

...

а вот и LRM

 

http://www.bluespec.com/forum/viewtopic.php?t=2

мне понравились больше слайды их курса по BSV - на мой взгляд сам РЛМ слишком размазан, и поэтому трудно уловить всей прелести новшеств для SV, а полистав слайды я понял гораздо больше

http://www.bluespec.com/forum/viewtopic.php?t=7

[des00 25]

мне понравились больше слайды их курса по BSV - на мой взгляд сам РЛМ слишком размазан, и поэтому трудно уловить всей прелести новшеств для SV, а полистав слайды я понял гораздо больше

http://www.bluespec.com/forum/viewtopic.php?t=7

 

таки неспешно докурил доки, первоначальное мнение о языке только укрепилось %)

 

вот оно средство фпга для "чайников" %)

 

особенно понравились средства синтеза КА, наличие автоматических статических проверок при компиляции проекта, встроенные средства для описания переходов доменов.

 

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

 

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