Документация на System Verilog, Сбор документации на SVerilog. И обсуждение тонких моментов синтаксиса Опции

[dimasen]

Ищу документацию на System Verilog.
Нашёл всяческие презантации и "перечни" отличий от Verilog'a (назовём ANSI Verilog )
А нормальной доки так и не нашёл.

[PavelSh]

Ищу документацию на System Verilog.
Нашёл всяческие презантации и "перечни" отличий от Verilog'a (назовём ANSI Verilog )
А нормальной доки так и не нашёл.

http://www.eda.org/sv/SystemVerilog_3.1a.pdf не подойдет?

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

[dimasen]

http://www.eda.org/sv/SystemVerilog_3.1a.pdf не подойдет?

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

Есть у меня этот док, так себе...
Взял я доку на КВАРТУС. Половина функций не поддерживается Если не больше.
От того кстати говоря ищу параллельно какие-нибудь внешние компиляторы; Леонардо, МоделСим... тоже пока безуспешно.

[Golikov A.]

http://www.eda.org/sv/SystemVerilog_3.1a.pdf не подойдет?

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

Есть у меня этот док, так себе...
Взял я доку на КВАРТУС. Половина функций не поддерживается Если не больше.
От того кстати говоря ищу параллельно какие-нибудь внешние компиляторы; Леонардо, МоделСим... тоже пока безуспешно.

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

[Doka]

Взял я доку на КВАРТУС. Половина функций не поддерживается Если не больше.
От того кстати говоря ищу параллельно какие-нибудь внешние компиляторы; Леонардо, МоделСим...

в подспорье: Вопросы системного уровня проектирования

могу еще куда-нить выложить:
SystemVerilog For Design: A guide to using SystemVerilog for HW design and Modeling. Stuard Sutherland, Simon Davidmann // Kluwer Academic Publishers

to all: а кто-нить вообще здесь на форуме есть, кто использует SV? Насколько моделсим его поддерживает (версий от 6.1 и выше)

[Postoroniy_V]

Взял я доку на КВАРТУС. Половина функций не поддерживается Если не больше.
От того кстати говоря ищу параллельно какие-нибудь внешние компиляторы; Леонардо, МоделСим...

в подспорье: Вопросы системного уровня проектирования

могу еще куда-нить выложить:
SystemVerilog For Design: A guide to using SystemVerilog for HW design and Modeling. Stuard Sutherland, Simon Davidmann // Kluwer Academic Publishers

to all: а кто-нить вообще здесь на форуме есть, кто использует SV? Насколько моделсим его поддерживает (версий от 6.1 и выше)

1)моделсим вроде его не поддерживает(возможно ошибаюсь ), а вот questSIM может, и может ещё и на systemC симулировать
2)активХДЛ поддерживает и systemverilog и systemC.
3)к sv присматриваюсь только, "вещь хорошая" . Жаль в квартусе только initial support of sv

Сообщение отредактировал Postoroniy_V - Aug 8 2006, 07:01

[dimasen]

to all: а кто-нить вообще здесь на форуме есть, кто использует SV? Насколько моделсим его поддерживает (версий от 6.1 и выше)

Я уже месяц пишу на убогом Квартус-СВерилоге. Даже в этом убогом квартусе, Сверилог очень привлекателен. Например очень удобно:
когда мы пишем:
always @(a or
y = a + b;

теперь не обязательно указывать весь Sensitivity List, для этого есть ключевое слово:
always_comb
y = a + b;

регистров не появится. так сказать - страховочное слово.
для регистров: always_ff

always @(a or

вот, блин, смайлики
always @(a or b )

[Postoroniy_V]

to all: а кто-нить вообще здесь на форуме есть, кто использует SV? Насколько моделсим его поддерживает (версий от 6.1 и выше)

Я уже месяц пишу на убогом Квартус-СВерилоге. Даже в этом убогом квартусе, Сверилог очень привлекателен. Например очень удобно:
когда мы пишем:
always @(a or
y = a + b;

теперь не обязательно указывать весь Sensitivity List, для этого есть ключевое слово:
always_comb
y = a + b;

регистров не появится. так сказать - страховочное слово.
для регистров: always_ff

always @(a or

вот, блин, смайлики
always @(a or b )

Однако Вы даёте
уже в верилоге -2001 появилось (*) вместо всего сенсивити листа!
тоесть

always@(*)
begin
a<= b+c;
d<=a+e;
.....
end

[dimasen]

Однако Вы даёте
уже в верилоге -2001 появилось (*) вместо всего сенсивити листа!
тоесть

always@(*)
begin
a<= b+c;
d<=a+e;
.....
end

Гыыыы )
действительно, работает. мне казалось, что я пробовал, не получилось и неудивился, потому что в квартусе работал
Лана.
Покажу что у меня из ДОКов есть.
 1a_DesignOverview.pdf ( 237.39 килобайт ) Кол-во скачиваний: 1947

 2003_SNUG_paper_SystemVerilog.pdf ( 203.49 килобайт ) Кол-во скачиваний: 1439


 2003_SystemVerilog_white_paper.pdf ( 85.94 килобайт ) Кол-во скачиваний: 1493

 CummingsSNUG2004Boston_2StateSims.pdf ( 137.86 килобайт ) Кол-во скачиваний: 1394

 verilog.9up.pdf ( 101.67 килобайт ) Кол-во скачиваний: 1467

 CummingsSNUG2004Boston_2StateSims.pdf ( 137.86 килобайт ) Кол-во скачиваний: 1339

[Doka]

1)моделсим вроде его не поддерживает(возможно ошибаюсь :blush: ), а вот questSIM может, и может ещё и на systemC симулировать
2)активХДЛ поддерживает и systemverilog и systemC.
3)к sv присматриваюсь только, "вещь хорошая" :) . Жаль в квартусе только initial support of sv

ну судя по изучению содержания мануала по моделсиму - SV он поддерживает, только вот systemC чаще попадается в содержании - насчет полноты не могу сказать. некомпетентен в этих языках :(
.
вот у меня тоже перепутье, так сказать: к чему присматриваться?! в плане моделирования..
с одной стороны после верилога SV - ближе.
с другой: вроде как systemC и поддерживается шире, да и в литературе больше упоминаний:
в "основы проектирования интегральных схем и систем" (Казёнов) сказано, что только systemC имеет возможность TLM, а у Немудров, Мартин в "системы-на-кристалле. Проектирование и развитие" так и вовсе сказано, что нет иного будущего, кроме как systemC. :(

Покажу что у меня из ДОКов есть.

вы бы выкладывали в более юзабельном виде. Этож всеже форум, а не фтп-свалка. пример

[dimasen]

вот у меня тоже перепутье, так сказать: к чему присматриваться?! в плане моделирования..
с одной стороны после верилога SV - ближе.
с другой: вроде как systemC и поддерживается шире, да и в литературе больше упоминаний:
в "основы проектирования интегральных схем и систем" (Казёнов) сказано, что только systemC имеет возможность TLM, а у Немудров, Мартин в "системы-на-кристалле. Проектирование и развитие" так и вовсе сказано, что нет иного будущего, кроме как systemC.

Честно говоря, пока не представляю применение systemC для PLD.

[dsmv]

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

Из презентаций по System Verilog узнал что там есть такая штука ка интерфейс,
т.е. можно объявить некую шину как структуру, в которой будут и входные и выходные
параметры. При этом облегчиться соединение компонетов, наверное.

Так ли это, есть там интерфейс ?

[dimasen]

Из презентаций по System Verilog узнал что там есть такая штука ка интерфейс,
т.е. можно объявить некую шину как структуру, в которой будут и входные и выходные
параметры. При этом облегчиться соединение компонетов, наверное.

Так ли это, есть там интерфейс ?

Ага. Всё прально понял!

[iMiKE]

хех, интересно-интересно.....значит эктив7 ещё и систем Верилог поддерживает, ща заценим что там да как, мне вообще нравится эта идея ОО в языках моделирования :-)

[dimasen]

А кто нить знает, какой софт ещё поддерживает SV? Больше всего интересует этап синтезирования. С симуляцией и верификацией, я уже понял, хорошо справляется МоделСим.

[Doka]

А кто нить знает, какой софт ещё поддерживает SV? Больше всего интересует этап синтезирования. С симуляцией и верификацией, я уже понял, хорошо справляется МоделСим.

можете объяснить преимущества использования SV перед обычным верилогом именно для синтезируемых описаний?

[dimasen]

можете объяснить преимущества использования SV перед обычным верилогом именно для синтезируемых описаний?

есть несколько моментов которые мне понравились, но это может выглядеть очень ущербным. Повторюсь, я ж только в квартусе с ним работал
вот например:
описание входных-выходных портов в модуле:
module ss_smii_rx
(
input aclr,
input rxclk,
input sync,
input rxd,..........)
т.е. теперь надо это писать только однажды.
потом, введение структур, енумерации.
Только я не понял нафига мне структуры если я с ними не могу производить никаких действий т.е. например:
struct {
logic PARITY;
logic[3:0] ADDR;
logic[3:0] DEST;
} pkt_t;

logic [8:0] m;
assign m = pkt_t; (так не прокатит)
assign m = {pkt_t.PARITY, pkt_t.ADDR, pkt_t.DEST}; (можно только так)
надеюсь это всего лишь ущерб квартуса
назначение новых типов:

typedef enum bit [1:0] {sopwait, sfdwait, pack} sm_states; //обозначили новый тип
sm_states state, next_st;//создали 2 переменные с таким типом
потом можно написать так:
assign state = sopwait;

классы:
class Packet ;
bit [3:0] command;
bit [39:0] address;
bit [4:0] master_id;
integer time_requested;
integer time_issued;
integer status;
task clean();
command = 4’h0;
address = 40’h0;
master_id = 5’b0;
endtask
task issue_request( int delay );
... // send request to bus
endtask
endclass
//ещё не работал с ними (хренов квартус )

есть теперь оператор инкремента-декремента УРА ТОВАРИСЧИ!
for (int = a; a < 10; a++);

объединения:
union {
int i;
shortreal r;
} N;
(не знаю как пользоваться)
ну пока, то что в голову пришло

[Doka]

вот например:
описание входных-выходных портов в модуле:
module ss_smii_rx
(
input aclr,
input rxclk,
input sync,
input rxd,..........)

я это давно уже юзаю в верилоге2000

а всякие классы.. ну не знаю.. у меня с детства аллергия на всё это ООП..

ну а эквивалент структур в верилоге: это возможность обращаться к любому сигналу любого модуля записью:
имя_экземпляра_компонента.имя_сигнала или имя_модуля.имя_экземпляра_компонента.имя_сигнала

[dxp]

ну а эквивалент структур в верилоге: это возможность обращаться к любому сигналу любого модуля записью:
имя_экземпляра_компонента.имя_сигнала или имя_модуля.имя_экземпляра_компонента.имя_сигнала

И какой синтезатор это поддерживает?

[Golikov A.]

ну а эквивалент структур в верилоге: это возможность обращаться к любому сигналу любого модуля записью:
имя_экземпляра_компонента.имя_сигнала или имя_модуля.имя_экземпляра_компонента.имя_сигнала

И какой синтезатор это поддерживает?

вы бы лучше сделали бы избранную копию в тему ХHDL для начинающих, книжки тут всякие проскакивали и так далее...

[dimasen]

я это давно уже юзаю в верилоге2000

а всякие классы.. ну не знаю.. у меня с детства аллергия на всё это ООП..

ну а эквивалент структур в верилоге: это возможность обращаться к любому сигналу любого модуля записью:
имя_экземпляра_компонента.имя_сигнала или имя_модуля.имя_экземпляра_компонента.имя_сигнала

нет такой возможности работы с иерархией в кавртусе.
а Вы чем пользуетесь?

[Postoroniy_V]

вот например:
описание входных-выходных портов в модуле:
module ss_smii_rx
(
input aclr,
input rxclk,
input sync,
input rxd,..........)

я это давно уже юзаю в верилоге2000

а всякие классы.. ну не знаю.. у меня с детства аллергия на всё это ООП..

ну а эквивалент структур в верилоге: это возможность обращаться к любому сигналу любого модуля записью:
имя_экземпляра_компонента.имя_сигнала или имя_модуля.имя_экземпляра_компонента.имя_сигнала

Может верилог-2001?
вроде есть только стандарты на Verilog-1995, Verilog-2001 и Verilog-2005(SV тоесть)
а полезного в SV (имхо) это нумерованные типы да и interface...думаю остальное так по мелочи

[iMiKE]

Хмм.. а по-моему нчинается что-то вроде "зачем ваш СиПлюсПлюс (ООП), когда есть Си", ровно столько же смысла в этом и ровно те же доводы. ООП это ООП, вы погодите, скоро ещё какое-нибудь сервисное программирование для моделирования придумают :-)

Но, по-моему, нет никаких сомнений, что за СистемВерилог/СистемСи будущее!

[dimasen]

Может верилог-2001?
вроде есть только стандарты на Verilog-1995, Verilog-2001 и Verilog-2005(SV тоесть)
а полезного в SV (имхо) это нумерованные типы да и interface...думаю остальное так по мелочи

ещё существует какая-то фича для выставления приоритетов CASE
т.е. указываешь есть ли приоритет в твоем CASE или нет (unique или priority)

always_comb
begin
next_state = state;
unique case(state)
red: if (sensor = 1) next_state = green;
yellow: if (yellow_downcnt = 0) next_state = red;
green: if (green_downcnt = 0) next_state = yellow;
endcase
end

[Doka]

to dxp & dimasen
постараюсь ответить на оба вопроса


PS: и еще насчет версий: это всё во многом условно. Могу показать официальный документ именуемый IEEE 1364.1-2002

[dimasen]

постараюсь ответить на оба вопроса
PS: и еще насчет версий: это всё во многом условно. Могу показать официальный документ именуемый IEEE 1364.1-2002

Ну надо же! Первый раз вижу! И ключевые слова какие-то уж очень новые(дополнительные)

[dxp]

to dxp & dimasen
постараюсь ответить на оба вопроса


PS: и еще насчет версий: это всё во многом условно. Могу показать официальный документ именуемый IEEE 1364.1-2002

И что Вы хотели доказать? Что язык Верилог имеет такую возможность? А кто это оспаривает? Мой вопрос внимательнее перечитайте - какой синтезатор (т.е. на уровне RTL) это поддерживает? Потому, что для нас-то главное именно это, а не абстрактные возможности языка.

[Doka]

И что Вы хотели доказать? Что язык Верилог имеет такую возможность? А кто это оспаривает? Мой вопрос внимательнее перечитайте - какой синтезатор (т.е. на уровне RTL) это поддерживает? Потому, что для нас-то главное именно это, а не абстрактные возможности языка.

ответьте честно: зачем это вам именно для RTL?
от хорошего стиля кодирования решили перейти к плохому?!

[iMiKE]

А кто говорит что ООП это плохой стиль кодига? ИМХО гораздо лучше, чем функциональное, тут и спорить не надо...

[dimasen]

О-па! ГРАБЛИ!
в связи с введением инкремента ++ и декремента --, сразу может возникнуть вопрос, вот например счетчик:
------------------------------------------------------------------
reg [3:0] cnt;
always_ff @(posedge clk or posedge aclr)
if (aclr) cnt <= 0;
else cnt++;
------------------------------------------------------------------
каким будет он? с блоковым "ровно" или с неблоковым?
cnt = cnt + 1; или cnt <= cnt + 1;
оказалось что БЛОКОВОЕ! cnt = cnt + 1;
долго думал... в чём проблема...

[Doka]

А кто говорит что ООП это плохой стиль кодига? ИМХО гораздо лучше, чем функциональное, тут и спорить не надо...

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

[iMiKE]

Разве СистемВерилог это не ООП?

[dxp]

И что Вы хотели доказать? Что язык Верилог имеет такую возможность? А кто это оспаривает? Мой вопрос внимательнее перечитайте - какой синтезатор (т.е. на уровне RTL) это поддерживает? Потому, что для нас-то главное именно это, а не абстрактные возможности языка.

ответьте честно: зачем это вам именно для RTL?

??? Как это зачем? А на кой оно вообще тогда? Я (как и, наверное, многие другие участники форума) на Верилоге потроха ПЛИСов, используемых в реальных дивайсах, описываю, для этого мне надо, чтобы мое описание было благополучно скушано синтезатором, а для этого я должен использовать синтезируемое подмножество языка, RTL то бишь. Отсюда и вопрос.

от хорошего стиля кодирования решили перейти к плохому?!

Причем тут вообще стиль кодирования? Что Вы подразумеваете под хорошим стилем и под плохим стилем?

[Doka]

to dxp

видимо тут произошло столкновение разных школ аппаратного проектирования:
да, соглашусь: для моделирования это полезно - иметь доступ к любому сигналу любого компонента.
моделсим поддерживает эту синтаксическую конструкцию давно и с успехом. сам пользуюсь при отладке такой возможностью .
но вот не понимаю.. зачем же такую анархию при RTL-кодировании творить?!
можно же вообще тогда отказаться от описания интерфейса модуля - раз можно подключаться откуда-хошь к любым его сигналам.. опять же из любого места v-файла. А потом убивать свое рабочее время на поиск ошибок.
строгость традиционного описания тут является преимуществом: объявили экземпляр компонента?! тогда будьте добры в этом же месте и его порты подключить.

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

[dxp]

видимо тут произошло столкновение разных школ аппаратного проектирования:
да, соглашусь: для моделирования это полезно - иметь доступ к любому сигналу любого компонента.
моделсим поддерживает эту синтаксическую конструкцию давно и с успехом. сам пользуюсь при отладке такой возможностью .
но вот не понимаю.. зачем же такую анархию при RTL-кодировании творить?!
можно же вообще тогда отказаться от описания интерфейса модуля - раз можно подключаться откуда-хошь к любым его сигналам.. опять же из любого места v-файла. А потом убивать свое рабочее время на поиск ошибок.
строгость традиционного описания тут является преимуществом: объявили экземпляр компонента?! тогда будьте добры в этом же месте и его порты подключить.

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

Да ничего я не считаю - Вы сами что-то додумали. Если уж интересно мое мнение, то я считаю лазить за пределы модуля, в обход интерфейса - плохой стиль и грязый хак. Поэтому признаю поведение синтезаторов в этом случае обоснованным.

Но возвращаясь к исходной точке: упомянули про структуры в СВ, на что Вы сказали, что их можно заменить на модуль.сигнал при использовании В. Я не считаю, что это хоть сколько-нибудь адекватная замена ни в идеологическом смысле (Вы и сами достаточно внятно только что объяснили причины), ни в практическом - не поддерживают синтезаторы. Идеологию я не стал затрагивать - это всегда момент скользкий и флеймоопасный - идеологию все по своему понимают. Остановился только на практическом моменте - нельзя использовать нотацию модуль.сигнал при описании синтезируемых вещей. Итого, нету в Верилоге аналога структурам, и уровень инкапсуляции и абстракции в Верилоге - это уровень модуля. Что, мягко говоря, не слишком гибко и удобно. Только и всего.

Надеюсь, точки над i расставлены.

Сообщение отредактировал dxp - Aug 10 2006, 10:14

[dimasen]

dxp, Doka
посмотрел на ваш спор и решил просто проверить работает ли... РАБОТАЕТ!
покажу значимость СТРУКТУР в новом верилоге.
Смотрим, по сигналу SLOAD загружаем все поля пакета на отправку, если НЕ_SLOAD, то пакет выдвигается на OUT. Смотрите, как красиво, и всё предельно понятно!

module struct_proba
(
input aclr,
input clk,
input sload,
input out
);

struct packed{ //структура пакета
logic PARITY;
logic[3:0] ADDR;
logic[3:0] DEST;
} pk;

always_ff @(posedge clk or posedge aclr)
if (aclr) begin
pk <= 0;//сбрасываем асинхронно пакет ВЕСЬ
end
else if (sload) begin //загружаем каждое поле пакета ОТДЕЛЬНО
pk.PARITY <= 1;
pk.ADDR <= 5;
pk.DEST <= 3;
end
else pk = pk >> 1;//сдвигаем ВЕСЬ пакет
assign out = pk[0];//наружу выдаём только нулевой бит ВСЕГО пакета
endmodule

------------------------------------------------------------------------------------
ну как??? КРАСОТА!!!

[dxp]

dxp, Doka
посмотрел на ваш спор и решил просто проверить работает ли... РАБОТАЕТ!

У нас дискуссия шла не про работоспособность структур в СВ, а про обращение к объектам по схеме модуль.сигнал.

покажу значимость СТРУКТУР в новом верилоге.

Она (значимость) как бы и так понятна.

Смотрим, по сигналу SLOAD загружаем все поля пакета на отправку, если НЕ_SLOAD, то пакет
[...]
end
else pk = pk >> 1;//сдвигаем ВЕСЬ пакет
assign out = pk[0];//наружу выдаём только нулевой бит ВСЕГО пакета
endmodule

В каком синтезаторе пускали?

[dimasen]

У нас дискуссия шла не про работоспособность структур в СВ, а про обращение к объектам по схеме модуль.сигнал.

В каком синтезаторе пускали?

Doka, и начал этот разговор с "моих" структур.
Ни в каком синтезаторе. Нет у меня нормального синтезатора кроме квартуса В МоделСиме тока проверял.

[dimasen]

Друзья! Есть ещё один очень интересный момент в SV - это INTERFACE.
Есть ли у кого-нибудь опыт работы с ним?

interface intf;
bit A,B;
byte C,D;
logic E,F;
endinterface

intf w;

modA m1(w);
modB m2(w);

module modA (intfi1);
endmodule

module modB (intfi1);
endmodule

Это из одного ПДФ'а. Видимо, что можно создать один интерфейс как структуру сигналов. И если надо навешивать на него кучу модулей одним движением руки.

[Postoroniy_V]

to dxp & dimasen
постараюсь ответить на оба вопроса


PS: и еще насчет версий: это всё во многом условно. Могу показать официальный документ именуемый IEEE 1364.1-2002

Что у вас за перевод такой? Перевод стандарта верилог 2000?
Где вы его взяли если не секрет?
ну а IEEE 1364.1-2002 это как раз и есть Verilog-2001 а не 2000.
вот есть The Insititue of Electrical and Electronics Engineers (IEEE) (website) Standards Group for Verilog сслыка на них IEEE standards group for verilog

по поводу версий это как раз совсем не условно
иначе зачем все эти комитеты и их стандарты существуют?

[Doka]

Что у вас за перевод такой? Перевод стандарта верилог 2000?
Где вы его взяли если не секрет?
ну а IEEE 1364.1-2002 это как раз и есть Verilog-2001 а не 2000.
вот есть The Insititue of Electrical and Electronics Engineers (IEEE) (website) Standards Group for Verilog сслыка на них IEEE standards group for verilog

по поводу версий это как раз совсем не условно
иначе зачем все эти комитеты и их стандарты существуют?

ну это не перевод, а книжка - ее название фигурирует в заголовке окна скриншота
"Языки VHDL и VERILOG в проектировании цифровой аппаратуры"
качал по рапидовской ссылке, которая пробегала на форуме


со ссылкой ознакомился. считаю что это всёже условность: называть стандарт, вышедший в 2002г - Верилог-2001:

The group release a revising of this standard in 2002, known as IEEE 1364-2001.

upd: книжку залил на рапиду:
http://rapidshare.de/files/29279190/Yaziki...-2003_.pdf.html

Сообщение отредактировал Doka - Aug 13 2006, 19:52

[Postoroniy_V]

со ссылкой ознакомился. считаю что это всёже условность: называть стандарт, вышедший в 2002г - Верилог-2001:

The group release a revising of this standard in 2002, known as IEEE 1364-2001.

ок! ваша позиция ясна
за ссылку спасибо

[dimasen]

Всем спасибо за осуждение С_Верилога.
И особенное спасибо за помощь в изучении его синтаксиса!

[dimasen]

забавно
я имел ввиду "обсуждение"

[Кнкн]

Вот встретилось, может кому-нибудь нужно ...

Verification Methodology Manual for SystemVerilog by

Janick Bergeron
Eduard Cerny
Alan Hunter
Andrew Nightingale


http://rapidshare.de/files/26050684/vmmsv.zip.html

[Gate]

Прикладываю статейку от менторовцев, в которой рассказано, чем удобен SV именно для синтеза. А также кратенькое описание отличия SV от verilog.

Прикрепленные файлы

 Changing_Role_of_Synthesis_1_0806.pdf ( 74.67 килобайт ) Кол-во скачиваний: 910
 2002_hdlcon_paper_systemverilog_3133.pdf ( 66.64 килобайт ) Кол-во скачиваний: 669

 

[PAB]

можете объяснить преимущества использования SV перед обычным верилогом именно для синтезируемых описаний?

есть несколько моментов которые мне понравились, но это может выглядеть очень ущербным. Повторюсь, я ж только в квартусе с ним работал
вот например:
описание входных-выходных портов в модуле:
module ss_smii_rx
(
input aclr,
input rxclk,
input sync,
input rxd,..........)
т.е. теперь надо это писать только однажды.
потом, введение структур, енумерации.
Только я не понял нафига мне структуры если я с ними не могу производить никаких действий т.е. например:
struct {
logic PARITY;
logic[3:0] ADDR;
logic[3:0] DEST;
} pkt_t;

logic [8:0] m;
assign m = pkt_t; (так не прокатит)
assign m = {pkt_t.PARITY, pkt_t.ADDR, pkt_t.DEST}; (можно только так)
надеюсь это всего лишь ущерб квартуса

Дело в том, что в этом случае (assign m = pkt_t;) вы пытаетесь присвоить структуру типа unpacked (она такая по умолчанию) переменной типа packed. Составляющие unpacked структур в памяти симулятора могут располагаться как угодно (размер струкиуры не известен), тогда как составляющие packed структуры располагаются друг за другом (известен размер структуры). Соответственно, чтоб работало нормально, нужно написать так:
struct packed{
logic PARITY;
logic[3:0] ADDR;
logic[3:0] DEST;
} pkt_t;

logic [8:0] m;
assign m = pkt_t;

Кстати говоря размер m равен 9, а размер pkt_t 8.....

Сообщение отредактировал PAB - Aug 30 2006, 14:06

[des00]

нда, чего только люди не придумают .....
лишь бы VHDL'93 не изучать

Насчет будующего думаю стоит упомянуть еще и новую редакцию стандарта VHDL.

[dimasen]

Дело в том, что в этом случае (assign m = pkt_t;) вы пытаетесь присвоить структуру типа unpacked (она такая по умолчанию) переменной типа packed. Составляющие unpacked структур в памяти симулятора могут располагаться как угодно (размер струкиуры не известен), тогда как составляющие packed структуры располагаются друг за другом (известен размер структуры). Соответственно, чтоб работало нормально, нужно написать так:
struct packed{
logic PARITY;
logic[3:0] ADDR;
logic[3:0] DEST;
} pkt_t;

logic [8:0] m;
assign m = pkt_t;

Кстати говоря размер m равен 9, а размер pkt_t 8.....

Спасибо. Всё правильно.
Правда, я это тоже недавно сам понял.

[dimasen]

Во! Нашёл. Есть отличная дока по SVerilog. И и лежит себе прямо на ФТП в ДОК/АНСОРТЕД/ аж на 350 страниц!
Плохо правда, что все страницы в растровом виде

[PAB]

Вот встретилось, может кому-нибудь нужно ...

Verification Methodology Manual for SystemVerilog by

Janick Bergeron
Eduard Cerny
Alan Hunter
Andrew Nightingale
http://rapidshare.de/files/26050684/vmmsv.zip.html

А нельзя ли ещё разок на рапиде выложить эту книгу, а то ссылка уже не работает

[Doka]

Verification Methodology - Manual for SystemVerilog - Bergeron, Cerny, Hunter, Nightingale; Springer; 2005.pdf (4.22 Mb)
(File code: Wr4cIc5FOpBrjrr )

[PAB]

спасибо

[CaPpuCcino]

Verification Methodology - Manual for SystemVerilog - Bergeron, Cerny, Hunter, Nightingale; Springer; 2005.pdf (4.22 Mb)
(File code: Wr4cIc5FOpBrjrr )

огромное спасибо.
вопрос:файл защищён от печати или у меня глюк? если да - то можно ли это как-нибудь обойти?

[Doka]

каюсь. не заметил "not for (re)distribution" (просто качал файл не по ссылке с рапиды, а из осла)
протекцию снял. (прога называется "адвенцед ПДФ пассворд рекавери про" (шоб враг не догадался))

Verification Methodology - Manual for SystemVerilog - Bergeron, Cerny, Hunter, Nightingale; Springer; 2005 FREE.pdf (4.22 Mb)
(File code: arMHkgElVmE0GXH )

[CaPpuCcino]

to Doka
ушло в печать
а вот этого случайно в ослике ещё не появилось? - оч бы хотелось :
http://electronix.ru/forum/index.php?showt...mp;#entry227805
к стати она в закрома покладена? а то я покопался - чё-т не нашёл

[Doka]

CaPpuCcino, ни той ни другой нет ни в ослике, ни в других источниках.. судя по всему электронная версия еще "не вышла".

[sazh]

SYSTEMVERILOG FOR VERIFICATION
A Guide to Learning the Testbench Language Features

http://rs60.rapidshare.com/files/22860629/sysverver.rar


rapidshare.com/files/22860227/sysverdes2.rar.html

[Doka]

sazh,

залил последние 3 книги, упоминаемые в теме в
/pub/DOC/Books/HDL/SystemVerilog

[CaPpuCcino]

вот отлично - а мне как раз позовчера доставили предпоследнюю - хорошо что я её запекать не начал. а последнюю я засыпал в закрома ещё летом прошлого года (правда первое издание и в скане). вот теперь сижу и думаю запекать Янчика Бергерона WT using SV или не напрягаться и подождать пэдээфок
нужно заметить что SVer for Ver немного разочаровала - совсем для бегинеров - стандарт читать намного круче, Янчик Бергерон - для среднего уровня и тоже выше стандарта в раскрытие темы использования СВ не прыгает, хотя и объясняет хорошо что к чему на генеральном уровне - но это можно было прочесть еще в просто WT 2nd edition а вот VerMetManual его же мне показалась очень интересной для размышления над тем как надобно жить мне показалась очень интересной для размышления

а вообще всем работником подполья

[DukeXar]

Doka: а можно еще залить куда-нибудь упомянутый в самом начале
"SystemVerilog For Design: A guide to using SystemVerilog for HW design and Modeling. Stuard Sutherland, Simon Davidmann // Kluwer Academic Publishers"?

[Doka]

Doka: а можно еще залить куда-нибудь ...

магам - можно ;-)


ссылка (11.59 Mb)
(File code: 4416TNTNHQN2BXH )

[DukeXar]

Спасибо большое, качаемс =)

[Doka]

нужно заметить что SVer for Ver немного разочаровала - совсем для бегинеров - стандарт читать намного круче, Янчик Бергерон - для среднего уровня и тоже выше стандарта в раскрытие темы использования СВ не прыгает, хотя и объясняет хорошо что к чему на генеральном уровне - но это можно было прочесть еще в просто WT 2nd edition а вот VerMetManual его же мне показалась очень интересной для размышления над тем как надобно жить мне показалась очень интересной для размышления

решил-таки потихоньку осваивать SV для писания тестбенчей.
в связи с этим вопрос: с чего бы начать?
что сейчас доступно из букварей:
1) SVer for Ver
2) VerMetManual
3) стюард, упоминаемый в теме последним
4) Advanced Verification Methodology Cookbook - халявная книжка от ментора с примера лаб для Квесты

стандарт оно конечно читать круче, но цель (по кр.мере у меня) - не ознакомиться с "инструментом", а научиться им пользоваться.. И понять на примерах - как эффективно использовать те или иные языковые особенности (преимущества SV перед V).
(как пример-аналогия: XAPP199 "Writing Effective Testbenches" от Xilinx, где лаконично, на двух десятках страниц изложены практические приемы работы на vhdl & verilog)

с учетом этого какую бы посоветовали для _начального_ прочтения?

[CaPpuCcino]

решил-таки потихоньку осваивать SV для писания тестбенчей.
в связи с этим вопрос: с чего бы начать?
что сейчас доступно из букварей:
1) SVer for Ver
2) VerMetManual
3) стюард, упоминаемый в теме последним
4) Advanced Verification Methodology Cookbook - халявная книжка от ментора с примера лаб для Квесты

стандарт оно конечно читать круче, но цель (по кр.мере у меня) - не ознакомиться с "инструментом", а научиться им пользоваться.. И понять на примерах - как эффективно использовать те или иные языковые особенности (преимущества SV перед V).
(как пример-аналогия: XAPP199 "Writing Effective Testbenches" от Xilinx, где лаконично, на двух десятках страниц изложены практические приемы работы на vhdl & verilog)

с учетом этого какую бы посоветовали для _начального_ прочтения?

я начинал со стюарда (это если не брать в расчёт кучу всяких свободно доступных пэдээфок) несмотря на то что он вообще-то писал не для верификации - но там есть достаточно интересных намёков которые можно использовать и в тестбенчах (автоматические функции и передача параметров по ссылке, интерфейсы с модпортами и экспортирование функций через интерфейсы + всякие мелочи по типам, динамическим переменным и последняя глава о поведенческом и транзакционному моделированию) потом прочёл Ассершн- бэйзд дизайн (интересна с точки жрения метрики функционального покрытия и самих ассершенов) после этого досканально изучил последний стандарт (вы к стати зря его игнорируете - знаете ведь как верилоговские стандарты пишутся - это скорее книжки чем стандарты - оттуда взял динамижеские массивы и очереди с мэил-боксами, randsequences и constrained randomization) затем SVer for Ver и VerMetManual (но в первой не нашёл уже ничего нового, а вторая достаточно серёзная книжецa - для старта не подойдёт )
all in all я бы посоветовал всё-таки начать со Стюарда(убьёте сразу двух зайцев), а затем SVer for Ver - добьёте Верификацию с Моделированием (можете также подождать ~2 дня будет ещё и Яник - половина уже готова, но SVer_forVer наверное для начала всё-таки предпочтительнее, потому как Яник пишет всякие заумности в чрезмерном колличестве, что поначалу может отвлекать от применения самого SV).
что касается 4-ого пункта от Ментора - то по-моему только зря потратите время - её можно читать как доп. литературу - там уже философия ТЛМ - для начала слишком - только голову мусором забьёте
PS а ксайлинковского ксапа не читал - поэтому не занаю с чем сравнивать

[DukeXar]

Извиняюсь, запостил сначала сюда, а потом сделал топик http://electronix.ru/forum/index.php?showtopic=29609

Сообщение отредактировал DukeXar - Apr 2 2007, 22:29

[CaPpuCcino]

второй пункт из этого топика выполнен:
http://electronix.ru/forum/index.php?showt...mp;#entry227805
(в ссылке найдёте где лежит)

[Juggernaught]

http://electronix.ru/forum/index.php?showtopic=30309

[RHnd]

Взял я доку на КВАРТУС. Половина функций не поддерживается Если не больше.

А где можно посмотреть что именно поддерживает Квартус? Какая это именно из его док?

Кстати, какое-то время с момента открытия темы уже прошло, может кто-нибудь нашел новую/более удачную литературу по Сверилогу? Желательно на русском.

[CaPpuCcino]

А где можно посмотреть что именно поддерживает Квартус? Какая это именно из его док?

Кстати, какое-то время с момента открытия темы уже прошло, может кто-нибудь нашел новую/более удачную литературу по Сверилогу? Желательно на русском.

товарищ - с момента последнего сообщения в данном топике прошло всего 9 дней - учитесь пользоваться форумом - данный топик многостраничный - дочтайте до конца - а не постите вопросы после первого же сообщения!
по сведениям разведки на данный момент Квартус поддерживает СВ достаточно сносно (за подробностями обращайтесь к Доке - он его вроде юзает)
на русском литературы пока что нет. подождите месяцок или учите англицкий

[RHnd]

товарищ - с момента последнего сообщения в данном топике прошло всего 9 дней - учитесь пользоваться форумом - данный топик многостраничный - дочтайте до конца - а не постите вопросы после первого же сообщения!

Упс. Очень-очень виноват. Оправдываться бессмысленно, но меня тянули за руку в "магазин за кофточкой". Еще раз упс.
Дочитал все страницы, пдф-ки качаются. Начну, пожалуй, со Стюарта, а там посмотрим. Но это все потом, сейчас хотяб просто верилог освоить.

[Escorial]

Writing Testbenches Using System Verilog:
http://electronix.ru/forum/index.php?showt...ng+testbenches#

Хороший tutorial по SystemVerilog:

начало: http://www.doulos.com/knowhow/sysverilog/tutorial/datatypes/
assertions: http://www.doulos.com/knowhow/sysverilog/t...ial/assertions/

Сообщение отредактировал Escorial - Jun 25 2007, 15:45

[des00]

Привет всем!

Внимание в книге Writing Testbenches using SystemVerilog от яника берегерона обнаружена серьезная баго. Сомневаться в таком авторе грешно, но все же факт :

страница документа 250 пример Sample 5-66. Autonomous RS-232 response monitor

Код

class rs232;
  local bit [8:0] fifo[$];
  ...
  function new(...);
    ...
    fork
      this.receive_thread(); // ВЫЗВАТЬ таск из функции нельзя (!!!)
    join_none
  endfunction: new

  local task receive_thread();
    forever begin
      automatic bit [8:0] resp;
      this.receive(resp[7:0], resp[8]);
      this.fifo.push_back(resp);
    end
  endtask: receive_thread
  ...
endclass: rs232

это противоречит стандарту верилог 2001 (систем верилог в этой части наследует верилог 2001)

10.1 Distinctions between tasks and functions .... A function cannot enable a task; a task can enable other tasks and functions.....

и естественно не работает в симуляторах типа к....а сим 6.2ф

Т.к. автор ссылается на синопсис то вполне возможно что для конструктора класса они сделали исключение. а вот в других симуляторах похоже труба, остается делать модели с автоматическим стартом через Ж. (а нужно то всего лишь завернуть модель описанную в интерфейсе через always в класс с виртуальным интерфейсом + forever).

Читающие эту книгу будте внимательные!!!!

Привет всем!

Внимание в книге Writing Testbenches using SystemVerilog от яника берегерона обнаружена серьезная баго. Сомневаться в таком авторе грешно, но все же факт :

страница документа 250 пример Sample 5-66. Autonomous RS-232 response monitor

Код

class rs232;
  local bit [8:0] fifo[$];
  ...
  function new(...);
    ...
    fork
      this.receive_thread(); // ВЫЗВАТЬ таск из функции нельзя (!!!)
    join_none
  endfunction: new

  local task receive_thread();
    forever begin
      automatic bit [8:0] resp;
      this.receive(resp[7:0], resp[8]);
      this.fifo.push_back(resp);
    end
  endtask: receive_thread
  ...
endclass: rs232

это противоречит стандарту верилог 2001 (систем верилог в этой части наследует верилог 2001)

10.1 Distinctions between tasks and functions .... A function cannot enable a task; a task can enable other tasks and functions.....

и естественно не работает в симуляторах типа к....а сим 6.2ф

Т.к. автор ссылается на синопсис то вполне возможно что для конструктора класса они сделали исключение. а вот в других симуляторах похоже труба, остается делать модели с автоматическим стартом через Ж. (а нужно то мне было всего лишь завернуть модель описанную в интерфейсе через always в класс с виртуальным интерфейсом + forever).

Читающие эту книгу будте внимательные!!!!

[CaPpuCcino]

...от яника берегерона обнаружена серьезная баго. Сомневаться в таком авторе грешно, но все же факт :

и естественно не работает в симуляторах типа к....а сим 6.2ф

Т.к. автор ссылается на синопсис то вполне возможно что для конструктора класса они сделали исключение.

да ничего не грешно. просто класс спроектирован откровенно неграмотно. а если подобный конструктор проглатывается и синопсисом, то это не фича, а серьёзная брешь в обороне.
суть ограничения на вызов таска из функции в следующем:
таски и функции в модели верилога различаются принципиально тем, что исполнение таска может быть размазано по модельному времени, а исполнение функции нет (её исполнение происходит атомарно за модельное время 0) то есть поток управления в таске может использовать событийные операторы (типа wait, @) внутри себя, а функция нет. больше они ничем не различаются(кому не хватает одного возвращаемого параметра по имени функции, может использовать void function и указывать направление параметра(input, output, inout)) хотя и единственного различия более чем достаточно, чтобы определить совершенно разную область использования данных типов подпрограмм.
таким образом чтобы сохранить целостность модели вызовы тасков из функций запрещены (понятно почему).
теперь перейдём к тому почему этого делать нельзя никогда даже в конструкторе класса (к стати и особенно в конструкторе): вообразите зачем кому-нибудь может потребоваться объект, который будет создаваться на протяжении некоторого модельного времени (для красноречия: на протяжении нескольких тактов? я пока не придумал такой пример). и более того к каким последствиям может привести создание объекта модели размазанное по модельному времени (ведь таск может быть и блокирующим)?
так что передавайте привет янику, он вроде книжки бесплатно раздаёт тем кто баги обнаруживает. а это действительно баг, а не фича

[des00]

суть ограничения на вызов таска из функции в следующем:
....

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

теперь перейдём к тому почему этого делать нельзя никогда даже в конструкторе класса (к стати и особенно в конструкторе): вообразите зачем кому-нибудь может потребоваться объект, который будет создаваться на протяжении некоторого модельного времени (для красноречия: на протяжении нескольких тактов? я пока не придумал такой пример). и более того к каким последствиям может привести создание объекта модели размазанное по модельному времени (ведь таск может быть и блокирующим)?

в этом конкретном примере таск запускается как отдельный программный поток (тред) с помошью великолепно реализованной идеологии fork/join_none. Поэтому конструктор в примере будет исполняться атомарно относительно модельного времени.

Пример задачи ну например вот такой.
Почитав яника я решил попробывать переделать одну из работающих для тестирования моделей через классы (что бы было как у правильных пацанов ).

Модель приемник и передатчик синхронного потока данных. Функционально модель выглядит как интерфейс с clocking секциями. Функциональность реализована через 2 always, в которых постоянно исполняется последовательный код. Модель стартует независимо в момент начала симуляции.

Целью было заворачивание функциональности в класс с передачей управления портами через абстрактные интерфейсы с clocking секциями. Функциональность планировалось реализовать через 2 программных потока реализованных через fork/join_none + task с forever. Но вот реализация независимого старта в момент начала симуляции, похоже невозможна. Требуется явная, внешняя относительно класса, инициализация программных потоков.

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

Жду его ответа на письмо, а вдруг действительно книгу пришлет

[CaPpuCcino]

идеологии fork/join_none. Поэтому конструктор в примере будет исполняться атомарно относительно модельного времени.

я об этом вчера думал - действительно создание потоков происходить мгновенно и фактически это не приводит к размазыванию по модельному времени. но (даже если не брать то что это противоречит правилам языка) есть ещё эстетический аспект - правила хорошего тона ООП: конструктор производит выделение памяти и инициализацию значений (как если бы перегруженный оператор "+" возвращает новый объект как результат операции над двумя исходными и он не модифицирует последние, и не бежит на кухню подогреть чайник и не ставит вашу любимую мелодию в проигрыватель, хотя мог бы )
так вот и запуском новых потоков, каждых к примеру следящих за своим уникальным объектом из набора однотипных объектов, должен заниматься отдельный метод класса - скажем какой-нибудь init(int number_of_threads) или run(int number_of_threads), но не конструктор - таково моё убеждение

Но вот реализация независимого старта в момент начала симуляции, похоже невозможна. Требуется явная, внешняя относительно класса, инициализация программных потоков.

вы можете абсолютно то же самое что планировали сделать в конструкторе сделат в методе run. чем вас такой вариант не устраивает? ведь функцию new вам же тоже приходится вызывать не в момент начала симуляции. в момент создания модели автоматически создаётся только указатель на объект класса и только затем вы уже вызываете конструктор. что плохово в том чтобы сделать так:

Код

class Class_Object_type;
...
task run(int thread_num); fork repeat(thread_num)... join_none endtask endclass;

Class_Object_type Object;//создаётся указатель на объект, но не сам объект
initial
begin
  Object=new;//выделяется память под объект, происходит инициализация, возвращается указатель на объект
  Object.run(x);//запускаем потоки
  ...
end

[des00]

Получить книгу с автографом Яника не получилось. Вот ответ :

The IEEE working group has clarified the standard and enabling a task from within a fork/join_none statement in a function is valid.

Please contact Mentor for a version of Questa that supports it. VCS also supports this feature.

должен быть документ более старший чем SystemVerilog 3.1a Language Reference Manual и опираться нужно на него.

насчет того что мешает ИМХО более красивый запуск выглядел бы как

Class_Object_type Object = new();

и не нужно заморачиваться на Object.run.
Правда иногда может потребоваться синхронизация начала тестирования как wait(Object != null);


PS. может плохо искал, но заметок про сие дополнение на сайте http://www.eda.org/sv/ не нашел.

[CaPpuCcino]

enabling a task from within a fork/join_none statement in a function is valid.

мдя... исключения не придают стройности теории
а может у него попросить и ссылку на стандарт, где это закреплено а то я тож что-то старше 3.1а ни о чём не слышал: http://verilog.org/sv/

[dxp]

а может у него попросить и ссылку на стандарт, где это закреплено а то я тож что-то старше 3.1а ни о чём не слышал: http://verilog.org/sv/

Да вы че, парни? А это что: /pub/DOC/Standarts&Specifications/IEEE Std 1800-2005.pdf?

[CaPpuCcino]

Да вы че, парни? А это что: /pub/DOC/Standarts&Specifications/IEEE Std 1800-2005.pdf?

так сравнивал я эти два документа 3.1а и 1800-2005 и отличий не нашёл, только зря 2 талмуда распечатал (вернее различия там может и есть но скорее редакторские - кажись Асселеровский 3.1а ЛРМ был как раз и принят ай-яяем как 1800-2005), между прочим говорят что есть ещё и 1364-2005 и перед выпуском в прессе была шумиха о том что 1364-2005 и 1800-2005 имеют ряд различий (с assertion они там как-то разошлись) однако так как пока все тулзы с которыми я работал соответствует именно 1800-2005 то будем надеятся 1364-2005 то ли запинали, то ли проигнорировали и он почил в бозе - двоевластие нам не нужно

[dxp]

так сравнивал я эти два документа 3.1а и 1800-2005 и отличий не нашёл, только зря 2 талмуда распечатал

Хм, у меня SystemVerilog_3.1a.pdf: 586 страниц, размер 4246776 байт.
SystemVerilog IEEE Std 1800-2005.pdf: 664 страницы, размер 6620828 байт.

Текстуальное сравнение не делал.

[CaPpuCcino]

Текстуальное сравнение не делал.

да, действительно есть разница по организации глав.

специально пересмотрел поиском весь стандарт 1800-2005 на предмет join_none, никаких разрешений запускать таски внутри функции внутри блока fork...join_none я не обнаружил.

[torik]

Я вот ради интереса хочу поглядеть этот SV - в Квартусе то как его создать? Просто создаем файл verilog и пишем по синтаксису SVerilog?

[CaPpuCcino]

Я вот ради интереса хочу поглядеть этот SV - в Квартусе то как его создать? Просто создаем файл verilog и пишем по синтаксису SVerilog?

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

[des00]

Решил я тут дальше осваивать VMM и для начала начал разбираться с AMM от ментора.

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

Копаясь в исходниках узнал много интересного про систем верилог и его классы.


Удачи !!!

Прикрепленные файлы

 avm_3_1.zip ( 2.33 мегабайт ) Кол-во скачиваний: 213

 

[des00]

Решил я тут дальше осваивать VMM и для начала начал разбираться с AMM от ментора.

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

Копаясь в исходниках узнал много интересного про систем верилог и его классы.
Удачи !!!

PS. Немного покопался и вот что нашел

http://www.ovmworld.org/overview.php

The Open Verification Methodology (OVM) provides the first open, interoperable SystemVerilog verification methodology in the industry. The OVM provides a library of base classes that allow users to create modular, reusable verification environments in which components talk to each other via standard transaction-level modeling (TLM) interfaces. It also enables intra- and inter-company reuse through a common methodology and classes for virtual sequences and block-to-system reuse.


Backward-compatible with AVM 3.0 and URM 6.2

вообще прекрасно. надо осваивать и к либе конкретного производителя можно не привязываться.

[PAB]

В чём отличие IEEE1800-2007 от IEEE1800-2005?

[des00]

В чём отличие IEEE1800-2007 от IEEE1800-2005?

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

Может они наконец стандартизуют либы, и не будет VMM, AMM, OVM

[PAB]

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

Так вроде уже лежит /upload/Books/verilog/IEEE_1800-2007.pdf

[CaPpuCcino]

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

Может они наконец стандартизуют либы, и не будет VMM, AMM, OVM

мда. и в новостях ничего не пробегало, ток это нашёл
http://ieeexplore.ieee.org/xpl/freeabs_all...unumber=4410438

[CaPpuCcino]

посмотрел файл. это не новый стандарт - это его свежая электронная публикация. (стандарт преждний 1800-2005; с какого перепугу ему в предыдущей ссылке новую цифру приписали я не понял)

[des00]

Добрый день!

5 ый день копания в AVM/OVM.

Первое ощущение : мракобесие, особенно после того, как доверяя издательству Springer и Янику Бергерону, смотришь их VMM (synopsys) в поиске функциональных аналогов.

Такое ощущение что господа из каденсе и ментор не долго думая, тупо переписали классы с SC на SV. При этом внеся ИМХО С++ сумятицу в стройный SV.

Господа кто работает по "пАцАнСкИ", объясните зачем в SV был введен геморой с типами портов для транзакций, и необходимостью их регистрировать и конектить?

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

Почему в AVM/OVM практически не используются callback, а предлагается использование analisys_* компонентов? Некоторые их которых содержат в себе объекты синхронизации(analisys_port например)?

Тогда как в SV for Ver не рекомендуется использовать активные scoreboard/monitor и т.д. А делать все на очередях callback классов.

VMM выглядит более простой и понятной, AVM/OVM как темный лес, здесь зарегистриуем, здесь экспортнем конекторы портов, тут импортнем их и т.д. Ведь по сути это обычная передача указателей на объекты синхронизации.

В итоге в тестбенче на основе AVM все закопано так, что почти теряется сам смысл использования SV перед SC.

Если не сложно объясните чайнику зачем это было сделано так ?

Спасибо.


Денис.

[CaPpuCcino]

5 ый день копания в AVM/OVM.

Первое ощущение : мракобесие, особенно после того, как доверяя издательству Springer и Янику Бергерону, смотришь их VMM (synopsys) в поиске функциональных аналогов.

привет! недавно тоже поглядел на OVM библиотеку плюс описалово классов, но не для анализа подхода, а для поверхностного ознакомления - впечатление так же хуже чем от VMM. OVM кажется менее развитой иерархией. (кстати сразу же возник вопрос, а если у них какая-нибудь обясняющая записка обосновывающая их модель на подобие Яниковского VMM for Ver? на сайте OVM нашёл ток описание класов, но ничего особенного по методике)

Такое ощущение что господа из каденсе и ментор не долго думая, тупо переписали классы с SC на SV. При этом внеся ИМХО С++ сумятицу в стройный SV.

когда читал Менторовскую книжецу по AVM сложилось такое же впечатление. сначала тоже не понял зачем дублировать концепцию СЦ. но есть предположение, что именно для того чтобы оставаться в рамках единой методики. чтоб соединение компонентов на одном языке и на другом языке было органичным. от сюда в общем-то и вытекает всё последующее (хотя я бы не хотел выступать их адвокатом, да и с учётом только поверхностного знакомства с OVM этого сделать пока не могу.)

Господа кто работает по "пАцАнСкИ", объясните зачем в SV был введен геморой с типами портов для транзакций, и необходимостью их регистрировать и конектить?

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

у Бергерона, как я разумею, есть та же концепция обозначенная как vmm_channel. и обе эти реализации находятся в согласии с концепцией СЦ(и TLM на базе объектов). в общем случае приследуются те же цели что и в концепции ООП - инкапсулировать потроха объекта и обезопасить их от неправильного или несанкционированного использования.
вспомните концепцию интерфейса в СЦ (абстрактный класс), вот обвешивание mailbox функциями приследует ту же цель (vmm_channel тоже строится на mailbox)- обезопасить объект, обеспечить возможность повторного использования компонентов и их заменяемость

VMM выглядит более простой и понятной, AVM/OVM как темный лес, здесь зарегистриуем, здесь экспортнем конекторы портов, тут импортнем их и т.д. Ведь по сути это обычная передача указателей на объекты синхронизации.

В итоге в тестбенче на основе AVM все закопано так, что почти теряется сам смысл использования SV перед SC.

да закопано под интерфейсами (по принципу СЦ см. выше), помогает скрыть реализацию и использовать сторонние компоненты с сохранением прав интеллектуальной собственности
(ещё раз гоговорюсь, я не выступаю адвокатом. это то как я себе объясняю их подход за неимением авторского разъяснения)

[cms]

Думал над вопросами. Мой вариант объяснения:

У OVM тестбенч не статический. Он строится программой тестирования (в OVM понятие теста и тестбенча разнесены), динамически создающей инстансы модулей и динамически их коннетящей - также как это делается в ООП программах при сборке алгоритма из классов. Динамическое создание тестбенча как раз и требует тех усложнений, которые Вы перечислили: регистрация и коннект портов (ака COM интерфейсы), работа только через указатели и специальные синхрообъекты.

Все это сделано для того, чтобы можно было программно менять тест-бенчи.

Добрый день!

5 ый день копания в AVM/OVM.

Первое ощущение : мракобесие, особенно после того, как доверяя издательству Springer и Янику Бергерону, смотришь их VMM (synopsys) в поиске функциональных аналогов.

Такое ощущение что господа из каденсе и ментор не долго думая, тупо переписали классы с SC на SV. При этом внеся ИМХО С++ сумятицу в стройный SV.

Господа кто работает по "пАцАнСкИ", объясните зачем в SV был введен геморой с типами портов для транзакций, и необходимостью их регистрировать и конектить?

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

Почему в AVM/OVM практически не используются callback, а предлагается использование analisys_* компонентов? Некоторые их которых содержат в себе объекты синхронизации(analisys_port например)?

Тогда как в SV for Ver не рекомендуется использовать активные scoreboard/monitor и т.д. А делать все на очередях callback классов.

VMM выглядит более простой и понятной, AVM/OVM как темный лес, здесь зарегистриуем, здесь экспортнем конекторы портов, тут импортнем их и т.д. Ведь по сути это обычная передача указателей на объекты синхронизации.

В итоге в тестбенче на основе AVM все закопано так, что почти теряется сам смысл использования SV перед SC.

Если не сложно объясните чайнику зачем это было сделано так ?

Спасибо.
Денис.

[CaPpuCcino]

У OVM тестбенч не статический. Он строится программой тестирования (в OVM понятие теста и тестбенча разнесены), динамически создающей инстансы модулей и динамически их коннетящей

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

[cms]

поясните пожалуйста что значит нестатический тестбенч? и что вы имеете ввиду под тест и тестбенч-понятия разнесены?

В OVM есть классы ovm_env, ovm_test, ovm_factory. Они позволяют динамически менять компоненты (override), структуру и параметры тестбенча. Плюс в классах компонент предусмотрены методы для внешней конфигурации типа set_config. Все заточено на reuse и инкапсуляцию.

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

Почему же сложно? Очень даже вероятно, что потребуется прогнать тест для всех возможных комбинаций каналов/коммутаций.
Представим себе DUT и план тестирования, по которому этот DUT сначала должен поработать под правильным источником, потом под источником генерирующим ошибки, потом изменить схему подключения с точка-точка на другую (два DUT на шине), а потом проверить все тоже самое с другими значениями параметра. Естественно, что при этом надо создавать компоненты по мере надобности, а уже отработавшие компоненты выгружать из памяти.

Можно конечно на каждом этапе править тестбенч ручками (менять define) и запускать каждый случай заново, но верификаторы все-таки решили, что удобнее это делать программно и перестаивать тестбенч в непрерывном процессе - написать программу тестирования, покрывающую весь план, поставить её на мейн-фрейм и уйти на неделю пить пиво Потом вернуться разребать логи.

[CaPpuCcino]

Представим себе DUT и план тестирования, по которому этот DUT сначала должен поработать под правильным источником, потом под источником генерирующим ошибки, потом изменить схему подключения с точка-точка на другую (два DUT на шине), а потом проверить все тоже самое с другими значениями параметра. Естественно, что при этом надо создавать компоненты по мере надобности, а уже отработавшие компоненты выгружать из памяти.

извините за придирки, но всё-таки эти примеры не подходят под динамически-изменяемую структуру тестбенча (понимаю конечно, что детально продумывать ответ вы не старались, но всё же): для вспрыска ошибок нет необходимости менять структуру тестбенча (пояснять наверное нет необходимости: ошибочный источник от неошибочного отличается только потоком данных им создаваемым, а изменение потока данных не нуждается в изменении компонентной/структурной/ конфигурации тестбенча); изменение схемы подключения никак не влияет на шинный интерфейс - тут хоть точка - многоточка, хоть многоточка-многоточка разницы для объекта тестирования никакой, тем более если смотреть с точки зрения размножения DUT, то это вообще невозможно динамически, так как module - статический объек и динамически размещаться не может и удалятся тоже, если даже представить что мы моделируем коммутатор и хотим посмотреть как он будет вести себя в зависимости от количества каналов им обслуживаемых и захотим сделать это динамически - то у нас тоже ничего не получится: interface в СВ тоже статический объект и кроме как через изменение parameter или define c последующей перекомпиляцией нам такую ситуацию не отверефицировать. так что ничего естественного в динамической пересборке инфраструктуры отсюда не вытекает

[cms]

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

Изменение схемы подключения несет существенную разницу для DUT, так как позволяет выявить ошибки арбитража. Размножения DUT динамически вожможно, так как размножается не модуль, а его обертка - класс ovm_object. То же и для interface - создаются и уничтожаются классы, их инкапсулирующие.

Задача OVM - продвинуть возможности верификации дальше 'define/parameter. Если Вы лично пока не видите в этом необходимости, это не значит, что её нет. Это вопрос Вашего личного круга задач.

P.S. Ответы продумывать я стараюсь детально. Могу ошибаться, но не преднамеренно.

извините за придирки, но всё-таки эти примеры не подходят под динамически-изменяемую структуру тестбенча (понимаю конечно, что детально продумывать ответ вы не старались, но всё же): для вспрыска ошибок нет необходимости менять структуру тестбенча (пояснять наверное нет необходимости: ошибочный источник от неошибочного отличается только потоком данных им создаваемым, а изменение потока данных не нуждается в изменении компонентной/структурной/ конфигурации тестбенча); изменение схемы подключения никак не влияет на шинный интерфейс - тут хоть точка - многоточка, хоть многоточка-многоточка разницы для объекта тестирования никакой, тем более если смотреть с точки зрения размножения DUT, то это вообще невозможно динамически, так как module - статический объек и динамически размещаться не может и удалятся тоже, если даже представить что мы моделируем коммутатор и хотим посмотреть как он будет вести себя в зависимости от количества каналов им обслуживаемых и захотим сделать это динамически - то у нас тоже ничего не получится: interface в СВ тоже статический объект и кроме как через изменение parameter или define c последующей перекомпиляцией нам такую ситуацию не отверефицировать. так что ничего естественного в динамической пересборке инфраструктуры отсюда не вытекает

[CaPpuCcino]

P.S. Ответы продумывать я стараюсь детально. Могу ошибаться, но не преднамеренно.

все мы смертны : )

Задача OVM - продвинуть возможности верификации дальше 'define/parameter. Если Вы лично пока не видите в этом необходимости, это не значит, что её нет. Это вопрос Вашего личного круга задач.

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

Изменение схемы подключения несет существенную разницу для DUT, так как позволяет выявить ошибки арбитража. Размножения DUT динамически вожможно, так как размножается не модуль, а его обертка - класс ovm_object. То же и для interface - создаются и уничтожаются классы, их инкапсулирующие.

вот как раз размножение DUT меня смущает: ведь DUT - это module, а модуль объект статический, а если даже представить что вы можете размножать указатель на модуль (ведь я так понимаю под обёрткой вы понимаете указатель) то количество модулей не меняется как не крути, а если вы имеете ввиду композитный класс по термином обёртки - то модули не могут быть членами класса. что же касается интерфейсов, то ситуация схожая: интерфейс вещь статическая и членом класса быть не может так же, вы тут конечно можете возразить по поводу virtual interface, но виртуальный интерфейс (который действительно может быть членом класса, и по сути специально для этого и был введён в язык) является лишь суть ссылкой на статический интерфейс (reference) и от того сколько у вас будет ссылок на статические интерфейсы количество последних менятся не будет (если углублятся и далее в тему ссылок на интерфейсы по средствам виртуальных интерфейсов, то наличие нескольких ссылок на один интерфейс вообще вещь очень опасная, потому как если несколько классов начнут управлять сигналами интерфейса без симафоров - для тестбенча произойдёт катастрофа)

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

хотелось бы ответить кратко: а опытные верификаторы стараются так не делать (но появится повод в обвинение в нескромности. так вот "опытные верификаторы"-это я не о себе ), поэтому прдётся объяснится - причина в следующем: если вы создаёте транзактор на базе наследованного класса, то вам необходимо переопределить виртуальный метод базового класса - ну допустим вы создаёте "папу(или ребёнка)-правильного транзактора" и "ребёнка-неправильного транзактора" при переопределение неправильной посылки вам фактически придётся переписать функцию посылки для искажения правильной транцакции это плохо тем что вам нужно быть осведомлённым для этого о к примеру реализации самого родительского класса или реализуемом по средствам его интерфейсе более низкого уровня абстракции, что в первом случае нежелательно с точки зрения интеллектуальной собственности, а во втором случае с точки зрения повторности использования. нам же удобнее иметь некоторый открытый интерфейс класса транзактора со спрятанными элементами рализации и сведеньями о нижних уровнях. здесь на мой взгляд хорошо подойдёт композитный класс транзактора, который бы включал в себя объект класса конфигурации "правильности и неправильности транзактора" и деталями этой "правильности и неправильности" (иначе для каждой неправильности нам придётся создавать свой класс-наследник при подходе с наследованием от общего предка, а если подумать об объединение всех возможных неправильностей в одном классе наследнике, то чем это хуже объединения в одном классе всех деталей правельности и неправильности и управления ими(деталями) посредствам общего интерфейса класса транзактора)
ЗЫ: в последнем абзаце под интерфейсом класса я не подразумеваю набор сигналов как в случае SystemVerilog interfaces, но набор открытых методов класса или его открытых члемов по средствам которых осуществляется управление объектом класса

[des00]

2 cms и CaPpuCcino

Спасибо за ответы. Кое о чем я интуитивно догадывался, но кое что по прежнему темный лес:

а если у них какая-нибудь обясняющая записка обосновывающая их модель на подобие Яниковского VMM for Ver? на сайте OVM нашёл ток описание класов, но ничего особенного по методике

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

у Бергерона, как я разумею, есть та же концепция обозначенная как vmm_channel. и обе эти реализации находятся в согласии с концепцией СЦ(и TLM на базе объектов). в общем случае приследуются те же цели что и в концепции ООП - инкапсулировать потроха объекта и обезопасить их от неправильного или несанкционированного использования.
вспомните концепцию интерфейса в СЦ (абстрактный класс), вот обвешивание mailbox функциями приследует ту же цель (vmm_channel тоже строится на mailbox)- обезопасить объект, обеспечить возможность повторного использования компонентов и их заменяемость

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

вот как раз в VMM мне больше понятно, что, куда и зачем. Но когда я копался в описании AVM/OVM и сорцах либ, меня удивляло большое количество объектов типа порт(!!!), через которые по сути и идет передача указателя на один единственный мелбокс, хотя по сути мейлбокс это и есть уже готовый объект и для передачи его указателя достаточно просто присвоить чиселки.

Или в объектах типа порт скрыт сакральный смысл проверки, правильности коннектов на этапе построения окружения (enviroment eleboration ) ?

Еще вот что сильно не понятно. В VMM рекомендуют именно callback и для этого у них есть специальный класс vmm_xactor_callbacks и методы класса vmm_xactor prepend_callback/append_callback. А в OVM callback есть только в hook функциях классов для вывода логов.

Управляя очередями callback функций можно так же на лету менять функциональность объекта. В том числе кстати вносить ошибки в уже сформированные правильные данные, без создания объекта потомка с другими алгоритмами, а с регистрацией класса callback с описанной callback функцией.

А если быть в концепции OVM то что бы сделать например 2 монитора (например для SDRAM контроллера scoreboard + bandwidth measurement) к классу драйвера, мне потребуется 2 analysy_port с analysy_fifo. Что потянет за собой 2 mailbox с кучей объектов портов. Тогда как в VMM концепции всего 2 вызова callback функций.

В OVM есть классы ovm_env, ovm_test, ovm_factory. Они позволяют динамически менять компоненты (override), структуру и параметры тестбенча. Плюс в классах компонент предусмотрены методы для внешней конфигурации типа set_config. Все заточено на reuse и инкапсуляцию.

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

Код

  prj_env_0 env0;
  prj_env_1 env1;
  prj_env_2 env2;

  initial begin
    env0 = new ("test normal", dut_if);
    env0.do_test();

    env1 = new ("test error", dut_if);
    env1.do_test();

    env2 = new ("test shock", dut_if);
    env2.do_test();

  end

Или всегда должен быть только один enviroment, а разные тесты должны перебираться на основе объектов ovm_test?

вот как раз размножение DUT меня смущает: ведь DUT - это module, а модуль объект статический, а если даже представить что вы можете размножать указатель на модуль

думаю это разрешимо если сразу вставить несколько DUT, к ним массив интерфейсов а коммутацию уже производить в программе на лету. Отключение холостых DUT можно сделать просто зафорсив тактовую в 0 а ресет в активное состояние.

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

тоже блуждаю в грамотной реализации подобной обработки. Делал и разные классы и наследуемые, у каждой концепции есть свои + и -, но думаю что использование базового avm_transaction/ovm_transaction решит часть проблем.

А по сабжу думаю тут нужно ввести классификацию ошибок.

Если требуется ввести ошибки в посылку правильных данных, то это делается легко и просто. Можно как на наследуемом классе, так и ввести в этот же класс. Но когда требуется внести интерфейсную ошибку (например в драйвере сформировать ошибку системной шины) то тут я вижу 2 варианта :

1. Модифицировать базовые классы драйвера и транзактора и ввести в них интерфейс управления вставкой ошибок. При этом не потребуется менять enviroment на верхнем уровне.

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

Хотелось бы знать как это правильно делается и почему ?

Спасибо!


Перед тем как править свой тестбенч для свича потоков, решил немного покурить ovm и

2 CaPpuCcino

ovm-1.0.1\examples\basic_examples\module\test.sv

похоже вот про какие dut идет разговор. Это behavor модели ovm_object, завернутые в ovm_object_wrapper, которые завязаны на ovm_factory.

Т.е. как я понимаю к отладке RTL это имеет малое отношение.


ЗЫ. 2 cms как по вашему на чем лучше остановиться на ovm или avm ? (vmm как я понял закрыта и в сорцах не поставляется %( ). Даже если не брать все из ovm/avm использование avm_transaction, avm_named_component, avm_treaded_component, avm_reporter сильно упрощает жизню %)


Нашел ответ

http://www.ovmworld.org/forums/showpost.ph...amp;postcount=8

Hi Sarath,
Thank you for your kind words about OVM. Our view has always been that the OVM is the next logical step in AVM development. So, new testbench features will be developed collaboratively with Cadence and put into OVM.

As for AVM, we will continue to support AVM-3.0 for the foreseeable future. This support will include bug fixes and ongoing support for future releases of Questa.
__________________
Tom Fitzpatrick
Verification Technologist
Mentor Graphics Corp.

Понятно куда двигаться.

Спасибо