yes 7 December 27, 2008 Posted December 27, 2008 · Report post в SV есть возможность "вложить" интерфейс внутрь другого есть модуль, в который инстанциированы подмодули с интерфейсом, хочется подключать этот модуль верхнего уровня посредством своего "обобщенного" интерфейса ну то есть если бы это был VHDL и структуры, то аналогом этого "обобщенного" интерфейса был бы массив структур но так как в интерфейсе подключение к модулю задается modport-ом и в нем есть как входы и выходы, а в "обобщенный" интерфейс не понятно как создать modport c интерфейсом, я не нашел описание этого в книжках и не могу понять принципиально это не возможно или я не понимаю синтаксиса собственно вопрос - можно ли и как описать??? объясните плиз -------------- базовый и "обобщенный" интерфейс interface bi; logic req; logic ack; modport up(input req, output ack); modport down(output req, input ack); endinterface interface di; bi i[1:0](); endinterface --------------------- внутренний модуль module c(input logic clk, rst, bi.up u, bi.down d ); --------------------- модуль, объединяющий два внутренних и имеющий обобщенный интерфейс (собственно его я и затрудняюсь описать) module dc(input logic clk, rst, di p[1:0]); bi u[1:0](); bi d[1:0](); c c0(clk, rst, u[0], d[0]); c c1(clk, rst, u[1], d[1]); как теперь соединить интерфейсы u и d с портом модуля dc???7 мне хочется чтобы p[0]=====u[1:0], а p[1]=====d[1:0] =================================================== я могу подключить напрямую c c0(clk, rst, p[0].i[0], p[1].i[0]); c c1(clk, rst, p[0].i[1], p[1].i[1]); но мне собственно хотелось бы в этом модуле dc иметь перекомутацию интерфейсов (случай есс-но более тяжелый, чем в примере) - то есть какой-то параметризованный generate с assign или alias или же посигнально module dc(input logic clk, rst, di p[1:0]); bi u[1:0](); bi d[1:0](); assign u[0].req=p[0].i[0].req; assign u[1].req=p[0].i[1].req; assign p[0].i[0].ack=u[0].ack; assign p[0].i[1].ack=u[1].ack; assign p[1].i[0].req=d[0].req; assign p[1].i[1].req=d[1].req; assign d[0].ack=p[1].i[0].ack; assign d[1].ack=p[1].i[1].ack; c c0(clk, rst, u[0], d[0]); c c1(clk, rst, u[1], d[1]); но где же тогда инкапсуляция и абстракция? возникает впечатление, что использование структур в качестве портов удобнее (там достаточно следить за двумя направлениями только) собственно, обобщенно нужно реализовать структуру, приблизительно показанную на рисунке. я попытался описать это на верилоге (только одномерные массивы) и застрелился :( юнит интерфейс, это не два провода, а полста, в разных направлениях, причем туда вносятся изменения в процессе работы поэтому хочется максимально возможной абстракции в описании соединений и коммутатора (там должны быть не только статические, но и run-time перекомутации модулей) собственно хочется понять, можно ли что-то лучше чем структуры и массивы структур. хотелось бы конечно, двунаправленные соединения держать в одном "агрегате" Quote Share this post Link to post Share on other sites More sharing options...
CaPpuCcino 0 January 19, 2009 Posted January 19, 2009 · Report post собственно вопрос - можно ли и как описать??? постораюсь быть кратким, потому что по поводу философии языка можно долго растекаться мыслью по древу и всё равно к консенсусу не притечь: иерархия интерфейсах в интерфейсах быть может, а вот протаскивать через модпорты внутренние интерфейсы наружу запрещено. рекоммендация от коммитета: распускать все внутренние веники интерфейсов и тянуть через модпорты старших по иерархие только те сигналы которые необходимы. вообще в коммитете есть мнение, что вложенные интерфейсы вещь абсолютно бесполезная и курс они хотят взять на наследование интерфейсов а не на композицию. с тем что вещь в условиях нынешнего стандарта абсолютно бесполезная согласен был ещё до ознакомления с официальным курсом партии. теперь как описать: подобные вашим вещи описывал как коммутирующий модуль с торчащими из него пучками (массивами) однотипных интерфейсов. парметризируемость такой штуки достаточно широкая - все статические связи коммутируются generate-ами Quote Share this post Link to post Share on other sites More sharing options...
yes 7 January 21, 2009 Posted January 21, 2009 · Report post теперь как описать: подобные вашим вещи описывал как коммутирующий модуль с торчащими из него пучками (массивами) однотипных интерфейсов. парметризируемость такой штуки достаточно широкая - все статические связи коммутируются generate-ами спасибо за разъяснение, в результате деятельности по писанию синтезируемого и симулируемого кода (имеющимися в наличии тулзами), я пришел к выводу что использовать интерфейсы пока (для меня) смысла нет и обхожусь структурами и массивами структур (типа, VHDL style) а сборка/разборка агрегатов данных для интерконекта через generate может иметь неприятные свойства - я собственно в SV и полез из-за того, что модуль описывающий таким образом соединения (с перегрупировкой одномерных векторов) перерос 1000 строк (а строки нехилые - файл под 100К) и стал, имхо, совершенно не годным к отладке ----------------------- если растечься мыслею: по-моему мнению интерфейсы в SV вообще криво и узко специализированая конструкция, и непонятно вообще какие проблемы описание интерфейса вызывает у синтеза (та же структура, но с возможность задать направление) единственное применение (специализация) это возможность скрыть в интерфейсе какие-то тестовые методы верификационной BFM, стоило ли для этого вводить дополнительную сущность в язык (там уже есть классы) - по-моему мнению - нет вопрос связи динамического объекта с иерархией DUT точно так же можно было сделать хэндлами на структуру Quote Share this post Link to post Share on other sites More sharing options...
CaPpuCcino 0 January 21, 2009 Posted January 21, 2009 · Report post мне так интерфейсы очень нравятся. пользуюсь ими постоянно. нареканий и дополнительных требований по состоянию стандарта на сегодня к ним не возникало. Quote Share this post Link to post Share on other sites More sharing options...
yes 7 January 22, 2009 Posted January 22, 2009 · Report post если найдете время, разъясните, плиз, конструкцию с параметрезированными модпортами, которую Вы приводили в другой теме http://electronix.ru/forum/index.php?showt...mp;#entry261700 собственно вопрос - как потом ссылаться (инстанциировать) нужный modport ни в стандарте, ни в книжках я ничего такого не нашел это может быть заменой вложености в моем случае я тут пытался на абстрактном примере объяснить, чего я хочу - http://electronix.ru/forum/index.php?showtopic=57336&hl= ----------------------- еще пара вопросов про практическое использование: когда в интерфейсе сигналы объявлены logic (без разрешающей логики), то невозможно добавить синхронный modport для тестбенча (с драйвером через clocking) - симулятор ругается на два конфликтующих драйвера, поэтому приходится описывать wire так ли это или я чего-то не так делаю? а то примеры некоторые из книжек не идут, ну и вообще использование разрешающей логики там где не надо мне кажется плохой идеей какими программными средствами Вы пользуетесь (вобщем-то вариантов немного :) но все-таки) , чтобы была поддержка SV (и синтез тоже) Quote Share this post Link to post Share on other sites More sharing options...
CaPpuCcino 0 January 22, 2009 Posted January 22, 2009 · Report post если найдете время, разъясните, плиз, конструкцию с параметрезированными модпортами, которую Вы приводили в другой теме http://electronix.ru/forum/index.php?showt...mp;#entry261700 собственно вопрос - как потом ссылаться (инстанциировать) нужный modport ни в стандарте, ни в книжках я ничего такого не нашел это может быть заменой вложености в моем случае я тут пытался на абстрактном примере объяснить, чего я хочу - http://electronix.ru/forum/index.php?showtopic=57336&hl= как ссылаться: блок generate имеет имя, ссылкой на инстанс в случае generate for будет имя+индекс (может быть вы не заметили, но я в приведённой вами ссылке привожу главу где это можно посмотреть\выделено жирным шрифтом\ - в той 20.4.4 посмотрите на второй пример - там как раз наглядный пример ссылки в подобных случаях) ваш вопрос я видел (AMBA), но там столько букв, что вникать в детали мне немного не позволительно (с временем небольшая напряжёнка), тем более там присутствовал des00, значит мне там особо делать нечего - он на мой взгляд правильную тактику там указывает, т.е. в общем виде, если относится к интерфейсу как более чем интерфейсу, то люди начнут старатся реализовывать в них например шинные контроллеры со всякими арбитрами и прочей светомузыкой, а интерфейс это всего лишь языковая или методологическая абстракция и растёт она из интерфейса в понимании объектного програмиста (т.е. абстракция высокого уровня) и предназначена для изоляции составных частей системы друг от друга со всеми вытекающими вроде повторного использования компонент, защиты интеллект. собств. и возможности параллельизации разработки проекта, а не для выделения из системы основных оерационных блоков и сопутствующей инфраструктурной коммуникации между ними (2 подсистем). когда в интерфейсе сигналы объявлены logic (без разрешающей логики), то невозможно добавить синхронный modport для тестбенча (с драйвером через clocking) - симулятор ругается на два конфликтующих драйвера, поэтому приходится описывать wire у меня с двунаправленным logic в интерфейсе тоже были какие-то проблемы, но это было относительно давно и точную ситуацию и как я её разрешал я не помню, а сейчас моделированием пока не занимаюсь, так что помочь не могу. через пару недель опять вернусь на моделирование и посмотрю в чём там проблема и как её возможно решить (если ещё бу актуально). по продуктам: пользуюсь всем менторовским (квеста+пресижен) на другое пока времени нет, хотя наверняка квеста не самый опт. модельная среда Quote Share this post Link to post Share on other sites More sharing options...
yes 7 January 23, 2009 Posted January 23, 2009 · Report post ----------- спасибо. то есть доступ через hierarhical reference - то есть такое должно работать и с любым генерейтом, интересно, кроме квесты такое понимает еще какой-либо тул... критических вопросов у меня нет, в любом случае, все можно описать другими конструкциями. проблема "общая", что конструкции SV не обеспечивают защиту данных и проверку при компиляции - я пытался что-то об этом отписать, но сейчас уже не интересно практически - из симуляторов квеста поддерживает SV лучше всех, затем NCSIM, затем VCS - такое у меня сложилось мнение. синопсис новый DC смотрел тоже - там слабее чем у пресижина, ну и разные ниши. а синплифай тоже не сильно хорошо SV поддерживает... Quote Share this post Link to post Share on other sites More sharing options...
des00 27 January 27, 2009 Posted January 27, 2009 · Report post по-моему мнению интерфейсы в SV вообще криво и узко специализированая конструкция, и непонятно вообще какие проблемы описание интерфейса вызывает у синтеза (та же структура, но с возможность задать направление) ИМХО я понимаю интерфейсы только как массивы двунаправленных сигналов, ну + между тегами можно напихать ассертов. Все. Не надо смотреть на них шире, только время тратить. единственное применение (специализация) это возможность скрыть в интерфейсе какие-то тестовые методы верификационной BFM, стоило ли для этого вводить дополнительную сущность в язык (там уже есть классы) - по-моему мнению - нет вопрос связи динамического объекта с иерархией DUT точно так же можно было сделать хэндлами на структуру Вы правы, более того комитет OVM не рекомендует использовать вообще интерфейсы. Т.к. в сложных моделях с ними больше гемороя, чем пользы. Ибо интерфейс вешь статическая и не подается наследованию. Для этого они предлагают использовать модули с классом, вставленным через фабрику. Статья об этом сейчас не под рукой, найду выложу. Если вам будет интересно. Quote Share this post Link to post Share on other sites More sharing options...
CaPpuCcino 0 January 27, 2009 Posted January 27, 2009 · Report post ИМХО я понимаю интерфейсы только как массивы двунаправленных сигналов идея интерфейсов была заимствована из методологии SystemC (книжки по СЦ как раз акцентируют своё внимание именно на методологии а не средствах языка. их полезно почитать прежде чем блатся именно за SV /не Верилог а именно СистемВерилог/ потому что в книжках по СВ методологии как раз внимания уделяют очень мало). интерфейс как веник их проводов это завершающая стадия сквозного проектирования сверху вниз. то что объекты класса интерфейс не наследуются это временное явление в коммитете это ограничение (как я уже говорил) хотят убрать. Quote Share this post Link to post Share on other sites More sharing options...
des00 27 January 28, 2009 Posted January 28, 2009 · Report post идея интерфейсов была заимствована из методологии SystemC (книжки по СЦ как раз акцентируют своё внимание именно на методологии а не средствах языка. я имел в виду не то, как я понял стандарт, а то как я использую интерфейсы. В своей работе для меня это только "веник их проводов" и только в моделировании. в атаче статья с ovmworld.org про то, что интерфейсы лучше не использовать abstractBFM_final_DR6.pdf Quote Share this post Link to post Share on other sites More sharing options...
