Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Документация на System Verilog
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Языки проектирования на ПЛИС (FPGA)
Страницы: 1, 2, 3, 4, 5, 6
des333
Цитата(CaPpuCcino @ Apr 30 2009, 21:16) *
...
вариант с прекомпилятором использовать не хочется, хотчется языковыми средствами.
спб



Встала аналогичная задача, только коммутировать интерфейсы необходимо динамически во время работы(в железе).
То есть вариант с прекомпилятором отпадает в принципе.

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


Заранее спасибо!
CaPpuCcino
Цитата(des333 @ Jun 4 2009, 19:06) *
Встала аналогичная задача, только коммутировать интерфейсы необходимо динамически во время работы(в железе).

на мой взгляд подобное языковыми средствами не решается. динамическая коммутация в железе - это полноценный блок-коммутатор, т.е. отдельное устройство (поправте, плз., если я заблуждаюсь).
IL-76
А не мог бы кто-нибудь выложить на рапидшару или подобный сервис "SystemVerilog For Design: A guide to using SystemVerilog for HW design and Modeling. Stuard Sutherland, Simon Davidmann // Kluwer Academic Publishers"?

Доступа к фтп не имею, а хотелось бы почитать..
MaOR
SV for Design
IL-76
Большое спасибо, MaOR
des00
господа проясните следующий момент, какой по вашему мнению должен быть результат в outb/outg

CODE

module test_bad (input logic zero, sign, input logic signed [15 : 0] idat, output logic signed [23 : 0] odat);

assign odat = zero ? '0 : (sign ? -idat : idat);

endmodule

module test_good (input logic zero, sign, input logic signed [15 : 0] idat, output logic signed [23 : 0] odat);

always_comb begin
if (zero)
odat = '0;
else
odat = (sign ? -idat : idat);
end

endmodule

module tb ;

logic zero, sign;
logic signed [15 : 0] idat;
logic signed [23 : 0] odatb;
logic signed [23 : 0] odatg;

test_bad uutb (.odat(odatb), .*);
test_good uutg (.odat(odatg), .*);


initial begin : main
#10ns;
zero = 1'b0;
sign = 1'b1;
idat = 1;
#10ns;
zero = 1'b0;
sign = 1'b1;
idat = -1;
#10ns;
zero = 1'b0;
sign = 1'b0;
idat = 1;
#10ns;
zero = 1'b0;
sign = 1'b0;
idat = -1;
#10ns;
$stop;
end
endmodule


квеста 6.4с считает вот так (см аттач). Исходя из битов odatb вообще не понятно как она думает. А квартус считает что в test_bad при инверсии надо делать беззнаковое расширение, не смотря на то, что результат операции знаковый. Посмотрел стандарт вроде все должно быть наоборот. Т.е. по правилам приведения операндов в test_bad должно быть знаковое расширение. Или я ошибаюсь?

PS. вопрос снимается, все по стандарту. сам дурак.

Цитата
SystemVerilog adds the ability to specify unsized literal single-bit values with a preceding apostrophe ( ’ ), but without the base specifier. All bits of the unsized value are set to the value of the specified bit. In a self-determined context, these literals have a width of 1 bit, and the value is treated as unsigned


будте внимательны
Builder
Вот, наткнулся на упоминание SystemVerilog 2009, по ссылкам кратко некоторые нововведения:
http://www.sunburst-design.com/papers/DAC2...burstDesign.pdf
http://www.sunburst-design.com/papers/DAC2...therlandHDL.pdf
Думаю будт интересно, кто на SV пишет.
des00
Цитата(Builder @ Nov 12 2009, 06:19) *
Вот, наткнулся на упоминание SystemVerilog 2009, по ссылкам кратко некоторые нововведения:
http://www.sunburst-design.com/papers/DAC2...burstDesign.pdf
http://www.sunburst-design.com/papers/DAC2...therlandHDL.pdf
Думаю будт интересно, кто на SV пишет.


работа над ошибками ассертов понравилась, про перегрузку функций так и не заикаются %(

Занятно у альдека использование $info/$warning/$error/$fatal было не привязано к ассертам (в отличии от ментора) как в воду глядели, а может быть и баг ставший реальностью %)

PS. надо готовиться к валу вопросов на форуме типа "почему не собирается" %)

Код
always_ff @(edge clk, posedge rst)
  if (rst)
    pipa <= '0;
  else
   pipa <= popa;
end
CaPpuCcino
Цитата(des00 @ Nov 16 2009, 09:07) *
PS. надо готовиться к валу вопросов на форуме типа "почему не собирается" %)

biggrin.gif
можно успокоиться только тем, что ещё относительно не скоро
CaPpuCcino
Цитата(Builder @ Nov 12 2009, 15:19) *
Вот, наткнулся на упоминание SystemVerilog 2009, по ссылкам кратко некоторые нововведения:

наткнулся в новом стандарте на интересную лазейку для параметризирования типов данных(если я, конечно, ничего не попутал):
пользовательский тип можно определять через ссылку на тип объявленный в теле интерфейса при условии, что этот интерфейс воткнут в модуль. Если параметризировать интерфейс типом(ами), то получим параметризируемые структуры данных. по-моему забавно smile.gif
Код
interface #(parameter type templatization_type_pt = int, parameter int size_p=8 )type_templated_if;
   typedef templatization_type_pt templated_array_type_t[size];
endinterface

module my_m(type_templated_if my_if);
   typedef my_if.templated_array_type_t my_templated_array_t;
   my_templated_array_t my_typed_array;
endmodule
torik
А у меня вот такой вот вопрос...

Код
reg                    global_prereset;            //reset for PLL
reg            [27:0]    global_prereset_reg;        //reset delay reg
initial begin
    global_prereset = 0;
    global_prereset_reg = 0;
end
always    @(posedge CLK_50) begin : global_prereset_build
    if (global_prereset_reg < (global_def :: GLOBAL_RESET_DELAY)) begin
        global_prereset <= 1;
        global_prereset_reg++;
    end else global_prereset <= 0;
end


Тут по правилам Verilog, объявляю переменную типа reg. Она может иметь 4 состояния, поэтому моделсим показывает неопределенное состояние этих сигналов, если не сделать initial.

Теперь вместо reg назовем переменную logic, результат такой же как и для reg, т.е. опять нужен initial.
Если же назвать переменные bit, которые могут принимать лишь 2 значения - 0 и 1, то все прекрасно работает без initial.

Необходима ли инициализация переменных типа bit, и какое значение она примет "по-умолчанию"?


Дальше я что-то вообще запутался.
В Verilog, можно написать
Код
assign a = 10;

если а объявлена как wire
и можно написать
Код
always @(posedge CLK) a <= 10;

если а объявлена как reg
Вроде бы, можно сказать, что wire - это просто соединение, а reg - комбинационная логика, на ней уже можно строить тригеры и прочее.

Для SV переменные bit и logic можно использовать где угодно. Что это означает? Просто более абстрактный подход, типа компилятор сам решит во что превратить переменную? Прошу специалистов разъяснить...





Цитата
A 4-state
variable can be explicitly declared using the keyword pair var
logic. For example:
Код
var logic [63:0] addr; // a 64-bit wide variable

A Verilog net type defaults to being a 4-state logic data type. A net
can also be explicitly declared as a 4-state data type using the logic
keyword. For example:
Код
wire logic [63:0] data; // a 64-bit wide net


Ква ругается на вторую, а первая прокатывает blink.gif

Простите за разговорчивость. Нашел ответ на первую часть вопроса:
Цитата
All 2-state date types begin simulation with a logic 0. Since 2-state
types do not store an X value, they cannot represent an unitialized
state. This is one of the reasons that it is preferable to use 4-state
types to represent synthesizable RTL models.
CaPpuCcino
Цитата(torik @ Dec 9 2009, 23:06) *
Теперь вместо reg назовем переменную logic, результат такой же как и для reg, т.е. опять нужен initial.
Если же назвать переменные bit, которые могут принимать лишь 2 значения - 0 и 1, то все прекрасно работает без initial.

вы ещё забываете о таком замечательном действии как инлайн инициализация
Код
reg x=1'b0;
в этом случае переменная приобретает значение ещё до начала симуляционного времени (initial, если я не ошибаюсь, тоже присваивает значение до модельного времени//конечно если не стоит задержка #0)
Цитата(torik @ Dec 9 2009, 23:06) *
Вроде бы, можно сказать, что wire - это просто соединение, а reg - комбинационная логика, на ней уже можно строить тригеры и прочее.

противопоставлять wire и reg/bit некорректно, корректно противопоставлять wire и var, т.е. есть типы данных(reg, int, string, my_type) и есть вид(или класс или тип) объекта(сигнал/переменная/параметр/макрос-переменная(genvar))
типам данных присущи множества/диапазоны значений и структура;
классы объекта составляют парадигму языка. ну например, genvar - это переменная препроцессора, параметр - переменная времени компиляции, сигналу присущи свойства уровнем абстракции ниже логического(физические свойства) и у сигнала нет дискретного во времени состояния, т.е. действительно похож на провод: если его подключить к источнику, то по нему течёт ток, если изменить скачко образно силу тока, то по нему будет теч ток другой силы, но всё равно будет течь непрерывно, хотя уровень тока кака-будто бы дискретно изменился, а если его отключить от источника, то не будет течь никакой, т.е. у сигнала нет состояния в прошлом/настоящем/будущем у него есть только одно состояние "всегда", т.е. у сигнала нет памяти как у переменной; но говоря о памяти переменной ни в коем случае нельзя понимать её как память в модельном времени - т.е. как регистр/зачёлку, а только как память языковой парадигмы. лучше всего это показать на примере:
Код
(var) int a;
always_comb
  begin
    a=b;
    a=a+1;
    a=a**2;
    a=a-1;
  end

это не запоминающий элемент на практике, а комбинационная схема, что же помнит тогда a? а помнит своё предыдущее состояние (кстати, не только самое последнее, и даже не только прошлое).
то что при помощи переменной можно описать физическую память, это только производная от её свойств как класса объекта.
почему происходит постоянная путаница между этими понятиями? потому, что по умолчанию всё что явно не декларировано как сигнал, является переменной. т.е. int a; на самом деле это var int a;
при этом необходимо помнить, что не корректно говорить об исключительном противопоставрении var - wire, так как по сути говоря, сигналы существуют 12 типов (по их "физическим" свойствам) т.е. корректное противопоставление было бы var - {wire,wor,wand,tri,,supply0 ...}
чем отличается сигнал от переменной на практике:
- сигнал может иметь несколько драйверов, переменная нет (т.е. синалу можно присваивать несколько значений одновременно, правило разрешения определит каким будет результирующее значение множественного присваивания), при этом переменной можно присваивать значения в нескольких блоках, однако это не будет считаться одновременным присваиванием, т.к. действует правило "кто прследний тот и папа" (но при этом если переменной присваивается значения оператором непрерывного присваивания, то это может быть только единственным присваиванием этой переменной);
- т.к. сигнал не может хранить значение ему нельзя присваивать значения в процедурных блоках, а только в операторах непрерывного присваивания assign (присваивание при объявлении сигнала и соединение с портом для сигнала считаются непрерывными присваиваниями), в то же время переменной можно присваивать значение в любых типах блоков а также оператором непрерывного присваивания assign, но если существует непрерывное присваивание, то это может быть единственным присваиванием данной переменной;
- переменная не может быть соединена с портом inout;
torik
Цитата
вы ещё забываете о таком замечательном действии как инлайн инициализация


Ага, периодически забываю, спасибо. Инлайн инициализация, насколько я понял, тождественна initial? В размере кода я разницы не заметил...



Вот такая штука не катит, почему? Особенность ква?
Код
wire logic sdfgsdfg;


Ну и насчет переменных bit с двумями состояниями. Вычитал, что такие переменные необходимы вобщем-то для тестбенчей.
Если использовать их в тестбенче, а подключать к ним сигналы logic тестируемого модуля, не получится ли что можно упустить при моделировании некие моменты, связанные с начальной инициализацией?
des00
уважаемый CaPpuCcino сильно пошел в теорию, вот на пальцах

Цитата(torik @ Dec 10 2009, 02:02) *
Аот такая штука не катит, почему? Особенность ква?
Код
wire logic sdfgsdfg;


потому что wire/wand/wor/wxor/tri/... это декларация сигнала-цепи, а bit/logic/reg/enum/class..... это декларация переменной. Вы пытаетесь их смешивать. К цепям можно использовать только длительные присвоение (assign), а переменным любые.

Цитата(torik @ Dec 10 2009, 02:02) *
Ага, периодически забываю, спасибо. Инлайн инициализация, насколько я понял, тождественна initial? В размере кода я разницы не заметил...


вы про RTL ? там это монописуально, а вот в tb разница есть

Цитата
Если использовать их в тестбенче, а подключать к ним сигналы logic тестируемого модуля, не получится ли что можно упустить при моделировании некие моменты, связанные с начальной инициализацией?


вы правы, тут надо смотреть как работает ваше железо и помнить что bit вектора/массивы весят как минимум в 2 раза меньше чем они же но на logic/reg. Имеется в виду память симулятора %)
torik
Цитата
потому что wire/wand/wor/wxor/tri/... это декларация сигнала-цепи, а bit/logic/reg/enum/class..... это декларация переменной. Вы пытаетесь их смешивать. К цепям можно использовать только длительные присвоение (assign), а переменным любые.


В книжке "Springer - SystemVerilog for Design, 2nd Edition" говорится, что wire, var - это тип. А logic/bit - это тип данных.
По-умолчанию, wire - 4 состояния, т.е. logic. Но можно и явно указать wire logic, так ниписано в книге. Верно? Т.к. wire может быть только 4 состояния и не иначе, то запись logic вроде излишняя, но дело принципа...

Цитата
вы про RTL ? там это монописуально, а вот в tb разница есть

Расшифруйте неразумному, пожалуйста, что такое tb...
des00
Цитата(torik @ Dec 10 2009, 04:12) *
В книжке "Springer - SystemVerilog for Design, 2nd Edition" говорится, что wire, var - это тип. А logic/bit - это тип данных.


потому что читать надо стандарты (ничего не имею против вашей книги, но лучше бы вы начали со стандарта). wire, var это вид ОБЪЕКТА. wire/wand/wor это типы объекта вида "цепь(net)", а logic/bit это типы объекта вида "переменная(variable)".

IEEE 1800-2005 -> 6. Data declarations -> 6.1 Introduction

Цитата
NOTE—There are several forms of data in SystemVerilog: literals (see Clause 3), parameters, constants, variables, nets, and attributes (see 4.17). A data object is a named entity that has a data value associated with it, such as a parameter, a variable, or a net.
Verilog constants are literals, genvars parameters, localparams, and specparams. Verilog also has variables and nets. Variables must be written by procedural statements, and nets must be written by continuous assignments or ports. SystemVerilog extends the functionality of variables by allowing them to be either written by procedural statements or driven by a single continuous assignment, similar to a wire. Because the keyword reg no longer describes the user’s intent in many cases, the keyword logic is added as a more accurate description that is equivalent to reg. See 6.9.2 for details on SystemVerilog type equivalence rules. Verilog has already deprecated the use of the term register in favor of variable.


Цитата
По-умолчанию, wire - 4 состояния, т.е. logic. Но можно и явно указать wire logic, так ниписано в книге. Верно? Т.к. wire может быть только 4 состояния и не иначе, то запись logic вроде излишняя, но дело принципа...


если у кошки 4 ноги то это собака верно ? ног то 4ре.

Цитата
Расшифруйте неразумному, пожалуйста, что такое tb


tb сокращение от testbench
torik
Ну вот, спасибо. Все стало гораздо понятнее smile.gif
CaPpuCcino
Цитата(des00 @ Dec 10 2009, 14:50) *
потому что читать надо стандарты (ничего не имею против вашей книги, но лучше бы вы начали со стандарта). wire, var это вид ОБЪЕКТА. wire/wand/wor это типы объекта вида "цепь(net)", а logic/bit это типы объекта вида "переменная(variable)".

Денис, ты не прав. Не помню с какого именно стандарта, но подход к типам объекта изменили принципиально. Ква просто работает по старинке и вот такое объявление он должен кушать хорошо и считать это объявлением цепи
Код
wire logic sdfgsdfg;

сейчас принцип такой: есть объекты типа цепь-net(то что я называю сигнал) и типа переменная-var. понятие типа объекта от понятия типа данных принципиально отмежёваны.
для обратной совместимости с V был введён следующий принцип:
- объекты "цепь" по умолчанию являются logic(тип данных) => wire a; <-> wire logic a;
- всё что явно не объявлено объектом типа "цепь" является var(класс объекта) => logic a; <-> var logic a;
(из-за того, что в одном случае по умолчанию назначается тип данных а в другом случае по умолчанию назначается тип объекта, и приводит к путаннице, но ещё раз повторюсь - мера вынужденная, иначе не было бы обратной совместимости)
((кстати тип данных по умолчанию назначается и переменной, но для этого должен быть явно назначен тип объекта var a; <-> var logic a;))
т.о. torik прав, предъявляя претензию к Ква

Цитата(torik @ Dec 10 2009, 14:12) *
Верно? Т.к. wire может быть только 4 состояния и не иначе, то запись logic вроде излишняя, но дело принципа...

верно

Цитата(torik @ Dec 10 2009, 12:02) *
Инлайн инициализация, насколько я понял, тождественна initial?

верно. initial (как между прочем и assign) зепускаются до начала модельного времени(для assign это сделано для распространения констант по цепи). этот принцип был введён с 2005, до этого initial запускался вначале модельного времени.
т.е. initial a=0; образца 1995года эквивалентен initial #0 a=0; образца 2005 года.
а int a=0; образца 2005 эквивалентен initial a=0; образца 2005, но не эквивалентен initial a=0; образца 1995
des00
Цитата(CaPpuCcino @ Dec 10 2009, 07:17) *
Денис, ты не прав. Не помню с какого именно стандарта, но подход к типам объекта изменили принципиально.


Да был не прав, уже с 2005 у цепей появились типы. Сказывается то, что я цепи не использую в работе (кроме inout портов, что в моих проектах редкость). Не совсем мне понятно зачем они это сделали, навскидку приходит только один случай когда типы цепей полезны, т.е. без цепей задача решается некрасиво.

Цитата
Ква просто работает по старинке и вот такое объявление он должен кушать хорошо и считать это объявлением цепи.


Он работает не по старинке, а потому что SV на него натянули сняв ограничения по assign на цепи и добавив bit/logic. Это старый баг.

Цитата
т.о. torik прав, предъявляя претензию к Ква


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

Цитата
верно. initial (как между прочем и assign) зепускаются до начала модельного времени(для assign это сделано для распространения констант по цепи). этот принцип был введён с 2005, до этого initial запускался вначале модельного времени.
т.е. initial a=0; образца 1995года эквивалентен initial #0 a=0; образца 2005 года.
а int a=0; образца 2005 эквивалентен initial a=0; образца 2005, но не эквивалентен initial a=0; образца 1995


Могу ошибаться но если мне память не изменяет то inline инициализации исполняются еще до любого initial. Именно на этом построен запуск OVM окружения. Чуть позже посмотрю стандарт на эту тему.
torik
Цитата
я бы без необходимости не спешил использовать все SV выверты, вдруг проект портировать под чистый верилог потребуется....


Учту.
Цитата
Могу ошибаться но если мне память не изменяет то inline инициализации исполняются еще до любого initial. Именно на этом построен запуск OVM окружения. Чуть позже посмотрю стандарт на эту тему.


Вроде того?:
Код
The SystemVerilog standard enhances the semantics for in-line
variable initialization. SystemVerilog defines that all in-line initial
values will be evaluated prior to the execution of any events at the
start of simulation time zero. This guarantees that when initial
or always procedural blocks read variables with in-line initialization,
the initialized value will be read. This deterministic behavior
removes the ambiguity that can arise in the Verilog standard.
des00
Цитата(torik @ Dec 10 2009, 11:39) *
Вроде того?:


100% ое попадание %)
torik
Господа специалисты. Не могли бы пояснить по-русски, что значит сие:

Цитата
Verilog’s nondeterministic order for variable initialization can
result in nondeterministic simulation behavior for asynchronous
reset or preset logic in sequential models. This nondeterminism can
affect resets or presets that are applied at the beginning of simulation.


Этот недертерминизм может повлиять на сброс или предустановку в начале симуляции. Чё, как это более простым русским языком сказать? Мне слово детерминизм вообще непонятно)))
des00
Цитата(torik @ Dec 14 2009, 00:17) *
Господа специалисты. Не могли бы пояснить по-русски, что значит сие:



Этот недертерминизм может повлиять на сброс или предустановку в начале симуляции. Чё, как это более простым русским языком сказать? Мне слово детерминизм вообще непонятно)))


IEEE Std 1364-2001 -> 5. Scheduling semantic -> 5.4 The Verilog simulation reference model -> 5.4.1 Determinism/5.4.2 Nondeterminism а лучше весь раздел 5 прочитать %)
CaPpuCcino
Цитата(CaPpuCcino @ Nov 21 2009, 22:19) *
наткнулся в новом стандарте на интересную лазейку для параметризирования типов данных(если я, конечно, ничего не попутал):
пользовательский тип можно определять через ссылку на тип объявленный в теле интерфейса при условии, что этот интерфейс воткнут в модуль. Если параметризировать интерфейс типом(ами), то получим параметризируемые структуры данных. по-моему забавно smile.gif

каюсь - проглядел. эта возможность присутствует ещё в 2005
Andy-P
Вопрос по методам в интерфейсах от новичка.

Только закончил читать SystemVerilog for Design. Последующие цитаты из этой книги.

Modules that use tasks or functions imported from interfaces are synthesizable. Synthesis will infer a local copy of the imported task or function within the module. The post-synthesis version of the module will contain the logic of the task or functions; it will no longer look to the interface for that functionality.

Следовательно, локальная копия задачи или функции внутри модуля будет иметь пространство имен ограниченное этим модулем. Задача или функция может быть объявлена static (за исключением случаев, где явно нужен automatic) и одни и те же имена переменных, с которыми работает задача или функция в разных модулях являются независимыми. Однако..

Imported tasks or functions must be declared as automatic and not contain static declarations in order to be synthesized.

1. Почему импортируемая задача или функция должна быть обязательно automatic и не содержать static деклараций?

Предугадывая куда меня могут отправить, сходил туда добровольно... biggrin.gif
Увы, стандарт в части п. 20.6 не пролил для меня свет на этот вопрос.

Цитируемое выше имеет отношение к импортируемым методам. Я пользуюсь Квартусом, который поддерживает синтез интерфейсов с методами, а также с modport, но при этом импорт (и, конечно, экспорт) задач или функций не допустим. Т.е., доступ к методам со стороны модулей, подключаемых к интерфейсу, не имеет ограничений.

2. Для задач или функций, которые не импортируются явно через import, синтезатор также сделает локальную копию в использующем их модуле?
3. Эти задачи или функции также должны быть определены как automatic и не содержать static деклараций?


И еще один момент...

When no modport is specified as part of the connection to the interface, all nets in the interface are assumed to have a bidirectional inout direction, and all variables in the interface are assumed to be of type ref.

Тип порта ref не синтезируемый. Однако..

If no modport is specified when the model is synthesized, then all signals within the interface become bidirectional inout ports on the synthesized module.

4. Если не определен modport, то на этапе моделирования все переменные интерфейса имеют тип ref, а на этапе синтеза они же становятся inout. Это верно?
5. Если да, то не приведет ли это к разным результатам при моделировании и при синтезе?


Посоветуйте софт с хорошей поддержкой SV для моделирования, симулирования, и, возможно, для синтеза (в паре с Квартусом)
des00
Цитата(Andy-P @ Dec 24 2009, 07:25) *
1. Почему импортируемая задача или функция должна быть обязательно automatic и не содержать static деклараций?
3. Эти задачи или функции также должны быть определены как automatic и не содержать static деклараций?[/i]

Вопрос не задан до конца, не хватает фразы "что бы быть синтезируемой". Тогда все встает на своим места. Это очевидно. Наличие static объектов, функций нарушает принципы объектного подхода в ХДЛ.

Цитата
2. Для задач или функций, которые не импортируются явно через import, синтезатор также сделает локальную копию в использующем их модуле?

Если мне память не изменяет вы пользуете либо модпорт, либо интерфейс. Область видимости определяется этим.

Цитата
Тип порта ref не синтезируемый. Однако..

а как вы себе представляете синтез ссылки(по сути копии адреса объекта), чем и является ref?

Цитата
4. Если не определен modport, то на этапе моделирования все переменные интерфейса имеют тип ref, а на этапе синтеза они же становятся inout. Это верно?

неверно, это как был inout, так и остался

Цитата
5. Если да, то не приведет ли это к разным результатам при моделировании и при синтезе?[/i]

если работать правильно то нет.

Цитата
Посоветуйте софт с хорошей поддержкой SV для моделирования, симулирования, и, возможно, для синтеза (в паре с Квартусом)


я использую ква + менторовские симуляторы, хотя давно смотрю на vcs %)

ЗЫ. Если вам интересно мое мнение, я бы не использовал интерфейсы еще годика 2-4. Не всегда они нужны, да и корректность их синтеза дело темное smile.gif
dxp
Цитата(des00 @ Dec 24 2009, 20:39) *
ЗЫ. Если вам интересно мое мнение, я бы не использовал интерфейсы еще годика 2-4. Не всегда они нужны, да и корректность их синтеза дело темное smile.gif

Возражаю. smile.gif Хотя синтезируемость пока не достигнута в полной мере, использовать уже можно и это реально помогает. Квартус вполне корректно синтезирует интерфейсы (сделали проект, полет нормальный) в базовом варианте (т.е. без generate, task'ов и прочего). Еще в 8-м ква была проблема с массивами интерфейсов, что огорчило, пришлось руками их все расписывать (но и это лучше, чем таскать десятки однотипных строк). В 9-ке пока не проверял эту возможность. Т.ч. ограничивать применение интерфейсов имеет смысл, если нужна переносимость на синтезаторы, которые не поддерживают такие возможности языка. А на ква уже можно.
des00
Цитата(dxp @ Dec 24 2009, 22:48) *
Возражаю. smile.gif Хотя синтезируемость пока не достигнута в полной мере, использовать уже можно и это реально помогает. Квартус вполне корректно синтезирует интерфейсы (сделали проект, полет нормальный) в базовом варианте (т.е. без generate, task'ов и прочего). Еще в 8-м ква была проблема с массивами интерфейсов, что огорчило, пришлось руками их все расписывать (но и это лучше, чем таскать десятки однотипных строк). В 9-ке пока не проверял эту возможность. Т.ч. ограничивать применение интерфейсов имеет смысл, если нужна переносимость на синтезаторы, которые не поддерживают такие возможности языка. А на ква уже можно.


Ни капли не сомневаюсь что иногда интерфейсы полезны, но при их применении надо учитывать

1. переносимость. не все синтезаторы вас поймут.
2. необходимость. например если интерфейс используется для соединений уникальных модулей вида точка-точка. Будет куча уникальных интерфейсов, что даст сплошную головную боль. Те же задачи лучше решить структурами или массивами портов Ну и делать интерфейс для 3-4 проводов смысла нет.
3. ограниченность. интерфейсы это не тип сигнала, а отдельный объект + они не наследуются.

Т.е. ситуаций, где интерфейсы реально помогают, а не делают вид что помогают достаточно мало. И выбирать что использовать надо с умом, что бы потом спешкодрапом не править свой проект.

ЗЫ. ситуацию хака "интерфейс :: параметризуемая функция" не рассматриваю.

UPD. Еще мне не нравиться вот такая ситуация, я называю это "парадокс интерфейсов". Накувыркался с ним много когда с разными шинами заморачивался для себя. Интерфейсы соединяются по ссылкам на интсансы интерфейсов. Ссылаться можно только на интерфейс того же типа. Теперь рассмотрим шину Wishbone. Есть мастер порты, которые торчат из мастеров и есть слев порты которые торчат в слейвы. Без расплетения веника вы не сможете соединить напрямую мастер и слейв. Пусть вы возьмете модуль интерконнекта, выглядеть будет красивее. Но все равно эти веники расплетаются и заплетаются у него внутри. Или возьмете мастер/слейв с разной разрядностью, потребуется опять конверсия в рукопашку. Это я к тому что соединение на интерфейсах это не банальные slave = master. Это много сложнее и об этом надо помнить %)
CaPpuCcino
Цитата(des00 @ Dec 25 2009, 08:30) *
Это я к тому что соединение на интерфейсах это не банальные slave = master. Это много сложнее и об этом надо помнить %)
проще сказать, что интерфейс это не шина (кстати он имено так и называется interface а не bus).
чтобы хорошо понимать разницу, см. понятие класса интерфейса в ООП (например тут http://ru.wikipedia.org/wiki/Интерфейс_(ООП) ).
ЗЫ: использую интерфейсы постоянно и несказанно рад этой возможности. проблему портируемости на разные компиляторы решаю инструкциями прекомпилятору(пока получается двойная работа)
Andy-P
Цитата
Если вам интересно мое мнение, я бы не использовал интерфейсы еще годика 2-4. Не всегда они нужны, да и корректность их синтеза дело темное smile.gif

Конечно, мне очень интересно ваше мнение. Именно ваш ответ я и ожидал. Вы и CaPpuCcino здесь из самых опытных и активных. CaPpuCcino, наверное, в Кёлне, а там Рождество...

На данный момент у меня сложилось представление об интерфейсе, как о средстве существенно упрощающем написание дизайна и при этом практически не представляющего сложности для синтеза. Поясню. Цепи и переменные, объявленные в интерфейсе, как с дополнением направлений через modport, так и без оного, переносятся в модуль, подключенный к данному интерфейсу. Т.е., у модуля заменяется интерфейсный порт на привычную декларацию портов. Задачи и функции, определенные в интерфейсе и импортируемые через modport-import, также получают свои локальные копии в подключенном к интерфейсу модуле. После выполнения этих операций этот модуль выглядит так, как будто был написан на Verilog-95/01 без применения интерфейсов. Что в этом представлении ошибочного, раз вы считаете синтез интерфейсов делом темным?

Цитата
Цитата
Цитата(Andy-P @ Dec 24 2009, 07:25)
1. Почему импортируемая задача или функция должна быть обязательно automatic и не содержать static деклараций?
3. Эти задачи или функции также должны быть определены как automatic и не содержать static деклараций?

Вопрос не задан до конца, не хватает фразы "что бы быть синтезируемой". Тогда все встает на своим места. Это очевидно. Наличие static объектов, функций нарушает принципы объектного подхода в ХДЛ.

К сожалению, мне не очевидно. Первая цитата из книги – утверждение, на основании которого было логично предположить, что локальная копия задачи или функции внутри модуля будет иметь пространство имен ограниченное этим модулем. Задача или функция может быть объявлена static (за исключением случаев, где явно нужен automatic) и одни и те же имена переменных, с которыми работает задача или функция в разных модулях являются независимыми.
Эти рассуждения противоречат второй цитате, поэтому и возник первый вопрос, разумеется в контексте синтезируемости.

Цитата
Цитата
2. Для задач или функций, которые не импортируются явно через import, синтезатор также сделает локальную копию в использующем их модуле?

Если мне память не изменяет вы пользуете либо модпорт, либо интерфейс. Область видимости определяется этим.

Не про область видимости я интересовался...
В первой цитате есть явная оговорка именно о импортируемых (в отличие от не импортируемых) задачах и функциях, для которых синтезатор делает локальную копию в подключенный модуль. Квартус не позволяет делать импорт, поэтому интересуюсь: так будет или нет локальная копия задачи или функции в подключенном модуле. Если копия будет, то получается аналогичная ситуация моего не понимания необходимости автоматических задач и функций. Если копии не будет, тогда мне понятно, зачем задачи и функции должны объявляться автоматическими.

Цитата
Цитата
Тип порта ref не синтезируемый. Однако..

а как вы себе представляете синтез ссылки(по сути копии адреса объекта), чем и является ref?

Синтез ссылки я себе также не представляю и такого вопроса не задавал. В моем тексте это было утверждение противопоставляющее третью и четвертую цитаты из книги.

Цитата
Цитата
4. Если не определен modport, то на этапе моделирования все переменные интерфейса имеют тип ref, а на этапе синтеза они же становятся inout. Это верно?

неверно, это как был inout, так и остался

Авторы утверждают (третья цитата), что когда не определен modport (т.е. не заданы направления) все nets становятся inout, а все var становятся ref.
Моделировать это можно, но синтезировать нет, так как все тот же ref.
Далее авторы пишут (четвертая цитата), что если в этих же условиях отсутствия modport выполняется синтез то все signals становятся inout и синтез выполняется. Т.е., то что было ref стало inout. Почему бы не универсально: все net и var сразу в inout? Но вы уверяете, что это не приведет к разным результатам pre- and post-syntethis, если правильно работать. Хорошо, буду внимательным smile.gif

Цитата
я использую ква + менторовские симуляторы, хотя давно смотрю на vcs %)

У меня похожая ситуация, но ModelSim вместо Questa.
VCS – симулятор. Для моделирования Synopsys позиционирует Syphony HLS. Ни тот, ни другой не пробовал. Может у вас есть комментарий?
Что скажете о Synplify или Quartus сам по себе не хуже?
des00
Цитата(Andy-P @ Dec 25 2009, 05:58) *
Вы и CaPpuCcino здесь из самых опытных и активных.

СкАжите тоже, просто чуть больше читаем/читали %)

Давайте разберемся по порядку. Начнем со static и в чем потенциальные сложности для синтеза. В SV квалификатор static описывает время жизни объекта. Для освежения памяти обратимся к стандарту IEEE 1800-2007 -> 6.6 Scope and lifetime.
Цитата
Any data declared outside a module, interface, task, or function are global in scope (can be used anywhere after its declaration) and have a static lifetime (exist for the whole elaboration and simulation time).
SystemVerilog data declared inside a module or interface, but outside a task, process, or function, are localin scope and static in lifetime (exist for the lifetime of the module or interface). This is roughly equivalent to C static data declared outside a function, which is local to a file.
Data declared in an automatic task, function, or block have the lifetime of the call or activation and a local scope. This is roughly equivalent to a C automatic variable.
Data declared in a static task, function, or block default to a static lifetime and a local scope.
....
SystemVerilog also allows data to be explicitly declared as static. Data declared to be static in an automatic task, function, or block have a static lifetime and a scope local to the block. This is like C static data declared within a function.
...
It is permissible to hierarchically reference any static variable unless the variable is declared inside an unnamed block. This includes static variables declared inside automatic tasks and functions.

Теперь смотрите что происходит когда в интерфейсе есть статическая функция. Интерфейс объект статический, импортировать функции вы можете в любые объекты. Тогда что вам мешает через переменную в статической функции передать информацию из одного модуля в другой? Или разделить переменную между модулями? Ведь с точки зрения языка все верно. Но при синтезе возникает парадигма ХДЛ : модули могут обмениваться сигналами только через порты ввода/вывода. В случае использования интерфейса он рассматривается как веник проводов и обмен идет через него. Использование статических функций это потенциальная мина, так же как и использование глобальных сигналов в SV/VHDL, ИМХО поэтому возможность синтеза таких объектов и не рассматривается.

Теперь про SV объекты вида интерфейс.
Если рассматривать интерфейс как веник проводов, а массив интерфейсов как массив веников проводов, то никаких проблем синтеза нет, за исключением возможных багов синтезатора с его сборкой/разборкой. Но ИМХО как только вы пойдете дальше: импорт/экспорт функций, которые работают с сигналами интерфейса, выражения в модпортах, прототипы функций и т.д. В общем все то что дает синтезатору большую свободу чем "взять этот сигнал и подцепить его к этому" ждите сюрпризов. Я считаю что лучше я потрачу немного времени сейчас, чем потом потрачу много больше времени что бы выяснить что не так или почему при апдейте синтезатора все сломалось.
Кроме того, как уже говорил я достаточно критично отношусь к необходимости применения интерфейса, особенно при point-point соединениях. Вопросы увеличения скорости разработки я решил другими методами. В моих проекта в среднем ~20-30 портов на модуль, на его вставку/подключение у меня уходит не больше 5/30 секунд. Также мне иногда приходиться переводить свои модули по чистый V, при моем стиле описания на это тоже уходим мало времени %)

В общем решать вам. Свою точку зрения я озвучил.

Цитата
Авторы утверждают (третья цитата), что когда не определен modport (т.е. не заданы направления) все nets становятся inout, а все var становятся ref.

Книгу эту читал давно, надо смотреть контекст. Но посмотрите шире на интерфейс. Ведь не обязательно использовать все сигналы интерфейса для интреконнекта. Например для отладки я делал интерфейс-память. Т.е. в интерфейсе была логика синхронной памяти (по некоторым источникам это даже синтезируемо). Думаю насчет ref авторы как раз и имели в виду использование переменных интерфейса, которые не используются для интерконнекта.

Цитата
Но вы уверяете, что это не приведет к разным результатам pre- and post-syntethis, если правильно работать. Хорошо, буду внимательным smile.gif

Когда я пишу я стараюсь четко понимать какой будет результат синтеза той или иной конструкции. Если мы расходимся во мнениях с синтезатором, то начинаю смотреть почему. ИМХО чем "прямолинейнее" написан код тем результат синтеза более однозначен.

Цитата
У меня похожая ситуация, но ModelSim вместо Questa.
VCS – симулятор. Для моделирования Synopsys позиционирует Syphony HLS. Ни тот, ни другой не пробовал. Может у вас есть комментарий?
Что скажете о Synplify или Quartus сам по себе не хуже?

Моделсим сильно кастирован в области поддержки SV моделирования. По VCS это к SM и yes. Использовал симплифай когда сидел на хилых, но на альтере мне хватает ква. SV он понимает получше некоторых + удобно бегать по разным вьюверам. Правда у него иногда бывают такие заскоки в синтезе, что лечиться только макросом и вставкой примитива целевой FPGA %)
dxp
Цитата(des00 @ Dec 25 2009, 11:30) *
Ни капли не сомневаюсь что иногда интерфейсы полезны, но при их применении надо учитывать

1. переносимость. не все синтезаторы вас поймут.

Я про это тоже упомянул - переносимость есть проблема в настоящее время для синтеза.

Цитата(des00 @ Dec 25 2009, 11:30) *
2. необходимость. например если интерфейс используется для соединений уникальных модулей вида точка-точка. Будет куча уникальных интерфейсов, что даст сплошную головную боль.

Почему даст головную боль? Если можно вынести какие-то пучки логически связанные между собой в другое место, а в точке применения заменить это одной строкой - это достойная цель. Это уменьшает загроможденность кода, повышает читабельность. Конечно, ради трех-четырех сигналов так делать не стоит, но когда их набирается с десяток, уже можно подумать. Хотя я так не делаю - лень мне. smile.gif

Цитата(des00 @ Dec 25 2009, 11:30) *
Те же задачи лучше решить структурами или массивами портов Ну и делать интерфейс для 3-4 проводов смысла нет.

Э-э.., как это структурами? Структура разве может быть портом? У структуры для того чтобы отправлять функции порта не хватает задания направления сигналов. Вот интерфейс эту проблему и решает. По сути, если грубо рассматривать, то интерфейс - это типа структуры, только с возможностью задания направлений сигналов (через модпорты).

Массив портов тоже проблемы не решает: массив - это всегда объект, содержащий объекты одинакового типа. А это далеко не все ситуации покрывает. Т.ч. эти средства - не альтернатива интерфейсам.


Цитата(des00 @ Dec 25 2009, 11:30) *
3. ограниченность. интерфейсы это не тип сигнала, а отдельный объект + они не наследуются.

А обычные порты наследуются, что-ли? smile.gif Я бы не стал в данном контексте ненаследуюемость относить к недостаткам. Интерфейс решает несколько другие задачи.


Цитата(des00 @ Dec 25 2009, 11:30) *
Т.е. ситуаций, где интерфейсы реально помогают, а не делают вид что помогают достаточно мало.

Вот не согласен! Мой пример. Есть у меня, скажем, контроллер памяти (там арбитр, SDRAM контроллер и т.д.), к нему из модулей есть доступ из энного количества мест - порядка 8. И нужно организовать указанное количество "сосок" к памяти. С буферизацией и прочим хозяйством. Тащит это пачку сигналов для коннекта: стартовый адрес для обращения, количество слов для транзакции, порт данных, сигнал загрузки данных в буфер, флаги буфера (FIFO), направление записи и т.д. и т.п. И вот приходилось весь этот набор сигналов таскать в портах модулей. А уж с именам-то танцы были - сигналы-то все похожие, придумать нормальные имена, чтобы из них было легко видно, что за сигнал и к чему относится, сами знаете, плохо формализуемая задача. Короче, решил попробовать реализовать это на интерфейсах и не пожалел. Код интерфейса (это для записи, для чтения чуть отличается, парой сигналов):

CODE

interface wr_agent_if;

bit start; // start write data from buffer to memory
bit up; // write direction
bit load; // load data to FIFO buffer enable signal
bit [ `ADDR_WIDTH-1:0] start_addr; // start address to writing
bit [ `DATA_WIDTH-1:0] data; //
bit [`COUNT_WIDTH-1:0] count; // number of words to write
bit busy; // busy flag, indicates that writing is in progress
bit [`COUNT_WIDTH-1:0] fifo_cnt; // number of word in FIFO
bit full; // FIFO full flag
bit empty; // fifo empte flag

modport agent
(
output start,
output up,
output load,
output start_addr,
output count,
output data,
input busy,
input fifo_cnt,
input full,
input empty
);

modport port
(
input start,
input up,
input load,
input start_addr,
input count,
input data,
output busy,
output fifo_cnt,
output full,
output empty
);

endinterface


А использование:

Код
module ...
    ...
    wr_agent_if.agent           sdr_wr,
    wr_agent_if.agent           bf_wr,
    ...


В итоге, никакой путаницы, порты модуля все как на ладони, прежнее нагромождение десятков однотипных сигналов вспоминаю как страшный сон.
des00
Цитата(dxp @ Dec 26 2009, 00:14) *
Почему даст головную боль? Если можно вынести какие-то пучки логически связанные между собой в другое место, а в точке применения заменить это одной строкой - это достойная цель. Это уменьшает загроможденность кода, повышает читабельность. Конечно, ради трех-четырех сигналов так делать не стоит, но когда их набирается с десяток, уже можно подумать. Хотя я так не делаю - лень мне. smile.gif

Читайте внимательнее то что я писал. Например проект, 30 модулей, на эти модули пусть будет 15 уникальных интерфейсов. Дальше работу можете представить...

Цитата
Э-э.., как это структурами? Структура разве может быть портом? У структуры для того чтобы отправлять функции порта не хватает задания направления сигналов. Вот интерфейс эту проблему и решает. По сути, если грубо рассматривать, то интерфейс - это типа структуры, только с возможностью задания направлений сигналов (через модпорты).

А кто ей запретит. Структура такой же тип данных как и все остальные типы. Да без направления, ну будет вместо одного интерфейса, две структуры. Как в VHDL.

Цитата
А обычные порты наследуются, что-ли? smile.gif Я бы не стал в данном контексте ненаследуюемость относить к недостаткам. Интерфейс решает несколько другие задачи.

если мне нужно расширить интерфейс модуля, то я вписываю именно то что мне надо в карту портов. А вот что вы будете делать если вам нужно к модулю с интерфейсом в 5 сигналов, добавить еще 5 сигналов из другого интерфейса? И опять все сведется к рукопашке.

Цитата
Вот не согласен! Мой пример.

Да конечно, мы все делаем 8ми портовые контроллеры памяти в каждом проекте..... Читайте внимательнее, ваш случай как раз тот, когда интерфейс вам помог. Но можно легко и просто было сделать и без интерфейсов. Не понимаю ваши танцы с именами

CODE

//
// component is wishbone system bus based upon crossbar switch architecture for pM_N masters and pS_N slaves
//

`include "define.vh"

module wb_cross
#(
parameter int pM_N = 4 ,
parameter int pS_N = 4 ,
parameter int pA_W = 32 ,
parameter int pD_W = 32 ,
parameter int pSEL_W = 4 ,
`ifdef MODEL_TECH
parameter bit [pA_W-1 : 0] pS_ADDR_BASE [0 : pS_N-1] = '{default : '0} ,
parameter bit [pA_W-1 : 0] pS_ADDR_MASK [0 : pS_N-1] = '{default : '0} ,
parameter bit [pM_N-1 : 0] pS_ACCESS_EN [0 : pS_N-1] = '{default : '1} ,
`else
parameter bit [pA_W-1 : 0] pS_ADDR_BASE [0 : pS_N-1] = '{32'h0000_0000, 32'h4000_0000, 32'h8000_0000, 32'hC000_0000} ,
parameter bit [pA_W-1 : 0] pS_ADDR_MASK [0 : pS_N-1] = '{32'h3FFF_FFFF, 32'h3FFF_FFFF, 32'h3FFF_FFFF, 32'h3FFF_FFFF} ,
parameter bit [pM_N-1 : 0] pS_ACCESS_EN [0 : pS_N-1] = '{4'hF , 4'hF , 4'hF , 4'hF } ,
`endif
parameter bit pS_ADDR_ERR_DISABLE = 0 , // disable slave address check logic
parameter bit pS_ACCESS_ERR_DISABLE = 0 , // disable slave access check logic
parameter bit pLOCK = 1
)
(
wb_clk ,
wb_rst ,
wb_m_cyc_i ,
wb_m_stb_i ,
wb_m_we_i ,
wb_m_adr_i ,
wb_m_dat_i ,
wb_m_sel_i ,
wb_m_ack_o ,
wb_m_err_o ,
wb_m_rty_o ,
wb_m_dat_o ,
wb_s_ack_i ,
wb_s_err_i ,
wb_s_rty_i ,
wb_s_dat_i ,
wb_s_cyc_o ,
wb_s_stb_o ,
wb_s_we_o ,
wb_s_adr_o ,
wb_s_dat_o ,
wb_s_sel_o
);


вот этот модуль я вставляю за 5 секунд, не путаюсь в именах и соединяю со схемой секунд за 30ть. %)

CODE

parameter int pM_N = 4 ;
parameter int pS_N = 4 ;
parameter int pA_W = 32 ;
parameter int pD_W = 32 ;
parameter int pSEL_W = 4 ;
parameter bit [pA_W-1 : 0] pS_ADDR_BASE [0 : pS_N-1] = '{32'h0000_0000, 32'h4000_0000, 32'h8000_0000, 32'hC000_0000} ;
parameter bit [pA_W-1 : 0] pS_ADDR_MASK [0 : pS_N-1] = '{32'h3FFF_FFFF, 32'h3FFF_FFFF, 32'h3FFF_FFFF, 32'h3FFF_FFFF} ;
parameter bit [pM_N-1 : 0] pS_ACCESS_EN [0 : pS_N-1] = '{4'hF , 4'hF , 4'hF , 4'hF } ;
parameter bit pS_ADDR_ERR_DISABLE = 0 ;
parameter bit pS_ACCESS_ERR_DISABLE = 0 ;
parameter bit pLOCK = 1 ;



logic wb_cross__wb_clk ;
logic wb_cross__wb_rst ;
logic [pM_N-1 : 0] wb_cross__wb_m_cyc_i ;
logic [pM_N-1 : 0] wb_cross__wb_m_stb_i ;
logic [pM_N-1 : 0] wb_cross__wb_m_we_i ;
logic [pA_W-1 : 0] wb_cross__wb_m_adr_i [0 : pM_N-1] ;
logic [pD_W-1 : 0] wb_cross__wb_m_dat_i [0 : pM_N-1] ;
logic [pSEL_W-1 : 0] wb_cross__wb_m_sel_i [0 : pM_N-1] ;
logic [pM_N-1 : 0] wb_cross__wb_m_ack_o ;
logic [pM_N-1 : 0] wb_cross__wb_m_err_o ;
logic [pM_N-1 : 0] wb_cross__wb_m_rty_o ;
logic [pD_W-1 : 0] wb_cross__wb_m_dat_o [0 : pM_N-1] ;
logic [pS_N-1 : 0] wb_cross__wb_s_ack_i ;
logic [pS_N-1 : 0] wb_cross__wb_s_err_i ;
logic [pS_N-1 : 0] wb_cross__wb_s_rty_i ;
logic [pD_W-1 : 0] wb_cross__wb_s_dat_i [0 : pS_N-1] ;
logic [pS_N-1 : 0] wb_cross__wb_s_cyc_o ;
logic [pS_N-1 : 0] wb_cross__wb_s_stb_o ;
logic [pS_N-1 : 0] wb_cross__wb_s_we_o ;
logic [pA_W-1 : 0] wb_cross__wb_s_adr_o [0 : pS_N-1] ;
logic [pD_W-1 : 0] wb_cross__wb_s_dat_o [0 : pS_N-1] ;
logic [pSEL_W-1 : 0] wb_cross__wb_s_sel_o [0 : pS_N-1] ;

assign wb_cross__wb_clk = '0 ;
assign wb_cross__wb_rst = '0 ;
assign wb_cross__wb_m_cyc_i = '0 ;
assign wb_cross__wb_m_stb_i = '0 ;
assign wb_cross__wb_m_we_i = '0 ;
assign wb_cross__wb_m_adr_i = '0 ;
assign wb_cross__wb_m_dat_i = '0 ;
assign wb_cross__wb_m_sel_i = '0 ;
assign wb_cross__wb_s_ack_i = '0 ;
assign wb_cross__wb_s_err_i = '0 ;
assign wb_cross__wb_s_rty_i = '0 ;
assign wb_cross__wb_s_dat_i = '0 ;



Но это уже больше к вопросу о философии проектирования, у каждого она своя. Я свое мнение некому не навязываю. Тем более нехочу начинать холивар smile.gif
dxp
Цитата(des00 @ Dec 26 2009, 12:32) *
А кто ей запретит. Структура такой же тип данных как и все остальные типы. Да без направления, ну будет вместо одного интерфейса, две структуры. Как в VHDL.

И чем это лучше одного интерфейса? Точно так же надо описывать отдельно типы структуры, только придется держать в голове, что вот, де, эти две структуры - они логически связаны (части одного целого).

Цитата(des00 @ Dec 26 2009, 12:32) *
если мне нужно расширить интерфейс модуля, то я вписываю именно то что мне надо в карту портов. А вот что вы будете делать если вам нужно к модулю с интерфейсом в 5 сигналов, добавить еще 5 сигналов из другого интерфейса? И опять все сведется к рукопашке.

Не понял вопроса. И там и там придется руками добавлять.


Цитата(des00 @ Dec 26 2009, 12:32) *
Да конечно, мы все делаем 8ми портовые контроллеры памяти в каждом проекте..... Читайте внимательнее, ваш случай как раз тот, когда интерфейс вам помог. Но можно легко и просто было сделать и без интерфейсов. Не понимаю ваши танцы с именами

CODE

//
// component is wishbone system bus based upon crossbar switch architecture for pM_N masters and pS_N slaves
//

`include "define.vh"

module wb_cross
#(
parameter int pM_N = 4 ,


вот этот модуль я вставляю за 5 секунд, не путаюсь в именах и соединяю со схемой секунд за 30ть. %)

CODE

parameter int pM_N = 4 ;
parameter int pS_N = 4 ;


Но это уже больше к вопросу о философии проектирования, у каждого она своя. Я свое мнение некому не навязываю. Тем более нехочу начинать холивар smile.gif

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

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

Кстати, поделитесь, пожалуйста, технологией применения скриптов? Откуда вы их запускаете - из шелла или прямо из слика?
des00
Цитата(dxp @ Dec 26 2009, 02:40) *
И чем это лучше одного интерфейса? Точно так же надо описывать отдельно типы структуры, только придется держать в голове, что вот, де, эти две структуры - они логически связаны (части одного целого).

Тем что это тип данных, а не объект как интерфейс.

Цитата
Не понял вопроса. И там и там придется руками добавлять.

Да так и есть. Но в моем случае я всего лишь расширил карту портов модуля, а вам придеться переделывать базовые интерфейсы. По идее ничего страшного, ну будут таскаться пути без фанаутов, но мой стиль явно описывать все порты модуля. Кроме того это все красиво в случае применения интерфейса для point-point соединения. Для двунаправленных mult-point, point-multi соединений вам все равно придеться ручками прописывать интерфейсы каждого модуля и их соединение друг с другом. Те же яйца только в профиль.

Цитата
Читабельность я бы не похвалил - загромождение. Хотя о стилях спорить, вы правы - это путь к холивару. Не будем. smile.gif

Это Copy-Past. Но я вообще их не читаю, т.к. знаю что скрипт работает без ошибок. Порой даже забываю как модули описываются %)

Цитата
Согласитесь, что когда средства языка позволяют эффективно избегать таких приемов, это хорошо. К тому же, когда надо поменять пару сигналов, тут придется уже руками по всем местам шерстить, автоматизация уже не поможет.

В том то и дело, что понятие эффективности и красивости кода несколько разные. ИМХО применение интерфейса не всегда оправдано.

Цитата
Кстати, поделитесь, пожалуйста, технологией применения скриптов? Откуда вы их запускаете - из шелла или прямо из слика?

на праздниках напишу в блоге как я автоматизирую разработку. Там же выложу скрипт-генератор. %)
CaPpuCcino
Цитата(Andy-P @ Dec 25 2009, 14:58) *
На данный момент у меня сложилось представление об интерфейсе, как о средстве существенно упрощающем написание дизайна и при этом практически не представляющего сложности для синтеза.

вы меня натолкнули на мысль, что неплохо бы написать приблуду для текстового редактора SciTE, которая в случае необходимости будет конвертить интерфейсные соединения в портовые, а то что я, право слово, постоянно руками через #ifdef код для совместимости дублирую.
ЗЫ: кстати я не католик, да и в Питере я сейчас smile.gif
Andy-P
Денис, благодарю за обстоятельный ответ и советы! И все же...

Цитата(des00 @ Dec 26 2009, 07:22) *
Тогда что вам мешает через переменную в статической функции передать информацию из одного модуля в другой? Или разделить переменную между модулями?

Для того, чтобы из одного модуля обратиться к переменной, объявленной в другом модуле (в том числе переменной в функции внутри этого модуля), потребуется иерархическая ссылка. Такая ссылка не синтезируемая, что ограничивает обмен информацией между модулями только через сигналы их портов. Получить синтезируемый вариант, указанных в цитате возможностей не удастся.
Модуль, импортирующий статическую функцию (или задачу) из интерфейса, получает собственную локальную копию этой функции. Функция будет в непосредственной области видимости только содержащего ее модуля. Если другой модуль импортирует из интерфейса ту же функцию, тогда для этого модуля будет сделана своя локальная копия этой же функции. Одно и тоже имя переменной функции в разных модулях это на самом деле две различные переменные. Реализовать обмен информации между модулями через переменную в импортируемой функции или сделать ее общей для нескольких модулей не удастся без привлечения иерархических ссылок. Ограничение синтеза последних является более общим правилом без привязки к импорту из интерфейсов.
Так вот, пока не вижу препятствий для синтеза статических функций импортированных в модули из интерфейса... Либо мои рассуждения не точны, либо есть неизвестная мне пока информация.

Цитата(des00 @ Dec 26 2009, 14:15) *
на праздниках напишу в блоге как я автоматизирую разработку. Там же выложу скрипт-генератор. %)

Можно адрес?
Где-то вы писали о своих открытых проектах. Было бы очень поучительно для меня


Цитата(CaPpuCcino @ Dec 27 2009, 19:39) *
вы меня натолкнули на мысль...

рад, что хоть чем-то оказался полезным
des00
Цитата(Andy-P @ Jan 2 2010, 14:50) *
Для того....
Реализовать обмен информации между модулями через переменную в импортируемой функции или сделать ее общей для нескольких модулей не удастся без привлечения иерархических ссылок.

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

Цитата
Модуль, импортирующий статическую функцию (или задачу) из интерфейса, получает собственную локальную копию этой функции. Функция будет в непосредственной области видимости только содержащего ее модуля. Если другой модуль импортирует из интерфейса ту же функцию, тогда для этого модуля будет сделана своя локальная копия этой же функции. Одно и тоже имя переменной функции в разных модулях это на самом деле две различные переменные.

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

interface pipa;

function static int get (int data);
int tmp = 0;
$display("enter %0t, state %0d, name %m", $time, tmp);
tmp = tmp + data * 3 ;
$display("exit %0t, state %0d, name %m", $time, tmp);
return tmp;
endfunction

modport a (import get );
endinterface

module a_unit (input clk, pipa p, output int led1, led2);

int cnt;

always_ff @(posedge clk) begin : one
cnt <= cnt + 1'b1;

led1 <= p.get(cnt);
led2 <= p.get(cnt);
end

endmodule


module top (input clk, output int led1, led2);

pipa p ();

a_unit a (clk, p.a, led1, led2);

endmodule


// synthesis translate_off
module tb ;

bit clk;
int led1, led2;

top top (clk, led1, led2);

initial begin : clk_gen
clk <= 1'b0;
#5ns forever #5ns clk = ~clk;
end

endmodule
// synthesis translate_on

посмотрите на результат моделирования когда функция static, а потом когда automatic. Если не сможете объяснить разницу в результатах моделирования, спрашивайте обсудим. Из разницы результатов моделирования и следует объяснение авторов данное в книге
Цитата
An automatic task or function allocates new storage each time it is called. When a module calls an imported task or function, a new copy is allocated. This allows synthesis to treat the task or function as if were a local copy within the module.

Хотя, если отдавать себе отчет в том что делаете, я бы заменил в предупреждении авторов must на should %)

Цитата
Можно адрес?
Где-то вы писали о своих открытых проектах. Было бы очень поучительно для меня

Мои и не только блоги про разные аспекты разработки. Блог про мой подход к автоматизации разработки пока еще не писал. Открытый проект. Ну и часть проектов по форуму разбросана %)
Andy-P
Цитата(des00 @ Jan 3 2010, 11:38) *
Вот вам пример почему статик не всегда добро

Пример написан настолько прозрачно, с точки зрения цели его создания, что первое прочтение и ожидаемое поведение полностью совпали с результатами моделирования для обоих вариантов: static and automatic.
В попытке найти ответ на свой исходный вопрос о поведении импортированных из интерфейса статических функций в модули, дополнил ваш пример еще одним экземпляром модуля a_unit установленным в модуль top.

CODE
interface pipa;

function static int get (int data);
int tmp = 0;
$display("enter %0t, state %0d, name %m", $time, tmp);
tmp = tmp + data * 3;
$display("exit %0t, state %0d, name %m", $time, tmp);
return tmp;
endfunction

modport a (import get );

endinterface

module a_unit (input clk, pipa p, output int led1, led2);

int cnt;

always_ff @(posedge clk) begin : one
cnt <= cnt + 1'b1;

led1 <= p.get(cnt);
led2 <= p.get(cnt);
end

endmodule

module top (input clk, output int led1, led2, led3, led4);

pipa p ();

a_unit a (clk, p.a, led1, led2);
a_unit b (clk, p.a, led3, led4);

endmodule


// synthesis translate_off
module tb;

bit clk;
int led1, led2, led3, led4;

top top (clk, led1, led2, led3, led4);

initial begin : clk_gen
clk <= 1'b0;
#5ns forever #5ns clk = ~clk;
end

endmodule
// synthesis translate_on

Если функция get объявлена с automatic – все выходные порты: led1 – led4 имеют одинаковые и независимые друг от друга значения, что является ожидаемым результатом.
Если функция get объявлена с static – led2 вычисляется с учетом текущего значения led1 (согласен), при этом led3 вычисляется с учетом текущего значения led2 (удивлен), а led4 - с учетом текущего значения led3.
Я ожидал, что поскольку led1 и led2 вычисляются в одном экземпляре модуля, а led3 и led4 – в другом, то led1 будет тождественным led3, а led2 - led4. Этого можно добиться в такой редакции

Код
...
module top (input clk, output int led1, led2, led3, led4);

  pipa p (), q ();

  a_unit a (clk, p.a, led1, led2);
  a_unit b (clk, q.a, led3, led4);
  
endmodule
...

Но это уже другая история.
Возвращаясь к примеру с двумя экземплярами модуля и одним экземпляром интерфейса, напрашивается вывод: статические функции, объявленные в интерфейсе и импортируемые в модули не имеют своих собственных локальных копий в модулях. Во всяком случае, это справедливо по отношению к ModelSim SE PLUS 6.5 Rev. 2009.01.

Синтезировал этот пример в Quartus 9.0 SP1. Пришлось убрать, во-первых, modport из интерфейса и, во-вторых, static из объявления функции по причине отсутствия поддержи. Без явного указания времени жизни функция предполагается статической (проверил это в ModelSim). Результат получился аналогичным, как при моделировании с автоматической функцией get.
Вспоминаются слова Нильса Бора о том, что понять – значит привыкнуть и пользоваться.

Денис, спасибо за время и внимание, которые вы мне уделили.
des00
Цитата(Andy-P @ Jan 5 2010, 08:59) *
Денис, спасибо за время и внимание, которые вы мне уделили.

Вам спасибо, а то уже стал забывать основы, все ДСП, да ДСП %)


IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
добрые люди залейте в закрома %)
nikolascha
Цитата(des00)
IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
добрые люди залейте в закрома %)

Можно и внешнюю ссылку оставить, не свои будут благодарны...
PAB
Цитата(des00 @ Jan 8 2010, 10:27) *
IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
добрые люди залейте в закрома %)



uploads/DOCs/SystemVerilog/05354441.pdf
nikolascha
Цитата(PAB)
uploads/DOCs/SystemVerilog/05354441.pdf

Забросте на какую-нибудь шару, пожалуйста...
MKS
Пожалуйста smile.gif
des333
MKS:
Спасибо! smile.gif
CaPpuCcino
Verilog and SystemVerilog Gotchas: 101 Common Coding Errors and How to Avoid Them, Stuart Sutherland, Don Mills. 2007
http://electronix.ru/forum/index.php?showt...st&p=773419

Цитата(grigorik @ Mar 21 2009, 18:29) *
iosifk
Цитата(dimasen @ Aug 7 2006, 18:13) *
Ищу документацию на System Verilog.


Если у кого есть SystemVerilog-2009, киньте мне на рабочую почту, т.к. все фтп у меня закрыты...
Или ссылочку, где можно свободно скачать...
Заранее спасибо!
des00
Цитата(iosifk @ Aug 4 2010, 23:13) *
Если у кого есть SystemVerilog-2009, киньте мне на рабочую почту, т.к. все фтп у меня закрыты...
Или ссылочку, где можно свободно скачать...
Заранее спасибо!

тут
iosifk
Цитата(des00 @ Aug 5 2010, 09:18) *

Большое спасибо!
lexus.mephi
Выложил кое-какие материалы по SystemVerilog на своем сайте SystemVerilog.ru. Сайт делаю в свободное от работы время, поэтому ему еще развиваться и развиваться rolleyes.gif Пишите, если будут пожелания, замечания и т.д.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.