[SM 0]

Кто что думает про http://www.forteds.com/products/cynthesizer.asp ? Что-то понаписано больно уж все красиво для современных версий... Reduced silicon area and power consumption... Относительно чего reduced?

 

А если еще вспомнить о выходе css_vC-2009.03, это что - про SC и синопсис вдруг вспомнил?

 

Я, собственно, к чему... Вроде все с год назад решили, что софтомонстры забили на SC в пользу SV. А оказывается не забили что-ли? И он в их подполье продолжает развитие?

[des00 25]

Кто что думает про http://www.forteds.com/products/cynthesizer.asp ? Что-то понаписано больно уж все красиво для современных версий... Reduced silicon area and power consumption... Относительно чего reduced?

 

А если еще вспомнить о выходе css_vC-2009.03, это что - про SC и синопсис вдруг вспомнил?

 

Я, собственно, к чему... Вроде все с год назад решили, что софтомонстры забили на SC в пользу SV. А оказывается не забили что-ли? И он в их подполье продолжает развитие?

 

пошарился тут http://www.forteds.com/products/papers.asp

 

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

[al1 0]

Там написано что это "first high-level design solution".

А разве первым не Catapult был? (он, правда, раньше по другому назывался)

 

Поскольку про катапульт децл знаю, то расскажу про него, а у форте идея должна быть аналогичная (за исключением того, что в форте написано что он с SystemC работает, а катапульт с чистым, не тактированным C/C++).

 

Идея такая: вы хотите в ваш IC встроить некий алгоритм (например шифрования) который уже давным давно отработан, но существует только в в виде C/C++. Вот вы и выбираете один из двух путей: либо 1) тратить время на написание HDL вручную, либо 2) нажал на кнопку - получил hdl.

 

Проверено на личном опыте (проверял в катапульте, но форте должен быть аналогичен):

минусы автоматической кодировки по сравнению с ручной

- больше затрачивает оборудования

- меньше частота получается

Плюсы:

- сам процесс синтеза занимает максимум несколько часов (мой опыт вообще показывал секнды), вместо недель вручную

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

 

Так что нужно вам это или нет можно решить только интуитивным путём: с одной стороны скорость и качество, с другой - затраты на доп. оборудование в IC и цена.

 

Не претендую на истину, если где не прав - поправьте.

 

 

P.S.

А "про SC и синопсис вдруг вспомнил?" это чтобы не отставать от ментора :)

 

 

Я, собственно, к чему... Вроде все с год назад решили, что софтомонстры забили на SC в пользу SV. А оказывается не забили что-ли? И он в их подполье продолжает развитие?

 

Не забили. Не смотря на то, что идеология схожая (классы) это немного разные задачи.

- В SV много инструментов для анализа непосредственно самого DUT (design under test), такие как ассерты и те же классы,

- а на SystemC удобнее часть окружения вокруг DUT строить.

 

Имхо, SystemC должен быстрее SV моделироваться, я лично пока не проверятл. Если кто занет расскажите.

 

Например:

вы проектируете некий блок1 который взаимодействует с другим блоком2. Всё делаете с нуля, например.

Для отработки взаимодействия целостной системы можно "накидать" два блока на SystemC, затем блок1 довести до RTL, и сравнить поведение RTL и "эталонным" SysmemC. Т.е. когда вы дошли до RTL вам не надо заново разрабатывать тесты.

 

А вот, сам блок сравнения эталонного SystemC с RTL, возможно, удобнее будет написать на SV, т.к. существуют всякие методологии типа OVM, AVM и т.д. в которых на SV уже создано большое количество "заготовок" для разных задач, например, для задачи сравнения результатов моделирования.

 

 

P.P.S.

Кстати, вот, про OVM тут можно почитать:

http://www.ovmworld.org/

[SM 0]

А разве первым не Catapult был? (он, правда, раньше по другому назывался)

Ну тут я не судья, кто первый, кто второй. Наверное эти в чем-то первые.

Идея такая: вы хотите в ваш IC встроить некий алгоритм (например шифрования) который уже давным давно отработан, но существует только в в виде C/C++. Вот вы и выбираете один из двух путей: либо 1) тратить время на написание HDL вручную, либо 2) нажал на кнопку - получил hdl.

Ну форте это немного другое. Все таки ESL на SC + TLM это != алгоритм на C++

Мне странно, что у них там reduced area/power. относительно чего редуцед? относительно того, как бы я вручную RTL сделал? не верю!

Кстати, вот, про OVM тут можно почитать:

http://www.ovmworld.org/

Ну это не надо, это я в курсе, мне если уж юзать, так VMM. Только вот я так понял, что TLM в SC это и есть примерный эквивалент VMM в SV.

 

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

[al1 0]

Ну форте это немного другое. Все таки ESL на SC + TLM это != алгоритм на C++

 

Не понял, почему "немного другое". Всегда можно построить окружение на SC + TLM (или без TLM), а имеющийся алгоритм просто вставить внутрь некоего модуля. Делов-то! Но это я не спорю, просто к слову.

 

Мне странно, что у них там reduced area/power. относительно чего редуцед? относительно того, как бы я вручную RTL сделал? не верю!

 

Ну под power под подразумевается вот что: при помощи TLM можно вылизать взаимоотношения между блоками до такого уровня, что каждый блок будет выполнять действия только!!!! тогда, когда он должен!!! это делать. А когда блок не нужен, он не будет производить бесполезной работы, а как известно основное потребление тока идёт именно при переключении транзисторов. Есть даже специальные софтины (по крайней мере у ментора (ну извините что знаю о том пою)) которые показывают график активности, например, шины.

 

А area х.м. ну, типа, скорее всего имеется в виду вот что: когда вы переделываете алгоритм (ну как ни крути, а внутри SC модуля всё равно алогритм запрятан) в RTL код, сколько вариантов переделки вы пробуете? Один? Ну если алгоритм совсем простой - пару тройку. А автоматический синтез возволяет перепробывать пару десятков!!! варинтов, выбрав лучший. Например в катапульте (не бейте сильно) резутьстаты экспериментов прям в табличку сводятся. Там разные характеристики, например, латентность...

 

Ну это не надо, это я в курсе, мне если уж юзать, так VMM. Только вот я так понял, что TLM в SC это и есть примерный эквивалент VMM в SV.

 

С VMM дело тёмное. Предположительно VMM это эквивалент AVM. А AVM - это я уже знаю - пересекается с OVM. Т.е. одни и теже задачи решаются как в avm так и в OVM.

Если не ошибаюсь

OVM - написан только на SV,

avm - оба, и SC и SV,

vmm - ???

 

Так, вот, пока непонятно как выбирать между avm/vmm и ovm?

 

Где-то видел фразу что ovm это развитие (точнее не развитие, а следующий шаг после) avm, ибо avm - это mentor, а ovm - это консорциум - на http://www.ovmworld.org/ упоминаются cadance и mentor.

Ну и, вот, непонятно, vmm, по аналогии с avm это конечная точка или промежуточный этап?

Я бы не рискнул завязываться на "закрытую" (в смысле от одной фирмы) методологию vmm при условии что есть "межкорпоративная" ovm. Тем более что вы упомянули что vmm написан на sv - также как и ovm.

 

Какие соображения по вышесказанному?

 

P.S.

Еще про OVM забыл сказать что раз это "открытая" методология, то под нее много информации сейчас появляется: статьи, примеры и т.д. Т.е. освоить попроще будет чем avm/vmm.

ИМХО.

Изменено 2 июня, 2009 пользователем al1

[SM 0]

OVM - написан только на SV,

avm - оба, и SC и SV,

vmm - ??.

 

Так, вот, пока непонятно как выбирать между avm/vmm и ovm?

 

VMM - SV

 

Крайне просто. Какой тулчейн, такой и *VM. В сигноффе Cadence NC-SIM => OVM. В сигноффе Synopsys VCS => VMM. Первое несовместимо со вторым (либа с симулятором) и наоборот. Но это не суть, VMM (http://www.vmmcentral.org/) примерный эквивалент OVM, на сколько я понимаю. А куда деть AVM - не знаю.

 

ЗЫ. Это уже мимо темы... Я больше про перспективы опять вылезшего SC

 

Не понял, почему "немного другое". Всегда можно построить окружение на SC + TLM (или без TLM),

ИМХО часть фишки в единой TLM (на SC) от начала и до конца (до гейт-левела).

[al1 0]

VMM - SV

 

Крайне просто. Какой тулчейн, такой и *VM. В сигноффе Cadence NC-SIM => OVM. В сигноффе Synopsys VCS => VMM. Первое несовместимо со вторым (либа с симулятором) и наоборот. Но это не суть, VMM (http://www.vmmcentral.org/) примерный эквивалент OVM, на сколько я понимаю. А куда деть AVM - не знаю.

 

AVM встроен в Questa, также как и OVL и OVM и TLM (как на SC, так и на SV) и полная поддержка SV и много чего ещё.

Поэтому если у вас NC-SIM или VCS - то да, просто, а у пользователей Квесты есть повод для размышлений.

 

ЗЫ. Это уже мимо темы... Я больше про перспективы опять вылезшего SC

 

 

ИМХО часть фишки в единой TLM (на SC) от начала и до конца (до гейт-левела).

 

Я не понял что такое "единая TLM"...

В едином маршруте от SC до гейт левела, вы, наверное, хотели сказать.

 

TLM -Transaction Level Modeling

http://en.wikipedia.org/wiki/Transaction-level_modeling

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

напрмер:

1. блок1 = старт отправки, ждём старта приёма на блоке2

2. блок2 = старт приёма, синхронизирован с отправкой блоком1

3. блок1 = финиш отправки, ждём финища приёма блока2

4. блок2 = финиш приёма, синхронизирован с финишом блока1

 

А переспектиы и у SC и у SV весьма перспективные. :)

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

Изменено 2 июня, 2009 пользователем al1

[SM 0]

Я не понял что такое "единая TLM"...

В едином маршруте от SC до гейт левела, вы, наверное, хотели сказать.

Это означает использование теста, построенного на базе стандарта OSCI TLM 2.0 вплоть до верификации гейт-левела. А не только верификации SC-модели самого устройства.

[al1 0]

Это означает использование теста, построенного на базе стандарта OSCI TLM 2.0 вплоть до верификации гейт-левела. А не только верификации SC-модели самого устройства.

 

А, ну, да, тогда согласен!

Единый тест это один из основных подходов в современных проектах.

 

Только надо будет дописать блоки-драйверы, которые на входе RTL блока будут конвертировать классы в сигналы, а на выходе - сигналы в классы.

 

Вот и получается что проект может состоять из:

 

SystemC - эталонный DUT + "соседние" блоки для отработки коммуникаций;

SystemVerilog - сопутствующие блоки, типа генератор псевдослучайных ограниченных данных, "сборщик статистики", компаратор эталонной модели и RTL и т.д. (написанные вручную на ассертах или с использованием avm/vmm/ovm);

VHDL/Verlilog - RTL модель DUT.

 

Т.е. SC ни куда и не "уходил" и ни кто на него и не забивал, он как развивался так и развивается.

А то что синопсис приподопоздал со своим синтезатором, ну чтож... задача не тривиальная.

Изменено 2 июня, 2009 пользователем al1

[SM 0]

SystemVerilog - сопутствующие блоки, типа генератор псевдослучайных ограниченных данных, "сборщик статистики", компаратор эталонной модели и RTL и т.д. (написанные вручную на ассертах или с использованием avm/vmm/ovm);

А я так понимаю, что Forte предлагает это убрать, оставясь полностью в рамках SC и OSCI TLM 2.0 (ну и видимо соответственно SCV вместо *VM, хотя тут я не уверен)

т.е. чтобы пользователь как бы не видел гейт-левела с его верилогами.

 

Только надо будет дописать блоки-драйверы, которые на входе RTL блока будут конвертировать классы в сигналы, а на выходе - сигналы в классы.

Думаю, это автоматизировано у форте.

 

А то что синопсис приподопоздал со своим синтезатором, ну чтож... задача не тривиальная.

Да он не опоздал, он был вместе с css, только потом его просто ликвидировали зачем-то. Т.е. в 2003.12 compile_systemc например еще работало. что-то политическое имхо, а не нетривиальность. behavioral compiler кстати у синопсиса пожалуй у первого был. но там без SC разумеется

[RVlad 0]

Небольшое уточнение : синтез SystemC (2.0.1) был точно в DC2002.05.

А помоему даже раньше DC2001-2000.

[al1 0]

А я так понимаю, что Forte предлагает это убрать, оставясь полностью в рамках SC и OSCI TLM 2.0 (ну и видимо соответственно SCV вместо *VM, хотя тут я не уверен)

т.е. чтобы пользователь как бы не видел гейт-левела с его верилогами.

 

 

Думаю, это автоматизировано у форте.

 

 

Да он не опоздал, он был вместе с css, только потом его просто ликвидировали зачем-то. Т.е. в 2003.12 compile_systemc например еще работало. что-то политическое имхо, а не нетривиальность. behavioral compiler кстати у синопсиса пожалуй у первого был. но там без SC разумеется

 

Ок. Про первенство утверждать не буду. катапульт раньше precisionC назывался и это тоже было в далёкие махнатые годы.

 

Про автоматизацию генерации драйверов можно по подробнее? У катапульта этого нет, у форте скорее всего тоже нет. Но если бы вы точно могли-бы ответить - было-бы здорово.

 

 

т.е. чтобы пользователь как бы не видел гейт-левела с его верилогами.

 

Скажем так: не "не видел", а "не писал руками".

 

Т.е. синтезировал из C, проанализировал полученный HDL (т.е. всётаки просмотрел, промоделировал и разобрался в его структуре), синтегировал ещё раз, ещераз проанализировал и так до тех пор пока не получится удовлетворительный результат. Но без ручной правки HDL.

 

А если бы хотели убрать SV блоки которые для анлиза нужны, то сделали-бы реализацию vmm и на SC тоже (как это сделано в avm). Потому что всякие там "генераторы", "анализаторы" и т.д. они же все похожи по своей сущности, проще взять готовый класс из vmm и подстроить под проект чем писать с нуля на SC.

Изменено 2 июня, 2009 пользователем al1

[SM 0]

Про автоматизацию генерации драйверов можно по подробнее? У катапульта этого нет, у форте скорее всего тоже нет. Но если бы вы точно могли-бы ответить - было-бы здорово.

Не могу. Ибо нарвался на форте совершенно случайно и на днях. Я хотел как раз получить либо подтверждения моих предположений, либо опровержение. Могу его в закрома зафортить - желающим разобраться в истине.

 

А если бы хотели убрать SV блоки которые для анлиза нужны, то сделали-бы реализацию vmm и на SC тоже (как это сделано в avm). Потому что всякие там "генераторы", "анализаторы" и т.д. они же все похожи по своей сущности, проще взять готовый класс из vmm и подстроить под проект чем писать с нуля на SC.

А что такое тогда:

TLM - Transaction Level Modeling Library, Release 2.0

SystemC Verification Library (SCV), Release 1.0p2

[al1 0]

Не могу. Ибо нарвался на форте совершенно случайно и на днях. Я хотел как раз получить либо подтверждения моих предположений, либо опровержение. Могу его в закрома зафортить - желающим разобраться в истине.

 

А нельзя не весь форте зафортить а только один юзер мануал?

А то ставить нет времени а мануал посмотреть - самое то.

 

А что такое тогда:

TLM - Transaction Level Modeling Library, Release 2.0

SystemC Verification Library (SCV), Release 1.0p2

 

Щас посмотрю полный состав библиотеки TLM но в сравнении с avm, ибо к vmm доступа нет.

Предлагаю считать их более менее эквивалентными.

Изменено 2 июня, 2009 пользователем al1

[SM 0]

ибо к vmm доступа нет.

Как нет? Она же открытая, как и OVM, http://www.vmmcentral.org/

Предлагаю считать их более менее эквивалентными.

ну да, разумеется,

 

А нельзя не весь форте зафортить а только один юзер мануал?

Зафортил. блин, не могли оглавление человеческое сделать. И на зафорчивание весь поставил. в еда.