CaPpuCcino 0 4 августа, 2007 Опубликовано 4 августа, 2007 · Жалоба что если потом все вызовы транзакторов подменять на код ГЕНЕРИРУЮЩИЙ HDL описание (т.е. фактически программа при моделировании будет генерировать себя на HDL) :) на вскидку, будет гемор с проектированием этих ХДЛ-билдеров и в общем случае неоптимальное управление потоком данных в интерфейсе (однако это уже из области фантазии - не хотелось бы развивать дискуссию поводом для которой является "а что если" - было бы какое-то готовое решение или подход - обсудили бы). в общем случае вызовы блокирующих подпрограмм транзакторов действительно затем подменяются вызовами неблокирующих функций (набора функций позволяющего реализовать ту же функциональность, что и блокирующая подпрограмма), но при этом всё равно используется эвалюционный подход (не революционный, который в данном контексте можно определить как "по моновению волшебной палочки" или "автоматически, возложив всю работу на компилятор-синтезатор", данную работу выполняет разработчик) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
9.9 0 13 августа, 2007 Опубликовано 13 августа, 2007 · Жалоба CaPpuCcino Спасибо за разъяснение :) Только начинаю работать с SoC. За раз свалилось море интересной информации...теперь разгребаюсь потихонечку :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
WARri0r 0 14 октября, 2007 Опубликовано 14 октября, 2007 · Жалоба а вот интересно, ПОЯВИТСЯ ЛИ вообще когда-нибудь вновь возможность синтезировать системС? сам я схемотехник по сути. дали мне комплексное задание изучить системС! и я начал это изучение так сказать с другой стороны:) нет, я конечно имею представление о программировании, но опыта работы с ВХДЛ значительно больше. и вот по прошествию некоего времени я уже поднаторел в разработке ТЛМ моделей! сразу скажу, что для всей организации я съэкономил этим кучу времени! ведь при помощи ТЛМ модели я мог протестировать ВХДЛ модель намного полнее, нежели просто набор входных и выходных данных от программиста на С++. но вот хочется перейти на новый уровень - попытаться синтезировать модели! и тут - на тебе - отказ от синтеза системС большинством гигантов-производителей синтезаторов. что делать? менять язык? но на системВерилоге фактически нет возможности ТЛМ моделирования! вот такая проблемма. нет, ну конечно можно выучить ВСЁ, и спокойно рботать, но на сколько это серьёзно - я судить не берусь! отписался, кажется, в тему. жду выших мыслей, уважаемые! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 14 октября, 2007 Опубликовано 14 октября, 2007 · Жалоба но на системВерилоге фактически нет возможности ТЛМ моделирования! учите Олбанский, товарищ, и не говорите глупостей Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gserdyuk 0 18 января, 2008 Опубликовано 18 января, 2008 · Жалоба ИМХО есть возможность поднять скорость моделирования в разы, только непонятно почему производители симуляторов на это не идут. .... вместо компиляции HDL кода в объектный код исполняемый ядром симулятора, сделать что-то вроде кросс-компилятора HDL ну пусть в тот же SC. Похоже есть то о чем Вы говорите. "It compiles synthesizable Verilog (not test-bench code!), plus some PSL, SystemVerilog and Synthesis assertions into C++ or SystemC code." http://www.veripool.com/verilator.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 18 января, 2008 Опубликовано 18 января, 2008 · Жалоба Похоже есть то о чем Вы говорите. "It compiles synthesizable Verilog (not test-bench code!), plus some PSL, SystemVerilog and Synthesis assertions into C++ or SystemC code." http://www.veripool.com/verilator.html Классно, надо попробывать. правда насторожила фраза : Verilog 2005 support added as users request them. попробую, на своих проектах, надеюсь что классы и рандомное тестирование там поддерживается. ЗЫ. нашел на сайте http://www.veripool.com/verilog_sim_benchmarks.html Verilator is 90x faster than Icarus Verilog. Verilator is 10-40x faster than Modelsim SE. Verilator is 3x faster than NC-Verilog. Verilator is 1.5x faster than VCS. VTOC is 4x faster than Verilator. VTOC is 50x faster than NC-Verilog. [/b]VCS is 3x faster than Verilator. [/b] VCS is 3x faster than NC-Verilog. VCS is 10x faster than NC-Verilog. VCS is the same speed as NC-Verilog. CVer is the same speed as Icarus Verilog аааа, хачу VCS %))))))))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 18 января, 2008 Опубликовано 18 января, 2008 · Жалоба Похоже есть то о чем Вы говорите. а разве Синопсис не компилит в исполняемый код вместо объектного? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 23 января, 2008 Опубликовано 23 января, 2008 · Жалоба сунусь я в эту тему со своей проблемой (жалобой на врагов :) переставших поддерживать SC): в системе есть некая задача обработки сигналов модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре) после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов) на HDL верифицируется (пишутся тестбенчи, проверяется их совпадение с С++ моделью и т.п.) затем синтезируется, верифицируется, изготовляется чип, плата... при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками. ======================== как может помочь SV - я не понимаю. требуется переписать модель на SV, но 1) требуется обучить программистов, 2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода) ------------------------------------------ обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте) ------------------------------------------ некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка ----------------------------------------- собственно - мое мнение, что по этой причине SV значительно хуже SC. то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари) а SV требует переноса моделей с С++ (что опять же нагрузка на HDL-щиков), а результат потребует обратной трансляции в C++ ---------------------------------------- Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 23 января, 2008 Опубликовано 23 января, 2008 · Жалоба сунусь я в эту тему со своей проблемой (жалобой на врагов :) переставших поддерживать SC): в системе есть некая задача обработки сигналов модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре) после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов) на HDL верифицируется (пишутся тестбенчи, проверяется их совпадение с С++ моделью и т.п.) затем синтезируется, верифицируется, изготовляется чип, плата... при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками. ======================== как может помочь SV - я не понимаю. требуется переписать модель на SV, но 1) требуется обучить программистов, 2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода) ------------------------------------------ обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте) ------------------------------------------ некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка ----------------------------------------- собственно - мое мнение, что по этой причине SV значительно хуже SC. то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари) а SV требует переноса моделей с С++ (что опять же нагрузка на HDL-щиков), а результат потребует обратной трансляции в C++ ---------------------------------------- Присоединяюсь к мнению уважаемого yes. Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. :) Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится. SV безусловно хорош, практически все, чего не хватало в Verilog добавлено + развитые средства верификации. Еще не один год пройдет, пока SV начнут реально использовать, ибо такого рода внедрение стоит очень дорого... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 23 января, 2008 Опубликовано 23 января, 2008 · Жалоба Присоединяюсь к мнению уважаемого yes. Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. :) Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится. всё это конечно правильно, но абсолютно все эти аспекты уже неоднократно обсуждались на форуме. зачем заного начинать оплакивания (кстати, например в этой же теме, на первой странице) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 24 января, 2008 Опубликовано 24 января, 2008 · Жалоба Позвольте вмешаться в спор :) 2 yes и oval Не могу считать себя гуру SV, но немного SV опыта есть. И хотел бы вынести его на рассмотрение. Сам полез в систем верилог, по сути ради развлечения. Изначально он показался мне легкой надстройкой над обычным верилогом, что-бы дотянуть его удобство до уровня вхдл. но сделав на нем 3 проекта (один из них вы скоро увидите в исходниках), покурив литературу и начав вкуривать его философию : ртл там не сильно изменился, а вот верификация.... могу заключить : 1. Основной концепцией является ООП. Не хотите его использовать ? тогда толку от SV будет не более чем от vhdl. 2. SV очень удобен для отладки НЕ ДСП систем. Используя рандомные подходы с ограничениями, на которые еще можно натравить и языковые средства по мониторингу функционального покрытия можно очень просто, используя настраиваемые констрейны или наследование классав перебрать очень много вариантов работы окружения тестируемой системы. Например как выглядит у меня тестбенч сдрам контроллера : 1. интерфейс с клокинг секциями (убиваем проблему гонок на корню). 2. класс - драйвер - вся работа с интефейсами контроллера 3. класс - callback к этому драйверу - scoreboard, performance monitor 4. класс - агента драйвера - API по работе с драйвером 5. класс - транзактор . рандомный с программируемыми ограничениями. ну и программа, которая инитит классы и строит архитектуру. все. больше в тестбенче ничего нет. Весь набор тестов сводиться к заданию констрейнов на параметры рандомных генераторов транзактора. на чистом верилоге описывать это - застрелиться можно. Да тут возникает проблема начальных затрат на разработку классов, но для этого и существует vmm/amm (у ментора) технологии (это я еще не освоил). по сути базовые классы для создания драйверов, агентов, скоребордов, транзакторов и т.д. но все это обладает большей контролируемостью чем стандартный верилог, вхдл тестбенч. 3. для отладки ДСП систем выскажу мнение в комментариях к посту уважаемого yes : модель этой задачи описывается на С++ (потом часть кода используется в боевом фирмваре) не вижу никаких проблем как для SC так и для SV. После того как есть модель, ее можно легко, используя технологию DPI, импортировать ее в SV, так и обратно (!!!) импортировать SV в C++. Тут опять уместно использовать концепцию драйверов, основанных на классах. Т.е. можно изначально сделать разделение софтваре, хардваре. и не моделировать хард на SC, а потом переводить его. А сразу делат хард на уровне модулей с заглушками - программами. после отладки С++ модели, то что отображает железо (RTL) переписывается в HDL, а внешний сигнал задается в виде файла воздействия (иногда и проверки ожидаемых результатов) вы сами пишете что потом следует переписывание кода на HDL. Причем этот сегмент есть как SC так и в SV маршрутах. При этом для SC нужно знать : vhdl/verilog + PSL + C++(на уровне SC), для его аналогичного маршрута достаточно знать только SV. при этом ошибка начальной С++ модели требует исправления HDL, обнаружение трудноустранимой и/или незначительной ошибки HDL - требует исправления С кода для соответствия. исправления делаются руками. Ошибки в алгоритме никуда не денутся, но ошибки проектирования структуры харда будут пройдены 1 раз. (ну кроме изначального просчета архитектуры) как может помочь SV - я не понимаю. вашему текущему проекту никак, если вы его начали в текущем маршруте, его и продолжайте. 1) требуется обучить программистов, без этого никуда, даже в жизни. 2) пропадает связь с реальным фирмварем (компилировать в исполняемые коды (например АRМа) SV нечем, даже если бы и был - как быть с "повторным использованием" С++ кода) см. выше. повторное использование остается, если грамотно сделано разделение софта и харда. обидно, теряется возможность (и смысл, имхо) системного уровня - "подвигать" границу между софтом и железом (ну типа этот фильтр лучше реализовать в железке, а этот в софте) никаких проблем, если делать все не на plain c, то все решается на уровне объектов-драйверов (причем вы даже можете передать в С++ программу задержки моделирования (!!!!)) . некое облегчение можно получить используя PLI и С код в HDL симуляторе, но это так... маленькая заплатка Если это маленькая заплатка, тогда зачем технология Direct-C в вхдл введена ? :) собственно - мое мнение, что по этой причине SV значительно хуже SC. Вы гуру, вам виднее. то есть SC (как расширение С++) покрывало все - и системный уровень, и проектирование и синтез RTL, и разработку встраиваемого ПО (фирмвари) Синтеза нормально с SC свет так и не увидел. А нормально, грамотно развести софтваре и хардваре на модели в SV достаточно просто. Даже если не пользовать DPI технологию, свои "софт" функции написанные на SV переносятся в C копи пастом (!!!). ну единственно что нужно это заменить begin end на {} и убрать endfunction. Хотя простота DPI подкупает, что и смысла так делать нет. Действительно SC более удобен для сквозного проектирования системы в целом на всех уровнях. SV и его столь активное продвижение - "большая политика" мировых законодателей моды данного направления, причем это не придумал. smile.gif Был период, когда поддержку SC активно развивали, но "деньги" взяли свое. Будем надеяться, что-нибудь изменится. как раз сквозного проектирования то и не было. Да были попытки синтезировать SV, но качество синтеза ... Его конвертировали в вхдл, верилог. Но выхлоп с такой конвертации тоже был не сахар. SC была великолепная попытка использовать армию доступных с++ программистов для хдлных дел, но похоже дело не пошло. Все вышесказанное мое ИМХО. я глупый, местами даже тупой, так что могу ошибаться :) Еще не один год пройдет, пока SV начнут реально использовать, ибо такого рода внедрение стоит очень дорого.. хмм у меня переход на SV. еще на старушке квесте 6.2ф занял 1 месяц, а постижение его философии еще 3. все. теперь обратного пути нет. ну если только ОБЭП ко мне домой не заявиться и не присудит мне срок лет 5 за использование софта от ментора, т.к. к сожалению бесплатного симулятора SV, на том уровне что нужен мне, пока нет Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
yes 7 24 января, 2008 Опубликовано 24 января, 2008 · Жалоба Позвольте вмешаться в спор :) ---------- большое спасибо, за комментарии. я вообще-то и хотел услышать в ответ, что-то подхожее: "если разобраться, то SV тоже рулит" ну и ключевые слова :) мне понятно, что классическая DSP задача (dataflow или как ее правильно назвать) и подход с моделированием транзакций не совсем соответствуют, но кроме DSP есть куча задач системного уровня, (которые из-за спешки были совершенно опущены в настоящем проекте) : моделирование памятей (например, размер и организация кэша), SDRAM контроллер, внутренние памяти с арбитражем, обмен DSP-процессор и т.п. конфигурация была сделана методом "экспертных оценок" (в основном - так делали раньше, так сделаем и сейчас) то есть оптимизировать систему можно, вот пытаюсь понять как :) --------------------------------- а с использованием assertion-ов (PSL) кто-нибудь продвинулся? вобщем-то идея правильная (имхо, для всяких хитрых шин/интерфейсов - очень полезно) - особенно если бы их можно было бы с одного уровня абстракции автоматически генерить... мы пытались шину в АЗИКе описать, но кривовато вышло (неполное описание) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
des00 25 24 января, 2008 Опубликовано 24 января, 2008 · Жалоба я вообще-то и хотел услышать в ответ, что-то подхожее: "если разобраться, то SV тоже рулит" Джа даст нам все. это будет лучше ? :) мне понятно, что классическая DSP задача (dataflow или как ее правильно назвать) и подход с моделированием транзакций не совсем соответствуют, но кроме DSP есть куча задач системного уровня, (которые из-за спешки были совершенно опущены в настоящем проекте) : моделирование памятей (например, размер и организация кэша), SDRAM контроллер, внутренние памяти с арбитражем, обмен DSP-процессор и т.п. конфигурация была сделана методом "экспертных оценок" (в основном - так делали раньше, так сделаем и сейчас) то есть оптимизировать систему можно, вот пытаюсь понять как :) думаю тут как раз и можно заняться системным моделированием. это можно делать как на уровне SV, так и на уровне SC. в Springer - Verification Methodology Manual for SystemVerilog - Bergeron 2005 Springer - SystemVerilog for Verification хорошо расписано про моделирование. причем яник не мог не упомянуть очередную ревизию (самую понятно читаемую) ATM свитча который он приводит в своих книгах. а с использованием assertion-ов (PSL) кто-нибудь продвинулся? вобщем-то идея правильная (имхо, для всяких хитрых шин/интерфейсов - очень полезно) - особенно если бы их можно было бы с одного уровня абстракции автоматически генерить... Незнаю насколько сильно, на мне использование асеров нравиться, причем в тестбенчах снимает головную боль про проверку некоторых случаев. (например временное расположение стробов друг относительно друга). PSL ем не пользовался, да и сам подход асеров в комментариях мне не нравиться. в SV ассерты входят как языковые конструкции. что очень удобно, для "компилирующих" разработчиков (коим являюсь я). ибо в подобных конструкциях можно и запутаться property access_cycle_prop (clk, reset, sop, eop, vld); @(posedge clk) disable iff (reset) $rose(vld) |-> (sop & ~eop) ##1 (vld & ~sop & ~eop)[->cPktBitSize-2] ##1 (vld & ~sop & eop) ##1 ~vld; endproperty плюсы ассеров систем верилога в том, что введен объект property. можно описать одно свойство и использовать его на для N объектов. Также есть понятия переменных в асертах и можно использовать вызовы функций. Но все же некоторые ассерты лучше пишутся комбинированным способом : процедурный код + ассерты. Это также подробно рассматривает яник. еще очень удобно делать отдельный, пассивный интерфейс с ассертами. в таком случае его можно использовать на любом уровне иерархии. т.к. в верилоге всегда были иерархические ссылки на сигналы. И строя модуль их кубиков, вы навешиваете на него нужные внешние/внутренние проверки. Кстати в vmm технолгии созданы специальные шаблоны для задания асертов, там даже не нужно сильно разбираться как их описывать. Удачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 24 января, 2008 Опубликовано 24 января, 2008 · Жалоба Позвольте вмешаться в спор :) да, печаль-то как раз о том, что синтез с СЦ не стали двигать (на мой взгляд тоже злонaмеренно). был бы синтез, то прелесть концепции СЦ заключалась бы в том, что весь процесс разработки велся бы в одном едином языке (без нужды в копи-пэйсте) + система софт+хард тоже была бы доступна в едином языковом пространстве. ну а СВ конечно рулит :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
oval 0 24 января, 2008 Опубликовано 24 января, 2008 · Жалоба да, печаль-то как раз о том, что синтез с СЦ не стали двигать (на мой взгляд тоже злономеренно). был бы синтез, то прелесть концепции СЦ заключалась бы в том, что весь процесс разработки велся бы в одном едином языке (без нужды в копи-пэйсте) + система софт+хард тоже была бы доступна в едином языковом пространстве. Двигали :) , только в определенный момент, закрыли, ибо очевидно, что все остальное в этом случае просто бы вымерло... опять же, не я придумал, знаком с людьми, которые занимались написанием средств синтеза SC, но поступил приказ работы свернуть, финансирование прекратить... Что касается возможностей верификации и самых современных тенденций, то в SC, аналогично SV, все это также реализовано: библиотеки SCV (SC verification), TLM и т.д. Вообщем, для полноты не хватает только нормальной поддержки синтеза... Против SV ничего не имею, все достойно :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться