[Leka 0]

Как хотелось бы:

module alisa(input d, output q); ... endmodule
module bob(input d, output q); ... endmodule 
module top; ... endmodule // тут много вариантов:

//вариант 1: 
    alisa(.d(bob.q), .q(bob.d)); 
    bob();

//вариант 2: 
    alisa(); 
    bob(.d(alisa.q), .q(alisa.d));

//вариант 3: 
    alisa(.d(bob.q)); 
    bob(.d(alisa.q));

//вариант 4: 
    alisa(.q(bob.d)); 
    bob(.q(alisa.d));

//вариант 5: 
    alisa(); 
    bob();
    alisa.d=bob.q;
    bob.d=alisa.q;

//вариант 6: 
    alisa(.d(bob.q)); 
    bob();
    bob.d=alisa.q;

//вариант 7: 
    alisa(); 
    bob(.d(alisa.q));
    alisa.d=bob.q;

//вариант 8: 
    alisa(); 
    bob(.q(alisa.d));
    bob.d=alisa.q;

//вариант 9: 
    alisa(.q(bob.d)); 
    bob();
    alisa.d=bob.q;

Тогда для N модулей, связанных каждый с каждым, потребуется

N+1 блоков описания (module+top).

2 модуля --> 3 блока описаний,

200 модулей --> ~200 блоков описаний.

 

И что имеем в SV:

interface eva; ... endinterface
module alisa(interface e); ... endmodule
module bob(interface e); ... endmodule 
module top; ... endmodule // тут один вариант:    
    eva e();
    alisa (e);
    bob (e);
endmodule

Для N модулей, связанных каждый с каждым, в общем случае требуется

N*(N+1)/2+1 блоков описания(interface+module+top).

2 модуля --> 4 блока описаний,

200 модулей --> ~20000 блоков описаний.

 

Поправьте пожалуйста, если не так понял SV.

 

 

 

[_Ivan_ 0]

Посмотрите в сторону generate для SV.

[Leka 0]

Вопрос не в том, чтобы решить какую-то конкретную задачу, а в общей методологии описания синтезируемых схем.

SV допускает описание логики (без инстансов) в интерфейсах, но даже это не позволяет такое, например:

interface alisa (input d, output q); ... endinterface
interface bob (input d, output q); ... endinterface
module top;
    alisa(.d(bob.q)); 
    bob(.d(alisa.q));  
endmodule

- из-за каких-то совершенно непонятных лично мне ограничений (которые невозможно обойти).

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

[ViKo 1]

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

[Leka 0]

Пример, который показывает проблему.

Как оформить синтезируемое описание без описания шины cd.q в топ-модуле?

 

module top (clk, a, b, c, d, q);
    input clk;
    input [3:0] a, b, c, d;
    output [3:0] q;
    //sum ab (.clk, .a, .b ); //это синтезируется
    sum ab (.clk, .a, .b(cd.q) ); //это не синтезируется
    sum cd (.clk, .a(c), .b(d) ); 
    sum abcd (.clk, .a(ab.q), .b(cd.q), .q(q) );    
endmodule

interface sum (clk, a, b, q);
    input clk;
    input [3:0] a, b;
    output reg [3:0] q;    
    always@(posedge clk) q <= a + b;
endinterface

Изменено 21 ноября, 2016 пользователем Leka

[ViKo 1]

Я в интерфейсе только описывал сигналы, и модпортами задавал варианты их направления.

[Sergiysss 0]

Как хотелось бы:

module alisa(input d, output q); ... endmodule
module bob(input d, output q); ... endmodule 
module top; ... endmodule // тут много вариантов:

//вариант 1: 
    alisa(.d(bob.q), .q(bob.d)); 
    bob();

//вариант 2: 
    alisa(); 
    bob(.d(alisa.q), .q(alisa.d));

//вариант 3: 
    alisa(.d(bob.q)); 
    bob(.d(alisa.q));

//вариант 4: 
    alisa(.q(bob.d)); 
    bob(.q(alisa.d));

//вариант 5: 
    alisa(); 
    bob();
    alisa.d=bob.q;
    bob.d=alisa.q;

//вариант 6: 
    alisa(.d(bob.q)); 
    bob();
    bob.d=alisa.q;

//вариант 7: 
    alisa(); 
    bob(.d(alisa.q));
    alisa.d=bob.q;

//вариант 8: 
    alisa(); 
    bob(.q(alisa.d));
    bob.d=alisa.q;

//вариант 9: 
    alisa(.q(bob.d)); 
    bob();
    alisa.d=bob.q;

Тогда для N модулей, связанных каждый с каждым, потребуется

N+1 блоков описания (module+top).

2 модуля --> 3 блока описаний,

200 модулей --> ~200 блоков описаний.

 

И что имеем в SV:

interface eva; ... endinterface
module alisa(interface e); ... endmodule
module bob(interface e); ... endmodule 
module top; ... endmodule // тут один вариант:    
    eva e();
    alisa (e);
    bob (e);
endmodule

Для N модулей, связанных каждый с каждым, в общем случае требуется

N*(N+1)/2+1 блоков описания(interface+module+top).

2 модуля --> 4 блока описаний,

200 модулей --> ~20000 блоков описаний.

 

Поправьте пожалуйста, если не так понял SV.

 

На сколько я понял вы хотите добавить в структуру SV систему ссылок портов на модули... Однако ушли от стандарта языка Verilog. В топ модуле создается экземпляр по примеру:

alisa N1 (.d(bob.N1.q), .q(bob.N2.d)); и т.д.

Таким образом вы забыли о создании экземпляров. Представим что в вашем топовом модуле несколько сотен экземпляров одного и того же модуля, значит нужно указать точный номер конкретного экземпляра... ОК, дальше мы идем на уровень выше. В вашей главной схеме может существовать десятки подсхем с экземплярами модулей которые могут иметь одинаковые идентификатор. То есть должно быть строгое пространство имен и ссылок, в котором огромное количество потенциальных ошибок. А если доверить это программе, то нужно создавать специальные структуры которые будут указывать, что данные ссылки находятся в теле только одного модуля.

Итог - никакой элегантности.

Теперь к делу - для создания чего либо глобального и похожего есть структура generate...endgenerate что позволяло сделать многое еще со времен традиционного Verilog.

А в SV помимо интерфейсов, появились пакеты и user-defined типы переменных которые можно с их помощью передавать в том числе и для портов в пространстве $unit. Но как вы сказали интересует почему не сделать так как вы предложили? Моё скромное мнение выше.

Изменено 23 ноября, 2016 пользователем Sergiysss

[Leka 0]

На сколько я понял вы хотите добавить в структуру SV систему ссылок портов на модули... Однако ушли от стандарта языка Verilog. В топ модуле создается экземпляр по примеру:

alisa N1 (.d(bob.N1.q), .q(bob.N2.d)); и т.д.

Таким образом вы забыли о создании экземпляров.

Да, в моем посте отсутствуют имена экземпляров, тк приводил псевдокод с инстансами разных модулей. Имел в виду ссылки именно на экземпляры, а не на описания модулей. Для нескольких инстансов однотипных модулей предполагал так:

alisa a ( .d(b1.q), .q(b2.d) );  
bob b1 ( .d(a.q), ... ); 
bob b2 ( ... ); и т.д.

те цепи определяются по именам экземпляров и портов, без имен модулей.

 

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

Не номер, а имя экземпляра. Или номер элемента массива экземпляров, тк Верилог позволяет создавать массивы инстансов без использования generate.

 

ОК, дальше мы идем на уровень выше. В вашей главной схеме может существовать десятки подсхем с экземплярами модулей которые могут иметь одинаковые идентификатор. То есть должно быть строгое пространство имен и ссылок

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