Перейти к содержанию
    

Работа с модпортами в SV

Добрый день.

Возник такой вопрос.

 

Есть интерфейс

 

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?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В топовом модуле хотелось бы обращаться не к данным в интерфейсе напрямую, а к ссылке на них в модпорте Out. Что-то вроде

intInter.Out.oData=1

 

Проблема заключается в том, что Ква означенное обращение ест, а Modelsim Altera SE - нет. В стандарте про такое обращение ничего не сказано, так что я так понимаю, что каждый разработчик может решать по-разному, в зависимости от своего видения стандарта (чем, вообще, славен Ква).

 

Есть ли способ использовать иерархическое обращение в рамках стандарта? Кроме создания дополнительного модуля, в который будет передаваться интерфейс Out?

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

1) modport не является иерархической ссылкой

2) на качество данных в интерфейсе никак не влияет то из какого модпорта вы на них смотрите, а только влияет на то что вам с ними разрешено делать (такой своеобразный констрейн),

3) поэтому смысла обращаться к данным через их какое-либо представление по средствам модпортов из топа а) нет никакой необходимости б) строго говоря не правильно (т.е. Ква делает это неправомочно, а вот моделсим прав)

 

зачем вам с практической точки зрения такая акробатика?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну если мне память не изменяет, то модпорт не является инстансом, а является спецификатором. по существу это аналог класса интерфейса в ООП. специфицирует он то как тот или иной модуль видит ваш интерфейс.

Ну вот и хотелось смотреть через спецификацию интерфейса в модуле, в котором интерфейс объявлен.

 

зачем вам с практической точки зрения такая акробатика?

Ну вообще, возможно, Вы и правы. Я так подумал, может быть, действительно, неправильно идеологически.

Просто, я привык сигналы, передаваемые в модуль описывать с префиксом "i", а из модуля - "o". А использовать префиксы в теле интерфейса, вроде как, не совсем правильно.

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

 

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну вот и хотелось смотреть через спецификацию интерфейса в модуле, в котором интерфейс объявлен.

ну так в котором объявлен же а не к которому подключен. модпорты это спецификация того как видятся сигналы из модуля в который интерфейс воткнут.

модпорт (или тип подключения интерфейса) нужен для того чтобы

а) задавать разграничения (constrains) направления в венике(интерфейсе) (intent)

б) создавать алиас (синоним) сигнала способствующий пониманию его функции для конкретного типа подключения (как раз добавление тех самых буковок i или o или bi)

в) определять набор доступных функций интерфейса данного подключения (intent и IP hiding/incapsulation) - прямая аналогия виртуального класса, описывающего интерфейс в ООП

 

а когда у вас веник не воткнут в модуль, а лежит поперёк модуля, то какие же тут направления (направления всегда относительно чего-то)

 

пожалуйста

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...