Ethereal 0 27 июня, 2011 Опубликовано 27 июня, 2011 · Жалоба Добрый день. Возник такой вопрос. Есть интерфейс interface Inter; bit Data; modport In(input .iData(Data)); modport Out(output .oData(Data)); endinterface И есть два модуля. Один, который соединяется через интерфейс module Mod2(Inter.In InterIn); always @(InterIn.Data) $display("Data %d", InterIn.iData); endmodule и топовый module Top(); Inter intInter(); Mod2 instMod2(intInter); initial begin intInter.Data=0; #10 intInter.Data=1; #20 intInter.Data=0; end endmodule В топовом модуле хотелось бы обращаться не к данным в интерфейсе напрямую, а к ссылке на них в модпорте Out. Что-то вроде intInter.Out.oData=1 Проблема заключается в том, что Ква означенное обращение ест, а Modelsim Altera SE - нет. В стандарте про такое обращение ничего не сказано, так что я так понимаю, что каждый разработчик может решать по-разному, в зависимости от своего видения стандарта (чем, вообще, славен Ква). Есть ли способ использовать иерархическое обращение в рамках стандарта? Кроме создания дополнительного модуля, в который будет передаваться интерфейс Out? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 27 июня, 2011 Опубликовано 27 июня, 2011 · Жалоба В топовом модуле хотелось бы обращаться не к данным в интерфейсе напрямую, а к ссылке на них в модпорте Out. Что-то вроде intInter.Out.oData=1 Проблема заключается в том, что Ква означенное обращение ест, а Modelsim Altera SE - нет. В стандарте про такое обращение ничего не сказано, так что я так понимаю, что каждый разработчик может решать по-разному, в зависимости от своего видения стандарта (чем, вообще, славен Ква). Есть ли способ использовать иерархическое обращение в рамках стандарта? Кроме создания дополнительного модуля, в который будет передаваться интерфейс Out? ну если мне память не изменяет, то модпорт не является инстансом, а является спецификатором. по существу это аналог класса интерфейса в ООП. специфицирует он то как тот или иной модуль видит ваш интерфейс. отсюда 1) modport не является иерархической ссылкой 2) на качество данных в интерфейсе никак не влияет то из какого модпорта вы на них смотрите, а только влияет на то что вам с ними разрешено делать (такой своеобразный констрейн), 3) поэтому смысла обращаться к данным через их какое-либо представление по средствам модпортов из топа а) нет никакой необходимости б) строго говоря не правильно (т.е. Ква делает это неправомочно, а вот моделсим прав) зачем вам с практической точки зрения такая акробатика? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ethereal 0 27 июня, 2011 Опубликовано 27 июня, 2011 · Жалоба ну если мне память не изменяет, то модпорт не является инстансом, а является спецификатором. по существу это аналог класса интерфейса в ООП. специфицирует он то как тот или иной модуль видит ваш интерфейс. Ну вот и хотелось смотреть через спецификацию интерфейса в модуле, в котором интерфейс объявлен. зачем вам с практической точки зрения такая акробатика? Ну вообще, возможно, Вы и правы. Я так подумал, может быть, действительно, неправильно идеологически. Просто, я привык сигналы, передаваемые в модуль описывать с префиксом "i", а из модуля - "o". А использовать префиксы в теле интерфейса, вроде как, не совсем правильно. Но в описанном случае сигнал и не является выходом топового модуля, так что все логично. Видимо, надо переобдумать собственные правила кодирования. Спасибо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CaPpuCcino 0 27 июня, 2011 Опубликовано 27 июня, 2011 · Жалоба Ну вот и хотелось смотреть через спецификацию интерфейса в модуле, в котором интерфейс объявлен. ну так в котором объявлен же а не к которому подключен. модпорты это спецификация того как видятся сигналы из модуля в который интерфейс воткнут. модпорт (или тип подключения интерфейса) нужен для того чтобы а) задавать разграничения (constrains) направления в венике(интерфейсе) (intent) б) создавать алиас (синоним) сигнала способствующий пониманию его функции для конкретного типа подключения (как раз добавление тех самых буковок i или o или bi) в) определять набор доступных функций интерфейса данного подключения (intent и IP hiding/incapsulation) - прямая аналогия виртуального класса, описывающего интерфейс в ООП а когда у вас веник не воткнут в модуль, а лежит поперёк модуля, то какие же тут направления (направления всегда относительно чего-то) пожалуйста Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться