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

Документация на System Verilog

В книжке "Springer - SystemVerilog for Design, 2nd Edition" говорится, что wire, var - это тип. А logic/bit - это тип данных.

 

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

 

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

 

NOTE—There are several forms of data in SystemVerilog: literals (see Clause 3), parameters, constants, variables, nets, and attributes (see 4.17). A data object is a named entity that has a data value associated with it, such as a parameter, a variable, or a net.

Verilog constants are literals, genvars parameters, localparams, and specparams. Verilog also has variables and nets. Variables must be written by procedural statements, and nets must be written by continuous assignments or ports. SystemVerilog extends the functionality of variables by allowing them to be either written by procedural statements or driven by a single continuous assignment, similar to a wire. Because the keyword reg no longer describes the user’s intent in many cases, the keyword logic is added as a more accurate description that is equivalent to reg. See 6.9.2 for details on SystemVerilog type equivalence rules. Verilog has already deprecated the use of the term register in favor of variable.

 

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

 

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

 

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

 

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

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


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

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

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

wire logic sdfgsdfg;

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

для обратной совместимости с V был введён следующий принцип:

- объекты "цепь" по умолчанию являются logic(тип данных) => wire a; <-> wire logic a;

- всё что явно не объявлено объектом типа "цепь" является var(класс объекта) => logic a; <-> var logic a;

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

((кстати тип данных по умолчанию назначается и переменной, но для этого должен быть явно назначен тип объекта var a; <-> var logic a;))

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

 

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

верно

 

Инлайн инициализация, насколько я понял, тождественна initial?

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

т.е. initial a=0; образца 1995года эквивалентен initial #0 a=0; образца 2005 года.

а int a=0; образца 2005 эквивалентен initial a=0; образца 2005, но не эквивалентен initial a=0; образца 1995

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


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

Денис, ты не прав. Не помню с какого именно стандарта, но подход к типам объекта изменили принципиально.

 

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

 

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

 

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

 

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

 

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

 

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

т.е. initial a=0; образца 1995года эквивалентен initial #0 a=0; образца 2005 года.

а int a=0; образца 2005 эквивалентен initial a=0; образца 2005, но не эквивалентен initial a=0; образца 1995

 

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

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


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

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

 

Учту.

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

 

Вроде того?:

The SystemVerilog standard enhances the semantics for in-line
variable initialization. SystemVerilog defines that all in-line initial
values will be evaluated prior to the execution of any events at the
start of simulation time zero. This guarantees that when initial
or always procedural blocks read variables with in-line initialization,
the initialized value will be read. This deterministic behavior
removes the ambiguity that can arise in the Verilog standard.

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


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

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

 

Verilog’s nondeterministic order for variable initialization can

result in nondeterministic simulation behavior for asynchronous

reset or preset logic in sequential models. This nondeterminism can

affect resets or presets that are applied at the beginning of simulation.

 

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

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


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

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

 

 

 

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

 

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

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


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

наткнулся в новом стандарте на интересную лазейку для параметризирования типов данных(если я, конечно, ничего не попутал):

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

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

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


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

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

 

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

 

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

 

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

 

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

 

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

 

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

Увы, стандарт в части п. 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 для моделирования, симулирования, и, возможно, для синтеза (в паре с Квартусом)

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


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

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

3. Эти задачи или функции также должны быть определены как automatic и не содержать static деклараций?[/i]

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

 

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

 

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

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


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

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

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

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


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

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

 

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

 

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

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

3. ограниченность. интерфейсы это не тип сигнала, а отдельный объект + они не наследуются.

 

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

 

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

 

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

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


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

Это я к тому что соединение на интерфейсах это не банальные slave = master. Это много сложнее и об этом надо помнить %)
проще сказать, что интерфейс это не шина (кстати он имено так и называется interface а не bus).

чтобы хорошо понимать разницу, см. понятие класса интерфейса в ООП (например тут http://ru.wikipedia.org/wiki/Интерфейс_(ООП) ).

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

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


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

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

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

 

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

 

Цитата(Andy-P @ Dec 24 2009, 07:25)

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

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

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

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

Эти рассуждения противоречат второй цитате, поэтому и возник первый вопрос, разумеется в контексте синтезируемости.

 

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

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

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

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

 

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

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

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

 

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

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

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

Моделировать это можно, но синтезировать нет, так как все тот же ref.

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

 

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

У меня похожая ситуация, но ModelSim вместо Questa.

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

Что скажете о Synplify или Quartus сам по себе не хуже?

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


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

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

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

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

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

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

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

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

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

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