Версия для печати темы

Автор: dimasen Aug 7 2006, 14:13

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

Автор: PavelSh Aug 7 2006, 16:24

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

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

Автор: dimasen Aug 7 2006, 17:02

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

Автор: Golikov A. Aug 7 2006, 19:04

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

Автор: Doka Aug 7 2006, 20:39

в подспорье: http://electronix.ru/forum/index.php?s=&showtopic=17415&view=findpost&p=123762

могу еще куда-нить выложить:
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 Aug 8 2006, 06:55

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

Автор: dimasen Aug 8 2006, 07:41

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

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

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


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

Автор: Postoroniy_V Aug 8 2006, 08:14

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

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

Автор: dimasen Aug 8 2006, 08:38

Гыыыы )
действительно, работает. мне казалось, что я пробовал, не получилось и неудивился, потому что в квартусе работал
Лана.
Покажу что у меня из ДОКов есть.
 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 Aug 8 2006, 10:01

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




вы бы выкладывали в более юзабельном виде. Этож всеже форум, а не фтп-свалка. http://electronix.ru/forum/index.php?s=&showtopic=18892&view=findpost&p=136172

Автор: dimasen Aug 8 2006, 11:25

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

Автор: dsmv Aug 8 2006, 16:22

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

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

Автор: dimasen Aug 8 2006, 20:51

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

Автор: iMiKE Aug 9 2006, 06:49

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

Автор: dimasen Aug 9 2006, 07:28

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

Автор: Doka Aug 9 2006, 08:05

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

Автор: dimasen Aug 9 2006, 09:58

есть несколько моментов которые мне понравились, но это может выглядеть очень ущербным. Повторюсь, я ж только в квартусе с ним работал
вот например:
описание входных-выходных портов в модуле:
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 Aug 9 2006, 10:03

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

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

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

Автор: dxp Aug 9 2006, 10:50

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

Автор: Golikov A. Aug 9 2006, 10:52

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

Автор: dimasen Aug 9 2006, 12:29

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

Автор: Postoroniy_V Aug 9 2006, 12:52

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

Автор: iMiKE Aug 9 2006, 14:10

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

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

Автор: dimasen Aug 9 2006, 15:08

ещё существует какая-то фича для выставления приоритетов 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 Aug 9 2006, 16:10

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

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

Автор: dimasen Aug 9 2006, 17:50

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

Автор: dxp Aug 10 2006, 04:17

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

Автор: Doka Aug 10 2006, 07:19

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

Автор: iMiKE Aug 10 2006, 07:28

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

Автор: dimasen Aug 10 2006, 07:29

О-па! ГРАБЛИ!
в связи с введением инкремента ++ и декремента --, сразу может возникнуть вопрос, вот например счетчик:
------------------------------------------------------------------
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 Aug 10 2006, 07:40

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

Автор: iMiKE Aug 10 2006, 07:46

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

Автор: dxp Aug 10 2006, 08:01

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


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

Автор: Doka Aug 10 2006, 09:47

to dxp

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

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

Автор: dxp Aug 10 2006, 10:12

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

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

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

Автор: dimasen Aug 10 2006, 13:00

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 Aug 10 2006, 13:11

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


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


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

Автор: dimasen Aug 10 2006, 13:47

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

Автор: dimasen Aug 11 2006, 08:10

Друзья! Есть ещё один очень интересный момент в 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 Aug 11 2006, 11:39

Что у вас за перевод такой? Перевод стандарта верилог 2000?
Где вы его взяли если не секрет?
ну а IEEE 1364.1-2002 это как раз и есть Verilog-2001 а не 2000.
вот есть The Insititue of Electrical and Electronics Engineers (IEEE) (website) Standards Group for Verilog сслыка на них http://electronix.ru/redirect.php?http://www.verilog.com/IEEEVerilog.html

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

Автор: Doka Aug 11 2006, 11:55

ну это не перевод, а книжка - ее название фигурирует в заголовке окна скриншота
"http://electronix.ru/redirect.php?http://www.dom-knigi.ru/book.asp?ART=117234&CatalogID=82"
качал по рапидовской ссылке, которая пробегала на форуме


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


upd: книжку залил на рапиду:
http://electronix.ru/redirect.php?http://rapidshare.de/files/29279190/Yaziki_VHDL_i_Verilog_v_Proektirovanii_Cifrovoy_Apparaturi__Polyakov-2003_.pdf.html

Автор: Postoroniy_V Aug 11 2006, 11:57

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

Автор: dimasen Aug 11 2006, 13:52

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

Автор: dimasen Aug 11 2006, 14:26

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

Автор: Кнкн Aug 22 2006, 12:06

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

Verification Methodology Manual for SystemVerilog by

Janick Bergeron
Eduard Cerny
Alan Hunter
Andrew Nightingale


http://electronix.ru/redirect.php?http://rapidshare.de/files/26050684/vmmsv.zip.html

Автор: Gate Aug 28 2006, 15:56

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

Автор: PAB Aug 30 2006, 14:05

Дело в том, что в этом случае (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.....

Автор: des00 Aug 31 2006, 07:37

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

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

Автор: dimasen Sep 6 2006, 10:58

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

Автор: dimasen Sep 12 2006, 06:54

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

Автор: PAB Mar 22 2007, 14:31

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

Автор: Doka Mar 23 2007, 14:21

http://electronix.ru/redirect.php?http://nukeuploads.com/download/1174649359/Wr4cIc5FOpBrjrr/Verification_Methodology_-_Manual_for_SystemVerilog_-_Bergeron,_Cerny,_Hunter,_Nightingale;_Springer;_2005.pdf.html
(File code: Wr4cIc5FOpBrjrr )

Автор: PAB Mar 23 2007, 15:03

спасибо

Автор: CaPpuCcino Mar 23 2007, 20:01

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

Автор: Doka Mar 24 2007, 10:06

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

http://electronix.ru/redirect.php?http://nukeuploads.com/download/1174720396/arMHkgElVmE0GXH/Verification_Methodology_-_Manual_for_SystemVerilog_-_Bergeron,_Cerny,_Hunter,_Nightingale;_Springer;_2005_FREE.pdf.html
(File code: arMHkgElVmE0GXH )

Автор: CaPpuCcino Mar 25 2007, 00:07

to Doka
ушло в печать
а вот этого случайно в ослике ещё не появилось? - оч бы хотелось :
http://electronix.ru/forum/index.php?showtopic=28470&st=0&gopid=227805&#entry227805
к стати она в закрома покладена? а то я покопался - чё-т не нашёл

Автор: Doka Mar 25 2007, 10:28

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

Автор: sazh Mar 29 2007, 12:23

SYSTEMVERILOG FOR VERIFICATION
A Guide to Learning the Testbench Language Features

http://electronix.ru/redirect.php?http://rs60.rapidshare.com/files/22860629/sysverver.rar


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

Автор: Doka Mar 29 2007, 13:55

sazh,

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

Автор: CaPpuCcino Mar 29 2007, 17:09

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

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

Автор: DukeXar Apr 2 2007, 09:01

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

Автор: Doka Apr 2 2007, 11:59

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


http://electronix.ru/redirect.php?http://nukeuploads.com/download/1175504729/4416TNTNHQN2BXH/Stuart_Sutherland_SystemVerilog_for_design.pdf.html
(File code: 4416TNTNHQN2BXH )

Автор: DukeXar Apr 2 2007, 12:03

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

Автор: Doka Apr 2 2007, 18:10

решил-таки потихоньку осваивать SV для писания тестбенчей.
в связи с этим вопрос: с чего бы начать?
что сейчас доступно из букварей:
1) SVer for Ver
2) VerMetManual
3) стюард, упоминаемый в теме последним
4) http://electronix.ru/redirect.php?http://www.mentor.com/products/fv/_3b715c/ - халявная книжка от ментора с примера лаб для Квесты

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

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

Автор: CaPpuCcino Apr 2 2007, 19:25

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

Автор: DukeXar Apr 2 2007, 22:25

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

Автор: CaPpuCcino Apr 3 2007, 19:33

второй пункт из этого топика выполнен:
http://electronix.ru/forum/index.php?showtopic=28470&st=0&gopid=227805&#entry227805
(в ссылке найдёте где лежит)

Автор: Juggernaught Apr 18 2007, 12:30

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

Автор: RHnd Apr 27 2007, 19:30

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

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

Автор: CaPpuCcino Apr 27 2007, 20:08

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

Автор: RHnd Apr 27 2007, 22:56

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

Автор: Escorial Jun 25 2007, 15:42

Writing Testbenches Using System Verilog:
http://electronix.ru/forum/index.php?showtopic=33449&hl=writing+testbenches#

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

начало: http://electronix.ru/redirect.php?http://www.doulos.com/knowhow/sysverilog/tutorial/datatypes/
assertions: http://electronix.ru/redirect.php?http://www.doulos.com/knowhow/sysverilog/tutorial/assertions/

Автор: des00 Nov 26 2007, 12:06

Привет всем!

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

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

это противоречит стандарту верилог 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 Nov 26 2007, 18:18

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

Автор: des00 Nov 27 2007, 05:27

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



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

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

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

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



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

Автор: CaPpuCcino Nov 27 2007, 19:08

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


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

Автор: des00 Nov 28 2007, 03:32

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

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

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

Class_Object_type Object = new();

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


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

Автор: CaPpuCcino Nov 28 2007, 15:22

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

Автор: dxp Nov 29 2007, 05:23

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

Автор: CaPpuCcino Nov 29 2007, 15:20

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

Автор: dxp Nov 30 2007, 09:07

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

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

Автор: CaPpuCcino Nov 30 2007, 17:51

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

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

Автор: torik Dec 10 2007, 15:43

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

Автор: CaPpuCcino Dec 10 2007, 18:38

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

Автор: des00 Feb 29 2008, 03:24

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

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

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


Удачи !!!

Автор: des00 Feb 29 2008, 06:13

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

http://electronix.ru/redirect.php?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 Feb 29 2008, 11:03

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

Автор: des00 Feb 29 2008, 13:03

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

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

Автор: PAB Feb 29 2008, 14:47

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

Автор: CaPpuCcino Mar 1 2008, 01:20

мда. и в новостях ничего не пробегало, ток это нашёл
http://electronix.ru/redirect.php?http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=4410439&arnumber=4410440&punumber=4410438

Автор: CaPpuCcino Mar 1 2008, 21:21

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

Автор: des00 Mar 4 2008, 08:25

Добрый день!

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 Mar 4 2008, 11:42

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

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

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

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

Автор: cms Mar 4 2008, 12:19

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

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

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

Автор: CaPpuCcino Mar 4 2008, 12:29

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

Автор: cms Mar 4 2008, 13:23

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



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

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

Автор: CaPpuCcino Mar 4 2008, 13:45

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

Автор: cms Mar 4 2008, 14:12

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

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

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

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

Автор: CaPpuCcino Mar 4 2008, 15:08

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

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

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

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

Автор: des00 Mar 5 2008, 04:40

2 cms и CaPpuCcino

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

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





вот как раз в 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 функций.



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



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




думаю это разрешимо если сразу вставить несколько 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://electronix.ru/redirect.php?http://www.ovmworld.org/forums/showpost.php?p=30&postcount=8



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

Спасибо

Автор: des00 Mar 5 2008, 06:28

2 CaPpuCcino


взято http://electronix.ru/redirect.php?http://www.ovmworld.org/forums/showthread.php?t=85

вот маленький учебник

http://electronix.ru/redirect.php?http://www.doulos.com/knowhow/sysverilog/ovm/

Автор: CaPpuCcino Mar 5 2008, 10:44

спасиб, Денис! первую видел, вторую ещё нет - будем почитать

Автор: CaPpuCcino Mar 9 2008, 00:46

приятный тюториал по SystemVerilog http://electronix.ru/redirect.php?http://www.electrosofts.com/systemverilog/index.html

Автор: makc Apr 7 2008, 14:14

Оффтопик был выделен в отдельную тему http://electronix.ru/forum/index.php?showtopic=46081
Убедительная просьба, будьте внимательнее при создании новых тем/сообщений.

Автор: Escorial Apr 19 2008, 11:23

Динамическая реконфигурация тестового окружения может быть использована для случайного формирования тестового окружения. Например у коммутатора к каждому порту может быть прицеплен endpoint или другой коммутатор. У USB-хост контроллера вообще может быть очень разнообразная обвязка - 8 уровней на которых могут быть как хабы так и функции до 255 устройств в общей сложности. Перебрать все варианты вручную через `ifdef `endif - врагу не пожелаешь.

Автор: des00 May 27 2008, 03:59

Добрый день господа!!!

Наконец то докурил до конца доку по VMM, последние главы SYSTEM-LEVEL VERIFICATION и PROCESSOR INTEGRATION VERIFICATION вводят в основы технологии XVС (EXTENSIBLE VERIFICATION COMPONENTS).

И если с софтовой частью все более, менее понятно, то раздел HARDWARE-ASSISTED VERIFICATION ставит
в тупик. А именно как модель для моделирования переноситься в железо?

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

Разбирался ли ли кто нибудь с технологиями XVC ? Если да то не могли бы прояснить технологию предлагаемую авторами данной методики от синопсиса ?

Спасибо.

Автор: yes Jul 22 2008, 12:58

доки от CADENCE

особо интересны, имхо, sysverilog.pdf и abv*

интересно мнение знающих, про эти доки

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

Автор: des00 Jul 31 2008, 02:37

в продолжение темы про OVM


http://electronix.ru/redirect.php?http://www.mentor.com/products/fv/questa_eval.cfm?PC=L&c=2008_07_30_verification_tech_news

таки дождались встроенной поддержки.

ждем 6.4 квесту

Автор: Vadim Jul 31 2008, 19:19

Я извиняюсь, а чего ждать-то? В известном месте лежит.

Автор: CaPpuCcino Jul 31 2008, 19:45

да и как-то к документации по SystemVerilog-у слабо относится

Автор: des00 Aug 1 2008, 02:42

2 Vadim

нда, старею. надо было сначала известное место проверить %)

Ну если подходить с такой точки зрения, то разговорам о VMM/OVM/AVM не место в этой теме, больше о подходах к верификации на SV здесь писать не буду %)

Хотел подвести черту к недавнему диалогу о выборе между OVM/AVM, как и планировалось менторовцы переходят на OVM, оставляя для AVM только саппорт.

Автор: CaPpuCcino Aug 1 2008, 13:10

по-моему слишком ёмкая тема. лучше выносить в отдельный топик, иначе структурированность потеряем - получится "все-обо-всём"

Автор: Intekus Aug 8 2008, 07:23

Момент синтаксиса: поддерживает ли SV вложенные (через import) пакеты? По БНФ-синтаксису, вроде не обязан (однажды так обжёгся на вложенных generate) - но это было бы так удобно... Пример:

m0 и m2 (!) компилируются, а m1 - нет; используется Quartus 7.2.

Автор: Вардан Oct 15 2008, 22:41

http://electronix.ru/redirect.php?http://www.asic-world.com/systemverilog/index.html

http://electronix.ru/redirect.php?http://www.asic-world.com/systemverilog/tutorial.html

Автор: CaPpuCcino Oct 16 2008, 12:46

по OVM появился тьюториал:
http://electronix.ru/redirect.php?http://www.doulos.com/knowhow/sysverilog/ovm/

Автор: CaPpuCcino Oct 22 2008, 15:12

очень недурственный учебный ресурс (тьюториалы) по SystemVerilog - http://electronix.ru/redirect.php?http://testbench.in/
помимо прочего рассматриваются такие вопросы как:
классы СВ, рандомизация в СВ, утверждения (SVA), DPI, управление с помощью событий (events)
приводятся примеры верификации проекта как на чистом SV, так и построенных по методологии VMM, AVM

Автор: CaPpuCcino Oct 25 2008, 20:19

у Doulos появилась в открытом доступе очень недурственная бумажка на тему процесса перехода от TLM модели к RTL (рекоммендую любителям пректирования больших систем по принципу "сверху-вниз"):
Seamless Refinement from Transaction Level to RTL Using SystemVerilog Interfaces (http://www.doulos.com/knowhow/sysverilog/ тамнайдёте)

Автор: CaPpuCcino Nov 15 2008, 18:30

обнаружил интерсную бумажку по интеграции SystemVerilog и SystemC через DPI (интересно что в списке публикаций она на сайте Сузерленда не числится, хотя на сервере лежит)
http://electronix.ru/redirect.php?http://www.sutherland-hdl.com/papers/2004-SNUG-Europe-paper_SystemVerilog_DPI_with_SystemC.pdf

Автор: CaPpuCcino Nov 17 2008, 20:56

господа, может ли функция SV возвращать непакованный массив не через список параметров а через собственное имя? например:

я так понимаю только через определение нового непакованного типа

или я чего-то не доглядел в нынешнем стандарте?
спс

Автор: des00 Nov 18 2008, 03:39

ИМХО вы поняли все правильно, только через введение нового типа %)

Автор: Iptash Nov 27 2008, 07:01

Я тут слепил PDFник с этой ссылки, пока tutor потом остальные слеплю, выложу. Так наверное
лучше будет.

Автор: dxp Nov 27 2008, 07:31

Достойное дело. Только вот отступы (indent'ы) в коде не присутствуют, что весьма снижает читабельность примеров.

Автор: Iptash Nov 27 2008, 20:57

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

Автор: Iptash Nov 30 2008, 11:47

Подскажите пожалуйста где можно скачать IEEE 1800-2007.

Автор: cms Nov 30 2008, 13:27

Не находил ли кто стандарт IEEE-P1800-2008 - говорят в начале 2008 объединили предыдущий 1800-2005 и верилоговский 1364 в один документ. Любопытно было бы его почитать.

Digitally yours,
cms

Digitally yours,
cms

Автор: CaPpuCcino Nov 30 2008, 20:11

новости по стандарту обсуждаются здесь: http://electronix.ru/forum/index.php?showtopic=49689
2008 ещё не опубликован, скорее всего только весной след. года

Автор: CaPpuCcino Dec 1 2008, 12:47

вопросы приобретения материалов не подлежащих свободному распространению в данной ветке не обсуждаются

Автор: des00 Dec 10 2008, 06:40

столкнулся с занятной баго фичей.

Итак господа что по вашему должно быть выведено в консоль в данном коде

Занятные результаты получаются у меня в квесте 6.4а



А у вас ?

Автор: CaPpuCcino Dec 10 2008, 14:15

ЗЫ: это баг квесты, а не нюанс СВ
ЗЗЫ: в службу поддержки написал. ЗЗЗЫ: при этом баг проявляется только при передачи типа через список параметров модуля, если напрямую объявить пипу как logic[0:0], то всё ок

Автор: CaPpuCcino Dec 15 2008, 16:55

ок, Ментор ошибку признал. Временное решение проблемы в использовании ключа -vopt.
ЗЫ:желательно проблемы ментора обсуждать в разделе по средствам разработки, чтоб не мешать приятное с полезным .

Автор: cms Dec 19 2008, 17:54

Должна ли в SV работать такая конструкция:


module a;

parameter param_a = 128;

endmodule


module b;

parameter param_b = a.param_a;

initial $display("param_a = %d", a.param_a);

endmodule

Т.е. можно ли использовать при определении параметра в модуле параметр из другого модуля и как?

Удивительно, но VCS параметр из внешнего модуля видит по иерархическому (?) пути без инстанса, $display его отображает правильно.
Правда при назначении параметра VCS уже сообщает что a.param_a неконстантное выражение и не компилит его.

QuestaSim сразу говорит что не находит в иерархии.

Автор: CaPpuCcino Dec 20 2008, 01:36

тут на мой взгляд не всё так однозначно. то, что написано, синтаксически правильно (НО). т.е. во втором модуле параметр через иерархическую ссылку должен быть виден (здесь в СВ аналогия с пакетом, да и вообще с любым пространством имён). другое дело как компилятор относится к этому пространству: включает ли он его при компиляции как подиерархию $root или как совершенно отдельное пространство имён (в случае с пакетом здесь было бы всё точно - пакет компилировался бы в единую подиерархию "рут")... и тут всплывает то самое "НО": какое практическое значение имеют 2 модумя никак не связанные в проекте (да и вообще никак синтаксически не связанные)? какой смысл им делить единое пространство имён?

Автор: cms Dec 20 2008, 19:26

Модули связанные: инстанциированные параллельно в топе или вложены друг в друга. Например модуль b инстанциирует а в зависимости от значения param_a.

P.S. Synopsys ответил, что эта фича еще не заимплеменчена, и что они отправили мой вопрос VCS R&D рассмотреть на предмет включения её в будущих релизах.

Автор: CaPpuCcino Dec 21 2008, 01:33

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

Автор: cms Dec 21 2008, 19:13

Вот как раз иерархия интсансов в данном случае значения не имеет. Рассматриваем compilation unit Согласно п.19.3 IEEE 1800-2005(E)

tools shall provide use models that allow both of the following cases:
a) All files on a given compilation command line make a single compilation unit (in which case the
declarations within those files are accessible anywhere else within the constructs defined within
those files).
Each file is a separate compilation unit (in which case the declarations in each compilation-unit
scope are accessible only within its corresponding file).

Т.е. если два модуля описаны в одном файле, то они находятся в одном пространстве имен $unit, независимо как они с друг другом соотносятся или инстанциируются где бы то ни было. Или вообще не инстанциируются.

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

Схожая бага была в квесте 6.3, когда $clog2 от константы почему-то воспринимался как переменная и не давал использовать результат в определении векторов. В 6.4 это пофиксили и теперь наконец можно писать

logic [$clog2(1024)-1:0] a;

Автор: yes Jan 13 2009, 13:56

выложил доки из синопсиского VCS (vmm+fssertions)
/upload/DOCs/SystemVerilog/synopsys/

вроде бы не встречал такого на сайте

в SOLD-е много еще всего, примеры, туториалы, всякие методологии типа RVM, OVA и т.д.
если нет линукса или лень распаковывать весь солд, могу дозалить

Автор: SM Jan 13 2009, 21:08

А VCS-то хоть "берет" эти мудрые конструкции, от которых плохеет ментору?

Автор: yes Jan 14 2009, 11:42

то о чем мы говорим (2008.9 mx) берет (но ментор их тоже берет), но VCS не глючит
ну и работает на порядки быстрее (позже попытаюсь пустить нетлист с SDF, и померить с каденсом, ментор то на этом вообще сосет)

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

зато гораздо внятней становится структура сборки (всякий маразм типа mfcu, sfcu отсутствует) и судя по всему все книжки по SV, написаны на основе VCS-а
ну и доки и примеров полно
ну и VMM там есть (вроде как прямее OVM, хотя я не копенгаген, чтоб их сравнивать)

Автор: des00 Feb 2 2009, 04:39

таки яник и сотоварищи признали что не правы, правда косвенно.

http://electronix.ru/redirect.php?http://synopsysoc.org/insideprotocolverification/?p=40



вот что интересно, открытый VMM может и не подняться на других симуляторах

Автор: Кнкн Feb 4 2009, 13:08

SystemVerilog Assertions

Author(s): Srikanth Vijayaraghavan
Publisher: Springer
Date : 2005
Pages : 334
Format : PDF

/upload/DOCs/SystemVerilog

Автор: CaPpuCcino Feb 16 2009, 15:38

пришло от ментора письмо. говорят, что фича исправлена в 6.5. поверил наслово.

Автор: iosifk Feb 25 2009, 09:56

Нашел вот это:
http://electronix.ru/redirect.php?http://www.pdf-search-engine.com/system-verilog-rtl-pdf.html
Сейчас буду рыться...

Автор: grigorik Mar 21 2009, 15:29

Ищу книгу
Verilog and SystemVerilog Gotchas:101 Common Coding Error and How to Avoid Them
by Stuart Sutherland and Don Mills
Пожалуйста, Не могли бы вы помочь?

Автор: CaPpuCcino Mar 23 2009, 15:15

не подскажет ли уважаемая публика, можно ли паковать интерфейсы в пакеты
спб

Автор: yes Mar 26 2009, 17:41

если я правильно понял вопрос -

нельзя - вроде бы где-то явно написано
так ткнулся в стандарт

Types, variables, tasks, functions, sequences, and properties may be
declared within a package. Such declarations may be referenced within modules, macromodules, interfaces,

то есть то что инстанциируется в хиерархию в пакадж нельзя

Автор: CaPpuCcino Mar 26 2009, 19:38

спб! тоже где-то в стандарте видел фразочку, типа, всё что может быть с hierarchical reference в пакет нельзя - но немного смутил доступ к полям классов, структур, объединений.

Автор: CaPpuCcino Apr 29 2009, 20:17

уважаемые, стоит такая задача:
есть массив интерфейсов типа if_t из n элементов -
if_t if_array[n]();
есть набор интерфейсов в количестве n того же типа никак не объединённых -
if_t if_a();
if_t if_b();
...
if_t if_n();
необходимо однозначно связать весь набор из разрозненных интерфейсов с каждым интерфейсом массива.
кто и как изящно решал эту задачу, поделитесь мудростью. я думаю, что нужно смотреть в сторону собственной функции интерфейса типа
interface if_t();
...
function automatic if_t if_assign(if_t interface_bind);
endinterface
но есть сомнения что это реализуемо;
другой вариант - делать модуль-заглушку, но это не изящно.
что посоветуете?

ЗЫ: вообще в последнее время некоторые участники форума стали говорить, что n мало, и лучше k, поэтому если будет k, я не возражаю

Автор: warrior-2001 Apr 30 2009, 05:49

Что значит "связать"? Присвоить элементам одного интерфейса значения другого? Или нужно, чтобы было взаимное переприсваивание?
В первом случае всё просто: на уровне environment-та приассайнить нужный интерфейс из массива к интерфейсу из набора. Остальную часть проекта можно не менять. При желании это же
можно сделать на верхнем уровне-

Если в каждый момент времени нужно управлять механизмом присваивания, тоесть необходима уметь присваивать как из массива к набору, так и обратно, то изящнее всего было бы воспользоваться
следующим: в нужном блоке кода определить присваивание в `ifndef а, а на верхнем уровне либо определять`define а 16, либо нет. Тем самым будет происходить выбор направления присваивания.

Надеюсь правильно понял вопрос.

Автор: CaPpuCcino Apr 30 2009, 17:16

извините за нечёткость формулировки. имеется ввиду второй случай, т.е. интерфейс сигнального уровня. во избежании ложной интерпритации опишу проблему подробнее:
на сигнальном уровне интерфейс подразумеваю как набор сигналов, т.е. аналогия структуры, с тем исключением, что в общем случае сигналы в интерфейсе имеют ещё и направление, таким образом оператор присваивания по аналогии со структурами здесь применять невозможно:
typedef struct {bit a;bit b;} struct_t;
struct_t x; struct_t y;
x=y; (эквивалентно x.a=y.a; x.b=y.b;)
таким образом если учесть направление сигналов в интерфейсе, то необходимо писать нечто например такое: x.a=y.a; y.b=x.b; (или наоборот в зависимости от направления сигналов).
таким образом для повторного использования кода необходимо вводить нечто на подобие метода класса, внутри которого происходит присваивание с учётом направления. кто-нибудь эксперементировал с подобным?
вариант с прекомпилятором использовать не хочется, хотчется языковыми средствами.
спб

Автор: Armen K May 16 2009, 18:58

загружать можно от суда:
http://electronix.ru/redirect.php?http://www.systemverilogtestbench.org/books/

Автор: des333 Jun 4 2009, 16:06

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

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


Заранее спасибо!

Автор: CaPpuCcino Jun 6 2009, 19:06

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

Автор: IL-76 Jul 14 2009, 14:51

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

Доступа к фтп не имею, а хотелось бы почитать..

Автор: MaOR Jul 15 2009, 06:32

http://electronix.ru/redirect.php?http://ifolder.ru/13111136

Автор: IL-76 Jul 15 2009, 06:54

Большое спасибо, MaOR

Автор: des00 Oct 7 2009, 06:57

господа проясните следующий момент, какой по вашему мнению должен быть результат в outb/outg

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

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



будте внимательны

Автор: Builder Nov 12 2009, 12:19

Вот, наткнулся на упоминание SystemVerilog 2009, по ссылкам кратко некоторые нововведения:
http://electronix.ru/redirect.php?http://www.sunburst-design.com/papers/DAC2009_SystemVerilog_Update_Part1_SunburstDesign.pdf
http://electronix.ru/redirect.php?http://www.sunburst-design.com/papers/DAC2009_SystemVerilog_Update_Part2_SutherlandHDL.pdf
Думаю будт интересно, кто на SV пишет.

Автор: des00 Nov 16 2009, 06:07

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

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

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

Автор: CaPpuCcino Nov 16 2009, 10:20

можно успокоиться только тем, что ещё относительно не скоро

Автор: CaPpuCcino Nov 21 2009, 19:19

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

Автор: torik Dec 9 2009, 19:06

А у меня вот такой вот вопрос...

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

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

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


Дальше я что-то вообще запутался.
В Verilog, можно написать

если а объявлена как wire
и можно написать

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

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







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

Простите за разговорчивость. Нашел ответ на первую часть вопроса:

Автор: CaPpuCcino Dec 9 2009, 23:38

вы ещё забываете о таком замечательном действии как инлайн инициализация
в этом случае переменная приобретает значение ещё до начала симуляционного времени (initial, если я не ошибаюсь, тоже присваивает значение до модельного времени//конечно если не стоит задержка #0)

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

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

Автор: torik Dec 10 2009, 08:02

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



Вот такая штука не катит, почему? Особенность ква?


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

Автор: des00 Dec 10 2009, 09:16

уважаемый CaPpuCcino сильно пошел в теорию, вот на пальцах

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



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



вы правы, тут надо смотреть как работает ваше железо и помнить что bit вектора/массивы весят как минимум в 2 раза меньше чем они же но на logic/reg. Имеется в виду память симулятора %)

Автор: torik Dec 10 2009, 10:12

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


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

Автор: des00 Dec 10 2009, 10:50

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

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





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



tb сокращение от testbench

Автор: torik Dec 10 2009, 12:19

Ну вот, спасибо. Все стало гораздо понятнее

Автор: CaPpuCcino Dec 10 2009, 13:17

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

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


верно


верно. 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 Dec 10 2009, 15:38

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



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



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



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

Автор: torik Dec 10 2009, 17:39

Учту.


Вроде того?:

Автор: des00 Dec 11 2009, 04:09

100% ое попадание %)

Автор: torik Dec 14 2009, 06:17

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

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

Автор: des00 Dec 14 2009, 08:08

IEEE Std 1364-2001 -> 5. Scheduling semantic -> 5.4 The Verilog simulation reference model -> 5.4.1 Determinism/5.4.2 Nondeterminism а лучше весь раздел 5 прочитать %)

Автор: CaPpuCcino Dec 19 2009, 17:50

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

Автор: Andy-P Dec 24 2009, 13:25

Вопрос по методам в интерфейсах от новичка.

Только закончил читать 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 деклараций?

Предугадывая куда меня могут отправить, сходил туда добровольно...
Увы, стандарт в части п. 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 Dec 24 2009, 14:39

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


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


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


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


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



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

ЗЫ. Если вам интересно мое мнение, я бы не использовал интерфейсы еще годика 2-4. Не всегда они нужны, да и корректность их синтеза дело темное

Автор: dxp Dec 25 2009, 04:48

Возражаю. Хотя синтезируемость пока не достигнута в полной мере, использовать уже можно и это реально помогает. Квартус вполне корректно синтезирует интерфейсы (сделали проект, полет нормальный) в базовом варианте (т.е. без generate, task'ов и прочего). Еще в 8-м ква была проблема с массивами интерфейсов, что огорчило, пришлось руками их все расписывать (но и это лучше, чем таскать десятки однотипных строк). В 9-ке пока не проверял эту возможность. Т.ч. ограничивать применение интерфейсов имеет смысл, если нужна переносимость на синтезаторы, которые не поддерживают такие возможности языка. А на ква уже можно.

Автор: des00 Dec 25 2009, 05:30

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

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

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

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

UPD. Еще мне не нравиться вот такая ситуация, я называю это "парадокс интерфейсов". Накувыркался с ним много когда с разными шинами заморачивался для себя. Интерфейсы соединяются по ссылкам на интсансы интерфейсов. Ссылаться можно только на интерфейс того же типа. Теперь рассмотрим шину Wishbone. Есть мастер порты, которые торчат из мастеров и есть слев порты которые торчат в слейвы. Без расплетения веника вы не сможете соединить напрямую мастер и слейв. Пусть вы возьмете модуль интерконнекта, выглядеть будет красивее. Но все равно эти веники расплетаются и заплетаются у него внутри. Или возьмете мастер/слейв с разной разрядностью, потребуется опять конверсия в рукопашку. Это я к тому что соединение на интерфейсах это не банальные slave = master. Это много сложнее и об этом надо помнить %)

Автор: CaPpuCcino Dec 25 2009, 11:11

проще сказать, что интерфейс это не шина (кстати он имено так и называется interface а не bus).
чтобы хорошо понимать разницу, см. понятие класса интерфейса в ООП (например тут http://electronix.ru/redirect.php?http://ru.wikipedia.org/wiki/Интерфейс_(ООП) ).
ЗЫ: использую интерфейсы постоянно и несказанно рад этой возможности. проблему портируемости на разные компиляторы решаю инструкциями прекомпилятору(пока получается двойная работа)

Автор: Andy-P Dec 25 2009, 11:58

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

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


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


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


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


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


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

Автор: des00 Dec 26 2009, 04:22

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

Давайте разберемся по порядку. Начнем со static и в чем потенциальные сложности для синтеза. В SV квалификатор static описывает время жизни объекта. Для освежения памяти обратимся к стандарту IEEE 1800-2007 -> 6.6 Scope and lifetime.

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

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

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


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


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


Моделсим сильно кастирован в области поддержки SV моделирования. По VCS это к SM и yes. Использовал симплифай когда сидел на хилых, но на альтере мне хватает ква. SV он понимает получше некоторых + удобно бегать по разным вьюверам. Правда у него иногда бывают такие заскоки в синтезе, что лечиться только макросом и вставкой примитива целевой FPGA %)

Автор: dxp Dec 26 2009, 06:14

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


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


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

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



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



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



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



В итоге, никакой путаницы, порты модуля все как на ладони, прежнее нагромождение десятков однотипных сигналов вспоминаю как страшный сон.

Автор: des00 Dec 26 2009, 06:32

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


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


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


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



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



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

Автор: dxp Dec 26 2009, 08:40

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


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



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

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

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

Автор: des00 Dec 26 2009, 11:15

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


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


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


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


на праздниках напишу в блоге как я автоматизирую разработку. Там же выложу скрипт-генератор. %)

Автор: CaPpuCcino Dec 27 2009, 16:39

вы меня натолкнули на мысль, что неплохо бы написать приблуду для текстового редактора SciTE, которая в случае необходимости будет конвертить интерфейсные соединения в портовые, а то что я, право слово, постоянно руками через #ifdef код для совместимости дублирую.
ЗЫ: кстати я не католик, да и в Питере я сейчас

Автор: Andy-P Jan 2 2010, 20:50

Денис, благодарю за обстоятельный ответ и советы! И все же...

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


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



рад, что хоть чем-то оказался полезным

Автор: des00 Jan 3 2010, 08:38

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


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

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

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


Мои и не только http://electronix.ru/redirect.php?http://embedders.org/ про разные аспекты разработки. Блог про мой подход к автоматизации разработки пока еще не писал. Открытый http://electronix.ru/redirect.php?http://opencores.org/project,hssdrc. Ну и часть проектов по форуму разбросана %)

Автор: Andy-P Jan 5 2010, 14:59

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


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


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

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

Денис, спасибо за время и внимание, которые вы мне уделили.

Автор: des00 Jan 8 2010, 07:27

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


http://electronix.ru/redirect.php?http://blogs.mentor.com/verificationhorizons/blog/2009/12/18/systemverilog-2009/
добрые люди залейте в закрома %)

Автор: nikolascha Jan 8 2010, 12:35

Можно и внешнюю ссылку оставить, не свои будут благодарны...

Автор: PAB Jan 9 2010, 14:34

uploads/DOCs/SystemVerilog/05354441.pdf

Автор: nikolascha Jan 9 2010, 19:38

Забросте на какую-нибудь шару, пожалуйста...

Автор: MKS Jan 9 2010, 22:15

http://electronix.ru/redirect.php?http://rapidshare.de/files/48970689/05354441.pdf.html

Автор: des333 Jan 9 2010, 22:31

MKS:
Спасибо!

Автор: CaPpuCcino Jun 17 2010, 11:11

Verilog and SystemVerilog Gotchas: 101 Common Coding Errors and How to Avoid Them, Stuart Sutherland, Don Mills. 2007
http://electronix.ru/forum/index.php?showtopic=77497&view=findpost&p=773419

Автор: iosifk Aug 5 2010, 05:13

Если у кого есть SystemVerilog-2009, киньте мне на рабочую почту, т.к. все фтп у меня закрыты...
Или ссылочку, где можно свободно скачать...
Заранее спасибо!

Автор: des00 Aug 5 2010, 05:18

http://electronix.ru/redirect.php?http://disk.tom.ru/wywrb7n

Автор: iosifk Aug 5 2010, 05:27

Большое спасибо!

Автор: lexus.mephi Aug 23 2010, 11:04

Выложил кое-какие материалы по SystemVerilog на своем сайте http://electronix.ru/redirect.php?http://www.systemverilog.ru/. Сайт делаю в свободное от работы время, поэтому ему еще развиваться и развиваться Пишите, если будут пожелания, замечания и т.д.

Автор: DevL Oct 27 2010, 09:58

если можно, было бы интересно тоже посмотреть книгу, ftp нет ( новичек ) и ссылка уже умерла, спасибо заранее!

и еще - есть ли какой то рейтинг документов по SV ? вроде самих доков и много, но все же ....

Автор: CaPpuCcino Oct 28 2010, 08:54

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

Автор: DevL Nov 4 2010, 17:27

ok, посыл понял

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

надо подумать как собрать найболее список книг по форуму или/и ftp

Автор: CaPpuCcino Nov 4 2010, 18:23

ничего централизованно собирать не придётся - открываете топик постите вопрос "назовите 1/2/3 наиболее понравившиеся/полезные/нужное_вставить вам книги по СВ для задач а)моделирования б)верификации в)дизайну"; ждёте 1-2 недели, отбираете, сортируете, выставляете на голосование с открытым пунктом "другая книга(просьба указать)".
наслаждаетесь статистикой и чувством удовлетворения от общественно полезного дела

Автор: DevL Nov 7 2010, 19:12

недавно увидел книгу - A SystemVerilog Primer
http://electronix.ru/redirect.php?http://www.amazon.com/SystemVerilog-Primer-J-Bhasker/dp/0965039110/ref=sr_1_1?ie=UTF8&s=books&qid=1289145502&sr=8-1-catcorr

может кто листал/купил ее уже?

Автор: nikolascha Jan 21 2011, 20:58

Наткнулся на книжку по System Verilog на русском языке:

Меня хватило только на http://electronix.ru/redirect.php?http://www.onlinedisk.ru/file/594729/. Может кто захочет почистить и сделать djvu... А может у кого уже есть она в электронном виде, может я зря 2 часа у сканера стоял?...

Автор: MKS Jan 22 2011, 09:43

У вас там одна из страниц оглавления смазана сильно, 523 кажется. Ну а вообще можно попробовать сделать djvu если её ещё нет в электронном виде.

Автор: nikolascha Jan 22 2011, 10:17

Эта страница 524, она затем продублирована. Т.е. файл sv0527 можно удалить.

Автор: MKS Jan 22 2011, 16:31

Готово, положил в:

Качество получилось не на высоте. Николашка вы наверно сканировали в 2-х цветном режиме, для качественого djvu рекомендуют 300dpi в градациях серого. Если будете ещё чтонибуть сканировать помните об этом . Ну а так что есть то есть. На всякий случай положил книгу на http://electronix.ru/redirect.php?http://filesurf.ru/213277

Автор: PII Apr 2 2011, 16:03

Всем Привет!!!! Пожалуста помогите разобратся. Раньше програмировал PIC и таких проблем невозникало . А сейчас решил прикрутить LCD к Cyclone 1 и задержки неработают
Может есть другие методы
мне нужно
реализовать передачу данных
пробовал
E=1;
delay(15);
DATA=DD;
delay(15);
E=0;


task delay
////
endtask
Интересует Verylog

always @ (posedge clk)
begin
t=t+1;
if ((t>17)||q)
begin
p=1;
t=0;
end

end
always @ (posedge p)
пробовал делать то что выше но так неудобно
Мне нужна универсальная задержка

Почемуто в разных примерах встречается запись # но в quartus 91 почемуто неработает

Автор: Nix_86 Apr 11 2011, 18:14

по просьбе трудящихся освежаю ссылку:
http://electronix.ru/redirect.php?http://rapidshare.com/files/456951617/IEEE_Standard_for_SystemVerilog___Unified_Hardware_Design_Specification__and_VerificationLanguage.pd

Автор: CaPpuCcino Apr 20 2011, 14:18

диар олл,

подскажите пожалуйста по приведению типов.
есть следующая комбинация типов:

typedef bit [7:0] byte_type_vt;
typedef bit [31:0] memory_word_vt;

typedef union packed {
byte_type_vt [0:3] byte_view;//ахтунг - реверсивный порядок
memory_word_vt memory_word_view;
}mem_word_ut;

mem_word_ut bit_vec_32;
memory_word_vt a;

вопрос. как будут располагаться биты каждого байта, если смотреть на них как на 32-битное слово, т.е.

a=bit_vec_32.memory_word_view;

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

спб

Автор: ViKo Apr 21 2011, 07:01

В стандарте не смотрел, но по моим представлениям должно получиться:
byte0-bit7,... byte0-bit0, byte1-bit7, ... byte1-bit0, ... ... byte3-bit0
Mожно посмотреть в книжке "SystemVerilog for Design".
Только вряд ли это называется "приведение типов".

Автор: CaPpuCcino Apr 21 2011, 10:34

вот и по моим тоже, а по представлению ментор графикс в последних версиях квестасима, видимо нет (начиная с версии 6.5е). у них в последних версиях вообще какая-то беда(10.0а я даже копать боюсь - там очевидно косяк в планировщике событий), но об этом в отдельной ветке, когда напишу им очередное послание.
в книжке этого я не видел - там пример с размерностью [3:0] [7:0] (однако, книжка всё-таки не стандарт - на неё не сошлёшься при апелляции ).
ЗЫ: да это наверное не приведение типа, но как точно назвать я не знаю, поэтому не могу сообразить в каком разделе стандарта смотреть

Автор: ViKo Apr 21 2011, 12:46

В главе 7. Агрегатные типы данных. Там и картинки есть. Только вникать сложнее.

Автор: CaPpuCcino Apr 21 2011, 13:10

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

Автор: ViKo Apr 21 2011, 13:36

В стандарте не смотрел (внимательно). По логике, так, как вы написали - естественный порядок нумерации. Биты нумеруются от старшего к младшему, элементы массива - от младшего к старшему.

Может, картинка из книжки поможет.

Автор: CaPpuCcino Apr 21 2011, 14:57

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

Автор: ViKo Apr 21 2011, 18:16

Попробуйте без typedef, просто byte и int.

Автор: CaPpuCcino Apr 21 2011, 19:06

на это я пойтить не могу! в реальном проекте иерархия типов намного сложнее (до 5-6 уровней). если б было бы так просто как в примере, я конечно особо не горевал бы.
пока, где нашёл заменил на явное присваивание через циклы. но проект огромный и расставлять костыли везде ток из-за ср....х румын оутсорсеров я не стану. сижу на старой версии Квесты.

Автор: ViKo May 31 2011, 10:52

Близкое к последнему, что здесь обсуждалось.
Обнаружил разногласия между C и SV.
В языке C битовые поля начинаются с младшего (правого) бита слова, и идут к старшим. Например,

В языке SV биты в упакованных структурах идут слева направо (от старшего к младшему).

Автор: ysmat Feb 22 2012, 12:01

почему не работает знаковое умножение

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

Автор: Poluektovich Feb 22 2012, 12:36

так будет работать
assign OUT = IN * 12'sd1000;

Автор: ysmat Feb 22 2012, 15:35

да действительно заработало
правда места много занимает

думаю вот попробовать этот алгоритм
будет ли экономия
http://electronix.ru/forum/index.php?act=attach&type=post&id=65881

Автор: myq May 17 2012, 09:12

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

Автор: Кнкн Nov 30 2012, 12:08

Не может ли кто-нибудь поделится файлами примерчиков
от менторовского UVM/OVM cookbook?

Автор: Poluektovich Dec 2 2012, 08:46

Выложил в upload/CODE

Автор: Кнкн Dec 3 2012, 07:43

Большое спасибо!

Автор: Mikhalych Dec 5 2012, 04:13

а можно поподробнее - что за "менторовский UVM/OVM cookbook" и где его достать?

Автор: Poluektovich Dec 5 2012, 06:03

Рецепты по использованию методологии UVM, доступен после регистрации:
http://electronix.ru/redirect.php?https://verificationacademy.com/cookbook

Автор: Кнкн Dec 5 2012, 10:48

/upload/DOC/SystemVerilog

Автор: Mikhalych Dec 5 2012, 15:10

Спасибо! Весьма полезная метОда, датируется 2011 годом... на verificationacademy.com после регистрации мне не удалось найти такой полной компиляции UVM+OVM как эта

Автор: NeedHelp Feb 1 2013, 11:43

Привет всем! Я начал работать в UVM, но многие вещи, которые  не понимаю, я хотел бы спросить, если у кого-то есть пример создания UVM testbench?

Автор: Poluektovich Feb 4 2013, 12:10

В дистрибутиве UVM есть хорошие примеры в каталоге examples/integrated.

Автор: torik Feb 7 2013, 12:36

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

Автор: true_pb Feb 14 2013, 12:36

я хочу невозможного??? надо из logic [5:0] сделать стринг, чтоб вывести число на экран через uvm_report. пытаюсь привести через str_val = 'string(logic_val), но пишет всякие символы! ткните носом, пожалуйста(

Автор: des00 Feb 14 2013, 15:05

$psprintf/$sformat ваш выбор

Автор: Vadim May 30 2014, 12:37

Случайно наткнулся на перевод нескольких страниц обзора новых фич в SV-2012. Перевод хороший, можно было бы сказать отличный, если бы не парочка косяков.
http://electronix.ru/redirect.php?https://freelance.ru/download/?id=395680

Автор: verali Nov 10 2014, 06:31

Здравствуйте! А в каком разделе стандарта SV четко написано, какие операторы являются синтезируемыми, а какие нет?

Автор: Poluektovich Nov 13 2014, 12:18

В стандарте не описано, но зато есть статья:
http://electronix.ru/redirect.php?http://www.sutherland-hdl.com/papers/2013-SNUG-SV_Synthesizable-SystemVerilog_paper.pdf

Автор: lexus.mephi Jan 27 2015, 13:18

Подскажите, куда переехала менторовская UVM cookbook? FTP прошарил - нашел только примеры кода от этой книги.

Автор: SM Jan 27 2015, 13:26

pub/DOC/Mentor (если, конечно, про местный FTP речь)

Автор: lexus.mephi Jan 27 2015, 13:39

Спасибо =)))

P.S. Эту книгу неплохо бы еще в /pub/BOOKS/Verilog/SystemVerilog закинуть

Автор: Кнкн Mar 31 2015, 13:19

Может быть нужно кому-нибудь:
Uvm Cookbook от mentor 13-го года
/upload/DOC/Uvm

Автор: lexus.mephi Apr 22 2015, 05:28

Есть у кого-нибудь вот такая книга по UVM:

Advanced Verification Topics Paperback – January 3, 2012
by Bishnupriya Bhattacharya (Author), John Decker (Contributor), Gary Hall (Contributor), Nick Heaton (Contributor), Yaron Kashai (Contributor), Neyaz Khan (Contributor), Zeev Kirshenbaum (Contributor), Efrat Shneydor (Contributor)
?

Спасибо!

Автор: Fitc May 28 2015, 10:20

А есть ли у кого книги как писать TLM-модели на systemverilog с использованием/без использования UVM?

Автор: des00 Jun 6 2015, 08:49

Если учесть что UVM вырос из сращивания OVM и VMM, то книги Janick Bergeron "Verification Methodology Manual for SystemVerilog" и Mike Mintz "Hardware Verification with SystemVerilog. An Object-Oriented Framework" должны подойти. Еще, если учесть что эти выросли на основе менторовской AVM, то неплохо прочитать документы от ментора на эту тему. А по самому UVM уже есть два учебника, в том числе один от авторов

Автор: favalli Jun 10 2015, 06:50

На сайте accellera есть юзер гайд и референс по UVM, а на сайте testbench.in есть куча лаб и основ применения.

Автор: Ereminem Jan 14 2016, 07:18

Не подскажите, где бы можно было приобрести/скачать книгу Verification Methodology Manual for SystemVerilog?
Я так понимаю, для освоения верификации проектов ПЛИС на SV и UVM - это хорошая вещь. Или что другое посоветуете?

Автор: x736C Jan 17 2016, 00:04

Ereminem, вторая страница гугла
http://electronix.ru/redirect.php?http://vdisk.weibo.com/s/aCH4qrkah4ecZ

Нажать синюю кнопку с пиктограммой скачивания.

Автор: des00 Jan 17 2016, 03:40

Идеи VMM действительно вошли в UVM, но в основном UVM основан на OVM (Open Verification Methodology). Книга хорошая, полезная. Но для другой области

Автор: Leka Nov 11 2016, 15:40

"... И обсуждение тонких моментов синтаксиса."

Почему-то можно:
assign a=b, c=d;
но нельзя:
always_comb a=b, c=d;
а только:
always_comb begin a=b; c=d; end

Есть какой глубокий смысл в таком ограничении ?

Автор: Fitc Jan 6 2017, 15:19

Думаю, это связано с тем, что оба присваивания a=b и c=d в assign выполяются параллельно, а в always_comb сначала выполняется присваивание a=b; затем c=d. В данном случае с точки зрения результата присваивания разницы нет, но с точки зрения трактовки данных конструкций симулятором есть большая разница.

Автор: sonycman Jul 14 2017, 15:23

Вышла новая книга RTL Modeling with SystemVerilog for Simulation and Synthesis: Using SystemVerilog for ASIC and FPGA Design.
Буду премного благодарен, если кто даст ссылочку.

А вообще хотелось бы печатный вариант, но дешевле будет самому распечатать, чем у буржуев покупать за 120 долларов...

Автор: JNAD Sep 2 2017, 17:52

Вопрос к знатокам, кто знаком с интерфейсом UNI/O. Подскажите как сформировать последовательность импульсов и считать данные с микросхемы 11AA02E48. Пытаюсь написать на SystemVeriloge, но не получается, непонятен сам принцип формирования последовательности и считывания. Есть наброски кода, но даже не знаю стоит ли их скидывать.

Автор: Mikhail B. Nov 11 2017, 16:45

Можете объяснить в чём глобальное отличие Verilog от VHDL? Изучал второй, сейчас требуют погрузиться в первый, есть ли смысл.
Где можно почитать на эту тему как "для чайников"?

Автор: Maverick Nov 11 2017, 22:19

http://electronix.ru/redirect.php?http://www.twirpx.com/file/43250/

Автор: Mikhail B. Nov 12 2017, 09:53

Спасибо большое!

Автор: Кнкн Nov 28 2017, 12:42

Нет ли возможности скачать у Синопсиса две статейки?

http://electronix.ru/redirect.php?https://www.synopsys.com/Community/SNUG/Pages/snugresults.aspx?qry=uvm

Shutdown with Agreements in a UVM Testbench - Silicon Valley, 2017
Mark Glasser - NVIDIA

Applying Stimulus and Sampling Outputs - UVM Verification Testing Techniques - Austin, 2016
Clifford E. Cummings - Sunburst Design

Автор: Losik Nov 28 2017, 14:33

Статьи + презентации.

Автор: Кнкн Nov 28 2017, 15:33

Большое спасибо!

Автор: Мур Dec 20 2017, 08:14

http://electronix.ru/redirect.php?https://dvteclipse.com/documentation/sv/index.html

Автор: Мур Jul 21 2018, 14:43

Мужички, кто поможет?
Почти год пытаюсь достать книгу Практикум по проектированию на языках VerilogHDL и SystemVerilog Мурсаев А.Х., Бурнаева Э.Г.
http://electronix.ru/redirect.php?https://lanbook.com/catalog/informatika/praktikum-po-proektirovaniyu-na-yazykah-veriloghdl-i-systemverilog-4/

И на книжную балку заказывал ...и в Белгород на главпочтампт ...и командировочным.
Самое ужасное, что ВСЕ мои попытки найти в интеренете заканчивались кидком. Потратил уже денег на две таких книги!

Может оно того и не стоит? Кто поделится впечатлениями об творении?

Спасибо

Автор: andrew_b Jul 22 2018, 09:09

Уже судя по тому, что авторы описание схемы упорно называют программой, книга очень мягко говоря не очень.

Автор: Мур Aug 1 2018, 08:11

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

Как только появится возможность поиметь текст книги слезно прошу в личку дать натырку. ...или сам файл. Спасибо!
...Вот только когда это будет?...

Автор: ViKo Aug 1 2018, 09:12

Даже стиральная машина болтает труселя и носки в барабане по программе.
А язык SystemVerilog описывает программу поведения схемы.
Если придираться, то к содержимому книги, а не терминам.

Автор: Мур Aug 1 2018, 09:45

Да как ни крути!..
В вашем случае,- ПЛИС это форма барабана, её объем, материал, количество точек крепления оси и тип передачи с движка. Это как периферия к внешнему интеллектуальному звену. Программистом выступает хозяйка, которая знает, что она бросает в барабан, задает режимы, вливает моющее средство и дает пуск на определенное время. Более низко уровневый программист описывает логику стирки и драйвер по управлению двигателем во ВНЕШНЕМ по отношению к барабану интеллектуальном звене.
....Даже если взять вариант, что это звено будет внутри ПЛИС будет описан вычислитель с определенной системой команд, памятью и внешними интерфейсами. ВСЕ! Это потом нужно ОТДЕЛЬНО программировать на ДРУГОМ языке...

...вы не внимательны! Достоинство SV в ориентации на тестирование, а значит хорош в тестбенчах! А это не обязательно синтезабельность. Там вольностей больше. Можно и программные трюки писать. В создании дизайна пишут не программу, а поведение. Причем число "программных счетчиков" равно числу процессов (а это тысячи!!!)

Автор: ViKo Aug 1 2018, 10:50

Пишут программу поведения во времени. А не просто статическую схему описывают. Кончайте придираться, займитесь изучением. Я по книжке Stuart Sutherland "SystemVerilog for Design" учился.
(программа - она всегда во времени)

Автор: Мур Aug 1 2018, 16:48

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

Я бы сказал, что речь для ПЛИС идет о создании архитектур, которые можно программировать на другом языке(машинных кодах, ассемблере и т.п.)